「AIを学ぶ」から「AIと仕事を変える」へ。私たちが考えるFDEと、コードキャンプのこれから

なぜなら、実際の企業の仕事にはシステムに記録されている情報だけではなく、

• 「このケースではこう判断する」
• 「このお客様の場合だけは例外」
• 「ここは担当者が経験的に判断している」

といった、文書化されていない大量の知識や判断が存在するからです。

だからこそ、顧客の現場に入り、その企業の業務や環境、例外、判断基準まで理解しながら、プロダクトやAIを実際の仕事に適応させていくFDEの役割が重要になる、という考え方です。Resolve AIはFDEの本質的な仕事を「サポート」ではなく「現場知の圧縮（compression）」と表現しています。ここでいう圧縮とは、現場の複雑さを単に要約することではなく、顧客固有の知識や例外を、プロダクトや組織が再利用できる能力へ変換していくことです。^[1]

この記事をチームにも共有し、FDEについて話すようになりました。

ちょうど同じようなタイミングで、コードキャンプの社内全体でもFDEという言葉が話題になっていました。

そこで改めて、

と考えるようになりました。今回、私が考える現時点での考えている内容をまとめました。

私たちが考えるFDEは、「顧客先で開発するエンジニア」だけではない

FDEという言葉だけを見ると、

「顧客のところへエンジニアを派遣して開発すること」

のようにも見えます。

ただ、私自身はもう少し広く捉えています。

私たちにとってのFDEとは、

現場の仕事を深く理解し、人とAI・テクノロジーの間に立ちながら、その仕事そのものをより良い形へ変えていくこと。

そしてもう一つ重要なのが、

そこで得た学びを、その顧客だけのものにせず、自分たちの組織の知識へ変えていくこと。

です。

この二つがそろって、FDE的な仕事になると考えています。

そして、この視点でコードキャンプがこれまで行ってきたことを振り返ると、一つ気づいたことがありました。

これは、私たちにとってまったく新しい考え方ではないのではないか。

ということです。

振り返ると、コードキャンプはすでにかなりFDE的なことをしていた

特に、企業向けのカスタマイズ研修では、その傾向が強くあります。

象徴的なのが、ニッセイアセットマネジメント様との取り組みです。

この研修では、プログラミングを教えることからスタートしたのではありません。

参加者の多くがプログラミング未経験であることや、実際の業務環境などを踏まえ、Google Workspaceと連携しやすいGASを題材として選択しました。さらに、最初からプログラミングに入るのではなく、まず自動化したい業務そのものを整理し、その後にプログラミングの基礎と実装へ進む設計にしています。先方からも、この「プログラミングだけでなく、自動化対象の業務整理から行ったこと」が効果的だったと評価いただいています。^[2]

そして研修中も、

• 何を生成AIに聞けばいいのか。
• どこから経験のある講師に相談するべきなのか。
• 技術的に何が実現できるのか。
• 限られた期間や現在のスキルで、どこまで作るのが現実的なのか。

といったことを、実際に手を動かしながら判断していきました。

講師は単にGASの書き方を教える人ではなく、画面を一緒に見ながら問題を見つけ、より現実的な実装方法を提案する役割まで担っています。

そして最後に残ったものも、研修用の架空の成果物ではありません。

実際のRFP業務の進捗管理など、現場で使うことを前提とした仕組みが生まれています。RFP関連の事例では、月90分程度かかっていた業務が10分程度まで短縮されたとされています。^[2]

つまり、

ここが重要です。

• 
  金融業界の業務効率化を加速するニッセイアセットマネジメントの生成AI×GAS活用研修事例

きらぼし様の取り組みも同じだった

東京きらぼしフィナンシャルグループ様との取り組みでは、この考え方がさらに明確に表れています。

研修は単なるツールの操作研修ではなく、

業務の棚卸し → 改善方法の検討 → ツール習得 → 自分自身の実業務を題材に実装 → 成果報告

という流れで設計されています。

仮想ケースではなく、自分自身の業務課題を持ち込み、生成AIと人間の講師の両方を活用しながら、実際の改善まで進めています。初回30名では年間1,600時間の業務削減効果が見込まれ、実際にツールも実装され、改善業務が動き始めています。^[3]

• 
  3.5日の研修で、年間1,600時間の削減効果が見込まれる。東京きらぼしフィナンシャルグループのDX人材育成事例

つまりコードキャンプは以前から、

「何を教えるか」だけではなく、「どの業務をどう変えるか」から研修を考える

ということを実践してきました。

そう考えると、コードキャンプがこれからFDEを始める、という表現は少し違います。

より正確には、

というのが現在地だと思っています。

では、今までと何が違うのか

一方で、まだ十分ではない部分もあります。

それは、

一つひとつの案件で得られた学びを、どれだけコードキャンプ自身の組織能力へ変えられているか。

という点です。

ニッセイアセットマネジメント様との取り組みでも、

• 「最初に業務整理をした方がいい」
• 「この環境ならこの技術が適している」
• 「生成AIだけでは判断しにくいポイントがある」
• 「講師は技術だけでなく実装の現実的な線引きを支援した方がいい」

といった、多くの知見が得られています。

別のお客様では、また別の知見が生まれます。

問題は、それが担当者や講師個人の経験としてだけ蓄積されてしまうと、次のお客様ではまたゼロに近いところから考えなければならないことです。

Resolve AIがFDEについて強調しているのも、この点です。^[1]

FDEが現場で得た学びを現場だけに残してはいけない。

顧客固有の複雑な問題から共通するパターンを抽出し、次からはプロダクトや仕組み自体が吸収できるようにする。

つまり、

これがFDEにおける「現場知の圧縮（compression）」だと私は理解しています。現場でしか分からなかった複雑さを、次の案件でも使える知識・仕組み・プロダクトの能力へ変えていく、という意味です。

ここが、これからコードキャンプがもう一段進化できる部分だと思っています。

だからといって、いきなり「FDEを導入する」のは違う

ただ、FDEという考え方が面白いからといって、

「では明日からコードキャンプ全体をFDE型にしよう」

とするのは、かなり唐突です。

まして、

「FDEを教える研修を作ろう」

という話でもありません。

それでは結局、新しく出てきた概念を新しい研修メニューに置き換えているだけになってしまいます。

FDEの本質を考えるなら、まず自分たち自身が実践するべきだと思いました。

そこで現在、私たちのチームでは、

という取り組みを始めています。

• 本当に仕事が良くなるのか。
• どこまでAIに任せられるのか。
• どこには人間の判断が必要なのか。
• 何をデータとして残すべきなのか。
• 一人の担当者が行った判断を、どうすればチーム全体が次に使える知識へ変えられるのか。

まず、それを自分たちの仕事で試してみることにしました。

その一例が、現在進めているSEOのFDE化

現在、私たちのチームではマーケティングの各工程に、こうした考え方を少しずつ取り入れ始めています。

今回は、その中でもSEOの一部を紹介します。

従来のSEOでは、

• 検索キーワードを調べる。
• 検索結果を見る。
• 競合ページを調べる。
• 記事を作る。
• 順位を確認する。

といった工程が存在します。

もちろん、それぞれ必要な仕事です。

ただ、それぞれが独立した作業になってしまうと、担当者が毎回情報を集め、経験に基づいて判断し、次の施策を考える必要があります。

そこで今は、

という一連の循環としてSEOを捉え直しています。

具体的なロジックの詳細はここでは省きますが、検索結果、検索需要、競合、自社コンテンツ、事業との関連性など、これまで別々に見ていた情報をつなぎ、

• 「どこに機会があるのか」
• 「何を優先するべきなのか」
• 「新しく作るのか、既存のものを改善するのか」

といった次の施策までつなげる仕組みを作っています。

内部設計でも、SEOを単なる検索順位の分析ではなく、検索（Search）・コンテンツ（Content）・事業（Business）を接続し、機会発見（Opportunity）→ 施策（Action）→ 効果測定（Measurement）→ 学習への還元（Feedback）までを一つの循環としてつなぐ構造で考えています。

さらに突き詰めれば、

検索結果（SERP） → エンティティ（Entity） → 関係性（Relationship） → 市場オントロジー（Market Ontology） → ギャップ（Gap） → 事業上の優先順位（Business Priority） → 施策（Action） → 成果（Outcome）

という流れを目指しています。

大事なのは、個々の分析ロジックではありません。

人間が毎回ゼロから考えて判断する業務から、過去の観測・判断・結果が蓄積され、次の判断がより良くなる業務へ変えること。

ここにFDE的な考え方があります。

オントロジーも、「仕事の地図」くらいに考えている

この過程では、オントロジー（Ontology）という考え方も重要になります。オントロジーは、業務上の対象を単に一覧化するのではなく、対象同士の関係や、そこから実行できるアクションまで含めて構造化する考え方として捉えています。^[4]

ただ、これも難しい概念として扱う必要はないと思っています。

私自身は、

くらいに考えています。

SEOであれば、

• 検索する人がいる。
• 検索クエリがある。
• 検索意図がある。
• 競合がいる。
• コンテンツがある。
• 商品がある。
• 顧客がいる。
• 売上がある。

それらはすべて、何らかの形でつながっています。

単なるデータの一覧ではなく、

「何と何が、どういう関係にあるのか」

をAIも扱える形にする。

そうすることで、AIが単に情報を出すだけではなく、対象同士の関係や業務上の文脈を踏まえて、判断やアクションを支援しやすくなります。^[4]

これもまた、SEOだけの話ではありません。

SEOは一つの実験でしかない

私たちがやりたいのは、「SEOをAIで自動化すること」だけではありません。

SEOは、現在試している一つのユースケースです。

マーケティングだけでも、

市場調査、コンテンツ、広告、CRM、リード獲得、商談への接続、効果測定など、さまざまな業務があります。

さらに営業、人事、カスタマーサポート、研修設計、開発などへ視点を広げれば、会社は大量の「情報 → 判断 → 施策・実行」の組み合わせで動いています。

そこで、

• どこまでAIに任せるのか。
• どこで人間が判断するのか。
• その判断に何の情報が必要なのか。
• 結果をどう蓄積して、次の判断を良くするのか。

これを整理していく。

つまり、現在のSEOでの取り組みは、

でもあります。

そして、この経験をもう一度お客様へ戻していく

ここまで来ると、私たちがこれから考えている教育の形も見えてきます。

従来の研修は、

学ぶ → 練習する → 実務で使う（Learn → Practice → Work）

が基本でした。

まず知識を学び、演習し、会社に戻って実務で使う。

これからも、この形が必要な場面はあります。

ただ、生成AIによって「必要なことを調べる」「コードを書く」「試作品を作る」といったハードルが大きく下がってきた今、別の学び方もできると思っています。

それが、

です。

• まず、自分たちの実際の仕事を見る。
• 何が問題なのか整理する。
• 仕事の構造を理解する。
• AIに任せるところと人間が担うところを考える。
• 実際に作ってみる。
• そして、その過程で必要なことを学ぶ。

振り返れば、ニッセイアセットマネジメント様やきらぼし様との研修は、すでにこの形にかなり近いものでした。

だからコードキャンプがこれから目指したいのは、教育をやめてコンサルティング会社になることでも、FDEという新しい研修商品を売ることでもありません。

だと考えています。

人を育てるだけではなく、業務と組織が変わる研修へ

例えば1日の研修でも、

「生成AIの使い方を学んで終わる1日」

ではなく、

自分たちの実業務を持ち込み、業務を整理し、AIと人間の役割を考え、実際に改善の第一歩を作る1日

にすることができます。

必要であれば、その後数週間、数か月と伴走し、実装や社内定着まで一緒に進めることもできます。

期間が重要なのではありません。

大切なのは、

研修を受けること自体をゴールにしないこと。

だと思っています。

学んだ結果、人が変わる。

人が変わった結果、仕事が変わる。

仕事の変化が一人だけで終わらず、チームへ広がる。

そして最終的には、

そこまでを教育の領域として考えていきたい。

それが、これからコードキャンプが教育とコンサルティングの間で作っていける、新しい価値ではないかと思っています。

コードキャンプ自身も、まだ進化の途中にいる

もちろん、これは完成した話ではありません。

コードキャンプ自身も今、AIを活用しながら自分たちの仕事を変えようとしている最中です。

だからこそ、まず自分たちで試す。

うまくいったことだけではなく、うまくいかなかったことからも学ぶ。

その学びをチームの知識へ変える。

そして、その経験を再びお客様へ還元する。

この循環を作っていきたいと思っています。

FDEという言葉自体が、これからどう変わっていくかは分かりません。

ただ、

• 現場を理解する。
• 業務を構造化する。
• AIと人間の役割を考える。
• 実際に作る。
• 使う。
• 結果を見る。
• そこから学び、次の改善につなげる。

という仕事のあり方は、これからさらに重要になっていくはずです。

最後に、FDEという言葉そのものより大切だと思うこと

ここまでFDEやオントロジーという言葉を使ってきましたが、書きながら改めて感じるのは、これらの言葉そのものが重要なのではない、ということです。

FDEもオントロジーも、生成AIによって突然生まれたものではありません。以前からあった、現場を深く理解すること、業務や判断の構造を整理すること、そこで得た知識を仕組みに戻すこと。そうした考え方が、生成AIの登場によって改めて重要になり、新しい文脈で語られる機会が増えているのだと思います。

DXや、AI変革（AI Transformation）という意味で使われることのあるAXも同じです。新しい名前を知ることや、その概念を導入すること自体が目的ではありません。

実際に仕事を変えようとすると、結局はもっと基本的な問いに戻ってきます。

• 自分たちは、そもそも何のためにこの仕事をしているのか。
• 一つひとつのタスクは、どのような判断によって動いているのか。
• 通常の手順だけでなく、どんな例外やイレギュラーがあるのか。
• 担当者の頭の中にしかない経験や暗黙知は何なのか。
• それを個人の経験で終わらせず、チームや組織が次に使える形へ変えられるのか。

AIに任せる範囲を考える前に、まず人間自身がこれらを理解し、整理できている必要があります。そして、一人では整理しきれない知識や判断を、組織として持ち寄り、共有し、改善へつなげられる環境が必要です。

そう考えると、FDEもAI活用も、突き詰めれば「業務をどう設計し、そこで生まれた学びをどう組織の能力へ変えていくか」という問題に戻ってくるのだと思います。

そして、もう一つ忘れてはいけないのが、何を目指して改善するのかということです。

目標が曖昧なままでは、業務を速くすることはできても、それが本当に良い改善なのかは判断できません。担当者のタスクを効率化するだけでは、局所的な最適化で終わってしまうこともあります。

それぞれの職務やタスクの先に、顧客への価値、売上や利益、生産性、リスクの低減といった事業としての成果がどうつながっているのか。会社として何を良くしたいのか。その共通認識を持ったうえで、そこから逆算して業務や判断の構造を考えることが必要です。

新しい言葉が出てくるたびに、その言葉を追いかけるのではなく、自分たちの仕事は何のためにあり、何を変えるべきなのかを考える。その上で、使える考え方やテクノロジーを取り入れる。

今回FDEについて考え、実際に自分たちの業務で試し始めたことで、改めてその重要性を感じています。

コードキャンプはこれまで「人を育てる」ことに取り組んできました。

これからは、その強みを活かしながら、

人を育てるだけではなく、業務を変え、組織が自ら変わり続けられる仕組みまで作る。

私たち自身も実践し、進化しながら、

「AIを学ぶ」から、「AIとともに仕事と組織を変える」へ。

そんな企業研修を、1日からでも実践できる会社へ、さらに進んでいきたいと考えています。