前回の記事で、FDEとSESの違いは「工数提供」か「成果責任」かという契約の性質にある、という話をした。では、その成果責任を果たせる動き方は、どうやって身につけるのか。
私自身、最初からFDE的に動けていたわけではない。実装は問題なくできても、稟議の通し方や情シスの巻き込み方は、現場で失敗しながら学んだ。ここでは、その過程で「これが分岐点だった」と思う変化を、身につけやすい順に書く。
目次
1. 「言われたことをやる」から「言われる前に潰す」へ
SES的な仕事の進め方は、要件や指示があって、それを正確にこなすことが評価される。FDE的な動き方の最初の分岐点は、指示が来る前に「次にボトルネックになりそうなこと」を自分で見つけて動くことだ。
これは才能の話ではなく、視点の切り替えの話だ。作業を「今日のタスクを終わらせる」単位で見るのではなく、「このプロジェクトが止まるとしたら、どこで止まるか」という単位で見る。稟議で止まるか、情シスで止まるか、定着で止まるか——前回・前々回の記事で書いた3つのボトルネックを、自分のプロジェクトに当てはめて先回りする癖をつけるところから始まる。
2. 技術以外の会話に混ざる
エンジニアとして現場に入ると、放っておいても技術の会話は耳に入ってくる。だが稟議の状況や、決裁者が何を気にしているかといった情報は、意識して取りに行かないと入ってこない。
私が変わったきっかけは、単純に「その会話に混ざる」ことだった。技術的な打ち合わせが終わった後、事業部門の担当者が次の会議に向けて何を心配しているかを聞く。情シスの窓口が、どんな理由で過去に他の案件を止めたことがあるかを聞く。これは営業活動ではなく、プロジェクトを止めないための情報収集だ。エンジニアの役割の外側だと思って避けていると、いつまでもボトルネックが見えてこない。
3. 「動くもの」と「稟議で通るもの」の違いを意識する
技術的に正しいものと、組織の中で承認されるものは、必ずしも一致しない。デモでは省略した前提が、稟議では致命的な懸念点になることがある。
これを身につける具体的な練習は、自分が作った成果物を「もしこれが決裁者の机に載ったら、何を聞かれるか」という目で見直すことだ。費用対効果は説明できるか。リスクは想定されているか。失敗したときの被害は限定されているか。技術のレビューとは別に、この視点でのセルフレビューを一つ加えるだけで、稟議の通りやすさは変わってくる。
4. 小さく「巻き取る」経験を積む
いきなり大きな案件でFDE的に動くのは難しい。まずは小さいスコープで、自分の職掌を少しだけはみ出して巻き取ってみるのがいい。
会議の議事録を、決裁者向けの一枚資料に整えてみる。情シスへの申請を、聞かれる前に自分から早めに出してみる。定着後の問い合わせ窓口を、頼まれる前に用意しておく。こうした小さな「巻き取り」の成功体験が積み重なると、自然と自分の担当範囲の捉え方が広がっていく。
まとめ
FDE的な動き方は、特別な才能というより、視点と習慣の積み重ねだ。
- 指示が来る前にボトルネックを見つけて動く
- 技術以外の会話に意識して混ざる
- 「動くもの」と「稟議で通るもの」の違いを意識する
- 小さく職掌をはみ出して巻き取る経験を積む
これらは、今の現場を離れなくても始められる。FDEというタイトルがなくても、今日から実践できることばかりだ。
FDE的な動き方を、実際にクライアントワークの現場でどう活かしているかは、これまでの記事（理由1〜3、PoC止まりの構造）で書いている。あわせて読んでもらえると、動き方のイメージがより具体的になるはずだ。
企業のAI導入をFDEとして支援しています。ご相談はサービス紹介ページから。
