はじめに
みなさん、こんにちは。BIPROGY アジャイル推進室の本多です。
今回、認定スクラムトレーナーでもあり、認定LeSSトレーナーでもあるAlexey Krivitskyによる Org Topologies Consultant研修 に参加しました。
Org Topologiesは、組織を単に「チームや部署の配置」として捉えるのではなく、ビジネス戦略に対して現在の組織設計がFitしているのかを考え、組織を継続的に再設計していくためのアプローチです。
研修を受ける前は、Org Topologiesを「組織の状態を可視化するフレームワーク」のように捉えていました。
しかし実際に学んでみると、重要なのはMapそのものではなく、
「私たちは何を実現したいのか。そのために、どのような組織であるべきなのか」
を考え、対話することだと感じました。
特に印象に残ったのは、AIが急速に普及している今だからこそ、まずAI導入を考えるのではなく、組織そのものを深く考えるという視点です。
本記事では、Org Topologiesの基本的な考え方と、研修を通じて学んだ「AI時代の組織設計」について、自分なりに整理して紹介します。
組織設計や組織変革、AI時代の開発組織のあり方を考えている方にとって、何か一つでも参考になれば幸いです。
「良い組織」ではなく「Fit for Purpose」
研修の序盤で出てきたのが、アダム・スミスの『国富論』で有名なピン工場の話でした。
仕事を細かな工程に分割し、それぞれの人が特定の工程に専門化する。
18世紀のピン工場では、この分業によって生産性を高めることができました。
現代のソフトウェア開発の文脈から見ると、「サイロ化した組織」と批判したくなるかもしれません。
しかし重要なのは、それが当時の目的に対して機能していたということです。
つまり、Fit for Purposeだった。
ここで、自分の中で一つ認識が変わりました。
組織設計には、絶対的な「良い組織」「悪い組織」があるわけではない。
研修では、F1マシンとダンプカーの例も出てきました。
F1とダンプカーのどちらが優れた車か？
この問いには、そのままでは答えられません。
レースをするならF1が目的に合うでしょう。
大量の土砂を運ぶならダンプカーが目的に合います。
何かに特化するということは、別の何かを諦めることでもあります。
組織についても同じです。
「どの組織設計が優れているか」ではなく、「何を実現したい組織なのか」。
ここから考えなければいけません。
かつては「良いアイデア」だった
研修中印象に残った考え方があります。
組織に存在しているものの多くは、かつては良いアイデアだった。
部署、役割、承認プロセス、会議、ルール、専門チーム。
現在は「なぜこんな仕組みがあるのだろう」と思うものでも、それが作られた時点では、何かの問題を解決するための合理的な理由があったのかもしれません。
問題は、環境や戦略が変わっても、それらが組織に残り続けることです。
だから、
- この部署をなくそう
- このプロセスを変えよう
- チームを再編成しよう
と、現在の構造だけを見て、いきなり変えようとするのは危険です。
なぜその構造が生まれたのか。
何を解決しようとしていたのか。
そして現在の戦略に対して、それはまだFit for Purposeなのか。
組織の歴史や関係性を理解したうえで、残すものと変えるものを考える必要があります。
組織図を変えることが、組織設計ではない
組織を変えるというと、つい「誰がどの部署に所属するか」「誰が誰にレポートするか」といったStructureに目が向きます。
しかし、研修で扱ったJay GalbraithのStar Modelでは、組織設計をStructureだけでは捉えません。
大きく捉えると、
Strategy
↓
Org Design
↓
Behavior
↓
Culture / Performance
という関係があります。
そしてOrg Designでは、Structureだけでなく、
- Org Design Criteria
- Structure
- Processes
- Rewards
- People
といった要素を考えます。
これらは独立しているわけではなく、互いに影響し合います。
組織図だけを変更しても、意思決定の仕組み、評価、人材、インセンティブなどが以前のままであれば、以前と同じ問題を再現する可能性があります。
つまり、
「組織図を変更すること」と「組織を設計すること」は同じではない。
組織を「箱と線」ではなく、相互に影響するシステムとして見る必要があります。
すべてはStrategyから始まる
では、どんな組織にすればいいのでしょうか。
ここで重要になるのが Strategy です。
研修のOrg Design Studioでは、対象となる会社や組織について、まず次のようなことを整理しました。
- 会社・組織は何をしているのか
- どの業界にいるのか
- どれくらいの規模なのか
- 主要な顧客セグメントは誰なのか
- ビジネス戦略は何なのか
いきなり「理想のチーム構成」を考えるわけではありません。
会社には存在目的があります。
外の世界に対して、何を変えようとしているのか。
そのために、組織は何を得意とする必要があるのか。
研修では「組織が何を得意とすべきなのか」を5〜7個ほど挙げ、そこから本当に重要なものを絞っていくワークも行いました。
ここで難しいのは、「組織が何を得意とすべきか」をユニークで具体的なものにすることです。
例えば、「顧客満足」「品質」「スピード」だけでは、どの会社にも当てはまる、ありきたりなものになってしまいます。
ありきたりで何が問題なのか？これは私なりの解釈ですが、Strategyは競争優位につながるものなので、ありきたりな言葉だけでは他社との違いが見えにくく競争優位につながりにくい。
そしてもう一つ、それだけでは、組織をどう設計すべきかのヒントになりにくいのだと思います。
「自分たちのStrategyだからこそ、組織として何を得意とする必要があるのか？」
そこまで具体化して初めて、
Strategy → Org Design
のロジックが見えてきます。
つまり、目指すのは「一般的に良い組織」ではありません。
自分たちのStrategyにFitする組織です。
Org Topologiesという「組織を見るための共通言語」
ここからOrg Topologiesが登場します。
組織設計について議論しようとすると、一つ難しい問題があります。
同じ組織を見ていても、人によって見えているものが違うことです。
「自律している」
「サイロ化している」
「クロスファンクショナルだ」
「顧客志向だ」
こうした言葉だけでは、人によって意味が違ってしまいます。
そこでOrg Topologiesでは、2つの軸を持つMapを使って組織を見ていきます。
参考：Org Topologies公式
Org Topologies Mapの実際の図は、公式のMappingページで確認できます。
Scope of Skills Mandate
横軸は Scope of Skills Mandate です。
その組織単位が、価値を届けるために必要なスキルをどの程度持ち、それを実際の仕事で行使するMandateを持っているかを見ます。
左側は incomplete。
右側に進むほど complete になります。
ここで重要なのは、単に「そのスキルを持った人が会社にいるか」ではありません。
その組織単位が、そのスキルを実際に使うことを許されているか。
これも含めてMandateとして考えます。
Scope of Work Mandate
縦軸は Scope of Work Mandate です。
どの程度広い仕事に介入できるMandateを持っているかを見ます。
下側では、決められた範囲の仕事を担当します。
上に進むほど、より広い問題や仕事に関われるようになります。
この2つの軸によって、組織がどのようなIntelligenceを発揮するよう設計されているのかを見ることができます。
重要なのは、Map上の「正しい場所」を探すことではありません。
自分たちのStrategyに対して、今の組織がどのように機能していて、どの方向へ発展させる必要があるのかを議論すること。
Mapそのものよりも、Mapを使って生まれる議論に価値がある。
これは研修で強く印象に残ったことの一つでした。
3つのTopology
Org Topologiesでは、組織の特徴を Resource / Delivery / Adaptive という3つのTopologyから見ることができます。
参考：Org Topologies公式
Resource / Delivery / Adaptive Topologiesの実際の図は、公式のMappingページで確認できます。
Resource Topology
Resource Topologyでは、専門性や予測可能性、リソース効率などが重要になります。
専門性ごとに人や組織が分かれ、計画、予算配分、スケジュール、調整などによって仕事を進めていきます。
こうした構造が目的に合っている環境もあります。
高度な専門性や高い予測可能性が重要なのであれば、それは合理的な組織設計かもしれません。
一方で、多数の専門組織をまたいで価値を届ける必要がある場合には、
- 人材の取り合い
- スケジュール調整
- 部門間の依存関係
- 優先順位の調整
- 根回し
などに多くのコストが発生します。
さらに、こうした調整コストは見えにくく、組織として認識されないまま残ってしまうこともあります。
Delivery Topology
Delivery Topologyでは、Resource Topologyよりも広いScope of Skills Mandateを持って仕事を届けられるようになります。
リードタイムやスループットの改善が期待できます。
一方で、担当する機能やプロダクト領域などScope of Work Mandateが限定されている場合、その範囲の外側にある問題には介入しにくくなります。
安定した需要に対して効率的に価値を届け続けるのであれば、非常に有効かもしれません。
しかし、市場や顧客ニーズが大きく変化すると、それまでの組織設計がStrategyにFitしなくなる可能性があります。そのため、一度作った組織を固定するのではなく、Strategyや環境の変化に合わせて組織設計を見直していく必要があります。
Adaptive Topology
Adaptive Topologyでは、より広いScope of Skills MandateとScope of Work Mandateを持ちます。
決められたOutputを届けるだけではなく、Outcomeに向き合いながら、自分たち自身も学習し、変化していきます。
ただし、ここで注意したいのは、
Adaptive Topologyが常に正解というわけではない
ということです。
Adaptiveであり続けるためには、継続的な組織学習が必要です。
当然、そこには学習のための時間やコストも必要になります。また、メンバー自身が継続的に学び、仕事の範囲を広げていく働き方を受け入れられることも前提になります。
つまり、Adaptiveであることにもトレードオフがあります。
そして、そもそもStrategyが高度な専門化や予測可能性を必要としているのであれば、別のTopologyの方がFitしていることもあります。
結局ここでも、
Fit for Purpose
に戻ってきます。
データサイエンティストを一人採用したら、どこに置く？
研修で面白かった問いがあります。
すでに自律的に動いている4つのチームがあるとします。
そこに、会社で初めてのデータサイエンティストを一人採用しました。
さて、その人をどこに配置するでしょうか。
例えば、
- どのチームにも所属させず、専門家として独立させる
- 複数のチームを横断して支援してもらう
- 一つのチームに所属してもらう
といった選択肢があります。
一見すると単なる人員配置の問題です。
しかしOrg Topologiesで見ると、それぞれが異なる組織設計になります。
専門家として独立させれば、専門性を最大化できるかもしれません。
しかし、仕事がその人のところで待つようになるかもしれません。
複数チームを横断させれば、今度は優先順位、スケジュール、管理、調整が必要になるかもしれません。
一つのチームに入り、そのチームのOutcomeを一緒に追うのであれば、その人自身が他のスキルを学ぶ可能性があります。
同時に、周囲のメンバーもデータサイエンスについて学ぶ可能性があります。
つまり、
「誰をどこに配置するか」という小さな判断にも、自分たちがどんな組織を作ろうとしているのかという意思が現れる。
ということです。
「自律してください」ではAdaptiveにはならない
研修で紹介された事例の中で、特に印象に残ったものがあります。
すでに自律的に働いていたチームが、新しい領域へ進出するために、足りない専門性を持った人たちを採用しました。
既存メンバーは自律的に働けていたため、新しいメンバーについても、
「見ていれば、そのうち自律的に働けるようになるだろう」
と考えていたそうです。
ところが、そうはなりませんでした。
十分な教育や意図的な働きかけがないまま、新しいメンバーは「言われたことをやる」という働き方になっていった。
ここから学んだのは、
Adaptiveな組織に人を置けば、その人も自動的にAdaptiveになるわけではない
ということです。
Scope of Skills MandateやScope of Work Mandateを広げるには、単に「自由にやっていい」と言うだけでは足りません。
新しいことを学べる環境。
実際にやってみる機会。
周囲との関係。
そして、実際に行動することを許可するMandate。
組織側から意図的に条件を作る必要があります。
OutputからOutcomeへ
もう一つ、研修で印象に残った事例があります。
複数のチームと複数のPOが存在し、それぞれがOutputを出すことで精一杯になっていた組織の話です。
Outputは出している。
しかし、本当はOutcomeを届けたい。
そこで組織の働き方を変えていった。
会社としての優先順位について対話し、イベントの進め方を学び、それを自分たちで実践していく。
最初から自律的にできたわけではありません。
やり方が分からなければ、学ぶ。
分かるようになったら、自分たちでやる。
そして少しずつ、より広い仕事へ介入するようになる。
この話を聞いて、
「自律性」は人の性格ではなく、組織設計や学習によって変化し得るものなのかもしれない
と感じました。
Outputを出すだけの関係から、Outcomeについて自分たちで考える関係へ。
その変化には、SkillsだけではなくMandateも必要になります。
組織変革は「完成」しない
では、実際に組織をどう変えるのでしょうか。
研修では、いきなり組織に手を入れることはアンチパターンとして扱われました。
そこで登場するのが、次のサイクルです。
Map
↓
Assess
↓
Design
↓
Elevate
↓
Map ...
Map → Assess → Design → Elevate
この改善サイクルを、それぞれの頭文字を取って MADE と呼びます。
参考：Org Topologies公式
MADE（Map → Assess → Design → Elevate）の実際の図は、公式のMADE Methodページで確認できます。
Map
まず、現在の組織を見る。
いきなり「こう変えよう」と決めるのではありません。
組織が現在どのように機能しているのかを理解します。
Assess
次に、その組織設計がStrategyと整合しているかを考えます。
そもそも変化は本当に必要なのか。
何がFitしていて、何がFitしなくなっているのか。
ここを評価します。
Design
そのうえで、次の組織を設計します。
目的は流行している組織モデルを導入することではありません。
Strategyに対して、よりFitした組織設計を考えます。
Elevate
そして、実際に組織が変化できるよう働きかけます。
学習する。
Mandateを広げる。
新しい働き方を試す。
そして、ここで終わりではありません。
またMapします。
環境もStrategyも変化します。
かつてFit for Purposeだった組織設計が、ずっとFit for Purposeであり続ける保証はありません。
だから組織設計は、一度実施して終わる「Transformation Project」ではなく、継続的な活動になります。
大きく見て、小さく変える
ここで重要なのが、変化させる範囲です。
100人、1,000人規模の組織を、一気に変えることは簡単ではありません。
研修では、
MapとAssessでは広く組織を見る。
実際の変化は、より狭い範囲から始める。
という考え方が出てきました。
例えば、
- 一つのプロダクト
- 一つのプロジェクト
- 一つの予算
- ある程度独立して実験できる組織
などから変化を始める。
この話とつながって印象に残ったのが、Gall's Lawです。
うまく機能している複雑なシステムは、うまく機能している単純なシステムから進化したものである。
最初から巨大で完成された組織を設計して、一気に導入するのではない。
小さく変化させる。
そこで学ぶ。
その結果から次を考える。
組織そのものが、組織設計する能力を学習していく必要があります。
そして、ようやくAIの話に戻る
ここまで組織設計について考えて、ようやくAIの話に戻ってきます。
研修で示された順番が、とても印象的でした。
1. AIを忘れる
↓
2. 組織設計を深く考える
↓
3. AIを使って、より良く・より速くする
AIを導入すること自体を目的にしない。
まず、
- 自分たちは何を実現したいのか
- そのために、組織は何を得意とする必要があるのか
- 現在の組織設計は、それを可能にしているのか
を考える。
そのうえでAIを使う。
なぜ、この順番なのでしょうか。
研修で出てきた比喩が、とても分かりやすかったです。
渋滞している街の車を、全部フェラーリに変えたらどうなるか。
一台一台の車は、ものすごく速くなります。
しかし道路が渋滞していれば、街全体の移動速度は上がりません。
組織も同じです。
AIによって一人ひとりのOutputを何倍にも増やしても、その成果が、
- 別部署の承認待ちになる
- 専門チームのバックログに積まれる
- 他チームとの調整待ちになる
- 複雑な依存関係に阻まれる
のであれば、組織全体として顧客へ価値を届ける速度が同じように上がるとは限りません。
AIで「車」を高速化する前に、
道路がどう設計されているのかを見る必要がある。
これは今回の研修で、自分にとって特に大きな学びでした。
AI時代だからこそ「人間の知性」が重要になる
AIは、これからも速い速度で変化していきます。
一方で、既存の組織は同じ速度では変化できません。
だからこそ問題になるのは、
「AIをどう導入するか」だけではない
のだと思います。
変化する環境に合わせて、人間が自分たちの組織を観察し、学習し、再設計できるか。
組織について共通認識を持ち、
我々は何を目的としているのか？
今の組織は、その目的にFitしているのか？
次に何を変えてみるのか？
を議論できるか。
AIによって、これまで人間が担ってきた多くの作業を支援・代替できるようになればなるほど、組織として「何を目的とするのか」「どこまでを自分たちの仕事として引き受けるのか」を考えることの重要性は増していくのではないかと感じました。
Org Topologiesは「右上を目指すゲーム」ではない
今回、Org Topologiesについて自分の理解が大きく変わったところがあります。
最初にMapを見ると、
「右上に行くほど成熟した組織なのでは？」
と思いたくなります。
しかし、研修を通して理解したのは、右上に組織を置くこと自体が目的ではないということでした。
高度な専門性や予測可能性が重要な仕事もあります。
安定した需要に対して、高い効率でDeliveryすることが重要な環境もあります。
一方で、顧客の問題そのものが不確実で、継続的に学習しながら変化する必要がある環境もあります。
だから問うべきなのは、
「どこが正解か？」
ではなく、
「Strategyに対して、今の組織設計はFitしているか？」
なのだと思います。
そしてStrategyが変われば、その答えも変わります。
まとめ：組織を「与えられたもの」として見ない
今回の研修を通して、一番変わったのは組織に対する見方かもしれません。
組織構造は、そこに最初から存在する固定されたものではありません。
過去のさまざまな意思決定によって作られてきたものです。
そしてStrategyや環境が変われば、再び設計することができます。
ただし、
- 最近この組織モデルが流行っているから
- 有名企業がこうしているから
- Agileだから
- AI時代だから
という理由だけで変えるのではない。
まずPurposeとStrategyがある。
その目的に対して、現在の組織がFitしているのかを見る。
組織がどのように機能しているのかを探求する。
そして必要なら、意図的に再設計する。
Map
↓
Assess
↓
Design
↓
Elevate
↓
Map ...
そして、また見る。
Org Topologiesは、理想の組織図を教えてくれるものではありません。
むしろ、
「自分たちは何のために、どのような組織であるべきなのか」
について議論するための共通言語なのだと、今回の研修を通して理解しました。
AIによって個人の能力を高めることが容易になっていくからこそ、その能力を組織としてどう活かせるのかが問われる。
フェラーリを増やすだけではなく、道路そのものを見る。
そんな視点を持ち帰ることができた研修でした。
もっと学びたい方へ ― LeSS Yoake
今回紹介したOrg Topologiesや組織設計について興味を持った方は、次の、リソースにもアクセスしてみてください。日本語での情報は残念ながらありませんがAIが味方になってくれます。
また、LeSS Yoake もぜひチェックしてみてください。
LeSS Yoakeでは、LeSS（Large-Scale Scrum）をはじめ、プロダクト開発や組織設計・組織変革について学ぶためのトレーニングやイベントが開催されています。
「チームのアジャイル」から一歩進んで、
- 組織全体をどう設計するのか
- StrategyとOrg Designをどうつなげるのか
- 複数チームでどのように価値を届けるのか
- 組織そのものをどう変えていくのか
といったテーマに興味がある方には、面白い学びの場になると思います。
そして、BIPROGYはLeSS Yoakeの活動に会場スポンサーとして協力しています。
今後開催されるイベントでは、BIPROGYのオフィスが会場となる機会もあります。
こうしたコミュニティの活動を通じて、会社の枠を越えてアジャイルや組織設計について学び、実践者同士がつながる場を支援していければと思います。
We Are Hiring!
BIPROGYでは、一緒に働く仲間を募集しています。
システム開発から企画、スタッフなど、さまざまな職種で採用を行っています。
この記事をきっかけにBIPROGYに興味を持っていただけた方は、ぜひ採用情報をご覧ください。
BIPROGYグループの技術への取り組み
こちらも是非チェックしてみてください。