少し暖かさを感じるようになりましたね。
最近は目的地に向かう時は徒歩で。帰りはシェアサイクルを使って自転車で帰ってくるという遊びをしています。だいたい 5km 程度であれば、徒歩移動の対象としています。何よりも交通費が節約できるのと、歩くのが気持ち良いです。
2月度の成果
品質
- 専門的なテスト知識の獲得 - アプリケーション品質の向上 - E2E テストの棚卸し（Flaky テストの撲滅とテストピラミッドのバランシング） - リグレッションテストの再設計（初期のものから更新ができていない） - テスト戦略の定義・チームでの合意 - テストガバレッジの確立（品質の数値化を検討）
今月は手を動かすことを重視しました。
主にテストピラミッドのバランシングを行い E2E テストとして実装されているテストを見直し 5% ほどを単体テストへ移動させました。大したことをしたというわけではなく、E2E テストを地道に確認して、単体テスト化できそうなものをひたすら潰したという感じです。テスト可能か・何をアサートしたいのかという視点で無駄を省きましたが、地味な作業でコストがかかります。
結果的に Flaky テストが解消された（テスト数が減った）のと、E2E テストの月間クレジットの節約にも貢献することができました。また、より高速に実行可能なテストとなったことで、検証容易性が向上したという嬉しいフィードバックも頂きました。
反省点
体制などが変わったこともあり、自分がテスト方針を定める必要性は弱くなりつつあります。 テスト戦略の定義をする機会はなくなりそうですが、テストガバレッジの確立（品質の数値化）に関しては、ほとんど手を動かせませんでした。関心あるメンバーと少し話をしましたが、ファーストアクションができていない。
少し話は変わりますが 「SREをはじめよう」という書籍を読了しました。
長くなるので詳細は別途、書こうかなと思っていますが、SRE 視点でどうすればシステム品質を担保する（信頼性）シグナルを拾えるのかを考え始めています。自分が考えていた品質というのはテストやカバレッジに関するものでしたが、もっと視野は広くユーザー目線で健全な状態なのか、信頼できる状態を観測することに価値があるかも？と感じており、アプローチを改める必要性がありそうです。
プロダクトと向き合う
- 複雑なドメイン知識と向き合う - 医療制度（特に負担額計算領域）の理解 - 知識をコードに落とし込む経験をより積む（eg: いわゆるDDDの実践的トライ） - 歴史あるコードとの向き合い知識の獲得 - レガシーコード改善ガイドを読む（購入済み） - 単体テストの考え方/使い方
AI をゴリゴリ使った開発をしている事もあり、精算業務からレセプトまで広いテーマに関わる機会を得られました。先月は樹形図が読めるようになり、ようやくコード上でどう表現されているのか、相関が少しずつ見えるようになってきたのが嬉しいです。何件か関連する不具合の調査・修正もやりました。
レガシコード改善ガイドについては読了して、書評を記事にしました。
反省点
不具合の原因は分かれど、ドメイン知識や設計に至ったコンテキスト情報などが圧倒的に不足しているので、どのように修正するかの判断が難しいと感じています。AI によってアウトプット速度は上がっていますが、最終的に自分が責任を持って OK の判断ができるかは重要です。 知識も増えて、手を動かす速度は確実に上がってきているので、引き続き向き合っていきたい。
総評
成果を意識して手を動かせたのは良かったです。 E2E テストの削減のような分かりやすいものから、ドメイン知識を深めて沼へ足を踏み込めている感覚があるのは継続していきたい。ここには書けない試作・改善なんかもやっているので、満足度が高めの月ではありました。とはいえレセコン開発（負担額計算）がシンプルに難しい...
