システム開発の要件定義｜業務の要望を合意できる条件へ整理する

システム開発の要件定義は、利用者の希望や業務上の課題を整理し、作るシステムが満たす条件について関係者の認識を合わせる工程です。「使いやすくしたい」「手作業を減らしたい」という言葉から、誰が、どの場面で、何をできればよいかへ具体化します。

要件定義書の項目を埋める前に、今回の対象と、決める必要がある業務上のルールをそろえましょう。この記事では、架空の備品貸出を例に、要望を合意できる条件へ変える流れを示します。

要望を集めることと、要件を決めることは違う

IPAは、利用者のニーズや課題から要求を抽出し、関係者と合意して要件としてまとめる流れを説明しています。業務の観点からの要求と、それを実現するシステムへの要求を分けて整理することが出発点です。IPA「要件定義とは」

要望をすべて一覧へ転記しただけでは、意見がぶつかったときの優先順位や、今回作らない範囲が残ります。現場の困りごと、責任者が改善したい結果、予算や期日などの制約を分けて整理してください。

「便利な画面」を先に考えるより、その画面を使って終わらせたい仕事を一つ選ぶと、必要な条件を具体化できます。

以下は説明用の架空の業務です。実在の会社の要件定義書や、テクノヴァースの実績ではありません。

社員が共用備品を借りる際に、貸出表への記入漏れと、返却状況の確認に困っているとします。この要望を次のように整理します。

段階	整理する内容	記入例
困りごと	何ができず、誰が困るか	管理担当が未返却の備品を探すため、個別に確認している
業務の目標	どの判断を可能にするか	管理担当が、現在の貸出先と返却予定を確認できる
機能の条件	誰がどんな操作をするか	借りる社員が備品と返却予定を登録し、管理担当が一覧を見る
例外	通常どおり進まない場合	予定日を過ぎた備品、紛失した備品を別に扱う
対象外	今回は何を作らないか	備品購入や経費精算の処理は含めない

「登録画面がある」だけでは、記入漏れという困りごとを解決できるか判断できません。誰がいつ登録するか、未登録をどこで確認するかなど、システム外の業務も含めて話し合います。

通常の貸出だけ決めると、取消しや返却予定の変更で判断が止まることがあります。すべての例外を想像して増やすのではなく、現行業務で実際に起こる場面から確認します。

仮例なら、申請した人と借りる人が違う場合、管理担当が代理で修正する場合、退職や異動で貸出先が変わる場合などが質問候補です。必要な場面かどうかは業務担当が確認します。

権限も「管理者が使う」とだけ書かず、閲覧、登録、修正、取消しを分けます。ただし具体的な実装方法までこの時点で固定する必要があるかは、開発担当と相談してください。必要な状態と、実現する技術を混ぜないようにします。

IPAの解説では、システムへの要求を機能面と非機能面から分析します。IPA「システム化要求を定義する」

例えば、利用する時間帯、同時に使う人数、データを残す期間、障害時の業務継続などは、画面一覧だけでは決まりません。備品を貸し出す場所で通信が使えない場合にどうするかも、運用と合わせて確認したい点です。

数字を置く場合は「一般的にこの程度」で埋めず、実際の利用状況や必要な業務から決めます。応答時間や復旧の条件を詳しく整理する方法は、非機能要件の決め方を参照してください。

条件が曖昧なままでは、完成後に満たしたかを判断しにくくなります。以下は確認可能性を確かめるための例です。受入テストの全項目ではありません。

要件の候補	合意前に確かめる問い
管理担当が貸出中の備品を一覧で見られる	貸出中と返却済みのデータを分けて表示できればよいか
社員は自分の返却予定を変更できる	他人の予定は変更できない条件も必要か
紛失は通常の返却と別に管理する	どの担当が状態を変え、一覧でどう区別するか

「何を試せば分かるか」を考えて答えが出ない場合は、対象や条件をもう一段具体化する余地があります。確認方法の準備は、受入テストの準備へつながります。

すべてが一度に決まるとは限りません。未決事項には、質問、決める担当、影響する範囲、確認する時点を付けます。仮置きした条件を確定事項と同じ欄に混ぜないことが重要です。

合意後に要求が変わったときは、元の要件を消して書き換えるだけでなく、変更理由と影響する設計・テストを確認します。変更自体を禁止するためではなく、関係者が同じ前提で次の作業へ進むためです。

最初の打ち合わせには、現在の仕事の流れと困る場面を一つ持ち寄ってみてください。機能名より先に、その業務で成立させたい条件を整理できます。開発体制については、テクノヴァースのSES事業をご覧ください。