今知ってほしいプロジェクトマネジメントのもう一つの世界観 ~予測型と経験型~
主張
ソフトウェア開発prjがなかなかアジャイルにならないのはなぜかなぁと考えてみた。 昨今、エンジニアにおいては、知識としての共有の機会も増えているし、実際に経験済み、習慣化済みになってきているように思う。要は「しっくり」くることが多いのだと思う。 しかしながら、現実のprjが経験型のアプローチ(アジャイル)を取ることはまだまだ少ない。この要因として、エンジニアと協業する他のメンバー、あるいはprjの利害関係者(組織の上層部を含む)が予測型の進め方を望むからではないか、と感じている。
というわけで、エンジニアと仕事をするエンジニア以外の人に伝えたいと思い、書いてみる。そのためにはおそらく、アジャイル開発、スクラムのプラクティスがどうこう、というよりは、プロジェクトマネジメントの世界観として語る方がよいかというのが本稿。エンジニアとして、抽象的な「しっくり」の言語化にもなればよいと思う。最初に主張のサマリ。
- 以下の分野において
- 無形のモノ。ソフトウェア、サービスの分野
- 比較的少人数(〜10人程度)で１つのモノ、事業を作ることができる分野
- 外界の変化も激しく、予測が難しい分野
- 以下の状況
- 意思決定者が近くにいて、利害の一致度合いが高い状況
- メンバーができるだけ、「専任」で取り組める状況
- である場合に有効。限定的なように聞こえるが、昨今こういうprj環境は多いと思う。また、モノ作り以外のprj(事業開発や社内改善など)でも応用できると考える。
また、
- 予測型プロセス(後述)を否定するものではない。予測型プロセスが適する状況も多い
- 完了状態と完了までに必要なタスクが明確な状況
- 数週〜数ヶ月で完了する見込みがあり、その間の外界の変化にあまり左右されない状況
- または、何がなんでもやりきるしかない状況
- 前述の分野、状況が当てはまらない環境(特に大規模開発)については今回はスコープ外。
- 後述するが、役割分担の効用が大きい大規模prjにおいて、それをトレードオフすることによって得るものがバランスするかについて私に知見がない。
という点を最初にことわっておく。
プロジェクトマネジメントの王道＝予測型プロセス
ウォーターフォールといったプロセスや、ガントチャートといったツールに代表されるプロジェクトマネジメント手法。
特徴としては、プロジェクト開始時点で、しっかり予測し、計画すること。
タスク(ここでは仕様や要求や要件や設計も含んだ総称)と言われるものを予め確定し、 タスクの前後関係や、タスクの消化に必要な時間を予測し、プロジェクトを計画する。 タスクの管理表を作成し、完遂状況を元にプロジェクトの進捗を把握し、管理する。 または、プロジェクトの前半(要件定義フェーズ、上流工程などと呼ばれる)で、タスクの量と期日までの完了を天秤にかけながら、タスクの量を調整する。
こうやって、プロジェクトの未来を予測し、計画と実績との差異を追いかけることで管理するのが、予測型プロセスの特徴。
力学①：なぜプロジェクトはそんなに時間がかかるのか
突然だけど、よくある話。
- 「ご要望の要件ですと、このプロジェクトには10ヶ月必要です」「えー、そんなにかかるの？！」
- (プロジェクトが開始して数ヶ月後に)「O月O日にリリースしたいのでしたら、どれかの要件を削る必要があります」「えー、話が違う！？」
なぜprjはそんなに時間がかかるのだろうか。それを理解するためには、prjが抱える不確実性を理解する必要がある。
知識：不確実性コーン
by Scrumと組織
これは、不確実性のコーンと言われる図。世の中想定どおりいかないことだらけ。
- prj初期では、0.25x(4分の1)から4x(4倍)という誤差
- 工程が進むと誤差は小さくなる
- 詳細に設計しても0.9xから1.1xの誤差
- 6ヶ月のprjなら、詳細に設計が完了するのは2ヶ月くらい経った時点だろうか。この時点でも、2週間以上の誤差が発生しうる。
初期に見積もる(完了を予測する)ためには、不確実性を吸収できる充分なバッファを確保する必要がある。 とはいえ、4xもの期間を提示することは現実的に無理(失注かprjの白紙撤回になってしまう)なので、許容されうる最大の見積もりを提示することが多い。 または、先にprjに着手することを説得する。
- 概算見積もりと詳細見積もりに分ける
- 設計フェーズのみの着手を取り付ける
- など
まさに、PMの度量と交渉力の見せ場！(この是非はここでは触れない)
知識：不確実性
何度も出てくる「不確実性」これは一体何なのか。一言でいうと、確率論的な性質。 あるタスクに対して、それが完了するまでに必要な時間を計る。そのタスクを100回、1000回実施すると、完了までに要した時間は正規分布になる(はず)。習熟を考慮に入れず考えるには、100人、1000人が1回ずつ同じタスクに取り組んだと考える方がイメージしやすいかも。 現実では、1人が1回タスクを担当することしかないので、こんな状況は発生しえないのだが、思考実験として考えてほしいし、突き詰めるとそういう性質がある、くらいで考えることができれば充分。 そして、この完了までに要した時間のバラつきは、タスクの中身に依存するし(似たことを取り組んだことがあるなら誤差は小さく)、タスクの大きさにも依存する。
あるタスクに取り組む時に、「予想以上にかかった」、「意外にすんなり終わった」ということは経験あるはず。 なぜなら、たいていのタスクは「すでにやったこと」ではなく、つまり不確実性を含むから。 不確実性のコーンの話も相似的に当てはまるが、本質は同じ確率論的な性質。
この完了までに要した時間のバラつきを積み上げると、「ある時点でタスクを終えることができる確率」と考えることができる。
さて、もう一つ、よくある話。
- あなたはPMからあるタスクに必要な時間の見積もりを質問された。
- あなたは答える「どこかでつまづくかもしれないので答えられません」あるいは「この部分まで進めばあとはやるだけなんで先に調査に着手させてもらえませんか」
- PMは言う「いや、今の時点での見積もりでいいから」「今見積もらないと計画できないんだよ」
- あなたは、時には不承不承ながらも「この時間があれば、ほぼほぼ確実に終えることができる」工数を答えないだろうか。
知識：90%見積もり
「この時間があればほぼほぼ確実に終えることができる」工数見積もり＝90%見積もり、と呼ぶ。 ということは、裏返すと、たいていのケースでは見積もり以内で終わるということ。余った時間は「確率論的なバッファ」の位置付けとなる。 この90%見積もりで、計画を立てていくとどうなるか。 意図して「予備の時間」を取るわけではないのだが、そこには確率論的なバッファが発生する。そしてこのバッファを各工程に含んだ計画が作成される。これは、prjの計画をかなり長くする方向に働く。
つまり「prjは時間がかかる」のだ。 無理な見積もりを要求するPMが悪いんじゃない。みんな苦しいながらも”予測”しようとしているのだ。
力学②：なぜプロジェクトは遅れるのか
もうひとつ不思議なことがある。「prjは遅れる」。必ずではないが、早く終わることよりも遅れることが圧倒的に多い。その力学について触れる。
知識：90%見積もりと学生症候群
前述のように、prjは、各タスクが90%見積もりによって見積もられ、計画される。 えてして、タスクは早く終わることもある。(むしろ確率的には大半が見積もりよりも早く終わる。)
この時、タスクの担当者は残りの時間をブラッシュアップに充てる。
- 不具合がないことを確認する
- パフォーマンスを考えてチューニング
- メンテナンス性を下げないようにリファクタリング
それにより、残りの時間(元々は確率論的なバッファー)は消化される。これを学生症候群という。 元来は、もう少しサボりの意図も含んでいる(締め切りギリまで着手しない的な)表現なのだけど、「ブラッシュアップしたい」、が本質だと私は考える。
早く終わった場合のバッファは消化されがちなのでprjは早まらない、一方で90%見積もりの時間でも確率論的に完了しないことは発生しえて、その場合prjのスケジュールは遅れる。
つまり、prjが遅れる方向に力が働きがちだ。
対策：TOC-CCPM
ソフトウェアの世界はせいぜい30年ほどの歴史しかないが、先人たちもこの状況を黙って見ているわけはない。 ここまで説明してきたことがらは、「ザ・ゴール」の制約理論(Theory of Constraint)をプロジェクトマネジメントに応用したTOC−CCPM(critical chain project management)という考え方で説明されていることを再解説しただけ。ではあるのだけど、非常に本質を捉えやすくしてくれるパワフルな考え方だと考えている。
このprjの力学を変えるための方法論は非常に有用で、予測型プロセスでprjに取り組む場合には、ぜひ参考にしてみるとよい。この話はまた別途触れたい。
考察：確定することの大変さ
ここまでは、prjに働く力学を主に不確実性の面から見てきた。 もう一つ、予測型プロセスが本質的に抱える困難として、「確定することの大変さ」をあげたい。
なぜ「使われない機能」が実装されるのか
ここには２つの理由がある。 １つは確定することの難しさ。「確定された」仕様の中には、仮説も多く含まれている。「この機能が求められているはず」。仮説の一部に期待というものもある。「ユーザーにこう使ってほしい」。どちらも仮説でしかない。使われるかどうかは提供してみないと分からない。つまり、「使われなかった」が一定確率で発生する。
もう１つは「どうせ〜ついでに」。prjは長い。今考えている仕様が実装されてくるのは数ヶ月後、半年後。実際に動くモノを手にするまでの時間、これをリードタイムと呼ぶが、この長いリードタイムの中ではとりあえず要望しておかないと(＝仕様に織り込んでおかないと)いつまで経っても手にできない。よって「どうせ手がけるならついでにこれも」となる。
この２つの要素が絡み合って使われない機能が実装されていく。
何が課題なのか
- 不確実性を含むものを予測し、管理しようとすることの難しさ
- 確定しきることの難しさ
prjが抱えるこの2つの困難に正面から向き合ってコントロールしてきたのが予測型プロセス。しかし、そこにはトレードオフになるオーバーヘッドとロスが存在する。それでも、予測型プロセスが多く用いられる理由はなんだろうか。
- 計画を立て、その進捗を刻みながら進むことの安心感。グリップ感。
- prjを管理する人にとって、この安心感はなにものにも変え難い。また次の項目のコミットメントと相乗効果がある。
- 利害関係とコミットメント
- お願いする人と作る人の間に会社の境目(受発注の関係性)が発生することは非常に多い。それだけで利害関係が発生するとは言わないが、会社の境目(会社間の契約関係)があることで、コミットメントを明確にせざるを得ない。
- この時のコミットメントは「完遂」になるのが一般的。発注するからには、その期間＆その金額で完遂してくれなくては困るし、完遂しなくてはならない。
- 会社間の境目でなかったとしても、そういう関係性になることは多い。部門間などでも発生しうる。
- 大人数のprjと役割分担
- これもまた一因。prjが大きくなると、役割分担が進む。
いろいろな困難はあるけれども、この確立されたプロジェクトマネジメントの世界観はやっぱり偉大。 さて、どういうパラダイム転換で臨むのか。
提案：経験型のプロジェクトマネジメント
パラダイム転換
経験型のプロジェクトマネジメントを考えるにあたって、これまで正面から向き合ってきたことのいくつかを受け容れ、その代わりに新たな何かを得ることが必要。
- 全体を予測して管理することをやめる
- 受け容れること
- 全体に対する現在位置・進捗が分からないこと。その不安感
- 代わりに得ること
- 見通しは分かる
- その時その時のベストに向かって進むこと
- 受け容れること
- 期日までの完了をコミットする/してもらうのをやめる
- 受け容れること
- 最初に予定したとおりの完成物ではないこと
- チームのベストエフォートをコミットする/してもらう
- 代わりに得ること
- 小さく反応を見ながら軌道修正できる
- 使われない機能を減らせる(かもしれない)
- 受け容れること
- 役割分担による効率の追求をやめる
最後にこのパラダイムを、重視するコンセプトの視点で並べ直す。 そして、これらのコンセプトが経験型のプロジェクトマネジメントのキモになっていると考えている。 それぞれの詳細は、また別稿で。
対案①：頻繁な軌道修正
確定することが難しいなら、確定する量を減らし、リリースのサイクルを早め、フィードバックを元に、頻繁に軌道修正をすることで対処しよう。 これにチームのリズム、ペースメイクを加味したものがイテレーション。
対案②：遠い未来の予測は避け、経験から推測する
未来のことになればなるほど不確実性がもたらす影響は大きくなる。であれば遠い未来は大まかにしか見積もらないことで対処しよう。 近い未来(今日、来週)の計画だけ精緻であれば今プロジェクトを進めるには充分。
一方で、経験＝過去(昨日、先週)にprjをどれだけ進められたか、は確実な情報。 過去のデータが貯まるほど、それに基づく見通しは精度が上がっていく。
対案③：それぞれが考える
確定する量＝一回の作業量が小さくなると、必然的に関わる1人1人の守備範囲は広がる。そもそも、役割分担は、規模の経済の産物。小規模で役割分担をするのは不経済。つまり、役割分担をしないことで対処しよう。
対案④：計画＜振り返り
対案①、②を支える習慣として、振り返りによる自己フィードバックを重視しよう。
