このブログ記事は、芝本秀徳著『誰も教えてくれない計画するスキル』を参考に、物語形式でプロジェクト計画の実践方法を解説したものです。
前回のあらすじ
山田太郎率いるプロジェクトチームは、マイルストーンを設定し、プロジェクトの重要な節目を明確にした。段階的導入計画も決まり、クリティカルパスも特定された。次は、これらのマイルストーンを達成するための具体的な作業の流れを設計する段階だ。
成果物から始める：プロセス設計の第一歩
月曜日の朝、プロジェクトルームには完成したWBSが壁一面に貼られている。山田は新しいホワイトボードの前に立った。
「今日からプロセス設計を始めます。」山田が切り出した。「プロセス設計には正しい手順があります。その第一歩は、WBSの成果物から必要なタスクを発想することです。」
村上が手を挙げた。「成果物から？タスクから考えるんじゃないんですか？」
「いい質問です。」山田は微笑んだ。「多くの人が陥る罠がそこにあります。『何をやるか』から考え始めると、本来不要な作業まで含めてしまう。でも『何を作るか』から考えれば、本当に必要な作業だけが見えてくるんです。」
山田はWBSから「要件定義書」という成果物を指差した。「この要件定義書を完成させるには、どんな作業が必要でしょうか？」
チームでブレインストーミングが始まった。現状を知らなければ要件は定義できない。だから現状業務の観察が必要だ。ステークホルダーの要望を聞かなければならない。だからヒアリングが必要だ。バラバラな要望を整理しなければならない。だから分析作業が必要だ。
「素晴らしい。」山田が頷いた。「成果物を起点に考えることで、必要十分なタスクが導き出せました。これが第一のステップです。」
グルーピングの妙：タスクがプロセスに変わる瞬間
タスクの洗い出しが一段落したところで、李が全体を眺めて気づいた。「これだけタスクがあると、管理が大変ですね。20個以上ありますよ。」
「その通りです。だから第二のステップ、タスクのグルーピングが重要なんです。」山田が説明を続けた。
山田は散らばったタスクを眺めながら、チームに問いかけた。「これらのタスクに共通点はありませんか？」
村上が最初に気づいた。「現状業務の観察、業務フローの文書化、ステークホルダーへのヒアリング...これらは全部、情報を集める作業ですね。」
「素晴らしい！」山田が賛同した。「これらをまとめて『情報収集プロセス』と呼べます。」
李も参加した。「ヒアリング結果の整理、要求事項の分析、優先順位付け...これらは集めた情報を整理・分析する作業です。」
「その通り。これは『分析プロセス』ですね。」
こうして、バラバラだった20個以上のタスクが、5つのプロセスにグループ化された。情報収集プロセス、分析プロセス、文書化プロセス、品質保証プロセス、承認プロセス。
「不思議ですね。」村上が感心した。「タスクをグルーピングしただけなのに、作業の流れが見えてきました。」
入力と出力を考える：プロセスの本質
「さて、第三のステップです。」山田が新しい話題を切り出した。「各プロセスには必ず入力と出力があります。」
「入力と出力？」村上が首を傾げた。
山田は身近な例で説明した。「料理を考えてみてください。材料が入力、調理がプロセス、できあがった料理が出力です。プロセスも同じで、何かを受け取って、処理して、何かを生み出します。」
「なるほど！」李が理解を示した。「情報収集プロセスなら、プロジェクトチャーターや現行システムの仕様書を入力として受け取って、現状業務フロー図やヒアリング議事録を出力として生み出すということですね。」
「完璧です！」山田が褒めた。「そして、ここが重要なんですが、各グループ内の入力と出力も整理する必要があります。」
チームで各プロセスの入力と出力を整理していった。情報収集プロセスの中にも、複数の入力と出力がある。分析プロセスも同様だ。この整理により、各プロセスが何を必要とし、何を生み出すのかが明確になった。
「プロセスの中身が透明になった感じがします。」村上が実感を込めて言った。
つなぐ：流れが生まれる瞬間
「第四のステップは、入力と出力の関係でプロセスをつなぐことです。」山田が核心に迫った。
李が気づいた。「あっ、情報収集プロセスの出力である『現状業務フロー図』や『ヒアリング議事録』は、分析プロセスの入力になっていますね。」
「その通り！」山田が興奮気味に答えた。「この発見が重要なんです。あるプロセスの出力が、次のプロセスの入力になる。この関係性でプロセスをつないでいきます。」
村上も理解が深まった。「つまり、情報収集プロセスから分析プロセスへ、分析プロセスから文書化プロセスへ...という具合に、出力と入力の関係で自然につながっていくんですね。」
「まさに！」山田が確認した。「ただし、一方通行とは限りません。品質保証プロセスで問題が見つかれば、文書化プロセスに戻る必要があります。」
李が付け加えた。「なるほど、品質保証プロセスの出力の一つに『修正指示書』があって、それが文書化プロセスの入力になるということですか。」
「完璧な理解です。」山田が満足そうに頷いた。「こうして、プロセス同士が有機的につながり、全体の流れが生まれます。」
階層を下りる：下位プロセスの世界
「最後の第五ステップは、下位プロセスの設計です。」山田が新たな次元の話を始めた。
村上が疑問を投げかけた。「下位プロセス？プロセスの中にまたプロセスがあるんですか？」
「鋭い質問です。」山田は例え話を始めた。「会社組織を思い浮かべてください。会社があり、その下に部署があり、部署の下にチームがある。プロセスも同じで、大きなプロセスの中に、より詳細な下位プロセスが存在します。」
李が具体例を求めた。「例えば、情報収集プロセスの中にも？」
「そうです。」山田が説明を続けた。「情報収集プロセスの中の『ステークホルダーヒアリング』というタスクを考えてみましょう。これ自体も、ヒアリング準備、ヒアリング実施、議事録作成という一連の流れがあります。」
「なるほど！」村上が声を上げた。「それぞれに入力と出力があって...ヒアリング準備は質問項目リストを出力し、それがヒアリング実施の入力になる。」
「素晴らしい理解です。」山田が確認した。「重要なプロセスや複雑なプロセスについては、このように下位プロセスまで設計します。ただし、すべてを詳細化する必要はありません。」
李が現実的な疑問を口にした。「どこまで詳細化すればいいんでしょうか？」
「経験則ですが、リスクが高い部分、新しい取り組みの部分、多くの人が関わる部分は詳細化します。逆に、定型的で実績のある部分は、上位プロセスレベルで十分です。」
プロセス設計の真価：2週間後の実感
プロセス設計から2週間が経過した。要件定義フェーズの真っ最中、山田のもとに村上が駆け寄ってきた。
「山田さん、すごいです！プロセス設計のおかげで、作業がスムーズに流れています。」
「どんなところで実感しましたか？」山田が尋ねた。
「情報収集プロセスから分析プロセスに移る時、必要な情報が全部揃っているかすぐに確認できました。出力リストと照合するだけで。昔なら『あれ、何か足りない気がする...』って不安になっていたと思います。」
李も別の観点から効果を語った。「下位プロセスまで設計していたヒアリング部分は、新人でも迷わずに実施できました。入力として何を準備し、どう処理し、何を出力すべきかが明確だったからです。」
高橋マネージャーも満足していた。「プロセスがつながっているおかげで、今どこにいて、次に何が来るか、常に把握できています。進捗管理が本当に楽になりました。」
生きたプロセスへ：継続的な改善
月次の振り返り会議で、山田はチームに問いかけた。「プロセス設計で改善すべき点はありませんか？」
村上が手を挙げた。「分析プロセスの出力に『用語定義集』を追加すべきだと思います。文書化プロセスで必要になることが分かりました。」
李も提案した。「品質保証プロセスの下位プロセスをもう少し詳細化した方がいいかもしれません。レビューの手順で混乱することがありました。」
「素晴らしい気づきです。」山田が応じた。「プロセスは一度設計したら終わりではありません。使いながら改善していくものです。」
チームで議論し、プロセスを更新した。新たな出力を追加し、曖昧だった下位プロセスを詳細化した。また、不要だと分かったタスクは削除し、グルーピングも一部見直した。
「大切なのは」山田が強調した。「5つのステップを守りながら改善することです。思いつきで変更するのではなく、成果物から考え、グルーピングし、入出力を整理し、つなぎ直す。この原則を守ることで、プロセスの一貫性が保たれます。」
第5章のまとめ：正しい手順がもたらす成功
夕方のプロジェクトルーム。山田はホワイトボードに5つのステップを書き出した。
「プロセス設計の手順をもう一度確認しましょう。第一に、成果物から必要なタスクを発想する。第二に、タスクをグルーピングしてプロセスにする。第三に、各グループの入力と出力を整理する。第四に、入力と出力の関係でプロセスをつなぐ。第五に、必要に応じて下位プロセスを設計する。」
村上が感想を述べた。「最初は面倒に感じましたが、この手順のおかげで、複雑な作業も整理できました。」
李も同意した。「特に入力と出力の整理が効果的でした。何が必要で何を作るのか、常に明確でした。」
山田はまとめた。「プロセス設計は、混沌とした作業群に秩序をもたらします。そして、その秩序は成果物を確実に生み出すための道筋となります。」
「次はスケジュール化です。」山田が締めくくった。「このプロセスフローに時間軸を加えて、具体的な計画に落とし込んでいきます。」
窓の外では、夕日が沈もうとしていた。チームは、正しい手順で設計されたプロセスという強力な武器を手に入れた。それは単なる作業の流れ図ではなく、成果物を確実に生み出すための精緻な設計図だった。
読者の皆様へ
第5章では、『誰も教えてくれない計画するスキル』に基づいたプロセス設計の正しい5つのステップを、物語形式でお届けしました。
プロセス設計は、以下の順序で行うことが重要です：
- 成果物からタスクを発想する
- タスクをグルーピングする
- 各グループの入力と出力を整理する
- 入力と出力の関係でつなぐ
- 下位プロセスを設計する
この手順を守ることで、成果物を確実に生み出すための論理的で実行可能なプロセスフローが完成します。
次回の第6章では、このプロセスフローに基づいて、具体的なスケジュール（ガントチャート）を作成していきます。お楽しみに！
