こんにちは。普段は、Rubyなどによるバックエンドアプリケーション開発をすることが多い、システムエンジニアの浅沼です。

今回の記事は、チームトポロジー - Martin Fowler's Bliki (ja)を読み、実際に現在関わっている開発チーム・企業でもフレームワークとして活用できるシーンがあり、その点で思うことを書いてみました。

と言っても、私自身がチームトポロジーやFour Keys/Spaceといったことを聞き始めたのは、ごく最近のことです。特に、7月13日に開催された 開発生産性Conference に参加したことの影響が大きいかもしれません。チームトポロジーは、後述しますが、書籍が2021年12月に出版されているので、その時に手にとってみたかったと、今更ですが思っています。

チームトポロジーに興味を持ったきっかけ

チームトポロジー - Martin Fowler's Bliki (ja)を知ったきっかけは、@ryuzeeさんの7月27日のPost（Tweet）なので、本当にごく最近でした・・・。
目を通してみると、現在参画中の企業さんが、ストリームアラインドチームのみで構成されていることに気づきを得たことが興味を深めた理由です。

そして、プラットフォームチームがないのです。その分、ストリームアラインドチームが持っているナレッジと今後の成長時に必要になりそうなプラットフォームに関わるナレッジに差がありそうなことに気づきました。自分が参画した理由も、その間を埋めるイネイブリングチームが担う役割が必要そうになったからだと、後から理解し始めました。

こうして、チームトポロジー のフレームワークと照らし合わせることにより、全体を俯瞰した状態で、現チームの特徴、自分に求められることの解像度が上がっていきました。実際、自分が担っていること、ナレッジ伝達、レビューしていることは、現チームの持っていない範囲の技術・知見です。

プラットフォームチームがないとはどういうことか

現在参画中の企業では、BaaSをメインに採用しており、DB等々のプラットフォームが、フルマネージド・APIで利用可能になっています。そのため、はじめからインタラクションは、X-as-a-Serviceモードであり、標準化されています。

私自身は、SSHして、パッケージインストールもして、コンフィグ、動作確認、負荷や可用性の確認、アプリケーションとの接続・・・等々、バックエンド、ミドルウェア、クラウド・インフラ等々をカバーしてエンジニアリングしてきたので、ある意味、衝撃を受けました。この話は、いつか機会があれば、別途、詳しく・・・。

重要なポイントは、現在のBaaSの仕様・制約を活かしきって、X-as-a-Serviceモードのインタラクションに集中してもらい、他の認知的負荷を生まないようにすることだと気づきました。

ストリームアラインドチームのスキルスタックは、主にフロントエンドに集中しているため、私は、そのスキルスタックの手の内に収まる、ちょうどよいサイズ感のプラットフォームでありつづけること、また、手に負えなくなりそうなリスクを見つけ出して、対策しておくことに力を尽くしています。

イネイブリングチームなメンバーとして行っていること

ストリームアラインドチームとプラットフォームの関係性について、上記のように一定の方針を見出しました。私自身がイネイブリングチームなメンバーとして行っている具体的なアクションをいくつか書き出してみます。

データベースのキャパシティプランニングと対策

BaaSの仕様・制約・料金モデルを踏まえた上で、事業成長に合わせたデータベース・レコードのサイズ感をプランニングしています。予測されるレコード量、データサイズを見積もり、設計上の見直し・改善に着手しています。いわゆる、今はフルテーブルスキャンで速くても、突如、遅くなる系への予防です。
また、アンチパターンに陥りやすいことをチェックリスト化し、今後のデータベース・テーブル設計をセルフチェックできるように、チェックリストを用意しました。

プラットフォームの統一感

やはり、BaaS以外にもクラウド上の仮想マシンがあったりします。そのインスタンスたちの役割を調査し、サーバレス化することで、仮想マシンのナレッジ・運用の認知的負荷を無くす試みをしています。幸いなことに、ストリームアラインドチームには、Lambdaのナレッジ・経験があるので、一切、インスタンスを持たないことが可能そうです。当面、コンテナやKubernetesを必要とすることもなさそうです。

セキュリティ目線でのレビュー・対策

ライブラリ、コード、Webアプリケーション・・・諸々の状況を確認し、私が存在しなくても、ストリームアラインドチームが開発・運用フロー上で可能、かつ、必要十分なセキュリティ運用を企画・構築しています。また、セキュアソフトウェア開発も踏まえて、チームへのナレッジドキュメントを準備中です。

以上、一部ですが、現在、ストリームアラインドチームへ行っているイネイブリングな活動になります。参画の初期段階でチームメンバーへヒアリングを行ってみても、DB・セキュリティ関連への悩み・負担への声があったので、お互いに噛み合いそうです。

自立したチームとなる成長可能性への期待

ストリームアラインドチームを軸にした成長、組織のスケールを考えたときに、各チーム内で自己オーケストレーション・マネジメントが高いレベルで機能する組織をイメージして取り組んでいます。そこには、Four Keys, Spaceといった要素を活用してもらい、可視化された活動状況をモニタリング、チーム自ら仮説・課題設定・検証を行ってもらいたいと考えています。そうなれば、余計な中間マネジメントが介在する必要性が低くなるのではないかと。

Four Keysを経営へのレポートとして考える方も一定数いるのではないかと思います。しかし、それだけでは、経営層から『どうなの？』って聞かれて終わりかもしれません。そして、査定に使われ始めると、そのうちに、数字の取り繕い・見せかけに陥る危険性が高いと考えます。そうなると、中間マネージャーの役割は、取り繕い・見せかけのためのタスク ディスパッチャーとなり、過分な管理が増え始め、結果、組織の温度差によるコンフリクトを起こしかねません。

SRE活動と同様に、持続的に計測し、変化を考察、課題設定とアクション、結果検証の飽くなきサイクル活動が、現場で継続できなければ効果が生まれないでしょう。

『経営のコトは経営に、現場のコトは現場に』、お互い、力を発揮すべきフィールドに注力できるように、自立型チームとなる可能性を高めたいと考えています。

最後に

ここまで、チームトポロジーのフレームワークを踏まえて、現在のチーム、プラットフォーム、参画したばかりの自分に求められる役割を眺めてみると、方針や行動の解像度が上がることに気づきました。

また、『このビジネス・ユーザー・企業にとって、もっとも重要、かつ、もっとも難しいことは何か？』、ということを遠慮なく経営メンバーとも話すきっかけとなりました。これは大きな進展だと感じています。

『もっとも重要、かつ、もっとも難しいこと』を担うチームづくり、そのため、今、自分の中では、コンプリケイテッド・サブシステムチーム となっている部分に注目しています。ストリームアラインドチームの認知的負荷を軽減することに加えて、特別に濃くスマートであり、ビジネス上でもっとも重要な技術を深掘って突き進むことができれば、価値あるソフトウェアを届ける上で大きな意味を持つ可能性があるかもしれません。

今後、さらに知見を得るために、@ryuzeeさん等々、株式会社アトラクタの皆さんによる翻訳で出版している チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計 を手にとって読んでみたいと思います。

それでは、ここまでお読みいただきありがとうございました！