この記事は元々LinkedInに英語で書いた記事を、せっかくだから日本語に翻訳してちょっと手直ししたものです。先に英語で書いて、その後日本語にざっくり訳してるので何か日本語が微妙ですが許して。
最近、Org Topologies というフレームワークに興味を持っています。アジャイル組織の成熟度、ケイパビリティを評価するツールで、それを2軸のマップ上にある、16種類のアーキタイプにシンプルに可視化・分類することができます。
その Org Topologiesを、最近支援に入っているログラス社内に紹介してみました。同社では、1つのプロダクトを複数の機能領域に分け、それぞれの領域を独立したスクラムチームが担当しています。各スクラムチームは、単独のチームとしての能力は高いのですが、チーム間の連携はそれほどしていない状態です。
そんなログラス社内で有志を集め、30分の短いセッションでOrg Topologiesの簡単な紹介をしたところ、参加者は皆さん強い興味を持ったようで、さっそく翌日、開発組織の全社員を集めて、現在の各チームの状態をマップ上にプロットする1時間のワークショップが開催されました。
短いワークショップでの自己評価でしたが、ほとんどのチームは（ほぼ想定通り）A1〜A2 に自分たちをプロットしていました。A1〜A2というのは、チームが単一機能か、もしくは複数のスキルから構成されている状態（いわゆるクロスファンクショナル）で、チームのスコープがフィーチャー単位になっている、というものです。
そして、主にAレベル（フィーチャー単位）からBレベル（プロダクト内のビジネスユニット単位）へ上げることについて議論が起こりました。一方それを観察していて、いくつか発見したことがあります：
- 視点が組織全体のスコープになっておらず、チーム視点からの発言になってるなーと思うことがちらほらありました。例えば、何人かは自分のチームがBレベルに上がりたいと述べていましたが、そのためには他のチームとの強い合意と協働が必要であることにあまり気づいていないようでした。良くも悪くも、現在の各チームが開発組織内でかなり独立しているんだろう、と思います。
- ほとんどの人はBレベルチームに何かしら利点があるということには同意していましたが、実際にBレベルや "team of teams" がどのようなものになるかは想像できていなかったように思えました。
- Aレベルにとどまることもアリな選択肢だと言う人もいました。実際、彼らはチーム単位ではかなり最適化されていて、個々のチームは十分に生産的な状態であると僕も思います。彼らの中からはBレベルに上がるのはコストがかかるという発言もちらほらありました。
そこで僕は、チーム間のコラボレーションについて、たとえばPBIを2,3個交換してどうなるか見てみる、といった"小さなトライアル "をしてはどうか、と提案してみました。議論はまだ継続中です。さてどうなることやら。
