FDEという職種が、同じことを言っている
Forward Deployed Engineer（FDE）という職種があります。米国のPalantir Technologiesが2010年代に確立したもので、顧客の現場に入り込み、顧客の環境で実際に動くものを作るエンジニアを指します。近年はOpenAIやAnthropicなども採用しており、日本でも募集が始まっています。
この職種がコンサルタントと違うのは、助言で終わらず、自分で動くものを作るところまでやる点です。提案書ではなく、動いているシステムで結果を示す。
実務者の言葉として、こういう整理があります。物理的な作業はAIで自動化できない。最終チェックで責任を担保するのも人。そして「全部聞き出す」のが一番大変。ツールや仕組みを作ることより、そこが難しい。
※当社は自社プロダクトを持たないため、FDEそのものではありません。ただし「現場に入り、動くものを作り、運用まで持つ」という考え方は同じです。
聞いた課題を、そのまま要件にしない
相談の場で出てくる課題は、その時点で本人が言語化できているものだけです。手順に書き出せていない作業、例外として処理されている業務、担当者が無意識にやっている判断は、話に出てきません。
だから当社は、紐解いたあとで現場を見せてもらいます。誰が、何時間かけて、どういう手順でやっているか。止まったとき誰が判断しているか。データはどこに、どんな形で溜まっているか。これを確かめてから、作る範囲を決めます。
要件定義に、失敗の兆候が出る
プロジェクトが崩れる兆候は、たいてい要件定義に出ます。決めきれていない項目が残ったまま次の工程に進むと、後ろの工程すべてに効いてきます。
そして要件は、技術だけ分かっていても詰められません。ビジネスの仕組みとオペレーションに精通していなければ、成し得ないと考えています。何がどう回っていて、どこで人が判断していて、例外が事業のどこに効いているのか。それが分かって初めて、作る範囲と作らない範囲を切れます。
準備に、思ったより時間がかかる
当社自身がAIで業務を回していて、失敗したこともあります。設定ファイルや、AIを動かすための足場（ハーネス）の設計に、逆に時間と労力を費やしたことです。
任せる仕事を決めて、手順を書き出して、判断の境目を定義して、動かしてみて直す。この準備が、任せたあとに浮く時間より大きくなる場面があります。だから渡す仕事を先に絞る必要があります。渡したのは、創造性を伴わない単純労働とルーティンワークです。
導入する側でも同じことが起きます。システムが完成するまでは、現状より工数が増えたように感じる期間があります。そこを先に伝えないまま始めると、現場の協力が途中で切れます。