プロジェクト憲法の作り方と100_ルール

こんにちは、ザ・ディープダイブへようこそ。いやー、プロジェクトの終盤になって、「あれ？これもスコープに入ってると思ってました」なんて言われて、 現場が急に慌ただしくなった経験、ありませんか？ああ、ありますね。ひやっとしますよね。ですよね。 今日はそんなプロジェクトの悲劇を防ぐための、まあ魔法の設計図とも言えるWBSについて、 あなたが共有してくださった資料をもとに、その核心に迫っていきたいなと思います。WBSと言うと、多くの人が何か単なるタスクをツリー状に並べたもの くらいのイメージかもしれないんですけど。ええ。でも資料を読み解くと、これってもっとずっと強力で、 プロジェクトの憲法みたいな役割を果たすものだってのが見えてくるんですよね。今回はこのプロジェクト憲法の正しい作り方と使い方を理解して、 なぜこれが実務で絶大な効果を発揮するのか、一緒に紐解いていきましょう。プロジェクト憲法。いや、いい表現ですね。 まさにその通りで、これがあるかないかでプロジェクトが法治国家になるか、それとも無法地帯になるかが決まると言っても、まあ過言ではないですね。 しっかりしたWBSがあれば見積もりの精度は劇的に上がりますし、チーム内の「言った言わない」みたいな混乱も防げますから。さて、この憲法のどの条文から見ていきましょうか。 はい。では早速、この憲法の最も重要ないわば第一条から見ていきましょう。資料の中心的な考え方として挙げられているのが「MECE、MECE」ですね。 はい。つまり「漏れなくダブリなく」というコンセプトです。ええ。そしてそのMECEの思想をWBSに適用したものが「100%ルール」と呼ばれるんです。 100%ですか？はい。これはWBSで分解された一番下の階層の作業、これを全部足し合わせると、 プロジェクト全体の作業範囲、つまりスコープと完全に文字通り100%一致しないといけないという大原則です。100%ですか。つまり、それ以上でもそれ以下でもダメだと。 そうです。これがなぜ憲法の第一条と言えるほど重要かというと、このルールがあることで、 このWBSという憲法に書かれていないことは我々の国の仕事、つまりプロジェクトのスコープではありませんとはっきりと。ええ、明確に宣言できるからです。 後からクライアントとか上司に「ついでにこれもお願い」って言われた時に、感情論じゃなくて、ああ、ありますね。 ありがとうございます。ただその作業は現在のWBSに含まれておりませんので、憲法改正、つまりスコープ変更の正式な手続きが必要になりますね。 追加する場合、納期と予算への影響を再評価しましょうと。こう客観的な根拠を持って対話ができる。これが現場を守る強力な防衛線になるんです。 なるほど。単に「できません」って突っぱねるんじゃなくて、やり方を変えましょうっていう、こう建設的な議論に持ち込むための土台になるわけですね。 でもうーん、正直なところそれって少し堅苦しすぎませんか？はいはい。なんかスタートアップみたいなスピード感が求められる現場だと、 そんな厳密なルールは足かせになりそうな気もしますけど。ああ、非常に良い指摘ですね。重要なのはルールで縛り付けること自体が目的じゃないっていう点なんです。 目的ではない。ええ。目的は変更があった際に、それがプロジェクト全体にどんな影響を与えるのかを全員が冷静に把握して、合意の上で進めるための共通の言語を持つこと。 変更を拒否するためじゃなくて、むしろ変更を安全に受け入れるための仕組みなんです。この憲法があるからこそ安心して航海を続けられるというわけですね。 憲法があるからこそ柔軟な法改正も可能になると。なるほど、理解が深まりました。じゃあ、その憲法の中身、つまり個々の条文はどれぐらい具体的に書けばいいんでしょうか。 細かすぎると、今度は憲法が分厚くなりすぎて誰も読まなくなりそうです。まさに。そして、この適切な粒度を見極めることこそ、 プロジェクトマネージャーの腕の見せ所であり、多くの人が最初にぶつかる壁でもあります。この「どこまで細かく書くか」という問題に対する一つの優れた指針が資料にもありましたよね。 「80時間ルール」、あるいは「40時間ルール」ですね。はい。WBSの一番下の階層、つまりタスクの最小単位であるワークパッケージは、 一人の担当者が2週間80時間か、まあ理想的には1週間40時間で完了できるサイズにするのが目安だど。その通りです。 この数字の裏にある思想を理解することが重要なんですね。思想ですか。例えば「顧客管理機能の開発」というタスクが期間1ヶ月とだけ設定されていたとします。 2週間経った時点で進捗を確認すると、担当者は「大体50%です」って答えるかもしれないじゃないですか。ああ、よくありますね。その50%が何を意味するのか全然わからない。 そうなんですよ。簡単な画面設計だけ終わって50%なのか、一番厄介なデータベース連携の目処がついて50%なのかで意味が全く違いますから。違いますね。 1ヶ月という期間はいわばブラックボックスなんです。一方で、タスクが2週間単位のワークパッケージに分解されていれば、 「今週中にこの顧客情報登録画面の実装は完了しますか？」という具体的で白か黒かではっきり答えられる質問ができるんです。 確かに「はい」か「いいえ」で答えられますね。もし遅れが発生しても、それを最大でも2週間以内に検知して、すぐに対策を打てる。 進捗管理の解像度を上げるための非常に効果的な仕組みなんです。これはマイクロマネジメントじゃなくて、リスクの早期発見システムと捉えるべきですね。 なるほど、進捗報告が「感想」から「事実」に変わるわけですね。ところで、WBSの図を見ていると、よく1.1.2とか2.3.1といった番号が振られていますよね。ええええ。 正直なところ、あれはワードのアウトライン機能でつくようなただの整理番号だと思ってました。ははは、多くの人がそう思ってます。 でもあの番号には、実はプロジェクト全体を動かす神経系のような非常に深い意味が隠されてるんです。資料では「コード体系」という言葉で説明されていましたね。 ええ。各タスクの階層構造を示す「住所」のようなものだと。まさに住所です。そして、その住所情報がプロジェクトの様々な情報と連携する際の 「共通キー」になる点が、ここからが非常に面白いところで。共通キー。ええ。例えば会計システムと連携させれば、住所コード1.1.2の作業に これまで人件費がいくらかかったかを自動で集計できます。へー、そんなことまで。それはなんか大企業の話であって、僕らのような中小規模のプロジェクトでは、 そこまでのシステム連携は現実的ではない気がしますが。いいえ、そんなことはありません。立派な会計システムがなくたって、例えば経費精算のスプレッドシートに、 このWBSコードを記入する欄を一つ追加するだけでもいいんです。ああ、なるほど。それだけで後からプロジェクトのどの部分にコストが集中したのかを分析する精度が格段に上がります。 さらに言えば、文書管理。関連する設計書とか議事録、顧客からのメールなんかを保存する際に、ファイル名の頭に1.1.2ってつけるルールにするだけでもいい。 あ、それならすぐできますね。そうです。後から「あのログイン機能関連の資料はどこだっけ？」ってなった時に一瞬で検索できるようになる。 ツールに関わらず情報を体系的に整理するための強力な武器になるんです。なるほど、考え方次第なんですね。番号一つでコストと情報がタスクに紐付く。 これは目から鱗です。さて、ここまでで憲法の骨格、つまりツリー構造と条文番号であるコード体系の作り方が見えてきました。 でも資料によれば、図を作っただけではまだ憲法は未完成だど。ええ。なぜなら法律の条文がそうであるように、言葉の解釈は人によって変わるからです。 解釈が。はい。例えばWBSに「ユーザー認証機能の実装」という箱が一つあったとします。これを見て、Aさんはログインとログアウト機能と考え、 Bさんはパスワードリセット機能も含むと考え、クライアントはSNSアカウントでのログインも当然入ってるでしょうと考えるかもしれない。うわあ。 この認識のズレが後々の巨大なトラブルの火種になります。恐ろしいですね。この解釈のズレをなくして、憲法の条文に公式な注釈を与えるのがWBS辞書の役割です。 WBS辞書。これは各ワークパッケージについて具体的に何を以て完了とするか、つまり完了の定義ですね。はい。 それから作成される成果物は何か、担当者は誰かといった詳細を文書で明確に定義した補足資料です。完了の定義を文書で書く、ですか。 これが決定的に重要です。以前私があるプロジェクトで見た、もう悪夢のような事例なんですけど。悪夢。テスト完了の定義が曖昧だったために、 開発チームは「単体テストが終わったから完了だ」と報告し、品質保証チームは「いやいや、結合テストでバグがゼロになるまで終わらない」と主張して、 リリース直前に大問題になったんです。うわあ、それは生々しいですね。もしWBS辞書に「完了とは結合テストケースを全て消化し、クリティカルなバグが0件であることを 品質保証リーダーが承認した状態を指す」と一文あれば、こんな悲劇は起きなかった。WBS辞書は未来の地獄を見ないための、いわばお守りなんです。 お守りですか。図と辞書。二つが揃って初めてWBSが機能するというのがよくわかりました。さて、ここまで学んできた知識をリスナー側からどう生かしていけばいいのか。 資料では「試験対策」と「実務」、両方の視点からのアドバイスも書かれていますね。ええ。まず試験対策の観点から。これはシンプルですけど非常に重要で、 情報処理技術者試験なんかのWBSを作成するプロセスは、「プロジェクトスコープマネジメント」という知識エリアの一部である。あ、その分類ですね。 そうです。この分類を覚えておくだけで正解できる問題があるんです。試験では知識そのものだけじゃなくて、それが大きな知識体系PMBOKとかの中で どこに位置づけられてるかが問われるんですね。WBSは「スコープ」、つまりプロジェクトの「領土」を定義するためのものだと覚えておけば迷うことはありません。 資料にあったポータルサイトの工夫も面白いと思いました。学習者向けに「漏れがあったり分解の粒度がバラバラな悪いWBSの例」と 「MECEが守られた良いWBSの例」を並べて、視覚的に比較させるというものです。はいはい。確かに絵で見せられると「ああ、なるほど。こういうことか」と一瞬で理解できますよね。 百聞は一見にしかず、ですね。特に「粒度がバラバラ」という状態は言葉で説明するよりも、悪い例を見せた方が「なんか気持ち悪いな」っていう感覚で直感的に理解できますからね。 そしていよいよ実務への橋渡しです。この完璧なプロジェクト憲法としてのWBSで、「何をやるか」が定義できた。でも国はそれだけでは動きませんよね。 その通りです。次に決めなければならないのは「誰がやるか」。誰が。はい。ここで登場するのがこれまた強力なツールであるRACIチャート、レイシーチャートです。 責任分担マトリックスとも呼ばれますね。WBSとRACIチャート。この二つはどうつながるんですか。これが非常に美しく繋がるんです。 まず先ほど作ったWBSのワークパッケージをそのまま縦軸に並べます。はい。そして横軸にプロジェクトメンバーの名前を並べる。 そうしてできた表の中に、「誰がそのタスクの実行担当者（Responsible）で、誰が最終的な説明責任者（Accountable）なのか」。 RとAですね。そうです。さらに「誰に相談すべきか（Consulted）」、「誰に報告すべきか（Informed）」をR、A、C、Iの記号で埋めていくんです。 なるほど、WBSで分解したタスクリストがそのままRACIチャートのインプットになるんですね。そうなんです。これで初めてやるべきこととやるべき人が明確に紐づく。 まさに。このWBSで何をを定義し、RACIチャートで誰がを割り当てるという一連の流れを理解して実務で使いこなせると、 「あ、この人はプロジェクトの動かし方を本当に理解しているな」とチームや上司から一目置かれる存在になります。 憲法を作り、それに基づいて政府の役割分担を決める。この流れそのものが、優れたプロジェクトマネジメントの縮図なんです。いや、今日は本当に勉強になりました。 WBSは単なるタスクのツリー図なんかじゃなくて、スコープという領土を確定する100%ルールという憲法第一条があり、ええ。 管理可能な単位に法律を定める80時間ルールがあり、そして言葉の解釈を統一するWBS辞書という公式注釈書がある。三位一体となったプロジェクトの成功を支える、まさに 憲法そのものだということが心の底から理解できました。ええ。良い憲法が描ければ、プロジェクトの成功確率は間違いなく上がります。 最後に、これを聞いているあなたに一つ思考の種をまかせてください。今日私たちはWBSで「何を」やるかを定義し、RACIチャートで「誰が」やるかを明確にしました。 しかし、プロジェクトという国家を運営するにはまだ決定的に重要なピースが足りません。と言いますと。それは「いつまでに（納期）」、そして 「いくらで（予算）」です。今回学んだようにやるべきことをここまで詳細に具体的に分解できた今、あなたのプロジェクトのスケジュールやコストの見積もりは、 これからどのように変わるでしょうか？その精度はどれだけ上がるでしょうか？ぜひ、次のステップとしてその変化を想像してみてください。