0時に寝て6時に起きた。6時半頃に動くバッチ処理がエラーになって朝から原因を調べてた。

ユニットバイアスとツァイガルニク効果⌗

いまのお仕事は火曜日にリリースして水曜日にプランニングしているため、1週間のうちの火曜日と水曜日がだらけがちになっている。火曜日に作成したリリースしない開発途中の PR が保留され、水曜日もプランニングやその後の調整にだらけていると PR が滞留しやすいからだ。昨日と今日で作成した PR が7つレビュー待ちで溜まっていて、他の作業を並行して進めるやる気をなくしてしまった。ここでなぜ作業を中断していると、自分の中でストレスが溜まったり、他の作業のやる気が削がれるのかを考えてみた。私が知っている認知心理学の知見からだと次の2つになる。

  • ユニットバイアス
    • 量や大きさに関係なく、やり終えることに満足を感じる
    • チケットやタスクを小さく分割することで小さな課題に集中して作業できる
  • ツァイガルニク効果
    • 途中で挫折したり中断してしまったことの方がよく記憶に残る
    • 心理的リアクタンスが高いほどこの効果が発生しやすくなる
      • 他人から行動を制限される反発して自分のやりたい欲求が高まる
    • レビュー待ちが多いと中断している課題のことが気になって集中力を削がれる

普通の開発者は1日3-5個ぐらいのチケットを fix するんじゃないかと思うけど、レビューが止まっているせいでそれが阻害されてストレスを感じる。しかも、レビューが有意義であれば待つ価値もあるが、レビューのほとんどがノーコメントで approve されるだけだと待ち時間だけが積み上がる。

普通のプログラマの普通の設計⌗

タイムラインでたまたまみかけて 普通のプログラマの普通の設計 に参加した。設計の話しはコンテキストやコードがないと抽象的過ぎてふわふわして勉強会で扱うには難しいテーマだけど、その懸念通り、ふわふわした内容だったと思う。おもしろくなかったわけではなく、発表者それぞれの考え方や大事にしている価値観などを知ることで多様性を認めるというか、他人のやり方を受け入れることにもつながるのかなとは思えた。

コードのない設計の話しは言葉から連想される概念が広過ぎてあまりよくわからない。現実の設計でも言葉でやり取りして同意していたのにコードは全然違うみたいなことはたまに発生する。だから言葉で設計のやり取りするよりも、2-3日でプロトタイプを実装できるならコードを先にみせてもらった方がよいとすら私は考えているところがある。あと一度設計をやったら終わりと考える開発者も多い。設計とは運用してからのフィードバックを受けてさらに改善していくことも含まれる。だから開発を継続している限り、設計したということはなくてずっと設計しているという考え方が正しい。matz もコードとは設計であると話していたと思う。