トランクベース開発の導入で見えた DevOpsの技術・プロセス・文化との繋がり DevOpsDaysTokyo 2024 @92thunder 2024/4/16

国定 凌太 @92thunder テックタッチ株式会社のフロントエンドエンジニアとして 全てのWebシステムの価値を向上するサービスを開発 津山高専（岡山県） → ソニーデジタルネットワークアプリケーションズ → テックタッチ株式会社（当時創業1ヶ月に1人目社員として） 2023年6月に北海道旭川市に移住

「テックタッチ」の紹介 ● WebサイトにJavaScriptを組み込むことで、 ノーコードでガイドやツールチップでの案内を追加できる ● スニペット / ブラウザ拡張で提供

トランクベース開発導入に 取り組んでDevOpsの 魅力に気付いた話をします

最初は “DevOps” 調べてもピンと 来なかった人 🙋

DevOpsとの出会い > DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協 力する（さらに両担当者の境目もあいまいにする）開発手法をさす。ソフトウェアを迅速に ビルドおよびテストする文化と環境により、確実なリリースを、以前よりも迅速に高い頻 度で可能とする組織体制の構築を目指している。 https://ja.wikipedia.org/wiki/DevOps 開発者が運用まで担当して開発ちゃんと進むの？ DevOps＝CI/CD？　継続的デリバリーのその後は？ 🤔

トランクベース開発の導入に取り組んで ● リリーストグルが無ければ ○ 開発中の機能が他チームの開発に影響を与えてしまう ● 小さいバッチサイズの作業が無ければ ○ リリーストグルが活用されず プルリクエストあたりの変更量が大きくなる ● 明確なビジョンと目的が無ければ ○ 納得感が得られず、変革への動機付けができない

トランクベース開発の導入に取り組んで ● リリーストグルが無ければ ○ 開発中の機能が他チームの開発に影響を与えてしまう ● 小さいバッチサイズの作業が無ければ ○ リリーストグルが活用されず プルリクエストあたりの変更量が大きくなる ● 明確なビジョンと目的が無ければ ○ 納得感が得られず、変革への動機付けができない 技術　　　 プロセス　 文化　　　 技術・プロセス・文化が揃ってやっと導入できた

トランクベース開発とは ● 1日に1度は本流の開発ブランチ（トランク）にマージする ● 毎日マージしながら機能開発を進めることで 早期に課題発見やフィードバックを得ることができる ● 短期間でマージすることで、コンフリクトが発生しにくくなる ● 燃え尽き症候群（バーンアウト）を軽減する効果がある 技術

なぜトランクベース開発を導入したのか リードタイム短縮 ● フロントエンドの機能開発プルリクエストがマージされるまでに2ヶ月以上 ○ エピックに関する変更が全て入らないとマージできない ○ マージ前にQAエンジニアによる手動テストを実施する必要あり ウェルビーイング ● 毎日変更をマージすることで、燃え尽き症候群を防ぐ ○ 自分が1人目社員というのもあり、他のメンバーにも早くマージする 開発リズムの良さを実感してほしい！ 技術

リリーストグル実装 開発途中の機能が他チームの開発・テストに影響 機能開発チームを1ヶ月離れ、 リリーストグルの設計・実装・ドキュメント整備を実施 リリーストグルを導入することで、開発途中の機能を Dev環境まで表示するか、本番でも表示するか柔軟に変更可能に 技術

ドキュメント抜粋 技術

技術 ドキュメント抜粋 導入の速さを考慮して機能の利用可否フラグを コード内に設定する静的リリーストグルを選択 背景 ● ネットワーク障害などの影響を受けない ● 新機能は3ヶ月に1度リリースの新バージョンで リリースしている ● 顧客ごとに機能の提供を切り替える機構は既に導入済み

タスク細分化ワークショップの実施 リリーストグルがあっても使われない状況が続く😢 タスクの粒度に課題があることに気付く 機能開発の全3チームにタスク細分化ワークショップを実施 作業量の少ないストーリーやタスクのチケットが増えた 全体でイテレーティブ開発的な進め方も浸透してきた プロセス

タスク細分化ワークショップの進め方 1. UIデザインを見てどのような機能を作るのか確認 一番重要な機能はどこ？ 2. 思いつく限りタスクを箇条書きで書き出してみる 型定義やリリーストグル追加などとにかく小さいもので󰢏 3. INVESTの法則を参考にストーリーとしてグルーピング 特に独立やテスト可能の意識 4. ストーリーを優先度順に並び替え 何が揃っていれば最低限の実装で一通りの価値を検証できる？ 5. ストーリーに更に細かくサブタスクを書き出してみる チケット作成する時もこの粒度を意識してみよう プロセス

全体でプルリクエストの数が増えてきた…！ ● 1日1回マージには届かないが、週にいくつかの機能開発プルリクエストが マージされるようになった！ ● ポジティブな意見 ○ プルリクエストあたりの変更が少なくなったので コードレビューが楽に ○ はやくマージできるようになってタスクが完了 →ストーリーポイントが安定 ○ プレビュー環境ではなくDev環境でテストできるためテストがスムーズに ○ 社内での早期フィードバックが生まれ改善が早くなった！ ● ネガティブな意見 ○ 他チームの変更を把握しきれず、別チームでのテスト時に 正しい挙動が把握しきれないなど、個人的には嬉しい悲鳴

トランクベース開発は順調に見えていたが… 文化 Four Keys改善ワーキングチームというチームを結成 まずはサイクルタイム改善を目指して取り組む メンバーからの反発の声を耳にする 「なぜリードタイムやサイクルタイムの短縮に注力してるの？ 　チーム体制や密結合アーキテクチャなど 　向き合うべき課題があるのでは？」 数値の改善やコードレビューを早くすることばかりに注力していて その背景にある目的の納得感が得られていなかった

Four Keys改善チームの見直しを実施中 チーム名： Four Keys改善 目的： Four Keysを改善し、アジリティ高くリーンな 　　　　　 開発を実践できる開発組織になる 活動内容： リードタイム短縮のためにトランクベース開発 導入支援、レビュープロセスの改善 チーム名： 開発プロセス改善 目的： フィードバックサイクル全体を改善し、 顧客により多くの価値を届けられるようになる 活動内容： 開発プロセス全体の現状整理と課題発見、 　 DevOpsケイパビリティの獲得支援 文化

今までの取り組みとDevOpsの能力の関係 文化 ● 創造的な組織文化 ● 仕事の満足度 ● 学習文化 ● 変革型リーダーシップ 技術 ● クラウド インフラストラクチャ ● コードの保守性 ● 継続的デリバリー ● 継続的インテグレーション ● 継続的なテスト ● データベースのチェンジ マネジメント ● デプロイの自動化 ● チームのツール選択をサポート ● 疎結合アーキテクチャ ● モニタリングとオブザーバビリティ ● セキュリティのシフトレフト ● テストデータ管理 ● トランクベース開発 ● バージョン管理 プロセス ● お客様のフィードバック ● システムをモニタリングして的確な判断 ● 障害の予兆通知 ● 変更承認の効率化 ● チームのテスト ● バリュー ストリームでの作業の可視性 ● ビジュアル管理 ● 仕掛り制限 ● 小さいバッチ単位の作業 https://cloud.google.com/architecture/devops?hl=ja

トランクベース開発を導入するまでの取り組み プロセス タスク分割 文化 変革型リーダーシップ リリーストグル トランクベース開発 技術 DevOps

私にとって “DevOps” とは 試行錯誤しながらトランクベース開発導入を経験して 技術・プロセス・文化によるアプローチが必要だとわかった 技術・プロセス・文化はソフトウェア開発の全てではないでしょうか？ ソフトウェア開発の一挙手一投足がDevOpsに繋がっている 身近な取り組みからDevOpsを実践していきましょう！