プラットフォームエンジニアリング 5

正式にプラットフォームチームが必要になる前もチームとしてそういう活動はするっていうのは、あくまでPMF前の小規模開発チームでその中でバージョン管理やCICDなんかをちゃんとやっておくっていう当たり前の話。そこからさらにプラットフォームの中核となるようなコンポーネントが生まれてもまだそれは開発チーム内の話。 そこから中央集権的なプラットフォームチームを誕生させるためにコストなどを考えたうえでそういう組織を誕生させる。そしてそのときは「共同作業を行うときは過ぎた」ということを認識する必要がある。 インフラチームは使われる場面のことを想像するのが不得意的なことがあって本当？と思ったけど、それは次の章にかいてあった。

システムによりすぎてもソフトウェアによりすぎてもだめで、それぞれのケイパビリティを理解することが大事そう。つまり、

• ソフトウェアを焦点とするソフトウェアエンジニア
• システムを焦点とする
  • リライアビリティエンジニア
  • システムエンジニア
  • システムスペシャリスト このあたりをちゃんと誰が何であるのか？を明確にしていくことで協業も進むし、そもそも組織文化や採用計画みたいな部分も改善されていきそうな感じがある。なんとなく、インフラチームだからインフラエンジニアの求人という感じだと結構厳しそうな気がする。いや、採用はそれで良くてもプロセスの中である程度期待値を言語化していくってそういうことなんじゃないかなあ。多分。 自分はどれなんだろう。データ関連だから難しいけどリライアビリティあたりなんだろうなと思う。興味範囲として。

社内プラットフォームとはいえ、一般的なSIとかと同じように言われたものを作る、だと失敗する。関係性ベースの表明された好みに従うだけでなく、顧客の顕在化された好み=実際にどうシステムが使われ、どんなタスクを実行しているかを特定する必要があり、計画はそこから立てるべきである。 となると、やっぱりちゃんとしたプロダクトマネジメントのアプローチをいれていかないと良くなさそう。