そごうソフトウェア研究所

SOA、開発プロセス、ITアーキテクチャなどについて書いています。Twitterやってます@rsogo

改善した開発プロセスを評価する。定量評価だけではなく、情報システム部門の戦略にあっているか?

今、基幹システムのリプレイスプロジェクトのパイロットとして、開発プロセスをこれまでのウォータフォールから、短期間でイテレーションを繰り返すアジャイル的な要素を組み入れた開発プロセスに変更してみて、内製化ができるか、工数がどう変わるのか、どのようなリスクが増えて、減るのかを検証しています。


今日議論になったのが、これまでの開発プロセスと、今考えている開発プロセスと比較して、どこかでどちらで行くのかを判断しないといけないと言うことでした。


で、新旧開発プロセスの比較評価が難しいね、と。
今のパイロットプロジェクトの要件では、新しい開発プロセスでしかシステム開発をやっていないので、実績としては新開発プロセスのものしか取れません
逆にプロジェクト開始当初にウォータフォール式で行った見積もりは存在しています。ただ、その時点では新開発プロセスは初挑戦で見積もり根拠が無かったので、プロジェクト当初の見積もりはありません。存在していたとしても精度がかなり低いでしょう。


ウォータフォール式の見積もりと、新開発プロセス実績を比較するのでいいの?
開発が終わったときに、要件やリスクがすでに分かっている状態で新開発プロセスで再見積するのは、プロジェクト当初にリスクをいっぱい積んだ見積もりと比較できるの?
という議論になりました。


個人的には、工数のような定量的な比較も重要ですが、内製化の方針をとるならどちらが向いているのか、PMのリスクの感じ方、本番の基幹リプレイスで人数が増えたらどうなるの?といった定性的な評価もして選択すれば良いと思います。
結果として、開発プロセスが今の会社の方針に合っているということが言えれば、工数の様な定量比較は厳密な比較は不要で、目標の工数内に収まるのならそれで良いじゃないかと割り切ることもできると思います。