エンジニアの報連相について
先日、後輩君と一緒に会議に出まして、 そこで後輩君の報告を聞きながらちょっと思ったので書いてみることにします。
まあ、後輩君が要領を得ない説明をするというのは、非常にありがちで自分もそうだったなーと思い出しました。
恥をさらすようですが、昔自分がやっていたことと、今気を付けていることを整理してみたいと思います。
昔の自分
上司「黒ブラくん、進捗はどうですか？」
ぼく「えっと、いまプログラムを書いていて、コンパイルエラーがやっとなくなりました」
上司「コンパイルエラーが無くなるのは当り前でしょ」
ぼく「あっはい」
上司「どうなの？」
ぼく「これから流してみます」
上司「間に合いそうなの？」
ぼく「大丈夫だと思います」
今思うと、だいぶアチャーな感じですね。。
このようなやり取りをしていたのは、ぼくが商社の情報システム部門で入社2年目くらいのころでした。
非コンピュータ系の学部を卒業した状態で、1年目はPCヘルプデスクをやり、2年目の後半からは基幹システムの新規開発プロジェクトに参加し、プログラム製造を担当していました。
初めてのプログラミングはPLSQLで、SQLの文法を理解するところからでしたが、商社の新人として入社したので、情報処理の教育はほぼ受けていません。
「SQLを覚えて」と言われて本を渡される感じの現場です。
当時、基本情報処理試験には3回落ちており、受験自体をやめてしまったので、基礎はだいぶ抜けていたと思います。
（今ではさすがに受かると思いますが。。）
なので、非常に聞いていて不安を感じる報告ですね。これからの工程とか理解してんのかという感じです。
もちろん当時は理解せずに報告しており、後で大変な目に合うのですが。。
どうすれば良かったか？
その場にいる人のレベルや会議の趣旨を理解した上で質問の意図と求められるレベルを想定する
想定するレベルに合わせて報連相する
具体的に進捗確認であれば、現在の状態、今後の予定、スケジュールとの差異、問題が発生しているか、等を簡潔に述べる
必要であれば、ホワイトボードに図を書く（積極的に）
報連相の常として結論から先に言うというのも大事だと思います。
あと、上司から質問が何回も出るというのは「こいつ本当にわかっているのか？」という疑問を払しょくするためでもあります。
そこで4に挙げたように、図を描くと「わかっている感」が生まれるので、聞いているほうに安心感が出てきます。
会議の時間を使ってしまうという問題はあるのですが、積極的に使っていきたいテクニックです。
製造工程の理解とマイルストーンの設置、スケジュールの感覚などは基礎的な教育と経験で得られるものなのですが、進捗の報告をする前に理解しておかないとそもそも話が通じないので、そこは上司や先輩とかがフォローしてほしいですね。
ちなみに後輩君はぼくと比べて基礎が非常にしっかりしており、「おまえこの年齢でこのスキルって、無敵じゃね？」ってぐらいの逸材なので、この手のテクニックを積極的に伝授してパーフェクト超人にパワーアップしてもらおうと思っています。
だいぶ待っていたよ
