Posts for: #Psychology

葛藤も逡巡もしない

2時に寝て4時に起きて6時に起きて7時半に起きた。意味なくあまりよく眠れなかった。自分の pr のレビュー待ちやリファクタリングと他人のデザインレビュー/コードレビューなど、いろいろ雑多なことをやって隙間の1日になった。

メイドインアビス 烈日の黄金郷

ちょっと時期は遅れていると思うけど、メイドインアビス の新しい作品が配信されているのに気付いた。晩ごはんを食べてから見始めたらおもしろくて、夜に別作業をするつもりが寝落ちするまで見続けてしまった。

劇場版「メイドインアビス」-深き魂の黎明- も何度もみた。好きな作品の1つだ。敵としてボンボルドというキャラクターが出てくるが、ボンボルドの在り方は一概に悪とか非道とか、サイコパスと断じられるものでもなく、なにか強い印象に残っていた。

今回の「烈日の黄金郷」においても敵でないが、ワズキャンというリーダーキャラクターが出てくる。メイドインアビスは、その世界観として死が身近な状況における強いリーダーシップを描いているようにみえる。それが世界観のせいなのか、作者の独特の感性なのか、その両方なのかはわからないが、とても特異なリーダーシップにみえてしまう。現代の生活や価値観から言えばサイコパスのようにみえるが、作品の世界観から言えば、強いリーダーシップと解釈できる。そのリーダーの選択、決断、思考、信念、潔さのどれもが淡々としたストーリーの展開をミステリアスなものにしている。

なぜか私はこの作品のちょっと特異なリーダーに共感するところがあっておもしろくみることができる。共感するところの1つに、メイドインアビスに出てくるリーダーは葛藤や逡巡をしない。括弧とした信念があるから仲間を犠牲にしても自責しない。それがある種の潔さや偽善を感じない爽快さにつながっていて私の価値観にあっているように思える。そう、失敗しても潔いのが私は好きなのだ。誰かの責任にもしないし、その結果で自暴自棄になったりもしない。なにが起きてもそれは自分の人生で受け入れていくしかない。メイドインアビスに出てくるリーダー像はまさにそれを体現しているように思う。

初めて lvm を操作してみた

0時に寝て何度か起きて7時に起きた。最近は寝る前にはてブのアプリで適当に記事を読みながら寝ることが多い。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

ここ1-2週間ぼーっとしていて、忙しくもなく、なにかやっているわけでもないけど、のんびり過ごしている。軽いバーンアウトだと思う。先週末は休みも取った。「hugo のテンプレート作り」のような新規開発を、どこかのもくもく会やイベントに行って、その場で集中してやったらいいんじゃないか?というアドバイスをいただいて、確かにそういうやり方もよいように思えた。今週末は課題管理のコンテンツを考えて、できればブログに書いてみようと思う。

lvm の論理ボリュームの結合

新規に almalinux 8 で仮想マシンを作った。デフォルト設定でインストールしたら //home でパーティション分割されていて、これは使い勝手が悪いなと思ってパーティションを結合することにした。

$ df -h
ファイルシス               サイズ  使用  残り 使用% マウント位置
devtmpfs                     1.9G     0  1.9G    0% /dev
tmpfs                        2.0G     0  2.0G    0% /dev/shm
tmpfs                        2.0G  8.6M  2.0G    1% /run
tmpfs                        2.0G     0  2.0G    0% /sys/fs/cgroup
/dev/mapper/almalinux-root    70G  6.5G   64G   10% /
/dev/mapper/almalinux-home   437G  5.0G  432G    2% /home
/dev/vda1                   1014M  221M  794M   22% /boot
tmpfs                        393M   12K  393M    1% /run/user/1000

基本的には次の記事をみてやったらうまくいった。

/home をバックアップする

# mkdir /home-bkup
# cp -a /home/ /home-bkup/

emergency モードに入る?

# systemctl emergency

結合したい領域を unmount して、home の論理ボリュームを削除する。

# umount /dev/mapper/almalinux-home
# lvremove /dev/mapper/almalinux-home
Do you really want to remove active logical volume almalinux/home? [y/n]: y
  Logical volume "home" successfully removed.

バックアップからデータを戻す。

# cp -a /home-bkup/ /home/

/etc/fstab から不要なパーティション設定を削除する。

# vi /etc/fstab
...
/dev/mapper/almalinux-home  /home  xfs  defaults  0  0  # <- この行を削除
...

root の論理ボリュームに余っている領域を拡張する。

# lvextend -l +100%FREE -r /dev/mapper/almalinux-root
  Size of logical volume almalinux/root changed from 70.00 GiB (17920 extents) to <507.04 GiB (129802 extents).
  Logical volume almalinux/root successfully resized.
meta-data=/dev/mapper/almalinux-root isize=512    agcount=4, agsize=4587520 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=0 inobtcount=0
data     =                       bsize=4096   blocks=18350080, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=8960, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 18350080 to 132917248

この時点で1つの領域に結合されたことがわかる。

# df -h
ファイルシス               サイズ  使用  残り 使用% マウント位置
devtmpfs                     1.9G     0  1.9G    0% /dev
tmpfs                        2.0G     0  2.0G    0% /dev/shm
tmpfs                        2.0G   78M  1.9G    4% /run
tmpfs                        2.0G     0  2.0G    0% /sys/fs/cgroup
/dev/mapper/almalinux-root   508G   14G  494G    3% /
/dev/vda1                   1014M  221M  794M   22% /boot

バックアップを削除する。

# rm -rf /home-bkup/

マシンを再起動する。

# reboot

これで問題なければ完了。

会社のテックブログは難しい

1時に寝て7時に起きた。

煩雑な検証

昨日の続き。午前中に pr を作成してレビューしてもらってマージしてデプロイして検証した。いくつか既存の設計には課題があると思いつつ、工数かけて直してくれという依頼は来ないのもわかっていて、煩雑なコードに煩雑な検証をやるだけにとどめた。テスト環境での検証自体は成功したので問題はなさそう。一部、本番環境でないと検証できないらしい。

会社のテックブログ談義

最高のテックブログを書くために気をつけている3つのこと というブログ記事をみかけた。内容はとても素晴らしいと思う。一方で会社のテックブログでこんな品質を求められたら、品質を満たせない執筆者のモチベーションを阻害しないかということがやや気になった。そんなもやもやを、こみやさんとまさひとさんに共有したらテックブログ談義が始まっておもしろかったのでまとめておく。会社のテックブログと言えばクラスメソッドさんが有名なので引用する。

もちろん弊社では、ブログを書くことを業務上の成果としても評価していますので、このブログを書くこと自体が評価につながるモチベーションになっています。

どのように評価をしているかと言うと、1つは本数という指標です。弊社では月4本エンジニアがブログを書くことを推奨しています。これは罰則はないので、書けていないからといって減点をすることはありません。逆に書いてるからといって加点をすることもありませんが、月4本を推奨していますし、10本書く人は高評価ということで「ブログのプロ」と呼ばれることがあります(笑)。その月は「10本書いたからプロになったね」というようなことを社内で言われたりします。

業務上の評価ということで、先ほど「減点・加点しないよ」というお話をしたんですが、3ヶ月に1回、ブログの本数とSNSのシェア数とビュー数が多い人に対して表彰をしています。やはり継続的にアウトプットをしているとこういった場面で表彰される機会も増えるので、社内でも「この人はたくさんブログを書いてるんだ」「この人はすごく高いスキルを持ってるんだ」と認められ、評価にもつながります。もちろん上司からも、技術ブログを書いてアウトプットが多いことが高い信頼につながります。

なぜ技術ブログを書きまくるのか? 『Developers.IO』のクラスメソッドが伝える、エンジニアの成長サイクル

みよ!この評価しているのか、していないのか、はっきりしない曖昧な制度設計を!

「テックブログは開発者がやるべき業務とみなしていますか?」と尋ねると、多くの会社では業務時間に書いてもよいけど必須でもノルマでもないみたいな答えが返ってくるのではないだろうか。業務に含めたくないのは、本質的に優先度の低い業務だという事実と、一定以上のコストをかけてまでテックブログに価値があると会社も考えていないのではないかと思う。業務とは言い難いので区別のためにここではテックブログを書くという 活動 と呼ぼう。

そして、個人のモチベーションに期待した活動を安易に評価の対象にするのは想像以上に厄介な制度設計になる。メタ認知で〈学ぶ力〉を高める:認知心理学が解き明かす効果的学習法 を読んで私は理解できたことなんだけど、おそらくクラスメソッドさんの (曖昧にみえる) 制度設計の裏には認知心理学の知見がある。

  • 外発的動機づけ: 金銭や物品などの物的報酬、よい評価を得るといった社会的報酬など
  • 内発的動機づけ: 自分がそれをしたいからする、知的好奇心など

外発的動機づけは内発的動機づけと比べてずっと弱い動機づけであることがわかっている。ここで外発的動機づけの業務から始めて内発的動機づけの活動に変わっていくこと自体は問題ない。スクラムで言及している自己組織化や自律的な行動というのは内発動機づけによる活動に変わっていくことを期待している。会社の制度設計として難しいのはこの逆はよくないという話しがある。内発動機づけで行動していた活動を外発的動機づけに置き換えてしまうことだ。テックブログのような、本人が自己学習やアウトプットを目的に自律的にやっていた活動に、安易に金銭的な報酬を与えてしまうと、お金のためにやっている業務に置き換わってしまってやる気をなくしてしまうという懸念がある。余談だが、褒めることそのものは副作用のない安全な報酬と認知心理学の研究からわかっているらしい。クラスメソッドさんが表彰という制度設計にしているのは、本人のやる気をなくしてしまわない報酬を考慮しているからかもしれない。

またコンテンツの所有権という側面からテックブログは会社のものだから、自身のブランディング戦略とは相性がよくない。これは 限定合理性 の話しとも関係してくる。開発者に限らないが、転職を当たり前にする時代で個人ブログに記事を書く方が開発者にとってのメリットがある。「会社ブログに書く動機はなにか?」は、人それぞれの理由があるだろうけれど、その理由が明確でないと消極的に会社ブログは書かないという帰結になるのではないか。私の経験則においても、会社のテックブログを書く開発者は圧倒的に少数である。私は過去に会社のテックブログを書いてきたモチベーションは単純にアウトプットすることで自身の勉強になるなら書く場所はどこでもよいという考えがあった。補足としては、会社の利益 (採用) に貢献しようとか、会社のテックブログを書く開発者が少ないという希少性に着目して自身をアピールするとか、そういった考えもあったと思う。

若い開発者にアウトプットする習慣を付けてもらう取っ掛かりとしてテックブログはよいのではないかという話題も出た。開発者のスキルアップのために会社がどこまでコストをかけてサポートするかという話題でもある。その延長上に評価制度もあるなぁと voyage さんの技術力評価会の資料もみてたりした。会社のイベントや業務を通じて、自然とアウトプットに関するスキルが身に付いて行動できるようになるなら本人のキャリアにとってもよいことではある。私は 書く という行為は開発文化から影響を受ける側面が強いと考えていたけど、voyage さんの制度はその下地を組織として支えていく仕組みになっているのかもしれない。

レビュー待ちのストレス

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

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

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

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

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

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

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

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

自己肯定感の考察

0時に寝て8時に起きた。

自己肯定感、高いか低いか

前になにかの記事で読んだことに、自己肯定感が高い人は困難な状況にあってもうまく折り合いをつけてやっていけるという。例えば、パワハラ気質の上司がいても、それは上司がおかしいのだと解釈して、なにを言われても全く自己否定やネガティブな感情にならないという。あるとき、別のイベントで起業家を養成するために幼児の頃から徹底的に自己肯定感を高めるためのカリキュラムを実践しているという話を聞いたことがある。田舎でのほほんと生きてきた人間とは幼児の頃から育ちが違う。

ふと自分の自己肯定感はどうだろう?とか考えるときもある。もうこの歳になって自己肯定感がどうこうで悩んだりすることはないけど、なにか事象が発生したときにまずは自分が悪かったんじゃないかと疑ってかかるところから思考が始まる。ネガティブな事象が起こると、自分が気付けば防げたとか、もっと機転を利かせばうまく対処できたんじゃないかと考えたりする。自己評価は5段階なら、自分で振り返って不満がなかったら3で、なにかあったら2をつける。そのため、多くのケースで360度評価が乖離する。たまたま野球部だったせいもあるかもしれないけど、基本的に監督に叱られるのが普通のような感覚をもっている。もっと言うと、他人から褒められた経験があまりないから褒められてもどう反応していいかもわからない。嬉しくないわけではないけど、相手に気を遣わせてしまって申し訳ないなとか思うこともある。

良くも悪くも私は他人に関心がないし、他人からの評価にはもっと関心がない。自分が取り組んでいる課題を自身の基準でうまくできたかどうかにしか興味がない。わりと他人に素っ気ない態度をとってしまうときもある。一方で他人から咎められると一通り自身の基準に当てはめて理が通っていればへこむときがある。褒められてもそれほど嬉しくないのに咎められたらへこむというのは、自己肯定感の高低によって変わったりするのかな?とか考えたりしていた。言うても、もうこの歳になると褒められることも咎められることもないのであまり気にする機会すらないのだけど。

メンタルモデルの参考

0時過ぎに寝て6時に起きてだらだらしてて8時に起き上がった。

会議室予約

明日おかださんと話すのでシェアオフィスの 会議室予約サイト で会議室を予約した。この予約サイト、リリースされて1年近く経つけど、本当に使いにくい。技術の無駄遣いって言葉がしっくり来る。会議室はオフィスを借りている人には5時間/月まで無料で使える。元町オフィスの会議室を予約するのは初めてかな。どんな使い勝手かを試してみるよい機会でもある。明日に備えて設備やモニターチェックをしていた。

ソフトウェアエンジニアと技術力

そねさんの1ヶ月以上前に公開されたスライドを、あとで読みこじらせて、今日読み直した。課題管理のためのメンタルモデルを確立しないといけないと考えるようになってきた。そのためのヒントになるかな?とちゃんとメモを取りながら精読しようと思って1ヶ月放置していた。他のことに注力していると別のことができなくなる。ソフトウェアエンジニアという定義をあまりみたことがなくて斬新だったり、書いてある内容そのものは共感できるものではあった。一方で精神論や思想的な話しが多くて、もう少し理論的な裏付けや技術的な背景があった方が私の好みだったなと1ヶ月も置いておいたから期待値が上がってしまっていた。

ソフトウェアエンジニアとは、科学 (ソフトウェア) を活用して問題を解決する力をもつ人であり、ソフトウェアを使いこなして最小の労力で問題を解決することを技術力が高いと言う。