FDE（フォワード・デプロイド・エンジニア）は、顧客の現場に入り、製品がその業務の中で動くところまで作るエンジニアです。
配属先は金融のこともあれば、医療や防衛のこともあります。
つまり、昨日まで知らなかった業界の言葉で、今日から仕事をすることが前提の職種といえます。
「業務知識がゼロの状態から、どうやって短期間で話についていけるようになるのか」と気になったことはないでしょうか？
私も FDE の経験はなく、この役割を学んでいる途中です。
足場にするのは、Palantir の公開インタビューや求人票、そしてドメイン駆動設計（DDD）の周辺で磨かれてきたドメイン理解の手法です。
先に結論を書くと、ドメインの知識は暗記するより、言葉と業務の流れを現場の人と一緒に組み立て、直してもらうほうが速く身につくと読み取れました。
業界を知らないまま入るのが前提の仕事
まずは、ドメインの学習が FDE の仕事にどれほど組み込まれているかを確かめます。
Palantir の公式ブログが 2020 年に公開したインタビュー「A Day in the Life of a Palantir Forward Deployed Software Engineer」（Palantir の FDSE の一日）には、同社で FDE にあたる FDSE のブライアン氏が登場します。
同氏がこれまで携わった分野は、サイバー、ヘルスケア、防衛です。
入社直後には、サイバー分野に触れた経験がないまま、大型のサイバー案件に投入されたそうです。
学ぶ必要があったのは、自社製品のサイバー向け機能、顧客が抱える技術的な課題、そしてサイバー分野そのものの知識の三つだったといいます。
同氏はこの状況を「消火ホースから水を飲むようなもの（drinking from a fire hose）」と表現していました。
求人票の側では、Anthropic のForward Deployed Engineer の募集要項が、金融やヘルスケアなどの業界経験を「あれば歓迎」（a plus）の欄に置いています。
一方で役割の説明には、顧客の業務の流れ（workflows）を理解することがはっきり書かれています。
業界の経験は入口の条件ではなく、入ってから身につけるもの、という読み方ができそうです。
ブライアン氏が追いつくために頼ったのは、メンターやチームの仲間、その分野をいちばんよく知る顧客と話す時間、そして自分での調べものの三つでした。
顧客と話す時間のうち、何を作るべきかを聞き出すディスカバリーの進め方は、以前の記事で扱っています。
ここから先は、業務そのものの知識を短期間で組み立てるための道具の話です。
用語集は「意味のずれ」を見つけるために作る
知らない業界に入って最初に戸惑うのは、たいてい言葉です。
エリック・エヴァンス氏が要点をまとめて公開している「Domain-Driven Design Reference」（ドメイン駆動設計リファレンス）は、この問題を具体的に書いています。
業務の専門家は業界の用語を、技術者は設計のための言葉を使うため、日々の会話の言葉とコードに埋め込まれた言葉が切り離されてしまうという指摘です。
通訳を挟むと伝達が鈍り、業務知識を噛み砕く作業（knowledge crunching）が痩せる、とも書かれていました。
処方箋は、会話にも図にもコードにも同じ言葉を使う「ユビキタス言語」という考え方です。
厄介なのは、同じ単語が部署によって違う意味で使われている場合です。
マーティン・ファウラー氏の解説記事「Bounded Context」（境界づけられたコンテキスト）には、同氏が電力会社と仕事をしたときの例が出てきます。
そこでは「メーター」が、送電網と場所のつながりなのか、送電網と顧客のつながりなのか、故障したら交換される計器そのものなのか、部署ごとに微妙に違っていたそうです。
会話ならぼかせても、コンピューターの厳密な世界ではぼかせない、と同氏は指摘しています。
こう考えると、用語集は覚えるための単語帳ではなく、同じ言葉のずれを見つけるための道具になります。
言葉ごとに、次の三つを書き残しておくと、ずれに気づきやすくなるでしょう。
- 誰がその言葉を使うか（部署や役割）
- その人にとっての意味
- 対応するシステムの項目名やテーブル名
業務の流れは「出来事」を時系列に並べて掴む
言葉の次は、仕事がどんな順番で流れているかです。
手がかりになるのが、アルベルト・ブランドリーニ氏が考案したイベントストーミングという手法です。
同氏が 2013 年に書いた最初の紹介記事「Introducing Event Storming」は、これを複雑な業務ドメインを素早く探るためのワークショップの形式と説明しています。
問いを持つ人と答えを知る人を同じ部屋に集め（目安は 6〜8 人）、業務の中で起きた意味のある出来事をオレンジの付箋に書いて、時系列に貼っていきます。
出来事から始めるのは、技術者でない人にもすぐ掴めるからだそうです。
同氏はこのやり方で、業務の流れ全体のモデルを、数週間ではなく数時間で描けたとも述べています。
新しく入った人の立ち上がりに効いた例も紹介されていました。
同氏の会社で研修講座の業務の流れを探ったときは、参加者は開発者ではなく、数時間で終わり、終えたころには新しく入った全員が会社のやるべきことをはっきり掴めていたといいます。
ここからは私の考えですが、FDE なら並べた出来事ごとに「どのシステムのどのデータとして残るか」を書き添えておくと、業務の流れとデータが一枚でつながりそうです。
顧客のシステムからデータを取り出す段階の注意点は、別の記事で扱いました。
仕事の横に座り、自分の言葉で言い直して確かめる
言葉と流れの見取り図ができても、会議室で聞いた説明だけでは足りない場面が残ります。
Nielsen Norman Group の記事「Contextual Inquiry」（文脈の中での調査）は、人が自分の仕事の手順を要約すると、理由や動機、頭の中にある前提が抜け落ちると説明しています。
作業している最中なら、何をなぜしているかを話すのはたやすい、とも書かれていました。
例として載っているのは、自動車保険の契約を作るソフトで、データ入力の部分を作り直したときの話でした。
聞き取りでは、担当者 3 人がそろって「表計算ソフトから車両データをまとめてコピーして貼る」と答えていたそうです。
ところが作業を横で見ると、足りない情報を別のツールの画面で調べて埋める手順が加わっていて、自動保存があるのに入力のたびに保存ボタンを押す癖もありました。
同記事はこの調査を「親方と弟子」の関係にたとえ、弟子の立場で仕事を見せてもらいながら質問する形として説明しているのです。
Palantir の採用担当マネージャーがまとめた「Dev versus Delta」（Dev と Delta の違い）にも、FDE にあたる Delta の一人が自動車の生産ラインを訪ね、品質試験中の車内に乗った話が出てきます。
見て聞いたことは、最後に自分の言葉で言い直して確かめます。
エヴァンス氏のリファレンスは、モデルの言葉を使って業務の場面を声に出して説明してみることを勧めていました。
たとえば「注文が確定すると、倉庫に出荷の指示が出る」のように業務の言葉だけで短い説明を書き、現場の人に間違いを直してもらう形です。
直された箇所は、自分の理解がずれていた場所をそのまま示す目印になってくれるでしょう。
理解したつもりを、相手に直してもらえる形で外に出すことが、短期間で追いつくための近道なのかもしれません。
最後に
未知の業務ドメインに追いつくやり方は、言葉のずれを拾う用語集、出来事で並べる業務の流れ、仕事の横での観察と言い直しの三つに分けられそうです。
どれも、資料をひとりで読み込むより、現場の人を「答えを持つ人」として巻き込むところに共通点があります。
まずは身の回りの業務で、同じ言葉が部署によって違う意味で使われていないかを探すところから試してみます。
以上です。
コメントを残す