条件を変えても、以前のやり方でできると思い込んでしまう

家電を買い替えたりするときに、買い替えだから買い換える前と後では同じ結果を期待して使う。コモディティな製品だから共通的な昨日は多少の操作が違っても使っているうちに慣れて、気にならなくなる。日々使うものだし、使えなければ困るからある意味、積極的に使いこなそうとするし、使う目的がはっきりしているから習得も早い。

あるプロジェクトは、従来のウォーターフォール型のシステム開発手法を採用した契約をしていた。いつもと少しだけ違ったのは、スコープが固定の部分と要件定義や課題管理で新規の要件なり、仕様が出てきたときに少しばかり対応できるような、ある部分だけ柔軟な契約形態になっていた。

この『ある部分だけ柔軟』な契約に対する適切な理解をできていたプロジェクト関係者は、誰1人としていなかった。

後になって聴いたところでは、これまでの経験から言えば、どのようなプロジェクトであっても、RFPや見積もり依頼書に対する追加の要件や仕様の膨張はあるから、

『従来どおりに、課題管理や変更管理をするつもりだった』

と話していた。

従来と同じなような契約であったら、システム開発手法は変えずともよかったかもしれない。ただし、今回は契約からして違う。ある部分だけは柔軟な契約であるから、それを前提条件で柔軟な部分を制御できるような条項を入れていたとしても、実際のプロジェクトチームで運用するシステム開発手法は同じでよかったのか、ということである。

条件が変わったとしても、どうせ同じように調整しながらやるのだから、システム開発手法に対して何も疑問を思わなかったのだろう。

こういったときは第三者の立場は違いに気付きやすい。

従来の、スコープを決めて始める場合はウォーターフォール型のシステム開発手法は使い易い。スコープを決めて始めるので、あとはシステムに落とし込めるように具体化を進めれば良い。仮に要件が変わったり、仕様が増えたりしたら、追加を見積もり、それでやるかを変更管理プロセスの中で討議する。その際、スケジュールやどのタイミングで追加分を吸収するかを協議するので、結果的には別リソースと時間軸を並行で走らせ、最終的にどこかのマイルストーンで統合する。

このケースでもそれと同じことを考えていたようだが、少し違うコンディションであることに気づけなかった。それは、柔軟な部分を賄うバジェットをどこから使うか決められないという特性である。

別の見方をすれば、プロジェクト全体から柔軟な部分に相当するバジェットはさっ引いたコストとスケジュールで計画し、要件の変更や仕様の追加を課題管理から対応を協議の上、合意したらそれの対応をしなければならないという、いつもとは違ったプロジェクトマネジメントをしなければならないということである。

条件が違うとき、同じ手法で対応できるかどうかはよくよくシミュレーションしなければ、対応方法を間違ってしまう。