全体の地図とスコープクリープ

プロジェクトにおいてデリバリーをする際には「全体の地図」が必要である。
全体の地図とは、「何を決め、何を作ればプロジェクトゴールを達成できたといえるのか」を指し示したもの。

例えば、システム開発だとわかりやすい。
システムを刷新・導入するにあたっては、ユーザーが直接利用するアプリケーションを設計・開発するだけでは終わらない。
ハードウェアやネットワークなどインフラもあれば、既存のシステムがあれば移行も必要となる。稼働後のシステム運用体制の設計や、ユーザー部門への教育も必要だろう。
こういった「全体として何が必要か」がここでいう地図。

新規ビジネスを立ち上げる際に事業計画を作成する際も同じである。
どんな顧客体験を実現するのかに始まり、それをどんなスキームで実現し、どうビジネスとして儲けられるようにし、それにはどんな関係者を巻き込まないといけないか。キャズムを越えるためにどんな施策を準備し、全体のスケジュール感といつ累損解消が見込めるのか、などが最低限ないと事業計画としてGo／NotGoは判断できない。

これがないとどうなるのか。

まず現状のプロジェクト進行上の良し悪しがわからない。
アプリケーションだけ開発は進んでいそうだが、移行やインフラはどうなっているのか？
スキームは検討されているが、累損解消は検討しなくてもいいのか？
プロジェクトがスケジュールどおり終わるのか？
何に手を打つべきか、もしくは手を打たなくてもなんとかなるのか？
地図として全体像が見えないと進捗が把握できない。
こういった疑問は顧客やメンバーは常に感じていることで、疑問に思った際に「XXの状況なので大丈夫」「AとBの検討後、この時期に決定する予定のため大丈夫」と回答ができないと不安を募らせることとなる。
実際にこれで顧客の不安が募り、PMOの立場を取って代わられた経験もある。

もう1つはスコープクリープしているのか、やるべきことをやっているのかが判断がつかない。
プロジェクトでは検討すべきことが山積みであるし、次から次へと発生する。
ただ、それが今やるべきことなのか、このプロジェクトでやることなのか、我々が契約上やることなのか、地図として論点があと何が残っているかわからなければ判断がつかない。
最悪のケースは顧客から言われたことを全てのみ、ひたすらやらざるを得ない状況に陥ってしまう。この場合、当然リソースは分散されるため、本当に必要な検討事項に時間が割けず、プロジェクト自体もうまいくいかなくなることが多い。

ではこういった地図をどう作るのか。
これは演繹的なやり方と帰納的なやり方の両面がある。
演繹的というのはいろいろな事例なりフレームワークから導くやり方。
システムならPMBOKなり、新規ビジネスならリーンスタートアップなり情報源は無数にある。そこから必要な要素を抽出する。
帰納的というのはゴールに対して必要なことを分解していくやり方。
例えば、「新規事業を経営層が了承するためには何が必要か」から考え、実現性やコスト、利益など分解していく。
通常は双方のやり方を組み合わせて考える方が精度が高くなりいいだろう。

意外にこのような全体像、そこまで行かなくても論点リストレベルのものがなくプロジェクトを進めるケースもまま見受ける。
顧客との関係が良好で、検討自体がうまく進んでいる時点では特に問題とならないが、一度疑問や不信を膨らませるとプロジェクト自体を危機に陥れるリスクをはらんでいる。