シェア
はてブ
2024年6月28日、29日、ファインディ株式会社が主催するイベント「開発生産性Conference 2024」が開催されました。本記事では、Visionalグループ 株式会社ビズリーチ リクルーティングプロダクト本部 PMO室 SODA推進グループの外山 大さんによるセッション「ビズリーチが目指す開発生産性ダッシュボード〜 データ収集の壁と乗り越え方〜」の内容をお届けします。
■プロフィール
外山 大（とやま だい）
Visionalグループ 株式会社ビズリーチ
リクルーティングプロダクト本部 PMO室 SODA推進グループ マネージャー（2024年6月現在）
SIerでエンジニアとして多くの案件を経験し、その後同社でマネージャーに転身しキャリアを積む。2016年に合同会社DMM.comに入社し、海外向けサイト、モバイル事業、豊洲のデジタルアートPRJなど、General Engineering Managerとして複数事業の開発責任者を歴任。2021年、建設DXを推進する株式会社アンドパッドへ入社し、Engineering Manager、組織開発部長などに従事。2023年、SODA構想（SODA : Software Outcome Delivery Architecture）に共感して株式会社ビズリーチにジョイン。
『「キャリアインフラ」になる』をビジョンに掲げるビズリーチ
外山：外山大と申します。本日は、「ビズリーチが目指す開発生産性ダッシュボード〜 データ収集の壁と乗り越え方〜」というタイトルで発表させていただきます。内容としては、我々が進めている開発生産性を可視化するためのダッシュボード「SODA構想」について、そしてSODA構想を進める際のデータ収集で起きた課題と解決方法などをご紹介します。
まずは自己紹介です。経歴としてはSIerでキャリアをスタートして、エンジニア、エンジニアリングマネージャー（以下、EM）と経験を積んできました。2016年にDMM.comに転職し、さまざまなサービスでEMを務めたのち、2021年にアンドパッドでEMや組織開発部長を務めてきました。そして、昨年SODA構想に共感して、ビズリーチにジョインしました。
外山：続いて、会社について説明させていただきます。今回は、Visionalとしてこのイベントに協賛していますが、Visionalグループ内の株式会社ビズリーチからの発表となります。
ビズリーチは転職サイトなど、HR Tech領域でサービスを提供している会社で、『「キャリアインフラ」になる』ことをビジョンとして掲げています。インフラというと、生活に必要不可欠な電気や水道をイメージされる方が多いと思いますが、それと同じように、働く人々が主体的にキャリアを考えて築いていくにあたって必要不可欠な存在になりたいという想いを込めて、このビジョンを掲げています。
ビジョンの実現に向けて、ビズリーチでは「キャリアに、選択肢と可能性を」というミッションを掲げています。キャリア形成において重要なのは、自分の未来に自信を持てる「はたらく」を選択し、挑戦し続ける企業とつながることだと私たちは考えています。だからこそ、キャリア形成においてたくさんの選択肢と可能性を提供して、「はたらく」を変革していきたいと思っています。
ビズリーチでは、さまざまなサービスを展開しています。社名にもなっているキャリア採用向け転職サイト「ビズリーチ」や学生向けの「ビズリーチ・キャンパス」のほか、採用管理やタレントマネジメントなどのための「HRMOS（ハーモス）」シリーズというサービスも展開しております。
開発生産性について考えるきっかけとSODA構想について
外山：それでは本題に入りたいと思いますが、前段として私が開発生産性について考えるようになったきっかけについて、お話させてください。当時、ある会社のある本部で各事業のエンジニアを統括するマネージャーを務めていました。
その本部には複数の事業部が属していて、各事業部はそれぞれ固有の事業を展開していました。各事業部がシナジーを生み出しやすくするため、本部が統括しているものの、事業部ごとの独立採算色が強い特徴がありました。事業部長は営業バックボーンの方が多く、開発経験はない方が多かったです。
こうした組織構成や役割において感じていた課題は、配置における事業の優先度をつけられないというものでした。事業をやっていると、残念ながら事業撤退となるケースもあり、そうなるとその事業部に属していたメンバーの異動が発生します。すると、その他の事業部では、みんな自分の事業を少しでも早く進めたいという思いがあるので、「うちの事業部のほうが優先度が高い！ そのメンバーをこっちにくれ！」という話が、あちこちから出てくるんですね。
それを聞いて、どの事業部の気持ちもわかるなと。ただ、そのエンジニアのリソースを使って、どれほどの価値をこれから生み出そうとしているのかが見えにくく、どう優先度をつけていいものかという悩みがありました。
外山：また別の課題として、開発組織の現状を伝える難しさも感じていました。開発現場を知らない経営メンバーから見ると、開発で起こるいろいろなトラブルに対して、例えば「またスケジュール変わった？」とか「最近、障害多くない？」「技術負債の解消って本当に必要なの？」といった疑念が上がることがあると思います。
こういった疑念に対して上手く説明ができないと、不信感がどんどん蓄積して、信頼貯金が減ってしまう。すると「外注した方が早くできるんじゃない？」とか「うちのエンジニアって本当に優秀なの？」「負債なんていいから新機能作ってよ」といった話に発展してしまいます。
こういったことに上手く対応するためには、可視化された情報をもとに、目線を合わせながら説明することが重要だと常々感じていました。そのため、開発組織以外のステークホルダーの人には、開発組織がどんな価値を生み出しているかという指標を、逆に開発組織の人たちには自分たちが価値貢献するための指標を、それぞれ模索していました。
外山：そんなときに出会ったのが、ビズリーチのSODA構想でした。SODA構想は、マネジメント関連のナレッジやスキル体系、フレームワークなどを集め、組織への実装をイメージして設計したもので、これをSODAプロトタイプと呼んでいます。
私が特に関心を持ったのは、可視化した価値をベースに意思決定をしていくEBM（Evidence Based Management）で、こういったものを取り入れて体系立てているところにすごく惹かれました。それをテーラリングして、「SODA ビズリーチバージョン」として設計し、今推進している状況です。
外山：SODAは、いくつかのサブプロジェクトで成り立っています。1つはFour Keysやケイパビリティなどを可視化するTeam Performance。それから、コードカバレッジなどを可視化するQuality Value。お客様の問題をどれくらい解決できたか、ニーズを満たせたかなどを可視化するOutcome Delivery。要求や要求仕様、リソースの状況などを含め、プロジェクトの状況を可視化するProject Value。
そして、そういったものを透明性高く見えるようにするEvidence Viewerや、改善活動で得た知見を蓄えて開発プロセスやプロダクトマネジメントの事例を定石集とするPlaybook。こうしたサブプロジェクトを進めることで、SODAプロジェクトを進めています。SODAに関しては過去にも何度かご紹介したことがありますので、もしご興味があればぜひご覧いただければと思います。
▶DevOpsDays Tokyo2022 ファクトから始める改善アプローチ 〜「LeanとDevOpsの科学」を実践して〜
https://speakerdeck.com/takabow/devopsdays-tokyo2022-huakutokarashi-merugai-shan-apuroti-leantodevopsfalseke-xue-woshi-jian-site
▶「エセ自己組織化」症候群から脱却し、約束を守るプロフェッショナルなアジャイルチームになるには -アジャイル時代のマネジメント進化論- / #RSGT2023
https://speakerdeck.com/visional_engineering_and_design/number-rsgt2023
▶ファクトから始める改善アプローチ EP2 〜 Four Keys の先にある アウトカムに向き合ってみた 〜 / DevOpsDaysTokyo-202
https://speakerdeck.com/visional_engineering_and_design/devopsdaystokyo-2023
▶開発者体験を見える化し「計器飛行」の実現を目指すSODA構想 〜事業の成長とプロダクト組織能力の相関関係を見いだすには〜 / Developer eXperience Day 2023
https://speakerdeck.com/visional_engineering_and_design/developer-experience-day-2023
▶テストだけで品質は上がらない?! エセ自己組織化した品質組織からの脱却 / JaSST'24 Tokyo
https://speakerdeck.com/visional_engineering_and_design/jasst24-tokyo
SODA構想で捉えている指標構造と、計測している指標
外山：SODAではさまざまな指標を可視化しようとしていますが、その指標構造をどう捉えているかをお話したいと思います。この図は、開発組織が関連する指標構造の縦のイメージを表したものです。最小単位が開発チームで、それが含まれるプロジェクト、プロダクト、サービス、事業、企業といった形で、下層から上層に影響を及ぼすものとして設計しています。
外山：さらに、横の構造もあると考えていて、営業指標とマーケティング指標とプロダクト開発指標、この3つに分けています。SODAではこれらを並べることで、相関関係を見出し、さまざまな意思決定に役立てていくことを目指しています。
並べて見るメリットについてお話しすると、3つの指標領域のなかで注目されやすいのは、営業指標やマーケティング指標で、プロダクト開発指標があまり見えていないことがあります。
こういった状況で、例えば顧客満足度や契約企業数が下がってきたとすると、顧客満足度を上げるためにCSに力を入れようとか、契約企業数を増やすために営業を頑張ろうといった打ち手を取りたくなると思います。
外山：しかし、プロダクト開発指標を見てみると、例えばデリバリーの変更率が下がっていたとします。お客様に約束したリリースが、ズルズルとずれてしまっている状況ですね。それを掘り下げてみると、オンプロダクト指標が下がっている。プロダクトの開発にあまり集中できていないということです。
さらに掘り下げてみると、従業員満足度のe-NPSが下がっている。よくよく聞いてみると、開発メンバーのモチベーションが下がってしまうような事象が起きていたと。そうすると、実は正しい打ち手としては、開発メンバーのモチベーションを下げた事象を取り除き、信頼を取り戻す必要があったということになります。
外山：このようにSODAでは、全体が見えることで打ち手の精度が上がるというところを目指しています。今は、この図のオレンジ色にした指標の部分が計測できていて、かなり範囲が広がってきています。
外山：我々が目指しているのは、指標を改善につなげていくことですが、改善における計測の重要性についてもお話ししたいと思います。何かを改善しようとするとき、まずは事実をもとに仮説を立て、それを実装して動かしていき、その結果を見て再び打ち手を考えるといったサイクルをまわしていきます。
SODAは、その事実を可視化する部分を担います。測定結果を見て仮説を立て、その仮説を実装した効果を測るといった形で、SODAの計測結果によって改善サイクルをまわせるようにしていきたいと考えています。ここまでがSODA構想についてのご説明です。
Four Keys編：負債解消の過渡期に理想の仕様で計測できない
外山：次は、このSODA構想を実現するために、さまざまな計測を行ってきた過程で起きた課題と、それに対する解決策についてご紹介したいと思います。紹介したい事例が2つあり、Four Keys編とオンプロダクト指標編としました。まずはFour Keys編の、負債解消の過渡期において理想の仕様で計測できないという事例から紹介したいと思います。
Four Keysの計測を始めたとき、技術的負債の解消を進めている過渡期にいました。事業会社の開発であれば、負債とは常に向き合うことになりますが、なかでも特に大きな石を砕いている時期だったため過渡期と表しています。
技術的な負債が蓄積された背景に触れると、ありがたいことに我々の事業が急成長しているという状況があります。そうしたなかで変更が積み重なっていき、ときには場当たり的な変更になってしまうケースもありました。あるあるだと思いますが、その結果としてコードのスパゲティ化が起きます。
さらに、事業運営が長期にわたって継続していくと、開発組織の人も入れ替わっていきます。そうすると、誰も見たことがないコードが増えたり、ドキュメントが残っておらず経緯を知る人がいないコードが積み重なったりして、技術的負債が蓄積していきました。
外山：こういった技術的負債を解消するため、さまざまな施策を実施しており、それについて過去に発表したスライドがあります。
本日の話題に関連するところを切り出すと、事業戦略は常に変化し続けるものであり、環境に合わせて変更に強いアーキテクチャにリアーキテクチャしていく必要があること。そして、リアーキテクチャを段階的に実施して、マイクロサービスとして切り出していくことについて触れられています。
▶ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う
https://speakerdeck.com/visional_engineering_and_design/jjug-ccc-2022-fall
こうした取り組みの過渡期では、リアーキテクチャ前と後のシステムが混在しています。そうしたなか、リアーキ後を開発するチームでは、計測の仕組みを入れるハードルも低く、計測しやすいです。
一方で、リアーキ前を開発するチームは大変で、構成やブランチ運用が複雑だったり、計測の仕組みを入れるにも既存の仕組みへの影響が大きかったりして、計測しにくい。そのため、計測ルールが複雑になったり、チームごとに分離して測れなかったりといった状況がありました。
簡略化した図で説明すると、このようにプロダクトAとプロダクトBが同じリポジトリで、かつ触るコードも入り組んでおり、それを複数のチームが改修している状況をイメージしていただければと思います。
この状況において、プロダクトAの変更リードタイムを取りたい。理想としては、この赤枠で囲った部分を取りたいけれども、プロダクトBとは分離できない。では、どうするかということで、まずは今取れるものを取ろうと考えました。
外山：プロダクト個別に取るには、リアーキテクチャして切り出す必要がありますが、リアーキテクチャは一朝一夕に終わるものではありません。レガシーシステムも常に開発を重ねていて、事業展開として重要なものですし、レガシーシステムの開発力も改善を重ねていく必要があります。
そこで、まずは分離できないプロダクトAとプロダクトBの密結合な部分ごと計測することにしました。この赤枠で囲った大きな部分ですね。なぜなら、この密結合になっているプロセスにボトルネックがあるという仮説があったからです。それを紐解く仮説検証という意味でも、この大きな枠ごと取る意義はあるだろうと考えました。
それから、プロダクトAだけの左上の小さな赤枠の部分も取りました。小さな改善の積み重ねが見えにくくなっていたので、それを打開するためです。
外山：結果として、レガシーシステムの改善が着実に進んでいます。ボトルネックの1つだと考えられた統合テストを廃止し、チームごとにテストを実施するといった施策を行うことで、デプロイ頻度の向上を目指す動きがありました。
また、大きなボトルネックに隠れて見えにくくなっていた改善効果を可視化することで、改善への取り組みのモチベーションも向上しました。大きな枠でボトルネックの解消ができているかどうかと共に、左上の小さな枠でのプロセス改善の効果も見ることができるという状況になっています。
オンプロダクト指標編：工数入力が定着しない問題
外山：次にオンプロダクト指標編として、工数入力が定着しない問題についてもご紹介したいと思います。まずオンプロダクト指標とは何かというと、EBMガイドでは、「チームがプロダクトと価値に費やす時間の割合」だと説明されています。
これが明らかになると、DevEX（開発者体験）の3コア・ダイヤモンドにおける「フロー状態」、つまり開発者が開発に集中できる環境であるかどうかがわかります。ここを可視化して、改善できる環境を整備するためには、工数をどう使っているかを収集することが必要になってきます。
外山：もう少し背景をお話しすると、同時期に工数の会計処理を効率化するためのツール導入を検討していました。オンプロダクト指標と親和性の高い目的だったので、同時に実現できる方法を導入することを目指し、CrowdLogというツールの導入が決定しました。
私も過去に、工数入力をする立場、工数入力を推進する立場、工数入力を設計する立場と、いろいろ経験してきました。そんな私から見て率直に、工数の入力は定着しにくいという実感があります。
定着しない原因として、1つには入力する意義がわからないことが挙げられます。やはり効果が感じられないと協力を得にくく、入力する人と使う人が違うケースや、効果が出るまでに時間や工夫が必要なケースなどは、なかなか協力を得るのが難しいと思います。
これを打開するために行った打ち手としては、まずは入力する意義を伝えること。その工夫として、聞く人の関心事に合わせて意義を強調して説明しました。例えば、マネージャーに対しては、スイッチングコストの作業効率への影響、会計処理の責務や集計コストの軽減、工数実績の蓄積による予測の立てやすさなどを中心に訴求しました。
メンバーに対しては、実感が伴う課題として、例えば割り込みが発生すると業務への影響が大きくなるから、そこを可視化して解決につなげたいとか。そういった部分を訴求していきました。
外山：さらに、もう1つの工夫として、チームごとにオフラインでの説明を行っていきました。メラビアンの法則では、コミュニケーションにおいて言語情報が7%、聴覚情報が38%、視覚情報が55%の影響を与えていると言われています。
リモートでもこちらの声や表情などはある程度伝わりますが、オフラインのほうが受け手側の反応をつかみやすく、話すスピードや間の取り方を調整したり、受け手側に話を振ったりできることが大きいです。さらに、普段仕事をしているチームの中に入って説明することで、ホーム感があって気軽に質問しやすい環境になります。
外山：定着しない原因のもう1つは、入力が面倒なこと。どんな作業をしたか記憶を辿って入力するのは、なかなか面倒ですよね。ですが、収集する側としては、せっかくツールを導入するのだから、あれもこれも取りたいと考えてしまいます。
しかし、収集の対象を増やすと入力項目も増え、手間が増えると入力が雑になって、結局入力しなくなってしまいます。これに対しては、入力項目をなるべくシンプルにするという工夫をしました。
外山：たくさん取りたい気持ちをぐっと抑えて、収集項目の優先度をつけます。最重要の項目、今回でいうとオンプロダクト指標と会計処理をピン留めして、1日分の入力を2分程度で収めるように設計しました。
毎日の入力を推奨しつつ、1週間に一度リマインドします。もちろん毎日入力してくれる人もいますが、リマインドのタイミングで入力する人も結構いると想定されたので、その人たちが10分程度で入力できるものを目指しました。
そして、手入力する項目をなるべく減らします。CrowdLogにはカレンダーや勤怠システムとの連携があるので、それをマネージャーが必ず行うようにフローを構築しました。また、勤怠管理システムとの連携にはコーポレート系の部門が関係してくるので、関連部門とのさまざまな調整も行いました。
結果として、入力率は80%くらいになりました。262の法則では、成果を出す2割、平均的な6割、意欲の低い2割と言われますから、80%は合格点だと考えています。本来の目的であるオンプロダクト指標では、割り込み作業や開発以外の作業の割合も、このように可視化できるようになりました。
外山：次に、計測時に注意していることをご紹介したいと思います。「スコア良すぎない？問題」と名付けたのですが、計測はハックが容易なものが結構あるので、肌感と比べて良すぎる結果には要注意です。「こんなこと起こっていませんか？」という内容をいくつか挙げますが、これは経験事例ではなく一般論での内容です。
例えば、工数を収集したら開発に対する工数の割合がものすごく高く、開発以外の不明な工数もほとんどない。開発に全集中できているようだと思いたいところですが、もしかしたら入力が面倒で、適当に入力されているかもしれません。
他にも、エンゲージメントの点数が非常に高かったら、組織が良い状態だと思いたいところですが、点数が下がると理由を問われたり、無言の圧力を感じたりする状況がなかったか、気をつけなければなりません。
それから、プルリクが増えて開発が活発なようだが、リリース回数は変わらないといった謎のスコアですね。これはもしかしたら、プルリク数が人事評価に使われているために、細かいプルリクを乱発して数を増やしているのかもしれない。そうなると、結果的にレビュアーが疲弊してしまう可能性があります。
謎のスコアとしてはもう1つ、金曜日になるとコメントやプルリクがピタッと止まるケース。これは土日が変更リードタイムに含まれるとスコアが悪くなるので、ローカルで保留しているのかもしれません。このように計測結果にこだわりすぎて、本来の目的からそれてしまう状況は避けたいですよね。
こうしたことが起こらないように、計測数値は単体で見るのではなく、本来の目的とセットで見ることを大事にしています。例えば、Four Keysの計測では、Four Keysの結果だけでなくケイパビリティも獲得できているか、オンプロダクト指標では、オンプロダクト指標だけでなくFour Keysも上向きになっているかなど、合わせて見ていくことが重要だと思っています。
SODAの活用シーンを増やし、改善サイクルの定着と加速へ
外山：次に、今後の展開についてお話しします。今後はSODAイネイブリングと名付けて、SODAを浸透させつつ、活用シーンをより増やしていきたいと考えています。
対象を経営層だけでなく、マネージャーやメンバーにも拡大するため、オフラインで各チームにSODA構想の意義を訴求してきたなかで、どうやって活用するのかといった相談が増えてきました。
そのため、そうした相談に対応する形で、開発現場の課題解決とセットで提供していきたいと思っています。そして、改善効果の計測として活用し、改善サイクルの定着や加速を目指していきます。
外山：それでは、まとめです。今日お話ししたことは、大きく4つです。SODA構想では、判断精度の向上を目指しています。プロダクト開発組織が事業成長に貢献するためには、開発組織自体の判断精度を向上させる必要があり、SODA構想はその判断材料を可視化するものです。
次に、Whyを丁寧に伝えること。データ収集は、データ提供側にとっては負担になることを意識する必要があります。協力者の関心事を踏まえてWhyを丁寧に伝え、協力してもらうことが重要です。
また、収集仕様は目的にこだわること。データ収集は、理想通りにいかないところもあります。そのため、最初から理想の測定仕様に固執せず、取れるところから取ることで、できる改善も多くありました。
そして、本来の目的を忘れずに見ること。数値化すると、数字を良くすることに注目してしまいがちですが、数字だけに注目すると思わぬ落とし穴もあります。本来の目的を常に意識しながら、データを見ることが重要だと感じます。
外山：最後に、VisionalのEngineering BlogやXでも、本日の資料を含めて情報を発信していますので、もしご興味を持っていただけましたら、ぜひご覧ください。発表は以上になります。ありがとうございました。
▶Visional Engineering Blog
https://engineering.visional.inc/blog/
▶Visional Engineering X
https://x.com/VISIONAL_ENG
アーカイブ動画も公開しております。こちらも併せてご覧ください。
本記事の登壇資料はこちら。
https://speakerdeck.com/visional_engineering_and_design/dev-productivity-con2024
