これは何?
開発生産性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について
今回の公演ではAugumented-Codingという言葉だけを紹介し、詳細は語っていませんでしたが，先日読んだKent Beck氏のSubtrackで詳細を説明していたのを思い出したので共有しておきます。
Vibe Codingはコードの振る舞いだけを評価するが，Augumented Codingではコードに注目し，その複雑さやテストなどにもプログラマーが注意を払う必要があるという話らしいです。
自分は，エンジニアとしては理解が浅い状態でアウトプットを量産しても意味がないなと思っていたので，Augumented Codingを意識して技術力を高めたいと思いました。
Kent Beck氏に質問してみた!
発表が終わった後，サイン会と質問会(Ask the Speaker)がありました。
サイン会の列は100人以上が並んでいましたが，質問会は全然並んでおらず，質問ができ、写真まで撮っていただけました!
質問としては，
「TDDを行う際に人間がテストを書くべきか，それともテストもまとめてAIに書いてもらうほうがいいか」というのを聞いてみました。
Kent Beck氏の回答としては，
「それは誰にもわからない。Genie(AI)によって私のコードをタイプする量は減ったけど，いろいろ試してみるといいんじゃない」という温かいアドバイスをいただきました。
TDDの創始者がそういうのであれば，いろいろ試してみるぞというモチベーションにつながりました。
Kent Beck氏は好奇心を大切にしている方だと思うので、やはり手を動かして自分でいろいろ試行錯誤することを大切にらし続けたいなと思いました。
次回のQiitaBashのLT会で抽選があたったらこのあたり，いろいろ試してみた結果を話そうと思います。
Kent Beck氏の公演をどう活かすか(全体を通しての感想)
- 数字が気になることが多いので，指標に囚われすぎないようにしたいと思った。
- PRの数少なくても自分が成長しているなら気にしない
- 最低出社数にとらわれず，コミュニケーション面なの必要に応じて対応する
- Qiitaのいいね数を目標にしない。
- 理解に時間をかける、自分で手を動かす経験を重視する。
- LTをする歳に知識の共有だけでなく，学びの共有をしてみる。
- 定期的な振り返りを行う。
最後に
運営のFindy様やスポンサー企業の皆様，Kent Beck氏への感謝で締めたいと思います。
ありがとうございました!
追記: System Thinkingについて
t-wadaさん曰く、System Thinkingを学ぶとより理解が深まるらしい。
昨日から、ドネラ•H•メドウズさんのThinking in Systems: A Primerの翻訳本「システムで世界は動く」を読んでいますが、
いろいろなベストプラクティスの背景にSystem Thinkingがあるのがわかってきました。
一読の価値はあると思います(ステマではない)。