システム開発の要件定義は、「欲しい機能を並べる作業」だけではありません。解決したい業務課題と、完成時に満たすべき条件を、発注者と開発者で共有する工程です。専門的な仕様書を書けなくても、現在の帳票と作業の流れ、困っている場面を用意すれば、話を具体化できます。

要望と要件を分ける

「スマートフォンで使いたい」は要望です。そこから「外出中の担当者が、担当案件の進捗を更新できる」「通信できない場合は送信失敗が分かる」など、利用場面と確認方法へ落とし込みます。見た目や技術名を先に固定すると、より簡単な方法を選べなくなることがあります。

発注者が準備する7つの情報

情報準備する内容
目的と課題何が起き、誰が困り、どの状態を目指すか
業務の流れ開始から完了までの担当、入力、確認、承認
利用者と権限利用部署、社外利用、閲覧・編集・承認範囲
管理するデータ現行台帳、項目の意味、件数、保存期間
例外と連携差し戻し、取消、重複、外部サービスとの接続
運用の条件利用時間、停止の影響、バックアップ、問い合わせ先
予算・時期・承認上限の考え方、必須期限、社内の決裁者

機能一覧には理由と優先度を添える

各機能に「必要な理由」「初回必須か」「後回しにできるか」を記入します。たとえば案件管理なら、案件登録・担当者設定・状態変更を初回の核にし、複雑な分析画面は運用後に検討する方法があります。これは構成の例であり、すべての開発に同じ優先順位が当てはまるわけではありません。

優先度は声の大きさではなく、使えないと業務が止まるか、代替手段があるかで話し合います。制約がある場合は、公開範囲を小さくして実際に使いながら改善できるか検討します。

受け入れ条件の記入例

「権限管理がある」だけでは完成を判断しにくいため、操作と結果をセットで書きます。

  • 担当者は自分の案件を編集でき、他部署の非公開案件は閲覧できない
  • 承認済みの申請を変更するときは、変更理由と再承認が必要になる
  • 同じ番号のデータを登録すると、重複を知らせる
  • 必須項目が空欄のとき、保存せず修正箇所を表示する
  • 帳票の合計値が、合意したサンプルデータの期待値と一致する

画面以外の条件も忘れずに決める

誰が利用者を追加するか、障害時にどこへ連絡するか、データをどう取り出すかも要件です。処理速度や同時利用については「速い」「大人数」ではなく、業務に基づく目安と測定条件を話し合います。個人情報を扱う場合は、扱う範囲と利用目的、アクセス制限、保管や削除の方針も確認します。

合意後の変更は差分を残す

開発中に要望が増えることはあります。変更の内容、必要な理由、費用や納期への影響、判断者を記録して合意します。口頭で決めた内容も要件一覧に戻し、「前に話したはず」という認識違いを防ぎます。

よくある質問

要件が全部決まってから相談するべきですか？

すべてを確定させる必要はありません。決まっている条件と未確定の論点を分け、調査や試作が必要な箇所を相談します。見積もりの前提も一緒に確認してください。

現場と経営者の希望が違う場合は？

現場の作業と、経営上の目的をそれぞれ書き出します。初回の対象範囲と最終決裁者を定め、開発会社だけに優先順位の判断を任せないようにします。

まず現行資料と課題を持ち寄る

最初の打ち合わせには、現行の帳票、操作手順、困っている具体例が役立ちます。AQUVELのシステム・アプリ開発では業務課題と必要な情報の流れを整理します。