Posts for: #Tax

確定申告の新しい合わせ技

2時に寝て6時半に起きた。いつも通りのサイクル。寝る前と起きた後に体重を測っていると寝た後に体重が少し減ることがわかった。寝ている間の減量 でも、寝ているときに筋肉増強と脂肪燃焼の代謝が起こっているらしくて睡眠時間を確保することは重要にみえる。

今日の運動は腕立て,スクワット,散歩をした。統計を 運動の記録 にまとめる。

2023年度の個人の確定申告2

先日の書類作成の続き 。さとふるで「寄付金控除に関する証明書」の電子データを申請していた。サイトには2日かかるとあったけど、おそらく翌日には作成完了していたと思う。この xml データを freee で取り込んで確定申告書類を作成する。あとは国境なき医師団への寄付だけ。認定 NPO 団体は 神戸市の条例指定寄附金 として申請すればいいのかなと思う。これで金額を確定してそのまま電子申告を行った。

電子申告したら、電子申告に漏れた書類を別途提出するためのシートがあって、そこには電子申告に関する情報が記載されているので、そのシートと一緒に紙の書類を提出する。午後から近所の確定申告特別会場へ行って提出してきた。提出したものは次の書類になる。

  • 電子申告に関する情報が記載されたシート
  • 認定 NPO 団体への寄付の紙の領収書

初めてだったので受付の担当者にあれやこれやを質問しながら、とくに問題なくそのまま提出できた。念のため、小規模企業共済の掛金控除証明書ももっていたので、この書類も提出した方がよいか質問してみた。これは不要だという。小規模企業共済もマイナポータルで紐付いているので私のマイナンバーから支払履歴を確認できるはず。デジタル庁がよいお仕事をしているのか、確定申告がどんどん電子化されていって楽になっていく。これはこれで毎年楽しみになってきた。

今回の確定申告で電子申告 + 紙の領収書の合わせ技パターンを学習した。

知の創造研究部会

第64回知の創造研究部会 に参加した。冒頭に主催から挨拶があって、このイベントはもう17年やっているらしい。ナレッジマネジメント、知の創造、共創といったものがテーマ、積極的に事例なども紹介している。

18:00~19:30 第一部: やさしいビジネススクール 中川功一 学長の講演

中川先生のやさしいビジネス研究 で youtuber もやっているらしい。話しもプレゼンテーションも上手くてわかりやすかった。ディスラプト (disrupt) とは非連続的な変化、まったく別の視点から創造的破壊を行うことを指す。体制側からはネガティブな言葉のように聞こえるが、必ずしもそうではない。ロン・アドナー著のエコシステムディスラプションの紹介されていた。中川氏が監修しているらしい。

いまのビジネスは単体の製品で行っているわけではない。複数の製品群でイノベーションを起こしている。それをエコシステムと呼んでいる。価値軸の転換をもたらすものが云々。こういった製品の組み合わせが社会的に何を意味しているのか、背景にある潮流を見抜く必要がある。グレタさんのような人をスポンサーしたり投資したりするのはなぜか?どんな方法であれ、ゲームのルールを変更すれば、競争の優位劣位はひっくり返る。世界の企業はいまゲームチェンジを争っている。エコシステムによるビジネスを一般化すると、ゲームチェンジさえ成し遂げればよい。しかし、日本の企業はゲームチェンジが苦手ではないか?

19:35~20:35 第二部: 細野一雄氏の研究書出版講演

sier で定年退職した著者がシニア層 (年配の人たち) が it 業界でどうやって活躍していくか、もしくはシニア層は残りの時間をどのように働いていくかといったことがテーマのお話だった。細野氏の博士論文を一般人向け?に読みやすく書籍にして出版もしている。自費出版ではないそうだが、初版500部と話されていたのでよく出版できたなと思ってしまった。

私の関心事に近いテーマではあるが、私の関心は第一線を離れたシニアの人たちが若い人にどう技術継承していくかといったことがテーマではない。技術的にも若い人より高いレベルにあるシニア層から若い人たちがどう技術継承していくかに関心がある。会社から厄介者扱いされるような元気のないシニア層に関心はない。シニアは最新の技術に付いていけないといった姿勢で話していて、私の周りにいる同年代や年配の人たちは、一般の若い人よりもずっと高いレベルで働いているのになと思って内容に違和感が多かった。sier で普通に働く人たちの業務と oss の世界で活躍している開発者と比較するのは酷なのかもしれない。

致命的バグをみつけた

2時頃に寝て5時過ぎに起きた。お風呂に入るときに fitbit を外して、その後付けるの忘れて寝てしまったから睡眠時間を計測できなかった。

今日の運動はレッグレイズ(椅子),腹筋ローラー,腕立て,スクワットをした。統計を 運動の記録 にまとめる。

agent の致命的なバグ

先週から QA テストをしていて agent の致命的なバグに気付いた。もともとあった java 製の agent から私が設計して作り直した go 製の agent になる。ldap エントリーの更新リクエストのテストツール を作ったことでシビアなタイミングによるバグを検出できた。

ツールを使ってテストしていて、成功するはずのリクエストが失敗して、ログを調査しながらデバッグしていた。ldap エントリーを扱う難しさの1つに、ldap サーバーはエントリー間の依存関係やデータの整合性といったものを検証しない。そういった用途はアプリケーションの役割であって、ldap プロトコルはあくまで id を管理することに特化したものという役割分担になっているのだと推測する。そうすると、(open) ldap サーバーへ登録できたエントリーが次の agent や api サーバーといったアプリケーションのレイヤーでエラーになることがある。このとき、ldap サーバーではエラーが発生していないため、直接的なエラーを検知することができなくて、デバッグや調査に時間がかかる。

agent の実装として、ユーザーエントリのストリームとグループエントリーのストリームの2つに分割して、非同期にそれぞれのエントリーを id 連携する設計にしていた。というのは、ldap エントリーにはユーザーやグループといった概念は原則として存在しない。そのエントリーがユーザーなのか、グループなのかはアプリケーションが判断している。アプリケーションの用途としてはこの2つを明確にわけないと不便なことから、ワークアラウンドもしくは実務的な解決策として検索するときのフィルターと base dn で管理するようにしていた。そして、これらをそれぞれ別のストリームとして扱うよう、私が設計していた。このことがタイミングによってはユーザーエントリーとグループエントリーに依存関係がある場合、データの整合性を保証できないことに気付いた。なぜならば、ユーザーエントリーとグループエントリーそれぞれ非同期/並行に処理されてしまうから。

結論としては、ldap サーバーからエントリーの更新の順序を保証するには1つのストリームを subscribe しないといけない。そして、ストリームから取り出したエントリーがユーザーなのか、グループなのかはアプリケーションが判別しないといけない。テストツールを作ったことでシビアなバグも検出できた。

定額減税

定額減税 特設サイト が公開されたらしいというニュースをあちこちでみつける。従業員の税金が安くなるので経営者としての私がなにかしないといけないと思っているけれども、まだ何をしていいのかよくわかっていない。時間をみつけて調べないといけない。税制が変わるとこういった事務手続きが突発的に入ってくるのがマイクロ法人の面倒なところ。

午後半休と西へ南へ

3時頃に寝て4時半に起きて7時半に起きた。いろいろやっていたら眠れなかった。

今日の筋トレは腕立て:20x1をした。午後半休で出掛けて実家へ寄って疲れたので休トレーニング日にした。

家族信託の契約書の読み合わせ

前回の打ち合わせ を経て、弁護士さんと三井住友信託銀行の担当者との契約書レビューを行い、契約書の叩き台が出来上がってきた。

午後半休をとって明石市の弁護士さんの事務所へ母と姉と私の3人で訪問してきた。目的は契約書の読み合わせで内容を確認しつつ、この契約は基本的に1度作ったら母が亡くなるまで10年や20年といった長期間に渡って効力をもつため、3人の利害関係者が本当に契約に合意しているかどうかの最終確認を弁護士さんが確認するという意図も含まれていたように思う。私の考えとしても姉はいまも今後も基本的に関わらないため、母に不利な契約の建付けをしているわけではないことを確認してもらう意図もあった。

母の財産を私 (と姉) が管理するという目的であり、母から私に必要なお金の送金を依頼するという形になる。母自身はその財産を自由に扱うことができない。母から私が依頼を受けて、契約内容の範疇で正当であれば、私が信託銀行の口座から母の口座へ振り込む。その際に大きなお金であれば、信託銀行の担当者から私に監査が入る。必要に応じて見積書や注文書などを求められるかもしれない。私は信託報酬として3万円/月を受け取る。年間で36万円になる。この金額は一般的な相場になる。信託報酬は生前贈与の代替として機能する。私が急死したり、病傷で入院して管理できなくなれば姉が引き継ぐ。

現時点において家族信託における資産の運用手段として NISA や投資信託は不可であるという。将来的に解禁される可能性はある。将来を見越して契約書に抽象的な表現で一応書いておくという話しにはなっているが、それを書いておいたところで将来 NISA や投資信託が容認されたとしても具体的な内容がないからダメだと信託銀行の担当者から拒否される可能性は高いとのこと。私の意図としては財産の一部を NISA の投資上限である360万円/年に追加していきたい。いまのところ、他の投資運用を考えるのが面倒でもあるので、NISA がダメならなにもせず預金として置いておくだけになるのかもしれない。

契約書を読み合わせしていておもしろかったのが、信託銀行の口座からの出金を私の口座に入れるのは不可だという。それが建て替えであっても。必ず母の口座、または請求者の口座でないといけないという。たとえば家が老朽化して新築し直したとしたら、信託銀行の担当者が工務店や建築会社の担当者とやり取りして直接支払ってくれるという。

この後の流れとして、作成した契約書を公証役場へ送り、弁護士さんと母と一緒に公証役場へ行く必要がある。そして公証人の前で契約書を作る。このときに公証人の前で母が契約内容の説明を求められる可能性もあるとのこと。契約書の手続きを完了したら私が三井住友信託銀行へ行って口座を開設する。口座を開設したら弁護士さんへ連絡して、父の遺産 (母の相続分) をその口座へ振り込むといった流れになる。

送迎とコワーキングスペースの荷物運び

明石市で打ち合わせを終えて、そのまま母と姉を実家まで送って帰った。その際にコワーキングスペースで使う小物や家具なども一緒に運んで離れのスペースに設置した。ハンガーラック を組み立てるのに少し時間がかかった。一通りの荷物運びを終えたらそのまま神戸まで戻ってきた。実家に泊まってもよかったが、週の中日だし、お仕事も溜まっているし、他にもいろいろある。20時半には神戸に戻ってきていたものの、あまり寝ていなかったせいか、眠気と疲労でそのまま寝てしまった。

ダブル掃除

0時に寝て3時に起きてちょっとネットみたりしてまた寝て7時に起きた。

今日の筋トレは腹筋:10x2,スクワット20x1をした。

ストレッチ

筋トレの疲労がたまっているのかもしれないが、今日も太ももの後ろの筋がかなり張っていた。胸筋もやや張りがあったように感じた。トレーナーさんによると、筋トレした後に使ったところはストレッチして伸ばした方がよいという。今日の開脚幅は開始前153cmで、ストレッチ後156cmだった。先週とほぼ同じ。

筋トレを継続できているのでトレーナーさんにいろいろ聞いてみた。

  • 筋トレメニューに慣れてきたら強度をあげる?回数を増やす?
    • 回数を増やした方がよい
    • 負荷をかけてしんどくなるとフォームが崩れて適切なトレーニングではなくなる懸念がある
  • 種別をもう1つ増やすなら何がよいか?
    • 背筋がいいんじゃないか
  • 筋トレを毎日やるのはどうか?
    • 大きな筋肉を使うトレーニングは2-3日休みを入れながらやった方がよい
    • 小さな筋肉なら毎日でも構わない
    • 私がやっている筋トレは10分でできるようなレベルなので毎日でよいだろう

電子帳簿保存法対応の事務処理規定と運用ガイドラインの策定

税理士さんに 電子帳簿保存法対応の事務処理規定の叩き台 をレビューしていただいた内容を規定に反映した。念のため、再レビューしてもらうが、これで完了とする予定。規定から実際の運用のためにガイドラインを作る。運用ガイドラインは notion にまとめる。

あまり notion を使う気になれないのは、課題管理システムをメインに使っているから wiki もそこにセットで付いていてほしいという願望がある。うちは jira cloud を使っているので本当は atlassian の wiki プロダクトを使いたいところだが confluence が使いにくいから使っていない。atlassian は confluence とは別にもっと軽量でシンプルな wiki プロダクトを別途提供すればよいのでないかとすら思う。一方で esa や notion のような、wiki 単体のサービスを活用するのは課題管理システムとの連携において不便なように思えた。だから notion は最近プロジェクト管理の方に手を広げているのかもしれない。 github や gitlab のように、課題管理システムと wiki はとても相性がよいのでツールセットで提供するのがよいと思う。今後のプロダクト構想の中で wiki を考えていなかったけれど、アプリケーション間連携という視点から考察してもよいかもしれない。

sns などで電子帳簿保存法対応がすごく大変といったメッセージをたまにみかける。この法律は電子取り引き (請求書や領収書を pdf ベースでやり取りするサービスなど) に対応するもので紙の請求書や領収書でやり取りしている事業者には影響はない。しかし、昨今取り引きが電子化されていく流れでもあるため、電子取り引きはまったくないという事業者もあまり存在しないのではないかと思う。そして、これまではそういった事業者が取り引きの証拠となる電子データを消失してしまっても法律から言及できないという状態だった。電子取り引きはデータしかその取り引きがあったことを証明する証拠がないのにそのデータを消失して OK なわけないよね?というのが本来の電子帳簿保存法の目的になる。

おそらくパソコンやシステムでデータ管理していない事業者にとっては取引データ保存の仕組みや運用を新規構築する必要があってコスト増になって大変なのだと推測する。しかし、私のような、最初から大半の取り引きは電子取り引きであり、そのデータもすべてクラウドストレージに整理した上で保存している事業者にとってはほとんど運用に影響を与えない。もちろん現行の運用にあうようにするには事務処理規定を策定しないといけない。ここで影響があるのは訂正・削除の運用時に記録を残すという点ぐらいしか、既存の運用と変わることはない。そして、過去の電子取り引きの訂正・削除が発生したことは私の記憶にないぐらい稀にしか発生しないと推測される。

低辺 sier のひどい労働環境や多重請負契約の構造を it 業界の代表的なもののように揶揄されるのと同様、いかに世の中のできない人たちが自分たちのスキル不足や知識不足を大騒ぎしてその内容が正当であるかのように喧伝しているのかが伺える。まともにシステムを使っている会社は電子帳簿保存法で大きな影響を受けない。多少の運用手順が変わったり、システムの開発が必要になったりする程度だと思われる。これはインボイス対応もそう。うちのようなマイクロ法人でもインボイス対応は新規の取引先を登録していく作業が増えたぐらいで日々の会計処理にほとんど影響を受けていない。世の中のニュースと実際の実務運用に大きな乖離がある。そして、実際にやったこともないような人たちが「弱者いじめ」だと党派性をもって大騒ぎする。

モニター変更

これまで27インチと24インチのダブルディスプレイを使ってきた。実家 (コワーキングスペース) に27インチのモニターを持って帰ろうと思って、24インチのモニターをもう1つ買ってその入れ替えをしていた。24インチ x 2 のダブルディスプレイに変更した。27インチ x 2 は有効視野を考えると幅が広過ぎて私にはあわない。首振りが疲れる。1台でもっと大きいモニターを使うという選択肢もあるかもしれない。しかし、私はなんとなく2台のディスプレイで1つをコードを書くメイン、もう1つをブラウザで調べたものを表示させておくためのサブという使い方を気に入っている。ただの習慣かもしれない。

人間の視野は左右の眼を合わせると180度以上あります。 片眼の視野は鼻側に約60度、耳側に約100度、上方向に約60度、下方向に約70度と言われています。その中で、標識の文字を読むなど、モノのカタチや色などがキチンと認識できる範囲を中心視と言い、わずか1~2度ほど。中心視のまわりの必要なものを識別できる範囲、有効視野は左右に35度ほど。その外側である周辺視野では、カタチや色などをハッキリと認識することはできません。

中心視と周辺視野

オフィス掃除

モニターを入れ替えしたら埃っぽくなったのでついでにオフィスも掃除した。掃除機は sharp の EC-CT12-C を使っている。サイクロンだからパワーもあるし、ゴミ捨ても紙パックいらないから簡単。コンパクトで数ヶ月に1回ぐらいしか使わない私の用途にちょうどよい。普段は箱にしまってある。

箱から掃除機を取り出して、終わったら片付けるときに箱にしまい方も書いてある。他の掃除機はどうなのか知らないけど、たまにしか使わない家電で使ったらまた箱にしまうよねと気の利いたこの絵が嬉しい。掃除機を作ることに一生懸命だとこういう気遣いはできない。こういった配慮ができるのは会社の文化や組織や開発体制に「余白」があるからじゃないかと、私もマネジメントをしていて最近は思うようになってきた。この絵があるからこの掃除機を購入するわけではない。それでも、この掃除機を使っていて故障してもまた sharp の掃除機を買おうかなという気持ちにさせる。

部屋のレイアウト変更

マンションに帰って22時半から部屋のレイアウト変更を始めた。少し前に ホットクック を購入したものの、思いの外、大きくて置く場所がなくてそのための 置き台 をジモティーで購入していた。その置き台を台所の横に設置するには、本棚をどかす必要があって、それは重労働になるのでついつい先延ばししていた。こんな感じ。

設置して無線 LAN の接続や COCORO HOME に家電登録してアプリ間連携の設定をしていた。私のような Web 系の開発者からみると設定 UI やわかりにくさはひどいものだったが、家電メーカーの作るアプリはそんなものだろう。ホットクックの WiFi は 2.4GHz しかサポートしていない。うちの無線 LAN ルーターは 5GHz only で稼働させていたので 2.4GHz も有効化して接続した。私が購入したホットクック (KN-HW24G-W) は COCORO KITCHEN に非対応だった。COCORO KITCHEN は deprecated で今後は COCORO HOME になるのかな?COCORO KITCHEN で家電登録しようとしてうまくいかないとまごまごしていた。

年明けからコーポレート業務いろいろ

23時に寝て4時半頃に起きてそのまま6時半までだらだらして起きた。早寝早起き。

今日の筋トレは腹筋:20x1,腕立て:15x1,スクワット20x1をした。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。内容が多くて1時間超えた。

  • 電子帳簿保存法対応の事務処理規定の共有
    • まだ始まったばかりで税理士さんの温度感も低い
    • 事務処理規定が省令に沿っているかどうかの判断はプロセス監査で行われる
    • 電子帳簿保存法には規定されていないため、事務処理規定の妥当性の検証は行われない
  • 融資を受ける構想作り
    • 日本政策金融公庫のみで検討していたが、融資実績を作りたいなら信用金庫も加えた方がよい
    • 借金のメンタリティ、担当者との折衝や審査など余裕のあるときに経験を積んでおくことはよいように思えた
  • ファイナンシャルプランナーさんとのやり取り
    • 会社の経費で役員のための保険に入ろうと考えている
    • 個人の保険控除は8万円らしい
  • ローカル複業化プロジェクトの考察
    • IT コミュニティに老人や子どもたちは入りにくい。農業なら老若男女誰でも入れる気がする
    • 農業や地元の特産品を切り口にコワーキング (コミュニティ) で街の人たちと田舎の人たちをつなげるのはすごいことだと思う (関係人口の創出)
    • 地元の有力者と仲良くなると、行政の口利きもしてくれて活動しやすくなる

はらさんが よりひろいフロントエンド を始めたそうでその話しも聞いていた。個人のブログサイトにするのか、複数人で記事を共有するサイトにするのかもまだ曖昧だという。Contentful + Next.js + Cloudflare Pages という構成らしい。Contentful というツールを私が知らなかったのでまた時間のあるときに調べてみようと思う。

母が一人暮らしをしていて体調もよくないことから要介護状態になるリスクがそこそこあると考えている。最悪の場合、会社を休眠させてしばらく介護をするかもしれない。はらさんが仰るには休眠はよいアイディアだという。会社員に例えると退職した日の帰り道を想像するとよいと話されていたのだけど、私は過去の記憶があまりないというのもあるが、これまで6回も退職してきたのに退職日を特別に思ったことはあまりない。退職日と他の日に大きな違いはなくて、次のお仕事の準備や調査をしていることが私は多かったと思う。それでも退職にあわせて有休を1-2ヶ月とってゆっくり過ごしていたことには変わりない。私もそういう、メリハリのある働き方が好きだ。

smtp 接続のタイムアウト

たまたまメンバーが誤った設定で smtp サーバーに接続したときにタイムアウトするまで5分ほどかかるという現象を発見した。タイムアウトの設定をせずに接続しようとするからそんなことが起きるのかな?と考えて smtp クライアントのタイムアウト設定を調べてみると net.DialTimeout を使えばよいという。

多めに見積もって30秒のタイムアウトを設定して接続するようにして再度メンバーに再現検証してもらったら直っていないという。接続そのものは出来ていたのだ。ソースを読んでみると、smtp クライアントを生成するときに 220 というレスポンスを読むことがわかる。誤った接続設定でもコネクションは確立するが、レスポンスが返ってこなくて待ち状態になっていた。

func NewClient(conn net.Conn, host string) (*Client, error) {
	text := textproto.NewConn(conn)
	_, _, err := text.ReadResponse(220)
	if err != nil {
		text.Close()
		return nil, err
	}
	c := &Client{Text: text, conn: conn, serverName: host, localName: "localhost"}
	_, c.tls = conn.(*tls.Conn)
	return c, nil
}

調べてみると Conn インターフェースにデッドラインを設定する API が提供されている。注意事項としては接続した後にデッドラインをリセットしないといけない。

デッドラインとは、I/O操作がブロックされずに失敗する絶対時間のことである。デッドラインは、ReadやWriteを呼び出した直後のI/Oだけでなく、将来の保留中の I/O すべてに適用される。デッドラインを超過した後は、未来にデッドラインを設定することで、接続をリフレッシュすることができる。

デッドラインを超えた場合、ReadやWrite、その他のI/Oメソッドの呼び出しは、os.ErrDeadlineExceeded をラップしたエラーを返します。これは、errors.Is(err, os.ErrDeadlineExceeded)を使用してテストすることができます。errorのTimeoutメソッドはtrueを返しますが、期限を超過していなくてもTimeoutメソッドがtrueを返すエラーが他にもあることに注意してください。

アイドルタイムアウトは、ReadまたはWrite呼び出しに成功した後、デッドラインを繰り返し延長することで実装できる。tの値が0であれば、I/O操作はタイムアウトしない。

https://pkg.go.dev/net#Conn

次のように SetReadDeadline() を使ってタイムアウトを5分から30秒に短縮できた。

func (s *Clinet) connectWithReadDeadline(conn net.Conn) (*smtp.Client, error) {
	if err := conn.SetReadDeadline(time.Now().Add(dialTimeout)); err != nil {
		return nil, fmt.Errorf("failed to set read deadline: %w", err)
	}
	c, err := smtp.NewClient(conn, s.config.Host)
	if err != nil {
		return nil, fmt.Errorf("failed to connect to the smtp server: %w", err)
	}
	// clear read deadline
	if err := conn.SetReadDeadline(time.Time{}); err != nil {
		return nil, fmt.Errorf("failed to reset read deadline: %w", err)
	}
	return c, nil
}

コミュニティとコワーキングの違いを説明できるようになってきた

4時過ぎに寝て8時半に起きた。まだ年明けだし10時ぐらいにオフィスへ行こうかとのんびりしていたら9時からのはらさんの打ち合わせを忘れていた。慌てて準備して5分ほど遅刻した。

今日の筋トレは腹筋:10x1,腕立て:10x1,スクワット15x1をした。このぐらいなら時間を取らないので日記をアップするために筋トレする動機づけになる。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日も事前に慌てて議題を準備した。

年始というのもあってほぼ雑談に近いものだったけれど、時間もあったのでわりと盛り上がって話していた。

はらさんも過去にコワーキングスペースの手伝いのようなお仕事をしたことがあったらしく、コワーキングマネージャーのあれこれで盛り上がった。コワーキングスペースは値段が安いため、ビジネスとして成り立たないという懸念についても私も同意する。コワーキングスペースを本業にするのではなく副業でやるのがよいと私も考えている。コワーキングスペースへ来る方は、他のコワーカーとのコミュニケーションを価値と考える方と単純に作業スペースを必要として来る方の2通りに分かれる。いとうさんは後者の用途はコワーキングスペースとは分けて、ワーキングプレースと呼ぼうと提案している。もちろん作業場としてのニーズがあることは間違いないし、そういった用途を否定するものでもない。しかし、いとうさんの仰る、本来の意図のコワーキングスペースというのは、他のコワーカーたちと協調しながら独りでは為し得なかったアイディアや価値を創り出すことにある。最初にワーキングプレースではないといったことを明言して来られる方を選択するのがよいのだろう。

あと sns を開発するのは難しいという話題も盛り上がった。とくに dm と決済は難しいという。dm は犯罪の温床になる懸念からプラットフォーマーとしての責任と利用者のプライバシー配慮の双方がぶつかり合う機能になるため、どういった実装をするかのバランスが難しいのだろうと推測する。

最果てのユースホステルのドキュメンタリー

はらさんが休暇中にみたという番組を教えていただいた。コミュニティやコワーキングの文脈で参考になるのではないかと。

もしかしたらドキュメンタリーだから意図的に特徴のある人を選択している可能性はあるけれど、人生に迷った人の境遇が紹介されていた。進路を悩んでいる、大学を休学している、組織の論理に従うのが嫌になったなど。以前からコワーキングやコミュニティに来る人たちは社会から弾かれた人が多いような気が私はしていた。既存の大勢派の考え方や論理に馴染めず、その枠組みとは異なる価値観や考え方を求めているような気がする。そして、それは人生においては、どちらかと言えば、順風満帆よりもうまくいっていないときに考える機会の方が多いのではないかと思う。

この番組で紹介していた事例は紛れもなくうまくいっている (即席の) コミュニティにみえる。宿泊者も一緒になってコミュニティのメンバーの一員としてイベントを盛り上げる役割を担っていて、そういう仕掛けをヘルパーと呼ばれる人たちがうまく誘導しているようにみえる。ヘルパーは実質的にコミュニティマネージャーを務めている。離島に数日泊まるという閉鎖的な環境や非日常が、そこに一緒にいる人たちと小さいコミュニティを築く上での装置としてうまく作用しているように私からは思えた。

事務処理規定の叩き台作成

年末に税理士さんと打ち合わせ した主な議題の1つで 電子帳簿保存法 対応のための事務処理規定の叩き台を作成した。今日のところは叩き台を作成して税理士さんにレビュー依頼した。レビュー依頼が通ったら実際のワークフローや手順を細かく記載したガイドラインを notion に作ろうと思う。他に社員がいないのもあって、私だけわかればよいのであれば、課題管理システムの issue のみで事足りて、ほとんど notion を使う機会がないというのが現状。いつか社員雇う日がくるのかどうか。

年始は事務手続きからぼちぼち

0時に寝て何度か起きて7時過ぎに起きた。午前中はだらだらして午後からオフィスに出て会計や税務の財務の事務手続きをまとめてやっていた。

今日の筋トレは腹筋:10x1,腕立て:10x1,スクワット10x2をした。昨日さぼったから罪悪感が出て今日はちゃんとやろうと思った。

給与支払報告書の申告

年末に作成済みの書類データ を送信した。

給与支払報告書は神戸市へ、ほとんど同じ内容の法定調書合計表と源泉徴収票を税務署へ提出する。eltax のアカウントに e-tax のアカウントも紐付けることで、給与支払報告書の送信時に e-tax へ法定調書合計表と源泉徴収票のデータも送信してくれる。本来は2つ行う必要がある書類の作成/データ送信の作業が1つに軽減されるのでこれは便利な仕組みだと思う。

うちは社員1人なので手入力で書類を新規作成している。それ自体は簡単なのだけど、年に1回しかやらない作業なので書類のどこにどの値を入力するか、毎回忘れて過去の issue をみながら作業することになる。

償却資産 (固定資産税) の申告

会計システムの固定資産台帳だけを眺めていると、基本的には30万円以内の機器を購入して次の特例を使って一括損金算入するので減価償却中の固定資産はないようにみえる。

しかし、この特例は国税 (法人税と地方法人税) の減税のための制度であって、地方税である固定資産税とは無関係になる。だから固定資産台帳にある取得価額を資産が増加したら申告データに含めて登録する必要がある。課税標準額が150万円未満であれば、固定資産税そのものは課税されないが、申告そのものは必要になる。私も起業してから2年目のときにはらさんと話していて国税と地方税の違いによるこの誤解に気付いた。この申告も年に1回しかやらないので書類のフォーマットを思い出して理解するのにいつもまごまごする。

オンラインで調べると、課税標準額は先方で自動算出されるように書いてあったりするので eltax のアプリ内で算出してくれたらよいようにも思うのだけど、アプリ上ではとくに算出されない。もしかしたら取得価額の合計が150万円未満ならそもそも非課税になるので計算しないといった仕様なのかもしれないし、課税標準額も定額法や定率法のなにで算出するかで変わってくるから一概に算出できないのかもしれない。謎い。

源泉所得税の納付

半期に1回の源泉所得税の納付。これは手慣れたもので15分あれば申請と納付と会計システムに取引明細の登録までできる。

小規模企業共済オンライン手続きポータルのログイン確認

以前 アカウント申請して 翌日には本登録されていたものの、その後、ログインしていなかった気がしたのでついでに調べてみた。

ログインしたら e-私書箱 と連携しろと言われ、そのシステムと連携したら今度は e-私書箱と マイナポータル を連携しろと言われて、3つのシステムを連携した。開発者の私でもこれは???になってしまう。私はシステム側の都合があることを理解できるが、こんな一方的な複数のシステム間連携を一般ユーザーは理解できるのかな?とか疑問に思いつつ、ひとまず連携設定はしておいた。マイナンバーカードで何度もパスワード入力さえすればすぐに連携できる。

小規模企業共済オンライン手続きポータルにおいても年間の納付データや証明書を取得できた。そして連携しているe-私書箱でも確認できるようになっていて、おそらくこの状態ならマイナポータルにも連携されるのだろうと推測する。私の場合、確定申告は freee で書類作成してやるからマイナポータルから確定申告をまとめてやることはないけれど、いずれ移行する可能性はあるのでシステム間連携は徐々に進めて仕組みなども理解していこうとは思う。

一周まわって飲み会も大事

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

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

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

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

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

姫路駅の雰囲気

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

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

税務相談のストレス

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

テックブログ公開

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

隔週の雑談

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

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

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

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

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

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

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

sveltekit/vite アプリケーションの調査を再開

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年にまともな開発者が作ったサイトとは思えない。デジタル庁に作り直してもらった方がよいと思う。

家族信託の打ち合わせ

1時に寝て4時に起きてもう1度どこかで起きて7時半に起きた。

テックブログ公開

テックブログレビュー を終えて公開した。この機会に 個々の記事に目次 も追加した。はらさんレビューから修正をして2時間後に公開しますよと宣言して勝手に公開した。

家族信託の打ち合わせ

15時にお仕事を早退して、親と一緒に明石市にある弁護士さんの事務所へ訪問した。三ノ宮から車で向かって、ナビゲーションに従っていたら京橋から高速道路に入って若宮でおろされて、なんでこんな早く高速道路おりるんやろ?と不思議に思ったけど、須磨からの海岸線はそれほど渋滞せず信号も多くないから下道で行ってもそんなに時間はかからないという判断だったようにみえる。だいたい40-50分ほどで明石市の中心地に着いた。3分ほど遅刻して打ち合わせが始まった。

遺産を相続するとさまざまなリスクがある。大きなお金をもつというだけで詐欺のターゲットにされる。家族信託 (民事信託) という制度を使って、そのとき必要なお金のみを受け取るように運用する。構成要素は次の通り。

  • 委託者: 母
  • 受託者: 私と姉
  • 信託財産: 預金

受託者は最低2人必要で、うちは姉もいるのでよいのではないかと弁護士さんが話されていた。たしかに1人っ子なら誰かにお願いしないといけない。大雑把に言えば、母の貯金を子どもに管理してもらうような制度になる。但し、最初の契約書に記載された内容の範囲内でしか、受託者はお金を引き出せないのでその契約書をしっかり作ることが重要になる。契約書に記載していれば、資産運用もできるらしい。契約書の叩き台として、どういった内容を書いておくかを相談した。弁護士さん曰く、契約書に書いておかないとその用途に使えなくなるため、1%でも可能性があれば、書くだけ書いておいた方がよいとのこと。書いておいて、実際に使わないというのはなんの問題もない。

3人でブレストするような感じで項目を洗い出した。

  • 生活費
    • 冠婚葬祭で払うお金
      • 10万円以内なら生活費として引き出してもよい
      • 例えば30万円いるとして、建替え可能なら10万円/月を3ヶ月かけて引き出すでもよい
    • (お金に困った親戚がいたと仮定して) 親戚への資金援助
      • 生活費の範囲内でやればよいはず
  • 看護、療養といった通院も含めた医療費
  • 老人ホームの入居費用
  • 納税 (一時所得)
    • 太陽光発電で得た収益のうち、所得税をこの口座から引き出して支払うといったこともできる
  • 家の改築、修繕、取り壊しの費用
  • 農業のための費用
    • 農機具の購入や修理など
    • トラクターが一番高い、100万円〜1,000万円ぐらいとピンからキリまである
  • 土地 (田んぼ、宅地) の購入
  • 太陽光発電設備の撤去費用
  • 自家用車の購入費用
  • 生命保険の支払い
    • 死亡保険金は500万円 x 法定相続人数まで非課税なので相続税の節税になるらしい
      • 例) 母の死亡時に姉と私が500万円受け取るような生命保険に入る
    • 相続税の基礎控除が3,000万円 + 600万円 * 法定相続人数
      • 例) うちは私と姉で 3000 + 600 * 2 = 4,200万円が基礎控除となる
        • この金額を超える遺産があれば相続税の課税対象となる
        • 生命保険へ付け替えることで 4200 + 500 * 2 = 5,200万円まで非課税にできる?
  • 資産運用
    • 投資信託
      • 積み立て系の投資信託がもっとも望ましいのではないか
        • リスクヘッジとして大きなお金を1度に動かすのはなるべく避けたい
        • NISA 口座を開設できるかどうかは調べないとわからない
      • 信託口座とは別に証券口座も開設しないといけない
        • 受託者が預金口座からお金を引き出して証券口座へ振り込むような運用になる?
      • 具体的にどういった運用にするかは信託銀行と応相談になるかもしれない
        • なんらかの制約が課されるのではないかと推測される
    • 株式投資
      • 可能ではあるが、条件を指定しないといけないため、中長期での実運用は難しいのではないか

私が信託口座からお金を引き出すときに、一定金額以下の生活費 (例えば10万円) ならノーチェックだが、100万円とか大きなお金を引き出すときには銀行員からチェックがかかり、正当な使途なのかどうかを確認されるという。場合によっては見積もり書の提出なども必要かもしれないとのこと。それはとくに問題ない。契約書の作り直し自体は委託者が元気であればできる。しかし、手数料や手間暇もかかるため、実運用としては最初に作った契約書を変更するといったことはそうそう行われない。最初が大事。弁護士さんが契約書を作成するのに2-3週間かかる。その後に三井住友銀行さんで赤ペン先生のチェックが入る。契約内容の修正などのやり取りをしてその後手続きに進む。

思考実験として、詐欺にあって借金してしまった、または連帯保証人となって借金してしまった。その場合はどうなるか?というのも考えてみた。信託銀行に確認してみるとのことだったが、弁護士さんが言うには、家族信託の目的は財産を守ることにあるため、本来の使途ではないものへ支払いは抵抗があるかもしれないとのこと。その状況によって銀行員の判断次第かもしれないとのこと。

受託者は年に1回報告書 (帳簿) を作り、どのように運用したかを委託者へ報告する義務がある。これは家族間だけの話ではある。この手の情報処理 (データ処理) は私が得意とするのでそんなのすぐやりますと回答できた。弁護士さんによると、こういう事務作業を嫌がる受託者もいるという。スプレッドシートでちゃちゃっと作ればよいはず。

契約書を作成したら、それをもって委託者、受託者、弁護士の3人で 神戸公証役場 へ一緒に行く。その公正証書をもって三井住友信託銀行へ行って、母が口座を開設して、そこに弁護士さんが遺産を振り込むといった段取りになる。将来、委託者の健康を害して成年後見人がつく状況になったとしても家族信託の口座はそのまま受託者が管理できる。成年後見人に信託口座が移管されるようなことはない。

最後に契約書の条項をチェックしていて次の内容を教えてもらった。

弁護士業務の適正の確保

甲は、本件事件等の処理の依頼目的が犯罪収益移転に関わるものではないことを、表明し保証する。

「半社チェックのようなもの?」と聞いたらちょっと違っていて、弁護士は大きなお金を動かしても監査を受けないという特権 (信頼) があって、その特権はマネーロンダリングできてしまうという諸刃の剣でもあるらしい。今回のお金は遺産なので半社会的なものに該当しないが、契約書では弁護士が扱う業務がマネーロンダリングではないことをチェックする必要があるみたい。

帰りに 明石焼き ゴ というお店で明石焼きを買った。駐車場の近くにあったお店に立ち寄ってテイクアウトしたのだけど、とてもおいしかった。それで 食べログ の評価もみたら 3.49 とかなり高い。たまたま買ったところがよいお店だった。18時半頃に店内もほぼ満席だったと思う。また明石へ行く機会があれば寄ってみようと思う。