物語化批判の哲学 〈わたしの人生〉を遊びなおすために

物語を通じたものごとの見方とか、固定されたステレオタイプやキャラクターを通じた振る舞いかたを強制する、という見方を批判する本。
会社でメンバーの人事評価や、その手伝いをしていると、期末に、半年分のストーリーを語ることになる。これは全員の思考を同じ形に強制してるんじゃないか？その時点で考えが合わない人はまったく評価できないということ？と、ちょっと怖い側面があるなと思っていた。

ゲーム、パズル、ギャンブル、おもちゃ、という章がある。その中では、ゲーム、パズル、ギャンブルは、個人的にはあまり好きでなくて、決まった遊び方になるのがおもしろくないな、と思う。ゲーム機は持ってるけど、ほぼカラオケ専用になっている。パズルは、めんどくさいからやらない。ギャンブルは、株主優待がほしくて株を買い集めているくらい。
唯一好きなのが、おもちゃを買うこと。ただ音が出るデバイスとか、手の中でころころ転がすと良い音がする球体、とかを買って遊ぶのが好き。
僕は新しいWebサービスを見ると、とりあえず変な入力を入れてみて、変な振る舞いをするかどうか観察して、おかしなことになるのを見るのが好き。
なんでこんなことをしてるのだろ？と思うこともあったけど、おもちゃ遊びというのは破壊すること、と書かれていて、そういうことだったのね、と納得した。

この本を読んでから、子がすることにたいして、壊れるからやめよう、とは言わなくなった。
遊ばなくなったら他の子が遊び、壊れる、もしくは、今遊んで壊れる、もしくは、捨ててゴミ処理場で燃やされる、のいずれかなら、結局、壊れるのだし、おもちゃの遊び方って規定されてないのだから、好きに遊んで壊れたら、それはそれでいいじゃん、と思うようになった。トイ・ストーリーを見てると、おもちゃに爆薬をくくりつけてロケット発射実験をする子どもが出てくる。おもちゃの立場から見るとさみしいことだけど、いずれ壊れるおもちゃ遊びとしては、それもまたよし、ということ。

物語化批判の哲学　〈わたしの人生〉を遊びなおすために (講談社現代新書)

■

保育園のお迎えに妻と2人で車で行ったので、そのついでに、回転寿司に行った。
子は最近は生魚を食べまくるようになっているので、寿司も普通に食べてくれて楽。
置いてある箸がツルツルでうまく使えなかったので、割り箸をもらったら、うまく食べていた。
豚汁は七味が入っていてちょっと辛い。あおさの味噌汁は辛くない。
パイナップルを注文したら、完全には切れてなくて、若干つながっていたけど、これはレーンで運ぶ途中にバラバラにならないためなんじゃないか、とか推測していた。
はま寿司に来ると、なぜか、鬼滅の刃のアニメを見たくなる。

伝わるコードレビュー

普段からチーム内でコードレビューについて話すことが多いので読んでみた。

コードレビューについて、って断片的なブログがよく書かれているし、語りやすいテーマなのか、いろんなブログが書かれている。
先日、コードレビューの優先度について仕事中に話していて、前に読んだ、コードレビューは最優先でやったほうがいい、というブログはどこだったかな、と探したら、大量に出てきてなかなか探せない、ということがあった。

• google:コードレビュー 最優先

探していた記事はこれだった。

• [翻訳] コードレビューについて

しかし、こうやって世間のおすすめ情報を集めても、網羅的にすべてを知ることは出来ないし、記事ごとにスタンスはバラバラで、私のコードレビュー観はこうです、というものは、各々、視点を磨く必要がある、という状況だと思う。
こうやってブログを探さなくても、この本によれば、コードレビューをお願いするときには、レビュワーに期限を共有しましょう、というアドバイスが記されていて、便利。

コードレビューってテキストコミュニケーションを思い浮かべてしまうけど、こういうときには同期的に喋るのがおすすめ、など、コミュニケーション全般についてアドバイスしてくれる。
TIPSが33個並んでいて、コミュニケーションの困りごと33連発、という感じで、これだけ網羅してくれていたら、普通に仕事していて直面するトラブルはだいたいこれらのうちどれかだろう、という印象。
Pull Requestでのやりとりがうまくいかなかったときに、この本でいうとどのパターンになっているだろう？という話題提供に便利そう。
しかし、「これはうまくいかなかったね」から話を始めることになるので、特定メンバーのコメントの吊し上げみたいにならず、建設的な議論になるように気をつけたい。

コードレビューのAI活用について最近考えていたのでメモしておく。
Claude Codeは/reviewというコマンドがあって、変更中のブランチのPull Requestの内容などをレビューしてくれる。これは汎用的な観点でみてくれる。
どういう観点でレビューするか、というプロンプトは公開されているのかな？と調べたけど見つからなかった。企業秘密っぽい。

/review コードレビューをリクエスト

スラッシュコマンド - Anthropic

レビューの観点はプロジェクトごとやチームごとに整備していくのがいいと思う。
Lintにしづらいコーディング規約とか、人々がよく間違う設計上の規約、とかはプロンプトに書いておかないと、レビューで拾ってもらえない。

AI時代における本書の活用としては、この本の33パターンのTIPSをもとに人間たちのやり取りを批評してもらう、という使い方ができて、遊びとしてはおもしろかった。
TIPSのリストは目次として公開されているので、目次をプロンプトに入れて遊ぶことができる。

〇〇番のPull Requestでのレビューコメントについて、以下33項目の観点でよい点、悪い点を批評してください

1：クイズを出さない
2：命令しない
3：性善説で考える
4：相手の意図を断定しない
(以下略)

実際に仕事のPull Requestでやってみたら、この意見は、主張が意見が曖昧です、という改善点を指摘してもらえた。
「性善説で考える」だけではAIへの指示としては不足だけど、このコミュニケーションのアンチパターンにはよく遭遇しているな、と思ったら、そのあたりAI用に解説して、注力してチェックしてくれるようなプロンプトを書いておけると、よくあるパターンを回避するのに使えそう。
送信したいレビューコメントをまずAIにぶつけて、アンチパターンに引っかかっていないことを確認してから投稿する、というチェックもできると思う。

コミュニケーションの良し悪しなど、人間が直接指摘しづらく、まずは関係性を作ってからようやく指摘できるようなことを、AIを通じて指摘してもらえば、直接対決を避けられていいかもしれないし、そんな無責任なコメントがきても困ります、という気分になるかもしれない。
最近仕事しながら喋っているのは、AIレビューはAIが直接レビューしてくれるんじゃなくて、レビュワー向けの支援として、おすすめのレビュー観点をコメントしてくれる、そのうえでレビュワーがレビューコメントを編成する、くらいの使い方がいいんじゃないか、ということ。
AIがこう言ってるのでこうだそうです、ではなくて、AIはこう言っていて私もそう思います、であってほしい。

伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書

■

後祭の宵々山を見に行った。
前祭はものすごい人で、まともに歩けなくて困るのだけど、後祭だと地域の祭りくらいのにぎわいになっていて、どこから来たのかわからない露店もなくなって、もともと存在する飲食店が路面で販売している食べ物ばかりになって、クオリティがアップしている。
はもかつバーガーの店が気に入っていて、前祭だとたどり着くのに苦労するけど、後祭ではふらっと寄れる。
今週から入院とかなら前祭にしか参加できないと思うけど、毎週来れるなら、今週のほうがおすすめ。

■

連休中、来客が多かった。
たこ焼きをやった。これは比較的難易度低い。子にタコやウインナーをはさみで切ってもらうことで、適当な仕事も与えられる。強火でガンガン焼くのがコツとわかってきた。熱くて食べられないので、ポン酢につけて食べていた。

保育園友がきたので、流しそうめんをやった。こっちは角度が変だと水がじゃぶじゃぶこぼれるので苦労するし、具の準備や皿のセッティングもややたいへん。
昼に流しそうめんをやって、スライダー部分を外して、下のプール部分だけで夕飯にまた流しそうめんをやった。モーターの音もうるさいし、下のプール部分で麺がぐるぐる流れているだけで、そうめんが冷えてきて、食事としても良い。

来客があると家が片付くので良い。毎週誰か、呼んでもないのに、勝手に来てほしい。

■

事実は小説よりも奇なり、ということわざがあるけど、その言葉を聞くことってだいたい小説の中だと思う。
小説の中では小説の中の出来事を事実として扱っているのだけど、小説を書いている作者がこのセリフを書いているわけで、小説よりおもしろい事実がある、という示唆をしていて、どっちつかずな立場だと思う。
アニメを見てたら、アニメなんか見てないで現実世界と向き合え、と説教される源流がここにあるのかもしれない。