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 ファイルを適用してくれる。ベースラインの考え方は実際に何度かデータベースの初期状態を変えて実行しないとわかりにくいかもしれない。
夜眠れなくてだらだらして朝もだらだらしてからお昼前ぐらいにオフィスに行った。
ようやく着手した。今日のところは前期の所得を求めて各種法人税の算出をした。所得を算出し終えて初めて決算書を作成できる。と言っても、前期は当社初の赤字となった。そのため、均等割以外の法人税はすべてゼロになる。法人県民税と法人市民税の均等割を合計すると7万2千円を納める必要がある。この税金は会社が赤字であろうと必ず支払う必要がある。他の法人税、地方法人税、法人事業税、特別法人事業税、法人県民税と法人市民税の法人税割は所得に対して税率を課すものなので赤字 = 所得がマイナスならゼロになる。ないに越したことはないけど、今後も赤字決算はあるかもしれないので今回は赤字決算のときの税制や会計処理について学ぶ機会となる。その1つとして前々期に納めた法人税を還付する仕組みがある。
あと赤字でも支払う必要のある税金として消費税がある。これも3期目から支払う必要があるため、今回が初めてとなる。算はすべて会計システムがやってくれるので私がやることは書類を作ったり、実際の手続きをするだけだとは思う。ちなみにうちは簡易課税で消費税を支払う。その方が節税になることは インボイス制度を調べていた ときにも書いた。
0時に寝て7時に起きた。祝日なので朝は掃除したり洗濯したりしてた。
中島聡氏が voicy を始められたのでたまに聴いている。とくに web3 関連の信頼できる情報源として聴いている。
氏は yuga labs は技術というよりはマーケティングの会社だと言いながら、どういうマーケティング施策でいまのような人気企業になったかを簡潔に説明されていた。yuga labs という会社名だけは知っていたが、どういう会社かはまったく知らなかったので私は勉強になった。yuga labs のやっていることは中長期でみればポンジ・スキームだと指摘しつつも、その胡散臭さを上回る優れたマーケティング施策で注目を集めているという。yuga labs が手がける nft やメタバースや暗号資産なども高騰していて、実際にそのマーケティング施策で億り人になった人たちも数千人規模で出ていて、今後の動向に期待が集まっているらしい。シリコンバレーのトップレベルの vc も資金を投入しているので vc の思惑からも次の gafa のような期待感があると受け取ることもできるらしい。yuga labs が手がけるメタバースプロジェクトの土地売買で起こった事件なども紹介されていた。あとは2-3年はこういったバブルが続くのかなぁ。
たまたまタイムラインでポール・グレアムの 頭の中の最上位にあるアイデア というエッセイを知った。ざっと斜め読みして、私の経験や価値観にも合致する内容だったので印象に残って後から精読した。
学生の頃、原付きの整備士のアルバイトをしていた。そのバイク屋の社長はアウトローな人生を歩んできた方で、私は破天荒な社長の生き様が好きでよく話を聞いて感心していた。あるとき草津から彦根までバイクを届ける遠出の運搬作業があって、トラックで社長と2人で出掛けたことがあった。雨降りの日だった。私は助手席で社長の話し相手をしていただけだったんだが、こんな話しをされた。
若い頃に5年働いてようやく100万円の貯金ができた。すでに妻子もいた。そのときに友だちに騙されて1500万円の借金を背負った。5年働いて100万円しか貯金できなかったのだから、もう人生終わりだと思って、自分を騙したその友だちを殺して自殺しようと思った。しかし、母親に諭されてその友だちを殺すことは思い留め、それから死ぬ気で働いたら2年で1500万円の借金をすべて返すことができた。
社長がどうやって借金を返したかの詳細は知らないし、相当の苦労や無理をしたことには変わらないだろう。そのときに続けて社長が言ったことはこんなことだった。
24時間365日、お金儲けのことばかり考え続けていたらなんか思いつくものなんや
ポール・グレアムのエッセイを読んで社長はこのことを言ってたんだなといま思い返した。私も何度かそういう機会を経験していて、全くわからない難しい問題に直面したとき、納期や品質を担保できそうにないプロジェクトを担当しているとき、課題に着手し始めたときの本音は無理やと思いつつも、どうやったらうまくいくかというのをずっと考え続けているうちに、難しい問題の解決方法がわかってしまったり、トラブルプロジェクトでもそれなりにうまくまわったりした。
いまは課題管理をどうやってビジネスとしてマネタイズ化するかを常に考えている。たまにアイディアがふっと湧いて、その内容を課題管理システムに起票したり、既存チケットのコメントに書き込んだりする。平均すると、1-2週間に1回ぐらいのコメントなんだけど、これを1年ほど続けているというのがいまの状態だ。これを2年3年と続ければ、ビジネスのアイディアが溜まることを経験的に理解しているからいまもずっと課題管理について考え続けている。
pull request と push イベントに対応して基本機能は実装できたとみなし、v1 のタグ/ブランチを作成して marketplace に公開した。backlog と連携するカスタム action はすでにいくつかあるのだけど、pull request か push イベントのどちらかしか対応していなかったり、説明が日本語で書かれていて日本人向けしか対象としていないものしかない。グローバル向けの今後も要件次第で拡張可能なカスタム action はこれしかないと、ポジショントークも含めて言っておこう。ちょうどこみやさんも関心をもっているのでまた機会があれば使い方の説明とかやりますよと伝えた。まずは会社のメンバーに紹介してくれるらしい。使ってくれる人が増えると嬉しいなぁ。
リリース作業をしていてその内容について mermaid 記法を使って簡単なフローチャート図やシーケンス図も書いてみた。感覚的には plantuml で書くのと大差ないので github がサポートしているネットワーク効果を考えると、今後は mermaid を積極的に活用していくのもよいかもしれない。
先日 第3期のふりかえり は行ったが、第4期の展望はできなかったので次回の打ち合わせのための資料を作った。今期も普通に業務委託をするだけではあるものの、今後のキャリアのために grpc の開発/運用経験を積む必要があることに気付いた。他人に話す機会があって、そのための資料を作ってみて、当たり前の抜け・漏れに自分自身で気付けるというのが思考の外在化のよいところと言える。誰かに指摘されればすぐ気付くことを自分自身で気付くのは意外と難しかったりする。特定技術を狙って案件を探すのはあまりうまくいかない。本来はビジネスがあって、それを実現するために技術を選ぶのであって、その逆ではないから。周りの友だちや知人に聞いてみるかなぁ。
23時に寝て5時に起きて2度寝して6時に起きた。今年の連休はカレンダー通りに過ごすので月曜日と金曜日の飛び石のお仕事。
今日から開発者が新たに加わった。6月から正社員になるそうだけど、手続きの問題なのか、5月から1ヶ月間は業務委託として働くという。正社員の開発者がいないために要件定義がうまく進まず、外部の協力会社の開発者が遊休するといった状況があったのだけど、それが改善されていくかもしれない。聞くところによると、シニア開発者らしいのでこれからバリバリ活躍されるはず。一方で1つのチームの開発者が6人というのは中途半端なサイズにもみえる。2チームに分割した方が実際の作業はやりやすいかもしれない。
backlog の rest api を使って課題一覧に定型的なフィルター処理を実行してその結果を slack に通知したい。日々のスクラムイベントで画面をぽちぽちしながらチェックするのにそろそろ飽きてきた。運用が熟れて、みないといけない課題のフィルター条件が明確になったとも言える。こういうのを人間が手作業でフィルターするのをやめて誰でも操作できて、頻繁に目に付くようにすることでメンバーの運用に変化をもたらす。人間の行動や運用を変えるのは並大抵のことではないので、こういった小さな気づきを絶え間なく与え続けることが大事だと私は考えている。気付く人はすぐに気付く。もちろんそうじゃない人もいるが。
backlog 公式 slack app は backlog で発生したイベントに対するデータを通知することしかできない。たぶん機能拡張されることもなさそうなので足りない機能は自分で作るしかない。当初は知人が働いている会社の次の記事を読んで aws chatbot を使おうと考えていた。
いろいろ調べてみると、chatbot は基本的に aws とのサービス連携を前提としたものだとわかった。もちろん lambda と連携することで backlog の rest api を呼び出すことはできるだろうけど、backlog にアクセスしたいだけなら最初から slack apps を自前で作ってそこから backlog の rest api を使った方が構成がシンプルでカスタマイズもしやすいのではないかと思えてきた。slack apps をどこにどうやってデプロイするかは検討課題と言える。lambda にデプロイすることもできるし、専用に ec2 インスタンスを設けてもいいかもしれない。すぐには結論が出ないのでデプロイは作った後で考えることにする。
次にサードパーティの slack apps のセキュリティはどうやって担保するのだろう？と調べてみた。slack 社もレビューはするけど、セキュリティを保証するものではない。適当にググってみつかった記事を読んでみても、基本的に悪意のない slack apps かどうかを検証する方法はなさそう。slack のメッセージを不正な用途に使われる可能性があるというリスクを受け入れつつ、サードパーティの slack apps をインストールするときに権限が適切かどうかを確認するぐらいしかできない。
従って、サードパーティ製の backlog slack apps を作ろうと思ったらソースコードを公開して悪意がないことを訴求するぐらいしかできることはなさそうにみえる。ソースコードを公開しておけば、それぞれの組織内でデプロイする手段も取れる。当社のプロダクトとしてクラウド上にパブリックに公開するかどうかはある程度、作り込んでから後で考えることにする。github のカスタム action は java で作ったけど、今回は go で作ろうと思う。
23時に寝て1時に起きて3時に起きて7時に起きた。
今日の開脚幅は開始前162cmで、ストレッチ後163cmだった。先週より少し数値がよくなった。相変わらず背中や腰の張りは強くてストレッチしてもらっていてなかなか辛かった。昨日は祝日だから早めに切り上げてゆっくりしてたし、ワクチン接種後というのもあるけど、最近は睡眠時間を多く取るようにして安静な生活を送ってたりする。それでもどこかしら張りがあったりする。ストレッチを受けると毎日座ってお仕事をすることの負荷を実感できる。
今日で1年以上ストレッチをしていただいた トレーナーさんが転勤 で最後。おかげで私は健康に過ごせているので感謝しかない。新しい環境でも活躍してほしい。来週から新しいトレーナーさんになる。それはそれで相対比較ができるのでトレーナーさんの違いもわかると思うから楽しみ。
少し前に対応したんだけど、backlog-github-integration-action でコミット連携ができるようになった。
そのことをブログの記事にも書くことにした。1時間もあれば書いてしまえる内容なのに英語で書くというだけで後回しにしてしまう。私は英語を書くときは Grammarly と DeepL を使って書いている。自分の言いたいことを Grammarly で構文チェックしながら書いて、それを DeepL で日本語訳して意味がとれるかどうかで内容があっているかの確認をするといった感じ。
23時に寝て5時に起きた。本当は夜に打ち合わせの資料を作らないといけなかったが、なんかだらだらやってそのまま寝て朝起きてから資料を作り始めた。今日は祝日だから業務委託のお仕事は完全に休むと決めた (非稼働日もデイリースクラムには参加するし、なんだかんだで軽いチケット整理や作業などはしている) 。その分の余裕が資料の作成を先延ばしにした気がする。
顧問のはらさんと隔週の打ち合わせ。今日の議題は会社の第3期 (前期) のふりかえりにした。半分ぐらいは資料はできていたものの、5時半ぐらいにはオフィスに行って6時過ぎから残りの部分を作り始めた。8時前には完成した。いつもは2-3日前には資料を提示するようにしていたが、今日は祝日でだらだらモードで1時間前 (打ち合わせは9時から) となった。はらさんも直前で資料に目を通してもらったが、こういうのはよくなかったと後で反省した。
資料を作っていて、ふと思い浮かんだ気づきの1つをあげる。
会社の銀行口座と自分の銀行口座残高がダブルでただひたすらに減額しているさまを見るのって普通にメンタルに良くないんですよね。しかも事業も全然伸びていきませんし…。
前期は3ヶ月ほど仕事をせずに遊んでいた。数字だけをみたら6ヶ月ほど遊んでいてもよい余裕はあったと言える。それでも3ヶ月ほど経ってから次のお仕事を探して、いま受託開発をしているのは 銀行口座の残高がダブルで減り続ける恐怖に抗うのが難しい からと言える。会社が倒産するわけでも、生活に困るわけでもなく、銀行口座の残高が減り続ける毎日が怖いという話し。「死の恐怖は死そのものよりも怖ろしい」と誰かの名言があるが、その経営者バージョンかもしれない。難しい判断は心身ともに落ち着いていて余裕をもった状態で下すのが望ましいと、誰もが頭では理解できるだろうが、実際に銀行の口座がずっと減り続けている状態でそう在れるかというのは別問題だという話し。無計画に仕事せずに遊ぶのは、うちの会社の場合は3ヶ月程度が限界だと分かった、というのが今期の財務における収穫と言える。
そんな1年を通したふりかえりを雑談してたら2時間ほど経過していた。また2週間後に第4期の展望をやることにした。
23時に寝て3時に起きて5時に起きて7時に起きた。なんか調子が微妙。
少し前だけど、jvm のセキュリティアナウンスがあった。
java 11 向けの docker イメージのビルドはあまり緊急度が高くなかったせいか、17よりは優先度が低かったようにみえる。docker イメージビルドの作業状況は次の issue で管理されている。
これまで adoptopenjdk/openjdk11:alpine-jre という docker イメージを使っていた。Transition to Eclipse - An Update によると、Eclipse Temurin という組織が管理する Adoptium というプロジェクトに移管されたらしい。この機会に docker イメージも eclipse-temurin:11-jre-alpine に移行した。
23時に寝て5時過ぎに起きた。
本番環境に初回デプロイして ecs から secrets manager のアクセスに失敗しているエラーが出ていたので調査した。エラーメッセージでググるとクラスメソッドさんの記事が出てきた。
この記事によると、次のどちらかの原因かなと推測していた。
調べども調べどもテスト環境との違いがわからなくてはまってしまった。ある検証をしていたときに、テスト環境を手動で構築した担当者から datadog の api key を設定してないんじゃない？と言われて、まさにそれが原因だった。cdk のコード上は設定済みのものとして ecs の datadog のサイドカーに設定していた。先入観で rds の credential 情報を取得できずにエラーになっていると思い込んでいたが、サイドカーの datadog の api key が原因ではまるべくしてはまったという感じ。
一方で secrets manager に登録するサードパーティの api key をどこで管理するかというのは難しい問題でもある。cdk のコードの中に書いてしまうというのも1つのやり方ではあるが、昨今の github 関連のサードパーティから派生したセキュリティインシデントで private リポジトリのソースコードにアクセスされることも発生しているのでソースコードには書きたくない。で、手動で secrets manager に設定しないといけないから、今回みたいな初回デプロイ時に誰も気付かないみたいなことが起きる。