昨今、エンジニア組織の開発生産性を定量化する指標として、GoogleのDevOps Research and Assessment（DORA）による研究で提唱された”Four Keys”指標がトレンドになりつつあり、開発生産性向上をミッションに掲げて取り組む組織が増えてきています。また海外では、メガテック企業を中心に、Developer Productivity Engineerという開発生産性向上をミッションとする専門職種が一般化しつつあります。

そこで今回は、開発生産性向上の先進的な事例として、ヤフー株式会社の技術支援本部にて、開発生産性向上のためのデータ可視化と分析を務める安永さんにインタビューしました。大規模な開発組織において、どのようにFour Keys指標を横断して可視化し、いかに開発生産性向上への取り組みを推進していったかなどについて伺いました。

2017年ごろから、開発生産性を計測する取り組みをスタート

──まず最初に、安永さんのこれまでの主なご経歴を教えてください。

安永：私は2004年にヤフーに入社して、当初はサービスの開発をしていました。2015年ごろからはエンジニアが社内で使用するツールであるプラットフォーム開発に従事しています。そして、2019年ごろから開発生産性を可視化するためシステム開発や分析を行っています。

──開発生産性に関する話題が盛り上がり始めたのは2021年ごろというイメージですが、それよりも早くトライされているんですね。

安永：私がジョインする前からプロジェクトは動いていて、計測を始めようとしていました。『LeanとDevOpsの科学』や、DORA（DevOps Research and Assessment）が発表しているFour Keysについてのレポートを参考に、2017年くらいから取り組みを始めています。

そのころからヤフーのサービスを支えるプラットフォームのモダナイゼーションの対応が始まっていて、その一環として行われました。プロダクトをより早く世に出すことで、早くフィードバックを得られ、早く改善につなげられるという考えのもと、開発生産性の計測が必要だという話が出てきたことが背景にあります。

──開発生産性向上に取り組むチームの体制について教えてください。

安永：私は直近ではチームから離れていますが、数名のチームがデータ収集や可視化のためのシステム開発や集計、ビジュアライズなどを行いつつ、各組織で開発生産性向上を推進するという体制になっています。

──チームには、データサイエンティストやアナリストの方もいらっしゃるのでしょうか？

安永：アナリティクスに長けている方もいますが、DevOpsの数値の特性などがわかっていないと、切り口を見つけるのが難しいため、両軸でわかる方が必要な分野だと思います。開発経験がないと、そこにどんな作業があるのかというところが、なかなか見えてこないので。

──チームの目標やゴールはどのように設定されましたか？

安永：まずは、いろいろな計測手法を使って精度を高めること。それから、全社的な取り組みとして開始されているものの、一部のチームやプロダクトから始めていたので、取り組みの網羅性を広げていくこと。この2つを目標としました。

計測自動化、成功事例のアウトプットを通じて、スタンダードに

──開発生産性を計測することの意義を、社内でどのように広められていったのでしょうか？

安永：マネジメント層からの期待で始まったものの、2017年ごろは各開発現場に目的を理解してもらうには至らない状況がありました。当初は、Four Keysとベストプラクティスをアンケートで回答してもらっていて、参加チームが150チームほどでした。

2019年ごろからは、アンケート方式ではスピードが足りないということで、Four Keysを自動計測できる仕組みを提供し始めました。その後に参画したのが280チームほどです。

自動計測ができるようになってデータの精度が上がってくると、本来の数値が見えてきました。やはりアンケートでは、個人の主観や考え方の違いが影響して、かなりブレた結果が出ていました。データの公平性が担保されてきたので、計測しているチームも理解を示すようになり、成功事例がアウトプットできるようになりました。

例えば、デプロイ頻度が高いチームであれば、巨大なプルリクエストをなくして、効率的なコードレビューを実践する方法をレポートとして出せるようになってきました。また、変更障害率が低いチームでは、テストデータ管理や、CI/CDパイプラインのインテグレーションテストの自動化まで行っているレポートが出来上がってきました。そのようなレポートが出来てくると、プロジェクトへの理解がより深まっていきました。

そうして、2021年ごろには480プロダクトで計測されるようになりました。今では、開発生産性を計測することはスタンダードになっています。

──成功事例を展開していく取り組みは、当初から行われていたのでしょうか？

安永：いえ、最初は、分析すれば何かしら素晴らしい結果が出るだろうと、一生懸命データを集めて分析していました。しかし、おそらく精度が足りないために、納得感のあるデータが出てこなかったんです。

なので、上手くいっているところにヒアリングしに行って、「こういう素晴らしいデータが出ていますが、どんなことをしているんですか？」と現場から一つずつ話を聞き、それをレポートやインタビューにして導入事例としてアウトプットしていました。

優秀な現場のエンジニアは往々にして忙しく、手ぶらで行くと聞きたいことを聞けないときもあります。でも、データを持っていって話を聞いてみると、「こういう取り組みをしています」と教えてくれる。それは私にとっても嬉しい発見でしたね。

マネジメント層の理解によって、トライし続ける環境が維持されていた

──取り組みを推進していくうえで、どういったことがカギになりましたか？

安永：このプロジェクト自体にちゃんとオーナーがいて、かつマネジメント層が取り組みを深く理解していて、トライして失敗しても継続していたところが大きいと思っています。

テクノロジーグループの技術トップがオーナーとなり一貫して牽引してもらったことで、なんとか成果が出るまで導いていただきました。マネジメント層の理解がなければ、続けていけなかったと思います。

──参画するチームを増やしていく段階で、各チームにはどのようにアプローチされていたのでしょうか？

安永：計測を始めるための手順がドキュメントとして公開されているので、組織として計測したいという意向があれば、その手順に沿って計測すると、データがシステム上で見ることができるようになっています。

我々は強制力を持っているわけではありませんので、最も大切なのは、きちんとベネフィットを伝えること。流れに乗るまでが大変でしたが、トップマネジメントからも計測についてブリーフィングしてもらっていたので、流れに乗ってからは網羅性という課題感は減っていきました。

──ここまでの取り組みを振り返って、一番難しかったのはどんなところでしたか？

安永：やはりプロジェクトに対する理解を得ていくところが、一番難しかったですね。もし最初から、計測の作業とそれに見合う効果をきちんと示すことができていたら、それほど時間はかからなかったのではないかなと。ただ、それでもプロジェクトとして数年トライできる環境が維持されていたおかげで、成果につなげることができたので、そこはとても良かったと思います。

同じ定義でのデータだからこそ、チームのPDCAに効果

──何をどのように計測するかについて、御社ではどういったポリシーで決められていますか？

安永：ポリシーというよりも、何が計測できるかといった方が近いかもしれません。Four Keysデータの場合、デプロイされるタイミングをデプロイ頻度、ファーストコミットのタイミングを変更のリードタイムとして計測。変更障害率とサービス復元時間に関しては、社内に障害管理ツールがあり、何かシステム障害が起きた際はそこに報告するルールがあるので、そこに溜まっている障害のデータから計測しています。

──もともと社内でさまざまな数値を計測されていたなかで、Four Keysにも着目されたのでしょうか？

安永：そうですね、最初はいろいろな数値を見ていました。ただ、『LeanとDevOpsの科学』のような書籍も出てきたので、参考にしながら取り組んできたという経緯です。

──計測を始めたことによって、各チームではどのような効果が見られましたか？

安永：定量的な数値が見えてくると、チームメンバー自身が、今どういう状態で何が悪いのかがわかるようになります。開発生産性の良し悪しだけでなく、フィードバックのなかに、例えば変更のリードタイムがどれくらいなのか具体的に伝えられると、自分たちを俯瞰して内省できる。自分たちのデータを正しく認知できることで、チームの成長にもつながります。

また、Four Keysは時系列で効果が見えてくるものなので、長いスパンで見たときに、開発に対するモチベーションにもつながると感じます。例えば、何か改善をして、それが数値で可視化されると、効果を実感することができる。PDCAのCheckの部分が数値化されるので、また次の改善をしていこうとPDCAがまわっていく、良い効果を生んでいると思います。

それから、全社横断で見えるところもメリットだと思います。ヤフーはとても多くのサービスを提供しているため、サービスや組織によって、特性を重視した開発スタイルを選定しなければなりません。そのなかで、横断的に情報を集めていくのは難しいのですが、Four Keysを計測することで、全社の状況を大まかに見ることができます。Four Keysですべてを測れるわけではありませんが、ある一定の視点を持つことにはなると感じています。

──Four Keysの指標が良くなること自体にも意義があると思いますが、ビジネスKPIへの影響について、経営陣やビジネスサイドから期待される声もありますか？

安永：今まさに新しい指標として、「本当に価値につながっているのか」、「ビジネスにどれぐらい貢献できているのか」といったところを見れるようにしたいと考えています。

──それについては、どのようなアプローチを考えられていますか？

安永：現状はFour Keys以外にも、たくさんのデータを集めています。Four Keysについては、DORAが先行しているおかげでいろいろなヒントがありますから、それを追いかけながら、他のデータについても分析を深めたいと考えています。

もう一つ、情報の展開にも力を入れていて、社内でユーザーコミュニティをつくったりしています。どうすれば生産性が上がるのか、ヒントとしてわかってきた部分も大きいので、今はそうしたナレッジを誰に届けるべきかに興味を持って取り組んでいます。

ベストプラクティスを型化し、改善に向けたアンケートを実施

──御社では6つの大項目をベストプラクティスとして型化し、アンケートを実施されているそうですが、6つの大項目はどういったプロセスで設定されたのでしょうか？

安永：まず、開発ステップに関する社内のガイドラインがあり、それと重複した項目があります。加えて、DORAから出ているDevOpsのケイパビリティも参考にしています。

ただ、もともと2017年から実施していたアンケートは大項目が13個あり、設問としては59節と、かなり回答の負荷が高いものでした。この負荷を軽減するために、6つまで絞ったという経緯があります。過去の回答を見て、回答が一定に定まっているものや、中央値に寄ってしまっているものを削減して、絞っていきました。

引用元：ヤフーでは開発迅速性と品質のバランスをどう取ってるか（2022年） - Yahoo! JAPAN Tech Blog

──定量的な数字だけでなく、定性的なアンケートも実施しようと考えられた理由を教えてください。

安永：Four Keysの自動計測が始まって、かなり計測負荷が下がりましたが、すべてを数値で測ろうとすると大変で、計測に必要な作業コストが高いんです。例えば、「トランクベースデベロップメントができていますか？」という項目を、数値で計測するのはすごく難しい。なので、アンケートとFour Keysの自動計測を分けています。また、新たに計測をトライしたいものについて、アンケートを使って探っていく目的もあります。

──いろいろな開発スタイルのチームがあるなかで、マストなものやチャレンジングなものなど、どういった要素を提示しているのでしょうか？

安永：Four Keys指標が、Lowでも80～90%に到達している回答があって、これは弊社の開発ガイドラインに載っているものです。逆に、Highでも全体的に上手く行っていない内容は、このアンケートのために作成した設問になっています。

──アンケートの設問は、どのように設定されていますか？

安永：2017年の当初は、はっきりと答えが出しにくいアンケートになっていました。例えば、設問が「データベースを含む環境のセットアップはデプロイを自動化できていますか？」で、それに対して「できている」から「できていない」までの5段階評価から回答するような、個人差が出てしまう内容になっていたんです。

それをマチュリティモデルを使って、上は簡単な設問で、下にいくにつれて難しくなるようにしました。例えば、デプロイ自動化だと、まず「手順書はありますか？」から始まって、【「全環境で同じ手順で、デプロイが自動化されていますか？」や、「ベースとなるブランチへのマージをトリガーに本番へデプロイされますか？」、「失敗した際には自動でロールバックされますか？」と続くイメージですね。

どこまでやれていればできていると言えるのかは議論の余地があるかもしれませんが、これらにYesかNoで答えてもらうことによって、どこまでできているかを具体的にしています。そうすると、Four Keysとの関係が見えてきたという結果ですね。

──チームにとっても、次に何をやるべきかの物差しになりますね。

安永：そうですね。「成績が悪い」とだけ言われるとつらいですが、数値やデータを見ながらであれば、感情的にならずに深く話し合えます。チームには、経験値やバックグラウンドが違う人が集まりますから、そのあたりはチームマネジメントに有効に使えるのではないかと思います。

数値化を通じて開発組織の頑張りが伝わりやすくなった

──計測結果をフィードバックする際には、どのような伝え方をされていますか？

安永：データ提供を中心としたコミュニケーションです。深く関わる場合もありますが、全社に対して「こうしてください」といったメッセージングはしていません。

レポートで、「このチームはこういう取り組みをして、この数値が改善しました」といった事例を公開することはあります。あとは、社内のカンファレンスに登壇いただいて、取り組みの内容を発表いただくこともありますね。

──改善の提案を行うところまでは、あえて踏み込まないようにされているのでしょうか？

安永：そこまでの規模で人がいないというのもありますが、各組織にSREチームがあって、そこに開発生産性チームができあがっていっています。そういったところで推進ができているので、どちらかというとデータ提供のような役割分担になっています。

──チームによっては、レポートを見ても実際のアクションにつながりにくいなどの課題はありますか？

安永：これらの情報は開発の一面でしかなく、プロダクト全体を表しているわけではありません。プロダクトのフェーズによって取り組むべきことも違いますから、まずはこういう情報があることを知ってもらうだけでもいいかなと。チームで上手くまわらなくなってきたとか、システム障害が増えてきたとか、そういうときに指針となるような、自分たちの状況を客観的に知れるツールとなることが望ましいと考えています。

──いろいろな立場の方がいらっしゃると思いますが、データを見ているのは主にエンジニアでしょうか？

安永：エンジニアが多いです。ビジネスサイドの情報もうまく組み込めると、ビジネスの課題としても受け止められやすいので、そうなることを望んでいますが、なかなかそこまでは難しいかなと感じています。

ただ、今まで開発において数値化されていなかった部分が見えるようになったことで、例えばビジネスサイドと開発サイドで議論をしなければいけない場面があったとしても、開発サイドの頑張りをわかりやすく見せられるようになりました。そこは一つの進歩かなと思っています。

次にトライしたいのは、適切なナレッジとのマッチング

──ナレッジの共有にも注力されていると思いますが、これも開発生産性チームが主導されたのでしょうか？

安永：計測するだけでは皆さんに納得していただけなかったので、事例が必要だと考えて、開発生産性チームからナレッジを展開するようになりました。今あるコンテンツをSECIモデルに当てはめて、準備していったという経過です。

ただ、当初はこちらからヒアリングしてナレッジを集めていたのですが、開発習慣の大切さが明確になってきて、ナレッジ共有の取り組みがトップマネジメントによってプロジェクト化され、全社的な取り組みとして推進されるようになりました。なので、最近はポストされて、さまざまなナレッジが集まるようになっています。

私は社歴が長いので、いろいろなチームに行った経験があるのですが、組織内で閉じられたナレッジがたくさんあるんですね。でも、それを自分たちでは価値のあるものだと思っておらず、シェアするほどのものではないと思っていたりします。なので、そういった情報がどんどん社内で展開されていくと、より生産性が上がっていくのではないかと考えています。

──ナレッジ共有に取り組むなかで、一番難しかったのはどんなところでしたか？

安永：データ可視化によって共同化まではできていたのですが、表出化させることが必要であると気がつくまでに時間がかかりました。溜まったナレッジを再現可能な状態にするということに、もっと早く気がつけば良かったなと思います。ナレッジが集まるようになった今でも、表出化が大切であるということまでは、まだ浸透しきっていないかもしれません。

──ナレッジ共有の取り組みに関して、次のトライとして考えていることがあれば教えてください。

安永：今はナレッジを収集できる組織になってきたので、今後はそれを各チームに適切に「これを読んでやってみてください」とマッチングするなど、自分たちができなかったコンサルティング的な部分をシステム化できたらいいなと個人的には考えています。

たくさんのナレッジがあるなかで、すべてを読まないといけないとなると、そこが次のボトルネックになってくると思うんですよね。すべての人にすべてのナレッジが必要なわけではないですから、最適な手法を提供していきたいと思っています。

──最後に、これまでの取り組みを踏まえて、今後目指したいゴールについて教えてください。

安永：おそらく多くのエンジニアの方々がそう思っているように、開発をとても効率的なものにしていきたいと思っています。開発の場では、人とのやり取りがずれていたとか、思考がずれていたとか、そういった調整も多いものです。それをもっとスムーズに、より効率的にしていって、エンジニアの皆さんがフラストレーションや負荷なく、快適に開発できる環境をつくりたいと思っています。

──安永さん、ありがとうございました！

※記事中にもある「Four Keys」などの開発生産性指標の可視化・向上を支援する「Findy Team+」のサービス詳細は、以下よりご覧いただけます。 https://findy-team.io/service_introduction