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

隔週の雑談

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

フロントエンド勉強会

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

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

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

創立記念日

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

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

0時に寝て3時に起きて6時半に起きた。前日あまり寝てなかったから普段よりよく眠れた。

rabbitmq の認証

たまたまなのだけど、前のお仕事でも rabbitmq を使っていて、いまのお仕事でも rabbitmq を使っている。私の中では kafka のエコシステムに感銘を受けたので私が技術選定してよいなら kafka を使っていきたいところだけど、rabbitmq も人気があってすごいなと思う。インフラを触っていて rabbitmq の認証をしていないことに気付いた。rabbitmq の docker image を使うとデフォルトで guest/guest のユーザーが作られる。

If you wish to change the default username and password of guest / guest, you can do so with the RABBITMQ_DEFAULT_USER and RABBITMQ_DEFAULT_PASS environmental variables. These variables were available previously in the docker-specific entrypoint shell script but are now available in RabbitMQ directly.

おそらくメッセージのやり取りを通信するときも何も指定しなかったら guest ユーザーとして扱っているのかな？通信するときの RabbitMQ URI Specification によると、amqp://user:pass@host:10000/vhost のような、昔ながらの uri にユーザー／パスワードを埋め込むような認証になる。このやり方だと uri 自体が credentials になってしまって運用の使い勝手が悪くなってしまうものの、アプリケーションの変更は必要ないというメリットもある。おそらく歴史的に認証は後付けで追加されたのかな？ともかく実際の運用だとユーザー／パスワードでアクセス制御を行うだろうと想定されるので気付いたタイミングで開発環境の docker image の設定と uri の変更を行った。

時事ネタの気軽な雑談会

【おはなし会】CEXだって安全にできるもん に参加した。ちょうさんは fin-py のイベントで何度か発表を聞いたことがある。データサイエンス系のお仕事をされているのかな？ftx 事件 をうけて ethereum の創始者である vitalik buterin 氏がブログに投稿したアルゴリズムの解説をされていた。

• Having a safe CEX: proof of solvency and beyond

取引所の不正を防ぐための仕組みとして、それぞれの口座の残高を公開しなくても merkle tree とハッシュ関数をうまく使って、取引所が実際に管理している残高とユーザーの残高が一致しているかをチェックできるような、そんなアルゴリズムだったと思う。ちゃんとブログの記事を読んでないけど、ちょうさんの解説を聞く分にはアルゴリズムはそう難しくないように思えた。そんなすごい仕組みじゃなくて、簡易的に大きな計算コストもなく全体の残高があっていることのおおよそのチェックはできますよといったもの。

イベントが始まる前にちょうさんが大学の研究室にいた頃、研究室へ行くと同僚がいて気軽に新しい技術の話しができたけど、社会人になるとそういう機会が減ってしまったという。時事ネタを気軽に雑談できるイベントがあればという話しをされていて私も共感できた。

0時に寝て3時に起きてそのまま眠れずにいたら6時になって7時過ぎから準備してオフィス行ってお仕事を始めた。

gitlab の ci/cd の調査

初めて GitLab CI/CD を触っている。まだ触り始めたばかりだが、感覚的には github actions 相当の機能はあるようにみえる。ソースコードリポジトリやパッケージリポジトリ／コンテナレジストリと ci/cd がセットになっているととても便利だ。これはすごいことだと最近思うようになってきた。もはやソースコードリポジトリのみのホスティングビジネスは成り立たない。なぜなら github や gitlab のような ci/cd が当たり前になってしまうと、その機能がない場合、デメリットを上回るメリットがないとそんなソースコードリポジトリを選択しない。

docker image をビルドして push する仕組みは既にメンバーが作ってくれていたのでその後始末の処理を作った。Container Registry API を使うと、不要な docker image を削除できる。

• Delete registry repository tags in bulk

削除向けに便利な api 設計になっている。こういう細かい配慮は嬉しい。keep_n で最低限残すイメージ数を指定して older_than で過去何日より古いイメージを削除対象とするといったよくある運用の設定ができる。

curl -s -H "PRIVATE-TOKEN: $PROJECT_ACCESS_TOKEN" -X DELETE "${endpoint}" \
  --data "name_regex_delete=.*" \
  --data "keep_n=${KEEP_N}" \
  --data "older_than=${OLDER_THAN}"

あとは認証のトークンを指定する方法として私が調べた限りだと2通りある。

• (ci_job_token_scope の feature flag を有効にして) $CI_JOB_TOKEN を使う
  • こっちの方が一時トークンなのでよりセキュアなはず
  • この場合はヘッダーに JOB-TOKEN を指定する
• プロジェクトレベルのアクセストークン を発行して ci/cd の variables に登録する
  • トークンが漏洩したときにプロジェクトレベルで被害が発生する
  • この場合はヘッダーに PRIVATE-TOKEN を指定する

使うトークンによってヘッダーが変わるというのがちょっと変な認証の設計にもみえるけど、まぁそれぐらいしか気にはならない。

にわかサッカーファンになって、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度目のビル名の変更があっても登記変更を申請しなくて済む。たまたま申請前にオフィスの掲示板を眺めて気付いたことで登記の住所の仕様を学ぶことができた。周りの観察は大事という話し。

22時に寝て1時に起きて吐き気がして苦しんでた。その後、寝て1度起きて7時半に起きた。寒くなってきたせいか、疲労のせいか、なんとなく体調が悪い。今日も掃除したり荷解きの片付けやったりしていた。

退去するオフィスの掃除

ワールドカップが盛り上がっているので関連するニュースを読んでいるうちにサポーターだけじゃなく、選手もロッカールームをきれいに掃除して退出しているニュースをみかけた。

• FIFA公式が日本代表のマナーを絶賛　ピカピカ更衣室に「ドウモ アリガトウ」

日本では小学校の頃から自分たちの活動の場を自分たちで掃除するという習慣が当たり前のように教育されている。その延長で自分たちが使った場所は掃除して帰るといった価値観が一般的に定着しているように思う。掃除するお仕事を奪っているという批判も、掃除はボランティアがやっている、ボランティアと言っても有償ではある、有償といっても歩合制でお金をもらっているわけではないでしょうとか。さまざまな意見がある。批判を認めないわけではないが、私も掃除をすることは正義の1つだと最近思うようになってきた。12月3日に引っ越しするのに12月4日 (予備日) まで借りていた理由はとくになかったのだけど、オフィスを掃除するためだったんだなと後付けの理由ができた。朝から掃除機をオフィスへ運んで掃除してきた。

This isn’t just a clean dressing room, it’s a clear demonstration of values.

It’s a statement about respect, gratitude and attention to detail.

The small things are the biggest indicator of the big things - your values.

https://www.linkedin.com/posts/stevenbartlett-123_this-is-how-the-japanese-mens-team-left-activity-7001499750009044992-qpeU/

たまたまねとらぼの記事を読んだ後に linkedin の投稿もみかけた。日本人は掃除に respect なんか感じたことはないかもしれないけど、外からみるとそういった振る舞いの1つにみえるんだという気付きにはなった。やっぱり掃除は正義やね。

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割ぐらいできたところで今日の作業は終えた。出張と移動で疲労は積み重なってきた。

23時に寝て何度か起きて7時に起きた。朝から近況報告のための資料を作ってた。

プロジェクトの進捗報告

お手伝い先の経営者の方々と、この1ヶ月で私がやったこと、開発の進捗、今後の展望などを打ち合わせした。組織のことも業務のこともわかっていないマネージャーがやってきて開発プロジェクトを仕切ることになったのが1ヶ月前。そんな簡単に成果を出せるわけがないがないと考えているため、私の所感としてはぎりぎりの及第点といったところかな。開発体制を構築し、4つのイテレーションから成る1ヶ月というマイルストーンを設け、その最初のサイクルがまわって、メンバーもどういった働き方を私が求めているか理解できたと思う。毎週の勉強会を設けて知識やスキルをチームで共有することの大切さも啓蒙している。嬉しいことにチーム外からも参加者がいる。ここからはこのワークフローを最適化していくだけ。その下地を作った1ヶ月だった。先方からも開発のプロがやるマネジメントから学ぶことも多いといったコメントをもらえた。1on1 も節目のタイミングでしかやっていなかったらしく毎週1on1をやっているのはよさそうといった話題も出た。一方で目標としている時期にこのプロダクトは何ができるのかわからないから次回はそれを明確にしてほしいといった要望もいただいた。この1ヶ月の私の課題として対応していきたい。