SW開発で火を噴くパターン

【1】SW開発ではいつも結合テスト以降で火を噴く。
設計、開発、単体テストまで順調であっても、結合テストから受入テストに至るまでに致命的な問題が発覚する。
例えば、下記のような問題がいつでもどこでも噴出するのではないか。

設計書には、複数の画面遷移による業務フローが考慮されていなかった。
業務のインターフェイスがシステムとして整合性が取れていなかった。
シナリオに従ってテストしたら、設計時には気付かなかった業務フローが見つかったり、想定しなかったデータが作られて、その対応が漏れていた。
つまり、設計漏れ。

実際に結合テスト環境で動かそうとすると、そもそも動かない。
実は、DB環境にViewやプロシージャがもれていた。
あるいは、帳票出力やPDF出力、バッチ処理などに必要なサードパーティのライブラリがテスト環境に無かった。
モジュールをビルドして、Webサーバーを再起動する作業が手順化されておらず、手間がかかる。
しかもリリース漏れなどのミスも多い。
つまり、環境構築やリリース作業漏れ。

特に帳票やPDF出力は、非常に重要な要件にも関わらず、実際に環境を構築して動作させないと、性能がボトルネックになるのが後になって気付くと致命的だ。

設計書に従って作ったのに、顧客に使ってもらうと、本来の要件は実は異なっていたらしい。
要件定義書や設計書は顧客から承認されたはずなのに、双方が誤解していたらしい。
つまり、要件漏れ。

あるいは、顧客が、本当はもっとこういう風に使いたい、と仕様変更を言い出してきた。
顧客との関係、顧客との要件定義をコストとビジネス要件の観点から、きちんとコントロールできていなかった。

【2】いつも思うのは、SW開発の失敗パターンは上記のように大体決まっている。
なのに、同じような失敗を何度も繰り返す。

問題の本当の原因は、技術にあるのか？
それともマネジメントにあるのか？

チケット駆動開発を1年間実践してみて、SW開発は高度な技術と高度なマネジメントを必要とすることを改めて経験した。
僕が思うに、高度な技術とはアジャイル開発とSW構成管理、高度なマネジメントとは真の意思決定ということ。

【2-1】アジャイル開発のおかげで、ビルド作業漏れは、1回目のイテレーションでリリースする時に判明する。
要件漏れ、設計漏れも、初めてその機能を実装するイテレーションか、そのイテレーションのリリース後に顧客が使う段階で判明する。

早めに失敗した経験を生かすことで、次のイテレーションでは同じミスはしなくなる。
顧客にシステムを少しずつ使ってもらいながら、顧客が求める本来の要求を開発チームも少しずつ理解しながら、システムのグランドデザインの精度を少しずつ上げていく。

これはプロセス改善とつながるはずだ。

【2-2】XPが提唱するSW構成管理のプラクティスは、チームに必要な技術を示唆してくれる。

最初は、凝った機能を実装する必要は無く、シンプルな設計でまず実装して、顧客に早く提供しよう。
それからフィードバックを受けて修正すればいい。
その時に、リファクタリングでプログラムの構造を綺麗にしてから、機能追加する。

テスト駆動開発のおかげで、プログラムの単体テストの品質はクリアできる。
ソース共同所有のおかげで、いつでも誰でもすぐに障害を修正できる。
継続的インテグレーションのおかげで、コミットしたコードラインは常時リリース可能になる。

これらのインフラがあるからこそ、アジャイルに開発できる。

更にチケット駆動開発のような強力なタスク管理があれば、アジャイル開発の弱点だったプロジェクトマネジメントの観点を強化してくれる。

TestLinkのようなテスト管理ツールも、結合テスト以降のシナリオベースのテスト工程を一括管理してくれるので、テスト工程の効率化に非常に役立つ。
システムの品質(特に信頼性)は結局、テストケース数の多さと要件カバレッジでしか顧客へ説明できないから、テスト工程の効率化は品質強化に直結する。

SW構成管理はSW開発プロセスの一部に過ぎないけれど、プロセスを回すインフラそのものだと思う。

【2-3】チケット駆動開発を実践して気付いたことは、SW開発のマネジメントがシステムの品質に大きく左右されていることだ。

アジャイル開発は、品質・コスト・スケジュール(QCD)の三角形から、スコープ・コスト・スケジュールの三角形へプロジェクトマネジメントのパラダイムを転換させた。
この意義は、常に品質が保証されたシステムでなければ、機能追加したり、人員を増やしたり、納期を延ばすといういずれの意思決定も役立たないということだ。

アジャイル開発のマネジメントで最も重要な点は、スコープの調整にある。
機能を追加したいなら、コストやスケジュールも変更しなければならない。
しかし、SIerの普通のビジネススタイルでは、コストやスケジュールはほぼ固定のため、スコープで調整するしかない。

だから、ビジネス要件の優先度、機能仕様の優先度、チケットの優先度を順位付けする意思決定が必要になる。
その意思決定を行うには、顧客の業務を把握する業務能力、更には、機能追加によってシステムがどれだけ影響を受けるかという設計能力、そして、どれだけ工数がかかるか細部まで知り尽くしている開発能力が必要だ。

管理者は単に開発スケジュールを保守するだけの、タイムキーパーのような役割だけでは務まらない。
あるいは、顧客から大きな開発案件を受託する営業マンのような役割だけでは務まらない。

SW開発で火を噴くパターンは、「アンチパターン―ソフトウェア危篤患者の救出」や「デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか」の本のように、昔から既に知られている。
そろそろ同じようなミスを繰り返す状態から脱却しよう。

そのために必要な解決方法を自分なりに、自分のチームなりに見出そう。