はじめに ― 「大きく発注して失敗する」のが一番怖い
先代から会社を引き継いだばかりの後継社長にとって、システム発注は「初めて自分の判断で会社の大金を動かす仕事」のひとつです。営業や工場のことなら先代の背中を見て育ってきたので勘が働くけれど、ITとなると勝手が違う。見積書に並ぶ「要件定義」「基本設計」「保守運用」という言葉の意味すら曖昧なまま、開発会社の説明を信じて数百万円の契約書に印鑑を押す。そして半年後、「思っていたものと違う」「現場が使いこなせない」「そもそも業務が変わってしまって、発注時に決めた仕様が今のやり方に合っていない」という事態に陥る。これは特殊な失敗ではなく、中小企業のシステム発注で繰り返されてきた典型的な失敗パターンです。
この記事で伝えたいのは、たった一つのシンプルな考え方です。最初から全部を一括で発注しない。まず小さく発注して、動くものを試してから、本格発注に進む。 この段階的なアプローチのことを、IT業界では「PoC」と呼びます。PoCとは Proof of Concept の略で、直訳すれば「概念実証」、つまり「そのアイデアが実際に機能するかどうかを、小さく作って確かめる」という意味です。
後継社長がPoC発注という考え方を知っているかどうかで、システム投資の成否は大きく変わります。この記事では、なぜ小さく発注すべきなのか、PoCとは具体的に何を発注することなのか、発注時にどう業者と話せばいいのか、そして関連する重要な考え方であるMVP（実用最小限の製品）（必要最小限の製品）についても、専門用語が分からない後継社長の目線でできるだけ丁寧に解説していきます。
なぜ承継直後の後継社長がシステム発注で失敗しやすいのか
先代の「勘」が使えない領域だから
先代経営者は、長年の経験から「この取引先はこういう癖がある」「この時期はこの部材が値上がりする」といった業界特有の勘を培ってきました。しかし、システム開発の発注においては、この勘がそのまま通用しません。ITの世界には独自の相場観、独自の失敗パターン、独自の契約リスクがあります。後継者が先代のやり方をそのまま引き継いでも、システム発注という場面では初心者からのスタートになってしまうのです。
さらに厄介なのは、先代の時代に導入されたシステムが、実はすでに時代に合わなくなっているケースが多いことです。20年前に導入した基幹システムを保守し続けているだけで、業務の実態とシステムの機能がずれてしまっている。承継後の後継社長は「このシステム、本当に今の会社に必要なのか」を判断する材料すら持っていないまま、更新やリプレイスの意思決定を迫られることになります。
「一括で全部決めてしまう」発注スタイルのリスク
昔ながらの受託発注の多くは、最初にすべての要件を固めて、それに基づいて見積もりを出し、契約を結び、数か月から1年かけて作り上げて、最後に納品されるという進め方でした。これを「ウォーターフォール型」と呼びます。この方式には一つの大きな弱点があります。最初に決めた仕様が正しいかどうかを確認できるのは、全部作り終わった最後の段階になってしまうという点です。
たとえば、後継社長が「取引先からの注文をシステムで自動的に受け付けたい」と考えて、要件を固めて発注したとします。半年かけてシステムが完成し、いざ現場で使ってみると、「実際の注文は電話やFAXが多く、システム経由の注文はほとんど来ない」という現実にぶつかる。これは仕様の誤りというより、そもそも「取引先がシステム経由で注文してくれるかどうか」という前提そのものが検証されていなかったことが原因です。
もし最初に、簡易な受注フォームだけを作って、数社の取引先に試しに使ってもらっていたら、この前提のズレは1か月もかからずに発覚したはずです。数百万円をかけて半年後に気づくのと、数十万円で1か月後に気づくのとでは、ダメージの大きさが全く違います。これが「小さく発注して試す」ことの本質的な価値です。
開発会社との情報の非対称性
もう一つ見落とされがちな理由があります。後継社長と開発会社の間には、知識量に大きな差があります。開発会社は「要件定義書」や「基本設計書」という言葉を当然のように使いますが、後継社長にとっては初めて聞く言葉かもしれません。この情報の非対称性がある状態で、いきなり大きな金額の契約を結ぶのは危険です。
PoCという小さな発注を挟むことで、後継社長は「この開発会社は約束通りのものを、約束通りの期間で作れるのか」「コミュニケーションはスムーズか」「見積もりの根拠は納得できるものか」を、少額の投資で見極めることができます。いわば「本番発注の前のお見合い期間」としての役割も、PoCは果たしてくれるのです。
PoCとは何か ― 概念実証を発注するということ
PoCの正確な意味
PoC（Proof of Concept、概念実証）とは、「あるアイデアや仕組みが、実際に技術的・業務的に機能するかどうかを、最小限の範囲で作って確かめる」ための取り組みです。ポイントは、PoCは「本番で使う製品」を作ることが目的ではないということです。あくまで「このアイデアは筋が良いのか、悪いのか」を確認するための実験です。
たとえば、「AIを使って請求書のデータを自動で読み取り、会計システムに入力する仕組みを作りたい」という構想があったとします。この構想を最初から本番システムとして作り込むのではなく、まずは「実際に手元にある請求書50枚をAIに読み取らせてみて、どのくらいの精度で正しく読み取れるか」を試すのがPoCです。精度が9割以上出るなら本格開発に進む価値がある。精度が5割程度なら、そもそもこの構想自体を見直すべきだということが分かります。こうしたAI活用の筋の良さを小さく確かめる工程は、運営会社ゼットリンカーのAI PoC開発のように、受託開発メニューとして提供している開発会社もあります。
PoCで確認すべき3つの観点
PoC発注を検討する際、後継社長が確認すべきことは大きく3つに分けられます。
第一に、技術的に実現可能かという観点です。「やりたいこと」が、今の技術水準で本当に実現できるのかを確かめます。前述のAI請求書読み取りの例のように、精度や処理速度が業務で使えるレベルに達するかを検証します。
第二に、現場が実際に使ってくれるかという観点です。どんなに技術的に優れた仕組みでも、現場の従業員や取引先が使ってくれなければ意味がありません。操作が複雑すぎる、既存の業務フローと合わない、といった問題は、実際に触ってもらわないと分からないことが多くあります。
第三に、投資に対して見合う効果が出そうかという観点です。PoCの段階で、本格導入した場合にどれくらいの時間短縮やコスト削減が見込めるかを、実測データを基にざっくり試算します。この試算が芳しくなければ、本格発注に進むべきではありません。
PoCと「試作品」の違い
ここで、後継者がよく混同しがちな概念を整理しておきます。PoCは「試作品を作ること」に似ていますが、目的が少し違います。試作品（プロトタイプ）は「見た目や操作感を確認するための模型」であることが多く、実際のデータや実際の業務ロジックまでは組み込まれていない場合もあります。一方でPoCは、「実際に動くかどうか」「実際のデータで機能するかどうか」を確認することに重点があります。見た目の美しさよりも、「本当に動くのか」「効果が出るのか」を優先するのがPoCです。
発注時にこの違いを理解しておくと、開発会社との会話がスムーズになります。「見た目のイメージを見せてほしい」という要望であれば試作品（プロトタイプ）の話であり、「このアイデアがうまくいくかどうかを確かめたい」という要望であればPoCの話です。両者を混同したまま発注すると、期待していたものと違う成果物が出てくる原因になります。
PoC発注のメリットを具体的な数字感で理解する
コストの桁が変わる
一般的な感覚として、本格的な業務システムの受託開発は、規模にもよりますが数百万円から千万円単位の投資になることが少なくありません。これに対してPoCは、対象を絞り込むことで数十万円から百数十万円程度に収まるケースが多くあります。桁が一つ変わるというのが実感に近いイメージです。
もちろん案件の複雑さによって金額は変動しますが、重要なのは「本格発注前に、失敗の可能性が高い部分だけを先に小さく検証できる」という発注のかたちそのものです。100万円のPoCで「この構想はうまくいかない」と分かれば、900万円の本格開発で同じ失敗をするのを防げたことになります。逆に、PoCがうまくいけば、その結果を持って本格発注の予算を社内で説明しやすくなるという利点もあります。
期間が短く、判断のサイクルが速い
本格的な受託開発は、要件定義から納品まで半年から1年かかることも珍しくありません。これに対してPoCは、対象を絞れば1か月から2、3か月程度で結果が出ることが多いです。後継社長という立場では、次から次へと経営判断を求められる中で、「半年待たないと良し悪しが分からない投資」を続けるのは正直かなりのリスクです。PoCによって判断のサイクルを短くできることは、経営のスピード感にも直結します。
社内の合意形成がしやすくなる
先代の時代からの幹部社員が社内にいる会社では、後継社長が新しいシステム投資を提案しても、「そんなものは必要ない」「今までのやり方で十分だ」という反発が起きることがあります。ここで最初から大きな予算を提示すると、反発はさらに強くなりがちです。
一方でPoCという「まず小さく試す」提案であれば、幹部社員も「試すだけなら」と納得しやすくなります。そして実際にPoCの結果として「作業時間が3割減った」「入力ミスがゼロになった」といった具体的な成果が出れば、その実績をもって本格発応への合意形成がぐっと楽になります。数字と実物を見せられることの説得力は、抽象的な計画書よりもはるかに強力です。
「小さく発注する」を実践する ― 発注時の具体的な進め方
ステップ1：解決したい課題を一つに絞る
PoC発注で最も重要な最初の一歩は、「今回のPoCで何を確かめたいのか」を一つに絞り込むことです。後継社長にはやりたいことがたくさんあるかもしれませんが、PoCで複数の課題を同時に検証しようとすると、結果がぼやけてしまい、何が原因で何がうまくいったのかが分からなくなります。
たとえば「受注管理を効率化したい」という大きな課題があったとしても、そのなかで「取引先からの注文をFAXから電子フォームに切り替えられるか」という一点に絞ってPoCを設計します。他の課題（在庫連携や請求書発行の自動化など）は、次のPoCや本格発注のフェーズに回します。
ステップ2：成功・失敗の判断基準を事前に決める
PoC発注をする前に、「どうなったら成功と言えるのか」を数字で決めておくことが欠かせません。たとえば「取引先の3割以上が電子フォームで注文してくれたら成功」「AIの読み取り精度が9割を超えたら成功」といった具体的な基準です。
この基準を事前に決めずにPoCを始めると、結果が出た後で「これは成功なのか失敗なのか」を判断できず、なんとなく本格発注に進んでしまうということが起こります。それでは、PoCを挟んだ意味が半分失われてしまいます。判断基準は開発会社と一緒に、PoC発注の契約前に文書として残しておくことをお勧めします。
ステップ3：開発会社に「PoCとして発注したい」と明確に伝える
意外に見落とされがちなポイントですが、開発会社に発注する際は「これは本格システムの発注ではなく、PoCとして小さく試したい」ということを明確に伝える必要があります。開発会社によっては、PoCという言葉を使わずに話を進めると、最初から本格システムの提案書を作ってくることがあります。そうなると見積もりも大きくなり、こちらの意図とずれてしまいます。
発注時の会話の例としては、「まずは小さく、この一点だけを確かめたいので、必要最小限の範囲で見積もりをください」「本格発注ではないので、デザインや細かい機能は後回しで構いません」といった伝え方が有効です。良い開発会社であれば、この意図を理解して、必要最小限の見積もりと期間を提示してくれるはずです。逆に、この意図を伝えても大きな提案しか返してこない開発会社は、PoCという発注形態に不慣れである可能性があり、注意が必要です。こうした発注前のやり取りで何を先に決めておくべきかは、刷新を開発会社に相談する前に、決めておきたい3つのことでも整理している。
ステップ4：PoCの成果物と「その後」を事前に確認しておく
PoC発注をする際には、「PoCで作ったものは、その後どうなるのか」も事前に確認しておくべきです。PoCで作ったプログラムやデータを、本格開発の際にそのまま活用できるのか、それとも一から作り直しになるのかは、開発会社によって方針が異なります。
一部の開発会社は、PoCを「捨てるための実験用コード」として作り、本格開発時には別のチームが最初から作り直すという進め方をします。これは決して悪いことではありません。実験用のコードは検証の速度を優先して作られているため、そのまま本番で使うと後々のトラブルの原因になることもあるからです。しかし、この方針を後継社長が知らずにいると、「PoCで払った金額が無駄になった」と誤解してしまうことがあります。契約前に、PoCの位置づけと成果物の扱いについて、しっかり説明を受けておきましょう。PoCであっても、成果物を受け取る際の確認の考え方は本格発注と共通する部分が多く、検収とは？後継社長が納品時にやるべき確認と落とし穴も参考になる。
PoCの次に来る「MVP」という考え方
PoCで「このアイデアは筋が良い」と分かったら、次に検討すべきなのがMVP（必要最小限の製品）という考え方です。MVPとは、必要最小限の機能だけを備えた製品を指す言葉で、PoCが「アイデアが動くかどうかの実験」であるのに対し、MVPは「実際に現場で使い始められる、最低限だけど本物の製品」という位置づけになります。
PoCで受注フォームのアイデアが有効だと分かったら、次はMVPとして「実際に取引先が日常的に使える、必要最小限の機能を備えた受注システム」を作ります。デザインの美しさや高度な分析機能などは後回しにして、まずは「注文を受け付ける」という核となる機能だけを備えた製品を、現場に投入します。そこで得られた実際の使用データやフィードバックをもとに、少しずつ機能を追加していく。これが、PoC → MVP → 本格システムという、段階的な発注の流れです。
後継社長にとって重要なのは、この3段階を意識して発注計画を立てることです。最初からいきなり本格システムを目指すのではなく、まずPoCで筋の良さを確かめ、次にMVPで実際に現場に投入し、そこからさらに磨き込んでいく。この段階を踏むことで、投資額に対する失敗リスクを各段階で最小化することができます。
PoC発注でよくある失敗パターンと回避策
失敗パターン1：PoCの範囲が広すぎる
PoCという名目で発注しているのに、実際には本格システムに近い機能を全部含めて発注してしまうケースがあります。これではPoCの本来の目的である「小さく、早く、安く試す」ことができません。開発会社から提示された見積もりや仕様書を見て、「これは本当に最小限の範囲か」を後継社長自身がチェックする姿勢が必要です。範囲が広いと感じたら、「もっと削れる部分はないか」と開発会社に率直に相談しましょう。
失敗パターン2：判断基準を決めずに始めてしまう
前述の通り、成功・失敗の判断基準を事前に決めずにPoCを始めてしまうと、結果を評価できません。「なんとなく良さそうだから本格発注しよう」という曖昧な判断で大きな投資に進んでしまうのは、PoCを挟まなかった場合と同じリスクを抱えることになります。数字で判断基準を決める、これを徹底してください。
失敗パターン3：PoCの結果を社内で共有しない
PoCを実施して結果が出たにもかかわらず、その結果を社内の関係者(現場の従業員や他の役員)に共有しないまま、後継社長一人の判断で本格発注に進んでしまうケースがあります。PoCの価値の一つは「実物を見せて社内の合意形成をしやすくする」ことにあるので、結果は必ず関係者に共有し、意見を聞く場を設けましょう。これは本格発注後の「現場が使ってくれない」というトラブルを防ぐことにもつながります。
失敗パターン4：PoCを実施した開発会社に、そのまま本格発注してしまう
PoCの結果が良かったからといって、そのままPoCを実施した開発会社に本格発注を任せるのが自動的に正解とは限りません。PoCは小規模な実験なので、その開発会社が大規模な本格開発を安定して遂行できる体制を持っているかどうかは、別途確認が必要です。PoCでの対応の丁寧さや技術力を評価材料にしつつ、本格発注の際には改めて他社の見積もりと比較検討することをお勧めします。もちろん、PoCでの信頼関係を評価して継続発注するという判断も十分に合理的です。要は「自動的に」ではなく「検討した上で」という姿勢が大切だということです。
発注前に確認しておきたいチェックリスト
PoC発注を検討する後継社長のために、契約前に確認すべき項目をチェックリストとしてまとめます。開発会社との打ち合わせの際に、このリストを手元に置いて確認してみてください。
- 今回のPoCで確かめたい課題は、一つに絞られているか
- 成功・失敗を判断する基準を、数字で事前に決めているか
- 見積もりの範囲は、本当に必要最小限になっているか(不要な機能が含まれていないか)
- PoCの期間はどのくらいか、その期間は妥当だと感じられるか
- PoCで作った成果物(プログラムやデータ)は、その後どう扱われるのか
- PoC終了後、結果をどのような形で報告してもらえるのか(数字を含む報告書があるか)
- PoCの結果が良くなかった場合、その後どうするかを開発会社とすでに話し合っているか
- 社内の現場担当者や役員に、PoCの実施と結果を共有する予定を立てているか
- 契約書や見積書に、PoCという位置づけが明記されているか(本格発注と誤解されない書き方になっているか)
- 開発会社とのコミュニケーションは、専門用語を後継社長が理解できる言葉で説明してもらえているか
このチェックリストの項目に一つでも不安がある場合は、契約前に開発会社に質問し、納得できる回答が得られるまで契約を保留することをお勧めします。小さな発注だからこそ、遠慮なく質問する姿勢が大切です。
具体例で見るPoC発注のイメージ
具体例1：製造業での在庫確認アプリ
ある製造業の後継社長は、先代の代から続く紙の在庫台帳を電子化したいと考えていました。しかし、いきなり本格的な在庫管理システムを発注するのではなく、まずは「スマートフォンで在庫を確認できる簡易アプリ」だけをPoCとして発注しました。対象は工場内のたった一つの部材倉庫に絞り、現場の従業員2名だけに使ってもらう小規模な実験です。
1か月後、「紙の台帳を見に行く手間が減った」という現場の声と、「在庫確認にかかる時間が半分になった」という実測データが得られました。この結果を持って、社内の幹部会議で本格導入の予算を提案したところ、実測データがあったことで反対意見はほとんど出ず、全社的な在庫管理システムの本格発注に進むことができました。
具体例2：小売業でのAI活用の検証
ある小売業の後継社長は、「AIで来店客の動線を分析し、売り場の改善に活かせないか」というアイデアを持っていました。しかし、AIという言葉には期待と不安が入り混じっており、いきなり大きな予算をかけるのは怖いと感じていました。
そこで、店舗の一角にカメラを1台だけ設置し、1週間分のデータをAIで分析するPoCを発注しました。結果として、「想定していた通路の混雑は実は起きていない」「別の場所に思わぬ滞留が発生している」という発見があり、AIの分析自体は一定の精度で機能することも確認できました。この結果を踏まえ、次のステップとして、複数店舗への展開を見据えたMVPの発注に進むことを検討しています。この事例では、PoCの結果が「想定通り」ではなく「想定と違う発見があった」ことにも大きな価値がありました。もし最初から全店舗にカメラを本格導入していたら、同じ発見をするのに何倍もの投資と時間がかかっていたはずです。
具体例3：サービス業での予約システム改善
ある美容関連のサービス業を営む後継社長は、電話での予約対応に時間がかかっていることを課題に感じていました。しかし、本格的な予約管理システムを導入するには数百万円の予算が必要と見積もられ、即決できずにいました。
そこで、まずは既存の無料ツールを組み合わせた簡易な予約フォームだけをPoCとして小さく発注し、一部の常連客にだけ試験的に案内しました。結果、常連客の半数以上がオンライン予約を使ってくれたことが分かり、電話対応の時間も実際に減少しました。この結果をもとに、より使いやすく、店舗の会員情報とも連携できる本格的な予約システムの発注に進む判断ができました。もしPoCを挟まず、いきなり本格システムを発注していたら、「本当にオンライン予約を使ってくれるのか」という肝心な前提を検証できないまま、大きな投資をすることになっていたでしょう。
PoC発注をめぐる、後継社長ならではの心構え
「失敗してもいい」という前提を持つ
PoCの本質は「試してみて、うまくいかなければやめる」ことを前提とした発注です。先代の時代には「一度始めたことは最後までやり遂げる」という価値観が強かった会社も多いかもしれませんが、システム投資においては、この価値観がむしろリスクを大きくすることがあります。PoCで「これはうまくいかない」と分かったなら、そこで潔く撤退する判断力も、後継社長には求められます。撤退は失敗ではなく、大きな失敗を防いだ成功だと捉える発想の転換が必要です。
開発会社を「発注先」ではなく「相談相手」として扱う
PoC発注は、単に仕事を発注して納品を待つという一方通行の関係ではありません。むしろ、開発会社と一緒に「このアイデアは本当に会社の役に立つのか」を検証していく共同作業に近いものです。後継社長が分からないことを率直に質問し、開発会社がそれに丁寧に答えてくれる。この双方向のコミュニケーションが成立する相手であるかどうかも、PoCを通じて見極めるべき重要な観点です。
数字で会話する習慣をつける
PoCを発注する際も、結果を評価する際も、できるだけ数字で会話する習慣をつけましょう。「なんとなく良さそう」「現場の感触は悪くない」という感覚的な評価だけでなく、「作業時間が何分から何分に減ったか」「利用率は何割か」「エラー件数はどれだけ減ったか」といった具体的な数字を、開発会社に報告してもらうよう依頼してください。数字があることで、社内の合意形成もしやすくなり、次の投資判断もより確かなものになります。
PoC発注で使われる見積書・契約書の読み方
見積書に「一式」としか書かれていないときの対処法
PoC発注に限らず、システム発注の見積書で後継社長がつまずきやすいのが、「開発費一式 ○○万円」というような、内訳のない見積もりです。先代の時代の建築工事の見積もりであれば「一式」という書き方が業界の慣習として通っていたかもしれませんが、システム開発においては、この書き方のまま契約してしまうと、後から「これは含まれていると思っていた」「あれは別料金だった」というトラブルの火種になります。
PoC発注の見積書を受け取ったら、最低限、次の項目が分けて書かれているかを確認してください。まず、実際にプログラムを作る「開発費」。次に、開発の前提となる打ち合わせや資料作成にかかる「要件整理・打ち合わせ費」。そして、PoC終了後に結果をまとめて報告してもらうための「報告書作成費」。この3つが分かれて書かれているだけで、見積もりの透明性は大きく上がります。もし「一式」としか書かれていない見積書を渡されたら、「内訳を分けて教えてほしい」と遠慮なく伝えましょう。良い開発会社であれば、快く対応してくれるはずです。
契約書で「PoC」という位置づけを明記してもらう重要性
もう一つ、後継社長が見落としがちなのが、契約書そのものの書き方です。口頭では「これはPoCとして小さく試すものです」と説明を受けていても、契約書の本文には「システム開発業務委託契約書」とだけ書かれていて、PoCという位置づけがどこにも明記されていないケースがあります。
これは些細な違いに見えるかもしれませんが、実務上は重要な意味を持ちます。もし契約書にPoCという位置づけが明記されていなければ、後になって「これは本格システムの一部の納品だったはずだ」という解釈の違いが生じかねません。契約書や発注書の中に、「本契約は、○○という課題を検証するための概念実証（PoC）を目的とするものであり、本格的な業務システムの完成を目的とするものではない」といった一文を入れてもらうよう、開発会社に依頼することをお勧めします。この一文があるだけで、後々の期待値のズレを防ぐことができます。契約形態そのものの基本を押さえておきたい場合は、請負契約と準委任契約、何がどう違うのかも参考になる。
知的財産権の扱いにも目を向ける
PoCで作られたプログラムやデータの著作権、いわゆる知的財産権が誰のものになるのかも、契約前に確認しておきたいポイントです。一般的には、発注者である会社側に権利が譲渡される形が多いですが、開発会社によっては、汎用的な部分のコードは自社の資産として保持し、その会社独自の部分だけを発注者に譲渡するという契約形態を取ることもあります。
後継社長としては、この権利関係がどうなっているかによって、「PoCで得たノウハウを別の開発会社に本格発注する際に、そのまま引き継げるのか」が変わってくることを理解しておく必要があります。将来的に開発会社を変える可能性も視野に入れるなら、契約時にこの点を確認し、可能であれば発注者側に権利が帰属する形にしてもらうよう交渉してみましょう。
PoC発注を成功させるための社内体制づくり
後継社長一人で抱え込まない
PoC発注は金額が小さいため、後継社長が単独で判断して進めてしまうことも多いのですが、それでもできる限り、社内に「PoCの窓口担当者」を一人置くことをお勧めします。現場の従業員の中で比較的ITに関心がある人や、実際にそのシステムを使う予定のある部署のリーダーなどが適任です。
窓口担当者を置くことで、開発会社とのやり取りの記録が社内に残り、後継社長が全ての打ち合わせに出席できなくても、進捗を把握できるようになります。また、承継直後で右も左も分からない状態であっても、窓口担当者と一緒に学びながら進めることで、後継社長自身のITに関する理解も自然と深まっていきます。
現場の抵抗感にどう向き合うか
先代の時代から長く勤めている従業員の中には、新しいシステムの導入に抵抗を感じる人が一定数います。「今までのやり方で問題なかった」「新しいことを覚えるのが面倒だ」という声は、承継直後の会社ではよく聞かれるものです。
PoC発注は、実はこの抵抗感を和らげる効果も持っています。本格導入ではなく「お試し」という位置づけであれば、現場の従業員も「試すだけなら」と協力しやすくなります。そして、PoCを通じて実際に便利さを体感してもらえれば、本格導入時の抵抗感は大きく減ります。後継社長は、PoCを単なる技術検証としてだけでなく、社内の意識を変えていくための一つのステップとして活用する視点も持っておくとよいでしょう。
PoCの結果を記録に残す文化をつくる
承継直後の会社では、過去の意思決定の記録が紙の資料や口頭伝承でしか残っていないことが少なくありません。これでは、次にまた似たようなシステム投資を検討する際に、過去の教訓を活かせません。
PoCを実施したら、その目的、判断基準、実際の結果、そしてその後の判断(本格発注に進んだか、見送ったか)を、簡単でもよいので文書として残しておく習慣をつけましょう。この記録が積み重なっていくことで、会社としての「システム投資の勘」が徐々に育っていきます。これは、先代が長年の経験で培ってきた「経営の勘」と同じように、後継社長の世代が新たに築いていくべき資産だと言えます。
PoC発注が向いている場面と、向いていない場面
PoC発注が特に効果を発揮する場面
PoC発注が特に効果を発揮するのは、次のような場面です。まず、「新しい技術(AIやクラウドサービスなど)を使ったことがなく、そもそも自社の業務に使えるのか分からない」という場面です。技術への不安が大きいときこそ、小さく試して手触りを確かめることの価値が高まります。
次に、「社内の意見が分かれていて、いきなり大きな投資に踏み出す合意が取れない」という場面です。PoCという小さな一歩であれば、意見が分かれている状況でも「まず試してみよう」という合意を得やすくなります。
さらに、「取引先や顧客の反応が読めない」という場面もPoCが向いています。前述の受注フォームの例のように、社内の努力だけでは結果が決まらず、外部の反応次第で成否が変わる場合は、小さく試して外部の反応を先に確かめることが重要です。
PoC発注がそれほど必要ない場面
一方で、PoC発注が必ずしも必要ない場面もあります。たとえば、すでに他社で広く使われている実績のある業務パッケージソフトを導入するだけの場合や、法律で対応が義務付けられている改修(インボイス制度対応など)で、選択の余地がほとんどない場合です。このようなケースでは、技術的に動くかどうかを確かめる必要性が低いため、PoCという工程を挟むメリットが薄れます。
後継社長としては、「新しさ」「不確実性」「社内外の合意形成の難しさ」という3つの要素が大きい投資であるほど、PoCを挟む価値が高いと判断してよいでしょう。逆にこれらの要素が小さい、枯れた技術の単純な入れ替えであれば、PoCを省略して直接本格発注を検討することも合理的な選択です。
よくある質問（FAQ）
PoCの発注には、どのくらいの予算を用意すればいいですか
案件の内容や規模によって大きく異なりますが、対象を一つの課題に絞り込んだ小規模なPoCであれば、数十万円から百数十万円程度で実施できるケースが多くあります。本格的な受託開発の見積もりと比べて、まずは一桁小さい規模から始められるかどうかを、発注前に開発会社に確認してみてください。金額が本格発注とほとんど変わらない場合は、範囲が広すぎる可能性があるので、削れる部分がないか相談することをお勧めします。
PoCがうまくいかなかった場合、それまでにかけたお金は無駄になりますか
PoCで「うまくいかない」という結果が出た場合、それは決して無駄な投資ではありません。もしPoCを挟まずに本格発注していたら、同じ失敗にもっと大きな金額と時間をかけていたはずです。PoCの成果は「作られたシステム」だけでなく、「このアイデアは今の会社には合わない」という判断材料そのものにあります。この判断材料を安価に得られたことこそが、PoCの本当の価値です。
PoCを発注する際、開発会社をどうやって選べばいいですか
PoC発注においては、開発会社の規模の大きさよりも、小回りの良さとコミュニケーションの丁寧さを重視することをお勧めします。専門用語を分かりやすく説明してくれるか、こちらの疑問に率直に答えてくれるか、必要最小限の見積もりを提示してくれるか、といった点を確認しましょう。また、過去に他の中小企業向けにPoCを実施した実績があるかどうかも、参考になる情報です。複数の開発会社から話を聞いて比較することも有効です。
PoCの結果が良かった場合、必ず本格発注に進むべきですか
PoCの結果が良かったとしても、それがすぐに本格発注に進むべきという意味ではありません。前述したように、PoCの次にはMVPという段階を挟むことも検討に値します。また、社内の資金計画や他の投資との優先順位を踏まえて、本格発注のタイミングを見極めることも重要です。PoCはあくまで「アイデアの筋の良さ」を確認するものであり、その後の投資判断は、経営全体の視点から改めて行うべきものです。
承継後の資金計画の中でPoCをどう位置づけるか
事業承継時に発生する資金負担との両立
事業承継の直後は、株式の買い取りや相続税、先代への退職金の支払いなど、資金面での負担が重なることが多くの会社で見られます。このタイミングで「システム投資も同時にやらなければ」と考えると、資金繰りの見通しが一気に厳しくなってしまいます。
だからこそ、承継直後のシステム投資はPoCから始めるという発想が、資金計画の面でも合理的です。数十万円から百数十万円程度のPoCであれば、事業承継に伴う他の資金負担と並行しても、無理なく進められる範囲に収まることが多いはずです。本格的な投資は、PoCの結果を見てから、資金繰りの状況を踏まえて改めて計画すればよいのです。最初から大きな投資枠を確保しておく必要はありません。
補助金・助成金の活用余地について
中小企業のIT投資に関しては、国や自治体が用意している補助金・助成金の制度が使える場合があります。ただし、補助金の制度は年度や自治体によって内容が大きく変わり、対象となる経費の範囲や申請時期も細かく決められています。PoCのような小規模な検証段階の費用が対象になるかどうかは、その時点の制度の詳細を必ず個別に確認する必要があります。後継社長が独自に判断するのではなく、商工会議所や顧問の税理士、中小企業診断士などの専門家に相談し、自社が使える制度がないかを確認してみることをお勧めします。制度の詳細をこの記事で一般論として断定することは避けますが、「調べる価値のある選択肢」として知っておいて損はありません。
複数のPoCを並行させるべきか、順番に進めるべきか
承継直後は、システムに関する課題が一つだけでなく、いくつも同時に見えてくることがあります。「受注管理も、在庫管理も、勤怠管理も、全部古いままだ」と気づいたとき、どれから手をつけるべきか迷う後継社長は少なくありません。
基本的には、PoCは一つずつ、順番に進めることをお勧めします。複数のPoCを同時に走らせると、社内の窓口担当者の負担が分散してしまい、どのPoCも中途半端な検証になりがちです。まずは最も業務への影響が大きい課題、あるいは最も現場からの不満が強い課題を一つ選び、そこから着手する。一つのPoCが完了し、次の一歩(見送りか、MVPへの進行か)が決まった段階で、次の課題のPoCに着手する。この順番を守ることで、限られた経営資源(お金・時間・人手)を有効に使うことができます。
他社の失敗例から学ぶ、PoCを挟まなかった場合の教訓
業種を問わず、中小企業のシステム発注の現場では、PoCを挟まずに大きな発注をしてしまい、結果的に投資が生かされなかったという事例が繰り返し語られています。たとえば、経営者の思いつきで導入を決めた高機能なシステムが、実際には現場の誰にも使われず、いつの間にか「入れただけのシステム」として放置されてしまうというパターンです。
このようなケースに共通しているのは、「現場の実際の使われ方を検証する工程を挟まなかった」という点です。経営者が良いと思ったアイデアが、必ずしも現場にとって使いやすいものであるとは限りません。PoCという工程は、この「経営者の思い込み」と「現場の実態」のギャップを、大きな投資をする前に発見するための、いわば安全装置のような役割を果たしています。
後継社長は、先代の時代からこうした「入れただけのシステム」が社内にいくつも眠っていないか、一度点検してみるとよいでしょう。もし過去にそうした失敗があったなら、その原因を分析することで、次のシステム投資でPoCをどう活用すべきかのヒントが得られるはずです。過去の失敗は、正しく振り返れば、次の成功のための貴重な材料になります。
まとめ ― 小さく試すことは、経営の慎重さであり、勇気でもある
先代から会社を引き継いだ後継社長にとって、システム発注は避けられない経営判断の一つです。しかし、専門用語も相場観も分からないまま、いきなり大きな金額を投じるのは、あまりにリスクが高い選択です。この記事で紹介したPoC発注という考え方は、「小さく試して、確かめてから、大きく踏み出す」という、極めて合理的な経営判断の手法です。
PoCで課題を一つに絞り、判断基準を数字で決め、必要最小限の範囲で発注し、結果を社内で共有する。この一連の流れを実践することで、後継社長は自信を持ってシステム投資の判断を下せるようになります。そして、PoCで筋の良さが確認できたアイデアは、次にMVPという段階を経て、実際に現場で使われる本物の製品へと育っていきます。
小さく発注することは、決して消極的な選択ではありません。むしろ、限られた経営資源を守りながら、新しい挑戦を続けていくための、積極的で賢明な戦略です。先代から引き継いだ会社を次の世代へつなぐためにも、まずは小さく発注して試す、という一歩から始めてみてください。
