新卒1年目がゼロから始めたDevOps
2017年創業で、LINE公式アカウントを使ったマーケティングや顧客管理を支援する「Liny」を開発・提供しているソーシャルデータバンク。従業員数63名のうち、エンジニアは約40%。機能開発10名（2チーム）・運用保守15名（2チーム）の体制である。
島田氏がDevOpsに取り組むきっかけは、入社して半年後のある日、「おもしろそうだから、やってみない？」と部長から声をかけられたことだった。「ピクスタ株式会社さんが技術顧問の@t_wadaさんと配信しているポッドキャスト『texta.fm』の話で部長と会話が盛り上がった。その中で紹介されていた書籍『LeanとDevOpsの科学』を読んで、DevOpsに興味はあった。当時、サービス規模が拡大している最中で、リードエンジニアが忙しく、私のような新人に白羽の矢が立った」と島田氏は振り返る。
DevOpsを始めるにあたり、島田氏は理想と現状のギャップを知るところから始めることにした。理想を明確にするために参考にしたのが、「DORA（DevOps Research and Assessment）」である。DORAは開発組織の「能力とパフォーマンスの関係」を明らかにするのを目的とした研究プログラムであり、Four Keysを提唱したことでも知られている。
Four Keysとは、ソフトウェア開発組織のパフォーマンスを示す4つの指標（デプロイ指標・リードタイム・平均修復時間・変更失敗率）のこと。DORAで示されたハイパフォーマンスな組織が持つ指標を、ソーシャルデータバンクが目指す理想に置くことにした。
次は、現状のパフォーマンスを知る必要がある。Four Keysのすべてを計測するのは大変なため、チームごとにプルリクエスト（以下、PR）のリードタイムを集計するダッシュボードを作成した。その結果、現状のリードタイムは1週間〜1カ月であることが判明。つまり、現状はDORAでいうミドルパフォーマンスの組織であり、ハイパフォーマンスな組織になるには、リードタイムを1日〜1週間に短縮する必要がある。
そこで島田氏は、「我々のパフォーマンスは真ん中くらいなので、まずはリードタイム1週間を目指して、PRを小さくするなど、各チームで改善をお願いします！」と呼びかけた。
しかし、これが失敗だった。「そんなことして何の意味があるの？」と、まったく賛同を得られなかったのだ。
「正直、心が折れかけた」と、島田氏は当時を振り返る。
「DevOpsはまず人」失敗から学んだ推進の糸口
島田氏の進め方のどこが悪かったのだろうか。その答えは書籍『システム運用アンチパターン』の中にあった。同書には「DevOpsはまず人、次にプロセス、そしてその次にようやくツールについて考えるのです」と書いてある。つまり、本当ならまずはチーム（人）について考えて、リードタイムの短縮に価値を見出してもらうところから始めなければならなかった。しかし島田氏は、いきなりダッシュボードというツールを渡すことから始めてしまっていたのだ。これが、失敗の原因だった。
方針転換の必要に迫られた島田氏は、『LeanとDevOpsの科学』に立ち返る。するとそこには、「チームの文化を変えるには、チームの考え方から変えるのではなく、チームの言動から変えるべきだ」と書かれていた。言動を変えるとは、DevOpsを実践することに他ならない。DevOpsのプラクティスを実践して、自らその良さを体感してもらうことが、何よりも大切だと理解した。
「自分の役割は、チームがDevOpsを実践するきっかけづくりをすることだ」と考えた島田氏は、実践可能なプラクティスとしてWIP制限に目をつけた。CI/CDや自動テストといった主要なプラクティスは、すでに整備済みだったからである。
WIP制限とは、「同時に進行する作業数（＝Work In Process）を減らして、チームの作業負荷を適切にコントロールすることで、生産性を高めよう」という手法であり、トヨタのカンバン方式などでも採用されている。
開発においてWIPは、PRに置き換えることができる。WIP制限では「1人あたりのタスク数は1〜2個であるべき」とされているのに対し、当時のソーシャルデータバンクでは、1人あたり10件以上のPRを持っていた。明らかに過剰である。
PRが多いと、コンフリクトが頻発して、調整ごとが増えてしまったり、作業を切り替えるたびに、思い出すための時間が必要になったりする。たとえ一つひとつにかかる時間が5〜10分だったとしても、その積み重ねによって全体の生産性が下がってしまう懸念があった。
ちなみに、なぜこんなにPRが多いのかというと、「『あったらいいな』をつくる」というソーシャルデータバンクのボトムアップな組織文化があるからだ。この組織文化は、「エンジニアが自由で主体性を持って仕事ができる」という良い面がある一方、「勢いで作り始めたものを着地できずに、そのまま放置しがち」という悪い面もある。結果、WIP数が増え、並行作業が増え、認知負荷が高い状態に陥っていた。
WIP制限の下地を整えるべく、島田氏は100件以上あったPRを精査していった。そして問題のあるPRは「開発自体は進んでいるが、何カ月も開発中のPR」と「放置されてコンフリクトまみれになったPR」の2種類に分類できると気づいた。
「放置されているならそのままでよいと思うかもしれないが、たまに『このPR、何で止まってるんだっけ？』と話題になることもある。頭の片隅に残っているだけで多少の認知負荷につながるため、解消したかった」（島田氏）
問題のある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ツールとの連携にも対応しています。お問い合わせはこちらから。
