ギフティにおける プラットフォームエンジニアリングことはじめ Platform Engineering Meetup #15 2025/11/27 

● j-maki(じぇまき) ● ギフティで3年半くらいエンジニアとして働いています。 ● 趣味はトロンボーンという楽器です。(歴18年くらい) ● プラットフォームエンジニアリングを初めて日が浅いので、お手柔らかにお願 いします🙏 自己紹介 

● 発表の想定聴衆 ○ プラットフォームエンジニアリングをこれからはじようとしている方 ○ 詳しい方は、ぜひお会いした際にアドバイスを頂けると助かります ● 持ち帰って欲しいもの ○ プラットフォームエンジニアリングの始め方の一例 ○ (オフラインの方は)懇親会での話のネタ 今回の想定聴衆と持ち帰って欲しいもの ゆるい発表 なので 気軽に聴いてね 

● 会社紹介とPEチーム*立ち上げの経緯 ● 半年の取り組み紹介(組織編) ● 半年の取り組み紹介(技術編) *以降はスペースの都合上、概念としてのプラットフォームエンジニアリングは PEと略して表記します。固有名詞としてのプラットフォームエンジニアリン グもしくはPlatform Engineeringはできるだけそのまま表記しています。 アジェンダ 

ギフティって何やっている会社？ 「eギフト」を軸に様々な事業を展開している会社です。 

開発組織の特徴 

全エンジニアがフルスタック故の課題が顕在化 ● これまでは各プロダクトのエンジニアがフルスタックで開発 ○ フロント+バックエンド+インフラ+設計+運用 ○ フルスタックかつフルサイクル ● 認知負荷拡大により、いくつかの問題が顕在化 ○ 機能開発等の合間でインフラを構築・メンテしなければならず回らない ○ セキュリティ・運用等のベースラインがプロダクト横断で揃っていない ○ インフラの管理が抽象化された PaaSなどが選択肢になりがち →　PEチームの立ち上げの機運 

スコープを一部署に絞り、PoC的にPEを立ち上げ ● 2025年5月にチームが発足 ● 現在は自分+マネージャー+10月入社の方の3人体制 ● 初手全社の基盤を作るのではなく、一部署にスコープを絞りPoC的に立ち上げ ● スコープとなる“一部署”を選定する際の基準 → 中央主権的なプラットフォームを構築することでレバレッジが効くかどうか 例えば弊社の場合だと ... ○ 標準化ができそうなインフラ構成 ○ 利用されるユースケースが幅広い (個人・法人・自治体問わず活用する ) ○ 少数精鋭で開発、リリースを高速に回す必要があるなどのチーム特性 

前置きが長くなりましたが、 ここからは実際の取り組みを組織編と技術編に分けて紹 介していきます 

半年の取り組みの紹介(組織編) 

(個人的に思う)PEチーム立ち上げ時の辛みあるある プラットフォームってそも そもどんなことをして、 何を目指してつくれば良 いか、わからない 課題は色々あるけど、 何から始めて良いのか わからない 他のチームからの 「PEチームが何でも やってくれる」のような 期待値が 上がりすぎてしまう 

プラットフォームが目指すべき先がわからない問題 プラットフォームってそも そもどんなことをして、 何を目指してつくれば良 いか、わからない 

プラットフォームエンジニアリング成熟度モデル ● CNCFが公表しているPEの標準的な指標 ● 5つの特性とそれぞれ4つのレベルで分類 ● PEチームが直面するであろう課題や目指すべき目標が体系的に示されている 

我々が実施した成熟度モデルをやってみて ● 発足時(5月)に設定した一年後ありたい姿と11月現在地をマッピング ● PEとしてどこを目指すべきかが把握できる ● レベルが上がるごとに壁が分厚くなってくるが、あくまで現在地の指標として認識する ことが大切 ● 立ち上げ時は、長くても半年のタイミングで振り返るのが丁度良さそう 

周りとの期待値調整が難しい問題 他のチームからの 「PEチームが何でも やってくれる」のような 期待値が 上がりすぎてしまう 

ビジョンを作成して他チームにも公開しよう ● ビジョンがないとどうなるか ラディカル・プロダクト・シンキング という本によると... ○ "明確なビジョンと戦略がないままイテレーティブを繰り返せば、プロダクトは肥大化したり、断片化したり、方向性を失った り、誤った数字に引っ張られたりするようになる。" ○ 次々に舞い込むアイデアや要望を「イエス」と言って対応してしまい何から手をつけるべきかわからなくなってしまう状態に 陥る… ● ビジョン駆動なアプローチを実践することで、基準を持つ ○ どこを目指し、どう進むべきかを決める支えになる ○ 何ができて、何ができないかの境界が明確になる ○ 他チームへも適切な期待値を伝えられる 

ラディカル・ビジョン・ステートメントの作成 ● ラディカル・ビジョン・ステートメントというフレームワークを利用 ○ チームを誰・何・なぜ・いつ・どうやっての観点から同じ方向へ進ませるようにデザインされている ○ それぞれの項目を穴埋め的に進めることができる ○ Platform Engineering Meetup #7でのSanSan株式会社様の発表を参考にされるとよし 

我々が設定したビジョンv1(2025/5 時点) 現在【gx module アプリケーション開発者】 が【ユーザー価値に直結するロジックに注力し、継 続的に素早くギフト機能をユーザーに届けること】 を望むとき、 彼・彼女らは【各々の努力でアプリケーション外の非機能要件の実現に 1〜2ヶ月程度の工数を 割かなければ】 ならない。 この状況は【ギフト機能を素早く届けられないことで、贈り手、受け取り手が、本来ギフトから得 られるはずだった価値を十分に感じられなくなる】 ため、受け入れられない。 我々は【gx module アプリケーション開発者が、運用・セキュリティ・ CI/CD などのユーザー価 値に直結するロジック以外の部分を安心して任せることができ、ストレスなく多様なギフト機能 をユーザーに提供することができる】 世界を夢見ている。 我々は【gx module アプリケーション開発者のニーズを正確に捉えた機能を備え、当たり前の 品質が自然と実現できる共通基盤の継続的な提供と改善】 を通じて、そのような世界を実現する つもりである。 

我々が設定したビジョンv2(2025/11 時点) 現在【GX, GC アプリケーションチーム】 が【それぞれのミッションの達成】 を望むとき、彼・彼女ら は【各々の努力でミッションの達成に直接寄与しない領域に工数を割かなければ】 ならない。 この状況は【本来のコストよりも多くのコストを割き、ユーザーに価値を届けるのが遅くなり、クオ リティの低下を招く。また、開発者体験が低下する】 ため、受け入れられない。 我々は【GX, GC アプリケーションチームが、運用・セキュリティ・ CI/CDなどのプラットフォーム 利用や、信頼できるサポートを得ることができ、ミッションの達成に直接寄与する領域に集中す ることができる】 世界を夢見ている。 我々は【GX, GC アプリケーションチームのニーズを正確に捉えた機能を備え、当たり前の品質 が自然と実現できるプラットフォームの継続的な提供・改善・サポート】 を通じて、そのような世界 を実現するつもりである。 

ビジョンステートメントを運用してみて ● 最初は精度が低いが、徐々にビジョンの解像度が上がっていく ○ 最初はPE自体の経験がないと手探りなので困難 ○ 他の会社の例を参考にしたくなるが、我慢して自分たちの言葉で考えるのが大切 ○ 微妙なニュアンスを考えることでチームの方向性を揃えられる ○ 一旦はスコープを狭めて半年くらいのスパンで考えるとやりやすい ● 誰からも見やすいところに置いておくことで、考え方が根ざしてくる ○ 自分ごと化になってくる ○ 期待値調整・行動の指針になる 

何から始めるべきなのかわからない問題 課題は色々あるけど、 何から始めて良いのか わからない 

優先度フレームワーク ● ラディカルプロダクトシンキングで紹介されているフレームワーク ● タスクを抽象的な切り方で4象限にマッピングしていく ● 「サバイバル可能性が高い」は短期的なリスク軽減の取り組みのこと ● 理想以外のタスクばかりに偏って取り組むのは危険信号 

我々が設定した優先度(2025/5時点) 

我々が設定した優先度(2025/5時点) 技術編でここに フォーカスします 

優先度フレームワークをやってみて ● バージョンアップやEOL対応などの「サバイバル可能性が高い」タスクに手間取りがち なことが可視化される ○ 危険信号として捉えることができる ● 自分たちが主体で優先順位を定めることができる ○ 他チームに左右されずに判断できる ● 優先順位は変化することに気が付く ○ ビジョンやスコープ、タイミングなどで優先度も変わっていく 

半年の取り組みの紹介(技術編) 

組織編の優先度フレームワークで最優先となっていた 「CI/CDの機構を提供する」について紹介します 

CI/CDが整備されていないことで生じていた課題 ● (歴史的経緯で...)既存のEKSクラスタが複数存在しており運用負荷大 ○ 各クラスタで独自のCIOps的なデプロイフローが構築されていた ○ デプロイフローが複数存在していて、認知負荷になっていた ○ Helm Chartもterraformや手で管理 ● 責務分解が曖昧 ○ PEチームとアプリケーションチームがコラボレーションする上で責務分解しにくい 

Hub-Spoke型によるEKSマルチクラスタ管理 ● マネージドクラスタを作成し、既存のEKSクラスタを中央集権的に移行 ● k8sのGitOpsのツールであるArgoCDによりデプロイを一元管理 ● PEチームがクラスタの運用に対しての責務を持つ NEW 

GitHubリポジトリで責務を切る ● app用のk8s マニュフェストはアプリケーション側のリポジトリで管理 ● アプリケーション側の責務はアプリケーションのリポジトリのみに閉じ込める ● その他のk8sクラスタ・アドオンやAWSリソースはプラットフォーム側の管理 

アプリケーション開発者のmanifest作成をサポート アプリケーション開発者にk8sの理解を一定強いるが... ● pod数の設定などはアプリケーション側でしかわからない ● 「漏れのある抽象化」の問題が発生しやすい領域 ただし、下記の取り組みによって突き放さないようにサポート ● (要望があれば)初手のk8s manifestは一緒に書く ● サンプルの提供 ● k8s社内勉強会の開催 

これからやること 一旦の責務分解は整理したものの、課題はまだ山積み... ● 責務分解が問題ないか検証しつつ運用 ● クラスタの統合・効率化の検討 ● セキュリティ・ガバナンス周りの強化 ● コスト最適化 ● などなど... 

俺たちの戦いはこれからだ！！！！！ 

完 

参考 ● ラディカル・プロダクト・シンキング イノベーティブなソフトウェア・サービスを生 み出す5つのステップ
 ○ ラディカ・ダット (著), 曽根原 春樹 (監修, 翻訳), 長谷川 圭 (翻訳) 
 
 ● Platform as a productの取り組み - Sansan研究開発のPlatform Engineering / Platform as a product initiative - Platform Engineering at Sansan R&D ○ 技術本部 研究開発部 Architectグループ 神林 祐⼀ ○ https://speakerdeck.com/sansan_randd/platform-as-a-product-initiative-platform-engin eering-at-sansan-r-and-d 

最後に宣伝です！12/3にイベントやります！ イベントやります！遊びに来てください！ 

ご清聴ありがとうございました！！！