第7章 エンジニアリング生産性の計測
7.1 何故エンジニアリング生産性を計測すべきなのか
「人月の神話」のブルックスさん亡くなられましたね。
!
社会科学の専門家を入れているのすごくいいなー。ソフトウェア企業でも、社会科学をはじめとした専門家を採用したり、一つのキャリアパス構築する話がもっと増えるとよさそう。
7.2 トリアージ:そもそも計測するほどの価値があるか
計測はそれ自体に高いコストがかかる。
単純に「コストがかかる」と表現するのではく、「高いコストがかかる」と表現しているところに強い意思を感じた
これはリーンスタートアップ?とかでもあるなーっていう。メトリクスとかKGIとかKPIとかあるあるというか。行動が変容しないメトリクスは意味がないっていう。。。 まさに7.3の内容というか。
Four Keysを最近測り出している企業が多い印象があるが、計測が企業のPR(=企業の開発体験が良いと思ってもらう)目的だけになっている企業も多いという話を思い出した。
以下それぞれの面を検討するよう求める
シンプルに「PDCAのCとして機能しているか」という話な気がする
7.3 ゴールとシグナルを伴う、意味のあるメトリクスを選ぶ
GSM いいですね、覚えた
GSMってGQMからインスパイアされてつくられたんだろうな。きっと。GQMといえば鷲崎先生だ。
生産性って言うとすぐSTEP数とか画面の数とかを言うマネージャーがいるから段々とその言葉が胡散臭くて嫌いになった
スクフェス札幌でkiroさんが言ってた生産性がビジネス価値≒KPI的なもの になるってのは納得
街灯効果(streetlight effect)を防げるというものだ。
日本語で「街灯効果」とググっても出てこないっぽい 日本語では同じような意味を他の言葉で表現していたりするのだろうか
ゴールとメトリクスの間にシグナルを挟むのいいな。本にあるように街灯効果を避けることができるのもそうだし、巷でよく言われているようなHOW(計測可能なデータ)に飛びつかないことにも繋がる
7.4 ゴール
ゴールはQUANTSという要素から検討する
Quality of the code
Attention from engineers
Intellectual complexity
Tempo and velocity
Satisfaction
QWAN = Quality Without A Name = 無名の質 = アレグザンダー提唱のやつ
7.5 シグナル
計測はできなくても、判断は自明なものがシグナルかと思っていたので、例には少しもやっとした。(最後の例の、「価値があるとみなしている」とか。)
7.6 メトリクス
三角測量的に割り出す
複数の指標から仮説をたてることへのすごく良い例え
数値がそのまま実情を表すわけではない
単一の数値のみを指標にすると数値ハックが横行する
「数字は嘘をつかないが、嘘つきは数字を使う」のは、数字は背景のシグナルを踏まえないからそこにミスリードの余地が生まれることによる
リーダビリティについては、質の低い代用品を用いて場合によりその代用品に基づ く決定を行うか、もしくは現在計測不能であることを単に認めるかという、いずれかの決定を我々 は下すことになった。
こういう「できない」ということを認める判断って、計測するという作業だけが評価に結びついてると難しいだろうなあと思った
指標を設定するための試行錯誤って実行されにくい気がする
計測の大事さは認識されていても難しさはあんまり認識されてない
学術書はコード品質の代用品となるものを多く提案しているが、そのどれもコード品質を正確に捉えてはいない
本章の主題からは外れているが、めちゃくちゃ気になった。「正確に」の基準が厳しいが故の記述なのかな。(代用品がたくさん出ちゃっている時点で品質を正確に捉えることはダメなんでしょ、みたいな)
少し後ろに「コード品質を定量的計測手段として取得することは~」とあるので、「正確に」は「定量的に」の言い換えなのかも
7.7 メトリクスの検証にデータを用いる
定量的メトリクスは文脈もナラティブも全く提供しない。(中略)定性的調査だけがその情報を提供できる。
定性的調査は調査側のバイアスに影響されることが多くて二の足を踏んでしまう、と書こうと思ったらすぐ下にバイアスを排除するための手法にした旨が書いてあった(プロの仕事すぎる)
想起バイアス・最新性バイアス→利用可能性ヒューリスティック
サンプリングバイアス→生存バイアス
バイアスを全て排除することを試みるのではなく、存在を認識しておくだけなのはGoogleらしいし、すごくいいなと思った。
表7-2めっちゃ便利だ。こういう議論の土台になるものがあるのいいな。
こうしたメトリクスを、エンジニア個人の評価や、場合によっては成績が優秀な者と成績が悪い者の特定にすら用いたくなる誘惑が存在する。しかし、そのように用いることは非生産的だろう
注釈にいいことが書いてあった。「測りすぎ」の本にも通じるけど、低い信頼を補うための計測になった瞬間、一気に機能しなくなるようなあ
「こういう効果/改善をするために計測しているんですよ」という話がないと、ここで言われているような個人評価のための計測になってしまうリスクが高くなりそう。そういった意味でも、計測結果をもとに何らかの改善を行うことを最初に明確にしておくのは大事そう
計測をしている側がその気はなくてもメンバー側が人事評価の指標(=目標設定)にしてしまう場合があるので、ICが個人の成長を計測できるような代替案を用意しておいた方が良い(実体験)
7.8 行動に出ることと結果の追跡
推奨事項は「ツール駆動」であることが理想的である
さらっと書いてあるが、とても大事なこと
人間を変えるのではなく仕組みを変える
7.9 結論
人間に基づく問題をどのように扱うのかが章全体を通してわかってよかった。
7.10 要約
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
中長期的に採算が取れることが計測できるビジネスを有しているから。スケール云々の前に価値があるかどうかわからないようなプロダクトを作っているような状態だと、エンジニアリング生産性を上げる引力が小さくなりがち。
この本があるのになぜ実践する企業はすくないのか?の質問とも繋がるが、計測の目的が根本的に違うから。誰かがやりたい行動の説明のために計測を求められることも多く見かける。
現場でどこまでできているか?
ゴールをまず定義して、そこに対してメトリクスを当てるという順番は意識していた。
一方で、本書のようにシグナルは定義してなかったので、せっかく先にゴールから考えたのに、知っているメトリクスを測るだけ、みたいな状態に陥ることはあった。
Four Keysを導入する現場は増えているように感じる(それを支援するツールも複数ある)
よくできた指標ではあるが、背景にあるシグナルを理解しなくても使える指標
導入する側はシグナルを理解して改善に努めることで、この章でやっているようなシグナルを見出してメトリクスを定める壁打ちになりそう
この本があるのになぜ実践する企業はすくないのか?
他のチームからの要望にもNoを回答できる、独立した専門性の高いチームを作るのにかかる難易度が高すぎるから?(評価や人事などの制度設計や、感情的な側面において理解を得る難易度的な意味合い)
読んでてかなり開発サイドからヘイトを買いそうだな... と思ってしまい、実践できるイメージが全く湧かなかった
「認知バイアスを可能な限り排除したメトリクスの設定」なんてプロにしかできないよ
自分もこれだなあと思った。社会学者を採用できる余裕やこれだけ重いプロセスをやる余裕はあるのか・・?という
これを言ってしまうと元も子もないのですが、今年のRSGTのクロージングキーノートにてMSでエンジニアとして働かれている牛尾さんが言ってた日本の企業との違いが頭をよぎります。「アメリカでエンジニアにはコンピュータサイエンスを学ばないとなれないので日本のエンジニアとボトムのレベルがちがう」「アメリカのマネージャーはエンジニアとしても超優秀」
経営者にもエンジニア出身の人が多いんだろう
発展途上国の初等教育の重要性みたいな話ですね
それの乗り越え方はなにか?
(前回の話を受けて)フルフルでやるのは難しいけど、実験的な小さなプロジェクトで小さく実験してみて、効果が出ればそれを既成事実として他のプロジェクトでも実施する、とかはできるのかなと思った
まずはゲリラ的に実施して、制度として成立しそうならインセンティブを設計して制度立ち上げをするとか
ステップを小さくするとしたらどうできそうか?
まずチームの少数名がエンジニアリング生産性の向上に責任を持つようにする。その人は、業務の片手間ではなく、生産性の向上にコミットする。
定性的指標の再評価