ログラスがOrg Topologiesを使って組織の目標設定をした話

この記事は、元々僕がLinkedInに2回に渡って投稿したものがまとめられ、Org Topologies というフレームワークの公式サイトにケーススタディとして紹介されたもの（こちら）の翻訳です。
えらく仰々しく掲載していただいたし、せっかくなので日本語版を自分のブログに載せておくか、と思って翻訳することにしました。元英文は自分が書いていますが、それを雑に日本語へ機械翻訳したあと軽く手を入れる、ということをやっています。大変翻訳文チックな日本語になっていますがご容赦ください。
ただし、ただの単なる翻訳ではなく、僕なりの考えや意味の補足をちょこちょこ挟んでいます。

目次

ログラスでOrg Topologiesを試した

私は昨年、Zuzi Shocova のA-CSM研修を受けた際、研修中に彼女が Org Topologies に軽く言及したのをきっかけに興味を持つようになりました。
それは、構造化や高い適応性の促進、透明性のある変更プロセスの確保を通じて組織設計を強化するように設計されたフレームワークでした。

Org Topologiesは、Scope of Capabilities と Scope of Work という2軸を使って展開します。 これらの軸を組み合わせると、さまざまな組織パターンまたはタイプを表す16のアーキタイプが形成されます。 これらのアーキタイプは、組織の適応性とパフォーマンスを最適化するために組織を識別、評価、設計するのに役立ちます。

Scope of Capabilities は、クロスファンクショナリティのレベルと、ユニットが独立して価値を提供する能力を測定します。 ケイパビリティの統合度が高いということは、技術的な依存関係が少なくなり、自律性が高まることを意味します。 一方Scope of Workは、タスク単位の狭い作業から、顧客のニーズ全体を網羅する幅広い価値定義まで、ユニットが処理できる作業のスコープの大きさを評価します。

このフレームワークにより、2軸マップ上で16の異なるアーキタイプを簡単に視覚化して分類できます。 これらのアーキタイプを理解することで、組織は十分に練られた組織設計を行い、変化するビジネスニーズに対してより高い適応性とレジリエンスを得ることができます。

2024年1月に、私は経営管理の生産性向上を目的としたクラウドベースのサービスを提供する日本企業、 ログラスに Org Topologies を導入しました。 同社は当時、プロダクトを複数の機能領域に分割し、各領域において独立したスクラムチームを置いて開発していました。 それぞれのスクラムチームは単体としては高い能力を発揮していましたが、チーム間の連携はそれまであまり行われていませんでした。

私は 30分間の短いセッションで Org Topologies を簡単に紹介しました。するとログラスの皆さんが強い関心を示し、翌日には開発組織の全メンバーを対象に1時間のワークショップが開催され、各チームの現状をマップ上にプロットすることになりました。

短いワークショップでの自己評価のみでしたが、私の予想通り、ほとんどのチームが A1〜A2 に位置づけられました。 詳しく説明すると、A1およびA2のアーキタイプは以下のようなタイプの組織構造を表します。

• A1 (フィーチャーに重点を置いた、サイロ化された機能グループ) : このアーキタイプ内のチームは特定のスキル/職能に特化し、フィーチャー単位の開発に取り組んでいます。サイロ内で作業する傾向があり、他のチームとのやり取りは限られています。

• A2 (フィーチャー重視の、不完全なマルチスキルチーム) : これらのチームはさまざまなスキルを持っていますが、完全にクロスファンクショナルではありません。また、A1チームと同様にフィーチャー単位の開発に重点を置いていますが、チーム間のコラボレーションが少し多くなっています。

このあと社内では主に、自分たちがAレベルからBレベルへ昇格すべきか、についての議論になりました。Bレベルのアーキタイプは、より協調的でビジネス目標に沿ったものであり、市場のニーズに対する俊敏性と応答性が向上します。たとえば、次のようになります。

• B2 (ビジネス領域に重点を置いた、不完全なマルチスキルチーム) : 完全にクロスファンクショナルではないが、さまざまなビジネス領域間でより協力的に作業し、ビジネス目標とのより良い整合性を促進するチーム

• B3 (ビジネス領域に重点を置いた、エンドツーエンドの高速フローチーム) : あるビジネス領域全体を対象とし、より迅速な提供と高い適応性を促進する、高度にクロスファンクショナルなチーム

そして彼らを観察しているうち、私はいくつかの点に気づきました。

1. 一部の人々の視点は、組織全体ではなく、自分のチームのみに向けられていました。たとえば何人かは、自分のチームがBレベルに昇格したいと述べましたが、これには他のチームとの強い合意と協力が必要であることを認識していないようでした。

2. 参加者のほとんどはBレベルチームの利点を認識していましたが、Bレベルまたは "team of teams" が、自分たちの組織において実際どのようなものになるかは想像できていないようでした。

3. Aレベルに留まることも現実的な選択肢であると感じた人もいました。彼らは、現行チームが十分「最適化」されており、各チームとも非常に生産的である一方、Bレベルに移行するにはコストがかかるだろうことを主張していました。

以降、ログラス開発組織の皆さんと私は、彼らの組織がチャレンジすべき課題は何なのか、そして彼らの目標は何かという点について長い間議論を重ねました。 そして最終的に、彼らは「昇格」することを数ヶ月かけて決断しました。

そして5か月後、開発生産性カンファレンスにて

5か月後の2024年6月、開発生産性カンファレンス が開催され、ログラスVPoEのいとひろさん（@itohiro73）が講演しました。 いとひろさんは、Org Topologiesを使って1月に行ったマッピング活動を紹介し、現在チームがA1-A2にあり、今後B2-B3に移行することを決定したと語りました。

Org Topologies を使ってAレベルからBレベルに上げることを説明しているいとひろさん

彼はさらにアジリティを組織に拡張していくことについて話し、そのため現時点では、FAST Agile の導入を試みる予定だと述べました。

FAST (a.k.a FaST Agile) は、カンバン、オープン スペース テクノロジー（OST）やその他アジャイルのアイデアを融合した、軽量でスケーラブルなフレームワークを作成するアプローチです。 集団（コレクティブ）を形成し、最初のセットアップで組織基盤を構築したあと、「バリューサイクル」と呼ばれる、2日程度の短いイテレーションサイクルを通じて継続的に改善することに重点を置いています。 このサイクルごとに、コレクティブはその中での同期と自己組織化を毎回行い、およそ30分だけの定期的なミーティングを通じて全体のアラインメントを取りながら開発を進めます。

いとひろさんによる、FASTフレームワークについての説明

このときのいとひろさんの講演資料はこちらで見れます。この記事で語った内容は、主に資料の後半で述べられています。

speakerdeck.com

この決断はログラスにとっては大きなチャレンジかもしれませんが、そこから得られる経験は、たとえFAST導入が上手く行かなかったとしても、彼ら組織にとって貴重な財産になると思っています。 私も、今後も積極的にサポートしていくつもりです。