はじめに：システム開発の失敗は「要件定義」で決まる

システム開発プロジェクトの失敗原因を調査すると、技術的な問題よりも「要件定義の不備」が最も多いという結果が出ています。

「作ってみたら、思っていたものと違った」 「途中で要望が増えて、費用が当初の2倍になった」 「完成したけど、現場が使ってくれない」

これらはすべて、開発前の要件整理が不十分だったことが原因です。

逆に言えば、要件定義をしっかり行うだけで、開発の成功率は劇的に上がります。そして、要件定義は専門知識がなくても、発注者側で十分に行えます。

本記事では、中小企業の経営者・担当者が、開発会社に依頼する前に自分でできる要件整理の方法を、具体的な手順とテンプレートで解説します。

要件定義とは何か

要件定義とは、「このシステムで何を実現したいか」を具体的に言語化する作業です。

家を建てる例で考えると分かりやすいです。

  • 要件定義なし：「家を建ててください」→ 大工が想像で作る → 思っていたものと違う
  • 要件定義あり：「3LDK、駐車場2台分、予算3000万円、来年3月完成」→ 具体的な設計が可能

システム開発も同じです。「業務を効率化したい」という漠然とした要望では、開発会社は何を作ればいいか分かりません。

ステップ1：「現状の業務フロー」を書き出す

まず、今どのように業務を行っているかを書き出します。

書き出す内容

  1. 誰が（担当者・役職）
  2. 何を（作業内容）
  3. どのツールで（Excel・紙・メールなど）
  4. どのくらいの頻度で（毎日・週1・月1など）
  5. どのくらいの時間がかかるか（1回あたり何分・何時間）

現状フローの例（受注管理業務）


1. 営業担当者がメールで受注内容を受け取る（毎日5〜10件）
2. 受注内容をExcelの受注台帳に手入力する（1件あたり5分）
3. 在庫担当者に電話で在庫確認をする（1件あたり3分）
4. 在庫があれば、Excelで出荷指示書を作成してプリントアウト（1件あたり10分）
5. 出荷後、受注台帳の「出荷済み」欄に手動でチェックを入れる
6. 月末に受注台帳を集計して売上レポートを作成（月1回・3時間）

この書き出しをするだけで、「どこが一番の無駄か」「どこをシステム化すれば効果が大きいか」が見えてきます。

ステップ2：「課題・ボトルネック」を特定する

現状フローを書き出したら、次に「困っていること」「無駄だと感じること」を洗い出します。

課題の洗い出し方

以下の質問に答えてみてください。

ミスに関する質問：

  • 入力ミスや転記ミスはどのくらいの頻度で発生するか？
  • ミスが発生したとき、修正にどのくらい時間がかかるか？
  • ミスによって顧客クレームや損失が発生したことはあるか？

時間に関する質問：

  • 最も時間がかかっている作業は何か？
  • 「この作業、なくなればいいのに」と思う作業は何か？
  • 担当者が休んだとき、誰も対応できない業務はあるか？

情報共有に関する質問：

  • 「あの情報、どこにある？」と探す時間はどのくらいか？
  • 複数人が同じファイルを同時に編集しようとしてトラブルになることはあるか？
  • 最新の情報がどれか分からなくなることはあるか？

課題の優先順位付け

洗い出した課題を、以下の2軸で評価します。

課題発生頻度影響の大きさ優先度
受注台帳への手入力毎日大（ミスが顧客クレームに直結）高
月末の売上集計月1回中（3時間かかるが月1回）中
在庫確認の電話毎日中（時間がかかるが致命的ではない）中

発生頻度が高く、影響が大きい課題から優先的にシステム化するのが、費用対効果を最大化するコツです。

ステップ3：「実現したいこと」を機能として書き出す

課題が特定できたら、「それをシステムでどう解決したいか」を機能として書き出します。

機能の書き方

悪い書き方（曖昧）：

  • 「受注管理を効率化したい」
  • 「情報共有をスムーズにしたい」

良い書き方（具体的）：

  • 「メールで受け取った受注内容を、Webフォームから入力できるようにしたい」
  • 「入力した受注データを、在庫担当者がリアルタイムで確認できるようにしたい」
  • 「受注データから出荷指示書をPDFで自動生成できるようにしたい」
  • 「月末に受注データを自動集計して、売上レポートをCSVで出力できるようにしたい」

機能の分類

機能は「必須」「あれば便利」「将来的に欲しい」の3段階に分類します。

必須機能（MVP：最小限の価値を提供する機能）：

  • これがなければシステムを使う意味がない機能
  • 最初のリリースに必ず含める

あれば便利な機能：

  • あると業務がさらに楽になるが、なくても業務は回る機能
  • 予算に余裕があれば追加する

将来的に欲しい機能：

  • 今は不要だが、将来的に追加したい機能
  • 設計時に「拡張できる余地」を残してもらうよう伝える

ステップ4：「非機能要件」を整理する

機能（何ができるか）以外にも、システムに求める条件があります。これを「非機能要件」と言います。

確認すべき非機能要件

利用者に関して：

  • 何人が使うか（3人？10人？100人？）
  • どのデバイスで使うか（PC・スマートフォン・タブレット）
  • ITリテラシーはどの程度か（PC操作が得意な人が多い？苦手な人が多い？）

データに関して：

  • 扱うデータの件数（顧客数・商品数・月間取引件数など）
  • 過去データの移行は必要か（既存のExcelデータをシステムに取り込む必要があるか）
  • データのバックアップはどのくらいの頻度で必要か

セキュリティに関して：

  • 個人情報や機密情報を扱うか
  • 社外からアクセスする必要があるか
  • ユーザーごとに見られる情報を制限する必要があるか（権限管理）

運用に関して：

  • システムが止まっても許容できる時間はどのくらいか（24時間365日必要？平日日中だけ？）
  • 社内にシステムを管理できる人材はいるか
  • 保守・更新は自分たちで行うか、外部に依頼するか

ステップ5：要件定義書のテンプレート

以下のテンプレートを使って、要件定義書を作成してください。A4用紙2〜3枚程度にまとめることを目標にします。

【システム要件定義書】

1. プロジェクト概要

  • システム名：〇〇管理システム
  • 目的：〇〇業務の効率化（現在〇時間かかっている作業を〇分に短縮）
  • 対象業務：〇〇部門の〇〇業務

2. 現状の課題

  • 課題1：〇〇（発生頻度：毎日、影響：〇〇）
  • 課題2：〇〇（発生頻度：月1回、影響：〇〇）

3. 必須機能（MVP）

  • 機能1：〇〇できる
  • 機能2：〇〇できる
  • 機能3：〇〇できる

4. あれば便利な機能

  • 機能A：〇〇できる
  • 機能B：〇〇できる

5. 利用者・環境

  • 利用者数：〇名
  • 利用デバイス：PC・スマートフォン
  • アクセス環境：社内のみ / 社外からも必要

6. データ

  • 主なデータ：顧客情報（約〇件）、商品情報（約〇件）
  • 既存データの移行：あり（Excelファイル〇個）/ なし

7. 予算・スケジュール

  • 予算上限：〇〇万円
  • 公開希望時期：〇年〇月

8. 参考サイト・イメージ

  • 参考URL1：〇〇（ここの〇〇の部分が参考になる）
  • 参考URL2：〇〇

まとめ：要件定義は「発注者の仕事」

要件定義は、開発会社がやってくれるものではありません。「何を作りたいか」を一番よく知っているのは、発注者であるあなた自身です。

開発会社は「どう作るか」のプロですが、「何を作るか」は発注者が決める必要があります。

この記事で紹介した5つのステップを実践するだけで、開発会社との打ち合わせがスムーズになり、見積もりの精度が上がり、結果として開発コストを抑えることができます。

要件定義の5ステップ：

  1. 現状の業務フローを書き出す
  2. 課題・ボトルネックを特定する
  3. 実現したいことを機能として書き出す
  4. 非機能要件を整理する
  5. 要件定義書にまとめる

要件定義から一緒に進めます

「要件定義書を作ってみたけど、これで合っているか不安」「そもそも何から始めればいいか分からない」という方も、ぜひご相談ください。

monouでは、要件定義のヒアリングから一緒に行っています。現状の業務フローをお聞きし、「どこをシステム化すれば最も効果が出るか」をプロの視点でアドバイスします。

初回のご相談は無料です。お問い合わせからお気軽にどうぞ。