これは何?
開発生産性Conferenceに参加し，Kent Beck氏の講演を聞いてきました。
とても興味深い内容だったので備忘録も兼ねてQiitaに感想をまとめます。
一回聞いただけなので間違っているところや加筆点があればコメントにお願いします。
この記事について
グッドハートの法則について
良くしようとした結果悪くなる
講演の中でKent Beck氏は，ものごとを良くしようとした結果悪化してしまうことがあるという話をしていました。
また，生成AIの登場により，この傾向が強まるのではないかという見解も述べられていました。
自分は最近xでみるような，AIに開発を任せすぎて保守できなくなって人間が呼ばれるみたいな話かなと解釈しました。以下はその例です。
- 開発者の生産性をあげるためにAIを導入した結果，開発者のシステムに対する理解度が下がってしまう。
- AIにテストのカバレッジを上げてもらった結果，不必要なテストが追加されてしまい，開発プロセスが遅くなる
グットハートの法則の詳細
グッドハートの法則（Goodhart’s law）とは、「ある指標が目標になると、その時点でその指標は“良い指標”ではなくなる」（When a measure becomes a target, it ceases to be a good measure.）という法則である。もともとは、イギリスの経済学者チャールズ・グッドハート（Charles Goodhart）氏が1975年に発表した、経済政策に関する論文の中で提示された原則1
つまり，指標を目標にするのが良くないという話です。
Kent Beck氏は講演のなかで，以下のようなたとえを話していました。
- タイピング速度が早い方が開発者の生産性は上がるが，タイピング速度を目的にしてはいけない。
- Pull Requestの単位は小さいほうが読みやすいし，コンフリクトも発生しにくいが，Pull Requestの数を増やすようなプレッシャーがあると過剰に細かくなり，無駄が多くなる
- 障害件数を減らすことを目的にすると障害報告をしなくなる。
自分は，最近読んだ単体テストの考え方/使い方2という本の中でもテストコードのカバレッジを追求しすぎてはならず，悪いテストのカバレッジは低いが，カバレッジが高いからといって良いテストであるとは言えないという話を思い出しました。
コード網羅率はちょっとしたことで簡単に算出結果が変わります。結局のところ、コード網羅率は行数しか見ていないため、テスト対象となるコードをよりコンパクトに実装すれば、コード網羅率は高くなってしまうのです。しかしながら、このようなリファクタリングを行ったことでコード網羅率が高くなったとしても、テスト・スイートの価値が変わったり、コードベースの保守がしやすくなったりするわけではありません（そして、すべきでもありません）。
また，Kent Beck氏の著書Tidy First3でもPRを小さくしたり，リファクタリングと機能のPRをわける話がでてきていたのを思い出しました。
指標は気づきのために使う必要があり，圧力をかけて強制するものではない。
Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
外部から指標に対してプレッシャーをかけられると指標が目的になってしまい，うまく機能しなくなるという話をしていました。
そのため，指標を扱う際のポイントは以下が挙げられていました。
- 指標は目標にせず，あとから測定する
- 指標を圧力にしない
- 個人が指標を見て気付きを得る目的で使う
- 一人一人に目的意識をもたせる(最も苦労したことだと語っていました)
重要な指標は測定しづらい
エンジニアがたくさん機能を追加したとしても，それがユーザ体験を向上させて価値があるというのがいい話だなとおもいました。エンジニアがどれだけPRを出したかは投資家は気にしていないし，ユーザ体験を向上したかどうかを数値で測定するのは難しいという話は納得感があり，グットハートの法則の正当性を後押しする内容だったなと思います。
Kent Beck氏の書籍Tidy First?3にあった，機能を優先させて後からリファクタリングを行うほうが経済的に合理的であるみたいな話にもつながるのではないかなと。
AIとのプログラミングについて
Kent Beck氏はAI(Genie)とプログラミングをするのは楽しいとおっしゃっていました。
自分もこれには同感であり，AIがうまく活用できると本質的な部分に集中できるなと思っています。
AIの登場でジュニアエンジニアはいらなくなるか
ジュニアに対しては，コードを何行書いたか，PRを何個作ったかという指標ではなく，何を学んだかを目標にしてほしいというようなことをおっしゃっていました。
生成AI時代，コードを評価する機会が増えるで本質的な理解が重要視されるようになると，ジュニアには成果よりも学んでほしいというのは非常に温かいエールだと感じました。
また，ジュニア側の自分としては積極的にふりかえりを行うなどして，学びを次に活かすような努力を行いたいと思いました。
Augumented Codingについて
今回の公演では喋らないとおっしゃっていましたが，上記の記事を先日見たので貼っておきます。
Vibe Codingはコードの振る舞いだけを評価するが，Augumented Codingではコードに注目し，その複雑さやテストなどにもプログラマーが注意を払う必要があるという話らしいです。
自分は，エンジニアとしては理解が浅い状態でアウトプットを量産しても意味ないなと思っていたので，Augumented Codingを意識して技術力を高めたいなと思いました。
Kent Beck氏に質問してみた!
発表が終わった後，サイン会と質問会がありました。
サイン会の列は100人以上が並んでいましたが，質問会は全然並んでおらず，質問と写真まで撮っていただけました。
質問としては，
「TDDを行う際に人間がテストを書くべきか，それともテストもまとめてAIに書いてもらうほうがいいか」というのを聞いてみました。
Kent Beck氏の回答としては，
「それは誰にもわからない。Genie(AI)によって私のコードをタイプする量は減ったけど，いろいろ試してみるといいんじゃない」という温かいアドバイスをいただきました。TDDの創始者がそういうなら，いろいろ試してみるぞというモチベーションになりました。
次回のQiitaBashのLT会で抽選があたったらこのあたり，いろいろ試してみた結果を話そうと思います。
Kent Beck氏の公演をどう活かすか(全体を通しての感想)
- 数字が気になることが多いので，指標に囚われすぎないようにしたいと思った。
- PRの数少なくても自分が成長しているなら気にしない
- 最低出社数にとらわれず，コミュニケーション面なの必要に応じて対応する
- 理解に時間をかける、自分で手を動かす経験を重視する。
- LTをする歳に知識の共有だけでなく，学びの共有をしてみる。
- 定期的な振り返りを行う。
最後に
運営のFindy様やスポンサー企業の皆様，Kent Beck氏への感謝で締めたいと思います。
ありがとうございました!
Reference
Views: 0
