IT

· 約 9 分

FDEの1日。朝会からリリースまで、4つの時間帯で見る仕事の中身

朝は顧客と今日の検証テーマをすり合わせ、午前は業務現場に張り付き、午後は小さなプロトタイプを動かし、夜は振り返りを書く。FDE(フォワード・デプロイド・エンジニア)の1日を4つの時間帯に分け、それぞれの動き方と成果物、ありがちな失敗を具体的に紹介します。

FDEの1日を朝会からリリースまでの流れで紹介するイメージ

朝9時。ほかの職種の人が会議室で週次の定例に出ているころ、この職種の人は顧客の席の横に座って、担当者の作業を黙って見ています。午後3時には、とりあえず動く小さなプロトタイプを組んでいます。夜8時には、「今日いったい何がわかったのか」を書き出しています。

これが FDE(Forward Deployed Engineer、フォワード・デプロイド・エンジニア) の典型的な1日です。

ここまでの記事では、FDEとはどんな仕事か、プログラマーやプリセールスと何が違うのか、そして4つの役割を取り上げてきました。今回は視点を変えて、1日のスケジュールをそのまま広げてお見せします。読み終えるころには、この仕事が忙しいのか、何に追われているのか、そしてこのリズムが自分に合いそうかどうかも見えてくるはずです。

わざわざ「1日」を取り上げるのには理由があります。職種紹介の記事ばかり読んでいると、わかった気になりやすいからです。役割は暗記しているのに、面接で「普段は1日をどう組み立てていますか?」と聞かれると、言葉に詰まってしまう。ある職種を本当に理解しているかどうかは、1日のスケジュールを再現できるかで確かめるのがいちばん早いと思っています。各時間帯に何をするのか、なぜその順番なのか、何が成果として残るのか。この3つにすらすら答えられれば、その仕事はもう理解できています。

明るいオフィスのホワイトボードの前で、リュックを背負ったFDEが業務フロー図の説明を聞いているイラスト

朝:今日は何を確かめるのか、顧客とすり合わせる

FDEの1日は、すり合わせから始まります。ポイントは、相手が自分のチームではなく、多くの場合は顧客側の業務責任者だということです。チーム内の朝会とは別物だと考えてください。

やることはシンプルで、3ステップだけです。

1. 前日の観察メモを見返す。 前日に現場でメモした問題や疑問点、よくわからなかった工程を整理して、その日の「確認したいことリスト」を作ります。

2. 顧客と優先順位を確認する。 今日いちばん見るべき工程はどこか。顧客が一番困っているのはどこか。ここで認識をそろえてから現場に入らないと、時間をムダにします。

3. その日のうちに確かめられる小さなゴールを決める。 たとえば「この伝票を1日に何回処理し直しているのかを把握する」「この工程のデータがどこから来てどこへ行くのかを追いかける」といったものです。その日のうちに結論が出るくらい小さくするのがコツです。

朝のこのステップがなぜ大事なのか。FDEの価値は、業務を実態どおりに理解していることから生まれます。そして、ゴールを決めておくからこそ、現場で過ごす1時間1時間が成果につながります。目的のない観察は、最後には「今日はこれを見ました」という作業メモの羅列で終わってしまいます。

ありがちな失敗: 自分のチームの中でしか話を合わせておらず、現場に着いてから何を見ればいいのかわからない。1日あちこち眺めて終わり、夜の振り返りでは役に立つ結論がひとつも書けない。

午前:業務現場に張り付いて、実際の業務の流れを見る

午前中はFDEにとってのゴールデンタイムです。やることはひとつだけで、担当者の実際の作業に付いて、業務の流れを最初から最後まで一緒にたどります。

観察するときは、次の3つに注目します。

誰が作業しているか。 作業しているのはどんな立場の人か。その作業を1日に何回くり返しているか。この回数が、そもそも改善する価値があるかどうかをほぼ決めます。

データがどこから来ているか。 担当者が入力している表、押しているボタン、書き写している数字の裏には、どのシステムがつながっているのか。複数のツールのあいだで、データを手作業で行ったり来たりさせていないか。

どこで詰まっているか。 何度も人に確認を取りに行く工程はどこか。目視チェックに頼っている工程はどこか。ミスが出ると差し戻しになってやり直す工程はどこか。詰まっているところが、そのまま改善のチャンスです。

ここでのキーワードは「実態」です。資料に書かれている業務フローと、現場で実際に回っているフローは、たいてい別物です。人が口で説明するフローは、どうしてもきれいに整理されたものになります。現場に張り付いて初めて、本当の流れが見えてきます。

特に記録しておきたいのが例外(イレギュラー)対応です。通常の流れなら誰でも図にできますが、自動化のチャンスが隠れているのはむしろ例外のほうです。ある工程でたまに特殊なケースが出てきて、担当者がそのたびに手作業でカバーしている。そういう場所はひとつ残らず拾っておきましょう。

午前の成果物は現場の観察メモです。業務がどう流れているか、各ステップの担当は誰か、どこで詰まっているか、どんな例外が起きたか。見た目はきれいでなくてかまいませんが、「この手順はなぜあるのか」に答えられるくらい具体的に書いておく必要があります。午後に何を作るかは、このメモで決まるからです。

もうひとつ、見落とされがちなポイントがあります。横で見せてもらうときの距離感です。担当者はもともと手いっぱいです。事前にひと声かけておく、声のボリュームを落とす、作業のリズムを止めない。相手が話してくれそうなときはすかさず質問し、忙しそうなときは黙ってメモを取り、邪魔をしない。現場との関係がうまく築けるかどうかで、その後数週間に集まる情報の質がまったく変わります。

午前の業務現場で、FDEが担当者の横に立ってノートを手に作業の様子を観察しているイラスト

午後:小さく一周回る仕組みを組んで、動かしてみる

午後は手を動かす時間です。午前の観察の中からいちばん確かめる価値のあるポイントをひとつ選び、最小限のプロトタイプを組みます。

ここで意識したい「小さく」が2つあります。

範囲を小さく。 一度に扱う工程はひとつだけ。たとえば「毎日3回入力し直している表」のデータの受け渡しだけを自動でつなぎ、ほかには手を出しません。欲張ることが、1日の中で最大の敵です。

検証を小さく。 動けばそれで十分です。見た目の良さも、あらゆるケースへの対応も求めません。「この方向ならいける」と数字ひとつ、あるいは実行結果ひとつで示せれば勝ちです。

典型的な動きは、データを1つつないで、処理ロジックを少しだけ書き、結果を誰でもすぐ見られる形で出す、というものです。動いたらすぐに担当者に試してもらい、その場でフィードバックをもらいます。「これじゃないんですよね」と「そう、まさにこういうのが欲しかった」。どちらの反応もとても貴重です。前者は方向を修正してくれ、後者は仮説が正しかったことを裏付けてくれます。

この時間帯は、FDEならではの立ち位置がいちばんよく表れる場面です。コードは本職の開発者ほど深く書けなくてもかまいません。そのかわり、正しい「小さなひとかけら」を選べるだけの業務理解が欠かせません。方向を間違えれば、どれだけ技術力があってもムダ骨です。逆に方向さえ合っていれば、小さくても一周回る仕組みのほうが、10日かけて練った大きな提案よりも価値があります。

ありがちな失敗: 午後の最初から、何でもできる大きなプロトタイプを作ろうとする。結局1日かけても何ひとつ動かず、翌日は一からやり直しになる。

もうひとつ付け加えておきます。午後のプロトタイプは、人に見せるためのデモではありません。役目はただひとつ、「この方向で本当にいけるのか」に答えることです。ですから、デザインや配色、文言を磨くことに時間を使う必要はありません。多少粗くても、結論が出せれば十分です。提案が採用されて本番導入が決まってから、じっくり作り込めばいいのです。

夜:「今日何を確かめたか」をはっきり書き残す

1日の締めくくりは振り返りです。FDEの振り返りで答えるべき問いは3つだけです。

今日、何を確かめたか。 午前の観察で立てた仮説に対して、午後のプロトタイプはどんな答えを出したか。仮説は正しかったのか、外れたのか。ひと言で書きます。

明日、何を聞くか。 今日わからなかった工程は、翌朝のすり合わせで聞く新しい質問になります。こうしておけば、翌日のすり合わせをゼロから始めずに済みます。

仮説リストのどこが変わったか。 どれを消したか、何を追加したか、どれがまだ確認待ちか。仮説リストはFDEにとっての作戦マップで、毎日手入れが必要です。

振り返りは長く書かなくてかまいません。数百字もあれば十分ですが、必ず具体的な結論に落とし込みます。「今日はけっこう収穫があった気がする」といった振り返りは、書いていないのと同じです。翌朝、それを材料に誰かと何かをすり合わせることができないからです。

できれば、振り返りの主な結論を翌日、顧客側のキーパーソンに口頭で共有しましょう。あなたが毎日何を進めているのかを相手に知ってもらう。信頼は、こうして1日ずつ積み上がっていきます。

1日を通して見ると

時間帯 主な動き 主な成果物
朝 顧客とその日のゴールをすり合わせる 確認したいことリスト+小さなゴール
午前 業務現場に張り付いて実際の流れを見る 現場の観察メモ
午後 最小限のプロトタイプを組み、小さく一周回す 実際に動く検証結果
夜 振り返りで結論を出し、仮説を更新する 振り返りメモ+明日の質問

お気づきでしょうか。この1日を貫いているのは、観察する、確かめる、振り返るというサイクルです。そして翌日は、少しだけ精度の上がった問いを持って、もう一度同じサイクルを回します。

FDEの1日に、劇的な瞬間はありません。毎日ひとつずつ小さなサイクルを回し、その積み重ねで勝負する仕事です。1か月もすれば、ほかの人がまだ提案内容を議論しているあいだに、FDEの手元には検証済みの小さな結論が20個以上たまっています。この積み上げが複利のように効いてくるのが、この職種の強みです。

3つのセルフチェック:この毎日、続けられそうですか?

  1. 1日の大半を担当者と一緒に過ごし、業務の流れについて話したり、作業を横で見たりすることに抵抗はありませんか?

  2. 午後には自分でデータをつなぎ、コードを書き、プロトタイプを動かす。その負荷に耐えられそうですか?

  3. 毎日振り返りを書き、仮説リストを更新し続ける。そんな規律を保てそうですか?

3つともうなずけるなら、この職種はじっくり調べてみる価値があります。迷うようなら、まずはこのリズムで1日を過ごしてみて、自分に合うかどうかを試してみるのもおすすめです。

夜、デスクライトの下でFDEがマグカップを手に窓の外を眺め、机の上にはチェックリストと手描きのフロー図が広がるノートが置かれているイラスト

次回は「FDEとして活躍するには何を学べばいいのか」を取り上げます。

FDE 30日入門 DAY06「FDEの1日 朝会からリリースまで」

本記事は連載「FDE 30日入門」の第6回です。1日の流れは典型的な例として整理したもので、実際の働き方は会社やプロジェクトによって異なります。

コメントを書き込む

コメントは管理人が確認のうえ、この記事の「みんなのコメント」に掲載する場合があります(即時には表示されません)。 URL・宣伝・誹謗中傷は掲載されません。

この記事が少しでも参考になりましたら、今後のデータ整理・記事作成・サイト改善の励みになります。
無理のない範囲で、OFUSEから応援いただけますと幸いです。

Blog 一覧へ戻る