23時に寝て1時半に起きて、起きてたのか寝ていたのか覚えてないうちに5時半になってた。あまりない時間の飛び方をしたので驚いた。

隔週の雑談

今日は特別な雑談で、顧問のはらさんに加え、新たに契約した税理士さん の3人で行った。税理士選定のときに何人かと打ち合わせをしていて、面談する回数で毎月の顧問料の金額が変わるという話しを伺った。契約した税理士さんはもっとも毎月のコストが低かった。本当は税理士さんとも、いまはらさんと話しているように月1回ぐらい雑談できれば望ましいが、それはいまのコストに含まれていないサービスだろうからそこは断念することにした。今日の議題はこれら。

• みんなで自己紹介大会
• 会社の前期のふりかえりと今期の展望の紹介
• ワーケーションの経費の共有と確認
• 未収還付法人税の扱いについての訂正依頼
• 電子帳簿保存法への対応

うちの会社としてのイベントとして毎年ワーケーションを行うことを考えている。昨年はあくまで個人として企画して仲のよい人たちと一緒に参加した。一般の会社なら開発合宿と呼ばれるものだが、うちには社員がいないので1人で開発合宿しても仕方がない。そこで知人やコミュニティを巻き込んでワーケーションという、コワーキングなイベントにしてしまって、他者からの刺激やフィードバックを受ける機会にしたいという意図がある。コワーキングやコミュニティの価値を検証する poc にもなるかもしれない。以前、いとうさんに教えてもらった 「余白」 という概念を検証するのもワーケーションという非日常の機会が望ましい。たった1人の会社でもこういったイベントができるということ自体も、なんか孤独ではなくて嬉しかったりする。

2021 の赤字決算のときに「欠損金の繰り返し還付」をその年で計上していなかったために、2022年は還付によって得たお金があり、それが2023年の帳簿では「未収還付法人税」として数字がマイナスで残ってしまっている。会計処理も税務処理も数字自体は誤っていないはずだが、この数値がずっと貸借対照表の資産として残り続けるのも気持ち悪いので訂正しないといけない。それを税理士さんへお願いしようと考えていた。税理士さんに伺ったところ、それは次の法人税の申告のときにまとめて直すという。別表4, 5, 5-1 あたりを修正すればよいという。法人税法をちゃんと理解しておかないと修正できないが、税理士さんは得意な作業の1つだという。

電子帳簿保存法についてまったくよく分かっていないけど、2024年1月から運用が変わるらしい。これまでは紙に印刷して保存しておけばよかったのが電子データでの保存が義務化される。それは問題ないのだが、電子データが改ざんされていないことを保証するためにはタイムスタンプ (電子署名のようなもの？) を付けて、さらに暗号化しないといけないといったシステム要件があるみたい。

2021年度の改正により、取引先と電子データでやりとりした書類の書面保存が禁止されました。2024年1月1日からは、決められた保存方法にもとづいて、データのまま保存しなければなりません。

電子帳簿保存法の電子保存義務化はいつから？2024年までに必要な対応を解説

なにかしらうちの会社も対応しないといけないと思われる。厳密に電子帳簿保存法に定められたシステム要件を守らなくても、内規を設けてそれぞれの会社のルールで運用する分には問題ないと税理士さんが仰っていた。なにかしら電子データ保存のための内規を作らないといけないのかもしれない。今後、税理士さんと詰めていきたい。

ワクチン接種

15時から5回目のワクチン接種へ行ってきた。14時59分に受け付けを済ませたものの、タイミングがよくなくて、15分ほど待ってワクチン接種して、待っている間に外は雷雨になって、雷を避けながら帰ってくることになった。その後、普通にお仕事して摂取直後はとくに身体への負担はなかった。21時頃に熱を測ると37.0度になっていた。ほぼ1年ぶりのワクチン接種になる。

こんなことあるんやという失敗談を書く。体温計の使い方を忘れた。電源ボタンが見当たらなくて、電池切れたのかと思って100円ショップに購入へ行ってきて、電池交換のために上部を取り外ししていて電源ボタンに気付いた。ほぼ1年体温計を使わないでいると、電源ボタンの位置すら忘れていた。イメージとしては眼鏡をおでこにかけて、眼鏡がないと探している人みたいな失敗。日々の記憶もほとんど覚えていないような生活ではあるけれど、体温計の使い方を忘れるみたいなこともあるんやと実感した。自分もそういう失敗をするのだから他者にも優しくなろうと思えた。

1時に寝て何度か起きて7時半に起きた。なんかしんどい夢をみたが、もう覚えていない。

rbac なミドルウェアの実装

昨日の続き 。rbac (role-based access control) なライブラリが一通り実装できたのでそれを使って echo のミドルウェア を実装した。やりたいことは次のようなこと。たったこれだけだが、これを実装するために、ここ1週間ほど、あれやこれやの実装をしてきた。ようやくそれが動くようになったというところ。私にとってはミドルウェアの仕組みは過去に何度も実装してきたものだが、頭に描いたイメージのまま、実装できたのがよかったと思う。

func rbacWithConfig(cfg rbacConfig) echo.MiddlewareFunc {
	return func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c echo.Context) error {
			if cfg.Skipper(c) {
				return next(c)
			}

			req := c.Request()
			ctx := req.Context()
			sessionStore := c.Get(keySession).(session.Store)
			userName := c.Get("username").(string)
			s, err := session.Get(ctx, sessionStore, userName)
			if err != nil {
				return fmt.Errorf("failed to get session: %w", err)
			}
			if !s.Role.CanAccess(ctx, req.URL.Path, req.Method) {
				return echo.ErrForbidden
			}

			return next(c)
		}
	}
}

node.js のアップグレード

ちょうど管理画面も少し触ろうと思って環境を構築し始めた。たまたま node.js のバージョンをみると、ちょうど10月18日で 18 (LTS) の active support 期間が終了していた。security support は2025年4月まであるのでそんな急がなくてもよいが、それに気付いたついでなので 20 (LTS) にアップグレードすることにした。幸い、大半のライブラリは 20 (LTS) でもそのまま動いた。しかし、依存ライブラリのアップデートをしていて、一部 conflict してうまく動かないライブラリもあった。細かい原因調査をしていないが、フロントエンドの方がこまめにバージョンを上げていかないと何が原因でアプリケーションが正常に動かなくなるのか、分からなくなる気がする。

• https://endoflife.date/nodejs

1時半に寝て3時に起きてもう1回起きて6時半に起きた。

interface はデシリアライズできない

昨日の続き 。rbac なライブラリを使ってアプリケーションを実装していく。ログイン時にユーザーにロールを割り当ててセッションにロールを保持するのが都合よさそうに思えた。ロールの実装で一部の型は interface にして後から拡張できるような設計にしていた。例えば encoding/json ライブラリだと、Marshaler/Unmarshaler の interface を満たすことで任意の json のシリアライズ/デシリアライズをフックできる。調べたり、実際に動かしていていて気付いたのだけど、interface の場合はシリアライズは任意にできるけど、デシリアライズはできない。当たり前と言えば当たり前だが、interface を満たす複数の型がある中で json ライブラリがどの型でデシリアライズしていいか判別できないからだ。当初の interface を用いた設計が誤りだったことに気付いて、一部の型を汎用の構造体で設計し直すようなことをしていた。

またデシリアライズするときに一部の値を初期化したいといった要件がある。例えば mutex を初期化したい。このときに処理の内部で派生型を宣言して、それにキャストした上でデシリアライズの処理を実行した上で差分の処理を実装するというテクニックを学んだ。スコープが限定されて、コードがシンプルになって保守性も高い、久しぶりに頭のよいスマートなコードをみた。

func (r *Role) UnmarshalJSON(b []byte) error {
	type Alias Role
	if err := json.Unmarshal(b, (*Alias)(r)); err != nil {
		return err
	}
	r.mu = &sync.Mutex{}
	return nil
}

• Custom UnmarshalBSON in mongo-go-driver

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

月例のカフーツさんのオンラインイベントに参加した。前回の所感はここ 。今日は参加者が2人だけだった。コワーキングスペースを運営するコワーキングスペースマネージャーの連携を強化することで、コワーキングスペースの付加価値が上がったりしないか？といった内容を話したりしていた。コワーキングスペースマネージャーは、普通はお仕事で自分のコワーキングスペースにいないといけないから、なかなか他所のコワーキングスペースへ訪問すること自体が難しい。コワーキングスペース同士の連携により、お仕事でコワーキングスペースマネージャーが自分ところのコワーキングスペースの利用者を連れて、他所のコワーキングスペースへ訪問して、そこでイベントをしたりすればいいんじゃないかという案が出た。

いとうさんがよく コワーキングツアー と称して、全国各地のコワーキングスペースへ訪問して、そこでイベント開催をしたり、その地域の取り組みなどを紹介したりしている。それと全く同じことを、コワーキングスペースの利用者に対してもその付加価値というのはあるかもしれないと私もよいアイディアだと思った。例えば、大阪のコワーキングスペースの利用者を広島へ連れていって、そこでイベントやって交流する。その逆も然り。通常のコワーキングスペースの利用者は自ら広島のコワーキングスペースへ行ってコラボレーションを行ったりしない。いや、いとうさんみたいに自らやる人もいるんだけど、そんな人は対象の利用者ではない。自分からは行かないが、誘われたら行ってもいいかなと考える人 (私もそんな1人だ) を移動させることで、新しい価値やアイディアが生まれるかもしれないと思える。私もいまはフルタイムのお仕事があるから自由に移動はできないが、いずれ会社の投資期間に入って、自分でスケジュールを決められる状況になれば、コワーキングツアーにも出掛けてみようと思う。

あと勉強会やイベント以外でコワーキングスペースで出来ることはないか？という話題でも盛り上がった。私は主催者の準備が大変だと出来ないから、主催者のコストが低いものという視点から考えて猫コワーキングがいいんじゃないかと提案してみた。ある週だけコワーキングスペースに猫が10匹ぐらいいますといった取り組み。課題は猫をどこから連れてくるかだけだが、そういう機会があれば確かに私も行ってみたい。そのアイディアの発散で非日常の体験ができるような取り組みがよいんじゃないかとまとめられていた。

• 猫コワーキング (猫がたくさんいる)
• 深夜コワーキング (深夜に開いている)

深夜コワーキングスペースのモデルとなる 弐拾dB さんというコワーキングスペースが広島の尾道にあるらしい。23-翌5時という営業時間だという。いとうさんが絶賛していたのでおもしろいオーナーが運営されているのだと思う。そのオーナーが執筆したエッセイの 頁をめくる音で息をする を購入してみた。

22時頃から休んでいて寝たり起きたりで7時に起きた。起きたらネットの記事とかだらだら読んでた。

rbac なライブラリの実装

昨日から認可のための仕組みを調査している。私の中ではもっとも一般的な rbac (role-based access control) でまずは作ってみようと思う。次の2つのライブラリの利用を検討したが、自分たちのやりたいことにあわない気がして今回は見送ることにした。

• https://github.com/casbin/casbin
  • モデル定義とポリシー設定が複雑過ぎて設定が難しい、保守が大変になりそう
• https://github.com/mikespook/gorbac
  • イメージはあっているが、この程度のライブラリなら自分で作った方が学習コストもなく、拡張にも柔軟に思える

一通り、ライブラリとして使えるように参照実装した。これから実際のアプリケーション要件にあわせてミドルウェアとして rbac な認可処理を作っていく。

変わりゆく世界秩序

サンフランシスコが陥った負の“スパイラル” の記事にあるような、米国で950ドル以下の窃盗は軽犯罪とするという法律の変更によって、万引きを逮捕しなくなってモラル崩壊が起きて、小売店の商品を普通に盗むという事件が多発しているらしい。fin-py でおがわさんとそんな話しをしていたら次の動画を教えてもらった。私は歴史が好きなので、こういった「歴史は繰り返す」といったものはだいたいみてしまう。厳密な裏付けはわからないが、盛者必衰という言葉もあるように、どんな国でも栄枯盛衰のサイクルはあるだろうというのは大局の視点として同意できる。過去の歴史と国の栄枯盛衰をいくつかの指標とお金の視点から調査したものでおもしろかった。

日本は80年サイクルで戦争の周期がくるといった説もあるが、この動画でもサイクルの切り替わりのタイミングで平和的にしろ暴力的にしろ、かならず戦争は起きると説明している。もうすでに戦争は始まっている感もあるが、戦争は避けようがないという点も同意するところだ。本も読んでみようと思う。

1時に寝て何度か起きて6時半に起きた。起きてから軽く部屋の掃除をした。

echo のミドルウェア開発

go の api サーバーの開発に echo という定番のフレームワークを使っている。少し前にメンバーに認証の処理をミドルウェアとして実装してもらった。いま認可の仕組みもミドルウェアで実装しようと、いくつかソースコードを読んでいて、echo のフレームワークが提供しているミドルウェアの関数名や config には共通点があることに気付いた。echo middleware によると、20個ぐらいのミドルウェアが提供されている。例えば、適当にそのうちの3つほどを取り出すが XxxWithConfig という命名規則で config を受けとって echo.MiddlewareFunc を返すというインターフェースになっている。

func HTTPSRedirectWithConfig(config RedirectConfig) echo.MiddlewareFunc
func LoggerWithConfig(config LoggerConfig) echo.MiddlewareFunc
func BodyDumpWithConfig(config BodyDumpConfig) echo.MiddlewareFunc

また config の中身をみていると、ミドルウェアの処理に必要な関数を渡すような設計になっている。複数のミドルウェアにとって共通なのは、ミドルウェアの処理を迂回する条件を実装するため middleware.Skipper という型が次のように型で定義されている。

e.Use(middleware.BasicAuthWithConfig(middleware.BasicAuthConfig{
	Skipper: func (c echo.Context) bool {
		// Skipper defines a function to skip middleware.
    },
	Validator: func(string, string, echo.Context) (bool, error) {
		// Validator is a function to validate BasicAuth credentials.
		// Required.
    },
	Realm: "Restricted",
}))

典型的なミドルウェアは次のように実装する。最初に Skipper を呼び出して処理の有無を確認する。

return func(next echo.HandlerFunc) echo.HandlerFunc {
	return func(c echo.Context) error {
		if config.Skipper(c) {
			return next(c)
		}

        // TODO: ミドルウェア本体の処理

		return next(c)
    }
}

認証のミドルウェアを実装してもらったときに、私がここまでみていなかったなということに気付いて、既存のミドルウェアを echo のそれと同じスタイルにあわせるようにリファクタリングした。自分でソースコードを読んでいるとコードレビューで気付かなかったことに気付くことが多い。自分がコードを書いているときと、コードレビューをしているときでなにかしら視点が違う。

3時に寝て何度か起きて8時半に起きた。午前中はだらだらしていた。午後は事務手続きしたり、本を読んだりしていた。

芦屋能の申込み

昨日 蝉丸の予習 をしてきたが、来月に能の「蝉丸」の上演がある。せっかく物語の背景や詞章の勉強したので見に行くことに決めた。第二十二回芦屋能・狂言鑑賞の会 にローソンチケットで申込みした。金曜日の17時と、ちょっとお仕事を早く終えて出掛けないといけない。芦屋ルナ・ホールという、行ったことない会場になる。前の方に座れるなら指定席を選択するのだけど、いま購入しようとすると、チケットが残りわずからしいのであまりよい席は残っていないと推測する。今回は2階席 (自由席) 3,000円 で観ることにした。昨日の能イベントの会場である芦屋能舞台でもいくつかチケットがあると朝原さんが話されていた。そこで買った方がよい席を取ることができたのかもしれない。また次の機会があれば聞いてみようと思う。

業務スーパーのナポリタンサラダ

ちょくちょく業務スーパーで買いものする。業務スーパーの惣菜などは国内工場で作っているとあるからなんとなく安心して買っている。いつもは マカロニサラダ を買っていて、野菜サラダの付け合わせにしたり、刻みネギを混ぜて食べたりしている。今日は初めてナポリタンサラダというのをみつけた。また業務スーパーのサイトにないのでおそらく新製品なのだろうと思う。私はナポリタンが好きなので買ってみた。よくあるお弁当の付け合わせに入ってそうな風味で300円程度の値段を考えれば十分においしい。単体で食べても小腹を満たせるし、他のものと組み合わせもしやすそうに思う。業務スーパーの買いもの楽しい。

21時頃から休んでいて何度か寝たり起きたりしながら5時に起きた。だらだらして気付いたら8時半だった。

ストレッチ

今週もとくに本業が忙しかったわけではないが、本業以外のお仕事や作業がたくさんあって、わりと座っている時間が長くて疲れていたのかもしれない。腰は大丈夫かな？と思ったものの、左腰の後ろはかなり張りがあってきつかった。トレーナーさんはあまり気付かなかったみたいだが。あと太ももの後ろの筋が張っていて今日は重点的にそこを伸ばしてもらって気持ちよかった。太ももの後ろの筋って物理的に自分では絶対に伸ばせない位置にあるため、トレーナーが伸ばしてくれることに大きな意義がある。これだけでもドクターストレッチさんに通っていてよいところだと思う。今日の開脚幅は開始前156cmで、ストレッチ後159cmだった。数値はまぁまぁ。

能楽の勉強

前に1度行ったことのある「能のことばを読んでみる会」へ行ってきた。前回の所感はここ 。参加者は私が数えたところ17名。前回、いつもは10人に満たないと仰っていたが、朝原さんのマーケティングがうまくいっているのか、今回も10人は軽く超えていた。

このイベントはとてもおもしろい。

• 『百人一首』で知られる蝉丸と、その姉・逆髪が出会い、別れる能《蝉丸》 第36回能のことばを読んでみる会

今日のテーマは「蝉丸 (せみまる) 」だった。国語の授業などで百人一首として習ったことを覚えている人もいるだろうか。

これやこの 行くも帰るも 別れては 知るも知らぬも 逢坂の関

蝉丸 (せみまる)

有名だし、私も学生の頃は百人一首を覚えていたのでこの歌は覚えている。百人一首の引用元となる 後撰和歌集 では次のように収録されている。

これやこの 行くも帰るも 別れつつ 知るも知らぬも 逢坂の関

オリジナルは「別れつつ」だったのが百人一首では「別れては」に改変されている。たまたま調べていると次のような質問をみつけた。

後撰和歌集に収録されている蝉丸の「これやこの 行くも帰るも 別れつつ 知るも知らぬも 逢坂の関」の和歌について、歌集によっては第三句が「別れては」となっている。「別れつつ」と「別れては」では解釈が違うのか、解説が載っている資料が見たい。

https://crd.ndl.go.jp/reference/modules/d3ndlcrdentry/index.php?page=ref_view&id=1000328600

この回答でも後世の人たちが「別れては」の方がまとまりが良いとか、読みやすいとか、抑揚が利くとか、そんな理由で勝手に改変してそれが有名になった例の1つだという。能の世界でもこういったオリジナルの単語 (漢字) や言い回しが変わってしまうことはちょくちょくあるらしい。それは文書を複写するときに単純に書き間違えたとか、後世の人がこの方がよいと勝手に表現を変えてしまうことがあって、オリジナルよりもそちらが有名になってしまうことがあるらしい。

日本の歴史を調べるときに最初に調べる辞典として 国史大辞典 がある。そこに蝉丸の記述がある。平安時代の歌人、音楽家。生没年不詳で、伝説的人物で諸説あるとのことで、本当に伝えられている経歴や逸話が正しいのかはよく分かっていないという。最も確実なのが、後撰和歌集の和歌を詠んだのが蝉丸という人物だという伝承だという。蝉丸を祀った神社は3つあり、現代では諸芸道の神様として祀られている。

• 蝉丸神社
• 関蝉丸神社
  • 上社
  • 下社

蝉丸は生まれつき盲目でありながら琵琶の名人として伝わっており「盲琵琶」の祖とされるが、これもよくわかっていない伝承だという。ここまでを能の「蝉丸」を読み始める前の予備知識として、講師の朝原さんがさらっと話すのがこのイベントの醍醐味。私がここに書き残せていない話題もまだいくつかある。一般人はここまででお腹いっぱいになるが、これが能を読み始める前段階である。

能の「蝉丸」 は、皇子なのに盲目であるために捨てられる蝉丸、皇女なのに逆さまに生い立つ髪をもち狂人であるために捨てられる逆髪の2人が、逢坂山という辺地でたまたま？出会うという物語になっている。朝原さんが天に向かって逆さまに生い立つ髪ってどういうものか現実には想像できないが、少年漫画の世界ではないか？と話されていて、私は HUNTER×HUNTER のゴンみたいな髪型を連想したw

蝉丸は盲目なので盲目の人からの視点の表現と、逆髪は目がみえるので (狂人だけど) 健常者からの視点の表現が対比として表されているのもおもしろい。京都から逢坂山の関を超える 道行 の表現がまったく異なる。お互い捨てられた先の辺地の藁屋で、蝉丸が琵琶を弾いたことに逆髪が気付いて、藁屋を尋ねる (出会う) と物語が進んでいって、お互いに涙を流して再会に感動するものの、逆髪は「じゃあ、またね」って感じにすぐ？帰ろうとするのに対して、蝉丸は「もう行っちゃうんですか？！」的な名残惜しくて、ただそれだけのやり取りの能となっている。この能はただ姉弟が出会って別れるだけの、なんの事件も起こらないし、なんの因果もない。これは仏教でいう 会者定離 (えしゃじょうり) を表しているという。出会った者は必ず別れることになるという普遍的な摂理。関西人からみると、オチがないやんとツッコミたくなるところが、哲学的ではまるところなのかもしれない。

11月に 第二十二回「芦屋能・狂言鑑賞の会」 で能の「蝉丸」が演じられるようなので見に行こうと思う。

0時に寝て4時に起きて6時前に起きた。最近早起きになってきた。

相続税の申告

今月に入って、何度か 会計事務所へ書類をもって訪問 したりしていた。昨日ようやく公認会計士の先生から相続税の申告を終えたという連絡をいただいた。父が失くなったのが 昨年の12月26日 でこの26日が申告期限となっていた。なんでこんなに時間がかかるの？と思いたくもなるが、うちの場合は10ヶ月ぎりぎりで相続税の申告ができた。遅れても延滞税がかかるだけで逮捕されるわけではなさそう。

ともあれ、相続が無事に終わってよかった。父は交通事故にあって遺言を残せる状態に回復することもなく入院生活を送って亡くなった。相続税の配偶者控除は手厚くて1億6,000万円までは相続税免除となる。なるべく母が相続する方が税金が少なくなるように一見はみえる。しかし、うちは2次相続も考慮して母と姉と私の3者に対して法定相続を採用することに決めた。2次相続のシミュレーション結果がどうであっても、私は母が相続しても詐欺で騙されて失ってしまうことを前提と考えているため、税金を余分に支払ってでも法定相続を採用しようと、もともと考えていた。最終的に母は相続税が不要なため、姉と私の2人が相続税を支払う形になった。それもすべて公認会計士さんが手続きしてくれたのでとくに労力があったわけでもない。

• なぜ二次相続は重要？一次相続との違いや税額シミュレーションについても解説

相続の手続きで揉めたのが 未登記の建物の扱い だった。原則として建物はすべて登記しなければならないという法律はあるものの、過去の建物は未登記のものが多く、うちの実家の建物も大半が未登記だとわかった。そのまま未登記のまま、固定資産税評価額を使って相続税を算出することで問題なく完了できた。

家族信託のススメ

母が一定のお金を相続するにあたり、弁護士さんから 家族信託 を推奨されている。家族信託とは、後見人制度に代わる柔軟な財産管理をするための仕組みらしい。

うちは交通事故により父が意思疎通を図れない状態となったため、有無を言わさず成年後見人が選任され、その財産管理の在り方に大きな不満をもっている。さらに成年後見人の弁護士さんに少なくない手数料を5年間に渡って支払っている。実際の運用を経験して成年後見人という制度に懐疑的なところがいくつかある。

家族信託はそういった成年後見人による財産管理に代わるもので、契約時に決めた条件に従って財産の管理を第3者 (たいていは親族？) に委託する仕組みらしい。初期費用として50-100万円ほどかかるが、その後の維持管理のために経費はかからない。うちの場合は年間 627,000 円 (税込) を成年後見人の弁護士さんへ支払っていた。つまり毎月 52,250 円 (税込) を弁護士さんへ支払っていたことになる。この費用が本人が亡くなるまでずっと継続するというのが、成年後見人制度のコストの大きいところ。うちは5年間、さらに他にもいろいろあって、もっと多額の手数料を弁護士さんへ支払っている。もしかしたら財産の多寡によっては、さらに大きな金額を支払うことになるのかもしれない。

初期費用がかかるのは次の段取りを踏む必要があり、これらの作業に専門家へ依頼することでそのコンサルティング費用や事務手続き費用がかかるとのこと。

• 契約書の作成
• 公正証書の作成
• 信託口座の開設

これによって、契約書で決めた用途に関しては私や姉がお金を管理をして、母に送金するといったことが可能となる。母は直接、信託口座からお金を引き出すことはできない。運用としては、母から送金依頼があったときに私や姉が手続きをして、年に1回、私や姉から母へ報告をおこなう必要があるといった程度の労力が必要になる。弁護士さんに教えてもらった話しとオンラインの記事をみながらメリットをまとめる。

• 成年後見人制度よりも (一般論として) コストが安く、柔軟に財産管理できる
• 最初に決めた契約の内容に従って財産を運用できる
  • (元本保証がない) 資産運用もできる (成年後見人は不可、財産が目減りする可能性があるものは一切できない)
• 親が判断能力を失っても財産管理に影響が出ない
  • 認知症になっても子どもが財産を運用できる
  • 詐欺に騙されてもお金を引き出せない
• 知的障害のある子どもがいる場合に、親が亡くなった後も財産を子どものために使ってもらうように運用できる
• ハイリスクな不動産の共有をしなくて済む

家族信託と、家族が勝手に親の通帳を取り上げて、認証情報を秘密にして運用するのと何が違うのかも弁護士さんに聞いてみた。

• 本人が金融機関に紛失届を出せば容易に再発行できる
• 親のお金を子どもが取り上げているという後ろめたさがある
  • この状態を裁判などで訴えれば親側の主張が正しい

姉とも相談しつつ、母も説得しつつ、家族信託をするのでいいのではないかと、いまのところ、私は考えている。

0時に寝て4時と5時に起きて6時に起きた。最近は4時から1時間ごとに起きたりする。メールの送信処理のリファクタリングのコードレビューが長く続いていてなかなかややこしい。

mailhog の web api を使って検索する

メール送信の結合テストに mailhog というツールを使っている。smtp サーバーとしてメールを受け付けて web ui でそのメールの内容を確認できる機能をもっている。さらに web api で任意のメール取り出すこともできる。パスワードリセットの一時トークンをメールで送信するため、結合テストで一連のパスワードリセットを検証するにはメールから一時トークンを取り出さないといけない。そこで mailhog の出番だ。

検索 api を使うと任意のメールをフィルターできる。例えば、送り先のメールアドレスで検索するときは次のようにリクエストする。

$ curl -s "http://localhost:8025/api/v2/search?kind=to&query=myuser1@example.com" | jq .

うちらのやり方はメールのメッセージ ID に意図した uuid をセットしている。メールのメッセージから指定した uuid を含んでいるかを検索することで任意のメールをフィルターできる。

$ curl -s "http://localhost:8025/api/v2/search?kind=containing&query=28c9391f-25a5-4a8f-9035-7b8d5ac2d0f4" | jq .

それを結合テストのテストコードから呼び出すようにユーティリティを作ると次のようなコードになる。

import (
	"github.com/mailhog/data"
)

type mmSearchResult struct {
	Total int            `json:"total"`
	Count int            `json:"count"`
	Start int            `json:"start"`
	Items []data.Message `json:"items"`
}

func searchMail(
	host string, kind string, query string,
) (*mmSearchResult, error) {
	q := url.Values{}
	q.Set("kind", kind)
	q.Set("query", query)
	u := &url.URL{
		Scheme:   "http",
		Host:     host,
		Path:     "/api/v2/search",
		RawQuery: q.Encode(),
	}
	url := u.String()
	slog.Debug("mailhog search endpoint", "url", url)

	req, err := http.NewRequest("GET", url, nil)
	if err != nil {
		return nil, fmt.Errorf("http create new request error. err: %s", err)
	}
	res, err := http.DefaultClient.Do(req)
	if err != nil {
		return nil, fmt.Errorf("http request error. err: %s", err)
	}
	if res.StatusCode >= 400 {
		return nil, fmt.Errorf("returned response code is %d", res.StatusCode)
	}
	var r mmSearchResult
	if err := convertBody(res, &r); err != nil {
		return nil, fmt.Errorf("failed to convert: %s", err)
	}
	return &r, nil
}

歯医者

17時から歯科検診へ行ってきた。歯科検診をしてくれた今回のスタッフはおそらく初めてだったと思うが、手際がよくていつもよりもストレスが少なかった気がした。うちのチームのメンバーは朝方なので8時過ぎにはだいたいみんな始業し始める。なので、朝よりも夜にいない方がメンバーにとってよいだろうと考えて、朝一 (9時) に歯医者へ行くよりも最終 (17時) に行くようにしている。

pycamp ふりかえり

先週末の Python Boot Camp のふりかえり。ここまでがスタッフのお仕事なので一般的な kpt でイベントのふりかえりをした。仕事じゃないし、大きなトラブルもなかったし、参加者の評判 (アンケートの内容) もよかったので概ねよい内容だったと思う。テキストの改善点は直接 issue に追加してほしいと言われたので報告した。是非も含めてスタッフに判断してほしいので私が直すつもりはない。

• タプルとリストの違いの説明に辞書のキーになれることも追加する #219
• Windows 環境で普通に pip upgrade をすると環境が壊れる #220
• pip コマンドの説明で実際に存在するモジュールを書いてあると誤ってインストールしてしまう #221

0時に寝て何度か起きて4時に起きて仮眠して6時に起きた。あまり寝た気がしない。

OWASP のパスワードリセットのガイドライン

パスワードリセットの仕組みをメンバーに開発してもらっている。そのコードレビューが先週から白熱している。セキュリティが関連するので堅牢に作る必要があるのでここはあまり妥協せきない。お手伝い先のシニアエンジニアから独自設計で作るのではなく、最低限、世の中の一般的なガイドラインに従っているかを確認するために OWASP のガイドラインを紹介してくれた。これはパスワードリセットの仕組みをテストするための要項をあげている。

• Testing for Weak Password Change or Reset Functionalities

これをメンバーに読んでもらって理解して実装しろと言いたいところでもあるが、私自身、読んだことがないとレビューできないことに気付いて、これは私が読んだ上で既存の設計や実装を見直すべきだと判断して deepl を駆使しながらほとんどを読んでみた。たしかに読んでみていくつか抜け・漏れに気付いたり、うちのセキュリティポリシーとして意図的に緩和しているところも認識できたりして、結論から言って読んでよかったと思う。当初はパスワードリセットのために一時トークンを1つだけ使っていたのだけど、それも2つを別々の経路に送って、割符のように組み合わせて認証する仕組みに変更した。よりセキュアにするという意図では一時トークンも1つよりも2つの方がよいというのは概ね正しいと思う。

1時に寝て何度か起きて6時半に起きた。なんか喉が乾いて一晩で飲むヨーグルトを900mlを飲んでしまった。今日もコードレビューが多くて疲弊した。

新規メンバーの受け入れ調整

早ければ9月末辺りから参加すると言いながら、既存のお仕事の調整でまだ新規メンバーが参加していなかった。一方で定例会議やチーム勉強会にはその頃から参加していた。そろそろ既存のお仕事が落ち着くということで来週の月曜日から開発に参加することに決まった。これでうちのチームの常勤メンバーは私を含めて4人になった。私は3人のメンバーの面倒をみることになる。3人もいればチームとして出来ることが大きく増えるのではないかと期待している。キングダムに例えたら信が100人将になったぐらいの影響力か。とはいえ、若いメンバーが主体なのでまだまだ指導してスキルアップしてもらうことにはなるが、私のお仕事が遊撃よりも指導の方に工数を割くようになっているのかもしれない。この機会にオンボーディングのドキュメントも作ることにした。