768 Views
June 23, 25
スライド概要
Engineering Productivity Meetup #4 in 東京 - connpass
https://cybozu.connpass.com/event/355795/
座右の銘は「an infinite iterator has no upper bound」
2025-06-20 Engineering Productivity Meetup #4 in 東京 生産性向上チームから プロダクトチームへ行って 見えた"生産性向上" 生産性向上チーム 谷 昌典 1
自己紹介 谷 昌典 (@uta8a) サイボウズ株式会社 生産性向上チーム #経歴 2023/4 サイボウズ新卒入社 2023/7 セルフホストランナー基盤 2024/10 Four Keys基盤 2025/3 プロダクトチームと兼任 #扱える技術 Terraform/CDK AWS/GCP GitHub Actions TypeScript 2
目次 • 前置き • 背景説明 • 技術パート • CIの整備 • CDK • ポエムパート • 生産性向上とは? 3
前置き ©️ Cybozu, Inc. 4
前置き 背景: 生産性向上チームの悩み • プロダクトチームでの経験があるメンバーが抜けた • 以前よりももっと「プロダクトチームが何を求めているか分からな い」状態に • 「開発者の生産性向上」をしたいのに、開発者のことがわからな い! 5
前置き 背景: 悩みに対してどうしたか • プロジェクトが終了したタイミングで2人が出向的な形で兼任へ • 開発チームの別々のチームへ • 今回はそのうちの一人である谷が発表 →3ヶ月以上経って、兼任してみてどうだった?という話をします 6
技術パート ©️ Cybozu, Inc. 7
技術パート やったこと: CI/CDの整備 前提 • 新しい機能の開発なので、リポジトリが新しく作られて間もない • 今後の開発速度を高めるようなCI/CDが求められる やったこと • AWSで、プルリクエストごとに環境が立つようなCIを組んだ • データをDBに自動投入する補助プログラムを書いた 8
技術パート やったこと: CI/CDの整備 ラベル ・環境をフルで作る 10分 ・一部モックで作る 5分以内 9
技術パート やったこと: CDKでインフラをいい感じに書く 前提 • CIが組めても、実際のところはPRごとのリソースと共通のリソー スが存在する やったこと • インフラ部分をCDK(TypeScript)で書いた 10
技術パート やったこと: CDKでインフラをいい感じに書く 共通リソース: commonの例 ・フロントエンドのビルドしたassetはPRごとに置き、それを配信するCloudfrontやS3 bucketはcommon 11
技術パート やったこと: 最終的にできたCI • fmt, lint, test, license-check • deploy周り • common, prといった環境の違いはnpm scriptの方で対応 “deploy:pr”: “cdk deploy --concurrency N --require-approval never --exclusively AService BService” • PR番号など、動的なものはcdkのcontextでCLIの引数から渡す pnpm run deploy:$TARGET --context prnum=“$PRNUM” ... 12
技術パート 感想 • 思ったより普通のことをやっている • 特殊なことは必要ない、王道っぽいこと(PRごとの環境など)をすれば良い • もちろん初めて触るAWSリソースなので苦戦してた • プロダクトチームは初めてなので、生産性向上の時より気持ちしっかりCI を組んでいた • Terraformをメインで触っていたので、CDKに苦戦した 13
技術パート ここがつらいよCDK Stackの分割 • Stack分割によって、インフラリソースを一部立ち上げられるようにし たい(CIの高速化) • でも結局依存関係が入ると高速化できない→変な部分で区切ることに... dependencyの適切な設定 • addDependency() でリソースAとリソースBの作成に依存関係を持たせ られる • この依存関係は、自分で設定する必要がある(!) • Cloudformationのログや、CloudTrailのログを見てデバッグ 14
ポエムパート ©️ Cybozu, Inc. 15
ポエムパート おさらい: 生産性向上の悩み • 開発チームとの距離がある • 開発者のことが分からないから、開発者の生産性向上に効くものがよく分から ない • 開発基盤のメンテは引き続き必要だが、本当にこれだけでいいのか...? 16
ポエムパート 悩みの本質は Embedded or Platform なのでは? 参考: SREの組織形態分類 • Product SRE: Enabling的に関わる • Embedded SRE: 開発チームに入って自ら手を動かす • SRE Center of Practice / Pure SRE: 中央集権的な基盤、コンサルティング 的な立ち位置 Embedded SRE ←→ SRE Center of Practice のゆり戻しに近い現象 Embeddedによってニーズを拾い、基盤に活かす 17
ポエムパート 兼任してみてどうだった? (Embedded的に)実際開発チームに行ってみて分かったこと • 小規模程度なら、開発チームはCI/CDをうまく作れる • CI/CDに詳しいことは専門性として発揮する機会がない • AWSに詳しくても、AWSのすべてのサービスに詳しいわけではない • 結局学習は必要 • アプリケーション寄りの部分では、複数チームで似たようなことをしている • プロダクト横断だとあまり開発基盤のアイデアがないけど、プロダクト内の複数 チームに対しては何か共通であると良さそう 18
まとめ • 生産性向上チームに新卒で入った人がプロダクトチームに行って実際にタスクを取っ てみたよ • CI/CD周りは当たり前のことをやると役立つことができた • 生産性向上をどう行うか?→Embedded or Platformの観点 • 実際開発チームにEmbedすることで体感できたことがあった 19