開発生産性が高い組織の特徴と、開発者が「自ら体重計に乗る」意義
まず、冒頭で佐藤氏は、開発生産性の向上はゴールではなく、ユーザーの価値提供や事業を伸ばすための「一つの手段」であることを強調した。そして、生産性向上のためには他職能との連携・協力なども必須ながら、今回は「開発時のボトルネックの解消」にフォーカスし、特にデリバリーのパフォーマンスが組織全体のパフォーマンスに影響を及ぼすと話した。
例えば、リードタイムやデプロイ頻度、平均修復時間、変更失敗率などが改善されると、収益性や市場占有率、生産性などが向上してくる。そこで、開発に関連する行動、例えばデプロイ頻度やリードタイム、プルリク作成数、デプロイ回数などを定量化することを今回のセッションのゴールイメージとして提案した。なお、ファインディの場合1日あたりプルリク作成数は3件ほどだという。そうした数値を把握している組織がどのくらいあるだろうか。
「開発生産性が高い組織の特徴」として、佐藤氏は「①数値化のマインド」があり、「②PDCAで改善」していること。それを「③組織全体で取り組んでいる」ことの3つをあげた。
まず「①数値化のマインド」については、全員が数値の意識を持っていることが重要だという。サーバーのパフォーマンスを見る際にもCPUやメモリなどメトリクスを可視化しているように、まずは現状を定量的に把握することが大事。そのうえで、他社の開発生産性向上の事例に学び、自社組織に合う形で活かせることが望ましい。そして、全員に数値への意識を持ってもらうことが重要だ。
そして「②PDCAで改善」とは、①で得られた数値をベースに議論し、改善し、効果測定を行なうことだ。定量的な議論は具体的な改善施策につながりやすい。そして、効果が可視化されるメリットとしては、チームのモチベーションがアップすること、施策とその結果を他チームへの横展開を行なうことで組織全体がよりよく進化できることがある。
「③組織全体でプロセス改善に取り組んでいる」については、開発組織はもちろん、企画やデザインなど、あらゆるも部門の全員がプロセス改善している状態にあることだ。とはいえ、企画などはコントロールしにくく、他のプロセスも業務によっては難しい。そのため改善の第一歩は開発から、それもコーディングプロセスからはじめるのがよいという。佐藤氏は「開発プロセスのボトルネックが解消されたところで、開発組織外の改善を進めるというのが現実的」と話した。
佐藤氏があげる「開発生産性の高い組織の特徴」を受けて、広木氏は「自分たち自身のことでなければ、開発の人は『パフォーマンスを測定するのは当然』『具体的な指標があって当たり前』とするのに、こと自分たちのパフォーマンスについては『気持ちよく仕事ができた』など、定性的なところで終わってしまいがち」と言い、「自分たちの現状を把握してこそ、改善策を考えることができるが、自分たちが”体重計”に乗るということをストレスに感じる人は少なくない。しかし、そうしたプレッシャーはありながらも、自分たちのアクションについて数値化し、議論し、その結果改善策を見出して生産性を向上する。そのように開発がまずやって成果を示し、『他責ではなく自責で、自ら体重計に乗ること』によって、開発生産性だけでなく、他部署からの信頼を獲得できる」と話した。その結果、自身の向上にもつながり、他部門との連携や全組織による生産性向上にもつながっていくというわけだ。
「自分たちに厳しさを持っている、事実に向き合っているという評価がなされ、関係部署の変化に影響し、段階的に組織全体がよくなっていく。それはとてもポジティブなことであり、そこに注目することはとてもよいこと」と広木氏はコメントした。
デプロイ頻度の改善は難しいが……。はてなブックマーク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などのデータを活用した可視化によって、エンジニア組織の開発者体験向上を目指すサービス課題を可視化できるというものだ。佐藤氏は「可視化が有効な指標などについてはブログでも紹介しているので見てほしい」と語り、セッションを終えた。
