0時に寝て5時に起きて7時に起きた。変哲のない普通の朝だった気がする。

三菱 UFJ 銀行の住所変更手続き

先週来店予約をとったので登記事項証明書をもって来店した。手続き自体はすんなりと進み10分で完了した。わざわざ対面で行うのは最早これセキュリティ。とりあえずセキュリティと言っておけば多少の不便さなんか吹っ飛ぶ。担当者が次の項目をチェックしていた。

• 免許証の写真と同じ人物かどうか
• 住所が書類とあっているかどうか
• 通帳が正しいかどうか
• 銀行の届け印が正しいかどうか

eltax の住所変更手続き

オフィスのプリンタを調べたらスキャナの機能もあることがわかった。夜に登記事項証明書をスキャナで取り込み pdf 変換できたのでそれを使って eltax で地方自治体 (県と市) の異動届も提出することにした。どうやら申請・届出は pc 版ではなく web 版を使うらしい。初めて行う申請だったので書類の在り処や段取りがわからなくて2時間ぐらいかかった。ざっくり次の手順でできる。

1. 県向けに異動届を作成
   1. 登記事項証明書の pdf 添付
2. 作成した異動届をマイナンバーカードを使った公的個人認証サービスで署名して送信
3. eltax の利用者情報の変更届けを送信
   1. 住所が旧住所になっているので更新
   2. 県と市のどちらかを選択すると両方に通知される？
4. 県向けに送付した異動届を複製
   1. 登記事項証明書の pdf 添付も複製される
5. 同じ異動届を使って市向けに作成
6. 作成した異動届をマイナンバーカードを使った公的個人認証サービスで署名して送信
7. メッセージ照会や受付状況照会で内容を確認

翌日には受付状況照会で手続きを完了したというステータスになっていたので問題はなかったみたい。同じ異動届を複製できたのが便利だった。

eltax で異動届を県と市の2つへ提出した。2時間ぐらいかかったけど、手続きを理解した (はず) 。最初に作った異動届をコピーして別の自治体向け申請ができた。入力の手間を省けるので便利な機能にみえる。この次に1つの申請を2つの自治体へ送るといった改善が期待される。

— Tetsuya Morimoto (@t2y) December 13, 2022

0時に寝て5時に起きて7時に起きた。起きたら冷やしたのかお腹痛かったが、まぁまぁ眠れたと思う。

テスト環境の構築

GitLab CI/CD にだいぶ慣れてきてジョブを追加したり改善したりしながらようやくアプリケーションの docker image もコンテナレジストリに push されるようになった。それを pull してきて、テスト環境を docker compose で構築する。Use Compose in production とドキュメントでは威勢がよいが、これが全然イケてない。複数の compose.yml で項目によっては変更したいところを置き換えるといった振る舞いになっていない。例えば、ポート番号などを dev と prod で置き換えたいといった運用の要件を考える。

• dev.yml

services:
  myapp:
    ports:
      - 18080:8080

• prod.yml

services:
  myapp:
    ports:
      - 8080:8080

これを次のように指定すると、

$ docker compose -f dev.yml -f prod.yml up -d

実際のサービスは次のように振る舞う。全然あかん。

services:
  myapp:
    ports:
      - 18080:8080
      - 8080:8080

他にもそれぞれの yml ファイルで読み込む environment file のマージなどもよくわからない振る舞いをしていて複数の compose.yml で制御するのは断念した。dry の原則に反して設定は重複するけど、それぞれの環境を個別に compose.yml として管理した方が保守コストは小さくなると私は判断した。複数の compose.yml の使い分けのデバッグを1-2日やった後に諦めてテスト環境の構築は完了した。

年金事務所の住所変更手続き

先週 法務局で法人登記の変更申請 をしていて、そのときに問題がなければ今日から登記事項証明書を取得できると案内をもらっていた。決定書が漏れていて再提出というトラブルはあったものの、最小限の損失で留めたせいか、問題なく登記事項証明書を発行できた。住所の変更だけわかればよいので履歴事項証明書ではなく現在事項証明書を発行してみた。この書類もおもしろくて1つ前の住所といまの住所の2つを確認できる。法務局へ行った帰りに年金事務所へ立ち寄って社会保険の住所変更の手続きを行った。次の3つの書類をもって窓口へ。

• 登記事項証明書: 番地まで記載されている
• オフィスの一時使用契約書: ビル名はあるがこのビル名は来月に改名
• ビル名変更の証明書類: ビル名の変更のみが記載されている

この3つの書類で完全に指定された住所 (Fully Qualified Address: 造語) を丁寧に説明したところ担当者に納得してもらえて事なきを得た。

0時に寝て何度か起きて7時に起きた。金曜日は普通の週でも疲れているが、今週はハードだったからさらにバテバテ。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。オフィス移転に伴う諸々を雑談したり、おもには夕方から講師をしてもらうフロントエンド勉強会の最終確認のようなことをしていた。

フロントエンド勉強会

私がマネージャーとなって今月決めないといけない大きな意志決定の1つにフロントエンドの技術選定がある。とはいえ、私はフロントエンドに関して素人なのでなにかしら取っ掛かりがほしい。その参考の1つとして、はらさんにお願いして技術選定というテーマでフロントエンド勉強会を開催してもらった。感謝。いまお手伝い先では私が毎週チーム勉強会を行っている。これも1ヶ月以上続けている。そろそろ定着しつつあってチーム外からも毎週数人が参加してくれるようになってきた。勉強会という開発文化の取り組みとしてもちょうどよいように思ったのでお手伝い先も巻き込んで講師だけ社外の人が務める勉強会となった。結果は15人以上参加してくれて質疑応答も盛り上がってよかったと思う。

State of JS アンケート (ここは翻訳されたサイト) という、主にはフロントエンドの開発者の調査結果がある。これはフロントエンドの開発者のみのアンケートなので偏りはあるだろうというのも考慮しつつ、最近のトレンドを理解する上でよさそうに思えた。React をデファクトスタンダードとして、対抗する候補に Svelte のみを私は考えていたが、もう1つ Solid を加えてもよいのではないかとアンケート調査をみていて思うようになった。

私にとってもっとも参考になった技術選定の考え方としてリニューアルを前提にフロントエンドを作るというもの。技術選定で難しいことの1つは、いま流行っている技術が未来もそうかどうか誰にもわからない。未来に人気がなくなって保守されなくなって開発中止となり、フロントエンドの作り直しを強いられることを避けたいという心理や懸念は一般的だと思われる。その懸念を逆転の発想をもって、例えば、作ってから3年経ったら既存のフロントエンドはすべて捨てて作り直すと決めておけば多くの悩みは解消される。こういう言い方をすると多くのフロントエンド開発者は怒るかもしれない。私にとってはプロダクトのコアはバックエンドであってフロントエンドはそうではない。だからフロントエンドはそのときの流行りの技術で動けば何でもよいという考え方は納得感が高い。

創立記念日

今日が会社の創立記念日。無事に3周年を迎えた。いつか創立記念日をお休みにしたいが、未だそのときではない。

2年目は大きな失敗も経験して経営やキャリアの両方で反省する機会にもなった。その過程でうちの会社はなにをやるのかという基本方針とプロダクトの種のようなものができた。3年目はプロダクト開発の前段階としての実証実験のようなことを実際のお客さんの業務を通じて行っている。しかもそれがいま2社目。会社を作ったときに最初の10年間のステージを3つに分けた。そしてそのステージにおけるフェーズ1の終わりが近づいていて、目標としていたことも達成の見込みがたっている。うまくいけば来年の中旬以降から実証実験の結果を踏まえたプロダクト開発に移っていけるかもしれない。そうなればフェーズ2に移行する。起業してから3年経ってもありがたいことにお仕事はあるし応援してくれる人たちもいる。周りの人たちに恵まれていて感謝することも多い。過去の自分がやってきたことに自信をもっているからその人脈も継続できているし、少しずつ新しい関係性を作っていくことにも注意を払っている。あと何年働けるだろうかと考えることもしばしばある。もうそんなに長くないこともわかっているので悔いのないよう挑戦していきたい。

にわかサッカーファンになって、20時頃に1-2時間寝て24時からワールドカップのクロアチア戦をみて3時に寝て8時に起きた。睡眠のリズムが完全に狂ってしまった。

echo のテストのやりやすさ

うちのチームでは http フレームワークに echo を採用 している。その後、開発を継続していていくつか http ハンドラーも実装されてきた。そろそろ http ハンドラーのテストを書いていこうと参照実装を私が書いてみた。メンバーが知らないことは、マネージャーの私が参照実装して教えるといったやり方をしている。echo.HandlerFunc に echo.Context を渡すシンプルなインターフェースはテストを書くときに http ハンドラー以外の依存関係 (例えば db とのコネクションなど) を context を介することでモックと差し替えるのが容易になる。

tests := []struct {
	name    string
	ctx     echo.Context
	err     *echo.HTTPError
} {
    ...
	func() echo.Context {
		data := `{...}`
		c := newEchoContext(http.MethodPost, "/endpoint", data)
		c.Set("db", &myMockDB{})
		return c
	}(),
    ...
}

if err := myHTTPHandler(ctx); err != nil {
    ...
}

こんな感じで context にモックを入れてしまえば http ハンドラーそのものの単体テストを簡単に書ける。そんなことをツィートした。

その後 echo を採用して echo のよいところに1つ気付いた。echo.HandlerFunc に echo.Context を渡すインターフェースはテストがやりやすい。例えば、コンテキストで db のコネクションを保持しておけば、テストのときにモックに差し替えて http ハンドラーの単体テストを実装しやすい。

— Tetsuya Morimoto (@t2y) December 7, 2022

そしたら podhmo からレスをもらったので go のリクエストコンテキストの扱いについても議論した。

• リクエストスコープのものを context に入れるのは同意
• それ以外のスコープのものを context に入れるのは懸念がある
  • http ハンドラーのレイヤーとアプリケーションのレイヤーが明確に分かれているならまだ理解できる
  • アプリケーションのレイヤーで context を自由に使うと依存関係や統制が取れなくなる
    • これは私も同意するところでアプリケーションのレイヤーにリクエストコンテキストを渡す必要はない

https://t.co/Yomdbyh1H0

昔にこういう記事を書いてた。
chiはルーティングライブラリと考えるとスムーズ。

あとはnet/httpのミドルウェアを使いたいかechoなど専用のものを書くかの違いくらいかな。 https://t.co/9LtoanpY0c

— po (@podhmo) December 7, 2022

オフィス住所の更新

引き続き、住所変更の手続きを時間をみつけてやっている。同じ銀行の住所変更の手続きでも PayPay 銀行と三菱 UFJ 銀行ではまったく異なる。前者はオンラインでアカウント情報を変更するだけで済んだ。簡単。一方で後者はオンラインではできず、来店予約をとって対面で行う。当日に登記事項証明書の原本をもってこいと。なんという面倒臭さ。よくよく考えたら法人の登記事項証明書は誰でも取得できる。行政のシステムがどうなっているか知らないが、銀行が法人の住所変更を自分たちで調べることもやろうと思えばできるはず。登記事項証明書をオンラインで取得する手数料は500円になる。来店予約すると応対する人の人件費を考えたらシステムの手数料を支払った方が安いのではないか。

国税庁の管轄ではあるが、国税庁法人番号公表サイト から法人の住所変更そのものは確認できる。これは e-tax で次の2つの書類を申請した。登記事項証明書がなくても申請はできた。なにも言ってこなければ問題ないのかな？

• 異動届
• 給与支払事務所等の開設・移転・廃止の届出

有償にはなるが 登記情報提供サービス というのがあって登記情報をオンラインで確認できる。このサービスを会社で契約していればいつでも確認できるはず？

4時に寝て8時に起きた。3時過ぎまでオフィスの片付けなどをやっていた。貧乏暇なし。

年金事務所でヒアリング

8時半から住所変更のために年金事務所に立ち寄る。会社の住所変更をすると行政機関にその申請をしないといけないが、年金事務所がもっとも短くて移転後5日以内となっている。行ってみたら登記事項証明書のコピーがないと手続きをできないという。すべてに先立って法人登記の変更申請が必要なことがわかった。法人登記の変更申請に1週間かかるのでその時点でこの手続きは無理だとわかった。行政のバグの1つかもしれない。

法務局で法人登記の変更申請

以前、電子公告の変更で法人登記の変更申請をやったことがあったので手続きの雰囲気を理解していた。お昼休みを兼ねて法務局へ住所変更の申請に行く。合同会社の法人登記の変更申請は次のリンクにある。

• ３　商号・目的の変更，本店移転

しかし、このリンクを辿ると、3つの記載例がある。

3-4 合同会社変更登記申請書（商号の変更及び目的の変更）【R4.11.11更新】

3-5 合同会社本店移転登記申請書（管轄内移転）【R4.9.20更新】

3-6 合同会社本店移転登記申請書（管轄外移転）【R4.9.20更新】

ここで私が慌てていて 3-4 の「商号の変更及び目的の変更」の記載例しか目に入ってなくてその内容を確認して申請書類を作って提出してきた。後日、担当者から決定書が必要ですと電話がかかってきた。私が参考にしないといけない記載例は 3-5 の「管轄内移転」の方だった。たしかにその書類には決定書が含まれていた。3-4 にはそれが不要だったので申請書類から漏れた。後日、決定書を再作成して法務局へ再申請に行ってきた。申請自体は15分もあれば終わる作業だけど、1度で終わらせる手続きを済ませられなかったという自分の不甲斐なさにショックを受けた。余裕をもって周りの観察が大事という話し。

初めての会社のオフィス移転で学ぶことも多かった。申請には「原因年月日」を記述できるので予め前もって登記変更の申請を行うことはできないのだろうか？移転後2週間以内に申請する必要があると書かれた記事を読んでいたので私は引っ越し後にしか申請できないと思い込んでいた。

また定款の記載内容によってはオフィス移転で定款変更も必要になる可能性がある。定款の変更には同意書が必要なため、さらに申請書類が増える。うちの会社の定款の条項は次になる。

(本店所在地) 第3条 当会社は、本店を神戸市に置く。

定款の本店所在地は市町村まで構わない。神戸市内で引っ越しする分にはうちの会社は定款変更を必要としない。おそらく会社を設立するときにオフィスがまだ決まっていなかったからそうしたのかもしれない。私が意図して定款の本店所在地を決めたわけではない気もする。freee 経由で定款作成代理人がよしなに作ってくれたようだ。感謝。

さらにたまたま申請する直前にオフィスの掲示板で来月からビル名が変わりますという掲示をみつけた。登記変更の申請を知らない人向けにこの手続きはどんな内容であろうが申請に手数料が3万円かかる。ビル名が変わったらその都度3万円支払う必要がある。少し調べてみると、新しいオフィスのビル名が変わるのは3度目でどうもそういう傾向のあるビルにみえる。これは4度目もありそうだ。登記の住所についてさらに調べてみると、法律上は番地まで記載すればよくてビル名を登記に含める義務はないという。今回の登記変更の申請にはビル名を含めず番地までとした。これで未来に4度目のビル名の変更があっても登記変更を申請しなくて済む。たまたま申請前にオフィスの掲示板を眺めて気付いたことで登記の住所の仕様を学ぶことができた。周りの観察は大事という話し。

3時に寝て8時に起きた。疲労困憊だけど、今日を乗り切ればよい。9時から荷造りの続き。昨日の深夜に大半の荷造りを終えていたので2時間ほどで終えて軽く掃除したりしていた。

引っ越し

14時から レントラ便 さんにお願いしていた。13時25分にレントラ便の担当者から電話がかかってきてオフィスに到着したとのこと。私もすでに準備出来ていたのですぐやりましょうということで搬出作業が始まった。作業員として1名しかお願いしてなかったが、先方の担当者は2名いたので荷物の搬出がその分楽になった。だいたい30分ぐらいで搬出作業が終わった。新しいオフィスに移動して14時から搬入作業を開始した。搬入作業はだいたい20分ぐらいで終わった。出すよりも入れる方が速かったのは、バンに荷物を積み込むときにスペース効率を考えながら配置する必要がないからだろう。時間に余裕があったので追加で新しいオフィスにある椅子を保管するために家まで運んでもらった。オフィスの椅子はアーロンチェアを使っているので備え付けの椅子はいらない。それが終わったのが14時25分だった。そこで事務手続きして完了とした。荷物の移動も含めて約1時間で引っ越し作業を終えた。本当は14-16時で依頼していたが、早く始めて想定したよりも早く完了していいこと尽くめだった。また次回があればレントラ便さんにしようと思う。その後、荷解きしながらぼちぼち片付けをしていた。

ストレッチ

19時半からストレッチ。先週の田んぼ作業 でスクワットに近い運動をたくさんやったので月曜日や火曜日はひどい筋肉痛になっていた。水曜日以降はましになったが、若干の違和感も残っていた。今日の開脚幅は開始前144cmで、ストレッチ後150cmだった。疲労と筋肉痛でまったくいつも通りにはいかなかった。お腹つったり足裏つったりしてた。トレーナーさんが言うには筋肉痛のときは普段のストレッチをあまりやるよりも筋肉をほぐすようなストレッチをした方が早く回復するみたいな話しをされていた気がする。あとはワールドカップの話などをしていた。

0時に寝て5時前に起きたらサッカーやってて最後の10分ほどみた。まさかスペインに勝つと思ってなかったから驚いた。

アーキテクチャと設計

退職したメンバー がドメイン駆動開発 (DDD) とクリーンアーキテクチャから既存のアーキテクチャを構成したというドキュメントを残してくれた。そのドキュメントを読みながら、説明の粗いところや足りないところを私が補って加筆し、既存のコードを読みながら誤っているところなどをリファクタリングしたりしていた。あとアーキテクチャや設計のドキュメントを書く上で図がないのはよくない。現代の開発は分割統治の概念で設計されていて、そこで扱う本質的複雑さは依存関係になる。誤解を恐れずに言えば、現代の開発のアーキテクチャは依存関係をどう管理するかの基本的な考え方に過ぎない。依存関係の向きが分かるので図があった方が圧倒的にわかりやすい。一方で私自身もクリーンアーキテクチャにそう明るくない。もう少し勉強し直す必要があることは感じた。クリーンアーキテクチャ勉強会もやっていいようにも思う。

課題管理 + イテレーション開発とスクラム開発の勉強会

今週ずっと朝起きたら2-3時間かけて資料を作り続けてきた。前回は時間が余ったので今回は余らないよう、最終的には43枚のスライドになった。

• スクラム事前知識
• スクラムガイド
• 課題管理+イテレーション開発とスクラム開発との比較
• スクラムマスター
• 会議体とツール
• 分析・計測
• スクラムの是非
• まとめ

話してみたら1時間を10分ほどオーバーした。勉強会で1時間話すネタを調整をするのは難しい。毎月出張でオフィスへ行くときは課題管理に関する勉強会を行う。課題管理や開発方法論の話しを聞いてくれる人たちがいるというだけでありがたい。5日前から準備を始めて資料作りの時間が少なかったので細部の調査はあまりできていないし、構成も荒くて練れていない。もう2-3ヶ月かけて細部の調査や理論武装をしたらよいコンテンツになるかもしれない。イテレーション開発とスクラム開発を比較するときの叩き台として寝かしておく。

オフィスの引越しの荷造り

神戸に戻ってきて一旦家に帰って晩ご飯を食べて一息ついて、23時過ぎから引越しのための荷造りを始めた。大きい家電や電子機器は購入時の箱を置いておくと引越しのときの荷造りが楽になる。言うても一部屋の荷物なんで本気出せばすぐ終わる程度の量。3時間ほど荷造りやって8割ぐらいできたところで今日の作業は終えた。出張と移動で疲労は積み重なってきた。

20時過ぎに寝て0時に起きて、何度か寝たり起きたりしながら7時に起きた。神戸マラソン のスタート地点が近所なので朝から神戸マラソンのアナウンスが聞こえてきた。

睡眠時間と仕事始め

後藤達也 note の掲示板 (たぶんメンバーしかみれない) に後藤さんがいつ寝ているのかという質問への回答を書かれていた。

よくある睡眠パターンは21:30ごろ～4:30とかだと思います。これだと7時間寝ているので十分です。

後藤さんも早寝早起き派らしい。私はだいたい0-6時が平均的なパターンだと思うけど、ちゃんと眠れないので6時間も寝ていない。体調の悪いときは横になっているものの1-2時間しか寝ていないときもある。7時半までには家を出てオフィスに向かい8時までにはお仕事を始める。開発が佳境に入ってきて集中力が上がっていれば仕事始めが6時半から7時ぐらいになる。開発のピークにそういう時期をもっていくように調整しながら働くときもある。最近は働き方改革でそういった密度の高い開発を要求されることも少なくはなりつつあるけど。

仕事を受ける判断

後藤さんはすごいなーと読んでいたら睡眠時間の投稿が思いの外盛り上がったらしく、第2段として仕事の選び方について投稿されていた。

そのなかで仕事を受ける判断として大事にしているのが、「発見があるか」「広がりがあるか」です。

これも私にとって共感のある内容でその投稿を読み入ってしまった。これまでも日記のあちこちに断片的には書いてきている。私も2021年1月31日に会社として引き受けないお仕事の基準を設けた。次の項目に該当したら基本的に引き受けない。

• 自分の目指すキャリアの延長上にない
• 自分がもっている知識や経験だけでできる
• すでにあるものを維持していく、手伝うだけ
• そこそこの開発メンバーがいて人手が足りないのを補うだけ
• 権限委譲がなくてイニシアティブを取れない

どういうお仕事を受けて、どういう働き方をするかを課題管理し、その後も継続的にずっと考えていてまだ答えは出ていない。もう2-3年かければより明確になりそうな気はしている。やりたいことよりもやりたくないことを定義する方がずっと簡単で具体的と言える。

jira の epic 運用にもの思い

jira に特化した話だけど、チケットの整理をしていて自分の中での結論を言語化できたので書いてみる。前からずっと思っていたことではある。twitter に書いた通りだけど、epic のサブタスクはあまり使わない運用がよいのではないかと思うようになった。そもそも epic という単位が story よりも大きな機能のグルーピングを表す概念なのだから epic チケットはシステム上の制約で存在しているだけでそれを通常のチケットのように扱わなくてもよいのではないかと思う。epic に限らず、チケットを束ねるだけのハブチケットまたは親チケットに通常のチケット機能を設けない方がユーザーにとってわかりやすいようにも考えている。ハブチケットや親チケットに特化した要件や振る舞いはあるはずで、多くの課題管理システムはそれを追求していないようにもみえる。

epic の子課題は新機能や改善の種別のみにしてしまう。複数チケットに分割が想定される調査タスクなどの子課題は「○○を研究する」ように新機能や改善に置き換える。epic のサブタスクは階層化を必要としない単発のタスクのみに限定して使う、もしくは一切使わない運用にする。

— Tetsuya Morimoto (@t2y) November 20, 2022

2時に寝て7時に起きた。昨日は23時ぐらいまで送別会やっててまた寝るのが遅くなった。

隔週の雑談

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

• オフィス引っ越し計画 の共有
• SECI モデルのワークショップ の共有

昨日の送別会で、システムはいくらでも社員を監視して効率や最適化を要求できるけれど、そんな働き方は嫌だろうし、幸せじゃないだろうと私が話した。それに対して次のような反論がきた。

そんなことはなく誰か (何か) に管理されたいと考える人間の方が多数派だ

私はまったく同意しないのだけど、はらさんにも聞いてみた。リスクの多寡や有無ではないかと。リスクを取りたくない≒管理されたいと考える人が多いのではないかと答えてくれた。上司の言うことさえ聞いていれば自分は何も責任を負わなくてよいと考える人たちが一定数いることは私も理解できるが、そんな卑屈な人たちが多数派になるのかな？とやはり懐疑的に思えた。

プロジェクトの最終日

スプリントレビュー、送別会、今日のデイリースクラムと、今週は「最後なんで」の挨拶を3回ぐらいした。毎回話すことを用意しているわけでもなかったので即興で話すわけだけど、こういうところを私はもう少し準備してちゃんとした方がよいのかもしれないと反省もした。自己肯定感のセミナー でも書いたが、私は他人との比較をやめてから自分の尺度でしか生きていない。このプロジェクトで私が為したことはもちろん私の全力ではあるが、私がもてるスキルや知識のすべてを提供できたわけではない。それは組織の壁、業務の壁、伝えるスキルの稚拙さなど、様々な要因がある。一切の他責はなく、いまの成果物はすべて私の実力を反映しているものだけれども、その成果に自分自身では満足していない。10段階で言えば3ぐらいの成果だろう。自分では低い評価を下しているにも関わらず、他人からの賞賛を受け入れるのは難しい。辞めるときなので社交辞令もある。それも考慮して感謝の言葉をもらうときに、自分はそんな感謝を伝えられることをしていないというギャップに違和感を覚える。これは何を為しても満足できない、私が抱えている心の闇かもしれない。

それはともかくプロジェクトメンバーが オンライン寄せ書き にメッセージを書いて送ってくれた。オンラインの寄せ書きは無料だけど1年経つと削除されてしまう。メンバーが私のためにわざわざ時間をとって書いてくれた寄せ書きが消えてしまうというのはみんなに申し訳ない気持ちになって、プリントしてお届けを購入 (2,948円) することにした。情に訴えるビジネスモデルは抗いがたい。せっかくなので内容を秘匿して会社の宣伝にも使うかなぁ。

葬送のフリーレン で勇者ヒンメルは依頼人とあっさり別れるといったエピソードが出てくる。

旅をしてる以上また会うことだってあるだろう、また会った時恥ずかしいからね。

依頼人から報酬を受け取って貸し借りなし。それでお終い。この感覚は私にもあって、いまの時代、一緒に働いた同僚と離れても転職やなにかの縁でまた一緒に働くことは多々ある。あまり仰々しくしたくないと私も思う。送る側も良かれと思って気遣いしてくれている。それもわかるのでこういう価値観を伝えるのはなかなか難しい。

2時過ぎに寝て7時半に起きた。眠れなくて夜更しした。

バッチ処理移行のリファクタリング

昨日の時点でスプリントのタスクを完了していたので空き時間に適当なリファクタリングを行う。k8s の cronjob を使い始める以前 spring の Scheduled アノテーションを用いた定期処理 を使っていた処理のうち、優先度が低くて残っていた最後の1つを対応することにした。その処理を作ったのが私だったので私が移行した方が効率がよいだろうという話し。サーバーアプリケーション、バッチ処理 CLI、手動実行のためのフロント画面の修正と3箇所直す必要があったけれど、私がやれば半日もかからず移行できた。

オフィスの引っ越し計画

オフィスの引っ越し が決まったので引っ越しタスクを整理していた。次の5つのタスクになる。契約はすでに完了しているので残りは4つ。

• 引越し先オフィスの契約
• 引っ越し業者の手配
• 本店移転の行政手続き
• 現オフィスの退去の手続き
• 名刺の再作成

オフィスを引っ越しすると、いくつか行政手続きにおける住所変更が必要になる。うちは就業規則を扱っていないので労働基準監督署とは関わりがない。たぶん3つだけ。

• 法務局
• 税務署/都道府県税務所
• 年金事務所

登記事項証明書を変更するとまた手数料に3万円かかる。それはともかくオンラインでできないかも調べてみた。商業・法人登記のオンライン申請について に手続きの方法が書いてあったけれど、この文章を読んで理解するよりも法務局行って書類に記入した方が速いように感じた。自転車で10分の場所に法務局があるので法務局のオンライン申請とか考えないことにする。

0時に寝て6時に起きた。週末に田んぼ作業で普段より体を動かしたせいか、久しぶりによく眠れた。

開発お手伝いの最終週

今週いっぱいで1年に渡った開発のお手伝いを終了する。金曜日に働いて月曜日は休暇をとる。1年働いて初めての休暇が業務最終日となる。契約上は稼働時間しか制約がないので日数は関係ないんだけど。すでに引き継ぎは完了しているし、私が担当している機能開発もほぼ終わっていて、細かいリファクタリングやバグ修正をするだけ。今週は余った時間に余剰な小さいタスクをいくつか取りながら業務を調整する感じかな。暇だったら開発ドキュメントを追加で書いてもいいかもしれない。

ストレッチ

今日の開脚幅は開始前156cmで、ストレッチ後160cmだった。前回と一緒かな。月曜日の夜に仕事終わりで行っている割にはまずまずの数字かな。土日の田んぼ作業でやや腰に張りがあった程度で体調は悪くなさそう。土日と比べて月曜日の夜のお店は閑散としていることに気付いた。ストレッチはトレーナーさんと1対1で行うから閑散としている施設のメリットがとくにない。これがジムならトレーニング器具が有限であることから待ち時間がなかったり、いろいろなトレーニング器具を使いやすいとかあったりするだろうし、単純に混雑しているジムで筋トレするのが嫌な人もいるだろう。経営視点から施設の稼働率をどうやって上げるかという思考になって、暇な時間にストレッチのお店にくるメリットはないのかな？とか考えてた。オチはないんだけど。