テストコードのリファクタリング

0時に寝て6時に起きた。今日は7時半から23時過ぎまで集中してコードを書いてた。最近は19-20時には帰って、晩ご飯食べて、ドラクエタクトやったり漫画読んだりだらだらしている。そんな暇あったら積ん読の本読めって感じだ。

テストコードのリファクタリング

業務機能の開発をするにあたって、既存のテストコードをみていて、@BeforeEach というテストメソッド単位に呼ばれるメソッドでテストデータの削除と postgresql の sequence のリセット処理をしていた。こんなの共通処理ですべてのテーブルの truncate と sequence のリセット処理をすればいいやんとか思って、いろいろ調べて2つのリファクタリングの PR を作成した。先日 JUnit5 の拡張 を調べたばかりだから、テストの共通化のノウハウが溜まっている。Testcontainers Postgres Module と連携して、postgresql コンテナに接続して sequence のリセット処理を汎用のテスト拡張として実装した。テストを実装する開発者は、次のように @ExtendWith(DatabaseInitializer.class) をアノテーションに付与すれば、自分で sequence のリセット処理を @BeforeEach のメソッドに実装する必要がなくなる。

@SpringBootTest
@Transactional
@ExtendWith(SetupDatabaseContainer.class)
@ExtendWith(DatabaseInitializer.class)
class MyTest {
    ...
}

この作業の過程で spring boot の @Transactional はデフォルトでテストメソッドの実行後にロールバックする機能が提供されていて、いままで @BeforeEach のメソッドで明示的にテーブルのデータを削除する必要はなかったんやと気付いた。じゃあ、なぜ削除するコードを書いてたかと言うと、テストの外部で初期データを作成する仕組みがあるから、初期データを削除する目的でそうしていたことが判明した。そして、一部のコードはそこで作った外部の初期データに依存して実装されていた。テストコードの一部が外部のデータに依存しつつ、テストメソッドでは外部のデータに依存しないように削除のコードが書いてある。書いていて何を言っているのかわからないと思うけど、私も調べてて訳がわからんくて、PR に「いまの状況はかなりややこしい」と前置きしつつ、無駄なコードや仕組みを取り除くための修正を行った。本当は機能開発やらないといけないのにテストコードのリファクタリングするのに大きな時間をかけるわけにはいかないだろうという意図で、半日掛けてリファクタリングして23時過ぎまで作業して、既存のテストコードも含めて全部直した。このリファクタリングで数十のテストケースの約300行ぐらいの初期化コードをなくせた。

確定申告書類の印刷

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

確定申告書類の印刷

最近は遅くても8時、速かったら7時過ぎからお仕事している。ちょうど仕事の谷間で手持ちのタスクを終えてしまっていて、今日から別のタスクに着手する予定が、昨日から障害が発生していたらしく、朝忙しそうだったから11時まで確定申告の作業をしていた。昨日、データ入力は終えていたので総勘定元帳をみながら変な数字になっていないかをチェックしたり、源泉徴収税の還付金の計算があうかどうかを検算したりしていた。あとすでに廃棄した固定資産が残っていることに気付いた。耐用年数が過ぎた固定資産の価値は1円として管理される。これを備忘価格と呼ぶらしい。除却の手続きもした。ついでに 固定資産売却益(損)とは の会計手続きも調べたりしていた。

オフィスのプリンタで一通り書類を印刷した。あとは提出するだけ。昨年から住んでいるところの徒歩圏内に申告できる場所ができて、散歩のついでに確定申告する程度の手間しかかからない。このまま電子申告してもよいのだけど、寄付金控除のための領収書を写真か PDF ファイルなどで取り込む必要があって、それだけ面倒なので放置している。このまま今年も紙で提出してくるかなぁ。

業務システムの開発

twitter のタイムラインで業務システムの開発者は「業務系エンジニア」と呼ぶとか言っている人をみかけた。そっか、私は web エンジニアから業務系エンジニアになったんだー、web アプリケーション開発しているけどな、とか思いながら、今週からいよいよお手伝い先の業務システムの開発に着手する。いままでインフラやサーバーサイドのシステム寄りの保守や機能開発のみをしていた。さっそく DB スキーマの定義やドキュメントの書き方、作業の進め方などを確認していた。ひとまず1週間のスプリントで終えられそうなタスクなのでがんばってやりたい。

確定申告の準備

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つの指標として生きていることに関心をもっているか、どういう行動を取っているかとかをヒアリングしてもおもしろいのかもしれない。

wiki のドキュメント整理

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 の情報を取得している。

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

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

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

ヘルスチェックのレスポンスのステータスコード

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

404 のレスポンスをヘルスチェック

ここ数日はお仕事でインフラ周りの調査をしていた。たまたまログをみていて、ELB のヘルスチェックが 404 になっているのを大量にみつけた。てっきりヘルスチェックを使ってないのだろうと思ってインフラ担当者に問い合わせたら、404 が返ってくることをヘルスチェックしているという。404 をチェックすることになんの意味もなく、ただ急ぎで設定する必要があったからとりあえず動かせるためにそう設定したという。一方でアプリケーション側は spring boot で開発していて、Spring Boot Actuator も導入されているので /actuator/health にアクセスすれば 200 が返ってくるようになっている。どういう経緯だったかはわからないけど、開発者に一言聞けば 404 のレスポンスをヘルスチェックすることは何もない状態でずっと運用されていたことがわかった。

アプリケーション側の Kubernetes: Ingress のマニフェストにもそういった設定が入っていて、インフラ側の CDK のコードにもそういったマニフェストがあって、両方の設定変更が必要なのか、アプリケーション側のものだけでいいのか、少し調査が必要ということになった。私も Ingress というのがなにものなのか、よくわかってないので調べて理解する機会としよう。

3ヶ月フィードバック書いた

1時に寝て7時半に起きた。昨日も半日ぐらいはコードを書いてて pr の草稿を作って帰ってきたら23時ぐらいだった気がする。

3ヶ月フィードバック完了

先日、書き始めた 3ヶ月フィードバック を書き終えた。平日少しずつ書こうと思ってたんだけど、平日は疲れて書かなくて、休日にまとめて書いた。最終的には1万文字ほどになった。見出しはこんな感じ。実質2日しか作業していないけど、2週間かけた。

  • 開発プロジェクトに参加して気付いた3つの大きな課題
  • 初めてスクラム開発をやってみた所感
    • 所感
    • スクラムのよいところ
    • スクラムのわるいところ
  • 課題管理システム (チケット駆動開発) と情報共有
    • 情報共有とは
    • 課題管理と情報共有
  • 情報共有とコミュニケーションコスト
  • Pull Request のレビューと開発の生産性

明日プロジェクトのメンバーに共有してみる。反響があるのかどうか?もしかしたら誰も読まないかもしれないけど、私自身の思考の整理にもなっている。ここで書いた内容を洗練させてコンテンツとして再利用できるようにもしていきたい。

ストレッチ

本当はこの週末に ワーケーションへ行く予定だったが延期した 。いつもは土曜日の午前中に通っているストレッチを日曜日の夜に変更していた。

最近は日曜日をだらだら過ごす日が多いのだけど、今日は夜にストレッチの予定が入っていたので午前中は自分でストレッチして、午後から3ヶ月フィードバックを書き終えて、夜に Dr.stretch さんでトレーナーさんにストレッチしてもらうといった、平日のような充実した1日となった。休日も予定を作った方がきびきび動ける。いかに自分が怠惰かを思い知る。今日の開脚幅は開始前166cmで、ストレッチ後169cmだった。今週も全然ストレッチしなかった割にはまぁまぁよかった。

不正の調査報告書を読んだ

不正の調査報告書

少し前にタイムラインでグレイステクノロジーという会社の粉飾決算が話題になっていたので関心をもっていて、調査報告書が公開されていたので読んでみた。100ページ超あるので目を通すだけでも数時間ほどかかった。

うちはマイクロ法人なんでなんのプレッシャーも目標もない、お気楽な会社ではあるけど、失敗事例から経営や会計を学ぶ機会にしている。多くのケースで成功する方法はわからないけど、失敗しない方法はいくつもある。凡人は成功しようとせずに失敗しないように注意するのがよいと私は考えている。これは麻雀で振り込まなかったら勝てるというのに近い考え方だ。

閑話休題。報告書を読んでいて最初は1社員による小さな不正だった。もちろんそれもよくないことだが、経営陣がまともであれば、いくらでも訂正することも立て直すこともできた。しかし、経営陣もおかしかった。すぐに個人の不正が組織ぐるみになり、創業者の虚栄心も拍車をかけて、2-3年後には数億円規模の不正となり、不正を働いた関係者が一蓮托生となった。これは構造的な問題もしくは失敗を学ぶ教材となる。関係者個人の道徳心や正義感などを批判することもできるだろうが、それよりも構造的にそんな状態に陥らないように会社の仕組みを作ることが重要で、一般論ではそれをコーポレートガバナンス (企業統治) と呼ぶのだろう。しかし、経営者がみずから不正をすることに対するガバナンスとはどう在るべきなのか、この問題に対する構造的な対策はなかなか難しいのだと、この調査報告書は語っている。

なんら擁護するものではないが、読み進めていて、関係者みんな辛かっただろうなと不正をしなければいけない状況や心境を察してしまった。目標数値が高過ぎる、過度なパワハラ、コーポレートガバナンスの不備などがその状況を5年も維持し続けてしまった。もっと早く明るみに出ていたら、いまより関係者は苦しまなかっただろうが、歴史に if はないので推測でしかない。不正の中心人物である創業者は急性大動脈解離で急逝しており、それは認知的不協和のストレスによって引き起こされた可能性が高いのではないかと私は考えてしまった。不正に限った話ではないが、なんらかの間違いというのは早期に検出できて、早期に改善のための取り組みをする方が短期的に大きな損害を被ったとしても、中長期的には最大の利益を得るというのを、多くの人は人生の経験の中で学んでいくと思う。たまたまその経験をもっていない人たちがこの会社には集まってしまって、不幸な事件が起きてしまったように私は受け取ってしまった。