要件定義で「決めたつもり」をなくす:発注者が見落としがちな要件と、良い要件の書き方

投稿日:

システム開発でもめる原因の多くは、「言った・言わない」です。

「CSVで出力できるのは当然だと思っていた」 「退職した社員のアカウントを止める機能がない」 「月末の締め処理だけ、手作業が残ってしまった」

どれも技術の問題ではありません。要件定義の段階で、誰も言葉にしなかった要件です。

要件定義とは、システムで何を実現するかを発注者と開発会社で言葉にし、合意する工程です。この記事では、社内にエンジニアがいない発注者向けに、「決めたつもり」をなくすための具体的な方法を、見落としやすい要件のチェックリストとあわせて紹介します。

要件には2種類ある

種類 意味 例
機能要件 システムが「何をするか」 受注を登録する、在庫数を表示する
非機能要件 「どのくらいの品質で動くか」 同時に何人使うか、どの程度止まってよいか

発注者が考えやすいのは機能要件です。しかし、見積もりに大きく効くのは、むしろ非機能要件のほうです。後ほど詳しく説明します。

「曖昧な要件」と「良い要件」の違い

要件定義書に書かれた一文が、人によって違う意味に読めると、後で必ずずれが生じます。

曖昧な要件 良い要件
在庫を管理できる 倉庫担当者が入庫・出庫を登録すると、商品ごとの在庫数がすぐに反映される。在庫が設定値を下回ったら購買担当にメールで通知する
使いやすい画面 受注1件の登録が、現在のExcel入力(約3分)より短い時間で完了する
検索できる 顧客名・受注日・担当者の組み合わせで検索でき、1万件の中から3秒以内に結果を表示する

良い要件には、誰が・何をすると・どうなるかと、確かめられる基準が入っています。

「受け入れ条件」をセットで書く

おすすめの書き方は、要件ごとに「受け入れ条件」を添えることです。受け入れ条件とは、完成したときに「これができていれば合格」と判断する条件のことです。

要件:営業担当として、外出先から受注状況を確認したい。顧客からの問い合わせにその場で答えるためだ。 受け入れ条件

  • スマートフォンのブラウザで受注一覧が見られる
  • 自分の担当顧客の受注だけが表示される
  • 出荷済み・未出荷が一目で区別できる

受け入れ条件があると、開発会社は見積もりを正確に出しやすくなり、発注者は納品時に何を確認すればよいかが明確になります。双方にとってメリットのある書き方です。

見落とされやすい要件チェックリスト

画面に表示される機能は話題にのぼりやすい一方、裏側の機能は抜けがちです。次の項目は、要件定義の打ち合わせで一度は確認しておきましょう。

運用・管理

  • 権限:誰がどの画面を見られ、何を変更できるか(一般社員・管理者・閲覧のみ など)
  • アカウント管理:入社・異動・退職のとき、誰がどう設定を変えるか
  • マスタ管理:商品・顧客・単価などの基本データを、誰が画面から変更できるか
  • 操作の記録:誰がいつ何を変更したかを、後から確認する必要があるか

データ

  • データ移行:今のExcelや既存システムのデータを、どこまで移すか
  • 出力:CSVやExcel、PDFの帳票として出力する必要があるか
  • 他システムとの連携:会計ソフトや既存の基幹システムとデータをやり取りするか
  • バックアップ:データが消えたとき、いつの時点まで戻せればよいか

例外・業務ルール

  • 締め処理:月末・年度末だけの特別な作業はあるか
  • 取り消し・差し戻し:登録した内容を取り消す、承認を差し戻すときの流れ
  • 通知:メールやチャットで誰に何を知らせるか

利用環境

  • 端末:パソコンだけか、スマートフォンやタブレットでも使うか
  • 利用場所:社内だけか、社外や外出先からも使うか

これらは、一つ追加されるたびに工数が増える項目です。「あとで足せばいい」と考えず、最初に「今回やる・やらない」を決めておくことが大切です。

非機能要件は「数字」で決める

「止まらないシステムにしてほしい」「速くしてほしい」は、要件としては曖昧です。数字で決めると、費用との関係が見えるようになります。

例:どの程度止まってよいか

稼働率とは、システムが正常に使える時間の割合です。1ヶ月(30日)で計算すると、次のような違いになります。

稼働率 1ヶ月に止まってよい時間の目安
99% 約7時間12分
99.9% 約43分
99.99% 約4分

数字が一桁違うだけに見えますが、99.99%を目指すには、サーバーを複数の場所に置く、24時間の監視体制を組むといった対策が必要になり、構築費も運用費も大きく変わります。

社内の業務システムで、夜間や休日はほとんど使わないのであれば、そこまでの水準は不要なことが多いです。「業務時間中に止まると困るが、夜間の数時間の停止なら許容できる」といった形で、自社の業務に合った水準を開発会社と話し合いましょう。

決めておきたい非機能要件

  • 同時に使う人数:普段と、ピーク時(月末など)の最大
  • 画面の表示速度:主要な画面が何秒以内に表示されればよいか
  • 復旧までの時間:止まった場合、何時間以内に戻ればよいか
  • データの保存期間:何年分のデータを残す必要があるか
  • セキュリティ:扱う情報の重要度(個人情報や取引先の情報を扱うか)

分からない項目は、「一般的にはどのくらいですか」「水準を上げると費用はどう変わりますか」と開発会社に聞いて構いません。選択肢と費用の関係を説明してもらい、発注者が決めるのが理想的な分担です。

現場ヒアリングで聞くべき質問

要件の抜け漏れは、現場の業務を知らないまま決めることで生まれます。実際にシステムを使う担当者に、次のような質問をしてみてください。

  • 量:「1日に何件くらい処理しますか? 一番多い日はいつ、何件ですか?」
  • 例外:「いつもと違う処理をするのは、どんなときですか?」
  • 理由:「この確認作業は、何のためにしていますか?」
  • 失敗:「ミスが起きやすいのはどこですか? 起きたらどう直していますか?」
  • 工夫:「Excelに独自に追加している列やメモはありますか?」

特に「理由」の質問は重要です。今の作業をそのままシステムに置き換えるのではなく、「その作業は本当に必要か」を見直すきっかけになります。不要な機能を作らずに済めば、費用も期間も抑えられます。

要件定義書を受け取ったら確認したい5つの観点

開発会社がまとめた要件定義書は、承認する前に次の観点で読み返してください。

  1. 目的とのつながり:各機能が、最初に決めた目的のどれに役立つか説明できるか
  2. 優先順位:「必須」「あると良い」「将来」の区別が書かれているか
  3. 受け入れ条件:完成時に合否を判断できる基準が書かれているか
  4. やらないこと:今回は対象外とする範囲が明記されているか
  5. 未決事項:まだ決まっていないことと、いつ誰が決めるかが整理されているか

4番の「やらないこと」は見落とされがちですが、双方の認識をそろえるうえでとても役立ちます。範囲がはっきりしていれば、開発会社も見積もりの前提を説明しやすくなります。

要件は変わる前提で考える

どれだけ丁寧に要件定義をしても、開発が進む中で「やはりこうしたい」は必ず出てきます。大切なのは、変更をなくすことではなく、変更を扱うルールを決めておくことです。

  • 変更の要望は、窓口を一本化して文書で伝える
  • 開発会社に、期間と費用への影響を示してもらってから判断する
  • 新しい要件を入れるときは、優先度の低い要件と入れ替えられないかを考える

最初から全部を作り込まず、必須の機能だけで動くもの(MVP:最小限の機能で動く製品)を先にリリースし、使いながら改善していく進め方も有効です。

要件定義を軽くしてよいケース

  • 既製のサービス(SaaS)を導入する場合:作るのではなく選ぶ作業なので、必須機能の一覧で比較できれば十分なことが多いです。
  • 小規模なウェブサイト制作:目的、掲載内容、参考サイトがそろっていれば短期間で進められます。
  • まず試したい場合:PoC(本格導入の前に、実現性や効果を小さく確かめる検証)で範囲を絞って作り、その結果をもとに要件を固める方法もあります。

一方、業務の中心となるシステムや、複数部署で使うシステムでは、要件定義に十分な時間をかけることをおすすめします。

外部の専門家に相談すべきタイミング

この記事のチェックリストや質問は、発注者だけでも使えます。ただし、次のような場合は自力での判断に限界があります。

  • 非機能要件をどの水準にすべきか、費用とのバランスが判断できない
  • 要件定義書に抜け漏れがないか、技術的な観点で確かめたい
  • 既存システムとの連携やデータ移行が複雑で、影響範囲が読めない
  • 社内の意見がまとまらず、優先順位を第三者の視点で整理したい
  • 開発会社の説明や質問の意図が、技術的に理解しきれない

範囲がはっきりした小規模な開発や、SaaSの導入であれば、この記事の内容を使うだけで十分なことも多いです。

まとめ

  • もめる原因の多くは、誰も言葉にしなかった「見落とされた要件」
  • 要件には「誰が・何をすると・どうなるか」と受け入れ条件を添える
  • 権限・データ移行・出力・締め処理など、裏側の要件をチェックリストで確認する
  • 非機能要件は数字で決め、自社の業務に合った水準を選ぶ
  • 変更は必ず起きる前提で、扱い方のルールを先に決めておく

開発計画を第三者の目で確かめたい方へ

相談先には、知り合いのエンジニア、フリーランスの技術者、技術顧問サービスなどの選択肢があります。TechMO合同会社もその一つとして、開発計画の相談や、開発会社の見積もり・提案書のセカンドオピニオンを受けています。

当社は受託開発も行っていますが、技術顧問としての相談は開発の売り込みを目的としません。他社ベンダーの提案も、発注する側の立場から公平に評価します。発注者と開発会社の話がかみ合い、双方が同じゴールに向かえる状態をつくるお手伝いをします。

「要件定義を始める前に、準備や進め方を相談したい」という方は、開発計画の無料相談を申し込むことから始めてみてください。

← ブログ一覧に戻る