要件開発の進め方～私のRDRA運用法～

　一般に要件定義といわれる工程ですが、私は「要件開発」という呼び方を好んで使います。これは全くの好みの問題ですので、「定義」と同義語とご理解下さい。ただし、一般論に言及するような時は、要件定義と使い分けています（あまり厳密ではありませんが…）。

　さて、今回は私の要件開発の進め方について、その大きな流れをご紹介します。
　これまでご紹介してきたように、私はRDRA（リレーションシップ駆動要件分析）と呼ばれる要件分析方法論を全面的に採用していますので、要件開発の基本的な流れは次のような順番となります。

1. コンテキストモデル
2. 要求モデル
3. 業務モデル
4. 利用シーンモデル
5. 概念モデル
6. ユースケースモデル
7. 画面帳票モデル
8. イベントモデル
9. プロトコルモデル
10. 機能モデル
11. データモデル
12. ドメインモデル

　私の場合は、企業内システム開発者ですので、顧客から提出されたRFPを元に作業するようなことはありません。私もしくは担当部署で描かれたシステム構想を要件としてまとめ、社内で開発したり、外注に出したりという流れになります。したがって、ユーザーがシステム導入によって問題が解決されるだろう、という非常にぼんやりとしたイメージを持っているところが、要件開発の出発点になります。そこで、上記のRDRAの基本工程に、若干のアレンジを加えています。

コンテキストモデルについて
　前述したように、要件開発のスタート時には、ユーザーはぼんやりとしたイメージしか持っていませんので、まずは、現行モデルを作成します。

要求モデルについて
　現行コンテキストモデルを基に、「何か困っていることはありませんか？」とあえて曖昧な質問から入ります。この質問に対するユーザーの回答の粒度はさまざまですが、私が一番着目するのは、ユーザーの関心がどこにあるかです。この関心を「外して」しまうと、そのユーザーにとっては「おもしろくない」作業になってしまい、主体性が低下することで後工程に悪い影響を与えてしまうことを回避するためです。結果として、要件にならないことはありますが、要件開発者に関心を持たれつつ議論を重ね、最終的に合意として要件から外すことになれば、ユーザーの最終的な納得感はかなり高い物になると経験的に捉えています。したがって、ここでのヒアリングは関心の対象を探る程度で比較的短時間で次に進みます。

業務モデルと利用シーンモデル
　業務モデルを「業務フローモデル」と呼称変更し、利用シーンモデルと合わせて業務モデルと再定義しました。これは、業務は「ストック系」（RDRAの利用シーン）と「フロー系」（RDRAの業務モデル）により構成されているという私の持論に基づく再定義です。
　また、業務モデルを描き始める前に、「業務シナリオ」という箇条書きのメモによって現行業務を記述していきます。これは、ユーザーがフローチャートになじみが薄い場合の対応や、テンポ良く業務をヒアリングするために、最初のイテレーションではモデリングを省きます。
　その後、業務シナリオとヒアリングの録音を元に、初版の現行業務モデルを描き、ユーザーにモデルの意味を説明していきながら業務を確認していきます。
　現行業務モデルの確認が終了後、新業務モデルを描きながら併せて要望・要求を聞き出していきます。
　要望、要求、要件の定義についてはRDRA定義のとおりです。
　＊この時には「マジカ」を使うこともあります。

ユースケースモデル
　モデリングにはEnterprise Architectを使用しているので、業務モデルを図として背景化し、そこにユースケースを貼り付けることでこのモデルを作成します。

データモデル
　画面帳票モデルの前に、データモデルをある程度描いてしまいます。これは、画面帳票モデルにデータモデルで作成したデータ項目をドラック&ドロップすることで、生産性を上げるためです。

機能モデル
　これは画面帳票モデルとデータモデルとの複合モデルとして作成します。

　以上を整理すると、次のような工程なります。

1. コンテキストモデル
2. 要求モデル
3. 業務シナリオ
4. 業務モデル
1. 業務フローモデル
2. 利用シーンモデル
5. 概念モデル
6. ユースケースモデル
7. データモデル
8.  画面帳票モデル
9. イベントモデル
10. プロトコルモデル
11. 機能モデル
12. ドメインモデル

 　＊上記工程は以前のものです。最新版は「システム開発上流工程のライフサイクルと主要WBS」をご覧ください。

　もちろん、これらの順序は絶対というのではなく、プロジェクトの特性、進捗状況など、臨機応変に変更しますが、基本は以上のとおりです。

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