この記事でわかること
-
現場のモダン化（アジャイル、DevOps等）が組織構造のせいで失敗する理由
-
「スパゲッティ組織」など、組織のアンチパターンを発見し、解決するアプローチ
-
AI時代にマネージャーが注力すべき「フロー効率」と「協働」の再設計
日々発生する開発現場の問題。その多くは、個人のスキルやモチベーションだけではなく、組織の構造的な「ひずみ」に起因している――。
『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』（技術評論社）の著者である松本成幸氏は、エンジニアリングマネージャーとして長年組織改革に携わってきた経験から、そう指摘します。
なぜ現場はアジャイルやDevOpsといったモダンな開発手法を導入しても疲弊してしまうのか。エンジニアの思考法で組織の構造的な問題を解決するには、どうすればいいのか。
「マネージャーの仕事は、メンバーのマネジメントだけではなく、仕組みを設計することも重要」と語る松本氏に、詳しく伺いました。
チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計
出版社：技術評論社 著者：松本 成幸
松本 成幸（mtx2s）
エンジニアリングマネージャー、ソフトウェアエンジニアとしてさまざまなプロジェクトに従事し、開発・保守・運用を幅広く経験。現在は、コンシューマー向けソフトウェアプロダクトを開発する組織のエンジニアリングマネージャー。
【note（@mtx2s）】：https://note.com/mtx2s
【HatenaBlog（@mtx2s）】：https://mtx2s.hatenablog.com/
目次
現場の「痛み」から見えた、技術と組織の不整合
松本さんは、これまで様々な開発現場で組織改革も主導されてきたそうですね。ソフトウェア開発における「組織設計」の重要性を意識されたきっかけや、原体験があれば教えていただけますか。
十数年ほど前、当時開発部長として、オンプレミスのモノリス（※1）なレガシーシステムから、クラウドのマイクロサービス（※2）へ切り替える大規模なリアーキテクチャを手がけた経験が大きいです。
その時に痛感したのは、システムだけを変えてもダメで、組織やプロセスも一緒に変えないといけない、ということでした。大きな変革になるので、当然チェンジマネジメントが必要になります。
※1 モノリス（モノリシック・アーキテクチャ）： すべての機能が一つの大きなプログラムとして構築されているシステム構造。
※2 マイクロサービス： システムを小さな独立したサービスの集合体として設計する手法。
「システムと組織を一緒に変える」というのは、非常に難易度が高いですね。具体的にはどのように進められたのですか？
まず私自身もエンジニアの一人としてチームに入って、一緒に開発や運用を行いました。変化に対する不安や「本当にうまくいくのか？」という疑念を和らげるには、マネージャーも一緒に責任を負う姿勢が重要だと考えたからです。
そして、実際に現場に入って運用までやっていると、いちエンジニアとして業務上の「痛み」を感じ始めるんです。それを辿っていくと、組織がねじれていたり、制度が実態に合っていなかったりすることに起因していると気づき始めました。
具体的にはどのような「痛み」だったのでしょうか？
当時、Webのモダナイズのためにフロントエンドの専門チームを作ったんです。新しいFE技術が次々と登場していたので、キャッチアップと技術力の強化が急務でした。この体制はローンチまではうまく機能していたのですが、サービスが軌道に乗り始めると状況が変わりました。
バックエンドも複数のチームに分かれていたため、ローンチ後に新しい取り組みを進めようとすると、そのたびに関連チーム同士で集まってミーティングを開かなければ、設計もリリースも前に進まない状態になってしまったんです。
それはまさに、本書で「アンチパターン」として紹介されている「水平統合」そのものですね。
おっしゃる通りです。「水平統合」というのは、組織を技術観点（フロントエンド、バックエンド、DBAなど）でチーム分けしている状態です。この構造に陥ると、典型的な症状として「プロジェクトは全チームの参加が基本」になってしまうんです。
その結果、チーム間で頻発する「調整」がボトルネックになっていました。その時は良くても、中長期的に見ると「ミーティングばかりしている」状態になります。これは続けるべきではない、と感じたのが原体験の一つですね。
そうしたご経験が、今回の執筆にも繋がっているわけですね。本書ではアジャイルやDevOps、チームトポロジーといった既存の方法論を「チーム指向の組織設計」というフレームワークで体系化しています。これはなぜでしょうか？
私自身の原体験もそうですが、現場はアジャイルやDevOpsなどを導入して一生懸命モダン化しようと努力しているのに、組織が従来のまま変わっていないがために不整合が起き、結局うまくいかない、という話を多く見聞きしてきました。
そこで本書では、アジャイルやDevOpsを導入した「新しい現場のやり方に、組織の形をうまく合わせるならどうすべきか」という観点で、世の中にある既知の知見を「組織設計」の視点から整理し直しています。
組織をデバッグする。開発のパフォーマンスを蝕む「3つの問題」
書籍では、組織のパフォーマンスを蝕む主要な問題として「非効率なコミュニケーション」「フローの滞留」「粗悪な内部品質」の3つが挙げられています。特にマネージャーが見過ごしがちな問題はどれでしょうか？
見過ごされやすいのは、間違いなく「フローの滞留」です。理由は単純で、他の2つと比べて圧倒的に可視性が低いからです。
具体的にどういうことでしょうか？
コミュニケーションコストが増えると、「ミーティングが多すぎる」という痛みとして現れますし、内部品質の悪化はエンジニアが開発時に直接苦しむ。しかし、「フローの滞留」は何も現場から聞こえてこない。
というのも、フローとは仕事が始まってから終わるまでの流れのことで、これは顧客にとって価値のある作業を行っている「付加価値時間」と、レビュー待ちや調整などで作業が止まっている「待ち時間」の連続なのです。
なるほど。「待ち時間」は、むしろスケジュールが延びて余裕ができた、とさえ思われそうですね。
はい、そこがまさに問題の根深いところです。その「待ち時間」（=フローの滞留）も、起点となるのは構造上の「ひずみ」なんです。これら3つの問題は独立しておらず、同時多発的に、あるいは連鎖して発生します。
例えば、組織構造のひずみによって内部品質が悪化したとします。そのせいで、修正のために複数のチームが調整（コミュニケーション）する必要が出てくるのです。そうすると、本来独立しているはずのチームが依存しあうことでフローが複雑化し、それを嫌って無理な回避設計をすると、さらに内部品質が悪化するという悪循環に陥るわけです。
そうした構造的な問題は、当事者である現場ではなかなか特定が難しそうです。特に、短期的な効率を優先した結果、気づかぬうちに「局所最適の罠」に陥っているケースも多いのではないでしょうか。
おっしゃる通りです。実際、短期の需要変動に対応するために、一人のメンバーが複数プロジェクトを兼務する「メンバー共有」や、必要に応じてエンジニアを柔軟にアサインする「共有リソースプール」といった運用は、多くの組織で自然に選ばれるやり方です。
これらは状況によっては機能する場面もありますし、一見効率的に見えますが、深刻な副作用（スイッチングコストや品質低下）をもたらします。ですが、そもそも「気づかないこと」が一番の問題だと思っています。自組織しか知らないと、比較対象がないので異常に気づけないんです。
外から見ると非常識かもしれないのに「比較できないからわからない」ということですね。
ですから、まずは「相対化」する努力が必要です。転職しなくても、社外のコミュニティやイベントに参加する、あるいは本やブログを読むなどで、外部の「物差し」を手に入れることができます。その上で、本書のアンチパターンを使い、自組織の症状とパターンマッチングしてみるのがおすすめです。
ただし、重要なのは、パターンに当てはまったから即アンチパターンだと決めつけないことです。組織のミッションや環境といったコンテキストを踏まえた上で、「本当にこのパターンを選択すべきか？」を判断することが、局所最適を避けることに繋がります。
スパゲッティ組織の処方箋。コードのように「リファクタリング」できない
アンチパターンの中でも、特に多くの組織が陥りがちな「スパゲッティ組織」についてお伺いします。プロジェクト体制やコミュニケーションが複雑に絡み合った状態ですが、これを整理していく上で何から手をつけるべきでしょうか？
正直なところ、コードのリファクタリングのようにはうまくいきません（笑）。私がもしエンジニアリングマネージャーの立場なら、まずは企画のマネージャーやデザインのマネージャーなど、関連する他部門のマネージャーと定期的に1on1を始めると思います。
そこで、高頻度の見積り依頼対応が発生している、開発チームが兼務者だらけになっているなど、「今、こういう問題が起きている」という認識を共有し、共感してもらう。信頼関係を醸成するところからですね。
すぐに改善に着手するわけではないんですね。
はい。実際に改善が始まるのは、3ヶ月後、半年後になることも珍しくありません。ただ、それでは時間がかかりすぎるので、並行して自分のチームや手の届く範囲からも変えていきます。 例えば、多くの現場でやりがちな「共有リソースプール」、つまり「プロジェクトの度にチームを編成している」 状態をやめてみる、とかですね。
「共有リソースプール」は、リソース効率を考えると一見良さそうに見えてしまいます。
そう見えるのですが、深刻な問題を抱えています。最大の問題は、チームビルディングが不十分なままプロジェクトが始まることです。 その結果、個々のスキルや経験の差がそのままコード品質に反映され、「低品質な設計・実装が混入」しやすくなります。
ですから、まずはプロジェクトにバイネームで個人をアサインすることをやめ、解決策である「プロジェクトを安定したチームにアサインする」ことから始める。一気に全体を変えようとせず、仮説検証するような形で、変えやすいところから小さく進めるのが現実的なアプローチだと思います。
手の届く範囲での改善として、他にできることはありますか？
はい。例えば、「プロダクトバックログ」をチームの窓口として設置することです。これは、「スパゲッティ組織」の典型的な症状である「高頻度の見積もり依頼対応」や「常態的な開発リソース不足」への有効な対策です。 安定したチームを作ったうえで、その窓口として「プロダクトバックログ」を明確に設置し、そこをチームのサービスインタフェースのように扱うのです。
これにより、企画部門からの様々な依頼がそのバックログに集約・整理され、開発チームは明確化された優先順位に基づいて作業に集中できます。これもマネージャーがすぐに着手できる強力な一手です。
「仕組みの設計」で人の負荷を下げる。エンジニア思考のマネジメント術
仕組みを設計する大切さは分かりましたが、メンバーのスキルやモチベーションといった不確定な「人」の要素を、どのように「仕組み」に落とし込んでいけばよいのでしょうか？
大前提として、私は「人のマネジメント」を仕組み化しようとは全く思っていません。世の中には優れたピープルマネジメントの知見がたくさんありますから。
私が社外に対する情報発信でフォーカスしているのは、あくまで組織設計や仕組みの方です。ただ、組織を変えようとすると、結局「人」のマネジメントが必要不可欠になります。 私が「仕組み」でアプローチできると考えているのは、組織設計の改善によって、人の負荷を下げることです。
「仕組み」を改善することで、開発者のストレスや負荷を直接的に下げていくアプローチなんですね。
例えば、組織のひずみを減らして働きやすい環境を作る、内部品質を改善して開発のストレスを減らす、といったことです。そうすれば開発生産性が高まるうえ、結果的にモチベーションの低下を防ぎ、開発者体験を改善できるのではないかと考えています。
確かに、働きにくい仕組みの中で「頑張れ」と言われるより、仕組み自体が改善される方がよほどモチベーションに繋がります。「安定」と「流動性」という一見相反する原則を両立する上で、まずチームを「安定」させることには、どのようなメリットがあるのでしょうか？
チームのメンバー構成や担当業務を「安定」させることは、非常に重要です。チームが心理的安全性を確保し、いわゆるタックマンモデル（※3）でいう「機能期（Performing）」、つまりチームが成熟して最も高いパフォーマンスを発揮できる段階を持続させるために不可欠だからです。
チーム内にノウハウが蓄積されますし、アジャイル開発でよく使われるベロシティ（※4）（チームが一定期間にこなせる作業量の目安）も安定してきます。
※3 タックマンモデル： チームビルディングの発達段階を示したモデル。「形成期」「混乱期」「統一期」「機能期」の4段階を経るとされる。
※4 ベロシティ： アジャイル開発（スクラム）において、1スプリント（開発期間）でチームが完了できた作業量（ポイント）を示す指標。
チームが安定すると計画も立てやすくなりますね。
しかし、その安定が「行き過ぎた固定化」 になると、今度は「あの仕事はAさんしかできない」といった「属人化」の問題を引き起こしてしまうんです。
安定させたい、でも固定化はさせたくない。このジレンマはどう解決すればよいでしょうか？
そこで「流動性」、つまり「少しずつチーム編成を変えていく」という原則が必要になります。 難しく考えすぎず、まずは「1人ずつ」入れ替える くらいで十分だと考えています。
一気にチームを入れ替えると生産性が一時的に大きく落ちてしまいますが、1人ずつであれば、コンフォートゾーンから抜け出す適度な刺激になります。新しい知見がもたらされますし、組織全体の「知識とネットワークが組織的に拡大」 するきっかけにもなります。
変革の「壁」を越える。技術的負債を「ビジネスの言葉」に翻訳する技術
これまで技術分野ごと（例：フロントエンド、バックエンド）に分かれていたチームを、プロダクト開発のために一つのチームにまとめ直す（垂直統合）ときには、メンバーや上層部からの抵抗も予想されます。どのように合意形成を進めていけばよいでしょうか？
粘り強いコミュニケーションと日頃の信頼関係が重要ではあるのですが、よくある失敗パターンが、そもそも組織にある「問題の存在」に合意できていないケースです。
「問題の存在」に合意できていない、ですか。
例えば、人間は「変化」に抵抗する習性を持っており、その最初の抵抗が「そもそも問題であるとは思わない」という不理解であることが多いんです。
この認識のズレをクリアして、「たしかに今、こういう問題が起きている」という共通の認識を持たない限り、提案する解決策に合意してもらうことは難しいでしょう。
「技術的負債」の話がビジネスサイドに伝わらない構図と似ていますね。エンジニアは「問題だ」と認識していても、相手にはそれが「問題」として見えていない。
まさにその通りです。エンジニア以外には「技術的負債」は見えません。ですから、コミュニケーションの際に相手に合わせて問題の視点を切り替える必要があります。
例えば「コード品質が悪い」と主張するのではなく、「品質悪化によって開発に時間がかかり、見積もりの正確性も失われ、結果として新規開発の時間が取れない」というビジネス上の問題に翻訳して伝えるんです。そうすれば、相手も問題の存在に合意しやすくなるはずです。
「問題の存在に合意する」ためには、やはり日頃からの信頼関係が土台になる、ということでしょうか。
その通りです。私が「仕組みの設計」が重要だと言っても、結局それを動かすのは人であり、組織を変えようとすれば必ず人のマネジメントが必要になります。
日頃から1on1などを通じて信頼関係を築き、相手が何に困っているかを理解していなければ、こちらの主張（問題の可視化）も受け入れてもらえません。変革は、そうした地道なコミュニケーションの土台があって初めて可能になります。
AIが変える「効率とフロー」。これからのマネジメントと組織設計
テーマはAIに移ります。GitHub CopilotのようなAIコーディング支援ツールが普及し、開発現場が大きく変わりつつあります。AIとの協働が当たり前になる時代、マネージャーとして特に意識すべきことは何でしょうか？
まず変化に対する感度を高め、素早く適応できる組織を作っておくことです。アジャイルの適用性や経験主義が、ますます重要になります。マネージャー自身もAIに触れ、何が起きているのかを肌感覚で理解しておくことが大切です。
AIによってコーディング速度が上がると、仕様調整やコードレビューなど、別の部分が新たなボトルネックになる可能性が指摘されています。「効率とフロー」の観点から、見直すべき仕組みはありますか？
まさにTOC（制約理論）の世界ですね。ボトルネックじゃないところをいくら早くしても、全体のフローは改善しません。コーディングが速くなっても、コードレビューが詰まればスループットは変わらない。 この流れは、設計・実装の前段階である「プロダクトディスカバリー」（価値探索）にも及びます。
AIはアイデアのプロトタイピングも高速化するため、企画・デザイン・開発をいかに同時並行で進められるか、新しい「協働」を前提とした組織設計がマネージャーに求められます。
AI時代の生産性を考える上で、マネージャーが持つべき最も重要な視点は何でしょうか？
AIで開発速度（アクティビティ）が上がると、スクラムチームのスプリントあたりのアウトプット量が上がりやすくなります。しかし、単純にアウトプット量が増えることを私はポジティブに捉えていません。それはつまり、バッチサイズ（一度に処理する作業量）が大きくなっているからです。『LeanとDevOpsの科学』（※5）にもある通り、検証サイクルを早めるためにはバッチサイズは小さい方がいいと考えられます。
つまり、AIによって生まれた余力を、より多くの機能を作る（ベロシティを上げる）ことに使うのではなく、デプロイ頻度を上げる、スプリント期間を短くするなど、「検証サイクルを短縮する」方へリソースを再配分していく。そこをモニタリングすることこそが、AIの効果的な活用に繋がると思います。
※5 『LeanとDevOpsの科学（The Science of Lean Software and DevOps）』： Nicole Forsgrenらが著した、DevOpsの実践と組織パフォーマンスの関係を科学的に調査した書籍。
ライター
