Closed11
開発生産性について考える
おとの自分の気づきを言語化していく
おとのはじめに
開発生産性の向上は、プロダクトの価値創出を最大化するための重要な取り組みである。
プロダクトの価値は成果によって定義される。
- 具体的なKPI達成による売上・利益の創出が価値の証明となる
- プロダクトは価値創出のための手段として位置づけられる
- 開発生産性の向上は、この価値創出プロセスを効率化する
開発生産性向上は組織全体の課題として捉える必要がある。
- エンジニアリングを起点に、企画・デザインを含めた組織全体の生産性向上へと段階的に展開する
おとの開発生産性とは
開発生産性は以下の3つのレベルで定義できる
レベル1：仕事量の生産性
タスク完了数や作業スピードなど、純粋な量（速度）を測定する。複数のメトリクスを設定し、継続的に測定することで、基礎的な生産性を把握する。
レベル2：期待付加価値の生産性
価値のあるタスクの実現と完了を測定する。次のサイクルにフィードバックを活かしながら、真に必要なものを見極め、ユーザー価値を最大化する。
レベル3：実現付加価値の生産性
実際にプロダクトを通じて得られた価値（KPI達成、売上・利益向上など）を測定する。最終的な目標であり、全員が改善のマインドを持って取り組むことが重要。
おとの開発生産性を向上させる目的
- プロダクトを通じて得られる価値を最大化する
- プロダクトのKPI達成と売上・利益の向上を実現する
- ユーザーへの価値提供を効果的に行う
- エンジニアリングのボトルネックを解消する
- 新たな課題や技術的負債の解消により多くの時間を確保できる
- 企画やデザインなど他の領域との協働が可能になる
- 単なる開発効率の向上だけでなく、エンジニアがより広い視野でプロダクト開発に関われるようになり、結果としてプロダクトの価値向上につながる
- 組織の健全な成長を支援する
- 職務満足度を高め、組織全体のパフォーマンスを向上させる
- 持続可能な開発体制を確立する
- エンジニアにとって魅力的な組織づくりを実現する
これらの目的を実現するには、単なる数値目標の達成ではなく、チーム全体での共通認識と継続的な改善への取り組みが不可欠となる。
おとの開発生産性向上による期待される効果
- プロダクトの価値創出が加速する
- 新機能のリリースサイクルが短縮され、市場への価値提供が迅速になる
- 品質を保ちながら、より多くの機能改善や新規開発が可能になる
- エンジニアの成長と満足度が向上する
- 技術的負債の解消や改善活動に十分な時間を確保できる
- 新しい技術の学習や実験的な取り組みにチャレンジできる
- 組織全体の協働が促進される
- 企画・デザインチームとの連携がスムーズになり、より良いプロダクト開発が実現する
- チーム間のコミュニケーションが活発になり、組織の一体感が強化される
これらの効果は、単にエンジニアリング組織だけでなく、事業全体の成長と持続可能性に大きく貢献することが期待される。
おとの開発生産性向上のアンチパターン
- 数値だけを追いかけすぎる
- 生産性指標を監視ツールとして使用してしまう
- 数値に表れにくい貢献（他メンバーのヘルプやミーティングのファシリテーションなど）が軽視される
- 指標のハッキング
- 数値を良く見せるための表面的な対応に終始する
- 本質的な課題解決や改善から目が離れてしまう
- 持続可能性の無視
- オーバーワークや品質低下につながる過度な追求
- チームの健康状態や職務満足度を考慮しない
これらのアンチパターンを回避し、プロダクト開発における具体的なボトルネックを特定・定量化することで、チーム全体で共通認識を持つことが重要である。
おとの意識したいこと
-
レベル2の開発生産性における大事なことを意識する
- 価値のあるタスクとは何か、そしてその判断基準となる効果（成果）をどのように設定すべきか、チーム全体で深く議論し、明確な基準を確立する必要がある
- 目的、タイミング、対象ユーザーを慎重に検討し、開発の必要性を見極める。必要性が確認できた場合は、シンプルかつ拡張性のある設計を心がけ、ユーザーフィードバックを得ながら段階的にリリースする計画を立てる。
-
小さいものでも共有する、アウトプットする文化をチームに浸透させる
- まずは自分が率先して情報共有の旗振り役となり、良い例を示す
- 定期的な技術共有や勉強会の機会を設け、学びと成長の場を創出する
- オンラインミーティングでは積極的にカメラをONにし、コミュニケーションの質を高める
- Slackのtimesチャンネルを活用し、日々の気づきや学びを継続的に共有する
- 開発生産性に関する知見や発見を記事や技術ブログとして発信し、チームの知見を蓄積する
- 外部のイベントや勉強会に積極的に参加し、得られた知見をチームにフィードバックする
-
開発生産性向上の意義を経営層を含めた全社に理解してもらう
- ビジネスKPIとの関連性を示しながら、定量的なインパクトを可視化して提示する
- 進捗や成果について定期的な報告を行い、建設的なフィードバックを得る機会を設ける
- 長期的な視点での対話を継続し、組織全体での理解と支援を根気強く獲得していく
-
持続可能な成長を実現するため、Four Keys以外にも重点的に取り組むべき指標を検討する
- プルリクエストの作成数と適切な粒度の基準
- 要件定義の文書化の充実度
- 開発者の実質的な集中時間（ミーティング時間との比較）
- 自動テストのコードカバレッジ
- 従業員満足度（1on1とアンケートによる測定）
- SPACEフレームワークに基づく具体的な指標 etc.
そして何よりも、チーム全員が開発に喜びを見出し、楽しみながら成長できる環境を大切にする
おとのその他
プラットフォームエンジニアリングの視点も取り入れ、開発基盤の整備も並行して進めたい
大事
最初から完璧なタスクリストを作ろうとしない
おとのSPACEフレームワークに関しても改めて理解したい
まずは開発生産性のレベル1の領域を改善することを目標に、どの指標を適用するか、イメージを膨らませる。
- Satisfaction and Well-being（満足度と幸福感）
- アンケートや1on1を活用し、定性的な評価をする
- Performance（パフォーマンス）
- レビュー数や安定稼働率、ストーリーポイントを活用
- レベルが向上していくにあたり、アップデートは特に必要
- Activity（活動）
- プルリクエスト数
- Communication and Collaboration（コミュニケーションとコラボレーション）
- オープンからマージまでの時間
- リソースとPJTの進行上、セルフマージも考えられるので、すぐには機能しないかも
- Efficiency and Flow（効率性とフロー）
- 開発に割ける時間（コミュニケーションコストとの兼ね合い）
- SREと協力する領域
おとのSとCをアンケートで定性的に計測したいので、以下スクラップで続きを展開
このスクラップは4ヶ月前にクローズされました