開発者の生産性を測定するための5つのヒント

開発者の生産性を測定するための5つのヒント
コンピューターで作業する Angular 開発者。
画像: StackCommerce

テクノロジーは現代の職場のあらゆる側面に浸透しています。運用コスト、セキュリティ、コミュニケーション、従業員満足度、そして顧客基盤はすべてテクノロジーの要素です。賢明なCIOは、優れたIT組織と強力なビジネスパフォーマンスの間には直接的な相関関係があることを知っています。

参照: Agile および Scrum のスキルを習得して生産性を向上させましょう。

テクノロジーリーダーとして、チームの進捗状況を測定し、正しい方向に向かっているかどうかを評価できるようにする必要があります。測定できないものを改善することはできません。

ジャンプ先:

  • 従来の測定方法の欠陥から学ぶ
  • ソフトウェア配信を測定するためにデータ主導のアプローチを採用する
  • チームのパフォーマンスに影響を与える他の要因を考慮する
  • パフォーマンスデータを評価するための時間を確保する
  • パフォーマンスデータに基づいて変更を推進する

従来の測定方法の欠陥から学ぶ

技術チームの成果を評価するのは難しい場合があります。チームは個人の集まりです。そしてIT組織の場合、各個人はそれぞれが個別に複雑なタスクを遂行しています。長年にわたり、ソフトウェア開発チームのマネージャーは生産性を測定するために様々なアプローチを試みてきましたが、その多くは2つの根本的な欠陥を抱えています。

  1. 結果ではなく出力に重点を置きます。
  2. チームよりも個人を重視します。

これらの欠陥のあるアプローチにより、有意義な生産性指標を提供できないだけでなく、チームの士気の低下につながる可能性のあるいくつかのアンチパターンが発生しました。

コード行数

開発者の生産性を測る上で最も有名で、かつ最も嫌われている失敗例の一つは、おそらくコード行数を数えることです。開発者が記述するコード行数と、その開発者が組織に提供する全体的な価値との間には、ほとんど相関関係がありません。

実際、開発者にコード行の記述に対して報酬を与えると、コードが肥大化し、最終的には維持コストが高くなります。

速度

ソフトウェア開発におけるアジャイルの普及に伴い、アジャイルコーチの中には、チームの生産性を測る指標としてベロシティの使用を推奨する人が出てくるでしょう。個々の貢献者のベロシティではなく、チームのベロシティこそが、ワークロードを計画する上で有用な指標です。

しかし、生産性の指標としては不十分です。速度と生産性を同一視すると、開発者は見積もりを水増ししてしまい、チームの有効性を誤って評価するだけでなく、キャパシティプランニングにおける指標の有用性を損なう可能性があります。

利用

多くのコンサルティング組織では、開発者の稼働率、つまりコード作成に費やした時間を生産性の指標として用いています。しかし、これは二重の欠陥を伴います。努力が必ずしも成果につながるわけではないことは周知の事実ですし、この指標はプロジェクトマネージャーに開発者の稼働率を100%に維持する動機を与えてしまうからです。

数学における待ち行列理論によれば、稼働率が100%に達すると、リードタイムは無限大に近づきます。これは、稼働率が100%のリソースには、革新、改善、あるいは変更を行う余地がないためである。

ソフトウェア配信を測定するためにデータ主導のアプローチを採用する

2018年、ニコール・フォースグレン、ジェズ・ハンブル、ジーン・キムは『Accelerate』を出版しました。この報告書には、2,000以上の組織から集められた23,000件以上の回答をクラスター分析したものが含まれています。彼らは、データの中に4つの共通点を発見し、ソフトウェア開発チームを高業績チーム、中業績チーム、低業績チームに分類する上で役立てています。

  • 変更のリードタイム:コードがコミットされてから本番環境で実行されるまでにはどれくらいの時間がかかりますか?
  • 展開頻度:チームは実際の顧客ベースにどのくらいの頻度でソフトウェア更新を配信していますか?
  • 平均復旧時間: 本番環境で障害が検出された場合、チームがサービスを復旧するのにどれくらいの時間がかかりますか?
  • 変更失敗率:実稼働環境への変更のうち、その後修復が必要となる変更の割合はどのくらいですか?
測定優秀な人材中堅企業低パフォーマンス
変更のリードタイム1時間未満1週間から1ヶ月1週間から1ヶ月
開発頻度オンデマンド(1日に複数回)週1回から月1回週1回から月1回
平均回復時間1時間未満1日未満1日から1週間の間
失敗率の変更0~15%0~15%31~45%

表の出典: Accelerate、IT Revolution 2018 発行。

チームのパフォーマンスに影響を与える他の要因を考慮する

厳密にコードベースの測定基準の他に、ソフトウェア チームのパフォーマンスを評価するのに役立つ文化的要因がいくつかあります。

  • チームメンバーは積極的に情報を求めています。
  • 悪い知らせを伝えた伝令は罰せられない。
  • 責任は共有されます。
  • 部門間の連携が評価されます。
  • 失敗は改善の機会として扱われます。
  • 新しいアイデアはいつでも歓迎します。

パフォーマンスデータを評価するための時間を確保する

チームのパフォーマンスを示す指標がわかったら、CIOとして、測定のためのダッシュボードを構築するための時間とリソースを確保する必要があります。必要なデータは単一の場所から得られるとは限らないため、複数のソースからデータを収集・変換し、TableauやPowerBIなどのカスタム可視化ツールを使用して提示する必要があります。

まずはシンプルに始め、最も価値を得られるところから拡張していくのが良いでしょう。多くの場合、必要な定量データのほとんどは、バージョン管理システムやコードパイプラインのAPIから取得できます。より定性的な指標が必要な場合は、四半期ごとのアンケートの活用を検討してください。

パフォーマンスデータに基づいて変更を推進する

結局のところ、組織が継続的にデータを確認し、それを使用して軌道修正を行っていなければ、たとえ少量のデータと指標を収集しても、無駄な労力になります。

個々のチームに任せれば、ある程度の優秀さは得られるかもしれませんが、組織として定期的に指標を確認し、洞察を収集し、データに基づいた変更を推進するための時間を確保することが、高パフォーマンスの IT 企業になるための最も早いルートです。

Tagged: