＼回答があります！／

• 

  和田健太郎

  エンジニア

  2年前
  個人的な所感としては「観測してない」というよりは、「観測しようとしたけど力尽きた」を私の知り合いの中では見ることが多いなー、と思いました。
  
  ■計測するだけでなく、チューニングにそれなりのコストがかかる
  往々にして、指標を取ってみたあとも、現場の感覚値とのズレを微調整して定義を変えたり、運用フローを変えた結果観点が変わったりすることによって継続的なチューニングによって精度の向上が必要になってくるので、途中で力尽きる。
  
  ■結局だからどうなんだ、というところの回答に持っていくのが大変
  おそらく4Keysのような指標をどこの組織でも一度は取ったことがあるものの、ビジネス側への影響を確認するには３ヶ月程度は継続して定点観測が必要だがそこまで持っていけない。
  おそらくデプロイ頻度とかリリース頻度との相関を最終的に取りたいというところだと思いますが、そこに生産性指標が効いてきているかどうかを信じたり説明し切る前に力尽きる。
  
  トップダウンで指示が降りてこない限りは現場が信じて主張し続ける構図が出来上がりやすそうなので、こういうのもあるのかなと思いました。イチ意見です。
  view数 13
  • 1
  • 1

• 

  山本隼汰

  エンジニア

  2年前
  弊社では、ほぼ私の趣味で開発の生産性をトラッキングしまくっていますが、ふと振り返って他の企業でできるか？と言えば難しいだろうなと思うことが多いですね。例えば、弊社で計測している代表的なものは、不具合発生率, テストカバレッジ（E2E, integration, unittest), LCP, FCP, レスポンスタイム, チームのキャパシティの予実, スプリントのベロシティ, などがあります。が、それらを経営目標に持ち出すことはしないようになるべくしており、チームの状況を構造的、多面的に理解するために用いています。
  
  単一の指標のみを用いると、わかりやすい反面その指標にとらわれて本質を見失う可能性があり、あえてさまざまな指標を同時に計測して、相互関係を見ながら課題解決に取り組むようにしているのですが、そうすると、一気に事象の複雑度が上がってしまい、慣れていないとおそらくかなりハードルの高い作業になる気がしています。それくらい複雑度の高い作業をしているのだからしょうがないと言えばそうなんですが、誰しも最初は「わかりやすくてシンプルに効果が出るもの」を求めたくなりますし、その意味では開発の生産性を計測して効果が出るまでにかなりリードタイムとコストをかけないといけないという点で、めんどくさいのかな...？というか大変だろうな、と思います。
  view数 8
  • 1
  • 1

• 

  Dai Fujihara

  プロジェクトマネジメント

  2年前
  私はアジャイルコーチとして、いわゆる開発チームの生産性を高めるような仕事をしています。
  
  おっしゃるように、ほとんどの企業さまは見てもいない、定義もしていない、計測もしていないです。
  
  なぜそうなのかは、状況に応じて色々あるのですが、最近ふとおもったことを共有させてください。
  
  ■ 生産性を計算するコストが大きすぎる
  
  できない理由のひとつです。ソフトウェア開発において、「決められたものを作る」従来のやり方であれば、作った量、すなわちコード量をトラッキングすれば、ある程度の「出力量」がわかります。
  
  しかし、コードというものは芸術性を含む成果物でもあるため、できるエンジニアは短いコード、効率の良いコードを書くため、単純な出力量だけで生産性を定義できません。
  
  また、たくさん書けるエンジニアほど、バグを生み出すリスクも増えます。よって、量が多いから品質がいいとも言えないため、これまた出力量だけで生産性を定義できなくなります。
  
  そこで、「コードの効率の良さ」、「コードの視認性の良さ」、「コードの重複度」、「コードの複雑度」、単位コードで生み出されたバグの数・・・など、変数を追加すれば、我々が求める（であろう）生産性に近づけるようになります。
  view数 6
  • 2
  • 2
  • 1