0時に寝て何度か起きて7時に起きてドラクエタクトのランクマッチやってた。

法人決算

朝から着手した。過去の日記から 第3期の法人決算に着手した のは5月5日だったらしい。この情報だけでも昨年よりは体調がよく、いまの業務に集中できていることが伺える。過去3回分の法人決算のノウハウがあるから私にとって法人決算はなんら難しくない、ただの作業になる。しかし、こういった面倒なだけの事務手続きをいつ取り組めるかというのはモチベーション管理の視点からはとても大きな意味をもつように、年齢を重ねてから思うようになった。というのは本気を出せば数時間で終えるものの、あまり楽しい作業ではないので、他の楽しい開発や調べものに心を奪われがちになる。たった数時間なのだから先に事務手続きをやってから他の楽しいことやればいいやんと頭ではわかっているものの、それができるかどうかがモチベーション管理の難しいところ。連休の初日からそれができるのだから調子がよいのだろうと考えられる。

消費税の申告

法人決算と消費税の申告は同じタイミングで行うものの、それぞれの申告は独立している。消費税は未払金として決算書には記載する必要があるので普通にやると、法人決算の前に消費税の申告をやるという手順になるはず。昨年は3期目で免税事業者から課税事業者へと移り、初めての消費税申告でやや手間取ったが、今回は2回目なので昨年のノウハウがあって1.5時間もあれば完了した。昨年のメモを見返しながら課題管理システムに手順や要項をメモしながらやっているので実質1時間もあればできる。こうやって作業手順を洗練させていくのが課題管理的なやり方。昨年は消費税の算出と申告と会計処理を2日に分けて別々のタイミングで行っていた。会計システムに振替伝票を登録するやり方なども初めてでよくわからなかった。しかし、今年は全体像も手順もわかっているのでこれらの作業をまとめて完了できた。よい感じ。

パワーランチ

大学の同級生の友だちが実家に戻ってきた機会にオフィスを案内してお昼ご飯を食べて雑談してきた。本当は昨年末に予定していたが、年末休み前に 父の訃報 があって先送りしていた。引っ越してから知人がオフィスへ来た機会は初めてかな。お昼ご飯食べてカフェで雑談してなんやらかんやらで3時間ほど話していた。ざっくばらんに近況やキャリアや起業についての話しをしていた。友だちの会社は外資系なのでリストラが敢行されているが、その友だちはビジネスに近い方の業務をやっていて、そういう人たちはリストラされていないらしい。リストラされているのは新しいビジネスの種としてやってたプロジェクトのメンバーでそれはベテラン／新参に関係なくリストラされているそうなので外資の厳しさを伺える。あとはお仕事のパフォーマンスがよくない新参者がリストラされているのはそうらしい。

50歳のキャリアどうするといった話しをしていて、いまの会社でずっと働くという選択肢もある。一方で40歳を超えると転職はとても選択肢が限られるというのは私の経験からもそうで、おそらく50歳はさらに転職の選択肢が限定されるだろうと推測する。そうなると、起業するという選択肢もあるが、そういった将来のキャリア観をお互いに話していた。私からは誰にでも言っていることだけど、知り合いのスタートアップに転職するよりも自分で会社を作って好き勝手やるのが楽しいよとお奨めしておいた。

きんとん さんでシャトーブリアン定食 (2,600円) を食べた。ヒレの中心部分の柔らかい部分をシャトーブリアンと呼ぶらしい。とんかつの種類で言えばヒレカツに分類される。前から気になっていたメニューだったので祝日だし接待だしと良縁も重なって食べてきた。岩塩、わさび醤油、とんかつソースという3つのタレを使い分けられるところもよい。値が張るし、おいしかったし、見栄えもよいので接待にもよいメニューだと思う。食べログのとんかつ百名店[2022]の1つ。

これまで私はロースカツ派でヒレカツというのをあまり食べてこなかった。カツ丼も好きだが、通常はロースカツだと思う。東京へ出張したときに とん金 さんで食べたヒレカツがおいしかった。金曜日のランチがヒレカツ定食 (1,200円) になる。肉の暑さと柔らかさではきんとんさんのヒレカツに負けないインパクトがあったように思う。食べログの定食百名店[2021]の1つ。それ以来ヒレカツもおいしいなと思うようになってきた。加齢によって脂身をあまり食べられなくなったのもあるのかもしれない。

0時に寝て何度か起きて7時に起きた。休んでもよかったんだけど、休む理由がないので飛び石でお仕事することにした。

docker エコシステムの調査

少し前に docker をライブラリとして使って運用ツールを作った 。その内容をテックブログに書こうと思って docker のソフトウェアスタックやアーキテクチャの背景を調べ直していた。もっとたくさんいろんな記事を読んだのだけど、次の記事とそこから辿れるものを読むとよいだろうと思う。

• Docker社がエンタープライズ事業を譲渡した今、Dockerの父が思うこと
• The differences between Docker, containerd, CRI-O and runc
  • Red Hat, Google Engineers Work on a Way for Kubernetes to Run Containers Without Docker

コンテナに関して cri と oci という2つの標準化があることを学び、その実装として docker 社が使っているツールに関係があるのが次の3つになる。おもしろいことにすべて docker 社のリポジトリにはなく、oss として然るべき所管の organization にリポジトリがある。

• https://github.com/moby/moby
• https://github.com/opencontainers/runc
• https://github.com/containerd/containerd

すべて docker 社がオリジナルを作って、いまも moby は docker 社が主体となって開発を継続しているだろうけれど、コンテナの実行環境のプラットフォームは k8s に取って変わられ、cri のコンテナランタイムとしての containerd があれば moby は docker daemon や docker engine のためのツールでしかなくなっている。当初 docker と moby を分割したのは、docker を開発ツール、moby を infrastructure にするという判断の下、moby を k8s のようなプラットフォームにしたかったはずである。しかし、結果的にその標準化競争に破れ containerd があれば dockerd daemon は不要になったとも解釈できる。docker という名前はコンテナのエコシステムにおいて docker 社が提供するコマンドラインやプロダクトの総称としての名前でしかなくなってしまっていて、一世を風靡した docker というパッケージングシステムの開発元に同情してしまう感もある。いまの docker engine は docker daemon と containerd の2つの daemon を起動していて docker 社としては微妙なアーキテクチャになっているのではないかと推測する。とくに swarm なんか最早削除したいだろう。

こういった docker を取り巻くエコシステムやツールの背景を説明するだけでも1つの記事になりそうなことが1日調べていてわかった。

しくじり先生

たまたま 竹原慎二先生「５０歳過ぎてもケンカを売られ続けてバリしんどい先生」 をみたらおもしろかった。ガチンコをリアルタイムでみていた世代なので竹原氏には好感をもっている。少し前に 【あの人の健康法】元プロボクサー・竹原慎二の膀胱（ぼうこう）がんとの闘い のような、闘病生活の記事もみかけていた。病気は克服してがんばっているといるようにみえる。よかった。もう51歳なのか。

この番組の中で若い頃に上京してボクシングジムへ通ったときに根性の定義が変わったという話しが出てくる。

殴られても耐えることを根性だと思っていた。そのときに初めて殴られようが何しようが毎日辛い練習を重ねるのが根性だと気付かされた。

地元で最強だったのが、ボクシングジムのヤンキーでもない先輩にまったく太刀打ちできなかったという。そのとき1番違うのはスタミナだったらしく、竹原氏は1分で息がきれるのに相手は軽く流すといった様相だった。この先輩にボコボコにされた経験を経てそれから心を改めて真面目になったと言う。その後ボクシングと真剣に向き合い、1995年に日本人初のミドル級世界チャンピオンになる。おそらく番組の主旨的に若ものへのメッセージとして「強さ」について話されていた。

「ケンカに強い」だけが「強さ」じゃない、「強さ」の意味を履き違えずに生きよう。大人になると、いろんな強さを知る。大切な人のために仕事をどれだけ頑張れるか、辛い状況でもじっと耐えることができるか。そういう強さもある。

私は誰かのために仕事をがんばったことないし、辛い状況を耐えるみたいなこともほぼやってなくて、嫌になったら仕事を辞めてて、こういう言葉にあうと自分を恥じてしまう。その後、喧嘩自慢で youtube 動画を検索していたらまさにそういうのがあった。竹原氏が「勝てるはずねぇだろ、お前らこんな茶番なことすんなよ」とぼやいていた。先の番組の中でも触れていたが、本当に真剣勝負したいと思って来ているのではなく、記念に戦ってみたいという不純な動機でやってくる人が多いらしい。たしかにそれは相手するのがしんどそう。

0時に寝て6時半に起きた。朝起きてからドラクエタクトしてた。

リリース

今日がプロダクトのリリースとなる。先週前半にはテストを完了して開発作業も終えてインフラの整備やドキュメントの作成に注力してきたのでここ数日の様子をみれば無難に順調にリリースできたようにみえる。結果からみれば「余裕でしたね」とコメントされても大きく外れてはいない。6ヶ月でやってと言われた開発を、3ヶ月目に5ヶ月でできると勝手に短縮して、4ヶ月目にやっぱ間に合わないからもう1ヶ月待ってと6ヶ月に戻した。一人時間差攻撃みたいなマネジメントをして完了した。ここ2ヶ月ほど私がいくつか開発やデバッグを肩代わりをして開発の下支えをした。別に私がやったらいけないという制約はないけれど、メンバーの教育も含まれているプロジェクトなのでなるべくメンバーが経験を積んでスキルを磨くのが望ましい。この件はちょっとズルしましたと進捗報告している。まずはうまくいって安心した。

ともあれ、私がプロジェクトマネジャーという肩書きをもって臨んだプロジェクトで概ねスケジュール通りに開発を進捗させてお客さんの要件にあったプロダクトを作り上げたことそのものが、私のキャリアにおいても重要なことであるし、うちの会社では課題管理という分野をビジネスの中核にしていく上での最初の実績として大きな意義のあるプロジェクトだった。課題管理はチーム開発において強力な武器になる。これまでの自分と、そう大きく変わらない働き方をマネージャーでやっても結果を出せたことは自信にもつながる。

この後は6ヶ月間の大きなふりかえりも控えていて、課題管理に溜まったデータを分析して、次開発への改善などにもつなげていこうと思う。過去の経験則では課題管理の価値を実感してもらうのに半年はかかるというのが私の持論。それは比較的、最初から課題管理システムを使えていたうちのチームでも同じだと思う。私がやっている課題管理とメンバーのそれとの違い、その違いによる実際の業務における成果などを分析していくと示唆を与えられるのではないかと思う。

2時に寝て7時半に起きた。昨日もWBCをみてから晩ご飯を食べて軽く作業してそのまま寝た。

伴奏

ここ2-3日若いメンバーの開発をサポートしている。

「◯◯ができません」

私が5分ほどでググってできそうなドキュメントや so をみつけてリンクを貼る。

「できました。」

みたいなやり取りを何度かした。大して難しくない処理を実装できないのは公式ドキュメントをちゃんと読んでいないのと、インターネットの検索方法を習得していないように私からはみえる。一度、定例会議のときに google の言語設定を英語にした方がよい。日本のキュレーションサイトの記事の品質は低いからと伝えたが、まだそれを実践しているようにはみえない。いまや英語は deepl で翻訳すれば大半を斜め読みできる。私も deepl で読んでいると教えたりしているのだけど、日本語の記事しか検索していないから未知のことをできないとなってしまう。

チャットで困っていることや問題点を整理したり、どういう視点で調べていくかをやり取りしながら本人が理解して作業できるようにサポートしている。私がやれば10分で終わるようなことを2時間ぐらいかけてチャットしている。それで昼間は自分のお仕事をやらずチャットの話し相手を務めている。誰もが最初は初心者なのでそういう時期はある。以前は質問すらできていなかったところを、あれができないとか、これがわからないとか質問できるようになったというのは成長したと受け取れる。わからないことを説明してもらうことで、私も相手のことを理解できて適切な指示や指導ができる。その過程でプログラミングの理解度も測れるので issue をアサインするときの参考にもなる。

曖昧なことをチャットで聞くのは効率が悪いから、口頭であれこれ質問してくれるようになるのがこの次のステップかな。以前と比べて質問してくれるようになったので信頼関係は少しずつ構築できてきつつあるのかもしれない。

昔の自分といまの自分

既存のある java のコードを読んでいて、私の中ではワーストから数えた方が早いほどのひどいコードをみている。java の言語仕様もプログラミングもどちらもよくわかっていない人がキュレーションサイトにあるような記事を読んで動くように作ったようなツールにみえる。アリエルを辞めてからいくつかの会社で働いてきて java のコードも読み書きしてきた。これまでの経験からその職場での java のコードは品質が高かったし、私もその影響で java の設計やアーキテクチャにも関心をもつようになった。私は未熟なので人並み程度のプログラミングしかできないが、そのスキルを底上げしてもらったのはその職場での3年間の java 開発といえる。私にとっての普通が当時の開発体験やチームの同僚になったことでそれ以降に出会った開発者の大半はスキルが低いようにみえてしまう。そして、その後に私がどんなプロダクトを開発しても決して当時の先輩方に敵うことはないと慢心することもない。だからプロダクトの開発を終えて、組織の方向性にあわなければすぐに辞めることもできた。

いま私がメンバーに教えていることも、メンバーからみたら少し厳しくみえるかもしれない。私にとって先人のような偉大な開発者に自分もなれるんやろか？とか思いながらマネジメントをしていたりする。今週はとくに18時にホテル戻って2-3時間寝て22時頃から2-3時間コードを書いたりしていた。当時の上長もよくそうやって開発していた。当時の私はよく働いたが、そんな私からみてもその上長もよく働いていた。そして上長の生産性は私よりも数倍高かった。お互いに課題管理システム上にいることはわかっていたし、夜中の1時頃にチケット上でやり取りすることもあった。私もいま当時の上長と同じようなことをやっているなと感慨に浸りながら夜中にコードを書いていた。うちのチームのメンバーは誰も夜中に開発していないことだけが当時とは違うことにも気付いた。

1時に寝て2時、3時、6時と起きて7時に起きた。久しぶりに胃酸が逆流して気分悪かった。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。sveltekit アプリで使う ui フレームワークの相談をして、昨日の課題管理の雑談内容 からさらに考察を深めた。私の中では知っていたことだったはずなのに、いつの間にか、そのことを軽視してしまっていることを再認識したような発見だった。

コミュ障の私にとってはペアワークという概念がすっぽり抜けていたことは昨日書いた通りだが、それでもいまマネージャーとしてそれなりにコードレビューやインフラタスクに時間を割いている。プロジェクトマネジメントだけをやっているわけではない。それは自分が遊撃として開発者のメンバーを手伝っていることに相当するなと気付いて、そう言えば、過去に五月雨式にだらだらと遅れるようなプロジェクトでは、他のメンバーのタスクが遅れることを横からみているだけしかやってなかったような気がした。もし私が自分のタスクを投げ出して遅れている課題に介入したらどうなっただろうか？と思考実験するだけの余地はあった。

もう1つ。盛り上がった話しにおっさんはエモい話しをしにくいと私が考えていると伝えた。なぜなら、私の経験則ではエモい話しをするおっさんは総じてスキルをもっていなかった。具体的な知識やプラクティスを話すときはエモい話にならないからだ。その発言に対して、はらさんからはこんなコメントが返ってきた。おっさんもスキルはあるのだけど、そのスキルが時代にあわなくなって古くなってしまった。現場の技術とあわないスキルは、現場の人間からみるとスキルがない人と同じである。少し前に40歳の壁という本を読んだが、そのノリで言うと、40歳になるとスキルが現場に通じなくなる。

いまマネージャーをしていて気付かないうちに遊撃というポジションをこなしているのではないかと思うようになってきた。原則として実務をやらず、プロジェクトマネジメントをしている。とはいえ、コードレビューには2-3日／週ぐらいの工数を割いてきた。

— Tetsuya Morimoto (@t2y) January 21, 2023

sveltekit アプリのデプロイ

昨日の続き。Building your app によると、sveltekit のビルドは vite と adapter の2段階で行われる。gitlab ci/cd で node.js 向けにビルドして、それを docker イメージに同梱して、コンテナレジストリに登録する。あとはテスト環境で構築している docker compose に組み込むだけ。今日中にできたらいいなと思って、ぎりぎりだったけど、テスト環境で node.js 上にデプロイしたアプリと疎通できるところまでできた。ssr を介して web api サーバーと疎通できるところまで整備した。ここから先はメンバーに管理画面を作っていってもらう。メンバーの開発着手前にデプロイが一通りできているという気持ちよさ。

起業相談

過去に働いていた会社の、私と同い年の元同僚が起業するというので相談にのることに。私が会社を作ってなんとかやっているのをみて関心が出てきたという。いきなり会社を辞めると不安だから副業から始めて、本業の収入を上回るようになったから個人事業主から法人化しようと考えているらしい。実際に会社を辞めるかどうかはまだこれから検討するのかな？本業をやりながら最大4つか5つの副業をまわしてたというから驚き。そんなこと物理的に可能なの？と思ったら開発は人を雇ってマネジメントだけやったりしていたらしい。おそらく4人ぐらい開発者を雇っているという雰囲気だったけど、それでも本業をやりながら4つもマネジメントをするのは相当に大変だと思う。十分にその同僚の能力を認めているつもりだったけれど、それ以上の忍耐や集中力をもっていて、もしかしたら過小評価していたのかもしれない。1つの会社内でも3つ以上プロジェクトを兼任して成果を出しているマネージャーなんか私は見たことない。それを本業と副業と寄せ集めの開発者で実現しているのは類稀な能力だと思う。本人も睡眠時間削って働いてやり過ぎたとは言っていたが。法人登記、税金、節税、働き方とか、ざっくばらんに私が起業してやってきた3年間のお話しをした。なにかしら役に立って活躍されるといいな。

0時に寝て4時に起きた。5時前には家を出た。初日だけは早起きして新幹線乗らないといけないので緊張する。新神戸6時10分発が始発になる。始発に乗った方が混雑もしていない。9時過ぎにはお手伝い先のオフィスについて業務を始められた。移動に約3時間。早起きは三文の徳みたいな話。

フルリモートワーク

朝一でオフィスに着いたものの、チームのメンバーの1人はお休み、2人は在宅勤務、上長は出張だったので私が一人だけオフィスワークしてた。普段は私がフルリモートワークなのでうちのチームはリモートワークの働き方が容易になるように業務を設計している。私がオフィスにいようが、普通にリモートワークするのはある意味で自然な働き方とも言える。周りのチームの人に「あっ、いたんですね」とか声を掛けられながら1人で黙々とお仕事してた。

全国旅行支援 + ただいま東京プラス

今回の出張は全国旅行支援で宿泊費が40%オフになっていて、且つ ただいま東京プラス という取り組みで3000円/日のクーポン券が付いていた。 region PAY というアプリにクーポンを登録して QR コード決済で対応店舗で買いものできる。すべてのお店が対応しているわけではないが、普通に周りの飲食店やコンビニなどでも使えた。ちょっとよい晩ご飯の定食を食べて、帰りにコンビニで飲みものを買って帰るぐらいの贅沢ができる。至れり尽くせり。

競輪選手というキャリア

ホテルでたまたまテレビをつけたらやっていておもしろかった。競輪オタクが競輪選手になったらめっちゃ強くて無双している、どこかのラノベみたいな話し。競輪という競技を私はあまりよく知らなかった。なぜこんなことができるかというと、競輪というスポーツは純粋な体力や身体能力で勝敗が決まらないらしい。試合展開の駆け引きがあって最後に勝敗が決まる。競輪オタクはすべての選手のプレースタイルを記憶していて、個々の選手の戦術を予測して対策できるから勝てるのだという。

• 競技経験ゼロ！28歳の「脱サラ競輪選手」。“オタク知識”をフル活用してまさかの快進撃

2時に寝て7時に起きた。とくに可もなく不可もなく淡々とリリース前の開発の詰めや検証をしていた。大きな改修を先週末に終えていたので後始末的なタスクが主だった。

お仕事探し終了

いくつか選考して次のお仕事を決めた。8月からお仕事探しをしていた。いくつか求人プラットフォームのステータを更新し、途中まで選考が進んでいた会社には辞退メールを送った。昨年は1ヶ月ほどで次のお仕事をたまたまみつけたけど、今回は2ヶ月ぐらいかけて求職活動をしていた。探す期間が短いとどうしても妥協したり近視眼的な考えに陥ってしまいやすい。心に余裕があることの利点を考慮して2ヶ月ぐらいかけるのがちょうどよいのかもしれない。私は基本的に辞めると決めて関係者と調整してから次を探す人間なので転職活動に失敗すると無職になるリスクが高い。自分の会社に所属していると、最悪の場合、契約終了時に次のお仕事がなくても無職になるわけではない。この安心感が人生において重要なものだとわかるようにもなってきた。

今回は3つの経路を使ってお仕事探しをしていた。

• 人脈
• スカウト
• エージェント

以前にも書いた が、私のような人間は普通の求職活動をしても、他者と比べて秀でたところがなく競争に勝つのが難しい。コミュニティやいくつかの会社で働いてきた人脈を駆使して、自分という人間を知っている人からお仕事をもらうしか生き残りの戦略はないのかもしれない。次のお仕事は課題管理を徹底的に実践して他社のお手伝いをする。うちの会社が今後ビジネスをやっていけるかどうかの分水嶺になるかもしれない。できるだけの準備をして臨む。

0時に寝て7時に起きた。朝には台風は過ぎ去っていた。

ロガーとデータベースとの境界

ちょっと前にバッチ処理の履歴をデータベースに保持して履歴情報を使って運用対応がやりやすいような機能を一通り構築した。その延長上でロガーが任意のログをデータベースに保存できるようになれば、開発者からみてロガーを使ってログ出力するだけでデータベース保存もできてよいのではないかと考え始めた。既存の処理を見直しながらその移行ができそうかどうかを考えていたら、既存の処理をすべて捨ててもう一度スクラッチから作り直した方がよい気がしてきた。また明日そのアイディアの是非を確認してみようと思う。

ブロックチェーンのお仕事の面談

ある会社から lapras さん経由でスカウトをもらってカジュアル面談をした。ブロックチェーン界隈の事業のミドルウェアに位置するサービスのようで、ブロックチェーンからみたらアプリケーションだけど、web3 や nft のようなアプリケーション側からみたらインフラ側といった業務内容だった。ブロックチェーンや web3 関連は昨年ぐらいから情報収集していて関心のある業界ではある。私自身バックエンドのスキルやキャリアを高めたいという考えもあり、流行りと詐欺のみわけがつかない上モノのアプリケーションよりも基盤の方が向く。話しを聞いていて真っ当なビジネスであることは確認できた。ブロックチェーンの予備知識はまったくないが、先方も基本的な技術は web2 でも使われているものを使って構築されており、一般的なコンピューターサイエンス、データ処理やアルゴリズムの知識があればよいとのこと。話しを聞いていてそれはよく理解できた。先方は基本的に正社員で採用を考えていて、私は業務委託でしかお手伝いできない。いまのところ、自社プロダクトの開発に着手するまであと1-2年しか時間がない。この職場に私が参加しても1-2年後には辞めないといけないとしたら申し訳ないというところだけが懸念に思えた。カジュアル面談だったので選考の候補の1つとして一旦は保留しておく。

23時に寝て5時過ぎに起きた。7時にはオフィスに着いて9時までプロダクトオーナーのためのインフラ入門のドキュメントの続きを書いてた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。前隔週を1回飛ばしたので話題はたくさんあった。エージェント経由のお仕事探しはまったくうまくいってないという状況を相談していたら、私のような開発者が匿名の職務経歴書で選別されるのは難しいのではないかとのこと。まさにその通りだと私も思う。逆に個人のパブリックなリソース (github, qiita, blog, slide など) からスコア算出するサービスは相手から面談のオファーがくる。長く生きている分だけパブリックなリソースがあってスコアがよくなるという理屈だが、そういったお仕事探しをしないと私の実績や経験では職務経歴書の見栄えが足りないということを学んだ。はらさんからのアドバイスとして、勉強会やイベントに登壇して発表者だけのレセプションパーティーに参加するのがよいと教えてもらった。懇親会とは異なる。懇親会はどちらかという参加している開発者のためのパーティーだが、レセプションパーティーは関係者のためのパーティーなのでスポンサーや著名人と話しやすい。そこでコネができるとカジュアルによいポジションのお仕事の紹介/斡旋が起きるとのこと。

お仕事探し

知人の働く会社で面談してもらった。たまたまやり取りするきっかけがあったので開発者を探していれば声をかけてくださいと言ったらまさにそういう状況だったみたい。経営者の方々とも、私からは面識があって10年以上前に1度だけご挨拶したことがあった。先方が覚えてくれていたかどうかはわからない。「いま何歳？」と聞かれて、あのとき20代だった人間がもう40代か、歳とったなとみんなで笑っていた。そりゃ16年も経っているのだからそうだよねって感じでおもしろかった。業界内ではトップレベルのパッケージベンダーだし、私自身も大先輩の方々だと認識しているし、技術的にも私などがお手伝いできるのだろうか？という懸念はあったものの、先方がやってほしいと考えている業務内容だけをみたらマッチングは問題なさそうに思えた。うちの会社のビジネスにしたい課題管理のノウハウを実践したり体系化したりする現実の職場としてもよさそうに思う。詳細な契約の条件や先方の要件などをこれから摺り合わせていく。うまくいくといいな。

0時に寝て7時に起きた。直近は日曜日はだらだらしてたんだけど、すんなり起きれた。

お仕事探し

offers さんのカジュアル面談 の雰囲気から企業に直接応募するプラットフォームの方が、私の経歴や実績の詳細を確認しやすいので面談に進みやすいのではないかとみている。そこで findy と lapras のプロフィールを作成してみた。これまで oss 活動やブログなどでアウトプットしていた資産がたくさんあるのでレベルはしょぼいにも関わらず、これらのプラットフォーム上ではそこそこよい数値がアルゴリズム的には算出される。プラットフォーム側としては転職やエンゲージメントを高めたいという意図があるから、ゴーストアカウントのようなものも含めて算出すると普通の人は高めの数字が算出されるのではないかと推測する。

やってみた / 【スキル偏差値v2の診断結果】

エンジニア向けスキル偏差値の診断結果は、Total 81.0、Python 81.0、HTML 80.0、Java 78.0でした。あなたもスキル偏差値をチェックしよう！ https://t.co/4E4ibyevz0 #findy #スキル偏差値v2

— Tetsuya Morimoto (@t2y) September 11, 2022

findy さんのスキル偏差値によると、想定年収予測は1060-1160万円らしい。この数値は起業する前のサラリーマン時代の年収に近いのでそんなにずれてはいない。lapras さんの公開プロフィール によると、技術力が4.01で約170万人中668位だというのは上位 0.04% に属することになってしまう。んな、あほなという思いはある。とはいえ、自己申告の経歴をいくらでも盛れる職務経歴書よりも、客観的なアルゴリズムで評価できる指標の方が絶対値が適切かは置いておいても、相対評価において他の候補者と比較できるのを好む採用担当者もいるだろう。匿名の一般的な職務経歴書を用いる remogu さんの選考 は書類選考でばんばん落ちまくる。それに比べたら、アルゴリズムで相対的によい数値が出ているプラットフォームの方が面談に進みやすいのではないかという話し。本当にそうかどうかの仮説はこれから検証する。

google の従業員が働いていないという発言の真意

昨日たまたま medium のダイジェストでみかけた記事を読んだらおもしろかったので、なるべく余裕のある日は medium の記事を1つ読むようにしてみようかと思う。言うても deepl を使って斜め読みして大意を掴む程度なので日本語の記事を読むのとそんなに時間が取られるわけではないと思う。今日は次の記事を読んだ。

• Why Google Employees Don’t Work

プログラミングにおける生産性とはどういうものかを説明しつつ、google の ceo がいう生産性が十分ではないという発言の真意は、従業員が業務時間にさぼっているとか怠慢だとかいう意味ではなく、google のビジネス全体がこれまで達成してきたのと同じ業務時間では期待した成果を達成できなくなってきているのではないかと考察している。

At some point, productivity measurement becomes Schrödinger’s cat.

また著者の引用？では生産性の計測とはシュレディンガーの猫のようなものだという話題もおもしろい。どんな会社もある時点での生産性の測定はシュレディンガーの猫のようなものになる。セグメントを分割し過ぎると返ってストレスとなり、余計な混乱を招き、計測そのものが生産性を低下させる。生産性の測定はマクロレベルでやるのが理に適っていて、工場時代のマネジメントをもつ amazon は大量の人員削減をしつつも成し遂げた。google のようなワークカルチャーをもつ会社ならその気になればスマートにできるだろう。一方で google という会社はすでにリベラルな極みにある企業文化をもっているため、生産性を測るような試みは組織全体に大きな感情的ダメージを与えるだろう。その結果として amazon と同じような道を歩むのではないかと。

シュレディンガーの猫がどういう意味かもわからなくてそれも読んでた。

• 「シュレーディンガーの猫」って結局どういう話なの？モヤモヤする部分を解説！

23時に寝て5時だと思って3時に起きてそのまま家事をやって5時から働いてた。早起きすると暇つぶしのように溜まっているタスクをこなし始めるので早起きは三文の得というのは本当だ。非稼働日だけど、午前中に次のタスクの要件のヒアリングだけやっといて、月曜日の朝一から作業できるように調整しておこうと考えたが、今日は開発リーダーが休みだったので何もしなかった。

カジュアル面談

Offers というサービス でみつけた会社にカジュアル面談を申し込んでいた。エンジニアリングマネージャーを業務委託で募集しているのは珍しかったのでその背景などを聞いてた。面談してくれた方はテックリードと言っていたが、この人も副業で手伝っているらしい。雰囲気的に若い会社のようで正社員はほとんどいなくてチームのメンバーが10人ぐらいのうち正社員が1-2名だという。基本的に外部の寄せ集めメンバーがそれぞれ副業や業務委託で空き時間を使って開発しているといった話らしい。8時間/週といった契約のメンバーもいるとのこと。どんな人を採用するにしてもまず業務委託から始めるというのがその会社の方針らしい。信頼関係という視点からみると、このような経営者にとって都合がよい労使関係を嫌う人もいるのではないかと思う。一方で私は雇う側も働く側もお互いにマッチングしないときの不幸を防ぐには1-3ヶ月ぐらい働いてからお互いに望むときに採用するといったやり方の方がよいと考えている。実際にマッチングしない人の場合は1週間で見切りをつけるとかあるらしい。私自身、初めてお手伝いする会社は最初の3ヶ月とかは1ヶ月契約でも構わないと伝えることがよくある。その後、お互いにマッチングするなら3-6ヶ月の契約期間に延長したいと交渉する。20年働いてきて、過去に試用期間で解雇されたことや1ヶ月で即解約になったことはないので一定の自信もある。

テックリードが若かったので組織もチームもメンバーも若いのだろうという印象を受けた。業務的にはお互いにマッチングしているように私からは思えた。あとは単純にテックリードが話してみた感覚や相性で私のようなベテランを求めているかどうかで次の選考の有無が決まるのではないかと推測する。次があったら正社員の人とも話してみたい。