某所で「PMBOK は科学的根拠がない」という話をしたけど、そこは経験則に沿うところが多いからだ。だからマネジメント自体が経験と勘が重要視される。たぶん AI に期待が大きいというのもそこかも。
だから、物理法則と統計を利用して不確定性を確率として扱えばよいだろう、という話が先に続く。— Tomoaki Masuda (@moonmile) 2018年10月23日
PMBOK に科学的根拠がない、というのは「知識体系」として網羅はしているけれど、そこに数学的な根拠とか確率の話がでてこないからだ。何をもってして「プロジェクトの成功」を決めるのかは実はそれぞれなんだけど、プロジェクトの最初に QCD（機能、コスト、納期）を決めておいて、
- プロジェクト終了時に要件や機能を満たしている
- 予算/コストをオーバーしていない。
- 納期が守られている
ということをプロジェクトの「成功」と仮定してよいだろう。実際のプロジェクトは時間とともに変化することが多いから、プロジェクトの最初に決めた「要件」がプロジェクト終了時に満たされていたとしても、時間の差からニーズにあっているかどうかは分からない。これは建築業界でもあることで、計画時に綿密に設計をしたとしても建築物自体ができあがるのはタイムラグがあるから出来上がったときには時代のニーズから外れている（あるいは流行おくれになる）というパターンも多い。公共物を建てるときはどうしてもその矛盾に立ち向かわないといけないし、ニーズ自体が進行中に代わっていくことに追随するためのアジャイル開発手法もあれば計画に沿うかたちで進める計画駆動もあれば（特に建築物は途中で変更が効かないことが多い）それは業界や最終的な利用者（ステークホルダー）に合わせて変化するしかない。
プロジェクト完成時に顧客のニーズを完全に解決することはできない
極端な話、プロジェクトというのは時間の概念から離れることはできないので、計画時の利用者ニーズと完成時の利用者ニーズは変わる可能性がある。車のように購入してすぐに使う、既製服のように吊るしを買う、という場合には買ってから使うまでのタイムラグが短いから差はあまりでないのだけれど（それでも、使ってみたら「思ってたのと違った」パターンがあるのだけど）、プロジェクトの場合は一回性のものでもあるから、ぴったりとはいかない。逆にいえば、「完全に解決する」ことは不可能なので、「おおむね解決できる」という矛盾に立ち向かわないといけない。
プロジェクト開始時の要件や機能（プロジェクト途中の変更も含めて）の規定は、顧客との契約と同時に、作る側としては開発規模を確認/確保するために必須な作業であったりする。が、契約という行為がプロジェクト開始前にある以上ずれが必ずでる。
- 顧客視点からすれば、プロジェクト開始前に契約して予算が分かることが望ましい
- 開発視点でいえば、プロジェクト開始時（要件、機能の定義前）に規模はわからない
という話もあり、先のプロジェクトの QCD を決めようとしても矛盾だらけになる。それでも何とかするのがプロジェクトマネジメントの役目だったりする。逆にえば、この「なんとかする知識体系」が PMBOK の根底にはある。
極端な話をすれば、プロジェクトの予算や納期は、プロジェクト終了時点で明確になる。
イメージを描くとこんな感じになる。プロジェクト開始時には予算/コストは、上下大幅なずれがあり分布している、当然のことながらプロジェクト終了時には、コストは確定しており納期も確定している。
この上下のブレは、もしプロジェクトが複数あったらという確率の話であるが、実際はプロジェクトは一回こっきりなので、この予算や納期をどうやって予測するのか？というのが PMBOK のプロジェクト計画になる
プロジェクトの予算や納期は分布している
個人にとっては１回こっきりのプロジェクトなのだが、会社にとって複数のプロジェクトが動いていれば、赤字もあり黒字もある、納期遅れもあれ納期より早いものもある。コストが増えたものあれば予算内でおさまったものもある。つまり、複数のプロジェクトでみれば、コストと納期は分布していると言える。
プロジェクトが納期/コスト通りに終わる確率は、正規分布なのかカイ二乗分布なのか色々憶測があると思うが「分布」があることが変わりない。少なくとも目標値の前後に広がりがある。
実際のところ納期よりも前にプロジェクトが終わることは稀（これには理由がある）なので、納期遅れが頻発するので適当な指標が必要になるが、大雑把いえば、次の図のように「本来の納期」から遅れが生じたとしても８割の確率で納期遅れが発生しない時点を、プロジェクトの開始時に「納期」として提示すればよい。
この部分を80%ラインに置くのか、95%ラインに置くのかは色々だが。納期遅れがシビアな場合は95%が望ましいし、会社の赤黒だけを考えれば8割方プロジェクトが成功するならばまずまずの成績と言える。
この「本来の納期」と80%ラインである顧客に提示する「納期」との差は「保険」と呼ばれ、プロジェクト計画時のマージンとなる。よく言われる「計画時の1.5倍すると大丈夫」というのがそれになる。この確率の話は、CCPM には書いてあるんだけど、PMBOK には出てこない。逆に言えば、どんなに WBS をしっかり作ったとしても納期やコストは分布（ひろがり）を持つので、納期ぴったりに終わる確率は極めて少なく、納期前に終わる確率は50%となる。
じゃあ、なんでプロジェクトは納期通りに終わるのか？というと、納品日に合わせて人が努力をしているからだ、と言える。遅れ気味になったら努力をして残業をして納品日にあわせようとするし、逆に早すぎる場合は待ちの時間を入れて納品日にあわせようとする（早めに納品したりしない）。極端な話、努力の余地がないサイコロを振って出た目だけ進むプロジェクト（実際に CCPM の解説として使われる）の場合は、納品日が前後する。当たり前だ。調節の余地がないからだ。
なので、プロジェクトは実際のところコストや納期に関しては分布を持つので、ぴったりとした値にはならない。というのが、科学的な根拠である。
プロジェクトの QCD はどのように分布するのか？
Q（要件や機能）は分布するのか？というと、まあアジャイル開発の例もあるし、先に書いた時間とともに顧客のニーズ自体も変化するので、実は QCD そのものが分布し、広がりを持つ。
さて、ここの80%成功ラインだが、最初のグラフを参照すると「プロジェクト終了時」には納期が決定している（納品しているから当たり前だ）。当然、コストも一意に決まる。
これを確率のグラフと重ね合わせると、時間とともに青線の分布が、オレンジ色の線の分布と変わってくる。80%ラインも時間とともに中央に寄って来る。つまり「本来の納期」に収束するように動く。
これが何を意味するかと言うと、プロジェクトが進行する（時間が経つ）に従って、未確定なものが確定となるので不確定部分は減り、分布が狭くなることを意味している。当たり前といえば当たり前。前に進めば進んだだけゴールに近づいている、ということを示している（なんだかよくわからない例えかもしれないが）。プロジェクト開始時点では未確定であったものが、プロジェクトを進めることにより確定に代わるので、分布が絞れるという形になる。
これを逆に発想すると、プロジェクト開始時に未確定な部分に対して「仮に確定事項」を与えてやれば、分布は絞られる、という話になる。そう、事後分布の話と同じだ。PMBOK とか品質システムで言えば、事前にリスクを抽出しておいてそのリスクが発生したときいどうなるのか？対処はどうするのか？ということを考えておくことにあたる。
そこで、もう少し話を進めると、この未確定事項（リスク管理でもいいし QCD の各項目でもよい）が決定したとしてシミュレーションをすれば、プロジェクトの成功確率を逆算できるのではないか？というが仮説である。また、プロジェクトが進行するうちに未確定事項やリスク項目が減ってきたら、それを確定として再びシミュレーションすれば、プロジェクトの成功率を再計算することが可能になるだろう。
このあたりの発想は、もともと CCPM にあるのだけど、ベイズの定理をあてはめて後はシミュレーションによって求めようというのが自説。実際、プロジェクトシミュレーションの話は、ワインバーグ氏やデマルコ氏のシステムダイナミクスの話にも出てくるし、TOC でも出てくるので、古くからある考え方だと言えるだろう。この続きは、また後日。
