開発生産性Conference 2024参加メモ
はじめに
noteを始めたことから、Twitter(自称X)に書いた開発生産性conferenceで学んだことのメモをこちらにも記載しようと思います。
全体図
イメージとしては横軸が時間、縦軸が組織レイヤーというイメージです。
大きく分けると時間軸ラインの上側にある「経営層」、下側にある「一般社員」の2つ、細かく分けると一般社員は「マネージャー」、「エンジニア」、「間接社員」、「QA組織」の4つに分けられます
分けられた部分
経営層
売れない、役に立たない、経営戦略に沿わないプロダクトを作っても意味が無いことは自明です。そのため自社におけるテクノロジ投資の「ストーリー作り」が重要となります。中長期的にアウトカムを最大化させるため「マーケットトレンド×テクノドジトレンド×自社の強み」が重なる部分について投資します。
開発者体験向上のため、企業における環境や習慣、文化の向上に取り組む必要があります。そのためのガイドラインとして日本CTO協会のDX Criteriaは非常に有用なものです。
マネージャー
エンジニアと経営層は見ている指標が異なり、エンジニアはアウトプットを、経営層はアウトカムを見ています。言い方を変えれば成果物がアウトカムに繋がっていないときがあります。マネージャーはそれぞれの指標を合わせるため、適切に変換・接続する必要があります。結局、経営層が求めるゴール基準に達するものを作れなければ、何を作っても意味のないものになります。
「何を作らないか？」を判断し、調整することもマネージャーに求められていることです。
経営層が本当に知りたいのは「戦略的に狙ったタイミングでモノが出てくる開発組織なのか？」ということ。遅れた場合、操作可能な変数は予算しかないためリカバリを行うために人件費を投入することになるが、合わせてマネージャーや開発チームの信頼が落ちていく。信頼を落とさないために経営を納得させるだけの説明が必要になります。
エンジニア
資産を作っても売り上げにならない。作ったものを使ってもらうことで始めて売り上げになります。アウトプットではなくアウトカムを意識することが重要になります。
使ってもらうためにエンドユーザが得られる付加価値を考えた開発が必要になります。
間接社員
開発組織が抱える問題として、エンジニアが増えるほど問題も増えていきます。例えば開発組織が抱える問題としてコミュニケーション不全があり、ギャップが生まれ意思統一が出来なくなることからプロダクト品質低下につながります。
自走できるエンジニアの育成は開発生産性に繋がります。スムーズにスタートできるよう、早い段階から必要な情報をインプットし、人材育成を行います。※お話しの中では「入社前」からプレボーディングとして実施するとのことでしたが、それはアリなのでしょうか？
インプット・学習・アウトプットのプロセス・指標を定めるとともに、アウトプットと繋がる評価テーブルを作成します。合わせて現在のスキルを確認、次のスキル目標を定め、市場価値の高いエンジニアの育成を行います。
目標設定のお話を出すと、以前Twitterエンジニア界隈で燃えた「目標管理はクソ」のお話が出てきますが、これは、高いレベルの組織や評価制度、そして文化があってこその取り組みなのです。
すべての人に深く文化が浸透しない、納得されていないレベルまで人が増えたとき、制度が維持できるかが課題になりますので、上記のように評価テーブルを作成することは有効だと思っています。
QA組織
開発生産性を上げるとデプロイ頻度・回数が多くなるが、結果として障害が増える可能性がある。このネガティブ要素の改善・軽減の方法として、インプロセスQA、テスト自動化の2つで品質担保を行います。つまり「品質と開発生産性はトレードオフではない」ということです。
上流工程、設計、ソースコードを加味したテスト設計の実施や振り返りを行うことで学びを行うとともに、集まった観点を資産化します。職能を超えた全員が関わり、協力姿勢や課題解決を行います。
テスト観点やユースケース等のテストに関するアイテムの資産化率が低いと、毎回テスト観点やデータを作成することになり回転数が落ちます。結果としてリードタイムが長くなり生産性が落ちます。
この手のお話をすると、理想論としてDevOpsが出てきますが、認知負荷の増大が課題であり現実的ではないような気がします。いい感じに上流工程からテストを回す運用の難しさを感じます。
セミナー中にお勧めされた本
セミナー中にお勧めされた本です。
登壇資料まとめ
610様が纏めてくださっています。有難うございます。
まとめ
開発生産性が作るものは品質と信頼。
この記事が気に入ったらサポートをしてみませんか？