マインドマップ(mind map)は、プロジェクト最初の2時間には最適な道具ですが、それ以降には向きません。「このプロジェクトは何でできていて、何が何に依存しているのか」という問いにはとても強い一方、日付や担当、進捗には弱いからです。その後の半年間を占めるのは、まさにそのどれかです。
だから使えるやり方は「マインドマップでプロジェクトを計画する」ことではありません。範囲をマップにし、葉(リーフ)が見積もれるところまで分解し、その葉を実際に作業を管理するツールへ書き出すことです。マップの役目は引き継ぎで終わります。その後は、誰かに「このタスクはなぜあるのか」と聞かれたときに読み返すものとして残ります。
フェーズではなく成果物でブランチを分ける
定番の構成は「調査 → 設計 → 構築 → テスト → ローンチ」ですが、ほぼ間違いなく不向きです。フェーズのブランチはプロジェクトの進み方を表すだけで、何が生まれるかを表しません。そのため成果物がどれも5つのブランチに分散し、1つの成果物を全体として見ることができなくなります。
分ける基準は、完了したときに存在しているものです。
# Website relaunch
## Content
## Design system
## Build
## Migration
## Launch comms
これらにはそれぞれ担当者がいて、完了の定義があり、「終わったか」を判断する明確な基準があります。フェーズにはありません。
例外は、建設工程や規制当局への申請のように、本当に順番どおりに進むプロジェクトで、フェーズそのものが成果物になる場合です。その場合は放射状ではなくタイムライン型のレイアウトを使い、順序を暗黙にせず図として描きます。
見積もれる葉まで分解する
各ブランチを、揉めずに所要時間を言えるところまで分解し続けます。そこがマップの最下層で、それを見つけること自体がこの作業の本題です。
十分に分解できたサインは2つあります。
- 葉が1人の作業で、1回の作業時間か1日で終わる。2人必要なら、それは2つの葉と1回の引き継ぎです。
- 見積もりが議論ではなく数字になる。「2日から2週間」というのは、そのノードにまだ答えの出ていない問いが残っているということなので、その問いのところで分割します。
分解しすぎのサインも2つあります。葉が100個前後を超える、または葉が作業の単位ではなく手順のチェックリストになっている場合です。「移行スクリプトを書く」を8行の疑似コードに分解するのは、ただの書き写しです。
階層は3〜4段に落ち着くことが多いです。1つのブランチだけがそれ以上深くなるなら、そのブランチは独立したプロジェクトで、別のマップが必要という合図です。
忘れられがちなブランチ
どのプロジェクトのマップにも、次の4つを加えてください。これらは遅延の4大要因ですが、誰の成果物でもないため、ほとんどの計画から抜け落ちています。
- 他の人への依存。 外部の誰かの返事が来るまでプロジェクトが止まる箇所すべて。法務レビュー、APIキー、クライアントの承認など。1つずつ名前をつけ、リードタイムを書きます。
- 不明点。 まだ見積もれないこと。見積もれないからといって外さないでください。だからこそ見える場所に置くべきで、不明点のブランチがあるのが誠実な計画です。
- やらないこと。 範囲から外すものを明示します。このブランチは、プロジェクトで最も高くつく会話を防ぎます。4か月目に「それは最初から対象だったのか」と揉める、あの会話です。
- 完了の条件。 プロジェクト全体の受け入れ基準。まだ意見の食い違いが安く済む最初の段階で書いておきます。
依存関係をクロスリンクでつなぐ
階層が表せるのは包含関係だけです。「コンテンツモデルが承認されるまで移行は始められない」といった関係は表せません。その事実はブランチをまたいで存在し、スケジュールを決めるのもその事実です。
そのリンクを描いたら、マップから2つのことを読み取ります。
入ってくるリンクが多いノードがボトルネックです。計画のどこにあるかに関係なく、最初に着手すべきもので、たいてい誰も最初にやりたがらないものです。
4〜5本つながったリンクの連なりが、おおよそのクリティカルパスです。マインドマップが計算してくれるわけではありませんが、最も長い連なりが見えれば、どのブランチに余裕がないかは分かります。
任意の2つのトピックをつなぐクロスリンクがあるので、依存関係のレイヤーを作れます。進捗がブランチに集計されるチェックボックスで、成果物ごとに自分の完了度を報告できます。レイアウトは8種類。順番どおりのプロジェクトはタイムライン、範囲整理は放射状で描けます。
できることマップ上で見積もる
ボトムアップで、幅を持たせて見積もります。各葉に見積もりを入れ、ブランチの合計を自動で集計させ、その合計を与えられた期日に合わせたくなる気持ちを抑えてください。この2つの数字の差が、この作業全体で最も役に立つ成果です。平均してならすと、それが消えてしまいます。
続けたい習慣が2つあります。
点ではなく幅で見積もる。「3〜8日」には、「5日」が切り捨てる不確かさが含まれています。幅の広さを見れば、どの葉をもっと考えるべきかが分かります。
調整コストを明示的に加える。 4人で進める30タスクのプロジェクトは、30個の見積もりの合計ではありません。レビュー、引き継ぎ、待ち時間も立派な作業で、誰も信じないバッファの割合を足すより、それ用のブランチを作るほうが誠実です。
そして、マップから出る
多くの人が飛ばす手順で、「マインドマップで計画した」が悪い結末になりがちな理由はここにあります。
葉をタスク管理ツールに書き出します。たいていのマインドマップアプリはMarkdownかOPMLで書き出せ、たいていのタスク管理ツールはMarkdownのチェックリストを取り込めるので、2分で済みます。タスク管理ツールにできてマップにできないのは、担当者の割り当て、日付の保持、遅れの表示、6人での同時更新です。
ただしマップは残し、読み取り専用にしておきます。その後の役目は「このタスクはなぜあるのか」「これを削ると何が壊れるのか」に答えることです。どちらもタスク管理ツールが平らにしてしまった構造についての問いなので、ツールでは答えられません。
編集のために開き直すのは、範囲が変わったときだけにします。タスク管理ツールと並べて毎日更新されるマップは、情報源が2つあるのと同じで、どちらかは必ず間違っています。
1人でプロジェクトを計画する場合
ルールは少し変わり、むしろ良くなります。マップは1回の作業時間で作り、2階層より深く分解せず、日付は外部の期限があるものにだけ入れます。
1人の仕事でいちばん価値があるのは、ほぼ「やらないこと」と「不明点」のブランチです。計画が1人の頭の中にあると見えなくなる2つで、1人のプロジェクトを静かに食いつぶすのもこの2つです。