そうであるなら、現場で営まれる改善に向けた努力は “対症療法” にしかなり得ない。一時的に症状を緩和できても、しばらくすれば問題はぶり返す。現場はそれを再び抑えにかかる。これではまるで、終わりのないモグラたたきだ。
組織設計の改善による “原因療法” が必要なのだ。もちろん対症療法も必要ではある。しかし、根本原因を取り除かなければ、そこから生じる問題が現場を苦しめ、ソフトウェア開発の足かせであり続ける。それはビジネスの足かせでもある。
だから、組織設計に携わるマネージャーには、現場に現れる症状から組織設計上の問題を読み解く力が問われる。そして、現場のチームも巻き込んで、組織の欠陥修正や、組織のリファクタリング、リアーキテクティングに取り組むのだ。
- 参考資料
- 組織設計のひずみは現場に問題をもたらす
- 現場を悩ませる主要な問題は三つに分けられる
- 従来型の組織が持つ文化・価値観が問題の解消を阻む
- 組織設計がひずむ理由は四つに大別できる
- “気づきにくい” ので「組織設計アンチパターン」を活用する
- 組織設計はマネージャーとチームの協働で進める
- さいごに
参考資料
本稿は、@bufferingsさんによる記事「チームの問題の原因は外側にあることが多いよなぁ。「チームの力で組織を動かす」を読んだ。 - Mitsuyuki.Shiiba」で拙著から引用いただいた「組織設計のひずみによって生じた問題は現場だけで解決することはできない」をテーマにして書いた。こちらのブログ記事も参考いただきたい。
引用元となった拙著は、2025年8月25日に発売されたこちら。
また最近、本書にちなんだ二つのイベントに登壇し、組織設計をテーマに発表した。本稿では、その登壇資料（下記二点）も用いながら、組織設計のひずみについて考えていく。
- 「モダンな現場と従来型の組織——そこに生じる "不整合" を解消してこそチームがパフォーマンスを発揮できる」Forkwell Library#104, 2025年8月25日
- 「現場が抱える様々な問題は “組織設計上” の問題によって生じていることがある」開発現場の課題から読み解く、組織設計の考え方 - Findy, 2025年8月27日
組織設計のひずみは現場に問題をもたらす
現場で生じる問題を、組織設計と結びつけて見る人は多くない。だが、それは確実に起きている。
例1: FEとBEを分ける体制がロジックを重複・分散させる
たとえば、バックエンド（BE）のロジックに変更を加えてテストしたら、なぜか変更前の挙動のままの箇所がある、なんて経験はないだろうか。原因を探ってみると、フロントエンド（FE）にも同じロジックがある。つまり、ロジックが重複し、保守性を低下させているのだ。
こうした症状は、FE開発とBE開発でチームを分けた体制で起こりやすい。設計を綿密にチーム間で議論するよりも、自分たちの手が届く範囲でやってしまった方が手っ取り早い。そういう意識が働く。時間に追われていればなおさらだ。これはコンウェイの法則の具体例でもある。
この体制には、単独チームでエンドツーエンドの機能開発ができないという欠点がある。新機能の開発は、FEだけ、あるいはBEだけで済むとは限らず、両方、またはデータベースまで含めて変更することも多い。
だから、チーム横断でプロジェクトを進めるしかない。その結果、チーム間の調整によるコミュニケーションコストがかさむ。けれど、そこにばかり時間を取られると、開発時間が奪われる。それを嫌って近道を選んだ結果が、ロジックの重複や分散につながるのだ。
例2: 従来型のままの組織の文化や価値観がスクラムを形骸化させる
他にも例はある。
ソフトウェア開発の現場は進化し続けている。それは、開発プロセスやデリバリー手法、アーキテクチャなど、多岐にわたる。昨今のコーディングにおける生成AIの活用がよい例だろう。
それでも、組織が従来のままだと、こうしたモダナイズは空回りしやすい。
その典型例が、開発だけでスクラムを回している状態だろう。企画・設計やテストは相変わらずフェーズ分断で進み、スプリントレビューにすら、当事者（企画、QA、運用など）が来ない。開発のリズムと組織全体のリズムが噛み合わない状態となるのだ。
背景には、職能別の完全分業と、大量生産の価値観が残っていることがある。
フェーズ間の引き継ぎを経るごとに情報は劣化し、開発側は企画側ほどドメインを理解できない。最適な設計やアーキテクチャの判断は鈍る。
さらに、PMによる中央集権的なオーケストレーションの下では、“自己管理型” の裁量はない。開発に求められるのは、期日までに、任されたタスクをきちんと終わらせることだ。「より速くより多く」に寄りがちで、アウトプットに意識が集中しがちとなる。価値検証のサイクルを高速化するという思想は失われ、アウトカムやインパクトは顧みられない。
そのうえ、開発だけがスクラム化しても、全体のリズムが一致していなければスプリントは簡単に崩される。たとえば、企画部門からの見積もり依頼や、PMからの突発タスクが割り込めば、開発時間は削られ、フローは途切れてしまう。
このようにして、組織設計のひずみが現場に生じさせる問題は様々にある。下記スライドは、組織設計のアンチパターンを踏んだ結果生じた問題を列挙したものだ。
もちろん、先述の二つの例や、後述するアンチパターンに当てはまっても、一概に悪い組織設計とは言えない。状況次第では最適解となることもある。この前提は踏まえておきたい。
現場を悩ませる主要な問題は三つに分けられる
組織設計のひずみの多くは、次の三種類の問題として現場に姿を現す。
- フロー効率の低下
- チーム境界を越えるコミュニケーションコストの増大
- ソフトウェアの内部品質の悪化
現場に問題を生じさせる組織設計上の構造は、次の図のとおりだ。「組織構造」から順に、「バリューストリーム」「フロー」「コミュニケーション構造」「システム構造」へと問題が連鎖していく。その過程で、前節の三つの問題として現れる（逆方向の連鎖もあるが、詳細は登壇資料を見てほしい）。
つまり、組織設計の対象はこの図全体に及ぶ。組織をチーム分けしてメンバー構成を決めるだけではないということだ。
従来型の組織が持つ文化・価値観が問題の解消を阻む
そして、従来型の組織が持つ文化・価値観が、これらの問題の解消を阻み、事態をより深刻にしている。
リソース効率には注目するが、フロー効率は意識されない
組織の多くは、“フロー効率” ではなく “リソース効率” に目が行きがちだ。マネージャーの意識は、限りある人的リソースをいかに無駄なく効率的に使うかに向けられる。メンバー一人ひとりのスケジュールを隙間なく埋め尽くし、そのためにはプロジェクトを兼務させることも厭わない。
リソース効率を最大限に高めやすい体制が、「共有リソースプール」型の組織だ。この体制は、プロジェクトチーム制を採る組織によく馴染む。開発組織をリソースプールとして捉え、プロジェクト発足の都度、エンジニアをリソースとして貸し出す（アサインする）。そうして全員の稼働が100%を超えるまで、プロジェクトを並走させるのだ。
しかし、このようなリソース効率重視型の配置では、人の稼働は高まっても、仕事のフローはかえって遅くなる。
この論理は少しわかりづらいので、人気のコーヒーショップを思い浮かべてほしい。
行列ができるような人気店のスタッフは、みな大忙しだ。常に手を動かしている。つまり、彼らのリソース効率は高い状態だと言える。
一方で、行列に並ぶ客は、自分の番がなかなか回ってこないことに苛立つ。下手をすれば、一杯のコーヒーを買うために十分も二十分も待つことになる。これはフロー効率が悪い状況だ。客にとっては、スタッフが多少手を持て余しているくらいの方が、待ち時間がなく嬉しい。
この例では、コーヒーショップのスタッフが開発メンバーで、客の一人ひとりが機能開発案件を指している。開発メンバーのリソース効率が高いほど、機能開発のリードタイムが長くなるということだ。
しかし、リソース効率を高めようとするあまり、次々と仕事を詰め込んでしまう。つまり、チームのキャパを超えるほどに機能開発やプロジェクトを割り当ててしまうのだ。
その結果、大量の仕事は直列ではなく並列で処理せざるを得なくなる。マルチタスクである。そのため、本来は3日で終わる仕事でも、より長い期間を要してしまう。
さらに、プロダクト開発全体を見渡すと、チーム間での仕事の受け渡しのあちこちでフローが滞留していることにも気づく。けれど、部門ごとに完全分業している組織では、自部門内の仕事にしか関心が向かない。だから部分最適に陥りやすく、この問題に気づきにくいのだ。
これがフロー効率に関して、従来型組織で起こりがちな現実である。
コミュニケーションは「多ければ多いほどよい」とされている
コミュニケーションについては昔から「多ければ多いほどよい」とよく言われる。無論、複数人が一つの目的に向けて協働するために、コミュニケーションは欠かせない。しかし、「多ければ多いほどよい」という主張は、話を単純化しすぎている。
この標語が頭に染みついている状態では、物事を何でもかんでもコミュニケーションで解消しようとする。そうしてミーティングが乱立する。そこに手を入れてミーティングを減らそうとすれば、猛反発に遭うことすらある。
少し考えてみてほしい。コミュニケーションに時間を割けば、その分だけ実務に充てる時間が削られる。手を動かしたり考えたりする時間が失われる。その関係を概念的にグラフ化したものが下図だ。
とりわけチーム間のコミュニケーションは、互いのコンテキストをそろえる労力が要るためコストがいっそう高くなる。資料を準備したり、前提情報を説明したりといった活動が必要になるからだ。
現場メンバーの仕事のカレンダー上で予定が入っていない時間帯は “空き” ではない。実務に充てる時間である。したがって、コミュニケーションはメンバーの実務時間とのトレードオフであることを念頭に、設計しなければならない。
ソフトウェアの内部品質は見えない
ソフトウェアの内部品質は、エンジニアでなければ “見えない” からやっかいだ。見えないものは、ないのと同じである。ユーザー体験にも直接は影響しない。だから、内部品質を改善するために時間を割く必要性を感じにくい。
「Agility and Architecture or: What colours is your backlog? - Philippe Kruchten」https://philippe.kruchten.com/wp-content/uploads/2012/07/kruchten-110707-what-colours-is-your-backlog-2up.pdf、本記事内の図を参考に筆者が作成
さらに、内部品質の悪さがビジネスにどれだけ影響を与えているか、誰も証明できない。実際、内部品質が悪いと言われながらも、開発は問題なく進んでいるように見えてしまう。であれば、改善のためにコストをかけるのはムダだと考えられてしまう。
これこそが、内部品質が抱える問題の根深さである。
しかも、こうした意見はエンジニア以外からだけ出るわけではない。エンジニアの中にも、内部品質を重視することに価値を感じていない人や、そもそも内部品質を適切に評価できない人は少なからず存在する。
結果として、内部品質上の問題は、組織の中での優先度を下げられてしまうのだ。
組織設計がひずむ理由は四つに大別できる
組織設計がひずむ理由は、主に四つに大別できる。
一つ目は、組織設計に関する知識や経験が単に不足しているために生じたケースだ。これが理由である場合、組織設計者は自ら設計した組織の品質問題に気づかない。そのため、いつまでたっても組織品質は改善されず、現場の苦労が続いていく。
二つ目は、妥協によって生じたケースだ。組織設計者はより適した設計に気づいているが、それを実現するための組織内コンセンサスが得られず、あきらめたものである。社内の政治的力学によるものかもしれない。単にリスクを甘く評価している可能性もある。なんにせよ、今後もひずみが積み重なっていくだろう。
三つ目は、リスクを承知でその組織設計を採用する意思決定をしたケースだ。組織設計者は、この設計によって現場に問題が及ぶことは理解している。しかし、現時点ではそれがより良い選択だと判断した。このタイプのひずみは、いずれ解消されていくだろう。
四つ目は、組織運営を通じて得た学びにより、現在の組織設計が陳腐化したケースだ。設計当初は最適だと考えていたが、よりよい設計があることに気づいた。組織を取り巻く環境は不確実で予測可能性が低い。だからこそ、組織設計も探索的になる。このケースは、それを体現している。
組織設計のひずみは、技術的負債とよく似ている。とても見えにくい。だから気づきにくいのだが、ひずみは確実に現場の足かせとなり、開発生産性の妨げとなる。これは技術的負債と同じ特徴だ。
実際、上記四つの類型は、マーティン・ファウラーによる「技術的負債の四象限」に倣ったものだ。左下を第一象限として時計回りに各象限を対応させてみると、上の四つがうまく当てはまることに気づくはずだ。
「Technical Debt Quadrant - martinfowler.com」https://martinfowler.com/bliki/TechnicalDebtQuadrant.html、本記事内の図を参考に筆者が作成
だからこそ、組織設計にもリファクタリングやリアーキテクティングが必要であり、ときには大規模に見直す決断が要るのだ。
“気づきにくい” ので「組織設計アンチパターン」を活用する
先述のとおり、組織設計のひずみは気づきにくいものだ。このようなときには、アンチパターンが役立つ。自組織の状態をアンチパターンの症状とパターンマッチしてみる。当てはまれば、ひずみが生じている可能性が高い。
詳細は割愛するが、以下は、書籍『チームの力で組織を動かす』に掲載した組織設計アンチパターンの数々だ（各登壇資料内でも、いくつか紹介している）。
組織設計はマネージャーとチームの協働で進める
マネージャーが担う組織設計という活動は、「設計」と言いつつも、「アーキテクティング」に近い。ITアーキテクトがシステム全体での責務分配やコンポーネント間の関係性を描くように、組織アーキテクトたるマネージャーも、チームへの責務分配やチーム間の関係性を描くのが主な役割だ。
このことから、組織設計は、“アーキテクチャ” と “設計” に分けて考えるべきだと気づく。チーム内部の設計や実装は、現場のチームと協力して作り上げたり、チームに任せればよい。こうすることで、現場のフィードバックを取り入れた、現場感のある組織を作り上げられる。
このように見ていくと、組織運営はソフトウェアエンジニアリングに似ていると実感できる。組織全体をソフトウェアシステムと見なし、それを構成するチームをコンポーネントと見立てるのだ。
その結果、チームの凝集度を高め、チーム間の結合度を下げることで、組織全体を疎結合に保つことの重要性も理解できる。それにより、書籍『LeanとDevOpsの科学』でハイパフォーマンスな組織の特徴とされる「チームとアーキテクチャが疎結合」な状態に近づけるはずだ。
さいごに
組織設計は、継続的なものだ。一度作ったらそれで終わりではない。不確実性が高く、流動的で予測可能性の低い環境の中で探索的に改善し、変化に適応し続けていくものである。
そこで注目すべきが、三つの問題――フロー効率、チーム境界を越えるコミュニケーションコスト、ソフトウェアの内部品質――である。組織設計のひずみは、必ずここに現れる。そして、そのひずみは、アンチパターンとのパターンマッチによって気づくことができる。
組織設計はマネージャーだけの仕事ではない。組織アーキテクトたるマネージャー自らがチームを巻き込み、あるいはチーム自身が積極的に関わって、協働で進めるものだ。そうすることで、現場感のある組織を作り上げることができる。
問題に対する現場での対症療法と、マネージャーとチームが協働で組織設計を見直す原因療法、この二つの側面から組織品質を改善し続けることが、組織設計のひずみを削減・解消する手立てである。
お知らせだが、2025年8月25日に拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』が技術評論社から出版された。本稿に興味を持っていただいたなら、楽しんで読んでいただけると思う。
書籍に関する紹介記事は、下記noteにまとめた。
また、今回参考にした登壇資料は、下記二つのイベントで使用したものだ。各リンクからアーカイブ動画も視聴できるので、参考にしてほしい（それぞれ、Forkwellさん、Findyさんのアカウントが必要）。
それぞれの登壇資料はこちら。
