0時に寝て6時に起きた。冷蔵庫に飲みものなくて不安。

docker の swarm mode

昨日から docker の swarm mode について調べていた。

オンプレにコンテナのアプリケーションをデプロイするにあたり、軽量のコンテナオーケストレーションツールはないかと調べ始めた。Kubernetes vs Docker Swarm vs Nomad - the orchestrator wars continue? を記事を読むと、軽量のオーケストレーションツールと言えるのは swarm mode か Nomad ぐらいしかない。docker に付属しているならまずはそれを調べるべきだろうと調査した。そして swarm mode の採用は見送った。現時点でこの機能が廃止されるというアナウンスはないが、あまり保守されておらず、docker 社も積極的に推進していない。近い将来、機能が廃止される可能性が高いと私は判断した。

docker のドキュメントをみながら3台の ec2 インスタンスでクラスターを構築してみて簡単であることは間違いない。コマンド2つで swarm クラスターを構築できる。一通り触ってみて数台のマシンを管理する軽量のコンテナオーケストレーションツールとしては十分だと私は思うけれど、残念ながらこのツールが求められる業務やビジネスは少ないのだろうと思う。みんな k8s に持ってかれたという感じかな。調べていて読んだ記事など。

• Docker Swarm Rocks
• Six Tips For Running Swarm Cluster in Production
• Docker swarm in production - Anyone using it?

hannali dao 雑談

Hannali DAO #02 に参加した。

最初は dao とは何かをみんなで雑談してた。私はお仕事しながら軽く聞いているつもりだったのが、議論に口出しして熱中してた。技術的に私が理解できないことが出てくると、私の認識が誤っていたり新しい気付きがあったりする可能性があるので、ついつい詳細を聞いてみたくなる。hannali dao でトークンをばら撒く戦略をみんなで考えていて dao の宣伝をしたら貢献の1つとみなしてトークンをもらえる。私は twitter でいくつか hannali dao のツィートをしていて、1ツィートが 300 PROG とかで、合計で 1250 PROG のトークンをもらった。PROG というのは hannali dao でのみ使えるトークンね。

その後、ウォレットに名前を付けられる ENS (Ethereum Name Service) というサービスがあるのを教えてもらった。ちょうどいくらか ethereum をもってたので metamask に送金して、metamask で ens の登録 (購入) をやってみた。初めて ethereum を使ってサービスの支払いをやってみた。これで私も web3 を完全に理解したよ。ens で名前を登録 (購入) するのに $22.58 、ドメイン名みたいなものでサブドメインも登録できる。サブドメインを付けるのに $2.96 かかり、その ens を metamask に紐付けるのに $7.49 がかかった。metamask に紐付けると https://etherscan.io/ などで検索したときにウォレットのアドレスではなく、ens で購入した名前が表示されるようになる。トランザクションの履歴に名前が付いてそれが誰なのかが他人にもわかってしまうことがどういった影響を及ぼすのか、プライバシー云々の他に私はまだわかっていない。web3 なので購入した名前は一般公開されているものだけど、その名前は知り合いにしかまだ教えていない。暗号資産のウォレットに名前を付けることの意味や体験などをこれから経験してみる。

0時に寝て6時に起きた。2時と3時ぐらいに起きたけど、まぁまぁ眠れた。

go の interface の考え方

メンバーと設計の議論をしていて interface の考え方の概念を誤解しているように感じたので Go Code Review Comments の interfaces で書いてあることの意図や背景などを解説した。メンバー全員を集めて30分ほどで説明した。既存のコードは過剰に interface を設計していて、特定のメソッドを呼び出すラッパー関数を設けて、そのシグネチャに interface を受け取って構造体のメソッドを呼び出すコードを書いている。こんな感じのコード。

type myBehavior interface {
  doSome(data string) error
}

type myObject struct {
  myBehavior
}

func (o *myObject) doSome(data string) {
  ...
}

func handleSome(o myBehavior, data string) error
	return o.doSome(data)
}

handleSome のようなラッパー関数は不要だし、myObject の構造体に interface を埋め込む必要はないし、Go Code Review Comments では構造体を定義しているところで interface を提供しない方が保守コストが下がってよいよと提案している。これは java のような nominal subtyping と go の structural subtyping の違いで go らしい interface は構造体の提供側ではなく、呼び出し側で勝手に定義して任意の振る舞いを強制できるといった内容を java と go のコードを比較しながら説明した。そして、この話しが重要になるのはサードパーティのライブラリを利用するときに interface が変わると、それを使っている開発者に大きな影響を与えるので interface を提供するなら慎重に練ったものを公開しないといけないという java 開発から得られた知見などが影響しているのではないかという私見も話した。さらに自分たちが管理しているコードなら interface が変わろうが struct のメソッドが変わろうが、すべて自分たちが変更できる権限をもっているから設計時に厳密に interface やメソッドの振る舞いを詰めきれなかったとしても、後から必要ならいつでもいくらでも変えればいいだけと一緒に話した。開発のバランス感覚は経験からでないと身に付かないものだと思う。

23時ぐらいに寝て2回ぐらい起きて7時に起きた。やっぱり家だとうまく眠れない。

mermaid の er 図

メンバーが mermaid の Entity Relationship Diagrams でデータモデルの図を書いてくれてレビューしてた。見た目もすっきりしていて、テキストも書きやすい方だと思うので印象はよかった。gitlab でもリポジトリや wiki で mermaid で書いた図を表示できた。

定例会議の進め方

マネージャーっぽいお仕事の1つとして定例会議を週に1回行う。スクラムにあるデイリースクラムのような、毎日メンバー全員を集める会議するのが私は好みではない。そんなことしなくても定例会議が週1で 1on1 が週1回ならば5日のうち2回は話すし、あと個別の打ち合わせも1-2回やれば十分に話す機会を得られると考えている。定例会議の進め方というドキュメントを一通り書いてみた。私が忘れたときに見返したり、実際にやってみてよかったこと・わるかったことを振り返りながら改善するための、基準として設けた。基準があるから改善できる。最初の1-2ヶ月ぐらいはうまく成果がでなくて悩むことも想定しつつ、過去に書いたドキュメントがそういうときの拠り所になる場合もある。

5時過ぎに寝て10時に起きた。出張で生活のリズムが狂ったまま。

2-1. メンタリングで相手の思考をリファクタリング

エンジニアリング組織論への招待 のメンタリングの技術の章を読み直すことにした。3年前ぐらいに読んだのであまり覚えてない。私は管理職ではなかったし、若い人に口であれこれ言うのもハラスメントになる懸念から私の働き方をみて役に立つところを盗んでもらえればよいと考えていた。これまでメンタリングには関心がなかった。しかし、いまマネージャーとしての役割で臨む以上は最低限の基礎は抑えた上で取り組む必要があると考え方を改めた。今日は「2-1. メンタリングで相手の思考をリファクタリング」を読んだ。節を簡潔に要約してみる。

メンタリングとは、対話を通じて、思考の幅を広げ、その人の歪んだ認知を補正し、次の行動を促し、成長させる手法である。スキルなので誰でも習得できる。自ら問題を発見し解決することができる 自立型人材 を作るために、信頼関係の上に正のフィードバックループから 自己効力感 (self-efficiency) を与えられるように働きかける。次の条件を満たさないとメンターの言葉でメンティの行動を自ら変えるようにはならない。

• 謙虚: お互いに弱さをみせられる
• 経緯: お互いに敬意をもっている
• 信頼: お互いにメンティ (自身) の成長期待をもっている

自らいままでわからなかったことを理解した状況を 自己説得 と呼ぶ。他人が質問で促し、体験を伴い、行動の変化が発生しやすい。メンティが自己説得できる状態になるようメンターは対話で気付きを与えないといけない。悩むと考えるは違う。悩んでいるときは思考がぐるぐると巡り、もやもやした状態。非常に苦しい上に生産的でもない。一方で考えているときはメモ帳やホワイトボードなどに課題を書き出し、分解したり、抽象化したり、具体化したり、、、何かしら行動をとっている状態。次にとるべき行動がはっきりしていれば悩むことはない。メンティが行動できているかどうかを観察し、悩んでいるようならその背景を聞き出して、気付きを与えて考えている状態へ変えていく必要がある。

ストレッチ

今日の開脚幅は開始前154cmで、ストレッチ後159cmだった。東京出張であちこちガタがきていて全身に張りがあったように思う。生活や睡眠が不規則になったことによる疲労もそのままストレッチの窮屈さにつながっているように感じた。毎週ストレッチの機会があって本当に助かっている。ストレッチをした後は体が軽くなって疲労を軽減できているように思う。これまでたまにマッサージへ行って対応していたのが、毎週チェックして手入れできていることの価値がこういうときによくわかるようになってきた。

24時に BOOK AND BED TOKYO にチェックインして雑多なことして25時過ぎには寝て8時過ぎに起きてチェックアウトした。それから新幹線に乗って神戸まで戻ってきた。東京・品川から新神戸間は、往路は EX早特21ワイド だと12,630円で、復路は自由席で14,420円だった。私の中で時間の制約はストレスやエネルギーを使う。帰りは時間に縛られたくないという思いで新幹線の駅に着いてから自由席を買うようにしている。一方で2千円近い差額も大きいので次回以降は帰りの新幹線もEX早特21ワイドで取ることにした。

フロントエンドの調査

昼過ぎに家に戻ってきて洗濯や片付けしたら疲れてまた寝てた。晩ご飯食べて21時ぐらいからオフィスで作業してた。猫みたいな生活。オフィスからお手伝い先のネットワーク接続の設定をやったりしながらフロントエンドのコードを読んでみた。これは作り直した方がよいだろうと私の中で決意して、どういった技術で作り直すかの技術選定のための調査を開始した。既存のフロントエンド開発の背景や経緯を知らないのでまだ確定ではない。提案の準備のために調査をしておく。

ここ最近 svelte の人気があるのをみかける。1年ほど前に三ノ宮.devで教えてもらってチュートリアルをやってみて、そのときは特にどうとも思わなくて、こんなやり方もあるんやな程度にみていた。その後 vue.js (nuxtjs) での開発を半年間ほど経験して、思いの外、私にとって vue.js がよいものにはみえなかった。react よりも簡単と聞いていたけど、私にとってはあまりそうは思えなかった。vue.js は vue.js なりの難しさ (学習コスト) があるように感じられた。管理画面のような小規模な用途に react や vue.js のようなリッチなライブラリ・フレームワークを使わなくてよい方法があるかを考えたときに svelte を思い出した。svelte の実際のアプリケーションのサンプルコードとして次のコードを読んでいた。

• svelte realworld example

vue.js の single-file components は svelte の前身である ractive.js のコンポーネント の概念に影響を受けているという。従って、svelte のコンポーネント開発は vue.js と考え方が近いものの、dom 操作は svelte のコンパイル時にコード生成するので仮想 dom は使わない。これがパフォーマンス上の大きなメリットと言われている。react や vue.js よりもずっと軽量なコンパイラ・フレームワークと言える。次のページに複数のフロントエンドの技術の流行をまとめている。svelte はこの2年ぐらいで人気が急上昇していることがわかる。

• Front-end frameworks popularity (React, Vue, Angular and Svelte)

また react と vue.js の現状もちゃんと把握しようと調べていて次の記事がおもしろかった。

• [Twitter] React ユーザーが Vue を選ばない理由

vue.js は vue3 で react になろうとしていて、その過程の過渡期には様々な問題を抱えているように私からはみえた。

• vue2 と vue3 は互換性がない
• vue3 移行へのエコシステムの本気度がみえない
• vue2 の開発者が本当に vue3 を求めているのか懐疑的
• シェアだけみたら vue.js よりも react の方が高い

0時に寝て7時に起きた。疲れているせいか、よく眠れたと思う。わりと出張でよく眠れているので普段眠れていなかったのは体力が余っているからではないかという気もしてきた。

課題の洗い出し

一昨日の続きでわかっていることや進捗のあったものを確認しながら、追加で課題を作って整理していく。まだまだ課題が足りないのでどんどん作っていかないといけない。それと同時に go のソースコードを読みながら設計や改善の要点を私の中で把握していく。java に慣れたプログラマーが書いた go のコードなので java の考え方の影響が強いようにみえた。私がいくつかアドバイスする余地はあるようにみえた。google でコードレビュー時によくある指摘事項をまとめた有名な wiki がある。メンバーに聞いたらちゃんと読んだことがないということだったので2-3回かけてみんなで読んで学ぶ機会にする。私自身、数年前に読んで忘れていていることも多いだろうから学び直し。テストのページは2019年9月に追加されている。たぶん読んだことない。

• https://github.com/golang/go/wiki/CodeReviewComments
• https://github.com/golang/go/wiki/TestComments

課題管理勉強会

1時間分ぐらいの資料を用意したつもりが35分で終わってしまった。勉強会の雰囲気が固かったのか、慣れない場所での説明だったのか、マスクした状態で長々と話すことも過去に一度もやったことなくて話しにくかった。初めての試みであまりうまくいかなかったが、初めてやることでうまくいかないのは私にとって当たり前のことなので次の勉強会に向けて改善していきたい。どのぐらい伝わったのかわからないけれど、もっと参加者を巻き込んだ活気のある勉強会になるように努めていきたい。

リアル飲み会

19時から3年ぶりに友だちとリアル飲み会。せっかく東京に行く機会だからと5日のうち3日飲んでいたので後半になるほどバテていった。これは加齢による体力低下もあるのだろう。娯楽はどういうものか？という定義や在り方の議論が盛り上がって、私は暇つぶしの時間であって何もしないのでぼーっとしているのも退屈だからその時間を埋めるもの、楽しければいいけど楽しくなくても、どうせ何もしない時間なのであまり気にしないといった考え方をしている。私の友だちは楽しむために娯楽に集中するとか、その時間を無駄にしないようになるべく楽しめる娯楽を選択するとか、24時間のうち、1時間足りとも無駄な時間にはしないぞという姿勢がみえて、私からみたらそんな生活はしんどくないですか？みたいな気持ちになった。おそらく時間を無駄にしたことがストレスになるからそういう姿勢になるのだろうと推測する。娯楽をしながらだらだら時間を過ごすということはないらしい。オンライン飲み会はちょくちょくしていたものの、3年ぶりにオフ会をしたので飲食代をご馳走になった。感謝。前も会社を作った後の飲み会でご馳走になっていて、なかなか私からお返しできていない。それを覚えておくためにもここに書いておく。

本棚に埋もれて眠る

この日は 新宿 BOOK AND BED TOKYO に泊まった。前に浅草の同施設に泊まったことはあったけれど新宿は初めて。大雑把に言えば本屋とカプセルホテルが合体したような施設になる。この非日常の雰囲気が好きなので機会があれば泊まるようにしている。宿泊費は6,000円とカプセルホテルより高くビジネスホテルより安いという価格帯。ここに来て本を読んだり泊まったりしている人はコワーキングスペースもしくはコミュニティ的なスペースが好きで本も好きな人たちだと思う。勉強会に行く感覚と似ている。そういう自分と似た人たちが集まる空間そのものが価値観の共有だったり安心感につながっていて私はそういう空気も楽しんでいたりする。とはいえ、バテバテで疲れていたので少しだけ本を読んでわりとすぐに寝た。

19時ぐらいに一口寝ようと思って寝たら0時過ぎまで寝てしまって、それから4時過ぎまで作業して寝て7時に起きた。出張の慣れない環境で生活が不規則になってきた。

ドラム式洗濯機

泊まっているホテルの部屋に備え付けられていたので洗濯・乾燥した。館内設備として有償のコインランドリーがあるのは普通だと思うけど、部屋に洗濯機があって無料で使えるのは長期出張客を対象とした差別化の1つだと思う。乾燥もしてくれるならうちの洗濯機もドラム式に変えようかなと使いながら思った。

もくもく会

出張もくもく会 を開催した。8人が参加してくれた。知り合いが5人でそうじゃない人が3人も来てくれた。初めて行った場所のコワーキングスペースの会議室だから設備をわかっていなかった。8人で作業するにはちょっと窮屈な部屋と外の工事と換気扇がややうるさかった。もくもく会をやる上で我慢できないほどではないが、あまり参加者の満足度は高くなかったかもしれない。私は3つの作業を目標として作業してた。

• 日記を書く
• 課題管理勉強会の資料作り
• go 言語の勉強

上の2つはできたが、それで疲れて go 言語の勉強はしなかった。17時から成果発表。なんだかんだで全員発表してくれたと思う。物理的にモニターやプロジェクターに接続しなくても zoom に参加してマイク／スピーカーをオフにして画面共有すればよいと教えてもらった。これはテレビ会議が当たり前になったいまのプラクティスとしてよいなと思えた。

後の飲み会

もくもく会が終わってから5人で飲みにいった。参加者が知り合いを1人呼んで6人になった。2時間半制で18時から始めて20時半で終わった。眠かったのと翌日も飲みに行く予定があったので私はそこで帰ってホテルで2時間ほど寝てた。昔は当たり前だった勉強会後の飲み会というのも久しぶりの感覚で楽しかった。

知り合いだけならうちの会社の経費で落とそうかと考えていたものの、その考えがまとまらないうちに割り勘になってしまって、自身の優柔不断さを悔いた。会社の経費を使う理由は売上につながるかどうかというのが原則になる。知人であれば、日常的にお世話になっているからという大義名分が私の中で成り立つものの、そうじゃない状況になってしまったことで私の中で論理的に説明がつかなくなって接待として経費で落とすという決断ができなかった。個人ではなく経営者として判断するときは理論武装してないと固まってしまうことに気付いた。

1時に寝て7時に起きた。ホテルのビッフェ形式の朝ご飯は2回目のなのでうまくプレートに盛り付けて段取りよく配膳できた。昨日より改善できた。

課題の意思決定と割り当て

プロジェクトの初期なのでとにかく段取りを早め早めに決めてタスクを洗い出し、メンバーが目標に向かって作業しやすい状況をマネージャーとして作り出さないといけない。昨日からプロジェクトのリポジトリ構成を変更しようというイシューを作ってメンバーと議論していた。当初は私がちゃちゃっと作業して移行しようと考えていたが、私の移行イメージを書き出していたらメンバーからいくつか背景や要望が出てきて、メンバー集めて打ち合わせして合意をとって決断することにした。私が入ってからプロジェクトでの初の意思決定かもしれない。

既存のソースを読んだらリポジトリ統合は少し工数がかかるとわかって、私がやるよりもメンバーの方がいいだろうと意思決定だけ私が判断して、実作業はメンバーに割り当てた。初めてのマネージャーっぽいお仕事をできたとちょっと自己満足。その議論の過程で monorepo vs polyrepo という比較記事を読んでみた。monorepo から polyrepo に切り出すのは容易だが、polyrepo から monorepo に統合するのは大変ということが書いてあって、まさにプロジェクトの状況と合致してメンバー間で認識合わせした。いま (過剰な) polyrepo で管理されているのを monorepo に統合しようという決断をした。これをやるのにコミット履歴を維持するのはコストがかかるのでソースファイルをコピーして新規ソースとして移行してよいという判断も下した。こういう意思決定は即断即決でやりたい。

monorepo の対義語として polyrepo という言葉があるのか。勘と経験でリポジトリは複数に分割するので私がやってきたのは polyrepo ではあるのだけど、ちゃんと考えたことはなかったのでアーキテクチャとして議論する余地があるんやろな。 https://t.co/7LQY4cMteF

— Tetsuya Morimoto (@t2y) November 1, 2022

1on1

マネージャーとして1on1を行う。プロジェクト初期は毎週やって、その後はメンバーの要望を聞きながら隔週でもよいと考えている。1on1 の目的ややり方は様々だが、私が提供できるのは次の3つに含まれることかなと思う。

• モチベーションアップ
• 業務・組織課題の改善
• 能力開発／キャリア支援

初日から長時間の会議と懇親会などでチームのメンバーと話す機会が多かったので 1on1 もみんな気さくに話してくれてよかった。私はなるべく話さずに聞くことに専念しないといけない。私は圧倒的に自分の思ったことをがんがん話してしまう方なので他人の話を聞く姿勢を身につけるよい機会になると思う。今回は準備不足で雑談がメインではあったものの、1on1 の本なども読みながら勉強していこうと思う。

0時に寝て6時過ぎに起きた。朝からシャワー浴びてホテルのビッフェ形式の朝ご飯食べてた。初めてのオペレーションだと段取りわからなくて朝ご飯さえうまく配膳できなかった。経験のないことは全然できない。

課題の洗い出し

お手伝い先のワークフローや段取りを学ぶ。毎週火曜日がプロジェクトの定例会議。火曜日の終わりに週報を書く。メールで週報を提出するという、いまどきの会社からみると古い会社の慣習にみえる。郷に入れば郷に従えということで私も同様に行う。課題管理で日々の活動をひたすら書いているので週報はいつでもすぐ書けるので私は全く苦にならない。

プロジェクトのリポジトリ構成の変更や課題の洗い出しなどをやっていた。イテレーションは週1でマイルストーンを4週間(月1)で設定して、その区切りでふりかえりなども実施していきたいと思う。コミュニケーションコストが高いことから、私は開発方法論としてスクラムを採用するつもりはない。あくまで自分がやってきた経験による課題管理 + イテレーション開発で製品開発のワークフローを構築したい。お手伝い先ではチームで課題を共有して開発に取り組むといったことはこれまでやってきていないものの、課題管理システムを使って開発者間でやり取りするのは普通にやっていたそうなのでイシューのコメントへの返信がめちゃくちゃ速い。イシュー上で議論していて私がこうしましょうとコメントを書いたら最も速いメンバーは5秒後にリアクションがつくぐらいの速さ。他のメンバーも数十分以内には返信がつくので課題管理システムを使うところのなにかを教える必要はない。課題管理が身に着くのに半年から1年間かかるというのは、他人のアクティビティを監視するという日々の運用 (行動) の変化に半年ぐらいかかると私は想定しているが、このチームはもっと早く課題管理の考え方に適応しそうな気がする。イシューの他人のコメントに5秒でリアクションできる開発者はそうそういない。

私がまだまだプロジェクトの理解が浅いので1-2週間はそのキャッチアップをして、メンバーが遊ばないように課題をどんどん作って優先度付けしてメンバーが担当できるようにしていきたい。

1時半に寝て3時半に起きて4時半まで仮眠して準備して5時41分に家を出た。出張も3年振りで寝過ごすのが怖くてうまく眠れなかった。

東京出張

3週間以上前に新幹線を予約すると EX早特21ワイド という割引サービスがあって 東京・品川から新神戸だと15,380円が12,630円と2,750円と18%もの割引でお得。6時55分の新幹線の予約をしていた。スマート ex の予約のやり方を忘れてたり、地下鉄のホームを間違えたりしていて朝ちょっと早く出掛けてちょうどよかった。段取りが読めないことは30分以上早く行動するのが安心できてよい。

自己紹介大会

お手伝い先のオフィスに到着し、一息ついてから自己紹介大会になった。1つの会議室に20人ぐらい、リモートからも10人ぐらい参加されていて全社員だったのかな？自己紹介大会をしていただいた。チーム内でのみ行うと考えていたのでたくさん参加者がいて緊張した。30人程度というのはそういうことができるぎりぎりの人数かもしれない。暖かい雰囲気の会社だなと思った。お土産のお菓子 が16個入りで数が足りないことにこのとき気付いた。チームと関係者のみだったら16個もあれば十分と安易な考えだったと気付いた。失敗。

プロジェクトの情報共有

午後から数時間をとってチームメンバーとプロジェクトの情報共有を行った。いまみえてて伺っている内容だけなら私の経験から全体の技術体系ややりたいことも見通すことができて、全部自分1人で開発しても提示された期間内にはできるように思えた。しかし、今回はマネージャーというポジションで若い開発者に実務を担当してもらうことになる。自分が手を動かすのではなく他人にやってもらう新しいキャリアへの挑戦になる。私がビジネスとして取り組みたい課題管理の探求にも力を入れたい。今回のお仕事は千載一遇のチャンスなので集中して取り組んでいきたい。

懇親会

初日は早々に業務を終えて関係者とチームで懇親会を3時間ぐらい行った。昔働いていた会社の同僚・先輩方がいて、やや平均年齢の高いメンバーだったので昔話や同世代の価値観のお話ができて楽しかった。40代以上の人が集まるとすぐ健康の話になって若い人がいると申し訳ない。運動しないと50歳ぐらいになると動けなくなるぞと念を押されたので注意しようと思った。初日は自己紹介、会議、懇親会とたくさんチームのメンバーと話すことができたので初日から随分打ち解けて話せるようになった。感謝。

2時に寝て7時に起きた。タスクが全然消化できなくてしんどい。ただ燃え尽き症候群は落ち着いて次に向けての気力が出てきた。

神戸お土産探し

3年ぶりに出張が増えそうなので神戸のお土産探しも始めようと思う。今回は リッチフィールド さんのバウムクーヘンと丹波みるく黒豆萬をもっていく。オンラインで注文すると取り寄せに1週間かかる。ちょうど発注するときのタイミングが悪くて間に合わない。店頭受け取りだとそのリードタイムが4日になる。明石駅に店舗があったので電車に乗って朝9時から受け取りに行ってきた。電車の待ち時間を含めて往復で約1時間で受け取れる。もっていくお土産は自分がおいしいと思うものをもっていきたいという考えもあって単品でも購入して食べてみた。バウムクーヘンはしっとりした食感で普通においしい。プレーンよりも黒糖の方が風味の自己主張が強いという特徴があって私は好きかな。丹波みるく黒豆萬は濃厚なミルク餡で丁寧で上品なお菓子という印象を受けた。甘いのが苦手な人はややしつこいかもしれないけど、普通においしいと思う。黒豆がちょこんとのっているのが他の乳菓子との差別化かな。(なんの認定にもならないが) 私の審査は軽く通るお土産だとわかった。

開発者として効果的に伝える方法

関心のあるタイトルをタイムラインでみかけたので読んでみた。

• How to communicate effectively as a developer

期待したほど私にとって参考になることが書いてあったわけではないけれど、読んでみて参考になることはいくつかあった。著者は「効果的に伝えることを共感的に文章の解像度を高めること」と定義している。私の周りでもエンジニアリングの文脈で解像度の高低というキーワードをよく聞く。一方で共感というキーワードを私は意識していなかったのでこれは素直に参考になった。読み手を想像してその人が共感できるように書くことの重要性に言及している。empathically=「共感して、親身になって」という意味だから日本語らしく訳すと相手の気持ちに寄り添って書くとか、相手のために親身になって書くとか、それ自体はよいことのように思える。高解像度、且つ共感性の高い文章を書くことは労力を要するものの、次のことから win-win-win だと著者は表現している。

• 読者はより深く理解し、レベルアップする
• 組織は知識の共有が進み生産性が向上する
• 自分の考えを伝えるのが上手になり、キャリアアップにつながる

いまとなっては後の祭りではあるが、私がいまの3倍速く巧く文章を書ければたしかにもっとキャリアップできていた気がする。書こうと思いながら筆が進まずに断念した文章はいくつもある。最後の結びの言葉も気に入った。

自分が相手の立場なら喜んで読んでくれるような文章を書きましょう。

課題管理の勉強会の資料作り

来週の出張で使うかもしれない課題管理の勉強会向けの資料の叩き台を作った。過去の資料を見返しながらスライドを作り直していた。過去に資料を作ったときは納得して作ったものを、いま見返すと誤解している箇所があったり、あまり重要とは思えなかったり、当たり前の話しだけど、スライドやドキュメントも時間が経って見返すと粗が目立つようになる。こういうとき私は自分を信じないと再確認できて慢心せずにすむ。常に課題管理システムに日々の学んだこと、考えたことを書き続け、チケットの構成を整理し直したり、チケットとチケットの関連を結びつけたりしているうちに過ちや無知に気付くきっかけになる。この暗黙知をいつか形式知として言語化できるようになりたい。