問題のあるPRを地道に削減、文化の醸成は泥臭く
問題のあるPRを島田氏はどのように減らしていったのか。問題のあるPRのうち、まず「開発自体は進んでいるが、何カ月も開発中のPR」から見ていく。当時の機能開発の流れは、よくあるフィーチャーブランチ運用だ。この運用方法では、フィーチャーブランチの生存期間が長い（3〜6カ月）という問題があった。この間、都度コンフリクトを解消したり、ライブラリのアップデートに対応したりと、常にメインブランチに追従し続けなければならない。
そこでリリーストグル（フィーチャーフラグ）を導入することにした。リリーストグルによって、コードのデプロイと機能のリリースを分離でき、開発中のコードもメインブランチにマージすることができる。結果、PRの生存期間が短くなり、コンフリクトの発生数が減少。副次的な効果として、本番環境で動かせるので環境起因のバグに気付けたり、関係者にβ版を開放してフィードバックをもらったりできるようにもなった。
もうひとつの課題である「放置されてコンフリクトまみれになったPR」はどうか。泥臭くシンプルに、PRを古い順に並べて、作った人と一緒にその場で閉じていった。入れられるものはマージして、練り直す必要があるものはクローズしてタスクに戻したのだ。これを10回ほど繰り返したところ、3カ月かけてPRを40件にまで減らすことができた。
放置されていたPRを閉じたことで、リードエンジニアがすべてのPRに目を通せるようになり、技術的に考慮が必要な箇所を早い段階で指摘できるようにもなった。その結果、開発中の大きな手戻りが減るという効果を得られたという。
PRの削減を通じてDevOpsを実践したことで、「組織文化の変化」「定量指標の変化」「顧客や社内からの反応の変化」という3つの変化が生まれた。
組織文化の変化
- 新機能開発時、「まずはフィーチャーブランチを切っていた」ところから、「まずはリリーストグルを作る」ように
- 「PRのサイズが大きくなってしまうのは仕方がない」という価値観だったところから、「PRのサイズは小さくするのが当たり前」という価値観に
- 放置されたPRは今まで「誰も気にしなかった」ところから、「チームで毎日確認」するように
定量指標の変化
- マージ済みのPR数（1人あたり）：DevOpsを始める前は4.3件、2年後の同時期は40.9件と約10倍になった
- リードタイム：DevOpsを始める前は7週間（622.6h）、2年後の同時期は3週間（375.9h）と半分以下に
顧客や社内からの反応の変化
- 社内：対応スピードの改善を実感
- 顧客：「嬉しい改善」「アップデート助かる！」など喜びの声
最後に島田氏は、「今回紹介した以外にも技術的な解決策は講じてきたが、改善の効果を発揮するためには文化があってこそ。文化をつくるには泥臭い解決法も必要だと感じた。そして、やはり組織にDevOpsを根付かせるには、考え方ではなく言動から変えることが重要であり、チームがプラクティスを実践するためのきっかけづくりが大切だ。DevOpsを定着させるのは大変だが、その価値はある。ぜひあきらめないで挑戦してほしい」と語り、セッションを締め括った。
Linyは、LINE公式アカウントの配信・運用・管理をサポートするツールです
顧客とのやりとりの中で、好みの属性を自動で収集・管理することができ、集めた顧客情報をもとに、一人ひとりの嗜好に合わせた情報だけを配信できるので反応率・売上のUPにつながり、運用負担も軽減します。また、LINE公式アカウントと、CRMやMAツールとの連携にも対応しています。お問い合わせはこちらから。
