Masahito IKUTA

知床育ち. 3児の父. WOVN の CTO. CSP-SM/A-CSPO, LeSS Practitioner, M3.0 Facilitator. 趣味で, Elixir/Erlang/Python. HN の由来は FreeBSD のデーモン君.

[Masahito IKUTA @cooldaemon]

これの意図は、こんな感じ。
- 設計段階で、業務上の集約を探せ
- 正規化をしろ
- 必要な集約の中で性能限界を観測したら、DBを水平分割をしろ(整合性は守れ)

つまり、「性能限界を理由に結果整合性に逃げるな」と「可能な限り結果整合性を探せ」は矛盾していない。

[Masahito IKUTA @cooldaemon]

普段から自分の知識と経験を Claude Config で明文化しておくと、他人から見て矛盾してそうなことは Claude が突っ込んでくれる。自分の頭の中では整合性がとれているため、その度に説明の機会が得られる。

例えば…
- DB系スキルに、結果整合性に逃げるな
- DDD 系スキルに、結果整合性を探せ
と…

[Masahito IKUTA @cooldaemon]

DeepEval で、
- 何度も実行して平均を取得する
- 閾値を設ける
- リリース前に自動実行する
などは否定しない。

ただ、これは、サーバーの負荷試験と同じ特性がある。完全に特性を理解して運用を検討するべき。

[Masahito IKUTA @cooldaemon]

「DeepEval は、CIとかに入れちゃダメ。あれは決定論的じゃない」と伝えても、何故か一部の開発者に伝わらないなーと思っていたら、DeepEval 公式に、こんなページあったよ。

https://t.co/SiAGZ1hOql

これは…はぁ…orz

[Masahito IKUTA @cooldaemon]

全てのビジネスロジックは、リストからリストへの変換で表現できると思うし、それを行えるからIOへの依存を切り離せるんだ！

と思うんだけど、どう思う？

と、GPT-5.5 や Opus 4.8 に問いかけると、私が欲しい回答をくれる。

もう人間と、これ系の話をしたくないwww

[Masahito IKUTA @cooldaemon]

Codex が Bedrock から使えるようになった。やっとこれで、満足に使える。

[Masahito IKUTA @cooldaemon]

とはいえ、私はマネージャーなので、学習や経験を通じて開発者の方々に、副作用とは何か？に自力で気がついてほしいなーと期待している。

この辺りの勘どころが血肉となってると、TDD とは何か、Clean Architecture とは何か、どの辺りがプロジェクト固有の落とし所かで迷わなくなる。

[Masahito IKUTA @cooldaemon]

社内であった面白い話し。
構造のテストは書くな。振る舞いのテストを書こう。
これで意見の一致はした。

次に起きたのは、決定論とは何か？副作用とはな何か？の定義の不一致が浮き彫りになってきた。
結果、LLMを組み込んだ製品の品質保証で揉めた。

[Masahito IKUTA @cooldaemon]

私が現場の開発者なら、LLM の回答は非決定的なため、「自動テスト」を作っても、それを git push や Deploy のゲートチェックに組み込んだりしない。メトリックを、Datadog か何かに流し込んで、「監視」の対象にする。

公開前に確認したいなら、負荷試験と同じように取り扱う。

[Masahito IKUTA @cooldaemon]

入社したとき、dotfiles を社内公開する場所はどこ？と Slack で尋ねたとき、そんなものはないし、必要性もわからんと英語で突っぱねられて、文化の違いに愕然とした。

そこから七年…徐々に文化改革を進めて、やっとここまで…ふぅ

[Masahito IKUTA @cooldaemon]

契約している Agile Coach と開発者たちの会議中、一人の開発者から AI Agent で開発をゴリゴリ進めているよ！という話題が出た。

私がハーネスを毎日更新するため、そのチームでは二週間に一回くらい、ハーネスの更新を一括で取り込むらしい。

コーチからハーネスとは何か？と質問が出たのだが…

[Masahito IKUTA @cooldaemon]

問われた開発者が、とても細かくワークフローの挙動などを説明してくれた。

以前は、同僚がどんな開発環境を構築しているか興味がなく、自分の経験だけで仕事をしていたが、今は、良いものは積極的に同僚から盗めるように変わってきた。感慨深い。

もちろん、私は上司なので同僚というと語弊があるが

[Masahito IKUTA @cooldaemon]

新規にプロジェクトを始める場合と、既存のメンテでプロセスを分岐させている。

既存なら、段階的に DDD や Clean Architecture を取り入れるか質問するように設定している。

また、コード修正時の探索範囲を絞れないかな？と思い Vertical Slice を実験中。

[Masahito IKUTA @cooldaemon]

最近、TDD 用の sub-agent 群に次の修正を入れた。

- Red と Green の直後に、それぞれ専用の Reviewer を起動
- 計画段階で、User Story を TDD サイクルごとにスライスする(一つでDeploy可能は維持)
- Crean Architecture (+ Vertical Slice)をリスペクト (そもそも計画段階がDDDだからね)

[farstep @farstep_]

https://t.co/fLIm4rlzco

[Masahito IKUTA @cooldaemon]

30代の頃、英語の技術書がスラスラ読めたらなーと思ってた。今は、読めるけど分量の多さに辟易としており、AI が必要な時に必要なだけ、情報を本からとってくれないかなーと。

今のところ、ほぼ実現しているんだけど、結局、AIに勧められた本を読んでる…。なんでだ…。

[Masahito IKUTA @cooldaemon]

AI Agent に不明点を質問すると、「すみません。間違ってました。修正します。」と謝罪して自己完結しがち。

こちらは、ただ、理解したくて質問してるだけなのに…。

これ、気を抜くと人間との1on1でも発生しがちなので、気をつけよう。

とりあえず、AI 側はルール化で回避。

[Kenn Ejima @kenn]

この記事すごい

エンジニアの設計論争を
認知戦略の違いとして見直している

自分はずっと圧縮型だったけど
AIでコーディングするようになってから展開型になった

たぶんだけどAIのおかげで視野角が広がって
自分のワーキングメモリを拡張できたからだろう

面白い視点だ

https://t.co/VYBwJSEXdn

[Masahito IKUTA @cooldaemon]

「本を読めなくなった人たち」を読んで思うのは、「コードを読み書きできなくなった人たち」「UX/UIデザインをできなくなった人たち」という現象も起こりつつあるなと。

”嫌いな”読書やコードをAIに丸投げして、自分は”好きな”読書やコード書ける時間を確保できるから嬉しいけどね。

[Masahito IKUTA @cooldaemon]

Claude Code に、一プロンプトを大切せよ、resume するときの目印になるし、悪いプロンプトは思考の妨げだと怒られた。

つまり、文書末尾に「w」をプロンプトに入れるなと、こんこんと説教されたよ…。