0時に寝て4時に起きて6時半に起きたつもりが、なんか3度寝して8時に起きた。

スライドマスターのデザイン作成

うちの会社のロゴは Ševarika™ というデザイナーさんに作ってもらった。言語にセルビア語とあるので旧ユーゴスラビア地域の国の出身なのかなと推測する。このご時世なので NATO 加盟国なのだろうか？とか調べてみたけど、旧ユーゴスラビア地域の国々の歴史は複雑ですぐにわかるものではなかった。閑話休題。私は会社のロゴをとても気に入っているし、ロゴを作ってもらうときの取り引きも円滑にできたのでそのデザイナーさんを信頼している。今回も2年半ぶりに連絡をとったら快くスライドマスターの作成を引き受けてくれた。4月30日に契約して、とくに急いでいないのでデザイナーの都合がついたらでという緩い依頼をしたんだけど、昨日さっそく最初の草稿が届いた。いくつか私の好みのスライドデザインのサンプルを渡したりしていたので、私の好みのスタイルは外していない。ただ私はデザインのことは何もわからないので、今回は顧問のはらさんにもレビューしてもらってご意見をもらうことにした。

ベースライン移行

先日の flyway のデータベース移行 の続き。管理しているマイクロサービスが4つあるのでそれぞれのサービスごとに設定していかないといけない。サーバーサイドって共通化できるのが大きなメリットなのに、同じサーバーサイドの仕組みを複数導入しないといけないというのはマイクロサービスのデメリットと言えばそうだし、アーキテクチャとしても正しいんやろか？という気持ちも出てくる。おそらく1つのチームが複数のマイクロサービスを開発する体制がよくない。変更作業と検証で約1日を費やした。

0時に寝て5時半に起きた。実家にいると、親が5時ぐらいから起き始めるのでつられて早めに起きている。親が8時からアルバイトなのでそのタイミングでバス停に送ってもらって9時半には戻ってきた。

消費税申告書と欠損金の還付請求書の作成

先日から 法人決算に着手 していた。

まずは消費税の申告書と未払い消費税の振替伝票の起票をしていた。初めての会計処理でいろいろ調べてた。No.6610 法人に係る消費税の確定申告書の提出期限について によると、消費税の申告期限も法人決算と同様、課税期間 (事業年度) の終了の日から2ヶ月以内に行う必要がある。厳密には消費税にも2種類あって国税と地方税にわけられる。地方消費税は国税ではなく地方税であるため、本来は都道府県に納税すべきものではあるが、手続きの利便性のため？なのか、国税と一緒に所管税務署へ納付するのでよいらしい。

• 消費税とは？地方消費税とは？

つぎに前期は赤字なので前々期に支払った法人税と地方法人税の一部を還付してもらう。前々期の所得と支払った法人税、前期の欠損金 (マイナスの所得に対する法人税法上の用語) の3つの数字があれば算出できる。計算してみたら支払った法人税のうち26.4%を還付できることがわかった。算出後に請求書をダウンロードして書類に数字を記入した。

ストレッチ

いつもは土曜日の10時に通っているが、実家に帰っていたので予定変更。今日から新しいトレーナーさんに師事することになる。今日の開脚幅は開始前160cmで、ストレッチ後162cmだった。昨日、草刈りをして筋肉痛になっていたのでそんなもんかな。腕と腰に張りがあった。新しいトレーナーさんも初めてなのでまずはどこの筋が張っていて、どこの関節が詰まっているかを確認しながら進めていくといった感じだった。話しを聞いていたら、新しいトレーナーさんも前のトレーナーさん同様、筋トレをしていて、週3日ぐらいはやっているらしい。やっぱりトレーナー業をする人は筋トレに興味をもつ人が多いのかもしれない。

1時に寝て4時に起きて6時半に起きた。なんか寝付けない。とくに用事があるわけでもないのだけど、たまに実家に帰らないといけないので帰る。病院へお見舞い行って、草刈りして、焼肉食べて、温泉入って実家でくつろいでた。

アボカドを植える

1ヶ月半前から水耕栽培を始めたアボカドの種から根が出始めた。いくつか持って帰って土に植えてもらうことにした。ライフ に売っているアボカドは他のスーパーよりも100円ぐらい高いけれど、ハズレがなくておいしい。アボカドはライフでしか買わなくなった。そのアボカドの種なのできっとおいしいアボカドの木になるはず。種から育てると実をつけるには10年ぐらいかかるという。さらに1年おきしか実をつけないみたい。実をつけなくても観葉植物として育てるという趣もあるみたい。

• アボカド栽培に挑戦！種から収穫までの上手な育て方をご紹介！剪定方法のコツも！

0時に寝て4時に起きてタイムライン眺めながらだらだらして6時半に起き上がった。

データベースの移行処理

半年前から導入したいという話しは聞いていたものの、先送りになっていたライブラリに flyway がある。データベースの移行処理のためのスクリプト (sql) を管理するツールでどの移行スクリプトを実行したかを記録したり、未適用の処理を自動で適用してくれたりする。spring boot だとすぐ組み込める状態になっていて Community Plugins and Integrations: Spring Boot をみながら設定したらすぐに動いた。flyway 自体の設定も Common Application Properties を参考に spring boot の設定ファイルで行える。

例えば、こんな感じ。

spring:
  flyway:
    enabled: true
    schemas: public
    locations: classpath:db/migration
    baseline-version: 0
    baseline-on-migrate: true

移行処理の履歴情報は flyway_schema_history テーブルに保持される。既存のテーブルが存在して flyway の履歴データがない場合 (初回起動時) に移行処理を実行するかどうかを baseline-on-migrate で決める。実行するなら baseline-version でどのバージョンをベースラインとするかも設定できる。ゼロにすることで V1 からの sql ファイルを適用してくれる。ベースラインの考え方は実際に何度かデータベースの初期状態を変えて実行しないとわかりにくいかもしれない。

• Tutorial: Baseline Migrations

夜眠れなくてだらだらして朝もだらだらしてからお昼前ぐらいにオフィスに行った。

法人決算

ようやく着手した。今日のところは前期の所得を求めて各種法人税の算出をした。所得を算出し終えて初めて決算書を作成できる。と言っても、前期は当社初の赤字となった。そのため、均等割以外の法人税はすべてゼロになる。法人県民税と法人市民税の均等割を合計すると7万2千円を納める必要がある。この税金は会社が赤字であろうと必ず支払う必要がある。他の法人税、地方法人税、法人事業税、特別法人事業税、法人県民税と法人市民税の法人税割は所得に対して税率を課すものなので赤字 = 所得がマイナスならゼロになる。ないに越したことはないけど、今後も赤字決算はあるかもしれないので今回は赤字決算のときの税制や会計処理について学ぶ機会となる。その1つとして前々期に納めた法人税を還付する仕組みがある。

• No.5763 欠損金の繰戻しによる還付

あと赤字でも支払う必要のある税金として消費税がある。これも3期目から支払う必要があるため、今回が初めてとなる。算はすべて会計システムがやってくれるので私がやることは書類を作ったり、実際の手続きをするだけだとは思う。ちなみにうちは簡易課税で消費税を支払う。その方が節税になることは インボイス制度を調べていた ときにも書いた。

0時に寝て7時に起きた。祝日なので朝は掃除したり洗濯したりしてた。

yuga labs は未来の gafa かもしれないらしい

中島聡氏が voicy を始められたのでたまに聴いている。とくに web3 関連の信頼できる情報源として聴いている。

• 僕らはweb3時代のGAFAの誕生を目撃しているのか？

氏は yuga labs は技術というよりはマーケティングの会社だと言いながら、どういうマーケティング施策でいまのような人気企業になったかを簡潔に説明されていた。yuga labs という会社名だけは知っていたが、どういう会社かはまったく知らなかったので私は勉強になった。yuga labs のやっていることは中長期でみればポンジ・スキームだと指摘しつつも、その胡散臭さを上回る優れたマーケティング施策で注目を集めているという。yuga labs が手がける nft やメタバースや暗号資産なども高騰していて、実際にそのマーケティング施策で億り人になった人たちも数千人規模で出ていて、今後の動向に期待が集まっているらしい。シリコンバレーのトップレベルの vc も資金を投入しているので vc の思惑からも次の gafa のような期待感があると受け取ることもできるらしい。yuga labs が手がけるメタバースプロジェクトの土地売買で起こった事件なども紹介されていた。あとは2-3年はこういったバブルが続くのかなぁ。

• Yuga Labs、仮想不動産NFT販売で3.2億ドル相当獲得　“ガス代急騰”の影響に謝罪

頭の中の最上位にあるアイデア

たまたまタイムラインでポール・グレアムの 頭の中の最上位にあるアイデア というエッセイを知った。ざっと斜め読みして、私の経験や価値観にも合致する内容だったので印象に残って後から精読した。

学生の頃、原付きの整備士のアルバイトをしていた。そのバイク屋の社長はアウトローな人生を歩んできた方で、私は破天荒な社長の生き様が好きでよく話を聞いて感心していた。あるとき草津から彦根までバイクを届ける遠出の運搬作業があって、トラックで社長と2人で出掛けたことがあった。雨降りの日だった。私は助手席で社長の話し相手をしていただけだったんだが、こんな話しをされた。

若い頃に5年働いてようやく100万円の貯金ができた。すでに妻子もいた。そのときに友だちに騙されて1500万円の借金を背負った。5年働いて100万円しか貯金できなかったのだから、もう人生終わりだと思って、自分を騙したその友だちを殺して自殺しようと思った。しかし、母親に諭されてその友だちを殺すことは思い留め、それから死ぬ気で働いたら2年で1500万円の借金をすべて返すことができた。

社長がどうやって借金を返したかの詳細は知らないし、相当の苦労や無理をしたことには変わらないだろう。そのときに続けて社長が言ったことはこんなことだった。

24時間365日、お金儲けのことばかり考え続けていたらなんか思いつくものなんや

ポール・グレアムのエッセイを読んで社長はこのことを言ってたんだなといま思い返した。私も何度かそういう機会を経験していて、全くわからない難しい問題に直面したとき、納期や品質を担保できそうにないプロジェクトを担当しているとき、課題に着手し始めたときの本音は無理やと思いつつも、どうやったらうまくいくかというのをずっと考え続けているうちに、難しい問題の解決方法がわかってしまったり、トラブルプロジェクトでもそれなりにうまくまわったりした。

いまは課題管理をどうやってビジネスとしてマネタイズ化するかを常に考えている。たまにアイディアがふっと湧いて、その内容を課題管理システムに起票したり、既存チケットのコメントに書き込んだりする。平均すると、1-2週間に1回ぐらいのコメントなんだけど、これを1年ほど続けているというのがいまの状態だ。これを2年3年と続ければ、ビジネスのアイディアが溜まることを経験的に理解しているからいまもずっと課題管理について考え続けている。

marketplace への公開

pull request と push イベントに対応して基本機能は実装できたとみなし、v1 のタグ/ブランチを作成して marketplace に公開した。backlog と連携するカスタム action はすでにいくつかあるのだけど、pull request か push イベントのどちらかしか対応していなかったり、説明が日本語で書かれていて日本人向けしか対象としていないものしかない。グローバル向けの今後も要件次第で拡張可能なカスタム action はこれしかないと、ポジショントークも含めて言っておこう。ちょうどこみやさんも関心をもっているのでまた機会があれば使い方の説明とかやりますよと伝えた。まずは会社のメンバーに紹介してくれるらしい。使ってくれる人が増えると嬉しいなぁ。

• https://github.com/marketplace/actions/backlog-github-integration-action

リリース作業をしていてその内容について mermaid 記法を使って簡単なフローチャート図やシーケンス図も書いてみた。感覚的には plantuml で書くのと大差ないので github がサポートしているネットワーク効果を考えると、今後は mermaid を積極的に活用していくのもよいかもしれない。

打ち合わせ資料の作成

先日 第3期のふりかえり は行ったが、第4期の展望はできなかったので次回の打ち合わせのための資料を作った。今期も普通に業務委託をするだけではあるものの、今後のキャリアのために grpc の開発/運用経験を積む必要があることに気付いた。他人に話す機会があって、そのための資料を作ってみて、当たり前の抜け・漏れに自分自身で気付けるというのが思考の外在化のよいところと言える。誰かに指摘されればすぐ気付くことを自分自身で気付くのは意外と難しかったりする。特定技術を狙って案件を探すのはあまりうまくいかない。本来はビジネスがあって、それを実現するために技術を選ぶのであって、その逆ではないから。周りの友だちや知人に聞いてみるかなぁ。

23時に寝て5時に起きて2度寝して6時に起きた。今年の連休はカレンダー通りに過ごすので月曜日と金曜日の飛び石のお仕事。

開発メンバーの加入

今日から開発者が新たに加わった。6月から正社員になるそうだけど、手続きの問題なのか、5月から1ヶ月間は業務委託として働くという。正社員の開発者がいないために要件定義がうまく進まず、外部の協力会社の開発者が遊休するといった状況があったのだけど、それが改善されていくかもしれない。聞くところによると、シニア開発者らしいのでこれからバリバリ活躍されるはず。一方で1つのチームの開発者が6人というのは中途半端なサイズにもみえる。2チームに分割した方が実際の作業はやりやすいかもしれない。

slack と backlog の連携

backlog の rest api を使って課題一覧に定型的なフィルター処理を実行してその結果を slack に通知したい。日々のスクラムイベントで画面をぽちぽちしながらチェックするのにそろそろ飽きてきた。運用が熟れて、みないといけない課題のフィルター条件が明確になったとも言える。こういうのを人間が手作業でフィルターするのをやめて誰でも操作できて、頻繁に目に付くようにすることでメンバーの運用に変化をもたらす。人間の行動や運用を変えるのは並大抵のことではないので、こういった小さな気づきを絶え間なく与え続けることが大事だと私は考えている。気付く人はすぐに気付く。もちろんそうじゃない人もいるが。

backlog 公式 slack app は backlog で発生したイベントに対するデータを通知することしかできない。たぶん機能拡張されることもなさそうなので足りない機能は自分で作るしかない。当初は知人が働いている会社の次の記事を読んで aws chatbot を使おうと考えていた。

• プロジェクトにChatOpsを導入してみる

いろいろ調べてみると、chatbot は基本的に aws とのサービス連携を前提としたものだとわかった。もちろん lambda と連携することで backlog の rest api を呼び出すことはできるだろうけど、backlog にアクセスしたいだけなら最初から slack apps を自前で作ってそこから backlog の rest api を使った方が構成がシンプルでカスタマイズもしやすいのではないかと思えてきた。slack apps をどこにどうやってデプロイするかは検討課題と言える。lambda にデプロイすることもできるし、専用に ec2 インスタンスを設けてもいいかもしれない。すぐには結論が出ないのでデプロイは作った後で考えることにする。

次にサードパーティの slack apps のセキュリティはどうやって担保するのだろう？と調べてみた。slack 社もレビューはするけど、セキュリティを保証するものではない。適当にググってみつかった記事を読んでみても、基本的に悪意のない slack apps かどうかを検証する方法はなさそう。slack のメッセージを不正な用途に使われる可能性があるというリスクを受け入れつつ、サードパーティの slack apps をインストールするときに権限が適切かどうかを確認するぐらいしかできない。

• Slack App Security Review
• Third-Party Apps on Slack: Lurking Data Security Threat

従って、サードパーティ製の backlog slack apps を作ろうと思ったらソースコードを公開して悪意がないことを訴求するぐらいしかできることはなさそうにみえる。ソースコードを公開しておけば、それぞれの組織内でデプロイする手段も取れる。当社のプロダクトとしてクラウド上にパブリックに公開するかどうかはある程度、作り込んでから後で考えることにする。github のカスタム action は java で作ったけど、今回は go で作ろうと思う。