この記事で分かること
先代からシステムや業務のIT化を引き継いだものの、「発注のやり方」までは引き継げなかった、という後継社長は少なくありません。取引先や会計士から「RFP（提案依頼書）を作ってから発注した方がいい」と言われても、そもそも何を書けばいいのか、どこまで厳密に作らなければならないのか、見当がつかないという声を頻繁に聞きます。
この記事では、事業承継後の会社が現実的に取れる発注準備の進め方を、難しい専門用語を極力使わずに解説します。結論を先に言うと、多くの中小企業にとって「教科書通りの分厚いRFP」は不要です。会社の規模と発注の緊急度に応じて、必要な情報を最小限にまとめた「簡易版の発注メモ」で十分なケースが大半です。一方で、複数社から相見積もりを取る場面や、投資額が大きくシステムが会社の基幹に関わる場面では、もう少し丁寧な準備が効いてきます。この線引きを、承継後の会社が置かれやすい状況に沿って具体的に示していきます。
なぜ承継後の会社で「発注のやり方」が引き継がれにくいのか
先代がシステムを発注していた時代は、多くの場合、次のような進め方がとられていました。
- 昔からの付き合いのある業者に電話一本で相談する
- 「いつもの感じでよろしく」という口頭発注
- 見積もりは1社のみで、比較検討をしない
- 契約書や要件のメモがほとんど残っていない
これは決して先代のやり方が悪かったという話ではありません。長年の信頼関係の中で成立していた、ある意味では合理的なやり方でした。しかし、後継社長がこの状態を引き継いだとき、いくつかの問題が表面化します。
まず、先代と業者の間にあった暗黙の了解が、後継社長には見えません。「言わなくても分かってくれる」という関係性は、代が変わった瞬間にリセットされます。次に、業者側も先代が退いたことで、これまでのような柔軟な対応を続けるかどうかは分かりません。さらに、後継社長自身がシステムの内容を正確に理解していないまま契約を続けている場合、いざトラブルが起きたときに何を確認すればいいのかも分からなくなります。
つまり、承継後の会社には「発注の型」そのものが存在していないケースが多いのです。ここに新しく型を持ち込むこと自体は正しい判断ですが、その型を最初から重厚にしてしまうと、実務が回らなくなります。この記事で扱う「現実的な進め方」とは、承継後の会社の実情に合わせて、型を軽くしてから運用に乗せるという考え方です。
そもそもRFPとは何か、なぜ話題に出てくるのか
RFPとは、発注者が開発会社やベンダーに対して「こういう課題があり、こういうことを実現したいので、提案してください」という内容をまとめた文書のことです。日本語では提案依頼書と呼ばれます。
なぜ承継後の会社でこの言葉が話題に出てくるかというと、多くの場合、以下のようなタイミングで外部から助言されるためです。
- 複数の開発会社から見積もりを取ろうとしたとき、「比較するための共通の資料が必要」と言われる
- 顧問の会計士や中小企業診断士から、「投資判断の根拠を文書化した方がいい」と勧められる
- 商工会議所や事業承継の専門家から、「先代の口頭発注のやり方を見直すべき」と指摘される
- 補助金や助成金を申請する際に、「発注根拠となる資料の提出」を求められる
これらの背景はいずれも正当な理由です。ただし、ここで注意したいのは、「RFPという名前の分厚い文書を作らなければ発注してはいけない」という思い込みに陥らないことです。RFPという言葉自体は、あくまで「発注前に要件と目的を整理して文書化する」という行為の総称に過ぎません。分量や形式に厳密な決まりはなく、A4一枚のメモでも、要件と目的が明確に書かれていれば十分に機能する場合があります。
教科書的なRFPが承継後の会社に合わない理由
書籍やコンサルティング会社が示す標準的なRFPのテンプレートには、通常、次のような項目が並びます。
- 会社概要とプロジェクトの背景
- 現状の課題とゴールの定義
- システムに求める機能要件の一覧
- 非機能要件（セキュリティ、性能、可用性など）
- 予算感とスケジュール
- 提案書の提出方法と評価基準
- 契約条件、支払い条件
- 保守運用の範囲
これをすべて埋めようとすると、通常は数週間から数ヶ月の準備期間が必要になります。大企業の情報システム部門であれば、専任の担当者がこの作業に取り組めますが、承継後の中小企業では次のような制約があります。
まず、情報システムの専任担当者がいないことがほとんどです。総務や経理の担当者が兼務していたり、社長自身がIT担当を兼ねていたりします。次に、日々の業務が優先されるため、数週間もかけて文書作成に専念する時間が取れません。さらに、専門用語が並ぶテンプレートを見ても、そもそも「非機能要件」や「評価基準」といった項目に何を書けばいいのか分からず、手が止まってしまいます。
この結果、多くの中小企業では「RFPを作ろうとして途中で挫折し、結局また口頭発注に戻る」という悪循環が起きます。これは非常にもったいない状態です。RFPという名前にこだわらず、実質的に機能する最小限の資料を作ることの方が、承継後の会社にとってはずっと現実的です。
現実的な進め方：3段階の発注準備
ここからは、投資額や発注の重要度に応じて、準備の重さを3段階に分ける考え方を紹介します。すべての発注に同じ重さの資料を用意する必要はありません。
段階1：小規模・低リスクの発注（既存業者への追加依頼、軽微な改修など）
例えば、既存のホームページに新しいページを追加する、社内で使っている業務ソフトに小さな機能を追加してもらう、といった発注です。この場合は、以下の4項目を箇条書きでまとめたメモで十分です。
- 何をしてほしいか（依頼内容を一文で）
- なぜそれが必要か（背景・理由）
- いつまでに欲しいか（希望期限）
- 予算感（上限だけでも構いません）
これをメールやチャットの本文に書くだけでも、口頭発注に比べて格段に行き違いが減ります。承継直後の会社が最初に取り入れるべきなのは、この段階1の習慣です。難しい文書は不要で、まずは「頭の中にあることを文字にして送る」という行為自体を定着させることが重要です。
段階2：中規模の発注（新しいシステムの導入、既存システムの入れ替えなど）
例えば、会計システムを入れ替える、在庫管理システムを新規に導入する、といった発注です。投資額はおおむね数十万円から数百万円程度になり、複数社への相見積もりを検討する場面が増えてきます。この段階では、次の項目を1〜2枚程度の資料にまとめることを推奨します。
- 会社の概要（業種、従業員数、拠点数など、簡単な説明で十分）
- 今回のプロジェクトの目的（何のために導入するのか）
- 現状の課題（今、何に困っているか。具体的な業務のシーンで説明する）
- 実現したいこと（優先度の高いものから3〜5個程度に絞る）
- 予算の目安（幅を持たせた範囲で構いません)
- 希望する導入時期
- 判断基準（価格だけでなく、対応の速さや実績なども重視するならその旨を明記)
この段階2の資料があれば、複数の開発会社に同じ内容を渡して見積もりを依頼できます。比較の土台が揃うため、「A社は50万円、B社は200万円と言っているが、対応範囲が違うのか、それとも単に価格の差なのか」といった判断がしやすくなります。承継後の会社が最も効果を実感しやすいのは、実はこの段階2の場面です。条件をそろえて相見積もりを取るための具体的な伝え方は、相見積もりを取るとき、条件をそろえるための伝え方で詳しく解説している。
段階3：大規模・基幹に関わる発注（基幹システムの刷新、複数部門をまたぐ大型投資など）
例えば、受発注から在庫、会計までを一気通貫で扱う基幹システムを刷新する、複数の拠点をつなぐ大掛かりなシステムを新規構築する、といった発注です。投資額も数百万円から数千万円規模になり、失敗したときの影響も大きくなります。この段階では、段階2の項目に加えて、以下も加えることを検討してください。
- 現場の業務フロー（誰がいつ何をしているか、簡単な図やメモで整理する)
- 関係部署とその代表者（誰が意思決定に関わるか)
- 既存システムとの連携要否（今使っているソフトと連携させる必要があるか)
- 契約・保守の希望条件（導入後のサポート体制についての要望)
- 評価の進め方（提案を受けた後、どう比較して決めるか。社内で誰が最終判断するか)
段階3まで来ると、いわゆる教科書的なRFPに近い分量になりますが、それでも「必要な項目だけを、自社の言葉で書く」という姿勢は変わりません。テンプレートをそのまま埋めるのではなく、自社にとって意味のある項目だけを残し、分からない項目は空欄のままにせず、開発会社に相談しながら一緒に埋めていくという進め方が現実的です。いきなり段階3の規模で発注するのではなく、まず小さく発注して試すという選択肢もある。小さく発注して試す、承継後のPoC発注のすすめもあわせて検討してほしい。
承継後の会社ならではの落とし穴
事業承継という文脈に特有の落とし穴がいくつかあります。順に見ていきます。
落とし穴1：先代の代の契約内容が分からないまま更新してしまう
先代が契約していたシステムの保守契約や利用契約の内容を、後継社長が正確に把握していないケースは非常に多く見られます。契約更新の時期が来ても、内容を確認せずに「今までと同じでお願いします」と伝えてしまうと、実際には使っていない機能に費用を払い続けていたり、逆に必要な保守が範囲外になっていたりすることがあります。新しい発注を検討する前に、まず既存の契約書を引っ張り出して、契約範囲と金額を確認する作業から始めることを強くお勧めします。
落とし穴2：先代の代の業者との関係性を引き継げず、疎遠になる
先代の時代からの業者は、後継社長のことをよく知らない場合があります。逆に業者側から見ると、後継社長が何を求めているのか分からず、従来通りの提案しかできないという状況も起こります。この関係性のリセットは、必ずしも悪いことではありません。承継のタイミングは、これまでの発注のやり方を見直し、複数の業者を比較検討する良い機会でもあります。既存業者に義理立てして相見積もりを取らないまま契約を更新するよりも、簡易な資料を作って複数社に同じ内容を提示し、公平に比較する方が、後継社長自身の判断にも説得力が生まれます。
落とし穴3：社内に「発注の記録」を残す文化がなく、次の代にも引き継がれない
先代から受け取った引き継ぎ資料の中に、システムに関する情報がほとんど含まれていなかった、という声もよく聞きます。これは先代個人の問題ではなく、そもそも「発注内容を文書化する」という文化が社内になかったことが原因です。今回、後継社長が発注準備の資料を作ることは、単に今回の発注をスムーズにするだけでなく、将来また誰かがこの会社を引き継ぐときのための記録を残す作業にもなります。段階1のような簡易なメモであっても、フォルダにまとめて保存しておくだけで、数年後に大きな価値を持つことがあります。
落とし穴4：分からない専門用語を放置してしまう
開発会社から提案を受けた際、聞いたことのない専門用語が並ぶことがあります。分からないまま相槌を打って進めてしまうと、後になって「思っていたものと違う」というトラブルにつながります。分からない言葉が出てきたら、その場で「それはどういう意味ですか、具体的に何ができるということですか」と質問することを徹底してください。良心的な開発会社であれば、専門用語を分かりやすい言葉に言い換えて説明してくれるはずです。逆に、質問しても曖昧にしか答えない業者には注意が必要です。
発注準備メモの具体例
ここでは、架空の製造業の会社を例にした、段階2相当の発注準備メモの具体例を示します。実際に使う際は、自社の状況に合わせて項目を増減させてください。
プロジェクト名：受注管理のシステム化について
会社概要：金属加工業、従業員18名、取引先は主に法人30社程度
背景・現状の課題：現在、受注情報はFAXと電話で受け取り、担当者がエクセルに手入力して管理している。入力ミスや対応漏れが月に数件発生しており、取引先からの信頼にも影響している。先代の時代からこの方法を続けているが、担当者の高齢化もあり、属人的な運用に不安がある。
実現したいこと：
- 受注情報を一元管理し、担当者以外でも状況を確認できるようにしたい
- 入力ミスを減らす仕組みを入れたい
- 将来的には取引先がウェブ上から直接発注できるようにしたい（今回は必須ではない）
予算の目安：初期費用で100万円から200万円程度を想定。月額の運用費用は5万円以内が希望。
希望する導入時期：半年以内を目標とするが、拙速な導入よりも確実な移行を優先する。
判断基準：価格だけでなく、導入後の相談対応の速さや、同業種での導入実績を重視する。
このように、専門用語をほとんど使わずに、自社の言葉で状況を説明するだけで、開発会社側は十分に提案の検討を始められます。むしろ、専門用語を無理に使おうとして不正確な内容になるよりも、平易な言葉で正確に状況を伝える方が、良い提案を引き出せる可能性が高くなります。
相見積もりを取るときのチェックリスト
発注準備メモができたら、複数の開発会社に同じ内容を提示して見積もりを依頼します。その際に見落としがちな点をチェックリストにまとめました。
- 同じ資料を、すべての依頼先に同じタイミングで渡したか
- 見積もりの回答期限を明確に伝えたか（期限を伝えないと、回答が数週間先になることもある)
- 見積もりに含まれる範囲と含まれない範囲を、必ず質問して確認したか
- 導入後の保守費用や追加費用の発生条件を確認したか
- 契約解除の条件や、データの引き渡し条件を確認したか
- 担当者の名前と、緊急時の連絡先を確認したか
- 実際の導入事例や、同業種での実績を確認したか
- 提案内容について、分からない専門用語をすべて質問して解消したか
- 社内で最終的に誰が意思決定するかを、事前に決めておいたか
- 見積もりの有効期限（いつまでその価格が有効か）を確認したか
このチェックリストを、発注準備メモとセットで社内の共有フォルダに保存しておくと、次回以降の発注でも再利用できます。
どこまで丁寧にやるべきかの判断基準
「結局、どこまで丁寧に準備すればいいのか」という疑問に対しては、次の3つの基準で判断することをお勧めします。
基準1：投資額の大きさ。年間の売上や利益に対して、投資額がどの程度の割合を占めるかを考えます。目安として、投資額が数十万円程度であれば段階1から段階2の準備で十分です。数百万円を超えるようであれば、段階2から段階3の準備を検討してください。
基準2：失敗したときの影響範囲。そのシステムが止まったら、会社の業務がどこまで止まるかを考えます。例えば会社案内のホームページが数日止まっても業務に大きな影響はありませんが、受発注や会計に関わる基幹システムが止まると、会社全体の業務が止まってしまいます。影響範囲が広いほど、丁寧な準備が必要です。
基準3：関係者の多さ。この発注の結果を使う人が、自分一人か、それとも複数の部署にまたがるかを考えます。関係者が多いほど、後から「そんな話は聞いていない」というトラブルが起きやすくなるため、事前に文書化して共有しておく価値が高まります。
この3つの基準のうち、2つ以上が「大きい・広い・多い」に該当する場合は、段階3相当の準備を検討することをお勧めします。逆に、すべてが「小さい・狭い・少ない」に該当する場合は、段階1の簡易メモで十分です。
発注準備メモを作る前に、社内で確認しておくべきこと
発注準備メモを作り始める前に、実は先にやっておくべき下準備があります。多くの後継社長がここを飛ばしてしまい、資料作りの途中で手が止まってしまいます。
現状の業務を、誰かに聞きながら書き出す
先代の時代からの業務は、後継社長自身がすべてを把握しているとは限りません。特に、現場の担当者が長年同じやり方で仕事をしている場合、その業務のやり方は担当者の頭の中にしかなく、文書化されていないことがほとんどです。発注準備メモを作る前に、まずは現場の担当者に「今、どういう順番で、どういう作業をしているか」を聞き取ることをお勧めします。このとき、担当者を問い詰めるような聞き方ではなく、「引き継ぎのために教えてほしい」という姿勢で聞くと、率直な情報が出てきやすくなります。
聞き取りの際に確認しておきたい項目は次の通りです。
- その業務は、一日のうちいつ、どのくらいの時間をかけて行っているか
- 誰が担当していて、担当者が休んだときは誰が代わりを務められるか
- 今のやり方で、担当者自身が困っていることは何か
- 紙やエクセル、電話やFAXなど、どんな手段を使っているか
- 過去にミスやトラブルがあったとすれば、それはどんな内容だったか
こうした聞き取りの結果は、そのまま発注準備メモの「現状の課題」の部分に活用できます。後継社長が一人で想像で書くよりも、現場の実情に基づいた説得力のある文章になります。
過去の契約書やこれまでのやり取りを引っ張り出す
先代の時代に契約したシステムの契約書、見積書、請求書などが残っていれば、発注準備の前にひととおり確認しておくことをお勧めします。特に確認したいのは、現在いくら払っているか、その金額に何が含まれているか、契約の解除にはどういう条件があるか、といった点です。これらが分からないまま新しい発注を進めると、既存システムを解約するタイミングでトラブルになったり、想定していなかった解約費用が発生したりすることがあります。
契約書が見当たらない場合は、既存の業者に直接問い合わせて、契約内容の控えを再発行してもらうことも検討してください。長年の付き合いのある業者であれば、こうした依頼にも柔軟に対応してくれることが多いです。
経営者自身が「何のためにこの投資をするのか」を一度言葉にする
発注準備メモの中核は「実現したいこと」の項目ですが、これを書く前に、経営者自身が「なぜこの投資をするのか」を一度、紙に書き出してみることをお勧めします。単に「システムが古いから」という理由だけでなく、「この投資によって、会社をどういう状態に持っていきたいのか」まで考えておくと、発注準備メモの説得力が増します。
例えば、「受注管理をシステム化する」という投資の裏には、「担当者の高齢化に備えて、誰でも対応できる体制を作りたい」「取引先からの信頼を維持し、新規の取引先も増やしていきたい」といった、より大きな経営上の狙いがあることがあります。この狙いを発注準備メモに一文加えるだけで、開発会社側もより適切な提案をしやすくなります。
開発会社との最初の打ち合わせで聞くべきこと
発注準備メモを渡した後、実際に開発会社との打ち合わせが始まります。この打ち合わせの場で、後継社長側から積極的に聞いておくべきことをまとめました。専門用語が分からないことを恥じる必要はまったくありません。分からないことをその場で聞けるかどうかが、後々のトラブルを防ぐ最大のポイントです。
見積もりの前提条件について
開発会社が出す見積もりには、必ず何らかの前提条件があります。「この機能までは含む、これ以上の追加要望は別途費用がかかる」といった線引きです。この線引きが曖昧なまま契約すると、後から「追加費用がかかると言われて困った」という事態になりやすいです。打ち合わせの場では、次のような質問を投げかけてみてください。
- 「この見積もりに含まれている作業と、含まれていない作業を教えてください」
- 「途中で要望が変わった場合、追加費用はどのように発生しますか」
- 「見積もりの前提となっている台数や利用人数、データ量はどのくらいですか」
- 「今回の見積もりの範囲外になる典型的なケースを教えてください」
導入後のサポート体制について
システムを導入した後、何かトラブルが起きたときにどう対応してもらえるかは、発注前に必ず確認しておくべき事項です。特に、先代の時代からのシステムが老朽化していて、それを置き換えるという状況では、導入直後のトラブル対応の速さが会社の業務に直結します。
- 「トラブルが起きたとき、どのくらいの時間で対応してもらえますか」
- 「保守契約に含まれる対応と、含まれない対応の違いを教えてください」
- 「営業時間外や休日にトラブルが起きた場合はどうなりますか」
- 「担当者が変わった場合、引き継ぎはどう行われますか」
将来の拡張性について
今回の発注では対応しないが、将来的にはやりたいことがある場合、その旨を打ち合わせの場で伝えておくことをお勧めします。開発会社側が将来の拡張を見越した設計にしてくれるかどうかで、後々の追加費用や作業のしやすさが大きく変わってきます。
- 「将来、こういう機能を追加したいと考えているが、今回の設計はそれに対応できる作り方になっていますか」
- 「将来、利用人数や取引先が増えた場合、同じ仕組みのままで対応できますか」
- 「他社の似たようなシステムに乗り換えたくなった場合、データを持ち出すことはできますか」
この最後の質問は特に重要です。ある特定の業者の仕組みに依存しすぎてしまうと、将来その業者と関係を解消したくなったときに身動きが取れなくなることがあります。承継後の会社にとっては、先代の時代の「特定の業者に頼り切る」関係性を見直す良い機会でもあるため、データの持ち出しやすさについては必ず確認しておくべきです。
複数社の提案を比較するときの考え方
発注準備メモを複数社に渡し、それぞれから提案と見積もりが返ってきた後、どう比較すればいいか迷う後継社長も多くいます。ここでは、専門的な評価手法ではなく、後継社長が実際に使いやすい比較の考え方を紹介します。
価格だけで比較しない
複数社の見積もりを並べたとき、つい金額の安い方に目が行きがちですが、金額だけで判断すると失敗しやすくなります。なぜかというと、見積もりに含まれる作業の範囲が会社によって異なるためです。ある会社は最初から手厚い保守を含めて見積もりを出し、別の会社は最低限の初期構築だけを見積もりに含めて、保守は別途契約にしている、といったケースがよくあります。金額を比較する前に、まず「この金額には何が含まれているか」を揃えてから比較する必要があります。
提案書の分かりやすさも判断材料にする
提案書の中身が専門用語だらけで、読んでもよく分からない、という場合、それは今後のやり取りでも同じような分かりにくさが続く可能性を示しています。逆に、専門用語を使わずに、後継社長にも分かる言葉で丁寧に説明してくれる提案書であれば、導入後のコミュニケーションもスムーズに進む可能性が高いです。提案書の内容そのものだけでなく、「この会社とこれから何年も付き合っていけそうか」という視点も、比較の重要な材料にしてください。
同業種や近い規模の会社での実績を確認する
提案の中で紹介される導入事例が、自社と近い業種や規模であるかどうかも確認しておくべきポイントです。大企業向けの実績ばかりを紹介する会社が、実際に中小企業の実情に合わせた提案をできるかどうかは分かりません。逆に、中小企業向けの実績が豊富な会社であれば、予算や運用体制の制約を理解した上での提案をしてくれる可能性が高くなります。
一度、他の経営者仲間に話を聞いてみる
同じように事業承継を経験した経営者仲間や、商工会議所などのつながりで知り合った経営者に、システム導入の経験談を聞いてみることも有効です。実際に導入した後の感想や、契約時に見落としていた点などは、開発会社からは聞けない生の情報です。特に、同じ地域や同じ業種の経営者からの情報は、参考になることが多くあります。
発注後にやっておくべきこと
発注準備メモを作り、複数社を比較し、契約先を決めた後も、後継社長が気をつけておくべきことがあります。
契約内容と発注準備メモを見比べて、ずれがないか確認する
契約書が届いたら、最初に作った発注準備メモと見比べて、内容にずれがないかを確認してください。特に、「実現したいこと」として挙げた項目のうち、どこまでが契約に含まれているのかを一つずつ確認することをお勧めします。口頭でのやり取りの中で、いつの間にか対象範囲が狭くなっていたり、逆に想定していなかった追加費用が発生する条件が盛り込まれていたりすることがあります。このずれを最終的に発見する場が納品時の検収であり、その具体的な進め方は検収とは？後継社長が納品時にやるべき確認と落とし穴にまとめている。
進行中の打ち合わせ内容を、簡単でも記録に残す
システムの構築が始まると、開発会社との打ち合わせが何度も行われます。この打ち合わせの内容を、簡単なメモでも構わないので記録に残しておくことをお勧めします。「何を決めたか」「誰がいつまでに何をするか」を毎回の打ち合わせの終わりに確認し、短いメールで双方に送っておくだけでも、後々の行き違いを大きく減らせます。これは先代の時代にはなかった習慣かもしれませんが、後継社長の代からこの習慣を根付かせることには大きな価値があります。
発注準備メモ自体を、社内の記録として保存する
プロジェクトが完了した後も、発注準備メモや契約書、打ち合わせの記録は、社内のフォルダにまとめて保存しておくことをお勧めします。これは単に今回のプロジェクトの記録としてだけでなく、将来、また別のシステムを発注するときの参考資料としても役立ちます。さらに、いつか後継社長自身がこの会社を次の世代に引き継ぐ日が来たとき、これらの記録は非常に価値のある引き継ぎ資料になります。先代からは口頭でしか引き継がれなかったことを、次の世代にはきちんと文書で引き継げるようにする、という積み重ねが、承継後の会社の体質を少しずつ強くしていきます。
発注準備メモの見直しに使えるセルフチェック
最後に、発注準備メモを書き終えた後、提出する前に自分自身で見直すためのセルフチェックの項目をまとめます。
- 専門用語を使わずに、自社の言葉で書けているか
- 「何をしてほしいか」が一文で言い切れているか
- 「なぜ必要か」という背景が具体的な業務のシーンで説明されているか
- 予算感に幅を持たせて、無理な金額を書いていないか
- 希望する時期が、社内の他の業務の繁忙期と重なっていないか
- 判断基準（価格以外に何を重視するか）が明記されているか
- 誰が最終的に意思決定するかが、社内で共有されているか
- 既存システムとの関係（残すのか、置き換えるのか）が明確になっているか
- 分からない項目を、空欄のまま放置していないか
このセルフチェックをクリアできれば、発注準備メモとしては十分に機能する内容になっているはずです。完璧な文書を目指す必要はなく、まずは自社の状況を正確に伝えられているかどうかを確認することが最も重要です。
発注準備メモを社内の「型」として定着させる
一度発注準備メモを作って発注がうまくいったら、その経験を社内の「型」として残しておくことをお勧めします。具体的には、今回使った発注準備メモのひな形を、社内の誰でも見られる場所に保存しておき、次に似たような発注が発生したときに、そのひな形を流用できるようにしておきます。
この型が社内に定着すると、後継社長自身が毎回すべてを一から考える必要がなくなります。さらに、将来、後継社長の下で新しく総務や経理を担当する社員が入ってきたときにも、この型を渡すだけで、発注の基本的な進め方を引き継げるようになります。先代の時代には存在しなかった「発注の型」を、後継社長の代で作り、次の世代にも引き継げる仕組みにしていく。これが、この記事で紹介してきた現実的な進め方の、最終的な狙いです。
発注準備メモとRFPという言葉の関係を、もう一度整理する
ここまで紹介してきた発注準備メモは、内容としては教科書的なRFPの簡易版にあたります。RFPという名前を使うかどうかは、実務上はさほど重要ではありません。大切なのは、次の3点が満たされているかどうかです。
- 発注者側が「何を実現したいか」を明確に言葉にできているか
- その内容が、複数の関係者（社内の担当者、開発会社の担当者）に共通して伝わる形で文書化されているか
- 発注前に一度、その内容を見直し、修正する機会が設けられているか
この3点が満たされていれば、それがA4一枚の簡易メモであっても、実質的にはRFPと同じ役割を果たしていると言えます。逆に、体裁だけ整った分厚い文書があっても、この3点が満たされていなければ、実務上は機能しません。承継後の会社にとって重要なのは、名前や体裁ではなく、この3点を満たす習慣を社内に根付かせることです。
発注準備を通じて、承継後の経営そのものを整えていく
発注準備メモを作るという行為は、実はシステムの発注だけにとどまらない効果を持っています。現状の業務を洗い出し、課題を言葉にし、社内の関係者と合意を取る、というプロセスそのものが、承継後の経営を整えていく作業になっています。
先代から引き継いだ会社を、後継社長自身の言葉で、後継社長自身のやり方で運営していくための最初の一歩として、システムの発注準備は非常に良い練習の場になります。最初は小さな発注から始めて、段階的に慣れていくことで、いずれ大きな投資判断が必要になったときにも、落ち着いて対応できる土台が育っていきます。
発注準備を「専門家に丸投げ」しないための注意点
外部の専門家やコンサルタントに発注準備メモの作成を依頼することも、選択肢の一つとして考えられます。ただし、この際に注意しておきたい点があります。発注準備メモの内容が、経営者自身の実感や現場の実情から離れた、体裁だけの立派な文書になってしまうと、実際の発注や導入の場面でうまく機能しないことがあります。
専門家に依頼する場合でも、最終的には後継社長自身が内容を理解し、自分の言葉で説明できる状態にしておくことが重要です。専門家に「作ってもらう」のではなく、専門家と「一緒に整理する」という姿勢で進めることをお勧めします。特に、現場の担当者への聞き取りや、経営上の狙いの整理といった部分は、後継社長自身が関わることで、より実情に合った内容になります。
発注準備を「一人で抱えない」という選択
承継後の社長にとって、発注準備の資料作成を一人で背負い込む必要はありません。次のような相談先を活用することも現実的な選択です。
- 顧問の会計士や税理士に、投資判断の根拠づけとしての視点で相談する
- 商工会議所や中小企業の支援機関に、資料作成のひな形について相談する
- 信頼できる開発会社に、資料の作り方自体を一緒に相談しながら決めていく
特に3つ目については、良心的な開発会社であれば、発注前の段階から「どういう資料があると提案しやすいか」を教えてくれることが多くあります。RFPという名前の文書を、後継社長が一人で完璧に仕上げる必要はまったくありません。まずは分かる範囲を箇条書きにして、開発会社に見せながら「ここが分からないので教えてほしい」と相談する、という進め方でも十分にスタートできます。
業種別に見る、発注準備メモの重点ポイント
最後に、業種によって発注準備メモの重点が変わってくる点についても触れておきます。すべての会社に同じ書き方が当てはまるわけではないため、自社の業種に近い例を参考にしてください。
製造業の場合
製造業では、受発注や在庫、生産の管理に関わるシステムが中心になることが多く、現場の作業手順と密接に関わります。発注準備メモには、現場でどのように部品や材料の情報が流れているか、どの工程で誰が何を確認しているか、といった業務フローの情報を、簡単な図でも構わないので添えることをお勧めします。文章だけでは伝わりにくい現場の流れも、簡単な矢印付きの図があるだけで開発会社側の理解が大きく進みます。
小売業・サービス業の場合
小売業やサービス業では、顧客とのやり取りや、予約・注文の受付に関わるシステムが中心になりやすいです。この場合、発注準備メモには「顧客からどういう経路で連絡が来るか」「ピーク時にはどのくらいの件数を処理しているか」といった、顧客対応の実情を具体的に書き込むことが有効です。特に、繁忙期と閑散期で業務量に大きな差がある業種では、その差についても触れておくと、開発会社側がシステムの処理能力を適切に見積もりやすくなります。
建設業・工事関連の場合
建設業や工事関連の会社では、現場ごとに異なる担当者や協力会社が関わることが多く、情報の共有範囲が複雑になりやすい特徴があります。発注準備メモには、「誰が、どの現場の情報にアクセスできる必要があるか」「協力会社にも情報を共有する必要があるか」といった、関係者の範囲についての情報を明記しておくことをお勧めします。この点が曖昧なまま発注すると、後から「協力会社にも見せられる仕組みにしてほしかった」といった行き違いが発生しやすくなります。
卸売業・物流関連の場合
卸売業や物流関連の会社では、複数の取引先や複数の拠点をまたいだ情報のやり取りが発生しやすいです。発注準備メモには、「取引先ごとに異なるやり方（例えば、ある取引先だけFAXでの受発注を続けているなど）が残っていないか」を整理して記載しておくことをお勧めします。取引先ごとの例外的な運用が多い業種ほど、システム化する際にその例外をどこまで残すか、あるいは統一するかという判断が重要になります。
発注準備メモを作る際に、経営者が忘れがちな視点
発注準備メモを作成する過程で、後継社長が見落としやすい視点についても触れておきます。
現場の抵抗感への配慮
新しいシステムを導入する際、現場の担当者が長年使ってきたやり方を変えることに抵抗を感じる場合があります。特に、先代の時代から同じやり方を続けてきた担当者にとっては、新しいシステムへの切り替えが大きな負担に感じられることもあります。発注準備メモの中で、「操作のしやすさ」や「導入時の教育・研修のサポート体制」についても触れておくと、開発会社側が導入時の支援を含めた提案をしてくれる可能性が高まります。
段階的な導入の可能性
大きなシステムを一度にすべて入れ替えるのではなく、段階的に導入していく方法についても検討する価値があります。例えば、最初は一部の業務だけをシステム化し、現場が慣れてきたら次の業務も対応範囲を広げていく、という進め方です。発注準備メモの中で、「今回はどこまでの範囲を対象とし、将来的にどこまで広げたいか」を明記しておくと、開発会社側も段階的な提案をしやすくなります。承継直後で社内の体制がまだ整っていない場合、この段階的な導入の考え方は特に有効です。
よくある質問
RFPを作らずに発注してもいいのでしょうか
小規模で低リスクな発注であれば、この記事で紹介した段階1の簡易メモで十分に機能します。ただし、投資額が大きい、複数社を比較したい、社内の複数部署が関わる、といった場面では、何らかの形で要件と目的を文書化しておくことを強くお勧めします。文書化する理由は、開発会社に正確に伝えるためだけでなく、後から「言った言わない」のトラブルを防ぐためでもあります。
専門用語が多くて何を書けばいいか分かりません
専門用語を使う必要はまったくありません。この記事の具体例のように、「今、何に困っているか」「何を実現したいか」を、自社の日常の言葉で書くだけで十分です。専門用語は、開発会社側が提案する際に使うものであり、発注者側が無理に使う必要はありません。分からない言葉が出てきたら、その都度質問して確認する姿勢の方が重要です。
先代の代からの業者に、今さら資料を出すのは気まずいのですが
気まずさを感じる必要はありません。むしろ、これまで口頭でのやり取りが中心だった関係性を、文書によるやり取りに切り替えることは、双方にとって仕事の質を上げる機会になります。長年の付き合いのある業者であれば、後継社長が資料を用意して依頼してきたことを、むしろ前向きに受け止めてくれる場合が多いです。既存の業者への義理と、複数社を比較検討することは両立できます。まずは既存の業者にも同じ資料を渡し、他社にも同時に依頼する、という進め方が公平です。
どのくらいの時間をかけて準備すればいいですか
段階1の簡易メモであれば、30分から1時間程度で作成できます。段階2の資料であれば、半日から数日程度を目安にしてください。段階3の資料であっても、関係者への聞き取りを含めて1〜2週間程度で仕上げることを目標にするのが現実的です。教科書的なRFPのように数ヶ月かけて完璧な文書を作ろうとすると、その間に状況が変わってしまったり、担当者の意欲が失われてしまったりすることがあります。まずは今分かっている範囲で書き始め、開発会社との対話の中で内容を精緻化していくという進め方をお勧めします。
まとめ
事業承継後の会社にとって、RFPという言葉に構えすぎる必要はありません。大切なのは、名前や形式ではなく、「何をしてほしいか」「なぜそれが必要か」「予算と期限はどの程度か」という基本情報を、自社の言葉で文書に残す習慣を持つことです。
投資額や影響範囲に応じて準備の重さを3段階に分け、小さな発注には簡易メモ、中規模の発注には1〜2枚の要件整理、基幹に関わる大きな発注には業務フローや関係者情報まで含めた資料、という具合に、段階的に丁寧さを上げていく考え方が、承継後の会社にとって最も現実的な進め方です。
先代の時代の口頭発注から、文書による発注へと切り替えることは、後継社長が会社の意思決定の仕組みを自分の代でアップデートする第一歩でもあります。この記事で紹介した簡易メモや具体例、チェックリストを、まずは次の小さな発注から試してみてください。積み重ねた資料は、将来この会社を引き継ぐ次の世代にとっても、貴重な記録になっていきます。
