NEW! スキル
現場を知り尽くしたPMOが教える
技術を、評価に変えるコツ客先常駐の現場では、技術力だけで成果や価値が正しく伝わるとは限りません。相手に合わせた伝え方、意思決定者を動かす報告、信頼を損なわない振る舞い、情報をつかむ動き方もまた、プロジェクトを前に進めるための技術です。 本連載では、数多くの開発現場を見てきたPMO・甲州潤さんが、客先で評価される人と損をする人の違いを実例から解説。単なるコミュニケーション論やマナー論ではなく、技術力を成果と評価につなげ、その経験を次の現場でも通用するキャリアの資産に変えるための「現場技術」を紹介します。
「進捗はどうなっていますか？」と聞かれ、「〇〇のタスクをやっていて、進捗率は70%です」と答える。
「問題が発生しました」と聞き、「〇〇の調査を行っていて、現在対応中です」と報告する。
自分としては、状況を包み隠さず正しく伝えているつもりなのに、お客さまのリーダーや上司からは「それで、結局予定通り終わるの？」「何が原因で、どう対処するつもりなの？」と、追加で質問が返ってくる……。
客先常駐（SES/SI）の現場で、こうしたやり取りに心当たりはないでしょうか。
「せっかく報告したのに、なぜ分かってくれないのか」
「何度も同じような質問をされて、作業を中断させられるのが苦痛だ」
もしあなたがそう感じているとしたら、少し注意が必要です。相手の理解力が欠けているのではなく、「あなたが報告できていると思っているその内容が、実はまったく報告になっていない」という状態になっています。
今回は、現場のエンジニアが陥りがちな「報告したつもり」を紐解き、マネジメント層や上層部にしっかり伝わる「正しい報告の技術」を解説します。
株式会社office Root（オフィスルート）
代表取締役社長
甲州 潤（こうしゅうじゅん）
国立高専卒業後、ソフトウェア開発企業でSEとして一連の開発業務を経験し、フリーランスに転身。国内大手SI企業の大規模プロジェクトに多数参画し、優秀な人材がいても開発が失敗することに疑問を抱く。PMOとして活動を開始し、多数プロジェクトを成功へ導く。企業との協業も増加し、2020年に法人化。さまざまな企業課題と向き合う日々。著書『DX時代の最強PMOになる方法』（ビジネス教育出版社）
目次
報告の場面は、大きく分けると以下の二つです。
１．依頼された仕事に対する「タスクの進捗報告」
２．トラブルや問題が発生した際の「問題の状況と対策の報告」
多くのエンジニアが「自分は正しく報告できている」と思い込んでいますが、実はどちらの場面でも“不十分な報告”が日常茶飯事になっているといっても過言ではありません。
典型的なダメなやり取りの例を見てみましょう。
今日の作業ですが、A機能の設計書作成を進めていて、進捗率は80%です
……で、それって当初の計画通り進んでるの？ 今週中に終わるの？
あ、少し遅れていて、来週の火曜になりそうです
遅れてるなら先に言ってよ。なんで遅れてるの？ 誰かフォロー入れた方がいいの？
Bシステムでデータ連携のエラーが発生したので、現在ログを調査中です
ちょっと待って。いつ発生したの？ 原因の調査は終わってるの？ お客さまへの影響は？
えっと、発生は今朝で、これから詳細を調べるのでまだ分かりません……
分からないなら分からないで、どこまで判明していて何が不明なのか整理して報告してよ。それに加えて、今後どのように進めようとしているのかも合わせて教えてもらわないと判断できないよ
これらの会話を聞いて、どう感じるでしょうか。「上司が細かく聞いてくれて親切だ」「質問にちゃんと答えているから会話が成立している」と思ったとしたら、それは大きな間違いです。
相手から「それって予定通り？」「原因は何？」「いつ終わるの？」と追加の質問をされている時点で、あなたの最初の報告は「失敗」なのです。相手が知らない情報を質問させてキャッチボールをしている状態は、報告内容としては不十分です。
なぜ、このような認識のズレが生まれてしまうのでしょうか。
それは、エンジニアとマネジャー（お客さまPMやリーダー）とでは、報告を聞く「視点」が根本的に異なっているからです。
作業者であるエンジニアは、無意識に「自分が今日やったこと」「今取り組んでいる作業の内容」という自分を主軸とした事実を話そうとします。
しかし、マネジメント層が知りたいのは、あなたの作業内容そのものではありません。彼らは報告を通じて、「このままの進め方で問題ないか」「軌道修正やリソースの追加が必要か」というマネジメント上の“判断”をしたいのです。
タスク報告で聞きたいこと
「順調か遅れているか」
「遅れているならどのような対策を打つのか（自分一人で解決できるか、人の手配が必要か）」
「進んでいるのであれば、なぜ計画とずれが発生したのか？計画を見直せないか？」
問題報告で聞きたいこと
「現在どのような状態か」
「問題の経緯と原因は何か」
「選択肢としてどんな対策案があり、なぜその案を選んだのか」
「その判断で進めて問題ないか」
「頑張って調査しています」「残業して終わらせます」といった精神論は、マネジャーにとっては何の判断材料にもなりません。時間的に不可能なものを「頑張ります」と言われても、マネジメント側としては「根拠がないのに任せられない」と不安になるだけです。
相手が欲しいのは、あなたの気合ではなく、正しく判断を下すための「構造化された情報」なのです。
（もちろん、やる気を見せることは重要なので、やらなくてよいという意味ではなく、報告の途中に挟む必要は無いという意味です。このような姿勢を見せるときは、最初か最後のどちらかで大丈夫ですよ！）
進捗報告では、「作業内容」ではなく「計画に対して順調か否か」を最初に提示します。
【進捗報告のテンプレート】
結論（状況）： A機能の設計書作成ですが、計画に対して 2日遅延 しています。
原因： 前提となる共通APIの仕様変更への対応に時間がかかったためです。
対策と完了見込み： 明日までにBさんのレビューフォローを1時間いただければ、今週末までに挽回可能です。
相談： 本日16時からBさんの時間を30分ほどいただいてもよろしいでしょうか？
この報告であれば、マネジャーは「遅れている事実」「原因」「自力でのリカバリ案」「自分に求めているアクション（Bさんの時間確保の承認）」が一瞬で理解できます。
上記のテンプレート通りに報告することはわかりやすいですが、意識するのは、過去、現在、未来という時間軸を意識しましょう。
過去：当初計画はどんなだったか？実際に自分で作業してどのような状態か？
現在：今の状況、この状況になった原因 （順調に進んだ場合も順調に進んだ理由があるはずです）
未来：予定通りに進められるか？（２週間後に＊＊＊があるから当初計画を変更しないといけないなど）、対策を打たなければいけない場合どのようにしたらよいか？
このように時間軸を意識して内容を整理するとタスク進捗報告に関して理解してもらいやすくなります。
問題が発生した際、「原因が分かるまで報告しない」のは最悪です。第一報の段階で確定していない情報は、「不確定であること」も含めて型に当てはめて報告します。
【問題報告のテンプレート】
発生事象と経緯： （第一報：yyyy/mm/dd 9:10 時点）
yyyy/mm/dd
9:05 Bシステムでデータ連携エラーが発生しました。今朝9時の定期実行で検知しました。
9:06 調査開始：原因・お客さま影響調査実施
影響範囲：（第一報：yyyy/mm/dd hh:mm 時点）お客さまへの影響はゼロ
対象環境・システム：Bシステム
再現手順：＊＊＊＊状態で、Bシステムのデータ連携が定期実行（朝9時）される
直接原因：エラーログより、データフォーマットの不整合が原因と推測されます。
特定のデータのみで起きているのかは現在調査中です。
14時までに原因を特定します。
暫定対応：復旧を優先するため、連携が成功したデータはスキップして再実行する準備を進めています。この方針で進めてよろしいでしょうか？
根本原因：（調査中）
恒久対応：（検討中）
分からないなら「14時まで分からない」と時間を区切って報告する。断定できないなら「〜と推測される」と自分の考えを述べる。これだけで、マネジャーは「このエンジニアは状況をコントロールできている」と安心し、的確な指示を出すことができます。
上記の問題報告のテンプレートはシステム障害が発生したときに使われる報告項目をベースに作成していますが、システム障害だけでなく、ビジネス上の問題全般に活用できると思います。
ほとんどの問題は、今すぐ解決しなければならない内容と同じ問題を起こさないためにどのように対策したら良いかの2つを考えなくてはなりません。まずは直接原因と暫定対応で今すぐ解決しなければならない問題を解決し、少し時間をかけて根本原因と恒久対応を整理して対策を打っていく必要があります。
日々の業務の中で小さな問題が起きたときから上記のような報告をすることを意識してみましょう。小さな問題だからといって、上記のような報告内容は必要ないだろう……と考えて、大きな問題が起きたときにやればいいやと思っているあなた！ そう思っているあなたは、大きな問題が起きたときは多分書けないと思います。
小さな問題で書き方のコツやどうやったら相手に伝わるのかを繰り返している人こそ、実際に大きな問題に直面したときも対応できるのです。
ここまで解説してきた報告の型を実践できるということは、あなたが作業者の視点を抜け出し、「マネジメント層の視点に立って仕事ができている」という何よりの証明です。
エンジニアとしてどれほど素晴らしい技術力を持っていても、報告の仕方が下手な人は損をします。
例えば、システム上の致命的なバグを自力で事前に見つけ、素早く修正してトラブルを防いだエンジニアがいたとします。
彼が「不具合を見つけたのでプログラムを直しておきました。以上です」とだけ報告したらどうでしょうか。
お客さまは「え、勝手に直したの？ そもそもなんでそんな不具合があったの？ 他の箇所は大丈夫？」と、不安になります。
一方で、同じ技術成果を出したとしても、
「どういう経緯で事前に検知できたのか」
「データや顧客への影響がないことをどう検証したのか」
「今後同じ不具合を出さないための再発防止策として何をすべきか」
ここまでを型に沿ってセットで報告できれば、お客さまは「そこまで見越して対応してくれたのか。素晴らしい技術力と危機管理能力だ」と絶賛するはずです。せっかくの高度な技術も、報告というインターフェースが優れていて初めて「正当な評価」へと変換されるのです。
今回紹介した報告の型は、知っていれば誰でも今日から実践できる「ただの技術」です。
そして、知っている人にとっては当たり前のことです。しかし、プロジェクトになると、何十人というメンバー全員ができているか？となると話は別になってきます。
あなたができていても、他のメンバーができていないとプロジェクトでの情報伝達に遅れやズレが発生します。
もし、あなたが現場のメンバーを率いるリーダーやPMで、「部下の報告がいつも要領を得なくて困っている」「毎回質問攻めにしないと状況が掴めない」と悩んでいるなら、ぜひこの記事をそのままチームのメンバーに共有してみてください。
「毎回いちいち口で指導する」のは、双方にとってコストがかかります。「まずはこの記事の型通りに報告してみて」とプチ教科書として渡してしまう方が、はるかに素早くチーム全体の報告レベルを引き上げることができると思います。
この記事を共有しても改善が見られない場合は、リーダー自身が具体的に報告の型を見せる必要があります。何回か具体例を見せればメンバーもそれに従って報告ができるようになるはずです。
エンジニア個人は、報告の型を身につけて自分の価値を高める。
リーダー層は、その型をチームの共通言語にして管理コストを下げる。
お互いに「何を聞きたいのか」「何を答えるべきか」の解像度を合わせることが、客先常駐の現場で無用なストレスを無くし、全員が気持ちよく成果を出すための最短ルートなのです。
『DX時代の最強PMOになる方法』
著：甲州潤
▼こんなエンジニアはぜひお読みください。
・今の仕事に不満を持っていて、現状を変えたいと思っている
・給料をアップしたい
・エンジニアとしての将来が不安だ
・キャリアアップをしたいが、何をしたらいいかわからない
・PMOに興味がある
・PMOとして仕事をしたい
【目次】
第1章 一番稼げるIT人材は誰か
第2章 これからはPMOが1プロジェクトに1人必要
第3章 SEとPMOの仕事は何が違うか
第4章 稼ぐPMOになる７つのステップ
第5章 優秀なPMOとダメなPMOの見抜き方
第6章 PMOが最低限押さえておきたいシステム知識とスキル
第7章 システムは言われた通りに作ってはいけない
第8章 どんな時代でも生き残れる実力をつけよう
>>>詳細はこちら
タグ
