プラットフォーム開発の実例と撤退から学ぶ / Learning from examples of platform development and withdrawal

2024/07/04：

Platform Engineering Meetup #9
https://platformengineering.connpass.com/event/322020/

プラットフォーム開発の実例と撤退から学ぶ

清水 那音也
ソフトウェアエンジニア

Transcript

1. プラットフォーム開発の実例と撤退から学ぶ @naoya7076 (Shimmy) Platform Engineering Meetup #9
2. 自己紹介 株式会社カミナシ ソフトウェアエンジニア Shimmy (@naoya7076) 略歴 複数の企業で開発やSET業務を経験した後、 兼業農家としての挑戦を経て 現在は株式会社カミナシでソフトウェアエンジニア をしています
3. 注意書き カミナシでの話ではない SETエンジニアをしていた時の話 転職前に登壇の話を頂いた 前職からは「明示的に名前を出さなければ登壇OK」
4. 1. 社内プラットフォームの開発と撤退 2. プラットフォーム開発時のアンチパターン 3. 新規サービスを作る時のように考える 4. 学びを活かす アジェンダ
5. 社内プラットフォームの開発と撤退
6. プラットフォーム開発の背景 歴史が長い大規模サービス 品質面の課題 • Staging環境になってからデグレードが見つかる ◦ Revert→ 再デプロイに時間がかかる ◦ Staging環境より手前で不具合を見つけたい • 機能の増加に対してE2Eテストがあまり増えていない
7. Staging環境になってからデグレードが見つかる → もっと手前で見つけたい → Pull Requestが出たらCIでE2Eを実行したい 機能の増加に対してE2Eテストがあまり増えていない → 開発者がE2Eテストを書くことがかなり少ない → 開発者にとってもっとE2Eテストを身近で実行しやすくしたい 課題の解決方法 → Pull Requestをベースに、独立した環境を立ち上げて、 そこに向けてE2Eテストを実行させよう！！
8. チーム構成 • 2チーム ◦ SET(Software Engineer in Test) ← 私がいたチーム ◦ SRE(DX)チーム • 特定の人が兼業するのではなくメンバーの中から関連チケットを取った人 が対応する ◦ 知識の偏りを防ぐため & 業務委託の人が多かったので離脱時のリス ク軽減 メンバーと進め方
9. プラットフォームの概要 • 準備 ◦ 開発者がPull Requestを作成すると自動的にEKS上に一時的な開発環 境を構築する ◦ この環境には前述したサービスとその関連サービスが含まれる • 実行 ◦ 一時的な開発環境に向けてE2Eテストを実行する • 結果 ◦ E2Eテストの結果をPull Requestにコメントする
10. 何が起きたか • チーム毎での優先度の違いやミスコミュニケーションの発生 • MVPまで1年かかった • 主要メンバーの退職 • ユーザー（エンジニア）からあまり使われなかった → プラットフォームの開発終了
11. 振り返り • チームにナレッジが貯まるのに時間がかかった ◦ EKS上での自動テストがFailした時のデバッグ方法 ◦ Kompose[1]の変換処理など • オーナーシップが明確でなかった • リリース後にあまり使われなかった • 既存システムとの棲み分け [1] : https://kompose.io/
12. プラットフォーム開発時の アンチパターン
13. やりがちな事 • 新しい技術全部盛り ◦ K8s, Otel, Service Mesh • やってみたい人を兼業でアサイン • とりあえず作ってみる
14. その時は良いと思っていた 新しい技術全部盛り → リスク少なく社内サービスで技術検証できる やってみたい人を兼業でアサイン → 兼業なら話を通しやすい、知識をチームで広められる とりあえず作ってから調整 → コード書くの楽しい！mainブランチに直プッシュだ！！
15. その時は良いと思っていた 新しい技術全部盛り → リスク少なく社内サービスで技術検証できる やってみたい人を兼業でアサイン → 兼業なら話を通しやすい、知識をチームで広められる とりあえず作ってから調整 → コード書くの楽しい！mainブランチに直プッシュだ！！
16. なぜアンチパターンに嵌るのか • 誰も失敗しようと思っていない • アンチパターンと知らずに進めても最初はうまくいく • でもその先に大きな沼があるからこそ、アンチパターン → 対抗する術を知っておく必要がある
17. 先人に学ぶ 役に立つプラットフォームを作ろう - プラットフォームエンジニアが知っておくべき『プロダクト』の考え方 . Kazuto Kusama. (参照2024年7月2日) 独りよがりのプラットフォーム / For Whom that Platform Runs. Tori Hara. (参照2024年7月2日)
18. 新規サービスを作る時のように考える
19. 新規サービスを作る時 • オーナーシップ ◦ メンバーを専任でアサインする • ユーザーヒアリング ◦ Burning Needs(後述)なのか • 小さくMVP(後述)を作る
20. Burning Needsとは “頭に火が付いていて、今すぐ消さないとマズイ、というような課題のこと” ユーザーの「あったら嬉しい」は、「無くても良い」ということ 無くて良いなら作らない。という決断も大事 顧客のBurning needsを解決する. 近澤 良. (参照 2024年7月2日)
21. Burning Needsとは(2) ユーザーにヒアリングをしても... • ユーザーが自分が本当に欲しいものを分かっていないケース • ユーザーと質問者での間で前提が違うケース 質問者: 〇〇なサービス欲し い？ ユーザー： （運用が安定していて、実行 時間が短くて、うまく動かな い時のデバッグも簡単で、認 知不可が低くて、導入コスト がさほど掛からないのなら） 欲しい！
22. Burning Needsとは(3) ユーザーに話を聞いたうえで • それは何が何でも解決したい課題なのか • その解決策で問題ないのか • 開発工数を投入してプラットフォームを作る必要があるのか ヒアリングを鵜呑みにせず 自分たちで考えないといけない
23. MVPとは MVP: 仮説を検証できる必要最小限の製品”ぽい”もの • プロダクト開発における最初の仮説は99%間違っている。 • プラットフォームを作る時の仮説も間違っている可能性が高い • 仮説を検証できれば”プロダクト”でなくても良い ◦ 手作業型MVP ▪ dinii社の例 “最もコアとなる注文までの導線のみアプリ実 装して、お金の支払いはメンバーが店舗にデポ ジット(要は身銭を切って建て替え)、注文受注 は、Slack に通知を飛ばしてメンバーが店舗に 人力電話をして予約することで、ランチの事前 予約システムを実現させていました。” dinii社のnoteより引用 MVP の作り方 🔨 とにかく雑に作る「手作業型 MVP」のススメ. Takaaki Umada / 馬田隆明. (参照 2024年7月2日) 1年間開発したプロダクトを捨てて、 5日でダイニーをリリースした話 . dinii（ダイニー）公式. (参照2024年7月2日)
24. プラットフォームを開発する時 • そもそも必要かどうかの検証、ヒアリングに時間をかける ◦ 検証の時間はその後の開発工数に比べると微々たるもの • あったらいい。ではなく絶対に欲しい。と言われるもの • 必要最低限のMVPを作る • ”プラットフォームを作る”必要はあるのか ◦ ユーザの課題を解決できるなら何でも良い ▪ 既存のSaaS ▪ 知識のEnabling
25. 学びを活かす
26. できること / できないことを明確に どうにもできなかったこと • 完全な専業で行うこと ◦ リソースやチーム状況から困難 • 転職を防ぐこと • E2Eの不安定さを一定以上取り除くこと ◦ ネットワーク通信の不安定さの解消
27. できること / できないことを明確に(2) あの時やれたこと メンバー • 専任は無理でもできるだけアサインを偏らせる プロダクト • ユーザーヒアリングして課題を捉える • 作らないという選択肢もありえた • 慣れた技術で素早くMVPを作る • “プラットフォームを作る”以外の解決策も考える
28. 課題を捉え直してやったこと E2Eテストを書いてく れる人が少ない 開発者にもっと書い てもらおう QA担当者の E2Eテストを書きたい ニーズの高まり E2Eテストの Enabling E2Eテスト 基盤を作る
29. 課題を捉え直す 不具合がStagingで見 つかる E2Eテストの カバレッジを上げる 不具合を早く見つけ たい APIテスト E2Eテスト 基盤を作る
30. 新たに注力したこと APIテスト • APIテストを新たに追加した ◦ 大規模サービスへの導入から始めない ◦ APIテストを1番必要としている新規サービスから小さく始める E2EテストのEnabling • 資料やカリキュラムの充実 • Weeklyで質問会 • QAチーム内にE2Eテストの伝道師(Guru)を作る
31. なにが変わったのか • 作る前に考える ◦ 本当に必要なのか • 課題の捉え方 ◦ ユーザーのBurning Needsは何なのか • 解決策の幅 ◦ 技術だけで解決しようとしない
32. あなたが本当に欲しいのは Kubernatesのサービス基盤ですか？ • ECSなどで充分かも • まずは開発イメージのDockerコンテナ化 E2Eの自動テスト基盤ですか？ • APIテストで充分かも • まずはUnitテストを増やす • 自動テストを人に教える いらすとや
33. ありがとうございました