本記事は『エンジニア育成現場の「失敗」集めてみた。 42の失敗事例で学ぶマネジメントのうまい進めかた』の「Episode 05 完璧な報告を強制する「賢者のレポート」」から抜粋したものです。掲載にあたって編集しています。
また、Episode 05を含む5つのエピソードをまとめた特別抜粋版（PDF）も配布しています。
60%の完成度で、おおむね用事は済んでいる
業務にはレポートがつきものです。出張に行ってもバグを修正しても、なんらかの報告を文書で残します。ただ新人の作るレポートは、上司からはどうにもお粗末に見えてしまいます。これも教育の一環と差し戻すのですが、十分な説明がなければ、新人には何が足りていないのか、理解できません。見えない完成に向けて、時間を無為に使わせるだけです。
実験結果をレポートしたつもりなのに
ガクさんは今週、アルゴリズムチームで測定原理の研修です。刺激プローブでロボット皮膚に様々な刺激を与え、刺激に応じてどういう信号が返ってくるのか、実験を行っています。
実験お疲れ様です。ではこれまでの実験結果をまとめて報告書にしてくれるかな。レポートすることも業務だからね。
了解しました！ えーと、今日中ですね。Excelシートにデータは取ってあるので、すぐにお送りできます。
ガクさんはこんなこともあろうかと、測定したデータはすでにExcelにまとめていました。早速Excelに表紙を付けてアルゴリズムリーダーに送りました。
あーガクさん。このレポート、データしかないよ。このデータをどう分析したのかが大事なので、考察を追記してもらえるかな？
あれ？ 実験結果をまとめてと言っていたのに……とガクさんは少しもやっとしましたが、早速レポートにグラフを追加し、考察を書き加えました。
考察を加えてくれてありがとう。だけど、これ事実と考察が混じっちゃっているよ。そこは分けてくれないと困るのだけど……。
またまた書きなおしです。改めてExcelの別タブに考察のためのシートを作成し、明確に実験結果と分けてみました。さすがにもうこれで完璧だろうと、リーダーに送ったのですが。
結局何がわかったのかよくわからないなあ。いっぱい考察は書いてくれているけど、最初のページに簡潔に目的と結果を書いてほしいんだ。そもそも目的ってなんだっけ？ その目的は達成できたの？
なんだかまたゴールが遠ざかった気がします。そういえばこのレポートの目的ってなんでしょう。目的は研修ということでいいのでしょうか。研修は終わったので達成できていますが、なんとなくそういうものではない気がします。
えーと、いったい何が記載できていたらいいのかなあ。すぐできると思っていたのに、結局今日1日このレポートにかかりっきりだよ……。
ガクさんは自分に求められていることがわからず、すっかり落ち込んでしまいました。
この調子だと、レポートだけであと何日も費やしてしまいそうだよ。実験結果があるからもういいんじゃないのかな。疲れてきちゃったなあ。
完璧なはずの俺のレポートがダメ出しされる件
企業でなんらかの活動を実施した際には、たいていの場合、レポートによる報告が求められます。上司からメールで「今日中に居室で作業上のリスクがある箇所を挙げてください」と指示があったなら、メールで「ブチョーさんの机のタコ足配線」と返すのも大事なレポートの1つです。
この頻繁に発生するレポートは、大学のときの論文作成とはまた異なるスキルが必要となります。新人の観点でじっくり細部までこだわり、美しい装丁までしつらえ、もうこれで100%完璧！ と思えるレポートを作成したつもりでも、上司から見たら本当に書いてほしかったことが記載されていなかったり、いくつもダメなポイントが見えてしまったりするものです。「悪いけどこれ今日中に修正できる？」と、上司から差し戻される光景は、職場の日常風景ですね。
期待されているのにその期待がわからない
これは必ずしも新人の能力に問題があるわけではなく、次のような原因によるものです。
- レポートの目的を達成できていない（目的を理解していない）
- 提出形式が間違っている
- 内容が足りない
- 業務内容の理解が間違っている（正しく伝わっていない）
- そもそも自分の業務じゃなかった
- 実はもうレポートはいらない
目的不明なんてそんな馬鹿な、と思われるかもしれません。しかし、上司が想像している以上に、新人にとって会社からの期待というのはわかりにくいものです。例えば、金曜日にブチョーさんから「今週の成果を1行か2行にまとめてメールで送ってくれ」という業務要請があったとしましょう。1行程度ですからなんということはありません。早速新人のガクさんはメールで次のような1文を送りました。
すると、ブチョーさんから速攻で「全然わからん！」とメールが返ってきました。バグ対応はやったことであって成果ではありません。バグの対応をした結果、そのバグはFixできたのかどうかも不明です。
報告しろと言われると、ついつい自分のやったこと（Do）を報告しちゃうのですが、レポートを求めている側は基本的に結果（Result）を欲しています。例えば「残バグ50件のうち今週は20件修正完了した。予定通りのVelocityが出ています」というような内容をブチョーさんは期待しているのです。
新人は会社勤めを始めたばかりですから、なかなか上司から求められていることがピンときません。きちんと期待に応えないと何度でもやり直しです。目的から外れたレポートを見ると、上司はつい、なんでこんな簡単なレポートも満足に書けないんだと叱責してしまいがちです。
しかし、そもそも依頼したレポートにどんな内容を期待しているのか、実はリーダーから十分に伝えられていない場合もよくあることなのです。
ここが失敗のポイントです。レポートに関してゴールの条件や基準を十分に与えていないのに、繰り返しダメ出しをすることで、新人にとっては求められていることがわからず、何を改善すればいいのかもわからないまま、ひたすらトライアンドエラーを繰り返し、時間とやる気を浪費してしまいます。
やがて、自分の報告が理解されないのは上司のせいだと思うようになります。まるでいじめのように無駄な労力を強いられているだけではと思い、組織に対する不信感が芽生えます。そのうち、理解されない上司のもとではなく、もっと生産性の高い仕事ができる組織で働きたい、と思うようになるかもしれません。
ええ？ ガクさんまだレポート書いているのか。時間かけすぎだよ。レポートに対するリーダーの期待を理解できていないかもしれないなあ。少し話を聞いてみるか。
業務の目的と受け入れ基準を明確にする
そもそも業務の前には、業務の目的と受け入れ基準を伝えることが大切です。事例の原理実験研修であれば、
研修の目的：ロボット皮膚の刺激測定の原理を理解すること
レポートの受け入れ基準：「理解の程度とその根拠を示す」項目があること
ということを最初に伝えるべきだったのです。そもそもレポート以前に、目的もゴールも伝えずになんとなく業務を実施させていては、成果にたどりつけません。
また新人が周りに相談できる環境も必要です。もし上司から見て、新人が業務に時間をかけすぎていると感じたら、業務を正しく理解しているかどうか、自分が求められていることを正しく把握できているのかどうか、軽く聞いてあげるのがよいでしょう。
60％チャレンジ
業務を60%ぐらいできたら一旦提出させる、というのも1つの手です。前述の「今週の成果を1行か2行にまとめてメールで送ってくれ」という業務要請に関しても、とりあえず「残バグ50件のうち今週は20件修正完了した。」とだけ書いて出してくれれば、実はもうOKだったりします。
もし上司が「予定通りなの？」と聞いてきたら「予定通り」と追記して出せばいいのです。じゃあ来週は、予定通りかどうかも書くようにしよう、と書き方を修正すればよいのです。
業務は誰かとの関係性の中で成立します。そのため何事も自分の中で勝手に作り上げた「完璧」な姿を目指すのではなく、60%ぐらいでキャッチボールを始めるというのが効率的です。意外と60%でも用事が済んでしまうケースが多いので、省力化にも繋がりますし、新人としても悩む時間が減ります。
上司としては、新人の業務に関する理解は不十分である、という前提を持って早めのコミュニケーションを心がけることが大事です。ふむ。これってちょっとAgileですよね。
