目的を徐々に明確にする
システムの目的・価値を明らかにすると個々の要件を定義することが容易になります。課題を解決する案が複数あったときにも、目的があることで判断が容易になります。さらにシステムの概要や目的などを考えることは、物事を集約していく方向で思考することになり、新たな発見や本質的に重要なことに気づくきっかけになります。
このようにシステムの目的・価値を明らかにすることは大事なことですが、通常は目的があいまいなままプロジェクトが進んでいくか、目標を最初に掲げてもすぐに忘れられ、顧みられることなく進んでいくプロジェクトがほとんどです。既存システムの再構築の場合は「システム化の目的？ 既存システムの再構築に改めて目的なんか考えてもしょうがない」という反応が返ってくることがあります。
システム化の目的や概要などは最初に決めておくものと思われがちですが、実際には最初から決めることは困難です。システム化の目的は要件定義を進めていく中で決めていくものです。「このシステムのポイントは何か」「どのような方向性でシステム化すればいいのか」などを考えながら要件を組み立てていくことで見えてきます。例えば、数十年使われている基幹システムの場合は「今回のシステム再構築のテーマは何か」のように「今回のテーマ」として考えます。今の会社を取り巻く状況を意識し、それに対応するための「今日的なテーマは何か」と問いかけることで今回の再構築の意義が見えてきます。
システムの目的・価値についてもマイルストーン毎のレビューにおいて確認をとり、最終的なものに洗練化します。
全体を俯瞰する
少し大きなシステムになるとすぐに要件定義の情報量が大量になります。しかし、大量の情報をそのままにしては全体像を把握することができません。量をコントロールするためには情報を分類し、分類された情報を一覧できることが求められます。マクロな視点で説明するときには全体を俯瞰できるものを手がかりに説明することが有効です。ある程度要件定義が進んだところで全体を俯瞰できるように情報を分類します。
作業量を調整する
RDRAでは要件定義として定義情報が決められています。しかし、プロジェクトの特性に合わせて定義する情報を絞り込むことが必要です。必要最低限度の情報に絞り込み、その関係性を決めることで作業量を減らすことができます。
例えばプロジェクトの状況は千差万別なので、状況に合わせて定義する内容とつなぎ方を変えます。ユースケースがある程度見えているプロジェクトの場合は、利用シーンを作成せずにアクターから直接ユースケースを洗い出します。同じく画面がある程度洗い出されている場合は、アクターから直接画面を結んで、アクター→画面→機能→データと結んでも構いません。あくまでもプロジェクトの状況やメンバーの経験などを踏まえて定義する内容を決めることが重要です。
表1に当てはめると「状況把握」のフェーズが終わったところで、プロジェクトの特性がほぼ見えてくるので、そこで改めて定義する情報と粒度を決め作業量を調整します。
