要件定義とは、システムや業務改善で「何を作るのか」「何を解決するのか」「どこまでやるのか」を決める工程です。
AI・DXプロジェクトでは、要件定義が曖昧なまま進むと失敗しやすくなります。AIツールを導入したのに使われない、簡易ツールを作ったのに現場の業務と合わない、想定外の運用負荷が増える。こうした失敗は、最初の整理不足から起きることが多いです。
この記事では、中小企業のAI導入、業務効率化、簡易ツール開発で使える要件定義の手順を整理します。
この記事でわかること
- AI・DXプロジェクトで要件定義が曖昧だと起きる失敗
- 現状業務、課題、対象範囲、業務フロー、権限、テスト条件の整理方法
- AIコーディングや簡易ツール開発で、最初に文章化すべき項目
- ベンダーやAIに依頼する前に、発注者側で決めるべきこと
筆者は、事業会社で複数のシステム開発を担当し、要件定義、ベンダー折衝、テスト、リリース、保守運用まで一貫して見てきました。その経験上、要件定義の質は、納品物の品質だけでなく、運用開始後に現場で使われ続けるかにも直結します。
要件定義で決めること
要件定義では、主に次の項目を決めます。
| 項目 | 決めること |
|---|---|
| 目的 | 何を改善したいのか |
| 対象範囲 | どの業務を対象にするのか |
| 利用者 | 誰が使うのか |
| 業務フロー | 現在と改善後の流れ |
| 機能 | 何ができる必要があるか |
| データ | 何を入力・保存・出力するか |
| 権限 | 誰が見られるか、編集できるか |
| 非機能 | セキュリティ、速度、運用、保守 |
| テスト | 何ができたら完了とするか |
要件定義は、分厚い資料を作ることが目的ではありません。関係者の認識を合わせ、作るものを絞ることが目的です。
要件定義を甘く見ると起きること（実務での経験）
要件定義を初めて担当したとき、最も強く感じた違和感は「システム会社（ベンダー）がそこは決めてくれるんじゃないか」という思い込みでした。やりたいことを伝えれば、なんとなくシステムができると考えていましたが、それでは時間をかけて質の低いものができてしまうことを実際に体感しました。
そこから、要件定義は「依頼する力」ではなく「自分の中で仕様を組み立てる力」だと考えるようになりました。曖昧なまま依頼すると、ベンダーは「決めてもらえなかった部分」を自己判断で埋めるしかなく、発注者の意図とずれたものができあがります。中小企業のAI導入や簡易ツール開発でも、同じことが起きます。
以降は、ユースケースのリスト、業務フローの分岐を示すワークフロー図、ケース別の挙動資料、テスト仕様書という複数の観点から、自分が考えられる最小レベルまで要件を資料化することを意識するようにしました。データがどの状態からどの状態へ遷移するかという感覚は、要件定義そのものより、日常的にExcelの関数を組んできた経験から培われたと感じています。
AIコーディングを使う場合も、要件定義は省略できません。むしろ、AIに正しく作らせるためには、最初の言語化が重要になります。目的、必要な機能、管理したいステータス、入力と出力、例外時の動き、ログの出し方まで伝えると、実装のズレを減らせます。
手順1. 現状業務を書き出す
最初に、今の業務をそのまま書き出します。
例:
- 問い合わせフォームからメールが届く
- 担当者が内容を読む
- 見積もり、採用、既存顧客、その他に分ける
- スプレッドシートに転記する
- 担当者へ連絡する
- 返信文を作成する
この段階では、改善案を出しすぎない方がよいです。まず現状を正確に見ることが大切です。
手順2. 困っていることを整理する
次に、現状業務のどこに問題があるかを整理します。
- 時間がかかる
- ミスが起きる
- 属人化している
- 対応が遅れる
- データが散らばっている
- 確認漏れがある
「AIを使いたい」ではなく、「何に困っているのか」を言語化します。
手順3. 対象範囲を絞る
AI・DXプロジェクトで失敗しやすいのは、最初から全部を改善しようとすることです。
最初は、対象範囲を絞ります。
例:
- 問い合わせの自動返信まではしない
- まず分類と返信下書きだけ作る
- 個人情報は保存しない
- 管理画面は作らず、スプレッドシートで始める
「やること」だけでなく「やらないこと」を決めると、費用と期間を抑えやすくなります。
小規模なDXでは、最初から中規模システムを作るより、既存のExcel、Google Drive、Slack、WordPressなどをどう使い続けるかも含めて考える方が現実的です。たとえば、Driveに置かれたExcelをGASで処理する、更新をチャットへ通知する、記事更新をAPI投稿で効率化する、といった形なら、現場の運用を大きく変えずに始められます。
手順4. 改善後の業務フローを作る
改善後の流れを書きます。
例:
- 問い合わせが届く
- GASでスプレッドシートへ記録する
- AIが内容を分類する
- 返信下書きを作る
- 担当者が確認する
- 必要に応じて送信する
ポイントは、AIの出力をどこで人が確認するかです。最初から完全自動化するのではなく、人の確認ポイントを残す方が安全です。
手順5. 必要な機能を一覧化する
次に、必要な機能を整理します。
例:
- 問い合わせ内容を保存する
- 種別を分類する
- 担当者を表示する
- 返信下書きを作る
- 対応済みフラグを付ける
- エラー時に通知する
このとき、「必須」と「後でよい」を分けます。
| 優先度 | 例 |
|---|---|
| 必須 | 保存、分類、確認、担当者表示 |
| できれば | 返信下書き、通知、集計 |
| 後でよい | 管理画面、詳細分析、外部連携 |
簡易ツール開発では、最初から見た目の整った管理画面を作るより、スプレッドシートや既存ツールで検証する方が早いことがあります。逆に、複数人で使う、権限管理が必要、継続的に保守する、データが増え続ける場合は、早めにプラグイン化やシステム化を検討した方がよいです。
手順6. データと権限を決める
AI・DXでは、データの扱いが重要です。
次の点を決めます。
- 何を保存するか
- どこに保存するか
- 個人情報を含むか
- 誰が閲覧できるか
- 誰が編集できるか
- どれくらい保存するか
APIキー、顧客情報、契約情報、売上情報を扱う場合は、特に慎重に決める必要があります。
手順7. 完了条件を決める
最後に、何ができたら完了とするかを決めます。
例:
- 問い合わせを3分類できる
- スプレッドシートに自動記録される
- 担当者が確認できる
- 10件のテストデータで問題なく動く
- エラー時に止まる
- 操作手順が残っている
完了条件が曖昧だと、いつまでも修正が続きます。小さな検証でも、完了条件は必要です。
品質確認では、動作だけでなく、ログ、セキュリティ、性能、SEO、デザインも見ます。特にWordPressプラグインや自動投稿ツールでは、想定外のページが大量に生成されていないか、低品質ページが公開されていないか、内部リンクが自然かを確認します。
要件定義チェックリスト
AI・DXプロジェクトでは、次の項目を最低限確認してから実装に進みます。
| 観点 | 確認すること |
|---|---|
| 目的 | 時間削減、ミス削減、売上改善、対応速度向上など何を狙うか |
| 現状業務 | 誰が、いつ、どのツールで、何を判断しているか |
| 対象外 | 今回やらないこと、後回しにすること |
| 入力 | どのデータを受け取り、どの形式で扱うか |
| 出力 | 画面、CSV、メール、通知、レポートなど何を返すか |
| 権限 | 誰が閲覧、編集、削除、承認できるか |
| 例外 | エラー時、データ不足時、担当者不在時にどうするか |
| ログ | 後から原因を追える情報を残すか |
| テスト | どのケースが通れば完了とするか |
| 運用 | 誰が保守し、改善要望をどこに集めるか |
この表を埋めるだけでも、AIやベンダーへの依頼精度は上がります。特に、入力、出力、例外、ログ、テスト条件が抜けると、実装後の手戻りが増えやすくなります。
AIを使う要件定義の注意点
AIコーディングやバイブコーディングでは、要件定義がさらに重要になります。
AIはコードを書くのは速いですが、目的が曖昧だと違うものを作ります。依頼するときは、次のように伝えます。
目的:
問い合わせ対応の初動を早くしたい。
対象範囲:
自動返信はしない。分類と返信下書きまで。
入力:
問い合わせ本文、メールアドレス、受信日時。
出力:
分類、担当者、返信下書き。
制約:
個人情報を外部に送らない。担当者が確認してから返信する。このくらい整理してからAIに依頼すると、修正回数を減らせます。
さらに、実装前にAIへ次の成果物を作らせると進めやすくなります。
- 要件定義メモ
- 詳細設計
- 実装計画
- テスト観点
- 不明点リスト
- 改善機能の提案
最初の依頼文だけで足りない場合は、AIに不明点を質問させます。人が答えた内容を設計メモへ反映してから実装に進むと、希望と違うものができるリスクを下げられます。
ベンダーに依頼するときの注意点
外部ベンダーに依頼する場合でも、「良い感じに作ってください」ではうまくいきません。ベンダーは、決まっていないことを推測で埋めるしかないためです。
依頼前には、少なくとも次の資料を用意します。
- 現状の業務フロー
- 改善後の業務フロー
- 必須機能と後回しにする機能
- 画面や管理画面で見たい項目
- 権限とステータスの一覧
- テストしたいケース
- 運用開始後の問い合わせ先と保守範囲
発注者側が業務を整理できているほど、見積もり、スケジュール、品質確認がしやすくなります。要件定義はベンダーに丸投げする作業ではなく、発注者とベンダーが認識を合わせるための土台です。
まとめ
要件定義は、AI・DXプロジェクトの土台です。
現状業務、困っていること、対象範囲、改善後フロー、必要機能、データ、権限、完了条件を整理することで、作るものが明確になります。
最初から大きなシステムを作る必要はありません。小さく範囲を決め、動くものを作り、現場で試すことが重要です。
要件定義・業務改善の相談
local-navi.jpでは、AI導入、業務効率化、簡易ツール開発のための要件整理から相談できます。
デジタル化支援として業務整理から入り、必要に応じて簡易ツール、中規模システム、保守運用まで段階的に進める相談も可能です。
