プラットフォーム開発の実例と撤退から学ぶ @naoya7076 (Shimmy) Platform Engineering Meetup #9

自己紹介 株式会社カミナシ ソフトウェアエンジニア Shimmy (@naoya7076) 略歴 複数の企業で開発やSET業務を経験した後、 兼業農家としての挑戦を経て 現在は株式会社カミナシでソフトウェアエンジニア をしています

注意書き カミナシでの話ではない SETエンジニアをしていた時の話 転職前に登壇の話を頂いた 前職からは「明示的に名前を出さなければ登壇OK」

1. 社内プラットフォームの開発と撤退 2. プラットフォーム開発時のアンチパターン 3. 新規サービスを作る時のように考える 4. 学びを活かす アジェンダ

社内プラットフォームの開発と撤退

プラットフォーム開発の背景 歴史が長い大規模サービス 品質面の課題 ● Staging環境になってからデグレードが見つかる ○ Revert→ 再デプロイに時間がかかる ○ Staging環境より手前で不具合を見つけたい ● 機能の増加に対してE2Eテストがあまり増えていない

Staging環境になってからデグレードが見つかる → もっと手前で見つけたい → Pull Requestが出たらCIでE2Eを実行したい 機能の増加に対してE2Eテストがあまり増えていない → 開発者がE2Eテストを書くことがかなり少ない → 開発者にとってもっとE2Eテストを身近で実行しやすくしたい 課題の解決方法 → Pull Requestをベースに、独立した環境を立ち上げて、 そこに向けてE2Eテストを実行させよう！！

チーム構成 ● 2チーム ○ SET(Software Engineer in Test) ← 私がいたチーム ○ SRE(DX)チーム ● 特定の人が兼業するのではなくメンバーの中から関連チケットを取った人 が対応する ○ 知識の偏りを防ぐため & 業務委託の人が多かったので離脱時のリス ク軽減 メンバーと進め方

プラットフォームの概要 ● 準備 ○ 開発者がPull Requestを作成すると自動的にEKS上に一時的な開発環 境を構築する ○ この環境には前述したサービスとその関連サービスが含まれる ● 実行 ○ 一時的な開発環境に向けてE2Eテストを実行する ● 結果 ○ E2Eテストの結果をPull Requestにコメントする

何が起きたか ● チーム毎での優先度の違いやミスコミュニケーションの発生 ● MVPまで1年かかった ● 主要メンバーの退職 ● ユーザー（エンジニア）からあまり使われなかった → プラットフォームの開発終了

振り返り ● チームにナレッジが貯まるのに時間がかかった ○ EKS上での自動テストがFailした時のデバッグ方法 ○ Kompose[1]の変換処理など ● オーナーシップが明確でなかった ● リリース後にあまり使われなかった ● 既存システムとの棲み分け [1] : https://kompose.io/

プラットフォーム開発時の アンチパターン

やりがちな事 ● 新しい技術全部盛り ○ K8s, Otel, Service Mesh ● やってみたい人を兼業でアサイン ● とりあえず作ってみる

その時は良いと思っていた 新しい技術全部盛り → リスク少なく社内サービスで技術検証できる やってみたい人を兼業でアサイン → 兼業なら話を通しやすい、知識をチームで広められる とりあえず作ってから調整 → コード書くの楽しい！mainブランチに直プッシュだ！！

その時は良いと思っていた 新しい技術全部盛り → リスク少なく社内サービスで技術検証できる やってみたい人を兼業でアサイン → 兼業なら話を通しやすい、知識をチームで広められる とりあえず作ってから調整 → コード書くの楽しい！mainブランチに直プッシュだ！！

なぜアンチパターンに嵌るのか ● 誰も失敗しようと思っていない ● アンチパターンと知らずに進めても最初はうまくいく ● でもその先に大きな沼があるからこそ、アンチパターン → 対抗する術を知っておく必要がある

先人に学ぶ 役に立つプラットフォームを作ろう - プラットフォームエンジニアが知っておくべき『プロダクト』の考え方 . Kazuto Kusama. (参照2024年7月2日) 独りよがりのプラットフォーム / For Whom that Platform Runs. Tori Hara. (参照2024年7月2日)

新規サービスを作る時のように考える

新規サービスを作る時 ● オーナーシップ ○ メンバーを専任でアサインする ● ユーザーヒアリング ○ Burning Needs(後述)なのか ● 小さくMVP(後述)を作る

Burning Needsとは “頭に火が付いていて、今すぐ消さないとマズイ、というような課題のこと” ユーザーの「あったら嬉しい」は、「無くても良い」ということ 無くて良いなら作らない。という決断も大事 顧客のBurning needsを解決する. 近澤 良. (参照 2024年7月2日)

Burning Needsとは(2) ユーザーにヒアリングをしても... ● ユーザーが自分が本当に欲しいものを分かっていないケース ● ユーザーと質問者での間で前提が違うケース 質問者: 〇〇なサービス欲し い？ ユーザー： （運用が安定していて、実行 時間が短くて、うまく動かな い時のデバッグも簡単で、認 知不可が低くて、導入コスト がさほど掛からないのなら） 欲しい！

Burning Needsとは(3) ユーザーに話を聞いたうえで ● それは何が何でも解決したい課題なのか ● その解決策で問題ないのか ● 開発工数を投入してプラットフォームを作る必要があるのか ヒアリングを鵜呑みにせず 自分たちで考えないといけない

MVPとは MVP: 仮説を検証できる必要最小限の製品”ぽい”もの ● プロダクト開発における最初の仮説は99%間違っている。 ● プラットフォームを作る時の仮説も間違っている可能性が高い ● 仮説を検証できれば”プロダクト”でなくても良い ○ 手作業型MVP ■ dinii社の例 “最もコアとなる注文までの導線のみアプリ実 装して、お金の支払いはメンバーが店舗にデポ ジット(要は身銭を切って建て替え)、注文受注 は、Slack に通知を飛ばしてメンバーが店舗に 人力電話をして予約することで、ランチの事前 予約システムを実現させていました。” dinii社のnoteより引用 MVP の作り方 🔨 とにかく雑に作る「手作業型 MVP」のススメ. Takaaki Umada / 馬田隆明. (参照 2024年7月2日) 1年間開発したプロダクトを捨てて、 5日でダイニーをリリースした話 . dinii（ダイニー）公式. (参照2024年7月2日)

プラットフォームを開発する時 ● そもそも必要かどうかの検証、ヒアリングに時間をかける ○ 検証の時間はその後の開発工数に比べると微々たるもの ● あったらいい。ではなく絶対に欲しい。と言われるもの ● 必要最低限のMVPを作る ● ”プラットフォームを作る”必要はあるのか ○ ユーザの課題を解決できるなら何でも良い ■ 既存のSaaS ■ 知識のEnabling

学びを活かす

できること / できないことを明確に どうにもできなかったこと ● 完全な専業で行うこと ○ リソースやチーム状況から困難 ● 転職を防ぐこと ● E2Eの不安定さを一定以上取り除くこと ○ ネットワーク通信の不安定さの解消

できること / できないことを明確に(2) あの時やれたこと メンバー ● 専任は無理でもできるだけアサインを偏らせる プロダクト ● ユーザーヒアリングして課題を捉える ● 作らないという選択肢もありえた ● 慣れた技術で素早くMVPを作る ● “プラットフォームを作る”以外の解決策も考える

課題を捉え直してやったこと E2Eテストを書いてく れる人が少ない 開発者にもっと書い てもらおう QA担当者の E2Eテストを書きたい ニーズの高まり E2Eテストの Enabling E2Eテスト 基盤を作る

課題を捉え直す 不具合がStagingで見 つかる E2Eテストの カバレッジを上げる 不具合を早く見つけ たい APIテスト E2Eテスト 基盤を作る

新たに注力したこと APIテスト ● APIテストを新たに追加した ○ 大規模サービスへの導入から始めない ○ APIテストを1番必要としている新規サービスから小さく始める E2EテストのEnabling ● 資料やカリキュラムの充実 ● Weeklyで質問会 ● QAチーム内にE2Eテストの伝道師(Guru)を作る

なにが変わったのか ● 作る前に考える ○ 本当に必要なのか ● 課題の捉え方 ○ ユーザーのBurning Needsは何なのか ● 解決策の幅 ○ 技術だけで解決しようとしない

あなたが本当に欲しいのは Kubernatesのサービス基盤ですか？ ● ECSなどで充分かも ● まずは開発イメージのDockerコンテナ化 E2Eの自動テスト基盤ですか？ ● APIテストで充分かも ● まずはUnitテストを増やす ● 自動テストを人に教える いらすとや

ありがとうございました