「PoC（概念実証。本格導入の前に小さく試す取り組み）は成功と報告された。なのに半年たっても本番で動いていない」。AI 導入の相談で、この話を聞かない月はありません。PoC の報告書には精度 9 割超と書いてある。担当者は満足している。それでも経理の締めや受注の登録は、以前と同じ手順で人が回している。止まった理由を聞くと「予算が付かなかった」「担当が異動した」と答えが返りますが、それは結果であって原因ではありません。
この記事は、PoC を 1 回以上やって本番に乗らなかった経験のある中堅企業の経営者と情シスに向けて書きます。前編にあたるバックオフィスAIエージェント、PoCで止まる会社と動かせた会社の分岐点では、PoC を始める「前」に決めておく 4 つの設計（使い方・データ・責任と例外・評価）を扱いました。本記事はその続きで、PoC が終わった「後」に本番へ乗らない原因を業務フロー上の詰まり方として 7 つに分け、それぞれに FDE（Forward Deployed Engineer。顧客の業務の中に入り、本番稼働まで作って動かし方を渡すエンジニア）がどう先回りするかを対にします。後半では、その先回りを準委任契約（成果物の完成ではなく、業務の遂行に対価を払う契約。2020年の民法改正後は、成果に応じて報酬を払う成果完成型（民法648条の2）も定められている）の条項にどう落とすかを、条項ごとに「PoC 止まりになる書き方」と「本番まで行く書き方」で並べます。
PoC が本番に乗らないのは AI の精度不足ではなく、例外の判断者・データの持ち主・運用担当・成功基準・権限と監査・二重入力・動かし方の引き継ぎ、という 7 か所が決まらないまま PoC が終わるからだ。FDE はこの 7 か所を PoC の初週に決めに行き、契約書では成果物を「動く仕組み＋動かし方」と定義し、判断者・範囲変更・引き継ぎ完了・検収・知財を条項で先に固める。
この記事の要約
「PoC は成功した」のに本番に乗らない——数字で見る停滞
まず、この停滞が自社だけの話ではないことを一次資料で確認しておきます。Gartner は 2024 年 7 月の発表で、生成 AI プロジェクトの少なくとも 30% が 2025 年末までに PoC の後で放棄されると予測しました。理由として挙げたのは、データ品質の低さ、リスク管理の不備、コストの増大、事業価値の不明確さの 4 つです。翌 2025 年 6 月には対象を AI エージェントに広げ、40% 超のプロジェクトが 2027 年末までに中止されるとしています。同社のアナリストは、現在のエージェント AI プロジェクトの大半は過熱した期待に駆動された初期段階の実験や PoC で、適用先を誤っていることも多く、大規模展開の実コストと複雑さを見誤って本番移行が滞る、と述べています（要旨）。
McKinsey が 2026 年 8 月 25 日に公開した年次調査「The state of AI in 2026」も同じ構図です。AI の利用が自社の EBIT（利払い前・税引き前利益）に影響したと答えた回答者は 37% で前年から変わらず、EBIT の 5% 以上を AI に帰属させ、かつ AI の影響を「大きい」と評価する「高成果企業」は約 6% のまま。一方で、AI が自分個人の生産性を上げたと答えた人は 80% に上ります。個人の効率は上がっているのに、会社の利益には届かない。この差が「本番に乗っていない」状態そのもの。大企業（年商 10 億ドル超）で AI エージェントを本格展開している割合は 27% から 40% に伸びましたが、それ以外の企業は 22% で横ばいでした。
日本の数字はもう一段厳しい。IPA（情報処理推進機構）が 2025 年 6 月に公開した「DX 動向 2025」によれば、DX に取り組む企業のうち「成果が出ている」と答えた割合は米国・ドイツが 8 割以上に対して日本は 6 割弱。従業員 1,001 人以上の企業でも日本は 64.2%（米国 84.0%、ドイツ 92.0%）、100 人以下では 58.1% です。しかも日本は「成果が出ているか分からない」と答えた企業の割合が両国より大きい。経営者・IT 部門・業務部門の協調が「できている」と答えた割合は日本が約 4 割で、米国の 8 割弱、ドイツの 6 割 5 分程度と開きがあります。生成 AI の利用形態でも、「個人や部署で試験利用」は 3 か国とも高いのに、「部署の業務プロセスに組み込まれている」は日本の回答率が低い。試すところまでは行くが、業務に組み込む段で止まる。統計はそう言っています。
この停滞を海外の AI 会社は「導入をやり切る人が足りない」問題と捉え、Claude 業務導入コンサル市場で書いたように導入専門の部隊を作り始めました。ハブ記事「今さら聞けない FDE とは」で整理したとおり、FDE の成果物は提案書でも PoC 報告書でもなく、本番で動いている仕組みと、その動かし方です。では、その FDE は「本番に乗らない原因」をどこで摘んでいるのか。
本番に乗らない 7 つの原因——業務フローのどこで詰まるか
前編の 4 つの設計は「PoC を始める前に何を決めるか」でした。ここから挙げる 7 つは、4 つを決めて PoC を走らせた会社でも、本番へ移す段になって表面化する詰まりです。どれも AI の性能の話ではありません。業務フローの上で「この件は誰が何をするか」が空欄のままだと、PoC は動いても本番は動かない。7 つそれぞれに、FDE が現場でどう先回りするかを対で書きます。エンタープライズ AI 導入のスケール 4 段階でいえば、1 段目（試す）から 2 段目（使う）へ上がる階段で起きることです。
原因 1 例外を誰が判断するか決めていない
PoC は「きれいなデータ」で回ります。請求書の読み取りなら、様式が揃った取引先の分だけを使い、精度 95% が出る。ところが本番では、手書きの但し書きが付いた請求書、金額が見積と 1 円違う請求書、取引先マスタに無い新規先からの請求書が毎日届きます。AI が「判断できない」と返したとき、誰が見て、何分以内に決めて、その結果をどこに記録するのか。これが決まっていないと、AI の出力を全件人が見直す運用になり、PoC 前より工数が増えます。本番に乗らない会社の多くは、この「例外の行き先」が空欄のまま PoC を終えています。
FDE は、PoC の初週に現場へ入り、過去 1〜3 か月分の実データから「AI に判断させない例外」の一覧を先に作ります。金額の不一致、マスタ未登録、添付漏れ、といった種類ごとに「誰が・いつまでに・どう記録するか」を担当者の名前で埋める。例外が多い種類は、AI に判断させる前に業務側のルール（例えば「新規先は登録申請を先に出す」）で件数を減らします。AI の精度を上げる前に、例外の行き先を決める。順番はこちらが先です。
原因 2 データの持ち主が決まっていない
前編で「正本を 1 つに決める」と書きました。本番で詰まるのはその次で、正本が決まった後に「誰が直すか」が決まっていない場面です。取引先マスタの住所が古い。勘定科目の名称が会計ソフトと管理表で違う。AI はそれを検知して「不一致」と返しますが、直す権限を持つ人がいない。経理は「営業が登録したから営業が直すべき」と言い、営業は「マスタは経理の管轄」と言う。PoC の期間中は FDE や外部ベンダーが手で直していたので気づかず、本番に移った途端に不一致が溜まって止まります。
FDE は、AI が参照するデータ項目ごとに「持ち主」を担当者名で決めた表を作ります。項目は 20〜40 になることが多く、1 項目ずつ「更新できる人」「更新を承認する人」「更新のきっかけ（入金確認時、契約締結時など）」を書く。持ち主が決まらない項目は、AI に読ませる対象から外すか、暫定で情シスが持つと決めて期限を切ります。FDE が本番で動かす仕組みは、この表が埋まった項目だけで組みます。
原因 3 PoC の担当者と運用担当者が別
PoC は情シスや DX 推進室が主導し、本番で使うのは経理や営業の担当者。この分離が、PoC の「成功」と本番の「不使用」を同時に生みます。PoC の担当者は仕組みの中身を理解し、多少の不具合は自分で回避できる。運用担当者は仕組みを説明された記憶しかなく、最初に見慣れない出力が出た時点で使うのをやめます。IPA の調査で「経営者・IT 部門・業務部門の協調ができている」と答えた日本企業が約 4 割にとどまる、という数字は、この分離がどれだけ一般的かを示しています。
FDE は、PoC の初日から運用担当者の隣で作ります。技術の説明相手は情シスでも、出力を毎日見るのは業務担当者だからです。具体的には、業務側に「Echo 役」（ハブ記事で使った言い方で、FDE から業務と仕組みを引き継ぐ担当）を 1 人決め、その人が日次で出力を確認する場を PoC の期間中に作ってしまう。本番移行は「新しい仕組みを使い始める日」ではなく「FDE がその場から抜ける日」になり、運用担当者にとって何も変わらない状態を目指します。
原因 4 成功基準が「精度」で、「運用性」ではない
PoC の報告書に書かれる成功基準は、ほとんどが精度です。読み取り精度 95%、分類の正答率 90%。この数字は本番で使えるかどうかを何も言っていません。本番で問われるのは、1 件あたり何分で処理が終わるか、人が修正した件数は何件か、エラーが出たとき誰が何分で復旧できるか、月末の 3 倍の件数でも同じ時間で終わるか、です。精度 95% でも、残り 5% の処理に 1 件 30 分かかれば、導入前より遅い。McKinsey の調査で個人の生産性向上を 80% が実感しながら、会社の利益への影響が 37% にとどまるのは、この「個人の体感」と「業務の指標」の差でもあります。
FDE は、精度に加えて運用の指標を PoC の開始時に 3 つ決めます。1 件あたりの処理時間（人の作業を含む）、人が修正した割合、例外の件数と平均の処理時間。前編で挙げた処理件数・所要時間・修正割合に、例外の扱いを加えた形です。導入前の実測値を先に取り、PoC 中は毎週同じ物差しで測る。この 3 つのいずれかが導入前より悪化（処理時間・修正割合・例外が増加）したら本番へ移さない、という判断基準を経営側と最初に合意しておきます。
原因 5 権限・監査・ログの要件が後から出る
PoC が終わり、本番へ移す稟議を回した段階で、内部監査や会計監査人から要件が出てきます。「AI が仕訳を起票するなら、誰がいつ承認したかを残せ」「顧客情報を外部の AI に渡すなら、送信範囲と保存期間を示せ」「担当者ごとに見られる範囲を分けろ」。PoC ではこれらを考えずに作っているため、追加の設計と開発が要り、予算と期間が想定を超えて止まります。Gartner が PoC 放棄の理由に「リスク管理の不備」を挙げているのはこの場面です。
FDE は、PoC の初週に「本番で誰が承認するか」「何を記録に残すか」「どのデータを外に出さないか」を監査・情シス・業務の 3 者に聞き、PoC の仕組みにその要件を最初から入れます。承認の履歴、AI に渡したデータの記録、担当者ごとの参照範囲は、後付けすると作り直しになる部分。逆に最初から入れれば、PoC の仕組みがそのまま本番の仕組みになります。
原因 6 既存システムとの二重入力が残る
AI で受注メールを読み取って案件を登録する仕組みを作った。しかし基幹システムには相変わらず人が同じ内容を打ち込んでいる。理由は「基幹側は変えられない」「PoC の範囲外だった」。二重入力が残ると、現場は「AI に登録させても結局自分で打つ」と判断し、新しい仕組みのほうを使わなくなります。PoC の範囲を狭くしたことが、本番でそのまま不使用の理由になる典型です。
FDE は、PoC の範囲を決める段階で「この業務の出力はどこへ行くか」を最後まで追い、二重入力になる箇所を洗い出します。基幹側を変えられないなら、AI の出力を基幹側の取り込み形式に合わせて渡す、または基幹側の入力を AI の出力から転記する手順に置き換えて人の入力を 1 回にする。二重入力を残したまま本番へ移す場合は、「いつまでに片方をやめるか」の期限を先に決め、期限の判断者を置きます。
原因 7 PoC 終了時に「動かし方」が誰にも渡っていない
PoC の納品物はたいてい、報告書とデモ環境です。動かし方、つまり毎朝の起動、エラーが出たときの見方、AI の指示文（プロンプト）を直す手順、取引先が増えたときの設定の足し方、月次で見る数字、といった運用の手順書と担当者が残っていない。PoC を作った人が異動や契約終了でいなくなると、動かせる人がゼロになります。「担当が異動したから止まった」の正体は、ここです。
FDE の成果物は「動く仕組み」と「動かし方」の両方だと、ハブ記事で書きました。動かし方とは、Echo 役が FDE なしで 1 か月回せる状態を指します。FDE は本番移行の前に、Echo 役だけで日次の確認・週次の設定変更・月次の指標確認を 2〜4 週間回してもらい、詰まった箇所を手順書に足していく。FDE が抜けた後に「誰が動かすか」が空欄なら、その仕組みは本番に乗っていません。
実際に本番まで行ったケースで共通していたこと
弊社は経理の AX（AI による業務変革）、kintone の業務アプリ構築、設備投資型の事業を営む中堅企業（従業員 100〜300 人）の案件管理システム刷新、Claude の導入で、本番稼働まで伴走した経験があります。社名や金額は書けませんが、本番まで行ったケースに共通していたやり方は 4 つに絞れます。
- 要件が固まる前に、動くものを出した。 要件定義書を待たず、着手から 1〜2 週間で実データを流した画面を業務担当者に見せた。見た人が「この列は要らない」「この例外が抜けている」と言う。その指摘を要件にした。文書で合意した要件より、動くものへの指摘のほうが本番で使われる形に近い
- 日次 15 分の確認で判断を積んだ。 週 1 回の定例で判断をまとめて取ると、1 回で 10〜20 件の判断が溜まり、担当者が決めきれず持ち帰りになる。Echo 役と毎日 15 分、その日の出力を見て 2〜3 件ずつ決めた。1 か月で 40〜60 件の判断が積み上がり、それがそのまま例外一覧と手順書になった
- 二重入力の終了日を先に決めた。 既存の管理表と新しい仕組みを並走させる期間を「2 か月」と最初に区切り、終了日に管理表を読み取り専用にした。終了日が無い並走は、忙しい月にすべて旧来の手順へ戻る
- PoC の初日から、本番で使う権限と記録の設計を入れた。 承認履歴と参照範囲を後から足したケースは、当社が関わった範囲では 1〜2 か月の手戻りが出た。最初から入れたケースは、PoC の仕組みをそのまま本番へ移した
4 つとも、技術ではなく「誰がいつ判断するか」の話です。『AI 導入』の本当の難しさで書いたフロー管理の壁は、FDE を入れても消えません。消えるのは、判断を小さく毎日取る場を FDE が作ったときです。そして、その場を作れるかどうかは、契約の書き方に大きく左右されます。
契約書にどう書くか——準委任を選ぶ理由
ここからは契約の話です。断っておくと、これは法的助言ではなく、発注側が本番まで行くために実務上どう書いておくかの整理です。以下の「書き方」は条項の例であって、法的な効力や契約類型の評価は個別の契約内容と事情で変わります。契約書に落とす前に、必ず弁護士に確認してください。
当社が見てきた範囲では、PoC 止まりになる契約の多くは、請負契約（成果物の完成に対価を払う契約）か、成果物を「報告書」と定めた準委任契約でした。前者は「何を作るか」を契約時に固定するため、PoC で分かった例外や二重入力の解消が範囲外になり、追加見積と稟議で止まる。後者は成果物が報告書なので、報告書が納品された時点で契約が終わり、本番移行は別契約の交渉になります。
FDE 型の支援は、要件が動くことを前提に、判断を顧客と一緒に積みながら本番まで持っていく仕事です。この進め方に合う契約の型として、IPA が 2020 年 3 月に公開した「情報システム・モデル取引・契約書（アジャイル開発版）」があります。このモデル契約は準委任を前提とし、解説文では、あらかじめ内容が特定された成果物を予定どおり完成させることに対価を払う請負契約よりも、ベンダが専門家としての注意義務を果たしながら業務を遂行することそれ自体に対価を支払う準委任契約のほうが馴染みやすい、という立場（要旨）。なお、このモデル契約自体は完成義務も検収も置いておらず（第5条・第10条）、毎月の実施業務の確認で進める建て付けです。あわせて、発注側がプロダクトオーナー（要求の優先順位と完了確認の権限を持つ責任者）を選任すること、契約書・別紙の変更は書面協議と変更合意書で行い、バックログの追加・優先順位変更はチーム内で行うこと、文書作成を要求事項として明示的に時間を確保すること、著作権は完了確認と支払いの時点で発注側に移転する案を原則とすること、を条項として示しています（適用の可否は個別の契約によります）。
このモデル契約は FDE 型の支援にそのまま使えるわけではありません。スクラム（1〜4 週間の反復で開発する進め方）を前提にしており、既存の業務システムへの組み込みや本番移行の完了条件は薄い。それでも「準委任＋発注側の判断者＋書面の変更手続き＋文書作成の明示＋知財の帰属」という骨格は、PoC を本番まで持っていく契約の骨格と同じです。以下、FDE 型の支援で足すべき条項を 6 つに分けます。
条項別——PoC 止まりになる書き方、本番まで行く書き方
6 つの条項について、よく見る書き方と、本番まで行く書き方を並べます。右列の書き方は、前半の 7 つの原因をそれぞれ契約で塞ぐものです。
| 条項 | PoC 止まりになる書き方 | 本番まで行く書き方 | 塞ぐ原因 |
|---|---|---|---|
| 成果物の定義 | 「検証結果報告書一式」「デモ環境」 | 「本番環境で稼働する仕組み」と「動かし方（日次・週次・月次の運用手順書、例外一覧、設定変更手順、担当者名入りの引き継ぎ表）」の両方。報告書は付随物と明記 | 原因 7 |
| 判断者と会議体 | 「甲乙協議のうえ決定する」 | 甲は業務側の責任者（Echo 役）1 名と最終決裁者 1 名を氏名で指定。日次 15 分の確認と週次 30 分の判断会議を定め、判断の記録先（議事録の置き場）を決める。Echo 役が決められない事項は 5 営業日以内に最終決裁者が決める | 原因 1・3 |
| 範囲変更の手順 | 「別途協議」「追加費用は見積による」 | 変更は書面（メール可）で提案し、影響（時間・費用・移行日）を添えて週次会議で判断。月あたりの稼働上限の範囲内なら合意書なしで優先順位の入れ替えで吸収し、上限を超える場合と、別紙に書いた移行日・体制・対象範囲を変える場合は変更合意書を交わす | 原因 6 |
| 本番移行・引き継ぎの完了条件 | 「納品をもって完了」「検収後 1 か月の瑕疵対応」 | Echo 役が乙の支援なしで日次・週次・月次の運用を連続 20 営業日回せた時点を引き継ぎ完了とする。その間の問い合わせ件数と復旧時間を記録し、手順書に反映してから完了 | 原因 3・7 |
| 検収条件 | 「精度 90% 以上」「デモの実施」 | 導入前に実測した 1 件あたり処理時間・人の修正割合・例外の件数と処理時間の 3 指標を基準とし、本番データで 4 週間の実測が導入前の実測値より悪化しないこと（本番移行の判定基準であり、支払条件とは分ける）。承認履歴・参照範囲・データ送信の記録が監査要件を満たすことを検収項目に含める | 原因 4・5 |
| 知財・データ | 「成果物の著作権は乙に帰属」「データの取り扱いは別途定める」 | 業務固有の設定・手順書・指示文の著作権は支払い時点で甲へ移転（乙の汎用部品は除く）。AI に渡すデータの範囲・保存先・保存期間・終了時の削除を別紙で列挙し、マスタの持ち主（更新権限者）を項目ごとに定めた表を別紙に添付 | 原因 2・5 |
表の右列は長い。長いのは、PoC の後で揉める箇所をすべて契約時に決めているからです。書き方が短い契約は、決めていないのではなく、決めるのを後回しにしている。後回しにした分が、本番移行の直前に稟議・見積・交渉として戻ってきます。
条項ごとの補足——どこまで細かく書くか
成果物の定義と検収は「本番データで測る」
成果物を「動く仕組み」と書いただけでは、デモ環境で動けば満たされてしまいます。「本番環境で」「本番データで」「業務担当者が」動かした結果で測る、と 3 つの条件を入れてください。検収の 3 指標（処理時間・修正割合・例外）は、導入前の実測値を契約の別紙に数字で書きます。実測値がまだ無い場合は、契約後の最初の 2 週間で乙が実測し、別紙を差し替える手順を条項にしておくと、検収の基準が「後で決める」になりません。
判断者は氏名で、代理と期限を付ける
「甲乙協議のうえ」が PoC を止めるのは、協議の場と期限が無いからです。IPA のモデル契約も、プロダクトオーナーは発注側が選任し、必要な情報と意思決定を適時に提供する義務を発注側に置いている。FDE 型の支援では、この役を Echo 役として氏名で指定し、不在時の代理と、決められない場合の上申先と期限を添えます。判断が滞った日数分の期間延長を乙が求められる、と書いておくと、発注側も判断を先送りしにくくなります。
範囲変更は「稼働の上限内なら合意書なし」にする
PoC で分かった例外や二重入力の解消を、毎回変更合意書と見積で処理していては、本番まで持ちません。月あたりの稼働時間の上限を決め、その範囲内では要求の優先順位を Echo 役が入れ替えるだけで対応できる、と書きます。IPA のモデル契約では変更協議の出席者を「意思決定権限を有する責任者」と定め、合意が調わないまま一定日数が過ぎた場合の解除まで規定している。上限を超える変更だけをこの手続きに回せば、書面の手間は月に 1 回あるかないかになります。
引き継ぎの完了は「乙がいなくても回った日数」で決める
「納品をもって完了」は、動かし方が渡っていなくても完了になります。Echo 役が単独で運用した連続日数を完了条件にすると、乙はその日数を稼ぐために手順書と例外一覧を仕上げざるを得ません。20 営業日は目安で、月次処理を 1 回含む長さを選んでください。並走期間中の問い合わせ件数を記録し、記録がゼロに近づいたことを完了の証拠にします。
知財・データは「業務固有」と「汎用」を分ける
乙が持ち込む汎用部品まで甲に帰属させると乙は受けにくくなり、逆に全部を乙に帰属させると、乙が抜けた後に甲が手順書や指示文を直せなくなるおそれがあります。どう分けるかは弁護士と詰める論点です。IPA のモデル契約が「ベンダーの汎用利用可能なプログラムを除き、完了確認と支払いの時点で発注側へ移転」を原則案にしているのは、この線引きのため。データについては、AI に渡す項目、保存先、保存期間、契約終了時の削除を別紙で列挙し、マスタの持ち主の表（原因 2 で作るもの）をそのまま別紙にします。契約の別紙が業務の台帳を兼ねる形です。
止まった PoC を再開するときの順番
すでに止まった PoC がある会社は、ツールを選び直す前に、次の順番で棚卸しをしてください。
- 7 つの原因に当てはめる。 止まった PoC を原因 1〜7 に照らし、空欄だった箇所に印を付ける。3 つ以上に当てはまることが多い。技術の問題だと思っていたものが、判断者と持ち主の空欄だと分かる
- Echo 役を先に決める。 空欄を埋める判断ができる業務側の責任者を 1 名決め、日次 15 分の確認の場を作る。この人が決まらないなら再開しない。決まらないまま再開すると、同じ場所で止まる
- PoC の仕組みを捨てるか、活かすかを決める。 権限・監査・記録の設計が入っていない PoC は、足すより作り直したほうが早いことが多い。例外一覧と実測値だけを引き継ぐ
- 契約を 6 条項で書き直す。 前の契約が請負か、成果物が報告書だったなら、準委任で成果物を「動く仕組み＋動かし方」に定義し直す。検収の 3 指標と引き継ぎの完了条件を別紙に数字で入れる
- 本番移行日ではなく、二重入力の終了日を決める。 移行日は延びる。並走の終了日を先に決め、その日に旧来の手順を止める判断者を置く
再開の判断で見落とされやすいのが 2 番目です。IPA の調査で日本企業の 3 部門協調が約 4 割にとどまる以上、Echo 役が決まらない会社のほうが多い。FDE を呼ぶ前に決めるべきは、ツールでも予算でもなく、この 1 名です。
まとめ
PoC が本番に乗らない原因は、AI の精度ではなく業務フロー上の 7 つの空欄です。例外の判断者、データの持ち主、PoC 担当と運用担当の分離、精度だけの成功基準、後出しの権限・監査要件、二重入力の残存、動かし方の未引き継ぎ。Gartner が PoC 後の放棄を 30%、エージェントの中止を 40% 超と予測し、McKinsey が利益への影響を 37% で横ばいと報告し、IPA が日本の DX 成果を 6 割弱と示す。これらの調査が示す停滞の内側で、当社の現場で繰り返し見たのがこの 7 つの空欄です。FDE はこの 7 か所を PoC の初週に決めに行き、日次で判断を積み、Echo 役が単独で回せるようになってから抜けます。
契約書は、その先回りを発注側が担保する道具です。準委任を選び、成果物を「動く仕組み＋動かし方」と定義し、判断者を氏名で置き、範囲変更を稼働上限内で吸収し、引き継ぎ完了を乙なしで回った日数で決め、検収を本番データの 3 指標で測り、知財とデータを業務固有と汎用で分ける。6 条項を書いた契約は長くなりますが、長さの分だけ本番移行の直前に戻ってくる交渉が減ります。条文は弁護士の確認を通したうえで、止まった PoC の再開から使ってください。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
止まった PoC の棚卸しと、本番まで行く契約の組み立て
止まった PoC を 7 つの原因に当てはめる棚卸し、Echo 役の選定、準委任契約の 6 条項（成果物・判断者・範囲変更・引き継ぎ完了・検収・知財とデータ）の実務上の書き方の相談をお受けしています。経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験をもとに、貴社の業務に合わせて組み立てます。契約条文は顧問弁護士との連携を前提にご相談ください。