00:02
どうも、なにがしかのラジオです。
今日もあまり役に立たない話をしようと思います。
風邪気味でね、ちょっと喉が痛いですね。
今日は、お悩みシリーズの延長なのかもしれないですけど、
レビューが嫌だという、苦手だという話をしようと思います。
ソフトウェアエンジニアの界隈では、ソースコードレビューというのは、
だいぶ一般化された習慣というか、実践というかベストプラクティスの一つだとされています。
何かコードを書いたら、それを反映する、保存する前に、
他の人に見てもらって、コメントをもらうと、何もなければそのまま保存するし、反映するし、
コメントをもらって、ここを変えた方がいいよとかいうのがあれば、変えると。
これのメリットとしては、他人のチェックが入るので、見落としていたミスがないかとか、
人から見ると分かりにくいコードになっているよとか、そういう指摘をもらえて修正できて、
レビューする側からしても、他の人の書いたコードを読む機会になるので、
複数人で開発していると、自分の書いたところは分かっているけど、
他の人が書いたところがどうなっているか、分かっていないことが発生しやすいので、
キャッチアップできるというメリットがあると言われているのかなと思います。
これは長いソフトウェア開発の歴史の中で、最近といってももう10年以上だと思いますけど、
特にやった方がいいと言われるようになっています。
デメリットとしては時間がかかるとか、レビューしてもらわないと反映できないので、
時間がかかるとか手間だとか、やりとりがストレスだとか、
レビューしてもあまり本質的な改善ができるわけではないとか、
小手先の指摘とかコメントとかは来るけど、
そもそもこれ大規模に変えた方がいいよねみたいなコメントはしづらいし、
03:08
されても直しにくいしみたいな、なんせ締め切りがあってやっているので、
そんな一から作り直しましょうみたいなことを言われても対応できませんみたいなことになりがちなので、
じゃあやる意味があるのかみたいな議論もあったりします。
それでデメリットもあったりします。
それでデメリットもあったりするんだけど、一応やった方がいいと。
たぶんおそらくほとんどの人はそう言っていると思います。
私の個人的にはこれが大変苦手で、レビューするのもされるのもすごい苦手だなという意識がありました。
なんでこんなに自分は世の中的にはした方がいいとされているし、
そのメリットも一応理解はできるんですけど、やっぱり嫌だって感じで、
なんでなんだろうというのを振り返って考えてみたんですけど、
仮説1としては人が判断するのが嫌なのかもしれないですねと思いました。
ミスがあるとか読みづらいとかは何らか基準を設けて機械的にチェックできるようにして、
機械的に判断するツールを入れて自動で指摘が表示されるようにしておいてくれよって思うのかも。
人がチェックしていると、チェックしても見ない人もいれば見る人もいて、
人の認知をハックするようになりますからね。
レビューはこれらのレビューは気づかないだろうみたいな行動を書き始めてしまうこともあるので、
そういうのが嫌だと。機械的にやるのは機械的にやりたいです。
機械的にやる以上の指摘をするならそれは結構大規模な修正になるので、
結局対応できないしやる意味ないよねという気持ちになるのが大きいかなと思います。
それが仮説1。
人がやるチェックは、名文化されているものは機械でやればいいし、
名文化されていないものは人がやる、人がチェックするということなんですけど、
名文化されていないものでチェックされるのがそもそも嫌だと。
06:02
名文化してくれという気持ちがあるんだろうなと思う。
仮説2は、この仕組みって人がチェックしましょうという仕組みは全般そうなのかも。
完璧なものを目指そう。
この世の中で一番良いものを目指そうというよりは、
大きな失敗が発生しないことを担保しましょうという系の取り組みだと思うんですよね。
それが嫌なのかもしれない。
それが実際、社会で物をやっていく上では非常に大事なことなのかもしれないですけど、
自分が実は結構完璧主義だったのかもしれない。
それで嫌だと思っているのかもしれないと思っていました。
そうなのかなと思っていて、
最近ある本を見まして、ソフトウェア開発とは全然関係ない本なんですけど、
新木博之さんの「農学の地図」という本がありまして、
この中で自分で物事を勉強していく、
勉強というより学びと呼んでいますけど、
本に書いてあることを勉強していくだけじゃなくて、
自分の知らなかったこと、自分のできなかったことができるようになるとか、
昨日と違うちょっと成長したなと、自分が成長したなと思えるようなものを学びだと呼んでいて、
その学びを自分で続けていく上でどういう仕組みでやっていけばいいかということを説いた本ですね。
ビジネス書かな、最近多分独学がブームなのかなと思うし、
ブームになっている独学という中でも、
資格を取るとかそういうことにフォーカスしたものというよりは、
もっと広い意味での人間性とか、資格とかテストの点数が上がるとか、
そういうことじゃなくて、自分が知りたいなと思ったことを考えていこうかもしれないと納得できる、
説明に至るというのを繰り返すための興味、一的好奇心という意味での学びの話でした。
09:10
この中で疑問と差分と他者のトライアングルというのが最初の本に出てきて、
これが結構キーになる、この本のキーになる話だったんですけど、
すごいうまく構造化されているなと、
物事を自分で学んでいくという営みを説明するにおいて、
すごい良いフレームワークだなと思いました。
疑問というのは何でもない、自分の知りたいこと、何でもいいので、
何でこうなっているんだろうかと思ったこと。
それを心の中に留めておいて、日々いろんな経験をする中で、
こうかもしれないとか、こうしたらうまくいったなみたいなものを学びと差分、
昨日わからなかったことがちょっとわかったとか、
昨日できなかったことがちょっとできたみたいなものをほんのちょっとの差分を学びと呼びます。
それを他者にちらっと説明すると、
昨日こう思ったんだよとか、こういうことに気づいたんですとか、
こうやったらうまくいったんですというようなことを人に説明する。
この3つを他者に説明すると、
さらに何でここはこうなんだろうとか、こうしたらどうなるんだろうとかという次の疑問が芽生えて、
このトライアングルをぐるぐる回すことで学びが深まるという話でした。
他者に説明することがすごい大事だなと思っていて、
理解するから語るのではなく、語ることによって理解するということをおっしゃっていました。
結局語るとき、人に説明するときにこうなのかなと言語化されるというか、
さらに腑に落ちるものになるのかも。
語るつもりで考えることによってゴールが人に語れるレベルまで理解ができるとか、
なんとなくふんわりした理解が言語化されるというようなことかと思いました。
12:04
これを読んで思ったんですけど、レビューが嫌なんですが、
レビューって学びを他者に説明する場と捉えればそんなに嫌でもないかもしれないと思い始めました。
何かあるタスクがあってこういうコードを書けば実現できたわ、ほぼ分かってたことだけどというような場合もあれば
ちょっと面白い書き方があったので試してみましたみたいなものを他者に見てもらうと。
必要に応じてディスカッションするという場だと捉えれば自分の学びのプロセスの一つという意味では
レビューもそんなに嫌じゃないかもと思ったりしました。
この本にも書いてあったんですけど、他者に説明することの本質は何かというと
他者からの一定の期待値があると。その期待を満たすことによって学びにもつながるし
他者からの評価も得ることができると。
ただ問題は評価を目的にしてしまうと承認してもらうためのプロセスになってしまうのでそれは良くない。
あくまで学んだことを自分が知らなかったこと、昨日との差分を言語化して
明確にするという学びが目的であって。
あなたは面白いことに気づきましたね。あなたは面白い人ですね。またすごい人ですね。という評価を得るためは目的ではないよと。
そっちを目的にしてしまうとあまり良いことはないよという話で書いてありました。
そうですよね。レビューが嫌なのも人から判断されて、それが自分の評価に自分の承認を求めるプロセスだと。
このことを反映していいですよという承認を求めるプロセスだと捉えるとすげえ嫌なことになる。
気づきというか学びを共有する場だと捉えればそんなに嫌ではないかもしれない。
人に評価されるのが嫌です。人に承認されるために頑張るのが嫌なのかな。そうかもしれないですね。
15:04
人の評価なんてあやふやだからそれのために頑張るなんて嫌だ。
ここのどこかで思っているのかもしれないなと思いました。
そんなところです。今日はあまり落ちもない話でしたが、また何かあったらアウトプットしていこうと思います。
ありがとうございます。
