要件定義は境界で語る

今から数年前、開発チーム内で要件定義を担当することになった。望んだわけではなく、若いメンバーの多いチームで他に適任がおらず、チームとしての必要にせまられて引き受けた。

最初はリーダーから頼まれたままに作業を進めていたが、ふわふわとしたドキュメントを量産するだけで工程のゴールが見えない。そもそもプロジェクトとして、開発プロセス定義がないのが問題だったが不満を言ってもはじまらない。そこで要件定義に関する書籍を数冊読んでみたが謎は深まるばかりだった。

＊＊＊

パワポ、一覧、詳細

当時参画していたプロジェクトでは、要件定義をリーダーの経験に基づいて進めていた。その手順はおおむね以下の通り。

1)ユーザーから要望をヒアリング
2)パワーポイントに整理（これが要件定義書の位置づけ）
3)整理した内容をユーザーと合意
※1)～3)は合意を達成するまで繰り返す

パワーポイントは、画面のイメージ図（スケッチ / ポンチ絵）に操作説明や業務ロジックを補足したもがメインだった。

また同時に後工程の見積りをするために、機能を分割してシステムの全体像をさぐった。以下のような各種一覧を作成し、個々に定義書を作成して詳細化する。

・機能（オンライン、バッチ）一覧、機能定義
・画面一覧、画面定義
・帳票一覧、帳票定義
・テーブル一覧、テーブル定義
etc..

（完全に余談だが、要件定義の途中で大量生産が開始されてしまうこれらのドキュメントは、要件が変更されるたびに末端の担当者に重い負荷としてのしかかる‥）

自分の経験上ではよくある手順で、小さな機能の追加なら特に問題もなかった。しかし大きな機能の追加やシステムの再構築では各定義の作成（=詳細化）を複数人で担当者するため、しばしば網羅性や整合性が問題になった。

そして個人的には、要件定義と設計の境界があいまいなこの進め方は工程の目的を見失うことも多く、それが大きなストレスになっていた。

＊＊＊

RDRAを知った

最初にRDRA（リレーションシップ駆動要件分析）という要件定義手法を知ったのは、おそらくアジャイル札幌のイベント（たぶん、↓これ）だと思うが、はっきりとは覚えていない。

リレーションシップ駆動要件分析 ☓ ドメイン駆動設計 ☓ アジャイル開発

そのころの自分は要件定義や設計を文章だけで表現することに限界を感じていて、図を多用するもののモデリングのような抽象度の高い分析/表現スキルはなかった。漠然とUMLを学び直す必要性は感じていたと思う。そんな時にイベントで神崎善司さん（株式会社バリューソース / RDRA考案者）から、RDRAの解説でシステム境界という言葉を聞いて、ぼくのもやもやは一気に晴れた。

＊＊＊

システム境界とは

簡単に言うと、RDRAでは要件定義を4つのレイヤーで説明する。ここで画面やユースケースはシステム外部とシステムの境界上にあるとされ、このレイヤーをシステム境界と呼ぶ。

※画像はRDRA2.0ハンドブックより引用

システム境界という用語を使って要件定義と設計の違いを説明すると、おおまかには以下になる。（注：RDRAをもとにした個人的な解釈を多分に含む）

システム境界より外（ユーザー側）が中心→要件定義
システム境界より内（システム側）が中心→設計

よくよく考えてみると当たり前のこの考えに気づかされてからは、前述のストレスは解消された。言語化されてはじめて気づくことってたくさんある。

＊＊＊

この記事は「要件定義とは」の説明のとっかかりにしたい話で、詳細な定義は複数の団体でが発行しているので調べてみるといいと思う。ぼくも調べつつ、下記のページに少しずつまとめているところ。