ChatGPT が出てきて、平均値なものに価値がなくなって、外れ値に価値があるか、人の役割はノイズを与えるだとか言われているのを聞くが、そんなことはないと思っている。間違い方は無数にあるが、正しいのやり方はほんの少ししかない。なにかをするときには、無数の選択肢の中から、正しいものを選び取っていかないと、ゴールにたどり着かない。ChatGPT だってプロンプトとして与えられるものは無数にあるが、求める答えが得られるプロンプトはわずかだ。正しい答えを素早く得る能力の価値は ChatGPT があっても変わらない。
もちろん人間なので、たまに道から逸れるだろう。外乱もある。でも、その場合も都度都度修正していけば、目的地にたどり着ける。 ChatGPT の画期的なところは即座にフィードバックを与えて修正ができることだ。
だが、修正がなしに一発で決める方が、何度もフィードバックを繰り返すより、速い。仕事が速い人は、自動車レーサーのライン取りが寸分違わずに正確だったり、将棋指しが最善手を間違いなく指し続けるように、正しい解を誤ることなく選び取っているように見えます。
フィードバックが効く以上に道から逸れるような場合は、系としては不安定になるので、目的地にはたどり着けない。その場合は、仕事が速い遅いとは別次元の話なので、どうしようもないというのは前回に考えたことだった。
目的地にたどり着ける人が、誤った方にいかないようにしていることはある。最も間違いのおかし方に詳しい分野なので、プログラミングを例に挙げてみます。まだ、思いついたのを並べているだけにすぎないので構造化も網羅もされていません。
間違いがあってはならぬと思う。
精神論だけど最も重要だと思う。レビューで見つけてもらおう、テストで見つけようなどと思わず、間違わないように細心の注意を払って一つ一つの作業をする。もちろんレビューやテストもするのだが、その工程でできることはやりきる。トヨタでいうところの自工程完結です。本当はマインドセットに頼らずにメカニズムにしたいが、メカニズムを効かすにもマインドが必要だ。
不安を信じる。
きっと合っていると思っているところでも、誤りはある。いわんや合っているか怪しいと感じるところには必ず間違いがある。不安は当たっている。
根拠のない持論ですが、論理的思考能力なんかより、非論理的な感受性の方が鍛えるのが難しい。言語化できない不安を察知して、言語化したり行動する能力は鍛えた方がいいと思う。
合っているかどうか確信が持てていないものはレビューに出さない。仮に出すとしても、この点には不安がありますといってほしいものです。
自己レビュー
自己レビューは視点を変えてやるのが有効です。例えば、音読してみたり、時間が許せば一晩寝かせたり、ローカルの開発環境ではなくて GitHub に上げたあとに見たり。
類似確認
間違いを少なくするとは、効率的に間違いを探すと同じです。タイポにしろ、勘違いにしろ、同じ間違いはよくあるので、必ず類似確認はする。タイポがあったら、まずは間違えた単語を検索して同じ形の間違いを探す。
パターン認識を活かす。
古いが『間違ったコードは間違って見えるようにする - The Joel on Software Translation Project』という話。A であるべきところが B になっているのを見つけるのは、見れば分かる場合が多い。パターン認識能力を鍛えて、まずは見て分かってほしい。高いレベルになったら、見れば分かるように作る。
型で守る。
一歩進んで、間違ったコードを目視で見つけられるようにするのではなくて、誤っていたらコンパイルが通らないようにする。
安全な言語を使う。
習熟した人が集まらないなどの問題を無視すれば、安全性を高める機能の付いた新しいプログラミング言語を使って解決する問題は多い。
この null チェックはいりませんとか、ここで NPE で落ちる危険性がありますなんて、指摘をしたくはない。
静的解析ツールを使う。
プログラミング言語を変えるのは大変だが、静的解析ツールの導入は簡単だ。チームとしてプロセスに組み込むのも容易だが、ローカルで勝手に実行するのは、もっと容易だ。
互換性を保つために、バージョンが新しくなっても言語仕様やライブラリの仕様は維持される、間違いを生みやすい仕様は残される。静的解析ツールで、一般的に陥りやすい間違いを排除できる。
構造化
A であるべきところが B になっているよりも、あるべきところに A がないのを見つけるのは難しい。構造化されていれば、あるべきところにあるべきものがないと、分かりやすくなる。
ドキュメントには、仕様が構造化して書かれているものだから、ドキュメントにかかれている通りに書けばいい。
間違えやすい書き方をしない。
重複しているのだが、間違いにくいコードの書き方の対として、間違をしやすいコードの書き方がある。あえて間違いを犯しやすい方に進みたくなる引力がどこかにあるのでしょう。
変数の値やオブジェクトの状態を条件に応じて変更してのは、よく見る。最初に返り値を宣言して、何か初期値を入れて、条件に応じて変数を更新していって、最後に返すみたいな。変数のスコープが大きくなっているからか、よく間違っている。
間違いやすい書き方をしても、正しく作りきれることもあるとは思いますが、間違いやすい書き方がわざわざ選ばれている場合は、作りきれていないことが多い。
そもそも書かない。
作ること自体が間違いなのもよくある話です。例えば、HTTP クライアントのライブラリを使わずに、Socket からストリームを読んでパースしてなんてしてはいけない。その選択をしてしまう人に、そんなものが正しく作れるはずがない。
