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人将になったぐらいの影響力か。とはいえ、若いメンバーが主体なのでまだまだ指導してスキルアップしてもらうことにはなるが、私のお仕事が遊撃よりも指導の方に工数を割くようになっているのかもしれない。この機会にオンボーディングのドキュメントも作ることにした。

0時に寝て何度か起きて6時に起きた。夜にストレッチを受けて寝たせいか、わりとよく眠れた。お仕事はコードレビューを中心に、既存のよくないところをリファクタリングして品質や堅牢性を高めることをしていた。

税理士さんと契約についての打ち合わせ

税理士さん探し の続き。3人の税理士さんと打ち合わせをして、その中で1人の税理士さんを選定した。ようやく、うちの会社も税理士さんに税務をお願いできるようになった。最初の打ち合わせを30分ほど行った。うちは会計システムに freee を使っているので freee の操作ができることを要件に探した。freee には税理士さんをアドバイザーとして招待する仕組みがあって、それを使って登録すると税理士さんがうちの会社の会計データを読み書きできるようになるという。まずはその登録作業を行った。他にも過去の決算書と決算申告のデータを共有したり、うちの会社の特徴や課題管理のやり方なども情報共有した。課題管理にも関心をもってくれたのでうちの会社の jira にも招待して、できれば、税理士さんもうちの会社の会計作業については jira で課題管理してくれると嬉しい。それは難しいかもだけど。

税理士さんが言うには、税理士会が情報共有のツールとして dropbox を推奨しているらしい。ファイルを情報共有するために dropbox のフォルダ共有してくれると助かるという。うちは google workspace を使っているので必然的に google drive が望ましいのだけど、それは税理士さんにあわせて dropbox にした。私の感覚だと、dropbox よりは google の方がセキュリティもサービスも信頼できてよいのだけど、そこは税理士会の慣習に従うことにした。

税理士さんは社内では slack を、お客さん向けには chatwork を使っているという。私は chatwork 使ったことがなかったのでこの機会に使うことにしてみた。これは税理士さん側から私を招待してもらって使えるようにした。どうやらフリープランで使ってみるみたい。chatwork にもフリープランあったんやと知った。

• 利用プランの変更

契約についてどうしましょう？と相談したところ、どっちでもよいと言う。税理士さんの守秘義務は法律で定められていて、これに違反すると懲戒処分に加えて、刑事罰もうけるような、強力なものらしい。したがって、税理士さんが契約書を企業と交わさなくても税務には問題がないらしい。一方で顧問契約を1年は継続してほしいといったときに期間を契約書に明記して契約するといったケースもあるらしい。先方がいらないと言っていたのでひとまず契約書なしで進めることにしてみる。

• 税理士の守秘義務

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

田んぼ

7時からトラクターで田んぼを耕す。昨日の夜、普通に雨が降っていたので今日は田んぼ無理かなと諦めつつ、朝起きたら雨もあがっていて、田んぼもそれほど水浸しになってなかったので予定通りで耕作できた。昨日、刈った草を焼いてあったのでスペースが空いたところをトラクターで耕していく。全体のうちの半分ぐらいを耕した。玉ねぎとか、なにか野菜をまた植えるらしい。

トラクターは大きな機械なので田んぼの隅などはうまく耕せないし、畝を作るときの縦と横の相反する畝などは作れない。畝を作る目的の1つに排水がある。雨が降ったときに水が田んぼから流れていくように道を作らないといけない。トラクターで大まかに作った後に鍬で調整していく。私はこの鍬仕事が苦手でいつも親にやってもらうのだけど、30分だけ (これが限界) 手伝うようにしている。中央の水を抜くための谷を開通させるところだけ30分ほど作業した。

ストレッチ

お昼過ぎに帰ってきてそのまま休んでいて夜にストレッチだけ行ってきた。夜のストレッチはいつもあまり調子よくないが、鍬仕事を少しやった分の筋肉痛などをほぐした感じ。今日の開脚幅は開始前153cmで、ストレッチ後155cmだった。

0時に寝て2時に起きて少し仮眠して5時に起きた。朝から出かける準備をして6時過ぎには出発した。神戸から実家まで約80kmの距離を、早朝だと高速道路が空いているのもあって1時間弱といったところ。

軽トラのエンジンをかける

車のバッテリーがあがってしまったときに使う ジャンプスターター を昨年末に購入していた。また軽トラのバッテリーがあがってしまったようで、今回は母に使い方を教えながらエンジンをかけてみた。バッテリーにつなぐケーブルに boost ボタンがあってそれを押下してエンジンをかけるだけ。これは本当に買ってよかった。たまにしか農業しないような家の軽トラ向けにあると安心できる。軽トラのエンジンがかかったら1時間ほど走ってくればそれで元のバッテリーは回復する。

草焼き

実家に着いたのが7時過ぎで朝ご飯を食べて、まだ時間があったので草焼きを手伝うことにした。すでに刈って干した草が集めてあったのでそれを火にかけて番をする。以前にも草焼きをした経験 があったので注意を払いながら行う。母が言うには、最近でも淡路島の人で草焼きをしていて2人亡くなっているという。おそらく煙に巻かれて一酸化炭素中毒で気を失ってしまったんだと推測する。干し草は一気に燃え上がるので青い草と干し草を調整ながら火の勢いを制御する。あとは表面だけ燃えるので内側も燃えるように混ぜ返したり空気を送ったりといった調整も必要になる。火の制御は難しい。1時間ほどやっていた。

Python Boot Camp

今日の目的は次のイベントに TA として参加してきた。

• Python Boot Camp in 徳島2nd

現地11時集合だったものの、早めに実家を出たので10時半頃に着いてしまった。他のスタッフもその後すぐに合流して10時50分には全員が揃った。私は知り合いのスタッフがほとんどいなかったので挨拶したりしていた。だいたいスタッフは次のような構成だった。

• 講師: 1人
• 現地スタッフ: 1人
• TA: 3人
• 会場関係者: 2人

次の段取りでほぼこの通りうまくスケジュールを進捗できたと思う。

11:00 スタッフTA講師が集合
11:00-11:30 準備
11:30-12:30 スタッフTA講師でランチ
12:30 開場
13:00 PyCamp開始
17:00 PyCamp終了
17:30 撤収完了

お昼に食べた「鳴門うどん」もひやむぎ程度のサイズの麺をにゅうめんのような食感で食べるものだった。身近に住んでいてこれは知らなかった。おいしかった。

boot camp イベントも順調に進捗して受講者も喜んでいたようだったのでよかった。久しぶりにこういったイベントに参加すると、プログラミングを始めたばかりの気持ちなどを思い出してよかったと思う。いまはお仕事でプログラミングの随分と高度なことをマネージャーとして教えているわけだけど、簡単なコードが動いておもしろいといった気持ちがあることも大事だと思う。懇親会も出て、その後、スタッフ同士での反省会もやって、21時前には現地を解散して21時20分に実家に戻った。

0時に寝て3時に起きて5時ぐらいまでネットで遊んでて6時半に起きた。昨日の夜に洗濯しようと思って忘れていたので朝から洗濯した。

隔週の雑談

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

• 税理士さんとの打ち合わせのふりかえり
• 昔お手伝いした会社の開発体制の話
• 新しいチーム勉強会 の導入

3人の税理士さんと打ち合わせしてみて最終的に顧問契約をお願いする方を決めた。話してみてやり取りした雰囲気だと、その税理士さんもスキルやこちらの要件対応については全く問題なさそうに思えた。あとは報酬とうちの会社の規模などを考慮して選択した。

昔お手伝いした会社で2年経ってちょっと相談にのってほしいという打ち合わせをした。私がいた2年前と開発体制はまったく変わってなくて、未だにテックリードがほぼ1人で開発している状況らしい。私が辞めてから以降も何人かは開発者が入っては辞めを繰り返しているのだと推測する。私も2度とその開発者と一緒に働きたくないと思うぐらいには信頼してなくて、開発者が引く手あまたな世の中の状況において、人間として信頼されないリーダーって致命的なんだなということを改めて実感した。おそらくテックリードを追放しない限り、あの開発体制 (と言ってもほぼ独り開発) は何も変わらないのだろうと思う。

oauth 2.0 で認証して google の smtp サーバーを使う

昨日の続き 。

リフレッシュトークンを使って取得したアクセストークンで smtp の AUTH コマンドで XOAUTH2 で認証すればよい。仕様は次のドキュメントに書いてある。

• Home > Google Workspace > Gmail > Guides > OAuth 2.0 Mechanism
• RFC 7628 - A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth 日本語訳

なぜか go の標準ライブラリの net/smtp には Plain と CRAM-MD5 の2つしか実装されていない。AUTH コマンドの実装は smtp.Auth インターフェースで定義されている。

type Auth interface {
	Start(server *ServerInfo) (proto string, toServer []byte, err error)
	Next(fromServer []byte, more bool) (toServer []byte, err error)
}

正常系の雑な実装だとこんな感じ。

type oauth2 struct {
	user        string
	tokenType   string
	accessToken string
}

func (o *oauth2) Start(server *smtp.ServerInfo) (string, []byte, error) {
	if !server.TLS {
		return "", nil, fmt.Errorf("need tls")
	}
	resp := []byte("user=" + o.user "\001auth=" + o.tokenType  + " " + o.accessToken + "\001\001")
	return "XOAUTH2", resp, nil
}

func (o *oauth2) Next(fromServer []byte, more bool) ([]byte, error) {
	if more {
		return nil, errors.New("unexpected server challenge")
	}
	return nil, nil
}

ググるとサンプルコードを実装している人たちがちらほらいるので、そのうち標準ライブラリに誰か実装してくれると思う。

• https://github.com/jacobalberty/smtpoauth2

go 本体に pr を送るチャンスでもあるけど、Contribution Guide を少し眺めて大変そうと思って、いまそこまでのモチベーションないなって感じ。

0時に寝て何度か起きて6時に起きた。昨日、凡人が天才に挑むという状況で、キングダムの 蒙驁 将軍が廉頗に挑むみたいな状況を思い出して見返していた。史実では蒙驁が魏を攻めて東郡を置いたというのは事実だが、廉頗と戦ったという記録はなく、おそらくは蒙驁と廉頗に因縁があって雪辱戦としたというのはキングダムの創作だろうと推測される。

oauth 2.0 で認証して google の smtp サーバーを使う

google さんの smtp.gmail.com の smtp サーバーを使ってメールを送信したい。

• Turning off less secure app access to G Suite accounts
• Beginning September 30, 2024: third-party apps that use only a password to access Google Accounts and Google Sync will no longer be supported

2019年にパスワード認証は廃止するので oauth 2.0 へ移行してくださいといった、最初のアナウンスが行われて、もうできないかと思ったら2024年9月30日に完全廃止するのかな？まだパスワード認証は動くかもしれない。一方で oauth 2.0 へ移行しないといけないのでその調査をメンバーにしてもらっていた。結局、途中からは私も本気になって調べていた。

oauth 2.0 で認証してアクセストークンとリフレッシュトークンを取得するためのサンプルコードとして OAuth2DotPyRunThrough が用意されている。このトークンを取得するときに callback の url にユーザーが明示的にアクセスして同意する必要がある。ここで得たアクセストークンは1時間で有効期限がきれる。しかし、リフレッシュトークンはユーザーが revoke しない限りは永続的に使えるそうで、このリフレッシュトークンを使って必要なときにアクセストークンを取得するというのが google さんの oauth 2.0 のアプリケーションの運用になるみたい。つまりリフレッシュトークンをアプリケーション側で管理することでアクセストークンは何度でも取得できる。

OAuth 2.0 Mechanism によると、取得したアクセストークンを使って XOAUTH2 という smtp の認証方式で認証すれば smtp サーバーに対して smtp でメールを送信できる。gmail 以外でメールをやり取りする機会がなくなって数年たつ。smtp の仕組みとか、まったく忘れてしまって関心もない。たったこれだけなんだけど、右往左往してあちこち調べることになった。ややこしいのは google のクラウド api 経由でメールを送ることもできて、そのやり方と混同するとまったく違う方向に行ってしまう。そこだけ注意。

0時に寝て4時ぐらいに起きてだらだらして7時半に起きた。やっぱりあまり眠れない。

ステートレスな認証という概念

次の開発フェーズが始まっていて、ちょっと時間が経ってしまったが、前開発フェーズのお披露目的な製品紹介をお手伝い先の全社向けに行った。主には直近の開発フェーズで追加した機能などを紹介した。その過程で新たに認証の仕組みを追加して jwt で認証するといった話しをしたところ、それはステートレスなのかどうかといった質問が出た。セキュリティを考慮して、アーキテクチャ的にフロントエンドの認証と api サーバーの認証は分けて実装しているのと、そのために仕組みも複雑になっているのだけど、ステートレスという言葉が指す意図を私がよくわかっていなくて、うまく説明できなかった。説明を終えた後にアーキテクチャのイメージ図と一緒に補足をしながらやり取りして次の記事を教えてもらった。

• “JWT=ステートレス"から一歩踏み出すための考え方

jwt は暗号化の技術で認証する仕組みなので有効期限が切れるまでは有効なアクセストークンとなる。そのため、jwt のみだとログアウトという概念はないため、そこをどうしているのか？という質問だった。フロントエンド／api サーバーともに session をオンメモリで保持して、ログインしたユーザーを管理しているため、ログアウトしたら session からレコードを削除することで有効な jwt のアクセストークンが来ても認証エラーにしてしまうことでステートをもった認証方式を実現している。とくまる先生が次のように説明しているところ。

「セッションIDをJWTに内包する」 という考え方です。

うちはこれをセッション ID ではなくユーザー名でやっている。とくに難しいことをやっているわけではなく、普通に実装したらそんな感じかな？と考えていたが、jwt = ステートレス認証だと思い込んでいる人たちがいるから ストートレスな認証 というキーワードが出てきたんだなと理解できた。最近のトレンドとしてはログアウトで jwt のアクセストークンを無効にできないと脆弱性と指摘される可能性がありそうとも書いてある。

ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど)

私はアーキテクチャ的にブラウザに api サーバーのアクセストークンをみせないというところに注力して認証機能の開発をサポートしていた。それ自体も間違っていないとは思うけど、今回の質問はその工夫とは異なるところの質問だった。認証は難しい。

0時に寝て何度か起きて7時過ぎに起きた。眠れたような、そうじゃないようなよく分からない起き方をした。お昼ご飯を食べる間もなく、打ち合わせとコードレビューで1日を終えた。連休明けでよい慣らしになった。

税理士さんとの打ち合わせ2

税理士さん探し の続き。今回話した方は公認会計士だった。監査ができるのが公認会計士で、税務の申告ができるのが税理士という役割の違いになる。会計監査も含めてチェックしてほしかったら公認会計士さんにお願いするといった役割分担になるかもしれない。話してみて、若くて理路整然として悪い印象はなにもなかったのだけど、逆にこの人がうちの会社の会計／税務を親身にやってくれそうにもみえなかったし、ホームページの事業内容をみても公認会計士だから税務のビジネスだけではなく、もっと大きな会計のお仕事の方がを目指しているようにもみえた。同じ質問をして、前回の税理士さんの回答の違いなども考慮しながら選定の判断材料にはなるなと思いながらやり取りしていた。選択する側の打ち合わせはおもしろい。

アーキテクチャの再考

お手伝いしているシステム開発で、私の中ではもうアーキテクチャは固まったかな？と考えていたのが、お客さんと話していて、さらなる要件や展望を聞いているとそうじゃなかったことに気付いた。どうやら最初の実装としてはいまのアーキテクチャを堅牢に作って、その次の要件として待っていてくれたようにみえる。

私の認識を正す意味も含めて、さらにお客さんの要件や世の中の競合製品に対して競争力をもつにはどうするかといった視点をざっくばらんに雑談した。もう1段階アーキテクチャを見直す必要があるなと思えた。開発に着手して今月末でちょうど1年が経つ。これまで大きなアーキテクチャの変更もなく、順調に開発は進んできたものの、ここらで見直しやズレの補正が必要になってきてもなんらおかしくはない。いまの開発フェーズでは対応しないが、次の開発フェーズに向けてのアイディアの1つとしてアーキテクチャの再考が必要なことを認識した。