要件定義書が固まってから作り始める。
受託開発の世界で長く当たり前とされてきた順番です。
ところが FDE（Forward Deployed Engineer）の紹介記事を読んでいると、この順番がほとんど出てきません。
代わりに並ぶのは、顧客の隣で手を動かしながら確かめていくという表現ばかり。
「要件が決まらないのに、何を作るんだ？」と最初は引っかかりました。
その引っかかりを、公開されている一次情報でほどいてみます。
反復の速さそのものが、この役割を選ぶ理由になっている
Palantir が公開している FDSE（Forward Deployed Software Engineer）へのインタビュー記事に、分かりやすい一節がありました。
なぜ従来型のソフトウェアエンジニアではなくこの役割を選んだのか、という問いへの答えがこうでした。
解決策を作ることと、それが実際に動いているのを見ることのあいだのサイクルが速いから。
顧客と手を取り合って反復することの即座のフィードバックによって、とても短い時間で大きな影響を生み出せる、という説明です。
同記事では例として、新型コロナ対応の取り組みで数日以内に意味のある解決策を展開して稼働させる必要があった件が挙げられていました。
数か月ではなく数日。
この時間感覚では、要件定義書を先に完成させるという工程がそもそも成立しません。
要件が固まるのを待っている間に、解くべき問題のほうが動いてしまうわけです。
動くものを先に出せるのは、ゼロから作らないから
とはいえ「速く出す」だけなら、品質を捨てているのではないかという疑いも湧きます。
同記事はコンサルタントとの違いを問われた場面で、そこを明確に否定していました。
FDSE の手の中では Palantir の製品である Foundry と Gotham がすでに組み上がった遊び場として機能し、柔軟かつ効率的に問題を解ける、という説明です。
コンサルタントと違ってほとんどの部品を既製のまま組み合わせられるので、顧客ごとに車輪を再発明して何年もかけたつぎはぎを作る必要がない。
だからこそ、機能の正しい構成を組み立てることに集中できる、と続きます。
ここが腑に落ちる部分でした。
要件を待たずに動かせるのは度胸の問題ではなく、土台となるプラットフォームを持っているという構造の問題なのですね。
裏を返せば、既製の土台を持たない現場で同じ進め方を真似ると、単なる行き当たりばったりになります。
自分の環境で使える「すでに組み上がった部分」がどこまであるのかを、先に数えておきたいところ。
現場で作るからといって、工学を捨てるわけではない
速さを優先すると、作ったものが翌月には誰も触れない状態になりがちです。
その懸念について、同記事は伝統的なソフトウェアエンジニアリングの考え方を日々の仕事に取り入れているかと問われ、「その通り」と答えています。
支えている仕事が非常に繊細で重要なものである以上、きちんと動くソフトウェアを展開しなければならない。
そしてそれは、現場で厳格なソフトウェアエンジニアリングの原則を適用することでしか実現しない、という整理でした。
具体的に挙がっていたのは、エンジニアリングレビュー、コードレビュー、デプロイしやすさの最適化、そして本番システムの保守と監視。
試作品を本番に置き去りにしないための仕掛けが、最初から仕事の内側に入っている形です。
「早く出す」と「雑に出す」は別物だ、と言い換えてもよいでしょう。
現場で作り込んだものを、製品へ戻す
FDE の進め方でもうひとつ特徴的なのが、作ったものの行き先です。
同記事は FDSE の重要な責務として、現場で得た技術的な知見を事業開発チームと製品開発チームへ共有することを挙げています。
特定の顧客向けに構成したものが、ほかの多くの顧客にも役立つと分かる場面は多い。
実際、最も価値のある製品への追加のいくつかは、この流れで現場から生まれたと書かれていました。
共有によって、ほかの FDSE がプラットフォームに何が既にあるのかを把握でき、その上に積み増せるようになる。
つまり一顧客のための作り込みが、次の顧客の初期値になるという循環です。
この視点があると、目の前の実装をどう書くかの判断も変わります。
顧客固有の事情に貼り付いた書き方をするのか、あとで一般化できる形に寄せておくのか。
役割そのものの定義や、なぜこの職種が生まれたのかという背景は、前の記事にまとめました。
いちばん難しいのは、何をやらないか決めること
進め方の話の最後に、同記事が「この役割でいちばん難しいのは何か」と問われた場面を置いておきます。
答えは、集中する先を定めること。
製品の機能も顧客のニーズも変わり続けるため、解くべき問題がほぼ無限にある状態になる。
その中から、自分の専門性や快適さに関係なく、いちばん価値のあるものを一貫して見極めて実行する必要がある、という説明でした。
要件定義書がない進め方は、優先順位づけを自分で引き受けるという負債とセットなのですね。
誰かが決めた順番を実装するのとは、必要な筋肉がまるで違う。
自分に足りないのはこの部分だな、と読みながら考えていました。
最後に
FDE が要件の確定を待たずに動けるのは、無鉄砲だからではありませんでした。
既製の土台があるから短い周期で回せて、現場でも工学の原則を適用するから壊れず、作ったものを製品へ戻すから次が速くなる。
そして確定した要件の代わりに、優先順位を決める責任が乗ってくるという構造でした。
手を動かして確かめる進め方は、土台と規律と判断がそろって初めて成立する、という順番で覚えておきたいところ。
以上です。
コメントを残す