1. はじめに
この記事は弁護士ドットコム Advent Calendar 2025の 25 日目の記事です。
こんにちは。クラウドサインの EM 戸田です。
2025 年の今、クラウドサインは導入社数 250 万社を超え社会への影響・期待の大きなサービスとなり、エンジニア組織もさらなる成長フェーズに入っています。そんな中、2025 年 4 月から始動したプロダクト開発組織の変革について、今日はお話しします。
こんな人に読んでほしい
- 組織拡大に伴う「壁」に直面している方
- Team Topologies などの組織設計理論に興味がある方
- スケーリングに悩むプロダクト開発組織の方
この記事で扱う組織変革とは
クラウドサインでは、開発組織を以下のように変えていきました。
Before：汎用フィーチャーチーム
- 複数のチームがプロダクトバックログから事業優先度を加味しつつ自由にタスクを選んで開発
- ノウハウが平準化され、柔軟に対応できる
- 全チームがプロダクト全体を担当
After：領域特化型フィーチャーチーム
- チームごとに専門性を持たせ、特定の機能領域を一貫して担当
- ユーザー体験ごとに領域を分け、専門性とオーナーシップを高める
- 各チームが特定領域に集中
この新しい組織構造を、私たちは社内で「領域別組織」と呼んでいますので、 以降は「領域特化型フィーチャーチーム」を「領域別組織」と記載します。
本記事では、この変革の背景、課題、成果、そして未来についてお伝えします。
2. 背景：なぜ変革が必要だったのか
以前の組織構造：汎用フィーチャーチーム
クラウドサインは長らく、汎用フィーチャーチームを採用してきました。これは、複数のスクラムチームがプロダクトバックログの優先度上位から自由にタスクを選び、開発を進める「フィーチャーチーム」です。
汎用フィーチャーチームのメリット
- ノウハウの平準化：各チームにノウハウが平準に蓄積される
- 柔軟性：その時々でもっとも価値の高いものに素早く取り組める
- 職能横断：各職能のプロフェッショナルが集まり、それぞれの専門性を活かせる
これは、スタートアップから成長期の企業ではよくある形で、実際にクラウドサインの成長を支えてきました。
しかし、エンジニア数が増え、プロダクトが巨大化するにつれて、この構造では限界を感じ始めていました。
直面していた3つの課題
課題（1）：認知負荷の高まり
プロダクトが巨大化し、一人のエンジニアがすべての仕様とコードを把握するのが不可能になっていました。
- 「この機能を修正したら、どこに影響が出るの？」
- 「この変更、安全にデプロイできる？」
- 「この仕様、誰が詳しいんだっけ？」
調査に時間がかかり、開発速度が落ちる。しかも、間違った場所を触って障害を起こすリスクも高まっていました。
課題（2）：オーナーシップの希薄化
汎用フィーチャーチームでは「その時々でもっとも価値の高いものに取り組む」という柔軟性がある反面、「機能を作ること」が目的になりがちという課題もありました。
- 「この機能、誰がビジネス数値に責任を持つの？」
- 「リリースしたけど、使われてる？ 効果出てる？」
- 「この領域のユーザーの課題、誰が一番詳しいんだっけ？」
誰がそのビジネス価値に責任を持つのかが曖昧でした。
また同じ領域を異なるチームが担当することで以下のような課題がありました。
- その領域のドメイン知識が分散してしまう
- ユーザーの課題に対する深い理解が育ちにくい
- 「広く浅く」になり、専門性が高まりにくい
もっとも顕著だったのは、最初に開発したチームと異なるチームがその機能の拡張や修正を担当する際に、設計思想の理解に時間がかかったり、コードベースの肥大化によって思わぬ影響範囲を見落としたりするケースが増えたことです。
課題（3）：プロダクトの拡大と一元的な意思決定の限界
クラウドサインというプロダクトは、取引全体のプラットフォームへと進化を続けている中で、 提供する価値も、ユーザーも、どんどん広く多様になっています。 一方で、意思決定の仕組みは従来のままでした。
この状態による問題は以下のとおりです。
（1） 意思決定のオーバーヘッドが大きい
- プロダクト全体で一元的に優先順位を決定
- 意思決定待ちが発生し、スピードが出しづらい
（2） 現場の判断が活きない
- 現場のチームが一番解像度高く課題を理解しているのに、意思決定の裁量が小さい
- 「もっと良い解決策があるのに、提案しづらい。..」
（3） 認知負荷が大きい
- 全エンジニアが全領域を把握する必要がある
- プロダクトが広がるほど、意思決定の負荷が限界を超える
（4） スケールしない
- チーム数を増やしても、意思決定の構造は変わらない
- 依存関係が複雑化し、かえって遅くなる
結果として、「社会に価値を届ける速度」が上がらない状況になってしまいます。
そこで私たちが目指したのは、各領域チームが専門性とオーナーシップを持って、自走できる組織「領域別組織」 でした。
領域別組織の特徴は以下のとおりです。
- ある領域の設計から拡張、保守までを一貫して同じチームが担当
- 専門性が高まることで、認知負荷が軽減される
- より深い知見が蓄積され、開発速度が向上する
専門性が高まることで、認知負荷が軽減され、より深い知見が蓄積されることを期待したのです。
Team Topologiesの思想
この変革は、「Team Topologies」の思想に近いものと言えるでしょう。 Team Topologies では、組織を以下の 4 つのチームタイプで構成し、チームの認知負荷を最適化することを提唱しています。
Stream-Aligned Teams（ストリームアラインドチーム）
- ビジネス価値の流れに沿って編成されたチーム
- ユーザーへの価値提供に直接責任を持つ
Platform Teams（プラットフォームチーム）
- 開発を支える共通基盤を提供するチーム
- Stream-Aligned Teams の認知負荷を下げる
Enabling Teams（イネーブリングチーム）
- チームの能力向上を支援する専門チーム
Complicated-Subsystem Teams（複雑なサブシステムチーム）
- 高度な専門知識が必要な複雑なサブシステムを担当
我々は、この考え方を理解しつつ、私たちの状況に合わせた組織設計を行いました。
Team Topologiesの考え方との対応関係
クラウドサインの組織設計を、わかりやすく Team Topologies の考え方との対応関係を整理してみます。
Stream-Aligned Teams的な役割
代表的な 4 つの領域別チームを紹介します。
| 領域 | 担当する体験 | 主なアクター | 主な関心事 |
|---|---|---|---|
| 締結 | 合意締結 | 送信者・受信者 | スムーズな締結完了 |
| 書類管理 | 契約・原本管理 | 書類管理者 | 検索性・履行管理 |
| IAM | 組織・管理 | 組織管理者 | 簡単な設定・運用 |
| Integration | システム間連携 | 開発者 | 自由度高い統合 |
Complicated-Subsystem Teams的な役割
- Technology1/2：高度な専門技術、技術的負債の解消etc
Platform Teams的な役割
- SRE：インフラ、監視、デプロイ自動化etc
- Technology1/2：共通基盤や開発環境の整備etc
- IAM：共通認証基盤etc
Enabling Teams的な役割
- エンジニアリングオフィス：開発者体験の向上を目的とした組織
この設計により、各領域チームは認知負荷を下げつつ、ビジネス価値の提供に集中できる環境を目指しました。
結果として、まだ兼務もあり完全に理論通りというわけではありませんが、チームの認知負荷を下げつつ、ユーザーへの価値提供を最大化するという思想は共通するものとなっています。
なぜ「ユーザー体験」で分けるのか
領域別組織のガイドラインには、明確に目的が書かれています。
- ドメイン知識と内部仕様の知見をためやすくすること
- 開発チームのオーナーシップを高めること
機能やレイヤーで分けるのではなく、「誰のどのような体験で直面する課題か」で分けることで、チームはそのユーザーの専門家になることを目指しました。
なぜ「オーナーシップ」が重要なのか
従来の体制では、プロダクト全体でバックログを管理し、各チームは「優先度が高いエピックを捌く」形でした。 これだと以下のような課題がありました。
- 当事者意識が薄れる：「言われたものを作る」になりがち
- 最適解を提案しづらい：現場が一番詳しいのに、意思決定権がない
- スピードが出ない：意思決定待ちの発生により、判断・行動の遅れにつながる
私たちが実現したかったのは、領域チーム主体で優先順位とスコープを判断・決定できる組織です。 そのために、以下の権限を領域チームに移譲したのです。
- ビジョン・ロードマップの策定権限
- バックログの管理権限
- 優先順位の決定権限
つまり「何を作るか」から「どう作るか」まで、領域チームが責任を持って決められるようにしたということです。
3. 移行期：直面した課題
とはいえ組織設計って、実際運用させていくのが難しいですよね。 ここでは、領域別組織への移行で直面した課題を、正直にお伝えします。
コンウェイの法則との戦い
「システムを設計する組織は、その組織のコミュニケーション構造をコピーした構造の設計を生み出す」 — コンウェイの法則
組織図を書き換えても、システムアーキテクチャ（モノリスな部分など）はすぐには変わりません。
領域別チームに分けたものの、コードベースやデータはきれいに分離はできておらず依存関係が整理できているとは言えない状況です。 中長期的に今後いろいろな手法でこの問題と向き合っていく必要があります。
境界線の設計
グレーゾーンの発生
例えば以下のようなケースです。
- 「契約書のプレビュー機能」はどの領域チームの担当？
- 「組織メンバー追加の Web API」はどの領域チームの担当？
こういったグレーゾーンが生まれると、どちらのチームも手を出しづらくなってしまいます。 完璧な境界線なんて最初から引けないので、運用しながら最適化していくしかありません。
4. 現在：領域別組織が生んだ成果
さて、課題はたくさんありますが、成果も出ています。 ここでは、領域別組織に移行して約 9 ヶ月経った今、どんな変化が起きているかをお伝えします。
成果（1）：意思決定スピードの向上と権限移譲の効果
PdMとエンジニアの距離が以前より近くなりました。そして、領域チーム全員で意思決定する意識が高くなりました。
Before（汎用フィーチャーチーム）
- エピックリストはプロダクト全体で管理
- エピックの優先順位も全体で決定
- 各チームは「価値の高いものを自由に選んで作る」
- でも、同じ領域を異なるチームが担当することもある
After（領域別組織）
- 領域チームがバックログを管理
- 領域チーム主体で優先順位とスコープを決定
- 「何を作るか」から考えられる
- 同じ領域を一貫して同じチームが担当
意思決定のリードタイムが短縮され、市場の変化への素早い対応が可能になってきています。
成果（2）：専門性とオーナーシップの向上
「広く浅く」から「特定領域のプロフェッショナル」へ。そして、「作る人」から「責任を持つ人」へ。
これが、領域別組織の最大の効果です。
ドメイン知識の深化
領域別チームに所属することで、チームメンバーはその領域のビジネスロジックに深く入り込む意識を高くもつようになりました。
従来は「優先度高いエピックの決定を待つ」姿勢が強かったのですが、今は以下のような問いを立てるようになりました。
- 「この領域で、次に解決すべき課題は何か」
- 「ユーザーの声を聞いて、優先順位を変えるべきじゃないか」
- 「この機能は、もっとシンプルな実装で実現できる」
チームメンバーが「How（技術）」だけでなく「Why（課題）」を理解し、自ら提案する場面も以前より見かけるようになってきました。
権限移譲の効果
ビジョン・ロードマップ・バックログの権限を領域チームに移譲したことで、当事者意識が高まりました。
- 「自分たちの領域は、自分たちで良くする」
- 「ユーザーの課題を、自分たちで見つけて解決する」
- 「リリースした機能の効果を、自分たちで測定して改善する」
これは「ミニスタートアップ」のマインドセットに近いのではないでしょうか。
成果（3）：リリース数の増加と自律性の向上
定量的な振り返りでも明確に成果が出ています。
| 指標 | 成果 | 評価 |
|---|---|---|
| 機能リリース数 | 増加傾向 | 良好 |
| 自律的な改善 | エピックリスト以外の開発にも手をつけられるようになった | 良好 |
| デプロイ頻度 | 1日30回以上 | 良好 |
※デプロイ頻度が高いのは、元々のデプロイ戦略が有効に機能しているのがベースとしてあります。
領域別チームの自律的な意思決定・開発・リリースが可能になり、待ち時間の削減につながりました。
具体例：エピックリスト以外の改善
以前は「エピックリスト（優先度の高い機能開発）」に追われて、細かい改善に手が回りませんでした。
でも今は、各領域別チーム が自分たちの判断で以下のような改善を実施しています。
- 技術的負債の解消
- ユーザビリティの改善
- パフォーマンスチューニング
といった「作るべきもの」を自分たちで見つけて実行できるようになりました。 AI 活用も進んでいるので、その相乗効果という側面もあります。
5. 未来：プロダクト組織としての理想状態
私たちが目指す理想状態は、領域別組織のガイドラインに明確に書かれています。
これからもプロダクト領域が拡大する中で、広範囲かつ大小様々な粒度のニーズ・課題・機会に、スピーディに応えられるプロダクト開発組織でありたい
具体的には以下のとおりです。
領域チーム主体で優先順位とスコープを判断・決定できる
- ビジョン・ロードマップ・バックログを自分たちで管理
- 「何を作るか」から「どう作るか」まで、チームが責任を持つ
領域チーム主体で最適なソリューションを提案・構築できる
- ユーザーの課題を深く理解し、技術で解決する
- 「言われたものを作る」ではなく「最適解を提案する」
スピード（アジリティ）とスケーラビリティを両立
- 領域チームを増やすことで、並行して価値を届けられる
- 新たな領域へのチャレンジを通じて、提供価値を最大化
組織も進化し続ける
大切なのは、組織を固定化しないこと。
- 事業フェーズが変われば、組織も変わる
- 技術が進化すれば、開発プロセスも変わる
- メンバーが増えれば、コミュニケーション構造も変わる
技術で取引の形を変えていくために、組織も進化し続けることが求められます。
6. おわりに
最後になりますが、組織に「正解」はありません。
- スタートアップ期には、汎用フィーチャーチームが最適かもしれません
- 成長期には、領域別組織が効果的かもしれません
- その先は、また別の形が必要かもしれません
大切なのは、その時のフェーズに合わせた「最適解」を選び続けることです。
- 「今の組織構造は、事業目標達成に最適か」
- 「エンジニアが最高のパフォーマンスを発揮できているか」
- 「ユーザーに価値を届けるために、何が必要か」
技術で社会を変える。取引の形を変える。そして、プロダクトと組織が進化し続ける。
クラウドサインの組織変革の旅は、まだまだ続きます。
最後まで読んでいただき、ありがとうございました。
本記事が組織変革に挑戦されている方々の参考になれば幸いです。
