Tweet
Tweet

Slide 1

Slide 1 text

© Findy Inc. 2024.09.24 Platform Engineering Meetup #10 1 Platform Engineeringのエッセンスを ⼩規模な開発組織に取り⼊れた事例紹介 浜⽥ 直⼈ Naoto Hamada (ham)

Slide 2

Slide 2 text

© Findy Inc. 2 開発⽣産性が向上する⽅法を探求しているエンジニア！ Ruby / Rails / React / TypeScript / AWS Agile / DevOps / Developer Productivity / DevEx Stock Investment 浜⽥ 直⼈ Naoto Hamada (ham) @hamchance0215

Slide 3

Slide 3 text

© Findy Inc. 3 Findy Team+(チームプラス)とは？ 開発⽣産性の可視化、開発プロセスの伸びしろの発⾒、継続的 な改善をサポート 3 ⽣産性可視化 ⽣産性向上 事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー･配置･ツールの伸びしろを可視化‧最適化) ⽂化づくり‧⾃⼰組織化 (メンバーの⾃発的な改善促進、改善を称賛する⽂化作り) データ 連携 Engineer Engineer 開発組織ブランディング (エンジニアは、開発⽣産性が⾼い組織で働きたい) Recruit Biz

Slide 4

Slide 4 text

© Findy Inc. 4 Agenda - ⼩さなチームのPlatform Engineering - やりすぎない。ただし先⾏投資も必要 - 事例紹介

Slide 5

Slide 5 text

© Findy Inc. ⼩さなチームの Platform Engineering 5

Slide 6

Slide 6 text

© Findy Inc. 6
 前提 - テーマ ○ ⼩規模でも始められる！Platform Engineeringの実践例

Slide 7

Slide 7 text

© Findy Inc. 7
 前提 - テーマ ○ ⼩規模でも始められる！Platform Engineeringの実践例 ⼩規模ってどれくらい？

Slide 8

Slide 8 text

© Findy Inc. 8
 前提 - 事例紹介でお話しするチーム規模(2023年ごろの話) ○ 1チーム、エンジニア約10名 ○ 全員プロダクトエンジニア ■ 各々得意領域はあるが、プロダクト開発に必要なこ とをフレキシブルに対応するエンジニアで構成 ■ SREやPlatform Engineering専属メンバーは不在

Slide 9

Slide 9 text

© Findy Inc. 9
 チームトポトジー - 4つの基本的なチームタイプ ○ ストリームアラインドチーム ○ イネイブリングチーム ○ コンプリケイテッド‧サブシステムチーム ○ プラットフォームチーム https://pub.jmam.co.jp/book/b593881.html


Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

© Findy Inc. 14
 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム - ストリームアラインドチームが全ての能⼒を(可能な限り)発 揮する必要がある ○ 各チームのエッセンスを取り⼊れることが重要

Slide 15

Slide 15 text

© Findy Inc. 15
 チームトポトジー - Platform Engineeringとは？ ○ 内部サービスを提供することで、ストリームアラインド チームが下位のサービスを開発する必要をなくし、認知 負荷を下げる ○ プラットフォームチームを結成する

Slide 16

Slide 16 text

© Findy Inc. 16
 チームトポトジー - ⼩さなチームのPlatform Engineeringとは？ ○ 必要に応じて内部サービスを提供することで、ストリー ムアラインドチームが下位のサービスを開発する必要を なくし、⾃分たちの認知負荷を下げる ○ プラットフォームチームのエッセンスを取り⼊れる

Slide 17

Slide 17 text

© Findy Inc. やりすぎない ただし先⾏投資も必要 17

Slide 18

Slide 18 text

© Findy Inc. 18
 Platform Engineeringの事例を取り⼊れる よーし！ Platform Engineeringに 取り組むぞ！ 各社の事例を参考にしよう！

Slide 19

Slide 19 text

© Findy Inc. 19
 やりすぎない - ストリームアラインドチームはプロダクトの価値向上がメ インタスクなので、PFEに取り組める⼯数は限られる ○ 価値向上とPFEに使っている⼯数のバランスを意識 ■ 価値向上により多くの時間が使えていること！！ ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム

Slide 20

Slide 20 text

© Findy Inc. 20
 やりすぎない - アラン‧ケリー「ソフトウェア開発者はプラットフォーム を作るのを好む。プロダクトマネジメントからの確かな情 報もなしに、必要以上に⼤きなプラットフォームを開発し てしまう」 良いプラットフォームは「ちょうど良い⼤きさ」
 https://pub.jmam.co.jp/book/b593881.html


Slide 21

Slide 21 text

© Findy Inc. 21
 やりすぎない - ⼤きな組織の事例で紹介されたものは⼩さな組織には重す ぎるものも多い ○ 全環境がIaCで管理しており、必要なときに必要な環境 をサクッと構築できる！ ○ 権限の付与‧剥奪をWFで⾃動化！

Slide 22

Slide 22 text

© Findy Inc. 22
 やりすぎない - 型化による⼯数削減 ＜ 型化する⼯数+メンテ⼯数 ○ 再実⾏する⾒込みのないIaC ■ 必要になってからリバースエンジニアリング ○ ⼈が把握できる範囲の少⼈数の権限管理 ■ Webコンソールなどから⼿動でやった⽅が早い ■ スプシ管理で⼗分 ○ 「属⼈化==悪」ではなく属⼈化を有効活⽤する ■ 型化してもその仕組みのメンテが属⼈化することも...

Slide 23

Slide 23 text

© Findy Inc. 23
 先⾏投資 - プロダクト開発をする上で繰り返し負担になっているもの は積極的に改善していくべき ○ ⽇々実施するタスクの改善はすぐに元が取れる可能性が ⾼い ■ 型化による⼯数削減 ＞ 型化する⼯数+メンテ⼯数

Slide 24

Slide 24 text

© Findy Inc. 24
 先⾏投資 - ⼯数がかからずできるものは積極的に活⽤ ○ 仮想開発環境 ■ 開発環境の構築が劇的に早まる ■ 環境構築⼿順書が必要最低限でよい ■ ドキュメントと違い陳腐化しづらい

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

© Findy Inc. 26
 先⾏投資 - ⼯数がかからずできるものは積極的に活⽤ ○ SaaS‧OSS ■ コード管理/イシュー管理/ドキュメント管理 ■ CI‧CD/監視 ■ メール/認証 ■ ⼩規模チームだとコスパよく使える可能性が⾼い ● 順調に成⻑した場合のコスト推移や(過度に気に する必要はないが)ベンダーロックインに注意 ● 必要ないものは⼊れない‧使わなくなったら消す

Slide 27

Slide 27 text

© Findy Inc. 事例紹介 27

Slide 28

Slide 28 text

© Findy Inc. 28
 前提(再掲) - 事例紹介でお話しするチーム規模(2023年ごろの話) ○ 1チーム、エンジニア約10名 ○ 全員プロダクトエンジニア ■ 各々得意領域はあるが、プロダクト開発に必要なこ とをフレキシブルに対応するエンジニアで構成 ■ SREやPlatform Engineering専属メンバーは不在

Slide 29

Slide 29 text

© Findy Inc. 29
 開発環境の仮想化 - Docker ○ https://www.docker.com ○ docker composeを活⽤してローカル環境に本番に近い 構成を再現 ■ web / worker / db / db(replica) / redis / storage

Slide 30

Slide 30 text

© Findy Inc. 30
 開発環境の仮想化 - 開発環境の要件がコード管理できる ○ 環境構築⼿順書が必要最低限でよい ○ ドキュメントと違い陳腐化しづらい - 開発者ごとの環境差異が発⽣しづらい - 本番環境との環境差異も発⽣しづらい - 開発環境の構築が劇的に早まる ○ 新規参画者がサクッと環境構築できて即戦⼒

Slide 31

Slide 31 text

© Findy Inc. 31
 Linter、スタイルガイド整備 - フロントエンド(TypeScript) ○ eslint / stylelint / prettier - バックエンド(Ruby) ○ rubocop - 上記でカバーしきれないルールは、スタイルガイドを GitHubのドキュメント(md)で管理

Slide 32

Slide 32 text

© Findy Inc. 32
 Linter、スタイルガイド整備 - 少しでも再利⽤しそうなコードなら必ず⼊れるべき ○ 途中で⼊れるとルール違反の修正が⼤変 ○ ルールを弱めると効果半減 - できる限り厳しいルールを適⽤する⽅が良い ○ 迷ったらデフォルト設定に準拠すると良い ○ 新しいルールも積極的に採⽤ - 機械的にチェックできないルールはドキュメント化 ○ 機械的にチェックされないルールは形骸化しやすいので 最低限のルールに留める

Slide 33

Slide 33 text

© Findy Inc. 33
 ⾃動テスト導⼊ - フロントエンド(TypeScript) ○ jest / react-testing-library / reg-suit - バックエンド(Ruby) ○ rspec

Slide 34

Slide 34 text

© Findy Inc. 34
 ⾃動テスト導⼊ - 少しでも再利⽤しそうなコードなら必ず⼊れるべき ○ 4回以上変更するなら導⼊価値がある 質とスピード (@t_wada) https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition

Slide 35

Slide 35 text

© 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

Slide 36

Slide 36 text

© 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

Slide 37

Slide 37 text

© 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より早く気づけるのでフィードバックループがより早くな る

Slide 38

Slide 38 text

© Findy Inc. 38
 commitメッセージにprefixをつける - git-cz ○ https://github.com/streamich/git-cz

Slide 39

Slide 39 text

© Findy Inc. 39
 commitメッセージにprefixをつける - 修正内容によってcommitメッセージにprefixをつける ○ commit内容がメッセージから明確になる ○ prefixは1つなので1つのcommitで1つのことをやるよう になる

Slide 40

Slide 40 text

© Findy Inc. 40
 プルリクエストテンプレート - GitHub`.github/PULL_REQUEST_TEMPLATE.md`を配置 - descriptionを揃えることでレビュー負荷軽減 - 関連イシューとのリンクやセルフチェック、動作検証など PRごとに実施して欲しいことの漏れを防ぐ

Slide 41

Slide 41 text

© Findy Inc. 41
 プルリクエストテンプレート - リリース時のQA有無や本番作業をPRごとに記載して、リ リース時のタスク⼀覧の⽣成に使う ○ GitHub Actionsを活⽤ PRs Release PR QAや本番作業を抽出 リリース時に リリースPRを⾒る だけでやることが 把握できる

Slide 42

Slide 42 text

© Findy Inc. 42
 プルリクエストのアサイン⾃動化 - Auto Assign Action (GitHub Actions) ○ https://github.com/marketplace/actions/auto-assign-action - プルリクエスト作成時に作成者をアサインする - 案外、アサインを設定しない⼈は多い - プルリクエスト⼀覧でフィルターできたり、パッと⾒ただ けで誰が担当したPRなのかすぐにわかるので良い

Slide 43

Slide 43 text

© 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

Slide 44

Slide 44 text

© 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 ■ 承認後にプッシュしたら承認取り消し

Slide 45

Slide 45 text

© Findy Inc. 45
 Branch protection rulesを設定 - おすすめ設定(GitHub) - Require status checks to pass before merging ○ 指定したCIが成功しないとマージできない ○ Linterや⾃動テストなど成功必須なものを追加

Slide 46

Slide 46 text

© Findy Inc. 46
 ランダムレビュアー - GitHub Teams > Settings > Code review - チームをレビュアーに設定した際、チーム内のメンバーを ランダムアサイン

Slide 47

Slide 47 text

© Findy Inc. 47
 ランダムレビュアー - バイネームでアサインすることで担当者が明確になる - 普段触らない⼈がレビュー依頼する際、レビュアー指定で 迷わない

Slide 48

Slide 48 text

© Findy Inc. 48
 dependabot - ライブラリなどのバージョンアップ⾃動化 ○ ライブラリだけではなく、コンテナやGitHub Actionsの actionのバージョンなどバージョン管理するものは多い ので⼿動運⽤は厳しい - CIが充実している場合、パッチバージョンなどであればCIが 通っているだけで安⼼してマージできる ○ オートマージは便利だが、壊れることも多い... ■ 頻繁に触るコードはすぐ気づけるから良いが、滅多 に触らないコードは気づくのが遅れるので怖い

Slide 49

Slide 49 text

© Findy Inc. 49
 PRラベル付与 - プルリクエスト作成時にGitHub Actionsで付与 - プルリクエストの内容から適切なラベルを付与 ○ モノレポの修正対象アプリごとに付与 ○ 修正の種類(feat / fix / refactor / chore...)ごと に付与 - PRの内容がラベルから明確になる - フィルタリングに使えるので、PRを分析したいと きに活⽤できる

Slide 50

Slide 50 text

© Findy Inc. 50
 ER図⾃動⽣成 - schemaspy ○ https://schemaspy.org/ - GitHub ActionsでDBスキーマからER図を⾃動⽣成 ○ GitHub Pagesに公開

Slide 51

Slide 51 text

© Findy Inc. 51
 技術スタックの統⼀ - 複数チームある場合、チーム間の技術スタックを揃える - 開発メンバーが少ないうちは退職者1名ですぐにチームが機 能しなくなる ○ 技術スタックを統⼀するメリット ■ チーム間のメンバー移動をしやすくする ■ ノウハウの横展開もできる - 開発組織が拡⼤してきたらチームごとに意思決定するのも あり

Slide 52

Slide 52 text

© Findy Inc. 52
 ドキュメントを⼀元管理 - GitHub ○ PRベースで修正できて良い - Notion / Confluenceなどもよい - 利⽤者に合わせて適切に選択するのが良い

Slide 53

Slide 53 text

© Findy Inc. 53
 ドキュメントを⼀元管理 - 1つにまとまっているのが良い ○ 様々なサービスを探しに⾏くのはつらい... - ドキュメント化のハードルを下げる ○ 調査メモなど個⼈レベルのドキュメントも気軽に残せる とノウハウが溜まりやすくて良い ○ 重複なども気にしない ■ フィルタリングでカバーする ■ ルールを厳しくするとドキュメント化しなくなる

Slide 54

Slide 54 text

© Findy Inc. 54
 イシューテンプレート - GitHub`.github/ISSUE_TEMPLATE`を配置 - イシュー内容を揃えることで読者の認知負荷を軽減 - イシューごとの内容のバラツキが軽減できる - イシュー内容をチェックするためにチェックリストを運⽤ するより、テンプレートに項⽬として⼊れておく⽅がチェッ ク漏れが少ない

Slide 55

Slide 55 text

© Findy Inc. 55
 パブリッククラウドのマネージドサービス - AWS ○ https://aws.amazon.com - パブリッククラウドの中でもマネージドサービスを積極的 に活⽤しよう ○ ECS / Aurora / s3 / CloudFront / Step Functions

Slide 56

Slide 56 text

© Findy Inc. 56
 パブリッククラウドのマネージドサービス - IaCの知識がない場合、無理してコード管理しない ○ 変更頻度や横展開が少ない中でコード管理してもメリッ トが少ない ○ 開発チームが充実してきたらリバースエンジニアリング しよう

Slide 57

Slide 57 text

© Findy Inc. 57
 デプロイ⾃動化 - GitHub Actionsを活⽤ - 定時にリリースPRを作成 ○ バックエンド、フロントエンドごとに2回/⽇ ○ リリースPRに記載されているQAや本番作業を確認 ○ マージしたらデプロイ開始 ○ デプロイは全⾃動 ○ デプロイ完了時にSlack通知 ○ リリースタグを⾃動⽣成

Slide 58

Slide 58 text

© Findy Inc. 58
 デプロイ⾃動化 - ⼿作業をなくして誰でも⼿間なく実⾏できるようにする - 本番に気軽にデプロイできるようにしておくことで、細か い修正などを気軽に本番反映できる 2023 State of DevOps Report https://cloud.google.com/devops/state-of-devops 開発⽣産性の⾼い 組織はデプロイ頻 度も⾼い

Slide 59

Slide 59 text

© Findy Inc. 59
 本番切り戻し⼿順確⽴ - デプロイを伴う本番障害を素早く切り戻せるようにしてお くことで、安⼼してデプロイできるようになる - ECSで1つ前のコンテナイメージを残しておき、すぐに戻せ るようにしている ○ 1分ほどで切り戻し可能 - DBのスキーマ変更を伴うと素早い切り戻しが難しい ○ 良いやり⽅があったら教えてください！

Slide 60

Slide 60 text

© Findy Inc. 60
 監視 SaaS - Datadog ○ https://www.datadoghq.com ○ バックエンドのログ監視 ○ インフラ監視 ■ 閾値を超えたらSlack通知 - Sentry ○ https://sentry.io ○ フロント‧バックエンドのSlack通知

Slide 61

Slide 61 text

© Findy Inc. 61
 監視 SaaS - Slack連携は⼿間でも作り込んだ⽅が良い ○ 頻繁に⾒るところに通知が来ないと⾒落とす - モニターの作り込みやや⾮機能要件の監視などは余裕がで きたら ○ ⾒ないモニターは作っても意味がない - 最初はパブリッククラウドの標準機能でも良いかも ○ リリース当初はあまり使わないわりに料⾦がかかる...

Slide 62

Slide 62 text

© Findy Inc. 62
 E2E SaaS - Autify ○ https://autify.jp/ - SaaSを利⽤することで気軽に始めることができる - ⾃前で作り込むのとどちらがメンテナンスコストが低いか 検討 - 開発規模が増えることで料⾦がネックになることも... ○ その時が来たら移⾏を視野に⼊れて検討すれば良い

Slide 63

Slide 63 text

© Findy Inc. 63
 CMS（コンテンツ マネジメント システム） - Contentful / WordPress ○ https://www.contentful.com/ ○ https://wordpress.com/ja/ - コンテンツ管理はCMSに頼るべき ○ コンテンツ管理者がエンジニアの⼿を借りずに更新でき るのが良き - 運⽤がツラくなることがよくあるので、運⽤コストを加味 して検討する

Slide 64

Slide 64 text

© Findy Inc. 64
 SaaS‧OSS - メールや認証‧認可などよく使われる機能は積極的に活⽤ しよう ○ ⾞輪の再開発を防ぐ ○ セキュリティ⾯でも有利 - スターの数や活動状況を確認 ○ ⼤きな組織で使われているライブラリは強い

Slide 65

Slide 65 text

© Findy Inc. 65
 まとめ ⼩さな開発組織でも Platform Engineeringの エッセンスを取り⼊れて よりよい開発者体験を ⼿に⼊れましょう！

Slide 66

Slide 66 text

© Findy Inc. 66
 プロダクトエンジニア ‧エンジニアをターゲットとした  プロダクト開発 ‧技術はモダンが当たり前 ‧⾼い開発⽣産性 ‧開発者体験の追求 ‧CI/CDや⾃動テストが  整備された開発環境 We are hiring！