AI時代のエンジニア組織のかたち

はじめに

こんにちは。Repro Booster のプロダクトマネージャーのEdward Fox（@edwardkenfox）です。

私たちのチームが開発しているプロダクト Repro Booster は、ありがたいことに事業・製品ともに順調な成長を続けており、導入企業数も右肩上がりで増えています。

今回の記事では、Repro Boosterの開発チームがこれまでどのような目的のもとで組織を変化させてきたのか、その歴史を振り返りつつ、現在進めている新しい組織的なチャレンジについて共有したいと思います。特に「技術を使って事業に貢献したい」と考えているエンジニアの方に、何かしらヒントとなるような情報をお届けできれば幸いです。また「AI時代において、プロダクト開発組織はどうあるべきか」という問いに私たちなりに向き合ってきた過程の記録としてもお伝えできればと思います。

Booster開発チームの歩み

これまでのBooster開発チームの歴史は、組織のスケールと役割の変化に伴い、大きく3つのフェーズに分類できます。

フェーズ1：黎明期

Repro Boosterという製品・事業は、私がプロトタイプを作ったところから始まりました。役員の1人に「こんなものを作りたい」と提案したところ、好感触を得て水面下でプロジェクトがスタートします。数ヶ月間、通常業務と並行してプロダクトの種となるものを作り上げていきました。

その後正式にプロジェクト化されたタイミングで、現在の事業責任者がジョインします。そこからは彼と二人三脚で、プロダクト開発と事業開発を同時に推し進めることになりました。この時期の私は、コードを書く業務はもちろんのこと、価格設計や各種アライアンスなど、役割の壁を設けずに事業のあらゆる側面に深くコミットしていました。

フェーズ2：チーム形成期

お客様とのPoC（概念実証）を経て、いよいよベータ版としてローンチする段階で正式な開発チームが発足しました。それまで専任は私1人だった状態から3人に増え、開発チームとしての活動が始まります。

この最初の1〜2年は、私が中心となって事業責任者と協議のうえプロダクトのロードマップを策定し、それを具体的なタスクやプロジェクト単位にブレイクダウンしてメンバーに割り振る、という進め方が主でした。製品の提供価値が形作られていく中で、メンバーのコミットメントも向上し、チーム全体に技術的なナレッジやドメイン知識が着実に蓄積されていきます。

フェーズ3：成熟期

ナレッジが溜まるにつれ、チームの動き方に変化が現れます。細かい機能開発だけでなく、プロダクトロードマップの根幹に関わる部分に対しても、メンバーから自発的な提案が盛り込まれるようになったのです。

メンバーそれぞれが「今、事業にとって何が必要か」「どのような価値を誰に届けるべきか」を俯瞰し、足りない要素を自ら提案する。そして、提案した本人がプロジェクトオーナーとなり、開発、リリース、顧客との検証までのPDCAサイクルを一気通貫で担当します。私はこれを「フルサイクル開発」や「1人1プロジェクトオーナー制」などと呼んでいました。事業に極めて近い距離から仮説検証のサイクルを回すこの体制は、少人数の開発チームとしては非常に成熟した段階だったと言えます。

フェーズ3の課題

しかし、この体制にも課題はありました。個々のプロジェクトが局所最適化しがちになり、開発・リリースした機能の Go-to-Market （市場投入）がおろそかになったり、開発チーム全体としてどれだけ事業成長に貢献できているのか、その総体としてのインパクトが見えづらくなってしまったのです。

フェーズ4: テーマ・KPIで駆動する組織

そこで私たちは組織体制をさらに進化させ、より開発組織が事業にコミットする形で運営することにしました。

具体的には、商談成約率（成約数 ÷ 商談数）であったり、成約から導入完了までのリードタイムといった、事業のPL（損益計算書）に関わる重要指標についてKPIを各エンジニアが持つという体制です。

ただし、エンジニアがPL上の指標をそのまま予算として持ってしまうと、短期的な数字の最適化ばかりを追求し、中長期的なプロダクトの伸び代やシステムの健康状態を損ねるリスクがあります。そのため、指標を一つ抽象化した「開発テーマ」を設け、そこに対してKPIを設定するアプローチを取っています。

例としては、次のようなイメージです。

背景・課題:
- Boosterにおいて、導入企業の「速度改善効果」や「収益改善効果」を最大化することは成約率や継続率に左右する極めて重要な指標である
開発テーマ:
- Booster導入による改善効果の最大化
紐づくKPI:
- 導入サイト全体の平均改善率

このように設計することで、単一の指標に局所最適化した活動に終始するのを避けつつ、プロダクトの全体最適となる活動を自律的に計画・実行できるようになります。他にも「導入のしやすさを向上する」というテーマであれば、「導入リードタイムの削減」をKPIに置く、といった具合です。

各メンバーは自身の担当テーマとKPIを持ち、その下にぶら下がる複数のプロジェクト（機能開発、リファクタリング、リリース後の検証など）を自身の責任と権限でロードマップ化し、推進していきます。各テーマのKPIに局所最適化しそうになるリスクは常にありますが、製品戦略を担うプロダクトマネージャーである私と事業責任者が連携し、全体のバランスや実現可能性を踏まえた調整を行います。全体最適な方向への舵取りは支援しますが、実行や意思決定の主導権はあくまでメンバーにあります。

小さなチームで、大きな仕事を

現在、Booster事業部は全体で20名ほどの小さな組織です。私の好きな本に「小さなチーム、大きな仕事　―働き方の新スタンダード―（原題: Rework）」がありますが、まさにこの本に書かれた思想と同じです。

事業の生産性を最大化し、飛躍的な成長を遂げるためには、腰の重い大きな組織を作るよりも、小さなチームでそれぞれが責任を持ってクイックにPDCAを回せる環境の方が圧倒的に強いと考えています。AI時代と言われる昨今において、この傾向はより強まるという自負もあります。プロダクト開発が事業のより深い領域に踏み込んで責任を負う。この形こそが Repro Booster という製品そして事業を大きく前に推進する力になると考えています。

Boosterの特性とAI活用

なぜここまで開発組織が事業に踏み込む必要があるのでしょうか。それはRepro Boosterというプロダクトの特性に起因しています。

Repro Boosterというプロダクトの提供価値は、良くも悪くも残酷なほど定量的な数字として現れます。速度を改善するツールである以上、導入によって何パーセント速度が向上したか、それによってどれだけ導入サイトに恩恵があったのか、すべて可視化されるからです。

個々の開発や活動が顧客にどれだけの価値をもたらしたか、そしてそれがどう事業に貢献したかが冷徹なまでに数字に出てくる環境だからこそ、私たちは「作ったけれど使われない」「効果が出ない」という停滞を防ぐことができています。開発が事業に踏み込む必然性が、プロダクトの提供価値レベルで組み込まれている、とも言えるでしょう。

また昨今のAI活用の潮流において、Booster事業部も例外なく多くの場面でAIを利用しています。

開発業務の生産性向上はもちろん、プロダクトでのAI利用もいくつか仕込んでいるところです。事業とプロダクト開発の距離が近いからこそ、技術やAIをレバレッジに「事業活動におけるどの変数を、どのように最適化するか」「あるいは新しい変数を持ち込むことで、どんな化学反応を起こせるか」という試行錯誤のインパクトは、そのまま事業への貢献に直結します。

こちらの記事にも書いたように、多くの場面でAIの助けを借りて生産性を上げ、より本質的な価値の開発に時間を割けるようになったからこそ、効率改善で満足するのではなく提供価値を大きくするところまで開発組織として踏み込むことができた、とも言い換えられるかもしれません。「AIはコードを書けても、その責任は負ってくれない」という話を耳にすることも多いですが、その責任を我々プロダクト開発を行う人間が能動的に取りに行く動きでもあります。

技術とビジネスの振幅

こうした方針を提示すると、「エンジニアが事業に入り込みすぎると、その反動で技術的な正しさがないがしろにされてしまうのではないか？」という懸念を持たれることがあります。

私の考えはむしろ逆です。事業全体の仕組みについて解像度が上がるほど、ある課題を達成するために最適なアプローチは何かという技術的な意思決定も研ぎ澄まされる、と考えています。

ビジネスドメインを深く理解することは、システム設計におけるコンテキスト境界をどこにどう引くべきか、正確に見極めることに通じます。事業の力学であったり、「どこが可変な要素で、どこは不変な要素か」を肌感覚として持てているからこそ、どのモジュールを疎に保つか、あるいはどこに堅牢性を持たせるべきか、適切な判断が可能になります。こうした前提があって初めて、事業に推進力を与えるアーキテクチャが設計できる、と私は信じています。

当然、フェーズによって「ビジネス課題を解決するための開発に寄せる時期」と「純粋に技術的な課題や困難に向き合う時期」とがあります。感覚としては、3〜6ヶ月スパンでそのフェーズを行き来している印象です。このフェーズ行き来の振幅をどれだけ大きくできるか、そして状況に応じて自由に行き来しながらPDCAの回転数を上げられるか、が重要です。振幅（ビジネスと技術の振れ幅） × 周波数（検証サイクルの速さ） = 出力の大きさ（アウトカム）、というイメージですね。

余談: スキルの複利

本筋の話題からは少し逸れますが、エンジニアのキャリアという観点からも、この取り組みには大きなメリットがあると考えています。

技術一辺倒、あるいはビジネス一辺倒のスキルは、どうしても「単利」での成長にとどまりがちです。しかし、製品開発の裏にある事業の力学を理解し、それを高度なアーキテクチャやコードに翻訳できるエンジニアのスキルと価値は、複利の構造で膨れ上がっていきます。異なる領域の知識と経験が掛け合わさることで、1つの課題に対してアプローチできる引き出しが乗算的に増えていくからです。