Sphere System Consulting ltd. スフィアシステムコンサルティング株式会社

Vol.110 停滞しないITプロジェクト進行術

 コラム

停滞しないITプロジェクト進行術

 

前回はITプロジェクトは危険な橋を渡る行為に似ており、素早く渡りきる心構えが必要だという話をしました。具体的にどのように危険な橋を素早く渡るのか?についてお話します。

 

前回も述べましたが、ITプロジェクトが素早く渡りきれない原因はプロジェクトの遅延です。よくある遅延する理由としては、要件が膨らんでしまうことにあります。システムを導入する際、あれもこれも機能を盛り込もうとして要求がどんどん大きくなることが遅延の最大の理由となります。

 

特に要件定義に代表される上流工程で遅延を起こさない指針を打ち出すことが重要となります。

 

要件定義の工程では、これからの仕組みづくりに望む事と称して、ゼロベースで要望を出し合う風潮があります。この事自体は良くも悪くもないのですが、そもそもの前提として、挙げた要望すべてが実現されるわけではないことを理解しておかねばなりません。これは、現場担当者の意見だから経営層直々の意見だからという区別はありません。全ての要望は公平に判断され、優先順位付けされて今回実現する要望として精査する必要があります。

 

さらに、重要な要望を後から出すことで遅延を発生させる原因となっています。一旦動き出したプロジェクトに後から要件を付けたすのは極めて危険です。システムの発注側も受注側も理解しておかなければなりません。追加でコストを払えば何とかなるものでもなく、時間を掛ければ何とかなるものでもありません。

 

よく発注側経営層や上層部のたっての願いで追加要件をねじ込もうとしますが、これほど危険行為はありません。これを受け入れてしまう受注側ITベンダーにも責任はあるのですが。

 

システム導入の目的に沿ってプロジェクトの範囲を決めることを、プロジェクトマネジメントではスコープと呼びますが、何をどこまでやるかを定義できたとしても、途中でブレて簡単に変更があるようでは方向がまとまりません。

 

もちろん、途中変更が無いに越したことはありませんが、要件の追加や変更など最初の決め事から途中変更が発生した場合に、どのように対応するかがポイントとなります。

 

停滞しないITプロジェクト進行術とは、必要最低限の要件で一旦最後までプロジェクトを走り終えることです。

 

プロジェクトの進行に大きく影響する途中変更は、一旦プロジェクトを完了させた後に対応するという姿勢をハッキリさせておく必要があります。現行で走り出したプロジェクトは止まる事をせず、最後まで走り切る事を徹底させます。

 

ITプロジェクトに対し、「危ない橋を素早く渡りきる」心構えが必要ならば、その実践には「自転車はなぜ倒れないのか」という事を念頭に置くべきです。

 

自転車は走りながらバランスを取り続けるから倒れないのであって、速度が落ちれば倒れてしまいます。ITプロジェクトも同様に、速度が落ちれば倒れてしまうのです。一旦立ち止まり追加要望という積み荷を追加することは、異例中の異例でなくてはなりません。

 

「遅延がないプロジェクトが良い事はわかっている。でも、この程度の追加なら対応できるのではないか?」という判断が危険です。「この程度」はどれほどの影響力があるのか全体を俯瞰して判断しなければ答えは出ません。「この程度」という落とし穴には注意しなければなりません。