システム開発を依頼すると、最初に「要件定義」という工程が始まります。 ここで決まった内容がその後の設計・開発の土台になるため、要件定義の質がプロジェクト全体の結果を大きく左右します。
とはいえ、発注側が身構えて完璧な仕様書を用意する必要はありません。 必要なのは、社内にしかない情報を持ち込むことだけです。 この記事では、受託開発を手がけるCoconutWorksが、要件定義の前に発注側が準備しておくと進みが良くなる材料と、 逆に準備しなくてよいことを整理します。金額には触れず、進め方の考え方に絞って解説します。
結論: 要件定義に持ち込む4つの材料
| 持ち込む材料 | なぜ必要か | どこまで書けば十分か |
|---|---|---|
| 今の業務の流れ | 現状を知らないと、どこを自動化・改善できるか判断できない | 担当者・順番・使っているツールが分かる程度。手書きのメモで十分 |
| 困っている事象 | 解決策ではなく事象が分かると、より良い解き方を検討できる | 「〇〇に時間がかかる」「〇〇でミスが起きる」を具体的な場面で |
| 優先順位 | 全部を一度に作ると費用も期間も膨らみ、結局使われない | 「これが解決すれば成功」と言える1つを決めておく |
| 関係者と既存の仕組み | 後から出てくると、設計のやり直しにつながりやすい | 誰が使うか、今どのシステム・ツールにデータがあるか |
ポイントは、きれいな資料を作ることではなく、社内にしかない情報を出すことです。 整理して文書にまとめるのは開発会社側の仕事なので、発注側は材料集めに集中するほうが、結果的に早く進みます。 以下、それぞれを掘り下げます。
そもそも要件定義で何が決まるのか
要件定義は、ひとことで言えば「何を作るかを決める工程」です。 どんな機能が必要か、どこまでを対象にするか、何を対象外にするか。 ここが曖昧なまま設計・開発に進むと、後から「思っていたものと違う」というすれ違いが起きます。
誤解されやすいのは、これが開発会社だけの作業ではないという点です。 進行と文書化は開発会社が担当しますが、今の業務がどう回っているか、何に困っているか、何を優先するかは、社内にしか答えがありません。 開発会社の役割は、その答えを引き出して形にすることであって、答えそのものを持っているわけではないのです。 だからこそ、材料を持ち込めるかどうかで、要件定義にかかる時間も出来上がるものの精度も変わってきます。
① 今の業務の流れを書き出す
まず用意したいのが、現在その業務がどう流れているかです。 誰が、どんな順番で、何を使って作業しているか。この現状が分からないと、 どこを自動化できてどこは人が判断すべきか、開発側は判断のしようがありません。
たとえば受注処理なら、「電話やメールで注文が来る → 担当者がエクセルに転記する → 在庫を確認する → 出荷指示を出す」 といった粒度で十分です。図にする必要も、正式な文書にする必要もありません。 むしろ体裁を整える過程で、実際にある例外処理が抜け落ちてしまうほうが問題です。 「基本はこうだが、この場合だけ別の人がやる」といった例外こそ、後で仕様に効いてきます。
実際に使っているエクセルや帳票があれば、それを見せるのが最も早い方法です。 現物には、言葉では説明しきれない運用の実態が現れています。
② 困っていることは「解決策」ではなく「事象」で書く
これが、準備の質を最も左右する部分です。 多くの場合、相談は「予約管理システムが欲しい」「顧客管理をシステム化したい」という解決策の形で持ち込まれます。それ自体は自然なことですが、 それだけだと検討できる選択肢が狭まります。
たとえば「予約管理システムが欲しい」と伝えると、そのシステムを作る前提で話が進みます。 しかし元の事象が「電話予約をノートに書いてからエクセルに転記していて、二度手間になっている」であれば、 既存ツールの設定変更で済むかもしれませんし、別の解き方が向いているかもしれません。事象まで伝わって初めて、より良い解決策を一緒に探せるようになります。
書き方のコツは、具体的な場面を添えることです。 「月末が忙しい」ではなく「月末に請求書を1件ずつ手作業で作っていて、2日かかっている」。いつ・誰が・何をしていて・何が困るかまで書けていれば、要件定義はかなりスムーズに進みます。 もちろん「こうしたい」という要望も一緒に伝えて構いません。要望と事象は、両方あるのが理想です。
③ 優先順位を決めておく
困りごとを書き出すと、たいてい複数出てきます。ここで全部を対象にすると、 費用も期間も膨らみ、結局どれも中途半端なまま使われないシステムになりがちです。
おすすめは、「これが解決すれば、今回は成功と言える」と思えるものを1つ決めておくことです。 残りは「できれば」「将来的に」と段階を分けておけば、予算や期間に応じて調整できます。 この優先順位は開発会社には決められません。どの業務がいちばん経営に効いているかを知っているのは社内だけだからです。
なお、優先順位を決めることは「他を諦めること」ではありません。 小さく作って動かし、効果を見ながら足していくほうが、結果的に無駄が少なくなります。
④ 関係者と既存の仕組みを洗い出す
見落とされやすいのが、誰が使うかと今どこにデータがあるかです。 この2つは、後から出てくると設計のやり直しにつながりやすい項目です。
使う人については、実際に毎日触る担当者の存在が重要です。 管理者だけで要件を決めたが、現場の作業実態と合わずに使われなくなった、というのはよくある結末です。 可能であれば、要件定義の場に実際の担当者にも入ってもらうのが確実です。
既存の仕組みについては、今使っている会計ソフト・販売管理・エクセル・クラウドサービスなどを挙げておきます。 連携が必要かどうか、既存データを引き継ぐ必要があるかで、作るものの規模が変わります。「実は別の部署でも似たデータを持っていた」という発見も、この洗い出しでよく出てきます。
準備しなくていいこと・やりすぎの線引き
ここまで挙げてきましたが、逆に発注側が無理に決めなくてよいこともあります。 準備を頑張りすぎて相談が遅れるほうが、機会損失としては大きくなります。
- 画面の細かいデザイン — どんな配置にするかは設計工程で一緒に決めます。先に固めると、かえって選択肢を狭めます。
- 技術の選定 — どの言語・どのクラウドを使うかは開発側の領分です。指定がある場合だけ伝えれば十分です。
- 正式な仕様書 — 文書化は開発会社の仕事です。メモや現物の資料で構いません。
- 完璧な予算額 — 幅や上限の感覚が伝われば、それに合わせた提案ができます。
自社の準備がどこまで整っているかを客観的に見たい場合は、外注前のチェックリストで6つの質問に答えると現在地が分かります。 また、要件定義が見積もりに含まれているかどうかは会社によって異なるため、見積書の見方もあわせて確認しておくと、金額の前提を取り違えずに済みます。
よくある質問
まとめ
要件定義の前に発注側が準備したいのは、今の業務の流れ・困っている事象・優先順位・関係者と既存の仕組みの4つです。 いずれも社内にしかない情報で、逆に言えばそれ以外は開発会社に任せて構いません。 きれいな資料より、現物と具体的な場面のほうが役に立ちます。 「何から整理すればいいか分からない」という段階のご相談も歓迎です。システム開発・業務改善サービスのページもあわせてご覧ください。相談・お見積もりは無料です。
