「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、何で止まってるんだっけ？』と話題になることもある。頭の片隅に残っているだけで多少の認知負荷につながるため、解消したかった」（島田氏）
