プログラマーのための行動経済学 (自信過剰とリーダブルコード)

はじめに
サマリー
記憶に対する自信過剰
対策
チームや組織で失敗を防ぐには？
- 1. 読みやすいコードを書くためのコストを下げる
- 2. 読みやすいコードを書くことを（ゆるく）強制する
まとめ
参考文献

※三浦は退職していますが、本人の同意を得て、掲載を継続しています。

はじめに

こんにちは。パーソルキャリア株式会社でデータアナリストとして働いている三浦です。
私はデータアナリストとしてこの会社で働いておりますが、それと同時に行動経済学の研究もしています。
行動経済学は端的に言えばより「人間くさい」仮定をとりいれて経済学的な分析を行う分野です。
例えば、先延ばしをするとか、楽観的な予想をするとか、情報を無視するとか、人の目を気にするとか、色々です。

修士から数えるとプログラミングは 9 年ぐらい行ってきました。
その過程で、様々な失敗もしてきました。
中には、誰もがしたことのある失敗もあるかと思います。
プログラミングにおけるよくある失敗を行動経済学の観点から考えてみようと思い、この記事を書いてみました。

サマリー

人は忘れてしまうことも忘れてしまう
記憶に対する自信過剰はレガシーコードの一因となる
リーダブルなコードを書こう
痛い目を見ないですむようにするには、ある程度の仕組みが必要

記憶に対する自信過剰

今回は、その中でも記憶に関する自信過剰をテーマに扱います。

例えば、こんな経験はありませんか？
データの記述統計量やグラフを見たり、色々試行錯誤して機械学習や分析のスクリプトを作成した。
数か月後にそのコードを見直してみると、書いてあることが全く分からず、解読と改修にかなりの時間を費やすことになった。

かくいう私もこのような事例は数回経験しました。
博士課程 2 年目ぐらいだったと思います。
論文を学術誌に投稿すると、場合によっては追加の分析を行うことになります。
経済学の出版までのプロセスは長いので、再分析をするのは前から半年後とかは普通にあります。
そのときはコードの解読に 1 週間以上かかりました。

なぜこのような失敗を犯すのでしょうか？
色々な理由は考えられますが、1 つとしては記憶に対する自信過剰が考えられます。

ここでいう自信過剰とは、自分の能力を過大評価すること、あるいは自分にとって都合の良い結果が起こりうる確率を過大評価することを指します。
有名な研究として、ほとんどの人が平均的なドライバーよりも運転が上手いと思っているというものがあります (Svenson, 1981)。
運転スキルだけではなく、様々な場面において自信過剰は見られています。

例えば、

経営能力: de Meza et al. (2019)
就職活動: Spinnewijn (2015), Mueller et al. (2021)
自己統制能力: Augenblick et al. (2015), Augenblick and Rabin (2019)
認知力: Grossman and Owens (2012), Zimmermann (2020)

最近呼んだ論文で面白かったのは、人は嘘を見抜く能力を過大評価しているというものでした (Serra-Garcia and Gneezy, 2021)。

どうやら人は自分がどのくらい物事を覚えていられるかも過大評価しているようです。
例えば、Ericson (2011) の研究では、約半年後に実験者にメールをすれば 20 ドルの報酬がもらえるか、何もせずとも同じ時期に xドルの報酬がもらえるかのどちらを好むかを測定しました。
すると、多くの人が何もしないでも報酬がもらえる選択肢にそこまで惹かれませんでした。
つまり、自分はちゃんとメールを忘れずにする自信があったというわけです。
選択結果から、著者らは少なくとも実験参加者は 75% の確率でメールをすることを忘れないと予想していると推定しています。
ですが、ふたを開けてみると、実際にメールをしたのは半数ぐらいしかいませんでした。

プログラミングの話に戻りましょう。
もし、将来的にコードを見返す可能性があったとして、このままのコードだと解読に 1 週間かかることが事前に分かっていたら、あなたはどうしますか？
その時はその時だという人もいると思いますが、理想としてはやはりコードを読みやすくするのではないでしょうか？
では、現実としてなぜそれをやっていないのかというと、「今」の自分はこのコードを読めるので、「将来」の自分も読めるだろう、つまりある程度は覚えているだろうと考えているからです。
しかし、先の研究の結果からも分かるように、それは過大評価の可能性があります。

対策

さて、将来の自分は今のスクリプトの内容をすっかり忘れているとしたら、将来の自分のためにどのようなコードを書けばよいのでしょうか？
多くのプログラマーは既にこの対策を行っていると思います。
例えば以下のものはそれにあたると考えられます。

分かりやすいコメントを残す
変数の命名規則を作る
影響範囲を最小化する
関連するコードは近くに書く

リーダブルコードではその名の通り、どのように読みやすいコードを書くかについて論じています。

チームや組織で失敗を防ぐには？

チームや組織でこのような失敗を防ぐにはどうすれば良いでしょうか？

多くの人がこのような失敗をすることを教えれば、自分も忘れるかもしれないと気付いてくれるのでしょうか？
Tasoff and Letzler (2014) では、Ericson (2011) に似た研究デザインを用いて、他者の実際のメール申請率を教えることが予想と行動にどのくらい影響するかを検証しました。
残念ながら、このような情報を与えても、実験参加者の予想と行動どちらにも影響を与えることはできませんでした。
もっと良い情報の与え方があるかもしれませんが、他の人の失敗談だけでは認識を変えるのは難しいのかもしれません。

認識を変えるのが難しいのであれば、行動を変えて失敗を防ぐ方法を探るのが良いかもしれません。
これには 2 つの方法が考えられます。

1. 読みやすいコードを書くためのコストを下げる

命名規則が分からなかったり、どのようなものが読みやすいコードなのかが分からなければ、読みやすいコードを書くために調べなければいけません。
フォーマットには Python であれば black などのフォーマッターで自動化するのも手だと思います。
命名規則等に関しては、チーム内や組織内で一定のルールかガイドライン的なものを作成すると良いでしょう。
私が最近メンバーから教わった方法は、まずどのようなことをやるかをコメントで箇条書きにすることです。
例えば、データを取得する、前処理をするとかです。
ここでは、細かく書かずに全体像のみを把握できるようにすれば十分です。その後にコードを書きます。
各タスクのコードを実装する際に、タスクが分割できるならば、またコメントで箇条書きしていきます。
こうすることで、何をすればよいかの全体像を常につかめますし、コメントも書けるので一石二鳥です。

2. 読みやすいコードを書くことを（ゆるく）強制する

読みやすいコードを書くコストが下がったとしても、自信過剰であれば読みやすいコードを書くメリットに気づけません。
ですので、そのような自信過剰な人（例えばプログラミング歴が浅い人とか）に関しては、コードレビューなどを定期的に設けるのはどうでしょうか。
読みにくいコードであると指摘して、読みやすいコードにしてもらう、あるいは読みやすいコードであれば称賛するようにして、読みやすいコードを書くことのインセンティブを与えるのです。
あるいは、ここで小さな失敗をして、読みやすいコードを書くことのメリットを認識してもらうというのも良いかもしれません。
メリットを感じていない人にルールを強制すると意欲が下がる恐れがありますから、そこの塩梅には注意が必要かと思います。
なぜこのようなルールを設けているのかという納得感を得てもらうのも重要かと思います。
また、ルールだけあっても、どのように読みやすいコードを書くことのコストが高いままであると、負担が大きくなってしまいます。
ですので、読みやすいコードを書くためのコストを下げるのと、ルールを設けるのは両方行った方が良いかと思います。

まとめ

人は自信過剰であって、自分が書いたコードは将来の自分も読めると期待してしまいます。
ですが、往々にしてそのようなことはないわけですから、読みやすいコードを書いた方が良いでしょう。
読みやすいコードを書くことは、将来の自分のためだけでなく、引継ぎをスムーズにしたり、ナレッジ・シェアという観点から見れば、他の人のためにもなります。
とりあえずは、コメントを書くことから始めてはいかがでしょうか。

参考文献

- Augenblick, N., Niederle, M., & Sprenger, C. (2015). Working over time: Dynamic inconsistency in real effort tasks. The Quarterly Journal of Economics, 130(3), 1067-1115.
- Augenblick, N., & Rabin, M. (2019). An experiment on time preference and misprediction in unpleasant tasks. The Review of Economic Studies, 86(3), 941–975.
- Boswell, D and Foucher, T (2012) リーダブルコード：より良いコードを書くためのシンプルで実践的なテクニックオライリージャパン
- de Meza, D., Dawson, C., Henley, A., & Arabsheibani, G. R. (2019). Curb your enthusiasm: Optimistic entrepreneurs earn less. European Economic Review, 111, 53–69.
- Ericson, K. M. M. (2011). Forgetting we forget: Overconfidence and memory. Journal of the European Economic Association, 9(1), 43–60.
- Grossman, Z., & Owens, D. (2012). An unlucky feeling: Overconfidence and noisy feedback. Journal of Economic Behavior & Organization, 84(2), 510-524.
- Mueller, A. I., Spinnewijn, J., & Topa, G. (2021). Job Seekers’ Perceptions and Employment Prospects: Heterogeneity, Duration Dependence, and Bias. The American Economic Review, 111(1), 324–363.
- Serra-Garcia, M., & Gneezy, U. (2021). Mistakes, Overconfidence, and the Effect of Sharing on Detecting Lies. The American Economic Review, 111(10), 3160–3183.
- Spinnewijn, J. (2015). Unemployed but optimistic: Optimal insurance design with biased beliefs. Journal of the European Economic Association, 13(1), 130–167.
- Svenson, O. (1981). Are we all less risky and more skillful than our fellow drivers? Acta Psychologica, 47(2), 143–148.
- Tasoff, J., & Letzler, R. (2014). Everyone believes in redemption: Nudges and overoptimism in costly task completion. Journal of Economic Behavior & Organization, 107(PA), 107–122.
- Zimmermann, F. (2020). The dynamics of motivated beliefs. The American Economic Review, 110(2), 337–363.