HsbtDiary

■ マネージャに大事な3つのこと

マネージャの人の失敗事例が公開されており、ふむふむと眺めると確かにやってはいけないことだらけという感想になって、後進に向けて公開するのは立派だけど、記載されている行動によって人生を破壊された人もいるかもしれないので、マネージャの経験則の共有の仕方は難しいとも考えていた。

自分はマネージャとして仕事はしてないのだけど、じゃあお前はどうなんだよ、と自戒もしたので、マネージャの経験から得られた営利組織におけるマネージャにとって大事なソフトスキルというか大原則を、やや抽象度高めの3つとして書いておこうと思う。

マネージャのしごとはミッションの達成

マネージャをやってると、人と金を裁量によって使えるようになるので「心理的安全性が確保されたチームを作る」とか「開発生産性を上げる」みたいなことを仕事にしてしまいがちなのだが、それは手段であって営利企業の目的ではない。マネージャがやるべきことはそのような錯覚や甘い誘惑に惑わされずに「会社のミッションを(自分の裁量の中で)達成する」である。

ようは法令遵守しているかぎりは、ギスギスしていても、チームの成果は出すし、給与バンバン上げるぞ、というマネージャのやり方でもいいわけだ。僕はそういうのは not for me なのだけど、人から嫌われたくないためにどこにも良いことだけを言って、成果を出してないというのはマネージャとしてはジュニアである。なお、たまにマネージャが自分個人のキャリアやブランディングのために自分の裁量で動かせる金や人を使うというのを見かけるがそういうのは論外というのも書いておこう。

正しさが唯一ではない

エンジニアなど専門職出身のマネージャに多く、自分も最初はそうだったのだけど、RFC であるとかベストプラクティスとか、いわゆる「正しい方法」みたいなことにこだわるのはやめよう。正しい方法かどうか、はマネージャにとっての結果にほとんど意味をなさない。自分の会社は Google ではない、Google が言っているベストプラクティスは自分の会社では正しい方法ではない、まずは自分に関係する人々と会社が達成すべきミッションに向き合おう。

「このコードよりこっちのコードの方が速いですよね」とか「その話は〜で議論済みですよね」みたいな「効率的」「効果的」が良いとされるエンジニアとしての「正しさ」はマネジメントでは絶対視すべきものではない。昨今でこそブリリアントジャークという便利な言葉ができたので周知されてはいるが、マネージャにとってやるべきことは正しさを追求するよりも他の人をモチベートして成果を出すことだ。

色んな人がいる

これが最も重要なことなので最初に持ってきても良いのだが、実は社会には色んな人がいる。老若男女、早起きな人・夜更かし気味な人、介護中の人、子育て中の人、遠方から通っている人など色々いるはずなのに、マネージャという帽子を被った途端にそれが見えなくなって「誰もが勉強する」「誰もがコードを書く」「誰もが英語を理解できる」みたいなことを考え出してしまう。

最近だと解像度、などとも言うかも知れないけれど、いろんな人がいるという社会の解像度を上げた上で先に述べたミッションを達成するのがマネージャだ。誰にでもいい顔をしなさいということではなく、そもそもが異なる人間であるし、そんな人間を集めたチームはその瞬間で全部違う、ということを念頭においた上でチームを運営しなくてはいけない。

まとめ

以上特に気にかけている3つについて改めて書き出してみたが、「えっ、こんなことからなの」という内容ではあるものの、この時期のアドベントカレンダーで大量に共有されている世の話をみると意外とできてないか、ほとんどできてない、ということが多い。

前から何度も書いているが、マネジメントスキルは天性のものではなく、勉強して身につくものなので、自分には向いてないというのは理解できてないか、ただやってない、というだけのことが多い。マネージャの皆さんはちゃんと理解して臆することなくしっかりマネジメントやっていきましょう。

■ Ruby 開発者会議 12 月

Ruby 3.4.0 リリース前最後の開発者会議、なので主に 3.4 にこれ入れるの? 入れないでしょ、来年来年、とかそういう話が中心だった。

https://bugs.ruby-lang.org/issues/20879

今回は module Ruby を 3.4 のうちに reserve して今以上に氾濫させるべきじゃないとは思ったけど、class Ruby が使われている quine が世の中にあるらしく、そんなコードが動かなくなるというのはケアする必要がある。最初はなかったら定義すればいいんじゃないの?と思ったけど、インタプリタに定義されるクラスだから、ユーザーのコードの前に用意しないとダメなのであった。結局、こいつはむずいなーとなったので、3.4 では警告するだけということになった。

あとは assert -1, foo で警告でるのはうざくないですか、とか話していて、そもそも assert_* に括弧を書かないというのはどこ発祥なの?という話題になって軽く調べたら minitest ぽかった。minitest とは別の test-unit とか Ruby の昔ながらのコードは assert であってもカッコを付けている。へえ。

minitest から始まって Rails へ、という形で広まったと思われるけどこの辺の文化人類学っぽいのは面白いので誰か調べてみるといいかもしれません。