FDE（Forward Deployed Engineer）型の支援を頼むと、決まって最初の契約実務で止まる論点があります。「成果物は何か」「何をもって検収とするか」。従来の受託開発なら、要件定義書・設計書・テスト仕様書・プログラム一式を納品し、検査仕様書に沿って検査して合格書を出せば終わりでした。ところが FDE の成果物は「本番で動いている仕組み」と「その動かし方」です。紙の束ではないので、従来の検収条件のままでは、何を確認すれば受け取ってよいのかが決まりません。
この記事は、発注側の経営者・情シス・購買担当の方に向けて、FDE 型支援の成果物を契約書に書ける形にする方法を整理したものです。読み終えると、①従来の成果物と FDE の成果物の違い、②「動かし方」として何を受け取るべきか、③準委任契約における検収の位置づけ（経産省・IPA のモデル契約書での扱い）、④業務単位で書く検収条件の良い例と悪い例、⑤自社で作れる検収書のひな型、の5点が手元に残る構成です。FDE そのものの説明はハブ記事「今さら聞けない FDE とは」に譲り、ここでは契約と検収に絞る。
FDE の成果物は「本番で動いている仕組み」と「動かし方」の2つ。動かし方とは、運用手順・例外時の判断表・権限表・データの持ち主一覧・変更のやり方・Echo 役への引き継ぎ記録のこと。検収条件は機能の一覧ではなく「本番データで、担当者が、FDE の同席なしに、業務1サイクルを回せること」と業務単位で書く。準委任契約では法律上の「検収」はなく、業務終了報告書の確認がそれに当たるので、確認の中身を契約で決めておく。
この記事の要約
従来の成果物と FDE の成果物は、何が違うのか
違いを一言でいえば、従来の受託開発は「文書と製造物」を納め、FDE は「稼働している状態」を残します。前者は納品日に机の上に置けるもの、後者は納品日に業務が回っている事実そのものです。この差が、検収の書き方を根本から変える。
| 観点 | 従来の受託開発 | FDE 型の支援 |
|---|---|---|
| 主な成果物 | 要件定義書、基本設計書、詳細設計書、テスト仕様書・結果報告書、プログラム一式、操作マニュアル | 本番環境で稼働している仕組み（システム・AI エージェント・連携設定）と、その動かし方 |
| 何と照合するか | システム仕様書（合意した仕様に合っているか） | 業務（本番データで、担当者が業務を回せるか） |
| 確認する人 | 情シスまたはベンダのテスト担当 | その業務の担当者と責任者（Echo 役） |
| 確認の場所 | 検証環境。テストデータ | 本番環境。本番データ |
| 確認の単位 | 機能ごと（画面、帳票、バッチ） | 業務サイクルごと（月次締め1回、案件登録から請求まで1件） |
| 合格の基準 | テスト項目が全件合格 | FDE の同席なしに1サイクル完走。例外が起きたときの判断が判断表に載っている |
| 終わった後に残るもの | 文書一式と、保守契約 | 回る業務と、変更のやり方と、引き継いだ担当者 |
従来の検収は「仕様書どおりか」を見ます。仕様書は発注側が承認したものなので、それに合っていれば受け取る義務がある、という建て付けだ。FDE 型は仕様書が先にありません。現場に入って業務を見ながら作るので、照合先は仕様書ではなく業務そのものになります。ハブ記事で「FDE には仕様書ではなく業務そのものを渡す」と書いたのは、この意味だ。渡すものが変われば、受け取り方も変わります。
AWS が2026年6月に FDE 組織の設立を発表した際、顧客に残るものを「稼働するシステム、ナレッジグラフ、ランブック（手順書）、構成の説明資料、独立して運用できるよう訓練された社内の担い手」と列挙しました。文書が要らなくなったのではなく、文書の役割が「仕様の証明」から「動かし方の記録」に変わった、と読むのが正確です。
「動かし方」の中身を6つに分ける
「動かし方も渡します」という言葉は、そのままでは契約書に書けません。何が届けば「渡った」と言えるのか。当社が経理 AX・kintone・案件管理システムの刷新・Claude 導入で本番稼働まで伴走した経験から、受け取るべきものは次の6つに分けられます。
| 項目 | 中身 | 無いと何が起きるか |
|---|---|---|
| ① 運用手順 | 日次・週次・月次で誰が何をするか。開始条件、確認する画面、終了条件。「いつもの手順」だけでなく月初・期末・年度替わりの特別手順も含む | 月次はできるが期末で止まる。担当者の頭の中にしか手順がない |
| ② 例外時の判断表 | 想定外の入力・エラー・不一致が出たとき、誰が何を基準に判断し、誰に上げるか。「AI の出力が怪しいと感じたら」の判断基準も含む | FDE に電話するしかなくなる。判断が属人化し、担当者交代で止まる |
| ③ 権限表 | 誰が何を見られて、何を変えられるか。管理者権限を持つ人、承認できる人、API キーやサービスアカウントの持ち主 | 退職者のアカウントで動き続ける。監査で「誰が承認したか」を答えられない |
| ④ データの持ち主一覧 | どのデータがどこにあり、正本はどれで、誰が責任者か。外部サービスに置いたデータの契約者名義と削除方法 | 同じ数字が2か所にあり、どちらが正しいか分からない。契約終了時にデータを取り出せない |
| ⑤ 変更のやり方 | 設定値を変える手順、プロンプトや判定ルールを直す手順、変えてよい範囲と変えてはいけない範囲、変更前の確認方法 | 小さな変更のたびに外注する。触るのが怖くて業務のほうを仕組みに合わせる |
| ⑥ Echo 役への引き継ぎ記録 | FDE が Echo 役に何をいつ引き継いだかの記録。Echo 役が自分で実施した回数と、その際に出た質問と回答 | 「引き継いだつもり」と「受け取ったつもり」がずれる。誰が業務の責任者か曖昧なまま FDE が帰る |
Echo 役は、ハブ記事で使った言葉で、FDE から業務と仕組みを引き継ぐ社内の担当者を指します。Palantir が FDE（社内呼称 Delta）と組ませた非技術職 Echo が語源。⑥の引き継ぎ記録が肝で、これがあるかどうかで残りの5つが「文書として存在する」から「使われている」に変わります。
6つの中で文書の形をとるのは①〜⑤ですが、いずれも A4 で数枚に収まる程度で足ります。厚い設計書は要りません。求めるのは網羅性ではなく、担当者が困ったときに開いて答えが見つかることです。②の判断表は、当社の経験では10〜20行の表になることがほとんどで、それ以上になるなら業務の設計そのものを見直したほうが早い。
「動かし方」が渡らなかったとき、業務で何が起きるか
契約書の話に入る前に、動かし方が渡らなかった会社で起きることを、業務の場面で書いておきます。どれも珍しい話ではなく、システム刷新のたびに繰り返されてきた光景です。
担当者が交代した月に、締めが止まる
月次締めを FDE と一緒に3回回し、4回目から担当者だけで回した。ここまでは順調でした。半年後、担当者が異動し、後任が初めての月次で「取り込みエラーが出たがどうすればいいか」で止まる。前任者は手順を口頭で引き継いだが、例外時の判断は「そのときは FDE さんに聞いた」で終わっていた。FDE の契約は終わっており、問い合わせ先がない。締めが2日遅れ、経営会議の資料が間に合わない。
変更のたびに見積を取る
取引先が1社増え、請求書のフォーマットが1種類増えた。仕組みの側では判定ルールを1行足せば済む変更ですが、どこを触ればよいか、触った後に何を確認すればよいかが社内に残っていない。結果、数万円の変更を外注するために見積を取り、発注し、2週間待つ。これが年に数回続くと、現場は仕組みを直すのをやめ、手作業で回避するようになります。仕組みは動いているのに、業務は元に戻っていく。
監査で「誰が承認したか」を答えられない
内部監査または会計監査で「この仕訳は誰がどの基準で承認したか」を聞かれる。AI が下書きし、人が承認する流れのはずが、承認者の権限表がなく、実際には管理者アカウントを共有していた。誰の判断かを示す記録がない。仕組みは正しく動いていたのに、統制の説明ができない。これは動かし方のうち③権限表と②判断表が渡っていない状態で、仕組みの品質とは関係なく起きます。
3つに共通するのは、仕組みは壊れていないという点です。壊れたのは「動かし方」のほうで、そこは従来の検収では確認対象になっていませんでした。PoC で止まる会社と動かせた会社で書いた分かれ目も、突き詰めればここです。
準委任契約に「検収」はあるのか。請負との違い
FDE 型の支援は、現場に入って業務を見ながら作るので、着手前に成果物を特定できません。この性質から、契約類型は準委任（仕事の完成ではなく、専門家として注意を尽くして業務を行うことを約束する契約）で組まれることが多いようです。ここで発注側が押さえておきたいのは、経産省・IPA のモデル契約書の整理では、準委任の工程に請負型の「検収」の手続が置かれていない、という点です。
経済産業省と IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」（第二版、2020年12月）は、請負と準委任の違いを次のように整理しています。請負では受託者は仕事の完成義務を負い、完成した成果物が契約内容に合わなければ契約不適合責任を負う、とされています。準委任では受託者は善良な管理者の注意をもって事務を処理する義務を負うが、仕事の完成義務は負わず、請負のような契約不適合責任も負わない、と整理されています。ただし注意義務に違反すれば通常の債務不履行責任を負う、とも書かれています。同書はさらに「請負に馴染むのは、業務に着手する前の段階でベンダにとって成果物の内容が具体的に特定できる場合」とし、要件定義のように着手時点で成果物を想定できない工程は準委任が適切だと述べています。
| 観点（モデル契約書の整理） | 請負 | 準委任 |
|---|---|---|
| 受託者が約束すること | 仕事の完成 | 専門家としての注意を尽くして業務を行うこと |
| 成果物の特定 | 着手前に特定できることが前提 | 着手時点で特定できなくてもよい |
| 成果物が契約内容に合わないとき | 契約不適合責任（追完・減額・損害賠償・解除）とされる | 契約不適合責任は負わず、注意義務違反があれば債務不履行責任、と整理されている |
| モデル契約書での確認手続 | 検査仕様書に基づく検査。合格をもって検収完了。期限内に異議がなければみなし合格 | 業務終了報告書の提出と、点検期間内の確認。異議がなければみなし確認 |
| FDE 型支援との相性 | 仕様が先に決まらないため馴染みにくい | 業務の中で作る進め方に合う。ただし「何を確認するか」を契約で決めないと確認が形式化する |
モデル契約書の構成を見ると、請負型の工程では「検査仕様書に基づいて検査し、合格をもって検収完了」と定める一方、準委任型の工程（要件定義支援、運用準備・移行支援）では「業務終了報告書を提出し、点検期間内にユーザが確認する」という手続。同書の解説は、この確認を「ベンダが善管注意義務に基づき適切に支援作業を実施したかを確認するため」の手続と位置づけています。つまり、モデル契約書の建て付けでは、準委任における「検収」に当たるものは業務終了報告書の確認だと読めます。
2020年3月公開の「アジャイル開発版」も同じ考え方で、契約全体を準委任とし、毎月の実施業務報告をユーザが点検期間内に確認する条項（第10条）を置いた。理由として、内容が変わっていく開発では「あらかじめ内容が特定された成果物を予定したとおりに完成させることを義務付ける請負契約より、専門家としての注意義務を果たしながら業務を遂行することを義務付ける準委任契約の方が馴染み易い」と述べています。FDE 型支援はこのアジャイル開発版に近い性質を持ちます。
発注側にとっての含意は2つです。第一に、準委任だから「動かなくても何も言えない」とは限らない、と説明されています。専門家として通常求められる水準を下回れば注意義務違反になる。第二に、業務終了報告書の確認は「報告書を読んで異議を述べない」だけでも成立してしまうので、何を確認して合格とするかを契約で具体的に決めておかないと、確認が形式に流れます。次の章で扱う「業務単位の検収条件」は、この確認の中身を決める作業です。
なお、2020年4月施行の改正民法で、準委任に「成果報酬型」（成果の引渡しと引き換えに報酬を払う類型）が明文化されました。モデル契約書の民法改正対応版の解説は、システム開発では「何をどこまでやれば成果を出したといえるか自体が紛争の原因となりそう」との意見から、成果報酬型を積極的に採用せず、履行割合型（行った業務の割合に応じて報酬を払う類型）で運用する整理をしています。FDE 型支援で「本番稼働をもって報酬」とする成果報酬型を組むことは可能ですが、成果の定義をめぐる争いを避けるためにこそ、以下の業務単位の検収条件が要ります。ここから先の契約類型の選択と条項の作成は、必ず弁護士に確認してください。この記事は法的助言ではありません。契約類型や責任の説明は、経産省・IPA のモデル契約書とその解説の記述を要約したもので、個別の契約でどう扱われるかは契約内容と事情によって変わります。条項として使う前に、必ず弁護士に確認してください。
検収条件は「業務単位」で書く。良い例と悪い例
従来の検収条件は機能の一覧でした。「請求書取込機能」「仕訳生成機能」「承認ワークフロー」がテスト仕様書どおりに動く、という書き方です。FDE 型ではこれを業務単位に書き換えます。型は「本番データで、担当者が、FDE の同席なしに、業務1サイクルを回せること」。この一文に、確認の場所（本番）、確認する人（担当者）、独立性（同席なし）、単位（1サイクル）の4要素が入っています。
| 悪い例（機能単位・環境不問） | 良い例（業務単位・本番・担当者・同席なし） | |
|---|---|---|
| 経理 AX | 請求書 OCR 機能、仕訳生成機能、承認機能がテスト仕様書どおり動作すること | 本番の当月分請求書を使い、経理担当者が FDE の同席なしに月次締めを1回完走し、締め後の残高が従来手順と一致すること。例外（読み取り不能、金額不一致）が出た場合は判断表に従って処理し、その記録が残っていること |
| 案件管理 | 案件登録画面、工程管理画面、請求書出力機能が要件どおり実装されていること | 実際に受注した案件1件について、営業担当者が登録し、工事担当者が工程を更新し、経理担当者が請求書を発行するまでを、FDE の同席なしに完了すること。3名とも権限表に記載された権限で操作すること |
| Claude 導入（問い合わせ対応） | 回答生成機能の精度が評価データで80%以上であること | 本番の問い合わせ1週間分（おおむね数十件）について、担当者が AI の下書きを確認して返信し、判断表の「そのまま送る／修正して送る／人が書き直す」の判定記録が全件残っていること。修正率が事前に合意した水準以下であること |
| kintone 導入 | アプリ5本とプラグイン3本が納品されていること | 月初から月末までの1か月、現場の担当者が日報を入力し、管理者が集計を取り出し、経営会議の資料に使うまでを社内だけで回せること。期間中に出た設定変更は⑤変更のやり方に沿って担当者自身が行ったこと |
悪い例が悪いのは、間違っているからではなく、確認しても「動かし方が渡ったか」が分からないからです。機能が全部動いていても、担当者が触れなければ FDE が帰った翌月に止まる。良い例は、機能の確認を含みつつ、担当者が自分で回せることまでを条件にしています。
書くときのコツを3つ挙げます。第一に、サイクルの終点を「業務上の事実」で書く。「締め後の残高が一致する」「請求書が発行される」「会議資料に使われる」のように、その業務の責任者が見て分かる事実にします。第二に、例外が出ることを前提にする。1サイクル回して例外が1件も出ない業務はまずないので、「例外が出ないこと」ではなく「例外が判断表で処理できること」を条件にします。第三に、人を名指しにする。「担当者が」ではなく「経理部の月次担当者（Echo 役）が」と役割を書き、検収書に実名を入れます。
検収の1サイクルをどう回すか。3つの条件の意味
「本番データ・担当者・同席なし」の3条件は、どれか1つを緩めると検収の意味がなくなります。それぞれ、なぜその条件なのかを書いておきます。
本番データで
テストデータは、作った人が想定した範囲しか含みません。本番データには、桁の違う金額、全角と半角が混じった取引先名、期の途中で変わった勘定科目、前任者が例外的に手入力した行が入っている。動かし方の②判断表が本当に使えるかは、本番データを流して初めて分かります。本番データを検収に使う以上、データの取り扱い（誰が見られるか、FDE 側に残さないか、終了時の削除）を先に決める必要があり、これは③権限表と④データの持ち主一覧に書くことになります。
担当者が
FDE が操作して動くことは、FDE がいれば動くことしか証明しません。検収で操作するのは、翌月からその業務を回す人。ここで大事なのは、担当者が「操作できる」だけでなく「判断できる」ことまで見ることで、判断表に載っていない例外に出会ったとき、その人が「これは上げる」「これは自分で決める」と切り分けられるかを見ます。切り分けられなければ、判断表に行を足して次のサイクルでもう一度回します。
FDE の同席なしに
同席していると、担当者は詰まった瞬間に FDE を見ます。それでは検収になりません。同席なしとは、FDE がその場にいない状態で1サイクルを完走すること。質問は禁止せず、記録する。「何に詰まり、何を聞いたか」が⑥引き継ぎ記録になり、質問がゼロになったサイクルが本当の合格です。当社の経験では、月次業務なら伴走2〜3回、同席なし1〜2回で質問が収束する例が多く、それより長引くなら仕組みか判断表のどちらかに設計上の問題があります。
回数について1点。検収は1サイクルで終えるのが原則ですが、月次業務で「同席なしの1回」を待つと契約期間が延びる。実務では、契約上の検収は「同席なし1サイクル完走」とし、その前の伴走サイクルを準委任の実施業務報告として毎月確認する、という2層にすると期間と確認の両方が収まります。エンタープライズ AI 導入のスケール4段階でいう「業務にする」段階の確認を、月ごとの報告確認で刻む形です。
検収書のひな型
以下は、FDE 型支援の検収に使える確認項目の一覧です。ひな型は自社で作成したもので、経産省・IPA のモデル契約書に含まれる様式ではありません。モデル契約書の「業務終了報告書」「業務終了確認書」に、この項目を追記して使うことを想定しています。実際の契約書に組み込む際は、弁護士の確認を受けてください。
| 項目 | 記入内容 | 記入例 |
|---|---|---|
| 対象業務 | 検収の単位となる業務サイクルを1つ。複数あれば1業務1枚 | 月次締め（請求書受領から仕訳承認・残高確認まで） |
| 確認者（Echo 役） | 実際に操作した担当者の氏名・所属と、業務責任者の氏名 | 経理部 〇〇（実施）、経理部長 〇〇（責任者） |
| 確認日 | サイクルの開始日と完了日 | 2026年〇月1日〜〇月7日 |
| 本番データでの実施 | 本番データを使ったか。使わなかった範囲があればその理由 | 当月分の請求書 143 件。うち3件は個人情報を含むため責任者が実施 |
| FDE の同席なしでの実施 | FDE が同席・遠隔で関与したか。質問した回数と内容 | 同席なし。チャットでの質問2件（内容は引き継ぎ記録 No.14, 15） |
| 例外時の判断表の有無と適用 | 判断表が存在するか。サイクル中に出た例外の件数と、判断表で処理できた件数 | 判断表あり（18 行）。例外7件、うち判断表で処理6件、追記1件（不一致額が1円未満の場合） |
| 権限表・データの持ち主一覧の有無 | 最新版の日付と、確認者が自分の権限で操作したか | 権限表 〇月〇日版。管理者権限は使用せず |
| 変更のやり方の確認 | サイクル中に担当者自身が行った設定変更の有無と内容 | 取引先マスタ1件追加（手順書 §3 に沿って実施） |
| 引き継ぎ記録の有無 | FDE から Echo 役への引き継ぎ記録の最終更新日と件数 | 記録あり（15 件、最終 〇月〇日） |
| 未完了事項と期限 | 合格条件に届かなかった項目、対応者、期限 | 判断表への追記1件を〇月〇日までに FDE が反映、次回サイクルで確認 |
| 判定 | 合格／条件付き合格／不合格。条件付きの場合は条件と再確認日 | 条件付き合格（上記1件の反映をもって合格） |
「未完了事項と期限」の欄を空欄で通さないことが、この表を使う唯一のルールです。1サイクル回して未完了がゼロになることはまずなく、ゼロと書かれた検収書は確認が甘い証拠と見たほうがよい。未完了を書いたうえで、それが業務を止めるものかどうかを責任者が判定し、止めないなら条件付き合格として次のサイクルに送ります。
もう1点、この検収書は FDE 側が書くものではなく、発注側が書くもの。書き手が発注側になることで、「渡した」ではなく「受け取った」の記録になります。準委任の業務終了報告書は受託者が書く建て付けなので、それと対になる「受領側の確認記録」として位置づけると、モデル契約書の手続に自然に収まります。
契約書に落とすときの実務ポイント
ここまでの内容を契約に反映するとき、当社が発注側と一緒に詰めてきた論点を4つ挙げます。いずれも最終的には弁護士の確認を経てください。
| 論点 | 決めること | 決めないと起きること |
|---|---|---|
| 確認の対象 | 業務終了報告書の確認対象に、検収書の項目（本番データ・担当者・同席なし・判断表・引き継ぎ記録）を明記する | 報告書を読んで異議なし、で確認が終わる。動かし方が渡ったかを誰も見ない |
| 点検期間 | 1サイクルを回すのに必要な日数を点検期間にする。月次業務なら1か月＋数日 | モデル契約書の点検期間を短く設定し、サイクルを回す前にみなし確認が成立する |
| 動かし方6点の納入 | ①〜⑥を成果物一覧に載せ、それぞれの完成の定義（判断表なら「サイクル中の例外を全件処理できること」）を書く | 「ドキュメント一式」とだけ書かれ、厚い設計書が出てきて判断表がない |
| 未完了事項の扱い | 条件付き合格を認める。未完了の対応が FDE 側の業務に含まれるか、追加契約かを線引きする | 未完了1件を理由に検収全体が止まり、支払いも引き継ぎも宙に浮く |
契約類型については、準委任の履行割合型（月額）を基本にし、「同席なし1サイクル完走」をもって最終の業務終了確認とする形が、当社が見てきた範囲では最も争いが少ない。成果報酬型を使うなら、成果の定義に上の検収書の項目をそのまま使えますが、成果が出ない場合の報酬の扱い（モデル契約書の解説では、改正民法上は請負の規定が準用されると説明されています）を弁護士と詰めておくのが安全です。
もう1つ、発注側の協力義務について。モデル契約書は、システム開発をユーザとベンダの共同作業と位置づけ、ユーザが社内の意見を調整し、機能を決め、検収を行う役割を分担する必要があると述べています。FDE 型ではこの分担がさらに重くなります。本番データを出す、担当者の時間を確保する、Echo 役を決める。これらは発注側の仕事で、契約書にも発注側の義務として書いておくと、後で「担当者の時間が取れず検収が延びた」ときの整理が楽になります。
当社が伴走してきた経験から
当社は経理 AX、kintone、案件管理システムの刷新、Claude 導入で、本番稼働まで伴走する形の支援を行ってきました。その中で、検収の書き方を変えたことで結果が変わった例を、一般化して2つ書きます。
設備投資型の事業を営む中堅企業（従業員100〜300人）の案件管理システム刷新では、当初の検収条件が「画面・帳票の一覧が要件どおり」でした。これを「実際の案件1件を、営業・工事・経理の担当者が登録から請求まで社内だけで通す」に書き換えたところ、通す過程で判断表に載っていない例外が十数件見つかり、稼働前に判断表へ反映できました。以前の条件のままなら、この十数件は稼働後に電話で聞かれていたはずです。
経理の AI 化では、本番の1か月分をテストデータ代わりに使うことに最初は抵抗がありました。個人情報を含む行の扱いを権限表で決め、責任者だけが扱う運用にして進めたところ、テストデータでは出なかった「同じ取引先の表記ゆれ」が本番データで数十件出ました。判断表に「表記ゆれはマスタに寄せる、寄せられないものは人が判断」の行を足し、その後の月次は担当者だけで回っています。動かし方の②判断表と④データの持ち主一覧が、検収の段階で埋まった例です。
2つに共通するのは、検収を「合否の判定」ではなく「動かし方を埋める最後の工程」として使ったことです。この使い方をすると、FDE 側にとっても検収は怖い工程ではなく、帰る前に穴を見つける工程に変わる。AI 導入の本当の難しさで書いた「フロー管理の壁」は、検収の場で最後に一度、正面から向き合うことになります。
まとめ
FDE 型支援の成果物は「本番で動いている仕組み」と「動かし方」の2つで、動かし方は運用手順・例外時の判断表・権限表・データの持ち主一覧・変更のやり方・Echo 役への引き継ぎ記録の6点に分けて受け取ります。契約類型は準委任で組まれることが多く、経産省・IPA のモデル契約書の整理では準委任に請負型の「検収」の手続はなく、業務終了報告書の確認がそれに当たると読める。確認の中身を契約で決めておかないと、確認は形式に流れます。
検収条件は機能の一覧ではなく「本番データで、担当者が、FDE の同席なしに、業務1サイクルを回せること」と業務単位で書く。検収書は発注側が書き、未完了事項の欄を空欄にしない。この2つを守れば、FDE が帰った翌月に業務が止まる確率は大きく下がります。契約条項の最終確認は弁護士に依頼してください。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
「動かし方まで渡す」ことを検収条件にする AI 導入支援
はてなベースでは、経理 AX・kintone・案件管理システムの刷新・Claude 導入で、本番稼働と動かし方の引き継ぎまでを成果物とする支援を行っています。検収条件の書き方、Echo 役の決め方、判断表・権限表の作り方から、社内で回る状態までを一緒に作ります。「FDE 型の支援を契約書にどう書けばよいか分からない」という段階からご相談ください。