流麗なシステム開発の上流工程を実現するために

　私は以前、システム開発の要件定義に関する考察の中で、

　システム開発の問題の本質は、現実世界からシステム世界への変換過程において、その変換の対象と変換方法を正確に知るのが工程のかなり後にあることです。となると、要件定義において、ビジネスルールを明らかにするべきなのは明らかなのですが、実務上の課題は、どのレベルをもって明らかであるとするかです。

　と書きました。これは、私が手掛けている大型プロジェクトでの失敗がトラウマとなったがために、「要件定義が固まるまでは絶対に次工程に進んではならない」という固定観念が私の頭にできてしまったが故のものです。つまり、要件定義と設計との分離にこだわり過ぎていた…？
　＊開発ライフサイクルについては、私は富士通のソフトウェア開発標準プロセスSDEMを基礎としています。
　しかし、こう書いた直後から（トラウマを明確に認識してから）、自身の考えは修正されつつあります。


　修正の前提となる未検証の仮説

1. ICONIXとRDRAを統合し、ユーザーがより具体的に要件を確定できるようにする。つまり、予備設計というICONIXの思想を、SDEMの要件定義工程に取り入れる。具体的には、
1. 画面モデルについては、画面遷移を明らかにする。
2. 機能モデルについては、プロセス定義（入力、処理、制御、出力）を明らかにする。
2. SDEMのWBS(Work Breakdown Structure)を、前項と整合するようユーザーインターフェース設計工程の一部のWBSを、要件定義工程に移動する。
3. 前項を持ってSDEMの要件定義工程とし、契約を次工程以降と分離することで、私の実務上の課題は解決される（かも）。

　以上の仮説の検証により要件開発の具体的なシナリオが再定義されると、私の頭の中の上流工程が一旦きれいに整理されます。ここが、「流麗なシステム開発の上流工程」を実現するためのスタート地点だと認識しています。

関連記事
流麗な上流工程の研究（メモ）
コンテキストモデル（カスタマイズ版）
流麗なシステム開発の上流工程を実現するために
小さな要件開発
システム開発の要件定義に関する考察
要件開発の進め方～私のRDRA運用法～
RDRA(2) - RDRAとの出会い
RDRA