プラットフォームエンジニアリング ―成功するプラットフォームとチームを作るガイドライン

訳者あとがき

私は現在、ソフトウェアテストに関するSaaSを提供している会社で働いています。入社したのは6年ほど前、最初の主力サービスを正式公開する直前でした。それから数年、私は新機能の開発、システムの安定化、スケーラビリティの改善などに取り組みました。時は過ぎ、幸いなことにサービスは成長し、数人しかいなかった会社は100人以上の規模になり、プロダクトを増やすことも決まりました。そのため、認証やストレージなど複数のプロダクトで共通するコンポーネントを切り出して、共通サービスを作ることにしました。まさにこの本で扱っているような社内プラットフォームです。

その社内プラットフォームを作り始めた時は、プラットフォームエンジニアリングという考え方は日本でも広まりつつあり、Platform Engineering Meetup（https://platformengineering.connpass.com/）のような勉強会もすでに立ち上がっていたはずです。しかし、当時の私は恥ずかしながら「プラットフォームエンジニアリングって、IDP（社内開発者ポータル）作る取り組みのこと？」ぐらいの解像度でいたというのが正直なところでした（すでに本文を読まれた方なら、これがあるあるすぎるよくない間違いであることはお分かりですね）。その社内プラットフォームの責任者は、将来のスケーラビリティや安定性の確保を優先してプラットフォームのアーキテクチャを慎重に決める一方、関係各所からはこのプラットフォームにはあれも足りないこれも足りないとつつかれるという、気の毒な立場でした。ちょうどその時、米O'Reillyからその名も「Platform Engineering」という書籍が、しかもそのタイトルの本を書くにふさわしい2人が著者となって出版されることを知りました。最近のO'Reilly（に限らず技術書出版社の多く）は、Early ...