見積り

仕様変更を前提にしたプロジェクト管理

システム開発プロジェクトの成否を決するには、いろいろな要因が複雑に絡み合っているのはここでいうまでもないですが、最近はその度合いがますます激しくなったように思われます。

・多様なユーザニーズへの迅速な対応
・製品サイクルの短期化に伴うシステム納期短縮
・高度に複雑化する技術対応のためのスキルアップ
・慢性的なプロジェクト要員の不足
・競争の激化による緊縮予算・・・・・・・・

プロジェクトリーダは非常に過酷な状況で責任を負っていることになります。
一般的には、「スケジュール遅延」や「コスト超過」、「メンバの超過勤務」「顧客ニーズが満たせない」といった結果になるのが常です。このような問題を最小限に押さえるのがプロジェクトマネージメントであり、プロジェクトリーダの役割といえます。

ところで、このようなプロジェクトの大きな課題しては、「初期での仕様確定が困難」「ニーズの変化は避けられない」というのがついてまわります。

このような問題に対し、これまでさまざまな方法で、事前の見積りの精度をあげるべく努力がなされてきましたファンクションポイント法、COCOMOなどはその代表的な手法です。
そして、これらの手法の前提には「見積り方法を高度化すれば見積り精度が上がる」「見積り精度が上がればコストやスケジュールの問題が解消する」といった論理による期待があるのです。
ところが、このような論理が機能する大前提として、「過去のプロジェクトの経験がデータベースとして蓄積されている」「見積り対象のプロジェクトの前提条件が明確になっている」「過去に経験したプロジェクトと似ている」というものなのです。

こんな前提とても現実的ではありません。

これが、ファンクションポイント法やCOCOMOがなかなか定着できない、またユーザに理解しにくい大きな理由となっています。

となると、もうこれらの方法論は限界です。
「変化・変更を前提とした管理」へ発想の転換をしなければならないのです。
つまり、
・プロジェクト初期段階で詳細の仕様確定は不可能である
・仕様変更は不可避である
・仕様変更に対して積極的にコントロールする
・ユーザと開発側がともに納得できる変更管理システムを確立する
というポイントを押さえたプロジェクトマネージメントが、実体に則した形といえます。

では、具体的に有効な変更管理を行う上で何が不可欠か？ということですが、次の５つのポイントに絞られます。

１．ユーザとの窓口の一本化
仕様変更の状況を一元管理しましょうということです。
仕様変更依頼書のような定型書式を作り、一覧表で管理するのも一つの手でしょう。
担当者が個別に変更依頼を受けないということです。

２．変更管理プロセスフローの明確化
１で定めた書式や管理をうまくまわすためには、そのフローの確立が必須です。
グループウェアを使ったりするのも有効でしょう。

３．「予想される変更」の予算化
あらかじめユーザに通告しておいて、全体の５～３０％を多めにつんでおくのが有効です。

４．開発側の交渉力の強化
「物事はプロセス通りに動かない」ということを認識し、開発側がイニシアティブをとることができれば、変更管理は非常にスムーズにまわるでしょう。
ユーザとのコミュニケーションをはかり、理解を促すという努力は常に必要です。

５．メンバーへの周知徹底
これらのフローや書式、ルールなどを参加者全員に周知し浸透させることが必須です。
キックオフミーティングや事務局による集中コントロールなどを利用することで、浸透を図りましょう。

最後に、ひとつ付け加えておきますが、事前の見積りがまったく必要ないということはないでしょう。むしろ、ある程度の見積りで検討をつけておくことは必須です。でないと、少し予算を多めにとっておくなんてできませんものね。

ここでは主に「変更管理」について述べてきましたが、他のプロジェクトマネージメントの大きな柱である「コスト管理」「進捗管理」といったものは、シミュレーションによる分析が今後主流になっていくとのことです。

以上

情報技術スキルアップの種に戻る

GLORY's OFFICEへ