Two Sigmaでプラットフォームエンジニアリングの責任者を務めるマネージングディレクタのCamille Fournier氏が先頃、社内のプラットフォームチームエンジニアリングチームのマネジメント経験から自身が得た教訓について講演した。氏が指摘した2つの大きな課題は、カスタマベースが小規模であることと、カスタマがプロダクトをどのように使用しているかを理解することの問題だ。さらに氏は、プロダクトとエンドユーザを最優先とする開発投資の重要性についても強調した。
"優れたプラットフォームチームは、自分たちが何を構築したのか、何を構築しているのか、それらのプロダクトがなぜエンジニアリングチーム全体をより効率的にできるのか、といったストーリを語ることができます"、と氏は言う。その上で、チームが"カスタマを重視し、戦略的にプラットフォームサービスを提供できる"ためには、メトリクス中心の方策を用いることが重要だ、と強調する。
Fournier氏に、氏が得た教訓とアプローチについて詳しく聞いた。
InfoQ: メトリクス中心の戦略はカスタマベースが小さい場合には難しい、という話題がありましたが、一方で、メトリクスを無視するのは危険である、という指摘もありました。プラットフォームチームとしては、どのようなバランスを取るべきなのでしょうか？
Camille Fournier: メトリクスを使って安易に次のプラットフォームを判断することが望ましくない場合があるのです。小規模なユーザベースでは、例えば、A/Bテストを実行するのは困難ですし、コンシューマアプリケーションのプロダクトマネージャが使うような古いデータ駆動アプローチを使うことも、非常に難しくなります。
だからといって、メトリクスをまったく無視するべきだという意味にはなりません。プロダクトの決定で使用するメトリクスは、"このシステムで一般的に使用されるAPIの中で、一番遅いのはどれか？"、といったものでしょう。システムの最大のユーザが誰であるかを特定して、何がうまくいっていて、何が問題なのかを話し合う上でも、メトリクスは有用です。それとは逆に、このデータからサービスを使っていないチームを見つけ出して、その理由を聞くこともできます！
さらに私は、プラットフォームエンジニアたちに対して、使用率のメトリクスを追跡可能なシステムを実装するように指示しています。プラットフォームの判断にメトリクスを用いる上で、それが共通的な問題だと見ているからです。提供するプロダクトがライブラリやフレームワークである場合は特にそうなのですが、システムの社内利用に関する追跡ができないことが多いのです。システムを効果的に運用するためには運用関係やパフォーマンス関連のメトリクスが必要ですが、それだけではなく、プロダクトの使用されている方法を知るために、使用方法に関するメトリクスやデータを早い段階から実装しておくことによって、より適切なプロダクト判断ができるようになります。
InfoQ: "開発のために開発するソフトウェア(software that is building to be built)"の意味について、詳しく説明してください。
Fournier: エンジニアはコードを書くのが好きなのです。そのため、問題が発生すると、その問題を解決するためにコードを書く必要があるようなソリューションに飛びつくことが多々あります。SaaSベンダを使わずに、自社製のメトリクスや監視システムを所有している企業がありますが、それはベンダ製品が面白くないエンジニアたちが、自社の特別なニーズに合わせやすい方法を選択した結果なのです。あるいは、出来合いのオープンソースが気に入らなくて、新たなWebフレームワークを開発するエンジニアもいます。これが今やらなければならない最も重要なことなのかという疑問を、なぜ誰も持たなかったのだろうか、とは思わないでしょうか？自ら開発したことが、既成のツールを使用する、あるいは既成のツールに何らかの手を加えて利用できるようにするよりも、本当によい判断だったのでしょうか？
これと同じようなことで、開発者がプロダクトをもっとクールにできるアイデアを持っている場合があります。"キャッシュシステムを独自に作ってこのデータを格納すれば、ずっと高速で使いやすいものになるはずだ！"と彼らは考えます。そして開発に着手し、システムはいつも汎用性をひとつ失うのです。ひとつのチームが一部を使用するだけかも知れませんし、そもそもそのソフトウェアには、あまり満足していないかも知れません。それでも私たちは、システムの開発、運用、サポートに多大な作業を投資するのです。私はそれは、そのソフトウェアの開発そのものが目的化している兆候だと思います。アイデアは気に入っているが、そのアイデアを役立てる方法が分からない、中止することで費用の無駄であったとは認めたくない、という理由で開発を続けているのです。
InfoQ: 開発済のシステムを引き継ぐ場合、チームが"自分たちが同意していない決定"に気を取られることなく、システム開発に集中するにはどうすればよいのでしょう？
Fournier: 先日、大規模なレガシシステムを運用しているエンジニアと話をしました。彼と私は以前から、そのシステムを拡張して新たなことをいくつか行う方法を考えていたのですが、よい手段が思い浮かばずにいたのです。彼は旧システムを廃止してリプレースすることを望んでいましたが、多大な移行費用が必要なことが分かっていたため、既存システムの修正との間で迷っていました。私は彼に、既存のシステムで十分なのは何パーセントなのか質問しました？20パーセント？50パーセント?80パーセント?旧システムは全体としてよいのか、それとも悪いのか？システムが私たち自身のレガシシステムであるか、あるいは誰かのシステムを拡張するつもりで引き継いだものか、どちらであってもこのような考え方をする必要がある、と私は思います。完璧なシステムは存在しないのです。システムの厄介な部分に手いっぱいになってしまうと、必要以上に書き直しをしたい衝動に駆られて、結局はそのシステムを引き継いだ元のチーム以外に役立つようなシステムの改善が何も進んでいない、という状況に気付くことになるかも知れません。そうではなく、大規模化した場合に問題になりそうな部分や、新機能を追加する上で実際に障害になっている部分に重点を置いて、まずはそれらを片付けることが必要なのです。システムの適用範囲を広げ、新たな機能を追加し、システムでの作業が本当に快適なものになれば、当初は納得できなかった設計判断の価値を認められるようになるかも知れませんし、そのような判断がシステム全体の障害にはなっていないことに気付くかも知れません。あるいは、修正することになる場合もまれにありますが、その場合でも、純粋に美学的な理由や、オリジナルのチームが使用した言語やフレームワークが気に入らないという理由で、システムの一部を書き換えることはしないでください。
InfoQ: 既存のエコシステムや文化を考慮するように勧めていますが、多くの企業において、これらは複雑で多様な概念です。そのような考慮を行う上で、何かアドバイスはありますか？
Fournier: エコシステムや文化が問題になるのは、おもに他の企業が採用していたソフトウェアやプラクティスを自社に取り入れようとした時です。Googleツールがそのよい例です。Googleツールを取り入れようとして躓くプラットフォームエンジニアはたくさんいます。Googleは優れた企業で、本当に素晴らしい社内ツールやインフラストラクチャを所持している上に、それらの多くをオープンソースとして公開しています。しかしGoogleの社員は、これらツールのひとつを独立して使っているのではありません。数多くの内部プロダクト、そしてGoogleの文化の中で、それらのツールは使用されているのです。
Googleのビルドツールとテストツールが好例です。Bazelは同社がオープンソースとして公開しているビルドシステムです。Googleの開発した多数のソフトウェアによって、同社のモノレポ(monorepo)内にあるソフトウェアの構築は極めて高速になっています。しかしGoole社内では、Bazelが単独で運用されているのではありません。他のツーリングによるエコシステム内で運用されているのであって、開発者がコードを書く場合に何を行うか、コードを修正し所有する上で何を期待されているか、などといった、明確な目的を持った文化の中で使用されているのです。潤沢な資金と才能ある多数の社員を持つ企業の中で、驚くべき開発者エクスペリエンスを実現するために運用されているのです。多くの人たちがBazelを導入し、自社内での運用を試みました。それは自社の開発者向け社内ツーリングスタックをよりGoogleライクにし、開発者エクスペリエンスをよりGoogle風にする上で、Bazelがそのマジックの重要な部分である、と想定した結果なのです。しかし、そのようなエクスペリエンスを実現するには、ツールだけでは不十分です。
自身の企業の中では、現実主義でなくてはなりません。ほぼすべてのチームがJavaを使っている中で、皆にPythonを使って欲しいと思うのならば、Javaを使用したソフトウェアを導入する、あるいは開発するよりも、はるかに厳しい道を進むことになります。Pythonを使用したツールがだめだと言うのではなく、やらなければならないことがずっと多くなる、という意味です。自分自身のコード以外にタッチしないような企業文化ならば、APIに大きな変更を加えた人が、すべてのコードやシステム自体にそれを実装することを期待するようなモデルを、大規模に展開するのは難しいでしょう。
InfoQ: 講演では、"すべての代替策を使い果たした場合にのみ、開発を行う"べきだ、と強調していましたが、プラットフォームエンジニアが最初の選択肢として開発に飛びつかないようにするために、何かアドバイスはありますか？
Fournier: まず最初に、個々のツールではなく、真のポートフォリオとプラットフォームを作り出すには、他の人たちのソリューションの上に構築することによってこそ、より多くの成果を上げられるのだ、ということを理解してください。監視システムやログアグリゲータ(aggregator)、優れた可視化ダッシュボード、優れたCI/CDシステム、優れたオーケストレータを開発するのは難しい作業ですが、これらのプロダクトを他の人たちやオープンソースから調達して、自社の開発者すべてに対して完全にシームレスな動作を提供できるようにすれば、非常にパワフルなプラットフォームが出来上がります。そのためにはいくらかのコードを書くことになりますが、それは通常とは違う場所になるかも知れません。自身のオーケストレーションロジックを開発して、これらすべてを連携させる必要があるかも知れません。必要なものが不足しているために、Kubernetesのプラグインを開発しなければならないかも知れません。会社で使っている言語のために、もっと効率的なロギングライブラリを開発する必要があるかも知れません。それは分かりませんが、クラウドベースのスイート、SaaS、オープンソースを活用して自社の開発者にとって生産的なプラットホームを提供するプロセスにおいて、相当量のコードを書かなければならなくなるのは間違いないでしょう。そして、これらのプロダクトが全体として適切に動作することに集中すれば、カスタマに対して非常に大きなプロダクトバリューを提供できることになるのです。