仕様凍結のつぶやきのその後


これについてグダグダと考えてみました。
このつぶやきの元になっていたWFの開発プロセスでは「工程毎にキチッと終了し、その工程は簡単に後戻りしない」という前提です。

実際のPJではプログラミングやテストでの仕様追加や変更時は、それなりに発生します。
「WFでは後戻りしないんです!」と主張してもPJが進まないわけで、どうにか取り込もうとするわけですが、たいがいそれまでWFの各工程でキッチリやっていたプロセス(管理系もそうだし、設計や影響調査なども)がおざなりになることがあります。

その後のよくあるシーンとして…
・再見積や追加見積の数字が「なんでこんな簡単な機能追加なのに、こんなにお金/時間がかかるの!?」とお客様と乖離がありすぎる
・追加/修正した機能や関連する機能にバグが混入する(設計や影響調査、テストが十分でない)
…というのがあります。
これの要因の1つは(お客様のシステム開発の知識や経験も関係しるとは思いますが)自分達開発チームが仕様追加/変更を適切に行える状態になっていないことだと考えています。

1つは、開発インフラ環境の状態です。
開発インフラの三種の神器であるSCM/ITS/CIを使って、プロダクトコードが構成管理されていてベースラインが分かり、ITSで仕様やその経緯、リポジトリとの紐付けができて、CIで自動テストがグリーンになっている、そして失敗したらすぐに分かる…という状態なら、仕様追加/変更にも品質に影響を出さず、容易く対応できると思います。
特にCI(とテストコード)が無いと、大量の再テストを手動でしたり、バグの混入に気づくのが遅れ、大きな影響が出やすくなります。

もう1つはプロダクトそのものです。
プロダクトのコードは可読性/保守性が高く、DBなど含む設計もそれなりのレベルが必要です。
スパゲッティコードや拡張ポイントがぐちゃぐちゃな設計だと、仕様追加/変更のスピード、確実性が大きく落ちるので。

この2つが成り立たないと、工程途中の仕様追加/変更で(要求側が「なんでそんなになる?」と思う)コストや期日になったり、品質の劣化が発生します。
この話はお客様が使い始めた後の機能追加/修正でも同じです。

では、こういう条件を「使うアプリはパワポとExcelばかりで、プログラミングはパートナー企業やオフショアに丸投げしている」SE(や組織)がクリアできるか?というとNoなわけです。

「Noなら、どうしようか?」となって、冒頭の「仕様凍結」という言葉で、変更を抑止したり、お客様の費用感でなく、自分達の費用感でやれる材料にする動きになると思います。
当然、こんなことではお客様に価値を提供することは難しくなります。

ちなみにお客様の費用感を受け入れた場合、PJは赤字になり、品質は劣化し、デスマーチになって行くと思います。

(要求が変わることにより)仕様追加/変更が発生するんだ…と「変化を抱擁する」ことを前提に開発プロセスを考え直すのも1つの対応方法だと思います。
ただ、「変化を抱擁する」ことができる状態…開発インフラ環境の整備とプロダクトのコード・設計レベル…が実現できない組織では絵に描いた餅に過ぎません。

なので、そういうSEが多いSIerが、これから生き残るには…
1:自分達もモノ作りができるようになる
2:従来の開発プロセスで良いとするお客様だけをターゲットにしてやる
…かじゃないと思っています。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo on Visualhunt

コメントを残す