プロジェクトのスコープを決める

前回までのおさらい

ユーザー側でのシステム導入にあたって、プロジェクト計画書をベースにシステム導入の勘所とRFPに記載すべき要件をお話ししていく「システム導入のエッセンス」、第５回目です。

一般的なプロジェクト管理手法であるPMBOKやPM7Keysを元に、ユーザー側でチェックすべき以下の７つのポイントを紹介しました。

１．ゴール
２．スコープ
３．スケジュール
４．チーム
５．コミュニケーション
６．コスト
７．リスク

前回はプロジェクトのゴールの設定について、現状把握や優先度などについてお話してきました。

今回からは「スコープ」の話になります。
第２回の「プロジェクト管理手法について」でプロジェクトをデスマーチに引き込む原因の二割がスコープの流動性にあるというような話をしました。
ちなみに残りの八割が「スケジュール」と言ったのですが、これは「発生割合」であって、「深刻度」を加味するとスコープが流動すると凄まじいインパクトが起こります。

ベンダーのスケジュールが生産性ギリギリの綱渡りでひかれていたとして、これによって発生する負荷は（ベンダーにとっては）もはや日常茶飯事です。
残業ありきでスケジュールをひいていることの良し悪しはありますが、逆にそれくらいで吸収できる影響と言ってしまうこともできます。
ベンダー側も経験則としてスケジュールにどれくらいのブレが発生するかは認識していますし、その範囲の中で推移している分には致命的な問題になりにくいでしょう。
（あくまでプロジェクトの成否のみについてであって、人として企業としての管理や倫理の点で「致命的な問題」ではないとは言いません。）

スコープがぶれたり変わったりした場合、そもそもの計画が崩壊していきます。
人も費用もスケジュールも根本から覆り、阿鼻叫喚の地獄絵図が待っています。
ベンダー側の痛手はユーザー側に無関係なわけではありません。
まともに機能しなくなったプロジェクトの成果物がまともである可能性は低いです。
提供されるシステム、サービスが使い物にならなくなって困るのはユーザー側です。
どれだけベンダーを罵倒しようが、損害賠償請求をしようが、本来行った投資によって得られるはずだった効果は得られず、事業計画そのものに影響を及ぼす場合もあります。

掛けた投資に対して必要な効果を得ようと思うのであれば、ユーザー側もゴネ得を狙って無理難題を吹っかけるようなことはするべきではありません。

と、冒頭からSE目線で釘を刺すような話をしましたが、そもそもこういうことが発生する原因は、ユーザー自身が今回何をどこまでしようとしているか決めていないしよくわかっていないという点にあると思います。

「何をどこまでしようとするか」＝スコープなのです。

ゴールは理想図、スコープは設計図

前回プロジェクトのゴールの設定についてお話しましたが、ゴールは「なりたい姿、あるべき姿」であり、定性的なイメージに近いものかもしれません。
具体的な数字をゴールにしてはいけないという意味ではありませんが、詳細な機能の実現方法や具体的な操作者を限定するところまで落とし込んでいるわけではありません。

スコープとはプロジェクトが対象とする範囲であり、具体的な実現範囲を定義するものです。
対象とする業務、必要とする機能、利用者の範囲、ベンダーとユーザーの役割分担などもスコープに該当します。

第２回の話の中で「「軽自動車がいい」といっていたユーザーが高級外車や２トントラックを要求しはじめるという現象が起こる」という例を出しました。

この例をベースにすると、車を買いたいユーザーのゴールは、「日々の通勤や買い物を楽にしたい」「家族で遠方へ旅行に行きたい」「快適なドライビングを楽しみたい」「10年乗れる車を買いたい」「できれば価格を安く抑えたい」だったとします。
こうしたゴールだけ見ればどのような車種でも良いように見えますし、「価格を安く」にクローズアップすれば軽自動車が適しているように見えます。

しかし実際には家族構成を見てみると７人家族だったり、家族で旅行に行きたい先は山や川でのアウトドアだったりして、そうなると乗車人数の多いミニバンやアウトドア向きのSUVが良いのでは、となります。
逆に家族構成は夫婦２人でだけど、「遠方に」「快適なドライビング」をするために高速性能の高いスポーツ仕様車が適している場合もあります。

これらの要件を達した中で「価格を安く」がようやく出てくるのです。
「価格を安く」が最優先である場合、まずは予算を提示した上でそれに該当するサービスの提供を求めなければいけません。
しかし価格が安ければ問題ないのでしょうか。

車もシステムも安くない買い物です。
費用を抑えたとしてもある程度の額の出費は発生します。
それだけのお金を払って得られるサービスが企業にとって最適なものになっていなければ非常にもったいないです。

スコープを決めるための制約

とはいえスコープ決定のためには様々な制約があります。
まず考えられるのは「コスト」と「スケジュール」の制約です。
「予算に収まる費用であること」「事業計画とリンクするためにいつまでに稼働させること」などを考慮しなければいけません。

システム導入予算についてはコストの回にもお話しますが、予算ありきで導入システムを選定すると、総じて中途半端な結果になったり、最悪何一つ要件を満たせないシステムになる恐れがあります。
まずはRFI等でやりたいことを実現するにはどの程度のコストがかかるか把握した上で、現実的な予算と突き合わせながら予算なで実現可能なところを模索していきます。
またスケジュールについても経営計画とのリンク以外にも、既存システムの保守切れなどのタイムリミットがある場合もあります。
リミットに合わせた導入が可能なベンダーを選択するか、他の方法でリミットを伸ばすなどの対策が必要になります。

ユーザー側の作業者のリソースや、パソコン、ネットワークなどのITリソースも制約になります。
システム利用をスコープとして想定している人に対して、システム操作という新たな業務が追加になる、もしくは現行システムからの切替が発生します。
誰を利用者として想定するか、というシステム面からの要件だけではなく、他業務も含めた全体的な負荷を含めたリソースを考えなければいけません。
ここは情シスやプロジェクト単体ではなく、経営層などにも検討いただかなければいけない部分になるでしょう。

またシステムを利用するクライアントとしてのパソコンやシステムに接続するためのネットワークが無ければ、そもそもユーザーがシステムに辿り着けません。
例えば社内ネットワークに入れない外回りの営業社員が使おうとするのであれば、モバイル環境などシステム利用のためにインフラも併せて整備するのか、現行インフラ上での動作を前提とするのか検討が必要です。

これらの制約があるがために、ユーザーの要件が「軽自動車がいい」に収まってしまうことが多いのではないでしょうか。

ゴールの実現を簡単に諦めてはいけない

様々な制約があるので実現できるパターンは自ずと狭まってくるかもしれません。

しかしスコープの最大の制約は「ゴールを達成できるスコープになっていること」です。
これはプロジェクトの大前提であり、これを達成できなければ他の制約を満たしても意味がありません。

費用が無いから、人が当てこめないから計画を縮小するのでは、当初に決めたゴールにはいつまでたってもたどり着けません。
現状に課題がありそれを改善することを目標とした時点で、改善自体を諦めることを早々に決めてしてしまってプロジェクト自体の目的が薄れまし、何よりこれがスコープをブレさせる原因になります。

本当はやりたいんだけど費用や時間や担当者がいないからスコープから取り下げる、でも本当はやりたい。
そうした思いはプロジェクトの進行の端々に顔をのぞかせてスコープをぐらつかせたり、完成したシステムへの満足度を低下させてしまいます。
「本当は電気自動車が買いたかった」という思いがあるままだと、いつの間にか電気自動車を要求しはじめてしまったり、買った軽自動車に不満をもったまま使い続けることになるのです。

やりたいことと現実的な着地点をどこまで近づけることができるか、それを調整する場がRFIやRFPなのです。
もちろん様々な調整をした結果、それでも全ての制約をクリアはできない場合にようやくどのように折り合いを付けるかという検討に至ります。

その場合も全社展開ではなく対象者や部門を限定したり、機能を区切った段階導入にしたりなど、あくまでもスコープの範囲をコントロールすることを重視し、ゴールを削ることは最後の手段とすべきでしょう。

こうしたプロセスで決定していったスコープは、そう簡単にぶれることはないのではないかと思います。