CFA構想を支える組織づくり ── PdMとの共創とエンジニアチームの再編の裏側

2026年1月21日 10:00

契約という領域が大きく進化しようとしています。
Hubbleが取り組む「CFA（Contract Flow Agent）構想」は、その未来を切り開くための挑戦です。

ただ、この挑戦はAI技術だけで前に進むものではありませんでした。
価値の定義から実装、改善までをスムーズに回すためには、組織そのものの仕組みや関係性をどうつくるかが非常に重要でした。

エンジニア組織のSr. Managerとして、PdM組織の再編と歩調を合わせながらCFA構想を動かすチームづくりに取り組んできた過程を、この記事で少し紹介したいと思います。

なぜ組織づくりがCFA構想の鍵になるのか

契約というドメインは、法務・ビジネス側の判断、運用フロー、AIの特性まで複雑に絡み合います。PdMとエンジニアが密接に価値を擦り合わせ、小さく素早く進める関係が欠かせませんでした。

議論を重ねるなかで強く共有されるようになっていったのは、CFA構想はプロダクトの枠を超えて、組織の動き方まで変えないと前に進まないという感覚でした。

当初 Hubbleの開発体制は、NPSとNew MRRの2つのSquadを中心に動いていました。

しかしCFA構想が進むに連れ、その構造では価値の責任が曖昧になりやすいという課題が見えてきます。

価値の種類ごとに、専任で深掘りしていく必要があるのではないか。そんな議論をCEOを中心に重ねていき、PdM組織はCore、ValueUp、AIの3ドメインへと再構成されました。

エンジニア組織もこれに連動し、メンバーがどこで最も力を発揮できるかを見極めながら配置を整えていきました。もちろん、理想どおりには進まない局面も多々あり、リソース調整や仕様変更への対応など、PdMやAssistant EMと何度も対話しながら進めた場面も少なくありません。

CFA構想の実装は、不確実性の高いAI領域が中心です。仕様や前提が変わりやすく、設計判断が難しい場面も多くありました。

そこで Tech Lead、CTO室、CTOによる多層レビューを導入する案が持ち上がります。当然ながら、レビューが増えればスピードが落ちるのではないかという懸念もありました。

しかし過去のトラブルや開発の停滞を振り返ると、実際に足を引っ張っていたのはレビューの重さではなく、問い合わせ対応や障害調査に多くのリソースが割かれていたことでした。

そこで、多層レビューは単に品質を高めるためではなく、むしろメンバーの迷いを減らして前に進むための仕組みとして機能するという結論に至ります。長期的にはこのほうがスピードを上げることにつながるという共通認識が生まれました。

Coreチームは表に見えにくい部分で、プロダクトを安定して動かすための基盤づくりを進めていました。

その中でも印象的だったのが、ドキュメント権限やユーザー権限まわりのリニューアルです。外から見ると細かな変更に思えるものでも、安心感や拡張性を支える大切なアップデートでした。

特にAIが関わる場面では、情報の扱い方がより重要になるため、この基盤が静かにチーム全体の動きやすさを支えてくれていた実感があります。

こうした組織づくりや日々の議論の積み重ねが、20週連続リリースという成果につながりました。

もちろん順調だったわけではありません。スケジュールがタイトになったり、予期しない調整が必要になったり、さまざまな場面で判断が必要でした。

それでもメンバー一人ひとりが、そのとき自分にできることを考えて動いてくれました。その積み重ねが、最終的な推進力になったと感じています。

HubbleのValuesにある「自律に基づくチームワーク・人間性の好循環」が、ごく自然に現れていた期間だったように思います。

今回の取り組みを通して感じたのは、技術、組織構造、文化、基盤、役割の明確化といった複数の要素が一体になった瞬間にこそ、プロダクトのスピードが生まれるということでした。

CFA構想はまだ続きますが、この一年で“組織としての学習速度”が確かに上がった実感があります。

ここまで読んでいただき、ありがとうございました。

AIを扱うプロダクトは、技術だけでも組織だけでも前には進みません。
人と文化が同じ方向を向き始めたとき、プロダクトの動き方も大きく変わります。

今回の経験が、これから挑戦するどなたかのヒントになれば嬉しいです。
Hubbleでは、これからもCFA構想を通じて、新しい価値を届けていきます。