はじめに
この記事に興味を示された方であれば、一度は次のような経験があるのではないでしょうか。
「今日も結論が出なかったので次回までに解決案を考えてきてください」
（何度も結論の出ない会議が続く……）
「まだ方向性が見えないので各自できるところをやってください」
（要件定義として何をやればいいかが明確でないまま、とりあえずできることをやっている）
「要件定義にはこの資料が必要だ！ いやこのドキュメントの方が重要だ……」
（要件定義の方法についての議論ばかりで肝心の要件の検討に入れない）
「多くのドキュメントを作成しているけどシステム化の目的が分からない」
（既存システムのドキュメントの焼き直しばかりで今回のシステム化の目的や価値が分からない）
プロジェクトリーダーの過去の経験やその会社で古くから行われている方式で要件定義を進めているケースをよく見かけます。問題を抱えているプロジェクトの多くが、そのプロジェクトの特性を考慮せず、要件定義のゴールも明確でないまま漫然と要件定義工程を進めています。
一方大量にドキュメントを作成しているプロジェクトの多くに共通するのが、成果物ベースでの管理の弊害です。成果物の作成だけに躍起になり、肝心のシステムの中身についての議論のないまま成果物だけが積み上がっている状況です。
『要件定義の勘どころ』の記事を書いた後、私のもとには「より具体的な話を聞きたい」「実際のプロジェクトで起こる問題にどのように応用するのか」という声をいただきました。
そこで今回は私が策定した「リレーションシップ駆動要件分析（RDRA）」をもとに、より具体的に要件定義を行う方法について連載します。
リレーションシップ駆動要件分析（RDRA）
この手法は「Relationship Driven Requirement Analysis」の頭文字をとって「RDRA（ラドラ）」と呼びます。
名前のとおり情報のリレーションシップを重視しており、そこから効率的に精度高く要件を定義する方式です。近年要件定義においてもトレーサビリティの重要性が叫ばれていますが、この手法に基づいて要件定義を行うと面倒なID管理を行わなくても自動的にトレーサビリティが確保されます。
この連載では要件定義を確実に行うための考え方と進め方、並びに実際に要件を定義するためのツールを紹介し、実プロジェクトでの要件定義のイメージをつかみます。
