「発注仕様書を作ってほしい」と社内で言われたものの、何をどこまで書けばいいのか分からず、パソコンの前で手が止まってしまう。そんな経験はないでしょうか。業務システムの発注は、日々の仕事の中で何度も経験するものではありません。テンプレートを検索してみても、専門用語が並ぶだけで自社の状況にどう当てはめればいいのか実感が湧かない。結局、思いつくままに要望を箇条書きにして開発会社に渡し、出来上がったものを見て「思っていたのと違う」と感じる。あるいは開発会社から「これでは見積もりが出せません」と差し戻される。そうした行き違いを繰り返しながら、発注担当者は疲弊していきます。
仕様書の書き方に不安を感じるのは、あなたの能力不足ではありません。仕様書という文書には独特の書き方の作法があり、それを知らずに書けば誰でも同じようにつまずきます。逆に言えば、いくつかのポイントさえ押さえれば、専門知識がなくても認識齟齬の少ない仕様書は書けるようになります。この記事では、要件定義でも稟議書でもなく、開発会社に実際に提示する「発注仕様書」という文書そのものに焦点を当て、何を、どのくらいの粒度で、どう書けば認識齟齬を防げるのかを具体的にお伝えします。
なぜ仕様書の書き方一つで認識齟齬が生まれるのか
発注仕様書は、発注者の頭の中にある業務のイメージを、開発会社という「その業務を知らない他者」に伝えるための翻訳作業です。この翻訳がうまくいかない最大の原因は、発注者と開発会社の間で「当たり前」の基準が違うことにあります。発注者にとっては説明するまでもない社内の常識が、開発会社にとっては初めて聞く情報だという場合がほとんどです。
例えば「在庫を管理できるようにしてほしい」という一文だけを見た場合、発注者の頭の中には具体的な業務フローが浮かんでいます。入荷時にバーコードを読み取り、出荷時に自動で在庫数が減り、一定数を下回ったら発注担当者にメールで通知が届く、といったイメージです。しかし開発会社はその文章から、それらのどこまでを実現すべきなのか読み取ることができません。結果として、開発会社は最も工数の少ない解釈でシステムを組み立て、納品後に「これでは業務が回らない」という食い違いが発覚します。
もう一つの原因は、仕様書に書かれていないことは「対応しない」と解釈されるという商習慣です。口頭の打ち合わせで話した内容や、以心伝心で伝わっていると思い込んでいる要望は、仕様書に文字として残っていなければ契約の対象外として扱われます。仕様書の書き方が甘いということは、開発会社の裁量に委ねる範囲が広がるということであり、その裁量の使われ方が発注者の期待と一致するとは限らないのです。
つまり認識齟齬は、開発会社の理解力の問題ではなく、発注仕様書という文書の設計思想を発注者側が理解していないことから生まれます。次の章から、その設計思想に沿って何を書くべきかを見ていきましょう。
発注仕様書に必ず書くべき項目
発注仕様書には、最低限次の七つの項目を盛り込む必要があります。どれか一つが欠けても、開発会社は独自の解釈で穴を埋めることになり、その解釈が発注者の意図と一致する保証はありません。
1. 業務の現状
今、その業務がどのように行われているかを説明します。誰が、どのようなツールを使い、どのくらいの頻度と量で作業しているかという事実の記述です。ここは主観を交えず、現状をそのまま書くことがポイントです。
2. システム導入の目的
なぜそのシステムが必要なのかという背景です。単なる要望の集合ではなく、達成したい状態を言葉にします。
3. 機能要件
システムが実際に持つべき機能を、業務の流れに沿って具体的に書きます。仕様書の中で最も分量が多くなり、かつ認識齟齬が最も生まれやすい部分です。
4. 非機能要件
性能、セキュリティ、バックアップ、可用性など、機能そのものではないがシステムの品質を左右する条件です。見落とされがちですが、後から追加すると大きなコスト増につながる部分でもあります。
5. 除外項目
今回のシステムに含めないことを明示する項目です。書かれていないことは対応外という商習慣がある以上、あえて「これは対象外です」と書くことで、双方の解釈のずれを未然に防げます。
6. 納期
いつまでに何が完成している必要があるかを具体的な日付で示します。全体の納期だけでなく、テスト期間や研修期間を含めた逆算のスケジュール感も共有できると理想的です。
7. 予算感
正確な金額でなくても構いませんが、想定している予算のレンジを示すことで、開発会社は身の丈に合った提案がしやすくなります。
この七項目は、どれか一つを厚く書けば他が薄くてもよいという関係ではありません。すべてが揃って初めて、開発会社は発注者の意図を立体的に理解できます。次の章では、それぞれの項目を実際にどう書けばよいのか、良い例と悪い例を対比しながら見ていきます。
項目ごとの書き方のポイントと記載例
業務の現状の書き方
業務の現状は、数字と手順を具体的に書くことが要点です。抽象的な感想ではなく、事実の記述に徹します。
悪い例:「現在は紙とエクセルで在庫を管理しており、非効率です。」
良い例:「現在は入荷時に紙の伝票へ手書きで数量を記入し、事務担当者が一日の終わりにエクセルへ転記しています。転記件数は一日あたり平均40件で、月末の棚卸しでは紙の記録とエクセルの数値が一致せず、月に数回は在庫数の再確認作業が発生しています。」
後者は「40件」「月に数回」といった具体的な数字が入っており、開発会社はこの記述からシステムが処理すべきデータ量や、解決すべき課題の重さを推測できます。件数や頻度、担当者の人数といった数字は、思いつく限り仕様書に盛り込んでおくべきです。
目的の書き方
目的は「効率化したい」だけで終わらせず、何がどう変わったら成功と言えるのかまで書きます。
悪い例:「業務を効率化し、ミスを減らしたい。」
良い例:「転記作業にかかっている一日あたり1時間程度の作業時間をゼロにし、棚卸し時の数値不一致を月0件にすることを目指します。」
この書き方をしておくと、開発会社は提案の際に「その目的であればこの機能が必要です」という逆算の提案ができるようになります。目的が具体的であるほど、開発会社からの提案の質も上がります。
機能要件の書き方
機能要件は、認識齟齬が最も起きやすい部分です。動詞を曖昧にしないこと、対象となるデータの範囲を明確にすることが鉄則です。
悪い例:「在庫を管理できるようにしてほしい。」
良い例:「商品ごとに在庫数を登録し、出荷登録が行われた時点で在庫数を自動的に減算します。在庫数が事前に設定した閾値を下回った場合、担当者宛てにメールで通知します。在庫数の変動履歴は過去1年分を画面上で確認できるようにします。」
良い例では、誰が何をしたときに、システムが何をするのかという主語と動詞の関係がすべて書かれています。「管理できるようにしてほしい」という一文は一見具体的に見えますが、実際には「登録」「更新」「削除」「検索」「通知」「履歴保持」のどこまでを含むのか読み手に判断を委ねてしまっています。機能要件を書くときは、必ず「誰が」「何をしたら」「システムが何をするか」という三点セットを意識してください。
非機能要件の書き方
非機能要件は専門的に感じられるため後回しにされがちですが、実は発注者自身の言葉で書ける部分です。
悪い例:「セキュリティを万全にしてほしい。」
良い例:「利用するのは社内の従業員10名のみとし、社外からのアクセスは許可しません。ログイン時にはID・パスワードによる認証を必須とします。データは日次でバックアップを取得し、過去30日分を保持してください。同時に利用する最大人数は10名を想定していますが、将来的に30名まで増える可能性があります。」
非機能要件は専門用語で書く必要はなく、利用人数や利用場所、データの保存期間といった、発注者自身が把握している事実を書くだけで十分に機能します。逆にここを「お任せします」で済ませてしまうと、必要最低限のセキュリティ対策しか組み込まれず、後から追加改修が必要になるケースが多く見られます。
除外項目の書き方
除外項目は、隣接する業務との境界線を引く役割を持ちます。
良い例:「経理システムとの連携は今回のスコープに含みません。会計処理は従来通り手動で行うものとします。将来的な連携は次期フェーズで検討します。」
このように書いておくことで、開発会社が「経理連携も含まれるかもしれない」と考えて見積もりを膨らませたり、逆に「含まれないだろう」と考えて必要な連携用のデータ出力機能まで削ってしまったりする事態を防げます。
納期と予算感の書き方
納期は最終納品日だけでなく、テストや研修に必要な期間を逆算して書くことが重要です。
良い例:「本稼働開始日は10月1日を予定しています。9月中に社内でのテスト運用期間を2週間確保したいため、9月15日までに仮納品をお願いします。」
予算感については、正確な金額を明かすことに抵抗を感じる担当者も多いですが、レンジだけでも共有した方が結果的に精度の高い提案を受けられます。
良い例:「予算は300万円から500万円の範囲を想定しています。この範囲を超える場合は、優先度の高い機能から段階的に実装する形でも構いません。」
「書きすぎ」「書かなすぎ」のバランスの取り方
ここまで具体的に書くことを勧めてきましたが、何でも細かく書けばよいというわけではありません。仕様書には「書きすぎ」の弊害もあります。
書きすぎの典型例は、画面のボタンの配置や色使いといった見た目の細部まで指定してしまうケースです。デザインや画面遷移の具体的な作り方は、開発会社の専門領域であり、発注者が細部まで指定すると、かえって開発会社の提案の自由度を奪い、より良い解決策が提示されなくなることがあります。発注者が書くべきは「何を実現したいか」であり、「どう実装するか」は開発会社に委ねるという役割分担を意識してください。
一方で書かなすぎの典型例は、機能名だけを箇条書きにして具体例や数字を一切示さないケースです。「検索機能」「承認機能」「帳票出力機能」と単語だけ並べても、開発会社はその機能がどの程度の複雑さを想定しているのか判断できません。検索機能一つとっても、商品名の部分一致検索なのか、複数条件を組み合わせた絞り込み検索なのかで、必要な工数はまったく異なります。
目安としては、業務の現状や機能要件については「その業務を知らない人が読んでも情景が思い浮かぶかどうか」を基準にし、画面設計や技術的な実装方法については「開発会社の専門性を信頼して委ねる」という線引きをすると、ちょうどよいバランスに落ち着きます。判断に迷った場合は、いったん詳しく書いておいて、開発会社との打ち合わせの中で「ここは会社様にお任せします」と伝える方が、書かずに後から追加要望を出すよりもずっとスムーズです。
開発会社に見せる前にセルフチェックすべきこと
仕様書を書き終えたら、開発会社に提示する前に、次の観点で自分自身の文書を見直してください。
数字が入っているか
利用人数、データ件数、処理頻度、保存期間など、数字で表現できる部分がすべて具体的な数値になっているかを確認します。「たくさん」「頻繁に」といった言葉が残っていないか探してください。
動詞の主語が明確か
「管理する」「対応する」といった曖昧な動詞が残っていないかを確認します。誰が何をしたときに、システムが何をするのかという三点セットに分解できるかを一文ずつチェックします。
除外項目が書かれているか
隣接する業務やシステムとの境界線が明示されているかを確認します。何も書かれていない場合、その境界がどちらに含まれるかは開発会社の解釈次第になってしまいます。
社内の別の担当者が読んで理解できるか
作成した仕様書を、その業務に詳しくない同僚に読んでもらい、内容を説明できるかを確認してもらいます。開発会社は、その業務に詳しくない同僚と同じ立場で仕様書を読みます。社内の誰かが読んで疑問に思う点は、開発会社にとっても疑問になる点です。
優先順位が示されているか
すべての機能要件に同じ重みをつけるのではなく、「これは必須」「これはあれば嬉しい」という優先順位を付記しておくと、予算や納期の制約が生じた際に、開発会社と発注者の間で建設的な取捨選択の相談ができます。
質問を受け付ける前提で書いているか
どれだけ丁寧に書いても、開発会社から質問が来ることは前提としておいてください。仕様書は一度で完璧なものを作る文書ではなく、開発会社とのキャッチボールの起点となる文書です。質問が来たときに「なぜそんなことも分からないのか」と受け止めるのではなく、「認識齟齬を防ぐための貴重な機会」として捉える心構えを持っておくと、その後のやり取りが格段にスムーズになります。
よくある記載ミスとその直し方
ここまで項目ごとの書き方を見てきましたが、実際の仕様書でよく見かける記載ミスには共通のパターンがあります。自分の仕様書に当てはまっていないか、具体的な事例で確認してみてください。
ミス1: 形容詞だけで終わっている
「使いやすい画面にしてほしい」「早く動くようにしてほしい」といった形容詞は、人によって基準がまったく異なります。使いやすさや速さは、具体的な操作手順や数値に置き換えて初めて仕様として機能します。
悪い例:「検索は早く結果が出るようにしてほしい。」
良い例:「商品名で検索した場合、3秒以内に検索結果一覧が表示されるようにしてほしい。想定するデータ件数は5000件程度です。」
形容詞が出てきたら、その言葉を数字か具体的な操作手順に翻訳できないか、一度立ち止まって考える癖をつけてください。
ミス2: 例外パターンが書かれていない
通常の業務フローだけを書き、例外的なケースへの言及がないまま仕様書を完成させてしまうケースも多く見られます。
悪い例:「注文が入ったら在庫を引き当てる。」
良い例:「注文が入ったら在庫を引き当てる。ただし在庫数が注文数を下回る場合は、注文を保留状態にして担当者に通知する。担当者が仕入れ先へ緊急発注するか、注文自体をキャンセルするかを画面上で選択できるようにする。」
在庫切れ、入力ミス、二重登録、権限のないユーザーによる操作など、通常フローから外れたときにシステムがどう振る舞うべきかを一つでも多く洗い出しておくと、テスト工程での手戻りが大幅に減ります。
ミス3: 現状の業務量を書かず「思っていたのと違う」規模のシステムができる
現状の業務量を書かずに機能要件だけを伝えると、開発会社は少人数・少データ量を前提とした簡易な仕組みを想定しがちです。逆に発注者は将来の拡大まで見据えた本格的な仕組みを期待していることが多く、この落差が「思っていたのと違う」という感想につながります。現在の利用人数やデータ件数だけでなく、1年後、3年後にどの程度の規模になっている見込みかも一言添えておくと、開発会社は将来を見据えた設計を提案しやすくなります。
ミス4: 承認者や関係部署の存在を書き忘れる
発注担当者一人の視点だけで仕様書を書くと、実際にそのシステムを使う他部署の存在や、稟議で承認を得る必要がある決裁者の存在が抜け落ちてしまうことがあります。
良い例:「本システムは総務部が入力を行い、経理部が閲覧のみ行います。最終的な仕様の承認は総務部長が行います。」
誰が使い、誰が承認するのかを書いておくことで、開発会社は打ち合わせに誰を同席させるべきかを判断でき、後になって「そんな部署が関係しているとは知らなかった」という手戻りを防げます。
仕様書に使えるひな形項目リスト
最後に、実際に仕様書を書き起こす際にそのまま見出しとして使える項目リストをまとめます。この順番で書き進めていくと、抜け漏れなく仕様書を組み立てることができます。
- 1. システム導入の背景と現状の業務フロー
- 2. システム導入の目的と達成したい状態
- 3. 利用者の範囲（部署・人数・役割）
- 4. 機能要件（業務フローに沿って、誰が・何をしたら・システムが何をするかの形式で記載）
- 5. 例外パターンへの対応方針
- 6. 非機能要件（利用人数、セキュリティ、バックアップ、稼働時間帯など）
- 7. 除外項目（今回のスコープに含まないこと）
- 8. 他システムとの連携有無
- 9. 想定納期とマイルストーン
- 10. 予算のレンジ
- 11. 機能ごとの優先順位（必須・希望・任意）
- 12. 承認者・関係部署
この十二項目を順番に埋めていくだけで、専門的な文書作成のスキルがなくても、開発会社が読んで具体的な提案を返せる水準の仕様書に仕上がります。すべての空欄を一度で完璧に埋めようとせず、分かる範囲から書き始め、分からない部分は「要相談」と書いておくだけでも、まったく手をつけないよりはるかに認識齟齬を減らせます。
仕様書と要件定義・稟議書はどう違うのか
ここまで発注仕様書の書き方を見てきましたが、社内でよく混同される文書として要件定義と稟議書があります。整理しておくと、それぞれの役割の違いが見えてきます。
要件定義は、そもそも自社にとってどんな機能が必要なのかを社内で洗い出し、優先順位をつけて合意形成をする作業です。いわば仕様書を書くための材料集めの工程であり、社内の関係者だけで完結する検討作業です。
稟議書は、その投資に対して社内の決裁者から予算の承認を得るための文書です。読み手は経営層や上長であり、費用対効果や投資回収の見通しが中心の内容になります。
一方で発注仕様書は、要件定義で洗い出した内容を、開発会社という社外の第三者に伝えるための文書です。読み手が社内の人間から社外の専門家に変わる分だけ、書き方の作法もまったく異なります。社内向けの文書では前提として省略していた情報も、仕様書では省略せずに書く必要があります。稟議書で使った「業務効率化」「生産性向上」といった抽象的な言葉も、仕様書では具体的な数字や操作手順に言い換える必要があります。
この三つの文書は、材料集め、社内承認、社外への伝達という異なる役割を持っています。稟議書がすでに社内で承認されているからといって、その文章をそのまま仕様書に転用してしまうと、抽象度の高さゆえに開発会社との間で認識齟齬が生まれやすくなります。仕様書を書く際は、稟議書や要件定義でまとめた内容を、開発会社という読み手に合わせてもう一段階具体的に書き直すという意識を持つことが大切です。
まとめ
発注仕様書の書き方に唯一の正解はありません。しかし、業務の現状、目的、機能要件、非機能要件、除外項目、納期、予算感という七つの項目を漏れなく押さえ、数字と具体例で語り、動詞の主語をはっきりさせるという基本を守るだけで、認識齟齬の多くは未然に防げます。書きすぎず、書かなすぎず、開発会社の専門性を信頼しながら、自社にしか分からない業務の実情を丁寧に翻訳する。それが発注仕様書という文書の本質です。
業務システムの発注は、日々の業務を回しながら、これまで経験したことのない役割に挑む仕事です。現場の業務を知り尽くした担当者が、開発の専門知識という別の領域に踏み出し、二つの世界の間に立って言葉を紡ぐ。その挑戦こそが、会社を次の段階へ進める原動力になります。私たちオルアナは、そうやって自分の持ち場を越えて働こうとする方の隣に立ち、仕様書という一枚の文書からシステム開発の伴走を始めます。どこから手をつければよいか分からないという段階からで構いません。まずはお気軽にご相談ください。