2時に寝て何度か起きて7時に起きた。9時ぐらいまでだらだらしてた。

事例紹介のたたき台更新

8月の上旬には たたき台を作成 していたものの、レビュー待ちしてたり、他の開発業務に意識を取られてそのまま放置していた。go-ldap のテックブログ を書いた後にその成果も事例紹介に含めて公開できる。結果的にはこの順番でよかったとも思える。また2週間も文章を寝かせておくと、記憶がリセットされて自分の文章の拙さにも気付けて全体を推敲できた。自分の成果物を自分で信頼しないというのが大事。明日に草稿を先方に提出して来週中には事例紹介を公開できるようなスケジュールで進める。

椅子の受け取り

また ジモティー 検索でみつけたバランスチェアを購入した。3,500円。なかなか無料や安価でよい椅子はみつからないのでこのぐらいの値段は出すのが相場のように思える。同じようなバランスチェアの新品の価格を調べると2万円程度だっだ。中古でこのぐらいの価格なら妥当にみえる。以前に購入したバランスチェア をオフィスで使っていて、それも快適なので実家の離れ用にあってもよいと思えた。

引き取りは車で20分程度のところにある駐車場に行ってきた。愛想のよい方ですんなりと取り引きを終えることができた。感謝。

2時に寝て何度か起きて7時に起きた。朝から弁護士さんにメールの返信をしたりしていた。午前／午後と普通に運用ツールの開発をして夕方に勉強会をして、夜に軽く呑みに行ってきた。

go-ldap テックブログとその勉強会

水曜日から テックブログの執筆 に着手して、木曜日のお昼には下書きを書き上げて社内レビューをお願いしていた。ldap プロトコルの振る舞いについて調べたことを書いた。あまり自信はなかったけど、社内のシニアエンジニアにレビューしてもらって、よく書けているとコメントをもらってシンプルに嬉しかった。いま開発の佳境のしんどい時期に、非開発以外のことに時間をとって記事を書いて報われた気持ちになった。

今日のチーム勉強会は私が担当だったのでこのテックブログの記事を解説した。実際に go-ldap のソースコードを一緒に読みながら進める。書いたり話したりすると、ちゃんと自分が理解できているかどうかを確認ができる。そして、コードを読みながら説明しているときに、記事に書いてある内容が一部間違っていることにも気付けた。こういう体験の繰り返しで私は自分を信頼しないことを学ぶ。私の浅い理解や未熟さを実感する機会があって、また次にがんばろうというモチベーションにもつながる。

自身の理解度の確認やチームへの共有、モチベーションコントロールなど、複数の意味で自分が書いたテックブログの記事を解説する勉強会はいいように思えた。

• go-ldap へのコントリビューション

思い入れのあった内容を書いて公開してしまうと、燃え尽きのような、少しやり切った感を感じていた。しかし、開発はまだ佳境の途中なのでここで立ち止まることはできない。それで呑みに行ってみた。とくに目的なくみつけたお店に初めて入ってみた。普通の居酒屋よりちょっとだけ値が張る感じの、落ち着いたお店で、私よりも少し年配 (にみえる) マスターが1人でやりくりしていた。軽く話しながら晩ご飯を食べれてやや救われた。また行ってみようと思う。

1時に寝て何度か起きて8時半に起きた。数ヶ月に1回ぐらいの頻度でしかないことだけど寝坊した。起きたら8時半であれ？と思った。起きてから家でそのぐらいの時間までだらだらするのはちょくちょくあることだけど、気付かず寝てたのは久しぶりだった。

台風が過ぎた後の焼き鳥屋さん

今朝に寝坊した理由はこれだと思うけれど、昨日の22時から晩ご飯を求めて仲のよい焼き鳥屋さんへ行ってきた。台風で9割以上のお店が閉めている中、唯一と言っていいぐらいの珍しさで開いてた。そのお店 (グループ) のオーナーは雨が降ろうが槍が降ろうが営業日は開けるという方針らしい。マスターも夕方から台風は過ぎて雨も弱まっていたので普通に営業していたらしい。しかし、お客さんは数グループと少なかったと仰っていた。私が22時に行って誰もいなくて24時までいたけれど、誰も来なかった。通常なら22時だと他に2-3グループはいて、その後も最低でも1グループは飲みにやってくるぐらいの人気のある焼き鳥屋さんだ。そもそも駅から人が出てこないし、道にも人が歩いていない。物流も止まっていたのでいくつか仕入れが出来なくて提供できないメニューもあった。

いつもなら2杯飲んで帰るところを、こんな日だから売上に貢献しようと思って3杯飲んで寝坊した気がする。

mongodb 7.0.0 リリース

ちょうど qa テスト前で mongodb のメジャーバージョンがリリースされそうなので毎週のようにチェックしていた。rc10 までいって ga されたみたい。

• MongoDB 7.0.0 is released

まだ docker hub には正式なリリースバージョンのコンテナイメージは公開されていない。しかし、rc10 が ga になったはずなのでひとまずはそれを使って開発環境とテスト環境を 7.0.0 に移行した。うちの用途だと ttl インデックスを作り直す以外には移行作業は必要なかった。自動テストはそのまま成功したし、テスト環境のデータもそのまま移行してパッとみた感じでは正常に動いている。来週から qa テストも始まるのでぎりぎり間に合ったというところ。MongoDB Software Lifecycle Schedules によると、だいたい mongodb は3年サポートされる。メジャーバージョンが年に1回リリースされているようにみえるので、いまメジャーバージョンを上げておくと1年余裕をもって運用できる。

テックブログの執筆開始

お昼からテックブログの執筆に着手した。あまり大きな意味はないのだけど、お手伝い先のテックブログの記事を早く3つ書きたかった。別に三部作というわけでもない。けれど、テックブログ書いてますよと他者へ伝えるときに最低3つぐらい記事を書いていないと、全然書いてないやんと私なら思ってしまう。3つぐらいあれば、この人はこういう技術に関心があるんだ、こんな業務をやっているんだ、内容もしっかり書けているねとか、そういう判断を下すことができる最低限のコンテンツ量と言えるのではないだろうか。私にとってはそれが3つの記事と言える。ちょっと前に公開した podcast でテックブログの記事を読んでくださいと話したのでリスナーが聞く前に増やしておきたい。ちょうどプロダクトのプレスリリースも出たのでその宣伝も兼ねられるし、勉強会のネタにもなるし、私の義務感を軽減してストレス解消にもなるし、ここは踏ん張って今日・明日で下書きを書き終えたい。

2時に寝て6時に起きてだらだらしてたらいつの間にか2度寝して9時に起きた。8月は開発の佳境なので基本的には土日を働く予定。

晩ご飯を外食して、夕方から NieR:Automata Ver1.1a というアニメが2期決定というニュースをたまたまみて、1期のコンテンツを見始めた。品質の高い作品だとは思うけれど、世界観 (設定) が私の頭の中のなにかとあわない。世界観の違和感や矛盾を受け入れ難いものがあって引っかかりを覚えるような作品だった。もともとゲームが原作らしい。人によって評価が分かれそうに思えた。

事例紹介のたたき台

先日のプレスリリース の続き。こういった会社の正式な文章を書くのは、その労力以上に面倒臭さが上回って後回しにしてしまう。簡潔な文章なので、過去の体裁やフォーマットなどをみながらやればすぐにできた。今回は私はマネージャーとしてプロダクト開発しているので、うちが作ったんよ的なノリでちょっと前のめりにプロダクト紹介をしてみた。私がもっている課題管理のノウハウを駆使して開発プロジェクトをうまくまわした工夫も書きたいところだけど、そうすると事例紹介と課題管理のプラクティスの話しがごっちゃになって訳の分からん記事になってしまう。事例紹介とは別に、今回の事例をベースに課題管理のプラクティスの記事を別途ブログに書こうと思った。他にもお客さん先のテックブログにも書かないといけない記事が2つ溜まっている。私は文章を書くのが遅いからなかなか捌けない。日記を書いて練習しているうちに早く書けるようにならないかな？と期待しているが、まだまだそんな予兆はみえない。

syncrepl を使ったエージェントアプリケーション開発

昨日のレビュー対応したものがマージされた 。それをもって自分たちのアプリケーションのコードを書かないといけない。以前に ldap の dirsync というプロトコル をメンバーが実装して、それを使ったアプリケーションのコードがある。その実装といくつか共通部分を再利用しつつ、プロトコルの違うところだけを追加できるようにしたい。既存のエージェントアプリケーションのソースを読みながら、どういう風に設計していくかのイメージを膨らませておいた。今日のところはコードを読んで頭の中に入れて考えるだけ。この状態で一晩寝かすと、寝ている間に脳が無意識に考えてくれて効率がよいはず。これは休日の時間のよい使い方だと思う。

お酒飲んで新幹線乗ったせいか、新幹線の中であまり寝られなくて暑くていつもより移動に疲れた。その後1時に寝て何度か起きて7時に起きた。2日酔いではないが、寝起きの気分はよくなかった。

issue を作ることによるストレス軽減

昨日の打ち合わせのメモから議事録を作ったり、そこから新しい issue を作ったりしながら来週の打ち合わせの資料作りをしていた。資料を作っている途中、割り込みでメンバーのコードレビューが入ったりして、あまり資料作りは進捗しなかった。

打ち合わせした内容から issue を作る作業を、私は好きだったりする。何をやってよいかわからない状況というのは苦しい。issue を作ること、要件を言語化したり、背景を調べたり、他の issue との関連付けしたり、そういった手を動かすことがきっかけになって、その issue を明確化していく作業を積み重ねれば時間の経過とともに課題が解決するということを経験的に理解しているからだ。

大雑把に言えば、私にとって、issue さえ作れればその課題解決は優先順位付けと (解決までの) 時間の問題に置き換えられる。あれやらなきゃ、これもやらなきゃ、なにか抜け・漏れがあるんじゃないかと頭の中でもやもやしているものを issue という概念に変換することで考えなくて済むようになっていく過程がストレスを軽減している気もする。

コンテナ勉強会

先日公開したテックブログ とプラスアルファで勉強会をした。コンテナという汎用的な話題だったので CTO から社内向けにアナウンスされて (半業務命令っぽい雰囲気で) いつもより参加者は多かったように思える。10人前後は参加されていた。40分ぐらいで話し終えて20分ほど雑談の時間をとって盛り上がりは微妙だったけど、いくつか意見や質問が出たのでよかったのではないかと思う。

チームのメンバーが発表するときは私がモデレーターの役割をしている。私が発表するときはモデレーター兼発表者になってしまう。モデレーターと発表者を兼任するのはとても難しい。おそらく脳の集中力を向ける先が異なるからではないかと思う。モデレーターは質問者の質問を広げたり、コミュニケーションがうまくいくように手伝ったりする。回答から次の質問を考えたりもする。一方で発表者は自分の調べたことや伝えたいことを聴衆にわかりやすく伝えることのみに注力する。

モデレーターと発表者が同じになってしまうと、自分の説明のどこが伝わっていないのか、質問者の意図を組むにはどうすればいいかといったモデレーターの視点がなくなってしまう。以前 tenntenn さんの個人カンファレンス に参加したときに1人2役でパネルディスカッションをされていて、そのときに同僚からあまりやり過ぎると人格崩壊するから気をつけた方よいといった忠告を受けたと冗談で話されていた意味が理解できた。役者が他人になりきるように、これは兼任じゃなくて1人で2つの人格を演じないといけない。そんな器用なことはそうそうできない。

少し寝ようかと思って横になった時間はあったものの、寝過ごすのが怖くて結局は新幹線の始発まで起きていた。この時期は4時を回り始めると徐々に外が明るくなっていき、5時は普通に明るくなっている。夏至も近い。

テックブログ公開

先日書いてレビューを終えた テックブログを公開した。

• Docker とは何か？

コンテンツは狙ってバズらない

私の言葉だ。多くの開発者が関心をもつ話題ではないけれど、仲間内では評判がよかったので拡散されると嬉しい、、、。と淡い期待を寄せていたが、そうでもなかった。工数をかけて丁寧に書いても関心をもたれないことはよくある。個々のコンテンツがバズらなくてもコンテンツは積み重ねることも大事なので私がよいと思う記事を今後も書いていく。

半年間の開発のふりかえり

2時間をとって半年間の開発のふりかえりをやった。課題管理システムから定量的な数字をみたり、定性的なのは、過去のマイルストーンのふりかえりのふりかえりをしたり、課題管理システムから特定の issue を取り上げて改善するにはどうしたらよいかなどを議論したりしてみた。

私もチームのファシリテーションに慣れてきて、自由に意見を求めるよりも、個人個人を指してどうですか？と尋ねる方が意見がわーっと出てきて議論が活発になることに気付いた。なにか議題があったら必ず当てられて意見を言わないといけないとメンバーも察してくれるようになっていると思う。そういう空気になってきた。そして、ちゃんと答えてくれるのでそれで問題ないと思う。大人しいというのか、消極的というのか、うちのチームのメンバーには意見を求められなければ言わないという姿勢が垣間みえる。これは開発の自律性とは反対にある価値観なのでなるべくそこから脱却して自分から議題に意見を言うようになってほしい。もしかしたら私が喋り過ぎなのかもしれない？

ふりかえりをしないチームは多いので何もしないよりはなにかしら 示唆は与えられた のではないかと思いたい。

3時に寝て7時に起きた。昨日は連休明け初日なのに2時まで作業していた。開発が落ち着いたので夜に自社のお仕事をする余力が戻ってきたとも言える。

Docker についてのテックブログ執筆

先日から Docker エコシステムの調査 をして、そこでわかったことをテックブログとしてまとめていた。一通り書き終えてマージリクエストを作成して社内レビューを依頼した。当初は 「ライブラリとしての Docker とは何か？」 というタイトルで書いていたものの、レビューを経て「ライブラリとしての」という修飾は必要ないことに気付いた。そのまま Docker のコンポーネントのソフトウェアスタックや過去の経緯や現状の雰囲気がわかるような記事にした。Docker を中心としたコンテナプラットフォームと標準化の概要について追っていく記事に仕上がった。インフラに関心をもつ人たちは少ないかもしれないけど、個人的にはコンテナの学びになってよい記事に仕上がったと思う。調査と執筆とレビューを含めると5人日ぐらいかけている。かけた工数を考えれば当然と言えるかもしれない。

デザイナーさんと契約締結

昨日の続き。デザイナーさんからいただいたワイヤーフレームをレビューして、契約書の叩き台も送付して、先方の所感や意見も伺いながら契約を締結した。基本的にはこちらが提示した契約書の通りに進んだのでとくに揉めることなくうまくいったと言える。顧問のはらさんからデザイナーと契約をするときの要項を事前にヒアリングしていて、その詳細を盛り込めんたこともよかったと思える。サイトデザインをお願いするものの、hugo のテンプレートは私が実装しないといけない。ある意味デザイナーと協調してサイトデザインを構築すると言えるかもしれない。私もそこから学ぶ機会があるだろうし、その過程でできた成果物は hugo のテーマとして oss で公開したい。

昨日は夜に晩ご飯の買い出しにオフィスを出てから、また戻って作業して22時頃に帰ってきて0時に寝て7時に起きた。今日はここ1-2ヶ月では久しぶりにプロジェクトの締め切りに追われずに落ち着いてやりたいことができた。

ストレッチ

先週に比べれば負荷は減っていたので右腰の張りは少しよくなった。むしろ先週が悪過ぎた。いつも通り右足全般は張りがあるのと、お尻と太ももの境界のツボもいつもより効く感じがして辛かった。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。リリースに向けての根を詰めてやってきた作業も一段落したのでこれからは体調をよくする方向に意識を向けていけるかもしれない。

プロダクトのドキュメント

追われてないので余裕をもって昨日の続きで2時間ほど書いてた。3 (ページ) ファイルを追加した。ドキュメントは一気に書くとしんどい。少しずつ書いていけば徐々に文量が増えてさらに内容も洗練されていく。休日にドキュメントを書いていると途中で割り込みが入らないから集中できて効率がよい。ソースコードにしろ、文章にしろ、書くときに割り込みが入らない状況は重要なことに最近気付いた。この日記もまとめて数日分を (下書きから) 書くときがあるが、それは集中して書ける時間を取れそうと見計らって書いている気がする。どうやら私は割り込みの有無と書くときのモチベーションに相関関係があるように思える。

きんとん

夕方にたまたま出掛けて、よく行くお店で晩ご飯食べようと思ったら開店の20分前で諦めて帰ろうとしていたときにたまたま目にとまった。以前から人気のあるお店であることは知っていたし、いつか入りたいと思っていたお店で、中途半端な時間帯だからお客さんも少なくて、いまがその「いつか」だと気付いて きんとん 神戸店 に入ってみた。後で食べログのとんかつ百名店2022の1つであることを知った。昔からあるから古いお店だと思い込んでいたけど、実際はそうでもなく、店内はオープンでモダンな佇まいで少し驚いた。特選ロースかつ定食が1900円。ちょっと高め。おいしかったので十分に満足した。タレもとんかつソース、わさび醤油、ヒマラヤ岩塩があって、それぞれに味わいがあってよかったし、キャベツにかけるドレッシングもオリジナルでおいしかった。接待にもよさそう。

第4期のふりかえり

年度が変わって1ヶ月が経とうとしている中、ようやく昨年度のふりかえりができる状況になってきた。今年は3月に余裕がなくて少し後ろにずれ込んでいる。この年度ふりかえりも毎年やっているから知見も溜まっていくし、新しい発見もある。来週の雑談に向けてまずは叩き台を作った。もう2-3日ほどかけて資料を洗練させていく。

0時に寝て何度か起きて6時半に起きた。起きてから8時までだらだらしてた。寒くて起きれない。2月入ってしまった。早いなぁ。

テックブログのレビュー／公開

先週に草稿は書き上げていた ものの、レビューが滞っていた。他社のテックブログを勝手に書いて公開するわけにはいかないので慎重にレビューをお願いしていた。私がそういう特性の人間なのか、課題管理システムを長年使い続けてきたからそうなったのか、その両方なのか。私は Unit Bias が大きい方の人間だと思う。自分の中で完了したタスクをクローズせずに放置しておくのが精神的に耐えられない。すぐに対応しない残作業があるなら新しい issue に作った上で古い issue をクローズすることもたまにある。放置するのは嫌なので今日は関係者にどんどん確認してレビューを進めた。

公開して知人にシェアしてみたものの、あまり反応がよくないので大して関心を唆る読みものにはなっていないようだ。扱っている内容が悪いわけではなく、私の構成や文章力が拙いのだと思う。悔しいのでもう1回ぐらい、この記事に関連するテックブログを書いて関心をもってもらうような読みものにしたい。関西人だからかぶせてかぶせて天丼にしていく。

• フロントエンドの技術選定

2時に寝て7時に起きた。生活リズムがやや乱れ気味。メンバーの1on1以外はスポット的に時間が空いていてテックブログを書いてた。

フロントエンドの技術選定のテックブログ

顧問のはらさんに勉強会をお願いして、技術選定の観点を教えてもらい、その後 next.js と sveltekit でチュートリアルやって感触を確かめ、最終的には CTO 判断でエイヤで決めた。その過程や調査結果などをそのままテックブログに書いた。お手伝い先のテックブログも hugo で動いている。私にとっては慣れた環境なので環境構築やプレビュー確認などはすぐにできた。テーマの違いによるテーブルやスタイルの定義などを他の記事を参考にしながら調整するのに手間取ったぐらい。半日ぐらいがっつり時間をとって草稿を書き上げた。これからレビューしてもらって問題なければ公開することになる。私の名前で普通に書いたけど、それが OK なら事例紹介に近いものにもなる。いつも半年働いてから、私が自分で納得できる品質を提供できていれば事例紹介をお願いしている。いまじゃなくてももう3ヶ月経ってからでもいいかもしれない。

私は会社のテックブログを書くのが嫌じゃない。私ぐらいになると、あちこちの会社でテックブログを書いてきたからお手伝いした会社は記事を1つぐらい書いて記念を残したいとまで考えるようになってきた。昔、ある会社でお手伝いしたときに調査した技術情報を社内 wiki にまとめただけで、長文をちゃんと書ける人は少ないと高い評価を得たことがあった。テックブログを書く開発者が少ないことを考慮するとさもありなんと言えるかもしれない。

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

煩雑な検証

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

会社のテックブログ談義

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

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

…

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

…

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

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

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

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

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

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

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

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

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

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