シリーズ記事
- SE約８年経験して重要だと思った仕事のスタンス（前編）
- SE約８年経験して重要だと思った仕事のスタンス（後編）←今回
ホウレンソウ
伝える時は相手の身になる
この課題を解決したい、その為に、この人からアドバイスをもらいたい。
自分でどうすれば良いかわからないので、解決策、ヒントが欲しい。
そのような時に、相手に、自分は何を求めているのかを伝える必要があります。
そして、どういう伝え方をすれば伝わりやすいかを考える必要があります。
この情報は、自分の課題を解決してもらう為に、相手にとって必要な情報か？を考える必要があります。
よくやってしまいがちなのは、無駄に謙った言葉遣いを連発したり、ダラダラ不要な現状報告をしたりで、結局自分が何を言いたいのか相手がわからなくなり、相手の時間を奪うことです。
無駄に丁寧な言葉遣いはいらない
稀に天皇陛下や社長相手と話してるんじゃないかと思うくらい、無駄に謙った言葉遣いをしてくる人がいます。
私の場合は、無駄に丁寧な言葉を使われるよりも簡潔に、何に困っていて、私に何をしてほしいかだけを言ってくれた方が遥かに嬉しいです。
私は「〜させて頂く」構文が嫌いです。
チャットだと尚更長文になりがちで読みづらく、イライラします。
その無駄な言葉1秒1秒の積み重ねで時間を奪われるのに辟易します。
無駄に敬語使う人は、だいたい身内に尊敬語を使ったり、目上の人の行動に謙譲語使ったりします。
だったら無礼のない最低限の言葉遣いさえ抑えていれば問題ありません。
相手にとって必要な情報は何かを考える
相手にとって不要な、自分の現状報告や事の経緯をダラダラ伝えるのもやめた方が良いです。
以前、私がコードレビューをしていて、指摘事項が多く、レビュイーの修正も躓いていて再レビュー依頼するのに時間がかかってしまう場面がありました。
そこで、レビュイーから長文チャットがきました。
簡潔にまとめると下記が書かれていました。
- ○○の箇所がうまくいってないのでいったん○○の対応をとる予定だ。
- 先に○○の箇所に関してのみ対応した。
- これから諸々調査や修正を行う。
- 指摘事項の残りの箇所も対応する。
私はこの文章を読んで、自分が何をすれば良いのかわかりませんでした。
何を教えて欲しいのかもわからない。どこを重点的に再レビューして欲しいのかもわからない。いつ終わるのかもわからない。
「どこをレビューすれば良いですか？」と聞き返しました。
すると、本日の夕方頃までかかりそう、勿論それまでにレビュー可能な状態になったらそこで声掛けするという旨の返事が返ってきました。
私は彼の教育担当でもなんでもなく、ただのコードレビュワーです。
レビュワーの私にとっては、彼が今具体的に何をしているのか、何をするのか知ったこっちゃありません。
いつ再レビュー依頼がくるのか、どこを重点的に再レビューして欲しいのかだけ教えて欲しいのです。
「色々躓いて時間がかかる為、○○時頃にレビュー依頼させてください。」とだけ伝えてもらえれば良かったのです。
もしわからなくて進められないのであれば、「○○をどう直せば良いのかわからないので画面共有などで教えてください」とだけ伝えてもらえれば良かったのです。
単純に、今どういう問題が発生していて、相手にどうして欲しいのかさえ伝えれば良いのです。
相手に、自分の状況を知らせる必要があるのか？
リーダーに進捗報告するにしても、相手が欲しい情報は、現状○％の進捗で○時頃までに終わる予定、
問題があれば、○○に躓いていて○○時頃になってしまう。または、助けが欲しいという情報です。
自分の現状を詳細に相手に把握させる必要があるのは、せいぜい自分が新人で相手が教育担当の先輩とかの場合くらいではないでしょうか。
自分の状況を詳細に相手に知って欲しいというのは、自分がこういう状況だからうまくいかなくても許して欲しい、または面倒を見て欲しいということの現れなのかなと思ってしまいます。
自分で考えるべきことと、他人に確認すべきこと
誰かに確認すべきことを確認せず自己判断で決めてしまう
自分で判断すべきことを誰かに確認してしまう
というのはNGです。
リーダーの性格にもよりますが、私の経験上は自分で考えて判断してくれというリーダーが多かったです。
普通に考えて、これだとおかしいよねというものの判断を他人に委ねると、ウザいと思われたり、君はどっちが良いと思うの？と聞き返されることが多いです。
自分に決定権がない場合や、ホウレンソウを細かく求めるくるリーダーに対しても、自分で考えた上で、○○なので、○○で良いですよね？という確認の仕方の方が良いです。
選択肢のメリット・デメリットを考慮した上で、総合的にこっちが良いと判断して提案すれば、リーダーの仕事の手間を省いてあげたことになります。
自分で良し悪しを全く考えもせず、丸投げはその人に仕事を任せている意味がありません。
逆に、特に理由もないけどなんとなくこっちで良いと思ったものや、
仕様を決める人のやろうとしている目的、意図を把握しないまま勝手に決めて進めるのも事故につながります。
遅れても品質優先
ちゃんと若い時から開発経験を積んでいた人にとっては当たり前のことかもしれませんが
私は本格的に開発経験をさせてもらえるようになったのは、上流工程をやった後でした。
決められたスケジュール内に収めないといけないから、設計の考慮漏れがあるにも関わらず完了としてしまう。
書いたコードの全ての処理を一度も動作確認せず、テストコードも書かずにマージ。
これをやると、本当に後で痛い目を見ます。
多くの人に迷惑をかけます。
特にバグ改修やちょっとした改修で、書き換えたコードの動作確認が不十分のまま上げてしまって本番で事故るケースは結構見ます。
私は、コードは絶対動作確認と心に決めています。
面倒だからという気持ちがあると、大丈夫でしょと勝手に甘く見積もって事故になります。
動くか動かないか自分で不安になるようなものをあげるより、遅れても品質優先。
遅れても考慮漏れを極力なくした設計。
間に合わなさそうだと思った時は早めにリーダーに相談すべきです。
低品質なものを上げて間に合わせたとするよりも、全体的な痛手ははるかに小さくなります。
問題が発覚した時に、高い優先度として割り当てなければならず、想定外の作業なのでスケジュール組み直しになるからです。
前工程でちゃんと作っておけば、後工程で本当に良かったと必ず思えます。
逆に前工程でテキトーにやってしまうと、後工程で過去の自分に殺意がわきます。
メンバーからも殺意を向けられます。
この記事が誰かの役に立てれば嬉しいです
コメント