プラットフォームチームが実現したいこと

HRBrainプラットフォームチームのテックリードのhidetatzです。札幌に住んでいるんですが雪がヤバいです。

このブログでは、HRBrainのプラットフォームチームとはどういうチームで、普段何をしていて、何を考えているのかを紹介します。社内のメンバーに知ってもらいたくて書いている部分もありますが、私達のことをもっと知ってもらうために、そして私達の仲間を増やすためにこの記事を書くことにしました。この記事を読んでもらって、私達の仕事の面白さを知ってもらい、話してみたいと思ってもらえたらいいなと思います。

プラットフォームチームは「インフラチーム」「DevOpsチーム」「SREチーム」のいずれでもありません。私達のチームが向き合っているプラットフォームエンジニアリングというタームは比較的新しいもので、よく説明されている記事は (特に日本語では) 筆者はあまり見かけません。この記事では、プラットフォームエンジニアリングとはなんなのかという点にも触れながら説明していきます。

プラットフォームエンジニアリングとはなにか

まずは私達のチームの話ではなく、もっと一般的な話からしましょう。

プラットフォームエンジニアリングは比較的新しいタームで、特に定義のようなものは筆者の知る限りありません。

インターネット上では、例えばThe Rise of Platform Engineering - Software Engineering Dailyには次のようにあります (太字は筆者によるものです) 。

The most prominent theme would likely be similar to the idea of bridging the gap between software and hardware. In other words, platform engineers enable application developers to put software into the hands of users in an easier manner.

あるいは、DevOps, SRE, and Platform Engineeringでは次のようにあります (太字は筆者によるものです) 。

From my understanding, Platform Engineering focuses on developing an ecosystem that can be efficiently used from the Dev, Ops, and SRE standpoints.

どちらも、アプリケーションの開発者が利用して開発を簡単に行うものであると、そんなには遠くないようなことを説明しています。これらはどちらも、筆者の理解とは特にずれていません。 筆者はしばしばプラットフォームエンジニアリングを、「開発者がアプリケーションをより簡単に、より素早く、より効率的に開発・運用するためのプラットフォームを開発すること」と説明しています。では、そのプラットフォームとはなにか?単なるインフラとは違うのか?という疑問が考えられるので、次に「プラットフォーム」について考えていきましょう。

プラットフォームとは

プラットフォームとは、アプリケーション開発者がより簡単にその開発や運用をするための基盤のことです。すなわちプラットフォームの利用者とは、アプリケーションを開発し運用するソフトウェアエンジニアです。まず、プラットフォームがなかった場合にどうなるか、例を挙げて考えてみましょう。

アプリケーションを開発・運用するためには、ネットワーク、サーバ、データベース、あるいは監視システムなどいろいろなものを調達する必要があります。パブリッククラウドによってこれらはかなり簡単にはなりましたが、パブリッククラウドを正しくうまく使うのは今もある程度の経験や専門知識が必要です。

例えば、インフラストラクチャのプロビジョニングにTerraformを使いたいとします。アプリケーション開発者はデータベースとサーバを単に作成できればいいはずなのに、Terraformの実行基盤やステートの管理などを準備するのはある種のYak Shavingといえるでしょう。これが最初の一度だけ発生するならまだ良いですが、たくさんのチームが同じことをするのは面倒です。プラットフォームがないと、最悪の場合、開発者一人ひとりがこういった問題に向き合う必要があります。

このようなケースで、 .tf ファイルだけ書いてマージすれば自動でいい感じに terraform apply してくれる基盤を作ろう!と考えるのはごく自然な発想です。その基盤があれば、アプリケーション開発者が自分たちに必要なインフラをプロビジョニングするのはずっと簡単になります。これは「開発者が簡単にインフラストラクチャをプロビジョニングすることでシステム開発を簡単にする」プラットフォームと言えるでしょう。そして、こういった基盤作りをやってみたいと思える人は、プラットフォームエンジニアに向いているのではないでしょうか。

ちょうどOSがハードウェアを抽象化するように、あるいはパブリッククラウドがコンピュータ資源を抽象化するように、プラットフォームはパブリッククラウドや様々なIaaS、PaaS、TerraformやAnsibleといったソフトウェアをアプリケーション開発者のために抽象化します。

HRBrainのプラットフォームチーム

プラットフォームチームのミッション

HRBrainのプラットフォームチームでは次のようなミッションを置いています。

「アプリケーションが高速に開発され、高い信頼性を持って稼働し続ける仕組みを創る」

HRBrainというシステムを支えるのはアプリケーション開発者です。彼らが機能を作ったり消したりする中で、システムはより便利に改善され、結果的にお客様により多くの価値を届けることができます。 プラットフォームチームはなるべく彼らが機能開発とその運用だけに注力できるように支える、縁の下の力持ちのようなチームです。実際チームには、そういった仕事を楽しめる人が揃っているのではないかと思います。

また、システムは作った後が最も大切です。私達の開発組織は機能を開発して終わりではなく、作ったものを運用し、それが常に使える状態であることを極めて重視しています。 この点にもプラットフォームが貢献できることは多くあり、運用という言葉もミッションに入れています。

プラットフォームチームのカルチャー

私達のプラットフォームチームには重視しているカルチャーがあります。それらをいくつか紹介します。

シンプルなプラットフォーム

後でまた触れるのですが、開発者にとってのプラットフォームのインタフェースには様々なパターンが考えられます。 例えば、インフラストラクチャをTerraformでプロビジョニングするIaCプラットフォームのようなものを考える時、その開発者にとってのインタフェースは様々に考えられます。

  • GitHubのリポジトリに .tf ファイルを編集したPRを作成、マージすることでプロビジョニングされる
  • GitHubのリポジトリに .tf ファイルを編集したPRを作成することは必要だが、作るリソースはほぼすべてモジュールとして抽象化されているので自分で書かなければいけないことはほとんどない
  • 専用のWebサイトを作り、GUIで作りたいインフラストラクチャを選択すれば裏で .tf ファイルが生成されている。つまり開発者は .tf ファイルを書く必要はないし、書き方を知っている必要もない

後になればなるほど、アプリケーション開発者にとっては簡単になり、プラットフォームエンジニアにとっては複雑で難しくなります。 この中でどのようなインタフェースを開発者に提供するのかはアプリケーション開発者の規模や実際使える時間、あるいはプラットフォームエンジニアの考え方にも左右されるでしょう。

私達のチームは、なるべくシンプルで、内部の仕組みを理解したくなった時に素早く理解できるような「普通の」プラットフォームを作るよう心がけています。個人的には、開発者の規模が100人を超えたらこの方針は見直す必要があるとは考えています。しかし現時点ではシンプルに作ることで、素早く作ることと素早く理解できることを達成しようとしています。

豊富なドキュメント

プラットフォームは開発者が使うものなので、開発者がその使い方や、何ができて何ができないかなどを理解できる必要があります。開発者に対するプラットフォームのオンボーディングの一環として、 私達はなにかプラットフォームに機能を入れるときは必ずドキュメントを書いています。開発者向けのドキュメントと、プラットフォームチームメンバー向けのを基本的に必ず書くことを半ばルール化しており、前者はdevelopers manual、後者はinternal manualと呼んでいます。 ドキュメントを書くことは実際はメリットとデメリットがありますが、私達はカルチャーとして、非同期でローコンテキストなコミュニケーションを支えるドキュメントを強く重視しています。 一方で、ドキュメントさえ用意すれば全員それを勝手に読んで勝手に使えるかというとそうでもなく、ワークショップなどの形式のオンボーディングも必要に応じて行います。

インフラチーム、運用チーム、SREチームではない

新しく入社した人にプラットフォームチームの紹介をしていると、「SREチームですか?」と聞かれることがたまにありますが、明確に否定しています。 私達は、開発者全員にサイトリライアビリティへのオーナーシップを求めています。システムは作った後が最も大事であり、開発者自身が作ったシステムの信頼性に開発者自身が向き合うのが最も良いはずだと信じています。 一方で、そういった経験の浅いメンバーにとってサイトリライアビリティを上手くやれるようになる難易度はかなり高いと考えており、その能力の向上もプラットフォームチームで担いたいと考えています。

プラットフォームの中身

ここでは実際に、私達のプラットフォームチームが開発・運用しているプラットフォームにどんなシステムがあるのかをいくつか紹介します。 なお、ここで挙げるのは既に開発自体終わっているもの、開発中のもの、あるいは将来開発予定でロードマップに載っているものも含まれています。

Application Workloads Platform

開発環境や本番環境のアプリケーションをデプロイし、ワークロードをさばく基盤です。現状はGCPのGKEを利用していますが、GKEが私達の組織に最適か?は常に考えており、実際Cloud Run等への移行も検討しています。 開発者がどこまで基盤部分を意識する必要があるのか (あるいは意識すべきか) は設計において重要なポイントであり、基盤をどこまで抽象化するのかは規模によって変えていく必要があります。HRBrainのシステムを支える重要な基盤のひとつです。

Development Platform

運用時でなく、開発時に必要な仕組みを指します。HRBrainのモノレポや、ライブラリの自動アップデート機構、テストカバレッジの計測、また「ブランチデプロイ」と呼ばれるパーソナル動作確認環境など、快適なアプリケーション開発をサポートする仕組みを整えています。

Infrastructure Platform

パブリッククラウドを使いこなすにあたり、インフラストラクチャをソフトウェアのように構築・変更できるIaC基盤を提供しています。中身はTerraformを使っており、PRベースでプロビジョニングが簡単にできるようになっています。 現状の課題として、危険なインフラストラクチャ (異常に価格の高いインスタンスや、安全でないネットワーク設定など) を開発者が誤って作ってしまうことを防げておらず、将来やりたいことのひとつです。

Security & Compliance Platform

インフラレイヤのセキュリティとアプリケーションセキュリティを分けて考えています。前者については、Cloud Armorを使ったWAF機構やイメージスキャンといった、アプリケーションの特定の箇所によらないセキュリティ基盤をメンテナンスしています。また、GCPのIAM機構の整備も行っており、開発者が不要に強い権限を持たなくて良いように、そして必要なときにはオンデマンドで必要な権限を得られるように仕組みを作っています。 アプリケーションのセキュリティについてはアプリケーション開発者にオーナーシップを持ってもらっていますが、gosecやCodeQLを使ったアプリケーションコードのスキャンといった機械的にできる部分はプラットフォームにビルトインしています。

Monitoring & Alerting Platform

ログやトレースの出し方・見方を開発者にドキュメントを書いて伝えています。また、ダッシュボードやアラート、ページを開発者が利用するためのサポートや、Datadogの使い方のレクチャーといったプログラムも行っています。 ポストモーテムの執筆やSLO策定及び運用のサポートなど、アプリケーションの運用・サイトリライアビリティ能力の向上にも貢献しています。

これら以外にも、Continuous Delivery PlatformやTesting platformなどいくつか名前をつけているものがありますが、まだまだやれていないことが多いのが現状で、プラットフォームチームではメンバーを強く募集しています。

プラットフォームエンジニアのチャレンジ

私達のチャレンジをいくつか紹介します。

ガードレールの高さ

プラットフォームの重要な機能のひとつに、「アプリケーション開発者が間違ったことをできなくする」というものがあります。 例えば先程のTerraformの例で言うと、間違った設定や作るべきでないリソースの作成をできなくすることで、アプリケーション開発者のミスを防ぎプラットフォームのUXを高めることができます。この、「間違ったことをできなくする」ことをプラットフォームのガードレールと呼んでいます。

ガードレールを高くすれば、ミスを減らせる代わりに開発者の自由を奪うことにもつながります。ガードレールを低くすることで開発者はプラットフォームで良くも悪くもいろいろなことができるようになります。 プラットフォームエンジニアにとってどちらが楽か?という視点では、これはどちらともいえないと考えています。不正な入力をバリデーションすることで、入力のパターンが減り楽になることもあれば、そもそもバリデーションが大変すぎるケースもあるでしょう。 これには正解は特になく、どういった設計がその組織に最適なのかはプラットフォームエンジニアの腕の見せ所だと考えます。今のところ私達は、開発者になるべく自由を与えず、間違ったことがなるべくできないプラットフォームを作ろうとしています。セキュリティと同じで、きつく締めたものを緩めるほうが簡単だからです。

組織の規模にあったプラットフォーム

私達の開発組織は現状数十人の組織です。筆者はこのくらいの規模のプラットフォームと、100人のためのプラットフォーム、あるいは500人のためのプラットフォームは作り方が異なるはずだと考えています。

数十人程度の組織では、まだお互いのことも把握できており、しないでほしいことに対して「それはしないでください」と伝えるというやり方が効きます。

しかし、規模が大きくなると思いがけないことをする開発者が現れたり、システムの抜け穴が見つかってしまうかもしれません。大きな規模のプラットフォームはより防御的でなければいけないですが、それは当然作るのに時間がかかります。「シンプルなプラットフォーム」でも触れましたが、このへんのバランスをどう設計するかには日々頭を悩ませています。

これからの組織の規模やあり方を想像し、それに合ったプラットフォームを設計する必要があります。これは口で言うよりかなり難しく、そしてやりがいのある仕事です。

Platform as Product

プラットフォームエンジニアリングにおける重要な考え方のひとつが「Platform as Product」です。

Platform as Productとは、プラットフォームを単なるツールではなく、「開発者」という「顧客」に提要するプロダクトとして捉える考え方です。

プラットフォームをせっかく作っても、使われなければなんの意味もありません。また使われていたとしても、そのやり方しかないからしかたなく使っているのと、喜んで使っているのは大きく異なります。

プラットフォームを主に使うことになるのはプラットフォームエンジニアではなくアプリケーション開発者なので、彼らの課題を深く理解し、彼らが喜ぶものを作る必要があります。これは、一般的なプロダクト開発とあまり変わりはありません。そこで、プロダクト開発のプラクティスをプラットフォーム開発にも取り入れようというのがPlatform as Productの考え方です。

私達も開発者に対してサーベイを実施するなど、顧客である開発者の課題を解決しようとしています。プラットフォーム開発では、顧客はすぐ近くの同じ社内にいるので、一般的なプロダクト開発よりもフィードバックを受けやすいのは面白い点です。

また、MVPの定義やミッション・ビジョンの策定、あるいはOKRの導入など、世の中にあるプロダクトマネジメントの知見を取り入れて、自分たちのプラットフォーム開発をどんどん改善していくことができます。

HRBrain開発組織の進化の基盤になる

私達の開発組織はビジネスや組織の規模の拡大に伴って、これまでと技術的課題の性質やその難易度が変わってきています。これまではハイスピードに機能を世に出すことが最も大切でしたが、これからは信頼性やパフォーマンス、セキュリティなどを今まで以上に上手くやれるようになる必要があります。

プラットフォームチームでは、これらを支援するプラットフォームの開発により、これらの問題を仕組みで解決しようとしています。一方で、仕組みだけではなく、そもそもの開発者のこれらの能力の向上にも貢献しようとしています。プラットフォームチームはDevOpsやサイトリライアビリティをEnableする仕組みを作っているので、まずは私達自身がDevOpsやサイトリライアビリティの専門家である必要があります。これらの知識や技術を開発組織全体に波及させていければ、私達の開発組織はもっとレベルアップできるはずです。これも私達がやりたいことのひとつです。

おわりに

HRBrainのプラットフォームチームを紹介してきました。私達は、開発組織の進化を支える誇るべきチームです。一般的なプロダクト開発とは異なる、開発者のための仕組みを作るやりがいや面白さがあります。

私達のチームではプラットフォームエンジニアを募集しています。プラットフォーム開発の経験や知識よりも、プロダクト開発のマインドを持っていることや、開発組織を縁の下の力持ちとして支えることを楽しめるかを重視しています。このポストを読んで面白そうと思ってもらえたら、プラットフォームチームのテックリードである私とぜひ話しましょう。最近Job Descriptionも書き換えたので、読んでください。

プラットフォームエンジニア | 株式会社HRBrain

参考

What I Talk About When I Talk About Platforms

The Rise of Platform Engineering - Software Engineering Daily

DevOps, SRE, and Platform Engineering

Code less, engineer more – Increment: Teams

Product management in infrastructure eng. | Irrational Exuberance

Product for Internal Platforms. For the past 3 years, I have been… | by Camille Fournier | Medium

Applying product management to internal platforms | Technology Radar | Thoughtworks

The human scalability of “DevOps” | by Matt Klein | Medium

Platform Engineering: Challenges and Solutions – The New Stack

社内PlatformチームのProduct Management | Taichi Nakashima

世界に誇れるプラットフォームチームをつくる - Speaker Deck