結論: PoCが止まるのは技術ではなく、目的設定・業務接続・成功基準の三点が事前に整理されていないためです。越えるには、PoC着手前にこれらを明文化する必要があります。
PoCは動くのに、本番に乗らない
公開されている国内のDX動向調査では、生成AI活用について「実証は進むものの本格利用に至っていない」という傾向が継続的に報告されています。PoCを一定数こなした事業者の側にも、そのまま停滞局面に入る層が観察される構造です。これは士業業界に限った話ではなく、業種を問わず広く見られます(ただし本番化に進む割合は規制度合いなどによって業種ごとに差があります)。士業事務所も例外ではなく、伴走前に各事務所の状況をヒアリングしてみると、同様のパターンが繰り返されていることが見えてきます。
PoCが止まる原因は、技術的な精度不足ではありません。主要な商用AIチャットツールは、業務に組み込む水準には到達しています。失敗してしまうのは、技術ではなく事前準備の構造です。
なお、PoCが本番運用で止まる構造そのものは、当ブログでも AIのPoCが「本番稼働しない」本当の理由・PoCが日々の業務に乗らないときに見直したい場面 で扱ってきました。本記事はそれらを踏まえ、「PoC着手前に明文化しておくべき三点」という事前準備の切り口で再整理し、終了時の判定を機械的に行うための二段階の成功基準まで踏み込みます。以下、士業事務所で観測される典型的な三つの失敗パターンを整理します。
パターン1:「AIを試してみたい」からPoCが始まってしまうケース
最も多いのが、目的設定が「AIを試してみたい」で止まっているケースです。きっかけは多様で、業界誌で他事務所の事例を読んだ、経営層がセミナーに参加した、ベンダーから提案を受けた、などがあります。どれも自然な動機ですが、そのままPoCを開始すると、「動くデモを作る」ことがPoCの目的になってしまいがちです。
具体的には次のようなフローが繰り返されます。商用AIチャットツールで試算表の要約をやってみる→動いた→「これで何ができますか」と関係者に問われる→「業務に組み込めば効果が出るかもしれません」と答える→経営層からは「で、何が変わるのか」と問われる→「もう少し検証期間が必要です」と回答することになります。ここでPoCが止まってしまいます。何度繰り返しても、「動く」と「業務が変わる」の間に橋がかからないままです。
この構造を抜けるには、PoC着手前に「何が変われば成功か」を業務指標として定義しておく必要があります。例えば、月次決算の平均工数を30% 削減する、顧問先面談の準備時間を一人あたり週5時間短縮する、申告書最終レビューに使う時間を半分にする、といった具体的な目標を、経営層と現場で合意してからPoCを始めます。この合意がないPoCは、動くデモを作るだけのコストとして終わってしまいます。
パターン2: 業務に踏み込まずにPoCが進んでしまうケース
二つ目のパターンは、PoCが情報システム担当や外部ベンダーだけで進み、実際に業務を回している現場の所員が関与しないままに完了してしまうケースです。完成したシステムは技術的には動作しますが、既存の業務フローと整合しないため、本番展開しても誰も使ってくれません。
士業事務所では、業務フローは事務所ごとに大きく異なっています。月次決算の手順は事務所の伝統と顧問先の業種で決まり、顧問先面談の準備は担当者ごとの暗黙知に依存し、申告書の最終チェックは代表者の判断基準で行われています。これらの暗黙的な業務文脈を踏まえずにPoCを組んでしまうと、出力は出ても現場では「これでは使えない」と判断される結果になりがちです。
例えば、試算表をAIで要約するツールをPoCで構築してみたとします。技術的には動きます。しかし現場の所員が見ると、「ここで触れている数字は、顧問先X社では特殊な処理をしているので、一般的な要約では意味を持たない」と判断されることがあります。こうした業務文脈は事前ヒアリングでは出てこないことが多く、実際に使う段階で初めて表面化してきます。結果として、PoCは技術的に成功したが業務には組み込めない、という状態で終わってしまうことになります。
これを避けるには、PoCの設計段階から現場の所員を巻き込み、業務フローの暗黙知をAIに取り込むプロセスを並走させていく必要があります。FDEモデル は、まさにこの統合を一人の責任で持つ役割設計になります。
パターン3: 成功基準を決めずにPoCが走ってしまうケース
三つ目は、PoCを始める段階で「何が成功か」が定義されていないケースです。パターン1と似ていますが、こちらは目的は曖昧でも始まってしまう、という違いがあります。結果として、PoCが終わった後に「これは成功と言えるのか」を判定できません。判定できないため、本番展開の稟議が通らず、PoCのまま放置されてしまいます。
成功基準は二段階で定義しておく必要があります。一段階目は業務指標で、工数削減率、出力品質、所員の利用率、顧問先からの評価といった、PoC終了時に観測できる指標です。二段階目は組織指標で、PoCで得られた成果を本番展開した場合に、何が経営に貢献するか、という指標になります。例えば、月次決算の工数が30% 削減できれば、浮いた時間で顧問先を一社あたり0.5件追加で対応できる、という形で換算します。
この二段階の指標をPoC着手前に経営層と合意しておくと、PoC終了時の判定が機械的に行えるようになります。業務指標を達成→本番展開の稟議へ。業務指標を達成できないが原因が特定できる→PoCのスコープを調整して継続。業務指標を達成できず原因も不明→PoCを中止して別のアプローチを検討。この三択を事前に合意しておくと、PoCが漂流しなくなります。
PoCを越えるための三つの前提条件
PoCを本番展開につなげるには、着手前に三点を明文化しておく必要があります。業務指標で表現された具体的な目標(「業務効率化」ではなく「月次決算の工数を30% 削減」のような数字)、現場の所員がPoC設計に関与する体制(情報システム担当やベンダー単独では業務文脈が抜け落ちる)、そしてPoC終了時の判定基準と次のアクション(業務指標の達成度に応じた三択の事前合意)。この三点が揃っていないPoCは、動くデモを作るコストとして終わります。
これらは技術より組織の話になります。だからこそ、PoCを越えられるかどうかは、ベンダーの提案力ではなく、事務所側の事前準備で決まる。伴走の最初に時間をかけるのも、この三点の整理になります。
初回相談で確認できること
自事務所のPoCが止まっている場合、三つのパターンのうちどれに該当しているかを60分の初回相談で整理することが可能です。受注前提ではなく、整理だけして社内検討に戻していただく形でも構いません。まずは現状を客観視するための時間として活用いただければと思います。