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

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

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

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. 4 Agenda - ⼩さなチームのPlatform Engineering - やりすぎない。ただし先⾏投資も必要 - 事例紹介
5. © Findy Inc. ⼩さなチームの Platform Engineering 5
6. © Findy Inc. 6
 前提 - テーマ ◦ ⼩規模でも始められる！Platform Engineeringの実践例
7. © Findy Inc. 7
 前提 - テーマ ◦ ⼩規模でも始められる！Platform Engineeringの実践例 ⼩規模ってどれくらい？
8. © Findy Inc. 8
 前提 - 事例紹介でお話しするチーム規模(2023年ごろの話) ◦ 1チーム、エンジニア約10名 ◦ 全員プロダクトエンジニア ▪ 各々得意領域はあるが、プロダクト開発に必要なこ とをフレキシブルに対応するエンジニアで構成 ▪ SREやPlatform Engineering専属メンバーは不在
9. © Findy Inc. 9
 チームトポトジー - 4つの基本的なチームタイプ ◦ ストリームアラインドチーム ◦ イネイブリングチーム ◦ コンプリケイテッド‧サブシステムチーム ◦ プラットフォームチーム https://pub.jmam.co.jp/book/b593881.html

10. © Findy Inc. 10
 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム 価値のある単⼀の仕事の ストリームに沿って働く チーム ストリームアラインドチーム の負荷を減らす
11. © Findy Inc. 11
 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム まだ1チームだし ストリームアラインドだけ 考えれば良いね！ 他のチームは組織が⼤き くなったら考えよう！
12. © Findy Inc. 12
 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム まだ1チームだし ストリームアラインドだけ 考えれば良いね！ 他のチームは組織が⼤き くなったら考えよう！
13. © Findy Inc. 13
 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム まだ1チームだし ストリームアラインドだけ 考えれば良いね！ 他のチームは組織が⼤き くなったら考えよう！ 専属チームを作らなくても そのチームが担う能力は必要
14. © Findy Inc. 14
 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム - ストリームアラインドチームが全ての能⼒を(可能な限り)発 揮する必要がある ◦ 各チームのエッセンスを取り⼊れることが重要
15. © Findy Inc. 15
 チームトポトジー - Platform Engineeringとは？ ◦ 内部サービスを提供することで、ストリームアラインド チームが下位のサービスを開発する必要をなくし、認知 負荷を下げる ◦ プラットフォームチームを結成する
16. © Findy Inc. 16
 チームトポトジー - ⼩さなチームのPlatform Engineeringとは？ ◦ 必要に応じて内部サービスを提供することで、ストリー ムアラインドチームが下位のサービスを開発する必要を なくし、⾃分たちの認知負荷を下げる ◦ プラットフォームチームのエッセンスを取り⼊れる
17. © Findy Inc. やりすぎない ただし先⾏投資も必要 17
18. © Findy Inc. 18
 Platform Engineeringの事例を取り⼊れる よーし！ Platform Engineeringに 取り組むぞ！ 各社の事例を参考にしよう！
19. © Findy Inc. 19
 やりすぎない - ストリームアラインドチームはプロダクトの価値向上がメ インタスクなので、PFEに取り組める⼯数は限られる ◦ 価値向上とPFEに使っている⼯数のバランスを意識 ▪ 価値向上により多くの時間が使えていること！！ ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム
20. © Findy Inc. 20
 やりすぎない - アラン‧ケリー「ソフトウェア開発者はプラットフォーム を作るのを好む。プロダクトマネジメントからの確かな情 報もなしに、必要以上に⼤きなプラットフォームを開発し てしまう」 良いプラットフォームは「ちょうど良い⼤きさ」
 https://pub.jmam.co.jp/book/b593881.html

21. © Findy Inc. 21
 やりすぎない - ⼤きな組織の事例で紹介されたものは⼩さな組織には重す ぎるものも多い ◦ 全環境がIaCで管理しており、必要なときに必要な環境 をサクッと構築できる！ ◦ 権限の付与‧剥奪をWFで⾃動化！
22. © Findy Inc. 22
 やりすぎない - 型化による⼯数削減 ＜ 型化する⼯数+メンテ⼯数 ◦ 再実⾏する⾒込みのないIaC ▪ 必要になってからリバースエンジニアリング ◦ ⼈が把握できる範囲の少⼈数の権限管理 ▪ Webコンソールなどから⼿動でやった⽅が早い ▪ スプシ管理で⼗分 ◦ 「属⼈化==悪」ではなく属⼈化を有効活⽤する ▪ 型化してもその仕組みのメンテが属⼈化することも...
23. © Findy Inc. 23
 先⾏投資 - プロダクト開発をする上で繰り返し負担になっているもの は積極的に改善していくべき ◦ ⽇々実施するタスクの改善はすぐに元が取れる可能性が ⾼い ▪ 型化による⼯数削減 ＞ 型化する⼯数+メンテ⼯数
24. © Findy Inc. 24
 先⾏投資 - ⼯数がかからずできるものは積極的に活⽤ ◦ 仮想開発環境 ▪ 開発環境の構築が劇的に早まる ▪ 環境構築⼿順書が必要最低限でよい ▪ ドキュメントと違い陳腐化しづらい
25. © Findy Inc. 25
 先⾏投資 - ⼯数がかからずできるものは積極的に活⽤ ◦ インフラのマネージドサービス ▪ 素早く初期構築 ▪ 運⽤コスト削減 ▪ パブリックなノウハウが多い ▪ インフラ障害時にサポートしてもらえる
26. © Findy Inc. 26
 先⾏投資 - ⼯数がかからずできるものは積極的に活⽤ ◦ SaaS‧OSS ▪ コード管理/イシュー管理/ドキュメント管理 ▪ CI‧CD/監視 ▪ メール/認証 ▪ ⼩規模チームだとコスパよく使える可能性が⾼い • 順調に成⻑した場合のコスト推移や(過度に気に する必要はないが)ベンダーロックインに注意 • 必要ないものは⼊れない‧使わなくなったら消す
27. © Findy Inc. 事例紹介 27
28. © Findy Inc. 28
 前提(再掲) - 事例紹介でお話しするチーム規模(2023年ごろの話) ◦ 1チーム、エンジニア約10名 ◦ 全員プロダクトエンジニア ▪ 各々得意領域はあるが、プロダクト開発に必要なこ とをフレキシブルに対応するエンジニアで構成 ▪ SREやPlatform Engineering専属メンバーは不在
29. © Findy Inc. 29
 開発環境の仮想化 - Docker ◦ https://www.docker.com ◦ docker composeを活⽤してローカル環境に本番に近い 構成を再現 ▪ web / worker / db / db(replica) / redis / storage
30. © Findy Inc. 30
 開発環境の仮想化 - 開発環境の要件がコード管理できる ◦ 環境構築⼿順書が必要最低限でよい ◦ ドキュメントと違い陳腐化しづらい - 開発者ごとの環境差異が発⽣しづらい - 本番環境との環境差異も発⽣しづらい - 開発環境の構築が劇的に早まる ◦ 新規参画者がサクッと環境構築できて即戦⼒
31. © Findy Inc. 31
 Linter、スタイルガイド整備 - フロントエンド(TypeScript) ◦ eslint / stylelint / prettier - バックエンド(Ruby) ◦ rubocop - 上記でカバーしきれないルールは、スタイルガイドを GitHubのドキュメント(md)で管理
32. © Findy Inc. 32
 Linter、スタイルガイド整備 - 少しでも再利⽤しそうなコードなら必ず⼊れるべき ◦ 途中で⼊れるとルール違反の修正が⼤変 ◦ ルールを弱めると効果半減 - できる限り厳しいルールを適⽤する⽅が良い ◦ 迷ったらデフォルト設定に準拠すると良い ◦ 新しいルールも積極的に採⽤ - 機械的にチェックできないルールはドキュメント化 ◦ 機械的にチェックされないルールは形骸化しやすいので 最低限のルールに留める
33. © Findy Inc. 33
 ⾃動テスト導⼊ - フロントエンド(TypeScript) ◦ jest / react-testing-library / reg-suit - バックエンド(Ruby) ◦ rspec
34. © Findy Inc. 34
 ⾃動テスト導⼊ - 少しでも再利⽤しそうなコードなら必ず⼊れるべき ◦ 4回以上変更するなら導⼊価値がある 質とスピード (@t_wada) https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition
35. © 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
36. © Findy Inc. 36
 CI⾃動実⾏ - ⾼速なフィードバックループは開発者体験にも良い https://speakerdeck.com/ham0215/kai-fa-zhe-noding-liang-ding-xing-detawozu-mihe-wasetekai-fa-zhe-ti-yan-woba-wo-surutamenoqu-rizu-mi?slide=26
37. © 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より早く気づけるのでフィードバックループがより早くな る
38. © Findy Inc. 38
 commitメッセージにprefixをつける - git-cz ◦ https://github.com/streamich/git-cz
39. © Findy Inc. 39
 commitメッセージにprefixをつける - 修正内容によってcommitメッセージにprefixをつける ◦ commit内容がメッセージから明確になる ◦ prefixは1つなので1つのcommitで1つのことをやるよう になる
40. © Findy Inc. 40
 プルリクエストテンプレート - GitHub`.github/PULL_REQUEST_TEMPLATE.md`を配置 - descriptionを揃えることでレビュー負荷軽減 - 関連イシューとのリンクやセルフチェック、動作検証など PRごとに実施して欲しいことの漏れを防ぐ
41. © Findy Inc. 41
 プルリクエストテンプレート - リリース時のQA有無や本番作業をPRごとに記載して、リ リース時のタスク⼀覧の⽣成に使う ◦ GitHub Actionsを活⽤ PRs Release PR QAや本番作業を抽出 リリース時に リリースPRを⾒る だけでやることが 把握できる
42. © Findy Inc. 42
 プルリクエストのアサイン⾃動化 - Auto Assign Action (GitHub Actions) ◦ https://github.com/marketplace/actions/auto-assign-action - プルリクエスト作成時に作成者をアサインする - 案外、アサインを設定しない⼈は多い - プルリクエスト⼀覧でフィルターできたり、パッと⾒ただ けで誰が担当したPRなのかすぐにわかるので良い
43. © 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
44. © 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 ▪ 承認後にプッシュしたら承認取り消し
45. © Findy Inc. 45
 Branch protection rulesを設定 - おすすめ設定(GitHub) - Require status checks to pass before merging ◦ 指定したCIが成功しないとマージできない ◦ Linterや⾃動テストなど成功必須なものを追加
46. © Findy Inc. 46
 ランダムレビュアー - GitHub Teams > Settings > Code review - チームをレビュアーに設定した際、チーム内のメンバーを ランダムアサイン
47. © Findy Inc. 47
 ランダムレビュアー - バイネームでアサインすることで担当者が明確になる - 普段触らない⼈がレビュー依頼する際、レビュアー指定で 迷わない
48. © Findy Inc. 48
 dependabot - ライブラリなどのバージョンアップ⾃動化 ◦ ライブラリだけではなく、コンテナやGitHub Actionsの actionのバージョンなどバージョン管理するものは多い ので⼿動運⽤は厳しい - CIが充実している場合、パッチバージョンなどであればCIが 通っているだけで安⼼してマージできる ◦ オートマージは便利だが、壊れることも多い... ▪ 頻繁に触るコードはすぐ気づけるから良いが、滅多 に触らないコードは気づくのが遅れるので怖い
49. © Findy Inc. 49
 PRラベル付与 - プルリクエスト作成時にGitHub Actionsで付与 - プルリクエストの内容から適切なラベルを付与 ◦ モノレポの修正対象アプリごとに付与 ◦ 修正の種類(feat / fix / refactor / chore...)ごと に付与 - PRの内容がラベルから明確になる - フィルタリングに使えるので、PRを分析したいと きに活⽤できる
50. © Findy Inc. 50
 ER図⾃動⽣成 - schemaspy ◦ https://schemaspy.org/ - GitHub ActionsでDBスキーマからER図を⾃動⽣成 ◦ GitHub Pagesに公開
51. © Findy Inc. 51
 技術スタックの統⼀ - 複数チームある場合、チーム間の技術スタックを揃える - 開発メンバーが少ないうちは退職者1名ですぐにチームが機 能しなくなる ◦ 技術スタックを統⼀するメリット ▪ チーム間のメンバー移動をしやすくする ▪ ノウハウの横展開もできる - 開発組織が拡⼤してきたらチームごとに意思決定するのも あり
52. © Findy Inc. 52
 ドキュメントを⼀元管理 - GitHub ◦ PRベースで修正できて良い - Notion / Confluenceなどもよい - 利⽤者に合わせて適切に選択するのが良い
53. © Findy Inc. 53
 ドキュメントを⼀元管理 - 1つにまとまっているのが良い ◦ 様々なサービスを探しに⾏くのはつらい... - ドキュメント化のハードルを下げる ◦ 調査メモなど個⼈レベルのドキュメントも気軽に残せる とノウハウが溜まりやすくて良い ◦ 重複なども気にしない ▪ フィルタリングでカバーする ▪ ルールを厳しくするとドキュメント化しなくなる
54. © Findy Inc. 54
 イシューテンプレート - GitHub`.github/ISSUE_TEMPLATE`を配置 - イシュー内容を揃えることで読者の認知負荷を軽減 - イシューごとの内容のバラツキが軽減できる - イシュー内容をチェックするためにチェックリストを運⽤ するより、テンプレートに項⽬として⼊れておく⽅がチェッ ク漏れが少ない
55. © Findy Inc. 55
 パブリッククラウドのマネージドサービス - AWS ◦ https://aws.amazon.com - パブリッククラウドの中でもマネージドサービスを積極的 に活⽤しよう ◦ ECS / Aurora / s3 / CloudFront / Step Functions
56. © Findy Inc. 56
 パブリッククラウドのマネージドサービス - IaCの知識がない場合、無理してコード管理しない ◦ 変更頻度や横展開が少ない中でコード管理してもメリッ トが少ない ◦ 開発チームが充実してきたらリバースエンジニアリング しよう
57. © Findy Inc. 57
 デプロイ⾃動化 - GitHub Actionsを活⽤ - 定時にリリースPRを作成 ◦ バックエンド、フロントエンドごとに2回/⽇ ◦ リリースPRに記載されているQAや本番作業を確認 ◦ マージしたらデプロイ開始 ◦ デプロイは全⾃動 ◦ デプロイ完了時にSlack通知 ◦ リリースタグを⾃動⽣成
58. © Findy Inc. 58
 デプロイ⾃動化 - ⼿作業をなくして誰でも⼿間なく実⾏できるようにする - 本番に気軽にデプロイできるようにしておくことで、細か い修正などを気軽に本番反映できる 2023 State of DevOps Report https://cloud.google.com/devops/state-of-devops 開発⽣産性の⾼い 組織はデプロイ頻 度も⾼い
59. © Findy Inc. 59
 本番切り戻し⼿順確⽴ - デプロイを伴う本番障害を素早く切り戻せるようにしてお くことで、安⼼してデプロイできるようになる - ECSで1つ前のコンテナイメージを残しておき、すぐに戻せ るようにしている ◦ 1分ほどで切り戻し可能 - DBのスキーマ変更を伴うと素早い切り戻しが難しい ◦ 良いやり⽅があったら教えてください！
60. © Findy Inc. 60
 監視 SaaS - Datadog ◦ https://www.datadoghq.com ◦ バックエンドのログ監視 ◦ インフラ監視 ▪ 閾値を超えたらSlack通知 - Sentry ◦ https://sentry.io ◦ フロント‧バックエンドのSlack通知
61. © Findy Inc. 61
 監視 SaaS - Slack連携は⼿間でも作り込んだ⽅が良い ◦ 頻繁に⾒るところに通知が来ないと⾒落とす - モニターの作り込みやや⾮機能要件の監視などは余裕がで きたら ◦ ⾒ないモニターは作っても意味がない - 最初はパブリッククラウドの標準機能でも良いかも ◦ リリース当初はあまり使わないわりに料⾦がかかる...
62. © Findy Inc. 62
 E2E SaaS - Autify ◦ https://autify.jp/ - SaaSを利⽤することで気軽に始めることができる - ⾃前で作り込むのとどちらがメンテナンスコストが低いか 検討 - 開発規模が増えることで料⾦がネックになることも... ◦ その時が来たら移⾏を視野に⼊れて検討すれば良い
63. © Findy Inc. 63
 CMS（コンテンツ マネジメント システム） - Contentful / WordPress ◦ https://www.contentful.com/ ◦ https://wordpress.com/ja/ - コンテンツ管理はCMSに頼るべき ◦ コンテンツ管理者がエンジニアの⼿を借りずに更新でき るのが良き - 運⽤がツラくなることがよくあるので、運⽤コストを加味 して検討する
64. © Findy Inc. 64
 SaaS‧OSS - メールや認証‧認可などよく使われる機能は積極的に活⽤ しよう ◦ ⾞輪の再開発を防ぐ ◦ セキュリティ⾯でも有利 - スターの数や活動状況を確認 ◦ ⼤きな組織で使われているライブラリは強い
65. © Findy Inc. 65
 まとめ ⼩さな開発組織でも Platform Engineeringの エッセンスを取り⼊れて よりよい開発者体験を ⼿に⼊れましょう！
66. © Findy Inc. 66
 プロダクトエンジニア ‧エンジニアをターゲットとした  プロダクト開発 ‧技術はモダンが当たり前 ‧⾼い開発⽣産性 ‧開発者体験の追求 ‧CI/CDや⾃動テストが  整備された開発環境 We are hiring！