FDEの1週間｜初日にコードを出し、金曜に製品へ返すまでの実装プロセス

こんにちは、株式会社TIMEWELLの濱本です。

FDE実践シリーズの7本目です。ここまでの6本で、聞く、見る、いる、構造にする、撮って数える、辞書を機械に渡すという技術を書きました。今回は、これらを一週間の中にどう配置しているかを書きます。

当社は、FDEスタイルで最速の実装ができると言っています。この言い方には、正直に言えば、誤解を生む余地があります。エンジニアの手が速い、という意味ではありません。聞いて、作って、反応を取って、製品に返す往復が、一週間に収まっている、という意味です。この記事は、その一週間を月曜から金曜まで書き、受託開発の工程と何が違うのか、そして一週間で本番に載らないものは何かを、隠さずに書きます。自社のチームがこの往復をどこまで回せるかを先に確かめたい方は、AIリテラシー診断を使ってください。

前提。速さの正体は、手の速さではなく往復の短さ

最初に、速さの正体を書きます。

Palantirで8年間FDEを務めた人物は、20代の小さなチームが顧客の現場に現れ、1〜2週間で人が使える本物のソフトウェアを作ったとき、顧客の側が驚いた、と書いています。相手にしていた既存のシステム導入業者が、年単位のウォーターフォールで動いていたからです¹。AWSが2026年6月に立ち上げたFDE組織は、展開を月単位から日単位に圧縮することを掲げています²。OpenAIが5月に立ち上げた実装専門会社は、典型的な進め方を、価値の診断、経営と現場で選ぶ少数の優先ワークフロー、組織の中での設計と構築と展開、と説明しています³。共通しているのは、要件が固まるのを待たず、動くものを早く置き、置いた後に学ぶ、という順番です。

当社の速さには、もう一つ理由があります。小さな会社であることです。大手のFDE組織では、現場で聞く人、作る人、製品に返す人が分かれます。当社では同じ人です。金曜に現場で見つけた例外を、その人が翌週の月曜に作り、その週の金曜に製品の標準機能にするかを判断します。人が分かれていれば会議で伝える内容が、同じ人の中で完結します。

そして、コーディングエージェントの存在です。以前は、初日にコードを出せるのは腕のあるエンジニアだけでした。いまは、名詞と動詞を渡せば、数時間で仮の画面が出ます。ただし、ここに落とし穴があります。抽象化と具象化の記事で書いたとおり、コードを書く速さが上がっても、価値の上がり方はそれより小さいという調査があります。速く書けることと、正しいものを書けることは別です。FDEの一週間は、正しいものを見つけるために往復を短くする設計で、速く書くための設計ではありません。

月曜。三層に聞き、データの持ち主を特定し、夕方に初版を置く

月曜の午前は、聞く日です。経営、事業部長、現場の三層に、別々に聞きます。同じ部屋に集めると経営の声だけが残るからです。経営には業界で変えたいことを、事業部長には今期の数字を、現場には昨日の午後に開いた画面を聞きます。三つを同時に満たす一点を探すのが、この週の目標です。OpenAIの言う「少数の優先ワークフロー」を、当社はこの一点と呼んでいます。

午前のうちに、もう一つ決めます。データの持ち主です。「その数字はどのシステムから来ていますか」「管理者は誰ですか」。Palantirの元FDEが書いたとおり、8〜12週間のパイロットがデータへのアクセス交渉で消えることがあります¹。当社は、初回の打ち合わせで匿名化の手順を決め、セキュリティ審査は並行して進め、審査中は匿名化データで動かす段取りにしています。月曜の午前に持ち主が特定できていれば、午後には匿名化した実データが手元にあります。

午後は、見る時間です。担当者の斜め後ろに座り、シャドーイングで一日の流れを見ます。口は挟みません。移動と待ちを記録します。ここで五列の記録が始まります。

夕方に、初版を置きます。当社の製品の標準部品の上に、午前に聞いた名詞と動詞を載せ、午後に見た画面の流れを写し、匿名化した実データで動かします。コーディングエージェントに書かせ、人が読み、担当者の前に置きます。作り方の詳細はライブモックの記事に書きました。置いた後に聞くのは一言です。「何が違いますか」。ここで出てくる違いが、火曜に作るものです。

初版には、書き込みを載せません。読み取りと提案までです。本番のシステムに書き戻す処理は、権限、事前のシミュレーション、重大な判断での人の介在、監査できる記録の四点を決めてからでないと載せません。これは速さより前にある条件です。

火曜から木曜。観察で例外を集め、毎日一版ずつ重ねる

火曜から木曜は、見ながら作る日です。午前は文脈的質問法で、作業の場に座り、作業を見ながら「いまなぜそうしたんですか」と聞きます。例外ノートが増えていきます。「急ぎのときは係長が押す」「月末だけこの帳票を使う」「この確認は課長が休みだと止まる」。午後は、午前の例外を版に載せます。

版の作り方は、仕様駆動です。例外ノートの一行を短い仕様に書き、コーディングエージェントに実装させ、人が読み、担当者の前に置きます。仕様を先に書く理由は、エージェントに何を作らせたかを後から辿れるようにするためで、書き方は仕様駆動開発の記事にまとめています。一日一版です。二版作る余裕があっても、一版にします。担当者が反応を返せる回数は、一日に一回が限度だからです。

木曜の午後には、効果の仮測定をします。動くものを使って同じ作業をやってもらい、時間と画面の切り替え回数を数えます。撮影の同意が取れていれば、ビデオで数えます。「承認待ちが47分から12分になった」という差分が、金曜の判断の材料になります。仮測定は担当者向けの成果であると同時に、自社向けの「この型は製品に返す価値があるか」の根拠です。

この三日間で、当社のエンジニアが気をつけていることを一つ書きます。作りすぎないことです。例外ノートに10個あれば、全部作りたくなります。しかし10個のうち7個は、その会社だけの枝で、しかも月に一度しか起きません。木曜までに作るのは、毎日起きる例外だけです。残りは金曜に、型か枝かを分けてから決めます。

金曜。束を作り、辞書を更新し、型を製品に返す

金曜は、現場を離れて考える日です。午前に、月曜から木曜の断片、逐語録、五列の記録、例外ノート、木曜の計数を、KJ法の考え方でカードにし、束を作り、名前をつけます。この手順はKJ法の記事に書きました。

午後に、束の名前から五つを抜いて辞書を更新します。名詞、動詞、関係、状態、例外です。「承認する」の定義が、今週は「係長が判断し課長が押印する」に変わり、版が一つ上がります。オントロジーの記事に書いたとおり、辞書は翌週の月曜にエージェントが読む前提で書きます。

そして、束の名前を型と枝に分けます。「承認が二段になっている」は、他社でも見た型です。製品の側で、承認の段数と判断者を設定できるようにする仕事が、製品のバックログに入ります。「その紙を経理の田中さんが預かる」は枝です。記録して、製品には入れません。a16zが2026年1月に整理した圧力テストの一つ、カスタマイズに「No」と言えるか⁴に、当社が答えられるのは、この金曜があるからです。

金曜の最後に、二つの文章を書きます。担当者向けに「来週は急ぎ案件の承認経路を画面に作ります。理由は、いまの紙の経路が係長判断を前提にしているからです」という一段落。自社向けに「急ぎ案件の別経路は型、預かり先は枝」という判断。この二つを書いて、一週間が終わります。

週を重ねる。45日から90日で、当社が要らなくなる

一週間はこの繰り返しですが、週を重ねると中身が変わります。a16zは2026年1月の論考で、本物のFDEの型を時間区切りの展開として整理し、90日で本番に届くスプリントを例に挙げています⁴。AWSは、終了時に顧客が自走できる状態、つまり動くものと文書と訓練された社内人材を残すことを設計の中心に置いています²。当社も、現場にいる期間を最初に決めます。おおむね45日から90日です。

第1週から第2週は、上に書いた往復で、読み取りと提案までを置きます。第3週から第4週で、書き込みを段階的に載せます。権限と事前シミュレーションと人の介在と監査記録の四点を決め、まず一つの処理だけを書き戻し、一週間本番で見ます。第4週あたりで、担当者に辞書を触ってもらい始めます。「急ぎ区分の判断者が変わった」を、当社ではなく担当者が直します。第6週から第8週で、当社のエンジニアが現場にいない日を作ります。いない日に往復が回っていれば、出る準備ができています。

出る条件は三つです。担当者が辞書を自分で更新できること。動くものの効果が、業務の指標で担当者自身に見えていること。そして、型が製品に返り、次の顧客で同じ学びが要らなくなっていること。Palantirの商用部門を率いた人物は、FDEを顧客の事業の「権限ゼロのCEO」と呼び、成果に責任を持つことを求めました⁵。当社にとって成果とは、当社が要らなくなることです。

受託開発の工程との違い

一週間の構造を、受託開発の工程と並べます。

観点	受託開発	FDEの一週間
工程の並び	要件定義、設計、実装、テスト、検収を直列に	聞く、作る、反応を取る、返す、を毎週並列に
初日の成果物	議事録と要件の下書き	匿名化した実データで動く初版
変更の扱い	要件の変更は追加費用と再見積	変更は火曜の版に載せる。金曜に型か枝かを分ける
成果の測り方	検収（仕様どおりに動くか）	業務の指標（47分が12分になったか）
学びの行き先	顧客の資産	型は製品へ、枝は顧客の拡張へ
終わり方	検収して撤収	担当者が辞書を触り、当社が要らなくなる

いちばん大きな違いは、工程を直列に並べないことです。受託開発は、要件が固まるまでコードを書きません。固まった要件を設計し、実装し、テストし、検収します。この順番は、要件が正しければ最も無駄がありません。FDEが直列を捨てるのは、要件が最初から正しいことがないからです。担当者は白紙の仕様書に、係長が押す例外を書けません。動くものを見て、初めて言えます。だから、聞くと作るを同じ週に置き、反応を取るを毎日置きます。

もう一つの違いは、成果の測り方です。受託開発は検収で測ります。仕様どおりに動けば完了です。FDEは業務の指標で測ります。仕様どおりに動いても、担当者の承認待ちが減っていなければ、完了ではありません。だから木曜に仮測定をし、翌週に撮り直します。この測り方の違いが、「速い」の意味を変えます。受託の速さは検収までの日数で、FDEの速さは担当者の一日が変わるまでの日数です。

当社の実践と限界。一週間で本番に載らないもの

正直に書きます。一週間で本番に載らないものがあります。

基幹システムへの書き込み連携は、一週間では載りません。権限と事前シミュレーションと人の介在と監査記録を決め、一つの処理から段階的に載せるので、数週目になります。セキュリティ審査が必要な接続も、審査の期間に依存します。当社は審査を並行して進め、審査中は匿名化データで動かしますが、審査そのものを速くはできません。月末や繁忙期にしか現れない処理は、その時期が来るまで見られないので、出来事として聞いて仮に作り、時期が来てから直します。

速さの条件も書いておきます。担当者の時間と、データへのアクセスです。担当者が「忙しいので後で」と言い続ける現場では、往復は回りません。データの持ち主が月曜に特定できない現場では、火曜に作るものがありません。当社は初回の打ち合わせで、この二つを案件の条件として合意します。合意できない現場では、一週間の往復は約束しません。

最後に、「初日にコード」という言い方の危うさを書いておきます。初日に出るのは、不完全な初版です。担当者から「何が違いますか」の答えを引き出すための、質問装置です。これを完成品と受け取られると、二日目に失望が来ます。だから当社は、初版を置くときに必ず「これは違いを教えてもらうためのものです」と言います。速さの価値は、初日の完成度ではなく、金曜までに正しいものに近づく速さにあります。

まとめ

当社が最速で実装できると言う根拠は、聞いて、作って、反応を取って、製品に返す往復が一週間に収まっていることです。月曜に三層に聞き、データの持ち主を特定し、夕方に匿名化した実データで動く初版を置きます。火曜から木曜は文脈的質問法で例外を集め、仕様駆動で一日一版を重ね、木曜に効果を仮測定します。金曜はKJ法で束を作り、辞書を更新し、型を製品に返し、枝を記録します。

週を重ねて45日から90日で、担当者が辞書を自分で更新し、当社が要らなくなります。受託開発との違いは、工程を直列に並べないこと、成果を検収ではなく業務の指標で測ること、学びが製品に返ることです。一週間で本番に載らないものもあり、速さの条件は担当者の時間とデータへのアクセスです。

この往復を自社のエンジニアのチームで回したい方、あるいは自社の現場にこの往復を持ち込む相手を探している方は、WARPのプログラムをご覧いただくか、個別相談でお話ししましょう。次の記事では、FDEという職種がなぜ2025年から2026年に急拡大したのかを、求人と投資と買収の数字で読みます。

Footnotes

1. Reflections on Palantir（Nabeel S. Qureshi、2024年10月15日）。1〜2週間で使えるものを出した記述、既存の導入業者との対比、パイロットがデータアクセス交渉で消えた逸話は同稿による（筆者訳） ↩ ↩²

2. AWS invests $1 billion to embed AI forward deployed engineers with customers（Amazon、2026年6月30日）。月単位から日単位への圧縮、終了時の自走は同発表による ↩ ↩²

3. OpenAI launches the OpenAI Deployment Company（OpenAI、2026年5月11日）。典型的なエンゲージメントの進め方は同発表による ↩

4. The Palantirization of everything（Marc Andrusko、a16z、2026年1月16日）。時間区切りの展開、90日スプリント、圧力テストは同稿による ↩ ↩²

5. Sorry, that isn't an FDE（Ted Mabrey、2024年9月21日） ↩