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ヶ月で即解約になったことはないので一定の自信もある。

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

0時に寝て3時に起きて2時間だらだらしていて6時に寝て7時半に起きた。ここ1週間ほどこういう寝方が続く。

運用対応の続き

昨日からまだトラブルが続いているらしく運用対応がてんやわんやになっている。私は本番環境のログもデータもみれないから社員さんから伝え聞く分しか状況がわからない。そのため、現状の運用でうまくいっているのかと思ってたら、たまたま他の要因が重なって発生しているのかもしれないけど、大きな障害に発展しているのかもしれない。従来の正しいと思われていた運用ツールにも誤りがあったらしく、これまでの運用は正しかったんやろか？という懸念も出てきた。スクラムマスターからも、既知の課題を放置してトラブルが常態化して運用対応に工数を割いて他の仕事ができなくなっているのではないか、仮説の検証をちゃんとやってないんじゃないかとかツッコミが入ってた。PO が未熟と言ってしまえばそうなのだけど、スクラムの悪いところは問題が起こっても責任の所在を曖昧に終わらせることがうちのチームでは多々ある。責任の所在をちゃんとふりかえらないと、再発防止やその対応に誰も責任をもたないという状況が発生する。今回のふりかえりがどうなるのかは来週にならないとわからない。ちゃんと反省してチームとしてふりかえりできるかどうかも観察してみようと思う。

次のお仕事探し

以前から勝手に私が応援している地元の会社の求人情報をみかけた。それは正社員しか募集していないのだけど、ダメ元で業務委託を雇っていないか問い合わせてみるかを迷っていた。そこで地元のコミュニティの知人が、地元の会社の中の人を知っていると話していたことを思い出して、その知人に業務委託で雇っているかどうかを試しに聞いてもらえるかを尋ねた。快く聞いてくれて、直接つながって問い合わせてくれて本当にありがたい。そしたら業務委託は採用していないらしいのだけど、一応は経歴はみるかも？といった返事だった。じゃあ、ダメ元で採用情報のページから応募しようかと考えていたら、その知人経由で経歴がわかるものがあったらそれでいいという話しになって linkedin と会社の事例紹介の url を転送してもらった。普通に応募するなら履歴書と職務経歴書をファイルで送らないといけない。仮に不採用になっても url を送るだけの手間しかかかっていない。わずか1時間ほどのやり取り。そう思うと人材求人プラットフォームに登録して、定型的な資料を用意して、手続きをとって、先方からの返信を待つといったワークフローはなんと無駄の多いことかとか考えたりしていた。

0時に寝て4時に起きた。5時からドラクエタクトしてた。

運用対応と遊休

今日も本番環境でトラブルがあったらしく、その対応で開発リーダーが忙しくて、お昼にあるチケットの仕様を決める小さい打ち合わせ (15分程度) を経て対応しようと思っていたのに、最終的にそれができたのは19時半になった。当然、実作業もやってない。昼間の3時間を休憩時間として別のお仕事をしていた。9月から新たにフロントエンド開発者が入って、チームの開発者が7人になって開発者が遊休する状態に拍車がかかった。本当はチームを分割すればいいけど、チーム事情でできず混乱している状態。権限委譲もできてないのでチームを任せられる開発者が他にいないのだと思う。人を教育せずに人数だけ採用して開発チームを拡充してきたのが垣間見える。古いプラットフォームの仕様を知っている人が1人しかいないといった状況は大変そう。そういう開発や組織を是としてきた先駆者の責任でもある。そんな組織の開発者が外部でいいことばかりを言っているのをみると、よい開発者が入ってきても騙されたと思って定着しないのではないかと思う。私がみえる範囲でもよい開発者がいないので組織における開発リーダーの重要性を実感する。

次のお仕事探し

たまたま求人検索していて Offers「オファーズ」 - エンジニア・デザイナーのための副業・複業・転職サービス というサービスをみつけた。ちょっと前に求人プラットフォームを開発していたのでいくつかの求人サイトに登録して調査したりしていた。その中でもこのサイトは上位に入る優れた品質だと思う。一番嬉しいのが職務経歴を linkedin からインポートしてくれる。求人プラットフォームでもっとも嫌なことは、それぞれのサイトごとに職務経歴書を作らないといけないところ。プログラマー的に同じ作業を何度も繰り返すことに苦痛を感じる。比較的新しいサイトなのでどういったものか、わかっていないけど、サイトの使い勝手がよかったので縁があれば面談もやってみようと思う。

3時に寝て7時に起きた。一昨日からやっているリファクタリングが佳境なので1時ぐらいまでコードを書いてた。コミットするときにソースコードを自動整形したらリファクタリングと関係ないところに diff がたくさん出てしまって、数十箇所は diff と突き合わせながらフォーマットを手で直さないといけない状況になった。量が多かったので不満が溜まってコミットしたときに課題管理にこんなコメントをした。

ソースコードがフォーマットされてないから自動フォーマットするとリファクタリングと関係ないところに差分が出るからそれを元のフォーマットに手作業で戻す作業を1時間ぐらいしてた。帰りたい。

2022/07/29 00:33:45

翌朝に来た PO がたまたまコメントをみかけてデイリースクラムで質問を受けて恥ずかしかった。変なコメントしてごめんなさい。

ストーリーポイント見直し大会

導入前からもいまもずっと私は一貫してこのプロジェクトでストーリーポイントの運用は不向きではないかという姿勢をとっている。ストーリーポイントを嫌っているわけではなく、論理的にうまくいかない課題をどうやって解決して運用にのせるかの施策が何もないのに盲目的に運用しているところに懸念をもっている。私の懸念を解決する施策を誰かが責任をもって進めるなら反対することない。2時間という時間を設けていたのでストーリーポイントの是非も含めての見直し大会だと私は考えていた。しかし、そうではなかった。始まって30分ぐらいは見直し大会をどう進めるかの会議の進め方を議論していた。この時点では私はこの会議にやる気をなくした。誰もなにも準備してなく、ただ2時間という時間をとっただけの会議だった。次の1時間で直近の実際のチケットをもってきて、内容を説明してみんなでポイントを付けていく作業をしていた。その後の30分はプランニングポーカーやって遊んでただけ。ストーリーポイントの運用の見直しという視点は何もなくて、いまの数値はデタラメだから正しい数値がつくリファレンスストーリーを作り直せばいいというだけだった。誰も責任をもってないので時間を潰すだけの会議だったと思う。

ちょうど10月末でお手伝いを終了することを伝えたのもあって、プロジェクトから去る開発者があれこれ大勢側に疑義を申し上げるのもどうかという思いもあって、これ以上はストーリーポイントの運用に口出ししないことに決めた。おそらくチームというよりは組織としてどうしてもストーリーポイントを運用したい動機が別の理由からあるようにみえた。ストーリーポイントさえ付けておけば、プロジェクトのスケジュールがどうなっても誰も責任を追求されなくて責任者は楽なんだろうと推測する。

一方で、協力会社の若い開発者がチケットの内容を説明していて、何度か「コピペしただけ」という説明の仕方をした。私は違和感があって気になっていた。本人は悪気なく大した工数ではなかったと伝えたかったのだと思う。開発作業の説明でコピペしただけと発言して恥ずかしいという感覚もない。仮にコピペしたコードを扱うとしても、そのコードの拡張性や保守性を考慮して抽象化することはあるだろうし、論理にあわせて修正するからまったく完全なコピペなどあり得ない。この発言をプロの料理人に例えたら「既成品をレンジでチンしただけ」と言っているに等しい。推測だが、プロの料理人は仮に既成品を使ってもそのまま客に出すことはなく、必ずプロとしての付加価値をつけていると私は思う。プロの開発者として開発の姿勢に問題があることがわかってしまうのに加えて、ビジネスパーソンとしても適切な発言ではないことに気付いていないのが不憫に思えた。まともな会社で働いていれば、先輩に叱られたり指導を受けたりできるのが、そんなことすら知らずにキャリアを歩んでしまう懸念がある。このまま中堅になったときにどこかで失言して信頼をなくしてしまうのではないかと心配になった。

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

煩雑な検証

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

会社のテックブログ談義

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

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

…

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

…

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

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

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

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

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

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

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

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

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

• 5分でわかる技術力評価会