00:06
はい、6月24日土曜日ですね。
僕は昨日38歳になりました。
相も変わらず、今夜ちょっと洋服化しをしてきましてですね。
かなり寝坊して、今からちょっとスタートになります。
また今日はですね、僕は午後から採用イベントが渋谷に行くので、
また超優秀な学生さんたちとお会いしてくるというところで、
そういう楽しみな面もあり、しっかり頑張ってこなきゃなという面もありというところですね。
はい、おはようございます。
エメミのkeethことくわはらです。
では、本日もあさかず始めていきたいなと思います。
本日はタイトルにありますとおり、インタビュー記事ですね。
プロダクトで4keysを計測。
カタカにこだわるヤフーの開発生産性マネジメントとはという記事を読んでいこうかなと思っています。
僕は仕事で開発生産性ってところも一応見る、ポジションにいる、
ミッション与えられているところなので、その辺の参考になるかなと思っております。
本題に入る前に、おとといかなぐらいに参加した勉強会ですね。
ファインディーさんの勉強会で僕も登壇させていただいたんですけど、
その後に登壇されていたワンキャリアの宇田川さんかという方が発言、登壇されていて、
その時に出ていた開発生産性の指標として、
ザ・スペースっていうものですね。
スペースが頭文字、5文字ですね。
5つのメトリクスがあって、それの頭文字を取ってスペースってなったんですけど、
そっちの方が僕は最近の注目というか関心が強くてですね。
フォーキーズも全然素晴らしいものではあるんですけど、
プロダクト開発とか事業会社に寄り添った指標というか、
メトリクスな印象というか、体感が強くて、
もうちょっとですね、開発者体験と開発生産性、
この両方を見た、上位互換ではないですけど、
より包括的な指標としてマイクロソフト社が作ったザ・スペースっていう、
メトリクスが僕は今関心が強いですね。
こっちの方が弊社にも合いそうなので、そっちの方も今後はしっかり追っていきたいというか、
導入できたらなというのを思ったりはしておりますけど。
さておき、今回の本記事に入りましょう。
はい、いきたいと思います。
昨今、エンジニア組織の開発生産性を低量化する指標として、
GoogleのDevOps Research and Assessment、DORAですね。
DORAによる研究で提唱されたフォーキーズという指標がトレンドになりつつあり、
開発生産性向上ミッションに掲げて取り組む組織というのが増えてきております。
また海外では、メガテック企業を中心に、
デベロッパープロダクティビティエンジニアという開発生産性向上をミッションとする
専門職種というのが一般が伝わります。
あ、そうなの?
デベロッパープロダクティビティエンジニアというか、
専門的なポジションというのが用意されていたんですよね、海外は。
それは知らなかった。
そこで今回は、開発生産性向上の先進的な事例として、
Yahoo株式会社の技術支援本部にて、
開発生産性向上のためのデータ可視化と分析を務める安永さんにインタビューしました。
03:00
大規模な開発組織において、どのようにフォーキーズ指標を横断して可視化し、
いかに開発生産性向上への取り組みを推進していったか、
などについてお伺いしましたというところで、
今のが前置きですね。
じゃあ本題に入っていきたいと思います。
2017年頃から開発生産性を計測する取り組みをスタートというところからです。
まず最初に安永さんのこれまでの主なご経歴を教えてください。
私は2004年にYahooに入社して、当初はサービスの開発をしていました。
2015年からエンジニアが社内で使用するツールであるプラットフォーム開発に従事しております。
そして2019年頃から開発生産性を可視化するためのシステム開発や分析を行っています。
開発生産性に関する話題が盛り上がり始めたのは2021年頃ですね。
イメージですけど、それよりも早くトライされているんですね。
私がジョインする前からプロジェクトは動いていて、計測を始めようとはしていました。
LeanとDevOpsの科学とか、Doraですね。
DevOps Research & Assessmentが発表している4K図についてのレポートを参考に、
2017年くらいから取り組みを始めております。
その頃からYahooのサービスを支えるプラットフォームのモノライゼーションの対応というのが始まっていて、
その一環として行われました。
プロダクトを世に出すことで、早くフィードバックを得られ、
早く改善につなげられるという考えの下、開発生産性の計測が必要だという話が出てきたことが背景にあります。
開発生産性向上に取り組むチームの体制について教えてください。
私は直近ではチームから離れていますけど、
数名のチームがデータ収集や可視化のためのシステム開発や集計、ビジュアライズなどを行い、
各組織で開発生産性向上を推進する体制になっております。
チームにはデータサイエンティストとかアナリストの方もいらっしゃるんでしょうかというところですけど、
アナリティクスに長けている方もいますが、
DevOpsの数値の特性などが分かっていないと切り口を見つけるのが難しいため、
両軸で分かる方が必要な分野だと思っております。
開発経験がないとそこにどんな作業があるのかというところがなかなか見えてこないので、
チームの目標やゴールはどのように設定されましたかというところです。
まずはいろいろな手法ですね、計測手法を使って精度を高めること、
それから全社的な取り組みとして開始されているものの一部のチームやプロダクトから始めていたので、
取り組みの網羅性というのを広げていくこと、この2つを目標としました。
精度はもちろんその通りなんですけど、精度だけじゃなくて網羅性というところも目標としたんですね。
結局深くそして広くという両方を追ったんですね。
いやーそれができるのは素晴らしいと思いましたね。
では続いて、計測自動化、もしくは成功事例のアウトプットを通じてスタンダードにというお話ですね。
では続いて開発生産性を計測することの意義を社内でどのように広められていったんでしょうかという問いですけど、
マネジメント層からの期待では始まったものの、2017年頃から各開発現場に目的を理解してもらうには至らない状況がありました。
当初はその4KEYSというベストプラクティスをアンケートで回答してもらっていて、
06:03
参加チームが150チームほどでした。
ヤフーさんデカいですね。やっぱり150チームもいるんですね。
いやーさすがだな。
2019年頃からはアンケート方式ではスピードが足りないということで、4KEYSを自動計測できる仕組みを提供し始めました。
その後に参画したのが280チームほどです。
もっといたんだ。そもそもチームとしてはもっとデカい。
自動計測ができるようになってデータの精度が上がってくると本来の数値が見えていくようになりました。
やはりアンケートでは個人の主観であったり考え方の違いが影響して、かなりブレブレな結果が出ておりました。
データの公平性が担保されてきたので、計測しているチームも理解を示すようになり、成功事例がアウトプットできるようになりました。
例えば、デプロイ頻度が高いチームであれば、巨大なプルリクエストをなくして効率的なコードレビューを実践する方法をレポートとして出せるようになっていきました。
また、変更障害率が低いチームではテストデータ管理であったりとか、CICDパイプラインのインテグレーションテストの自動化まで行っているレポートが出来上がってきました。
そのようなレポートができてくると、プロジェクトへの理解がより深まっていきました。
そうして2021年頃には480プロダクトで計測されるようになりました。
はぁ、480プロダクトってYahooさんはそんなにプロダクトを持ってたんですね。
表に出ているサービスばかりしか見えていないんですけど、本当は細かいものを探すとどれだけいっぱいあるんですよね。
今ではその開発生産性を計測することがもうスタンダード、標準というか文化になってきたんですかね。
これは本当にいい話ですね。
では続いて、成功事例を展開していく取り組みは当初から行われていたのでしょうかというところですけど、
最初はですね、分析すれば何かしら素晴らしい結果が出るだろうと一生懸命データを集めて分析をしていました。
しかしおそらく精度が足りないために納得感のあるデータが出てこなかったんですよね。
なのでうまくいっているところにヒアリングしに行って、
こういう素晴らしいデータが出ていますがどんなことをしているんですかと現場から一つずつ話を聞き、
それをレポートやインタビューに導入事例としてアウトプットしていきました。
優秀な現場のエンジニアは往々にして忙しく手ぶらで行くと聞きたいことを聞けない時もあります。
でもデータを持って行って話を聞いてみるとこういう取り組みをしていますと教えてくれます。
それは私にとっても嬉しい発見でしたね。
では続いてマネジメント層の理解によってトライし続ける環境が維持されていたところですね。
取り組みを推進していく上でどういったことが鍵になりましたかという問いです。
このプロジェクト自体にちゃんとオーナーがいて、かつマネジメント層が取り組みを深く理解していて、
トライして失敗しても継続していたというところが大きいと思っております。
テクノロジーグループの技術トップがオーナーとなり一貫して牽引してもらったことで
何とか成果が出るまで導いてきました。
マネジメント層の理解がなければ続けていかなかったと思います。
ではついで三角するチームを増やしていく段階で各チームにはどのようにアプローチをされていったんでしょうかという問いですね。
09:01
計測を始めるための手段がドキュメントとして公開されておりますので組織として計測したいという意向があれば
その手順に沿って計測するとデータがシステム上で見ることができるようになっております。
我々は強制力を持っているわけではありませんので
最も大切なのはきちんとベネフィットを伝えること。
流れに乗るまでが大変でしたがトップマネジメントからも計測についてブリーフィングしてもらっていたので
流れに乗ってからは網羅性という課題感は減っていきました。
流れをまず作るところが大事なんですね。網羅性はそこからついてくるということですね。
まあそれもそうですよね。
本当物事は軌道に乗ったら後は勝手に進んでいきますのでその軌道に乗るまでのところに注力をしたってところですね。
まあ当たり前のことをちゃんと当たり前にやったってことですね。
いやーいい話でした。
続いてここまでの取り組みを振り返って一番難しかったのはどんなところでしたでしょうか。
やはりですねプロジェクトに対する理解を得ていくところっていうのがやっぱり一番難しかったですね。
もし最初から計測の作業とそれに見合う効果っていうのをきちんと示すことができていたのであれば
それほど時間はかからなかったんじゃないかなと。
ただそれでもプロジェクトとして数年トライできる環境が維持されていたおかげで成果につながることができましたので
そこはとても良かったと思っております。
では続いて。
同じ定義でのデータだからこそチームのPDCAに効果っていうところですね。
何をどのように計測するかについて、御社ではどういったポリシーで決められておりますかという問いですね。
ポリシーというよりも何が計測できるかといった方が近いかもしれません。
フォーキーズがデータの場合、デプロイされるタイミングをデプロイ頻度、ファーストコミットのタイミングを変更のリードタイムとして計測。
変更障害率とサービス復元時間に関しては社内に障害管理ツールがあり、何かシステム障害が起きた際はそこに報告するルールがあるので
そこに溜まっている障害のデータから計測をしていきますと。
もともと社内で様々な数値を計測されていた中でフォーキーズにも着目されたんでしょうかと。
そうですね。最初はいろいろな数値を見ていました。
ただ、リーンとデブオプスの科学のような書籍も出てきたので、参考にしながら取り組んできたという経緯があります。
計測を始めたことによって各チームではどのような効果が見られましたかということですね。
定量的な数値が見えてくるとチームメンバー自身が今どういう状態で何が悪いのかというのが分かるようになっておきます。
開発生産性の良し悪しだけでなく、フィードバックの中に例えば変更のリードタイムがどのくらいなのか具体的に伝えられると
自分たちを俯瞰して内省できます。
自分たちのデータを正しく認知できることでチームの成長にもつながります。
またフォーキーズは時系列で効果が見えてくるものなので
長いスパンで見たときにまた開発に対するモチベーションにもつながると感じています。
例えば何か改善をしてそれが数値で可視化されると効果を実感することができます。
PDCAのチェックの部分が数値化されるのでまた次の改善していこうとPDCAが回っていくような良い効果を生んでいると思っております。
12:06
それから全社横断で見えることもメリットだと思っております。
Yahooはとても多くのサービスを提供しているため
サービスや組織によって特性を重視した開発タイルを選定しなければなりません。
その中で横断的に情報を集めていくのは難しいのですが
フォーキーズを計測することで全社の状況をおまかに見ることができます。
フォーキーズで全てを測れるわけではありませんが
ある一定の視点を持つことになると思っております。
フォーキーズの座指標が良くなること自体にも賄識があると思うんですけど
ビジネス系PIAの影響について経営陣やビジネスサイドから期待されるという声もありましたか?
今まさに新しい指標として本当に価値につながっているのか
ビジネスにどれだけ貢献できているのかを見れるようにしたいと考えているところですね。
それについてどんなアプローチを考えられていますか?
現状はフォーキーズ以外にもたくさんのデータを集めております。
フォーキーズについてはドラが先行しているおかげで色々なヒントがありますから
それを追いかけながら他のデータについても分析を深めたいと思っております。
もう一つ情報の展開にも力を入れていて
社内でユーザーコミュニティを作ったりしています。
どうすれば生産性が上がるのか
ヒントとして上がってきた部分も大きいので
今はそうしたナレッジを誰に届けるべきかについて
興味を持って取り組んでおります。
では続いてベストプラクティスを型化し
改善に向けたアンケートを実施というセクションですね。
御社では6つの大項目のベストプラクティスとして型化し
アンケートを実施されているそうですけど
6つの大項目はどういったプロセスで設定されていたのでしょうか?
まず開発ステップに関する社内のガイドラインというものがあり
それと重複した項目というのがあります。
加えてドラから出ているDevOpsのケーパビリティも参考にしています。
ただ元々2017年から実施していたアンケートは
大項目が13個あり
説問としては59説とかなり負荷が高いものですと
回答負荷が高かったと思うんですね。
この負荷を軽減するためにも
6つまで絞ったという経緯があります。
過去の回答を見て回答が一定に定まっているものや
中央値に寄ってしまっているものというのを削減して
絞っていきましたよということですね。
一応画像がペッと貼られていて
ディベロップメントハビッツサーベイという
開発者の何か
ハビッツなので習慣とか
というものの調査をしていたところです。
これの画像の引用元として
Yahoo!では開発人属性と品質のバランスをどう取り扱っているか
2022年という記事がYahoo!テックブログからも出ていますので
これなんかちょっと気になるので
ついでに明日ですかね
読んでいきたいかなと思っています。
長さ的に
長さ的にもちょうどいいんですけど
画像が多いんで
読みたいけど
ちょっと音読だと難しいかもしれないですけど
まあ読んでいこうかな
はい、というので
本文も載って続けます。
定量的な数値だけでなくて
定性的なアンケートも実施しようと考えられた理由というのを
ちょっと教えてください。
15:00
ポッキーズの自動計測が始まって
かなり計測の負荷は下がりましたが
全てを数値で測ろうとすると
結構大変で
計測に必要な作業コストが高いんです。
例えばトランクベースディベロップメントが
できていますかという項目を
数値で計測するのは結構難しいんですよ。
なので
アンケートとポッキーズの自動計測を分けております。
また新たに計測を
トライしたいというものについて
アンケートを使って探っていくというような
目的もあります。
いろいろな開発スタイルのチームがある中で
マストなものやチャレンジングなものなど
どういった要素を提示しているのでしょうかというところですね。
ポッキーズ指標が
ローでも80から90%に
到達しているという回答があって
これは弊社の開発ガイドラインに沿っているものです。
逆にハイでも
全体的にうまくいっていない内容というのは
このアンケートのために作戦した質問になっています。
指標としてはローかもしれなくても
でも80から90になっているものの
回答がある。そりゃそうなんだよね。
逆にハイだとしても
全体的にうまくいっていないというのは
クリティカルなものなのですぐに対応しなきゃな
と思います。
ちゃんとアンケートを取って今の現状どうですか
というのも一緒に把握していく
というのは本当にいい話だなと思います。
では続いてアンケートと質問は
どのように設定されていますかというところですね。
これ気になりますね。
2017年の当初は
はっきりと答えが出しにくいアンケートには
なっておりました。例えば質問というものが
データベースを含む環境の
セットアップはデプロイを自動化できていますか
みたいな質問ですね。
それに対してできているできていないまでの
5段階評価を回答するような
正直個人差が出てしまうような内容になっていた
ということですね。
それはマチュリティモデルを使って
簡単な質問で下に行くにつれて
難しくなるようにもしておりました。
例えばデプロイ自動化だと
まず手順書はありますかから始まって
全環境で同じ手順で
デプロイが自動化されておりますかというものだったり
ベースとなるブランチへの
マージをトリガーに本番へデプロイされますか
というすごい具体的な
質問ですね。とか
失敗した際には自動でロールバックされますか
という風に続くイメージですね。
いやーこれいいですね。分かりやすい例ですね。
なるほどなるほど。
本当に具体的
かつ踏み込んだ
質問に行っていくというのが
回答しやすいですね。逆に僕らからすると。
どこまでやれていれば
できていると言えるのかは正直議論の余地は
いくらでもありますけど、これらに
イエスかノーかで答えてもらうことで
どこまでできているかというのを具体的にしていきます。
そうするとForky2の関係が見えてきた
ということですね。
続いてチームにとっても
次に何をやるべきかものさしになりますね。
では
そうですね。成績が悪いとだけ言われると
まあ辛いですけど、数値や
データを見ながら感情的にならずに深く
話し合います。まあ確かにそうですね。
親からとにかくお前のテスト点数
悪いじゃんって言われたら、まあそれだけ悪いと辛いし
なんだってなるんですけど、例えば
国語の小論文かもしくは小説の
部分の点数が低いねってなったら
その本の読み方の話をすればいいみたいな
ところで、具体的な次の
アクションまで話できるんですけど、ただただ
点数が悪いだけ言われたら、こちらとして
カチンとなってその先に進まないですからね。
18:00
はい。
これよくわかりますわ。
チームには経験値や
バックグラウンドが違う人も多く集まるので
そのあたりはチームマネジメントに
有効に使えるんじゃないかっていうところですね。
なるほど。結局そのマネジメントに対しても
数値を使うことで
この人の個性とか特性だったりでも見えてくるので
マネジメントに割と使えるんじゃないの
っていう風には思っていると。
そこまでをちゃんと義務というか仕組み化してる
ってわけではどうなんだろうね。
知ってるんだったらそれで聞いてみたいですけどね。
はい。じゃあ続いて。
数値化を通じて開発組織の
頑張りが伝わりやすくなったという話ですね。
計測結果を
フィードバックする際にはどのような伝え方を
されていますか。
これに対してデータ提供を中心とした
コミュニケーションにはしております。
深く変わる場合もありますが、前者的に
対してこうしてください
みたいなメッセージはしておりません。
レポートで
このチームはこういう取り組みをしていて
この通知が改善しましたといった事例を
紹介することはあります。または社内の
カンファレンスに登壇いただいて
取り組みの内容を発表いただくことも
ありますね。はいはいはい。なるほどね。
改善の提案を行うところまではあえて
踏み込まないようにされているんですか。
そこまでの規模で
人がいないというものもありますけど
各組織にSRAチームがあって
そこに開発生産性チームが出来上がっています。
そういったところで
推進が出来ているのでどちらかというと
データ提供のような役割分担になっています。
各チームに一人SRAチームがあるのか
各チームの中にSRAチームが
担当をしているのか
というのはちょっと分からないですけど
そこまでしっかり、少なくとも全チームに
SRAチームがいるという風に明記されているので
そこまで出来ている。なんですかね。
リソースがあるというのは結構羨ましいと
ちょっと思いました。
では続いて。チームによっては
レポートを見ても実際のアクションに繋がりにくい
などの課題はありますかという話ですね。
これらの情報は
開発の一面でしかなくて
プロダクト全体を表しているわけではありません。
プロダクトのフェーズによって
取り組むべきことも違いますから
まずはこういった情報があるということを
知ってもらうだけでも良いかなと思っています。
チームでうまく回らなくなってきたとか
システム障害が増えてきたとか
そういう時に指標となるような
自分たちの状況を客観的に知られるツールと
なることが望ましいという風に考えております。
いろいろな立場の方がいらっしゃると思いますけど
データを見ているのは主にエンジニアなんでしょうか
というところですね。
この答えとしても
やっぱりエンジニアが多いですと
ビジネスサイドの情報もうまく組み込めると
ビジネスの課題として受け止められやすいので
そうなることを望んでおりますが
なかなかそこまでは難しいかなという風には
感じております。
ただ今まで開発において
数値化されていなかった部分が見えるようになったことで
例えばビジネスサイドと開発サイドで
議論をしなければいけないみたいな場面があったとしても
開発サイドの頑張りを
分かりやすく見せられるようにもなりました。
そこは一つの進歩かなと思っております。
じゃあラストですね。
次にトライしたいのは
適切なナレッジとマッチングというセクションですね。
じゃあナレッジの共有にも
注力されておると思いますが
これも開発生産性チームが
21:00
主導されたんでしょうかというところですね。
計測するだけでは
皆さんに納得していただけなかったので
事例が必要だという風に考えて
開発生産性チームから
ナレッジを展開するようになりました。
今あるコンテンツをセシモデル化に
当てはめて準備していったという経過ですね。
ただ当初は
こちらからヒアリングをして
ナレッジを集めていったんですけど
開発習慣の大切さというのが明確になってきて
ナレッジ共有の取り組みが
トップマネジメントによってプロジェクト化され
全社的な取り組みとして推進されるようにもなりました。
なので最近は
ポストされて様々なナレッジが
集まるようになっております。
私は社歴が長いので色々なチームに
行った経験があるんですけど
組織内で閉じられたナレッジが
たくさんあるんですよね。
でもそれを自分たちでは
価値のあるものだと思っておらず
シェアするほどのものでもないと思っていたので
そういった情報がどんどん社内で
展開されていくと
より生産性が上がっていくんじゃないかな
という風に考えております。
じゃあナレッジ共有に取り組む中で
一番難しかったのはどんなところでしたかというとですね
データの可視化によって
共同化まではできていたんですけど
共出化させることが必要であると
気がつくまでは結構時間がかかりました。
たまったナレッジを再現可能な状態に
早く気づけばよかったなという風に思っています。
ナレッジが集まるようになった今でも
表出化というのが大切であるということまでは
まだ浸透しきっていないかもしれません。
じゃあナレッジ共有の取り組みについて
次のトライとして考えることがあれば
教えてください。
今はナレッジを収集できる
組織にもなってきたので
今後はそれを各チームに適切にこれを呼んでください
みたいな。もしくはやってみてくださいと
マッチングするなど自分たちができなかった
コンサルティング的な部分を
システム化できたらいいなという風に個人的には思っています。
これいい話ですね。
まさにコンサルティング的なところが
できればというのは結構重要なんですね。
たくさんのナレッジがある中で
全てを読まないといけないとなると
そこが次のボトルネックになってくると思うんですよね。
全ての人に全てのナレッジが必要ではない
わけですから最適な手法を
提供していきたいという風に思っています。
最後にこれまで取り組みを踏まえて
今後目指したいゴールについて
教えてください。
おそらくの多くエンジニアがそう思っているように
開発はとても効率的なものにしていきたい
というふうに思っています。
開発の場では人とのやりとりがずれていたとか
思考がずれていたとかそういった調整も多いものです。
それをもっとスムーズに
より効率的にしていって
エンジニアの皆さんがフラストレーションや不可なく
快適に開発できる環境を作りたいと思っております。
というところで締められておりました。
とても
勉強になりましたしとても
刺激になりましたね。
うちでもやってみたいなという施策とか考え方だったり
こういう風な流れでやっていたんだというのをすごく
感じましたので
僕らもですね
弊社も開発生産性まだ全然仕組み化できていなくて
僕がポンコツだからなんですけど
こういうですね
知見だったりとかノウハウというのを真似しながら
参考にしつつやっていきたいなという風に
強く感じました。
本記事はこれで終了ということで
明日もですね
ヤフーさんの別の記事ですけど
ヤフーでは開発人測定と品質のバランスをどう保てているか
というところも
24:00
できれば読んでいこうかなと思っていますので
今日も読んでみてください。
本日の朝カツはですけども
しかないさんと
トチュータムさんが参加されていたペイシュンさんと
スーさんですね。おはようございます。ご参加いただきありがとうございました。
また明日もですねやっていきたいと思います。
多分寝坊しないと思います明日ぐらいは。
わかんないけど。
また明日ものんびり日曜日ですけど
頑張っていきたいと思います。
じゃあ土曜日ですねゆっくり休んでいただいて
僕はちょっとこれから採用イベントの準備をしていきたいと思います。
はいじゃあ終了します。お疲れ様でした。
