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分でわかる技術力評価会

1時に寝て6時に起きた。朝ちょっとデバッグをやって午後からは来週のオンライン飲み会の手配をしたり、打ち合わせのメモをまとめたりしていた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。直近の2-3週間でやっていた ci/cd の改善や github actions のことについて共有したりした。次の契約更改のタイミングで契約条件の変更を相手と協議しようと考えている。具体的には単価をあげたり事例紹介を許可してもらったりといった類の交渉をする予定。一般論として業務委託は最初の契約条件から条件変更するのが難しいらしく、なかなかタフな交渉になるっぽいというのをはらさんから助言してもらったりしている。私の中では交渉するネタはいくつかあるし、ダメならダメで最悪のケースなら契約終了して、別の会社のお仕事に切り替えてもよいし、いまは開発者は売り手市場なので楽観的に考えていたりする。

近況報告

元同僚と1年ぶりにオンライン飲み会をした。それぞれ近況を話したりしていた。私が見限ったビジネスはその後うまくいったらしくてなにがうまくいくかわからんものだという話しも聞いた。私が在籍していた頃の早期退職制度は50歳以上が対象だったけど、いまは45歳以上に下がっているらしい。また来期から年配の社員を辞めさせるための追い出し部屋ならぬ追い出し会社がグループ企業として設立されるという話しも聞いた。おそらくは戦力外社員をその会社に集めて待遇を下げるみたいな話なんだろうと推測する。日本の労働基準法では、一方的な解雇や減俸はできないが、配置転換は許されていて、別会社に転籍してその会社の待遇が元の会社よりも悪いというのは法律的に問題ないらしい。本体より待遇の悪いグループ企業を作って、そこに転籍することで事実上の減俸や自主退職を促すような慣習となっている。私が起業した理由の1つは早期退職制度ができて自分の未来もそうなると実感したというのがある。少なくとも自分の会社で自分が解雇されることはない。

元同僚の1人も来期は45歳になるので早期退職制度を使って会社を辞めるかもしれないという話されていた。40代からのキャリアってなかなか難しいなとは思えた。私もいまはなんとかなっているけど、このままお仕事がある保証はないし、引き締めていかないといけない。ただあるとき急に追い出し会社に送られるという組織の論理で生きているわけではないという自由だけは謳歌している。

2時半に寝て6時半に起きた。なぜか眠れなくて鬼滅の刃をみてた。本当は夜に bizpy の資料作りをしようと思っていたけど、前日にあまり寝てなかったせいかバテてそのまま寝てしまった。

お仕事の辞め方

たまたまお手伝いしているところである開発メンバーが今月いっぱいで辞めますという連絡があった。その方は今日お休みだったので明日で辞めますみたいな急な連絡となった。もちろん上司や関係者には前々から話しは伝わっていて、引き止めや調整をしていたのだろうけど、チームとして働くにおいてメンバーはショックを受けるというか驚くというのが普通の感覚だろう。私も少なからず組織を退職してきた。私の場合、有給休暇が余っていたので辞めると言い出すのは実際に辞める3ヶ月ぐらい前で、有給消化が1ヶ月、引き継ぎに1ヶ月、引き止めや調整に2週間、2週間ぐらいはバッファみたいな感じで辞めてきた気がする。組織の規模によるけど、大きい組織は順番に引き止めの打ち合わせがくるので時間がかかる。組織にもよるけど、私の場合は3-4ぐらい、上長、課長、部長、その上の偉い人みたいな感じか。少なくともメンバーが退職を知ってから1ヶ月以内に辞めるということはない。私は過程の記録が課題管理システムに残っているし、ドキュメントも普段からそこそこ書く方なので辞めるときにドタバタすることはほぼない。ドキュメントなくても課題管理システムにやったことはすべて残ってますからと説明できる。上長からも引き継ぎに困るという心配をされたこともない。

辞め方というのはその人の信義を表すように私は思っていて、どういう背景や事情があるにしろ、ひどい辞め方をするのは本人にとって百害あって一利なしだと思う。余裕のない辞め方というのはあまり推奨しない。

忘年会

【初参加大歓迎】三宮.dev＆bizpy 合同忘年会 の日程を12月10日に決定した。オミクロン株の不安などが出てきたところだけど、水際対策をがんばっているのでまだ大丈夫かなといましかできない飲み会をこのまま行うことにする。言うても参加してくれるメンバーは限定的なのでいつも人たちで労をねぎらうみたいな飲み会になりそう。