中小企業が要件定義を業者任せにしない進め方：主体的に動くための型と実践ステップ

「システム開発を外部業者に任せたのに、完成したシステムが現場の業務と全く合っていなかった」——こうした失敗は、中小企業のIT導入プロジェクトで繰り返されてきた典型的なパターンです。原因の大半は、要件定義を業者任せにしたことにあります。

業者は「依頼された通りのもの」を作ります。発注側がやりたいことを言語化できていなければ、どれだけ優秀な業者でも期待通りのシステムは生まれません。この責任の不均衡が、中小企業のIT投資を無駄にし続けています。

この記事では、ITの専門知識がなくても使える「要件定義の型」と、4週間で骨格を固める実践ステップを解説します。情シス兼任担当者や中小企業の経営者が、業者との交渉で主体性を保つための現場ガイドとして活用してください。

要件定義を業者任せにすると何が起きるか

要件定義とは、「このシステムで何を実現したいか」を文書化するプロセスです。これを業者任せにした場合、具体的に何が起きるかを順を追って見てみましょう。

最も頻繁に起きる問題は、「作ったけど使われないシステム」の誕生です。業者が「こういう設計が使いやすいはず」という仮定に基づいてシステムを設計すると、実際の業務フローとかみ合わない画面構成やデータ入力方法が生まれます。製造業の受注管理システムで言えば、現場の担当者が1日に100件の工程入力を行う場面で、画面遷移が多すぎて誰も使わなくなるといった事態が典型例です。導入コスト100万円以上を費やしながら、半年後には誰も触らなくなったシステムが社内サーバーに眠っている——中小企業でよく見られる光景です。

次に起きるのが、追加費用の問題です。「要件を変更したい」と言うたびに追加見積もりが発生し、当初予算の1.5倍、2倍と膨らんでいきます。業者側から見ると、要件定義段階で詰めきれていなかった部分への変更は正当な「追加作業」です。発注側が要件を言語化しないまま「なんとなくこんな感じで」と依頼したツケが、後から費用として回ってくる構造になっています。要件定義を適切に行った場合と比べると、追加費用だけで当初予算の20～30%を超えるケースも珍しくありません。

さらに深刻なのが、検収の基準が曖昧になることです。「最初に言ったことが実現されているかどうか」を判断する基準が書面になっていないため、業者が「完成した」と主張しても発注側が「違う」と感じる場面が生まれます。この対立が長引くと、法的なトラブルに発展することもあります。中小企業がIT開発で法的紛争を抱えるリスクは、要件定義の不備から始まっていることが多いのです。

これらの問題をまとめると、要件定義を業者任せにした場合のリスクは「品質リスク」「費用リスク」「法的リスク」の3層構造になっています。いずれも、発注側が要件定義の主体になることで大幅に軽減できます。

中小企業が主体的に動けない本当の理由

「要件定義は業者に任せてください。プロが上手くやります」という言葉を信じてしまう背景には、中小企業特有の3つの構造的な理由があります。

1つ目は、「ITのことは分からないから業者に任せる」という思い込みです。しかし、要件定義に必要な知識のほとんどは「業務知識」です。自社の仕事の流れ、ボトルネック、入力データの種類、レポートで使う数字——これらを一番よく知っているのは自社の現場担当者であり、業者ではありません。システムを構築する技術は業者が持っていますが、「何を作るべきか」を決める業務知識は発注側にしかないのです。技術と業務知識は別物であり、後者を持つ発注側が要件定義のリーダーになるのが本来の姿です。

2つ目は、時間の問題です。中小企業では情シス担当が他部門を兼任していることが多く、要件定義のために専用の時間を確保することが難しい状況があります。結果的に「業者に任せた方が楽」という判断をしてしまいます。しかし前節で述べた通り、その「楽さ」が後の大きなコスト増と失敗を招きます。要件定義に投資する4週間を惜しんだ結果、プロジェクト全体で何倍もの時間とお金を失う典型的なパターンです。

3つ目は、「型」を持っていないことです。要件定義の進め方を体系的に学ぶ機会がなく、何から始めればよいか分からないまま業者のペースに乗ってしまいます。大企業では要件定義の方法論が社内標準として存在しますが、中小企業にはそうした仕組みがない場合が多い。逆に言えば、型さえ身につければ、ITの専門知識がなくても主体的に動けます。次節では、その型を5つの問いとして整理します。

要件定義を主体的に進める「5つの問い」

中小企業が要件定義で主体性を持つために有効なのが、以下の「5つの問い」です。この問いに答えることで、要件定義の骨格が完成します。業者との打ち合わせの前に、自社内でこの問いに回答する文書を作ることが第一歩です。

問い1：このシステムは「誰が」「何を」するためのものか？

最初に確認すべきは、システムの利用者（エンドユーザー）と用途です。「営業担当が顧客への提案書を作成するために使う」「工場の現場作業員が工程進捗を入力するために使う」のように、利用者と用途を1行で書けるまで具体化します。ここが曖昧なまま進めると、誰にも使われないシステムができあがります。複数の利用者がいる場合は、それぞれの役割別に記述することが重要です。

問い2：現状の「困り事」は何か？

システムは現状の問題を解決するために作るものです。「手動でExcelに入力しているため月末に4時間かかっている」「複数の担当者が同じデータを二重入力している」のように、数字を使って具体化します。この困り事が解決されていれば、そのシステムは成功と言えます。困り事を数値化できない場合は、まず現状業務の計測から始めましょう。

問い3：「絶対に必要な機能」は何か？

要件定義で最も重要なのが「必須機能」の特定です。すべての要望を詰め込もうとすると、コストが膨らみスケジュールが伸びます。「これがなければシステムを入れる意味がない」という機能を3つ以内に絞ることが鍵です。絞り込む際は、問い2で特定した困り事と直接結びつく機能を優先します。

問い4：「あったら便利な機能」は何か？

必須機能とは別に、予算と時間があれば実装したい機能を別リストに分けます。この区別ができていない発注書は、業者に「全部作れ」と受け取られ、費用が青天井になります。問い3と問い4を明確に分離することで、予算交渉時に「問い4の機能は次フェーズに回す」という現実的な判断ができるようになります。

問い5：「絶対にやってはいけないこと」は何か？

制約条件の明確化です。「既存の会計ソフトとデータ連携しなければならない」「スマートフォンでも使えなければならない」「顧客情報を外部のクラウドサービスに保存してはいけない（情報セキュリティの観点から）」のように、制約として必ず守ることを書き出します。特にセキュリティ要件は、この問い5で必ず明記すべき最重要項目です。

この5つの問いに文書で回答できれば、業者との打ち合わせで主導権を握れます。業者が提示してくる仕様書に対して、「この機能は問い3の必須機能を満たしているか？」「この設計は問い5の制約条件に抵触していないか？」という視点でレビューできるようになります。

4週間で要件定義を固める実践ステップ

5つの問いを実際の業務に落とし込む4週間のスケジュールを紹介します。情シス兼任担当者が他業務と並行しながら進めることを前提に設計しています。1週間あたりの実作業時間は5～8時間程度を想定しています。

1. 第1週：現状業務の「見える化」

まず現場の業務フローを書き出します。ツールはA4の紙でも、ExcelでもWhiteboardアプリでも何でも構いません。「誰が・何を・いつ・どこで・どのように・何件/日」を書き出し、システム化したい業務の全体像を掴みます。この段階では完成度は問いません。「ざっくりとした全体図」で十分です。

現場担当者（システムを実際に使う人）に対して30分のヒアリングを行い、「今一番困っていること」「時間がかかっていること」「ミスが起きやすいこと」を3つ挙げてもらいます。複数の業務担当者からヒアリングすると、優先度が自然に見えてきます。5名以上にヒアリングする場合は、Googleフォームなどのアンケートツールで回答を集めると集計が楽になります。

2. 第2週：課題と優先順位の確定

第1週のヒアリング結果をもとに、問い2（困り事）と問い3・4（必須機能と便利機能）を文書化します。各機能に「解決できる困り事」「月間削減時間（概算）」「使用頻度」を紐づけると、経営判断として優先順位をつけやすくなります。

たとえば、「受注データの手動入力を自動化する→月40時間削減→毎日使用」と「売上レポートをPDFで自動生成する→月2時間削減→月1回使用」では、前者が明らかに優先度が高いことが数字で分かります。こうした数値化によって、業者との打ち合わせで「まずこの機能から作ってほしい」という主張に客観的な根拠が生まれます。

3. 第3週：機能要件と非機能要件の整理

「機能要件」とは「何ができるか」の要件（受注データを入力できる、在庫数をリアルタイム表示できる等）です。一方「非機能要件」は「どの品質で動くか」の要件（同時接続者数が10名でも遅くならない、データのバックアップを毎日取る等）を指します。

中小企業が見落としやすいのが非機能要件です。「速度」「セキュリティ」「可用性（何時から何時まで使えるか）」「データのバックアップ方式」を最低限整理しましょう。特に顧客情報や財務データを扱うシステムでは、「外部のクラウドサービスにデータを保存しない設計にする」という非機能要件が重要なセキュリティポリシーになります。この要件を明記していなければ、業者がコスト優先でデータを外部クラウドに保存する設計を選択することがあります。

4. 第4週：業者との合意と文書化

第3週までに整理した内容を「要件定義書（仮）」として業者に渡し、認識の齟齬がないかをすり合わせます。業者から「それは技術的に難しい」「追加費用が発生する」という回答が来た場合、第2週で整理した優先順位をもとに何を妥協するかを判断します。

最終的に合意した内容を「確認書」として文書化し、双方が署名します。この書類が将来のトラブルを防ぐ最重要書類になります。確認書には「必須機能一覧」「納品物の定義」「検収基準（何をもって完成とするか）」「変更発生時の費用ルール」を最低限含めましょう。書類を作ることを嫌がる業者とは、プロジェクト開始前に関係を見直すことも選択肢の一つです。

比較表：業者任せ型 vs 主体型の要件定義

業者任せ型と主体型では、プロジェクトの結果にどのような差が生まれるかを整理します。

業者任せ型の最大の問題は、「楽に見えて後から高くつく」点です。主体型は準備に4週間を要しますが、その後のトラブルや追加費用を防ぐことで、プロジェクト全体のトータルコストは大幅に下がります。特に追加費用リスクとセキュリティ要件の取り扱いは、主体型と業者任せ型で結果に大きな差が出やすい領域です。

よくある質問

Q1. 要件定義書は何ページくらいで作ればよいですか？

最初のプロジェクトであれば、A4で5枚以内を目安にしてください。重要なのは量ではなく「5つの問いへの回答が揃っているか」です。システムの規模が大きくなれば自然と枚数は増えますが、初めてのプロジェクトで100ページの要件定義書を最初から要求する業者がいれば、その業者の選定を見直すことをお勧めします。まず5枚の骨格を作り、業者との打ち合わせで肉付けしていく進め方が現実的です。

Q2. 業者から「要件定義は我々がやります」と言われた場合はどうすればよいですか？

業者が要件定義の素案を作ることは問題ありません。ただし、その内容を発注側が「自分ごと化して確認する」工程が必須です。業者が作った要件定義書を読んで、「この機能は本当に必要か」「現場の業務フローと合っているか」を発注側で確認し、必要なら修正を要求します。業者に任せてよいのは「書く作業」であって、「決める権限」ではありません。確認と承認のプロセスに発注側が主体的に関わることで、業者主導の要件定義でもリスクを下げられます。

Q3. 予算が少ない場合、要件定義にどこまで時間をかけるべきですか？

予算が少ない場合こそ、要件定義に時間をかけるべきです。予算100万円のプロジェクトで要件の認識ズレが発生すると、追加費用が30万～50万円になることも珍しくありません。一方、要件定義に4週間を投資すれば、このリスクを大幅に下げられます。予算が少ないほど、最初の要件定義に時間とエネルギーを集中させることが合理的です。「急いで安く作りたい」という状況で要件定義を省略することは、最もコストのかかる選択になりかねません。

Q4. 要件定義の段階でセキュリティ要件も決める必要がありますか？

必ず決める必要があります。特に顧客情報・個人情報・財務データを扱うシステムでは、「外部のクラウドサービスにデータを保存しない」「社内ネットワーク外からのアクセスを制限する」「アクセスログを90日分保持する」といった非機能要件（セキュリティポリシー）を要件定義の段階で明記しなければ、業者がコスト優先でクラウドストレージを使った設計を選択する可能性があります。セキュリティ要件を後から変更すると、設計の大幅な見直しが必要になり、追加費用の原因になります。要件定義のセキュリティ要件欄は、必ず埋めてから業者に渡しましょう。

Q5. 要件定義で合意した内容を業者が無視した場合はどうすればよいですか？

合意書（確認書）が存在すれば、「書かれた内容と異なる」という事実を書面で指摘できます。まずは書面で「確認書の〇ページ〇項目と異なる」と指摘し、修正を求めます。業者が応じない場合は、契約書の「瑕疵担保責任」や「変更管理手順」に沿った対応を検討します。合意書が存在しない状態で口頭で「言った・言わない」の議論になると、発注側が不利な立場に置かれます。書面化の習慣が、トラブル時の唯一の防衛手段です。

要件定義着手前チェックリスト

プロジェクトをスタートする前に、以下の項目を確認してください。すべてに「はい」と答えられる状態になってから業者との打ち合わせを開始することをお勧めします。一つでも「いいえ」がある場合は、その項目を先に整理しましょう。

・現状業務フローの文書化：「誰が・何を・どの順で行うか」をA4紙1枚でも書き出している
・困り事の数値化：「月に何時間かかっているか」「何件のミスが発生しているか」など、困り事を数字で表現できる
・必須機能の絞り込み：「これがなければシステムを入れる意味がない」機能を3つ以内に絞り込んでいる
・便利機能の分離：必須機能と「あったら便利な機能」を別リストに分けている
・制約条件の確認：既存システムとの連携要否、セキュリティポリシー（外部クラウドへのデータ流出禁止等）を確認し文書化している
・予算と期限の確定：「いくらまで使えるか」「いつまでに稼働させる必要があるか」が経営判断として確定している
・ステークホルダーの合意：現場の利用者と経営者が「このプロジェクトを進める」という合意を共有している
・業者への質問リスト：「同規模のシステム構築実績はあるか」「要件変更時の費用発生ルールはどうなっているか」など、業者に確認する事項をリスト化している

まとめ

中小企業が要件定義で失敗する最大の原因は、「業者がうまくやってくれるはず」という思い込みです。業者は技術を提供しますが、「何を作るべきか」を決める業務知識は発注側にしかありません。この本質を理解した上で、主体的に要件定義を進めることが、IT投資を成功に導く第一条件です。

本記事で紹介した「5つの問い」と「4週間の実践ステップ」を使えば、ITの専門知識がない担当者でも要件定義の主体になれます。第1週で現状業務を見える化し、第2週で優先順位を確定し、第3週で機能・非機能要件を整理し、第4週で業者との合意を文書化する——この4ステップを完走することで、追加費用リスクと「作ったけど使われない」リスクを大幅に下げられます。

セキュリティ要件を含む非機能要件の明文化は、後からでは変更コストが大きくなる最重要事項です。次のITプロジェクトを始める前に、まず5つの問いに答えることから始めてください。そのために時間を使うことが、最もコストパフォーマンスの高いIT投資になります。