2024年7月13日
PEK 2024に当日スタッフ参加しました
Platform Engineering Kaigi 2024 に当日スタッフとして参加してきました。セッションを通じた自分なりの感想と、初めてカンファレンスの運営に携わったことについての感想を残しておきたいと思います。
イベント概要
以下の説明がとても端的に要点を得ていると思うので、引用します。
Platform Engineering Kaigiは、現在注目を浴びているPlatform Engineeringをテーマにしたテクノロジーカンファレンスです。
コンテナをはじめとしたクラウドネイティブ技術の発展やDevOpsの浸透、さまざまな便利なツールの登場により、アプリケーション開発の現場は大きく変わりました。その一方で、開発者一人が扱わなくてはいけない技術の高度化、複雑化により認知負荷が年々高まっていると言われています。認知負荷の高まりは生産性の低下に繋がるおそれがあり、せっかく導入した新技術がスポイルされかねません。
その解決策として期待されているのがPlatform Engineeringです。Team topologiesに基づいた適切なチーム分け、そして認知負荷を減らすことを目的とした共通プラットフォームを構築することによって、技術のコントロールを取り戻し、組織のスケーラビリティと生産性を両立することができます。
当イベントは今年初めての開催で、Chair の @jacopen 氏は来年もやりたいと話していました。来年も楽しみです。
アーカイブ
トラック A
トラック B
セッションに関する感想
まずは印象に残ったパートから。
Platform Engineering においてだいじなこと
次の点が強調されていました。
- プラットフォームを使うか使わないかは各チームに委ねられていて、誰も使用を強制しない
- ユーザーが関心を持って使いたくなるようにする
- そのためには、プラットフォームチームはいくらかマーケティングをしなくてはいけない
- 慎重に設計され、厳選されるべき
- 他のチームとしっかり相談する
- ペルソナにフォーカスして、ユーザーに合った製品を作る
- ユーザーの仕事を現状よりもシンプルにする製品を作る
- つまり、仕事が楽になる、認知負荷を減らせる製品を作ること
- 技術の変化を活用して進化する
- 機能の追加または削除によって進化させる
- 他のベンダーのサービスを活用して薄くしてことも必要
- 数ヶ月先までのロードマップを固めるのではなく、日々の変化に対応するべく毎週のように変わる柔軟なロードマップで信頼を勝ち取る
- プロマネが重要
- ユーザーは同僚なので、社内の事情や優先順位に精通した、熟練した人がやるべき
関連部分: トラック A 0:42:51
良いプラットフォームがあったとしてもそれが社内で認知されず、使ってもらえなければ意味がありません。そのためにプラットフォームチームはマーケティングをしていく必要があり、しばしば経営者にアプローチすることがあるかと思います。しかしながら、めでたく経営者にそのプラットフォームが気に入られて推進されていくことになったとしても、もしそれが 強制力を持って 推進されるとなれば、プラットフォームにとっては不幸なことだと思います。
プラットフォームはユーザーにフォーカスして、また、外部の変化を受けて、常に改善していき、ユーザーを獲得することで成長していくべきものです。経営者が社内の全チームに使うことを強制してしまうと、そのプラットフォームは成長機会を奪われてしまうのではないでしょうか。
プラットフォームの持続可能性
強固なプラットフォームを築くことは長い道のりで、継続的に予算を確保し続けることは難しいです。プラットフォームを持続可能にしていくためには経営者にプラットフォームの有効性を理解してもらう必要があります。
- CFO の立場になって考えてみる
- 彼らの関心事に刺さるようなデータを提示することで資金を得やすくなる
- e.g. 「クラウドのコストを10%削減しました」
- 「ラストマイル」にフォーカスすること
- つまり、どんな価値を生み出したかを測る
- e.g. どれだけ生産性が上がったか、プラットフォームを通じてどれだけ売り上げがあったか
- プラットフォーム内部の指標ではなく、ビジネスの言葉で会話することが重要
関連部分: トラック A 1:00:33
この点は会場の注目も高く、既に Platform Engineering を実践している各社も悩むことが多いのだなと思いました。質問でも、3年くらいごとにプラットフォームが解体されてしまっているという事例が登場しました。経営陣に何を提示すれば良いのかというこの質問に対する回答として、プラットフォームが解体された時の影響を裏付けるデータを見せるということが挙げられていました。
組織において、あるモノが作られたがそれが古くなってきたので解体され、「新 〇〇」や「NEXT 〇〇」への移行を余儀なくされるということはよくあると思います。その移行には（主体的であれ強制であれ）コストがかかります。もちろん必要に迫られて選択しているはずなのですが、必ずしも十分なデータに基づいて判断されているかは怪しいなと思いました。移行によってエンドユーザーにどんな価値を届けられるのか、どれくらいコスト削減になるのかなど、検討できる項目は多いです。完全に偏見ですが、日本企業は十分な分析をせずに破壊して、ろくに振り返りもしないので何も学ばないということをやりそうな気がします。
また、そもそも移行をせずに、そのプラットフォーム自体が変化し続けられればベストなはずです。そのためにはプラットフォームチームに十分な人員を配置しなくてはいけませんからコストがかかります。プラットフォームを持続可能にしていくには、その有効性を示すデータを測定し、経営陣と会話し続ける努力が必要なのだと認識しました。
Platform Engineering, SRE, DevOps
新しい言葉や概念が出てくると「それって既存のものとはどう違うの？」という疑問が湧くことがしばしばあります。「Platform Engineering と SRE の門」というセッションはそれに答えるユニークなセッションでした。
- SRE (Site Reliability Engineering)
- 組織が信頼性を制御するための技術
- ユーザーの満足と、限りあるリソースのバランスを取るための SLO
- システム全体の監視と自動化
- Platform Engineering
- チームが「どう機能」するかが本質
- 開発生産性の最適化
- 開発者のニーズに応じたインフラのカスタマイズ
- システムの安定性、自動化重視、継続的な改善、フィードバックループは共通
関連部分: トラック B 3:47:15
Platform Engineering と SRE は目指しているシステムの安定性などの目標は同じですが、それに対するアプローチが異なっていて、また互いに干渉するものでもないので両方ともやっていくことが重要なのだと学びました。「class SRE implements DevOps」という有名な言葉がありますが、Platform Engineering と SRE はともに DevOps という interface を実装するための両輪と言っても良いでしょう。
質疑でありましたが、チームを分けるべきかどうかは一概には言えず、最適解は組織によって異なるという点も参考になります。小規模なチームの場合は分けようがない場合もありますし、大規模なチームでは分けた方が効率的になる場合もあります。コンテキストスイッチは少なからず発生するのである程度の規模になったら分けた方が良い気がします。
運営参加に関する感想
今回私は当日スタッフとして参加したので、当日はお弁当を配布したりノベルティの引き換えをやったり会場のセッティングをしたりしてました。カンファレンスの運営に参加したのは今回が初めてだったのでとても新鮮でした。
学生でありながらインフラ分野に興味を持った人、実は自分と同じような仕事をしている人など、話しかけたことで色々な人に出会えました。コミュ障気味な自分としてはゲストとしてぽつんと参加するよりも、運営として参加した方が周りの人に話しかけやすく、イベントをより楽しめたと思います。次もまたどこか別の機会でコミュニティに貢献していきたいです。
おわりに
Platform Engineering は「エンジニアを幸せにしたい」という私の考えにも明確にマッチしていて、注目していることの一つです。私はいまプラットフォームチームに属しているわけではありませんが、今後も学んでいき、社内に共有していきたいと思っています。