Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Platform Engineeringのエッセンスを小規模な開発組織に取り入れた事例紹介

ham
September 23, 2024

Platform Engineeringのエッセンスを小規模な開発組織に取り入れた事例紹介

Platform Engineering Meetup #10で登壇したスライド

https://platformengineering.connpass.com/event/329871/

ham

September 23, 2024
Tweet

More Decks by ham

Other Decks in Technology

Transcript

  1. © Findy Inc. 2024.09.24 Platform Engineering Meetup #10 1 Platform

    Engineeringのエッセンスを ⼩規模な開発組織に取り⼊れた事例紹介 浜⽥ 直⼈ Naoto Hamada (ham)
  2. © Findy Inc. 2 開発⽣産性が向上する⽅法を探求しているエンジニア! Ruby / Rails / React

    / TypeScript / AWS Agile / DevOps / Developer Productivity / DevEx Stock Investment 浜⽥ 直⼈ Naoto Hamada (ham) @hamchance0215
  3. © Findy Inc. 3 Findy Team+(チームプラス)とは? 開発⽣産性の可視化、開発プロセスの伸びしろの発⾒、継続的 な改善をサポート 3 ⽣産性可視化

    ⽣産性向上 事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー・配置・ツールの伸びしろを可視化‧最適化) ⽂化づくり‧⾃⼰組織化 (メンバーの⾃発的な改善促進、改善を称賛する⽂化作り) データ 連携 Engineer Engineer 開発組織ブランディング (エンジニアは、開発⽣産性が⾼い組織で働きたい) Recruit Biz
  4. © Findy Inc. 8
 前提 - 事例紹介でお話しするチーム規模(2023年ごろの話) ◦ 1チーム、エンジニア約10名 ◦

    全員プロダクトエンジニア ▪ 各々得意領域はあるが、プロダクト開発に必要なこ とをフレキシブルに対応するエンジニアで構成 ▪ SREやPlatform Engineering専属メンバーは不在
  5. © Findy Inc. 9
 チームトポトジー - 4つの基本的なチームタイプ ◦ ストリームアラインドチーム ◦

    イネイブリングチーム ◦ コンプリケイテッド‧サブシステムチーム ◦ プラットフォームチーム https://pub.jmam.co.jp/book/b593881.html

  6. © Findy Inc. 10
 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム

    価値のある単⼀の仕事の ストリームに沿って働く チーム ストリームアラインドチーム の負荷を減らす
  7. © Findy Inc. 11
 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム

    まだ1チームだし ストリームアラインドだけ 考えれば良いね! 他のチームは組織が⼤き くなったら考えよう!
  8. © Findy Inc. 12
 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム

    まだ1チームだし ストリームアラインドだけ 考えれば良いね! 他のチームは組織が⼤き くなったら考えよう!
  9. © Findy Inc. 13
 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム

    まだ1チームだし ストリームアラインドだけ 考えれば良いね! 他のチームは組織が⼤き くなったら考えよう! 専属チームを作らなくても そのチームが担う能力は必要
  10. © Findy Inc. 14
 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム

    - ストリームアラインドチームが全ての能⼒を(可能な限り)発 揮する必要がある ◦ 各チームのエッセンスを取り⼊れることが重要
  11. © Findy Inc. 15
 チームトポトジー - Platform Engineeringとは? ◦ 内部サービスを提供することで、ストリームアラインド

    チームが下位のサービスを開発する必要をなくし、認知 負荷を下げる ◦ プラットフォームチームを結成する
  12. © Findy Inc. 16
 チームトポトジー - ⼩さなチームのPlatform Engineeringとは? ◦ 必要に応じて内部サービスを提供することで、ストリー

    ムアラインドチームが下位のサービスを開発する必要を なくし、⾃分たちの認知負荷を下げる ◦ プラットフォームチームのエッセンスを取り⼊れる
  13. © Findy Inc. 19
 やりすぎない - ストリームアラインドチームはプロダクトの価値向上がメ インタスクなので、PFEに取り組める⼯数は限られる ◦ 価値向上とPFEに使っている⼯数のバランスを意識

    ▪ 価値向上により多くの時間が使えていること!! ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム
  14. © Findy Inc. 22
 やりすぎない - 型化による⼯数削減 < 型化する⼯数+メンテ⼯数 ◦

    再実⾏する⾒込みのないIaC ▪ 必要になってからリバースエンジニアリング ◦ ⼈が把握できる範囲の少⼈数の権限管理 ▪ Webコンソールなどから⼿動でやった⽅が早い ▪ スプシ管理で⼗分 ◦ 「属⼈化==悪」ではなく属⼈化を有効活⽤する ▪ 型化してもその仕組みのメンテが属⼈化することも...
  15. © Findy Inc. 24
 先⾏投資 - ⼯数がかからずできるものは積極的に活⽤ ◦ 仮想開発環境 ▪

    開発環境の構築が劇的に早まる ▪ 環境構築⼿順書が必要最低限でよい ▪ ドキュメントと違い陳腐化しづらい
  16. © Findy Inc. 25
 先⾏投資 - ⼯数がかからずできるものは積極的に活⽤ ◦ インフラのマネージドサービス ▪

    素早く初期構築 ▪ 運⽤コスト削減 ▪ パブリックなノウハウが多い ▪ インフラ障害時にサポートしてもらえる
  17. © Findy Inc. 26
 先⾏投資 - ⼯数がかからずできるものは積極的に活⽤ ◦ SaaS‧OSS ▪

    コード管理/イシュー管理/ドキュメント管理 ▪ CI‧CD/監視 ▪ メール/認証 ▪ ⼩規模チームだとコスパよく使える可能性が⾼い • 順調に成⻑した場合のコスト推移や(過度に気に する必要はないが)ベンダーロックインに注意 • 必要ないものは⼊れない‧使わなくなったら消す
  18. © Findy Inc. 28
 前提(再掲) - 事例紹介でお話しするチーム規模(2023年ごろの話) ◦ 1チーム、エンジニア約10名 ◦

    全員プロダクトエンジニア ▪ 各々得意領域はあるが、プロダクト開発に必要なこ とをフレキシブルに対応するエンジニアで構成 ▪ SREやPlatform Engineering専属メンバーは不在
  19. © Findy Inc. 29
 開発環境の仮想化 - Docker ◦ https://www.docker.com ◦

    docker composeを活⽤してローカル環境に本番に近い 構成を再現 ▪ web / worker / db / db(replica) / redis / storage
  20. © Findy Inc. 30
 開発環境の仮想化 - 開発環境の要件がコード管理できる ◦ 環境構築⼿順書が必要最低限でよい ◦

    ドキュメントと違い陳腐化しづらい - 開発者ごとの環境差異が発⽣しづらい - 本番環境との環境差異も発⽣しづらい - 開発環境の構築が劇的に早まる ◦ 新規参画者がサクッと環境構築できて即戦⼒
  21. © Findy Inc. 31
 Linter、スタイルガイド整備 - フロントエンド(TypeScript) ◦ eslint /

    stylelint / prettier - バックエンド(Ruby) ◦ rubocop - 上記でカバーしきれないルールは、スタイルガイドを GitHubのドキュメント(md)で管理
  22. © Findy Inc. 32
 Linter、スタイルガイド整備 - 少しでも再利⽤しそうなコードなら必ず⼊れるべき ◦ 途中で⼊れるとルール違反の修正が⼤変 ◦

    ルールを弱めると効果半減 - できる限り厳しいルールを適⽤する⽅が良い ◦ 迷ったらデフォルト設定に準拠すると良い ◦ 新しいルールも積極的に採⽤ - 機械的にチェックできないルールはドキュメント化 ◦ 機械的にチェックされないルールは形骸化しやすいので 最低限のルールに留める
  23. © Findy Inc. 33
 ⾃動テスト導⼊ - フロントエンド(TypeScript) ◦ jest /

    react-testing-library / reg-suit - バックエンド(Ruby) ◦ rspec
  24. © Findy Inc. 35
 CI⾃動実⾏ - GitHub Actions / Nx

    (https://nx.dev/) - PRにPushするたびにLinter / Test / Buildなどを実⾏ ◦ Pushごとに実⾏するので実⾏時間は10分以内が⽬安 - CI⾼速化について 👉 https://speakerdeck.com/ham0215/ciha5fen-yi-nei-su-zao-ikai-fa-saikuruwozhi-eruci
  25. © Findy Inc. 37
 pre-commitでLinterやコード整形 - husky / lint-staged ◦

    https://typicode.github.io/husky/ ◦ https://www.npmjs.com/package/lint-staged - commitのときにLinterやコード整形を実⾏する ◦ 実⾏時間は注視 ▪ commitごとに実⾏されるので数秒で終わらないと開 発者体験が⼤幅に低下する - CIより早く気づけるのでフィードバックループがより早くな る
  26. © Findy Inc. 40
 プルリクエストテンプレート - GitHub`.github/PULL_REQUEST_TEMPLATE.md`を配置 - descriptionを揃えることでレビュー負荷軽減 -

    関連イシューとのリンクやセルフチェック、動作検証など PRごとに実施して欲しいことの漏れを防ぐ
  27. © Findy Inc. 41
 プルリクエストテンプレート - リリース時のQA有無や本番作業をPRごとに記載して、リ リース時のタスク⼀覧の⽣成に使う ◦ GitHub

    Actionsを活⽤ PRs Release PR QAや本番作業を抽出 リリース時に リリースPRを⾒る だけでやることが 把握できる
  28. © Findy Inc. 42
 プルリクエストのアサイン⾃動化 - Auto Assign Action (GitHub

    Actions) ◦ https://github.com/marketplace/actions/auto-assign-action - プルリクエスト作成時に作成者をアサインする - 案外、アサインを設定しない⼈は多い - プルリクエスト⼀覧でフィルターできたり、パッと⾒ただ けで誰が担当したPRなのかすぐにわかるので良い
  29. © Findy Inc. 43
 Branch protection rulesを設定 - ブランチに対するルールを設定 ◦

    “ブランチ保護ルールを管理する” ▪ https://docs.github.com/ja/repositories/configuring-branches-and- merges-in-your-repository/managing-protected-branches/managin g-a-branch-protection-rule
  30. © Findy Inc. 44
 Branch protection rulesを設定 - おすすめ設定(GitHub) -

    Require a pull request before merging ◦ プルリクエストをマージする前の要件を設定 ◦ Require approvals ▪ レビュアーによる承認が必要 ◦ Dismiss stale pull request approvals when new commits are pushed ▪ 承認後にプッシュしたら承認取り消し
  31. © Findy Inc. 45
 Branch protection rulesを設定 - おすすめ設定(GitHub) -

    Require status checks to pass before merging ◦ 指定したCIが成功しないとマージできない ◦ Linterや⾃動テストなど成功必須なものを追加
  32. © Findy Inc. 46
 ランダムレビュアー - GitHub Teams > Settings

    > Code review - チームをレビュアーに設定した際、チーム内のメンバーを ランダムアサイン
  33. © Findy Inc. 48
 dependabot - ライブラリなどのバージョンアップ⾃動化 ◦ ライブラリだけではなく、コンテナやGitHub Actionsの

    actionのバージョンなどバージョン管理するものは多い ので⼿動運⽤は厳しい - CIが充実している場合、パッチバージョンなどであればCIが 通っているだけで安⼼してマージできる ◦ オートマージは便利だが、壊れることも多い... ▪ 頻繁に触るコードはすぐ気づけるから良いが、滅多 に触らないコードは気づくのが遅れるので怖い
  34. © Findy Inc. 49
 PRラベル付与 - プルリクエスト作成時にGitHub Actionsで付与 - プルリクエストの内容から適切なラベルを付与

    ◦ モノレポの修正対象アプリごとに付与 ◦ 修正の種類(feat / fix / refactor / chore...)ごと に付与 - PRの内容がラベルから明確になる - フィルタリングに使えるので、PRを分析したいと きに活⽤できる
  35. © Findy Inc. 50
 ER図⾃動⽣成 - schemaspy ◦ https://schemaspy.org/ -

    GitHub ActionsでDBスキーマからER図を⾃動⽣成 ◦ GitHub Pagesに公開
  36. © Findy Inc. 51
 技術スタックの統⼀ - 複数チームある場合、チーム間の技術スタックを揃える - 開発メンバーが少ないうちは退職者1名ですぐにチームが機 能しなくなる

    ◦ 技術スタックを統⼀するメリット ▪ チーム間のメンバー移動をしやすくする ▪ ノウハウの横展開もできる - 開発組織が拡⼤してきたらチームごとに意思決定するのも あり
  37. © Findy Inc. 52
 ドキュメントを⼀元管理 - GitHub ◦ PRベースで修正できて良い -

    Notion / Confluenceなどもよい - 利⽤者に合わせて適切に選択するのが良い
  38. © Findy Inc. 53
 ドキュメントを⼀元管理 - 1つにまとまっているのが良い ◦ 様々なサービスを探しに⾏くのはつらい... -

    ドキュメント化のハードルを下げる ◦ 調査メモなど個⼈レベルのドキュメントも気軽に残せる とノウハウが溜まりやすくて良い ◦ 重複なども気にしない ▪ フィルタリングでカバーする ▪ ルールを厳しくするとドキュメント化しなくなる
  39. © Findy Inc. 54
 イシューテンプレート - GitHub`.github/ISSUE_TEMPLATE`を配置 - イシュー内容を揃えることで読者の認知負荷を軽減 -

    イシューごとの内容のバラツキが軽減できる - イシュー内容をチェックするためにチェックリストを運⽤ するより、テンプレートに項⽬として⼊れておく⽅がチェッ ク漏れが少ない
  40. © Findy Inc. 55
 パブリッククラウドのマネージドサービス - AWS ◦ https://aws.amazon.com -

    パブリッククラウドの中でもマネージドサービスを積極的 に活⽤しよう ◦ ECS / Aurora / s3 / CloudFront / Step Functions
  41. © Findy Inc. 57
 デプロイ⾃動化 - GitHub Actionsを活⽤ - 定時にリリースPRを作成

    ◦ バックエンド、フロントエンドごとに2回/⽇ ◦ リリースPRに記載されているQAや本番作業を確認 ◦ マージしたらデプロイ開始 ◦ デプロイは全⾃動 ◦ デプロイ完了時にSlack通知 ◦ リリースタグを⾃動⽣成
  42. © Findy Inc. 59
 本番切り戻し⼿順確⽴ - デプロイを伴う本番障害を素早く切り戻せるようにしてお くことで、安⼼してデプロイできるようになる - ECSで1つ前のコンテナイメージを残しておき、すぐに戻せ

    るようにしている ◦ 1分ほどで切り戻し可能 - DBのスキーマ変更を伴うと素早い切り戻しが難しい ◦ 良いやり⽅があったら教えてください!
  43. © Findy Inc. 60
 監視 SaaS - Datadog ◦ https://www.datadoghq.com

    ◦ バックエンドのログ監視 ◦ インフラ監視 ▪ 閾値を超えたらSlack通知 - Sentry ◦ https://sentry.io ◦ フロント‧バックエンドのSlack通知
  44. © Findy Inc. 61
 監視 SaaS - Slack連携は⼿間でも作り込んだ⽅が良い ◦ 頻繁に⾒るところに通知が来ないと⾒落とす

    - モニターの作り込みやや⾮機能要件の監視などは余裕がで きたら ◦ ⾒ないモニターは作っても意味がない - 最初はパブリッククラウドの標準機能でも良いかも ◦ リリース当初はあまり使わないわりに料⾦がかかる...
  45. © Findy Inc. 62
 E2E SaaS - Autify ◦ https://autify.jp/

    - SaaSを利⽤することで気軽に始めることができる - ⾃前で作り込むのとどちらがメンテナンスコストが低いか 検討 - 開発規模が増えることで料⾦がネックになることも... ◦ その時が来たら移⾏を視野に⼊れて検討すれば良い
  46. © Findy Inc. 63
 CMS(コンテンツ マネジメント システム) - Contentful /

    WordPress ◦ https://www.contentful.com/ ◦ https://wordpress.com/ja/ - コンテンツ管理はCMSに頼るべき ◦ コンテンツ管理者がエンジニアの⼿を借りずに更新でき るのが良き - 運⽤がツラくなることがよくあるので、運⽤コストを加味 して検討する
  47. © Findy Inc. 64
 SaaS‧OSS - メールや認証‧認可などよく使われる機能は積極的に活⽤ しよう ◦ ⾞輪の再開発を防ぐ

    ◦ セキュリティ⾯でも有利 - スターの数や活動状況を確認 ◦ ⼤きな組織で使われているライブラリは強い