以前、FDEについて「やったことがない人が語りすぎでは」と書いた。 今回はその続きで、こちらは前向きな話。 結論から言う。 FDEは外から買うものではなく、社内のBizOpsがなるものだと思っている。 それも、ClaudeやOpenAIといった特定のSaaSに依存しない形で。 FDEの求人票を要約するとこうなる。 「現場に入り込み、課題を見つけ、システムを繋ぎ、AIを実装し、定着させ、自社プロダクトに還元する」 この一行の後半にひっかかる。「自社プロダクトに還元する」。 外部FDEの還流先は、顧客ではなくFDEの雇い主のプロダクトだ。 顧客の課題解決と自社プロダクトの強化は、たいてい一致する。ただ、一致しない瞬間が必ず来る。そのとき外部FDEがどちらを選ぶかは、構造上決まっている。 社内BizOpsは違う。還流先が「自社の社内業務OS」しかない。 課題を見つけて、繋いで、定着させて、その知見を次の業務設計に戻す。この循環がそのまま自社の資産になる。還元先を選ぶ葛藤が、そもそも存在しない。 しかも、BizOpsはFDEの仕事の前半をすでにやっている。 ・部署ごとに言っていることが違う、を毎日聞いている ・「前に一度やって失敗した」記憶を知っている（当事者だったりもする） ・組織図に描かれていない本当の意思決定線を知っている ・動くものを出しても使われない、を何度も経験している 前回、FDEに必要なのは 技術力 × 業務理解 × 組織の力学 × 嫌われる能力 × 言語化 × 諦めない精神 と書いた。 BizOpsはこのうち4つを持っている。足りないのは「技術」と、それを使って「AIを実装する」部分だけ。 そしてこの足りない部分のハードルは、この1年で激減した。 Claude Codeでも何でもいい。業務を言語化できる人間が、そのまま実装まで届く距離になった。コードが書けないから、と止まっていた壁がほぼ消えている。 ただし、ここで一つだけ条件をつけたい。 最初は構わないが、最終的に特定のAIに依存した形で作り上げていくこと。 理由は単純で、AIモデルは半年で入れ替わる。価格も変わる。APIも変わる。 今日のベストが来年もベストである保証はどこにもない。 例えば特定SaaSの機能に業務を合わせて作ると、そのSaaSが変わった瞬間に業務ごと巻き込まれる。SFA導入で散々見てきた光景がAIで再現されるだけとなとなる。 では何に依存すべきか？ 自社の業務そのものの言語化に依存すべきだと思う。 ・この業務は何を入力に、何を判断して、何を出すのか ・判断基準は何か。例外はどこで、誰が決めるのか ・どのデータがどこにあり、何と繋がっているのか これをテキストとして書き切った会社は、裏側のモデルが何であろうと動く。 プロンプトもスキルもMCPの設計も、自社に残る。モデルは差し替え可能な部品として扱えばいい。 逆にこの言語化ができていない会社は、どんな優秀なFDEを外から呼んでも、還流先がないので定着しない。 要するにこういうことだと思う。 FDEを外から雇うと、知見はFDEの会社に還流する。 社内BizOpsをFDE化すると、知見は自社に還流する。 どちらが早くて、安くて、残るかは明らかではないだろうか。 前回「FDEは職種ではなく結果だ」と書いた。 「あの人がいたから、あのプロジェクトは死ななかった」の、あの人。 それは今、社内で一番業務を知っていて、一番組織に嫌われる覚悟があって、一番諦めが悪い人だ。 多分、BizOpsをやっているあなたであって欲しいと切に願う。 #BizOps#

AIで音声を評価できる時代に、それでも人が集まってレビュー会をする理由というnoteを書きました。組織や商材が変わっても応用しやすく、日々の実務そのものから学べる再現性の高い施策だと思っています。他の教育施策やロープレとの役割の違いなど私なりに整理してみました！