はじめに
今回は以前開催された開発生産性カンファレンスに現地参加したのでレポートを記載します。昨今注目の集まる分野で自分自身も組織的な動きの改善に取り組んでおり、非常に勉強になりました。もし興味があればとっかかりとしてご覧いただければと思います。
イベント内容
本記事では、個別の発表というよりはいくつか参加した登壇の内容の抜粋と個人的に面白かったポイントや考えたことなどを記載します。
From Metrics to Mastery: Improving Performance with DORA and the SPACE Framework
登壇者
- Dr.Nicole Forsgren （『LeanとDevOpsの科学 テクノロジーの戦略的活用が組織変革を加速する』の著者）
登壇概要のDeepL訳：
Nicole Forsgren博士による、DORAメトリクス、SPACE生産性フレームワーク、およびソフトウェア開発における最新の生産性研究の活用に関する啓発的な講演にご参加ください。DevOpsのパフォーマンスを測定し、実用的な洞察を得るためにDORAメトリクスを使用する方法を発見してください。DORAとSPACE生産性フレームワークの類似点、相違点を学びます。文化がソフトウェアデリバリーと生産性に与える影響を探ります。また、ハイブリッドワークモデルやGitHub Copilotのようなツールを取り上げた最新の生産性研究について学びます。この講演では、ソフトウェアデリバリーを強化し、生産性を向上させ、進化する開発の状況をナビゲートするための実践的な洞察を得ることができます。Nicole Forsgren から学び、あなたとあなたのチームの仕事を最適化するこの機会をお見逃しなく。
内容としてはDORAだけでなく、SPACEフレームワークについて概要も紹介いただき、指標をいくつか用意して研究する中で見るべき指標/見るべきでない指標についても見えてくると語られていました。DORAで改善すべきボトルネックを特定し、SPACEで何を改善すべきか、メトリクスに何を使うべきかを特定するという使い方が良いようです。単に自分のPJの状況をDORAのメトリクスで確認する際は以下のサイトで確認することもできます。
DORAでは、単に行動量やアウトプットだけにフォーカスしているので、SPACEフレームワークで仕事の中断や文化、コミュニケーションについて個人の満足度を確認することの重要性が語られていました。
公演では紹介されていませんでしたが、以下の記事がSPACEを理解する上での参考になりました。
SPACEを図るためのプロダクトも紹介されていました。以下の「SPACE GooDay Project」です。このプロダクトによってミーティングのデータとGitHub上のデータを使い、SPACEフレームワークのメトリクスがどういう状況か調べることができます。
実際に調べれると「1日の間にたびたび作業中断がある人」が「素晴らしい日だと感じる」のは7%しかおらず、逆に「1日のうち中断がないか、ほぼない人」は「素晴らしい日だと感じる」割合が82%という調査も語っていました。これは直感とも一致する内容で、組織の現状をチェックするために使えるフレームワークだと感じました。
詳細が気になる際は、以下のレポートでも同様の話が語られていたのでご確認ください。
次の話ではトヨタや自動車業界、Amazonを例に挙げ、言葉でなく行動や言い合える文化やメトリクスを使うことで誰でも改善活動が進められるという例も挙げられていました。勝手にA/Bテストをするのは驚きましたが、メトリクスをとっているからこそ改善例と結果が示せるので、この部分の透明性が誰でも改善を進める足掛かりにできるのだと感じました。
最後に今後注目すべき2つの論文も軽く紹介されていました。1つ目は「Reading between line: Modeling User Behavior and costs」で、昨今のGenerative AIによるコード記述支援をどうやれば効率的に使えるのかを研究したレポートです。AI支援によってプログラミングだけでなく、レビューについても変わっていくことが紹介されていました。
2つ目は「Te best both worlds unlocking potential of hybrid work for SF」です。昨今のリモートとオフラインを合わせたハイブリッドワークによって、どんなユニークな課題が生まれているのかを調査したレポートです。
どちらもネット上で無料で読むことができたのでリンクを記載しておきます。
感想としては、DevOpsの科学で止まっていてSPACEフレームワークなどの存在は知らなかったのでこの考え方も今後の改善に取り込んでいきたいと考えられるような内容でした。動画などは残っていないのですが、登壇者の別の記事やレポートなどはネット上にいくつもあるので探してみてください！
フロー効率を重視して「2年半でエンジニア2名→35名」の急拡大組織で高い生産性を実現した話
登壇者
- 株式会社SODA VP of Engineering 林 雅也 様
こちらについては以下で別途レポート記載しているのでご確認ください。
大手企業の開発内製化事例 〜東急×KINTOが語る内製化の3ステップ〜
登壇者
- 東急株式会社 VP of Engineering 宮澤 秀右 様
- KINTOテクノロジーズ株式会社 取締役副社長 景山 均 様
モデレータ
- ファインディ株式会社 事業イネーブルメント室 エンタープライズ事業推進 佐藤 周治 様
登壇概要
KINTOテクノロジーズ社では2019年から開発内製化を掲げ、約3年で300名規模の開発組織を作ってこられました。一方、東急株式会社では、URBAN HACKSというブランディングを取り、1年で50名以上の採用や特殊な委員会活動を活かしたユニークな開発組織を築かれています。 本セッションでは、両社ともに、大手企業における開発内製化という取り組みにおいて、0から1、1から10、10から100の開発組織のフェーズに分けて、どのような点を意識して組織作りに向き合われたのか、その苦労や生産性における取り組み、また今後の展望についてお話しいただきます。
いくつかのテーマについてそれぞれの会社の視点で語られていました。
開発内製化組織作りと開発生産性
東急としては、交通/不動産/生活サービス/ホテルなど様々な事業を展開しており顧客接点の量が多いので、ユーザサービスの改善がDXによる変革に繋がるという仮説で、内製化は手段として取り組んでいると語られていました。5~10人にいれば成果を出せる確信はあったので、いきなりは増やさずブランディングなどにも気をつけたそうです。
KINTOとしては、内製開発がなぜ必要なのかを幹部向けに3ヶ月ぐらい話しをして、マネージメント陣よりは社長側など経営陣に何度も話をしたそうです。こちらもまずは自分の周りから人数を増やして、20人ぐらいの部隊と作って行ったそうです。
両者とも急に組織を拡大するのではなく、小さくチームを初めて成功体験を作りながら進めるような動き方をされている印象でした。
成長期の課題
東急としては、現状がここにあたりマネジメントなしで組織を運営しており、地方自立する分散型、フラットな組織になってうまく行っている。ただ、さらに拡大した際にこのままうまくいくかは疑問があるという話がありました。
KINTOとしては、事業会社から生まれた子会社なので事業サイドに内製開発部隊との付き合い方を教える必要があった。最初想定した機能は、不要になる場合も多いので、小さく切って早く作るようにして生産性が高くなると語られていました。
フラットな組織づくりによる自立分散、素早く小さく価値を提供するというお手本のような組織文化や作り方について聞くことができ、リーンやスクラムの考えた方を深く実践されているように感じました。
成熟期の課題
両社ともまだ成熟期は迎えていないとおっしゃっており、今後訪れた際の懸念や残していきたいことについて語られていました。
東急としては、「エンジニアの理想郷を作る」という思想は今後も貫きたい。信頼などあり楽しい方が生産性が最大になるはずという仮説のもの進めていきたい。今後は新卒/インターンなども混ぜつつ自己自立組織を生かしていくかがテーマになりそうと語られていました。組織の拡大に当たっても、ポイントとしてはボトムアップで新しいツールを使えるところが重要だと語られており、承認だけは行うスタイルで実施されているそうです。
KINTOとしては、SIや堅めの企業出身向けに内製開発スタイルという働き方を言語化した。最先端のテクノロジーを追いかけて、プロダクトを作り 現場の皆さんがこだわっていることも大事にするという話をされていました。開発生産性に対しての取り組みと組織作りの課題は残るので、技術の標準化はしないがPJの見えるかには現状も取り組んでおり、報告してもらうのではなく勝手に見えるスタイルにしていて、ここでFindy Team+を活用されているそうです。
自分としては、事業会社の開発内製化の組織拡大によくある問題やまず初めにどう進めていたのかという話を聞くことができ参考になりました。特に標準化はしないために、PJの見える化には取り組んでいるという話は印象的だったので、自分の組織でも考え方を取り入れたいと思えました。
メルカリ×DeNAの考える開発生産性とは？〜専門チームが推進する可視化の取り組み〜
登壇者
- 株式会社メルカリ Platform DXチーム 星野 将 様
- 株式会社 ディー・エヌ・エー 品質本部品質管理部 SWET第二グループ 片山 大樹 様
- 株式会社 ディー・エヌ・エー 品質本部品質管理部 SWET第二グループ 田熊 希羽 様
モデレータ： ファインディ株式会社 Findy Team+事業部 マーケティングチーム 山口 優也 様
こちらは以下のイベントで話した内容と話しきれなかった内容も追加で話していただいていました。
資料は以下とほぼ同様のものを使われて話されていました。
【メルカリ様×DeNA様】何を計測すべき？開発生産性可視化のWhy-What-How
登壇の途中で開発生産性の可視化について参加者向けにアンケートがあり以下のような結果でした。印象としては検討している方が多く、測定は思っていたより内製で取り組んでいる方も多い印象でした。
アンケート：票数：65
- 可視化の取り組みを検討している：40%
- 内製で取り組んでいる:33%
- 外部ツールを用いて取り組んでいる:21%
- 可視化に取り組む予定はない:6%
内容としては、メルカリでは、ビジネスグロース、そのための源泉に開発力があると考えて可視化について取り組んでいる。DeNAではDev-vitalチームという組織があり、Pocochaのチームの中で開発生産性を見える化することで課題を明確化して、効果的なアクションを打てるようにし、課題の予防・早期発見・改善できている状態を目指していると両社の方が話されていました。
メルカリとしては、Four keysの可視化と改善をテーマとしている。改善によってデプロイ頻度の改善に跳ね返るという仮説からサブKPIが見えるのではという仮説を立てているそうです。全社的にツールを統一しているのでDevStats Productを自作しており、ツール上で取るべきメトリクスを設定し、PRのcreateとmergeその差分、merge/deployの時間差分などを取っていると話されていました。
また何もないところから始める際は、ツールでなくDORAと同じものを確認するアンケートを投げてから始めて、定性的なデータから開始し、定量的なデータの取得を進めていました。
DeNAとしては、FourKeysは一度取ったがチケット運用と合わなくて調整して運用しており、フロー効率はJira上のチケットと連動して確認していました。以下のデータを内製化したツールで取得しており、現場のメンバーと話ながら調整しているそうです。
- スプリントないで消化したポイント
- チケットのステータス
- リリース頻度
- 変更障害率/復元時間
取り組む時間としては業務の20%の時間を使っており、取り組みをOKRに含めることで組織として確保すべき時間として取り組んでいるそうです。
他にいくつかのテーマに対して、パネラーの方が話をされる形式でした。
可視化だけで終わらせないためにどうしたら良いか？
メルカリとしては、例えば心拍だけみてもしょうがない、ガソリン残量と速度だけみても目的地までに足りるかは考えないと判断できない。事業という車に対してどういう数字が必要かを考える。ビジネスグロースを最後には目指す、その際の源泉が生産性という論理で辿って考えていると話されていました。
DeNAとしては、可視化の後に、やりたかったことの背景があり自社としては継続的に改善するための可視化である。なので本来やりたかったことを進める。プロセスや設計を変えただけだと成功にはならないので、ボトルネックを特定し改善するために始めているそうです。
組織も大きい・技術的負債が多いなどで可視化するのもの難しい時は、何から取り組むべき？
メルカリとしては、ツールが統一されているので始めやすい。別会社で考えるならツールを統一するだと遠いので、サーベイするか1つのPRなら手動でもなんとかできるはず。それで気づきを得ることもできる。ただ、昔は測っていたが今はやめているものもある、d/d/dは今はとっていなく、項目の取捨選択もやっていると語っていました。
DeNAとしては、開発プロセスをそのままの可視化をしている。PFD(Process flow diagram)をまず作っているそうです。
可視化している指標を評価に紐づける場合のデメリットはあるか？
メルカリとしては、メトリクスを評価に使っていないし使わない方が良い。リードタイムを避けるためにPRを消して作り直すなど数字をハックできる。文化的に嫌なことで言うと、何もリリースしないと障害発生率が下がるので改善するはず、または障害をメトリクスから隠すと数値が上がるので個人以上のスコープで問題が起きると考えている
DeNAの方も、マネージメントの人ではないので参考程度ですが、数値が良くなるのは良いが、よくするために何に取り組んだかを評価した方が良さそうと話されていました。
当日は現場からの質問を受け付けながらその場での回答も行っていました。自分としては数値はハックできるので評価に使わない話や内製化したツールで現場に入りながら分析を行なっているという話は非常に参考になりました。
Four Keys改善のハードシングス！ NewsPicks・バイセル・はてなが直面したハードルと乗り越え方
登壇者
- 株式会社ユーザベース NewsPicks フェロー UB Research 所長 高山 温 様
- 株式会社BuySell Technologies CTO室エンジニアリング マネージャー 渡邊 直人 様
- 株式会社はてな チーフエンジニア 大仲 能史 様
モデレータ
- ファインディ株式会社 Findy Team+事業部 副事業部長 内田 博咲也 様
登壇概要：
本セッションでは、ニューズピックス・はてな・BuySell Technologiesの3社の具体的なFour Keys改善の事例を元に、Four Keysの中でもどこに注力するのかや「可視化指標を改善することの意義を問われた」「改善した先にある頭打ち」といった、改善活動を進める中で出てくるハードルにどのように向き合ったのかについてお話しします。 開発生産性の1つの指標として、Four Keysの可視化・改善を始めている方、これから向き合っていきたいと思っている方にぜひ見ていただきたいと思います。
3社の中での開発生産性の考え方や計測方法、ゴールなどについて語られていました。基本トークのみだったので話されていたことを抜粋して記載します。
かなり後方で聞いていてどなたが話したか分からなくなったのですが、聞いていて面白かった内容をせっかくなのでここにまとめて記載します。
- FourKeysで計測することでエリートチームでないのであれば何かしらの課題が見つかるはず
- PRの作成頻度を計測し3日間PRができていない人は、タスクの粒度を揃えていくことなどが重要になる。基本はストーリーポイントをわかりやすくし、1日3PR出そうを適当な目安として設定してタスク分解を行なっている。
- レビュー依頼が来た際に、即レビューか仕事をそのままやるかは人による。レビューが返るのに1日かかるのは遅いが、遅い人にヘイトが溜まると良くない。チームの振り返りで、ひとりひとりムラがあるかを見てあげている
- PRを作ったらzapierでカレンダーの予定を作って、いつまでにレビューを強制するなどやったこともあった。どんな方法でもよいが、チームとして作ったスタイルを守れるようにすることが重要
- 生産性の可視化によって課題のレベル感が変わってきた。アーキテクチャの刷新の話などをしたとき根拠を話していたが、数字で話せるようになったので、あとは何をすればよいのかだけ考えれるようになった。交渉やネゴの時間が減ってきた
高山様
- 動き始める時SREチームとデプロイを簡単にするところから取り組んだ。途中からチームが自発的にやり始めて、トップダウンからボトムアップの動きが始まったことでうまく行った。
- デプロイ頻度を大事にしているが、あげられないときもある。結構なチームでレビューを早くすることを見ているチームが多い。レビューとマージまでの時間が24hなら12hにするなどで改善を考える。
大中様
- メトリクスの計測は、スクラムチームに導入してもらった。ただ、なぜ必要なのかを聞かれる時に理由を返せないと受け入れられないので、推進する側が自分の言葉で話せないと進められない。ゴール設定はあるが、チームごとに段階を踏んで設計してあげないと何もうまくいかない。チームがそのままのフォームだと改善されないので、フォーム改善を考えて進める。
直人様
- 生産性可視化/改善のゴールとしては、いけてる組織にするは共感している。ローンチスケジュールに対してうまくいかせたいなどチームの先の目標上がるのでそこを目指している。
全体として各組織で取り組まれていた改善の内容が詳しく語られており、PRの粒度の改善などはチームとして取り組みやすいので非常に参考になり面白かったです。
480プロダクトの開発生産性指標から見えたベストプラクティス
登壇者
- ヤフー株式会社 テクノロジーグループ システム統括本部技術支援本部 システムエンジニア 安永 華七子
登壇概要
ヤフーでは3,000人以上のエンジニアが、毎日プログラムコードの変更を行いながら、サービスの新機能リリースおよびシステム改修を行っています。近年のソフトウエア開発では、ビジネスの変化へスピーディーに対応することが求められます。いかに迅速にかつサービスの品質を落とさずにお客様へ新しい価値を提供できるかが重要です。 このセッションでは、開発迅速性とサービスの品質の計測と可視化、そして、データから浮かび上がったベストプラクティスについてご紹介します。
以下のブログの内容をもとに話をされていました 。
Yahooの中では、3000人エンジニアがおり480PJが動いているので自社の中だけでデータを取って、上位チームと下位チームを分析することが可能になっており、分析した内容から傾向などを話していました。
最初の取り組みとしてはアンケートで、「トランクベース開発」「アーティファクト管理」「デプロイ自動化」「テスト自動化」「テストデータ管理」「疎結合化」がどこまでできているかを調査し、上位クラスのチームと下位クラスのチームとを比べて、上位クラスとの差分を探っていました。ただ最初のアンケートでは13項目59節と回答内容が多く不評だったので、質問を絞ったりブレがでないようYes/Noで回答できる内容に絞ったりと改善も進めていたそうです。
改善のためのアクションを取りやすくするためバランスシートを作成し、自分達の状況を分かる状況にした。アンケートで上記6項目の習慣を確認し、習慣の改善を通常業務と並行して取り組んでもらうよう進めていました。具体的には以下のような項目に取り組んでもらっていました。
- 環境変数の管理をコード管理できるように改善
- デプロイの自動化に取り組み
- 結合環境へのデプロイ自動化ができていないので、不要な作業があったのでデプロイパイプラインを改良して対応
開発生産性の改善はダイエットに似ており、体重や運動量などを数値化することで改善でき、組織の取り組みも計測することで改善できる。また計測によって暗黙知を表出させ、共同化することで、暗黙知を共有できるのではと語られていました。
自分としては、1会社の中でのPJ数が凄まじい量なのでこのような統一的な取り組みからの計測結果は非常に参考になり、取り組んでいた6つの改善は是非参考にしながら取り組みたいと思えました。
所感
イベント全体として、開発生産性カンファレンスという名の通り各社で行われた計測の仕方や取り組みの上で出た課題を吸収することができ、登壇者の方にも直接内容についていろいろ話を聞くことができとても有意義な時間を過ごすことができました。今後ここで仕入れた情報をもとに弊社で取り組んだ内容についても外部公開できればと思います。
17
