FDEの1日：クライアント先での実際の仕事の流れ

FDEがクライアント先に入った日、仕事の9割は「動くものを見せること」に向かっている。資料を作る時間よりも、実際に画面を操作してもらう時間を最大化するのがFDEの基本姿勢だ。ここでは製造業の工場事務所に常駐しているFDEの1日を、時間軸に沿って具体的に描く。

結論

FDEの1日は「朝に現場を確認し、午前にニーズを掘り出し、昼に試作し、夕方に動くものを見せる」サイクルで回る。1日に平均3〜4回のデモを挟み、その場でフィードバックをもらって翌朝の実装に反映する。プロジェクト管理票の更新より現場の反応を優先する点が、従来のSIerと根本的に違う。

---

8:30〜10:00 朝の現場確認とスタンドアップ

工場事務所に着いたFDEはまず、製造部の朝礼に同席する。自社の社員ではないが、「今日の製造ライン状況を聞く」という目的でほぼ毎日参加している。昨日の製品検査でラインが2時間停止したことを朝礼の場で知る。前日のデータを見ると、停止直前に品質センサーの異常値が3回記録されていた。

9:00から品質管理チームの担当者2名とスタンドアップミーティングを行う。立って話す15分の場で、前日の進捗と今日やることを共有する。この場でFDEは「センサーデータの異常検知をリアルタイムで通知できるか試してみます」と発言する。プロジェクト計画にはない作業だが、昨日の停止が繰り返されれば損失は大きい。担当者の「それ、今日中にできますか」という反応がゴーサインになる。

スタンドアップが終わったら、昨日のコードに昨夜気づいた不具合を1件直す。作業は30分以内で終わる。デプロイは開発環境にとどめ、本番への反映はデモ後の確認を経てから行うと決めている。

---

10:00〜12:00 要件の深掘りと素早い実装判断

10時から生産管理の主任との1時間のヒアリングに入る。テーマは在庫の引当処理を自動化できるかどうかだ。主任は「毎朝30分かけて手で確認している」と言うが、5分後には「実は引当の優先順位が案件によって変わる」という話が出てきた。これが「言語化できていなかったニーズ」だ。

FDEはその場でノートに簡単な処理フローを書き、「この優先順位のロジックは、どのシステムのどのデータを見れば判断できますか」と聞く。主任が「生産計画のExcelと、受注システムの納期フラグを組み合わせる」と答えたところで、今日の実装スコープが決まる。Excelを直接読んで受注システムのAPIと突き合わせるスクリプトを昼までに作る、という判断だ。

ヒアリングの後半でFDEは「今日の午後3時に試作版を見せます。完成品ではなく、動きを確認するためのものです」と伝える。「完成品ではない」という一言を最初に言っておくことで、クライアント側がデモに対して正しい期待値を持てる。これを省くと、デモ後に「思っていたものと違う」というすれ違いが起きやすい。

FDEに必要なスキルセットの一つに「技術の翻訳力」があるが、ヒアリングの場こそそれが最も試される。担当者の「なんとなく不便」を、1時間で実装可能なスコープに落とし込むのが午前の核心だ。

---

13:00〜15:30 コーディングと動作確認

昼食をとりながら、午前のヒアリングをメモにまとめる。箇条書きで5行、処理の優先順位ロジックを整理する。食後すぐコードを書き始める。

最初の30分でExcelファイルの読み込みとデータ整形を書く。受注システムのAPIはドキュメントが古く、実際のレスポンスと仕様が一部ズレていることがわかった。担当者に確認のチャットを送り、待ち時間に別の処理を先に書く。返信が来たのは14:10、「納期フラグは2種類ある」という情報が加わった。ロジックを修正して再度走らせる。

14:30にスクリプトが通しで動いた。テストデータとして過去1週間の在庫と受注データを使い、手動で確認していた結果と照合する。3件の差異が出たが、2件は計算ロジックの実装ミスで即修正。残り1件は「Excelのデータ入力ミスが元々あった」と気づく。本番運用でも同じ状況が起きるため、エラーハンドリングを追加する。

15:00に動作確認完了。デモ用のスクリプトを整え、出力結果を見やすいCSV形式に変える。画面に表示するだけでなく、担当者が確認しやすいファイル出力もあるほうがいいと判断した。

---

15:30〜17:00 クライアントへのデモと即時フィードバック収集

15:30から生産管理の主任と、声をかけてもらった製造部長の2名に見せる。ノートPCを会議室のモニターに繋ぎ、実際のデータで動かす。処理にかかるのは4秒、出力されたCSVを開くと優先順位順に引当候補が並んでいる。主任が「これ、毎朝自動で届いたら助かる」と言った。

デモ中に製造部長から「このデータ、他のラインの分も同時に処理できるか」という質問が出た。今の実装は1ライン分しか対応していない。FDEはその場で「複数ライン対応にするには設定ファイルを1つ追加すれば対応できます。明日試作します」と答える。その場で判断できたのは、コードの構造を自分で把握しているからだ。

フィードバックは口頭でその場に記録する。「毎朝7:30に自動実行してほしい」「結果はメールでなくチャットツールに届けたい」という要望が2点追加された。これをメモに書きとめ、担当者にも確認してもらう。「今日のデモで見えたこと」「次回のデモまでに対応すること」を3行で整理して共有する。

FDEのコミュニケーションにおいて、デモ後のこの5分の整理が翌日の作業の質を大きく左右する。言った言わないの曖昧さを消すためにも、その場でテキスト化する習慣が重要だ。

---

17:00〜18:00 ドキュメントと翌日の準備

デモが終わったら開発環境に今日の変更をコミットする。コミットメッセージには「在庫引当自動化スクリプト初版：1ライン対応、CSV出力あり」と書く。コードの説明は後で読んだ人が動作を再現できる最低限を書く。過剰なコメントは書かない。

翌日の作業リストを3項目に絞る。複数ライン対応の追加、チャットツールへの通知連携、センサー異常検知の試作だ。3項目のうち、センサー異常検知は朝のスタンドアップで浮上した話で、もとのプロジェクト計画にはない。それでも翌日の最優先に入れる。クライアントにとって今最も痛い課題だからだ。

FDEとアジャイルスプリントでは週単位で計画を見直すが、FDEの現場では1日単位での優先順位の更新が当たり前に起きる。事前の計画を守ることより、今日の現場で見えた課題に素早く対応することを優先する。

退勤前に担当者にSlackで簡単な報告を送る。「今日対応したこと」「明日の予定」「確認してほしいこと」の3点だけ書く。これで担当者が翌朝までに確認事項を処理でき、翌日の朝のスタンドアップをスムーズに始められる。

---

FDEの1日に通底するマインドセット

上で描いた1日には、いくつか共通するパターンがある。

一つ目は「動くものを先に作る」優先度だ。要件が完全に固まる前にコードを書き始め、動かしながら要件を確定させる。ヒアリングが終わった段階で100%の仕様を求めない。60〜70%わかったら動かし、残りは動きを見ながら詰める。この姿勢がないと、クライアントも「何が欲しいか」を言語化しにくい。

二つ目は「その日にフィードバックを受け取る」設計だ。1日の仕事を、夕方のデモでクローズするリズムに設計している。フィードバックが翌週まで待てない。一週間後に間違った方向に進んだものを見せても、修正コストが大きくなるだけだ。毎日短いサイクルで確認することで、ズレが小さいうちに直せる。

三つ目は「言語化されていないニーズを掘り出す対話」だ。クライアントの担当者は技術の専門家ではない。「なんとなく不便」「もっとよくなりそう」という感覚はあっても、それをシステムの要件に変換できない。FDEはその変換を担う。午前のヒアリングで主任が「実は優先順位が案件によって変わる」と言った瞬間がそれにあたる。引き出すための質問の仕方、言葉の選び方が毎日の現場で鍛えられる。

FDEとは何かを読んだとき「コードが書けるコンサルタント」という説明を見た人もいるかもしれない。実態を見ると、コーディングとコミュニケーションが交互に混ざった仕事だとわかる。2時間のコーディングの前後に30分のヒアリングと15分のスタンドアップが挟まり、夕方には1時間のデモで全員の認識を合わせる。

FDEが1日で動かす成果物は、完成品ではなく「確認用の試作品」だ。翌日さらに良くするために、今日動くものを見せる。この繰り返しがプロジェクト全体の精度を高める。

---

FDEの現場に入る前に想定していた「1日の仕事」と、実際の1日の比較を表にまとめる。

時間帯	想定していた仕事	実際の仕事
午前	設計書のレビュー	朝礼参加・スタンドアップ・ヒアリング
午後	実装	実装・動作確認・デモ準備
夕方	進捗報告書作成	デモ・フィードバック収集・翌日計画

報告書を書く時間はほとんどない。その代わりに、担当者への短いSlackメッセージと、コードのコミットメッセージが記録として残る。プロジェクトの透明性を保つための記録は、書類でなく動くコードと短いテキストで担保する。