0時に寝て4時に起きて7時に起きた。最近は4時に一回起きることも多くなってきた。ちょっとゲームしていつの間にか、寝たりもするけど。

法人決算の間違い

5月の最終日なのでお昼休みに社会保険の引き落としの明細を手動で入力していた。ufj 銀行 (法人口座) の api 連携は有償サービスで、主に社会保険や経営セーフティ共済の引き落としにしか使っていないのでうちの会社は有償サービスを使っていない。通帳もしくは当日残高の明細をみて、それを手入力で freee の口座に登録する。そこで稀に利息がつくというのを失念していた。2月の利息15円の明細登録が漏れていることに気付いた。freee には登録残高という自動計算された口座残高をもっているので、それと明細の残高を見比べれば気付けるようになっているのだけど、たった15円の差異だったのでこれまで私が見落としていた。

法人決算の確定申告をすでに終えているのに15円の受取利息が漏れていることに気付いてしまった。ひとまず税務署に電話してどうしたらいいかを相談した。今日中に訂正するなら上書き更新、明日以降なら修正申告と言われた。所得や税引き前純利益の金額に15円の差異があり、3つか4つぐらいの帳票の項目の値が変わる。法人税の金額計算には影響しない。欠損金の繰り戻し還付の申請でも15円の違いから2円の差額になった。銀行の受け取り利息の消費税は非課税なので消費税の申告には影響しない。

e-tax で送信したデータをコピーして、元データがある状態で誤り箇所を修正して再送信するのはすぐできて30分ぐらいで訂正送信できた。電子申告の良さを実感した。紙だとこうはいかなかったかもしれない。財務諸表は紙で提出しないといけないので、e-tax の修正送信後に慌てて税務署へ行って再提出してきた。それが16時15分。法人決算締め切りの45分前。オフィスから税務署まで自転車で5分の距離だから間に合った。思いの他、最終日に落とし穴にはまったものの、ちゃちゃっと訂正できたので行政の事務手続きスキルは上がってきたなと自信ももてた。こんな失敗をしておけば今後は登録残高と明細残高のチェックも忘れることはないだろう。

0時に寝て6時頃に起きて7時半に起きた。

cloudfront と waf と s3 と ipv6 と

aws サービスについて ipv6 について調べると、少しずつ対応してきた経緯があって、ipv4 と ipv6 の両対応のことを aws は dualstack と読んでいる。エンドポイントのサブドメインに dualstack があれば、ipv6 対応していると考えてよいと思う。リモートワークしている開発者がテスト環境に接続するときに、その開発者の IP アドレスを登録する aws lambda 関数がある。その lambda 関数にリクスとすると、リクエストしたクライアントの IP アドレスを waf の IP sets に登録することで、パケットフィルタリングのルールを更新している。たまたま、そのインフラを cdk 移行したところ、ある開発者は ipv6 で登録しようとしてエラーになるということがわかった。移行のときに api gateway を使わずに直接 lambda の fuction url を使うようにしたところ、lambda は ipv6 対応しているのでそのまま ipv6 の IP アドレスを登録しようとして waf の設定が ipv4 しか対応していなかったためにエラーになっていた。

• AWS Lambda がインバウンド接続用のインターネットプロトコルバージョン 6 (IPv6) エンドポイントのサポートを開始

cloudfront, waf, s3 の ipv6 対応は2016年頃に対応していて、この3つのサービスに対して一緒にブログ記事を書いているのは、これらのサービスを一緒に使うことを想定しているとみなすべきだろう。

• IPv6 サポートの更新 – CloudFront、WAF、S3 Transfer Acceleration

cdk のコードで cloudfront, waf は ipv6 対応したのだけど、cloudfront のオリジンに当たる s3 の ipv6 対応を cdk からどうやって設定していいかわからなかった。aws-cloudfront-origins の S3Origin のコードを読むと、どうも s3 の ipv6 対応のエンドポイント (dualstack) を考慮して制御しているようにはみえない。バグではないけど、設定方法がわからないので feature request として issue 登録してみた。aws-cdk に issue 登録するのは初めて。余談だけど、ISSUE_TEMPLATE もよく出来ていて、これを参考にして自分たちのリポジトリにも取り入れてもよさそう。

• (aws-cloudfront-origins): Support dualstack domain name (ipv6) for S3 origin #20550

0時に寝て7時に起きた。

レンタカーで運転の練習

ふと思い立って8時からレンタカーを借りて運転の練習をしてきた。今週末に ワーケーション を予定しているが、城崎温泉との往復を私が参加者を乗せて車で運転しないといけない。たまに実家に帰ったときに家にある車を運転する程度なので私の運転スキルには不安しかない。言うても田舎の交通量の少ないところを走る分には問題ないはずだけど、それでも準備しておくに越したことはない。レンタカーの慣れない車だと予期しないことで失敗することもあるだろう。そういうリハーサルも兼ねてレンタカーを借りて六甲山、六甲アイランド、灘五郷と50kmぐらい、5時間ほど走って、時間貸駐車場での駐車して料金支払いをやってみた。普段は週末を自社のお仕事で過ごしているし、今月は法人決算に時間をとられていて、その鬱屈した気持ちの気分転換にもなってよかった。

資料作成の準備

ワーケーションでは、参加者の親睦も兼ねて内容自由のプレゼン大会を企画している。その準備で資料を作り始めた。なんの話しをしようかなぁと考えて、私は会社紹介をすることに決めた。営業さんと一緒に初めて訪問する会社へ行ったり、ピッチなどに参加すると、発表者が会社紹介をしているのを過去にもよくみかけていた。うちにお仕事を依頼してくれる会社は基本的に知人なので会社に依頼しているというよりも、私個人に仕事を依頼している。だからこれまで会社紹介を必要とされなかった。今後のマーケティングやプロダクト開発をしていくにあたり、いずれ様々な場面で知らない人たちに会社紹介をしなければいけなくなることが想定される。直近で必要はないけど、いまから数ヶ月かけて少しずつ会社紹介を作っていって「ぼくのかんがえたさいきょうのかいしゃしょうかい」ができればいいかなといったところ。その最初の叩き台をつくって、参加者にレビューしてもらおうと考えた。ちょうど スライドマスターのデザイン もできたばかりなのでスライドに熟れる必要もあった。3時間ほど資料作りして続きはまた翌日に持ち越し。

0時に寝て6時に起きた。

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後162cmだった。先週とほぼ変わらないので現状維持といったところ。右腰に張りがあって今週は椅子に座って後ろに寄りかかっていてもやや右腰が張るなぁと自覚症状もあった。ストレッチを受けていても効くなぁって感じだった。新しいトレーナーさんに代わってから1ヶ月のストレッチを受けてだいぶ打ち解けた感はある。

法人決算をほぼ完了

法人決算の e-tax 申請 の続き。前に消費税の申告をしたときに別表五以外はすべて作成していた。別表五はどこに何の数字を入力するのかが難しくて、過去の書類と数字を見返しながらやらないと詳細を覚えていなかったりする。その作業をするのが面倒でずっと先送りしていた。本気出してやれば1-2時間もあれば完了した。なんやらかんやらで eltax も e-tax の電子申告も自分でできるようになった。できることが増えていくことそのものが楽しい。

今回の法人決算で申告・申請したのは次の3つ。

e-tax の画面は基本的に帳票そのものなので数値を入力した後で紙に印刷することで帳票を保管することもできる。例えば、法人税・地方法人税の申告に必要な帳票がこれらになる。過去2年は手書きで作成していたけど、ほぼ同じの内容を画面で作成してデータで送付するだけの違いしかない。紙なら2時間で終えられる作業を、(使いにくい) アプリケーションの画面で入力すると余分に数時間かかってしまうものの、システムだと差し引きや合計値の計算は自動でやってくれるので記入ミスは起こりにくい。とはいえ、システムの自動計算が間違っていることもあるので強制入力が必要になるときもある。

税務署へ電話で問い合わせたときに財務諸表を pdf 添付でよいと話していたけど、いざやろうとしたら財務諸表は xml または xbrl 形式でないとダメだと説明が出てきた。仕方ないので月曜日に税務署へ行って紙で提出してくる。電子申告と紙を組み合わせて法人決算やることは構わないとのこと。

0時に寝て6時に起きた。調子よくて7時からオフィスで作業してた。なんだかんだで今日は主にお手伝い先のお仕事をしてた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の話題はたくさんあった。

• スライドマスター作成のふりかえり
• 課題管理のためのメンタルモデルづくり
• スクラムの悪いところの共有
• 住民税の変遷について

会社としての発表のスライドを管理するために speakerdeck の会社アカウントを作成した。jjug の主催者のスライドチェックが完了したらアップロードしようと思う。google docs をそのまま公開するのと speakerdeck のどちらがいいかを検討した。google docs だと、スライド資料のノートまで公開されてしまうのでスライドだけなら speakerdeck の方がよさそうかなと判断した。

• https://speakerdeck.com/kazamori

スクラムの悪いところの1つとして、スクラムマスターが現状認識を誤っているときの是正方法がないという話題をした。スクラムマスターは po や開発者にアドバイスするのだけど、アドバイス自体が誤っているのではなく、アドバイスしている内容がプロジェクトの置かれている状況にあっていないというギャップに対しての、ふりかえりや是正の仕組みがスクラムに包含されていない。ある知人によると、スクラムマスターは超人でなければ務まらないという前提になっているのではないかという意見もあった。現時点でとくに結論はないのだけど、難しい課題だなぁと議論していた。

0時に寝て6時に起きて7時半に起きた。なんかバテバテ。

aws-lambda-python-alpha

cdk 標準の lambda モジュールで python スクリプトをデプロイすることはもちろんできるが、その python スクリプト内でサードパーティのライブラリを使いたい場合、layer という機能を使って複数の lambda 関数で再利用するというのがもともとのやり方っぽい。とはいえ、サードパーティの依存ライブラリも python スクリプトによって使うものが違ったりするので lambda 関数単位に管理したいという場合もある。その要件を考慮した場合、python のパッケージングを lambda 関数のデプロイ時に再利用できるのが望ましくて、そのためのモジュールが aws-lambda-python-alpha になる。説明が長い。

• @aws-cdk/aws-lambda-python-alpha
• Amazon Lambda Python Library - Packaging

JJUG CCC 2022 Spring のタイムテーブル

タイムテーブルが公開された。

タイムテーブルが公開されたみたい。2022/06/19 10:25〜 Track C #jjug_ccc_c でカスタム github actions の話しをします。よかったらご覧ください。スライド資料も主催のチェック完了後に公開予定です。https://t.co/AjP1aLt9EM

— Tetsuya Morimoto (@t2y) May 26, 2022

私の前の発表が大橋さんという、一緒のチームでお仕事している方で github actions で運用している開発のワークフロー全般を改善したという話しをされる。その大半は私が設計して既存のワークフローを作り直したものなので応援している。改善の前後におけるワークフローの実行時間の比較や資料のレビューなども手伝っていて、私が主導してやったんだから内容についての責任は私にあると考えていろいろサポートしていた。おそらく github actions つながりで連続しているのかなと推測する。当初はお互いに送客すればいいかなと考えていたけど、普通のセッションの規定が厳しくて、スポンサーじゃなければ会社や製品の宣伝はダメという話しなので送客は断念した。

22時に寝て1時に起きて5時半に起きた。前日はあまり寝てなかったので知らないうちに寝てしまった。

severless framework と cdk の比較

serverless framework というツールがある。マルチクラウド対応で aws で言えば lambda のような、サーバーレスのアプリケーションを簡単にデプロイするためのツール。よく使われているようで、私がお手伝いしている会社でも lambda 関数のデプロイにこのツールを使っている。いろいろ調べていたら、serverless framework は cdk と真正面から競合になるツールで、cdk をすでに使っているなら cdk に一元管理した方が保守コストが下がっていいだろうと考え、新たに lambda 関数を作る作業を cdk でやってみた。私はほとんど serverless framework を使ったことがないので正しく理解できていない可能性は高いが、ざっくり比較すると次になる。

serverless framework

メリット

• cdk より学習コストが低い
• yaml 設定だけで簡単にデプロイできる

デメリット

• リソース管理のための s3 バケットを必要とする
• lambda に関連するリソースしかデプロイできない
• 開発者が明示的に設定しなくても裏でリソースを勝手に生成するので意図せず適切に管理されていないインフラを作ってしまう懸念がある
• 大半の実務レベルのアプリケーションでは cf テンプレートの dsl を yaml に設定する必要があり、設定が煩雑になったり見通しが悪くなる

cdk

メリット

• 任意の aws インフラのリソースを管理できる
• プログラミング言語で記述できるので動的なリソースの依存関係を定義できる
• cf は裏に隠蔽されているが、serverless framework のような dsl を記述する必要はない

デメリット

• 学習コストが高い

リファレンス

• AWS CDK vs Serverless Framework
• Serverless Framework vs SAM vs AWS CDK

結論から言うと、将来的に cdk を使うならまず cdk を使った方がよい。本当にシンプルな要件で lambda 関数のインフラしか扱わないなら serverless framework でもいいかもしれない。serverless framework は cdk がない時代に作られたツールだろうからいまから新規に導入する場合は、多少の学習コストを払っても cdk を学んでおけば、将来的に役に立つ場面が多いと思う。

5時に寝て7時過ぎに起きた。前日の夜から法人決算の電子申告に取り組み始めた。本当は紙でやるつもりだったんだけど、eltax が快適だったので e-tax も衝動的にやってみたくなった。

消費税と地方消費税の申告

法人決算 の一部。今回が初めての消費税と地方消費税の申告になる。簡易課税で支払う。

消費税は、国税（国に納付する税金）であり消費税の納税義務がある事業者が納付します。地方消費税とは、 消費税と同様で商品の販売やサービスの提供などの取引にかかる税金 です。消費税との違いは、 地方消費税は国税ではなく地方税（都道府県や市町村に納付する税金）という点です。 しかし実際に納付するときは消費税と分けて納付はせずに、 消費税と一緒に地方消費税を所管税務署へ納付します。

消費税と地方消費税の違いは？納付対象者や納付方法、計算の仕方まで徹底解説！

freee で出力した書類をみながら e-tax の画面で同じ書類の項目を埋めていくだけの作業。1つだけバリデーションエラーが発生して、何度やり直しても数値は正しいようにみえるので無視して処理を継続することにした。メッセージにも値が正しければ継続してくださいと書いてあるのでバリデーションがバグっているのだろうと推測する。書類を作成して、署名して、送信して、納付情報が返ってきて、pay-easy で納付額を振り込む。1時間ほどで完了できた。

eks (k8s) から alb の管理

eks (k8s) に aws-load-balancer-controller をインストールすると k8s 上のリソースとして alb を管理できるようになる。

• AWS Load Balancer Controller アドオンのインストール

具体的には k8s の Ingress と Nodepoint リソースから次の3つのリソースを生成してくれる。

• application load balancer
• http listener
• target groups

alb からのヘルスチェックは次のようにエンドポイントを記述する。spring boot だと Actuator という web api がヘルスチェックの機能を提供している。

alb.ingress.kubernetes.io/healthcheck-path: /actuator/health

alb.ingress.kubernetes.io/scheme の設定で alb を配置するサブネットを指定できる。デフォルトは internal になる。

private subnet に配置するとき

alb.ingress.kubernetes.io/scheme: internal

public subnet に配置するとき

alb.ingress.kubernetes.io/scheme: internet-facing

0時に寝て5時半に起きた。

draw.io を触ってみた

先週末から着手している インフラのドキュメント作成 の続き。aws のシステム構成図を書こうと思ったものの、書いたことがないので次の記事を読み始めた。

• AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ?

そこから AWS アーキテクチャアイコン のダイアグラム作成ツールとして紹介されているツールを一通りみてみた。書いたことがないのでどのツールを使えばいいのかすらわかっていない。見た目だけ比べればどれも似たり寄ったりで何でもいいやと思えた。既存の cdk コードからインポートして自動生成できるツールもあったけど、なんか出力結果がいまいちでそれよりは手で書いた方がいいように思えた。前任者は draw.io で書いていたので、それでいいかと思って draw.io を触り始めた。前任者はリポジトリに svg ファイルのみをコミットしていた。なぜ draw.io の web サイトのリンクがないのだろう？と不思議に思いつつ、draw.io でユーザーアカウントをどうやって作るのかを調べていて気付いた。draw.io って ui ですべて作図していてサーバー側に情報をもってないみたい。だからユーザーアカウントを作る必要もなくて、ブラウザを単なる gui のインターフェースにしているだけみたい。有償プランもユーザーが管理しているストレージに対するアクセス管理機能のようなものを提供している。先入観から web ベースのツールだと思い込んでいたので新鮮な気持ちになった。

前任者は web ブラウザも使っていなくて vscode の Draw.io Integration で書いたらしい。ui 側のロジックが再利用できるなら vscode でもブラウザで書くのと同じ品質レベルの操作ができるのだろうと推測する。vscode の方がローカルで書いている実感がわくかもしれない。svg ファイルをコミットしていたのも github の rich diff を使うと svg ファイルの画像差分も表示してくれるから。当初は xml でバージョン管理しようと思っていたんだけど、差分表示ができるなら svg ファイルでもいいと思えた。今日のところは draw.io を使おうということだけ決定した。

• Draw.io（diagrams.net）で作成したインフラ構成図をコードで管理する、GitHubで編集差分を確認する

1時に寝て8時に起きた。疲れてだらだらしてた。

ビデオセッションの撮影

Widnows マシンで撮るか、Ubuntu で撮るかを迷ったあげく、Kazam Screencaster というツールを使って Ubuntu で撮ることにした。google docs のスライドをプレゼンター表示にして、メニューから全画面モードを選択すれば、プレゼン資料のノートをみながらフルスクリーンで画面に表示できる。そのフルスクリーン画面を kazam でキャプチャーする。kazam はシンプルなツールなので私の要件にも合致していてよかった。うちのシェアオフィスは壁が薄いので話し声などが隣に聞こえてしまう。発表のビデオ撮影をしていると、お隣さんからするとうるさくて迷惑をかけてしまうのでお隣さんが帰るのを待っていたら19時ぐらいになってしまった。19時から撮影を始めて内容を手直ししたり、失敗したりしながら3回ぐらい撮り直しをして完成させた。ビデオ撮影を1度やったので次にやるときはもっと要領よくできそうな気がする。ビデオ登壇は準備が楽そうだというのがわかってきたので今後も挑戦してみたい。

小規模企業共済と住民税

住民税は原則として所属している会社が給与天引きで徴収して納めないといけない。これを特別徴収と呼ぶ。住民税の区切りは6月始まりなので、年に1回、5月に翌年の社員の住民税の通知が会社宛に届く。その通知には毎月徴収する住民税の金額が書いてある。2021年度は小規模企業共済による所得減額 が48万円ある。所得税も減るし住民税も減る。昨年から総所得金額は変わっていないので小規模企業共済の掛け金によって所得金額が少なくなっている。おそらくその分で37,300円の住民税が安くなった。現状は4万円/月で運用しているが、将来的に余裕ができてくれば掛け金を増やしてもいいのかもしれない。

4時に寝て8時に起きた。昨日は遅くまで資料作りをしていてやや眠い。

ストレッチ

トレーナーさんが代わってから3週目。だいぶ新しいトレーナーさんのストレッチにも慣れてきた。7割ぐらいは同じストレッチだけど、3割ぐらいは似て非なるもので指圧の掛け方や伸ばしている部位が微妙に違う。あとやり方も違う。トレーナーさんが代わったばかりのときはその微妙の違いに耐性がなくて調子が出なかったけど、少しずつ慣れてきたみたい。今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。腰も右股関節もそれほど悪い状態でもなかった。トレーナーさんが言うには肩甲骨と骨盤周りがあまりよくないといった話だった。3月ぐらいから怠惰な日々が続いているのでそろそろ運動やストレッチも再開したい。

jjug のビデオ録画

昨日の続き。資料はできたのでその発表ビデオを撮らないといけない。イベントで発表するのにビデオを提出するのは私にとって初めての試み。まずビデオを撮ったことがないのでツールの使い方から分からない。リハーサルをやぎさんに手伝ってもらって Windows マシンで試しにやってみた。感謝。Windows の標準機能だとゲームバーという録画ツールが使える。ショートカットは Windows キー + G で起動する。ゲームのプレイ動画などを録画して sns にアップロードするようなツールみたい。撮ってみたら録画時間は21分だった。発表時間は15分なのでここから6分削ればよい。

はっくばー

近所にはっくばーが出来たのでそのプレオープンイベントに行ってきた。内装は普通のバーで4人席が4卓、カウンター席が5席ぐらいかな。こじんまりとした可もなく不可もなくな装いだった。2時間弱ほどいてビールとレモンサワーを飲んで支払いは2,000円だったので料金は普通と言えるだろう。プレオープンだからなんかイベント的なことやるのかな？と期待して行ったんだけど、とくに何もなくて、参加者同士がお酒を飲みながらわいわい話すだけのイベントだった。オーナーが挨拶するといったこともなかったし、どういった展望をもってはっくばーをやっているのかもわからなかった。参加者の中にはオーナーやその所属組織の関係者のコネで来ましたという人もちらほらいたので、どこかしらの技術コミュニティで盛り上がっているのかもしれない。

私は7人の参加者と話した。相対的に若い人が多かったようにみえた。youtuberのサロンでプログラミング勉強してますというフリーターの人とか、ベンチャー企業やってますみたいな人とか、普通の会社員の人とか、マイクロソフト社にお勤めの人とか、大学生でプログラミングの勉強してますとか、いろんな人がいて、話しを聞いてみて、私が普段関わっている業界の内容ではなかったのでそれはそれで楽しかった。若い人たちは twitter をフォローしてくださいと qr コードで相互フォローをお願いしていた。twitter に qr コードを表示する機能があったんだと初めて知った。しかし、私だけ鉄の意志でやらなかった。スマホに twitter アプリ入れてないし。私が普段参加している 三宮.dev というコミュニティがある。少し前にそこに参加された方がたまたまその場にいて、少し話してみて、その人は技術の話しをしたいのではなく、インフルエンサーになりたい人なんだなと感じた。twitter のフォロワーを集めるためにイベントやコミュニティに参加しているようにみえた。別にそれも悪いことではないけれど。

あと、たまたま私が話した人がそうだっただけかもしれないが、あるベンチャー企業の社長が2つの目的、仕事をもらうのと採用のためにここに来てますと話していて、それ自体は悪くないと思うのだけど、そういう人が来るところに私は行かないなと率直に感じた。プレオープンイベントに参加した雰囲気だと、異業種交流会のような性格が強かった。オーナーの関係者で〇〇の会社をやっていて協業できれば嬉しいですみたいな紹介があったりしたし、卓を囲む人同士で名刺交換しているのもみかけた。バーというのはそういう特性もあわせもっているのかもしれないけど、コミュニティではないなという印象を受けた。

神戸に IT 系の有名な会社やコミュニティはないよねというのは、私も感じている共通認識で、はっくばーがそういったコミュニティの役割になればいいんじゃないかと話す人もいた。一方で私はそうはならないだろうと思っている。相互協力のコミュニティというのはもちろん存在するけど、それはどちらかというとそうせざるを得ない事情があって成り立つ。神戸はまだまだ余裕のある都市なのでそんな様相にはならない。じゃあ、コミュニティはなにをもって形成されるかというとコンテンツ (そして、その先にある文化) だと私は考えている。コンテンツのないコミュニティに人は集まらない。

はっくばーが今後どういった活動をしていくのかはわからないけど、単なるビジネス出会い系の場だとしたら三ノ宮みたいな地方都市ではなく、東京や大阪のような大都市でやった方がうまくいく可能性は高いだろうと思う。東京の Hackers Bar がうまくいっているかどうかは知らないけど、東京ですらうまくいくかどうかわからないものを三ノ宮で成功させるのは難しいだろうという印象を私はもっている。