22時から寝始めて何度か起きて7時に起きた。久しぶりにどっしりくるような夢をみたけれど、もう内容を覚えていない。

ふりかえりを兼ねたチーム勉強会

新しい開発に着手して初めてのチーム勉強会を行った。前の開発とチーム勉強会の運用を大きく変更した。ざっくり次が要項になる。

• 前開発の postmortem 運用がうまくいかなかったので代替としてやってみる
• 開発システム全体の機能が増えてきて、メンバーそれぞれがやっていることもバラバラになりつつある
  • 普段やっていることを他メンバーへ情報共有する機会とする
  • そのときのマイルストーンでやっていることをふりかえりする機会とする
• 開発システムについて知りたいところや設計の議論などをしてもよい
  • メンバーが全員揃っていれば、どんな質問をしても誰かが知っているはず
• そのマイルストーンでやったことを基本として他メンバーへ共有する
  • 内容は基本的になんでもよい、あまり準備せずに話せる内容でよい
    • 特定の issue の内容でも、マージリクエストの解説でも、機能や振る舞いの考察など
  • 知識やノウハウを他メンバーに共用する上で wiki やブログの記事などにしてもよい
    • 書くところがなかったらテックブログに書けばよい
• 勉強会のために調査する時間が必要であれば、その調査時間も仕事の一環とする
  • 勉強会の準備も考慮して開発のスケジュールを各自で調整する
  • 業務で実装したことや調査したことを共有する機会にもなる

まだ合流前だけど、メンバーが新規に1人増える。2週間に1回の定例のみだと、新しいメンバーが既存のメンバーに追いつくための情報が足りないだろうと思って質問しやすい機会を設けようと考えていた。雑談時間とか、設計会議とか、そういう呼び方をしてもよいのだけど、私にとって違和感なく一番しっくりきて柔軟性も高いのが「チーム勉強会」になる。ふりかえりと情報共有と学びの場の3つを兼ね、チームビルディングにも応用しようという、まさに天才の所業ではないかw まだ始めたばかりだから言うだけ言っておく。また開発が終わったときに良し悪しのふりかえりはする。

今日のところは最初だったので前マイルストーンでやった issue をメンバーそれぞれ1つずつ内容を説明して共有した。私も mongodb の初期化ツールのマージリクエストが出来たばかりだったのでその背景や意図、工夫したところなどを紹介した。他のメンバーも背景やソースコードを紹介しながらみんなでわいわいできた。第1回目にしては活気があって情報共有という目的も果たせたし、よい感じの取り組みにみえた。このままうまく運用にのせていく。

22時頃から寝始めて何度か起きて6時に起きた。早寝早起き。

会計士事務所への訪問

相続税の申告手続きを未だにやっている。

父が失くなったのが 昨年の12月26日 になる。相続税は死亡を知った日から10ヶ月以内と期限が決められている。それを過ぎると算税や延滞税などのペナルティが科せられる。うちの期限は10月26日になる。1-3月ぐらい葬儀やらお仕事やらで忙しかったものの、4月ぐらいから相続の手続きに着手した。5月29日に親族の相続関連の書類を取りまとめて弁護士さんへ送付した。それから銀行口座の解約やら司法書士さんやら税理士さんの作業やらなんやらあって、いまもまだ会計士さんに申告の書類を作ってもらっているところ。その過程でいくつか質疑応答があってそれを調査したりしている。

その会計士さんの事務所が近所にあるのでお昼に訪問して挨拶してきた。申告に必要な書類の提出をしつつ軽く打ち合わせをした。税務署は20年遡って口座のお金を動きを調べるらしい。話しているときに死亡保険金とかないですか？と聞かれて、母が受けとったと話していたなと思い出して、それも父の遺産として扱う必要がありますと言われて、確かにそうだと思って申告漏れしていることに気付いた。これで死亡保険金の書類が必要になってまた取り寄せに時間がかかる。こんな感じに五月雨式に遅れていくので10ヶ月ぎりぎりになりそうな雰囲気。来週中に申告が終わる嬉しいなといったところ。

mongodb の初期化ツール

ちょっと前から少しずつ mongodb の初期化ツールを作っている。コレクションの作成ならびにインデックスの追加を、さらに初期データの投入も制御したい。mongodb のバージョンが 6.0.x のときは作成済みのコレクションに対して同じ設定で作成しようとすると、既に作成済みというエラーが発生していた。それが 7.0.x になってエラーにならないようになっていることに気付いた。調べてみると、次の issue で同じ設定なら作成の結果に関係なく冪等であるのでエラーとして扱わなくてよいという考え方になる。

• Make create command idempotent on mongod

これは初期化ツールを作っている私にとっては朗報で、同じコレクションに対して複数の操作をしても変更した設定だけが有効になるといった振る舞いをする。こういう細かい所もバージョンアップをしながら改善していくことが伺えて学びになった。

22時ぐらいから寝始めて何度か起きて6時に起きた。早く寝たから早く起きた。

selinux の微妙な振る舞い

今日は火曜日なのでチームの定例会議をやって、ドキュメントを書いて、その後はインフラの細かい作業をわちゃわちゃやって、ドキュメントを書いてとわちゃわちゃやってた。

先週、最新の almalinux 8 をインストールして、その後、lvm の論理ボリュームの結合 とか、rootless コンテナ の設定とか、テスト環境を構築していた。gitlab ci/cd から ssh で公開鍵認証を使ってデプロイしている。作り直したこのテスト環境に対してその公開鍵認証がうまく動かない現象に遭遇した。よくある設定や権限のトラブルではなく、デバッグ用の sshd を起動すると公開鍵認証できた。なにかしら systemd 経由で起動する sshd の設定ミスなんじゃないかと、2-3時間デバッグしてもわからなくて社内の有識者に尋ねてみた。

$ sudo /usr/sbin/sshd -d -p 2222

selinux を無効にしてみたら？というアドバイスをいただいて、試しに enforced から disabled にしたら動いたので selinux のなにかしらの設定を変えてしまったのかな？とそのときは思っていた。しかし、別の開発者からデフォルト設定で enforced でも動くはずという情報をもらって、もう一度 disabled から enforced に戻して再起動したら普通に動いて、その前の公開鍵認証の失敗を再現できなくなった。私にはこの先のデバッグはまったくわからない。お手伝い先のシニアエンジニアの方にみてもらって次のようなことを教えてもらった。

SElinuxが怪しいなと思ったら、/var/log/audit/audit.log とかausearch -m avcコマンドを確認。
authorized_keysのアクセスが拒否されているので確かにSELinuxの問題があったことがわかります。
type=AVC msg=audit(1696315292.258:1446): avc: denied { read } for pid=446534 comm=“sshd” name=“authorized_keys” dev=“dm-0” ino=201836096 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=file permissive=0
現在、authorized_keysのコンテキストは期待通りunconfined_u:object_r:ssh_home_t:s0となっているけど、問題が起きていたときは、unconfined_u:object_r:default_t:s0 だったことがわかります。
詳しい経緯はわからないけど、.ssh/authorized_keysを作成した時点でopenssh用のselinuxポリシーが適用されていなかったと考えられます。
その後なにかのイベント(再起動?)でrestorecon 相当が行われて、コンテキストがssh_home_tに変更され問題は解消した。
なんだかよくわかないけど、OSのマイナーバージョンアップで微妙にセキュリティコンテキストが変更されてrestoreconすると解決する、ってのは時々起きてますね。
たぶんopensshインストール前にrsyncしたのでコンテキストがdefault_tになってたんじゃないかと。なかなかの罠ですね。

おそらく lvm の論理ボリュームのバックアップ／リストアに rsync -a を使った (本当は cp -aの方がよい) ことによる問題ではないかということ。私が報告した状況と selinux のログからすぐ助言できるのが素晴らしいと思う。まだまだ私のインフラエンジニアとしての未熟さを実感した瞬間でもあった。一昔前は selinux は disabled にするものという常識だったが、最近は初期設定で動くようになっているのでなるべく selinux は有効にして運用するものという意識に変わってきているらしい。

1時に寝て何度か起きて5時に起きた。それからだらだらして寝てまた7時に起きた。

テスト環境の再整備と rootless コンテナ

インフラの式年遷宮のようなことをしていて、テスト環境をリファクタリングして再整備していた。これまで root でコンテナを実行していたが、最近は rootless コンテナがセキュリティ強化の観点から望ましいということで次のドキュメントをみながら設定した。

• Linux post-installation steps for Docker Engine

設定はとくに難しくないが、dockerd や containerd の起動を systemd のユーザーインスタンスに依存することになる。systemd のユーザーインスタンスは基本的にユーザーがログインしたときに生成されるものなので OS が再起動したときなどに困る。OS 再起動時にも systemd のユーザーインスタンスを生成するには linger という仕組みを有効にすればよいらしい。systemd –user の扱いと linger のことまで理解していれば、たぶん大丈夫なのかな？これで運用がうまくいくことを祈りたい。

$ sudo loginctl enable-linger ucidm

0時に寝て何度か起きて7時過ぎに起きた。いろいろ作業していたんだけど、お昼からインボイス制度の開始に伴って請求書や会計処理がちょっと変わるのでそのシステムの運用や調べものをしていた。

インボイス制度の開始

10/1にサブスクリプションの請求が届いているものを経費登録しようとしていて税区分が変わってくることに気付いた。適格請求書発行事業者向けの支払いであればこれまで通りだが、そうじゃない場合に経過措置期間用税区分が新設されている。合理的に考えたら経過措置の控除割合80%を選択することで節税になる。ここで会計システムに経費登録する際、適格請求書発行事業者なのかどうかについて、これまでは未確認だったものを請求書 (領収書) から判断する必要が出てくる。いまみたらセブンイレブンのレシートにも登録番号が記載されている。こうやってシステム (仕組み) で世の中を変えていくのは強力だなと思えた。

• インボイス制度(クリエイター向け)
• 経過措置期間用税区分の消費税計算方法

その後、取引先の設定に適格請求書発行事業者の登録番号を設定できることがわかって、明らかにそうだとわかっているものは検索して設定したりしていた。外国企業については 国境を越えた役務の提供に係る消費税の課税関係について に書いてある。例えば、google workspace を使っていると請求書には Google Asia Pacific Pte. LTd. と書いてある。しかし、請求書には登録番号がない。これは 登録国外事業者名簿 をみると、有効であることがわかり、さらに法人番号もみつかる。法人に関しては法人番号と登録番号は基本的に同じなのでそれを登録しておけばよい。

0時に寝て3時、5時ぐらいに起きて7時に起きた。

ストレッチ

先週に比べれば、出張を終えてのんびり過ごしていたのもあってかなりよくなっている気はした。足の張りはどこも目立つほどではなく、左の太もも後ろの筋肉の張りが強かったぐらいで復調している感じはした。腰もそれほど自覚症状はなかったものの、トレーナーさんからみると硬めだったという話しもあり、たしかに部位によってはきついところもちらほらあって、腰はまだまだ復調していないことがわかった。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。暑さも和らいで時間も出来てきたので少し運動してもよいかもしれない。

コワーキングとコミュニティ

2014年11月に発刊された Coworking Magazine の創刊号がある。昨年ぐらいまでは amazon に在庫があって購入できたが、いまみたら在庫がなくなったようだ。2014年に出版して2022年まで在庫が残っていたという雑誌ではあるが、内容はとてもよいものだと私は思う。2014年頃、コワーキングという新しい働き方のスタイルが日本に輸入され、広まっていったときのそのときの雰囲気や価値観を本書から読み取ることができる。多くのコワーカーたちがコメントしていたり、インタビュー記事もあったりして、コワーキングの価値やコミュニティの良さを語っている。こうやって出版という形で残しておくことで、その歴史の過程を学ぶ機会にもなることが本書から伺える。

私はコワーキングのような価値観や働き方を2016年頃から知ることになり、私もコワーキングスペースで作業したりするようになった。しかし、当時はワークスペースとして利用しているだけでそれはコワーキングと呼べるものではなかった。本書を読んでいて、ある人はコワーカーとはコミュニケーションを取る人たち、またはコミュニティに参加する人たちを指すのだと話していた。コミュニティ参加しなければ、コミュニティの恩恵を受けることが難しく、その状態をコワーキングとは呼べないようだ。2022年6月に カフーツさんを訪問 して、いとうさんとコミュニティについて話してみて、私の知っている IT 業界のコミュニティの在り方とコワーキングにおけるコミュニティには通じるところがあって、それ以来、コミュニティを学ぶことや課題管理のヒントになると考えて、いとうさんの主催しているオフライン／オンラインイベントにも参加するようになった。

コワーキングの価値はコミュニティやコラボレーションにある。作業場としてのワークスペースではない。コラボレーションと言うと、企業間の業務提携だったり、新商品企画を共同でやるとか、そういう大きなものをイメージしてしまうが、コワーキングにおけるコラボレーションとはそんな大きな話しではない。ただ一緒に作業しながら、軽く雑談したり、なにかのテーマで話し合ったり、その場に一緒にいることで生まれるコミュニケーション全般を指す。共通の話題や課題に対して一緒に考えたりする行為で構わない。もっと小さいものだと気付けるようになった。

それは私がマイクロ法人を経営して1人で黙々とずっと仕事をしていても、この延長上に新しい価値を築けるような気がしないというのを実感した後だった。リモートワークと相談相手 にも書いたが、会社に勤めていると自然と同僚とコラボレーションしている。マイクロ法人には同僚がいないのでコラボレーションによる気付きや刺激を受けることができない。コワーキングは1人会社やフルリモートワークのような、同僚が身近にいない人たちへコラボレーションの価値を提供しているということを、身に染みてわかるようになった。

IT 業界では Open Source Software の歴史をみると、古くは1950/1960年代の Unix に端を発し、1990年代の Linux の公開、1998年の Netscape 社の Mozilla Firefox のソースコード公開などの大きなエポックメイキングを経て、社会運動としての OSS 文化や OSS コミュニティが発展してきた。その歴史の過程で日本では2010年前後から IT 勉強会という、主に Web 業界の様々なバックボーンをもつプログラマーが技術情報を共有するようになった。OSS の技術はみんなで共有するものという価値観があるが、それはこういった IT 勉強会によって草の根的に広まっていったと思われる。私もそんな IT 勉強会に参加して技術を研鑽してきたプログラマーの1人なのでまさに生き証人でもある。それはまさにコワーキングの人たちが言う、コミュニティのそれとまったく同じである。IT 技術という共通の話題で困っていることを共有したり、不具合を改善したり、新しいプロダクトを開発したりしていた。製造業の人たちには驚かれたが、web 業界はコンテンツを公開して広告費で儲けるビジネスモデルであることから、自社の技術情報やノウハウをすべて公開してしまう。ビジネス上では競合他社であっても、別会社の開発者とも仲良くなって技術情報を共有している。それが業界全体のレベルの底上げをしてきた。いまもその文化は変わっていない。

次にくる流れとして、IT 業界のプログラマーはどんどん独立していくと私は考えている。いまもフリーランスになる人は増えつつあると思う。スキルも経験もない若い人が安易にフリーランスになることはお奨めしないが、20年も働いてきたベテランはどんどんフリーランスになって、組織の枠に収まらない活躍をしていけばよいと思う。マイクロ法人を経営することのハードルも歴史上、もっとも低くなっていると私は思う。私が経営できているのだから普通のプログラマーでも経営できる。しかし、1人で働いていると、私が陥ったような「行き詰まり」を覚えるようになるかもしれない。コワーキングやコミュニティはそれを防ぐきっかけになるのではないか？と思うようになってきた。この「行き詰まり」に名前を付けたい。私が感じたのは次のようなことになる。

• 自身が成長しているように思えない
• 日々の生活で気付きや刺激がなくなる
• 新しいことに挑戦する気概がなくなる
• 自分の状態が自分で判断できない
• 誰に何を相談していいか分からない

もしかしたら会社に勤めているときも同じような状況になっているときもあったかもしれないが、会社に所属していると、仕事はいくらでも上から降ってくるし、仮にぼーっと何もしなくても給料は毎月もらえる。この先どうやって生きていくのか？という、生命としての根源的な問いから目を背けてしまうような錯覚がある。なんの後ろ盾もないマイクロ法人やフリーランスになることでこういった根源的な問いから目を背けられなくなる。私の場合、そのことに2年目で気付けるようになった。今後のビジネスにおいても、直接的ではなく間接的にコミュニティというのはキーワードだと考えている。コミュニティへの理解を深めるためにもコワーキングには今後も注目していきたい。

0時に寝て何度か起きて7時に起きた。最近は寝る前にはてブのアプリで適当に記事を読みながら寝ることが多い。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

• 今後のお手伝いの展望
• fun/done/learn をカスタマイズする話し
• hugo のテンプレートを作る話し
• 課題管理のコンテンツを作っていく話し

ここ1-2週間ぼーっとしていて、忙しくもなく、なにかやっているわけでもないけど、のんびり過ごしている。軽いバーンアウトだと思う。先週末は休みも取った。「hugo のテンプレート作り」のような新規開発を、どこかのもくもく会やイベントに行って、その場で集中してやったらいいんじゃないか？というアドバイスをいただいて、確かにそういうやり方もよいように思えた。今週末は課題管理のコンテンツを考えて、できればブログに書いてみようと思う。

lvm の論理ボリュームの結合

新規に almalinux 8 で仮想マシンを作った。デフォルト設定でインストールしたら / と /home でパーティション分割されていて、これは使い勝手が悪いなと思ってパーティションを結合することにした。

$ df -h
ファイルシス               サイズ  使用  残り 使用% マウント位置
devtmpfs                     1.9G     0  1.9G    0% /dev
tmpfs                        2.0G     0  2.0G    0% /dev/shm
tmpfs                        2.0G  8.6M  2.0G    1% /run
tmpfs                        2.0G     0  2.0G    0% /sys/fs/cgroup
/dev/mapper/almalinux-root    70G  6.5G   64G   10% /
/dev/mapper/almalinux-home   437G  5.0G  432G    2% /home
/dev/vda1                   1014M  221M  794M   22% /boot
tmpfs                        393M   12K  393M    1% /run/user/1000

基本的には次の記事をみてやったらうまくいった。

• How to merge two or more disk partitions on Centos 7

/home をバックアップする

# mkdir /home-bkup
# cp -a /home/ /home-bkup/

emergency モードに入る？

# systemctl emergency

結合したい領域を unmount して、home の論理ボリュームを削除する。

# umount /dev/mapper/almalinux-home
# lvremove /dev/mapper/almalinux-home
Do you really want to remove active logical volume almalinux/home? [y/n]: y
  Logical volume "home" successfully removed.

バックアップからデータを戻す。

# cp -a /home-bkup/ /home/

/etc/fstab から不要なパーティション設定を削除する。

# vi /etc/fstab
...
/dev/mapper/almalinux-home  /home  xfs  defaults  0  0  # <- この行を削除
...

root の論理ボリュームに余っている領域を拡張する。

# lvextend -l +100%FREE -r /dev/mapper/almalinux-root
  Size of logical volume almalinux/root changed from 70.00 GiB (17920 extents) to <507.04 GiB (129802 extents).
  Logical volume almalinux/root successfully resized.
meta-data=/dev/mapper/almalinux-root isize=512    agcount=4, agsize=4587520 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=0 inobtcount=0
data     =                       bsize=4096   blocks=18350080, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=8960, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 18350080 to 132917248

この時点で1つの領域に結合されたことがわかる。

# df -h
ファイルシス               サイズ  使用  残り 使用% マウント位置
devtmpfs                     1.9G     0  1.9G    0% /dev
tmpfs                        2.0G     0  2.0G    0% /dev/shm
tmpfs                        2.0G   78M  1.9G    4% /run
tmpfs                        2.0G     0  2.0G    0% /sys/fs/cgroup
/dev/mapper/almalinux-root   508G   14G  494G    3% /
/dev/vda1                   1014M  221M  794M   22% /boot

バックアップを削除する。

# rm -rf /home-bkup/

マシンを再起動する。

# reboot

これで問題なければ完了。

1時に寝て何度か起きて7時に起きた。エアコンを入れていると夜は寒くなってきた。

feedly pro+ にアップグレード

前からやろうやろうと思っていながら忘れて放置していた feedly のサービスに課金した。基本的に sns をやめていく方針でいるため、情報収集のソースを rss リーダーに戻そうと考えている。これまでも sns と並行で feedly を使ってはいたんだけど、もうちょっと feedly の機能も使ってインプットの効率を上げられないかと考え始めた。Pricing をみると、pro, pro+, enterprise の3つのプランがある。真ん中のプランが推しのようだったのであまり調べもせず Pro+ プランを選択した。いまのところ、検索の機能を使うぐらいでしかないが、そのうち ai 機能的なものも触ってみようと思う。

次開発の優先順位付けと担当者の割り当て

先週の要件発散会議 の続き。発散させた要件を整理して優先順位を決めて、担当者まで割り当ててしまった。課題管理がうまくできている必然なのか、なにも迷わずに自然にこのモジュールは○○さんでといった棲み分けもできて、それぞれが役割を果たせば開発の要件が満たせる体制になっている。全体像としての要件一覧は概ね用意した通りではあったものの、要件や設計の詳細の話しをしていると、私の要件の誤解もいくつかあって、それらは訂正しながら設計していくことにはなる。それでもメンバーも成長してきて、私がお膳立てしなくても、メンバーが自ら考えてうまくいくように設計してくれそうな雰囲気もみえてきたりしていて、それによって、私は面倒で厄介なインフラの再整備に注力できたりもしている。前開発がうまくいったので、なんとなく次開発もうまくいきそうな、始まる前から気を抜き過ぎにも思えるが、もう始まる前から開発が終わっている (うまくいくことが分かっている) ような感覚をもっている。できることは分かっていて、あとはどれだけの量を次開発で実装できるかといった、私が区切りの線をどこに引くかだけ決めればいいんじゃないかと考えている。よいチームになってきたなとちょっと誇らしい。

0時に寝てうまく眠れなくて、吐き気がして3時頃に起きてそのまま起きてたらいつの間にか寝て8時に起きた。夜遅くにアルフォート食べたのがよくなかったかもしれない。

go アプリケーションのライセンスチェック

お手伝い先で開発しているプロダクトは原則として oss ライセンスにするといった方針らしい。公けにソースコードを公開していないものの、お客さんが望めばソースコードも提供するといった運用にしているらしい。実際にお客さんでソースコードを要求されたことはないという。そのため、自分たちの開発したアプリケーションを oss なライセンスで提供可能かどうかを、一応は、調べておく必要がある。プレスリリースもしているし、いつお客さんが使い始めるかもわからないので、プロジェクトの隙間のときにライセンスチェックをした。

ググってみたら google/go-licenses というツールがあってこれを使って自分たちが開発したモジュールのライセンスチェックをした。問題なく apache 2.0 のライセンスで提供できることを検証した。

• インストール

$ go install github.com/google/go-licenses@latest

• レポート出力

$ cd path/to/repository
$ go-licenses report ./...

• ライセンスチェック

$ go-licenses check ./... 2>&1 | egrep "^(W|E)[[:digit:]]+"

コワーキングのオンラインイベント

月例のカフーツさんのオンラインイベントに参加した。前回の所感はここ 。8月は私の予定があわなかったのでイベントを欠席したが、7月の所感がないのはなぜか忘れてしまった。単純に忙しくて書く余裕がなかったのかもしれない。

今回のテーマは都会と地方のコワーキングスペースの運営の違いなどについてざっくばらんに雑談するといったイベントだった。後半に ONOMICHI SHARE というコワーキングスペースを運営しているごとうさんという方が参加されて、広島県尾道市という地方というバックボーンをもっていて、ごとうさんからの視点や考え方を話していただいて、いくつか示唆を受けることがあった。ごとうさんが言うには、都会から尾道市へ移住してくる人たちにはなにかしら目的があって来る、しかし、地方は都会の人たちが求めているなにかを消費するだけの場所ではないという考えを大事にしたいと話されていた。

私が地方出身の都会暮らしだから感じることがある。都会の人たちにとっての地方は娯楽とみられることが多い。わかりやすさのために、地方の不便さや独特の文化などを例にあげるが、そこに住んでいる人たちにとってはそれが日常だから何も思わないことを、都会の人たちは娯楽だと接しているようにみえることがよくある。そのギャップを埋める役割があって然るべきだと私からも思えた。要は勘違いした人たちを、現実に引き戻す役割というべきか。その話の延長上で、地方の人たちは暮らしをよくしようとか、世界をより良くしようとか、ビジネスに挑戦しようとか、そういったことをまったく考えていなくて、自治体がどんなに過疎化していっても、生活が不便になっても、この生活が一生続くと思ってなにもせず、そのまま暮らしているという人たちも多い。都会の人たちの役割の1つとして、そういった地方の人たちに世の中はどんどん進んでいて、新しいことに挑戦する価値や楽しさもあるんだよという気付きを与えることができるんじゃないかと、雑談しながら思えた。

おそらく、ごとうさんの話しを聞く限りでは、そういう仲介をする役割を担っているようにみえた。コワーキングスペースマネージャーも奥が深いという気付きを得た雑談だった。

23時に寝て何度か起きて7時に起きた。

開発方法論／開発ガイドの更新

前回の改訂 から約4ヶ月ぶりに開発方法論と開発ガイドを改訂した。

• 開発方法論: プロダクトで採用している開発方法論の概念をまとめる
• 開発ガイド: 開発方法論を具体的に実践する方法についてまとめる

近いうち、チームに新規メンバーが入る。今回の開発を経て新たにわかったことや変わったところなどを更新するつもりで全体を読み直してみたが、大きく変わったところはなく小さいアップデートに留まった。開発方法論に 情報共有とコミュニケーションのレベル というタイトルで5段階のレベルについての考え方を追記した。この内容は私もまだ完全に言語化できているわけではない。「聞かなくてもわかる」という価値観の存在をまったく疑っていないが、その背景にあるコミュニケーションの在り方や人間関係や組織での運用についてまだ曖昧なところが多い。それも含めて考えるよい機会だと思ってうちのチームに向けた内容に整理し直してまとめてみた。もう2-3回ぐらいこのテーマで話しをしたりすると、より言語化できてもっとよいものができそうな気配は感じている。

fun/done/learn のカスタマイズ

昨年からふりかえりの手法として fun/done/learn という手法を採用している。2週間のイテレーションが終わったときに毎回このフレームワークを使って、やったことをメンバーに共有するといった用途のために使っている。大きな開発のふりかえりを行ったときにマイルストーンごとの fun/done/learn の個数の変化などもふりかえってはいるが、そこの統計値がなにかに役に立つようには、いまのところ、うちのチームでは思えない。

今回のふりかえりをしているときにメンバーから done はいらないのではないか？という意見が出た。この手法の発明者のオリジナルの記事 ファン・ダン・ラーン(FDL)ふりかえりボード と読むと、done = deliver だし、done しなかったことも含めてのふりかえりを実践していたことが伺える。うちらはやったことをふりかえるためのフレームワークとして活用しているため、done がデフォルトでプラス fun/learn が付くといった運用になっていた。その通りだなと納得して done に置き換わる、うちらの開発の運用にあうカテゴリを考えてみて give を採用した。ゴロがよいように fun/give/learn と呼ぶ。

give とは、このマイルストーンでやったことを形式知として、他のメンバーに共有可能な状態にしたという意図を表す。wiki を書いたりするのもよいし、テックブログを書くのもよい。暗黙知を形式知に変えるには少し手間暇がかかるのでちょうどよいカテゴリに思える。3つのカテゴリに属するときにもっとも価値が高いような運用にも向いている。そのためのボードも作って、これを jamboard の背景に設定してふりかえりをしている。何ヶ月か運用してみて、うまくいきそうだったら fun/done/learn の亜種としてどうだろう？といった提案のテックブログを書いてみたい。

0時に寝て何度か起きて6時に起きた。土曜日から喉が痛くてコロナ感染の懸念もあったけど、前日は一日中休んでいたせいか、喉の痛みは全くなくなった。たまたまだったのかもしれない。

slog 移行

slog 勉強会 で学んだ LogValuer という interface を使うと、機密情報のログ出力をカスタマイズできる。要はパスワードのような文字列を *** に置き換えるといったことをしたい。もっともシンプルな機密情報を扱う型として Secret を定義した。この Secret でラップした文字列を扱う分には slog のロガーでそのまま出力しても問題ない。

type Secret string

func (s Secret) LogValue() slog.Value {
	return slog.StringValue("***")
}

func (s Secret) String() string {
	return string(s)
}

あと自前で定義していたロガーのログ関数を slog のトップレベル関数を使うように1つずつコードを書き直していった。機密情報に関するところで一部まだ置き換えていないところもあるが、98%のログ出力のコードは slog に直接置き換えた。時間がかかるだけの面倒くさい作業なので、こういうプロジェクトの隙間に地道にやるのがよいと思う。今回も移行にあたって slog のコードを少し読んだが、slog は本当に既存のログ出力の機能で大事なところだけをシンプルに実装していてよく出来ていると思う。