「システムを作りたいが、何をどこまで伝えればいいのか分からない」
初めてシステム開発を外部に依頼される方から、私たちが最もよくいただく声です。要件定義という工程があることは知っている。けれど、そこに何を持っていけばいいのかは誰も教えてくれない——そんな状態で最初の打ち合わせを迎える方が、実はとても多くいらっしゃいます。
結論から申し上げます。要件定義がうまくいくかどうかは、打ち合わせが始まる前の準備でほぼ決まります。そして発注する側が準備すべきなのは、完成した仕様書ではありません。開発会社が質問したときに、その場で答えられる「判断材料」です。
この記事では、要件定義に入る前に発注側が何をそろえておけばよいのかを、開発会社の立場から説明します。つまずきやすいパターンと、逆に「準備しなくていいこと」まで含めてお伝えします。
要件定義で決めるのは、開発会社ではなく発注側です
まず、要件定義という工程が何をするものなのかを整理させてください。ここに認識のずれがあると、準備の方向が丸ごとずれてしまいます。
要件定義とは「何を作るか」を文書として確定させる工程
要件定義は、システム開発の一番最初にある工程です。ここで「どんな業務を、どういう手順で、誰が使えるようにするのか」を洗い出し、文書として確定させます。この文書が、その後の設計・開発・テストすべての土台になります。
見積書の金額も、納期も、すべてこの文書の内容から逆算されます。要件定義が曖昧なまま先に進んだ場合、金額と納期の前提が崩れるということです。
「決める」のは発注側、「引き出して整理する」のが開発会社
ここが最も誤解されやすい点です。要件定義は開発会社が主導して進めますが、中身を決める権限を持っているのは発注する側です。
開発会社にできるのは、質問して、聞いた内容を整理して、抜けている論点を指摘することまでです。「御社の業務では、この場合どう処理していますか」という問いに答えられるのは、その業務を実際にやっている方だけです。
私たちがお引き受けした案件を振り返ると、要件定義が長引いたケースには共通点があります。技術的に難しかったからではなく、「その質問に答えられる人が、その場にいなかった」ことが原因です。
準備不足のまま進めると、何が起きるか
要件が固まらないまま設計や開発に進んだ場合、順番に次のことが起こります。
- 仮の想定で作り始める — 決まらない部分を、開発会社が「おそらくこうだろう」と補って進めます
- できあがったものを見て初めて違いに気づく — 動く画面を見て「思っていたのと違う」となります
- 作り直しが発生する — 設計からやり直すため、想定していた工数を超えます
- 追加費用と納期延長の相談になる — ここで初めて金額の話になり、双方にとって苦しい局面になります
つらいのは、この流れの起点が「聞かれたときに答えられなかった」という小さな点にあることです。逆に言えば、事前の準備でかなりの部分を防げます。
要件定義がつまずく典型パターン5つ
これまでお引き受けした受託開発を振り返ると、つまずき方には驚くほど共通のパターンがあります。業種が違っても、同じところで止まります。
①決める人が打ち合わせに同席していない
担当者の方だけが打ち合わせに出席し、決裁される方が別にいるケースです。その場では話が進みますが、持ち帰って確認するたびに1〜2週間止まります。
さらに厄介なのは、決裁者の方が後から加わって、それまでの前提をひっくり返す場合です。悪気があるわけではなく、単に議論の経緯を共有されていないだけなのですが、実質的に要件定義が振り出しに戻ります。
②現行の業務を説明できる人がいない
「今どうやっているか」を、最初から最後まで通しで説明できる方が意外にいません。担当者ごとに自分の持ち場は分かっていても、全体の流れを把握している方がいないのです。
長く続いている業務ほどこの傾向が強くなります。誰も理由を知らないまま続いている手順が残っていて、それがシステム化の障害になることもあります。
③「今と同じでいい」という要望
一見すると親切な要望に見えますが、実は最も危険な言葉です。理由は2つあります。
ひとつは、「今」が正確に定義されていないこと。現行の運用は、担当者の判断や口頭のやりとりで補われている部分が必ずあります。それをそのまま作ることはできません。
もうひとつは、現行業務をそのまま移植すると、業務が改善されないことです。手間のかかる作業がそのままシステムに乗るだけで、費用をかけた意味が薄れてしまいます。
④例外処理が後から出てくる
要件定義では、まず通常の流れをうかがいます。ここまでは順調に進みます。
問題は、開発が進んだ段階で「そういえば、月末だけは処理が違います」「この取引先だけ特別なルールがあります」と出てくる場合です。例外処理は、後から追加するほど費用が高くつきます。すでに作った部分に条件分岐を足すことになり、確認すべき範囲も広がるためです。
⑤既存データを誰も確認していない
今使っているExcelや既存システムのデータを新しいシステムに移す作業は、想像以上に手間がかかります。
にもかかわらず、中身を確認しないまま「移行はお願いします」となる場合があります。実際に開けてみると、同じ会社名が複数の表記で登録されていたり、必須のはずの項目が空欄だったりします。この整理は業務を知っている方にしかできず、結果として発注側の作業として戻ってきます。
発注側が事前にそろえる6つの材料
ここからが本題です。要件定義の打ち合わせに入る前に、次の6つをそろえておいてください。完璧である必要はありません。たたき台があるだけで、要件定義の進み方はまったく変わります。
①この開発で何を良くしたいのか、を一文で
最初に決めていただきたいのは、目的です。「受注処理にかかる時間を減らしたい」「担当者が休んでも業務が止まらないようにしたい」——このくらいの粒度で構いません。
なぜ一文かというと、要件定義では必ず「どちらを優先するか」という判断が発生するからです。そのとき立ち返る基準がないと、判断のたびに議論が振り出しに戻ります。目的が一文で共有されていれば、「今回はこちらを優先しましょう」と即決できます。
②現行業務の流れ（手書きでも構いません）
誰が、いつ、何をきっかけに、何をして、次に誰へ渡すのか。この流れを紙1枚に書き出してください。きれいな図である必要はまったくなく、箇条書きで十分です。
作る過程で、社内でも認識が違っていた部分が見つかることがあります。それ自体に大きな価値があります。
③使う人と、それぞれができること
システムを誰が使うのかを一覧にしてください。そのうえで、それぞれが「見られる情報」と「できる操作」を分けて書きます。
たとえば、担当者は自分の案件だけ見られる、管理職は全件見られる、経理は金額だけ見られる、といった具合です。この整理は後から変更すると影響範囲が広いため、早い段階で決めておくと費用面でも有利になります。
④例外と、繁忙期の動き
通常の流れが書けたら、そこから外れるケースを思い出せるだけ挙げてください。「この場合だけは手順が違う」「この相手先だけ特別扱い」といったものです。
あわせて、繁忙期にどのくらいの量を扱うのかも共有してください。普段の10倍の処理が集中する時期があるなら、それは設計に影響します。後から分かるより、最初に分かっているほうが安く作れます。
⑤今使っている道具と、既存のデータ
現在使っているExcelファイル、紙の帳票、既存システムの画面——実物を用意してください。言葉で説明していただくより、実物を1つ見せていただくほうが、私たちは10倍速く理解できます。
データについては、件数と、実際の中身を確認しておいてください。移行するのか、新しいシステムでは一から入力し直すのか。この判断だけでも先に決まっていると、見積もりの精度が上がります。
⑥決める人と、決め方
最後に、社内の意思決定の流れを整理してください。誰が最終的に決めるのか。その方が打ち合わせに出席できるのか。難しい場合、確認にどのくらいの日数がかかるのか。
この1点を最初に共有していただくだけで、要件定義の期間は明確に短くなります。私たちも、決裁のタイミングを見越して打ち合わせの順番を組み立てられるためです。
準備がある発注と、ない発注の違い
| 観点 | 準備がない場合 | 6つの材料がある場合 |
|---|---|---|
| 要件定義の進み方 | 質問のたびに持ち帰り、確認待ちが積み重なる | その場で決まり、決められない点だけ持ち帰る |
| 手戻り | できあがってから「思っていたのと違う」が発生 | 文書の段階でずれに気づける |
| 追加費用 | 例外処理やデータ移行が後から積み上がる | 最初の見積もりに織り込める |
| 完成後 | 現場の実務と噛み合わず、使われなくなる | 業務の流れどおりなので定着する |
なお、要件定義の内容がそのまま見積金額の前提になります。見積書の読み方については別の記事で詳しく説明していますので、あわせてご覧ください。
逆に、発注側が「決めなくていいこと」
ここまで準備の話をしてきましたが、反対のことも申し上げます。準備とは、全部を決めることではありません。
抱え込みすぎると、かえって時間がかかります。次のものは、開発会社側の仕事だとお考えください。
画面のデザインや配置
どこにボタンを置くか、どんな色にするか。こうしたことを事前に考えていただく必要はありません。むしろ、画面の形を先に決めてしまうと、業務の流れの議論がそこに引きずられます。
先に決めるべきは「何ができる必要があるか」で、見た目はその後です。
技術的な構成
どういう仕組みで作るのか、どこにデータを置くのか。これは開発会社が、ご要望の内容とご予算に合わせて提案する領域です。
「詳しくないので技術のことは分かりません」で、まったく問題ありません。判断していただくのは、提案された構成が業務上どういう意味を持つか——たとえば外出先から使えるのか、といった点だけです。
細かい文言や項目名
画面に表示する言葉、入力欄の名前。こうしたものは、実際に動く画面を見てから調整するほうが確実です。文字だけで議論しても、完成形を想像するのは難しいためです。
すべての例外を漏れなく洗い出すこと
先ほど例外の棚卸しをお願いしましたが、完璧を目指す必要はありません。思い出せる範囲で構いませんし、抜けを見つけるのは私たちの仕事です。
「例外があるかもしれない」という前提を共有できていれば、開発会社は必ずその方向から質問します。完璧なリストを作ることに時間をかけて着手が遅れるより、たたき台を持って早く始めるほうが、結果的にうまく進みます。
打ち合わせ当日の進め方と、開発会社の見極め方
準備した材料は、そのまま持参してください。清書する必要はありません。手書きのメモや、社内で使っている実物のほうが情報量が多く、私たちにとってはありがたい資料です。
「分からないこと」も伝えてください
準備の過程で「ここは社内でも意見が割れている」「これは誰も把握していない」と分かった点があれば、それも率直にお伝えください。
隠されるより、はるかに助かります。分かっていない箇所が最初から見えていれば、そこを重点的に整理する時間を確保できるからです。要件定義でいちばん怖いのは、決まっていないことに双方が気づかないまま進んでしまうことです。
良い開発会社は「聞き方」で分かります
最初の打ち合わせは、開発会社を見極める場でもあります。次の点をご覧ください。
- 機能ではなく業務を聞くか — 「どんな機能が欲しいですか」ではなく「今どうやっていますか」から入る会社は、業務を理解しようとしています
- 例外を自分から聞くか — 「イレギュラーな場合はありますか」と質問してくる会社は、後から膨らむ費用の芽を先に摘もうとしています
- 決められない点を一緒に整理するか — 「決まってから来てください」と突き放さず、その場で論点を分解してくれるかどうか
- できないこと・やらないほうがいいことを言うか — すべてに「できます」と答える会社より、優先順位を一緒に考えてくれる会社のほうが、結果的に費用は収まります
ご要望をそのまま受け取って見積書だけ出してくる会社と、業務を掘り下げて質問してくる会社。手間がかかるのは後者ですが、完成後に使われるシステムになるのも後者です。
まとめ
要件定義における発注側の準備は、仕様書を作ることではありません。開発会社の質問に答えられる材料をそろえること、そして決める人を確保することです。
本記事でお伝えした6つ——目的を一文で、現行業務の流れ、使う人と権限、例外と繁忙期、既存の道具とデータ、決める人と決め方。これらは手書きのメモで構いません。完璧なものを用意しようとして着手が遅れるくらいなら、たたき台を持って早く相談されるほうが、確実にうまく進みます。
そして、まだ何も整理できていない段階でのご相談も歓迎です。「何から手をつければいいか分からない」という状態こそ、私たちが一緒に整理をお手伝いできる場面です。まずは今のお困りごとを、そのままの言葉でお聞かせください。
よくある質問
仕様書は自分たちで作る必要がありますか
いいえ、必要ありません。仕様書としてまとめるのは開発会社の仕事です。発注側にご用意いただきたいのは、判断のもとになる材料と、決める人の確保です。文書の体裁は整っていなくて構いません。
資料が何もない状態で相談してもよいですか
問題ありません。むしろ、資料を作る前にご相談いただくほうが、無駄な作業を省けます。何をそろえるべきかは業種や業務によって変わるため、最初の打ち合わせで「まずこれを用意してください」とご案内できます。
要件定義だけを依頼することはできますか
できます。要件定義だけを先に実施し、その結果をもとに開発の進め方や費用を判断する進め方は一般的です。要件定義の成果物をもとに他社と比較検討されることも可能です。ただし、その場合の成果物の扱いは事前に契約で確認しておいてください。
要件定義にはどのくらいの期間がかかりますか
対象となる業務の範囲によって大きく変わるため、一律の目安はお伝えできません。ただし期間を左右するのは規模よりも、決裁の速さと、質問に答えられる方が同席しているかです。同じ規模でも、この2点で必要な期間は倍近く変わります。
