下流でのプロジェクト管理を上流でやらないほうがいい理由、あるいは不確実性にまみれた世界

2,3年前にUdemyさんで、変革プロジェクトをリードする方法論について合計24時間のシリーズ講座を発表した。
いま講座の一つを見たら受講生が2万人を超えていたので、それなりの人気コンテンツの様だ。
基本的にこれまで書いた4冊ほどの教科書を整理し直したもの（書いた順番により、複数の教科書をまたがった説明もあるので）。ただ、もちろんこれを機に新しく追加したテーマもある。今日はそれを一つ紹介しよう。

事業会社であれ、SIerなどの外部サービス提供者であれ、システム開発の経験は豊富で、ある程度ノウハウも整理されている。一方で僕らが上流と呼んでいる工程（一般的に上流と呼ばれる要件定義よりも更に前にやる、ゴール策定や現状分析、将来構想など）には慣れていない。というか、全くやったことがない人がほとんど。

そんな状況で、大規模プロジェクトの上流工程をやる際に頻繁に起こるのが「上流工程のプロジェクト管理を下流で慣れた方法でやろうとする」という現象だ。
・タスクを一生懸命洗い出す
・それをメンバーに分配
・実施タイミングを考慮し、WBSの形で表現
・WBSベースで進捗をチェックし、週次定例会議の報告資料を作る
みたいな感じだ。

やめたほうがいい。
弊害が多い割に効果が薄く、「一見きっちり管理できている様に見えて、本質的なプロジェクト状況は全然分からない」という状況に陥る。


★なぜ下流のプロジェクト管理が上流では機能しないのか？

実は上流に限らず、プロジェクトという仕事には、以下の特徴がある。
a)やったことがない仕事なので、何をやればいいか、先読みしにくい
b)何をどこまでやればいいのか判断が難しい
c)やったことがない仕事なので、工数見積がしにくい
d)寄せ集めチームなので、参加者の関与度や能力を読みにくい

なので、ある程度要件がキッチリ見えてきた下流ですら、スケジュールは本質的にブレやすい。
・初めて使うパッケージの挙動が想定とは異なり、対応を迫られた
・営業部門が全く協力してくれず、顧客情報の精査が進まない
みたいなことが起こるたびに、進捗は遅れていく。


で、上流はこれが100倍ひどい状態だと思ってください。

a)やったことがない仕事なので、何をやればいいか、先読みしにくい
上流だと・・
⇒前述の様に、上流未経験者だけでチームを構成することが多い
⇒僕らの様に上流工程をしょっちゅうやっていても、「この企業、この業務、いまのテクノロジー」ではやっておらず、読めないことが多い。

b)何をどこまでやればいいのか判断が難しい
下流だと最後は「プログラムが動けばいい、テストに合格すればいい」となるが、上流だと・・
⇒ゴールの議論や現状調査はやろうと思えばどこまでもやれてしまい、キリがない
⇒「このフェーズではどれくらいまでやるのがセオリー」が共有されておらず、人によってバラバラ

c)やったことがない仕事なので、工数見積がしにくい
上流だと・・
⇒何をどこまでやればいいのか分からないので、そもそも見積どころじゃない

d)寄せ集めチームなので、参加者の関与度や能力を読みにくい
上流だと・・
⇒プロジェクト計画ができていない（これから作る）。だから体制も不明確。
⇒体制表に載っている人も「参加度合い」に大きな幅がある。
（これについては、「プロジェクトを失敗させる55の罠」の"罠18メンバーが皆ひとごと"で詳しく論じた。いつかブログにも書くかも。）



a)についてはもう少し深堀りした方がよいだろう。
下流と違って上流では、
「3歩進んで見えてきた風景で、次の行動を決める」ということがすごく多い。
例を出すと、
・価格決定プロセスがガンだと思って3日調べたが、特に問題はなかった
・売掛金チームと相談したが揉めて、役員に説明しに行くことに
みたいな感じだ。

つまり、少しやってみないと先の展開が読めないのだ。
結果として工数を使わなくてよくなる時もあるし、予定していなかった作業がガバっと増えることもある。
とにかく不確実性が大きいのだ。
こういう不確実性に対処するために、僕らは「ブラックボックスをちょっと開けてみる」という行動をとる。
覗いてみて、次の予定を考える。


こんな状況で、下流と同様にWBSで進捗を管理しようと思っても、ままならない。
一見、
「この作業は今日で80%まで終わりました！」
「よしよし、順調だな」
のように、管理できている気にはなる。
だが不確実性が高い状況では、80%終わった時点で、40％分の仕事が発見されることが結構ある。すると作業の総量は140%になり、80%だと思っていた進捗率は、実は57%でしかなかった、ということになる。
いきなりゴールラインが後ろにズレる。
もっとひどく、一切予定していなかった仕事の100%がポンと発生したりする。


だから冒頭に書いたように「一見きっちり管理できている様に見えて、本質的なプロジェクト状況は全然分からない」ということが頻発する。一見管理出来ている風、というのが厄介だ。結構な管理工数を割いたのに。


★とはいえスケジュール的なものは必要
そこまで先行きが見えないと、上流では「予定を立てる」ということを一切放棄したくなるのが自然だ。実際にそうなっているプロジェクトは多い。

とはいえ、スケジュールを表現する「何か」がないと、
・「今どこ？」を認識しないと迷走する
・粗くてもスケジュールがないとみんな不安になる（プロジェクトオーナー含め）
・他のメンバーがやっていることが分からず、協力しにくい
という状況になり、それはそれで、わざわざカオスを作ってしまうことになる。

★では、上流ではどんな感じにプロジェクトをマネージするのか？

これを真面目に説明しようとすると、本で言えば100ページくらいになる。ので、大事そうなことだけ。

A)3段階で考える
僕らは上流を3階層で考えることにしている。

階層1）ロードマップ（フェーズ展開）
「システムを作らせる技術」などの、僕が書いた教科書はこのフェーズごとに章を分けているので、見たことがある人もいるだろう。
まずはざっくりと「いまはこのフェーズ」「いまはこのフェーズだけど、前のフェーズでやっておくべき〇〇だけは宿題として残っちゃってる」と、共通認識を作る。

階層2）アプローチ図
タスクの順番と依存関係を示した図。
一般的なWBSよりも（あえて）粗く作る。その代わり、依存関係（工程Aのアウトプットが工程Cのインプットになる）をかなり意識して作成する。
上記のように、やってみて変更が必要だと分かったら柔軟に変更する。
（WBSほど緻密に作ると、この柔軟性が失われる）

階層3)セッションスケジュール
アプローチ図のタスク1つ1つを実施するために、どんな検討を何回くらい必要か。誰を呼べば検討が成り立つか。それを具体的な会議に落としていく。


B)何をどこまでやったら次の工程に行けるか？を明確にする
特に上記のアプローチ図のタスク1つ1つについて、成果物やその精度をなるべく言語化する。
これをやらないと、作業を分担できないからだ。なにしろやったことがないので、呆然と立ちすくんでしまう。
「このフェーズで"アーキテクチャ検討"といったら、こんな図を書ければOK」
「ただし適当に書くだけではNGで、裏付けとなる調査をこの精度でやっておかないとダメ」
という感じだ。

ポイントは「ここまでやれば、後工程に着手できるよね」という観点。
逆に言えば、後工程ができるレベルまで検討できたなら、次に言っていい。
そうしないと、永遠に仕事を続けてしまうし、それはもう「ホビー」の領域かもしれない。


ということで、「上流のプロジェクト管理」と言っても考えないといけないことは膨大で、ちょっと舌足らずだ。だが長くなってきたので終わりにしよう。

***********************
「プロジェクトを失敗させる55の罠」より、今日のテーマに関連した罠

罠27：永遠に始めない
罠48：管理過剰