ヤフーでは開発迅速性と品質のバランスをどう取ってるか（2022年）

皆さんは「No Measurement, No Improvement」という言葉をご存じでしょうか。これは「測れないものは改善できない」という意味で、熱力学者であるウィリアム・トムソン博士の言葉とされています。

下図はGoogle社のDORA（DevOps Research and Assessment）を参考にして作成しました。開発スピードとサービスの品質を改善するためには計測が必要です。計測のための4つの指標を紹介します。

四つの指標で計測し、開発スピードとサービスの品質を改善

開発スピードの分析に利用する指標は、1つ目が「Change Lead Time（開発が始まってから本番にデプロイされるまでの時間）」、2つ目が「Deploy Frequency（本番にデプロイされる頻度）」です。

サービスの品質の分析に利用する指標は、1つ目が「MTTR（Mean Time To Repair＝発生した事故の平均修復時間）」、2つ目が「Change Failure Rate（本番にデプロイされていたもののうち、システム事故が発生した割合）」です。

Change Lead Timeは、GitHubとCI/CDツールであるScrewdriver.cdのデータを活用して計測しています。具体的には、デプロイの際にその情報をAPI連携し、集計システムにデプロイ情報を蓄積。その情報からGitHubのfirst commitを見つけ出し、集計します。Deploy Frequencyは、デプロイの際のAPI連携の回数を計測します。

Change Failure RateとMTTRは、社内ツールである事故報告ツールのデータを利用しています。ヤフーでは、事故が発生した場合、発生時間と応急処置完了時間を報告する義務があるので、その報告内容から集計します。

次に、371プロダクトの指標の計測結果を示した4つのグラフを紹介します。グラフの青信号は良い結果、赤信号は悪い結果、黄信号はちょうどその中間点を示しています。

Change Lead Time

ソフトウェアデリバリーのChange Lead Timeは、短ければ短いほど良い結果と言えます。お客さまからのフィードバックが高速に反映され、それを受けての進路変更も素早く行えるからです。

デプロイ頻度

開発スピードに関するもう1つの計測指標が、デプロイ頻度です。皆さんは複数の変更要件が入った大きなプルリクエストをもらったとき、レビューしきれないと感じることはありませんか。作業サイズの削減によって得られる効果は、お客さまからのフィードバックの高速化とリスクの削減、コストとスケジュールの膨張抑制です。ただソフトウェアの場合、作業サイズは目に見えないため、代わりにデプロイ頻度を計測指標にしました。

MTTR（平均修復時間）

複雑なシステムが急速に変化する現代のソフトウェア開発に失敗はつきものなので、サービスをいかに迅速に復旧できるかが鍵です。そこでインシデントが発生した場合に復旧までにかかった時間を示す、平均修復時間を計測指標にしています。

Change Failure Rate（稼働に失敗したケースの発生率）

開発現場で一度失敗をすると、復旧作業と影響調査で予定外の作業が増えてしまいます。エンジニアの心理的にも、なるべく失敗率は少ない方が健全です。そのため稼働に失敗したケースの発生率も指標の1つです。ヤフー社内ではSite change Success Rate（SSR）とも呼んでおり、品質評価指標となっています。

各指標をどうやって評価するか

開発のスピードとサービスの品質は開発現場において相反する場面が多くあります。例えば、テストを強化すればサービスの品質は上がりますが、提供までの時間は増加します。逆に、急ピッチに開発をした場合、十分なリスク検証ができず、サービスの品質は低下します。

そこで、開発スピードとサービスの品質をバランスよく改善するために、指標ごとに下位クラス、中位クラス、上位クラスの3つに分け、評価基準を定めました。

ここで注意すべきは、指標単体での評価ではプロダクトの状態を容易には判断できないことです。例えば、スピードは速いがインシデントが多い場合、そのプロダクトをどのような状態と見ればよいでしょうか。そこで、スピードと品質について、4つの指標の中で最も低い評価となった指標を、プロダクトが属する総合クラスで表しました。こうすることで、スピードと品質のバランスを取りながらプロダクトを評価でき、自身のプロダクトの状態を見ながら、より高いクラスを目指して改善に取り組みます。

可視化については、計測のためにデプロイパイプラインへ特別な設定を組み込まなければならず、ヤフー全社で統一した計測を行うことについて、理解を得るのは非常に苦労しました。しかし結果として、全社を相対的に数字で見られるようになりました。

今回一番お伝えしたいことは、開発について「あの手この手で見える化する」ことです。

Change Lead Time、Deploy Frequency、MTTR、Change Failure Rateの4つの指標を、見える化の手段として用いました。ほかにも計測している数値はありますが、私はこの4つが最もバランスが良い計測だと思います。

プロダクトへのアンケートを行い、数値改善に有効な開発習慣を見つける

開発習慣はサービス特性に関係しています。例えば、課金系システムであれば品質が最重要視され、常にミスのない状態が求められるため、テスト自動化が開発習慣として発達します。

開発習慣はプロダクトのライフサイクルにも関係しています。スタートアップのような生まれたてのサービスでは、素早くシステムを作り上げ、何度も機能調整することが必要となるため、デプロイ自動化が開発習慣として発達します。

多くのサービスを提供しているヤフーでは、開発習慣についても多くのバリエーションが存在します。さまざまな開発特性がある中、何をすれば数値改善につながるのかを明確にするため、プロダクトへのアンケートを行い、数値データとの関係性を調べました。

アンケートでは、開発習慣に関する6つの大項目を設定しました。「トランクベース開発」「アーティファクト管理」「デプロイ自動化」「テスト自動化」「テストデータ管理」「疎結合化」です。この項目は社内においてベストプラクティスと呼ばれており、CI/CDを中心とした開発スタイルを参考としています。

アンケートでは回答誤差が生じないように設問内容を具体化し、「はい」か「いいえ」のどちらかで答えられるものに設定しました。

下の図はアンケートの回答結果と、各クラスの関係性をグラフで示したものです。これを見ていくことで、開発習慣とプロダクトが属するクラスとの関係が見えてきます。上位クラスになればなるほど、ベストプラクティスな開発習慣が定着していることが分かります。

アンケートの内容を少し詳しく見てみます。テスト自動化に関しては、3つの設問を用意しました。設問は回答が進むにつれて難易度が高くなるように設計しています。

「単体テストが自動化されている」「テストがCI/CDツールで実行されている」のプラクティスは社内で定着しつつある状態です。反対に、結合テストの自動化については上位クラスでもまだ十分ではない状態でした。ここから考えられることは、現在、下位クラスであるチームは、結合テストに注力するよりも、単体テストの自動化やテストがCI/CDツールで実行される状態にフォーカスする方が、上位クラスになるために効果的だということです。

実際の開発現場はさまざまな問題を抱えています。より効果的なプラクティスを優先的に実践することが必要です。

今回のアンケートの結果で意外だったのは、基本的なプラクティスの集計結果は僅差だということです。僅差ではあるものの、上位クラスは基本的なプラクティスを徹底的に習慣化できていると感じます。

改善のためのアクションを開発現場で実践

次は「改善のためのアクション」について、あるプロダクトの例を紹介します。

このプロダクトは4つのステップで改善のためのアクションを起こしました。1つ目は「自プロダクトの数値を知る」、2つ目は「自プロダクトの開発習慣を知る」、3つ目は「上位クラスと比較する」、4つ目は「通常業務と並行しながら改善する」です。

上図の左はスピードに関する指標、右は品質に関する指標です。これを見ると、右側の品質に関する指標は2つとも上位クラスにあります。一方、左側のスピードに関する指標は下位クラスになっており、改善が必要なことが分かります。

このチームは、運用作業に追われてDeploy Frequencyの数値が低くなっていました。そのため、先ほどのバランスを見るグラフにプロットすると、総合的には下位クラスに属していました。そこで課題を見つけるために、チーム全員にアンケートを回答してもらいました。

そこから見えてきたのは、チーム内でも開発ルールの認識に差があり、回答にばらつきがある現実でした。そこでばらつきについて議論することで、チームの開発ルールについて再確認することができました。

次のレーダーチャートの図は、アンケートの集計結果を平均値として表したものです。

このチームではテスト自動化の習慣が低いことが分かります。先ほどまとめた自身のプロダクトの数値に上位クラスの平均値を重ね、このグラフで比較しながら、チーム全員で開発習慣について議論しました。

さまざまな開発経験を持つメンバー構成なので、これまでは白紙の状態から意見をまとめると時間がかかっていました。しかし今回は、ベストプラクティスと数値データという物差しを用いたことで客観的な視点につながり、アーティファクト管理とデプロイ自動化、テスト自動化のベストプラクティスに、開発メンバーから次々と改善点が出てきました。

通常業務もありますので、改善はアプローチしやすいところから実施するのが良いです。このチームにとってテスト自動化は言語的ハードルもあり、チーム内で対応が難しいという意見が多数だったため、アプローチしやすいアーティファクト管理から改善を始めることにしました。

アーティファクト管理の「全環境で同一のパッケージ、イメージ構成管理ができて、利用している」の設問に対してですが、本番環境での構成管理はできていたものの、「全環境で同一」の部分ができていませんでした。プロダクトが成長を遂げる過程で増築していた、新しい検証環境の構成管理が不十分だったのです。検証作業のたびに変数を手作業で上書きしていて非効率的でした。また、担当ごとにこの変数に関する知識にばらつきがあり、情報共有に時間がかかっていました。そこで、全ての環境変数をコード管理できるように変え、同一の構成管理に刷新しました。

次に、「全環境でデプロイ手順が同じである、デプロイは自動化されている」というデプロイ自動化のプラクティスに取り組みました。本番へのデプロイ自動化はできていたのですが、設問の中の「全環境で」の部分ができていませんでした。ステージング環境や開発環境へのデプロイ自動化ができていないため、デプロイに不要な手作業が発生していたのです。こちらもデプロイパイプラインを改良して、全て自動化しました。

これら2つの設問に関して改善したことで、コミュニケーションロスや手作業のための設定ミスに悩まされることなく、すぐに目的の作業に着手できるようになりました。また、時間が取られていた運用作業が効率的に変化し、リソースにも余裕が出てきました。テスト自動化は未対応のまま残っていますが、半年後には数値に変化が出てきました。

Change Lead Timeは213時間から134時間へ改善。Deploy Frequencyの数値は0.66回から8回へ大きく改善しました。

この結果、半年間の改善アクションで、下位クラスから上位クラスへと移行できたのです。

効果が明確であるため、改善に向けてエンジニアのモチベーションも上がり、ポジティブフィードバックがうまく回っている状態と言えます。開発効率が良くなったことで作業に余裕が出てきたので、今後は課題であったテスト自動化の改善が進んでいくはずです。

開発生産性の向上は、ダイエットに似ています。もし自分が太ったなと思えば体重を測り、歩数計を着け、食事のカロリーを計測。それで運動量の減少が原因だと分かれば、その部分を改善しようとするのではないでしょうか。

開発生産性も同じです。まずスピードと品質を計測し、開発習慣を可視化すれば、的確に改善点を見つけられ、生産性向上の成功へと導きます。

開発生産性におけるナレッジを全社に展開し、暗黙知から形式知へ

ヤフーには長年培われた開発に関するさまざまなナレッジが存在し、個々のサービスやプロダクトにとどまっていて、暗黙知化しています。この暗黙知は、先ほど紹介したようなベストプラクティスのように明確な形式知とはなっていません。

例えばベストプラクティスを実践するに当たり、テスト自動化をチームに普及させるにはどうすれば良いのでしょうか。また、作業サイズを小さくするにはどうすれば良いのでしょうか。その答えを他のチームが持っているとしたら？

開発生産性を向上させるには、ナレッジを再現可能なノウハウとして展開する必要があります。

そこで、私たちはナレッジマネジメントに取り組んでいます。個人やプロダクトが持つ暗黙知は共同化、表出化、連結化、内面化という4つのプロセスを経ることで、組織全体の共通の知識になります。開発生産性におけるナレッジを、このプロセスを使ってヤフー全社に展開しています。

具体的に各プロセスについて紹介します。

共同化

共同化とは、日々の業務を通じて個人が持っている暗黙知を他人に共有できるようにすることです。数値の可視化や開発習慣に関するアンケートを全社に公開し、暗黙知を他人と共有できるようにしています。

表出化

表出化とは、暗黙知を言葉やチャートを用いて具体的な形に変えていくことです。私たちは、開発生産性が優れているチームへヒアリングをし、優良な事例を具体的な数値とデータ、方法としてまとめ、社内技術ドキュメントで紹介しています。

連結化

連結化とは、形式知化された知識またはデータをさらに結びつけ、最終的な形に落とし込むことです。開発プロセスに関する最終的な形式知として、社内技術ガイドラインにエンジニアの順守事項として提示されています。

内面化

内面化とは、連結化によって組織として形式知とされたものを個人に取り込んでいくフェーズです。ここでは社内カンファレンスを活用しています。開発生産性で成果を出しているプロダクトを社内カンファレンスで成功事例として紹介し、より身近に改善を感じてもらうことで、開発現場に導入しやすくしています。

これら4つのプロセスを通して、ヤフーで培われている優良なナレッジの展開に努めています。

開発現場におけるスピードと品質の両立は個人の力でなせるものではなく、チームや組織で相互理解をしながら取り組むことが大切です。従来、感覚的に語られていた開発生産性よりも、具体的な数値で全員が共通理解できる状態とし、組織文化として生産性が常に保たれる状態を作ることが大切だと感じています。

ヤフーには多種多様なサービスがあり、プロダクトはそれぞれのサービス業種および業態特性を考えながら最適な開発習慣やプロセスを考えています。そして、作業が円滑にミスなく行われるようにCI/CD、自動化の仕組みづくりをしています。さらに効率的な開発を実現することで、お客さまへ価値あるサービスをスピーディーに提供し、そして安全に利用していただけるように、取り組んでいきたいと思います。

アーカイブ動画