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

こんにちは。ヤフーで開発生産性の可視化を担当している安永です。

ヤフーでは3,000人以上のエンジニアが、毎日プログラムコードの変更を行いながら、サービスの新機能リリースおよびシステム改修を行っています。近年のソフトウェア開発では、ビジネス変化への対応がスピーディーであることが求められます。いかに迅速にかつサービスの品質を落とさすに新しい価値を提供できるかが重要です。しかし、迅速性とサービスの品質は開発現場にとって相反する場面が多くあります。例えば、テストを強化すればサービス品質は上がりますが、提供までの時間は増加します。反して、急ピッチに開発をした場合、十分なリスク検証ができずサービスの品質は低下します。

このように、スピーディーさとサービス品質をバランスよく改善するには、どのようなことが必要なのでしょうか？　今回は、バランスの数値化から開発現場の改善まで、どのように行っているかご紹介したいと思います。

1. まずは、迅速性と品質を数値的にわかるようにする

迅速性と品質の状態がわからなければ、改善すべきことがわかりません。また、取り組みの効果が不明であれば推進が難しくなります。まずは、これらの要素の数値化を行います。計測指標と計測ポイントを決め、集計されたデータを理解しやすくする必要があります。

ここでは、どのように数値化して、その結果を理解しやすくしたかを紹介します。

迅速性とサービスの品質を数値化する

迅速性としては、以下の2つの指標を数値化しています。

• Deploy Frequency : 本番にデプロイされる頻度
• Change Lead Time : 開発が始まってから、本番にデプロイされるまでの時間

品質としては、以下の2つの指標を数値化しています。

• Change Failure Rate : 本番にデプロイされていたもののうちシステム事故が発生した割合
• Mean Time To Repair (MTTR) : 発生した事故の平均修復時間

迅速性と品質のそれぞれから指標を選定したことで、どちらかに偏った評価にならず、迅速性と品質のバランスを保てます。この指標はDORAが発表しているState of DevOps Report2019を参考にしています。算出元となるデータは、社内で使用している開発ツールのGitHub、Screwdriver.cd、事故管理ツールから抽出しています。数値はプロダクトごとに集計されており、BIツールで誰でも確認できます。

数値化した4つの指標を用いて総合ランクを作成

4つの指標に対して数値化を行いました。しかし、数値化されてデータだけでは、そのプロダクトの状態を容易に判断はできません。例えば、迅速性指標（Deploy Frequency）は良いが、サービスの品質指標（Change Failure Rate）が悪い場合どのような状態と見るのかという場合です。

そこで、迅速性（Deploy Frequency・Change Lead Time）と品質（Change Failure Rate・Mean Time To Repair）のそれぞれの指標について、相対ランキングを付けました。

【図1 . 4指標とランク】※調査対象 385プロダクト（457システム）結果

そしてさらに、それぞれをバランス良く評価をするために、プロダクトが獲得した4つの指標の中で最も低いランクを総合ランクとして、採用しました。このようにすることで、品質と迅速性のバランスを取りながらプロダクトの状態を見ることができます。

• 総合ランクが低い 品質と迅速性のどちらか、または両方の数値が相対的に低い
• 総合ランクが高い 品質と迅速性の両方の数値が相対的に高い

どんなに迅速であっても、品質が悪ければ総合ランクは上位には含まれません、どんなに品質が良くても迅速でなければ総合ランクは上位には含まれません。

【表１ . 各ランクと総合ランク例】

2. 数値改善に有効な開発習慣を見つける

迅速性と品質の双方の数値データを用いて、プロダクトに総合ランクをつけられました。ただ、それだけではどのように数値改善をするためのアクションを取れば良いのかわかりません。そこで、開発習慣に着目しました。

開発習慣は、サービス特性とライフサイクルに関係しています。例えば、サービス特性を例にとると、課金系のシステムであれば品質が重要視され、常にミスのない状態が求められるため、テスト自動化が開発習慣として発達しています。ライフサイクルの例では、スタートアップのような生まれたてのサービスでは、迅速に小さなシステムを作り上げ、何度も機能調整が必要となるため、デプロイ自動化が開発習慣として定着します。このように、多くのサービスを提供しているヤフーは、開発習慣について多くのバリエーションが存在します。

開発習慣に関するアンケートを実施する

どのアクションが数値改善につながるのかを明確にするため、エンジニアへのアンケートを行い、総合ランクとの関係性を調べました。アンケートには開発習慣に関する6つの大項目を設定しました。この項目は社内においてベストプラクティスと呼ばれており、CI/CD（継続的インテグレーション/継続的デリバリー）を中心とした開発スタイルを参考としています。

＜ ベストプラクティス ＞

• マスターベース開発
• アーティファクト管理
• デプロイ自動化
• テスト自動化
• テストデータ管理
• 疎結合化

これらの項目について、合計19の設問を用意しました。設問内容は、【表2 . アンケート設問内容と結果】を参照してください。回答誤差が生じないように設問内容を具体化し、「はい」または「いいえ」のどちらかで回答できるようにしています。

アンケート結果をランクごとに統計データとして表す

アンケートの回答結果を総合ランク毎の統計データとして表しました。そうすることで総合ランクと開発習慣の関係が見えてきます。下位より上位のプロダクトの方が、ベストプラクティスと呼ばれる開発習慣が定着していることがわかります。

【表2 . アンケート設問内容と総合ランク】※調査対象 385プロダクト（457システム）結果

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

ここからは視点を変えて、あるプロダクトの改善への取り組み事例を紹介します。数値化から導き出された総合ランクとアンケートから得られたベストプラクティス統計データを活用して、自分たちの開発について振り返りをしました。

このプロダクトは、当初、総合ランクは下位相当となっていました。その後分析と改善を通じてランキングが変わりました。さて、どのような取り組みをし、どのような結果となるでしょうか。

ランク上位のプロダクトと開発習慣を比較する

総合ランクが下位相当とされた理由は、品質についての評価は高いが、迅速性が足りないことでした。これは、運用作業に追われ、Deploy Frequencyのランクが低いことが起因しています。そこで自分たちの開発習慣をアンケート結果を見ながらチーム全員で議論しました。すると、アーティファクト管理とデプロイ自動化、テスト自動化のベストプラクティスに不十分な点が見つかります。

さまざまな開発経験を持つメンバー構成なので、これまでは、白紙の状態から意見をまとめると時間がかかっていました。しかし、ベストプラクティスとランクごとの数値データを用いたことで、メンバーがプロダクトに対し客観的な視点を持つことができ、内省できました。自分たちと上位のプロダクトとの開発習慣の違いは何かという議論で、改善点の発見につなげています。

通常業務と並行しながら改善する

通常業務もありますが、改善のための環境整備や自動化の対応を並行させます。対応の順番は難しいことより、簡単なことからで良いと考えています。

まず、以下の設問が「はい」と回答できるようにしました。

（アーティファクト管理）・全環境で同一のパッケージ・イメージ・構成管理を利用している

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

次に、以下の設問が「はい」と回答できるようにしました。

（デプロイ自動化）・全環境でデプロイ手順が同じである。デプロイは自動化されている。

本番へのデプロイ自動化はできていたのですが、設問の中の 「全環境で」 の部分ができていませんでした。ステージング環境や開発環境へのデプロイ自動化ができていないためデプロイに不要な手作業が発生していました。こちらもデプロイパイプラインを改良し、全て自動化しました。

これら改善の結果

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

すると、リソース不足のために停滞していた新規案件への着手が可能となり、デプロイができるようになります。その結果、Deploy Frequencyが改善します。迅速性が増して、下位ランクから移動し中位ランクに属せるようになりました。効果が明確であるため、エンジニアのモチベーションも上がりプロダクト開発効率が好転しています。

このプロダクトにとって、テスト自動化 のベストプラクティスは難易度が高い改善であり、まだ未対応として残っています。しかし、開発効率が上がったことにより作業に余裕ができているので、今後はこれら改善も推進されるでしょう。そして、将来的には上位ランクに属せるようになると推測します。

おわりに

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