「外部設計はこれでOKですね？ハンコ押してください。これで仕様凍結します。これ以降は仕様変更になります」なんて会話をお客様にして、良い気持ちで押してくれるお客様なんていないよ。
— yoh nakamura (@yohhatu) 2011年8月3日
これについてグダグダと考えてみました。
このつぶやきの元になっていた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
コメント