【イベントレポート】UV Study: Platform Engineeringの始め方 #UV_study

いつも記事を読んでいただきありがとうございます！
モブエンジニア（[@mob-engineer](https://qiita.com/mob_engineer))です！

今回は2025.04.25（金）に開催した**UV Study: Platform Engineeringの始め方**に参加しましたので、アウトプットとしてイベントレポートを執筆しました。

初見の方でもサクッと読めるように平易な表現で執筆しておりますので、お気軽に読んでいただければ幸いです。

:::note info
誤字脱字、わかりづらい表現、認識相違などは極力なくすように心がけています。そのうえで、リアルタイムで執筆しておりますので、誤字脱字、わかりづらい表現、認識相違などがあるかもしれません。
:::

#### イベントページ

https://uniquevision.connpass.com/event/350834/

#### ユニークビジョン様サイト

https://www.uniquevision.co.jp/

# 目次
- イベント概要
- セッション
    - 今日からはじめるプラットフォームエンジニアリング
- LT
    - 仮)この道四半世紀の どインフラ屋さんがPlatform Engineering組織にJOINしてみた体験談
    - 基盤チーム再始動から6ヶ月でデプロイ数を9倍にするまでの取り組み
    - TDB
- まとめ

## イベント概要
>本イベントは、
「Platform Engineeringを導入したいけれど、何から始めるべきかわからない」
「他社はどんなふうに取り組んでいるの？」
そういった疑問を持つエンジニアのための勉強会です。
現場でPlatform Engineeringに向き合っている登壇者たちによる、リアルな取り組みや課題、組織変革のヒントなどを共有します。
基調となるメインセッションと、多様な視点が得られるLTセッションの二部構成となっております。
会場では懇親会も予定しております。
Platform Engineeringを「知る」「学ぶ」「話す」きっかけとして、ぜひご参加ください！

## セッション

### 今日からはじめるプラットフォームエンジニアリング

#### 参考サイト

https://www.gartner.co.jp/ja/articles/what-is-platform-engineering

https://cloud.google.com/blog/ja/products/application-development/common-myths-about-platform-engineering

https://zenn.dev/shinyay/articles/idp-platform-portal

https://www.ryuzee.com/contents/blog/14566

https://speakerdeck.com/iwamot/team-topologies-in-practice-on-aws

- 自己紹介
    - 普段はjacopenと呼ばれている
    - PagerDuty所属のプロダクトエバンジェリストの方
        - （個人的意見）プラットフォームエンジニアリングの発起人ですね
- プラットフォームエンジニアリングの起こり
    - 始まりはクラウドの登場とDevOpsの考え
        - エンジニア一人がインフラ・開発をすべて行うことが理想
        - ただし、そんな人材は少ない＋企業で採用できない
            - （個人的意見）そんな人材はいないですね～
        - 認知負荷に関しても高くなっている
            - （個人的意見）クラウドすべて理解する＋CI/CD＋コンテナだけでも厳しいですよね
    - 認知負荷の軽減＋開発者体験の向上＋生産性の向上を目的にプラットフォームエンジニアリングが生まれた
- ゴールデンパス
    - プロジェクトによってベストプラクティスは変わってくる
        - 例えば、GitHubを利用しているのであればGitHub Actionsを利用するなど
    - ベストプラクティスを実現するための道筋をゴールデンパスと呼ぶ
- IDPあれこれ
    - 2種類存在するため誤解を生みやすい
        - 開発者を利用するためのツールとインターフェースに分かれる
- プラットフォームエンジニアリングの進め方
    - いきなり共通基盤の構築から始めるとうまくいかない場合も
    - インタラクションモードを理解してチームへ浸透させる
        - （個人的意見）チームトポロジーの考えは誰しもが理解しないとですね
    - AWSのワーナー氏もプロダクト開発で浸透させている
    - プラットフォームエンジニアリングを成功させるのであれば定義を忘れること
        - 本質である「開発者体験＋生産性向上」を理解することが重要
        - まずは、開発のつらいところを理解し、言語化していく
        - （個人的意見）分かりみが深い内容ですね
    - 小さいチームでも課題はある
        - 数人規模の開発でもパイプライン設計・envファイル共有などの課題もある
        - （個人的意見）誰しもがプラットフォームエンジニアリングに貢献で切る可能性がありそう
- チームトポロジーの作り方
    - １対多の場合：勉強会チームからのアウトプット・フィードバック
        - 最も小さいプラットフォームはただのWiki
            - （個人的意見）Notionにまとめるのは面白いですね～
    - 1対1の場合：コラボレーションから始めていく
        - コラボレーションを通じて腹落ちしてからプラットフォームを作っていく
    - （個人的意見）「いきなりプラットフォームを構築しない」というのが大切なのね
        - プラットフォームについてもコラボが完了したものから自動化していく
    - 開発者体験が良ければプラットフォームがなくてもいい
        - （個人的意見）開発者体験が第一なのはその通り過ぎる
- 開発者体験のつぎに重要なもの
    - 相手との信頼関係が第二に重要
        - （個人的意見）信頼関係づくりは本当に難しいですからね
    - プラットフォームを継続していくことが大切
        - （個人的意見）確かに続けていくことが大切ですよね

## LT

### この道四半世紀の どインフラ屋さんがPlatform Engineering組織にJOINしてみた体験談
-　自己紹介
    -　タイミー所属のプラットフォームエンジニアの方
    -　キャリアの始まりはネットワークエンジニア
-　会社について
    -　働きたい時間と働いてほしい時間をマッチングする隙間サービス
        -　ワーカー視点であれば働きたいときに働ける
        -　企業視点であればリソースを柔軟に活用できる
-　キャリアから見たプラットフォームエンジニアリング
    -　2015年ごろからインフラ領域の認知負荷が高まっている印象を持った
        -　（個人的意見）この時期からクラウドサービスが拡大していった印象がありますね
    -　プラットフォームエンジニアリングを行う目的は「プロダクトエンジニアリング」
        -　（個人的意見）ChatGPTの回答は確かに分かるが...
-　具体的な取り組みについて
    -　分業化・認知の外に置いていく・オーナーシップの分離
    -　会社の成長段階で考えてみることが大切
        -　数百名規模で行うのがベター
    -　最初期はプロダクト開発組織のみだった
        -　コスト最適化を考えるとプラットフォームエンジニアリングの存在が必要
        -　インフラ周りはプラットフォームエンジニアリングに回すことで開発に集中できる
    -　（個人的意見）やはり分業化を進めていくことが大切なのね

### 基盤チーム再始動から6ヶ月でデプロイ数を9倍にするまでの取り組み

#### 参考サイト

https://mosh.jp/

- 自己紹介
    - ソフトウェアエンジニアの方
    - プロダクト開発寄りのかた
    - OSS運用もされている方
- 開発組織
    - 小さなサービスをプラットフォームにまとめている
    - 開発チームとして機能開発チーム・プロダクティビティチームで分かれている
        - （個人的意見）チームミッションを言語化しているのはいい組織ですね
- デプロイ改善の流れ
    - ドキュメンテーションの仕組みづくり
        - 変更時の情報を文書として残していく
            - 仕様検討の背景をヒアリングする時間がかかっていた
            - 技術キャッチアップの時間がかかってしまう
            - （個人的意見）意思決定かノートかで変わってくるのよね
        - ソリューション選定について文書で振り返りができるようにした
    - 監視設定の見直し
        - 一元管理されたシステムモニタリングの基盤が難しい
            - DataDogを利用して一元管理した
            - （個人的意見）輪番制や学習会の文化は取り入れたいわね
    - CI/CDの課題
        - 手動デプロイ対応・メインブランチへのマージ
        - 動作確認のためマージがしょっちゅう起こってしまう
            - （個人的意見）品質向上の課題は抱えているのよね
        - 開発ボトルネックを分析し都度改善していく
- 改善を通じて見えたこと
    - デプロイ回数が約9倍へ増加することができた
        - （個人的意見）まずは私の知識拡充からだな
    - 事業メンバーを増やすことができた
        - 人数が増えることでパイプライン運用の新たな課題が見えたりする

### 共通テンプレートから始まるPLATFORM ENGINEERING
- 自己紹介
    - ハリネズミ好きのエンジニアの方
- プラットフォーム開発の背景
    - 開発体制の変化によってインフラ担当が別プロジェクトへ
        - 担当者ごとに認知負荷が増えてしまう
- 認知負荷軽減を実現するために
    - 開発言語の統一を行う
    - インフラ基盤についてもAWS一本化で行っていく
    - 開発ライブラリについても統一化している
        - Linter/Formatter、パッケージ管理など
    - CI/CDの改善について
        - GitHub ActionsでCI/CDを実現
        - CDK・Honoなどを利用して依存関係を解消
- 将来の開発のために
    - コーディングエージェント用のドキュメントがあれば開発が進む
        - テンプレート化することでメンテナンス対象を限定できる
        - （個人的意見）K8Sは確かに職人運用ですよね
    - （個人的意見）人材育成は大切なのよね

## まとめ

個人的にプラットフォームエンジニアリングをキャッチアップして社内開発を推進したいと思っていたため、本セッションを通じて多くの学びを得ることができました。

そのうえで、インプット↔アウトプットを通じてキャッチアップしていかないといけないなぁと思いました。

最後まで記事をお読みいただきありがとうございました！！