合同会社DMM アーキテクト pospome氏の発表
120名の開発組織を支える、技術マネジメントと選定
大谷氏：
それでは早速、「120名の開発組織を支える、技術マネジメントと選定」というタイトルで、合同会社DMMのpospomeさんからお話を伺います。
pospome氏：
はい、ありがとうございます。今回は10分という短い時間ですが、以下の4つのテーマついてお話をさせていただきます。
▶︎登壇資料はこちらから
まずは、私が所属する開発組織の規模感をお話ししようと思います。
私が所属しているのは、DMMプラットフォームという部署です。この部署では、DMMで共通利用される機能を作っています。例えば、DMM会員のマイページや決済用のWebAPIなどです。DMM内の一つの部署ではあるものの、エンジニア数は120名以上在籍し、2016年からマイクロサービスの形を採用しています。
当時は独立性の高い小さなチームで構成されていました。
小規模組織は、コミュニケーションをスムーズにするため、自走する開発環境を維持するため、開発から運用まで自分たちで対応するためというメリットがありました。
これはAmazonの「ツー・ピッツァルール」や「You build it,you run it」といった方法を参考にしたもので、比較的大きな開発組織で一般的に見られるプラクティスを踏襲しています。しかし、結果的には開発効率は高くありませんでした。
その原因として、テクノロジースタックがバラバラだったことが挙げられます。
強力なオーナーシップを各チームが持つ結果として、大きな組織全体として取るべき戦略を取ることができなくなりました。先ほど紹介したメリットが裏目に出たという感じです。そのため、知見の共有が難しく、エコシステムが形成できない、他チームから優秀をアサインしてもテクノロジースタックが異なるため、十分な実力を発揮できないといった問題がありました。
以上の理由によりDMMプラットフォームはサイロ化し、スタートアップの集合体のような形になっていました。チーム間でプロダクトの設計や採用、テクノロジースタック、開発ルールなど、あらゆる事柄についてオーナーシップが異なり、各チームが独立して動いていました。
オーナーシップの程度設計が重要である
先ほどもお話ししたように、強すぎるオーナーシップが開発効率低下の原因になっていました。この状況を改善するために、私がDMMプラットフォームに入社したときに行ったのが、オーナーシップの程度設計です。
具体的には、共通のテクノロジースタックと開発ルールを定義し、チーム全体でそれを統一する形にしました。これが難しく、統一の程度が大きいほど、各チームの特定の要件を満たしにくくなります。
例えば、プログラミング言語を全てPHPに統一しようというルールを作った場合、WEBフロントエンドでJavaScriptが使用できないのか、というような話になるわけです。
どの程度統一するかは難しい問題で、より解像度を高く何をどこまで統一するかを組織にあわせて検討する必要があります。理想は、共通のテクノロジースタックや開発ルールを定義しつつ、各チームに一部の責任を持たせ、バランスを取ることです。
上の図が、実際に統一したテクノロジースタックの一例です、
プログラミング言語やコンテナ環境、モニタリング、ログ等が含まれます。プログラミング言語についてはGoとTypeScriptをデファクトスタンダードとして定義しました。
逆に統一しなかったテクノロジースタックはクラウドです。現在、DMMプラットフォームでは、各チームがAWSとGCPのどちらでも好きな方を選択して使用することが可能です。なぜどちらかに寄せなかったのかと言いますと、私が入社した当時、各チームがAWSとGCPを半々くらいで使っていたため、どちらか一方に統一することができませんでした。統一するにしても、AWSとRDSで動いているデータベースをGCPにどう寄せるのかという話がありまして、ここが難しいため統一を断念した経緯があります。
また、アプリケーション依存のDB&キャッシュやアプリケーションフレームワーク&ライブラリについては、基本的に各チームが自由に選択していいとしています。この理由ですが、サーバーサイドの選択はアプリケーションの特性によるため、全てを統一することは困難であると認識しているためです。
そして重要なのは、デファクトスタンダードから外れる権利を各チームに持たせていることです。ただし、それによって組織全体の技術戦略の利点を享受できなくなるので、各チームでメリットとデメリットを判断する必要があります。
これらの取り組みを120名もの組織でどうやって進めるかですが、基本的にはトップダウンで進めました。全チームのテックリードと話し合い、課題を明らかにし、そこであがった課題と解決方法をCTOに提案して実行に移しました。現場のエンジニアからの反発は予想以上になく、良い結果となりました。
技術選定の結果
次は技術選定の結果についてです。テクノロジースタックの統一に関して社内エンジニアでアンケートを採った結果、約8割のエンジニアが開発効率の向上を実感していました。具体的には、アプリケーションの立ち上げ時間が1から1.5人月短縮されました。
その一方で、選定したテクノロジースタックが適切かどうかは、現段階では判断が難しいです。
例えば「GoよりPHPの方が良かった」という可能性は十分にあると思っています。PHPを採用していないので直接的な比較はできないため、判断が難しいところではあります。
技術選定の結果は、時間の経過とともにわかることもあります。ただしそれは結果論で、選定した当時の状況に依存する部分があると感じています。重要なのは当時の判断に妥当性があったかどうかで、それぞれの選択肢のメリットとデメリットをリストアップし、それに基づいてロジカルに選定されていれば、基本的には問題ないと個人的には判断しています。まとめると、テクノロジースタックを統一し、トップダウンで推進しました。現状は以前よりも改善されているようですが、その選定が成功したかどうかはまだ分かりません。
私の発表は以上となります。ご静聴いただき、ありがとうございました。
関連：【2023/06/19 更新】DMMプラットフォームのマイクロサービスアーキテクトグループのエンジニア募集について
株式会社カウシェ Platform Team / Architect 伊藤 雄貴氏の発表
スタートアップにおけるPlatform Engineeringについて
伊藤氏：
私からは、アーキテクトの役割とPlatform Engineeringが弊社でどのように行われているか、どのように考えられているかを話していきます。
▶︎登壇資料はこちらから
自己紹介を簡単に再度しますと、私は株式会社カウシェの伊藤です。Platform Teamでアーキテクトという役割でプロダクト開発に携わっております。Google Cloudのサービスの組み合わせやAPIをどのように管理していくかなど、会社全体にわたる設計などを行っています。
一方で、Google Cloudから推薦を受けて、「Champion Innovator」として「Modern Architecture」と「Serverless App Development」の分野で情報発信も行っています。興味がある方はぜひTwitterをフォローしてください。
弊社の開発しているアプリ『KAUCHE』について簡単に説明します。基本的にECサービスです。友達と一緒に購入すると少し安くなるなど、ショッピングに楽しさとお得感を提供するアプリケーションを運営しています。ぜひ使ってみてください。
今日は、私が弊社におけるアーキテクトとPlatform Engineeringの役割について話します。
まず私がアーキテクトとしてPlatform Teamを立ち上げたとき、最初にチームとしてのビジョンとミッションを決めました。
具体的には「各々の ビジネスに沿った 開発チームが自律性と生産性を極限まで高めつつ、ビジネスのフェーズに応じた 信頼性と安全性を担保したプロダクトを開発できるようにするために、技術基盤を構築し、開発チームに導入する」というビジョンを定めました。
ビジョンを達成するためのミッションとしては、基盤を構築し、常に最適な技術要素を探求するというものを共に掲げました。アーキテクトは時に象徴的な役割とされますが、自分たちが何のために存在するのか、なぜこのチームが存在するのかをビジョンとミッションとして定めることが結果的に良かったと思います。
株式会社カウシェにおけるPlatform Teamの役割について説明します。我々は「Team Topologies」という考え方に基づいており、4つの大きなチームのタイプの中からPlatform TeamとEnabling Teamの役割を兼ね備えるチームとして活動しています。「Team Topologies」では、4つのチームタイプが3つのコラボレーションタイプを活用することで効果的な開発チームを作り上げることが推奨されています。
その4つのタイプは以下のような役割を持ちます。
「Complicated-subsystem team」 …AIやMLなどの複雑なサブシステムの開発・保守を行う
「Stream-aligned team」 …ビジネスドメインの開発
「Enabling team」 …「Stream-aligned team」の2チームのサポートを行う
「Platform team」 …内部で利用する基盤的なシステムを作る
特にカウシェでは、ソフトウェアシステムのアーキテクチャが組織の構造に制約されるという「Conwayの法則」に基づき、チーム構成とアーキテクチャ設計を同時に考えています。
また、「Inverse Conway Maneuver」の考え方を考慮して、よりよいソフトウェアアーキテクチャのシステムを作るためにはどのようにチームを構成すべきかを検討しています。
カウシェのPlatform TeamはTeam TopologiesにおけるPlatform TeamとEnabling Teamの役割を併せ持つような活動をしています。Platform Teamの活動としては、一般的に言われるPlatform Engineeringの活動をミッションに掲げています。
例えば、サービス間での通信方式やプロトコルの決定、Google Cloudのリソースの組み合わせ、ネットワークの構築、そして開発者が利用するCI/CDの仕組みの整備などを行っています。
以下はプラットフォームエンジニアリングの構築における重要な要素（Attributes）について、CNCF（Cloud Native Computing Foundation）の発表したホワイトペーパーを参照しています。
例えば、社内向けのプラットフォームであっても、プロダクトであることを意識し、ユーザー（この場合は社内のデベロッパー）がどのような体験を期待しているか、また、その体験を如何に良くするかという点に注目すべきだと、そのホワイトペーパーには7つの要素として述べられています。
その中でも、特にドキュメントと新規参入者への教育（オンボーディング）や、認知的負荷の軽減は重要な考え方であると感じています。
この観点は、プラットフォームエンジニアリングだけでなく、システム全体を設計する際に、非常に重要であると考えています。
特に技術選定をする際に、どのような根拠を元に決断を下したのか、また、どのように取り入れたものが各デベロッパーの認知的負荷を軽減するかという点は、大いに意識しています。
また、プラットフォームエンジニアリングのチーム自体のキーファクターも、このホワイトペーパーで述べられています。
ユーザーの要求を適切に理解すること、そしてインターフェースをどのように設計するかなどに言及がある中で、特に2番目の「Market, evangelize and advocate for the platform’s proposed values」（プラットフォームが提案する価値を市場に広め、啓蒙し、推進する）の要素が重要だと感じています。
ただ便利なプラットフォームを作り、そのドキュメントを提供し、その後は開発者が自由に活用するという状況では、せっかくの便利なものを作っても広まるのに苦労することがあります。
それに対し、社内の開発チームに対して、なぜ特定の技術を採用したのか、その技術のどの部分が既存の問題を解決するのか、あるいは何が優れているのかといった点を説明し、ある種のエバンジェリストやアドボケートとなって、自分たちが作った便利な仕組みを社内で広め、宣伝するといった取り組みを併用することが重要だと感じています。
この部分は、「Team Topologies」で述べられているEnabling Teamの振る舞いに似ていると思っており、これを強く意識しています。
この意識を持つことで、弊社ではアーキテクトの役割やPlatform Teamの役割は、例えばサーバーレス環境でアプリケーションを動かす場合、そのサーバーレス環境をどのようにプロビジョニングするか、という仕組みとセットで提供しています。
また、非同期処理の場合はどのパターンでクラウドリソースを使用するか、定期実行処理の場合はGoogle CloudのCloud Schedulerをどのように使用するか、それをプロビジョニングツールを経由してどのようにセットアップするかなどをドキュメントに記述し、実際に自分たちが導入するといった形で提供しています。
ドキュメントを作成しただけで終わらせず、初めて導入するチームに対してサポートしたり、実際に自分で構築し、どのように使用するかをデモンストレーションするといった形で、自分たちが作成したものを広めていくというスタンスを取っています。
また、できるだけ全てをサーバーレス環境で動かし、全てを宣言的に作成するというソフトウェアの設計原則も定めています。これと共に、自分たちが作った基盤とその背後にある考え方を広めるという活動も行っています。
開発チームの自律性・生産性を高め、フェーズに応じた信頼性と安全性を確保することで、プロダクト開発を強化すること。これが弊社でのアーキテクトとPlatform Teamの役割です。
私のLTはここで終わります。ありがとうございました。
ディスカッション 感想とご質問
大谷氏：
ディスカッションに入っていく前に、お互いの発表を聞いて感想や質問があればお伺いしたいと思います。伊藤さん、まずはpospomeさんの発表についてどう思いましたか？
伊藤氏：
お話の中でAWSとGCPのどちらかを選んで利用できるとのことでしたが、これはいずれどちらかに寄せていきたいのか、現状のマルチクラウド型を許容する形を継続していくのかなど、将来的な展望はありますか？
pospome氏：
現体制で確立化されているため、今からどちらかのCloudに寄せるのは困難だと思っています。反対に、マルチクラウドの強みを活かす方向に舵を切らざるを得ない感じですね。
伊藤氏：
詳しくお聞きしたいのですが、具体的にどのようなところが困難でしょうか？たとえば、RDSを明日からGoogle Cloudで行うというのは困難だと思いますが、他にも何か統合が困難な点はありますか？
pospome氏：
困難というのは、そのために工数をかけなければならないということです。工数をかけて結果としてどれだけの成果を得るのかというコストパフォーマンスの問題があります。
現在はマルチクラウド環境で運用していて、基本的にはマルチクラウドを前提にエコシステムを作っています。それらすべてを無駄にして、たとえばAWSに統合したとしても、具体的なメリットが見えにくいです。
伊藤氏：
そうすると、マルチクラウドを続けて、両方のクラウドの可用性を高めるような方向に進むということでしょうか？
pospome氏：
現状はそのような感じです。
伊藤氏：
なるほど、ありがとうございます。
大谷氏：
それでは、pospomeさん、伊藤さんの発表について質問等はありますでしょうか？
pospome氏：
正直に言うと、プレゼンテーションがきれいで、納得感しかなかったです。ありがとうございます、よかったと思います。
伊藤氏：
ありがとうございます。それでは、第1テーマに移りたいと思います。
大谷氏：
Google Cloudによるアーキテクチャの構築など、開発者のスキルセットや技術スタッフの採用の難易度などが影響を及ぼすと思いますが、具体的な技術選定の判断軸とは何でしょうか？伊藤さんからお話しいただければと思います。
伊藤氏：
プラットフォームのキーアトリビュートについて先程いくつか紹介しましたが、スタートアップは人数も少ないので、自由度が高すぎると、チーム間での移動などが発生した場合に、ゼロから覚え直さなければならないという状況が生じます。これは一種の認知的負荷が高い状態になると思います。
特に、全社で採用する技術の決定時には、その技術がどれだけ認知的負荷が低いか、使いやすいかという視点が重要です。その特性を社内向けにパッケージ化し、適切に提供するのがPlatform Teamの役割です。使用しやすさや認知的負荷といった要素が、我々が特に重視しているポイントです。
大谷氏：
具体的な負荷などは、既存のテックリードにヒアリングを行いながら、アーキテクトとして、理想の状態を示していくことが重要ということでしょうか？
伊藤氏：
それが理想ですね。ただし、その理想の状態というのは、スタートアップの現実とは異なる面があります。我が社は2～3年前に設立され、当初の開発者は私一人でした。そこで、「これが良い」と感じたものを組み立て、最低限の状態を作り上げた上で、現実の問題に対してヒアリングを行ってきました。
スタートアップでは、最初に「これが便利だから作ってみよう」という発想からスタートするフェーズが特徴的です。その後、サービスの定期評価などを行いつつ、まだ未完成の部分についてもユーザーからのフィードバックを取り入れていく必要があります。
大谷氏：
このあたり、pospomeさんはいかがでしょうか。Goを選定した理由などがあればお聞かせください。
pospome氏：
技術選定については、エンジニアは大なり小なり携わる機会があると思います。例えば、どのライブラリを使用するかといった技術選定は、私自身がサーバーサイドエンジニアとして行ってきました。しかしながら、私の技術選定は、120人のエンジニアが使えるかという視点で行うため、自分が使うというよりも、他の人が使えるような技術を選ぶことが重要です。
例えば、世の中のシェアが高い技術や、既存の知識を基に使用できる技術などを選定します。技術単体の良し悪しよりも、現在の組織のレベルにマッチするかどうかを重視しています。アーキテクトとしての判断軸は、普段のエンジニアリングの技術選定の判断軸とは少し異なるところです。
大谷氏：
ありがとうございました。次のテーマに移りたいと思います。
例えば先ほどのLTの中だと「パイロットプロジェクトに伴走しながら作っていく」「トレーニングを行う」といった話もあるかと思いますが、このあたり浸透させる工夫というのはどのようなものがあるのでしょうか。
伊藤氏：
大切にしているのは社内アドボカシーです。選定した技術の優れた点を説明し、なぜそれが良いのかを理解してもらうために、ドキュメント作成やトレーニング、ワークショップの提供などを行っています。新しいメンバーが入った時には、なぜ我々のアーキテクチャがそのようになっているのかを説明するオンボーディングも行います。
大谷氏：
なるほどですね。例えばオンボーディングの中で、例えばモジュール性やデータ設計の部分も含めてチームに説明するというプロセスを取っているのでしょうか。
伊藤氏：
その他にも、技術選定についての詳細をデザインドキュメントにまとめています。これにより、詳細を知りたいエンジニアが、どの技術がどの問題を解決するのか、どの技術が採用されたのかなどを理解することが可能です。
オンボーディングの過程で、例えばアーキテクチャのガイドラインなど、モジュール性やデータ設計の部分をチームに落とし込むことを行っているのでしょうか？
伊藤氏：
データ設計の部分まで完全には対応できていませんね。現在は、マイクロサービスの初期段階のようなフェーズです。なぜ分割しているのか、コミュニケーションのパターンがどうなっているのか、全体のシステム設計がどうなっているのかといったことを話し合っています。
本当はデータ設計や分析をどのように行うべきかといった部分も語り合いたいと思っていますが、今後の課題と考えています。
大谷氏：
そのようなガイドラインがあると、なぜシステムが現状の形になっているのか理解できるのでかなり作りやすくなりますね。素晴らしいと思います。
伊藤氏：
選定した技術については、その選定時点で「この技術が何を解決するのか」「代替案は何か」「どうしてこれを採用するのか」を全てドキュメントにまとめています。したがって、詳細について知りたいエンジニアがいれば、そのドキュメントを参照して問題を深掘りし、「このような問題を解決するためにこの技術を採用したのか」と理解できるようにしています。
大谷氏：
なるほど、ありがとうございます。次にpospomeさん、この点について何か工夫していることはありますか？
pospome氏：
まず、技術を使わせるという0から1の部分については、比較的トップダウンで指導するので、特に苦労はしていません。むしろその技術が身についていないと、DMMプラットフォームの開発フローに乗れないので、逆に困るレベルです。
その次に、技術の学習コストをどう下げるかという点については、私が比較的脳筋型のエンジニアで、自分で手を動かして学ぶタイプなので、基本的にはとにかく書かせる、触らせるという形で学習コストはかけてもらうことを前提にしています。
ただ、技術選定を担当したチームに質問できる仕組みを作ったり、オンボーディング用のドキュメントを用意したり、各種ツールへのドキュメントなどには力を入れています。これにより、学習コストはある程度削減できるように努力しています。
大谷氏：なるほど、それであれば次のテーマに関連すると思いますので、次のページに進んでいただきます。
このドキュメントは社内のスタンダードになっているものだと思いますが、どの程度まで決めていますか？例えばコーディング規約やレビューの手順など、このあたりでどのように決めていますか？
pospome氏：
私は基本的に、共通して提供できる技術は社内のスタンダードとして定めています。例えば、Kubernetesはどんなアプリケーションでも使えるので、120人の要件を実現できると思います。
バックエンドにGo言語を用いることやフロントエンドにTypeScriptを用いることも同じです。しかし、データベースをMySQLに固定するというのは少し問題があります。
たとえば、GCPには最近、AloiDBというものが出ましたが、基本的に分散型のデータベースが主流になってきています。それらを使いたいという要望もあるため、プラットフォームチームとして提供して、全員の要件を実現できるかどうかが基準になります。
大谷氏：
なるほど、そういう形でスタンダードを定めているのですね。それをドキュメント化して契約なりで整理していくという形なのでしょうか？
pospome氏：
その通りです。DMMプラットフォームでは、会員のマイページや決済のWebAPIなど、バックエンドサーバーを主に扱っています。そのため、私が先ほどお話ししたテクノロジースタックをスタンダードとして決めています。
しかし、ビッグデータや機械学習が関わる場合などは、これらのスタンダードが適用できないこともありますので、どのようなルールをスタンダードとして定めていくかは、組織の特性によって変わると思います。
大谷氏：
なるほど、組織ごとに異なる場合もあるのですね。ありがとうございました。では、次に、伊藤さんがスタンダードとして定めている具体的な要素についてお伺いします。
伊藤氏：
弊社ではかなり細かいレベルで規定を設けています。例えば、全チームで同じLintリントのルールを使用したり、単一のレポリストで開発を行っていて、Goで言えばパッケージ構成の書き方なども細かく決めています。
また、アプリケーションの運用環境や使用するデータベースも規定しています。もっと言えば、ビジネス要件とは無関係な部分については、可能な限り詳細に定めていきたいと考えています。
大谷氏：
なるほど、細部まで規定しているのですね。ありがとうございます。続いてのテーマに移ります。
大谷氏：
アーキテクトに必要だと感じる能力や、向いている人の特性について教えていただきたいです。
伊藤氏：
それは難しい質問ですね。私自身、正解があるとは思っていませんが、一つ大切だと感じるのは、「広く深く見ること」です。
技術だけでなく、法律や経営の観点からも問題を見ることが重要だと思います。一方で今の時代、技術は多岐にわたり、新しいものが次々と出てくるので、それらを追い続ける柔軟性も必要だと考えています。
今、例えば、CNCF（Cloud Native Computing Foundation）も注目されていますね。クラウド技術、アプリケーションの書き方、プログラミング言語、パッケージやモジュールの管理方法、ネットワークやAPIの配信など、多様な要素が関わっています。
アーキテクトの役割とは、そうした要素を編纂するようなものだと考えています。さらに、その理由や根拠を説明することが重要です。そして、新しい技術が出てきたときには、技術を組み合わせて既存の問題を解決できそうなデザインを作り、それを社内に宣伝する力も必要です。
それは一種のアドボカシーですね。私自身、技術が好きで、そうしたことを社内で広めるのが好きなのです。また、ビジネスや組織作りも含めたものづくりも好きです。このような性格の人が向いているのかもしれません。
大谷氏：
なるほど、リーダーシップや影響力は重要な要素ですね。ありがとうございます。では次に、pospomeさんはどう思いますか？
pospome氏：
向いていると考える人材は、ドキュメンテーション能力とコミュニケーション能力が高く、そういった作業を嫌がらない優秀なエンジニアだと思います。
一見、アーキテクトは高い技術力が必要というイメージがあると思いますが、技術力の高い人はたくさんいます。アーキテクトとしては、人とのコミュニケーションをうまくとり、特定の技術を浸透させるために、ドキュメンテーションを書いて知識を共有することが重要です。そのための政治力も必要ですね。
一見するとエンジニアの技術力に関係ない部分のスキルが高いと優れたアーキテクトになれると思います。また技術と言っても、先ほど伊藤さんが仰ったような広さと深さが必要です。
ただしアーキテクトは多様な技術領域をカバーする必要がありますので、全てを自分一人で教えることはできません。その領域に詳しい人とコミュニケーションをとって意思決定を下すことになります。そのため、自分のバックグラウンドがある程度深く強ければ、広さは組織全体の力としてカバーできると思います。
大谷氏：
なるほど、意思決定能力や明確な判断力が重要なのですね。ドキュメントを嫌がらないことも大切なポイントですね。非常にありがたいお話を聞かせていただきました。
質疑応答
言語選定の理由について
大谷氏：
ZOOMのQ&Aからも質問が来ていますね。時間が許す限り回答していただければと思います。言語選定の理由についての質問が最初にありますね。pospomeさん、GoやTypeScriptを選んだ理由について詳しく教えていただけますか？
pospome氏：
Goを選定した理由は、型があることとスピンナップが早いという2つの特徴を持つ言語が欲しかったからです。型がある言語といえば、GoやJava、Scala、Kotlinなどありますが、スピンナップまで考えるとJVM系はチューニングが必要になります。一方、Goはバイナリを置くだけでスピンナップが保証されるので、これまでの経験もあり、基本的にはGoがデファクトスタンダードだと考えていました。
また、私が入社した当時、DMMの新卒研修がGoで、社内でもマイナーな感じではなかったのも選定の理由です。フロントエンドでは、JavaScriptとTypeScriptの二択しかなく、型があった方が良いのでTypeScriptを選びました。
大谷氏：
社内で広く使われているGoやTypeScriptを選んだというわけですか。他に候補として挙げられたプログラミング言語はありますか？それとも最初からGoを一択で進めていたのでしょうか。
pospome氏：
KotlinとJavaは候補にあがっていました。DMMプラットフォームにはJavaで作られたマイクロサービスが非常に多く存在します。したがって、既存のチームメンバーの知見を活用するためには、Javaをそのまま使用するか、Kotlinを使用するといった選択肢が存在していました。
しかし、あるチームからはJavaによるJVMのチューニングが難しいというフィードバックがありました。私自身もJVMには不慣れであり、ここを自分の力でリードするのは難しいと感じました。それらの理由から、Goへのシフトを検討し、最終的にはGoを採用することにしました。
CloudはAWSとGCP、寄せるのなら？
大谷氏：
ありがとうございました。次の質問です。CloudはAWSとGCPのどちらかに寄せることはできなかったとのことですが、もし寄せるのであればどちらが良かったでしょうか？
pospome氏：
社内のAWSとGCPの利用割合を見ると、AWSが7割、GCPが3割となっています。したがって、最もシンプルな方針としてはAWSに統一するのが理想的です。しかし、GCPを使用しているチームが、非常に高いリクエストレートを持つAPIゲートウェイのようなサービスを保有しており、トラフィックの観点から見るとGCPの方が多いです。そのため、どちらに統一するにしても難易度は高いですが、どちらかと言えば利用率の高いAWSに統一する方が良いと考えています。
技術的な理由よりも、利用率が高いというシェアの問題で、AWSですね。
現場からの抵抗の声
大谷氏：
ありがとうございます。続けての質問ですが、現場からの抵抗の声というものはどの程度想定していましたか？反対が少なかったということですが、その理由の深掘りはしていますでしょうか。
pospome氏：
各チームからは自チームで選択した技術スタックを統一すると言われると、何らかの反発があると予想していました。しかし、実際には反対意見は少なかったです。その理由を詳しく掘り下げるかというと、特に反対意見が出なかったため、深く考えずに進めることにしました。
Enabling TeamとPlatform Teamの違い
大谷氏：
ありがとうございます。次には伊藤さんにお伺いできればと思います。「Enabling TeamとPlatform Teamの違いはなんでしょうか。またEnabling TeamとStream Aligned Teamの役割の範囲をどのように分けていますか」とのことですが、いかがでしょうか。
伊藤氏：
「Team Topologies」に定義されているEnabling TeamとPlatform Teamを一体化したチームを、弊社ではPlatform Teamとしています。
例えば、VPCネットワークの提供など、基盤となる部分を実際に作成、運用、開発する役割をPlatform Teamが担っています。一方、Enabling Teamは、Platform Teamが開発した技術を内部に広めたり、他のチームが困っている部分をPlatform Teamに伝えたりするなど、様々な役割を果たしています。
Stream Aligned Teamとの役割分担についてですが、これは非常に明確です。具体的なビジネスに直結した機能の開発は、Enabling TeamやPlatform Teamではなく、Stream Aligned Teamが行っています。
例えば、ビジネスの課題解決やAPIサーバーの構築など、提供体験の作成を担当します。また、Stream Aligned Teamが作成したアプリケーションやクラウドシステム、ネットワークなどの基盤などを広めるのがPlatform Teamの役割です。
マイクロサービス間での基本的な設計方針
大谷氏：ありがとうございました。次の質問に移りたいと思います。
「マイクロサービス間での基本的な設計方針などがあるのでしょうか」とのことですが、お二方それぞれいかがでしょうか。
pospome氏：
特に決まりはありません。その要件に合った通信をしてくださいという感じになります。
伊藤氏：
明確な線引きはしていないものの、マイクロサービスをgRPCで記述し、通信も必ずgRPCで行うというルールは決めています。
データベースへの書き込み処理を必ずイベント駆動にするというルールなどは、逆にやらない方が良いと社内では認識しています。オーソドックスにgRPCサーバーのRPC同士で通信し、非同期に逃がすときは、例えばCloud Pub/Subで、チーム向けにそれを他のチームのAPIをRPCとして呼び出す形をスタンダードにはしています。
ファクトスタンダードを外れる権利の保護
大谷氏：
次に、ファクトスタンダードを外れる権利はどのように保障されているのでしょうか？私（質問者）の経験上、指定されたバージョン以外のTomcatを使用すると、全OSミドルのバージョンアップに対応する必要があると指摘され、結局断念したという経験があります。この辺りの権利の保証について教えていただけますか？
pospome氏：
保証はしていません。標準から外れた場合、全てをチーム内で対応する形になります。例えば、特定のアプリケーションをAWSで動かしたい、ECSを使うとなったとき、まずはAWSアカウントの払い出しから始めてもらうことになります。
基本的に技術選定は私が行っているため、基本的に標準から外れる必要はないという前提があります。そのため、よほどのエッジケースでなければ外す必要がありませんし、外れる場合の条件はかなり厳しいです。
大谷氏：
標準を外れるチームに対して保証はしないという形ですね。
pospome氏：
そうですね。外れた場合の権利を保障すると、外れるチーム全ての運用や管理が発生するので、結果的にチームとしての開発スピードが落ちてしまいます。
Team Topologiesを浸透させるには？
大谷氏：
わかりました。ありがとうございました。次に、「Team Topologiesにおいて認知負荷やコミュニケーションパスを健全にすることが重要だという考え方を、会社組織にどのように浸透させるべきでしょうか？」とのことですが、いかがでしょうか。
伊藤氏：
「Team Topologies」のような概念は、経営層や非エンジニアリングのメンバーにはあまり理解されていません。そこで組織が大きくなってくるようなタイミングを見計らい、経営者やエンジニアリングマネージャー、ステークホルダーなどの意思決定できるメンバーに対して働きかけて、「Team Topologies」のような考え方を社内で話したりなどして、浸透するように進めます。
大谷氏：
ステークホルダーへの説明には「Team Topologies」の概念を理解するために、資料を用意するなどの働きかけなどは行っているのでしょうか。
伊藤氏：
資料を大量に用意するようなことは行っていませんが、要点やメリットについてはしっかりと説明するようにしています。
「Team Topologies」は、チームのパターンを4つのパターンに分け、それに基づいてコミュニケーションのパターンを決定することでチーム間のコミュニケーションを効率的にし、結果的に生産性を上げるという概念です。その理解を深めることで、ステークホルダーも我々の取り組みに納得し、その後のプロジェクトを進めていくことができました。
経験の少ないメンバーとの向き合い方
大谷氏：
最後に質問になります。「言語を選定した場合、経験のないメンバーが渋る場合もあるかと思いますが、そういったケースとどのように向き合っていますか」とのことです。これについてはいかがでしょうか。
伊藤氏：
弊社のメンバーは学習に対しても比較的アクティブで、特定の言語に対して嫌悪感があるといった意見は特に見られませんでした。また、メンバーの人数がまだ少ないことも、こういった問題が起こらなかった要因と考えられます。
ただし、言語の選定など新しいことを学ぶ必要がある場合は、そのケアを怠らないようにしています。例えば社内の勉強会でその言語についての話題を提供したり、コーディング規約やリンターなどを全チームで共有したりなどを行っています。
また、一度プログラミング言語を学んだ経験があれば、他の言語を学ぶのはそこまで難しくないというのが私たちの考え方です。未経験の言語を学ぶことを成長の機会と捉え、そのような気持ちをメンバーにも共有し、オンボーディングなどを実施しています。
pospome氏：
もし、そのメンバーが特定の言語を嫌いという理由で学習を渋っている場合は、それは個々の好みに左右される部分なので仕方ありません。仕事なのでやってもらうようにお願いします。
もし、学習コストや時間を理由に抵抗を感じる場合、それらは業務時間中に確保することで解消できると思います。具体的な問題点に対しては、それぞれの原因を深く掘り下げ、適切な対策を考える必要があります。
