デプロイ頻度の改善は難しいが……。はてなブックマークWebチームの生産性向上事例
ここで佐藤氏から「はてなブックマークWebチーム」の事例が紹介された。はてなブックマークでは、リアルタイム通知やランダムレビュー導入によりレビューまでのスピードが2倍になったり、計画作業に力を入れ、チームでの認識を揃えたことでプルリク作成数が約2倍になったり、とさまざまな成果が得られている。
そもそも取り組みをはじめたきっかけは、サービス成長を実現するために、デプロイ頻度の向上が大事という認識を持ったことにあるという。とはいえ、デプロイ頻度は可視化・改善は難しいことから、先行指標であるプルリク作成数を倍増を目指し、そのためにプルリク毎のリードタイムの低減に取り組んだ。
具体的には、ランダムアサインとリアルタイムな通知設定することで、レビューまでの時間を短縮し、偏りを解消した。そして、スクラムを実施することで、各メンバーのタスク状況を把握し、ゴール達成のための透明化・検査・適応がかなったことがある。さらにタスクの計画作業に力を入れた結果、プルリクエストの粒度が小さくなり、タスク完了時間が最小化したことなどがある。
その結果、レビューまでのスピードとプルリク作成数が約2倍になり、エンジニア組織としての変化も現れた。例えば、タスクの最小化を進めることでフロー効率が向上したことや、レビューの偏りが解消され、レビューまでのスピードが2倍になったことなどがあげられる。実際、一人ひとりの生産性についても、アクティビティの推移を見ても約4か月前とは段違いに向上している。
プルリク作成数も2月の9件から6月は16.6件と倍近くになり、プルリク作成からレビューまでの平均時間が24.1時間だったのが12.8時間まで短縮された。またレビュワーもランダムにすることで、1人に負荷が偏ってボトルネックになっていたのが解消されたことがわかる。こうした数値は、すべて「Findy Teams」で把握・可視化できるものであり、当然ながら他部署ややマネジメント層とも共有できる。
広木氏は「エンジニア組織が改善努力をした結果、生産性が上がったとしてもなかなか数値化・可視化できず、周知することが難しい。こうした可視化ツールがあることで成果が可視化され、社内的に認知されるのはよいこと」とコメントした。
さらにその内容について、「プルリクの粒度を小さくすることで数を多くこなせるようになっただけとも思われたが、実際によく見るとリードタイムが半分になっている。プルリクが小さくなったことで、レビューが簡単になり、スムーズに解決できるようになったということは、安心安全なコードが増えていることでもあり、細かく検証されることでバグもなくなり、品質向上につながったのではないかと想像できる」と話した。
グロービスが作り上げた、コードの修正に対する心理的安全性
2つ目の事例として、グロービスの取り組みが紹介された。取り組みの背景としては、エンジニアが5倍になったものの、デプロイは週1回と決まっていたため、1回につき300行以上の変更が入ることもあった。長期の休み明けには”ビッグバンリリース”が横行するようになり、精神的負荷も高かった。その中で、エンジニアが自分で開発している製品であるにも関わらず、好きなタイミングでデプロイできないことで「コントロール感がなくなる感覚がある」という声があり、デプロイ頻度は上げた方が開発リスクの軽減につながると判断した。
具体的な取り組みとしては、設計方針から”モブプロ”をすること、そしてレビューを最優先にすることにより、フロー効率が改善されたという。また、RSpecを整備したことで、フェーズゲートQAなしで、プルリクがマージされたらデプロイされる環境を整えた。他にも、「デプロイ頻度（d/d/d）を計測して健全な数値になっていないことを確認する」「まずは自身のチームにてデプロイ頻度を上げるメリットを共有して文化を変える」などにも取り組んだ。特に文化の醸成については、開発における手戻りがチームの課題になっていたため、「リードタイムを短く」「プルリクは小さく」「頻繁にデプロイすること」でフィードバックループを短くする重要性をさまざまな角度から、さまざまな人が伝え続けたことが課題の解決につながった。
佐藤氏は「デプロイ頻度が適切になり、リードタイムも計測していくことで、より早い開発がかなう組織にしていった。1チームから変化を起こすことで、変化が伝播していった」と分析した。
実際、数値としても、今年1〜3月と4〜6月では明らかにアクティビティが約2倍になっていることが伺える。メインブランチへのマージ回数は11.7件が29.5件に2倍以上増え、プルリク作成からレビューまでの平均時間が72.7時間から26.3時間へと大幅に削減できていることがグラフから読み取れる。
さらにメインブランチへのマージ回数も右肩上がりになっており、開発者1人あたりのデプロイ頻度も健全な値で安定して推移している。
広木氏は「BtoBのサービスなどで、最初から完璧にしなくてはという思いから人間による入念なチェックが必要になり、結果としてデプロイ頻度が下がるということがある。逆に頻度が高くても、自動テストなどを信頼できるようになり、リリースできるようになれば、ソースコードの修正に対する心理的安全性が担保される。そうした経験がない人だと、ちゃんと計画して検査してもらわないとデプロイできないとなれば、胃が痛むような気になるのも当然。それではエンジニアとしての面白さを損ねることになる」と話した。
それはいわば「エンジニアのコントロール感」にもつながる部分であり、ソフトウェアの継続的デリバリーや継続的インテグレーションに対する投資は、その組織への帰属意識が高いほど、より増える傾向にあるといわれている。修正に心理的コストを払わなくてもデプロイできる環境ができるのは重要。それがかなえば、例えば小さなリファクタリングとして気になった部分を修正しようという、いわば「ボーイスカウト・ルール」のような文化ができていく。しかし、心理的安全性がないチームだと抵抗を受けることがある。
こうしたデプロイ頻度とその向上のための投資について、広木氏は、「ドラム式洗濯機に対して『1週間に1回しか洗濯しないのだから、高い洗濯機はいらない』と言っているようなもの」と表現。実際にドラム式洗濯機を導入すると、毎日快適に洗濯・乾燥されるため、毎日洗濯するようになる。つまりは習慣が変わるというわけだ。
広木氏は「同じように、自動テストなどデプロイ頻度を上げる投資をすると、頻度の感覚が変わってデプロイが頻繁になり、それが質の向上へとつながっていく。頻度によって品質がつくられ、心理的安全性が高まり、結果的にソフトウェアの質が上がり、修正速度も上がり、生産性も上がる。いい連鎖につながっていく。その部分に注目して取り組んでいくことはとても重要」と話した。
「自分達の生産性が数値化される恐怖心」を乗り越えて
佐藤氏は、改めて「開発生産性を向上させるのはゴールでなく手法」と強調し、ユーザーの価値提供や事業を伸ばすための「一つの手段」として開発生産性を向上させようという。そして、そのためには可視化・数値化が重要であり、「プルリク作成数やリードタイム、デプロイ頻度・回数など」について可視化することを提案した。
広木氏からは「数値化がいいなと思っても、なかなか積極的に手が動きにくい理由の一つは、自分たちの生産性を測定されてしまうという恐怖心があると思う」と語り、「しかしながらちょっとやってみると、例えばテストの回数が増えて品質の安全性につながったり、ブランチ滞在時間が減ってコンフリクトが減ったりして、いろいろと変化が現れ、それが結構本質的な変化であることも少なくない。まずはそのきっかけとして、測ってみることをお薦めする」と話した。
そして、最後にそうした「測定・解析」が可能なファインディの「Findy Teams」が紹介された。GitHubなどのデータを活用した可視化によって、エンジニア組織の開発者体験向上を目指すサービス課題を可視化できるというものだ。佐藤氏は「可視化が有効な指標などについてはブログでも紹介しているので見てほしい」と語り、セッションを終えた。
