「FDE（Forward Deployed Engineer）型でお願いしたい。ところで、うちは何を用意すればいいのか」。FDE を発注する側の経営者・情シス責任者・部門長から、契約の話が固まったあとに必ず出る問いです。技術は FDE が持ってきます。データも既存システムも、すでに社内にある。足りないのは、判断を出す人と、判断を出す場です。これが決まっていない会社では、FDE が着任しても、最初の2週間は「誰に聞けばいいか」を探すことに使われます。
この記事は、FDE 型の支援を受け入れる側の体制と会議体だけを扱います。着任1週間で FDE が何をするかは前の記事に書いたので、そちらに譲る。ここで答えるのは3つ。経営・現場・情シスの3者がそれぞれ何をやり、何をやらなくてよく、どこで失敗しやすいか。社内で業務と仕組みを引き継ぐ Echo 役（FDE の相方）を誰にして、週に何時間を確保し、その上司にどう了解を取るか。そして日次15分・週次30〜60分・月次の3つの会議で何を決め、誰が出て、どう記録するか。AWS・Palantir・IPA の一次資料にある「発注側の役割」の記述と、当社が経理 AX・kintone・案件管理システムの刷新・Claude 導入で本番稼働まで伴走した経験を一般化して書いています。
FDE を受け入れる側が用意するのは、人と場の2つ。人は、決裁と優先順位を出す経営、業務の実態と日次の判断を出す現場、データの持ち主・権限・監査要件を出す情シスの3者と、その真ん中で業務と仕組みを引き継ぐ Echo 役。場は、日次15分（今日直したこと・明日見せるもの・決めてほしいこと）、週次30〜60分（判断者が出て論点一覧を消化する）、月次（経営への報告と方向修正）の3つ。先方確認が必要な論点は「論点・判断者・期限・結論」の4列で一覧にし、期限を過ぎた論点を週次で必ず読み上げる。
この記事の要約
受け入れ側が用意するのは「人と場」——3者と Echo 役の体制
ハブ記事で整理した FDE の型を、この記事では4つに分けて書くと、「顧客の業務の中に入る」「動くものを先に出す」「判断を顧客と一緒に決める」「本番まで持っていき、動かし方も渡す」になります。このうち受け入れ側の体制に直接かかるのは3つ目の「判断を一緒に決める」と4つ目の「動かし方を渡す」です。判断を出す人がいなければ FDE は動くものを見せた翌日に止まり、動かし方を受け取る人がいなければ FDE が帰った月に仕組みが止まる。体制づくりとは、この2種類の人を決めることに尽きます。
受け入れ側は3者に分かれます。決裁と優先順位を持つ経営。業務の実態を知っていて日次の判断を出せる現場。データの持ち主・権限・監査要件と既存システムを握る情シス。中堅企業では、この3者が同じ会議に揃うことがまずありません。経営は月に1回、情シスは要望があったときだけ、現場は FDE が席まで来たときだけ。FDE 型の支援では、この3者を毎週同じ論点で結ぶ必要があり、その結び目が Echo 役です。
3者それぞれの「やること」「やらなくてよいこと」「よくある失敗」を先に表にします。この表の右2列が、この記事で最も伝えたい部分です。受け入れ側は、やることを増やしすぎて失敗する。要件定義書を書こうとする経営、画面設計に口を出す情シス、全部の例外を洗い出そうとする現場。どれも善意ですが、FDE 型の進め方では待ち時間を増やすだけです。
| やること | やらなくてよいこと | よくある失敗 | |
|---|---|---|---|
| 経営（社長・担当役員・部門長） | 対象業務の優先順位を決める。月次で方向を修正する。二重入力を終わらせる日と、旧システムを止める日を決裁する。Echo 役の任命を本人と上司に伝える | 要件定義書を書く。画面や帳票のデザインを決める。日次の会議に出る | 「現場に任せた」と言って週次に出ない。週次に出ないまま月次で「聞いていない」と差し戻す。PoC の延長を3回続ける |
| 現場（実務者・係長・課長） | 業務の実態を見せる。例外を、起きたその日に申告する。動くものを触って「ここが違う」を言う。日次15分で今日の判断を出す | 業務フローを整理した資料を作る。全部の例外を事前に洗い出す。仕様書を読む | 「忙しいので来週まとめて」と判断を溜める。旧帳票を全部そのまま移そうとする。最も詳しい人が1人で抱えて休めなくなる |
| 情シス（システム担当・ベンダー窓口） | データの持ち主・権限・監査要件を着任前に一覧で出す。既存システムの ID・接続・ログを出す。動かし方の引き継ぎ先として運用手順を受け取る | 業務の判断をする。FDE の作業の承認者になる。画面の作り方を指定する | 「セキュリティ確認が終わるまで ID を出さない」で2週間止める。要件を情シス経由で集約する。作った後に監査要件を出す |
表の「やらなくてよいこと」は、従来の受託開発なら発注側の仕事だった項目が並びます。要件定義書、業務フロー図、仕様の承認。FDE 型ではこれらを FDE が動くものと一緒に作るので、受け入れ側が先回りして書くと、かえって二重の手戻りになる。要件を情シス経由でまとめない理由は前の記事に書いたとおりで、部署ごとに現場に聞いたほうが速く、正確です。
一次資料が示す「発注側の役割」——AWS・Palantir・IPA
受け入れ側の体制について、FDE を送り出す側と、日本の契約実務の側の双方が、公開資料で同じことを書いています。3つを引きます。
AWS は2026年6月30日の発表で、FDE が顧客の「事業・エンジニアリング・セキュリティの各チーム」と組んで、顧客のデータ・ガバナンス・手順の中で本番の AI システムを構築すると書いています。同じ発表の中で、案件が進むにつれて顧客側のエンジニアが「観察者から共同開発者へ、そして自律的な運用者へ」移っていくこと、顧客に残るものとして、稼働するシステムに加えて手順書・構成の説明資料・「社内で運用を引き継ぐ担当者（trained internal champions）」を挙げている。当社の整理に引き寄せれば、この事業・エンジニアリング・セキュリティの3チームは、この記事の経営と現場・情シスに対応させて読めます。受け入れ側にこの3者がいないと、AWS の言う「観察者から運用者へ」の移行が起きる場所がありません。
Palantir の公式ブログ（2022年3月）は、FDE（社内呼称 Delta）と組む Deployment Strategist（社内呼称 Echo）の仕事として、顧客の業務を理解して効果の大きい箇所を見つけること、ユーザーと素早く繰り返して解決策を合わせること、顧客との関係と案件の進行を管理すること、顧客の経営層に対して Palantir を代表することを挙げています。つまり Palantir は、FDE と組む Echo という役を自社側に置いている。当社はこの Echo を顧客側に置き換えて「Echo 役」と呼んでいます。理由はハブ記事に書いたとおりで、中堅企業の AI 導入で仕組みが定着するかどうかは、FDE が帰った後に社内で誰が回すかで決まるからです。
契約の側から同じ役を定義しているのが IPA（情報処理推進機構）が2020年3月に公開した「情報システム・モデル取引・契約書（アジャイル開発版）」です。契約と法律に触れる話なので先に断っておくと、ここに書く内容は IPA の解説文の整理であり、個別の契約内容と事情で扱いは変わります。契約書に落とす前に弁護士に確認してください。そのうえで読むと、このモデル契約の解説では、発注側（甲）が業務を開始する前に「プロダクトオーナー」を選任し、その人に、開発対象のビジョンを示すこと、要求事項の一覧（プロダクトバックログ）の作成と優先順位の変更、会議への出席、利害関係者からのフィードバックの提供、要求事項ごとの完了確認、必要な情報提供と意思決定を適時に行うこと、社内の利害関係者との調整、という役割を担わせる建て付けになっている、と整理されています。
同じ解説文には、発注側にアジャイル開発の経験がなく、この役を全うできる人員がいない場合はベンダー側に補佐を出してもらうこともあり得るが、それでも「プロダクトに対して責任を持つプロダクトオーナーの職務自体をベンダ側に委ねるべきでない」という趣旨の記述があります。契約前チェックリストにも「適切なプロダクトオーナーを選任し、権限委譲ができるか」「ユーザ企業としてプロダクトオーナーへの協力ができるか」という項目が置かれている。FDE を送り出す AWS も、日本の契約実務も、受け入れ側に「判断する人」を置け、と言っている。当社が Echo 役と呼んでいるのは、この人です。
経営の役割——決裁と優先順位を「週次で」出す
経営がやることは3つに絞れます。対象業務の優先順位を決める。月次で方向を修正する。そして「やめる日」を決裁する。3つ目が一番忘れられます。二重入力をいつ終わらせるか、旧システムをいつ止めるか、PoC をいつ本番に切り替えるか。これらは現場も情シスも決められない。決められるのは、業務が一時的に乱れる責任を引き受けられる人だけです。
優先順位については、経営が出すのは「順番」であって「要件」ではありません。当社が伴走した一例では、設備投資型の事業を営む中堅企業（従業員100〜300人）の案件管理システム刷新で8つの部署に順に入った際、経営に決めてもらったのは「どの部署から入るか」と「どの帳票を最初に止めるか」だけでした。画面の項目や承認の段数は、現場と Echo 役が日次で決める。経営が項目まで決めようとすると、週次の会議が要件定義の会議に変わり、判断が月単位で遅れます。
経営の失敗で最も多いのは、「現場に任せた」と言って週次の会議に出ないことです。週次に出ないと、論点一覧の中で経営しか決められない項目が溜まる。溜まったまま月次を迎えると、経営は初めて聞く話として差し戻す。この差し戻しが2回起きると、FDE 型の支援は PoC と同じ止まり方をします。当社が伴走した案件で分かれ目になったのは、この「経営が週次に顔を出すかどうか」でした。経営判断の論点がある週は、30分でよいので判断者として出る。それが経営の最大の役割です。PoC で止まる会社と動かせた会社で書いた PoC の分かれ目も、判断の場の有無という点で同じ構図です。
現場の役割——業務の実態と、日次の判断
現場がやることは、業務の実態を見せることと、日次の判断を出すことです。資料は要りません。FDE が隣に座って画面と帳票を見る。そのときに「これは月末だけ」「この列は実は使っていない」と言ってもらえれば足ります。動くものが出てきたら、触って「ここが違う」と言う。これも文書にしなくてよく、日次15分の場で口頭で伝え、Echo 役が記録します。
日次の判断とは、たとえば「この例外は AI に任せてよいか、人が見るか」「この項目は必須にするか」「この承認段階を残すか」のような、その日に出てきた小さな分岐です。現場が判断を溜めると FDE の作業が止まり、翌日見せるものが減り、現場の関心も薄れる。逆に、日次で判断が出る部署では、動くものが毎日変わるので現場が自分たちの仕組みだと感じるようになる。当社が伴走した一例では、8つの部署に入った案件管理システムの刷新で、日次15分で判断を積んだ部署とまとめて週1回にした部署の間に、本番移行までの期間で数週間の差が出ました。
現場側の失敗は、最も詳しい人が1人で抱えることです。その人が休むと判断が止まり、その人が異動すると動かし方が失われる。対策は、各部署に「見せる相手」を1人ではなく主担当と副担当の2人置くことと、判断の記録を Echo 役が一元的に持つことです。もう1つの失敗は、旧帳票を全部そのまま移そうとすること。当社が伴走した一例では、使われていない帳票を移す工数が全体の半分近くに達しました。「作らない」候補を出すのは現場にしかできない判断で、これも日次で決めます。
情シスの役割——データの持ち主・権限・監査要件を最初に出す
情シスがやることは、FDE が着任する前に3つの一覧を出すことです。データの持ち主（どのマスタを誰が直せるか）、権限（誰が何を見られるか、外部に見せてよい範囲）、監査要件（誰がいつ何をしたかの記録をどこまで残すか、保存期間、既存の監査法人や親会社からの要求）。この3つを最初に出してもらう理由は、後から出ると作り直しになるからです。権限と記録の設計は仕組みの土台に入るため、動くものができた後に「実は全操作ログが要る」と言われると、画面より下を組み直すことになる。
PoC→本番と契約の記事で「後出しの権限・監査要件」を PoC が本番に乗らない7つの原因の1つに挙げました。後出しになるのは情シスが怠けているからではなく、誰も最初に聞かないからです。受け入れ側の体制として、着任前の情シスの仕事を「3つの一覧を出す」と決めておけば、後出しは起きません。一覧は完璧でなくてよく、「分からない」と書いた行があるほうが役に立つ。分からない行が、週次で決める論点になります。
情シスの2つ目の仕事は、既存システムとの二重入力をいつ終わらせるかの判断材料を出すことです。新しい仕組みが動き始めても、旧システムへの入力が残っている間は、現場の負担は増えたままです。終わらせる日を決めるのは経営ですが、その判断に必要な材料、つまり旧システムから他の何が参照しているか、止めた場合に誰の何が困るか、データを移す方法があるか、は情シスにしか出せません。当社は、二重入力の終了日を「新しい仕組みで1か月分の締めが問題なく回った日の翌月初」を目安に、情シスと Echo 役が週次で提案し、経営が月次で決裁する形にしています。
情シスの失敗は2つあります。1つは、セキュリティ確認を理由に ID の発行を止めること。閲覧のみの ID なら初日に、書き込みの ID は権限一覧が確定した週に、と段階を分ければ止めずに済みます。もう1つは、要件を情シス経由で集約しようとすること。情シスが業務の判断を代行すると、「この承認段階を減らしてよいか」で必ず詰まる。情シスは判断者ではなく、データ・権限・既存システムの持ち主として並走する。この線引きを最初に3者で確認しておくと、情シスの「勝手に作られる」懸念（後述）も同時に小さくなります。
Echo 役——選び方、週の時間、上司の了解
Echo 役の条件は前の記事に書いた3つです。その業務を実際に知っている。判断を上に通せる。週の一定時間を確保できる。ここでは重複を避け、体制の観点から「時間」と「上司の了解」を書きます。
週に何時間かかるか。IPA のモデル契約の解説に付いている体制表の例では、発注側のプロダクトオーナーは「営業部門経験が2年以上あり業務に精通し、経営幹部と週に1回以上直接コミュニケーションを取れる立場」で、稼働は 1.0 FTE（フルタイム換算で1人分）とされています。同じ解説の事例集には、見積り条件として「要件を決定できる人材をプロダクトオーナーとして専任もしくは週20時間以上稼働」と書く工夫が紹介されている。専任か、少なくとも週20時間。IPA の資料に出てくる水準はこの程度です。
ただ、従業員100〜300人の中堅企業で業務側の管理職を専任にするのは現実的ではありません。当社の目安は、日次15分が5回で約1時間15分、週次が1時間、論点一覧の整理と社内の根回しに2〜3時間、合わせて週4〜5時間程度です。着任からの2〜4週間は現場に一緒に入る時間が要るので、週8〜10時間を見ておく。本番移行の前後2週間も同じくらいに戻ります。この時間は、Echo 役の通常業務からそのまま引かれる。ここを曖昧にしたまま任命すると、Echo 役は日次15分に出られなくなり、判断が止まります。
だから上司の了解が要ります。了解の取り方は、経営から Echo 役の上司へ、次の3点を文書で伝えてもらうのが確実です。Echo 役の氏名と期間。週の時間の目安（上の数字）。その分の通常業務を誰が引き取るか、または後回しにしてよいか。3つ目が抜けると、上司は「了解した」と言いながら通常業務を減らさず、Echo 役だけが残業で吸収することになる。8つの部署に入った案件では、Echo 役を務めた業務側の管理職に対し、期間中は定例の一部を副担当に委ねる旨を経営から部門に伝えてもらいました。この一手があるかないかで、日次15分の出席率が変わります。
Echo 役に向かない人は、いちばん忙しい人と、詳しいが権限のない人です。前者は出られず、後者は通せない。どちらも該当する場合は、「詳しい担当者」と「判断を通せる管理職」の2人組にし、日次は担当者、週次は管理職、と分けます。2人組にしたときの注意点はひとつで、論点一覧の記録者を1人に固定すること。記録が2人に分かれると、聞き忘れが起きます。
会議体の設計——日次15分・週次30〜60分・月次
会議は3つだけです。日次15分、週次30〜60分、月次30分。どれも「会議のための資料」を作りません。記録は論点一覧と、週次・月次の1枚だけ。この3つに絞る理由は、受け入れ側の負担を週4〜5時間程度に収めるためと、判断の階層を明確にするためです。日次で決められないものが週次に上がり、週次で決められないものだけが月次に上がる。逆に、月次で初めて出る論点があってはいけない。
日次15分は、FDE と Echo 役と、その日に関わる現場の担当者が出ます。決めるのは3つ。今日直したこと、明日見せるもの、決めてほしいこと。3つ目で出た「決めてほしいこと」のうち、その場で現場が決められるものはその場で決め、決められないものは論点一覧に判断者と期限を付けて追記する。これだけです。立って話すか、オンラインならカメラを付けずに15分で切る。記録は Echo 役が論点一覧に書き、議事録は作りません。
週次30〜60分は、判断者が出る会議です。部門長、情シス責任者、そして経営判断の論点がある週は経営。ここで論点一覧のうち期限が来たものを上から順に読み上げ、結論を出す。決められない論点は、誰が何を確認すれば決められるかを決め、期限を引き直す。あわせて翌週の優先順位と、「作らない」候補の確定を行います。記録は論点一覧の結論欄と、週次1枚（決まったこと・未決の論点・翌週の予定）。この1枚は経営と情シスに送り、月次の材料にもなります。
月次30分は、経営への報告と方向修正の場です。出るのは経営・Echo 役・FDE・情シス責任者。決めるのは、対象業務の順番を変えるか、二重入力の終了日、旧システムの停止日、次の対象業務。報告は週次1枚を4枚並べたものと、実測値（処理件数・所要時間・例外件数）で足ります。月次で初めて経営が論点を聞く状態になっていたら、週次に経営が出ていない証拠なので、週次の出席者を見直します。
| 会議 | 頻度・長さ | 出る人 | 決めること（議題） | 記録 |
|---|---|---|---|---|
| 日次 | 毎日15分 | FDE、Echo 役、その日の現場担当 | ①今日直したこと ②明日見せるもの ③決めてほしいこと（現場が決められるものはその場で。残りは論点一覧へ） | 論点一覧への追記のみ。議事録なし |
| 週次 | 週1回30〜60分 | 上記＋部門長・情シス責任者（判断者）。経営判断の論点がある週は経営 | ①期限が来た論点の結論 ②決められない論点の確認先と期限の引き直し ③翌週の優先順位 ④作らない候補の確定 ⑤実測値の確認 | 論点一覧の結論欄、週次1枚（決まったこと・未決・翌週予定） |
| 月次 | 月1回30分 | 経営、Echo 役、FDE、情シス責任者 | ①対象業務の順番の見直し ②二重入力の終了日 ③旧システムの停止日 ④次の対象業務 ⑤Echo 役の稼働の見直し | 月次報告1枚（週次4枚の要約＋実測値） |
この会議体は、FDE が本社に戻っている日や、案件の後半で FDE が抜けた後も、Echo 役が同じ型で回すためのものです。成果物と検収の記事で「動かし方」を成果物に含めると書きましたが、動かし方の中には、この3つの会議をどう回すかも入ります。FDE が抜けた後に日次15分が続いているかどうかが、定着の最も分かりやすい指標です。
「先方確認が必要な論点」を4列で管理する
FDE 型の支援で最も多い停滞は、技術ではなく「聞き忘れ」です。現場で出た疑問を FDE が持ち帰り、判断者に届く前に忘れられる。判断者が「後で」と言ったまま期限がない。決まったはずの結論が記録されておらず、翌月に同じ議論を繰り返す。これを防ぐ道具が論点一覧で、列は4つだけにします。論点、判断者、期限、結論。
| 列 | 書き方 | 書き方の例 |
|---|---|---|
| 論点 | 何を決めるかを疑問文で1行。「〜してよいか」「〜はどちらか」の形にする | 承認段階を2段から1段に減らしてよいか |
| 判断者 | 役職ではなく氏名。決められない場合の上申先も併記 | 〇〇部長（決められない場合は△△役員） |
| 期限 | 次の週次の日付を初期値にする。延ばすときは理由を結論欄に書く | 9月12日（週次） |
| 結論 | 決まった内容と、決まった日と場。「保留」の場合は何が分かれば決められるかを書く | 9月12日週次で「1段に減らす。ただし金額が〇〇以上は従来どおり」 |
運用のルールは3つです。追記は日次15分の場で Echo 役がその場で行う。週次では期限が来た論点を上から全部読み上げる（読み上げないと、判断者が気づかない）。結論が出た論点は消さずに残す。3つ目は、翌月に「そんな話は聞いていない」が出たときに、日付と場を示して終わらせるためです。
聞き忘れが起きる典型パターンは決まっています。FDE が現場で聞いた疑問を、判断者に聞く前に自分で「たぶんこうだろう」と決めてしまう。判断者が口頭で答え、記録されないまま担当者が変わる。論点が「〜について」という名詞で書かれていて、何を決めればよいか分からず放置される。判断者が「関係部署に聞いてから」と言い、その関係部署が一覧に載っていない。期限が「なるべく早く」になっている。5つとも、4列の書き方を守れば防げます。とくに論点を疑問文で書くルールは、書く側に「何を決めてほしいのか」を考えさせるので効果が大きい。
論点一覧の置き場所は、受け入れ側が普段使っている道具に合わせます。表計算でも、kintone のアプリでも、社内の課題管理ツールでも構いません。条件は、判断者が自分でも開けること、期限順に並べ替えられること、結論が消えないこと。FDE 側の道具に置くと、FDE が抜けた後に一覧ごと消えます。受け入れ側の道具に置くのは、動かし方を渡すための準備でもあります。
反対や不安にどう答えるか——現場・情シス・経営
体制を作るとき、3者それぞれから決まった反応が返ってきます。現場の「仕事がなくなるのではないか」、情シスの「勝手に作られるのではないか」、経営の「PoC で十分ではないか」。3つとも正当な懸念で、言葉で説得するより、体制と会議体の設計で答えたほうが早い。
現場の「仕事がなくなる」
答えは、日次15分の出席者を現場にすることです。何を AI に任せ、何を人が見るかを決めるのは現場であり、その決定は日次で現場が出す。「作らない」候補を出すのも現場です。仕組みを作る側に現場を置くと、仕事がなくなる不安は「自分たちの仕事のうち、どこを手放すか」を自分で決める作業に変わります。当社が伴走した一例では、案件管理システムの刷新で入った8つの部署のうち、最初に反発が強かった部署ほど、日次15分に出始めてからの判断の量が多く、本番移行も早かった。不安の正体は多くの場合「自分の知らないところで決まること」で、決める場に入ればそれは消えます。
情シスの「勝手に作られる」
答えは、着任前に情シスが出す3つの一覧（データの持ち主・権限・監査要件）を、仕組みの設計の前提にすることです。この一覧に書かれた範囲の外で FDE が作ることはない、と3者で確認する。加えて、週次に情シス責任者が判断者として出る。FDE が作ったものの中身（構成・ログ・権限の実装）は、週次で情シスが確認できる状態にし、本番移行の前に運用手順を情シスに渡す。「勝手に」の対義語は「一覧に沿って、週次で見せながら」です。情シスの人数が1〜2人の会社では、週次の出席そのものが負担になるので、隔週にして論点一覧の情シス分だけを事前に送る運用にすることもあります。
経営の「PoC で十分では」
答えは、PoC と FDE 型の違いを「成果物」で示すことです。PoC の成果物は「できそうだと分かった報告」で、FDE 型の成果物は「本番で動いている仕組みと、動かし方」。前者は3か月後に判断材料が増えているだけで、後者は3か月後に業務が変わっている。PoC→本番と契約の記事に書いたとおり、PoC が本番に乗らない原因は精度ではなく、判断者・データの持ち主・運用担当が決まっていないことにあります。この3つは、まさにこの記事で作る体制そのものです。PoC で十分かどうかは、PoC の後に体制を作る気があるかどうかで決まる。作る気があるなら、最初から作って FDE 型で進めたほうが、PoC の期間分だけ早い。
経営への説明でもう1つ効くのは、時間の見積もりを出すことです。Echo 役が週4〜5時間程度、経営が論点のある週に30分と月30分、情シスが着任前の一覧作成に数日と週次30分。この数字を先に出すと、「体制を作る」が「人を何人か張り付ける」話ではないと伝わります。AI 導入の本当の難しさで書いた「フロー管理の壁」は、人数ではなく、判断の場があるかどうかの問題です。
まとめ
FDE を受け入れる側が用意するのは、技術でも要件定義書でもなく、人と場です。人は、決裁と優先順位を出す経営、業務の実態と日次の判断を出す現場、データの持ち主・権限・監査要件を出す情シスの3者と、その真ん中で業務と仕組みを引き継ぐ Echo 役。場は、日次15分、週次30〜60分、月次30分の3つの会議と、論点・判断者・期限・結論の4列で管理する論点一覧。AWS は顧客側の3チームと「社内で運用を引き継ぐ担当者」を、IPA のモデル契約の解説は発注側が選任するプロダクトオーナーを、それぞれ受け入れ側の役割として書いています。Palantir が自社側に置いている Echo を、当社は顧客側に置き換えた形です。
体制づくりで最初に決めるのは Echo 役と、その週4〜5時間程度を上司が了解することです。次に、情シスに3つの一覧を着任前に出してもらう。そして経営判断の論点がある週は経営が週次に30分出る。この3つが揃えば、FDE は着任初日から判断を積み始められ、抜けた後も Echo 役が同じ型で回せます。揃わないまま着任させると、FDE は最初の2週間を「誰に聞けばいいか」に使い、PoC と同じ場所で止まる。体制は契約書より先に決めてください。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
FDE を受け入れる体制と会議体の設計を、着任前に一緒に作ります
経営・現場・情シスの役割分担、Echo 役の選定と時間の確保、日次・週次・月次の会議体、論点一覧の運用を、貴社の組織と既存システムに合わせて設計します。経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験をもとに、着任前の準備から本番移行後の引き継ぎまでご相談いただけます。