システム開発の要件定義に関する考察

私は先日、KenichiroMurata氏のブログ「要件定義の怪物、ビジネスルールをいかにして仕様化するか？」を読みました。これは、システム開発の上流工程に携わる人々にとって、大きなテーマだと思います。

私は富士通グループの開発者と仕事をすることが多いのですが、その富士通にはSDEM（Solution-oriented system Development Engineering Methodology）という優れた開発標準があります。大変残念なことに、SDEMに関する詳細な情報を富士通は一般公開していないので、その内容を詳しくお伝えすることができません。しかし、SDEMは共通フレーム2007との整合性を考慮しているので、基本的な考え方は共通フレーム2007と同質です。
＊一言でいうならば、SDEMは共通フレーム2007をより具体化したものである、といえます。しかし、富士通に確認したところ、SDEMはあくまでも富士通のオリジナルのナレッジであり、他の様々な規格やフレームワークとの整合を図りながら絶えず進化している、というような趣旨の回答を得ました。

この共通フレームにおいて非常に注目すべき点は、要件定義という「何を作るのかを定義する」プロセスが、2007年9月に公表された共通フレーム2007において新設されている点です。また、私自身が要件定義の重要性を再認識し、その方法論を見直したのは今年の春ごろです。要は、比較的最近になって上流工程の再整備が始められたという点です。
これ以前はひと世代前のSDEMの開発工程のように、要件定義は設計工程の一部分として捉えられていたのです。しかし、システム開発にスピードと低コスト、複雑性が増す一方で安定性はより強く求められる。簡単にいってこのような開発パラダイムが支配しだしたとき、要件定義の重要性がクローズアップされてきたのです。そして私も、次期基幹システムで人生最大規模のシステム開発に着手し、自分の方法論の未熟さを痛感することで、やっと要件定義の重要性を再認識できたのです。「知っている」ことと、実体験を伴った「本当の理解」とは、全く違うものだと私は思います。

さて、私はSDEMに影響を受けているので、システム開発の工程を次のように捉えています。

• システム化の構想と企画(VP,SP)
• 要件定義(RD)
• ユーザーインターフェース設計(UI)
• システム構造設計(SS)
• 製造工程(PS,PG,PT)
• 結合テスト(IT)
• システムテスト(ST)
• 運用テスト(OT)
• システム運用保守(OM)

これらの工程のうち、ビジネスルールを固めていくのは、RDとUIのふた行程です。RDでビジネスルールを洗い出し、UIでその詳細を設計するというのが一般論でしょうか。しかし、設計過程でビジネスルールの複雑性が露呈することによって、工数が増えるという問題が発生しがちです。SDEM等では契約を工程毎に分割することでリスクをヘッジすることを提唱していますが、これは根本的な解決にはならず、むしろ開発陣に甘えを与えかねません。また、工程毎にシステム要件や見積りのレベルに合意をとる、というのは論理としてはあるのでしょうが、「先に起こることをあらかじめ知っていること」が最大のリスクコントロールであるとした時、あまり効果があるとは私には思えません。

システム開発の問題の本質は、現実世界からシステム世界への変換過程において、その変換の対象と変換方法を正確に知るのが工程のかなり後にあることです。となると、要件定義において、ビジネスルールを明らかにするべきなのは明らかなのですが、実務上の課題は、どのレベルをもって明らかであるとするかです。
これには試行錯誤と実体験を重ねる時間が必要でしょうが、今時点として次のような条件が考えられます。

• ビジネスルールのすべてがRDRAの機能モデルとして洗い出されていること。
• すべてのビジネスルールについて、インプットとアウトプットがRDRAの各モデルと結合する形で洗い出されていること。
• ビジネスルールをコードに変換する際の問題や課題について、経営層、管理層、実務層といったユーザーと開発陣が議論をし、リスクについて評価できること。

まだまだ研究すべきことがシステム開発にはたくさんあります…

関連記事
簡単なソフトウェアを作ってみよう
性質変換によるデスクワークの工場化
ソフトウェアの開発プロセスについて
Open Knowledge System
流麗な上流工程の研究（メモ）
コンテキストモデル（カスタマイズ版）
流麗なシステム開発の上流工程を実現するために
小さな要件開発
システム開発の要件定義に関する考察
要件開発の進め方～私のRDRA運用法～
RDRA(2) - RDRAとの出会い
RDRA