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.3k
アジャイルを始めるための基礎を固める
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
JAWS-UG 横浜支部 #76 AWS re:Invent 2024 宇宙一早い Recap LT3Amazon EKS Auto Modeと遊び(パーティ)の話
tjotjo
0
130
Kubernetesトラフィックルーティング徹底解説/Kubernetes-traffic-deep-dive
oracle4engineer
PRO
3
270
Empowering Customer Decisions with Elasticsearch: From Search to Answer Generation
hinatades
PRO
0
300
GitHub Actions의 다양한 기능 활용하기 - GitHub Universe '24 Recap
outsider
0
510
プロダクトの爆速開発を支える、 「作らない・削る・尖らせる」技術
applism118
10
8.7k
宇宙最速のランチRecap LT会(AWS re:Invent 2024)
watany
1
380
re:Inventで発表された Bedrockの新機能を色々使って、マルチRAGエージェントにクラウド選定させてみた件
minorun365
PRO
3
220
My Generation 年配者がこの先生きのこるには (Developers CAREER Boost 2024 Edition)/My Generation How elder engineers can survive
kwappa
3
370
Advancing the 3D Geospatial Ecosystem in Japan via Global Collaborations
osgeojp
0
180
ドメインロジックで考えるテスタビリティ
leveragestech
1
280
2024年のModern Data Stackを振り返ろう~分野別の目玉アップデート情報まとめ~
sagara
0
340
【ASW21-01】STAMPSTPAで導き出した課題に対する対策立案手法の提案
hianraku9498
0
600
Featured
See All Featured
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Producing Creativity
orderedlist
PRO
341
39k
Raft: Consensus for Rubyists
vanstee
136
6.7k
The World Runs on Bad Software
bkeepers
PRO
65
11k
A better future with KSS
kneath
238
17k
A designer walks into a library…
pauljervisheath
204
24k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Become a Pro
speakerdeck
PRO
25
5k
The Pragmatic Product Professional
lauravandoore
32
6.3k
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!