企業は自らの顧客やビジネスに対して、継続的に価値を提供できなくてはならない、それが企業の存在理由なのだ、とRandy Shoup氏はQCon Plus May 2021で述べた。そのためには、自分たちが使用可能な"リソース" — 人材、チーム、テクノロジ — を、効率的かつ効果的に活用できることが必要だ。
Shoup氏は、仕事の分割と共有のために企業が使用する3つのメカニズムを論じた。すなわち、サービス、プラットフォーム、コミュニティである。
サービスは、ビジネスのさまざまな部分、あるいはドメイン駆動設計で"ドメイン"と呼ぶものを表しています。
プラットフォームは、一般的に、ほとんどのチームが使用する必要のある共通機能を括り出したものです。
組織階層に厳密に従わずに、共有したい、コラボレーションしたい、というものは常に存在します。コミュニティはこのためのもので、Spotifyモデルでは"ギルド(guild)"と呼んでいます。
これらのメカニズムは相互に排他的ではなく、大企業の大半はこれらをすべて使用している、とShoup氏は言う。
心理的安心感と包括性を促進する上でリーダが実践できる、小さいが重要なことがひとつある。それは、Shoup氏が説明するように、議論やミーティングにおいてすべての見解を尊重する、ということだ。
白人男性だけが発言しているならば(珍しい状況ではありません)、"Xさん、どう思いますか？"、というように、他のチームメンバからのインプットを明示的に勧める必要があります。リーダとして、このような行為の模範になることは、必要な(ただし、まったく十分ではありません！)ステップなのです。
eBayのエンジニアリング担当VPでチーフアーキテクトのRandy Shoup氏に、エンジニアリング企業について話を聞いた。
InfoQ: eBayでは、業務ドメインに関連するサービスを、どのように体系立てているのでしょうか？
Randy Shoup: 最も高いレベルでは、販売ドメイン、購買ドメイン、検索ドメイン、支払ドメイン、といったところです(当社では実際に、これらの部署名に"ドメイン"という用語を使用してます)。これらの極めて大きなドメインは、より小さなドメインで構成されていて、通常はいくつかのレベルがあります。この組織の木構造における"葉"のレベルにおいて、個々の開発チームが唯一のサブドメインを担当し、少数の(マイクロ)サービスの開発とメンテナンスを行う、という構造が理想的です。
このような構造にした理由はたくさんあります。
- それぞれ特定の領域でチームを長く存続させることによって、自身のドメイン領域において深い知見を得ることができる。
- 特定の機能を(通常は！)1か所のみで構築することが可能である。
- 適切に定義されたAPIを通じて、成果を相互に活用することができる。
Conwayの法則に詳しければ、このような組織とサービスの構造は相互に2重である -- それぞれが他方を反映して、互いに強化する関係にある、ということが理解できると思います。マイクロサービスによるアーキテクチャは、自律的なチーム組織によってサポートされ、組織構造を反映しています。
このようなチームとサービスのエコシステムが時間の経過とともに進化する、という状況は、想像に難くないでしょう。つまり、サービスを追加したり、廃棄したり、といったことです。すべてが流動的であるように思われるかも知れませんが、事実そのとおりです。Google社内には、例えば"すべてのサービスは廃棄(deprecated)か準備中(not ready yet)のどちらかである"といったような、よく知られた言い回しがありますが、まさにそういった感じなのです！
あるチームが、自分たちのサービスをリファクタする必要がある -- 一般的には新たなサービスを括り出す作業ですが、2つのサービスを組み合わせることもあります -- 場合、コンタクトを取る必要があるのは直接的に影響を受けるチームに限定される上に、そのようなチームは組織内で"近く"にいることが多いのです。これによって、変更のオーバーヘッドが削減されて、進化が容易になります。
InfoQ: プラットフォームは開発チームに対して、どのような可能性を提供できるのでしょうか？
Shoup: 私自身もこれまで、何らかの形のプラットフォームチームを持っていない企業で働いたことは一度もありません。プラットフォームとは何か、と問われた時に考えられるのは、インフラストラクチャ(パブリッククラウドやプライベートクラウドなど)、共通機能(認証、機密管理、可観測性など)、開発者エクスペリエンス(CDパイプライン、ソース管理など)といったものでしょう。
これらのものをプラットフォームの一部とすることで、自分自身で構築することはもちろん、運用することさえ必要ではなくなります。ほとんどの企業は、これらの中のひとつ、あるいはすべてにおいて、サードパーティプロバイダを活用していると思います(そうするべきです！)。また、ある程度以上の規模の企業ならば、買収の結果にせよ、開発者による選択にせよ、複数のプラットフォームを持っているでしょう。
これによって得られるメリットは、開発チームの認知負荷を軽減し、抵抗を最小限にする方法として共通プラットフォームを利用することで、使いやすい"舗装道路"を提供する、というものです。共通のプラットフォームが使用できれば、多くのものが何の心配もなく、自由に使用できるようになります。ですから、特別なユースケースにおいて*はるかに*優れたものでない限り、プラットフォームが提供する以外のものを選択することはないのです。
InfoQ: 社内ユーザに対してもプラットフォーム使用を課金すべき、というのはなぜでしょう？
Shoup: プラットフォームの開発や運用には費用と時間が必要ですから、誰かが負担しなければなりません。無料で使えるものに対して、それを賢く効率的に使用する、という経済的動機を強く持つことはないでしょう。小規模な組織であれば、非公式な方法で使用量を制限することができますが、組織のサイズが一定に達すると、こういった非公式な方法ではスケールアップできなくなります。効率的な使用を促すためには、何らかの形のチャージバック(cjhargeback)、少なくともショーバック(showback)を実施する必要があります。幸いにもパブリッククラウドでは、すべての使用量が測定されているので、以前に比べれば簡単になっています。
私はこのことを、Google App Engineで学びました。外部的に非常に高価で希少なリソースを、あるクライアントチームが社内的に25パーセントも使用していたのです。外部のユーザには課金して、私たち自身も内部的に課金していましたが、当時、App Engineの社内利用は無料でした。そのチームに依頼するのはうまくいきませんでしたし、懇願したり脅したりするのもだめでした。要するに、私たちの仕事に協力するというのは、彼らにとって最優先事項ではなかったのです。しかしながら、私たちが外部的に請求している金額を彼らに送ると -- その費用には0がたくさん付いていました！ -- ほとんどすぐに、使用方法の最適化が彼らの最優先事項になったのです。彼らは使用量を1/10に削減しました。その直接的なメリットとして、App Engineのレイテンシが実際に向上したのです。経済的な動機付けが有効です。
InfoQ: 実際にコミュニティを組織するには、どうすればよいのでしょうか？
Shoup: Slackチャネルでも、社内グループでも、定期的なミーティングでも、あるいはそれらすべての組み合わせでも構いません。例えば、同じ言語フレームワークを使用している、同じ役割を持っている、あるいは同じテクニックを実践している開発者同士のコラボレーションを促進することに、極めて大きな価値があるのです。
リーダ層に対しては、これを簡単に、ライトウェイトに行えるようにすることをアドバイスします。Slackチャンネルを作る場合などにおいて、承認や監視を行うべきではありません。官僚主義的なプロセスが実施されるのを待つのではなく、自分たちで状況を改善するように、チームに対して働きかけるのです。
提案も有効です。eBayでは数年前から、いくつかのチームが社内サービス用にGraphSQLを使用しているのですが、それぞれ独立的に行われていました。それが、リーダシップのちょっとした後押しによって、関係するチームがワークグループを(Slackチャネルを使用して ;-))立ち上げて、アイデアを共有したことで、GraphQLがeBay社内で広く利用されるようになったのです。
InfoQ: 心理的安心感と包括性を進める上で、リーダには何ができるでしょうか？
Shoup: GoogleのProject Arisyotleでの調査によると、心理的安心感(提案者であるAmy Edmondson氏は最近になって、"felt permission for candor(率直でいられるという感覚)"と表現を変えました)は、チームの成功を決定付ける唯一かつ最大のファクタです。このチーム力学が、チームメンバ個々のあらゆる特徴よりも重要である、というのです。そこから分かるのは、すべての人たちの視点を取り上げなければ、不適切な決断しか下すことができず、結果として利益を得るチャンスを無駄にする、ということです。
Xerox PARCのリーダであったBob Taylor氏が言うように、"私たちは誰一人として、私たち全体を会わせたよりも賢くはない"のです。