0時に寝て何度か起きて7時過ぎに起きた。9時までにはオフィスへ行くつもりが、気が緩んで9時はまわっていたと思う。年末でだらけている。

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

この3ヶ月ほど 税理士さんとやり取り してきた懸念事項の共有または改善も含め、電子帳簿保存法 への対応の打ち合わせをしてきた。打ち合わせのため、姫路市にある税理士さんの事務所を訪問してきた。オンラインでできないわけではなかったが、1度も直接会ったことがなかったので、こちらの言い分や相手の言い分も気兼ねなく出し合う機会にしようと思って出掛けた。打ち合わせ後に一緒に晩ご飯を食べに行って、その後も2件飲み屋さんをはしごして、結果的には親睦を深めてお互いの考え方や人間性などを理解する機会になってよかったと思う。17時から22時まで飲み歩いてた。古い時代の人間関係では当たり前だったことが、いまどきの付き合いでは珍しいことかもしれない。

晩ご飯は プロ酒場 というお店を紹介してもらった。路地裏の隠れた場所にあって地元の人が行くお店って感じだった。「プロ」はプロフェッショナルではなく、労働者を指す プロレタリアート に由来するという。

あまり先方からはどういった運用をしたいという考えや既存のワークフローはないようで、ほぼこちらの言い分は通って改善へ向けての最初の切り口として収穫は大きかった。実際にそういった運用ができるかどうかはこれから徐々に実践して取り組んでいく。当社としてもこちらの要望だけを主張するつもりはなく、先方の状況や考えも聞いた上でお互いに合意できるところを探っていきましょうと伝えた。業務をうまくまわすために協調しましょうということは理解してもらえたのではないかと思う。

姫路駅の雰囲気

姫路駅の北側には姫路城がそびえている。駅を降りるとすぐに姫路城が目に入るようになっている。そして観光客向けのお店とアーケード街のお店も並んでいて、それほど人がいるわけではないけど活気がある。20分ほど駅から北側へ歩くと姫路城に辿り着く。

駅の南側はうってかわってオフィス街となっている。ビルが立ち並びお店などはあまりない。駅の南北で役割分担をしているような、おそらく都市計画でそういった整備が行われているのだと推測する。税理士さんの事務所まで、姫路駅から徒歩20分ぐらい歩いた。あらかじめ調べた上で歩いたわけだけど、それでもやや遠かった。体力が落ちていて駅から徒歩20分とか、普通には歩けないようになりつつあるのかもしれない。帰りはタクシーを使ったら運賃が1300円だった。三ノ宮から姫路まで JR で990円なのにこの距離で1300円なのかとか、いろいろ思うことがあるな。

0時に寝て4時に起きてアニメをみて5時半に寝て9時に起きた。午前中はだらだらしていた。

旅のしおりのたたき台作り

3月に予定している 開発合宿 イベントの打ち合わせを次の木曜日に行う。そのための資料作りをした。昨年の記録があるのでその内容を見返したり、写真を貼り付けたりしながら、昨年作った資料よりも詳細な「旅のしおり」を作ることができた。

• 1日目
• 2日目
• 3日目

しばらくは冬の城崎温泉の開発合宿を、うちの会社の年中行事として継続していきたい。

コワーキングの価値の考察

独りで活動する個人事業主やマイクロ法人の役員にとってコワーキングがもたらす価値は大きいのではないかと私は考えている。以前 リモートワークと相談相手 という記事を書いた。そのふりかえりや考察の中から 日記を書き続ける ことに決めた。それは思考の外在化を強制的に行わないと、私はすぐに劣化するということを身をもって理解した。ひとえに人間が弱いのだと思う。思考の外在化とは次になる。

• 書くこと
• 話すこと

これらの活動が減ることで思考が鈍化したり脳が退化したりする。書くことは日記で補えたが、話すことは相手がいないと成り立たない。顧問のはらさんに隔週で相談しているのもそうだし、カフーツさんのオンラインイベントに参加しているのもそうだし、開発合宿に社外の人たちを呼ぶのもその一環になる。そして、このことは会社員時代にあまり感じたことはなかった。それは会社員時代にはこれらの活動を伴うイベント、つまり会議だったり、報告だったり、同僚との雑談などが自然に日々の生活の中に含まれていたからだ。

無駄じゃなかったんやと思ったら次のシーンを思い出した。

初めて、成功したよ。800年か……全く、無駄な魔法だと恨んでさえいたが。ああ、意味はあったんだな。

意味のない無駄なことだと思いながらも長く続けていたことが、その意図をもって実施したかの如何に関わらず、なにかの役に立つことはあるし、なにごとも継続するに無駄なことはないという気付きでもある。古代の中国においても 鶏鳴狗盗 という故事がある。人それぞれに長く継続できていることがあるならそのことを大事にしたらよいと私は思う。それは継続した先にしかわからないこともある。

やや非科学的な仮説ではあるが、小林正観 という人物が「ありがとう」を唱えると幸せになるという仮説を提唱している。「ありがとう」を一万回となえると幸せになり、二万五千回となえると涙があふれだし、五万回となえると奇跡がおきる、もしくは年齢×一万回となえると第一段階の奇跡が起きるという。仮にこういった現象が本当に起きるのであれば、他者への感謝を述べる言葉から脳が影響を受けて、感謝の行動や考え方が身に付いて、現実の生活にも影響が出てくるのだろうと推測する。

晩ご飯食べて21時頃から横になっていた。なんか寒くてなにもやる気がしない。1時に寝て何度か起きて7時に起きた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日は議題を準備するのを忘れていて、ふりかえりをしながらフリートークのような雑談をした。

• 2023年ふりかえり

昨日の 組織論の動画 なども共有しながら課題管理の文脈でマネジメントやリーダーシップの原則として思うことを言語化していた。次のような価値観をメンバーにもってほしい。

• 常に人間は学ぶ
  • どのポジションの人も、どんな役割でも、人それぞれのペースで学ぶのは当たり前である
  • 組織に学ばない人がいると足を引っ張るようになってしまう
• 人間は時間とともに成長して変わっていく
  • 同じことを何年もずっとやり続ければよいという時代ではない
  • 成長することでやり方もやることも責任も変わっていく
• プロジェクトは一期一会
  • 人は学び成長することから同じプロジェクトを再現することは本当の意味でできない
  • そのときそのメンバーで、その知識や習熟度で取り組むプロジェクトはその人の人生において1度しかない
  • 本当の意味でプロジェクトマネジメントに再現性などないし、そのときの状況で最適解を考えて実践しないといけない

知の創造研究部会第63回

知の創造研究部会第63回 に参加した。内容は悪くなかったが、私が関心のあるテーマではなかった。

最初の30分ほど、会そのものの紹介やイベントの宣伝、登壇者の自己紹介が延々と続いて、ちょっと長過ぎてうんざりした。自分たちのことをちゃんと知ってもらった方が内容がわかりやすくなるというのはやや前時代的な考えだと私からは思えた。私がイベントに登壇するとき、ほとんど自己紹介を省いて本題へ入るようにしている。それはおっさんの経歴を多くの聴衆は関心がないというのもあるが、本題を聞きたいのに関係ない話しをされるのを私自身もしんどく思うようになったのがある。映画館で映画をみるとき開始前に他の映画の宣伝が10分ぐらいあるのをうんざりする気持ちと同じ。

知の創造部会 というクローズドな facebook グループがあると聞いたので参加申請した。翌日には承認されていた。今後はイベント情報などをここでチェックすればよいのかもしれない。

23時に寝て2時に起きて5時に起きて8時に起きた。税理士さんの件がもやもやしていてあまりよく眠れない。

ストレッチ

今週もとくに負荷のかかることがあったわけではないため、とくにどこも悪くなく、張りや疲労を感じることはなかった。トレーナーさんもどこも悪くないという前提の上で上半身の肩が前屈みになってしまっているために肩甲骨周りが硬くなりがちであるとアドバイスしてくれた。寒くなると上半身の硬さが目立つようになるのかな。いつも通りの体調管理の一環としてストレッチを受けた。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。

創立記念日

今日が会社の創立記念日。無事に4周年を迎えた。過去20年、3年以上1つの会社で働いたことがない私が自分の会社では4年を迎えられたことも少し感慨深い。今日は土曜日なので創立記念日が休日ではあるけれど、やはりオフィスでいろいろ作業をしている。

2年目に経営的に大きな失敗をやらかして、その反省もあるせいか、3年目は財務が安定してきた。この3月で 経営セーフティ共済 の掛金上限の800万円の積み立てを完了する。事例紹介 にも毎年1社新しい顧客が増えている。達人プログラマーではないが、毎年新しい顧客と取り引きをするというのもよいかもしれない。とはいえ、いまの取引先とのお仕事の契約が終了したら課題管理の研究や自社プロダクトの開発に取り組む。目安としては3年間を考えている。役員報酬をカットすれば財務的には5年はいける。意味もなく起業した私にとってはうちの会社は社会になにを還元するのかを問う期間として3-5年ぐらいを想定している。法人としてモラトリアムのようなものかもしれない。個人としても40代になって3年といった時間を自由に使えるというのはとても貴重な時間になるのではないかと考えている。自分で会社をやると年単位で時間を自由にできる。これだけでも起業する価値はあるのではないかと思う。

いまのお仕事でも課題管理の POC の1つとして実践している。想定通りと言えるほどの成果には至っていないが、時代背景や世の中の変化にも追随しながら私の頭の中にあるイメージと現実とのギャップを補正していく必要があるのかもしれない。

完璧ではないが、最善は尽くしている。うぬぼれるな、矢口

と赤坂先生に叱責されたい。

過去の創立記念日

• 3年目
• 2年目

23時に寝て2時に起きて6時に起きた。晩ご飯食べてから作業するつもりが、疲れて寝てしまった。今日は権限管理のバグ修正したり、昨日の mongodb の調査を継続していた。

テックブログ公開

先日 テックブログレビュー を終えていた記事を公開した。

• SvelteKit アプリケーションの組み込みへの考察

隔週の雑談

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

• テックブログ (↑) のふりかえり
• 日本ナレッジ・マネジメント学会の年次大会の所感
• 税理士さんと契約 して3ヶ月間やり取りした所感

1ヶ月に1-2件ほど折りにふれて税務相談をする機会があったりする。税理士さんとは chatwork でやり取りしている。これがストレスになってきたのではらさんに相談にのってもらった。はらさん曰く、税理士さんの普通と it 業界のうちらとは業務の取り組み方への姿勢がまったく異なるため、最初の1年はストレスや不満がたまるのはあるという。士業という資格によって独占的に保護された業務のせいか、顧客に寄り添った対応をしてくれるわけではなく、質問の背景や意図を汲んでくれなくて質問に回答を返して終わりといった、チャットなのにメールのような一問一答のようなやり取りになっている。さらに回答が意図した内容ではなくて、追加で質問や背景の説明をしても、すぐにレスポンスが返ってくることはなく、数時間たってから回答が1つ届き、それも期待したものじゃないとさらに質問して、さらに数時間といったやり取りで5-6往復するのに数日かかるのがざらにある。はらさんがいうには税理士さんの回答を得るのに1週間ぐらいかかったり、問い合わせを数日放置されるのも普通とのことらしい。

先方も複数の顧客を相手にサポートしていて、やり取りに時間がかかることそのものは理解できるが、チャットのやり取りがコンテキストを理解しているようにみえなくてコミュニケーションが成立していない。例えば、当社への税理士報酬の支払いの対応について問い合わせたら次のような回答が戻ってくるだけ。

報酬の額と消費税等の額が明確に区分されている場合には、その報酬の額のみを源泉徴収の対象とします。

こんなことはググればすぐに分かるし、私も顧問報酬は原則として源泉徴収することを知っている。その上で税理士さん事務所の、当社への顧問報酬の明細について尋ねているのにこういった回答が返ってくるだけ。

• インボイス制度開始後の報酬・料金等に対する源泉徴収

インボイス対応もあるため、請求書に明細を書いて pdf で送ってくださいと依頼して2日間返信なく放置されている。税理士さん事務所の顧問報酬の明細や請求書について尋ねても即日に返信がこないような状況になる。はらさんが言うには税理士さんの対応とはそんなもんらしい。チャットでやり取りしている意味がないし、こんなググればわかるレベルのやり取りしかできないなら解約も検討している。もう1つ懸念に思っているのは本人がチャットで回答していないのではないか？と考えている。チャットなのに1問1答でしか返信がこないし、コンテキストが伝わっていないと感じることも多々ある。とてもベテランの税理士さんが答えているとは思えないコミュニケーションの齟齬がある。

ちょっと調べてみると、税理士は日本税理士会連合会に登録する必要があり、税理士試験に合格しても登録していない場合は税理士としての独占業務を行うことができないらしい。また税理士事務所で働いている人の中には無資格職員もいて税務補助をしている可能性もあるという。必ずしも税理士資格がなければダメだというわけでもない。無資格職員でも経験を積んで税務に詳しい人もいると思う。一方でチャットでベテランの税理士のふりをして職員が回答しているのであれば、それはそれで信頼関係や偽証などの問題がある。そこら辺も聞いてみようと思う。次の記事では無資格職員が税務相談をしている事務所もあると書いてある。

• 税理士へ依頼したつもりが税理士でなかった

1時に寝て起きたか起きてないか覚えてない感じで6時に起きた。起きてちょっとゲームして気付いたら7時だった。

kit/vite アプリケーションのデバッグ

先週公開したテックブログ の続き。

vite アプリケーションのバックエンドインテグレーション の詳細を調査している。丸1日デバッグしていていくつか振る舞いがわかってきて、designer アプリケーションを作りたいという要件に対して、こうすればできるんじゃないかという仮説も立てられるようになった。いまやりたい要件は kit の ssr アプリケーションを埋め込みたい。これは要件に満たないが、kit の ssg アプリケーションならば static ディレクトリに置くだけで参照できるし、インポートパスさえ書き換えてやれば別の kit アプリに埋め込むこともできるのを確認した。意図した通りの振る舞い。

vite アプリケーションはビルドオプションで manifest.json を出力し、エントリーポイントやどのファイルがどのファイルをインポートしているかといった情報を管理している。sveltekit はこれらの manifest.json から rollup でバンドルするために manifest.js を生成している。厳密には、sveltekit では production ビルド向けのチューニングをしたビルドツールを adapter と呼び、vite のビルドをフックする場所に1つになっている。node.js サーバー向けに production ビルドするときは adapter-node を使う。この実装を読んでみると、vite がビルドした成果物に対して、再度 rollup でバンドルして成果物を作り直すといったことをしている。そして、vite の成果物 (manifest.json も含む) を抽象化したものが Builder となる。adapter は Builder のインスタンスを使ってビルドの成果物を制御できる。先の manifest.js もこのときに生成していて、rollup でバンドルするためのパラメーターの1つとして使っているようにみえる。しかし、rollup のドキュメントをみても直接的に manifest.js の説明はなく、rollup の拡張の仕組みで manifest.js を作っているというよりは、sveltekit の要件によるもののようにもみえる。ここの背景はまだよくわからない。

私はフロントエンドのことが全然わからないのでライブラリのソースコードを読みながら、ドキュメントとあわせて調べて、1つずつ理解を深めていくというアプローチで進めている。こういった調査のやり方もメンバーへ伝えていければと考えている。

小規模企業共済オンライン手続きポータル

2021年度から小規模企業共済 に加入している。今年から掛け金を7万円/月に変更した。年間で84万円の所得控除となる。ちょうど2023年9月1日からポータルサイトが作成されたらしい。いずれマイナポータルと紐付くのかもしれない。

• 「オンライン手続きポータル」を公開しました

利用登録しようと思って、メールアドレスを登録しようとしたら会社のメールアドレスはなぜかバリデーションエラーになって gmail のアドレスなら登録できた。その後も氏名の半角カナ入力を強制されたりしながら、マイナンバーカードを読み取って認証チェックして利用登録の申請はできた。しかし、自動で本登録されるわけではなく、おそらく申請内容が先方に届いてなんらかの運用があって本登録されるみたい。オンラインポータルのホームでも半角カナを使っていたり、<title> タグには「マイナ手続きポータル」とあったり、申請しただけでいくつも不備がわかるようなひどいサイトになっている。2023年にまともな開発者が作ったサイトとは思えない。デジタル庁に作り直してもらった方がよいと思う。

• 小規模企業共済ｵﾝﾗｲﾝ手続きﾎﾟｰﾀﾙ

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年体温計を使わないでいると、電源ボタンの位置すら忘れていた。イメージとしては眼鏡をおでこにかけて、眼鏡がないと探している人みたいな失敗。日々の記憶もほとんど覚えていないような生活ではあるけれど、体温計の使い方を忘れるみたいなこともあるんやと実感した。自分もそういう失敗をするのだから他者にも優しくなろうと思えた。

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

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

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

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

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

• 利用プランの変更

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

• 税理士の守秘義務

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

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

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

アーキテクチャの再考

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

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

1時に寝て3時頃に吐き気で起きて1時間ぐらい苦しんでた。久しぶりにやばかった。その後なんとか寝て7時半に起きた。

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

うちの会社のイベントとして毎年ワーケーション (開発合宿) をやろうかと考えている。コワーキングやコミュニティの延長上でワーケーションを行うわけだが、いくらかうちの会社の持ち出しで費用負担してよいと考えている。しかし、そのときの支出はどういった建付けで経費として扱えるのかどうか、私は税理士ではないのでよくわかっていない。そういったことを相談するために税理士さんに顧問になってもらおうと考えている。うちから税理士さんへの要件としては freee のデータを正として扱ってくれればそれでいいかな。

また2021年度は赤字決算になったので2022年度に 法人税の欠損金の繰り戻し還付 を行った。このお金を2022年度に計上していないため、その分の金額が資産のマイナスとして2023年度の決算に残ってしまっている。法人税の支払いは正しいのだが、還付金を2023年度に雑収入として登録するか、2022年度に遡って未計上の金額を登録するかのどちらかで訂正しないといけない。過去の法人決算の訂正自体も行う仕組みはあるので手続きするだけだが、それも手間暇がかかるのでついでに税理士さんにやってもらうと考えている。

• 税理士・会計士にfreeeの情報を共有する

会計システムに freee を使っているので freee さんの税理士紹介サービスを使って選定する。3事務所ピックアップしてくれたので順番に打ち合わせしていく。今日はその最初の税理事務所の方と打ち合わせした。話した感覚でうちの会社の考え方や規模にあった税理士さんだったのでこの方でいいんじゃないかとも思っているけれど、せっかく他の事務所もピックアップしてくれたので他の税理士さんの話も来週また聞いてみる。

コードレビュー

まる一日コードレビューをしていた。私もマージリクエストを投げていてレビューしてもらいつつ、メンバーのコードレビューも順番にやっていった。その中で smtp の仕様を把握しておく必要があっていくつかシニアエンジニアの方からもアドバイスをもらって、私もそうだったんだと勉強していた。メールヘッダーのエンコーディング、昔は覚えていたけど、ずっとメールを送るコードを書いてなかったので私も忘れてしまっていた。こういうことをさらっと指摘できるのがシニアエンジニアのすごいところ。

• sendmail コマンドによるメール発信 - Postfix Advent Calendar 2014 - ダメ出し Blog

go だと標準ライブラリに mime パッケージがある。mime パッケージを使って件名を utf-8 でエンコーディングされた文字列で指定すると次のようになる。q エンコーディングと b エンコーディングの2種類がある。b エンコーディングの方がデータ量が減ってよさそう。

fmt.Println("Subject: " + mime.QEncoding.Encode("utf-8", "テスト"))
fmt.Println("Subject: " + mime.BEncoding.Encode("utf-8", "テスト"))

Subject: =?utf-8?q?=E3=83=86=E3=82=B9=E3=83=88?=
Subject: =?UTF-8?b?44OG44K544OI?=

• https://go.dev/play/p/zQjMMp17bKf