roadmap-planning

ロードマップ計画

始める前に

まず、EM に関するコンテキストを確認してください。.agents/em-context.md が存在する場合は、内容を読んでください。

.agents/em-context.md が存在しない場合は、詳細なアドバイスを提供する前に、まず最低限のマネージャーのプロフィールを尋ねて保存してください。役職・職位、チームの規模、チームのミッションまたは担当領域、現在の課題または優先事項を確認します。

特定の人物が会話の中心であり、.agents/reports/[name].md が存在しない場合は、詳細なアドバイスを提供する前に、まずその人物について最低限のプロフィールを尋ねて保存してください。役職・レベル、在籍期間、強み、現在の課題または成長領域を確認します。

会話の中で、後から長期的に有用な新しいコンテキストが明らかになった場合は、.agents/em-context.md または .agents/reports/[name].md を自動的に更新してください。安定した事実やパターンを保存し、推測、一時的な不満、未解決の解釈は保存しないでください。

回答スタイル

最初の回答は簡潔で役立つものにしてください。ユーザーが詳しい説明を求めない限り、フレームワーク全体を一度に提示しないでください。

基本方針：

• 可能性の高い診断または推奨を最初に述べる
• 不足しているコンテキストによってアドバイスが変わる場合に限り、的を絞った質問を最大2～3個する
• 次に取るべき具体的な行動を示し、役立つ場合はマネージャーが使える正確な文面も提示する
• 関連するフレームワークには簡潔に触れるが、各要素をすべて説明しない
• 直接的な回答の後で、さらに詳しい説明を提案する

---

このスキルの使い方

• ステークホルダーと技術的負債に充てる時間を交渉する → 技術的負債と「20％ルール」
• 機能を複数のフェーズに分けているが、その判断が適切か検証したい → 段階的リリース
• 新しいものを作る継続的なコストを示す必要がある → 第三の軸としての保守コスト
• チームがスプリントの目標を達成できず、「遅い」と見られている → 常にグリーンでいる方法
• スプリントの儀式が価値よりも摩擦を生んでいる → スプリントのアンチパターン
• PM が単発のカスタム機能を追加し続けている → カスタム機能にかかる隠れたコスト
• 厳しい期限に間に合わないおそれがある。どうすればよいか → チームが重要な期限に間に合わないとき
• プロジェクトの見積もりが何度も外れる → プロジェクトの鉄則
• 技術的な作業が何度も後回しにされる → 技術プロジェクトなど存在しない
• チームはリリースしているのに、何の効果も出ていないように見える → 機能ファクトリーの警告サイン
• 全社的なクリーンアップイベントを実施する → references/extended.md を読む — クリーンアソン

---

回答の基本構成

ロードマップ計画を支援する際は、トレードオフを明確にしてください。

1. 計画上の問題： 技術的負債、フェーズ、期限、キャパシティ、保守、機能ファクトリー、またはステークホルダーとの調整。
2. 意思決定の枠組み： 実際に選択肢となるもの。
3. ビジネス上の説明： エンジニアリング作業が、プロダクトや会社にとってなぜ重要なのか。
4. 推奨事項： 今すべきことと、先送りすること。
5. ステークホルダーへのメッセージ： PM、リーダーシップ、またはチーム向けの簡潔な文面。

「技術的な作業がいつも後回しになる」ことが問題なら、作業の必要性を主張する前に、リスク、コスト、速度、信頼性、または顧客への影響に置き換えて説明してください。

---

技術的負債と「20％ルール」

純粋なエンジニアリング作業にキャパシティの20％を充てることは、広く推奨されている実践であり、実際に役立ちます。ただし、多くのチームは実践方法を誤り、予測可能な落とし穴にはまっています。

5 つの落とし穴

1. プロダクトと技術のバックログを分ける

プロダクトの作業と技術の作業を別々のバックログで管理すると、プロダクトチームは技術的な意思決定への介入をやめ、エンジニアリングチームはプロダクトの優先事項に関与しなくなります。平和に聞こえますが、実際にはじわじわと失敗に向かっています。

プロダクトと技術は別々のものではありません。バグ修正、ライブラリの更新、自動化の改善、セキュリティパッチなど、これらのほぼすべてにビジネス上の価値（信頼性、セキュリティ、デリバリーの速度）があります。

解決策：技術項目の一覧にあるすべての項目について、ビジネス上の価値を明確に定義します。定義できたら、プロダクトバックログに移動します。そこで、ほかのすべての項目と並べて優先順位を付けます。個別の技術トラックは、技術に詳しくないステークホルダーに説明するのが難しい重要な作業に限って設けます。

2. 会社があなたの仕事の価値を理解していない

ビジネス側があなたの技術的な取り組みに関心を持たない、またはその価値を理解していない場合、「緊急」の案件が発生するたびに、それらの取り組みは真っ先に優先順位を下げられます。また、採用、トレーニング、追加の時間を交渉するのも、はるかに難しくなります。

解決策：技術的な作業を可視化します。エンジニアリングチームが、特定のプロダクトチームに結び付いていない技術的な取り組みの進捗を発表する月次レビューを実施します。単に「Swift に移行しました」と言うのではなく、「コンパイル時間を短縮し、開発者体験を向上させ、Objective-C に関わりたいエンジニアが減っているため採用にも役立ちます」というように、ビジネス上の観点から作業の重要性を示します。

3. 集中が分散する

20％の時間を確保しても、すべてが解決するわけではありません。チームの一人ひとりに別々の技術的な取り組みを割り当て、それぞれが異なる方向に進んでしまうと、どこでも実質的な進捗を上げられません。

解決策：20％の時間は、長期的なエンジニアリング戦略に貢献する、一貫性のある取り組みのセットに集中させます。目標を把握し、どの取り組みが目標に貢献するのかを見極め、あらゆる技術的な気がかりに同時に対処したいという誘惑に抗います。

4. 「後で修正します」

チームに20％の保護された時間が設けられると、作業を早く進め、技術的負債は後から解消すればよいと考えたくなります。しかし、そうなることはほとんどありません。次のスプリントには、いつもより緊急度の高い作業があります。

20％の時間は、物事をより良くするためのものであり、単に悪い状態を少しマシにするためのものではありません。MVP を構築するときでも、機能的で使いやすく、信頼できるものでなければなりません。「顧客にリリースしてから」テストを書くというのはよくあることですが、本番環境の問題を修正するか、次の取り組みに着手することになるため、こうした作業はほとんど完了しません。

5. 大規模な取り組みで効果が出ない

20％の時間は、週に1日、1日に1.5時間、または月に約4～5日です。モノリスの分割やプラットフォームの再構築といった、本当に大規模な取り組みの場合、2～3か月分の進捗を上げるために、1年間コンテキストを切り替え続けることになります。これではうまくいきません。

解決策：大規模な戦略的取り組みを20％の時間に含めるべきではありません。ビジネス上の根拠と組織全体の支援を得て、進捗を追跡するプロダクトの優先事項にする必要があります。20％の時間は、本当の意味での保守作業や小規模な戦術的改善に充てます。

---

段階的なリリース：効果がある場合とない場合

機能を段階的にリリースするのは、慎重でリスクを抑えた方法に思えます。しかし、多くの場合、学びを先延ばしにし、足かせを生むだけです。

段階的なロードマップを厳しく検証するための5つの質問：

1. 段階を分けているのは、ユーザーから要望があったからですか。それともチームがもっと作りたいからですか。 フェーズ2は、ユーザーのニーズではなく、願望リストになっていることがよくあります。
2. フェーズ2がなくても、フェーズ1は実際に使われますか。 フェーズ1だけでは価値がないなら、単なる仮のものをリリースしているにすぎません。ユーザーは、内部のフェーズ分けなど気にしません。
3. フェーズ1では、フェーズ2に反映すべきどんなことを学べますか。 答えられないなら、フェーズ2はすでに完全に設計済みです。つまり、フェーズ1を学びの節目として実際には活用していません。
4. フェーズ1の後で止める場合、どんなコストが発生しますか。 フェーズを設けると、社内に期待が生まれます。フェーズ1をリリースすると、フェーズ2は選択肢ではなく、約束のように感じられるようになります。
5. 価値をすべて届けられる、もっとシンプルなバージョンはありませんか。 「フェーズ1＋フェーズ2」の最良の形は、スコープをより適切に定めたフェーズ1だけであることがよくあります。

Hondaの話。 Hondaが米国のオートバイ市場に参入したとき、主力として大型バイク、つまり本格的なオートバイを投入する計画でした。しかし、それらは故障しました。代わりに、従業員自身が乗り回していた小型で安価なオートバイが注目を集めました。Hondaはすぐに方針を転換し、当初は想定していなかった市場を築きました。

教訓は、最初に立てた計画は仮説だということです。優れたプロダクトチームは、状況がそう示しているなら、開発途中でも機能を止めることをいといません。停止を失敗ではなく、優れたプロダクト文化の表れとして捉えます。

チームにこう伝えましょう。 機能が中止されると、エンジニアは意欲を失いがちです。あなたの役目は、これを別の形で捉え直すことです。「リリースし、学び、実際のデータに基づいて方向転換しました。これが本来の進め方です。」明らかにうまくいっていないものを作り続けることこそ、本当の失敗です。

---

第三の軸としてのメンテナンスコスト

ロードマップについての議論では、通常、「何を」作るかと「どれくらい時間がかかるか」という2つの軸にとらわれがちです。その結果、引き受けるすべてのものに継続的にかかるコストが見落とされます。

リリースする機能はすべて、恒久的な負担になります。技術的負債がゼロでも、保守し、サポートし、高速で安全な状態を維持するには、チームの継続的な稼働能力が必要です。関連性のないシステムが増えるほど、これは難しくなります。

メンテナンスコストを議論に加える方法：

1. 担当する各システムに現在継続的にかかっているコストを洗い出します（バグ修正、障害、緊急の顧客要望、セキュリティパッチ）
2. チームの稼働能力に対する割合として見積もります（例：「システムごとに、私たちの時間の約10％」）
3. 提案された新しい作業を引き受けた場合に、継続的なコストがどれほど増加するかを示します
4. その情報が見える状態で、相手に判断してもらいます

数値が正確である必要はありません。そこが目的ではないからです。目的は、議論の中でメンテナンスコストという軸を見えるようにすることです。正確さを追求するのではなく、考慮されることを変えるためです。

こうしたことを記録し、実際の事例を持ち込むようになると、妨害と受け取られることなく、スコープの拡大に異議を唱えやすくなります。

---

常に達成する方法

デリバリーの速さは、95％が認識によって決まります。小さな目標を一貫して期限どおりに達成するチームは、仕事が速いと認識されます。野心的な目標を掲げて達成できないチームは、より多くを出荷していたとしても、遅く見えます。

核心となる気づきは、適切な目標を選べば、いつでも期限どおりにデリバリーできるということです。

ヒルの概念（Shape Up より）

プロジェクトには、ヒルを登る段階（未知のことを発見し、実際に何を作るのかを見極める段階）と、下る段階（明確になったことを実行する段階）の2つがあります。計画だけでプロジェクトに必要なことを完全に理解することはできません。全体を見渡せるところまで登る必要があります。

目標にコミットする前に、1スプリント早く作業を始めます。数日間、実際に取り組み、難しい点、依存関係、未知のことを明らかにします。ヒルの頂上に到達したら、高い確信を持ってコミットできます。スコープに関する想定外の事態はめったに起きなくなります。

必ず完了できるスプリント目標の設定方法：

1. 最小限の目標を選びます。 ユーザーにとって明確な成果を1つだけ設定します。凝ったものは必要ありません。チームのキャパシティの半分以下に収まるようにし、水曜日までに完了できると確信できるものにします。
2. 並行して進められる作業に分解します。 互いにブロックし合うことなく、それぞれが取り組める作業にします。他のチームへの依存関係は設けません。
3. 全員に公表します。 共有チャンネルに「他のことがすべてうまくいかなくても、これだけはデリバリーします」と投稿します。全責任を引き受けます。
4. 毎日状況を確認します。 状況を把握し、すぐにブロック要因を取り除きます。必要なら「目標外」のタスクから人員を回します。
5. 完了させます。 目標が3つなら、チェックマークも3つ必要です。3つ中2つの達成は成功ではありません。それでは、チームは完了させないものだという期待を改めて定着させるだけです。

スプリントの残りの作業も止まりません。バグ対応、技術的負債、計画、他チームのサポートなどがあります。最小限の目標は、あくまで譲れない最低ラインです。

野心的な目標について： 100％の達成率を一貫して維持するチームは、野心的な目標を追いかけて達成できないチームよりも、長期的には多くのことを成し遂げます。常に成功するチームはより効果的で、より信頼され、追加の成果を上乗せしようとする意欲も高まります。野心的な目標を掲げて失敗し続けるという選択肢は、全員を疲弊させるだけです。

---

スプリントのアンチパターン

スプリントを厳格に実施すると、それ自体が問題を生むことがあります。スプリントのプロセスがチームの妨げになっている兆候：

• 実際の作業には2日では足りないため、スプリントの終了間際に小さなバグを選ぶ
• もはや意味のないスプリント目標を達成しようとする
• 「X を進める」がスプリント目標として数えられる
• 機能のリリースが一貫して遅れているのに、ベロシティを成功指標として追跡する
• 技術的負債が6か月連続で「次のスプリント」に先送りされる

プロセスを変えられないときにすべきこと：

• 常に余裕を残します。「スプリントに入れておこう。最悪の場合は先送りすればいい」という意見には、「入れないでおこう。時間があれば追加するのが最善のケースだから」と対抗します。
• 意味のないスプリント目標を無理に設定しません。偽りの目標を立てるより、目標がないほうがよいです。
• 誰かがタスクを終えたら、本人が望む作業に取り組んでもらいます。
• 少なくとも年に1回、「品質向上スプリント」――問題を修正するための2～3週間の期間――を設けるよう働きかけます。
• チームの役に立たない慣行には疑問を投げかけます。デイリースタンドアップに価値がないなら、任意参加にします。

---

カスタム機能にかかる隠れたコスト

PM や顧客から一度限りの「特別な」機能を求められたとき、目に見えるコストは開発時間です。見積もりにほとんど含まれないコストが3つあります。

1. 将来のメンテナンスコスト — すべてのカスタム機能は、修正し、プロダクトの変更に合わせて調整し、動作し続けるように保守する必要があります。このコストは際限なく積み重なります。
2. 複雑性コスト — 新機能が増えるたびにプロダクト全体が複雑になり、その後の機能すべてのコストが増加します。
3. 機会費用 — その開発者の1か月分の時間を、より大きな効果をもたらす作業に充てることもできました。

実践的な対応：

• 「顧客向けの特別機能」には標準機能より大幅に高い料金を設定し、実際のコストを明らかにする
• チームのキャパシティのうち、特別機能に割かれている割合を記録する。PM や経営陣と上限について合意する
• 機能の実際の利用状況を測定する。誰も使わない機能は、見返りのないメンテナンスコストです

---

チームが重要な期限に間に合わないとき

厳しい期限に間に合わないおそれがあるとき、多くのマネージャーがまず選ぶ対策は、最も効果の薄いものです。

ほとんど効果がないこと：

• 人員を増やす — 遅れているプロジェクトに開発者を加えると、コミュニケーションの負担が増えて、最初のうちは進みが遅くなります（ブルックスの法則）。例外が1つあります。既存の開発者に付いてペアで作業するシニア開発者を、十分早い段階で加えれば効果がある場合があります。
• 品質を下げる — 「テストは後で書く」は、節約できる時間を上回るコストが必ずかかります。リリース後の緊急対応を招くか、返済不可能な品質上の負債が増えていく結果になります。

効果がある場合もあること：

• 作業時間を増やす — 本当の危機では正当な対応ですが、前例を作ってしまいます。必要最小限にとどめてください。

最も効果があること：

• スコープを縮小する — 中核的な価値を提供しながら削れる部分を特定します。「問題を解決できる範囲で、リリースできる最小限のものは何か？」は、期限が迫ってからではなく、その前に問うべき最も重要な質問です。

---

プロジェクトの鉄則

How Big Things Get Done（Flyvbjerg）によると、調査対象となった何千もの大規模プロジェクトのうち、予定どおりに予算内で完了したのはわずか8.5％でした。これはプロジェクト管理の失敗ではなく、人間の計画の立て方に構造的に備わっている性質です。

見積もりがほとんどの場合に誤る理由：

• 計画担当者は最良のシナリオや独自性（「このプロジェクトは特別だ」）を基準に考えます
• 予測できない未知の要素は、どの見積もりにも現れません
• 複雑性は非線形に増加しますが、見積もりは線形に増加します
• 楽観バイアスにより、チームは期間とコストを一貫して過小評価します

参照クラス予測 — 解決策：

ゼロから見積もる（「これはどれくらいかかるか？」）のではなく、こう尋ねます。「類似プロジェクトでは何が起きたか？」

スコープ、チーム、領域が似ている、完了済みの比較可能なプロジェクトを集めます。実際にかかった期間とコストを確認します。それを見積もりの基準とし、個別の違いを考慮して調整します。

これは当たり前のように聞こえます。しかし、実際に行う人はほとんどいません。あらゆるプロジェクトを独自のものとして扱い、ボトムアップで見積もるのが自然な反応です。データが示すのは、外側から見る視点（比較可能なプロジェクト）のほうが、内側から見る視点（詳細なボトムアップ見積もり）よりも、ほとんどの場合に正確だということです。

じっくり考え、素早く行動する：

プロジェクトの遂行で最もコストがかかるのは、実行の途中で方針を変えることです。Flyvbjerg の原則は、コミットする前の計画に十分な投資をし、いったんコミットしたら素早く実行することです。

プロジェクトを失敗に導くパターンは、設計が固まる前に急いで始め、途中で根本的な問題に直面し、コストをかけて方針転換するか、うまく機能しないものをリリースすることです。

実践では、大規模な取り組みを承認する前に、設計が本当に固まっているかを確認してください。「進めながら考えます」は設計ではありません。丘のコンセプト（「常にグリーンな手法」を参照）も同じ考え方の小規模版です。コミットする前に、全体のスコープが見えるところまで登ってください。

---

技術プロジェクトなど存在しません

考え方を改める価値のある大胆な主張があります。すべてのプロジェクトはビジネスプロジェクトです。 ビジネス上の観点で正当化できないことをエンジニアリングチームが行っているなら、それは間違っています。

これは技術的な作業を放棄するという意味ではありません。リファクタリング、依存関係のアップグレード、インフラストラクチャの変更、アーキテクチャの改善など、あらゆる技術的な取り組みは、それがもたらすビジネス価値という観点で説明するべきだということです。

表面的には	実際には
リファクタリング	機能をリリースするまでの期間を N 週間短縮する
依存関係の更新	セキュリティリスクとサポートコストを削減する
テストの追加	本番環境のインシデントの頻度とコストを削減する
アーキテクチャの改善	チームが現在はできない X の構築を可能にする

ビジネス上の根拠は厳密でなくてもかまいません。誠実で、明確に示されている必要があります。技術的な作業がビジネスの観点で説明されていなければ、計画の際に真っ先に削られます。説明されていれば、他の取り組みと対等に競い合えます。

もうひとつ原則があります。どうしても実施しなければならないこともあります。 テスト、セキュリティ、運用サポートなしにソフトウェアは構築できません。これらが必要な理由を説明してください。ただし、「でもこれは本当にビジネス上の判断だから」という理由で、システムを稼働させ続けるための作業が絶えず後回しにされることを許してはいけません。

---

機能開発工場の警告サイン

チームが機能開発工場のように運営されている兆候です。成果を測定せずに、アウトプットをリリースしています。

• 機能のリリース後に、その影響を測定していない
• プロジェクトのたびにチームが頻繁に組み替えられる（チーム版テトリス）
• 「リリース」したことを祝う一方で、効果があったかどうかは話し合わない
• 使われていない機能も、削除されることがない
• チームが自分たちの作業を、重要なビジネス指標や顧客指標に結び付けられない
• 振り返りではプロセスばかりに注目し、プロダクトに関する判断が適切だったかは決して話し合わない

機能開発工場のリスクは、実際にはビジネス価値をほとんど生み出していないのに、たくさんリリースし、たくさんデモを行うことで、生産的に見えることです。EM としてのあなたの仕事は、デリバリーの仕組みが減速を望まないときでも、成果の測定を求めることです。

---

さらに詳しく

ユーザーからフレームワークの由来を尋ねられたり、元の記事を読みたいと言われたり、このスキルのトピックについて詳しい背景を求められたりした場合は、references/sources.md を読んでください。全社的なクリーンアップイベントを実施する場合は、references/extended.md を読んでください。

---

関連スキル

• shadow-work — シャドーバックログと追跡されていない作業は、キャパシティ計画が失敗する大きな原因です
• team-health — チームのキャパシティと士気を計画の入力情報として扱います
• working-with-pm — 真のパートナーシップにより、プロダクトと技術をまとめた単一のロードマップが生まれます
• managing-urgency — 締め切りのプレッシャーが計画を覆す場合