はじめに
こんにちは。
たーとるマークでおなじみ（？）の亀崎です。
今回は個人の見解が内容の中心となっているのであえて記名とさせていただきました。
ということで最初に。『本記事は個人の体験・感想・考えであり組織を代表するものではありません。』
みなさん、Team Topologies（チームトポロジー）というものをご存知でしょうか？
日本語版の書籍が2021年12月に出版されてから、だいぶその文字・言葉を見聞きする機会も増えてきたように思います。 実は私や私の属するチームでは日本語版書籍が出版される以前からTeam Topologiesについて、その重要性を感じて 理解を深めてきました。その内容について触れていきたいと思います。
Team Topologiesとの出会いからこれまで
Team Topologiesとの最初の出会いは2020年2月に行われたDomain Driven Design Europe(DDD EU) 2020でした。ちょうど横浜港でコロナ騒動が始まったのをアムステルダムのホテルの新聞で見たのを覚えています。 このカンファレンスから数多くのものを学びました。
- DDDの根幹:Bounded ContextとUbiquitous Language
- 事業のCore/Support/Generic 3 DomainTypeの分類とそれを分析・活用する際に有用なビジネス戦略マップのWardley Mapping
- EventStorming / Domain Storytelling
他にも多数有用な情報を持ち帰って活用をしましたがTeam Topologiesもその１つでした。 プロジェクトを効果的・効率的に進めていくためにはどうすればいいのかといった内容だったと思いますが、 Team Topologiesはその中の要素の１つでした。その話を聞いているうちに「あれ、これは結構重要なものじゃないか？なにか気になるな」と感じました。
帰国して早速こちらの英語版の書籍を購入して内容の理解を進めていくと、まさに「自分たちが実現したかったことではないか」と感じ、 チームに紹介し、さらにお客様にもその必要性を説明しています。
DDD EU後コロナの影響もあってオンラインイベントが多くなり、さまざまなカンファレンスの情報が収集しやすくなりいくつもの講演を見ましたが、次第にTeam Topologiesを引用するものが多くなってきています。まさにチーム体制・組織構成に関するものの 世界レベルでのデファクトスタンダードになってきているのではないかと思います。
そんな中で日本語翻訳版も出版され、日本でも次第に認知されて来ましたので「あのときの直感は正しかった」と 感じずにはいられない、今はそんな状況になってきています。
Team Topologiesって簡単に言えばなに？
Team Topologiesとはなにか。ひとことで言えば、従来の 機能中心の分業から事業中心組織へのの転換とその型だと思います。
なぜ事業中心組織への転換が必要なのか。それを考える上でまずAgile、DevOps、Cloud Nativeといったムーブメントから考えてみたいと思います。
Agile、DevOps、Cloud Native
従来の一般的なITシステム開発の問題点、それは開発開始からリリースまでのリードタイムの長さ、そして多くのプロジェクトの失敗でした。以前のITシステム開発は、専門技術を要しそれを身につけたチームが開発する必要があるという状況でした。 そうした専門技術を持つ人間が集まりSIerとして技術力を提供する。一般企業は自社のビジネス面の要求事項をまとめ、そうしたSIerに開発を依頼する。こうした業務を確実に遂行するためのメソドロジーがウォーターフォールであり、それがSIビジネスの中心でした。 最初は小規模だったITシステムも次第に複雑化し、またビジネスの不確実性の高まりもあって、リリースまでのリードタイムが問題となりはじめ、複雑性とリードタイムの解決ができずに多くのプロジェクトが失敗に陥る、そうした時代からアジャイルとアジャイルマニフェストは生まれました。
アジャイルメソドロジーを採用して、リードタイムの短縮をした結果、次第にビジネス要求をまとめ、それをSIer（開発チーム）に説明し、開発が完了したら運用チームに引き渡す、といった（水平）分業が次第にボトルネックとなりはじめました。組織をまたいだ情報の伝達の問題、いわゆる認知負荷の高まりです。そんな中から出てきたのが（Biz）DevOpsです。これまで分業していたものを１つのチームにまとまって行うことを目指し始めます。１つのチームにまとめることで認知負荷を低減しボトルネックの解消を図るもので、これによりビジネス要求をより早く・確実に実現できるようになることを期待したものです。 つまり事業を実現することにフォーカスしてきたのがBizDevOpsになると思います。
Team Topologiesが示すもの
これまでアジャイルがウォーターフォール開発に代わって実現したかった世界は、「要求からリリースまでのリードタイムを短くし、（ビジネス・）開発・運用が一体となったチームによるシステムの開発・運用」です。
当然ウォーターフォールを想定していた過去の組織体制では歪を生みます。アジャイル時代にあった組織体制が必要です。 Team Topologiesはアジャイル時代にあった組織体制はどういったものなのか、を様々な事例を分析して導き出しています。
従来のウォーターフォール時代の水平分業体制ではなく、事業にフォーカスしたBizDevOpsを採用する、 その方向に組織を転換していく、その型を示しているのがTeam Topologiesだと思います。
そして、Team Topologiesは技術要素ではなく、組織論になると思います。技術領域から発展したものではありますが ビジネス層の方々が一番必要とする内容になっていると思います。
Team Topologiesの今後
上記のようにAgile・BizDevOpsという背景の中で注目されているTeam Topologiesですので、 すべての場面で有効であるというわけではありません。 しかし、Agility（俊敏性）が期待されるのは今後避けて通れないものであり、多くの場面でTeam Topologiesの型を 参考にしていくことが必要になってくると思います。
さまざまな領域の方々にその内容を知っていただき、よりよいITの活用につなげていきたいと思っています。
とりあえずはじめたいという方
ご本家のサイトで２つのInfographicsを公開しています。実際に始める方はこちらをご覧になるとよいかと思います。
Getting started with Team Topologies - infographic — Team Topologies
Team Topologies in a nutshell - infographic — Team Topologies
（実は手元では翻訳しているのですが、公開して良いものかどうか判断が付き兼ねておりまして・・・。） それほど難しい単語はなかったと記憶していますので問題はないかと思います。
最後に
私達のチームでは、Azure・AKSを活用したシステムのSIや内製化のお手伝いをさせていただいております。 Azureやコンテナ技術の知見を持つエンジニアだけでなく、Team Topologiesについてもご相談等ありましたらぜひご連絡ください。
よろしくおねがいします。
