○ 前回、WBSの効果について解説したが、今回は、その中で見積もり評価とプロジェクトマネジメントの双方のベースになる考え方である「スコープが決まる」ことについて、さらに掘り下げて解説したい。
関連記事：プロジェクトマネジメントの一丁目一番地、「WBS」がもたらす7つの効果とは？
WBSの100％ルールがなぜ怖いの？
プロジェクトマネジメントに関わっている方の中には、タイトルを見て「WBSの100％ルールは知っているけど、なんでこれが怖いの？」と、はてなマークがついた方も多いのではないだろうか。2012年の拙著『システム開発のためのWBSの作り方』（日経BP）でも100％ルールについてはもちろん触れているが、この時はまだ筆者自身も「怖い」と思っていなかった。筆者が「怖い」と思い始めたのは、比較的最近、2021年に同書のeラーニング教材を作成している時だった。
なお、ここで言う「怖い」の意味は、混乱プロジェクトやもめ事につながる可能性が高いということである。順を追って説明する。
まず「WBSの100％ルールとは何か」から説明する。100％ルールは、WBSの階層構造において、「親子関係の子に当たる（下位レベルの）WBS要素の集合は、その親のWBS要素を100％網羅する」というルールだ。図1と図2に例を示した。両ケースは、100％を満たしているだろうか？
図1を見てみよう。上部のWBSは、システム開発のWBS要素として「テスト」が書かれていない。テストを行わないシステム開発はありえないから、100％ルールを満たさない。次に図2を見てみよう。上部のWBSは、2階層目の「テスト」のWBS要素として「テスト設計」「組み合わせテスト」「連動テスト」などが記載されているが、図2下部のWBSに示すように「テスト設計」は、「テスト」工程ではなく、「設計」工程の作業である。上位レベルと下位レベルのWBS要素が親子関係になっていないので、このケースも100％ルールを満たさない。
こうした抜け・漏れや親子関係の不一致があってはWBSとしては不完全なので、プロジェクトマネジメントの研修では、MECE（Mutually Exclusive and Collectively Exhaustiveの略でミーシーと読む。「漏れなく、ダブりなく」を意味する）に作業を洗い出すことが大事だと教えられる。
確かに抜け・漏れはまずいけど …
では、図3の例はどうだろう？ あるプロジェクトで設定したシステム方式設計工程の「実現方式（非機能要件）の設計」のWBSである。
見積もりやプロジェクトマネジメントの研修で聞くと、何かありそうだと迷いながらも「100％ルールを満たしていない」と答える人が圧倒的に多い。「実は満たしている」と説明を始めると一様に、はてなマークが顔に浮かぶ（えっ、性能設計が入ってないけど…）。確かに標準WBSを見ると、非機能要件の設計項目は他にもある（図4）。
だが、ここで議論しているのはプロジェクトのWBSである。このプロジェクトで実施するのは「信頼性設計」「システム連携方式設計」「ユーザビリティー設計」の3つのみ、これで100％だ。性能設計など他の項目はスコープ外である。だから性能設計はやらないと言っているのだ。見積金額もこれを基にはじき出すので、スコープ外の作業をやることになったら追加費用が発生する。
このように100％ルールは、抜け・漏れやダブりのない整合性の取れたWBSの作成を求めるとともに、WBSがスコープのベースライン（ステークホルダー間で合意した基準線）として機能することを担保するルールにもなっている。つまり、100％ルールをWBSのすべての階層に適用することにより、WBSに書かれた作業はスコープ内、WBSに書かれていない作業はスコープ外となり、スコープのベースラインが明確になる。
なお、100％ルールは、ISOのプロジェクトマネジメント関連の国際規格 ISO21511 Work breakdown structures for project and programme management（2018年制定）にも用語として定義されている。国際規格と聞くとWBSの書き方を細かく決めているのではないかと想像するかもしれないが、そうではなく、この規格はWBSの概念定義などが主で、表記方法を規定するものではないことを補足しておく。実務に携わる方は、WBSがISO化されていることと、その中に100％ルールが記載されていることを知っておけばよいだろう。
IT以外のプロジェクトでは100％ルールは「怖い」と思われていない？
WBSの100％ルールについて、IT分野以外のプロジェクトマネジメントの専門家数人と議論してみたのだが、おおむね「100％ルールが怖い？ なんで？ WBS作成の原理原則をうたっているもので、当たり前のことでは？」という反応だった。抜け・漏れやダブりがあると困るのは、すべてのプロジェクトに言えることだ。だが、スコープのベースラインの問題は、ITプロジェクトほど深刻ではないようだ。確かにそうかもしれない。
発電所などのプラント建設プロジェクトでは、契約締結時点でスコープが曖昧ということはありえない。例外はあるだろうが、プロジェクト開始後、スコープが変わることは基本的にない。また、受注者と発注者の責務の分担はWBSではなく契約で厳密に決められる。
家電製品や自動車など、市場投入型ビジネスの新商品あるいは新モデル開発プロジェクトはどうだろう？ 企画から始めるので、確かにスコープは曖昧で、技術上の隘路や市場動向などによりスコープ変更は頻繁に起こるだろう。だが、優先順位はスコープのコントロールよりも、売れる商品を作ることや量産に入ってからの原価、品質などの方がはるかに高い。
ITプロジェクトでWBSの100％ルール、すなわちスコープのコントロールがなぜ怖いのか考えてみよう。また、ITプロジェクトと言っているが、その中でも怖いのは、生産管理システムや販売管理システムなど、企業のビジネスを支える業務アプリの開発を請け負うプロジェクトだ。以下、業務アプリ開発プロジェクトを対象に考察する。
業務アプリは、企業の中でしか位置付けが決まらない。同じような機能が提供されていても、企業規模や製品、業界でのポジション、トップや現場の責任者の考え方、ビジネス文化などにより業務は異なる。基本的に一品生産である。ベンダーは、こうしたユーザーのバックグラウンドも理解したうえでシステムを開発しなければならないのだが、見積もり時点では、わからないことも多い。ユーザーから提示された要件をこう解釈したけれども、もしかしたら齟齬（そご）があるかもしれない。こうしたスコープが曖昧な状態で費用を約束する。このように見積もり段階で怖さの種がまかれる。
スコープが曖昧な状態で見積もっているので、プロジェクト開始後の仕様追加や仕様変更が頻繁に発生する。設計してみると見積時に想定していた機能とやはり齟齬がある。カットオーバーに必要な機能なら対応しなければならないが、問題は、対応するのに費用が発生することである。費用を負担した方がロスコストとなる。だから、もめる。大きなトラブルになると責任問題にもなるので、なおさら解決しにくくなる。
つまり、プラント建設プロジェクトや新商品あるいは新モデル開発プロジェクトとは異なり、ITプロジェクトは見積もり段階でスコープのベースラインがよく定義できないうえに、開発段階ではベンダーとユーザーが双方の役割と責務を果たしながらプロジェクトを進めなければならないという面がある。このため、ベンダーとユーザーの境目を決めるよりどころとしてWBSの100％ルールが重要な意味を持つ。
見積もり段階でWBSの記載項目を議論することが大切。
では、スコープに関するトラブルを少なくするには（残念ながらなくすとまではいかないが）、どうすればよいか？ 手を打つなら見積もり段階だ。ベンダーは、見積もり時点でユーザーにWBSベースでスコープに含まれるものと含まれないものをきちっと説明する。ユーザーは、必要な作業がWBSに記載されているか、抜けがないかを評価する。これに尽きる。プロジェクト開始後、齟齬が発覚してからでは手遅れである。見積もり段階でWBSの100％ルールを基準にユーザーとベンダーで議論する場が設けられるだけでも大きな効果があると期待する。
最後にもう1つだけ怖い話をしておきたい。もし図5のように「実現方式（非機能要件）の設計」とだけWBSに書いて、下位層の作業項目を書いていなければどうなるだろう？
WBSを作成した側は「信頼性設計」と「システム連携方式設計」、「ユーザビリティー設計」の3つしかやらないつもりでも、受け取った側が、図4の標準WBSに示したような「信頼性設計」から「システム移植方式設計」まですべてやってくれると解釈しても仕方がない。双方の思惑が食い違っていることに気付いた時点でもめ事になることは避けられないだろう。
例に挙げた非機能要件のWBSは比較的わかりやすいが、グレーな作業もたくさんある。また、標準WBSは網羅性が大事なのでMECEに作業を洗い出すが、あくまでも現時点で100％と考えられる作業項目である。例えば、図4の非機能要件についても技術が変われば新たな非機能要件が加わるかもしれない。だから、やる、やらないの意思を明確に伝えられるところまでブレークダウンして提示しないとトラブルの元になる。
ITプロジェクトにおいてWBSの100％ルールを知らないと怖い理由をご理解いただけただろうか。WBSをMECEに作成するだけではなく、スコープを明確にするという観点が重要なのである。
