こんにちは、LIFULLでシニアエンジニア兼エンジニアマネージャーをしている渡邉です。普段はLIFULL HOME'Sの流通領域のエンジニアチームにて、マネジメントを担当しています。 最近のお気に入りはSupabaseです。
今回は、私たちが1年半にわたって磨き上げてきたGitHub完結型リリースフロー「Beezy」が、ついに弊社の一番メインのLIFULL HOME'Sシステム群に採用されたという大きなマイルストーンを迎えたことをご報告します。
- これまでの歩み
- 🐝 「Beezy」という名前に込めた想い
- なぜメインシステム群への採用が重要なのか
- Beezyが目指す3つの柱
- Beezyの主要機能
- 導入までの険しい道のり
- 1年半の成長の軌跡
- 導入を成功させた5つの要因
- 今後の展望
- まとめ
これまでの歩み
私たちのリリースフロー改革の取り組みは、これまでに2回ブログで紹介してきました。
1本目の記事では、リリースフローをGitHubに集約し、自動化を図った初期の取り組みについてお伝えしました。
2本目の記事では、その後の進化として、Chrome拡張機能の開発や自動リリース機能の実装など、さらなる改善について紹介しました。
そして今回、1年半のスモールスタートでの検証を経て、ついに弊社の一番メインのシステム群への採用が決定しました。
今回は導入までの行ってきたことを紹介させていただきます。
🐝 「Beezy」という名前に込めた想い
本格的な展開を前に、私たちはこのリリースフローシステムに「Beezy」という名前を付けました。
名前の由来
Beezy（ビージー）は、Bee（ハチ）とEasy（楽）を組み合わせた造語です。
なぜハチなのか
ハチは自然界で最も効率的で組織的な生き物の一つです。巣の中では、それぞれのハチが明確な役割を持ち、無駄のない動きで協働しています。女王蜂、働き蜂、それぞれが自分の責務を果たすことで、巣全体が機能します。
このリリースフローも同じです。エンジニア、CodeOwner、G長（グループ長。開発チームの責任者）、PJ承認者（プロジェクト単位でリリース可否を判断する役割で、主に企画担当者が担う）、リリーサー（本番環境へのデプロイを実行する担当者）、企画担当者、デザイナー。それぞれが自分の役割を果たし、GitHub上で一つの「巣」として機能します。 リポジトリごとにリリースに必要なactionsを適用していくことで、最終的に完璧なリリースパッケージが完成する。まさにハチの巣の構造そのものです。
また、ハチは「集約」の象徴でもあります。花から花粉を集め、一つの巣に集約し、蜂蜜という価値を生み出す。私たちも、JIRAやSlack、Googleスプレッドシートに散らばっていた情報をGitHubという一つの巣に集約し、価値創造を加速させる基盤を作りました。
なぜEasyなのか
このリリースフローの最大の成果は、「楽になった」ことです。
リードタイムが最大60%短縮されたという数字以上に、承認者やリリーサーの心理的負担が劇的に軽減されました。情報を探し回る手間、手作業でのチェック、見落としへの不安。これらがGitHub Actionsによる自動チェックで解消され、人間は本当に必要な判断だけに集中できるようになりました。
「Easy」は単なる「簡単」ではなく、「気楽に、安心して」リリースできる状態を意味しています。
Beezyが目指すもの
Beezyは、ハチのように効率的で組織的でありながら、誰もが気楽にリリースできる世界を目指しています。
将来的にはリリーサーすら不要になる完全自動化を見据えながらも、今この瞬間、チーム全員がリリースを「重荷」ではなく「日常」として扱えるようになること。それがBeezyの願いです。
Busy（忙しい）ではなく、Beezy（ハチのように効率的で楽）なリリースを。
なぜメインシステム群への採用が重要なのか
本質的な課題は「スケールの壁」
私たちがBeezyを開発した当初、まずは小規模なシステムでスモールスタートを切りました。これは正しい判断でした。新しいしくみを導入する際には、リスクを最小化しながら検証を重ねることが重要だからです。
しかし、本質的な課題は「メインシステム群でこそ顕在化する」ということを、私たちは理解していました。
- リリース頻度の高さ: メインシステムは日々多くの機能追加や改善が行われ、リリース頻度が圧倒的に高い
- 関係者の多さ: 開発者、企画担当者、デザイナー、リリーサーなど、多くのステークホルダーが関わる
- 承認プロセスの複雑さ: ビジネスへの影響が大きいため、承認プロセスも慎重にならざるを得ない
- 情報の分散: JIRAとGitHubを行き来する手間、Slackでの確認など、情報が分散している
つまり、メインシステム群でこそ、Beezyの真価が問われるのです。
Beezyが目指す3つの柱
Beezyの開発において、私たちが一貫して追求してきたのは以下の3つです。
1. 集約化：すべての情報をGitHubに
従来の課題:
- リリースチケットはJIRA
- コードレビューはGitHub
- 承認依頼はSlack
- リリース履歴は別のツール
情報が分散していると、承認者やリリーサーは必要な情報を探すだけで多くの時間を費やしてしまいます。
Beezyのアプローチ:
- リリースに関わるすべての情報をGitHubのPRとIssueに集約
- PR作成時に自動的に関連Issueが作成され、必要なタスクがすべて可視化
- リリースカンバン機能により、GitHub上で進捗管理が完結
- リリース履歴ダッシュボードで、過去のリリースも追跡可能
2. 自動化：人間の判断に頼らないしくみ
従来の課題:
- 承認者は手動でチェックリストを確認
- リリーサーは目視でリリース可否を判断
- リリース忘れは人間の記憶に依存
Beezyのアプローチ:
- GitHub Actionsによる自動チェック
- 必要な承認がそろっているかを自動検証
- リリース可能な条件を満たしたPRを自動検出
- リリース忘れを防ぐ自動通知システム
- 自動リリース機能により、条件が整い次第リリーサーの介入なしでリリース
3. 加速化：価値をより早くユーザーへ
従来の課題:
- リリースまでのリードタイムが長い
- 週2回程度のリリース頻度
- 承認からリリースまで数日かかることも
Beezyのアプローチ:
- リードタイム中央値を最大60%短縮
- 1日2回のリリースが可能に
- 承認からリリースまで数時間に短縮
Beezyの主要機能
Beezyは、30以上のGitHub Actionsで構成された包括的なリリースフローシステムです。主要な機能を紹介します。
承認フロー
LIFULLでは、本番環境へのリリース前に「G長承認（開発チーム責任者による技術的な承認）」と「PJ承認（企画担当者によるプロジェクト観点でのリリース可否判断）」という2段階の承認プロセスを設けています。これをGitHub上で完結させます。
G長承認・PJ承認のGitHub完結化:
- PRのコメントで
/G長承認OK、/PJ承認OKと書くだけで承認完了 - 適切な権限を持つ人のみが承認可能（GitHubチームで管理）
- Chrome拡張機能により、ボタン一つで承認コメントを投稿
自動承認スキップ:
- ドキュメントのみの変更など、プロダクトに影響のないファイルのみの変更は自動的に
skip-release-checkラベルを付与 .dockerignoreまたは.releasecheckignoreでスキップ対象を定義可能
Issue駆動開発
SubIssueによるタスク管理:
- PR作成時に、Epic IssueとSubIssueが自動生成
- 開発チェックシート、テスト仕様書、デザインチェックなど、必要なタスクを自動で分解
- SubIssueの完了状況がPR上に進捗バーとして表示
- すべてのSubIssueが完了すると、自動的に
subissue-closeラベルを付与
リリースチェック
ステージング確認・本番確認の自動化:
- リリースPR上でチェックボックスをクリックするだけで確認完了
- 確認忘れを防ぐ自動通知機能
- 定時実行により、未確認のリリースを検出してSlack通知
自動リリース
条件が整い次第、自動的にリリース:
- ステージング確認・本番確認が完了したPRを自動検出
- Googleカレンダーと連携してリリース可能日を判定
- 指定されたスケジュールで自動実行
- リリース依存関係のチェックにより、順序を守ったリリースを実現
リリース依存関係管理
マイクロサービス間の依存関係を自動制御:
- 設定ファイルで依存関係を定義
- 依存先のリリースが完了するまで、後続のリリースを自動的にブロック
- システム障害を防ぐための安全装置
Hotfixフロー
緊急リリースにも対応:
- 通常のリリースフローとは別の、簡略化されたHotfixフロー
- Hotfix後のreverse merge PR（本番ブランチからdevelopへのPR）は自動承認
- 緊急時の対応をスムーズに
自動バージョンアップ
メンテナンスの自動化:
- Beezyのバージョンアップ時に、自動的にPRを作成
- 各リポジトリでの手動更新作業が不要
- 常に最新の機能とバグフィックスを利用可能
導入までの険しい道のり
最初の壁：既存フローへの愛着と不安
メインシステム群への導入を提案した際、最初に直面したのは「既存フローへの愛着」と「新しいフローへの不安」でした。
既存フローの強み:
- 長年の運用で培われた安定性
- チーム全員が慣れ親しんだ手順
- JIRAを中心とした統一的な管理
- 問題発生時の対応パターンが確立されている
これらはけっして軽視できるものではありません。私たちは、この既存フローの良さを理解したうえで、Beezyを提案する必要がありました。
チームからの懸念:
- 「GitHubに移行して、本当に大丈夫なのか？」
- 「企画担当者やデザイナーがGitHubを使えるようになるのか？」
- 「今までのリリース履歴はどうなるのか？」
- 「リリースカンバンでの進捗管理はどうするのか？」
- 「移行期間中、二重運用になって逆に負荷が増えるのでは？」
これらの懸念は、すべて正当なものでした。そして、私たちはこれらの懸念に一つ一つ真摯に向き合う必要がありました。
第二の壁：既存運用を損なわないための工夫
Beezyの開発で最も時間をかけたのが、「既存の運用を損なわない」ための機能開発でした。
リリースカンバン機能の実装
既存の運用:
JIRAのカンバンボードで、リリース予定のチケットを管理し、進捗を可視化していました。これは、リリーサーや企画担当者にとって、リリース状況を一目で把握できる重要なツールでした。
Beezyでの実現:
- GitHub Projectsを活用したリリースカンバンの実装
- PRの状態に応じて自動的にカードが移動
- ラベルによる視覚的なステータス表示
- フィルタリング機能により、特定の条件のPRのみを表示
試行錯誤の過程:
最初は、GitHub Projectsの標準機能だけで実現しようとしましたが、既存のJIRAカンバンとの操作感の違いが大きく、ユーザーからの抵抗がありました。そこで、GitHub Actionsを使って、JIRAに近い操作感を実現するための自動化を追加しました。
リリース履歴ダッシュボードの作成
既存の運用:
過去のリリース履歴を追跡し、「いつ、何がリリースされたか」を確認できることは、障害発生時の原因特定や、機能のリリース時期の確認に不可欠でした。
Beezyでの実現:
- マージされたリリースPRの一覧表示
- リリース日時、リリース内容、担当者などの情報を集約
- 検索・フィルタリング機能
- 各リリースに含まれる変更の詳細へのリンク
試行錯誤の過程:
当初は、GitHubのリリース機能を使おうとしましたが、私たちの運用フローとは合いませんでした。そこで、GitHub APIを活用して、独自のダッシュボードを構築しました。これにより、既存の運用で必要だった情報をすべて提供できるようになりました。
JIRAとの連携維持
既存の運用:
すべてのプロジェクトがGitHubに移行できるわけではなく、一部のチームはJIRAでの管理を継続する必要がありました。
Beezyでの実現:
- JIRAチケットとGitHub PRの相互リンク
- JIRAチケットの状態をGitHub上でも確認可能
- 段階的な移行をサポート
これらの工夫により、「既存の運用を損なわない」という約束を守ることができました。
第三の壁：技術的な課題の山積
既存運用への配慮と並行して、技術的な課題にも取り組む必要がありました。
1. 複数リポジトリ間の依存関係
メインシステム群は、複数のマイクロサービスで構成されており、リリース順序に依存関係があります。
課題:
A→B→Cの順でリリースしなければならない場合、順序が逆転するとシステム障害につながります。
試行錯誤:
- 最初は手動でのチェックを考えましたが、それでは自動化の意味がない
- 次に、依存関係を設定ファイルに記述する方式を試しましたが、メンテナンスが煩雑
- 最終的に、リリースブロック機能（release_block）を実装し、依存先のリリースが完了するまで後続のリリースを自動的にブロックするしくみを構築
実装のポイント:
依存関係を設定ファイルで定義することで、自動的にリリース順序を制御できるようになりました。
2. 多様なリポジトリ形態への対応
メインシステム群には、モノリス、マイクロサービス、フロントエンド/バックエンド分離など、多様な構成のリポジトリが存在します。
課題:
すべてのリポジトリ形態で同じ操作感を実現する必要がある。
試行錯誤:
- 最初は個別にワークフローを作成していましたが、メンテナンス性が悪化
- 共通化を進めすぎると、柔軟性が失われる
- バランスを取るために、設定ファイルベースのアプローチを採用
実装のポイント:
release_actions.config.yamlという設定ファイルを導入し、リポジトリごとに必要な機能を選択できるようにしました。
workflows: # G長承認とPJ承認をGitHub上で行う - id: approval_on_github enabled: true # 自動リリース機能 - id: auto_release enabled: true # Issue駆動開発 - id: issue_driven_development enabled: true inputs: ORGANIZATION: lifull REPOSITORY: your-repository-name PRODUCTION_BRANCH: main # その他、リポジトリごとの設定
この設定ファイルを用意した後、renovate_actionsワークフローを実行することで、必要なワークフローファイルが自動生成されます。これにより、導入の手間を大幅に削減できました。
3. 導入方法の簡略化
課題:
当初、対話形式のCLIツールを開発しましたが、以下の問題が発生しました：
- ローカル環境でのセットアップが必要
- Node.jsのバージョン依存
- チーム全員が同じ手順を踏む必要がある
試行錯誤:
CLIツールは便利でしたが、導入のハードルが高いという問題がありました。そこで、より簡単な方法を模索しました。
最終的な解決策:
release_actions.config.yamlとrenovate_actionsワークフローを組み合わせた方式に変更しました。
導入手順:
- テンプレートから
release_actions.config.yamlとrelease_actions_renovate_actions.yamlをコピー release_actions.config.yamlを編集して、必要な機能を有効化- GitHubのActions画面から
renovate_actionsワークフローを手動実行 - 自動的にPRが作成され、必要なワークフローファイルがすべて生成される
この方式により、ローカル環境のセットアップが不要になり、導入のハードルが大幅に下がりました。
4. パフォーマンスの最適化
メインシステム群では、1日に数十件のPRが作成されることもあります。
課題:
GitHub Actionsの実行回数が増えると、コストとパフォーマンスの問題が発生します。
試行錯誤:
- 不要なワークフローの実行を減らすためのフィルタリング
- キャッシュの活用
- 並列実行の最適化
実装のポイント:
変更されたファイルに応じてワークフローをスキップするしくみを導入しました。これにより、ドキュメントのみの変更では、重いチェック処理をスキップできるようになりました。
第四の壁：組織的な合意形成
技術的な課題以上に難しかったのが、組織的な合意形成でした。
ステークホルダーの多様性
- 開発者: 新しいツールへの学習コスト、既存の開発フローの変更
- 企画担当者: GitHubアカウントの作成、新しい承認フローへの適応
- リリーサー: 役割の変化への不安、新しいツールの習得
- マネジメント層: 移行リスクへの懸念、投資対効果の検証
合意形成のプロセス
1. 小規模チームでの実証（3ヵ月）:
- 協力的なチームで実証実験を実施
- 週次で振り返りを行い、問題点を洗い出し
- フィードバックをもとに機能改善
2. 成果の可視化（6ヵ月）:
- リードタイムやリリース頻度の改善を数値で示す
- 開発者、企画担当者、リリーサーそれぞれの声を収集
- 定量的・定性的な成果をレポートにまとめる
3. 段階的な展開計画の策定（3ヵ月）:
- 一気に移行するのではなく、段階的な計画を提示
- リスクの高いシステムは後回しにする
- 移行期間中のサポート体制を明確化
4. 充実したサポート体制の構築（継続）:
- 詳細なドキュメントの整備
- ハンズオンセッションの定期開催
- Slackチャンネル(リリースフローに関するすべての窓口)でのリアルタイムサポート
- Chrome拡張機能による操作の簡略化
特に重要だったのは、「既存の運用を尊重する」という姿勢を明確に示すことでした。リリースカンバンやリリース履歴ダッシュボードの実装は、この姿勢を具体的な形で示すものでした。
1年半の成長の軌跡
Beezyの開発は、決して一直線ではありませんでした。多くの失敗と学びを経て、現在の形にいたっています。
フェーズ1：言語化とシステム化（最初の3ヵ月）
目標: 現在のリリースフローの構成要素を言語化し、システム化する
取り組み:
このフェーズでは、とにかく既存のリリースフローを徹底的に分解し、理解することに注力しました。
- 既存のリリースフローの各ステップを洗い出し
- それぞれのステップの目的と必要性を言語化
- 一つのリポジトリを対象に、大量のワークフローを作成
- 少しずつ検証を進めながら、システム化の可能性を探る
直面した課題:
- 暗黙知として存在していたルールの発見
- 「なぜこの手順が必要なのか」を理解すること
- GitHub Actionsでどこまで実現できるかの見極め
- ワークフローの数が増えすぎて管理が煩雑に
学んだこと:
- リリースフローは想像以上に複雑で、多くの暗黙知が存在する
- すべてを一度に自動化しようとすると失敗する
- 小さく検証を重ねることの重要性
- ワークフローの整理と構造化の必要性
この3ヵ月は、地味で泥臭い作業の連続でした。しかし、この期間に得た理解が、その後の開発の基盤となりました。
フェーズ2：流通チームでの実証と汎用化（次の3ヵ月）
目標: 実際のチームで使ってもらい、汎用化する
取り組み:
私の所属する流通チームの企画担当者とエンジニアに説明し、マイクロサービスの1リポジトリで導入させてもらうことを握りました。
- 流通チームの企画担当者とエンジニアへの説明会を実施
- マイクロサービスの1リポジトリで導入
- 実際に使ってもらいながら、フィードバックを収集
- 機能開発とユーザビリティ改善を並行して実施
汎用化への挑戦:
このタイミングで、ほかの流通リポジトリにも導入するつもりだったので、まずは今の1リポジトリに作ったワークフローをcomposite actionsとして汎用化することに全力を尽くしました。
- 個別のワークフローをcomposite actionsに分解
- 共通部分と個別部分を明確に分離
- 設定ファイルによるカスタマイズのしくみを構築
- composite actions用の専用リポジトリを作成し、移設
この専用リポジトリの作成が、後の展開において非常に重要な役割を果たすことになります。
他の流通リポジトリへの展開:
汎用化ができ次第、ほかの流通リポジトリでも検証を開始し、効果を検証しました。
直面した課題:
- 企画担当者のGitHub習熟度のばらつき
- リポジトリごとの微妙な運用の違い
- composite actionsの設計の難しさ
- ドキュメントの不足
学んだこと:
- 実際のユーザーからのフィードバックの価値は計りしれない
- 汎用化は想像以上に難しい
- 「使いやすさ」は技術的な正しさとは別の次元
- ドキュメントとサポート体制の重要性
- 早い段階での汎用化とリポジトリ分離が、後の展開を容易にする
この期間で、Beezyは「動くもの」から「使えるもの」へと進化しました。
フェーズ3：流通チーム以外への展開（次の6ヵ月）
目標: 流通以外のチームでも使ってもらい、効果を確固たるものにする
取り組み:
機能改善も行いながら、マイクロサービスを運用しているほかのチームに、流通での結果をもとに導入の相談を持ちかけました。
- 流通チームでの成果をレポートにまとめる
- ほかのチームへのプレゼンテーションと導入相談
- 導入サポートを丁寧に実施
- 実際に使ってもらってアンケートを実施
- 改善の数字を確固たるものに
テストマーケティングの効果:
社内のさまざまなチームで先にテストマーケティングさせてもらっていたことが、後のメインリポジトリ導入において非常に大きな意味を持つことになります。
成果の可視化:
- リリース頻度の向上
- リードタイムの短縮
- リリーサーの作業時間の削減
- 開発者、企画担当者、リリーサーそれぞれの満足度
直面した課題:
- チームごとの運用の違いへの対応
- 「流通でうまくいったから」だけでは説得力が不足
- 導入サポートの負荷
- 機能改善と導入サポートの両立
学んだこと:
- 数字で示すことの重要性
- 定量的な成果だけでなく、定性的な声も重要
- 導入サポートは想像以上に時間がかかる
- 異なるチームでの成功事例が説得力を生む
- 複数のマーケットでの実績が、組織全体への認知度を高める
この期間で、Beezyは「流通チームのツール」から「複数チームで使えるツール」へと進化しました。そして、メインシステム群への導入に向けた確信を得ることができました。
フェーズ4：メインシステム群への導入準備（次の6ヵ月）
目標: LIFULL HOME'Sのメインリポジトリ群への導入を実現する
取り組み:
いよいよLIFULL HOME'Sのメインリポジトリ群への導入相談と調整を開始しました。
組織的な調整:
- ものづくり全体への導入相談
- 予算の確保
- ステークホルダーとの合意形成
- 移行計画の策定
認知度の高さが後押し:
いろんなマーケットで先にテストマーケティングさせてもらっていたので、いざメインリポジトリに導入するとなった時にも、多くの関係者はBeezyについて知ってくれていました。これは非常に大きなアドバンテージでした。
- 「あのリリースフローのことね」という認識がすでにあった
- 成功事例を知っている人が多かった
- 「使ったことがある」という人が組織内に点在していた
- 新しいツールへの抵抗感が大幅に軽減された
課題解決への注力:
とにかく課題解決に時間を費やして粛々と準備を進めました。
- リリースカンバン機能の実装
- リリース履歴ダッシュボードの作成
- JIRAとの連携維持
- 複数リポジトリ間の依存関係管理
- パフォーマンスの最適化
運用上の問題への対策:
運用上の問題が発生しないように、ドキュメントの充実と告知もしっかり行いました。
- 詳細なドキュメントの整備
- 企画担当者向けガイドの作成
- ハンズオンセッションの実施
- Slackチャンネルでのサポート体制の構築
- Chrome拡張機能の開発
直面した課題:
- メインシステム群特有の複雑さ
- 既存フローへの愛着と新しいフローへの不安
- 多様なステークホルダーとの調整
- 移行リスクへの懸念
学んだこと:
- 大規模な変更には、技術以上に組織的な調整が重要
- 既存の運用を尊重する姿勢を示すことの重要性
- 丁寧な準備が成功の鍵
- 予算確保には明確な効果の提示が必要
- 事前の認知度が、導入のハードルを大きく下げる
この期間は、技術的な開発よりも、組織的な調整と準備に多くの時間を費やしました。しかし、この準備があったからこそ、スムーズな導入が実現できました。
フェーズ5：メインシステム群への導入完了（現在）
目標: メインシステム群への導入を完了させる
取り組み:
準備が整い、いよいよメインシステム群への導入を開始しました。
- 段階的な導入計画の実行
- リアルタイムでのサポート
- 問題発生時の迅速な対応
- 継続的なフィードバックの収集と改善
成果:
そして今、メインリポジトリへの導入が完了しました。
品質の向上:
- 人的ミスの完全排除
- リリース品質の安定化
直面した課題:
- 導入初期の混乱
- 予期しないエッジケース
- ユーザーの習慣を変えることの難しさ
学んだこと:
- 1年半の準備があっても、導入時には予期しない問題が発生する
- リアルタイムでのサポート体制の重要性
- 継続的な改善の必要性
- 成功は一つのマイルストーンであり、ゴールではない
導入を成功させた5つの要因
1年半の道のりを振り返ると、メインシステム群への導入を成功させた要因は、以下の5つだと考えています。
1. スモールスタートと段階的な展開
一気に大規模な変更を行うのではなく、小さく始めて段階的に展開したことが成功の鍵でした。
- 最初の3ヵ月: 1リポジトリでの検証
- 次の3ヵ月: 流通チーム内での展開
- 次の6ヵ月: 流通チーム以外への展開
- 次の6ヵ月: メインシステム群への導入準備
各段階で学びを得て、次の段階に活かすことができました。
2. 早い段階での汎用化とリポジトリ分離
フェーズ2の段階で、composite actions用の専用リポジトリを作成し、ワークフローを移設したことが、後の展開を大きく容易にしました。
メリット:
- 複数のリポジトリで同じアクションを使える
- バージョン管理が容易
- 機能追加や修正が一ヵ所で完結
- 導入リポジトリ側のメンテナンスコストが低い
この判断により、ほかのチームへの展開やメインシステム群への導入が、スムーズに進みました。
3. 複数マーケットでのテストマーケティング
いろんなマーケット（チーム）で先にテストマーケティングさせてもらっていたことが、メインリポジトリ導入において非常に大きな意味を持ちました。
効果:
- 組織内での認知度が高まった
- 「使ったことがある」という人が点在していた
- 成功事例を知っている人が多かった
- 新しいツールへの抵抗感が大幅に軽減された
いざメインリポジトリに導入するとなった時にも、多くの関係者はBeezyについて知ってくれていました。これは、説明コストを大幅に削減し、導入のハードルを下げる大きな要因となりました。
4. 既存の運用を尊重する姿勢
新しいシステムを導入する際、既存の運用を否定するのではなく、尊重する姿勢を貫きました。
- リリースカンバン機能の実装
- リリース履歴ダッシュボードの作成
- JIRAとの連携維持
これらの機能は、技術的には必須ではありませんでしたが、ユーザーの信頼を得るために不可欠でした。
5. 丁寧なサポート体制
技術的に優れたシステムでも、サポートがなければ使われません。
- 詳細なドキュメント
- 企画担当者向けガイド
- ハンズオンセッション
- Slackチャンネルでのリアルタイムサポート
- Chrome拡張機能
特に、企画担当者向けガイドとChrome拡張機能は、技術者以外のユーザーにとって大きな助けとなりました。
組織全体への波及効果
メインシステム群での成功は、組織全体に波及効果をもたらしています。
- ほかのチームへの展開: 成功事例を見たほかのチームからも導入希望が相次いでいる
- ベストプラクティスの共有: Slackチャンネルを通じた知見の共有
- 継続的な改善: ユーザーフィードバックをもとにした機能追加や改善
開発者の声
開発者からの声:
- 「ボタン一つで承認が終わるなんて！」
- 「タスクの進捗が自動で更新されるから楽」
- 「リリース忘れがなくなった」
- 「リリーサーを待つ必要がなくなった！」
企画担当者からの声:
- 「GitHubは難しいと思っていたけど、ガイドがあるから安心」
- 「Chrome拡張機能のおかげで、承認が簡単になった」
- 「リリース状況が一目で分かるようになった」
リリーサーからの声:
- 「定型作業から解放されて、より重要な仕事に集中できる」
- 「自動リリース機能のおかげで、リリース日の緊張感が減った」
- 「リリース履歴ダッシュボードで、過去のリリースも簡単に追跡できる」
今後の展望
さらなる進化に向けて
メインシステム群への採用は、ゴールではなくマイルストーンです。私たちは今後も、以下の方向性で進化を続けていきます。
1. より多くのチームへの展開:
- 全社的な展開
- グループ会社も含んだLIFULLグループ全体への導入
2. 機能の継続的な改善:
- ユーザーフィードバックをもとにした改善
- 新しい技術の導入
- パフォーマンスの最適化
3. Developer Experienceのさらなる向上:
- より直感的なUI/UX
- ドキュメントの充実
- サポート体制の強化
まとめ
1年半のスモールスタートを経て、ついにメインシステム群への採用を実現できたことは、私たちにとって大きな達成感をもたらしています。
しかし、それ以上に重要なのは、この取り組みを通じて得られた「組織の変化」です。
- 技術者が創造的な仕事に集中できる環境
- 心理的安全性の向上
- チームの幸福度の向上
これらは、単なる効率化では得られない、本質的な価値です。
私たちは「価値創造を加速させ続ける」ことをビジョンの一部に掲げています。今回のメインシステム群への採用は、そのビジョンに向けた大きな一歩だと確信しています。
「仕方がない」と思っているポイントこそ、変化の余地があるかもしれません。開発フローにおけるそれぞれの構成要素をあらためて見直し、最低要件を確認してみることで思わぬ改善の糸口が見つかる可能性があります。
今後も一歩ずつ改善を積み上げることで、リリースのさらなる加速化につなげていければと思います。
最後に、LIFULL ではともに挑戦し成長していける仲間を募集しています。よろしければこちらのページもご覧ください。
