注力すべきチーム/サービス/プラットフォームはどこですか?
Team Topologies を使って、Stream aligned teamやPlatform group などの役割や分割方法、コミュニケーション(Interaction)方法などについては書籍でもしっかり説明されていると思います。また、ネット上でも様々な情報が出ており、なんとなく理解している部分はあると思います。
では、いくつもあるチームのどこに一番注力していけばよいのでしょうか? またはあまり注力しなくてよい領域、できればなくしていったほうが領域はどこでしょうか?
こうした点はTeam Topologies社のワークショップにおいても、様々なツールと組み合わせてこうした点について解説しようとしています。
今回はその中の1つ、Core Domain Chartを使って、より注力すべき領域を確認していきたいと思います。
Core Domain Chartとは
事業内容の重要度を「差別化要因」と「実現する際の複雑度」の観点から考えるのがCore Domain Chartで、Nick Tune氏が提唱しているものです。
簡単に図示すると以下のようなものになります。
Core Domain
通常差別化要因・複雑度が高く、当該ビジネスの競争力の源泉となる部分です。 不確実性の高い内容の場合、一般的に内製することで短期間にさまざまなことを実現しながらその精度を高めていきます。
Supporting Domain
差別化要因または複雑度のいずれかが低く、競争力がCore Domainに比べて低い部分ですが、組織固有の要素が高かったり、Core Domainを支援するような要素が多く、Core Domainを実現するために必要な部分です。
Generic Domain
差別化要因が低く、他の組織でも同様のことを行っているような汎用的な内容の部分です(例えばメールサーバーやファイル共有サービスのようなものです)。コスト削減等を検討すべき領域です。
認知負荷とのマッピング
この分類を認知負荷の3分類と重ね合わせてみると次のような関係があるように見えてきます。 techblog.ap-com.co.jp
Domain Type | Cognitive Load |
---|---|
Core domain | 適度な(Germane)認知負荷 |
Support domain | 内在的な(Intrinsic)認知負荷 |
Generic domain | 余計な(Extraneous)認知負荷 |
もちろん完全に一致するものではありませんが、Stream-aligned teamから見た場合、集中すべき領域(=Core domain)は、認知負荷としても集中したい領域(Germane)。そして、必要ではあるけれど、事業の中心ではない領域(=Supporting domain)、外部ツールを使っても問題のない領域(=Generic domain)は、認知負荷としても余計なものと考えれば、非常にしっくりくるのではないでしょうか。
どこに注力するか
このように見てくると、どこに注力すればよいかが見えてきます。
Core Domain、特に差別化要因が多く複雑度が高い(右上に近い)領域は強化したほうがよいことが多いようです。 Supporting Domainについても、プラットフォームチームなど組織横断的に利用して効率化しつつも、事業スピードを高めるような努力をするとよいでしょう。 Generic Domainに属すると考えられる部分に関しては外部委託やSaaSなどを活用し、効率化を進めるのが適切だと考えます。
また、こうした区分も市況が変化することで差別化要因・複雑度などが変わってきます。随時見直しも必要です。
Core Domain Chartのような考え方を組織内の共通言語とすることで、自分たちがどういったところに注力すべきか、今そして将来どうなっていくかを議論しやすくなると思います。
議論する際には以下のような情報も参考にするとよいかもしれませんね。
ぜひ活用していただきたいと思います。