本記事では、2025年8月27日に開催された技術イベント「開発現場の課題から読み解く、組織設計の考え方」の内容をお届けします。イベントでは、『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』の著者である、松本成幸さんが登壇。多くの開発現場が抱える「コード品質の悪さ」「ミーティングの多さ」「開発の遅さ」といった問題の本質が、なぜ組織設計に起因するのかを解説いただきました。ぜひ本編のアーカイブ動画とあわせてご覧ください。
書籍『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』について
松本：
コンシューマー向けのソフトウェアプロダクトを開発する組織で、エンジニアリングマネージャーをしている松本です。個人ではnoteやはてなブログで、プロダクト開発に関連する情報発信をしています。
先日、技術評論社から『チームの力で組織を動かす ソフトウェア開発を加速するチーム指向の組織設計』を出版しました。現場で起きている問題の多くは、実は組織構造上の問題が原因で起きていて、それをチーム指向の組織設計で正していこう、というのがこの本の趣旨です。また、そのために使えるフレームワークを整理してまとめています。
本日は、書籍の第2〜4章あたりの内容である「現場を蝕む3つの主要な問題」と「16の組織設計アンチパターン」を中心にお話しします。
開発現場が抱える問題とは何か
まず、開発現場が抱える問題とは何でしょうか。例えば、「書き手によってコード品質がばらつく」「十分に理解しないまま既存システムを改修している」「属人化したコードに苦労する」「コードが劣化しすぎて手が出せない」といった状況が挙げられます。
開発現場でこうした問題が起きると、アウトプットは不十分になり、結果としてユーザー価値やビジネス価値、つまりアウトカムやインパクトも小さくなってしまいます。開発生産性の低下、そして開発者体験の悪化にもつながるため、これらを削減し開発生産性を高めることは組織全体の課題です。
組織設計の問題が引き起こす現場の課題
「本当にこれらの問題は組織設計が原因なのか？」と、すぐにはピンとこない方もいるかもしれません。ここからは書籍でも紹介している組織設計のアンチパターンをいくつかご紹介します。
アンチパターン1：保守・運用の分離
開発チームから、本番システムで得られるフィードバック機会を奪い、運用品質への無知を招いてしまう組織構造です。
開発チームが設計・実装・テストまでを担当し、保守・運用チームが本番環境へのデプロイ以降を引き継ぐという分業体制は、決して珍しくありません。しかし、開発中のシステムと本番システムでは性質が大きく異なります。
本番システムでは、「ログ情報が不足し原因分析が難しい」「データ復旧が困難」「サービスレベルが安定しない」などの問題が日々発生します。これらは保守・運用チームにとっては貴重な「学び」ですが、チームが分離していると、この学びが開発側に届きません。
結果として、開発チームは負荷軽減策を知らないまま、配慮に欠けた設計を続け、引き継いだ保守・運用チームは高い負荷に苦しみ続けることになります。これが「システムに保守・運用面の考慮がない」問題に直結します。
AmazonのCTO ワーナー・ヴォゲルス氏は、「開発者に運用責任を与えることで、顧客と技術の両面でサービス品質が大幅に向上した」と述べています。開発者が運用も担うことでフィードバックループが生まれ、品質改善に繋がるのです。
アンチパターン2：水平統合
フロントエンド、バックエンド、データベースのように、技術領域単位でチームを編成するのが「水平統合」です。メンバーの専門性を高める意図で採用されるケースもあります。
専門性は高まりますが、新機能追加は単独領域で完結することが稀なため、エンドツーエンド開発がチーム単独では成立しにくいです。結局、横断プロジェクトとなることが多いですが、チーム横断型のプロジェクトでは、さまざまなコミュニケーションコストが発生します。
また、全チームが同時に着手できるとは限らず、最後に終わるチーム待ちの計画になりがちで、スケジュールも間延びします。また、コミュニケーションコストを嫌ってチーム間での調整を回避するとロジックの重複や分散が起こります。問題は、「複数チームが動かなければ小さな機能も開発できない」ことです。
コンウェイの法則が示す組織とシステムの関係
水平統合で起きるような問題は、「コンウェイの法則」が作用している一例と見ることができます。「システムを設計する組織は、その組織のコミュニケーション構造を模倣した設計を生み出す」というこの法則に従えば、コミュニケーション構造が不適切だとシステムの内部品質にも悪影響が及びます。
ここまでの話で、いくつかの構造が見えてきました。まず、チーム間のコミュニケーションは、仕事のフロー上で発生します。このフローがコミュニケーション構造を発達させ、そのコミュニケーション構造がシステム構造、つまりソフトウェアの内部品質を決定づけます。フローに問題があれば、コミュニケーション構造はいびつになり、コストは増大します。
一方、フローはバリューストリームによって生じています。企画、開発、テスト、デプロイといったさまざまなプロセスを経て、ユーザーに価値を届けるプロダクト開発の一連の流れがバリューストリームであり、パイプラインにおけるジョブのような個々の機能開発がフローです。
ですから、バリューストリームに問題があれば、フローの効率も悪くなるということがイメージできると思います。さらに、バリューストリームを形成しているのは、企画部門、開発部門、品質部門といった部署の配置、つまり組織構造です。
これで全体像が見えました。組織構造がバリューストリームを形成し、バリューストリームがフローを生じさせ、フローがコミュニケーション構造を発達させ、コミュニケーション構造がシステム構造を決定づける。この階層構造になっているため、一番上の組織構造に問題があれば、その問題は下の階層へと連鎖していきます。
そして現場では、「フロー効率の低下」「チーム境界を超えるコミュニケーションコストの増大」「ソフトウェアの内部品質の悪化」という3つの主要な問題として現れるのです。
逆方向の連鎖を生じさせるアンチパターン「ねじれコンウェイ」
実は、この問題の連鎖は逆方向にも起こり得ます。それは、コミュニケーション構造とシステム構造の間にねじれが生じたときです。書籍ではこれを「ねじれコンウェイ」というアンチパターンとして紹介しています。
これは、長年プロダクト開発を続けると、繰り返される追加開発でシステムの依存関係が複雑化したり（システム構造の変化）、チーム体制の見直し（コミュニケーション構造の変化）によって、組織のコミュニケーション構造とシステムの構造が乖離してしまう“ねじれ状態”を指します。
ねじれコンウェイが起きると、機能開発による変更のほとんどがこれまで自チーム内で完結していたのに、他のチーム担当のコード領域にまで広がってしまう。その結果、チーム横断の調整などのコミュニケーションコストが増大し、計画が遅延するのです。
さらにこのねじれ状態は、システム構造がコミュニケーション構造に反発し、コミュニケーションコストの増大やフロー効率の低下を発生させるという、逆方向の連鎖を引き起こしてしまいます。
現場を蝕む3つの主要な問題
結局、開発現場で起きる多くの問題は、突き詰めると次の3つに集約されます。
- フロー効率の低下
- チーム境界を超えるコミュニケーションコストの増大
- ソフトウェアの内部品質の悪化
そして、本書表紙にある「開発の遅さ」はフロー効率低下の症状、「ミーティングの多さ」はコミュニケーションコスト増大の症状、「コード品質の悪さ」は内部品質悪化の症状とそれぞれ捉えることができます。
現場で個別の問題をいくら潰しても、その根本原因である組織設計上の問題が残っていれば、また同じような問題が繰り返されてしまいます。したがって、本当の解決のためには、組織設計そのものに手を入れる必要があります。
組織設計とは、メンバーの分け方を決めるだけではありません。組織から分配する責務は何か、その責務をどうプロセスとして設計・実装するか、プロセスを回すのに必要なスキルや人数はどれくらいか、関わりの深いコードやモジュール、コンポーネントはどれか、といった要素がすべて含まれます。
部門レベルではミッションや業務機能を明確にしますが、チームレベルでは曖昧なことも多い。ですが組織設計を進めるなら、それを意識することが重要です。マネージャーだけでなくチームも協力して作り上げるものだと思います。
組織設計を進める上では、先ほど挙げた「フロー効率の低下」「コミュニケーションコストの増大」「内部品質の悪化」の3つの主要な問題をいかに削減できるか、という視点が不可欠です。それぞれの問題を引き起こすアンチパターンをさらに見ていきましょう。
フロー効率を悪化させるアンチパターン「低凝集な業務機能」
フロー効率とは、作業をどれだけ滞らせずに進められているかを示す尺度です。待ち時間が多いほどフロー効率は悪化し、リードタイムが伸びて市場投入が遅れます。開発プロセスでは、承認待ち、レビュー待ち、他チームの作業完了を待つ同期など、さまざまな滞留が発生しがちです。
フローの滞留はあちこちで起きがちです。企画・分析からデプロイまでの機能開発の場合、企画承認会議を待つ、アーキテクチャレビューを待つ、フロントエンドとバックエンドの両方の開発が終わるのを待ってからテストを始めるための同期といった滞留があります。こういった滞留が積み重なるとフロー効率が下がり、リードタイムが長くなり、リリースが遅れます。
こうした滞留を引き起こしやすいのが、「低凝集な業務機能」という、1つの業務機能（例えばソフトウェア開発）を構成する要素を複数のチームで分担してしまっている状態を指すアンチパターンです。
例えば、開発チームにアーキテクチャを設計する権限はあるものの、それを最終決定する承認権限がない、というケースです。その承認権限は、アーキテクトチームのような別のチームが持っています。
スライドにあるような構成はあくまで一例ですが、この場合、開発チームはアーキテクトチームにレビューを依頼しなければならず、そこに依存関係が生まれます。
こうした承認権限は、少人数で構成されたセントラルな部門やマネージャーに集約されがちで、結果として、複数の開発チームからのレビュー依頼が殺到し、ボトルネック化してしまいます。これが「承認や審査で待たされることが多い」という問題に繋がるのです。
コミュニケーションコストを増大させるアンチパターン「人気者チーム」
次に、チーム境界を超えるコミュニケーションコストです。
コミュニケーションコストは、実際の会議時間だけでなく、資料の準備、事前のすり合わせ、承認会議の開催日待ち、会議後の作業復帰にかかるオーバーヘッドなども含みます。コミュニケーションは不可欠ですが、多すぎると実務時間が削られ、組織のパフォーマンスは低下します。
このコストを増大させる例が、ライブラリや共通サービスなど社内の共有コンポーネントを専任で開発する共有コンポーネント開発チーム、つまり「人気者チーム」が、多くのクライアントチームからの要望に追われてしまうアンチパターンです。
共有コンポーネント開発チームは、各クライアントチームから来る大量の要望の優先順位付けや、関係者間で矛盾する仕様の調整に追われ、チーム外とのコミュニケーションに膨大な時間を奪われてしまいます。これが関係各所との優先度調整や仕様合意に追われてばかり、という問題を生み出します。
内部品質を悪化させるアンチパターン「無制限のコード共有」
最後に、ソフトウェアの内部品質の悪化です。ここでは技術的負債という考え方が役立ちます。内部品質の低いソフトウェアは、将来の機能追加や修正を困難にし、開発生産性の足かせとなります。これが負債の「利息の支払い」です。
低品質なコードは、見積もりが困難で、欠陥が多く、開発に時間がかかってしまいます。これが積み重なると、保守・運用コストは増大し、新しい価値提供にかけられるはずの時間が削られていきます。
こうした負債の中でも特に厄介なのが、スキル不足などから無自覚に抱え込む「無謀で無自覚な負債」や、「品質を犠牲にすれば速く開発できる」という誤った信念で積み上げる「無謀で意図的な負債」です。
このような無謀な負債を抱え込みやすいのが、プロダクトのコードを誰でも制限なく変更可能とするポリシーによる「無制限のコード共有」というアンチパターンです。言い換えると、コード変更権限に関するポリシーが存在しない状態です。
コードの適切な変更には、その領域のドメイン知識や技術、設計思想を理解している必要がありますが、1人のメンバーがその領域すべての知識とスキルをカバーするには認知的負荷が高すぎます。そのような知識やスキルが不十分なメンバーがコードに手を入れてしまうと、設計の一貫性が失われ、コードは混沌化し、一度劣化したコードはオーナーシップの欠如からさらに品質が悪化するという悪循環に陥ります。これが「劣化しすぎてもう誰もコード品質を気にしていない」という絶望的な状況を生み出してしまうのです。
まとめ
本日は6つのアンチパターンを紹介しましたが、書籍では全部で16個取り上げています。
組織設計が扱う範囲は、組織構造から価値の流れを示すバリューストリーム、実際の作業の進み方であるフロー、コミュニケーション構造、最終的なシステム構造など、非常に広範です。さらにチーム内だけを見ても、誰が何を担うかという責務配分、プロセス設計、必要なスキルやメンバー構成、コードの所有権と変更ポリシーなど多岐にわたります。そして、組織設計上の問題は、この階層を順方向にも逆方向にも連鎖するという特徴があります。
特に注目すべきは、「フロー効率の低下」「チーム境界を超えるコミュニケーションコストの増大」「ソフトウェアの内部品質の悪化」という3つの主要な問題です。組織設計を考える際には、この3つの問題をいかにして削減できるか、という視点が最も重要になります。
ただし、今日アンチパターンとして紹介した組織設計が、特定の状況や文脈においてはうまく機能する場合もあることには注意してください。ぜひ、皆さんの現場が抱える問題を、組織設計という武器も駆使して削減していっていただければと思います。
ご清聴ありがとうございました。
Q&A
Q. スタートアップで開発速度を優先し、現在は個人（+AI）単位で並列開発していますが、期待した成果が出ていません。メンバーはチーム体制を望んでいますが、機能提供スピードは落とせず、チームビルディングの時間も担保できません。どのようにチーム型組織へ移行すべきでしょうか？
A. これは難しい問題ですね。本来であれば対話を通じて課題を探りたいところですが、それができない前提でお答えします。
まず、「成果が出ていない」ということは、結局のところ「機能提供のスピードが出ていない」ということだと思いますので、やり方の見直しは必要です。それでも現状が変わらないのは、マネジメント層がエンジニアの感じている課題を自分たちの課題として認識できていないからかもしれません。エンジニア側が発信する課題とマネージャーの視点がずれていると、共感を得られず話が進まないことがあります。
このような場合、訴える側が相手の視点に合わせる努力が必要です。例えば、「コード品質が悪い」とだけ言っても伝わりません。「なぜ品質が悪いとダメなのか」を、最終的にはユーザー価値やビジネス価値に結びつけて言語化することが重要です。
例えば、「コード品質が悪いと、コードの読解や変更に時間がかかり、結果的にリリースが遅れて機会損失に繋がります」とか、「バグ対応に追われて新しい機能開発の時間が取れません」といった形で、マネージャーが課題だと捉えている指標への影響と紐づけて説明すると、話が通りやすくなるはずです。
Q. システムが複雑化すると「全体像をみんなで把握しよう」となりがちですが、どうすればよいでしょうか？
A. システムの規模によります。比較的小さなシステムであれば、全員で全体像を把握するアプローチも良いでしょう。しかし、規模が大きくなると、それは現実的ではありません。その場合は、役割を分担するしかありません。
具体的には、チームごとに担当する領域を明確に分け、各チームがその領域のコード品質に責任を持つ形です。そして、他チームが担当するコードを変更したい場合のポリシーを定めておくと良いでしょう。例えば、「コードの変更自体は他のチームが行っても良いが、最終的なレビューとマージは担当チームが行う。プルリクエストを送ってくれれば対応します」といったルールを設けるのが、バランスの取れたやり方だと思います。
アーカイブ動画・発表資料
イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。
▼動画・資料はこちら
※動画の視聴にはFindyへのログインが必要です。