「で、いつ出来るの？」
開発チームの進捗報告会。PMとして丁寧に準備した資料を説明し終えた直後、役員からこの一言が飛んでくる。
「スプリントの消化率は85%で、残バックログは12ポイントです」——自分としては十分に説明したつもりでした。でも、経営層の表情は明らかに曇っている。
この「噛み合わなさ」、開発PMを経験した方なら一度は感じたことがあるのではないでしょうか。
私はPMとして5年間、この問題と向き合ってきました。そして気づいたのは、これは報告の仕方の問題ではなく、言語の違いの問題だということです。
経営層とエンジニアは「違う言語」を話している
経営層が知りたい3つのこと
経営の立場から開発チームに求めている情報は、突き詰めるとこの3つです。
- いつ出来るのか（納期リスク）
- いくらかかるのか（コスト）
- 投資に見合うのか（ROI・利益）
これらはすべて「お金」と「時間」という経営言語で語られるべき情報です。
エンジニアが報告する3つのこと
一方、開発チームが進捗報告で伝えがちなのはこの3つ。
- タスクの消化率（全30タスク中25個完了）
- 技術的な課題（APIの設計変更が必要、パフォーマンス改善中）
- 機能の完成度（ログイン機能は完了、決済機能は実装中）
これらは「技術言語」で語られる情報です。
断絶が生まれる瞬間
この2つの言語は、一見するとつながっているように見えます。しかし、実は大きな断絶があります。
「タスク消化率85%」は、「全体の85%が完了した」を意味しない。
残り15%のタスクに、全体の40%の工数がかかるかもしれない。あるいは逆に、消化率は60%でも工数ベースでは順調かもしれない。タスクの数と工数は比例しないからです。
「技術的な課題がある」は、「遅れる」を意味するかもしれないし、しないかもしれない。
エンジニアにとっては重要な情報でも、経営層にとっては「で、それは何日遅れるの？」「追加コストはいくら？」が知りたい。
この翻訳がなされないまま報告が繰り返されると、経営層には「何を言っているかわからない」「本当のことを言っていないのでは」という不信感が蓄積します。
不信感が生む「過干渉」の悪循環
経営層が開発チームに不信感を持つと、こんな悪循環が始まります。
ステップ1: 報告頻度の増加 →「週次ではなく日次で報告してほしい」
ステップ2: 報告フォーマットの追加 →「この項目も追加して」「経営会議用の別資料も作って」
ステップ3: 直接介入 →「このタスクの優先度を上げてほしい」「この機能は本当に必要なの？」
ステップ4: 開発チームの疲弊 →報告作業に時間を取られ、開発速度が落ち、さらに進捗が遅れる
ステップ5: 不信感の増大 →「やっぱり遅れてるじゃないか」→ ステップ1に戻る
この悪循環の根本原因は「経営層が開発の状態を正しく把握できていないこと」。そして、それは進捗の「翻訳」ができていないことに起因しています。
経営言語への翻訳 ― 3つのアプローチ
では、どうすれば開発の進捗を経営層に正しく伝えられるのか。私が実践して効果があった3つのアプローチを紹介します。
アプローチ1: 「タスク数」ではなく「工数（時間）」で語る
タスクの消化率ではなく、工数ベースの進捗を示す。
Before: 「全30タスク中25個完了。進捗率83%」
After: 「計画工数800時間に対し、消化工数620時間。進捗率77.5%。残180時間分のタスクがあり、現在のペースだと計画通り完了見込み」
工数ベースで語ると、「あとどれくらいかかるか」が経営層にも直感的にわかります。「あと180時間分」と言えば、「3人で週40時間稼働なら約1.5週間」と計算できる。
アプローチ2: 「予算消化率」で語る
開発の進捗を「予算」に紐づけると、経営層の関心事にダイレクトに響きます。
報告例:
- 総予算: 1,200万円
- 消化済み: 780万円（65%）
- 残予算: 420万円
- 目標利益率: 20%
- 現時点での見込み利益率: 18%（やや下振れ）
「利益率が目標を下回りそうです」と言えば、経営層は即座にリスクの大きさを理解できます。「ストーリーポイントが…」では伝わらない危機感が、「利益率が2ポイント下振れ」なら伝わる。
アプローチ3: 「予定と実績の差分」で語る
計画と実績の乖離をビジュアルに示す。バーンダウンチャートはエンジニア向けの表現ですが、「予算消化のバーンダウン」なら経営層にも伝わります。
ポイントは、「順調です」「遅れています」の二択ではなく、データで状態を示すこと。
- 理想のペース vs 実際のペースの差分
- 差分がいつ頃から開き始めたか
- このまま推移した場合の着地見込み
データがあれば、「対策が必要か否か」「どの程度の対策が必要か」を経営層も自分で判断できます。これが信頼関係の基盤になります。
「翻訳」を仕組みにする
ここまで読んで、「言いたいことはわかるけど、毎回その翻訳作業をPMがやるのは大変じゃないか」と思った方もいるでしょう。
まったくその通りです。
実は翻訳の問題は、「誰がやるか」より**「自動化できるか」**がポイントです。
私がたどり着いた答えは、実績データの記録→集計→可視化を自動で行う仕組みを作ることでした。
メンバーが日常業務の中で自然に実績を記録し、そのデータが自動的に集計されて、以下のような「経営言語の報告」が勝手に出来上がる。
- 工数ベースの進捗率
- 予算消化率と残予算
- 利益率の見込み
- 計画と実績の差分グラフ
こうなれば、PMは毎週「データを集めて、計算して、資料を作る」必要がなくなります。代わりに、データを見て「何をすべきか」を考える時間に充てられる。
「見える化」が信頼を生む
プロジェクトの状態が常にデータで可視化されていると、経営層とのコミュニケーションが劇的に変わります。
変化1: 報告会議が短くなる
データが常に最新の状態で見られるなら、「状況報告」の時間は最小限で済みます。会議の時間を「判断と意思決定」に使えるようになります。
変化2: 早期のアラートが可能になる
月末に「実は赤字でした」ではなく、月中に「このままだと利益率が目標を下回りそうです」と伝えられる。早期の警告は、経営層にとって最もありがたい情報です。
変化3: 過干渉が減る
状態が透明であれば、経営層は安心します。「見えない」から不安になり、干渉したくなるのです。常にデータが見える状態は、開発チームの自律性を守ることにもつながります。
仕組み化のヒント
最後に、こうした「翻訳の仕組み化」を進める上でのヒントを共有します。
ヒント1: 入力負荷を限りなくゼロに近づける
どんな仕組みも、データが入力されなければ機能しません。メンバーに「これ以上入力作業を増やさないでくれ」と言われた経験は何度もあります。
解決策は、日常のワークフローに溶け込む形で実績を記録すること。
- カレンダーでスケジュールを管理する延長で、実績工数を記録する
- 日報を書く延長で、その日の工数が記録される
- 予定をワンクリックで実績にコピーできる
入力が「負担」ではなく「自然な行為」になれば、データは自動的に溜まります。
ヒント2: 経営指標と開発指標をつなぐ「変換レイヤー」を持つ
開発チーム内ではタスク単位・工数単位で管理しつつ、対外的には予算・利益率・納期で語れるようにする。この変換が自動で行われることが重要です。
ヒント3: 小さく始める
いきなり完璧な仕組みを作ろうとしないこと。まずは1つのプロジェクトで「工数の予実を記録して、予算消化率を自動算出する」ところから始めるのがお勧めです。
ちなみに私は現在、こうした「管理と分析の連動」を実現するためにdevDashというツールを使っています。タスク管理で入力された実績データが自動的に集計・分析され、予算消化率や工数の予実比較が手間なく見られるようになっています。β版を無料で提供中なので、気になった方はぜひ試してみてください。
まとめ
開発の進捗が経営層に伝わらないのは、報告の仕方が下手だからではありません。使っている言語が違うからです。
- 経営層は「お金」と「時間」で判断する
- 開発チームは「タスク」と「技術」で報告する
- この翻訳がなされないと、不信感と過干渉の悪循環が生まれる
解決策は、工数・予算・利益率という経営言語で開発進捗を語れる仕組みを作ること。そしてその翻訳を自動化することで、PMの負荷を減らしながら、経営層との信頼関係を築いていけます。
開発チームと経営層の間に立つPMの役割は、技術の専門家でも経営の専門家でもなく、両者をつなぐ翻訳者。その翻訳を仕組みで支えることが、健全な開発組織を作る第一歩だと考えています。