アヒルの人形相手に話す talk with a rubber-duck
聞くところによると、プログラマたちは自分で書いた一連のコードが理解しやすいものかどうかを品質確認するため、あるいはお互いの上達のために見せあってレビューしあうのだそうだ（実際、私も昔そのような現場にいた頃には先輩にしてもらっていた）。なぜならば、コードが顧客の要求に沿ったものであり、それどころかプログラマ自身の意図に沿ったものなのかどうかすら、あやしい場合もあるからである。言い換えれば、不具合や意図せぬ動作を含んでいないかを検品するという役割もこの「レビュー」作業には備わっている。また、コードが読みやすく後から他のプログラマが読んでも理解しやすく書かれていればメンテナンスコストも減るし、その反対ならメンテナンスはうんざりするほど大変になる。もちろんチームで既に共有されたコードの書き方の方針に沿っているかどうかもチェックされる。こうしたことをお互いの目玉を使ってチェックし合うのがコードレビューというものである。
仮にあなたがたとえ一人で仕事をしていても、あるいは一人で趣味でプログラムを書くような人であっても、こうしたコードの品質問題を完全に無視することはできない。なぜならば、それを無視できるのは本当にわずかな期間だけ使用するプログラムで、本当に短いプログラムだけだろうからだ。そのようなプログラムは学校の教材か、使い捨ての試作品か、エクセルの数式程度の単純さしか持つことができないだろう。
例えば、思いつきでわずか数十行のコードを書いたとしても、それを半年後に書いた本人がみて正確にプログラムの挙動やその意図を思い出すのは困難になることはよくある（例えば1文字で表されたこの変数が何を意味するのか、半年前の自分の意図がもはやわからない）。プログラマあるいはエンジニアと呼ばれる人たちが高品質なプログラムや大規模なプログラムを書くときに様々なお作法を工夫したり、どの作法がベストなのかを考えるのは、このような困難をどうやって回避するのが一番いいかに意見の違いがあるからである。
そもそも自分の書いたコードはコンピュータに読ませるものだ。だから、コンピュータは最終的には文法ミスさえなければ、コードに書かれた通りに処理を実行する（あるいは、書かれた通りにまったく何もしない）。一方、コードを書く人間には意図があり、自分の意図通りにコードを書けるとは限らない。つまり、これはプログラマの間でよく言われる格言であるが「プログラムは思った（意図）通りに動くのではなく、書いた通りに動く」ということである。プログラマなら、誰でも知っていることだ。念のためにもう一度言うが、これはプログラマなら誰でも知っていることである。だから、どうやって今自分が意図をもって書いたものが意図通りに動作するかが課題である。このひとつの解決手段が上記に挙げた「他人にレビューしてもらう」だ。つまり、他人に向かって自分のプログラムそのものと自分がなぜそのように書いたのかを言葉で説明して、意図とコードとのズレを指摘してもらうという手法である。
だが、このレビューの「聞き手」は必ずしも人間である必要はない。なぜならば、このような他人に向かって説明するという手法を実践してみると、聞き手から指摘を受ける前にそもそも自分のコードがどのように動作するかを他人に説明しているときに自分自身で意図とコードとのズレに気がつく・自覚するという現象に出会うからだ。つまり、自分で何を書いているかそもそもわかっていない場合がかなりあるからである。もしそのようなミスであれば、わざわざ聞き手がそこにいる必要はないだろうし、聞き手がベテランである必要も、人間である必要もないだろう。したがって、少なくとも最初のレビューの「聞き手」は例えばアヒルのぬいぐるみでもOKなのである。
このように、コードを書いた後に、そのコードがどのような動作をもたらすのか、ディスプレイの脇においたアヒルに向かって声に出してしゃべっていくという手法は「ラバーダッキング」と呼ばれている。言い換えれば、これはいわゆる「壁打ち」と呼ばれる作業の一種である。
このようにアヒルに向かって話すとき、アヒルはプログラマの説明を「聞く」という機能を果たしている。いや、そのような機能を果たしているとみなされている。なぜならば、実際にはアヒルの人形には聴覚もなければ、説明を理解するための知識も神経基盤も存在しないのだから。言い換えれば、アヒルの人形にはプログラマの話を理解するための構造は何も備わっていないのである。それがわかっていても、プログラマは他でもないそのアヒルに向かって話しかけているのであり、アヒル以外の存在にはない機能をプログラマに対して持っていることも確かだろう（もちろん、そのアヒルではなく他の人形でもかまわないかもしれないが）。つまり、ここでアヒルは単にそれが顔を持った人形であるという程度の構造しかない。そこに大きな機能がかぶせられ、使われているのである。
こうして、我々は物言わぬ人形のアヒルに向かって自分の書いたコードを説明することを通じて自分のミスに気がつける。これはプログラマの話であるが、類似のことは人間が独り言をつぶやく至るところで起こっているはずだ。例えば、信仰告白や懺悔（ざんげ）や祈祷（きとう）がそうだろう。自分がこれからおこなうことを憶えているかどうか、暗記できているのかどうか、ひとつひとつ声に出して点検するときもそうだろう。懺悔や祈りを通じて、人は自分自身の心を整理したり、分析して、課題を絞ることができる。あるいはそれを言葉にするだけで、せき止められていた何かが流れるようになって楽になるのかもしれない。試験や舞台の本番の前に自分の学んだ内容やセリフをリハーサルするとき、そこではじめて今の自分に何かが足りていないことに気がつけるかもしれない。
これらの事例から学べることは何だろうか？ それは我々は自分たちで思った以上に言葉に不自由しているということである。アヒルや懺悔室の窓口の向こう側（そこには誰もいないかもしれない）や祈る方角、想像上の舞台の観客や記入前の試験用紙に向かって、我々は何かを語る。そのとき、聞き手はどこにもいない。言い換えれば、言葉を聞いて理解するという神経構造を持った相手は必要ないのである。それでも、私はそこで自分の言葉をプレイしてみて、「あっ、今、私は間違ったプレイをした」とか「ここでどうプレイすべきかわからなくなってしまった」とか気がつくことができるのである。そういう現象があるということはつまり、我々は言葉を知っているにも関わらずそれを知らないということである。なぜならば言葉の使い方に間違いがあるとかキズがあるということに気がつけるのは我々自身がそれらの言葉（ルール、あるいはあるべき姿）を知っていなければあり得ないのだが、一方で実際に話してみる（プレイ）してみると、我々はルール通りに言葉を使えておらず、あるべき姿にふさわしいプレイもできないからである。
このことは我々の中に言語という他者がいることを暗示してもいる。すなわち、我々がふだん何気なくプレイしている言葉というのは他人に指摘されてその間違いを直したり学んだりすることもあるけれども、一定の習得を経ると、我々の内側にある言語そのものが私と我々の言語を訂正してくるようになるのである。いったいこの私の中に潜んでいて壁打ちのときにひょっこり顔を出す言語とは誰なのだろうか。
(3,060字、2024.04.27)
#毎日note #毎日更新 #毎日投稿 #note #エッセイ #コラム #人生 #生き方 #日常 #言葉 #コミュニケーション #スキしてみて
この記事が気に入ったらサポートをしてみませんか？