PoC検証の進め方｜実際の導入前検証から作った検証項目サンプルと合否基準（テンプレート付）

PoC（Proof of Concept：概念実証）とは、本格的な導入や開発を決める前に、構想や製品が実際に機能するかを小さく試して確かめる取り組みです。業務システムの場合は、「自社の実際の業務データと帳票を使って、この業務をシステムで問題なく運用できるか」を確かめる検証と考えると分かりやすくなります。

 

これまでの検証から見えた結論は、次の3点です。

 

1. 仮説は「合否を判定できる1文」で書きます。 「今のExcel運用を置き換えられるか？」という問いのままでは、検証が終わっても判定ができません。
2. 検証項目は4つの層で洗い出します。 「業務をシステムで再現できるか」「現場が使い続けられるか」「既存システム・セキュリティと両立するか」「費用と運用体制が成り立つか」の4層です。検証の中で挙がった懸念は、すべてこのどれかに当てはまりました。
3. 判定する人と判定の場を、検証の前に決めます。 誰が、何を見て、Go／条件付きGo／No-Goを決めるのかが決まっていないPoCは、結論が出ないまま自然に止まります。

 

PoC検証の進め方（6ステップ）

 

1. PoCのテーマを「問い」の1文で書く
2. 対象を1業務まで絞り、現物（Excel・帳票）を集める
3. 「マスト」と「できれば」を分けて検証項目を洗い出す
4. 合否基準と判定者を決める
5. デモストーリーを組み、検証しない部分は「仮置き」と明記する
6. 残課題を記録し、判定会議でGo／条件付きGo／No-Goを決める

 

この記事を読み終えたとき、以下ができるようになっているはずです。

 

1. PoC検証のテーマを「問い」の1文で書ける
2. 検証する範囲を「今回確認する／将来の候補／既存のまま継続」の3つに切り分けられる
3. 自社の検証項目を、マスト要件と「できれば」要件に分けて一覧にできる
4. 合否基準と判定者を決め、判定会議まで進められる

 

この記事で扱う範囲と、扱わない範囲

本記事は、業務システム（ノーコードツールやクラウドサービスを含む）の導入を決める前に行うPoC検証の「始める前から、合否を判定するまで」を扱います。

 

扱う範囲：
PoC検証の目的と関連用語の違い、メリットとデメリット、失敗する理由、テーマの立て方、対象範囲の切り方、検証項目と合否基準の作り方、デモストーリーの組み方、未達・残課題の扱い、判定会議の進め方、計画書・報告書、期間と費用の考え方

 

扱わない範囲（それぞれ既存の記事で詳しく解説しています）：

• どの業務から手を付けるかの選び方全般
• バックオフィスDX「スモールスタート×アジャイル」導入ガイド
• 判定後に作る要件定義書の書き方、未決事項の管理
• 要件定義書の必要項目と書き方
• システムの選定基準とROI（費用対効果）の算出
• 失敗しない業務効率化システムの選定基準とROIを高める導入術
• PoCで成功した後の全社への横展開
• 部門単位のDXが失敗する理由と成功に変える横展開の進め方
• Excel運用そのものの限界
• エクセルマクロはもう限界？属人化・ブラックボックス化から脱却

進め方に入る前に、PoC検証の基本を整理しておきます。ここを曖昧にしたまま始めると、「何を確かめる検証なのか」が関係者の間でずれ、後の判定で揉める原因になります。

PoC検証の目的は「本格的な投資の前に、判断材料を得ること」です

PoC検証の目的は、本格的な開発や導入に費用と時間をかける前に、「このまま進めてよいか」を判断するための材料を、小さな費用で手に入れることです。導入してから「自社の業務には合わなかった」と分かるのと、PoCの段階で分かるのとでは、戻るためにかかる費用がまったく違います。

 

つまり、PoC検証の成果物は「動く仕組み」そのものではなく、「進む／条件付きで進む／見送る」を決めるための根拠です。この記事で、仮説や合否基準を重視しているのはそのためです。

一般的な検証の観点と、業務システムでの置き換え方

PoCで確かめることは、一般に「技術的な実現性」「効果と費用対効果」「具体性（実際の運用で使えるか）」の3つの観点で整理されます。業務システムの導入前に行うPoCでは、この3つをさらに具体的な問いに置き換えると、検証項目が作りやすくなります。

 

一般的な検証の観点	業務システムのPoCでの問い	本記事の4層モデル
技術的な実現性	今の業務・帳票を、システムで再現できるか。既存システムとつながるか	第1層・第3層
具体性（運用できるか）	現場の担当者が、説明なしで使い続けられるか	第2層
効果と費用対効果	全社に広げたときの費用と運用体制が成り立つか	第4層

 

4層それぞれの具体的な検証項目は、後半の「PoC検証項目サンプル」の章で紹介します。

PoV・PoB・プロトタイプ・MVP・実証実験・無償トライアルとの違い

PoCと一緒に使われる言葉は多く、社内で意味がずれたまま話が進むことがあります。違いは、「何を確かめるためのものか」で整理すると分かりやすくなります。

 

用語	確かめること	業務システム導入での位置づけ
PoC（Proof of Concept：概念実証）	構想や製品が、実際に機能するか	自社の業務をシステムで運用できるかを、導入前に確かめる
PoV（Proof of Value：価値実証）	期待する効果や価値が得られるか	作業時間がどれだけ減るかなどを、本格運用の前後で測る
PoB（Proof of Business：事業実証）	事業として採算が取れるか	主に新規事業で使われる言葉。業務システムでは投資対効果の試算に近い
プロトタイプ	検証するための試作品	PoCで使う画面や帳票の試作
MVP（Minimum Viable Product）	最小限の機能で、実際の利用者の反応を見る	小さく本番運用を始める「スモールスタート」に近い
実証実験	実際の環境で、実用に耐えるか	限定した部署での試行運用
無償トライアル	製品を一定期間、自由に試す	何を試すかは利用者に任される。検証項目を決めて進めるPoCとは違う

 

業務システムの場合、一般的には「PoCで業務をシステムで再現できるかを確かめる → 限定した範囲で試行運用する → 効果を測る（PoV）→ 全社に広げる」という順番で進みます。

業務システムのPoCは、新規事業やAI開発のPoCと何が違うのか

PoCについて書かれた情報の多くは、新規事業やAI開発を想定しています。一方、業務システムの導入前に行うPoCには、次のような違いがあります。

 

• 確かめるのは「新しい技術が動くか」より「今の業務をシステムで再現できるか」です。 製品そのものはすでに動いているため、論点は自社の帳票や例外処理、既存システムとのつながりになります。
•  
• 材料は、今使っているExcelや帳票です。 新しいデータを集めるのではなく、すでにある現物を使って検証できます。
•  
• 「現場が使い続けられるか」の比重が大きくなります。 機能がそろっていても、今の操作の感覚から離れると定着しません。
•  
• 製品の提供元がPoCを支援することが多くあります。 その分、自社側で評価の物差しを持っておかないと、デモの印象で判断してしまいがちです。

PoC検証には大きなメリットがある一方で、進め方を誤るとかえって時間と費用がかさむこともあります。業務システムの導入前に行う場合を前提に整理します。

メリット

1. 導入後の「こんなはずではなかった」を防げます。 帳票が再現できない、既存システムとつながらないといった問題を、契約前に見つけられます。
2. 稟議や社内説明の根拠になります。 「自社のデータで動かして、ここまで確認できた」という事実は、カタログやデモよりも強い説得材料になります。
3. 現場を早い段階から巻き込めます。 日常業務の担当者に実際に触ってもらうことで、導入後の抵抗が小さくなります。
4. 要件定義が速くなります。 PoCで確かめた項目や残課題の記録が、そのまま要件定義のたたき台になります。

デメリットと注意点

1. 社内の工数がかかります。 提供元が無償で支援する場合でも、現物の準備や打合せ、操作の確認には社内の時間が必要です。
2. 終わりを決めないと、だらだら続きます。 検証のたびに要望が増え、いつまでも判定できない「PoC疲れ」の状態になります。
3. 実際のデータを扱うため、情報管理が必要です。 取引先名や金額などを含むデータを使う場合は、使う範囲や管理方法を事前に取り決めておきます。
4. PoCで成功しても、本番で成功するとは限りません。 対象を絞っている分、全社に広げたときの課題は別に確認が必要です。

 

これらのデメリットの多くは、次の章で紹介する「検証が止まる3つの地点」を先につぶしておくことで防げます。

まず、本記事のベースとなった情報について説明します。当社では2026年から、業務システムの本格導入を決める前に、お客様の実際の業務データや帳票を使ってPoC検証を行っています。本記事は、その検証の記録をもとにしています。

 

検証にご協力いただいている企業の業種は、製造、卸売・小売、商社、建設、教育、ソフトウェアなど幅広く、従業員規模もさまざまです。対象の業務も、見積や請求などの販売管理、申請・承認のワークフロー、在庫の管理、案件の進捗管理など多岐にわたります。

 

なお、検証にご協力いただいている企業が特定されないよう、本記事では企業ごとの業種・規模・業務の組み合わせは掲載していません。紹介する内容は、複数の検証で共通して見られた傾向を中心にまとめ、具体例は内容を一般化しています。

 

あらかじめお断りしておくと、これは「導入してどれだけ効率化したか」という成果の報告ではありません。検証を始める前と、検証の途中で、何が決まっていて何が決まっていなかったかの記録です。そのぶん、一般的な導入事例には出てこない「止まった地点」まで把握できています。

 

当社では、PoCを始める前に、共通のヒアリングシートへ検証の仮説や評価指標を記入していただいています。その記入内容を振り返ると、PoC検証が止まりやすい地点が3つ浮かび上がりました。

 

PoCがうまくいかない状態は、一般に「PoC疲れ」（検証を繰り返すだけで結論が出ず、関係者が疲弊する）、「PoC止まり」（検証で終わり、本格導入に進まない）、「PoC貧乏」（検証に費用だけがかさむ）と呼ばれます。当社の検証の記録を振り返ると、これらは検証の途中ではなく、検証を始める前の段階で種がまかれていました。

 

評価指標を事前に決めている企業は、ほとんどありませんでした

ヒアリングシートには「評価指標（KPI）とその測定方法」を書く欄を設けていました。KPIとは、目標の達成度を測るための指標のことです。ところが、この欄を検証の前に埋められていたケースは、ほとんどありませんでした。

 

つまり、「何をもって導入可と判断するか」を数字や条件で決めてから検証に入ることは、実際にはまれだということです。

 

これは珍しいことではありません。業務システムのPoCでは、検証を持ちかけるのが製品の提供元であることが多く、お客様側は「まず見てみよう」という姿勢で参加されます。その結果、評価の物差しを持たないまま、デモの印象で判断することになりがちです。

仮説が「置き換えられるか？」のまま止まっています

評価指標の欄とは別に、「検証で確かめたい仮説」を書く欄も設けていました。こちらは記入されていることが多かったものの、合否を判定できる形で書かれていたものは、ごく一部でした。

 

多かったのは、たとえば次のような書き方です（表現は編集部で一般化しています）。

 

1. 今のExcel運用を、新しいシステムに置き換えられるか
2. 現場の担当者が無理なく使えるか
3. 自社の課題にどこまで対応できるか

 

どれも検証したいことそのものは正しいのですが、「どうなっていたら合格か」が書かれていません。そのため、検証が終わっても「置き換えられそうな気はする」という感想しか残らず、社内で導入を決める材料になりません。書き方の直し方は、後半の「仮説の書き方」の章で紹介します。

比べる相手を決めないまま検証に入っています

「他に比較した選択肢」の欄も、「比較対象なし」や未記入のまま検証に入るケースが多く見られました。

 

比較する相手がないと、PoCの結果が良くても悪くても、それが製品の良し悪しなのか、自社の業務の難しさなのかを切り分けられません。比較対象は製品でなくても構いません。「今のExcel運用を続けた場合」や「既存システムを改修した場合」を比較対象として置くだけで、判定の基準がはっきりします。

ここからは、これまでのPoC検証で実際に行ってきた進め方を、6つのステップに整理して解説します。

説明を分かりやすくするため、この章では「見積から請求までをExcelとメールで管理している企業」を例にします。この例は、複数の検証で共通して見られた状況をもとに編集部が構成したもので、特定の企業の事例ではありません。

ステップ1：PoCのテーマを「問い」の1文で書く

最初に行うのは、PoCで何を確かめるのかを1文で書くことです。ポイントは、「〜を導入する」ではなく「〜できるか」という問いの形で書くことです。

例であれば、次のような1文になります。

Excelとメールに分散している見積の管理を、1つのシステムで一元管理できるか

 

検証の中でも、判定までスムーズに進んだのは、このように「今使っている仕組みのうち、何を残し、何をまとめるのか」をテーマの段階ではっきりさせていたケースでした。

問いの形にしておくと、検証の最後に「はい／いいえ／条件付きではい」で答えられます。反対に、「業務の効率化を目指す」といった目的の形で書くと、何をもって達成とするかが曖昧になり、ステップ4の合否基準が作れなくなります。

ステップ2：対象を1業務まで絞り、現物を集める

次に、検証の対象を絞ります。業務システムのPoCで最もよくある失敗は、最初から業務全体を対象にしてしまうことです。対象が広いほど準備に時間がかかり、判定も難しくなります。

 

例では、見積・受注・請求のうち、現在最も手間がかかっている「見積」だけを対象にします。検証の中でも、複数の業務や品目の中から1つだけを先に選んだ企業ほど、判定までの流れがスムーズでした。

 

対象を決めたら、その業務で実際に使っているExcelや帳票を全種類集めます。ここで一部の帳票しか集めないと、検証の途中で別の帳票が出てきて、前提が崩れます。

 

もう1つ大切なのが、現行のExcelの中身を読み解くことです。長く使われてきたExcelには、関数やマクロが組み込まれ、シート同士が複雑に参照し合っていることが少なくありません。「どのシートがどのデータを参照しているか」「なぜこの構造になっているのか」を確認事項として整理してから打合せに臨むと、検証がずっと速く進みます。

 

なお、どの業務を最初の対象に選ぶかという判断の考え方は、スモールスタートの導入ガイドで詳しく扱っています。

ステップ3：「マスト」と「できれば」を分けて検証項目を洗い出す

対象が決まったら、検証項目を洗い出します。このとき必ず行っていただきたいのが、マスト要件（満たせなければ導入しない）と、できれば要件（満たせればよい）を分けることです。

 

例であれば、次のように整理できます。

 

要望	区分	理由
見積書を作成・管理できること	前提	対象業務そのもの
現行の見積書と同じ項目を出力できること	マスト	取引先に提出する書類のため、項目が欠けると業務が止まる
担当範囲ごとに閲覧・編集の権限を分けられること	マスト	他部署の金額や条件が見えては困る
外出先から承認できること	できれば	あれば承認待ちの時間が短くなる
操作の履歴を確認できること	できれば	誰がいつ変更したかを追えるとよい

 

検証の中でも、セキュリティに関わる要件が1つあるだけで、それが導入可否を左右するマスト要件になるケースがありました。こうした要件は、「満たせなければ、ほかがどれだけ良くても導入しない」と先に決めておくことが大切です。

このように区分を付けておくと、検証の途中で要望が増えても、判定の軸がぶれません。検証項目の洗い出しに使える4層のチェックリストは、後半の「PoC検証項目サンプル」の章で紹介します。

ステップ4：合否基準と判定者を決める

検証項目ごとに、「どうなっていたら合格か」と「誰がそれを判定するか」を決めます。

 

検証の中で、判定がスムーズに進んだのは、打合せの場で評価ポイントを言葉にしてもらい、判定する人を決めていたケースです。たとえば次のような形です。

 

1. 現行のExcelと同じ入力・集計ができるか
   （日常業務の担当者が確認）
2. 複数の拠点や部署から問題なく使えるか
   （各拠点の担当者が確認）
3. 今の業務の進め方や操作の感覚を、大きく変えずに済むか
   （現場の担当者が確認）

 

そのうえで、「現行の業務を最もよく知る人が画面を確認してから、次の段階に進むかを判断する」といった判定の手順も決めておきます。

 

前の章で見たとおり、ヒアリングシートの段階では評価指標を書けていた企業はありませんでした。しかし、評価ポイントを打合せの場で言葉にしてもらい、判定する人を指名しておくだけで、PoCは「試しただけ」で終わりにくくなります。

ステップ5：デモストーリーを組み、検証しない部分は「仮置き」と明記する

検証項目が決まったら、実際の画面で何をどの順番で見せるかという「デモストーリー」を組みます。例であれば、次のような流れになります。

 

STEP	内容	扱い
1	取引先から見積の依頼を受け付ける	システムの外（既存の受付方法のまま）
2	顧客・案件の情報を登録する	検証する
3	見積を作成する	検証する
4	見積を承認する	検証する
5	見積書を出力する	帳票ツールとの連携は「連携した想定」で進める
6	受注を登録する	検証する

 

注目していただきたいのはSTEP5です。PoCの段階では、外部のツールとの連携までは組んでいないことがよくあります。その場合は、「今回は連携した想定で進めます」とあらかじめ明記したうえでストーリーを流します。

PoCでは、すべてを本番と同じ状態で動かす必要はありません。大切なのは、どこが実際に動いていて、どこが仮置きなのかを、見る人全員が分かっている状態にすることです。仮置きの部分を黙って見せてしまうと、「全部できる」という誤解が生まれ、導入後に「聞いていた話と違う」という事態につながります。

ステップ6：残課題を記録し、判定会議で次の段階を決める

検証を終えたら、分かったことと、分からなかったこと（残課題）を記録します。残課題は「失敗」ではなく、次の段階で検討すべき論点の一覧です。検証でよく見られた残課題は、後半の「PoCで見つかった想定外」の章で紹介します。

記録がそろったら、判定会議を開いて、Go（進める）／条件付きGo（条件を満たせば進める）／No-Go（見送る）を決めます。判定会議の進め方は、記事の後半で説明します。

判定がGoになった後は、検証で確かめた内容を要件定義書にまとめる段階に入ります。要件定義書の書き方や、決まらない項目の管理方法は、要件定義書の必要項目と書き方で詳しく解説しています。

ステップ2で対象を絞ると説明しましたが、ここでもう一歩踏み込みます。PoCの範囲は、「対象にする」「対象にしない」の2つではなく、3つに区分すると、関係者の認識が揃いやすくなります。

 

 

区分	意味	例（見積から請求までをExcelとメールで管理している場合）
今回確認する範囲	PoCで実際に画面を作り、検証する	見積の登録・一覧、見積の承認、見積書のPDF出力
将来の適用候補	今回は検証しないが、次の段階で対象にする	受注・請求の管理、入金の消込、他システムとのデータ連携
既存のまま継続	システムを置き換えず、今後も使い続ける	会計システム、取引先からの依頼の受付方法（メール・Webフォームなど）

 

3つめの「既存のまま継続」を書いておくことが、とても大切です。この区分がないと、「新しいシステムを入れたら、今使っている仕組みはやめるのか」という不安が現場に広がります。「この仕組みは今後も使い続けます。その後の管理だけを検証します」と明示すれば、現場の抵抗はかなり小さくなります。

 

また、「将来の適用候補」を書いておくと、PoCの範囲を絞ったことが「この範囲しかできない製品を選んだ」と誤解されるのを防げます。最終的な目標（例では、見積から受注、請求、入金までを一気通貫で管理すること）を示したうえで、「今回はその入口だけを確かめる」と位置づけるのがポイントです。

ここからは、検証項目のサンプルを紹介します。PoCを始める前に挙がった懸念や「うまくいかないのでは」という声を集めて整理すると、すべてが次の4つの層に分類できました。

 

 

層	確かめること	よく挙がる懸念の例
第1層	業務をシステムで再現できるか	今使っている帳票と同じものが作れるか／案件ごとに内容が変わる業務に対応できるか
第2層	現場が使い続けられるか	現場の担当者が使い続けてくれるか／今の操作の感覚を変えずに済むか
第3層	既存システム・セキュリティと両立するか	基幹システムとデータをやり取りできるか／許可していない環境からのアクセスを防げるか
第4層	費用と運用体制が成り立つか	利用者が増えたときに費用が合うか／自社で構築・変更していけるか

 

以下、層ごとに検証項目のサンプルを示します。合否基準はそのまま使うのではなく、自社の業務量に合わせて調整してください。

第1層：業務をシステムで再現できるか

検証項目	合否基準の例	確かめ方
現行の帳票を再現できるか	帳票の全種類について、必須の記載項目がすべて出力される	現行帳票と出力結果を1項目ずつ突き合わせる
明細の行数・ページ数に対応できるか	過去の実績で最も多い明細行数・ページ数の帳票が出力できる	実績の最大値の案件で出力してみる
転記がなくなるか	案件情報を1回入力すれば、見積・帳票に自動で引き継がれる	同じ情報を2回以上入力する箇所を数える
パターンの多い業務に対応できるか	代表的なパターンすべてで、入力から出力まで完了できる	パターンの一覧を作り、1つずつ実行する
現行の関数・マクロの処理を置き換えられるか	現行で自動化されている処理が、手作業に戻らない	現行の関数・マクロを一覧化し、対応を確認する
取引先指定の帳票に対応できるか	取引先が指定する書式どおりに出力できる	取引先指定の様式を全種類そろえて出力する

第2層：現場が使い続けられるか

検証項目	合否基準の例	確かめ方
現場の担当者が説明なしで入力できるか	日常業務の担当者が、簡単な説明だけで1件の入力を完了できる	実際の担当者に操作してもらい、つまずいた箇所を記録する
今の入力の感覚を維持できるか	見出しの固定、並べ替え、一覧での入力など、現行で使っている操作が再現できる	現行で使っている操作を一覧化して確認する
使う端末で操作できるか	タブレットやスマートフォンなど、現場で使う端末で入力が完了できる	現場で実際に使う端末で操作する
入力のミスを防げるか	選択肢の固定や必須入力で、表記の揺れや入力漏れが起きない	誤った値を入力してみて、止まるかを確認する
運用ルールに頼る箇所が残らないか	「毎回検索する」「目で確認する」など、人の注意に頼る対処がマスト項目に残っていない	運用でカバーする箇所を一覧化する

 

操作感の小さな違いが定着を大きく左右するという声は、検証の中で繰り返し聞かれました。機能の有無とは別に、検証項目として必ず立ててください。

第3層：既存システム・セキュリティと両立するか

検証項目	合否基準の例	確かめ方
基幹システムのデータを取り込めるか	基幹システムから出力したCSVを、加工なしまたは定型の加工で取り込める	実際の出力ファイルで取り込む
基幹システムへデータを戻せるか	連携方式（CSV／APIなど）と、連携する項目が特定できている	連携先の仕様書をもとに確認する
アクセス元を制限できるか	許可した拠点・ネットワーク以外から接続できない	許可していない環境から接続を試す
権限を分けられるか	担当範囲に応じて、参照・入力・承認の権限を設定できる	役割ごとのアカウントで操作する
操作の記録が残るか	誰がいつ何を変更したかを後から確認できる	変更を加えて、履歴を確認する
確定したデータを保護できるか	締めが終わったデータを、後から変更できないようにできる	締め後のデータを変更してみる

 

APIとは、システム同士が直接データをやり取りするための接続口のことです。基幹システムとの連携仕様は、PoCの期間中に手に入らないことがよくあります。その場合は、「仕様が判明したら見直す項目」を記録したうえで先に進んでください。具体的な記録の書き方は、要件定義書の記事の「未決事項一覧」で紹介しています。

第4層：費用と運用体制が成り立つか

検証項目	合否基準の例	確かめ方
利用人数が増えたときの費用	全拠点・全社員に広げた場合の月額費用が、予算の範囲に収まる	利用人数と利用量で試算する
社外の取引先を含めた場合の費用	取引先にも使ってもらう場合の費用が、予算の範囲に収まる	社外ユーザーの課金条件を確認する
自社で項目や画面を変更できるか	項目の追加・変更を、ベンダーに依頼せず社内で行える	実際に項目を1つ追加してみる
構築・運用を担う人がいるか	導入後の変更を担当する人と、その作業時間が確保できる	担当者と作業時間を決めておく
製品側の未提供機能の扱い	検証に必要な機能の提供時期と、提供されない場合の代替手段が確認できている	提供元に書面で確認する

 

費用は、PoCの相談のきっかけになることが少なくありません。利用する人数が増えると費用が合わなくなる、社外の取引先まで含めると費用がかさむ、といった声です。費用の検証は、利用者1人ごとに課金される仕組みか、使った量に応じて課金される仕組みかによって結果が大きく変わります。まずは課金の仕組みを確認したうえで、自社の人数と利用頻度で試算してください。試算には料金シミュレーターもご利用いただけます。

 

 

---

PoC検証項目テンプレート（Excel）をダウンロード

 

本記事で紹介した4層の検証項目サンプルを、そのまま使えるExcelテンプレートにまとめました。PoCテーマの記入シート、範囲の3区分シート、マスト／できれば・判定者の列を付けた検証項目チェックリスト、仮説の書き方シート、判定会議の記録シート、開始前チェックリストの全7シート（使い方シートを含む）で構成しています。判定者と結果を記入すると、マスト要件の達成状況から判定の目安が自動で表示されます。

 

---

 

検証項目が揃ったら、PoC全体の仮説を書きます。前半で見たとおり、仮説を合否判定できる形で書けているケースはごく一部でした。ここでは、よくある書き方をもとに、判定できる文への直し方を紹介します。

直し方のコツは1つだけです。「〜できるか？」の後ろに、「どうなっていたら『できた』とするか」を書き足します。

 

直す前（よくある書き方）	直した後（判定できる形）
今のExcel運用を、新しいシステムに置き換えられるか	現行のExcelで扱っている帳票がすべて出力でき、日常業務の担当者が説明書なしで1件を登録できれば、置き換え可能と判断する
現場の担当者が無理なく使えるか	対象部署の担当者全員が検証期間中に1回以上入力し、従来の方法に戻した件数がゼロであれば、定着の見込みありと判断する
自社の課題にどこまで対応できるか	挙げた課題のうち、マスト要件に指定した課題がすべて実現でき、残りの課題の実現方法が特定できれば、対応可能と判断する
紙の申請を電子化して定着するか	対象の申請が検証期間中にすべて電子で出され、承認の停滞箇所を画面上で確認できれば、定着の見込みありと判断する

※表の内容は、編集部が書き方の例として作成したものです。

 

判定しやすい仮説は、「できた／できなかった」をその場で答えられる粒度まで具体的です。たとえば申請業務の場合、次のような書き方になります。

 

1. 申請画面で、申請者の氏名と所属が自動で入力されること
2. よく使う項目を、選択肢から選べること
3. 承認されたら、担当部署に自動で通知されること

 

この粒度まで具体的にしておくと、検証が終わった時点で結論をはっきり答えられ、PoCの結果がそのまま社内の稟議資料になります。

一般的な導入事例では、うまくいったことだけが紹介されます。しかし、これからPoCを始める方にとって本当に役立つのは、検証の途中で何につまずいたかという記録です。ここでは、検証の中で繰り返し見られた4つの「想定外」を、傾向としてまとめます。

帳票の書式は、自社で決められないことがあります

見積書や納品書など、取引先に提出する帳票の中には、書式を取引先から指定されていて、自社の都合で変えられないものがあります。また、案件ごとに明細の数やページ数が大きく変わる帳票もあり、固定の様式を用意するだけでは対応できないことがあります。

帳票の書式が取引先の指定かどうかは、PoCを始める前に必ず確認してください。自社で変更できない帳票は、第1層「業務をシステムで再現できるか」の中でも最も難易度の高い項目になります。この種の帳票は、早い段階で実物のパターンをすべて集め、出力方法を検討しておくと安心です。

「運用でカバーします」は、続かないことが多いです

検証の途中で、システムでは防げない問題が見つかると、「そこは担当者が毎回確認する運用にしましょう」という案が出ることがあります。しかし、現場からは「忙しい時期には、きっとやらなくなる」という率直な声が返ってくることが少なくありません。

これはとても大切な指摘です。システムで防げないことを「運用でカバーする」と決めても、忙しい時期には抜けてしまいがちです。PoCで運用ルールによる対処が出てきたら、それは解決ではなく残課題として記録してください。

データの型と桁を決める作業が、想定以上に重くなります

Excelでは、どのセルに何を入力しても基本的には受け付けられます。一方、業務システムでは、各項目が文字列なのか、数値なのか、日付なのかを決め、さらに文字列なら何桁まで、数値なら上限はいくらまでかを定義する必要があります。検証の中でも、この作業に想定以上の時間がかかったという声がありました。

 

PoCの計画を立てる際は、このデータ定義の作業時間をあらかじめ見込んでおいてください。過去の実データから、各項目の最大の桁数や値を拾っておくと、作業がかなり早くなります。

製品側の機能待ちで、検証の一部が止まることがあります

PoCで見つかるのは、自社側の課題だけではありません。検証を進める中で、必要な機能が製品側にまだ提供されていないことが分かり、その部分の検証を後回しにしたケースもありました。また、機能はあっても、表示や出力の細かい部分が要望に届かず、調整に時間がかかることもあります。

製品の提供元がPoCを行う場合でも、こうした制約は隠さずに記録し、「いつ解消する見込みか」「解消しない場合の代替手段は何か」をセットで確認してください。それが、導入後の「聞いていた話と違う」を防ぐ一番の方法です。

PoCの最後に行うのが判定会議です。検証の結果を持ち寄り、次に進むかどうかを決めます。

 

 

判定会議の結論は、次の3つのどれかにします。

 

結論	判断の目安	次に行うこと
Go（進める）	マスト要件をすべて満たし、できれば要件の大半も満たした	要件定義に進む
条件付きGo	マスト要件は満たしたが、残課題に解消の見込みが必要なものがある	条件と期限を決め、満たせたら進む
No-Go（見送る）	マスト要件のうち1つでも満たせなかった	見送りの理由を記録し、代わりの手段を検討する

 

判定会議を開く際は、次の3点を事前に決めておいてください。

 

1. 判定会議の日付を、PoCの開始時に決めておきます。 期限がないPoCは、忙しさに押されて自然に止まります。
2. 判定する人を1名に決めておきます。 現行の業務を最もよく知る人を判定者にすると、現場とのずれが小さくなります。
3. 撤退の基準も先に決めておきます。 「マスト要件が1つでも満たせなければ見送る」という基準を先に決めておけば、検証に時間をかけたことを理由に、ずるずると導入を決めてしまうことを防げます。

 

条件付きGoは、使い方に注意が必要です。条件と期限を決めずに条件付きGoとすると、実質的には判断の先送りになります。「いつまでに、何が満たされたら進むのか」を必ず記録してください。

 

---

自社の業務で、PoC検証を無償で試してみませんか

Slopebaseでは現在、お客様の実際の業務データを使ったPoC検証を無償で受け付けています。本記事で紹介したように、テーマの定義から範囲の切り分け、検証項目の整理まで、一緒に進めます。お持ちいただきたいのは、現在お使いのExcelと帳票のサンプルだけです。

 

（フォームに「PoC希望」と記入してください）

---

 

PoC検証では、始める前に「計画書」を、終わった後に「報告書」を作っておくと、社内の合意が取りやすくなります。どちらも分厚い文書にする必要はありません。次の項目が埋まっていれば、A4で数枚程度に収まります。

PoC計画書に書く項目

項目	書く内容	本記事での対応箇所
テーマ	「〜できるか」の問いの1文	ステップ1
背景と目的	なぜ今検証するのか、何を判断するための検証か	―
対象と範囲	今回確認する／将来の候補／既存のまま継続	ステップ2・範囲の3区分
仮説	合否を判定できる形で書いた仮説	仮説の書き方
検証項目と合否基準	マスト／できればの区分、合否基準、確かめ方	ステップ3・4、検証項目サンプル
比較対象	今の運用を続けた場合、他の手段など	止まる3つの地点
体制	判定者（1名）、参加者、提供元の窓口	ステップ4
日程	開始日、打合せの回数、判定会議の日付	判定会議の持ち方
撤退の基準	どうなったら見送るか	判定会議の持ち方
使うデータと管理方法	検証に使うExcelや帳票、その取り扱い	ステップ2

PoC報告書に書く項目

項目	書く内容
結論	Go／条件付きGo／No-Goと、その理由を1〜2文で
仮説に対する答え	計画書の仮説に「はい／いいえ／条件付きではい」で答える
検証項目ごとの結果	合否基準に対する結果（○／△／×）と、確かめた方法
残課題	分からなかったこと、運用でカバーするとした箇所、製品側の制約
条件付きGoの条件	いつまでに、何が満たされたら進むか
次の段階	要件定義、試行運用、効果測定（PoV）など、次に行うこと

 

報告書で大切なのは、うまくいかなかったことも残すことです。No-Goになった場合も、その記録は次に別の手段を検討するときの検証項目になります。

記事内で配布している検証項目テンプレート（Excel）は、「テーマと体制」「範囲の3区分」「検証項目チェックリスト」「仮説の書き方」の各シートが計画書に、「判定会議の記録」シートが報告書に対応しています。そのまま計画書・報告書のならしとしてお使いいただけます。

PoC検証の期間と費用は、対象の範囲と進め方で大きく変わるため、一律の相場はありません。その代わりに、何によって決まるのかを知っておくと、自社の場合の見積もりがしやすくなります。

期間は「検証そのもの」より「準備」で決まります

対象を1業務まで絞った業務システムのPoCでは、画面を作って確かめる作業そのものは、数回の打合せで進められる範囲に収まることが多くあります。期間を左右するのは、むしろ次の3つです。

 

期間を左右する要素	延びやすいケース	短くする工夫
現行のExcelや帳票を読み解く時間	関数やマクロが複雑で、作った人しか分からない	確認事項を一覧にしてから打合せに臨む
データの型と桁を決める時間	項目が多く、過去データの表記がばらばら	過去の実データから最大の桁数や値を拾っておく
社内の確認と判定の時間	判定者が決まっておらず、「持ち帰って検討」が繰り返される	判定者を1名にし、判定会議の日付を先に決める

 

期間を決めるときは、「何週間で終わらせるか」よりも、「判定会議をいつ開くか」を先に決めることをおすすめします。終わりが決まると、そこから逆算して検証の範囲を絞る判断がしやすくなります。

費用は「提供元への支払い」と「社内の工数」に分けて考えます

PoC検証にかかる費用は、「製品の提供元に支払う費用」と「自社の社員が使う時間（社内の工数）」の2つに分けて考えると整理しやすくなります。

製品の提供元に支払う費用には、検証用の環境の利用料や、画面・帳票を試しに作ってもらう費用などがあります。業務システムやノーコードツールでは、提供元が無償でPoCを支援している場合もあります。

社内の工数とは、検証に使うExcelや帳票の準備、打合せへの参加、実際の操作の確認、判定のための社内調整などに、社員が使う時間のことです。金額として表に出にくいため見落とされがちですが、実際には提供元に支払う費用より大きくなることもあります。

提供元の支援が無償でも、社内の工数はかかります。だからこそ、対象を絞り、判定の日付を決めて、「試しただけ」で終わらせないことが大切です。導入後の利用料については、検証項目の第4層（費用と運用体制）として、PoCの中で試算しておきましょう。

Q1. PoCと無償トライアルは何が違いますか？

無償トライアルは、製品を一定期間自由に使えるようにする仕組みで、何をどう試すかは利用者に任されます。PoCは、自社の業務データを使い、あらかじめ決めた検証項目に沿って、実現できるかを確かめる取り組みです。
操作に慣れていない段階や、何を試せばよいか決まっていない段階では、自社だけでトライアルを進めるよりも、提供元と一緒にPoCから始めるほうが確実です。

Q2. PoC検証の期間はどのくらいが目安ですか？

対象の範囲によって大きく変わるため、一律の目安はありません。対象を1業務まで絞れば、検証そのものは数回の打合せで進められる範囲に収まることが多くあります。期間を左右するのは、現行のExcelを読み解く時間、データの型と桁を決める時間、社内の判定の時間です。詳しくは「PoC検証の期間と費用の考え方」の章をご覧ください。

Q3. PoC検証で必ず確認すべき項目は何ですか？

業務システムのPoCであれば、少なくとも次の4つは確認してください。①現行の帳票がすべて再現できるか、②日常業務の担当者が説明なしで入力できるか、③既存システムとのデータのやり取りと、権限・アクセス制限などのセキュリティ要件を満たせるか、④全社に広げたときの費用が予算に収まるか、です。この4つは、本記事の検証項目の4層にそれぞれ対応しています。

Q4. 情報システム部門の担当者がいなくても、PoCは進められますか？

進められます。実際の検証でも、業務部門の担当者だけで進めているケースは少なくありません。ただし、基幹システムとの連携やセキュリティ要件（第3層）が検証項目に含まれる場合は、その部分だけでも情報システム部門や基幹システムの保守ベンダーに確認できる体制を用意しておいてください。

Q5. PoCの結果が良くなかった場合は、どうすればよいですか？

まず、どの層の検証項目が満たせなかったのかを確認してください。第1層（業務をシステムで再現できるか）や第3層（既存システム・セキュリティ）のマスト要件が満たせなかった場合は、別の手段を検討するのが妥当です。一方、第2層（現場が使い続けられるか）の課題は、設定や画面の工夫で解消できることも多くあります。No-Goの場合も、見送りの理由を記録しておくと、次に別の製品を検討する際の検証項目としてそのまま使えます。

ここまでの内容を、PoCを始める前に確認できるチェックリストにまとめました。すべてに「はい」と答えられれば、検証を始める準備は整っています。

 

始める前に決めておくこと

• □ PoCのテーマを「〜できるか」の問いの1文で書いた
• □ 対象を1業務まで絞った
• □ その業務で使っているExcelや帳票を、全種類そろえた
• □ 範囲を「今回確認する／将来の候補／既存のまま継続」に分けた
• □ 検証項目をマストとできればに分け、合否基準を書いた
• □ 比較対象を決めた（今の運用を続けた場合も含む）
• □ 判定する人を1名決めた
• □ 判定会議の日付と、撤退の基準を決めた
•  

検証中に守ること

• □ 日常業務の担当者に、実際に操作してもらっている
• □ 仮置きの部分を、関係者全員が把握している
• □ 「運用でカバーする」とした箇所を、残課題として記録している
• □ 製品側の制約について、解消の見込みと代替手段を確認している

 

このチェックリストは、検証項目テンプレート（Excel）の「開始前チェックリスト」シートにも収録しています。

PoC検証が「試しただけ」で終わる原因は、検証の前に「何が確認できたら導入するか」が決まっていないことにあります。実際の検証でも、評価指標を事前に決めているケースはほとんどありませんでした。

 

PoC検証は、次の6ステップで進めます。テーマを問いの1文で書き、対象を1業務まで絞って現物を集め、マスト要件とできれば要件を分けて検証項目を洗い出し、合否基準と判定者を決め、仮置きを明記したデモストーリーで検証し、残課題を記録して判定会議で結論を出します。

範囲は「今回確認する／将来の候補／既存のまま継続」の3つに区分し、検証項目は「業務をシステムで再現できるか」「現場が使い続けられるか」「既存システム・セキュリティと両立するか」「費用と運用体制が成り立つか」の4層で洗い出してください。検証項目テンプレートを使えば、この一連の整理をそのまま進められます。

 

---

業務システムの導入前検証について、資料と個別相談をご用意しています

 

PoC検証項目テンプレート（Excel・7シート）は、フォーム入力なしでダウンロードできます。

 

 

自社の業務をシステムで運用できるかを検討する段階では、バックオフィス業務の課題整理と、ノーコードでの実現範囲をまとめた資料もあわせてご覧いただけます。

 

PoCに関するご相談は以下よりお問い合わせください。PoCのお申し込みなら、「PoC希望」とお書きください。

 

 

※本記事は、当社が2026年から実施している業務システムの導入前検証（PoC）を通して得られた知見をもとにしています。検証にご協力いただいている企業が特定されないよう、事例は複数の検証に共通する傾向として一般化しており、本文中の「例」は編集部が説明のために構成したものです。検証の完了報告や導入効果の報告ではありません。