スコープは期待をすり合わせてなんぼ

プロマネが扱うべきスコープには、プロダクトスコープとプロジェクトスコープの2つがある。

プロダクトスコープは「何をつくるか？」であり、プロダクトを特徴づける特性や機能のことだ。一方プロジェクトスコープは「何をするか？」で、プロダクトスコープを実現するために実施する作業を指す。

例えば、夫婦でゲストを招き料理を振る舞うというプロジェクトがあったとすると、どんな料理を作るかが「プロダクトスコープ」、その料理を出すための作業が「プロジェクトスコープ」という感じである。

このスコープの議論で注意したいのは、プロダクトスコープに意識が行き過ぎて、プロジェクトスコープの管理がおざなりになってしまうことだ。特に経験が少ないプロマネに起こりがちである。

先の例になぞらえると、どんな料理を作るかに気を取られすぎて、買い出しや後片付け、ゲストへの好みやアレルギー有無のヒアリングなどの段取りを忘れてしまうという感じだろう。結局は誰かがやらなければならないわけだし、仲の良いカップルであれば「その辺は阿吽の呼吸でやりましょう」ということもあるのかもしれないが、後片付けを片方に任せて自分だけゲストと酔いつぶれて後で喧嘩になるという話は、結構ありがちである。

業務系システムのケースで言えば、テスト環境整備、初期マスタデータの作成や準備、マニュアルやユーザー研修、立ち上げ当初の問い合わせ対応、顧客受入テストのシナリオやデータ準備などは、役割分担があいまいになりがちなので注意が必要だ。すべてはWBSに落とし込まれることになるので、開始時点でのWBSレビューで大きな抜け漏れは防ぐことができる。

組織で起こる憎しみや悲しみの約90%は期待の不一致から起こるという。
曖昧さを許容することは、期待の不一致の種の温床である。同じチーム内でも起こるわけだから、顧客とベンダーという会社を挟んだ関係性の間なら、なおさら起こっても不思議はない。

スコープを扱う上で一番大切なことは、プロジェクト関係者間で期待の不一致をなんとしても避けることだ。プロマネは、2つのスコープのそれぞれについて、顧客とベンダー、ベンダーチーム内、そして顧客関係者内のあらゆるところで発生する期待の不一致の芽を摘まなければならない。どちらのスコープも必ず言語化/資料化し、共有し確認の意思確認をログに残しておく。自己満足のスコープ定義は全く片手落ちである。併せて変更が発生する場合のルールも必ず決めておく。

システム開発プロジェクトの目的は、期待するビジネスインパクトを起こすことに他ならない。チームメンバを本質に最大限注力させるためにも、避けられるはずの期待の不一致を起こさない環境整備をすることが、プロマネの重要な仕事の一つである。

１．あらゆるMTGログ（議事録）のステークホルダー間での迅速な共有
２．スコープベースラインの合意/承認取得状況の可視化
３．変更管理の運用

特にクライアントワークにおいては、この3つはこそが佳境でメンバを不毛な戦いから守るための壁となる。Backlogのようなチケット管理システムを用いることで簡単に基盤は用意できる。後は序盤からの仕掛け作りと地道な運用に掛かっている。心して臨みたい。