Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Platform Engineeringのエッセンスを小規模な開発組織に取り入れた事例紹介
Search
ham
September 23, 2024
Technology
8
1.5k
Platform Engineeringのエッセンスを小規模な開発組織に取り入れた事例紹介
Platform Engineering Meetup #10で登壇したスライド
https://platformengineering.connpass.com/event/329871/
ham
September 23, 2024
Tweet
Share
More Decks by ham
See All by ham
開発者の定量・定性データを組み合わせて開発者体験を把握するための取り組み
ham0215
4
1.5k
アジャイルを始めるための基礎を固める
ham0215
1
83
開発者体験を意識した開発チームの生産性向上の取り組み
ham0215
3
880
MySQLのViewを活用した安全なマルチテナントの実現方法
ham0215
2
880
開発パフォーマンスを最大化するための開発体制
ham0215
7
1.6k
今こそ思い出すGraphQLの特徴
ham0215
0
170
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
520
CIは5分以内!素早い開発サイクルを支えるCI
ham0215
1
3.9k
現場主導で取り組む継続的な技術的負債の解消
ham0215
4
4.6k
Other Decks in Technology
See All in Technology
A/Aテストにおけるサンプルサイズ/japanr2024
nikkei_engineer_recruiting
1
610
開発者向けツールを魔改造してセキュリティ診断ツールを作っている話 - 第1回 セキュリティ若手の会 LT
pizzacat83
0
400
Kaggleふりかえり会〜LLM 20 Questions & ISIC 2024
recruitengineers
PRO
2
190
お悩みハンドブック紹介資料
grafferhandbook
0
1.4k
プロダクトの爆速開発を支える、 「作らない・削る・尖らせる」技術
applism118
10
8.7k
密着! Bedrockerがre:Invent 2024で過ごした5日間を紹介
minorun365
PRO
3
320
PostgreSQL Conference Japan 2024 A4 Comparison of column-oriented access methods
nori_shinoda
0
150
総会員数1,500万人のレストランWeb予約サービスにおけるRustの活用
kymmt90
3
2.9k
「品質とスピードはトレード・オンできる」に向き合い続けた2年半を振り返る / Quality and speed can be traded on.
mii3king
0
730
Replit Agent
kawaguti
PRO
2
200
GeminiとUnityで実現するインタラクティブアート
hokkey621
0
640
スパイクアクセス対策としての pitchfork 導入
riseshia
0
190
Featured
See All Featured
Statistics for Hackers
jakevdp
796
220k
Site-Speed That Sticks
csswizardry
1
150
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
GraphQLとの向き合い方2022年版
quramy
44
13k
Navigating Team Friction
lara
183
15k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.2k
We Have a Design System, Now What?
morganepeng
51
7.3k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Code Review Best Practice
trishagee
64
17k
Writing Fast Ruby
sferik
627
61k
Become a Pro
speakerdeck
PRO
25
5k
Transcript
© Findy Inc. 2024.09.24 Platform Engineering Meetup #10 1 Platform
Engineeringのエッセンスを ⼩規模な開発組織に取り⼊れた事例紹介 浜⽥ 直⼈ Naoto Hamada (ham)
© Findy Inc. 2 開発⽣産性が向上する⽅法を探求しているエンジニア! Ruby / Rails / React
/ TypeScript / AWS Agile / DevOps / Developer Productivity / DevEx Stock Investment 浜⽥ 直⼈ Naoto Hamada (ham) @hamchance0215
© Findy Inc. 3 Findy Team+(チームプラス)とは? 開発⽣産性の可視化、開発プロセスの伸びしろの発⾒、継続的 な改善をサポート 3 ⽣産性可視化
⽣産性向上 事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー・配置・ツールの伸びしろを可視化‧最適化) ⽂化づくり‧⾃⼰組織化 (メンバーの⾃発的な改善促進、改善を称賛する⽂化作り) データ 連携 Engineer Engineer 開発組織ブランディング (エンジニアは、開発⽣産性が⾼い組織で働きたい) Recruit Biz
© Findy Inc. 4 Agenda - ⼩さなチームのPlatform Engineering - やりすぎない。ただし先⾏投資も必要
- 事例紹介
© Findy Inc. ⼩さなチームの Platform Engineering 5
© Findy Inc. 6 前提 - テーマ ◦ ⼩規模でも始められる!Platform Engineeringの実践例
© Findy Inc. 7 前提 - テーマ ◦ ⼩規模でも始められる!Platform Engineeringの実践例
⼩規模ってどれくらい?
© Findy Inc. 8 前提 - 事例紹介でお話しするチーム規模(2023年ごろの話) ◦ 1チーム、エンジニア約10名 ◦
全員プロダクトエンジニア ▪ 各々得意領域はあるが、プロダクト開発に必要なこ とをフレキシブルに対応するエンジニアで構成 ▪ SREやPlatform Engineering専属メンバーは不在
© Findy Inc. 9 チームトポトジー - 4つの基本的なチームタイプ ◦ ストリームアラインドチーム ◦
イネイブリングチーム ◦ コンプリケイテッド‧サブシステムチーム ◦ プラットフォームチーム https://pub.jmam.co.jp/book/b593881.html
© Findy Inc. 10 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム
価値のある単⼀の仕事の ストリームに沿って働く チーム ストリームアラインドチーム の負荷を減らす
© Findy Inc. 11 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム
まだ1チームだし ストリームアラインドだけ 考えれば良いね! 他のチームは組織が⼤き くなったら考えよう!
© Findy Inc. 12 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム
まだ1チームだし ストリームアラインドだけ 考えれば良いね! 他のチームは組織が⼤き くなったら考えよう!
© Findy Inc. 13 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム
まだ1チームだし ストリームアラインドだけ 考えれば良いね! 他のチームは組織が⼤き くなったら考えよう! 専属チームを作らなくても そのチームが担う能力は必要
© Findy Inc. 14 チームトポトジー ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム
- ストリームアラインドチームが全ての能⼒を(可能な限り)発 揮する必要がある ◦ 各チームのエッセンスを取り⼊れることが重要
© Findy Inc. 15 チームトポトジー - Platform Engineeringとは? ◦ 内部サービスを提供することで、ストリームアラインド
チームが下位のサービスを開発する必要をなくし、認知 負荷を下げる ◦ プラットフォームチームを結成する
© Findy Inc. 16 チームトポトジー - ⼩さなチームのPlatform Engineeringとは? ◦ 必要に応じて内部サービスを提供することで、ストリー
ムアラインドチームが下位のサービスを開発する必要を なくし、⾃分たちの認知負荷を下げる ◦ プラットフォームチームのエッセンスを取り⼊れる
© Findy Inc. やりすぎない ただし先⾏投資も必要 17
© Findy Inc. 18 Platform Engineeringの事例を取り⼊れる よーし! Platform Engineeringに 取り組むぞ!
各社の事例を参考にしよう!
© Findy Inc. 19 やりすぎない - ストリームアラインドチームはプロダクトの価値向上がメ インタスクなので、PFEに取り組める⼯数は限られる ◦ 価値向上とPFEに使っている⼯数のバランスを意識
▪ 価値向上により多くの時間が使えていること!! ストリームアラインド イネイブリング プラットフォーム コンプリケイテッド サブシステム
© Findy Inc. 20 やりすぎない - アラン‧ケリー「ソフトウェア開発者はプラットフォーム を作るのを好む。プロダクトマネジメントからの確かな情 報もなしに、必要以上に⼤きなプラットフォームを開発し てしまう」
良いプラットフォームは「ちょうど良い⼤きさ」 https://pub.jmam.co.jp/book/b593881.html
© Findy Inc. 21 やりすぎない - ⼤きな組織の事例で紹介されたものは⼩さな組織には重す ぎるものも多い ◦ 全環境がIaCで管理しており、必要なときに必要な環境
をサクッと構築できる! ◦ 権限の付与‧剥奪をWFで⾃動化!
© Findy Inc. 22 やりすぎない - 型化による⼯数削減 < 型化する⼯数+メンテ⼯数 ◦
再実⾏する⾒込みのないIaC ▪ 必要になってからリバースエンジニアリング ◦ ⼈が把握できる範囲の少⼈数の権限管理 ▪ Webコンソールなどから⼿動でやった⽅が早い ▪ スプシ管理で⼗分 ◦ 「属⼈化==悪」ではなく属⼈化を有効活⽤する ▪ 型化してもその仕組みのメンテが属⼈化することも...
© Findy Inc. 23 先⾏投資 - プロダクト開発をする上で繰り返し負担になっているもの は積極的に改善していくべき ◦ ⽇々実施するタスクの改善はすぐに元が取れる可能性が
⾼い ▪ 型化による⼯数削減 > 型化する⼯数+メンテ⼯数
© Findy Inc. 24 先⾏投資 - ⼯数がかからずできるものは積極的に活⽤ ◦ 仮想開発環境 ▪
開発環境の構築が劇的に早まる ▪ 環境構築⼿順書が必要最低限でよい ▪ ドキュメントと違い陳腐化しづらい
© Findy Inc. 25 先⾏投資 - ⼯数がかからずできるものは積極的に活⽤ ◦ インフラのマネージドサービス ▪
素早く初期構築 ▪ 運⽤コスト削減 ▪ パブリックなノウハウが多い ▪ インフラ障害時にサポートしてもらえる
© Findy Inc. 26 先⾏投資 - ⼯数がかからずできるものは積極的に活⽤ ◦ SaaS‧OSS ▪
コード管理/イシュー管理/ドキュメント管理 ▪ CI‧CD/監視 ▪ メール/認証 ▪ ⼩規模チームだとコスパよく使える可能性が⾼い • 順調に成⻑した場合のコスト推移や(過度に気に する必要はないが)ベンダーロックインに注意 • 必要ないものは⼊れない‧使わなくなったら消す
© Findy Inc. 事例紹介 27
© Findy Inc. 28 前提(再掲) - 事例紹介でお話しするチーム規模(2023年ごろの話) ◦ 1チーム、エンジニア約10名 ◦
全員プロダクトエンジニア ▪ 各々得意領域はあるが、プロダクト開発に必要なこ とをフレキシブルに対応するエンジニアで構成 ▪ SREやPlatform Engineering専属メンバーは不在
© Findy Inc. 29 開発環境の仮想化 - Docker ◦ https://www.docker.com ◦
docker composeを活⽤してローカル環境に本番に近い 構成を再現 ▪ web / worker / db / db(replica) / redis / storage
© Findy Inc. 30 開発環境の仮想化 - 開発環境の要件がコード管理できる ◦ 環境構築⼿順書が必要最低限でよい ◦
ドキュメントと違い陳腐化しづらい - 開発者ごとの環境差異が発⽣しづらい - 本番環境との環境差異も発⽣しづらい - 開発環境の構築が劇的に早まる ◦ 新規参画者がサクッと環境構築できて即戦⼒
© Findy Inc. 31 Linter、スタイルガイド整備 - フロントエンド(TypeScript) ◦ eslint /
stylelint / prettier - バックエンド(Ruby) ◦ rubocop - 上記でカバーしきれないルールは、スタイルガイドを GitHubのドキュメント(md)で管理
© Findy Inc. 32 Linter、スタイルガイド整備 - 少しでも再利⽤しそうなコードなら必ず⼊れるべき ◦ 途中で⼊れるとルール違反の修正が⼤変 ◦
ルールを弱めると効果半減 - できる限り厳しいルールを適⽤する⽅が良い ◦ 迷ったらデフォルト設定に準拠すると良い ◦ 新しいルールも積極的に採⽤ - 機械的にチェックできないルールはドキュメント化 ◦ 機械的にチェックされないルールは形骸化しやすいので 最低限のルールに留める
© Findy Inc. 33 ⾃動テスト導⼊ - フロントエンド(TypeScript) ◦ jest /
react-testing-library / reg-suit - バックエンド(Ruby) ◦ rspec
© Findy Inc. 34 ⾃動テスト導⼊ - 少しでも再利⽤しそうなコードなら必ず⼊れるべき ◦ 4回以上変更するなら導⼊価値がある 質とスピード
(@t_wada) https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition
© 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
© 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
© 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より早く気づけるのでフィードバックループがより早くな る
© Findy Inc. 38 commitメッセージにprefixをつける - git-cz ◦ https://github.com/streamich/git-cz
© Findy Inc. 39 commitメッセージにprefixをつける - 修正内容によってcommitメッセージにprefixをつける ◦ commit内容がメッセージから明確になる ◦
prefixは1つなので1つのcommitで1つのことをやるよう になる
© Findy Inc. 40 プルリクエストテンプレート - GitHub`.github/PULL_REQUEST_TEMPLATE.md`を配置 - descriptionを揃えることでレビュー負荷軽減 -
関連イシューとのリンクやセルフチェック、動作検証など PRごとに実施して欲しいことの漏れを防ぐ
© Findy Inc. 41 プルリクエストテンプレート - リリース時のQA有無や本番作業をPRごとに記載して、リ リース時のタスク⼀覧の⽣成に使う ◦ GitHub
Actionsを活⽤ PRs Release PR QAや本番作業を抽出 リリース時に リリースPRを⾒る だけでやることが 把握できる
© Findy Inc. 42 プルリクエストのアサイン⾃動化 - Auto Assign Action (GitHub
Actions) ◦ https://github.com/marketplace/actions/auto-assign-action - プルリクエスト作成時に作成者をアサインする - 案外、アサインを設定しない⼈は多い - プルリクエスト⼀覧でフィルターできたり、パッと⾒ただ けで誰が担当したPRなのかすぐにわかるので良い
© 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
© 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 ▪ 承認後にプッシュしたら承認取り消し
© Findy Inc. 45 Branch protection rulesを設定 - おすすめ設定(GitHub) -
Require status checks to pass before merging ◦ 指定したCIが成功しないとマージできない ◦ Linterや⾃動テストなど成功必須なものを追加
© Findy Inc. 46 ランダムレビュアー - GitHub Teams > Settings
> Code review - チームをレビュアーに設定した際、チーム内のメンバーを ランダムアサイン
© Findy Inc. 47 ランダムレビュアー - バイネームでアサインすることで担当者が明確になる - 普段触らない⼈がレビュー依頼する際、レビュアー指定で 迷わない
© Findy Inc. 48 dependabot - ライブラリなどのバージョンアップ⾃動化 ◦ ライブラリだけではなく、コンテナやGitHub Actionsの
actionのバージョンなどバージョン管理するものは多い ので⼿動運⽤は厳しい - CIが充実している場合、パッチバージョンなどであればCIが 通っているだけで安⼼してマージできる ◦ オートマージは便利だが、壊れることも多い... ▪ 頻繁に触るコードはすぐ気づけるから良いが、滅多 に触らないコードは気づくのが遅れるので怖い
© Findy Inc. 49 PRラベル付与 - プルリクエスト作成時にGitHub Actionsで付与 - プルリクエストの内容から適切なラベルを付与
◦ モノレポの修正対象アプリごとに付与 ◦ 修正の種類(feat / fix / refactor / chore...)ごと に付与 - PRの内容がラベルから明確になる - フィルタリングに使えるので、PRを分析したいと きに活⽤できる
© Findy Inc. 50 ER図⾃動⽣成 - schemaspy ◦ https://schemaspy.org/ -
GitHub ActionsでDBスキーマからER図を⾃動⽣成 ◦ GitHub Pagesに公開
© Findy Inc. 51 技術スタックの統⼀ - 複数チームある場合、チーム間の技術スタックを揃える - 開発メンバーが少ないうちは退職者1名ですぐにチームが機 能しなくなる
◦ 技術スタックを統⼀するメリット ▪ チーム間のメンバー移動をしやすくする ▪ ノウハウの横展開もできる - 開発組織が拡⼤してきたらチームごとに意思決定するのも あり
© Findy Inc. 52 ドキュメントを⼀元管理 - GitHub ◦ PRベースで修正できて良い -
Notion / Confluenceなどもよい - 利⽤者に合わせて適切に選択するのが良い
© Findy Inc. 53 ドキュメントを⼀元管理 - 1つにまとまっているのが良い ◦ 様々なサービスを探しに⾏くのはつらい... -
ドキュメント化のハードルを下げる ◦ 調査メモなど個⼈レベルのドキュメントも気軽に残せる とノウハウが溜まりやすくて良い ◦ 重複なども気にしない ▪ フィルタリングでカバーする ▪ ルールを厳しくするとドキュメント化しなくなる
© Findy Inc. 54 イシューテンプレート - GitHub`.github/ISSUE_TEMPLATE`を配置 - イシュー内容を揃えることで読者の認知負荷を軽減 -
イシューごとの内容のバラツキが軽減できる - イシュー内容をチェックするためにチェックリストを運⽤ するより、テンプレートに項⽬として⼊れておく⽅がチェッ ク漏れが少ない
© Findy Inc. 55 パブリッククラウドのマネージドサービス - AWS ◦ https://aws.amazon.com -
パブリッククラウドの中でもマネージドサービスを積極的 に活⽤しよう ◦ ECS / Aurora / s3 / CloudFront / Step Functions
© Findy Inc. 56 パブリッククラウドのマネージドサービス - IaCの知識がない場合、無理してコード管理しない ◦ 変更頻度や横展開が少ない中でコード管理してもメリッ トが少ない
◦ 開発チームが充実してきたらリバースエンジニアリング しよう
© Findy Inc. 57 デプロイ⾃動化 - GitHub Actionsを活⽤ - 定時にリリースPRを作成
◦ バックエンド、フロントエンドごとに2回/⽇ ◦ リリースPRに記載されているQAや本番作業を確認 ◦ マージしたらデプロイ開始 ◦ デプロイは全⾃動 ◦ デプロイ完了時にSlack通知 ◦ リリースタグを⾃動⽣成
© Findy Inc. 58 デプロイ⾃動化 - ⼿作業をなくして誰でも⼿間なく実⾏できるようにする - 本番に気軽にデプロイできるようにしておくことで、細か い修正などを気軽に本番反映できる
2023 State of DevOps Report https://cloud.google.com/devops/state-of-devops 開発⽣産性の⾼い 組織はデプロイ頻 度も⾼い
© Findy Inc. 59 本番切り戻し⼿順確⽴ - デプロイを伴う本番障害を素早く切り戻せるようにしてお くことで、安⼼してデプロイできるようになる - ECSで1つ前のコンテナイメージを残しておき、すぐに戻せ
るようにしている ◦ 1分ほどで切り戻し可能 - DBのスキーマ変更を伴うと素早い切り戻しが難しい ◦ 良いやり⽅があったら教えてください!
© Findy Inc. 60 監視 SaaS - Datadog ◦ https://www.datadoghq.com
◦ バックエンドのログ監視 ◦ インフラ監視 ▪ 閾値を超えたらSlack通知 - Sentry ◦ https://sentry.io ◦ フロント‧バックエンドのSlack通知
© Findy Inc. 61 監視 SaaS - Slack連携は⼿間でも作り込んだ⽅が良い ◦ 頻繁に⾒るところに通知が来ないと⾒落とす
- モニターの作り込みやや⾮機能要件の監視などは余裕がで きたら ◦ ⾒ないモニターは作っても意味がない - 最初はパブリッククラウドの標準機能でも良いかも ◦ リリース当初はあまり使わないわりに料⾦がかかる...
© Findy Inc. 62 E2E SaaS - Autify ◦ https://autify.jp/
- SaaSを利⽤することで気軽に始めることができる - ⾃前で作り込むのとどちらがメンテナンスコストが低いか 検討 - 開発規模が増えることで料⾦がネックになることも... ◦ その時が来たら移⾏を視野に⼊れて検討すれば良い
© Findy Inc. 63 CMS(コンテンツ マネジメント システム) - Contentful /
WordPress ◦ https://www.contentful.com/ ◦ https://wordpress.com/ja/ - コンテンツ管理はCMSに頼るべき ◦ コンテンツ管理者がエンジニアの⼿を借りずに更新でき るのが良き - 運⽤がツラくなることがよくあるので、運⽤コストを加味 して検討する
© Findy Inc. 64 SaaS‧OSS - メールや認証‧認可などよく使われる機能は積極的に活⽤ しよう ◦ ⾞輪の再開発を防ぐ
◦ セキュリティ⾯でも有利 - スターの数や活動状況を確認 ◦ ⼤きな組織で使われているライブラリは強い
© Findy Inc. 65 まとめ ⼩さな開発組織でも Platform Engineeringの エッセンスを取り⼊れて よりよい開発者体験を
⼿に⼊れましょう!
© Findy Inc. 66 プロダクトエンジニア ‧エンジニアをターゲットとした プロダクト開発 ‧技術はモダンが当たり前 ‧⾼い開発⽣産性 ‧開発者体験の追求
‧CI/CDや⾃動テストが 整備された開発環境 We are hiring!