意外に知らないプロジェクトマネジメントの大局観と成功の秘訣
最終更新日：2024年8月9日
修正内容：「はじめに」の３つの考え方の説明を補足
はじめに
日本で最初の民間大手シンクタンクで、プロジェクトマネジメントのコンサルタントとして、ある時はＰМ、ある時はＰМОとして、お客様と問題解決に取り組んでいます。日々の学びを共有することで、お役に立てれば幸いです。
本記事では、
ＱＣＤバランスをはかるために必要な、でも意外に知られていないプロジェクトマネジメントの基本的な考え方をご説明します。
これらの考え方を参考にして頂くことで、
プロジェクトに潜む不確実性を早期に排除し、プロジェクトマネジメントの目的である、ＱＣＤバランスを成立させることができるようになります（下図参照）
これらの考え方は、
プロジェクトマネジメントの基本であるにもかかわらず、意外に知られておらず、ＰＭＢＯＫなどの教書でもあまり取り扱われておりません。
理由は、
これらがＰＭ有識者にとってあまりに自明で、普段から無意識にやっているため、無意識から意識下に持ってきて言語化することが難しいためです。
ちなみに、
プロジェクトマネジメントの知識については、
ＰＭＢＯＫで、たくさんの知識やメソッドが幅広に紹介されていますが、
「プロジェクトの目的や状況にあわせて、任意にお選びください」というスタンスにとどまり、それぞれの知識やメソッドが、どのようにＱＣＤバランスに寄与するのかの説明がないため、とりあえず、できることを自己流でやってみるということになりがちです。
対して、
これからご説明する「基本的な考え方」では、プロジェクトマネジメントという手段が、ＱＣＤバランスという目的をどのように実現しているか、ということを、できるだけ構造的に説明していきます。
これらの考え方は、
プロジェクトマネジメントを、
「不確実性が引き起こす問題解決」として捉えるとてもシンプルなもので、結局は次の３つの考え方に帰結します。
＜ プロジェクト前半 ＞
①.如何に 早期に不確実性を排除しＱＣＤをバランスできるか
＜ プロジェクト後半 ＞
②.如何に 早期にバランスさせたＱＣＤを維持し続けられるか
③.如何に 余力内でＱＣＤバランスを脅かす課題を解決するか
いいかえると、
不確実性を早期に排除してＱＣＤをバランスさせ、
余力内で、ＱＣＤバランスを脅かす課題を解決できれば、
プロジェクトは成功します。
（理屈のうえのお話で、現実はそんなに簡単ではありませんが💦）
プロジェクトは、一見すると、
それぞれの要素が広く複雑に絡み合っているようにみえますが、大まかな世界観のイメージは前述の通りで、結局は前述の３つの考え方に帰結します。
これらの３つの考え方は、
プロジェクトにおけるＯＳのような位置づけで、ＰＭＢＯＫのナレッジをＱＣＤバランスに向けて有効に活用するための羅針盤となります。
そういう意味で、
ＰＭがプロジェクト全体をその通りマネジメントできているかどうか、との｢プロジェクトに対するグリップ感」はとても重要になります。
逆にいうと、
グリップがはずれ、課題の量が解決余力を超え始めると（メンバーは気づかないことが多いですが、）プロジェクトの瓦解がはじまります。ので、「課題を解決余力内にいかに収めるか」の視点は、とても重要になります。
また、
プロジェクトにおける解決余力は、ほぼ一定（余力工数×時間）のため、いかにはやめはやめに不確実性を排除するか、「いかにはやめはやめに課題を解決するか」、が重要な視点になります。
ここまで、
重要な３つの視点（グリップ感、解決余力の留意、早めの対応）について述べました。これらの考え方は、とてもシンプルで、ＰＭＢＯＫのように複雑なものではありませんが、
それぞれの考え方が構造的に連携して機能し、ＱＣＤバランスを実現していく仕組みになっていますので、プロジェクトマネージャーの経験の少ない方には、イメージが湧きにくい場面があるかもしれません。
もし、
記事中の説明で、わからないところなどがありましたら、遠慮なくコメントや直接メッセージなどでお尋ねください。※長文（約1.8万文字）ではありますが、ゆっくり、お付き合い頂けるとありがたいです。
では、次章より、
まずは１章、２章で「基本的な考え方」をご理解いただくための前提となる「２つの目的」と「ＱＣＤバランスのＱ」についてご説明した後、３章からどうやってＱＣＤバランスを成立させるかについて説明してまいります。
１.正しく理解すべき２つの目的
1-1.そもそも、プロジェクトマネジメントとは
さて、
そもそも、なぜ、
プロジェクトマネジメントは必要とされるのでしょうか。
それは、
｢不確実性｣によってプロジェクトのＱＣＤバランスが損なわれるためです。
もし、
プロジェクトに｢不確実性｣がなければＱＣＤバランスは損なわれることはないので、プロジェクトマネジメントは不要です。
プロジェクトに｢不確実性｣がなければ、
それはいわゆる定常業務であり、もはや非定常業務であるプロジェクトではありません（下図参照）
そういう意味で、
プロジェクトマネジメントとは、シンプルにいうと、｢不確実性によってＱＣＤバランスが損なわれる｣という問題の「解決策（いわゆるソリューション）」です。
極端な言い方になりますが、
この問題が存在しなければ、プロジェクトマネジメントは不要です。
結果、
上述内容を踏まえると、
｢不確実性によってＱＣＤバランスが損なわれる｣との問題の解決策として、プロジェクトマネジメントのなすべきことは全て次の３つに収斂します。
・如何に 早期に不確実性を排除しＱＣＤをバランスできるか
・如何に 早期にバランスさせたＱＣＤを維持し続けられるか
・如何に 余力内でＱＣＤバランスを脅かす課題を解決するか
プロジェクトマネジメントにおいては、
たくさんの知識領域があり、限られたリソースの中で、何から手を付けたらよいのか悩ましいところですが、プロジェクト全体を通して、常にこの３点に注力することで、ＱＣＤバランスの成立確立を効果的に上げていくことができます。
かかる背景を踏まえて、
最初の起点となるプロジェクトマネジメントとプロジェクトのそれぞれの目的について考えていきます。
余談：解決すべき本来の問題と離れてしまったプロジェクトマネジメント
繰り返しになりますが、
プロジェクトマネジメントとは、そもそもシンプルに言えば、前述のような問題解決の手段です。
ところが、
ＰＭＢＯＫなどの教書では、なぜか解決すべき本来の問題とその解決策との文脈で説明されることのほとんどないまま、まるで店頭に並ぶ商品のように、たくさんの手法や知識が、幅広い領域に渡って、バラバラに並べられています。
それらの手に余る情報を前に、
私たちは立ちすくみ、混乱し、自信を失います。
そして、
本来のプロジェクトマネジメントに対する理解を伴わないまま、それらの商品の中から、自己流で、場当たり的に、何となくＰＭＢＯＫに乗っているので、という理由で、よさそうなものを選ぶことになります。
ですが、
プロジェクトマネジメントは、「そもそもの問題とその解決策」という視点から理解すると、実はとてもシンプルです。ぜひ、本記事を通して、その感覚を持っていただけると幸いです。
余談：非定形業務と提携業務
プロジェクト（非定形業務）と提携業務は、
それぞれのパラダイム（課題の枠組み）が全く異なります。
プロジェクト（非定形業務）において最も重要な課題が「いかに早期に不確実性を排除するか」であるのに対し、定形業務では「いかに効率をあげるか」が最も重要な課題になります。
こうしたパラダイムの違いを理解せずに、
プロジェクト（非定形業務）に対して、定形業務の「効率重視」の観点を持ち込んでしまうと、プロジェクトマネジメントを誤ることにつながるため、注意が必要です（残念ながら、こうした状況は、結構見かけます💦）
1-2.プロジェクトマネジメントの目的 と プロジェクトの目的
さて、そっそくですが、
「プロジェクトマネジメント」の目的と「プロジェクト」の目的は異なるもので、一致しません。関係はありますが、同じではありません。
ところが、
この２つが混同され、
同じものであると誤って理解されている場面を散見いたします。
プロジェクトマネジメントは、
｢不確実性によってＱＣＤバランスが損なわれる｣という問題解決の手段のため、プロジェクトマネジメントの目的は常に「ＱＣＤバランス」です。
一方で、
プロジェクトの目的はプロジェクトによって様々です（業務改善や売上向上など）。そして、少なくともＱＣＤバランスそのものがプロジェクトの目的になることはありません。
したがって、
プロジェクトの目的とプロジェクトマネジメントの目的は異なるもので、一致することはありません。
ところが、
私たちは、次のような理由から、「ＱＣＤバランス」がプロジェクトマネジメントの目的であることに確信が持てず、「プロジェクトマネジメント」の目的＝「プロジェクト」の目的と、誤った解釈をしてしまいがちです。なぜこのようなことが起こるのでしょうか。
１つ目の理由は、
これらの目的と手段の関係のわかりにくさです。
私たちは普段、
目的と手段の関係はシンプルな２層構造ととらえている（思い込んでいる）ため、「プロジェクトマネジメント」の目的と、「プロジェクト」の目的、という文字面は似ていても、実は異なる目的を、なんとなく１つの同じ目的として理解してしまうことです。
具体的な内容は後述しますが、
プロジェクトマネジメントの目的とプロジェクトの目的は、シンプルな２層構造ではなく、多層的な構造になっているため、私たちは正しく理解しにくい状況となっています。
そのため、
実際にプロジェクトでやるべきタスクとその内容を決める際に、「異なる２つの目的をおいかけている」という奇妙な状態になり、私たちは実際の活動をそれぞれの目的に対して有効に行うことができません。→ このことは次項で扱います。
２つめの理由は、
ＰＭＢＯＫとアジャイルの影響です。
プロジェクトマネジメントの教書たるＰＭＢＯＫでは、
「プロジェクトマネジメントは、プロジェクトの目的に応じてテーラリングしましょう」と説明し、推奨していることです。
この説明は、
｢プロジェクトマネジメント」の目的も、｢プロジェクト」の目的に応じてテーラリングするのではないか。との誤解を招き、結果的に「ＱＣＤバランス」という、本来は変わらないはずの「プロジェクトマネジメント」の目的そのものを不確かで、危ういものにしてしまいます。（ＰＭＢＯＫに悪意はありませんが、前述のような条件が重なることで、誤解してしまう可能性があるという意味です。）
そして、アジャイルの影響です。
アジャイルの場合、
「ＱＣＤバランス」ではなく、「プロジェクトの生む価値」に重心を置いているため、ついついＱＣＤバランスをおざなりにしてもよい。という感覚を持つことになってしまいます。
結果的に、
私たちは「ＱＣＤバランス」という本来の目的に対して確信を持てなくなり、「プロジェクトマネジメントの目的=プロジェクトの目的｣、という誤った理解が優先されてしまい、ＱＣＤバランスをおざなりにすることで、プロジェクトマネジメントの本来の目的を見失っていきます。
そして、３つ目は
「どうすればＱＣＤバランスを判断できるのか」、そもそも、その具体的なやり方を私たちは教えられていないことです。
そのため、
プロジェクトマネジメントの目的が「ＱＣＤバランス」と知っているものの、具体的にＱＣＤバランスがとれていることを、どのように判断すればよいかを理解していないため、結果的に「ＱＣＤバランス」を諦めてしまったり、あるいは放置したままになってしまいます。→ このことは３章以降で扱います。
では、
私たちはどうすれば良いのでしょうか。
まずは、
｢プロジェクトマネジメント」の目的と「プロジェクト」の目的は、そもそも異なることを深く理解し、そのうえで、それぞれの関係と構造を正しく理解します。
そうすることで、
「ＱＣＤバランス」という目的に対して確信をもって取り組むことができるようになります。→ このことは次の項で扱います。
つぎに、
ＱＣＤバランスをとる具体的な方法を理解します。具体的な方法を理解することでＱＣＤバランスをとることに対して、自信をもって取り組むことができるようになり、「ＱＣＤバランス」という目的に対して確信をもって取り組めるようになります。→ このことは次の章から扱います。
1-3.目的と手段の関係と構造
ここで、
「プロジェクトの目的」と「プロジェクトマネジメントの目的」の関係と構造を正しく理解して頂くにあたり、構造を理解する準備として、目的と手段の関係と構造について、少し一般的な説明をします。
一般的に、
目的と手段は単純な２層構造ではなく、多層構造になっています。構造は、目的はより上位の目的に対する手段であり、手段はより下位の手段に対する目的となるカスケード構造をしています。
そして、
各層の手段の妥当性は、ひとつ上の目的に照らして評価されます。ひとつ上よりも上の目的に照らしては評価できません。
なぜならば、
ひとつ上よりも上の目的はここでの手段とは間接的にしか関係がなく、曖昧な評価しかできないからです。
例えば、
進捗管理や課題管理など、プロジェクトマネジメントのプロセスが「ＱＣＤバランス」に対して適切に寄与しているかどうかは、
「QCDバランス」に照らして、キチンと貢献しているか、機能しているか、評価することで判断できます。
ところが、
プロジェクトマネジメントの目的である「ＱＣＤバランス」よりも上の目的である「プロジェクトの目的」、例えば、業務改善や売上アップなどに対して照らしても、進捗管理や課題管理などプロセスが、それらの「プロジェクトの目的」に対して、適切に寄与しているかどうか、具体的に評価することはできません。
言いかえると、
自分たちのやっている進捗管理、課題管理のやり方・あり方が、「業務改善に照らして妥当か？｣と問うても、目的と手段との距離があるため、曖昧過ぎて手段を適切に評価できません
余談：目的の目的
本来、目的の目的は「手段の適切さを評価すること」です。そのため、手段のひとつ上よりも上の目的が手段を評価できないのは、「目的として機能していない」ことになります。繰り返しになりますが、手段のひとつ上の目的だけが、その手段の妥当性を適切に評価できる唯一の目的となります。
そういう意味で、
手段の妥当性を評価する場合、手段と直接つながっていない目的にはほとんど意味がありません。
1-4.プロジェクトマネジメントの目的とプロジェクトの目的の関係
上述の内容を踏まえると、
「プロジェクトマネジメントの目的」と「プロジェクトの目的」の関係と構造はつぎのように整理できます。
「プロジェクトマネジメント」は、
ひとつ上の目的である「ＱＣＤバランス」を通して、プロジェクトのスコープを実現する。
そして、
そのスコープが「プロジェクトの目的」に直接貢献する。
つまり、
「プロジェクトマネジメント」はスコープを介して、間接的に「プロジェクトの目的」に寄与する。
結果、
プロジェクトマネジメントがＱＣＤをバランスさせてスコープを実現し、スコープがプロジェクトの目的を実現する。との流れとなります（下図参照）
また、
ＰＭＢＯＫでは、プロジェクトの目的に対する価値に関する説明がありますが、それは前述の「プロジェクトのスコープ」が価値あるものかどうかが問われており、「プロジェクトマネジメント」そのものが問われているわけではありません。
余談：アジャイルの影響（少し長いです）
アジャイルの場合、価値基準を「ＱＣＤバランス」ではなく、「プロジェクトの生む価値」に重心を置いているため、ついついＱＣＤバランスをおざなりにしてもよい。という感覚を持ちがちですが、アジャイルの採用にあたっては、プロジェクトに求められる次の要件に対する留意が必要です。
それは、
プロジェクト全体のＱＣＤバランスが求められているか、です。
例えば、
「システムの維持保守フェーズで、決まった道幅の予算とリソースによって次の３か月でできることをやりましょう」というプロジェクトでは、プロジェクト全体のＱＣＤバランスは求められませんので、アジャイルで問題はありません。
ところが、
新システム開発のような、プロジェクト全体のＱＣＤバランスが求められる場合、アジャイルの採用にあたっては注意が必要です。
なぜならば、
アジャイルは、実はプロジェクト全体のＱＣＤバランスをはかるための考え方（概念）やプロセスを持っていないからです。（正確には、スプリント内のＱＣＤバランスの概念はあります。）
そのため、
全体のＱＣＤバランスが必要な場合は、アジャイルプロセスの外側で、プロジェクトマネジメントとして意識し、状況によっては必要なプロセスを補足する必要があります。
このことを理解していないと、
アジャイルプロセスの採用によって、プロジェクト全体のＱＣＤバランスを実は放棄していることに気づけないので、注意が必要です。（個人的には、プロジェクト全体のＱＣＤバランスが求められる場合は、アジャイルをベースにするのではなく、ウォーターフォールをベースに、足りない部分をアジャイルで補完する方が、相性がよいように思います）
そういう意味で、
いわゆるウォーターフォールかどうかにかかわらず、例えアジャイルを採用するプロジェクトであっても、全体のＱＣＤバランスが求められる場合は、本記事の考え方は欠かせません。
繰り返しになりますが、
プロジェクトマネジメントとプロジェクトの目的は異なり、プロジェクトマネジメントの目的はプロジェクトの目的によらず、「ＱＣＤバランス」です。
結果、いずれにしても、
プロジェクト全体のＱＣＤバランスが必要な場合、プロジェクトマネジメントの活動は全て、ＱＣＤバランスに貢献するようにデザインされていることが望ましく、そうすることでプロジェクトマネジメントは、最大の効果を上げることができます。
２.正しく扱うべきＱＣＤバランスのＱ
2-1.Ｑ＝品質のままではＱＣＤバランスの要素として使えない
プロジェクトマネジメントにおけるＱＣＤバランスにおいて、Ｑは一般的に品質とされていますが、
ＱＣＤバランスにおいて、
Ｑ（品質）とＣ（費用）がバランスするとはどういう意味でしょうか。
Ｑ（品質）とＤ（納期）がバランスするとはどういう意味でしょうか。
私たちは、
何をもってＱとＣ、ＱとＤのバランスを判断できるのでしょうか。
品質という主観的で、抽象的なものと、
費用や納期という定量的なものをどのように比較すれば良いのでしょうか。
私たちは、このことを教えられていません。
では、どうすればよいのでしょうか。
2-2.Ｑ＝成果物+品質=スコープ
実は、
Ｑは、品質を含むスコープと意味を読み替えることで、定量的に扱えるようになります。
そもそも、
品質だけが単独で存在することはなく、必ず何らかの成果物（スコープ）の品質を意味します。
そういう意味で、
Ｑは、言葉どおり品質と単純に理解するのではなく、その背景にある本来の意味を含め、成果物（スコープ）＋（成果物の）品質、と理解することで、定量的に扱えることができるようになります。
成果物（スコープ）と費用はバランスしているか、
成果物（スコープ）と納期はバランスしているか、
この条件であれば、
ＱＣＤバランスを確認できるようになります。
余談：Ｑ＝スコープ
前述では、Ｑ＝成果物（スコープ）＋（成果物の）品質と述べましたが、実は、私たちが会話する際、暗黙の条件として、すでにスコープに品質も含まれていることが多いため、Ｑ＝スコープとして実質的に問題となることはほとんどありません（下図参照）
2-3.ＰＭＢＯＫにおけるバランス要素
プロジェクトマネジメントで、バランスさせるべき要素について、実は、ＰＭＢＯＫでも、その要素はゆれています。
以下、ＰＭＢＯＫにおけるバランスさせるべき要素
・第１版（1996）：スコープ、コスト、スケジュール、品質
・第２版（2000）：スコープ、コスト、スケジュール、品質、リスク
・第３版（2004）：スコープ、コスト、タイム、品質
・第４版（2008）：スコープ、予算、スケジュール、品質、リスク、資源
※第4版では「ただし、これらの要素に限定されない」と他の要素にも含みを持たせた表現。
本書では、前述の
スコープ（Ｑ）、コスト（Ｃ）、スケジュール（Ｄ）以外の以下の要素は、次のように考えることで、プロジェクトマネジメントの目的を「ＱＣＤバランスをとること」に帰着して扱います。
a.品質：スコープに含む
b.リスク：バランスを損なうもので、バランスさせるべき要素ではない
c.タイム：スケジュール（Ｄ：納期）と同義
d.予算：コスト（Ｃ）と同義
e.資源：資源は結局コストに帰着するため、コスト（Ｃ）と同義
余談：ＱＣＤバランスのＤの意味
ＱＣＤバランスにおけるＤは、納品（Delivery）やスケジュール（Schedule）と説明される場合がありますが、バランスをはかる場合は、そのままだとわかりにくいので、納品日（Delivery date）、もしくは完了日（Due date）、すなわち「納期」の意味と理解すると、わかりやすいです。
３.見極めるべき３つのＱＣＤバランス（プロジェクト前半）
3-1.３つのＱＣＤバランス
ＱＣＤバランスのＱについて、
品質ではなく、スコープと理解することで、
ＱＣＤバランスのイメージがだいぶ沸いたのではないでしょうか。
次は、
ＱＣＤバランスとは、スコープとコストと納期のバランスであるとのおおまかなイメージを持っていただいたのうえで、プロジェクトマネジメントでＱＣＤバランスを見極めるべき３つのタイミング（すなわち、３つのＱＣＤバランス）をお話しします（下図参照：具体的な説明は後述）
3-2.１つめのＱＣＤバランス：見積もり
ひとつめのＱＣＤバランスは、
プロジェクトが始まる前の「見積もり」がそれにあたります。見積もりは、業界やテーマによらず、プロジェクト開始前にスコープと費用と納期を見積もります。幸い、ここでは、ＱＣＤバランスのＱを「品質」ではなく、「スコープ」にキチンと置き換えてＱＣＤバランスが見極められます。
結果、私たちは無意識に、
プロジェクトマネジメントの教書であるＰＭＢＯＫでは、Ｑは品質であるにもかかわらず、見積もり時はＱをスコープと理解し、「スコープ」と「コスト」と「納期」のＱＣＤバランスをキチンと見極めていることになります（これはよい話です）
ところが、残念なことに、
このタイミング以降、多くの場合、ＱＣＤバランスはあらためて見極められることなく、プロジェクトが進んでしまいます。
その理由は、
これからお話しする２つのＱＣＤバランスを見極めるプロセスに、次のような特徴があるため、暗黙知のまま形式知化されていないことにあります。
１.プロセスが必須ではない
見積もりプロセスのように必須になっていないために、あらためてＱＣＤバランスを見極めなくても、問題にならない。
２.プロセスが内面的で言語化しにくい
そのプロセスはプロジェクトマネージャー自身のとても内面的なものであり、無意識に行われているため、ノウハウが言語化されにくい。
３.プロセスが抽象的で言語化しにくい
プロセスの内容がかなり抽象的であり、プロジェクトごとに内容も異なるため、言語化が難しい。
3-3.２つめのＱＣＤバランス：ＷＢＳ １.０
ふためのＱＣＤバランスは、
プロジェクト開始早々の段階で作成する「ＷＢＳ １.０※」です。
※説明の便宜上、ここでのＷＢＳを１.０とし、次にご紹介するＷＢＳを２.０といたします。
ここでの「ＷＢＳ」は、
スコープの全量をタスクに落とし込み、タスク全量の完了日がプロジェクトの納品予定日よりも手前になること、すなわち、スコープ（Ｑ）と納期（Ｄ）がバランスすることを確認します。（費用とのバランスについては、見積もりで精査されているため、ここであらためてバランスを確認する必要はありません。）
このタイミングで作成する「ＷＢＳ」の、
目的は「不確実性の摘出と対策」によるＱＣＤバランスの確保です。
補足：見積もり時のＱＣＤバランスとの違い
見積もり時のＱＣＤバランスにも不確実性は含まれていますが、具体的な不確実性は特定されていません。
そのため、
不確実性に対する対策もタスクも織り込まれておらず、そのままの状態でプロジェクトに突入すると、不確実性に対して後手々となってしまい、いわゆる受け身のマネジメントになってしまいます。
そうならないよう、
プロジェクト開始早々の「ＷＢＳ」における「不確実性の摘出と対策」を通して、（２回目の）ＱＣＤバランスを確認いたします。
「ＷＢＳ １.０」における
「不確実性の摘出と対策」の基本的な考え方は以下の通りです。
１．ＰＭが「よし、いける！」と実感できることがゴール。
２．そのため「ＷＢＳ」はＰＭ自身が作成する。
３．タスクの粒度はＰＭが「よし、いける！」との実感を持てるイメージが湧く粒度。
４．「ＷＢＳ」におけるＰＭの❓はプロジェクトにとっての不確実性。
５．不確実性を見つけたら、いったん仮説をおいてタスクを定義する。
６．不確実性を見つけたら、不確実性の早期排除タスクを極力検討する。
７．不確実性を見つけたら、プロジェクト前半に決着させるようにする。
それぞれについて、説明します。
１．ＰＭが「よし、いける！」と実感できることがゴール。
プロジェクトにおいて、
実は、ＰＭのみが、プロジェクト全体のＱＣＤバランスを見極める役割を負っています。他のメンバーは誰もその役割を負っていません。
そのため、
ＰＭが自らＷＢＳを作成して、「よし、いける！」という実感を持つことは、プロジェクトにとって実はとても重要な意味があります。
逆にいうと、
ＰＭが「よし、いける！」という実感を持っていないプロジェクトは、誰も「よし、いける！」という実感を持っていないことになります。（意外に、そういうプロジェクトは多いのではないでしょうか）
２．そのため「ＷＢＳ」はＰＭ自身が作成する。
複数の部門からなるプロジェクトの場合、
よくある「ＷＢＳ」は、各部門から「ＷＢＳ」を寄せ集めただけで、「ＷＢＳ」作成を終了してしまいます。
実は、
多くの場合、各部門のスケジュールはそれぞれ部門のとって都合で作られているため、そのまま整合することはまずありません。
そのため、
各部門の「ＷＢＳ」を統合した全体ＷＢＳがなければ、ＰＭが実感を持つことができませんが、実際にはそれすらないプロジェクトは実際に散見されます。
繰り返しになりますが、
ＰＭが「よし、いける！」という実感を持つためには、ＰＭ自身が「ＷＢＳ」を作成する必要があります。
３．タスクの粒度はＰＭが「よし、いける！」という実感を持てるイメージが湧く粒度。
多くの場合、
プロジェクト全体のタスクは多くの場合数百から千程度で、
規模が大きいと数千になる場合があります。
では、
「ＷＢＳ」ではタスクをどの程度の粒度にする必要があるのでしょうか。
それは、
ＰＭが自信をもって「よし、いける！」と実感を持てる粒度になります。
そのため、
幾度も経験のあるタスクの粒度は粗くても想像ができますが、はじめてのタスクは粒度を小さくして、そのタスクを自分が担当した場合をイメージできるところまで砕く必要があります。
イメージが湧けば、
自信をもって「よし、いける！」と実感を持つことができます。
４．「ＷＢＳ」におけるＰＭの❓はプロジェクトにとっての不確実性。
ＰＭが「ＷＢＳ」を作成する時、
タスクを詳細化して、先行関係を定義しながらプロジェクトの道のりをシミュレーションしていくと、次々に以下のような疑問（はてな）が湧いてきます。
ＰMがイメージできていない部分、
これらこそがウィークリンク（weak link）と呼ばれるプロジェクトのほころび、すなわち排除すべき不確実性です。
あれ❓
ここ具体的にどうなってるんだっけ❓
イメージわかないな❓
あれ❓
複数領域にまたがる間にあるこのタスクって誰がやるんだっけ❓
あれ❓
ここってこんな期間でいいんだっけ❓
収まるのかな❓
あれ❓
これってどのような方式で実現するんだっけ❓
あれ❓
この実現方式って実現性あるんだっけ❓
などなど・・・・・
それらのひとつひとつがプロジェクトにとっての「不確実性」で、そうした疑問（はてな）に気づきながら、始まりから終わりまでの全てのタスクをＷＢＳに落としこんでいくこと自体が「不確実性の抽出」にあたります（ほとんどのプロジェクトでは、ここから先のプロセスがほとんど実施されていません）
５．不確実性を見つけたら、いったん仮説をおいてタスクを定義する。
不確実性を見つけても、
大抵の場合はやってみないとわからないことが多く、「ＷＢＳ」を作成する際に明確にできることはあまりありません。
そのため、
不確実性を見つけたら、いったん仮説をおいて（「やってみないとわからないけど、いったんこのやり方と仮置きしよう…」など）ＷＢＳを作り切ります。
そして、
仮説はプロジェクトがはじまったらできるだけ早く、結果が良くも悪くも早めに明確にできるように、「ＷＢＳ」における該当のタスクを前倒しします。これが、「不確実性の対策」です。
６．不確実性を見つけたら、不確実性の早期排除タスクを極力検討する。
「タスクの前倒し」
これこそが摘出された不確実性に対する最善の対処です。
コストの追加も必要ありませんし、納期の延長も必要ありません。
繰り返しになりますが
「タスクの前倒し」は、見積もり時に見極めたＱＣＤバランスを崩すことなく、実行できる不確実性に対するもっとも有効で、最大の打ち手となります。
そして、
ＰＭが「ＷＢＳ」作成時に「タスクの前倒し」を織り込めるかどうかが、プロジェクトの目的であるＱＣＤバランスにとって、とても重要な意味があります。（逆にいうと、ここで「タスクの前倒し」を織り込めなければ、プロジェクトのＱＣＤバランスはとても難しくなってしまいます）（下図参照）
７．不確実性を見つけたら、プロジェクト前半に決着させるようにする。
プロジェクトに潜む不確実性は、
「タスクの前倒し」によって、できるだけプロジェクト前半に決着させることが重要です。
なぜならば、
プロジェクトが進むと「ＷＢＳ」作成時には想定できなかった「課題」が必ず発生します。
ここでの「課題」とは、
ＱＣＤバランスを脅かすもので、発生したらＱＣＤをバランスさせることがとても難しくなってしまいます。
そのために、
はやめはやめに当初の不確実性を決着させ、プロジェクトの前半が終わるタイミングで、つぎの３つ目のＱＣＤバランスを見極める必要があります。
このＷＢＳ １.０によるＱＣＤバランスの見極めは、
ＰＭ自身が「不確実性の摘出と対策」を通して、「よし、いける！」という実感を持つ、プロジェクトにとってとても重要なプロセスであり、肝の部分となります。
3-4.３つめのＱＣＤバランス：ＷＢＳ ２.０
さて、
プロジェクトにおける最も大きな不確実性はなんでしょうか。
それは、
スコープの「実現方式」です。
具体的な内容は後述いたしますが、
実現性の裏付けのある「実現方式」が決まるとプロジェクトにとっての不確実性は大きく排除されます。
そのため、
その時点であらためて「ＷＢＳ」をＷＢＳ ２.０として見直し、ＱＣＤバランスを見極めます。（補足：できれば、タスクの前倒しによって、不確実性が排除される都度にＷＢＳを見直してきていることが理想です）
そして、
このタイミングで、実現方式の実現性の裏付けがとれた高い角度でのＱＣＤバランスを確立しておくことで、その後に発生してくるＱＣＤバランスを脅かす課題に備えます。
では、
「実現方式」とは、いったいどのようなものでなのでしょうか。
「実現方式」とは、
どのようなパーツを、どのように組み合わせてスコープを実現するかという実現のしかたのことを指します。
具体的には、次のような例があげられます。
イベントについて、
プロジェクトの関係部門がどのような役割を担って、どのように連携してそのイベントを実現するか。
新サービスについて、
プロジェクトの関係部門がどのような役割分担で、どのように連携して、そのサービスを実現するか。
新システムについて、
プロジェクトの関係システムのうち、どのデータとどの機能を使って、どのように連携させてシステムを実現するか。
こうした実現方式の実現性をプロジェクトの前半で裏付けをとり、決めきることで、ＷＢＳ ２.０では高い確度でのＱＣＤバランスの確立をはかり、後半はＱＣＤバランスを脅かす課題に早め早めに対応することで、ＷＢＳ ２.０で確立したＱＣＤバランスの継続・維持をはかります。
余談：実現方式を決める意味
実現方式を決めることで、部門間やシステム間の調整事項（不確実性事項）は、ほぼほぼ決着済みとなり、以降はそれぞれの部門、それぞれのシステムの中で、単独で仕様やタスクの詳細を決めていくことができるようになります。言い換えると、実現方式が決まるまでは横の調整が必要ですが、実現方式が決まったら横の調整は不要となります。一方で、もし実現方式が決まらないままだと、いつまでもコストのかかる横の調整が続くこととなり、課題に対する対応が疎かになるため、ＱＣＤバランスを確保するタイミングを逸することになってしまいます。
余談：実現方式の実現性確認プロセスの前倒し
システム開発プロジェクトの場合、実現方式は、要件定義のあとの設計工程に委ねられることが一般的ですが、実はユーザ部門と開発部門が協調する要件定義と同時並行で実施し、要件定義完了時には、実現方式の実現性確認を同時に完了させることが望ましいです。ある意味で、設計工程のタスクの中から、実現方式の仮説づくりと、その実現性検証という大きなタスクのかたまりを取り出して「前倒す」ことが、プロジェクトの成否を大きく左右することになります。
４.維持すべきＱＣＤバランス（プロジェクト後半）
4-1.課題管理の意味
プロジェクト前半は、
不確実性の早期排除と実現方式の実現性を確認し、ＷＢＳ ２.０によってＱＣＤバランスを高い確度で見極めることが活動の中心でした。
そして、
プロジェクト後半は、その見極められたＱＣＤバランスを維持することが活動の中心に移っていきます。（こうしたプロジェクト全体の枠組みの理解がなく、いつまでも不確実性を放置すると、プロジェクト後半になってもＱＣＤはバランスしないままプロジェクト納期を迎えることになりますので、注意が必要です。）
ＱＣＤバランスを維持するにあたっての基本的な考え方は次のとおりです。
１．課題とはＱＣＤバランスを脅かすもの
２．課題解決はできるだけ早く（期限はＡＳＡＰ）
３．解決できる課題量は、解決余力✖️時間
４．同時に対応できる課題は１０〜２０程度
５．特に部門またがりの課題に注意
それぞれの考え方を次に説明します。
１．課題とはＱＣＤバランスを脅かすもの
課題とは、一般的に様々な意味を持ちますが、プロジェクトマネジメントにおける課題とは、「ＱＣＤバランスを脅かすもの」です。（ＱＣＤバランスを脅かすにあたらないものは、シンプルにＴＯＤＯだったり、ＡｃｔiｏnＩｔｅｍとして扱います）
２．課題解決はできるだけ早く（期限はＡＳＡＰ）
プロジェクト定例において、課題解決を議論する際、「この課題は、いつまでに解決すればよいですか❓」とか、「後続タスクの開始が⚪︎⚪︎なので、それまでに解決すればよいですか❓」などの会話される場合がありますが、プロジェクトマネジメントにおえるＱＣＤバランスの確保、維持、との観点ではいずれも誤りです。
正しくは、
プロジェクト前半で確保したＱＣＤバランスを脅かす課題の解決期限は、内容によらず、常にできるだけ早く（ＡＳＡＰ）になります。
なぜならば、
発生した課題は、ＱＣＤバランスを脅かす不確実性であり、あらかじめ定量的に完了期日の目処を立てられないものばかりだからです。
つまり、
完了日は解決を終わるまでわからないものばかりなので、とにかくできるだけ早く解決することがＱＣＤバランスを維持できる可能性を高める唯一の戦略となります。
３．解決できる課題量は、解決余力✖️時間
課題解決期限がＡＳＡＰでなければならない理由がもう１つあります。
それは、
プロジェクトが解決できる課題の量は、解決にあてられるプロジェクトの工数余力✖️プロジェクトの残存期間に依存するためです。
ここでの工数余力とは、
プロジェクト完了に必要なタスクが割り当てられていない工数（大抵の場合、ＰＭ、ＰＭＯ、各領域リーダーなど）のことです。
プロジェクトの進捗に影響を与えずに、課題を解決するにはこれらの工数余力を解決余力として、課題に振り向けることになるため、結果的にプロジェクトが解決できる課題量は、解決余力✖️（プロジェクトに残された）残存時間となります。
実は、
意外にこのことをプロジェクト全体で理解しているプロジェクトはあまり見かけません。そのため、前述のような「この課題はいつまでに終わらせればいいですか❓」との会話が常態化し、むだに残存時間を消費してしまい、結果的に課題の解決量を減らしてしまっています。
４．同時に対応できる課題は１０〜２０程度
前述の内容の一部繰り返しになりますが、
大抵の場合、解決余力はプロジェクトを通して、一定のため、プロジェクトが同時に取り組める課題は１０〜２０程度が限界です。
特に、
プロジェクトとして管理すべき課題は領域またがりの課題となりますが、領域またがりの課題の場合、横の調整が発生するため、解決には工数も期間も必要となるため、極力短い期間で、できるだけ早めの解決が必要となります。
５．特に部門またがりの課題に注意
各領域内にとどまる課題の場合、
課題解決はそれぞれの領域の管理に委ねればよいですが、領域またがりの場合、ＱＣＤバランスを脅かす課題が発生していることに、それぞれの領域メンバーは気づきにくい、という問題があります。
そのため、
全体のＱＣＤバランスの責任を担うＰＭが（あるいはＰＭＯ）が、ＱＣＤバランスを脅かす事態が発生していないか、との観点でプロジェクトを観る必要があります。
こうした考え方を理解し、
プロジェクト後半でははやめはやめの課題解決を通してＱＣＤバランスを継続・維持します。
余談：課題解決量の限界
課題解決量の限界の理由には、前述の解決余力✖️時間の他に、もう一つ理由があります。それは課題解決にあてられる会議の時間です。多くの場合、全領域の集まる定例は週次で１時間程度ですが、全ての時間を課題解決にあてることができたとしても、１つの課題につき５分とすると、一度に１２前後しか議論できないことになります。いずれにしても課題はどんどん解決して、同時に取り組まなければならない課題数が常に余力ないに納める努力が必要です。
4-2.進捗管理の意味
ＱＣＤバランスの確保との観点によれば、
進捗管理の目的は、前述の課題（＝ＱＣＤバランスを脅かすもの）を摘出することが目的です。
具体的には、
進捗の遅延がＱＣＤバランスを脅かすものとなります。
そのため、
必要な報告は、進捗が報告日時点で完了している進捗に対して遅れているかどうか、そのリカバリーは可能なのか、あるいはＷＢＳの見直しが必要なのか、になります。
余談：進捗報告
前述の通り、遅延がなければ進捗報告は不要です。よく、「タスク⚪︎⚪︎はいつからいつに実施の予定です。」とか、「タスク⚪︎⚪︎は予定通りに完了しました。」との報告がありますが、ＱＣＤバランスとの観点においては、不要です。
4-3.課題解決の足枷
ここまでの説明にあったように、
不確実性や課題に対するもっとも有効で、唯一の戦略は、「前倒し（できるだけはやく）」です。前倒し戦略がプロジェクトの最初から最後まで貫かれることで、ＱＣＤバランスは確立され、維持されます。
にもかかわらず、
プロジェクトにはこの「前倒し」の足枷になるものがあります。それはなんでしょうか。
それは、
プロジェクトを構成する各部門の無意識の不作為（さぼり）です。
プロジェクト全体としては、
できるだけ不確実性や課題を排除することが望ましいですが、各部門にとってはタスク期限は遅ければ遅いほど、自分たちの組織にとってはありがたいことになります。
メンバーに悪気はないし、
プロジェクトに貢献しようとの心構えもありますが、無意識に人事評価を伴う所属部門の都合を優先してしまうのは、機能別組織のもつ宿命です。
この問題の解決については、また別の機会に委ねようと思います。
おわりに
最後までお読みいただきありがとうございます。
ＱＣＤバランスの達成に必ず必要にも関わらず、意外に知られていない基本的にな考え方について、説明してまいりました。
ざっくり整理すると、
基本的な考え方全体の大きな枠組みはつぎの4つになります。
１．プロジェクトマネジメントの目的の深い理解
まずはプロジェクトマネジメントの目的とプロジェクトの目的がちがうこと、プロジェクトマネジメントの目的は常にＱＣＤバランスであることを深く理解すること。
２．Ｑの意味の深い理解
Ｑは品質ではなく、品質を含めたスコープと正しく理解すること。
３．３つのＱＣＤバランスの見極め
まずは見積もりで大まかなＱＣＤバランスを見極める。次に、
初回のＷＢＳ（１.０）作成時に、ＰМ自身が「あれ？ここどうなるんだっけ？」と思うところを洗出し（不確実性の摘出）、それらに対する対策（前倒し）をＷＢＳにキチンと織り込むことで、スコープ（全量タスク）と納期（ＷＢＳの完了日）のバランスを見極め、ＰМ自身が「よし、いける！」という実感も持つ。←アナログですが、ここがプロジェクトマネジメントにおいてＱＣＤがバランスする瞬間なのです。
そして、
プロジェクト前半（システム開発では要件定義が完了するまで）に、
プロジェクトにとって最も大きな不確実性であるスコープの実現方式の実現性確認という大きなタスクの前倒しによって、実現性が確認された後のＷＢＳ ２.０で高いレベルの確度でＱＣＤバランスを見極めること。←これがプロジェクト後半におけるＱＣＤバランスの起点となります。
４．ＱＣＤバランスの維持
上述のＷＢＳ ２.０で見極めたＱＣＤバランスを受け、
プロジェクトの後半では、そのＱＣＤバランスを脅かすもの、すなわち課題を課題解決余力（解決余力×時間）に収まるように解決していくことで、最後までＱＣＤバランスを維持した状態でプロジェクトの完了を迎えられるようにします。
そして、ここで意識すべきは、
課題は完了する目途がわからないものばかりのため、問題解決余力の要素である時間を無駄にしないよう、常に課題解決期限はできるだけ早く（ＡＳＡＰ）すること。となります。←ここまでの仕掛け（プロジェクトマネジメントの基本的な考え方の枠組み）が全体的に機能することでプロジェクトのＱＣＤバランスが成立します。
これらの基本的な考え方は、
全体が構造的に機能することでプロジェクトマネジメントの目的であるＱＣＤバランスを実現するため、いずれの考え方が欠けてもＱＣＤバランスは成立しません。（正確にいうと「成立する可能性が著しく低くなります」）
とはいえ、
これらの考え方を実際のプロジェクトで実現することは、意外に大変です。その場合、できていない部分にはプロジェクトのリスクが必ず潜んでいる。という意識をもてる。という意味でも、今回ご紹介した考え方がお役に立てると嬉しいです。
今回の内容は、
昨年秋にnoteにマガジンとして投稿した内容のうち、必要最小限の要素をまとめてみましたが、初版でいたらないところもたくさん残したままですが、いったん公開いたします。
抽象的な内容であるため、わかりにくい部分がたくさんありそうですが、普段無意識にやっていることなので、なかなか自分では気づきにくい表現や説明があるとおもいます。
私にとっても勉強になりますので、是非遠慮なく、ご指摘いただけるありがたいです。どうぞよろしくお願いいたします。
長文、おつきあいありがとうございました。