要件定義、開発会社に伝わる資料の作り方
「刷新したい気持ちはあるが、開発会社に何を伝えればいいのか分からない」——先代から会社を引き継いだ経営者から、この相談を受けることは少なくありません。先代のシステムがいつからか誰にも把握されない状態になっていて、業務は現場の勘と紙とExcelでかろうじて回っている。そろそろ手を打たなければと思うものの、いざ開発会社に相談しようとすると、何を話せばいいのか分からず足が止まってしまう。
この足踏みの正体は、たいてい「要件定義」という言葉への戸惑いです。開発会社との最初の打ち合わせで「要件定義から始めましょう」と言われても、それが具体的に何を指すのか、自分が何を用意すればいいのか、経営者の立場では見当がつかないのが普通です。前職でシステム開発に関わった経験がなければ、なおさらです。
この記事は、次のような状況にある方に向けて書いています。
- 先代の代からのシステムを刷新したいが、開発会社に何を伝えればいいのか分からない
- 「要件定義書を作ってください」と言われたが、テンプレートを見ても何を書けばいいのか手が止まる
- 現場の業務は分かるが、それを「システムの言葉」に翻訳する方法が分からない
- 過去に一度、開発会社との認識違いで追加費用や手戻りを経験し、同じ失敗を繰り返したくない
結論を先に言うと、経営者であるあなた自身が分厚い仕様書を書く必要はありません。必要なのは、開発会社が「何を、誰のために、どう使うか」を正確に理解できるだけの材料を、あなたの言葉でそろえることです。この記事では、その材料をどう集め、どう整理し、どんな形にまとめれば開発会社に伝わるのかを、承継後の経営者という立場に即して具体的に解説します。開発会社に相談する前に社内で決めておきたいことは、刷新を開発会社に相談する前に、決めておきたい3つのことにもまとめている。
要件定義とは何か、経営者はどこまで関わるべきか
まず言葉の整理から始めます。要件定義とは、これから作るシステムに「どんな機能が必要か」「誰がどう使うか」といった要求を、発注者と開発会社の間で明確にしていく工程を指します。開発の一番最初に行われる作業であり、ここで固めた内容が、その後の設計・開発・テストのすべての土台になります。
多くの経営者が誤解しているのは、「要件定義は開発会社の仕事だから、丸投げしてよい」という考え方です。たしかに、要件をシステムの仕様に落とし込む専門的な作業は開発会社が担います。しかし「そもそも何をしたいのか」「誰のどんな業務を、どう変えたいのか」という出発点の情報は、発注者側、つまり経営者や現場の担当者しか持っていません。ここを開発会社に委ねてしまうと、開発会社は限られた情報から推測で仕様を組み立てることになり、後から「思っていたものと違う」という食い違いが発生します。
IPA（独立行政法人情報処理推進機構）が発行する「ユーザのための要件定義ガイド 第2版」でも、要件定義の責任はシステムを利用してビジネスに貢献する側、つまり発注者にあると位置づけられています。システム開発の遅延や失敗の多くが要件定義の段階でのつまずきに起因するとも指摘されており、この工程を軽視できないことは、経営者個人の感覚ではなく、業界的にも共有された認識だと言えます。
ここで重要なのは、経営者が「要件定義書」という体裁の整った文書そのものを書く必要はない、という点です。求められているのは、開発会社が正確に理解するための「材料」を提供することです。文書の体裁を整え、専門的な用語で仕様に落とし込む作業は開発会社の仕事であり、経営者の仕事は「現場で何が起きているか」「何を実現したいか」を、開発会社が誤解しないように伝えることに尽きます。
なぜ承継後の会社ほど要件定義でつまずきやすいのか
承継後の経営者が要件定義で苦労する理由には、いくつかの共通する背景があります。
第一に、先代の時代のシステムがどう使われているか、経営者自身が正確に把握していないケースが多いことです。先代が独断で導入したシステムや、古参社員が長年の慣習で使い続けている業務フローは、経営者から見ると「何がどう動いているのか」がブラックボックスになっていることがあります。要件定義は「今の業務をどう変えたいか」を語る工程ですが、その前提となる「今の業務がどうなっているか」自体が分からなければ、開発会社に伝える材料が集まりません。
第二に、社内に相談できる相手がいないことです。情報システム部門を持つ大企業であれば、要件定義の実務は情シス担当者が主導し、経営者は方針を承認する立場に立てます。しかし従業員数十人規模の中小企業では、そうした専門部署が存在せず、経営者自身が発注者としての役割をすべて担わなければならない場面が多くなります。
第三に、古参社員の協力を得にくいことです。要件定義には、実際に業務を行っている現場の声が欠かせません。ところが「今のやり方を変えられるのではないか」という不安から、古参社員が業務の詳細を話すことに消極的になるケースがあります。経営者が一人で開発会社と向き合おうとすると、現場の実情を反映しない要件定義になってしまうリスクがあります。
これらの背景を踏まえると、承継後の経営者に必要なのは「専門知識を身につけること」ではなく、「現場の情報を集める仕組みと、それを開発会社に伝える型」を持つことだと分かります。以下、その具体的な手順を見ていきます。
開発会社に伝わる資料を作る5つのステップ
ステップ1：解決したい課題を1枚にまとめる
最初にやるべきことは、機能の話をする前に「なぜシステムを刷新したいのか」を明文化することです。開発会社との会話がいきなり「こんな機能が欲しい」から始まると、その機能が本当に課題を解決する手段なのか、開発会社側も判断がつきません。
まとめる内容は次の3点で十分です。
- 今、現場で困っていること（具体的な業務の場面で書く）
- その結果、会社にどんな損失や負担が生じているか（時間・人手・ミスの発生など）
- 理想としては、どういう状態になれば「解決した」と言えるか
例えば「請求書の作成を手作業で行っており、月末に担当者が3日間かかりきりになっている。転記ミスも年に数件発生している。理想は、受注データから請求書を自動生成できる状態」というように、1つの課題ごとに3行程度でまとめます。これを課題の数だけ並べれば、1枚の資料として十分に機能します。
この段階では専門用語を使う必要はまったくありません。むしろ、日常の言葉で具体的に書くことのほうが重要です。開発会社は、抽象的な「業務を効率化したい」という言葉よりも、「誰が」「いつ」「何に」困っているかという具体的な場面の記述から、必要な機能を逆算できます。
ステップ2：業務の流れを箇条書きで書き出す
次に、課題が発生している業務の流れを、時系列の箇条書きで書き出します。フローチャートのような図を描く必要はありません。次のような順序立てた文章で十分です。
- 誰が（担当者・部署）
- いつ（月末・受注時・毎日など）
- 何を使って（Excel・紙の台帳・既存システムの名前）
- どういう作業をして（入力・確認・転記・印刷など）
- 誰に渡す、または何が完成するか
この書き出しを、現場の担当者にヒアリングしながら埋めていきます。経営者自身がすべての業務を把握しているとは限らないため、実際にその作業をしている社員に「今、この作業はどういう順番でやっていますか」と聞くところから始めるのが確実です。
ここで見えてくるのが、承継後の会社特有の「なぜこの手順になっているのか誰も説明できない」という工程です。先代が昔決めたルールがそのまま残り、今の業務には不要になっているのに惰性で続けられている手順が見つかることは珍しくありません。要件定義の段階でこうした工程を洗い出しておくと、開発会社から「この作業は本当に必要ですか」という有益な指摘を受けられることもあります。
ステップ3：使う人と使う場面を具体的に書く
システムを実際に使うのは誰か、そしてどんな場面で使うのかを明確にします。経営者自身が使うのか、経理担当者が使うのか、営業担当者が外出先のスマートフォンから使うのか、パソコンに不慣れな高齢の従業員も使うのか——これによって、開発会社が提案する画面の作り方や操作の複雑さが大きく変わります。
書くべき内容は次のとおりです。
- 主な利用者は誰か（部署・年齢層・ITへの慣れ具合）
- どこで使うか（社内のパソコンのみ／外出先のスマートフォンも含む）
- どのくらいの頻度で使うか（毎日／月末のみ／年に数回）
- 同時に何人くらいが使う想定か
例えば「経理担当は60代のパートスタッフで、パソコンの操作に不安があるため、入力項目はできるだけ少なくシンプルな画面にしてほしい」という情報は、機能そのものの話ではありませんが、開発会社にとっては画面設計の重要な判断材料になります。この種の情報は、経営者や現場の担当者しか持っておらず、開発会社側からは聞き出しにくい情報でもあるため、意図的に資料に含めておくことが望まれます。
ステップ4：「絶対に必要」と「できれば欲しい」を分ける
要件を書き出していくと、機能の希望リストがどんどん膨らんでいきます。ここで重要なのが、優先順位を「絶対に必要な機能」と「できれば欲しい機能」の2段階に分けることです。
すべてを「絶対に必要」として伝えてしまうと、開発会社は全部を同じ重要度として見積もらざるを得ず、結果として予算や期間が想定以上に膨らんでしまいます。逆に、優先順位を示せば、開発会社は「まずこの範囲で作り、後から機能を追加できる設計にする」といった提案をしやすくなります。
分け方の目安は次のとおりです。
| 区分 | 判断の目安 |
|---|---|
| 絶対に必要 | この機能がなければ、今の業務課題が解決しない |
| できれば欲しい | あると便利だが、無くても業務は成立する |
| 今回は見送り | 将来的には検討したいが、今回のスコープには含めない |
この仕分けを事前に行っておくことで、限られた予算の中でまず何を作るべきかという判断が、経営者自身の手を離れず、開発会社との対話の中で建設的に進められるようになります。
ステップ5：今使っているデータと連携先を書き出す
最後に見落とされがちなのが、既存のデータと、連携が必要な他のシステムの情報です。先代の代から使っているExcelファイルや、古い基幹システムに蓄積されたデータを新しいシステムに引き継ぐ必要があるのか、他の会計ソフトや販売管理システムと連携する必要があるのかによって、開発の難易度や費用は大きく変わります。
書き出す内容は次のとおりです。
- 今、業務で使っているExcelファイルやシステムの名前
- そこに蓄積されているデータの量（おおよその件数や年数）
- 新しいシステムに引き継ぐ必要があるデータの範囲
- 連携させたい既存の他システムやサービスの名前
ここで特に注意したいのが、先代の時代に導入されたシステムの中には、データを外部に取り出す方法自体が用意されていない、あるいは開発会社が既に廃業していて確認できない、というケースがあることです。この点は要件定義の初期段階で疑わしいと感じたら、早めに開発会社へ伝え、データ移行の可否を先に調査してもらう必要があります。データが引き継げないと分かった段階で計画全体を見直すよりも、要件定義の段階で発覚したほうが、後戻りの費用を抑えられます。
資料の形式はどこまで整えるべきか
ここまでの5つのステップを終えると、次のような資料の骨格が自然に出来上がります。
- 解決したい課題一覧（誰が・何に困っているか・理想の状態）
- 業務の流れ（現状の作業手順を時系列で）
- 利用者と利用場面の情報
- 機能の優先順位（絶対に必要／できれば欲しい／今回は見送り）
- 既存データと連携先の情報
これをPowerPointの数枚にまとめても、Wordの文章として書いても、あるいはExcelの表形式で整理しても構いません。形式そのものに正解はなく、開発会社が読んで理解できることが唯一の基準です。むしろ形式を整えることに時間をかけすぎるより、内容の具体性を優先すべきです。手書きのメモに近い状態でも、内容が具体的であれば、開発会社は十分に理解して打ち合わせを進められます。
逆に避けたいのは、抽象的な言葉だけで終わらせてしまうことです。「業務を効率化したい」「使いやすいシステムにしたい」という表現だけでは、開発会社は具体的な仕様に落とし込めず、想像で機能を組み立てることになります。抽象的な言葉を使ったら、必ずその直後に「具体的にはどういう場面か」という一文を添える習慣をつけると、資料全体の精度が上がります。
開発会社との打ち合わせで起きやすい行き違い
資料を用意して打ち合わせに臨んでも、いくつかの行き違いが起きやすい場面があります。事前に知っておくことで、落ち着いて対応できます。
「それは要件ではなく要望です」と言われる
開発会社によっては、経営者が伝えた内容を「要件」と「要望」に分けて整理し直すことがあります。要件は「必ず実現すべきこと」、要望は「実現できれば良いが必須ではないこと」という区別です。この整理自体は開発会社の専門的な仕事であり、経営者側が事前に完璧な要件定義書を用意できていなくても問題ありません。むしろ、経営者が伝えた情報の中から開発会社が要件と要望を仕分けていく過程そのものが、要件定義の打ち合わせの本質です。焦って自分だけで完璧な文書を作ろうとせず、開発会社との対話を通じて精度を上げていく姿勢で構いません。
現場の担当者の意見と経営者の意見が食い違う
要件定義の打ち合わせに現場の担当者を同席させると、経営者が把握していなかった業務の実情が明らかになることがあります。時には、経営者が想定していた解決策と、現場が本当に困っている点がずれていることも判明します。これは決して悪いことではなく、要件定義の段階でこの食い違いに気づけたことは、開発が始まってから食い違いに気づくよりもはるかに望ましい状態です。むしろ、こうした食い違いが見つからないまま要件定義が終わってしまうことのほうが危険だと考えてください。
予算に対して要望が多すぎると指摘される
ステップ4で優先順位を分けていたとしても、実際に見積もりが出てくると「絶対に必要」とした機能だけでも予算を超えることがあります。この場合、開発会社と一緒に、機能そのものを削るのか、開発の範囲を段階的に分けるのかを相談することになります。ここで役立つのが、最初から機能を絞った小さな範囲でシステムを試験的に作り、効果を検証しながら本格開発に進める考え方です。承継後の会社では、こうした段階的な進め方を選ぶケースが多く見られます。
要件定義でやってはいけない3つのこと
具体的な手順に加えて、承継後の経営者が陥りやすい失敗も押さえておきます。
1つ目は、開発会社に「お任せします」と伝えて丸投げすることです。 開発会社は技術の専門家ですが、あなたの会社の業務の専門家ではありません。丸投げされた開発会社は、限られたヒアリングの中で推測を重ねて仕様を組み立てることになり、完成後に「思っていたものと違う」という結果を招きやすくなります。
2つ目は、先代の時代のやり方をそのままシステム化しようとすることです。 要件定義は、単に今の業務をそのままデジタルに置き換える作業ではありません。先代の時代に決まった手順の中には、今の事業規模や人員体制にはもう合わなくなっているものが含まれていることがあります。要件定義の場は、そうした手順を見直す機会でもあります。
3つ目は、一度まとめた資料を「完成品」として固定してしまうことです。 要件定義は、開発会社との対話を通じて何度も内容を見直しながら精度を上げていく工程です。最初に用意した資料に固執せず、打ち合わせで出てきた指摘や現場からの新しい情報を反映して、資料を都度更新していく姿勢が求められます。
開発会社からよく聞かれる質問に、先回りして答えておく
要件定義の打ち合わせでは、開発会社側から一定のパターンで質問が飛んできます。これらをあらかじめ想定し、資料の中に答えを組み込んでおくと、打ち合わせの回数を減らせます。承継後の会社で実際によく聞かれる質問を紹介します。
「今のシステムは何を使っていますか」
先代の代から使っているシステムやソフトウェアの名前、導入した時期、契約している開発会社やベンダーの名前を聞かれます。経営者が把握していない場合、まずは契約書や請求書を確認する、あるいは経理担当や総務担当に聞くところから始める必要があります。中には、契約自体が先代個人の名義になっている、担当者が退職して連絡先が分からないというケースもあり、この確認だけで数日かかることもあります。要件定義の打ち合わせより前に、時間の余裕を持って調べておくことをおすすめします。
「そのデータは今、どこにありますか」
顧客情報や取引履歴など、引き継ぎたいデータが実際にどこに保存されているかを聞かれます。「担当者のパソコンの中」「クラウドサービスの中」「紙の台帳」など、保存場所は業務によってさまざまです。保存場所が分かれば、そこからデータを取り出せるのか、取り出せるとしてどんな形式になるのかを、開発会社が調査できます。この調査には時間がかかることもあるため、早い段階で情報を伝えておくと、後工程の遅れを防げます。
「予算感はどのくらいをお考えですか」
多くの経営者が答えづらいと感じる質問です。相場が分からないまま金額を口にすることに抵抗を感じる方もいますが、開発会社に予算感を伝えないまま進めると、実現できない機能を前提とした要件定義が進んでしまい、後から大きな見直しが必要になるリスクがあります。正確な金額でなくても、「このくらいまでなら検討できる」というおおよその範囲を伝えるだけで、開発会社は現実的な提案の幅を絞り込めます。もし社内で予算がまだ固まっていない場合は、その旨を正直に伝え、複数のパターンで見積もりを出してもらうという進め方も選択肢の一つです。予算面では、対象になり得る制度がないかをデジタル化・AI導入補助金（旧IT導入補助金）は先代からのシステム刷新に使えるかで確認しておくのもよい。
「いつまでに使えるようにしたいですか」
希望する完成時期を聞かれます。承継後の経営者は「早ければ早いほど良い」という気持ちを持ちがちですが、具体的な理由のない期限を伝えると、開発会社は無理な工程で進めざるを得なくなり、品質の低下や後工程でのしわ寄せにつながることがあります。もし決算のタイミングや、既存システムの契約終了時期など、動かせない理由のある期限があれば、その理由も含めて伝えることで、開発会社は優先順位をつけた工程を組みやすくなります。
要件定義でよくある失敗パターンとその防ぎ方
承継後の会社に特有の失敗パターンを、実際の相談でよく見られる形に整理しました。自社に当てはまるものがないか、確認しておくと安心です。
失敗パターン1：現場の声を聞かずに経営者だけで決めてしまう
経営者が「効率化したい」という思いだけで要件を固めてしまい、実際に使う現場の担当者の意見を反映しないまま開発が進んでしまうパターンです。完成後、現場から「使いにくい」「今までのやり方のほうが早かった」という反発が起き、せっかく作ったシステムが定着しないという結果になりがちです。防ぐためには、要件定義の初期段階で必ず現場の担当者を巻き込み、意見を聞く機会を設けることが欠かせません。
失敗パターン2：先代の時代の業務ルールをそのまま要件にしてしまう
先代の時代に決まった承認の手順や、二重チェックの工程を、深く考えずにそのまま新しいシステムの要件に含めてしまうパターンです。事業の規模が変わり、担当者の体制も変わっているにもかかわらず、古い手順を前提にシステムを作ってしまうと、せっかく刷新しても業務の重さは変わらないという結果になります。要件定義の段階で、それぞれの手順が「今も本当に必要か」を一つずつ確認する時間を取ることが重要です。
失敗パターン3：機能を盛り込みすぎて予算と期間が膨らむ
ステップ4で紹介した優先順位付けを行わないまま、思いつく限りの機能をすべて「必要」として伝えてしまうパターンです。結果として、当初想定していた予算や期間を大きく超える見積もりが出てきて、計画そのものを見直さなければならなくなります。優先順位を決める作業は地味に感じられますが、この工程を省略すると、後工程での手戻りのほうがはるかに大きな負担になります。
失敗パターン4：資料を一度作ったら見直さない
要件定義の初期段階で作った資料を、その後の打ち合わせで得られた新しい情報を反映せずに固定してしまうパターンです。打ち合わせを重ねるうちに、当初は気づかなかった業務の実情や、優先順位の変化が明らかになることは自然な流れです。資料はいつでも更新して構わないものだと理解しておくことで、開発会社との対話がより実りのあるものになります。
チェックリスト：開発会社に相談する前に確認しておきたいこと
打ち合わせに向かう前に、次の項目を確認しておくと、当日の会話がスムーズに進みます。
- [ ] 解決したい課題を、具体的な業務の場面で3行程度にまとめてあるか
- [ ] 課題が発生している業務の流れを、担当者にヒアリングして書き出したか
- [ ] 主な利用者の年齢層やITへの慣れ具合を把握しているか
- [ ] 機能を「絶対に必要」「できれば欲しい」「今回は見送り」の3段階に分けたか
- [ ] 引き継ぐ必要のあるデータと、連携が必要な既存システムを書き出したか
- [ ] 先代の時代のシステムについて分かる社員に、事前に話を聞いたか
- [ ] 想定している予算のおおよその範囲を、自分の中で決めているか
- [ ] 資料の内容を、開発が始まってからも見直す前提でいると理解しているか
すべての項目を完璧に埋められていなくても構いません。むしろ、埋められていない項目があること自体が、開発会社との打ち合わせで確認すべき論点として役立ちます。
資料作りにどのくらいの時間を確保すればよいか
具体的な時間の目安についても触れておきます。もちろん会社の規模や課題の複雑さによって変わりますが、承継後の経営者が初めて要件定義の資料を作る場合、おおよその目安として次のような時間配分を想定しておくと計画が立てやすくなります。
まず、ステップ1の課題の書き出しは、経営者一人で取り組む部分が中心であり、半日から1日程度で最初の骨格は作れます。ここは経営者自身の頭の中を整理する作業なので、時間をかけすぎず、まずは思いつく限りを書き出してしまうことをおすすめします。
次に、ステップ2の業務の流れの書き出しと、ステップ3の利用者情報の整理は、現場の担当者へのヒアリングが必要になるため、1〜2週間程度を見込んでおくとよいでしょう。担当者のスケジュールを調整し、1回30分から1時間程度のヒアリングを複数回行うことになります。日々の業務に追われている現場の担当者に時間を取ってもらうことになるため、経営者からあらかじめ「〇〇について聞かせてほしい」と事前に伝えておくと、当日の話がスムーズに進みます。
ステップ4とステップ5は、それまでに集めた情報を整理する作業が中心であり、数日程度で形にできます。ただし、既存システムのデータ移行に関する調査が必要な場合は、開発会社に確認を依頼する必要があり、その回答待ちの時間が追加でかかることもあります。
全体を通して、資料の初版を作るまでに2週間から1ヶ月程度を見込んでおくと、無理なく進められます。この期間は、開発会社との打ち合わせが始まる前の、社内での準備期間として捉えてください。もちろん、打ち合わせが始まった後も資料は更新され続けるため、この期間で「完成」させる必要はなく、開発会社と対話を始められる程度の材料がそろえば十分です。
資料作りを一人で背負い込まないための工夫
承継後の経営者は、経理から営業、現場管理まで幅広い業務を一人で背負っていることが多く、要件定義の資料作りに十分な時間を割けないという悩みを抱えがちです。この負担を軽減するための工夫をいくつか紹介します。
まず、資料作りの作業そのものを分担することです。ステップ2の業務の流れの書き出しは、経営者本人ではなく、現場を最もよく知る社員に下書きを依頼し、経営者はその内容を確認・修正する役割に回るという分担も可能です。すべてを経営者が一から書く必要はありません。
次に、開発会社に相談する前の準備段階から、開発会社に相談してしまうという方法もあります。多くの開発会社は、初回の相談やヒアリングの段階から、要件定義の材料集めを一緒に進めてくれます。資料が完璧に整っていない状態で相談することを避ける経営者もいますが、実際には、未完成の状態からでも相談を始め、開発会社の質問に答えていく過程で資料を完成させていくという進め方のほうが、効率的な場合が多くあります。
最後に、社内に相談できる相手がいない場合は、商工会議所や中小企業診断士など、外部の中立的な立場の専門家に相談するという選択肢もあります。特定の開発会社の利益に偏らない立場から、資料の整理を手伝ってもらえることがあります。
FAQ
要件定義書のテンプレートをそのまま使えば大丈夫ですか
テンプレートは書く項目の枠組みを示してくれるという点で有用ですが、枠組みを埋めることが目的化してしまうと、内容の薄い資料になりがちです。テンプレートの項目を見て「何を書けばいいか分からない」と感じた場合は、この記事のステップ1から順に、自分の会社の言葉で内容を先に固め、それをテンプレートの項目に当てはめていく順序のほうが、結果的に伝わる資料になります。
現場の社員がヒアリングに協力してくれない場合はどうすればよいですか
いきなり全体像を聞き出そうとせず、「今日はこの1つの作業だけ教えてください」と範囲を区切って質問すると、負担感が減り協力を得やすくなります。また、要件定義の目的が「今のやり方を否定すること」ではなく「今のやり方を正確に開発会社に伝えるため」であることを、先に丁寧に説明しておくことも効果的です。現場の担当者は、自分たちの仕事のやり方が変わってしまうことへの不安から消極的になっている場合が多く、目的を誤解されないようにする配慮が要件定義の初期段階では重要です。
要件定義にはどのくらいの期間をかけるべきですか
システムの規模や課題の複雑さによって大きく異なるため、一律の期間を示すことはできません。ただし、経営者側の準備、つまりこの記事で紹介した5つのステップの資料作りに時間をかけておくほど、開発会社との打ち合わせの回数や期間を圧縮できる傾向があります。逆に、準備が不十分なまま打ち合わせを重ねると、同じ内容を何度も確認し合う手戻りが発生し、結果的に要件定義全体の期間が長引くことになります。
要件定義とRFP（提案依頼書）は同じものですか
異なる工程です。RFPは、複数の開発会社に相見積もりを依頼する際に、要望や予算感を伝えるための文書であり、要件定義よりも前の段階、あるいは要件定義と並行して使われることが多い文書です。要件定義は、発注する開発会社が決まった後、実際に作るシステムの内容を詳細に固めていく工程を指します。この記事で紹介した資料作りは、RFPを作る段階でも、要件定義そのものの段階でも、どちらでも土台として活用できます。
事例で見る、資料作りのビフォーアフター
抽象的な説明だけでは実感が持ちにくいため、実際によくあるパターンを2つの事例で見ていきます。いずれも複数の経営者から聞いた話をもとに、典型的な状況として再構成したものです。
事例1：受注管理をExcelから刷新したい製造業
従業員30人ほどの部品加工業を継いだ経営者のケースです。受注情報を古参社員が1人でExcelに入力し、生産部門への指示も同じファイルを印刷して手渡すという運用が20年近く続いていました。この経営者が最初に開発会社に伝えた言葉は「受注管理システムを作ってほしい」という一言だけでした。開発会社からは「どんな機能が必要か、もう少し具体的に教えてください」と返され、そこで初めて資料作りに取り組み始めます。
ステップ1で課題を書き出したところ、実際の課題は「受注入力」そのものではなく、「入力を担当している古参社員が休むと、誰も代われない」という属人化の問題であることが分かりました。ステップ2で業務の流れを書き出す過程では、受注情報が3つの部署を経由して初めて生産指示になっていること、その途中で口頭確認が2回挟まれていることが判明しました。これらの情報を整理した結果、開発会社への相談内容は「受注管理システムを作る」という当初の依頼から、「複数部署がリアルタイムで同じ受注情報を見られるようにし、口頭確認の工程を減らす」という、より具体的な要件に変わりました。この変化こそが、資料作りの本来の目的です。
事例2：顧客対応の履歴が個人のメモ帳にしかない販売業
先代が創業した小売業を継いだ2代目のケースでは、顧客からの問い合わせ対応の履歴が、担当者個人のノートにしか残っていないという状態でした。この経営者は「顧客管理システムを入れたい」という要望を持っていましたが、ステップ3で利用者の情報を整理する段階で、実際にシステムを使うのは60代のベテラン社員が中心であり、パソコン操作に強い抵抗感を持っていることが分かりました。
この情報がなければ、開発会社は一般的な顧客管理システムの機能を前提に提案を進めていたかもしれません。しかし利用者の実情を先に伝えたことで、開発会社からは「入力項目を最小限に絞り、選択式の入力を中心にした簡易な画面にする」という提案が出てきました。機能の豊富さよりも、実際に使われ続けることを優先した設計方針は、利用者の情報を具体的に伝えたからこそ導き出せたものです。
これら2つの事例が示しているのは、経営者が最初に思いつく要望（「受注管理システム」「顧客管理システム」)は、多くの場合、本当に解決すべき課題そのものではなく、課題を解決するための手段の一つに過ぎないという点です。要件定義の資料作りは、この手段の手前にある本当の課題を掘り出す作業でもあります。
社内での資料作りを進める体制の作り方
ここまでの5つのステップは、経営者が1人で机に向かって完成させるものではありません。実際には、社内の複数の人からの情報収集が欠かせません。承継後の会社でこの体制をどう作るかについて、具体的に触れておきます。
誰にヒアリングするかをリストアップする
まず、業務に関わる社員を部署ごとにリストアップし、それぞれに何を聞くべきかを整理します。経理担当、受発注担当、現場の作業担当など、業務の種類ごとに聞くべき相手は異なります。1人の社員がすべての業務を把握しているとは限らないため、複数人からの情報を集めて初めて全体像が見えてくることを前提に進めます。
ヒアリングは1回で終わらせない
一度のヒアリングで完璧な情報を得られることは稀です。最初のヒアリングでは大まかな業務の流れをつかみ、資料をまとめる過程で疑問点が出てきたら、再度その社員に確認するという往復を前提にしておきます。特に、承継直後で経営者と現場社員との信頼関係がまだ十分に築かれていない場合、最初のヒアリングでは表面的な回答しか得られず、関係性が深まるにつれて本当の課題が語られるようになることもあります。
先代への確認が必要な場面もある
先代がまだ経営に関与している、あるいは相談できる関係にある場合、システムの導入経緯や、なぜその運用ルールになっているのかという背景を確認できることがあります。この確認は、現在の業務を否定するためではなく、なぜ今の形になっているのかを理解し、変えるべき部分と残すべき部分を見極めるために行います。先代に確認する際は、「今のやり方を変えたい」という切り出し方よりも、「会社が今後も困らないように、経緯を教えてほしい」という伝え方のほうが、協力を得やすい傾向があります。
資料は1人の担当者が集約する
複数人からヒアリングした情報がそれぞれの断片のまま散らばっていると、開発会社に渡す段階で矛盾や重複が生じます。経営者自身か、社内で最も業務全体を把握している社員が1人、情報を集約する役割を担うことが望ましいです。集約担当が全体を通して読み直すことで、部署ごとに言葉の使い方が違う、同じ業務を指しているのに呼び方が違う、といった食い違いにも気づきやすくなります。
開発会社を選ぶ段階でも、この資料が役に立つ
ここまで紹介した資料は、要件定義のためだけに使うものではありません。実は、開発会社を選ぶ段階、つまり複数の開発会社に相談したり相見積もりを取ったりする段階でも、同じ資料がそのまま役立ちます。
相見積もりを取る際、開発会社ごとに異なる説明をしてしまうと、返ってくる見積もりの前提条件がそろわず、金額の比較そのものが意味を持たなくなってしまいます。事前に資料を1つ用意しておき、どの開発会社にも同じ内容を提示することで、見積もりの条件をそろえられます。これは、後になって「あの会社にはこう説明したはずなのに」という食い違いを防ぐ意味でも重要です。
また、資料を提示した際の開発会社の反応も、その会社を見極める材料になります。資料の内容を丁寧に読み込み、具体的な質問を返してくる開発会社は、要件定義を一緒に進めるパートナーとして信頼できる可能性が高いといえます。一方で、資料をほとんど確認せずに「とりあえず作ってみましょう」と即答するような会社には、慎重な姿勢で向き合うことをおすすめします。要件定義を軽視する開発会社は、開発が始まってからの認識違いや手戻りのリスクを抱えやすい傾向があります。
資料をまとめる際に使える言い回しの工夫
最後に、実際に文章としてまとめる際の細かい工夫を紹介します。専門用語を避けて具体的に書くという原則を、より実践しやすくするための工夫です。
まず、「〜したい」という願望の言葉だけで終わらせず、必ず「なぜそうしたいのか」を1文添える書き方をおすすめします。例えば「入力を簡単にしたい」で終わらせず、「入力を簡単にしたい。理由は、担当者が60代で、複雑な操作だと入力ミスや作業の遅れにつながっているから」というように、理由をセットで書きます。理由が書かれていると、開発会社はその手段だけでなく、他の解決策も含めて検討できるようになります。
次に、数字が分かる部分は必ず数字で書きます。「よく起きる」「たまにある」といった表現ではなく、「月に3回程度」「年間で10件程度」というように、頻度や量を具体的に示します。正確な数字が分からない場合でも、「おおよそ月10件前後」という形で幅を示せば十分です。数字がないよりも、幅のある数字がある方が、開発会社は規模感をつかみやすくなります。
最後に、業務で使っている社内独自の呼び方には、必ず簡単な補足を添えます。「〇〇台帳」「△△シート」といった社内でしか通用しない呼び方は、開発会社には伝わりません。「〇〇台帳（受注内容を記録しているExcelファイル）」というように、初めて読む人にも分かる説明を括弧で添えるだけで、資料全体の伝わりやすさが大きく変わります。
まとめ
要件定義という言葉の重さに身構えてしまう経営者は少なくありませんが、実際に求められているのは、専門的な文書を一人で完成させることではありません。現場で何が起きているか、誰が困っているか、理想としてはどうなりたいか——これらを、経営者自身の言葉で具体的に書き出すことが出発点です。
先代の時代のシステムを刷新するという場面では、業務の背景を知る手がかりが社内に少なく、経営者一人で情報を集めるのは簡単ではありません。しかし、この記事で紹介した5つのステップを1つずつ埋めていけば、開発会社が正確に理解できるだけの材料は十分にそろいます。事例で見たように、最初に思いついた要望が、実際に掘り下げていくと別の本当の課題に変わることも珍しくありません。完璧な資料を目指す必要はなく、開発会社との対話を重ねながら精度を上げていくという姿勢を持って、まずは手元にある情報を書き出すところから始めてみてください。
