開発プロセス - A.R.N [日記]

通常、ウォーターフォール型の開発（というか、今現在でも世のプロジェクトのほとんどはこれだし、実際のプロジェクトを考えると極めてリアリティのある開発プロセスである）では下記のようなプロセスが想定されている。

順番	プロセス
1	要件定義
2	基本設計
3	詳細設計
4	開発
5	単体テスト
6	結合テスト
7	システムテスト

なお、基本設計、詳細設計は外部設計、内部設計と呼ばれることもあるが、個人的には設計を外部と内部にわけるという観点が気に食わない（原価計算の計算プロセスとか夜間バッチの運用設計って外部なのか内部なのか明確ではないでしょ）ので使わないことにしている*1。

だが、このプロセスの流れは、実際の手順や重みを考えると不十分だと最近感じている。私案だとこんな感じになる。

順番	客	コンサル	SI	開発
*	コンサル会社選定（1,2の範囲で契約）
1		対象領域・現行業務分析
*	SIer選定（2,3の範囲で契約）
2		新業務設計	現行業務調査
*	コンサル納品物の検収
3			要件定義/インフラ・フレームワーク設計
*	SIerと契約（4,5,6,7の範囲で契約）
4			基本設計/フレームワーク開発
5			進捗・調達管理	詳細設計/開発/単体テスト
6			結合テスト
*			開発会社納品物の検収
7			システムテスト
*	SIer納品物の検収

従来の開発手法と何が違うのか。実は中身という面から見ると基本的にはまったく変わってない。新たに加わった部分も通常の開発プロセスで普通に行われていることである。

では何が特徴なのかと言えば、内容を詳細化するとともに役割を明確化したことである。

まず、コンサルタントを入れる場合には、要件定義全般をコンサルに任せるべきでない。しかし、だからと言ってSIerだけに任せると全体最適な業務プロセスの構築が困難になる。上記のように期間を被らせる形でSIerの選定を行い、コンサルが新業務設計で無茶をしないよう牽制させるべきである。コンサルもSIerも現状分析は行うが、その中身は大きく違う。コンサルが行うのはトップダウン的な分析であるのに対しSIerが行うのはボトムアップな調査である。前者が無ければせいぜい現状維持のシステムとなるし、後者が無ければ動かないシステムになってしまう。

次にインフラ・フレームワーク設計を要件定義フェイズに置いたことである。インフラ設計は結果的に要件定義フェイズで行わざるを得ない場合が多い。なぜなら、セキュリティや設備といった社会的・物理的な側面が影響するため、ソフトウェア開発の要件の前提にかかわってくるからである。フレームワーク設計も同様で、開発環境によって実現不可能な事柄や得意な事柄などもあるので、早々に利用するソフトウェアやフレームワーク技術を決めることで、実現可能性を高めるよう要件の誘導を行うことが可能になる。また、基本設計終了時にフレームワーク開発を完了させることで、開発部隊や開発会社に仕事を渡しやすくなる。

そして、開発作業である詳細設計・開発・単体テストを単一プロセス内に併合したことである。現実を考えればこの三つは個々の開発者で繰り返されるわけであるからそれぞれがプロセスとして分離されるなどありえないことである。であれば、記載の上でもそのように書くべきであると考える。また、結合テスト後は原則開発会社を開放すべきである。システムテストは、SIerの責任において行いバグの修正はあくまで瑕疵対応として行ってもらう。システムテストがSIerだけで問題なく実施できる程度に情報の受け渡しができるドキュメントが用意されているのであれば、その後の運用にも対応できる品質である可能性が高い。

こうやって、作業をより明確に意識できるプロセスが基盤としてあれば、一番最初の提案時に意味不明なプロジェクト計画書を出さなくて済み、失敗プロジェクトを少なくできるのではなかろうか。

*1:テストもモジュールテストやらリリーステストやらといった用語が定義も明確でないまま出てきて困るのだが、単体・結合・システムの三種類に分類されるのが一般的であろう