1時に寝て8時に起きた。朝から洗濯と掃除をしてた。姪の大学進学で下宿先を探しに来ると姉が言うからなんか手伝う必要あるのかなと午後は時間をあけてたけど、そうでもなかった。

2021年度の個人の確定申告

夕方から確定申告の作業を始めた。毎年 freee で1ヶ月だけ契約して確定申告の書類を作っている。データ入力の作業は次の2つだけ。

• 印税の源泉徴収税の明細作成
• 寄付金の明細作成

書籍の印税収入が定期的に振り込まれる。印税収入は源泉徴収済みとなる。銀行 (出版社) からの明細取り込みに対して、印税と源泉徴収税の明細に分割する必要がある。今年は3社から印税があって、それぞれ数件程度の明細を作成した。クレジットカードで寄付金を支払っているものは明細連携できていないので12ヶ月分の明細を手入力することになる。言うても、それは1団体だけなので12個の明細だけ。会社を作る前は技術書の購入や勉強会の参加費や交通費 (新幹線とか) などにかかった経費なども明細登録していたけど、いまは会社の経費ですべて計上しているので個人で計上するものはなくなった。会社の経費はクレジットカード連携できているし、日々のお仕事で会計処理しているから、確定申告のタイミングでまとめて作業する必要はなくなった。

あと2021年度から 小規模企業共済 に入った。最小1000円/月から最大7万円/月の掛け金を選択する。いくらぐらいが妥当かわからなかったのでひとまず4万円/月で運用している。もちろん掛け金は変更できるが、基本的に20年とか掛け続けるもので、支払った金額は戻ってこないので、あるとき大きなお金が必要となっても融通できない貯金があるみたいものになってしまう。その分のメリットとして、所得控除の対象となる。加入シミュレーション があるので、自分の条件にあわせてやってみるとおもしろい。例えば、納付月数240ヶ月、掛け金7万円/月、課税所得400万円で算出すると24万円/年の節税となる。課税所得が減るので所得税だけでなく住民税も節税となる。

23時に寝て8時半に起きた。夜中に胃酸が逆流してむせてしんどかった。

ストレッチ

先週の日曜日に自転車でこけて胸を強打してまだ治りきっていない。トレーナーさんに伝えたら主に足のストレッチを重点にしてくれた。今週は2日間ストレッチをやったんだけど、今日の開脚幅は開始前166cmで、ストレッチ後169cmだった。先週と同じなので現状維持といったところ。悪くない数字ではある。今日は左のお尻の後ろの筋肉の張りと右太ももの後ろの筋肉の張りが強かった。

見積もりとは

昨日の バーンダウンしないチャート に関連して「見積もりとはなにか」というタイトルでつらつらと書き始めたら6000文字ほど書いてた。当初はお手伝い先の wiki に書こうと思って書き始めたものの、アウトラインと言いたいことをまとめたら、とくに機密情報はほとんどないことに気付いて、自分のブログのどこかにまとめ直そうと思った。社内向けに書こうとすると、実務の具体例をベースにして自分の論理や考察を展開し、最終的には提案の説得力を高めようと構成する。一方で社外向けに書こうとすると、社内の関係者に対してハラスメントにならないように配慮して書くのをやめた内容を一般論という立て付けで構成できる。文章を書くときに誰向けに書くかは、内容が同じでも話の展開や構成に影響を与えるということにふと気付いた。また数日以内にはどこかのブログに書き直す。

0時に寝て4時に起きてドラクエタクトしたり twtter 眺めたりして金朝ツメトギで DX 実践手引書 を読んでた。

スプリントの残チケット

スクラム開発でバックログのバーンダウンチャートを表示させるために、スプリントに対して、同じ期間のマイルストーンを設定するように運用が変わった。運用変更に伴い、バーンダウンチャートも表示されるようになり、スプリントの進捗状況の見える化が進められた。そのバーンダウンチャートの運用について SM と話していて、私の過去の開発とスプリントの考え方の大きな違いを発見した。

私がこれまでやってきた開発はマイルストーンの日には残チケットがゼロになるように開発していた。開発が遅延してそのマイルストーンで完了しそうにないチケットはどこかのタイミングで次のマイルストーンに先送りさせることで、いまやっているマイルストーンの開発が計画通りに完了するよう調整していた。作業が期限までに間に合わないチケットは早めに検知して報告して対応を検討する。一般論として、遅延したときは期限を延期するか、次のマイルストーンに先送りするかのどちらかしかない。

スクラムの場合、PO はスプリントを中止する権限をもっているが、基本的にスプリントの計画は変更しない。スプリント内でマイルストーンに間に合わないチケットがわかっていても、マイルストーンは変更せず、次のスプリントプランニングまで放置して、次のスプリントプランニングで遅れたチケットの作業を中止するか、引き続きやるかを検討するという。このやり方だと、スプリント終了日 (マイルストーンの日) に遅延して完了できないとわかっているチケットがすべて残ってしまう。当然バーンダウンチャートはバーンダウンしない。

一方でこれまでマイルストーンこそ設定していなかったものの、様々な理由でスプリントでやる予定だったチケットが遅延することは度々あった。それはデイリースクラムで遅れますとか、予想外のタスクが出てきましたとか、そういう報告をもって実運用では次のスプリントに持ち越ししていた。実運用では持ち越ししているのに、マイルストーンを変えるのは計画の変更だからやってはいけないという話しになって、見える化したのにバーンダウンしないチャートがあって、この運用に何の意味があるのだろう？わからなくなった。

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

ドキュメント作成

今週はあまり開発せず、バックログの wiki にドキュメントを書いてた。バックログの wiki は慣れると書きやすいし、Backlog Power Ups の chrome 拡張をインストールすると PlantUML で UML もレンダリングできる。ドキュメントの階層化はタイトルに / で区切ってグルーピングするというちょっと変なやり方。wiki のタグはフィルター条件として使いやすいように思えた。添付画像のサイズ指定ができないか調べてたら、ヌーラボコミュニティがあることに気付いた。せっかくなので 改善要望 を投稿しておいたけど、過疎っててあまり意味がないかもしれない。

0時に寝て4時半に起きてドラクエタクトを1時間ほどやって寝て7時半に起きた。

課題管理の情熱

先日、行った 3ヶ月フィードバック はスクラムマスターには好評だったらしく、他にも3人ほど読んでくれた人たちがいたようだ。いま課題管理のボードの整理をしたり、wiki のドキュメント階層を整理したり、情報共有や書く文化の重要性を説いたり、チームに私のやり方を見本のように示している。チームにも、私のチケットはコメントの量が大幅に違うということは認識され、それを見様見真似でやり始める開発者も現れ始めている。誰もが最初はお手本を模倣しながら学ぶ。いままで課題管理と情報共有というコンテキストで見本を示せる開発者がいなかっただけという話だ。

ふと、なぜ私はここまで課題管理やドキュメントなどを整理したがるのか、自分で考えてもよくわからない。強いて言うと、自分が働く環境やツールに関心をもっていて、それをいまよりもより良く改善したいという気持ちが他人よりも強いのかもしれない。働くからにはよいものを作りたい、ひいてはよい環境があればよいものを作れる、よい環境を作るための投資は惜しまないという姿勢から、課題管理のワークフローと情報共有の最適化を常に考えながら実践している気がする。もっと端的には言えば、仕事がどうこうというのは全く関係なく、日々の活動に関心をもっていると言えるのかもしれないなと思ったりした。採用における特性をみるときの1つの指標として生きていることに関心をもっているか、どういう行動を取っているかとかをヒアリングしてもおもしろいのかもしれない。

23時に寝て4時半に起きた。昨日の帰りに自転車でこけて胸を強打してひたすら痛い。起き上がるのも痛い。安静にしてた。

kubernetes のログ管理と datadog-agent のログ連携不具合

先日、datadog にログ連携されていない不具合 が発生していて、その1次調査を終えたことについて書いた。緊急対応としては datadog-agent を再起動することで改善することはわかっていたので、その後、kubernetes のログ管理と datadog-agent がどうやって kubernetes クラスター上で実行されているアプリケーションのログを収集しているかを調査していた。今日は wiki に調査してわかったことなどをまとめていた。

kubernetes クラスターはコンテナランタイムに docker を使っていて、アプリケーションの stdout/stderr を docker の logging driver にリダイレクトし、JSON Lines に設定された logging driver が kubernetes ノード上にログファイルとして出力する。datadog-agent は autodiscovery 機能で pod の情報を常にポーリングしていて、pod が新たにデプロイされたらログファイルを pod 内にマウントして、そのマウントしたログファイルを読み込んでログ収集していると思われる。datadog-agent から pod の情報を取得するには kubernetes のサービスアカウントを使っていて、その credential が projected volume としてマウントされて pod 内から利用できる。その credential を使って kubelet api にリクエストすることで pod の情報を取得している。

文章で書けばたったこれだけのことなんだけど、たったこれだけのことを理解するのに次のドキュメントを読んだ。実際の調査のときはわからなかったのでもっと多くのドキュメントを読んでいる。いま書いたことを理解するならこのドキュメントを読めば理解できるはず。

• https://kubernetes.io/docs/concepts/overview/components/
• https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/
• https://kubernetes.io/docs/concepts/cluster-administration/logging/
• https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
• https://kubernetes.io/docs/concepts/storage/projected-volumes/
• https://docs.datadoghq.com/agent/kubernetes/log/?tab=helm
• https://docs.datadoghq.com/getting_started/agent/autodiscovery/?tab=kubernetes

ドキュメントに書いてあることを深く理解するために、kubernetes と datadog-agent のソースコードも読んだ。どちらも go 言語で実装されている。

• https://github.com/kubernetes/kubernetes
• https://github.com/DataDog/datadog-agent

kubectl logs の振る舞いを確認するだけでも、ソースコードからは実際のログファイルを open してストリームを返しているところはわからなかった。api 呼び出しが連携されて抽象化されていて、コンポーネントの役割分担があって、何も知らずにコードを読んでいてもわからなかった。Kubernetes の低レイヤーのところは Container Runtime Interface (CRI) という標準化を行い、1.20 から docker は非推奨となり、将来的に CRI を提供する実装に置き換わるらしい。ログファイルを open する役割は CRI の実装が担うんじゃないかと思うけど、そこまでは調べきれなかった。また機会があれば CRI の実装も読んでみる。