「プラットフォームエンジニアリング」を読んだ

プラットフォームっぽい立ち位置にずっといる気がするけど、全然わからないので読んでみることにした。

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

目次は以下。

第Ⅰ部プラットフォームエンジニアリングとは何であり、なぜプラットフォームエンジニアリングなのか

1章プラットフォームエンジニアリングが重要になりつつある理由

2章プラットフォームエンジニアリングの柱

第Ⅱ部プラットフォームエンジニアリングの実践

3章どのように、そしていつ始めるか

4章素晴らしいプラットフォームチームを作る

5章プロダクトとしてのプラットフォーム

6章プラットフォームの運用

7章計画とデリバリ

8章プラットフォームのリアーキテクチャ

9章プラットフォームのマイグレーションと廃止

10章ステークホルダとの関係管理

第Ⅲ部プラットフォームエンジニアリングの成功指標

11章プラットフォームに整合性がある

12章プラットフォームが信頼されている

13章プラットフォームが複雑性を管理している

14章プラットフォームが愛されている

プラットフォームエンジニアリングで出てくるプラットフォームってどういうものなんだろうかと思っていた。本書を読んだ限りだとセルフサービスAPIやツール、ナレッジ、サポートを含む基盤を、アプリケーション開発チームの生産性を向上させるために提供するものになるのだろうか。たくさんの人が一緒に使うものだけではなく、生産性が向上することが目的となっていることが大事なのかなと思った。そして生産性を向上させるだけでなく、運用の負担を軽減し、最終的には全体の効率を高めるという観点はなるほどと思った。

多様なOSS やクラウドサービスを各チームが個別に選択し自由に組み合わせて使ってしまうと、それぞれをつなぐためのシステム開発も必要になるためどんどん複雑性が増大してしまう。これではメンテナンス性も下がってしまうため、統一をして運用まで見据えた設計をしたプラットフォームを提供することが大事。

プラットフォームエンジニアリングの成功に不可欠な4つの柱が紹介されている。「プロダクトアプローチ」「ソフトウェア開発」「幅広い開発者対応」「運用基盤」の4要素で構成されており、複雑なシステムを管理し、ビジネス基盤としての運用をするための必要なポイントとして紹介されている。ソフトウェア開発は普通にアプリケーションを作成するものではなく、複雑なシステムをユーザーにとって使いやすく、効果的に抽象化するための開発の重要性を感じた。

プラットフォームを作るタイミングやチームに必要なメンバ、文化についてもたくさんの記載がある。その中でも自分の分野や好みに、今までの経験に引きずられてしまうため、複数のエンジニアが所属するチーム編成にするというのはたしかになと思った。バランスがとても大事。
プラットフォームのアーキテクチャとして設計についてや移行と終了についての記載もある。V2 構築とリアーキテクトについての比較も面白かった。リアーキの方が稼働しているシステムに対して段階的に再実装する反復的なプロセスになるため、無駄な機能追加を避け、顧客への影響やリスクを最小限に抑えられると説明されている。

Ⅲ部では信頼されているか、愛されているかなどプラットフォームが組織に受け入れられていることがいかに大事かが説明されている。プラットフォームが成功するためには使ってもらう方からの信頼が不可欠。信頼を得るために運用をしっかりする、ボトルネックにならない、気に入ってもらえているか、無駄なコストがかかってないかなどの指標があるらしい。自分たちの提供しているシステムがどう思われているかを定期的に情報収集してみたい。