Two Sigmaでプラットフォームエンジニアリングの責任者を務めるマネージングディレクタのCamille Fournier氏が先頃、社内のプラットフォームチームエンジニアリングチームのマネジメント経験から自身が得た教訓について講演した。氏が指摘した2つの大きな課題は、カスタマベースが小規模であることと、カスタマがプロダクトをどのように使用しているかを理解することの問題だ。さらに氏は、プロダクトとエンドユーザを最優先とする開発投資の重要性についても強調した。

“優れたプラットフォームチームは、自分たちが何を構築したのか、何を構築しているのか、それらのプロダクトがなぜエンジニアリングチーム全体をより効率的にできるのか、といったストーリを語ることができます”、と氏は言う。その上で、チームが"カスタマを重視し、戦略的にプラットフォームサービスを提供できる"ためには、メトリクス中心の方策を用いることが重要だ、と強調する。

Fournier氏に、氏が得た教訓とアプローチについて詳しく聞いた。

InfoQ: メトリクス中心の戦略はカスタマベースが小さい場合には難しい、という話題がありましたが、一方で、メトリクスを無視するのは危険である、という指摘もありました。プラットフォームチームとしては、どのようなバランスを取るべきなのでしょうか？

Camille Fournier: メトリクスを使って安易に次のプラットフォームを判断することが望ましくない場合があるのです。小規模なユーザベースでは、例えば、A/Bテストを実行するのは困難ですし、コンシューマアプリケーションのプロダクトマネージャが使うような古いデータ駆動アプローチを使うことも、非常に難しくなります。

だからといって、メトリクスをまったく無視するべきだという意味にはなりません。プロダクトの決定で使用するメトリクスは、“このシステムで一般的に使用されるAPIの中で、一番遅いのはどれか？”、といったものでしょう。システムの最大のユーザが誰であるかを特定して、何がうまくいっていて、何が問題なのかを話し合う上でも、メトリクスは有用です。それとは逆に、このデータからサービスを使っていないチームを見つけ出して、その理由を聞くこともできます！

さらに私は、プラットフォームエンジニアたちに対して、使用率のメトリクスを追跡可能なシステムを実装するように指示しています。プラットフォームの判断にメトリクスを用いる上で、それが共通的な問題だと見ているからです。提供するプロダクトがライブラリやフレームワークである場合は特にそうなのですが、システムの社内利用に関する追跡ができないことが多いのです。システムを効果的に運用するためには運用関係やパフォーマンス関連のメトリクスが必要ですが、それだけではなく、プロダクトの使用されている方法を知るために、使用方法に関するメトリクスやデータを早い段階から実装しておくことによって、より適切なプロダクト判断ができるようになります。

#japanese build systems #continuous integration #プラットフォーム #カルチャー＆手法 #デベロップメント #devops #ニュース