Developers Summit 2024：開発生産性の現在地点について～エンジニアリングが及ぼす多角的視点～を見て

2024年3月5日 09:28

セッションの概要

合同会社DMM.com プラットフォーム事業本部第1開発部部長兼 VPoE室兼 α室
石垣　雅人氏

開発生産性という言葉の本質に迫るセッションでした。
開発生産性をもとにビジネスにおけるエンジニアリングの課題へのアプローチ方法や可視化方法のテクニックを教示いただきました。

以下の二つの時流を抑えること。

「推測するな、計測せよ」が現実的な位置まで来たとしています。
ただし、「はじめは推測から始めた方がいい」とも。

メトリクスサービスの発展によって、さまざまな計測が支えられるになってきた。

Four KeysのパイプラインもDoraのGithubを見ると随分と充実してきたそうです。

私たちが最新の開発生産性の計測に追いつくまでにはまだまだやるべきことがたくさんありますね。
少し前に自チームの生産性の計測をしてみましたが、無駄とまでは言いませんが、色々と問題を抱えていたのは、このセッションを見てかなりすっきりとしてきました。

そもそも生産性は測れない
- Margin Fowler
  - Cannot Measure Productivity
Four Keysの数値をよくしても、悪影響になるケースもある
- デプロイ回数を増やしても、コミュニケーションコストが上がることもある
- UIを改変しまくるとユーザーは使いづらい・覚えられない…etc
DevOpsの生産性自体が、組織全体の生産性とは限らない
- サイクルタイムとリードタイムは一致しているか
- もっと複雑ではないのか

「何を計測するのか、誰のために計測するのかが大事」と石垣氏は語ります。

Four Keysについては、数字を意識しすぎると、極々小さなデリバリーで"数字を稼ぐ”ようになってしまう危険性などが指摘されていますね。

私たちのチームにそれはないと信じたいですが、そうなる可能性自体は否定できません。

そういう意味では、なんのための指標なのかは明確に定義・共通認識化して取り組む仕組みが必要だなと感じました。

これは少しわかります。いろんなパターンでデータ分析していると楽しくなってしまう瞬間があるんですよね。仕事なので「なんのために、どんな結果を知りたいか」を真っ先に定義して取り組むのはとても大事なことです。

クラウドサービスに代表されるように、エンジニアリングそのものが一般商品化してきていますね。
「あらゆる技術は誰でも利用可能な武器になった」と石垣氏も話します。

これはつまり、競争優位性としての生産性の見方で「タイミングの自由自在さ、機能優位性をどれだけ早く作れるか」で競争相手に負けていないか・勝てないかを計測する手段としての生産性計測が必要であるということです。

など、資金的にも人的にも余力が出ればエンジニアリングそのものにも余力がでることに他なりません。

会社内でも組織によって「開発生産性」そのものが持つ言葉の意味が変わるというお話でした。

組織のレイヤーによって求める意味も使われる言葉も違うため、レイヤー間で変換が必要です。

経営層は、それができる可能性があるかどうかを知り、そのためにどの程度の予算・時間が必要なのかを知ることで、投資するかどうかを判断します。
それに対してエンジニアは人月や個人あたりのスループットで生産性を測ります。

直接この話とは関係ありませんが、私の所属するチームにおいて、どこまで作るべきか問題が問われた際に、同じことを言われたばかりであったため、とても刺さるものがありました。

この記事が気に入ったらサポートをしてみませんか？