Top List Tag Search

/note/tech

DebConf 14: QA with Linus Torvalds

要約:

■ 1. 概要

  • Linus Torvaldsを招いたQ&Aセッションの書き起こし(場所はDebianカンファレンス)
  • Linuxカーネル開発・ディストリビューション・ライセンス・セキュリティ等の幅広いテーマについて質疑応答が行われた

■ 2. Linuxディストリビューションと個人的な利用環境

  • 2007年のインタビュー以降もDebianをインストールしたことはない
  • ディストリビューションは「インストールが容易で作業の妨げにならないこと」が最重要との立場
  • Ubuntuは試したがmake installが機能しなかったため断念した
  • 個人の作業環境はWebブラウザと3つのターミナルウィンドウのみという極めてシンプルな構成
  • 家族のマシンを管理する必要があるため一度使い始めたディストリビューションからの変更が困難

■ 3. Linuxデスクトップの普及問題

  • アプリケーションのパッケージングがLinuxデスクトップ普及の最大の障壁
  • Windowsや macOS向けにはバイナリを提供できるがLinux向けは困難な状況
  • 問題の本質はディストリビューションごと・バージョンごとに異なるバイナリが必要になること
  • glibcをはじめとする共有ライブラリが頻繁にABIを破壊することが根本原因
  • カーネルにおける「ユーザ空間を壊さない」という唯一の絶対ルールをディストリビューションが守っていないと批判
  • ValveがLinuxデスクトップを救う可能性があると期待:
    • 複数バイナリを作成せず静的リンクを使用するため各ディストリビューションも対応せざるを得ない
    • ゲーム自体よりもこのバイナリ配布モデルの実証が重要

■ 4. アプリケーションのバイナリ配布問題

  • gitやsparseのような問題と異なり本質的に複雑であり短期間での解決は困難
  • 解決策として現状は静的リンクと独自ファイルシステムの同梱が現実的
  • Dockerコンテナを用いたアプリケーション配布の可能性に期待
  • アプリケーションに求められる要件:
    • グラフィックライブラリやOpenGLなどのUI要素
    • USB・シリアルポート・Bluetooth等のハードウェア直接アクセス
    • Javaのような移植性重視の環境ではハードウェアアクセスが困難

■ 5. ディストリビューションに対する改善要望

  • タイムゾーン設定や無線プリンタへの接続など日常操作に管理者権限が不要になること
  • 一般ユーザが管理者権限なく作業できる環境を整備してほしい
  • ディストリビューションのパッケージ管理者はコアパッケージに集中すべきであり小規模プロジェクトのパッケージ管理は工数の無駄

■ 6. コミュニティにおけるコミュニケーションスタイル

  • 自身の攻撃的な言動を認めつつ文化的背景や個性の違いを理由に変える意思がないと表明
  • 敬意は与えられるものではなく獲得するものという立場
  • オープンソースでは合わない人物を避け自分に合う協力者を選べる利点がある
  • 「政治的正しさ」を優先するあまり技術的品質が低下したプロジェクトの存在を懸念

■ 7. systemD

  • 予想に反してsystemDを嫌いではないと表明
  • 評価する点:
    • Unixのinitシステムの問題を解決した
    • 起動速度の向上は実質的な成果
  • 批判する点:
    • バグレポートが無視される事例がある
    • Linuxカーネル固有技術への依存によるポータビリティの欠如

■ 8. GCCのバージョンについて

  • 問題となっていたGCCの特定バグはカーネル側で修正済み
  • インラインアセンブリを使用しないプロジェクトへの影響は限定的
  • GCC 4.2以降のバージョンはおおむね問題なし

■ 9. revokeシステムコールの実装

  • 実装に向けた提案パッチを確認中
  • CFSと共通のインフラ基盤を使用できる可能性があり設計上の利点
  • 実装は確実に行われる見込みだが次バージョンへの搭載は未確定

■ 10. ドライバ開発とioctlの問題

  • ioctlはバイナリ互換を破壊しやすい設計上の問題を内包
  • 典型的な問題:
    • 32ビットと64ビット環境でデータ型のアライメントが異なる(例: dma_addr_t)
    • ioctl呼び出しのデータ構造変更によるABI破壊
  • ドライバ開発者がこれらの問題を認識していないケースが多く理解できるが残念
  • GPUレイヤーはかつて同様の問題で被害を受けた後改善された事例がある

■ 11. 後方互換性の維持

  • 1991年当時のバイナリが現在も動作するという実績がある
  • 真の互換性問題は古いバイナリではなく現代の複雑なバイナリで発生
  • UI関連ライブラリのほうが低レベルコードより互換性が壊れやすい
  • ライブラリのバグ修正が依存アプリケーションを壊す具体例:
    • glibcがmemcpyの未定義動作への依存を修正したことでAdobe Flash Playerが動作しなくなった
  • カーネルでもバグ修正が結果的に互換性を破壊する事例は発生しており完全な保証はできない
  • 商用環境では2年遅れでカーネルを使用するケースがあり破壊が遅れて発覚することがある

■ 12. GPL v3とライセンス

  • GPL v2の理念: ソースコードを提供する代わりに変更点を還元するという対等な関係
  • GPL v3を強く批判する理由:
    • Tivoization条項により「ソースを渡しても自分のデバイスで使えない」状態が生じ得る
    • これはGPL v2の精神に反する
    • FSFがTivoization条項の無効化について不誠実な説明を行ったと批判
  • 対応: Linuxカーネルを意図的に「GPL v2のみ」と明示しGPL v3への自動アップグレードを阻止
  • GPL v3は別の目的のために選択するライセンスとしては有効であるという立場
  • BSD/ISCライセンスは「コードを自由に使ってほしい」という目的に適している

■ 13. FSFへの評価

  • FSFの一部の人物を「過激で視野が狭い」と批判
  • 寄付先としてはEFFを推奨
  • GPL v3をめぐるFSFの説明には不誠実な点があったと明言

■ 14. gitの発展

  • gitの現在の成功はJunio Hamano(2006年頃から保守担当)の貢献によるところが大きい
  • 良い技術者を見極める基準として「センス(taste)」があるとし、Junioにそれを認めた
  • 分散型バージョン管理のモデルが広く受け入れられた
  • GitHubがgit普及に大きく貢献した:
    • ホスティングを容易にした
    • オープンソースへの参入障壁を下げた
  • かつて批判されたUI上の設計(リネームの扱い等)が後から正当性を認められた

■ 15. セキュリティへのアプローチ

  • セキュリティコミットをコミットログに明示的に記載することに反対:
    • 攻撃者が最初に読むのがコミットログであるため情報提供になりかねない
    • あらゆるバグはセキュリティバグになり得るため区別に意味がない
  • SELinuxへの評価:
    • かつてはパフォーマンスへの悪影響が深刻だったため無効化していた
    • 現在は改善されており有効化した状態で性能問題を修正した
  • セキュリティは単一の層で解決できるものではなくカーネル・ユーザランド双方の多層防御が必要
  • セキュリティ研究者(ブラックハット含む)の技術力を高く評価しつつも過度に白黒思考な姿勢を批判

■ 16. 世界観と現状認識

  • 公の場での発言が批判的に見えるのは問題発生時にのみ発言するためであり基本的には楽観的
  • かつて批判したNvidiaも現在はLinuxカーネルに積極的に貢献するようになった:
    • Android市場の重要性を認識したことが態度変化の主因
  • Linux全体として良い方向に進んでいると評価

(2026/04/17)

「1.58ビットに進化したから8GBで十分ですよ。任せてくださいよ」とBonsaiが言うのでMacBook Neoに...

要約:

■ 1. Ternary Bonsai (1.58ビット) の概要

  • PrismMLが1ビットBonsai 8Bの後継として「Ternary Bonsai」を発表
  • 1.58ビットとはlog₂(3) ≈ 1.585に由来し、ウェイトが{-1, 0, +1}の三値を取る構成
  • 0（何もしない）という選択肢が加わることでスパース性が生まれ、ネットワークの表現力が向上
  • マイクロソフトのBitNetと同様のアプローチに基づく

■ 2. 性能比較

  • メモリ消費:
    • Bonsai 8B (1-bit): 1.15 GB
    • Ternary Bonsai 8B (1.58-bit): 1.75 GB
    • Qwen3 8B (FP16): 16.38 GB
  • ベンチマーク平均スコア:
    • Bonsai 8B (1-bit): 70.5
    • Ternary Bonsai 8B (1.58-bit): 75.5
    • Qwen3 8B (FP16): 78.2
  • 600MB増（53%増）でスコアが5ポイント（7%）向上
  • FP16モデルの約9.4分の1のメモリでほとんどの実用シナリオを網羅
  • MMLU Redux・MuSR・GSM8K・HumanEval+・IFEval・BFCLv3の広範なベンチマークで均等にスコアが向上

■ 3. 動作環境と導入方法

  • MLX形式のみ対応（Apple Siliconネイティブ）
  • HuggingFaceモデルID: prism-ml/Ternary-Bonsai-8B-mlx-2bit
  • 標準のmlx-lmパッケージで動作し、PrismMLのフォーク版ビルドやXcodeは不要
  • 起動コマンド一行で初回実行時にモデルが自動ダウンロードされOpenAI互換APIサーバが起動
  • 8GB MacBook Neoでの動作結果:
    • 生成速度: 19.3 tok/s
    • ピークメモリ: 2.365 GB

■ 4. mazzaineoへの統合

  • mazzaineoのMODEL_REGISTRYに1行追加するのみで統合完了
  • 既存のOpenAI互換バックエンドを流用しポート8082を1-bit Bonsaiと共有
  • UIのモデルセレクタとサブタイトルが自動切り替えに対応

■ 5. 使用感

  • 日本語応答の丁寧さとテキスト接続のスムーズさが1-bit Bonsaiより向上
  • 短い質問への回答では差が少なく、複数ステップの推論やTool Calling連鎖で差が顕著
  • エージェンティックAIとして使用する場面での文脈保持能力が向上
  • 速度は1-bit Bonsai（21.1 tok/s）よりやや劣るが、M4 Proでは82 tok/s出るとPrismMLが発表

■ 6. 8GBマシン向け推奨構成

  • 品質最重視: Ternary Bonsai 8B（1.75GBで75.5点、Tool Calling完璧）
  • 品質重視: Bonsai 8B (1-bit)（1.15GBで70.5点、最小フットプリント）
  • 速度重視: Ollama Qwen3 8B（kv-cache量子化が有効）
  • Vision用途: Qwen 3.5 4B / Gemma 4 E2B（カメラ・スクリーンキャプチャ対応）
  • 軽量会話: Qwen 2.5 3B（最軽量、エージェント不要時）

■ 7. スマートフォンへの展開と今後の展望

  • iOSのメモリ制限により1-bit Bonsai 8Bが実用に至らなかったiPhoneで、1.58-bit版の4B・2Bモデルが選択肢に
  • iPhone用LLMクライアント「Locally AI」ではすでにTernary Bonsai 8Bが配信開始
  • Qwen 3.6も登場し、1-bit・1.58-bit・量子化等による最適化と基盤モデルの進化が並行して進行
  • オープンソースのエージェンティックAI「Agent」が公開
  • mazzaineoのMCPエージェント化を実施済み

(2026/04/17)

アンソロピック辞めた研究者｢世界は危機に｣　AI開発競争で理念が無力化

要約:

■ 1. AI安全性研究者の相次ぐ離脱

  • アンソロピックのムリナンク・シャルマ氏が2月に退職
    • 英オックスフォード大で機械学習の博士号を取得しAIの安全性研究に従事
    • 退職時に「価値観を行動の指針とする難しさ」を訴える手紙を公開
    • 「世界は危機に陥っている」と警鐘を鳴らす
    • 「知恵と影響力が釣り合わなければ代償を払うことになる」と警告
  • オープンAIのゾーイ・ヒッツィグ氏も同月に退職
    • ChatGPTへの広告導入に反対して離職
    • 利用者のプライベートな悩みに基づく広告は「利用者を操ることになる」と批判
    • 「オープンAIはフェイスブックと同じ過ちを繰り返している」とNYTに寄稿
    • 「AI開発者はAIが引き起こす問題に先手を打てると信じていたが、オープンAIはそれをやめた」と指摘

■ 2. 危険性が高まるAI開発の実態

  • アンソロピックが4月7日に「Claude Mythos（クロード・ミトス）」を試験公開
    • システム上の未知の欠陥を特定できるほど高性能
    • 銀行へのサイバー攻撃などへの悪用が懸念される
    • 公開先を一部に限定しベッセント米財務長官が大手銀行トップと緊急会合を開催
  • オープンAIは赤字改善のため無料・低価格プラン利用者向け広告の表示を計画

■ 3. 理念と開発競争の乖離

  • 各社の売上・企業価値が拡大する一方で安全や倫理への姿勢が揺らぎ始めている
  • アンソロピックCEOのダリオ・アモデイ氏が1月公開のエッセーでAIの急速な技術革新が数年以内に深刻なリスクをもたらす可能性を表明
    • 雇用喪失・格差拡大・生物テロなど大量破壊兵器への悪用リスクを列挙
  • アンソロピックはAIの軍事利用を禁じる方針を掲げながらもライバルのオープンAIが米国防総省と契約後に政府との協議継続を表明
  • 「どれだけ崇高な理念があっても開発競争の前には無意味だ」（米グーグル社員）
    • 米国内のテック企業間競争に加え中国勢との争いも激化
    • 国際的な規制ルールが欠如した状態が続く

■ 4. ブレーキをかける主体の不在

  • オープンAIが4月6日にAIが世界を変えるビジョンを政策提言として発表
    • 税制改革・週4日労働・保育強化などAIがもたらす社会変革のビジョンを提示
    • 国家レベルの安全基準策定など規制の必要性も訴える
  • アンソロピックが4月2日更新の提言で開発プロセスの透明性と超知能モデルのリスク制御を強調
  • トランプ大統領が政府によるAI強制停止のための「キルスイッチ」保有を主張（4月15日放送のインタビュー）
  • 米連邦議会下院公聴会（2月24日）で民主党議員らが「AI対人類の問題」「労働者保護」について国務次官に質問
  • 米国内の分断と米中対立が深まるなかで最適解は見いだせていない
  • AIの急速な進化が人類に残す「考える時間」は長くないとの認識が広がっている

(2026/04/17)

社名こそ出せないが、氷河期新卒時代に常駐したとあるメーカーは下請けをゴミのように扱う...

要約:

■ 1. 概要

  • Togetterまとめ「社名こそ出せないが、氷河期新卒時代に常駐したとあるメーカーは下請けをゴミのように扱うところだった→ひどい扱いを受けた会社の製品は買わなくなるという話」の内容
  • 就職氷河期時代に大手メーカーへ常駐した元下請け社員が経験した職場環境の劣悪さと不買運動への発展を主題とする

■ 2. 発端となる投稿

  • 投稿者:クワタ (@kuwataku)
  • 就職氷河期の新卒時代に常駐したメーカーにおいて下請け社員がゴミのように扱われていたと告発
  • 日常的なパワーハラスメントの具体例:
    • 頭を押しのけて「どけよ」と言われることが日常茶飯事であった
    • 精神的に追い詰められメンタルヘルスが悪化した
  • 社名は明かさないとしながらも「富士通の製品だけは絶対に買うまいと心に誓っている」と明言
  • フォロワーのコメントにより富士通であることが示唆される構造となっている

■ 3. 反応と共感の広がり

  • 投稿に対し多数のユーザーが同様の体験を共有:
    • asaji:富士通において女性・若年層への職場いじめを目撃したと証言
    • Yunsaurus:富士通でのパワーハラスメント・セクシャルハラスメント経験を報告
    • HiLack:三菱電機における下請け蔑視の実態を告発
    • tiny_ynz:N社での不当な扱いを言及
  • 企業名を明かさない投稿でも文脈から企業が特定される現象がコメント内で指摘される

■ 4. 不買運動の論点

  • 不当な扱いを受けた企業の製品を永続的に購入しないという「報復的消費行動」が複数ユーザーにより表明される
  • 対象企業は富士通・三菱電機・トヨタグループ系など複数業種にわたる
  • 「当時の下請け蔑視を行った当事者が現在も同企業に在籍・出世しているため恨みが持続する」との見解が示される
  • 就職氷河期における労働環境の劣悪さが現在進行形の消費行動に影響を与えていることが示される

MEMO:

(2026/04/17)

Linux 7.0カーネルにおけるPostgreSQL性能劣化問題、その後の動向

■ 1. 発端

  • Linux 7.0開発カーネル上でPostgreSQLのスループットが約半減する性能劣化が報告された
  • 報告者はAWSエンジニアのサルヴァトーレ・ディピエトロ（2026年4月3日 LKMLへ投稿）
  • テスト環境: AWS EC2 m8g.24xlarge（Graviton4 / 96 vCPU）、PostgreSQL 17
  • pgbench（simple-update / 1024クライアント / 96スレッド / 1200秒）の計測結果:
    • Linux 7.0（PREEMPT_LAZY）: 約50,751 TPS
    • 問題コミットをリバート後（PREEMPT_NONE相当）: 約98,565 TPS（約1.94倍）
  • perfプロファイリングにより CPU時間の55%がPostgreSQLのユーザースペーススピンロック（s_lock）で消費されていることが判明

■ 2. 当初議論された原因

  • Linux 7.0 rc1で導入されたカーネルスケジューラの変更が根本原因
  • IntelのカーネルエンジニアPeter Zijlstraによるコミットがプリエンプションモードを制限
  • 従来はサーバー向けに「PREEMPT_NONE」（プリエンプションなし・スループット最大化優先）が存在した
  • Linux 7.0でx86・ARM64等の主要アーキテクチャからPREEMPT_NONEが廃止され「FULL」と「LAZY」の2モードのみに変更
  • 廃止の目的はカーネルの簡素化とPREEMPT_RT（リアルタイム対応）への統合推進
  • PostgreSQLはプロセスモデルを採用し共有メモリへのアクセスにユーザースペーススピンロックを多用する
  • PREEMPT_LAZY環境ではロック保持中にタスクが中断される頻度が上がり他のプロセスが無駄にスピンし続ける

■ 3. 真の原因とAndres Freundの分析

  • Andres FreundがLKMLスレッドを調査した結果、真の原因はスピンロック機構そのものではなくスピンロック保持中に発生するTLBミスとマイナーページフォルトであると判明
  • 問題の連鎖:
    • Huge Pages未使用時、PostgreSQLの共有メモリは標準4KBページで管理される
    • 100GB超のバッファプールでは各ページへの初回アクセス時にマイナーフォルトが発生する
    • マイナーフォルトがスピンロック保持中に起きるとスレッドが失速し待機中の全スレッドがスピンし続ける
    • PREEMPT_LAZYは失速したロック保持者をスケジュールアウトすることがあり事態をさらに悪化させる
    • 根本問題は最初からページフォルトにあり、プリエンプションモードではない
  • Huge Pages有効化により新旧どちらのカーネルでもスループットが同等（約185k TPS）になることが確認された

■ 4. 4KBページとHuge Pagesの比較

  • ページサイズ:
    • 通常ページ: 4 KB
    • Huge Pages: 2 MB（x86）/ 1 GB（gigantic）
  • 100GBバッファに必要なTLBエントリ数:
    • 通常ページ: 約2,600万
    • Huge Pages: 約5万
  • TLBミス頻度:
    • 通常ページ: 高
    • Huge Pages: 大幅に低下
  • スピンロック保持中のフォルト:
    • 通常ページ: 発生しやすい
    • Huge Pages: ほぼ発生しない

■ 5. Huge PagesとTHPの区別

  • Transparent Huge Pages（THP）と明示的なHuge Pagesは別物
  • THPはLinuxカーネルが自動でHuge Pagesを割り当てようとする機能でスワップ対象になり得る
  • PostgreSQLには明示的に設定するHuge Pagesが推奨される
  • PostgreSQL公式ドキュメントもTHPについて「一部のユーザー・一部のLinuxバージョンで性能劣化が知られており現在は非推奨」と明記している

■ 6. 具体的な設定手順

  • OSレベル（明示的なHuge Pages予約）:
    • shared_buffersに必要なHuge Pagesページ数を計算する（例: 32GB ÷ 2MB = 16384ページ + 余裕分）
    • sudo sysctl -w vm.nr_hugepages=16500 で設定し /etc/sysctl.conf に永続化する
    • /proc/meminfo の HugePages_Total / HugePages_Free / Hugepagesize で割り当てを確認する
  • PostgreSQL設定（postgresql.conf）:
    • huge_pages = on: 確実に使用（取得失敗時は起動拒否）
    • huge_pages = try: 取得失敗時は通常ページで起動（デフォルト）
    • PostgreSQL 15以降は SHOW huge_pages_status で実際の使用状況を確認可能
  • THP無効化（競合防止）:
    • 明示的Huge Pages使用前にTHPを無効化しなければカーネルがTHPで共有メモリをマッピングし性能が不安定になる
    • /sys/kernel/mm/transparent_hugepage/enabled および defrag に never を書き込む

■ 7. 影響が限定的なケースとまとめ

  • 影響が出やすい条件:
    • Huge Pages未設定
    • shared_buffersが数十GB以上の大規模構成
    • コールドスタート直後（ウォームアップ期間）
    • 高コアCPU（96vCPUなど）での高並列ワークロード
  • Huge PagesまたはTHPを使用していればこのリグレッションはほぼ心配不要という見解がPostgreSQLメーリングリストでまとめられている
  • 問題の本質は「PREEMPT_LAZYが悪い」ではなく「Huge Pages未使用環境でのTLBミスがスピンロックと組み合わさった時にPREEMPT_LAZYによって悪化する」という複合的なもの
  • Huge Pagesを正しく設定すればLinux 7.0でも従来と同等の性能が得られることが実証されている

関連:

(2026/04/17)

【スゴ本】開発現場で使える「良い問い」集

要約:

■ 1. 概要

  • ITエンジニアのコミュニケーションにおいて言葉の選択が結果を左右する
  • 著者は「正確・論理的に説明すれば伝わる」という思い込みを克服し人への伝え方を変えた
  • 人はコンパイラではなく立場・感情・文脈によって解釈が異なる
  • 4冊の書籍から「ITエンジニアのピンチを救う言葉」を紹介する

■ 2. 「なぜ」ではなく「いつ」と問う

  • 出典: 『「なぜ」と聞かない質問術』中田豊一 著
  • 「なぜ」の問題点:
    • 問われる側に圧力・説明責任・問題の責任を押し付ける効果がある
    • 「なぜなぜ分析」は偶然性やプロセスの特殊性を無視し特定個人のミスを根本原因とする傾向がある
    • 繰り返されるとメンバーのモチベーションが萎縮しミスが報告されなくなる
  • 「いつ」による事実質問の効果:
    • 「いつ設定を変えたか」「いつGOサインが出たか」と問うことで責任追及なしに事実を収集できる
    • 心理的圧迫を解消しながら責任の所在により速くたどり着ける
  • 応用原則:
    • 事実質問は「考えさせるのではなく思い出させる」
    • 過去形・時間・主語を意識して問う

■ 3. 「なぜ」ではなく「うれしいのは」と問う

  • 出典: 『伝わるコードレビュー』鳥井雪・久保優子・諸永彩夏 著 島田浩二 監修
  • 力関係のある質問の問題点:
    • ベテランから新人への「このメソッドを使ったのはなぜ？」は意図不明で受け手を不安にさせる
    • 質問の背景・理由・求める回答を明示しないと意図が伝わらない
  • 「うれしいのは」という問い方の効果:
    • 「このメソッドを使うとうれしいのは何？」とすることで「採用するメリットの主体」が明確になる
    • 「メリット」という言葉より誰にとっての価値かという焦点が鮮明になる
  • 実践上の留意点:
    • コードレビューのコメントには質問の背景・意図・求める回答を含める
    • 評価軸の両面を言い換えるだけの問いより価値と結びつく主体を問う問いが有効

■ 4. 解くべき問題を見極める問い

  • 出典: 『ライト、ついてますか』D.C.ゴース・G.M.ワインバーグ 著 木村泉 翻訳
  • 「問題への飛びつき」の弊害:
    • 学校教育により最初に見つけた問題を素早く解こうとする癖がつく
    • 本当に解くべき問題かどうかを吟味せず固執すると誤った解決策に至る
  • 問題再定義の方法:
    • 「問題文をどう変えたら解答を変えられるか」と自問する
    • チケット予約の例: 「予約処理を間に合わせる」ではなく「リクエストを受け付ける」に問題を再定義することで処理分離という発想につながる
  • 「ライト、ついてますか」の事例:
    • トンネルでのバッテリー上がりの問題を「バッテリーが上がる」でも「消し忘れ」でもなく「ドライバーに気づいてもらう」と再定義した
    • ヘルプデスクの「コンセントを抜いて挿し直してください」も同様の問題再定義の実践例
  • 本質: 問題の定義次第で解答はいくらでも変わる

■ 5. 「問題ない症候群」への対処

  • 出典: 『スーパーエンジニアへの道』G.M.ワインバーグ 著 木村泉 翻訳
  • 問題ない症候群の特徴:
    • 問題の内容を理解せずに「問題ない」と答える
    • 問題ではなく解決策を説明し始めた場合に症候群と判断できる
  • 見分け方の手順:
    • 難しい問題を提示する
    • 「問題ない」と言われたら「その問題とは何か説明してください」と問う
    • 相手が解決策を説明し始めたなら症候群と判断する
  • 著者の実体験:
    • データ移行プロジェクトで営業が「問題ない」と遮り代替データを提示
    • 移行ファイルに欠落・フォーマット崩れが多発しスケジュールが大幅遅延
    • 「その問題とは何か」と問うことで問題把握の有無を早期に確認できた
  • 対処の原則:
    • 「問題ない」は思考停止ワードとして扱う
    • 「その問題とは何か分かっているか」という問いからリスタートする

■ 6. まとめ

  • 良い問いの定義:
    • 事実と判断を明確にする
    • 価値と結びつく主体を明らかにする
    • 本当に解くべき問題に焦点を合わせる
    • 「私たちは何を解決しようとしているのか」というメタ的視点を与える
  • 各書籍のエッセンス:
    • 「いつ」: 事実を炙り出し人による判断を一旦保留する
    • 「うれしいのは」: 質問の背景・意図を伝え回答者の価値判断基準を示す
    • 「解くべき問題はこれか」: 誰にとっての問題かによって解答が変わることを意識する
    • 「その問題とは何か」: 問題定義の曖昧さを放置しないための問い

(2026/04/17)

「ブラウザの戻るボタン→広告表示」がスパム扱いに　Google、6月にポリシー変更　違反で検索冷遇も

米Googleは4月13日（現地時間、以下同）、ブラウザの戻るボタンを押した際、すぐ元のページに戻さず、広告など意図しないページを表示する行為をスパムとして扱うと発表した。6月15日にGoogle検索のスパム対策ポリシーを更新する予定。違反した場合、Webサイトが検索上位に表示されにくくなったり、検索結果から削除されたりする可能性がある。

同様の行為が増加傾向にあるといい、「『Back Button Hijacking』（戻るボタンの乗っ取り）はブラウザの機能を妨害し、ユーザーの期待する操作を阻害し、ユーザーの不満につながる。最終的には見慣れないサイトを訪れる意欲が低下する」（同社）として、対策を強化する。

GoogleはWebサイトの管理者に対し、戻るボタンの挙動を妨げるようなスクリプトなどをポリシー更新までに削除・無効化するよう呼び掛けている。

MEMO:

(2026/04/17)

The peril of laziness lost

要約:

■ 1. プログラマの三徳とLaziness(怠惰)の本質

  • Larry WallはProgramming Perlにおいてプログラマの三徳として「Laziness(怠惰)」「Impatience(短気)」「Hubris(傲慢)」を提唱した
  • 三徳の中でもLazinessは最も深遠な徳であり「システムをできる限りシンプルにする」という美学を内包する
  • Lazinessは表面的な怠惰ではなく高度な抽象化を生み出すための知的労働を意味する
  • ハンモック・ドリブン開発と呼ばれる一見怠惰な思考作業は実際には問題を繰り返し検討する高度な知的プロセスである
  • 優れた抽象化は自分自身だけでなく後継の開発者全員に恩恵をもたらし「より多くの人がより多くのソフトウェアを書けるようにする」ことに繋がる

■ 2. 現代におけるLaziness喪失の背景

  • ソフトウェア開発の裾野拡大により自らをプログラマと呼ばない層が増加しLazinessの本来の意味が失われつつある
  • 現代の高度な抽象化がもたらす生産性向上は「偽の勤勉さ」を重視する文化を台頭させた
  • これはコードを大量生産することを礼賛する「brogrammer」文化として具体化した
  • 皮肉なLazinessとハンモック・ドリブン開発は「コードをクラッシュする」ハッスル文化に取って代わられた

■ 3. LLMがもたらすLaziness喪失の加速

  • LLMはソフトウェア開発者のあらゆる傾向をより強力に発揮させる増幅器として機能する
  • brogrammer文化に対してLLMはアナボリックステロイドとして作用した
  • Garry Tanが1日37,000行のコードを生産すると誇示した事例はこの問題を象徴する
  • 実際にTanのプロジェクトを分析した結果として複数のテストハーネス・RailsのHello Worldアプリ・テキストエディタ・同一ロゴの8バリアント(うち1つはゼロバイト)が含まれていた
  • コードを重量で評価するような指標の誤謬は初学者にも明白である

■ 4. LLMがLazinessを欠く構造的理由

  • LLMは作業にコストを感じないため将来の自分や他者の時間を最適化しようとする動機を持たない
  • 制約なく放置されたLLMはシステムを改善するのではなく肥大化させる
  • LLMはパフォーマンスとは無関係な虚偽の指標に訴求しつつ本質的な品質を損なう
  • 人間のLazinessが不可欠な理由は有限な時間という制約が「認知負荷を許容できる限度まで下げよう」という動機を生み出すからである
  • 制約こそが最良のエンジニアリングを生む原動力であり時間的制約のないLLMはこれを自発的に行わない

■ 5. LLMを正しく活用するための指針

  • LLMは重要なツールではあるがあくまでもツールに過ぎない
  • 皮肉でも徳でもない「非生産的な怠惰」の側面(技術的負債への対処など)にLLMを活用することは有効である
  • LLMはエンジニアリングの厳密性を高める目的で使用すべきである
  • LLMの活用は人間の「徳としてのLaziness」に奉仕する形で行わなければならない
  • 最終目標は自分自身だけでなく後続のソフトウェアエンジニア世代に貢献するシンプルかつ強力なシステムを生み出すことである

(2026/04/16)

手戻りを防ぐ、AI駆動プロダクト企画開発プロセス

(2026/04/15)

3つの「AI精神症」――投資家のAI妄想、経営者のAI妄想、そしてAI批判者のAI妄想

要約:

■ 1. 「AI精神病」という用語の定義と背景

  • 「AI精神病（AI psychoses）」はチャットボットによって誘発・増幅された妄想を抱く人々を指す比喩的用語
  • 医療問題と隣接するため将来的に廃止が予測されるが現時点では有用な比喩として機能する
  • 妄想そのものは新しい現象ではなく歴史的先例が存在する
    • モルゲロンズ病：体内でワイヤーが成長するという妄想であり17世紀に遡る
    • 集団ストーキング妄想：陰謀集団が隠しメッセージを送り込むという信念であり数世紀前から存在する
  • インターネットはまばらに分布する同種の妄想を持つ人々の連帯を可能にし妄想を増幅させる
  • LLMは昼夜を問わず即座に迎合的な応答を返すことで妄想をさらに深層へと引き込む
  • 一過性の認知の誤作動をチャットボットに説明させることで完全に誤った信念体系（妄想）が構築される危険がある

■ 2. 投資家のAI精神病

  • AIは史上最大規模の投資バブルを形成しており6000〜7000億ドル以上が投じられている
  • AIは劣悪なユニットエコノミクスを持つ
    • ユーザが増えるごとにコストが増加する
    • 利用するたびに損失が拡大する
    • 技術世代が進むほど損失が増加する
  • AI企業の全売上を合わせても年間600億ドル程度であり黒字化への道筋が存在しない
  • データセンター・GPUの実際の耐用年数（2〜3年）を5年と偽る会計詐欺が横行している
  • 「ビザンティン・プレミアム」：投資機会があまりにも複雑で投資家が理解できないために騙されやすくなる構造が成立している
  • 損失の大きさを投資の魅力に転換するナラティブが機能している
  • 巨大テック企業は自社市場の飽和後にメタバース・Web3・暗号通貨・AIと投機的新規事業を乗り継ぎ成長ナラティブを維持し続けている

■ 3. 経営者のAI精神病

  • 経営者は労働者を代替できるものなら何にでも飛びつく傾向がある
  • AIは「全ての出力が自分に直接帰属する」という経営者の自己顕示的妄想を強力に刺激する
  • チャットボットが労働者の仕事をこなせないという事実よりもボスを説得できるという事実の方が重要な結果をもたらす
  • 人間をAIで代替した結果が壊滅的な事例（AWSの障害など）が現実に発生している
  • AIセールスマンは経営者の妄想をさらに深化させ企業全体をその妄想に賭けさせる

■ 4. 批判者のAI精神病

  • 批判者のAI精神病とは「AIは例外的にひどいテクノロジーだ」という信念
  • これはAI企業の誇大宣伝を批判として繰り返す「クリティハイプ（criti-hype）」の一形態
  • AIはふつうのテクノロジーであり例外的な性質を持たない
    • 環境コストや雇用への脅威はバブルによるものであり技術自体の性質ではない
    • 問題のある人物や機関がテクノロジーを推進することは歴史上一般的な現象
    • チャールズ・バベッジは奴隷農園管理のために汎用コンピュータを発明した
    • エイダ・ラブレスは競馬の賭けのためにプログラミングを考案した
    • ウィリアム・ショックレーはシリコントランジスタの共同発明者でありながら優生学者だった
    • IBMはアウシュビッツ用タビュレータを製造した
  • AIの例外性という主張を増幅することはAI企業のバブル維持を助ける結果になる
  • AI企業の罪は株式詐欺と労働者の困窮化にあり人類の知識をスクレイピングすること自体ではない
  • サム・アルトマンらはふつうの詐欺師であり例外的な大悪魔として扱うことは彼らの評判を高めるだけ

■ 5. 自動化の二形態とテクノロジーの政治性

  • 自動化には二種類が存在する
    • 速く安く作るための自動化：資本が好む形態
    • より良いものを作るための自動化：労働者が好む形態
  • ケンタウロス：機械を使って人間の目的を達成する形態（自動はんだ付け機を活用するホビイスト）
  • 逆ケンタウロス：機械の周辺機器として人間が酷使される形態（組立ラインの労働者）
  • テクノロジーに政治が埋め込まれているのは事実だが単純・明白・不変ではない
  • 労働者が自らの判断で自動化ツールをどう使うかを決められる世界の方がよりよい
  • 逆ケンタウロスは経営者の決定がもたらす結果であってテクノロジーがもたらす結果ではない

■ 6. AIをふつうのテクノロジーとして扱うことの帰結

  • 多くの熟練した実践者がAIをプラグインのような普通のツールとして活用している
  • これらの実践者はAIを神やセラピストと取り違えておらず控えめな熱意で受け入れている
  • 熟練した労働者の実体験を否定することは正当でない
  • AI以前の自動化ツールにもプログラマを誤った方向に導くものは存在しており例外ではない
  • AIが例外的だという信念は批判者を誤った方向へと追い込む
    • 熟練の実践者が特定のツールを使うべきかどうかについてツールの道徳的性格に基づいて判断するという誤りを犯す
  • 例外的ではないからこそ他のテクノロジーを律するのと同じ力学がAIにも当てはまる
  • AI製品の有用性は何をするかによって決まり誰が作ったかや資金の出所には依存しない

(2026/04/14)

ハーネスエンジニアリングはただの環境構築では？

要約:

■ 1. ハーネスエンジニアリングの概要

  • 「ユーザの想定通り・望み通りに動くような環境」を作る試みとして定義される
  • 2026年1月〜2月頃からZennで散見されるようになった概念である
  • AIエージェントの挙動制御のための環境構築を指す

■ 2. 著者の問題提起

  • 著者はわざわざ用語を作るほど困難な話なのかという懐疑的立場をとる
  • SubAgentやAgent Skillなどの概念がすでに存在することから「制御が難しい」という議論に疑問を呈す
  • 「ハーネス」という表現に違和感を示し「Boundaries（境界）」や「Permitted（許可・権限）」の方が正確だと主張する

■ 3. ハーネスの語源

  • 語源として以下の2つが挙げられる:
    • 犬の安全装置
    • 高所作業の墜落制止用器具
  • 両者に共通する解釈として「安全に事を為す装置」が導き出される

■ 4. OpenAI側とarXiv論文側の主張

  • OpenAI側（Codex実験）の主張:
    • 「環境の設計と意図の明確化」によるフィードバックループ構築を強調する
    • 制御システムの設計による環境整備を重視する
  • arXiv論文側の主張:
    • 制御ロジックを「自然言語の実行可能アーティファクト（NLAH）」として外部化することを提案する
    • モジュール化と体系的な研究対象化を目指す

■ 5. 両者の共通点と相違点

  • 共通点:
    • モデル性能よりも「制御構造」が成果を左右するという見解を共有する
    • フィードバックループの重要性を重視する
  • 相違点:
    • 構築手法が異なる（制御システム設計 vs 自然言語ベースのモジュール化）

■ 6. 結論

  • ハーネスエンジニアリングは「AIエージェント挙動制御のための環境構築」である
  • 単なる環境構築にとどまらず終わりのない継続的なプロセスである
  • AIの進化への「追随」が必要とされる点が従来の環境構築と異なる

(2026/04/14)

Harnessing Claude's Intelligence | 3 Key Patterns for Building Apps

要約:

■ 1. 概要

  • Anthropicが2026年4月2日に公開したブログ記事であり Claudeを用いたアプリケーション構築における3つの中核パターンを示す
  • 知性・レイテンシ・コストのバランスを取りながらモデルの進化に対応する設計思想を論じる

■ 2. パターン1: Claudeが既に知っていることを活用する

  • bashやテキストエディタなどClaude が熟知しているツールを優先的に活用する
  • Claude 3.5 Sonnetはこれらの基本ツールのみを用いてSWE-bench Verifiedで49%のスコアを達成した
  • Claudeは汎用ツールをプログラマティックなツール呼び出しやメモリ機能など多様なパターンへと組み合わせる

■ 3. パターン2: 「何をやめられるか」を問い直す

  • Claudeの能力向上に伴いエージェント設計の前提を継続的に見直す必要がある
  • オーケストレーション:
    • どのツール出力を処理すべきかをClaudeがコンテキストウィンドウを通じて判断できるよう委譲する
    • すべての結果をオーケストレーターに戻すことを必須とする設計を廃止できる
  • コンテキスト管理:
    • タスク固有の指示をスキルを通じて段階的に開示するプログレッシブディスクロージャーを採用する
    • 全情報を事前ロードする方式から移行できる
  • メモリの永続化:
    • コンパクションやメモリフォルダを通じてClaudeが記憶対象を自律的に選択できるようにする
    • ゲームのプレイログを例として挙げ 旧世代モデルが全履歴を記録していたのに対し 新世代モデルは戦術メモを生成するようになった変化を示す

■ 4. パターン3: ハーネスによる境界設定

  • 高いセキュリティや可観測性が求められる箇所では専用ツールを設け静的コンテンツを先頭に配置するなどキャッシュ最適化を行う
  • ユーザー確認や監査証跡が必要な高リスクな操作は型付きツールに昇格させセキュリティ上の判断をハーネスで強制する

■ 5. 主要な示唆

  • モデルの能力が向上するにつれて旧来の設計上の前提が「不要な重荷」となり蓄積する
  • コンテキストリセットによる「コンテキスト不安」の解消など かつて有効だった手法がより高性能なモデルでは不要になる例を示す
  • 開発者は能力の進化に応じて設計上の前提を継続的に再評価することが求められる

(2026/04/14)

TechLead Conference 2026

MEMO:

(2026/04/13)

GoのAPI開発が変わる！GinやChiに乗せるOpenAPI層「huma」の魅力

humaの本当の立ち位置は、「GinやChiなどの既存ルーターの上に乗せて、型安全なリクエスト処理とOpenAPIドキュメントの自動生成を提供する層」 なのです。

huma自体はHTTPリクエストのルーティング（URLパスと関数の紐付け）を行いません。ルーティングは Gin、Chi、Echo、あるいは標準の net/http に任せます。humaは、そのルーターの「ハンドラー（コントローラー）」として機能し、以下の役割を担います。

  1. リクエストの型安全なパースと自動バリデーション
  2. レスポンスの型安全なシリアライズ
  3. Goの構造体（コード）からのOpenAPI 3.1仕様書とJSON Schemaの完全自動生成

つまり、humaは 「HTTPパッケージのようなもの」ではなく、「GinやChiをFastAPIのように進化させるための拡張パーツ」 と捉えるのが正解です。

MEMO:

(2026/04/13)

LINEヤフーは“社員の失望”とどう向き合うのか…フルリモートを約束→廃止の企業に求められる「優秀層...

要約:

■ 1. LINEヤフーの出社回帰方針とその背景

  • 2026年4月に赤坂オフィスを開設し週3回出社を原則とする体制への移行を公表
  • 2020年に旧ヤフーが「コロナ収束後もフルリモートを継続する」と発信した過去投稿との整合性を問う声がSNS上で噴出
  • 組織人事コンサルタントの曽和利光氏はこの決定を「共創と育成を取りにいく強い経営意思の表明」と位置づけつつ採用ブランドや心理的契約という見えにくい資産への影響を伴う繊細な経営判断と評価

■ 2. 納得なき変更が生じさせる代償

  • 心理的契約の問題:
    • 組織行動論における心理的契約とは雇用契約書に書かれない相互期待すなわち「約束だと信じられているもの」を指す
    • DeniseRousseauの整理によれば心理的契約は当事者が「約束がなされた」と信じることで成立しその違反認知は態度と行動をマイナス方向に変える
  • SNS投稿の影響:
    • 法的拘束力はないが期待形成としての効果は文書化された規程に劣らないほど強い
    • 一度形成された期待は後日の方針変更を「裏切られた」と受け取られやすくする
  • 「事実として違法でないこと」と「心理的に納得されること」は別物であり納得が得られなければエンゲージメントが低下し優秀層から静かに離職していく

■ 3. 人事のプロが提言する7つの対策

  • 第一：見直し条件の明示:
    • 「何が起きたら出社を増やす・減らす」をKPIとセットで提示する
    • 意思決定リードタイムやエンゲージメント・離職意向などの指標を社内に開示し定期的にレビューする
    • 出社が「信仰」ではなく「仮説検証」となることで納得性が生まれる
  • 第二：例外を制度として扱う:
    • 育児・介護・治療・障害・遠隔居住は多くの企業で常態であり例外ではない
    • 基準・手続・守秘・更新をルール化し現場上長の恣意に任せない
  • 第三：代償措置と経過措置の用意:
    • 転居猶予・段階導入・遠距離通勤者への補助・サテライトやコワーキングの活用を講じる
    • 就業規則の不利益変更における合理性判断でも代償措置は重要な考慮要素となる
  • 第四：出社日の業務内容の工夫:
    • 出社日にはオンボーディング・コードレビュー・部門横断の意思決定など対面の必然性が高い活動を集約する
    • 集中作業はリモートに寄せることでハイブリッド勤務が機能する
  • 第五：評価制度との整合:
    • 出社の多寡が評価に影響するように見えた瞬間に心理的安全性が崩れる
    • 近接性バイアスを避けるためのガードレールを明文化し管理職への教育を実施する
  • 第六：データ開示と対話プロセス:
    • Gartnerの調査では出社回帰が離職を増やすことへの懸念はHR側で広く共有されている
    • サーベイ・タウンホール・個別相談窓口などで社員の声を拾う仕組みを先に設置し決定後も改善を継続する
  • 第七：採用戦略のアップデート:
    • 職種別にリモート比率の高い役割を残す・地方拠点やサテライトを組み合わせる・転居支援とセットにするなどの再設計が必要
    • 国土交通省の令和7年度調査でテレワーク実施率は増加傾向に転じており候補者のリモートワーク志向は消えていない

■ 4. 問われるのは「決め方」と「直し方」

  • 週3回出社・フルリモートいずれが正解かは職種構成・評価制度・管理職の力量・出社日の設計によって異なる
  • 経営や人事に求められるのは決定そのものではなく以下の能力:
    • なぜそう決めたかを言語化できること
    • 例外と代償をどう設計するかを示せること
    • データに基づいて修正する勇気を持つこと
    • 社員と候補者に対して誠実に説明し続けられること
  • 出社回帰の波の後にも別の最適解が現れる可能性があり「変化を扱える組織」をつくることが経営・人事部門に求められる最大の責務

(2026/04/12)

60年前から存在するメモリの欠陥を克服し、レイテンシーを削減する新たな手法「Tailslayer」が登場

要約:

■ 1. 背景: DRAMのリフレッシュ問題

  • DRAMはキャパシタに蓄えられた電荷の有無で「0」と「1」を判別する仕組み
  • キャパシタ内の電荷は時間と共に失われるため「リフレッシュ」作業が定期的に必要
  • リフレッシュ中はメモリへのアクセスが不可となる
  • CPUがリフレッシュ中にメモリアクセスを試みると数百ナノ秒〜数マイクロ秒の待機時間が発生
  • この問題は1966年のDRAM考案時から60年以上にわたり存在
  • CPUのクロック数換算で数千クロック分に相当し金融などリアルタイム性重視の分野で問題視

■ 2. Tailslayerの概要と開発者

  • Google研究員のローリー・ワイアード氏がDRAMのリフレッシュ問題を克服するライブラリ「Tailslayer」を公開
  • 書き込み時に複数の独立したDRAMチャネルへデータを複製する仕組み
  • 読み込み時は全複製先アドレスへ同時に読み取り命令を送り最初に応答したデータを採用
  • いずれかのチャネルがリフレッシュ中でも他チャネルから応答を得ることで待機時間を回避

■ 3. 技術的実装

  • 実装方法:
    • メモリコントローラーが物理アドレスを扱う方式を統計的なタイミング測定によって特定
    • チャネルスクランブリングオフセットを用いてデータが異なるチャネルに配置されるよう書き込みを実施

■ 4. 性能評価

  • AMD EPYC 9255での検証結果:
    • 複製数に応じて2〜6段階でレイテンシー分布を測定
    • 6箇所複製の設定では最悪ケースでもレイテンシーを250ナノ秒程度に抑制
  • 複数プラットフォームでの検証:
    • AMD・Intel・GravitonなどさまざまなCPUとメモリの組み合わせで効果を確認
    • いずれの環境においても6複製時にレイテンシースパイクを回避
  • 99.99パーセンタイル点でのレイテンシーを最大15分の1まで削減

■ 5. 活用用途

  • 高頻度取引(HFT)など極めてわずかな遅延が大きな影響を与える分野への活用が見込まれる

(2026/04/12)

アーキテクチャモダナイゼーションとは何か

要約:

■ 1. 発表の概要

  • 発表タイトル: 「アーキテクチャモダナイゼーションとは何か ― 技術・事業・組織で大事なこと」
  • 発表者: nwiizo（株式会社スリーシェイク所属のソフトウェアエンジニア）
  • 発表の軸: Nick Tune「アーキテクチャモダナイゼーション」（翔泳社, 2026）およびSusanne Kaiser「Architecture for Flow」（Addison-Wesley, 2025）の2冊
  • 目的: 「モダナイゼーション」の実体を掴み、なんとなくではなく構造で判断する軸を持ち帰ること

■ 2. 発表の構成と前提

  • 技術・事業・組織の3軸を同時に動かすことが主題
  • 技術軸: 何を変えるか（境界・結合・疎結合の本質）
  • 事業軸: なぜ変えるか（ドメイン・進化段階・投資判断）
  • 組織軸: 誰が変えるか（チーム設計・認知負荷・文化）
  • 1つだけ動かせば残り2つが設計図を上書きするという構造的問題を提起
  • 本フレームはすべての組織に当てはまるわけではなく、文脈によって3軸のバランスは変わる
  • 「3軸同時」は完璧解ではなく自組織の盲点を可視化する装置として活用すべき

■ 3. 設計判断が間違う構造

  • 技術・事業・組織それぞれに「よくある語られ方」が存在し、一見正しく聞こえるが構造的に間違っている
  • 技術の「よくある語られ方」:
    • 「マイクロサービスにすれば速くなる」「疎結合にしよう」「コンテナ化すれば運用が楽になる」といった語り方が典型
    • 手段の名前が出た瞬間に「なぜそうすべきか」を考えなくなる
    • 成功事例には生存バイアスがあり、失敗した企業の声は聞こえない
  • 事業の「よくある語られ方」:
    • 「DXを推進する」「売上20%増」「リリース速度2倍」は目標であって戦略ではない
    • 「うちもAIを入れないと取り残される」という周囲に流される意思決定が起きる
  • 組織の「よくある語られ方」:
    • 「Spotifyモデルを導入した」「Team Topologiesに基づいて再編した」は他社のアーキテクチャをコピーするのと同じ問題
    • 「チームを再編しよう」「アジャイルを導入しよう」は仕組みの導入として語られるが、組織図を変えても報告ラインが変わるだけ

■ 4. 各軸で間違う構造の本質

  • 技術で間違う構造:
    • 技術の名前には「正解感」があり、名前が判断の代わりを務める
    • 文脈を無視して手段だけを借りることが根本的な誤り
    • 技術の名前が出た瞬間に「なぜ」が消えるなら、それは選定ではなく信仰
  • 事業で間違う構造:
    • 分析を省略するほうが簡単なため、標語で済ませてしまう
    • 判断基準がなければ残るのは同調圧力だけとなり、隣の会社がやっているという理由で投資判断が下される
    • 診断を省略した目標設定は速いのではなく雑なだけ
  • 組織で間違う構造:
    • 掲げた言葉ではなく実際に起きたことを信じるのに、言葉だけ変えて行動を変えない
    • 仕組みに変化を任せることが誤りであり、見えやすいものを変えて見えにくいものを放置するのは変革ではなく自己満足
    • 組織図を変えるのは簡単だが難しいのは人の行動が本当に変わること

■ 5. 技術への情熱とBVSSHフレームワーク

  • 技術への情熱がなければ設計は前に進まない
  • 信仰が常に間違うわけではなく、熱量がすべてを凌駕することもある
  • アーキテクチャモダナイゼーションにはBVSSHというフレームワークが存在する
  • BVSSHの5軸: Better（品質）、Value（価値）、Sooner（速度）、Safer（安全性）、Happier（幸福）
  • 開発者の幸せはオマケではなく5軸のひとつ
  • 問題は信仰そのものではなく、信仰が「なぜ」を省略する口実になること

■ 6. アーキテクチャモダナイゼーションの定義

  • マイクロサービス化でもクラウド移行でもない
  • 技術は名前で判断を代替し、事業は周りに合わせて走り出し、組織は仕組みに変化を任せる構造はすべて3つの軸のうち1つだけを語り残りを無視している
  • アーキテクチャモダナイゼーションとは技術・事業・組織の現状をそれぞれ正直に見直し、3つを同時に動かすこと
  • リプレースでもリライトでもなく、3つの軸を同時に見直す終わらない営み

■ 7. 「同時に」でなければならない理由

  • 3つの軸はつながっている
  • どこでシステムを切るか（技術）はチームの分け方（組織）を決め、チームの分け方はどこに投資するか（事業）に縛られ、投資の判断はシステムの切り方に戻ってくる
  • ぐるっと一周する関係だから1つだけ動かしても残り2つが元に引き戻す
  • 「同時に」とは全部を一度に変えるという意味ではなく、何かを変えるとき他の2つにどう影響するかを考えながら小さく動かすこと
  • 技術だけの改善計画・事業だけの戦略資料・組織だけの再編提案がバラバラに作られている組織はすでに部分最適の罠にはまっている

■ 8. 3つが同時に語られない理由

  • 理由1 ― 専門の壁: 技術の話は技術者が、事業の話は経営者が、組織の話はマネージャーが語り、それぞれの専門が深くなるほど他の軸が見えなくなる
  • 理由2 ― 具体性の罠: 3つを同時に動かしている組織は存在するが1人のエンジニアや事業責任者が語ることではなく、現場では複数の人が複数の軸を少しずつ動かしているため個々の具体例は抽象化しにくくカンファレンスで語れる形にならない
  • 3つが互いに影響し合う現実をひとつの枠組みで語ることは本質的に難しい
  • 3つを同時に語れる言葉はまだ誰も持っていないため、組織は3つを別々に語る分業を生む

(2026/04/11)

制約を設計する - 非決定性との境界線 / Designing constraints

要約:

■ 1. 発表概要

  • タイトル:「制約を設計する - 非決定性との境界線」(設計ナイト 2026)
  • 発表者: 曽根壮大 (Have Fun Tech LLC 代表社員 / 株式会社リンケージ CTO兼COO)
  • テーマ: LLMの非決定性という課題に対し、制約を設計することで決定性を確保するアプローチを論じる

■ 2. 非決定性との境界線

  • LLMの非決定性の本質:
    • 同一インプットに対して実行ごとに異なるアウトプットが生成される
    • 複数回実行しても出力は不定だが精度は向上する
    • LLMは確率的に、人間は経験的に答えるという違いはあるが、どちらも同一アウトプットを保証しない
  • 標準化による解決:
    • 標準化によって単純化・統一化が行われ、アウトプットのばらつきが揃い品質が向上する
    • 手順の標準化は手順書の作成を意味する
    • 入力の標準化としてテンプレート作成や判断分岐の網羅・対応行動の決定を行う
    • チェックリストによって必要な仕様を満たすことを確定させる
    • 暗黙知を明示的・測定可能・更新可能な仕組みに変えること(業務の言語化)
  • 境界線の必要性:
    • 非決定性の高い状態から決定性の高い状態へ移行するためには境界線が必要
    • ソフトウェアはハードウェアのために非決定的な現実世界を仕様として決定する役割を担う
    • Webフォームが人間とソフトウェアの境界線として機能し、内部のREST API・バリデーション・ロジック・型・データベースは決定性の世界を構成する
    • 再現性を高めるためには境界線の設計が不可欠

■ 3. 制約が決定性を作る

  • 基本原則:
    • ソフトウェアの世界における制約が境界線を作り、品質の担保と安全性を設計する
  • 具体例(GeminiによるGoogleカレンダー操作):
    • 直接指示するだけでは品質が安定しない
    • Gemini → GAS → API → Googleカレンダーという経路に制約を設けることで安定化する
    • GASのバリデーションによってハルシネーションを防ぐ
    • APIレイヤーでエラー処理・リトライが実現できる
  • ソフトウェアにおける境界線の設計例:
    • REST APIは責任境界線とセットで決定性を作る(CLIインターフェースも同様)
    • 標準入力のバリデーションが制約として境界線を形成する
    • アウトプットの品質が固定される(内部にLLMを含む場合は非決定性が維持される)
    • データ層には決定された事実が保存される(集計・分析の元データは揺らいではならない)
    • 契約プログラミングの概念と類似する
  • 制約はガードレールとして機能し、AIが間違った方向に進むことを防ぐ

■ 4. 制約以外のアプローチ

  • 制約はガードレールによってAIの方向性を制限するが、ゴールに直接導くわけではない
  • ハーネスエンジニアリングも標準化の方向性の一つとして位置づけられる
  • ゴールへ導くための手法:
    • テストコード: ソフトウェアに対する期待値を明確化する
    • オブザーバビリティ: ソフトウェアの振る舞いを可視化する
    • 境界線: ソフトウェアのスコープを決める(ドメインモデルと同義)
    • アウトプットの品質指標: コードの方向性を決める(ただし安易な指標はグッドハートの法則を招く。LLMも同様)
  • モデルが変わると設計が陳腐化する課題があるため、コミュニティの集合知を活用することが現実的な対策となる

■ 5. おわりに

  • ソフトウェアエンジニアの役割の変遷:
    • これまで: 人間のあいまいな要求を仕様として決定してきた
    • 今後: 人間とAIの非決定性をソフトウェアとして決定していく
  • AIの発展と人間の学習:
    • AIがどれほど発展しても、仕事の形は変われど抽象度を高める視点は変わらない
    • 知識のある者がAIを活用できることは確かである
    • 理由: 良い質問をするための知識が必要 / AIの出力を評価する能力が必要 / 抽象的なアドバイスを活用する能力が必要
    • AI普及後も人が学ぶことの重要性は変わらない
  • 変化への対応:
    • 半年後の状況は予測できないからこそ、変化できる設計が重要
    • 「どうでもよいことは流行りに従い、重大なことは標準に従い、ドメインのことは自分ら設計する」(郡山昭仁)
    • 不易流行(松尾芭蕉): 変わらない本質を大切にしつつ時代の変化に応じた新しいものを取り入れる
    • 温故知新(孔子): 過去の事実を研究し新しい知識や見解をひらく
  • 結論: 眼の前の問題を解決できるのは自分自身であり、現実と設計を楽しむことが重要

(2026/04/11)

Rails: 個人開発環境の Docker 化をやめた理由（翻訳）

MEMO:

(2026/04/11)

Ubuntu 26.04（resolute）の開発; 要求スペックの変更とUbuntu Mateの新メンテナ募集

これまでは4GBメモリが要件となっていたため、「⁠Windows 11よりも多くのリソース（特に、6GBメモリ）を要求する」ということでいろいろな技術サイトでさまざまな話題になっています。

なんとなく言葉遊びとして不毛な部分もありつつ、「⁠Windows 11の新規インストール要件はTPM2.0などのより複雑な要件（＝比較的新しいCPUが搭載された環境）を要求する」「⁠そもそもメモリを消費するのはアプリケーションで、特にWebブラウザがどれぐらいのメモリを消費するかが支配的」といった点が議論されており、「⁠古くなったマシンをLinuxデスクトップを用いて再生する」といった捉え方がまだまだ残っていた、ということがわかります（Xubuntu, Lubuntuは2GBメモリが最低要求なので、「⁠メモリが少ないマシン」での利用はこれらを使うことになるでしょう⁠）⁠。

MEMO:

(2026/04/11)

アダムバック、「自分はサトシではない」と調査報道を否定

ブロックストリーム（Blockstream）のCEOであり暗号学者のアダム・バック（Adam Back）氏が、自身がビットコインの創設者サトシ・ナカモト（Satoshi Nakamoto）であるとの指摘を否定した。同氏は4月8日、自身のXアカウントで「自分はサトシではない」と投稿した。

この発言は、米紙「ニューヨーク・タイムズ（The New York Times）」が同氏をサトシ・ナカモトの有力候補とする調査報道を掲載したことを受けたものとみられる。同報道は、サイファーパンク（Cypherpunk）のメーリングリストにおける過去の投稿データや文体の類似性などをもとに分析したものだが、同氏をサトシと断定するものではない。

バック氏は投稿で、自身が1990年代初頭から暗号技術や電子マネー、プライバシー分野に関心を持ち、サイファーパンクの議論に参加してきた経緯を説明した。そのうえで、自身がサトシと結び付けられる背景について、発言量の多さなどにより関連性が過大に評価される「確証バイアス」の可能性を指摘している。

また同氏は、自身を含む複数の研究者がビットコインに類似するアイデアに取り組んでいたとし、「サトシが誰であるかは分からない」と述べた。さらに、ビットコインにとって創設者の正体が不明であることは望ましい側面もあるとの見解を示している。

なおビットコイン創設者の正体を巡っては、これまでも複数の人物が候補として取り沙汰されてきたが、いずれも決定的な証拠は示されていない。

(2026/04/10)

ここんところのWeb界隈についての主観的記録

要約:

■ 1. JSフレームワーク戦争の帰結

  • ReactがVue.jsとの競争に勝利した
  • 採用企業の増加が正のループを形成しフロントエンドエンジニアの実用的武器となっている
  • 学習者には特別な事情がない限りReactを優先して習得することを推奨する

■ 2. Vercelの台頭とNext.jsの優位

  • Next.jsがNuxtとの競争に勝利した
  • Vercel社はフレームワークから実行環境まで一手に引き受けるプラットフォーム事業を展開している
  • NuxtもVercel傘下に収められている状況にある

■ 3. Pax Reactia（パクス・リアクティア）とフレームワーク倦怠感

  • 著者の造語「Pax Reactia」はReactを中心とした安定期を表す
  • State of JSのデータがフレームワークへの満足度低下を示している
  • フレームワークは成熟に伴い高度化し習得難易度が上昇している
  • 革新的機能よりも個別最適化型の地味な新機能が主流になると予想される
  • 技術変化の速度が過去と比較して鈍化しつつあるという認識を示している

■ 4. JSランタイム・開発環境競争の激化

  • Node.jsに代わる候補としてDeno・Bun・Biome・Vite+が競争を繰り広げている
  • 将来的にNode.jsが過去の技術として語られる可能性を示唆している

■ 5. Tailwind CSSの功罪

  • 功績:
    • CSS設計の煩雑さからの解放に貢献した
  • 問題点:
    • 根源的なCSS設計の問題をJavaScriptに肩代わりさせているに過ぎない
    • フレームワークを使わないプロジェクトでは効果が限定的である
    • CSS設計がロストテクノロジー化する懸念がある

■ 6. ネイティブCSSによるJavaScript代替の進展

  • ネイティブCSS技術の進歩によりJavaScriptが不要なCSS機能が増加している
  • JavaScriptを個別実装するより容易であるため積極的活用を推奨する
  • ネイティブ技術であるため支援技術との相性がよくアクセシビリティの向上にも寄与する

■ 7. AIとWeb開発の関係

  • AIの影響によりフロントエンド専門エンジニアが不要になる可能性がある
  • 一方でフロントエンドの知見なしにはAIを適切に活用できないため引き続き必要とされる可能性もある
  • 両方向の可能性が相反する形で共存している状況にある

■ 8. 現状認識のまとめ

  • フロントエンドの最先端部分は安定しつつある
  • 根本部分はいまだ不安定な状態が継続している

(2026/04/10)

「OpenSSL」なのに……次期バージョン「OpenSSL 4.0」で「SSL 3.0」対応が完全削除

「OpenSSL」の次期バージョン「OpenSSL 4.0」では、「SSL 3.0」（Secure Sockets Layer version 3.0）サポートが完全に削除される。開発チームが4月7日（米国時間）、公式ブログで発表した。

「OpenSSL」は、インターネット通信で用いられる暗号化実装を提供するオープンソースのライブラリ。SSL/TLSプロトコルの実装をはじめ、暗号化、復号、証明書の管理といった機能を提供する。

「OpenSSL」は1998年12月の誕生当初から「SSL 2.0」（SSLv2）と「SSL 3.0」（SSLv3）の両方をサポートしてきた。つまり、「SSL 3.0」は四半世紀以上前の古い暗号化プロトコルということになる。その設計の古さから、「POODLE」脆弱性をはじめとする多くの問題が指摘されて久しい。

そのため、「SSL 3.0」は「RFC 7568」（2015年6月発行）で廃止が勧告、「OpenSSL 1.0.2h」からはビルド時に既定で無効化されている。これまでは「SSL 3.0」を有効化してビルドすることもできたが、次期バージョン「OpenSSL 4.0」では「SSL 3.0」機能そのものが削除されるため、それも不可能となる。

また、これにあわせて「SSLv2 Client Hello」も廃止されるとのこと。「SSL 3.0」や「SSLv2 Client Hello」を利用しているアプリケーションは、サポートされているTLSプロトコルのバージョン（現時点では「TLS 1.2」または「TLS 1.3」）へ移行する必要がある。

なお、「OpenSSL 4.0」は3月24日の時点でベータ版に達している。このバージョンはもはや「SSL」をサポートしないが、「OpenSSL」の名前に変更はない。

関連:

(2026/04/09)

Domain Modeling Made Functionalの読書メモ

(2026/04/08)

AIのお世話が辛いのでUsecase Design Docを書く

(2026/04/08)

axios, LiteLLM...不使用だったのでOK、ではない。「次に備える」ソフトウェアサプライチェーン侵害への対策

(2026/04/07)

Karpathy 氏が言語化した「LLM Knowledge Base」というパターン

要約:

■ 1. 概要

  • 2026年4月3日にAI研究者Andrej Karpathy氏がX上で「LLM Knowledge Bases」を投稿し1300万回以上の閲覧を集めた
  • 翌日に詳細なアイデアファイルがgistとして公開された
  • 多くの人がすでに類似の試みを行っていたことが大きな反響の背景にある
  • Karpathy氏の投稿は散発的な試みに名前と構造を与えた

■ 2. LLM Knowledge Baseのコンセプト

  • 生のドキュメントをLLMに渡し構造化されたMarkdownのwikiを「コンパイル」させるアイデア
  • RAGが「質問のたびにドキュメント断片を検索して回答する」アプローチであるのに対し知識をあらかじめ構造化して永続化する点が異なる
  • wikiは使うたびに育つため知識が複利的に蓄積される

■ 3. 3層アーキテクチャ

  • Raw sources:
    • 記事・論文・リポジトリ・画像など不変の精選ドキュメント
    • Web記事はObsidian Web ClipperでMarkdownに変換し関連画像もローカルに保存することでLLMが参照しやすくなる
  • Schema:
    • wikiの構造や規約を定義する設定ドキュメント
    • カテゴリの整理方法やファイル命名規則などのルールを記述するいわばwikiの「設計図」
  • Wiki:
    • LLMが生成したMarkdownファイル群
    • Raw sourcesのサマリー・概念ごとのエンティティページ・バックリンクで構成される
    • 人間が直接書くことはほとんどなくLLMの領域であり人間はキュレーションと方向づけに集中する

■ 4. 3つの操作

  • Ingest（取り込み）:
    • 新しいソースを処理してwikiに統合する操作
    • LLMがドキュメントを読みサマリーを書き関連エンティティページを更新しindex.mdを改訂する
    • 既存の知識との矛盾も解消される
  • Query（質問）:
    • wikiに対して質問を投げ回答を得る操作
    • 回答を新たなページとしてwikiに「filing back」することで探索や質問がそのまま知識として蓄積される
  • Lint（健全性チェック）:
    • wiki全体に対するヘルスチェック
    • 矛盾するデータ・古くなった主張・孤立したページ・欠落したリンクをLLMが検出し修正を提案する

■ 5. 意図的な抽象さ

  • Karpathy氏自身がこれを「hacky collection of scripts」と呼んでいる
  • 完成されたプロダクトでも確立された方法論でもなく探索段階の共有と位置づけている
  • gistに「意図的に少し抽象的/曖昧にしている。方向性がたくさんあるから」と記載されている
  • 概念としてはVannevar Bushが1945年に提唱したMemex（ドキュメント間の連想トレイルを辿る装置）に通じる

■ 6. RAGとの違い

  • RAGはクエリごとにドキュメント断片を検索してLLMに渡すアプローチで永続的な構造を持たない
  • LLM Knowledge Baseは事前に情報を読み込んで構造化し永続的なwikiとして保持する
  • Karpathy氏は約100記事・約40万語規模ではRAGなしでもLLMがindex管理とサマリー維持をうまく行えると述べている
  • ドキュメントが数千件・数百万語規模になると異なる可能性がある
  • 「RAGかwikiか」は二択ではなくアドホックな質問にはRAG的検索が全体像の把握にはwikiが適するという使い分けが実用的

■ 7. Claude Codeでの実装例

  • Karpathy氏の投稿以前からMem0によるfact抽出やベクターDBへのドキュメント蓄積・監査コマンドなどのセッション間知識永続化の仕組みを持っていた
  • 既存のメモリ基盤の上にwiki層を載せる形で/kb-compileというカスタムコマンドを作成した
  • ディレクトリ構成:
    • workspace/knowledge/ がRaw sourcesに相当（日報・リサーチ・セッションログ）
    • 各ディレクトリのCLAUDE.mdがSchemaに相当
    • workspace/wiki/ がCompiled Wikiに相当
    • Memory MCP（Mem0 + pgvector）という検索レイヤーも併用しRAG的検索とwikiの両方を使い分ける
  • /kb-compileコマンドの機能:
    • 特定プロジェクトのみのコンパイルや--allオプションによる全体一括更新が可能
    • --lintオプションで矛盾検出・リンク切れチェック・古い記事の検出が可能
  • コンパイルされた_index.mdに30プロジェクトの全体地図がまとまり新セッション開始時の状況把握に活用している
  • 個々のプロジェクト記事にfrontmatterやバックリンクがありObsidianのグラフビューも利用できる
  • 現状の課題:
    • 手動でコマンドを実行しないと更新されない
    • プロジェクト横断のトピック記事は未整備
    • Lintの自動実行が仕組み化できていない

■ 8. まとめ

  • Karpathy氏の投稿の核心は「LLMをコンパイラとして使う」という発想の転換
  • コードを書かせるだけでなく知識の整理・構造化・保守をLLMに任せる
  • 人間は退屈な保守タスクから解放されキュレーションと方向づけに集中できる
  • Karpathy氏は「hackyなスクリプトの寄せ集めではなくここには素晴らしいプロダクトが生まれる余地がある」と述べている

(2026/04/06)

実務経験ゼロでもシステムエンジニア　派遣会社が経歴詐称を強要　早期の退職で精神的苦痛

システムエンジニア（SE）の派遣会社に採用され、取引先で勤務した元SEの男性3人が、実務経験がないのに経歴詐称を強要されて精神的苦痛を受けたなどとして派遣会社代表らに賠償を求めた訴訟で、最高裁は、賠償を命じた東京高裁判決を不服とした代表らの上告を棄却した。原告の支援者らは「派遣会社は名前を変えながら従業員の経歴詐称を続けており、問題は終わっていない」と警鐘を鳴らしている。

男性らは、未経験者をSEとして採用するという求人広告などで、被告らが経営するSE派遣企業に入社した。

前後して、SEに必要な技術の習得を名目として、「スクール」の受講を求められ、受講料を支払ったが、SEとしての経歴を偽る「スキルシート」の作成や面接の練習をさせられたという。

男性らは、能力に見合わない多くの業務を担当させられて退職し、精神的苦痛から退職に追い込まれたとして提訴した。

令和6年7月の東京地裁判決は、未経験者を経験者と偽って派遣する代表らの事業は「詐欺行為により利益を得ようとするもの」と指摘。スクールは「詐欺を実現するための手段」で「社会的な相当性を欠く」と非難し、被告側に3人分計約516万円を支払うよう命じた。

東京高裁はおおむね地裁の判断を踏襲した上で賠償額を計約769万円に増額。最高裁も今年2月、代表らの上告を退け、高裁の判断が確定した。

原告の男性らの相談を受け付けた首都圏青年ユニオンの尾林哲矢執行委員長は、「この件は特殊な詐欺事件と思われるかもしれないが、相場賃金より高い相場を示して未経験者を募集するという点で、闇バイトと共通点がある」と指摘。「IT業界には多重下請け構造があり、派遣を受け入れた企業側のチェックにも問題がある」と述べた。

原告代理人の伊久間勇星弁護士は、「被告らはグループを組織して、一つがだめになれば新しい企業を作って活動を続けている。こうした手口は許されないという社会共通の認識を作る必要がある」と訴えている。

MEMO:

(2026/04/06)

EMにはチームを強くして欲しい

要約:

■ 1. EMの責務

  • EMの責務は「チームを強くすること」
  • チームのボトルネックを特定し自身の作業時間をその解消に充てることが基本的なアプローチ
  • 半年・1年後に「チームが強くなった」と言われ続けることがEMとしての価値
  • EMの責務は「マイナスをゼロにする」と「ゼロをプラスにする」の2段階に分類される
  • マイナスをゼロにする:
    • チームの状態が悪い際に目に見える課題（コミュニケーション問題・開発プロセスの停滞など）を一つずつ解決する行動
    • 課題が可視化されているため何をすべきかは比較的明確
  • ゼロをプラスにする:
    • チームの状態が悪くない状況で潜在的なボトルネックを発見し解消する行動
    • 可視化された課題がない状態での発見が求められるため難易度が高い
    • AI活用による開発スピード向上のように「困ってはいないがさらに改善できる領域」への働きかけが例として挙げられる

■ 2. 強いチームの定義

  • 「強いチーム」の定義に唯一の正解はなく離職率・開発スピード・人材の質など複数の軸が存在する
  • 重要なのはEMのスキルセットとチームメンバーの特性に合致した定義を設定すること
  • 現実から乖離した理想像では実現不可能なため自チームが実際に目指せる方向性を選ぶ必要がある
  • チーム内で「この方向で強くなろう」という合意が取れている状態が望ましい

■ 3. EMのスキルセット

  • EMのスキルセットは以下の4領域に大別される
  • プロジェクトマネジメント:
    • スクラム等の開発プロセスを深く理解しスプリントゴール設定や改善サイクルを確立する能力
    • 外部ステークホルダーからの流入をコントロールしエンジニアが開発に集中できる環境を整える
  • テクノロジーマネジメント:
    • 技術選定・方針決定における意思決定のガードレール設定やエンジニアの相談相手として機能する能力
    • 技術的負債や将来リスクを見据えた判断のサポートを含む
    • エンジニアリングの最低限の知識がなければ適切な育成・評価が不可能
  • プロダクトマネジメント:
    • 仕様・ユーザー価値・事業的価値を理解しエンジニアリング観点での論点整理や仕様検討に貢献する能力
    • プロダクトを理解していないと管理だけして何を作っているか分からない状態になる
  • ピープルマネジメント:
    • 採用: 組織に必要な人物像の定義と採用活動への主体的関与・社外アウトプットによる認知拡大
    • 育成: メンバーのWillとチーム課題を踏まえた成長・活躍のための育成計画設計
    • メンタリング: 日常的フィードバックを通じた心理的安全性とエンゲージメントの向上
  • 理想は4つのスキル全てを最低限習得した上でいずれかに強みを持つこと
  • 実際にはケースバイケースでありPdMが主担当する領域や優秀エンジニアがいる環境では求められる範囲が変わる

■ 4. EMと野球の監督の類比

  • EMは野球の監督に類似した役割を担う
  • 監督の目的「チームを優勝させる」はEMの「強いチームを作る」に相当する
  • 監督のスキルや所属選手の特性によって目指すチームの形が異なる点は「強いチームの定義はEM・メンバーの特性に合わせて決める」という考えと一致する
  • コーチ選定・練習メニュー設計・対戦相手分析など幅広い領域の理解が必要な点はEMに求める4つのスキルセットと対応する

■ 5. EMアンチパターン

  • なんとなくスクラムイベントに参加しなんとなく1on1を実施してチームにポジティブな変化を与えないまま半年が終わる状態はアンチパターン
  • 自分の時間をどう使えばチームにポジティブな変化をもたらし強いチームを作れるかを常に考えることが重要

(2026/04/05)

Bonsai-8Bに関するメモ

■ 1. Bonsai-8Bの概要

  • PrismMLが2026年3月31日にステルスから公開した82億パラメータのLLM
  • モデルサイズは1.15GBで同サイズの標準16ビットモデルの約14分の1
  • エッジハードウェア上で8倍高速かつエネルギー効率は4〜5倍優れる
  • Caltechのリサーチから生まれたスタートアップでKhosla VenturesやCerberusおよびGoogleが出資

■ 2. 1ビット量子化の特徴

  • 全重みが−1または+1の2値のみで表現される
  • 学習後処理ではなくネイティブの1ビット精度でゼロから学習される
  • 埋め込み層・アテンション層・言語モデルヘッドを含む全層が1ビットで構成される

■ 3. 性能と動作速度

  • ベンチマーク平均スコアは70.5点でフル精度8Bクラスモデルと競争力を持つ
  • 知性密度(intelligence density)はQwen3 8B(0.10/GB)を大幅に上回る1.06/GBを達成
  • 動作速度:
    • M4 Pro Mac: 毎秒131トークン
    • RTX 4090: 毎秒368〜440トークン(記載箇所により異なる)
    • iPhone 17 Pro Max: 毎秒約44トークン
  • 標準的な16ビット8BモデルはiPhoneでは動作しないがBonsai-8BはiPhone上でネイティブ動作が可能

■ 4. 対応プラットフォームとハードウェア要件

  • 必要メモリ: 約1.5GB(モデル本体1GB＋オーバーヘッド)
  • 標準のllama.cppやLM Studioは1ビット重みに未対応のためPrismML提供の専用推論エンジンが必要
  • Appleデバイス(Mac/iPhone/iPad):
    • MLXを通じてネイティブ動作
    • M1以降のMシリーズおよびA18以降のAシリーズチップ対応
    • 統合メモリ8GB以上が最低スペック
    • PrismMLのカスタムMLXフォークが必要
  • NVIDIA GPU(Windows/Linux):
    • llama.cppのCUDA経由でネイティブ動作
    • CUDA対応GPUが必須でVRAM 2〜4GB程度で動作可能
    • ただし、標準のllama.cppやLM Studioは1ビット重みに未対応のため、そのままでは動作しない
    • PrismMLが提供するカスタムフォーク版のllama.cppまたはMLXが必要
  • CPUのみ:
    • GPUは必須でなくモダンなCPUで推論可能
    • AVX2対応CPUで速度が向上
    • ただし、現時点ではCPUサポートが不完全で公式ベンチマークが存在しない

■ 5. モデルのバリエーションとライセンス

  • 8Bのほか4Bと1.7Bのモデルも提供
  • GGUF形式とMLX形式で利用可能
  • Apache 2.0のオープンソースライセンス

■ 6. 用途と限界

  • リアルタイム会話AI・コード補完・シンプルなエージェントタスクをローカルで処理可能
  • プライバシー重視のアプリ・オフラインアシスタント・エッジデバイス・ロボティクスへの活用が期待される
  • 多言語対応や複雑な推論が必要なワークロードではより大きなモデルに劣る

関連:

(2026/04/05)

突如実用化した1ビットLLM Bonai-8B もう推論にGPUはほぼ不要になる。その先に何が起きるか

要約:

■ 1. Bonsai-8Bの概要と性能

  • カリフォルニア工科大学(カルテック)のババク・ハッシビ教授率いる研究チームPrismMLが開発したLLM
  • 独自の非公開日本語要約能力ベンチマークにおいて第3位の精度(ROUGE-L)を記録
  • 第2位のQwen3:235b-a22bと比較して1/100のサイズ・10倍の推論速度を実現
  • Googleが発表したGemma4と比較して精度1.25倍・速度3倍でありながらサイズは1/8〜1/10
  • モデルサイズは1.2GB(80億パラメータ)でスマートフォン上での動作を実証
  • Google・カルテック・ベンチャーキャピタルからの資金調達により開発を実現
  • モデルは公開済みだが訓練方法は非公開

■ 2. 1-Bit LLM技術の意義

  • Bonsai-8Bの極小サイズと高速推論を支える中核技術
  • Microsoftが最初に本格開発したが商業的理由(GPU貸出ビジネスへの影響)から積極展開されなかった
  • Bonsai-8Bは初の本格的かつ実用的な1-Bit LLMとして従来手法を凌駕
  • 10GBサイズへ拡張した場合800億パラメータ相当のモデルが一般的なPCで動作可能となる計算
  • その性能規模はDeepSeek-R1に匹敵しゲーミングPCやメモリ24GB搭載のMacで実用的に稼働する見込み

■ 3. ゲーム産業への影響

  • AAAタイトル(大予算ゲーム):
    • 開発期間が数年に及ぶためAI活用の計画が困難
    • AI生成素材に対するスタッフやプラットフォームの慎重姿勢も障壁
  • ハイパーカジュアルゲーム:
    • 基本無料の収益モデル維持のためオンデバイス計算が必須
    • 生成AIの本格組み込みが現状では困難
  • 1-Bit LLMの普及により低予算ゲームへの生成AI統合が現実的になる可能性
  • 将来的に画像・動画生成でも同様の小型化が進めば応用範囲がさらに拡大
  • 著者は「AIゲームセンター構想」クラウドファンディングを個人プロジェクトとして開始

■ 4. コンテンツ・メディア産業への影響

  • スマートフォン上で動作するエージェントAIが個人向けニュース番組を自動生成する時代が到来
  • 著者自身がDGX Spark搭載マシン(約60万円)上でAgenticAI「Siki」を運用中:
    • 24時間ソーシャルメディアと最新論文を監視・解析
    • 数時間ごとに約10分のニュース番組動画を自動生成
  • 現在は高性能マシンが必要だが1-Bit LLM普及後はスマートフォン単体で同等機能が実現される
  • TikTok・InstagramなどのプラットフォームがオンデバイスAI生成コンテンツに移行した場合:
    • ネットワーク維持コストの大幅削減と収益性向上が見込まれる
    • インフルエンサーはAI生成の無限コンテンツとアイデア・根性で競合することを強いられる
  • 固定コンテンツを発信するYouTuberや解説配信者も同様の競争圧力にさらされる

■ 5. 人間とAIの共存における価値の転換

  • 画面内で完結するコンテンツはAI生成物に品質・体験の両面で対抗困難になる
  • 映画DVDと比較してディズニーランドやユニバーサルスタジオが支持される理由の分析:
    • 静的な映像コンテンツと異なり共同体験は毎回異なる
    • 他の観客の存在やライブパフォーマンスが非再現性をもたらす
  • 人間が求めるのは快感だけでなく共感であり共有体験の価値は今後も上昇
  • アメリカではアーケード回帰の流れが生じ酒場とゲーム機を融合した「バーケード(Barcade)」文化が拡大:
    • Raw Thrills社はトップガン・マーベリック・ゴジラ・マーベル等を題材とした筐体を展開
    • 手軽なテーマパーク体験として機能
  • モデル圧縮・小型化の流れはLLMに限らず全AIモデルに適用される不可避な潮流
  • 著者がソフトウェアよりもゲームセンターという非効率な体験に注目する理由もこの文脈に基づく
  • 1-Bit LLM時代の幕開けはAIと人類の関係における新たな時代の到来を象徴

(2026/04/05)

Linux 7.0におけるPREEMPT_NONE削除問題に関するメモ

■ 1. PREEMPT_NONEとは何か

  • Linuxカーネルのプリエンプションモードの一つで、カーネルが原則としてタスクを強制中断しない設計
  • プリエンプションモードの種類:
    • PREEMPT_NONE: ユーザー空間復帰時または明示的なschedule()呼び出し時のみ切り替わる
    • PREEMPT_VOLUNTARY: cond_resched()による任意の降伏点を随所に挿入
    • PREEMPT_LAZY: 通常はNONEに近いがスケジューラ判断でプリエンプト可能
    • PREEMPT_FULL: どこでもプリエンプト可能
    • PREEMPT_RT: スピンロックを含むほぼすべてをプリエンプト可能なリアルタイム対応
  • スループット優先のサーバー向けとして長年利用されてきた

■ 2. PREEMPT_NONEが削除される理由

  • PREEMPT_RTへの統合:
    • Linuxコミュニティは長年PREEMPT_RTのメインライン統合を進めており、カーネルの設計が「どこでもプリエンプト可能」を前提とする方向に移行中
    • PREEMPT_NONEはその前提と根本的に相容れない
  • cond_resched()の乱用解消:
    • PREEMPT_NONEおよびPREEMPT_VOLUNTARYでは長時間CPUを占有するコードパスにcond_resched()を手動挿入する必要がある
    • Peter ZijlstraはこれをPREEMPT_LAZYへの移行により解消できると説明
  • コードの簡素化:
    • 4〜5種類あるプリエンプションモードをFULLとLAZYの2種類に絞ることでカーネルの複雑性を大幅削減

■ 3. 変更の経緯と「急だった」とされる根拠

  • 段階ごとの経緯:
    • 2004〜2024年: PREEMPT_RTプロジェクトが約20年を経てLinux 6.12でメインライン統合
    • 2024年9月: Linus TorvaldsがEurope Open Source SummitでPREEMPT_RTのメインライン受け入れを発表
    • 2024年11月: Linux 6.13にPREEMPT_LAZYが追加。この時点でPREEMPT_NONEは廃止されていない
    • 2026年1月: PREEMPT_NONEをLinux 7.0から廃止するパッチが投入
  • 「急だった」とされる根拠:
    • PREEMPT_LAZY追加からPREEMPT_NONE廃止まで約2ヶ月しかない
    • PostgreSQLのような高競合スピンロックワークロードへの影響が事前に検証されていなかった
    • PREEMPT_RTのメインライン化（2024年9月）からPREEMPT_NONE廃止まで1年余りという短期間
    • Linux 7.0がUbuntu 26.04 LTSに採用される予定であり企業・サーバー環境への波及が大きいタイミング

■ 4. 性能劣化の構造とPostgreSQLへの影響

  • PREEMPT_NONEの保証とPostgreSQL:
    • PostgreSQLは高競合のスピンロックを多用する設計であり「ロック保持中に中断されない」という保証が性能上クリティカル
    • PREEMPT_LAZYへの移行でAWSエンジニアがLinux 7.0リリース約2週間前に性能半減を報告
  • Zijlstraの回答とその問題点:
    • 「PostgreSQL側でRSEQ（Restartable Sequences）のタイムスライス拡張を使え」と回答
    • RSEQタイムスライス拡張自体がLinux 7.0で初めて利用可能になったばかりであり移行コストを下流に一方的に押し付けている

■ 5. カーネルとPostgreSQL開発者間の過去の議論

  • 2011年:
    • PostgreSQL開発者Robert Haasが「スピンロック保持中にプロセスがタイムスライスアウトされることが問題」と正確に分析・認識
  • 2012年:
    • Linux 3.6でのスケジューラ変更によりpgbenchが3.5比で約20%低下
    • カーネル側の議論は「これはカーネルの問題」という前提で行われPgSQL側への修正要求はなかったとLWNが明記
    • PostgreSQL開発者Josh Berkusが「アプリ修正案は機能しない。旧バージョンのカーネルに留まり続けるユーザーが大量発生するだけ」と論証
  • 2026年:
    • PREEMPT_NONEの廃止に際してカーネル開発者とPostgreSQL開発者間の事前正式調整が行われた形跡はない
    • 問題が表面化したのはAWSエンジニアがLinux 7.0リリース約2週間前にメーリングリストへ投稿したタイミング

■ 6. 「性急・強引」という評価の妥当性

  • 「性急・強引」と言える根拠:
    • 置き換え先（PREEMPT_LAZY）の実績が不十分なまま廃止が進んだ
    • 解決策として提示されたRSEQがまだ実用可能でないタイミングでPREEMPT_NONEを廃止
    • LTSとの組み合わせが最悪のタイミングとなった
  • 一概には言えない側面:
    • PREEMPT_NONEはロック保持中の割り込み排除のためカーネル全体の設計を複雑化させる面があった
    • PREEMPT_RTへの移行は20年越しで段階的に告知されており完全に唐突ではない
    • カーネル開発者の責務はシステム全体の健全化であり特定アプリケーションに合わせて設計を曲げることには限界がある
  • 本質的な問題:
    • 技術的な正誤ではなく移行コストの分担の問題
    • 設計の方向性は正当だが移行を支える十分なベンチマーク・検証・猶予期間なしに進めた点は拙速
    • 「調整の仕組みが機能しなかった」と見るのが正確な分析

■ 7. Linus Torvaldsの立場

  • 現状（2026年4月時点）:
    • 問題発覚から2日時点でLinusの公式発言はなく未関与
    • Linux 7.0安定版リリースは約1〜2週間後が見込まれるリリース直前のタイミング
  • 2012年の先例:
    • 同種の問題に数時間で参加し「アイドルCPUを探すコストを削減する方向」などカーネル側での解決を主導
    • 当時の立場はZijlstraの今回の「PostgreSQL側で直せ」という回答とは対照的
  • 今後のシナリオ:
    • 楽観的: 2012年と同様に性能リグレッションを受け入れずPREEMPT_NONEのデフォルト復帰か緩和策を求める
    • 悲観的: Zijlstraの立場を支持しリリースをそのまま進める
    • 中間: 今回のリリースはそのまま出しつつ次のサイクルで緩和措置を指示する

関連:

(2026/04/05)

Linux 7.0でPostgreSQL性能半減、修正困難か

要約:

■ 1. 問題の概要

  • Linux 7.0の開発カーネル上でPostgreSQLのスループットが約半減する性能劣化が報告された
  • AWSのエンジニア サルヴァトーレ・ディピエトロが2026年4月3日にLinuxカーネルメーリングリストへ報告
  • テスト環境はAWS EC2 m8g.24xlarge（Graviton4 / 96 vCPU）でPostgreSQL 17を使用
  • pgbench（simple-update / 1024クライアント / 96スレッド / 1200秒）の結果:
    • Linux 7.0（PREEMPT_LAZY）ベースライン: 約50,751 TPS
    • 問題コミットをリバート後（PREEMPT_NONE相当）: 約98,565 TPS（1.94倍）
  • perfプロファイリングにより CPU時間の55%がPostgreSQLのユーザースペーススピンロック（s_lock）で消費されていることが判明

■ 2. 原因

  • Linux 7.0 rc1で導入されたカーネルスケジューラの変更が根本原因
  • Intelのカーネルエンジニア ペーター・ジルストラによるコミットが利用可能なプリエンプションモードを制限
  • 従来はサーバー向けに「PREEMPT_NONE」（プリエンプションなし・スループット最大化優先）が存在していた
  • Linux 7.0でx86・ARM64等の主要アーキテクチャからPREEMPT_NONEが廃止され「FULL」と「LAZY」の2モードのみに変更
  • 目的はカーネルの簡素化とPREEMPT_RT（リアルタイム対応）への統合推進
  • PostgreSQLはプロセスモデルを採用し共有メモリへのアクセスにユーザースペーススピンロックを多用する
  • PREEMPT_LAZY環境ではロック保持中にタスクが中断される頻度が上がり他のプロセスが無駄にスピンし続ける結果となった

■ 3. カーネル開発者の対応方針

  • ディピエトロはPREEMPT_NONEをデフォルトに戻すパッチを提出したが受け入れられなかった
  • ジルストラはPostgreSQL側がRSEQ（Restartable Sequences）のタイムスライス拡張を活用すべきと回答
    • タイムスライス拡張はLinux 7.0で利用可能になったカーネル機能
    • アプリケーションがスケジューラに対してタスク切り替えの延期を要求できる仕組み
  • リバートの見込みは薄く修正責任はPostgreSQL側に求められている
  • PostgreSQLがRSEQのタイムスライス拡張を採用するにはコード変更が必要であり実現時期は不透明
  • 少なくともLinux 7.0のリリースには間に合わない状況

■ 4. タイムラインと影響範囲

  • Linux 7.0安定版リリースは4月中旬を予定
  • Ubuntu 26.04 LTSのリリースは4月23日を予定
  • Linux 7.0はUbuntu 26.04 LTSのカーネルとして採用予定
  • LTSは企業・サーバー環境で広く使われるためPostgreSQL運用組織への影響が懸念される
  • 今回のテスト条件は96 vCPU・1024クライアントという高負荷環境であり全構成で同影響が出るわけではない
  • AWSのGraviton4のような大規模インスタンスはPostgreSQLの主要な運用環境であり影響を受ける環境は少なくない

■ 5. 過去の類似事例とパターン

  • PostgreSQLとLinuxカーネルの性能摩擦は今回が初めてではない
    • 2010年: Linux 2.6.32のEXT4 fsync変更によりPostgreSQLの性能が大幅低下
    • 2008年: CFSスケジューラ導入後にpgbenchのリグレッションが報告
  • カーネル開発者はシステム全体の設計改善を優先し特定アプリケーション向けの最適化を「アプリ側の責任」とする構造的パターンが繰り返されている
  • Phoronixが2月に実施したLinux 7.0のAMD EPYCベンチマークではPostgreSQLの読み書き性能が大幅に向上していたとの報告もあり プリエンプションモデルの変更は環境やワークロードによって正反対の影響を与えうる

関連:

(2026/04/05)

色々な面でコメントしたくなるな　・カーネル開発者はもう20年ぐらいPostgreSQL開発者にユーザーランド...

色々な面でコメントしたくなるな

・カーネル開発者はもう20年ぐらいPostgreSQL開発者にユーザーランドのspinlockは正気じゃないから考え直して欲しいと繰り返し要求していた

・linux kernel summitにPostgreSQL開発者を招待してディスカッションしたがうまくいかなかった。平行線というよりもPostgreSQL側が今こうなっている、実装したときはそれが一番性能よかったという話に終始していて、会話があまり建設的ではなかったと思う

・記事には「PostgreSQLはプロセスモデルを採用しており、共有メモリ上のデータ構造へのアクセスにユーザースペーススピンロックを多用する。」と書かれているが、マルチプロセスというのとスピンロックでないといけないは論理的につながらないと思う。なにか書き忘れてない？

・記事ではUbuntu 26.04 LTSへの影響を気にしているが、最近のUbuntuはPREEMT_DYNAMICかつデフォルトがpreempt voluntaryなので、影響ないのではないか？元々のバグ報告にあるAmaxonLinux2023はPREEMPT_NONEだから影響有るけど。RHELもRHEL9からPREEMPT_DYNAMICなので影響ないっぽい。SUSEも影響ないっぽいな。なら実質困るのはAmazon Linuxユーザーだけ？？

・それはそれとして、PREEMPT_NONEはサーバー用distroで長らく使われてきた決してマイナーではないオプション

・なんだけど、peterはRed Hatにいた時代から -rtチームにいて、PREEMPT_NONEには当たりがキツかった。

どの視点でも面白いディスカッションが出来そうだな、と思ったところで、興味MPが切れたので、ただの感想を投下して逃げる。

おやすみなさい

Linux 7.0でPostgreSQLの性能がほぼ半減。 AWSエンジニアがGraviton4上で実測し、カーネルのプリエンプション変更が原因と特定した。

開発者の回答は「PostgreSQL側で対応しろ」。 リバートの見込みは薄く、Ubuntu 26.04 LTSにはこのまま載る。

カーネルの「改善」がアプリを壊し、修正をアプリ側に求める。

Linux 7.0でPostgreSQL性能半減、修正困難か

@joho_no_todai

@kosaki55tea

(2026/04/05)

ハーネスエンジニアリングを極めたら、IssueからAIエージェントが動き、人間の役割は要件定義だけになった

(2026/04/04)

Claude Codeの「ソースコード流出」をどう見るのか

(2026/04/04)

Claude Codeでドメインエキスパートを育てる ── 解体新書自動生成Pluginの設計と実践

(2026/04/03)

料金を払えばAIが任意のGPLソフトを合法的に再実装するサービス「malus.sh」が登場：著作権法が...

MEMO:

(2026/04/02)

ログ設計：基礎から応用まで

(2026/04/01)

特別調査委員会による調査結果について

(2026/03/31)

「売上99.7％が架空取引」　KDDI、ビッグローブら子会社2社の広告代理事業巡り調査委が公表

(2026/03/31)

Reactのフラグ地獄を状態遷移テーブルで解消する — Discriminated Union×テーブル駆動設計の実践

(2026/03/31)

クラファン未払いという前代未聞の事態──イシイジロウ氏『シブヤスクランブルストーリーズ』緊急インタビュー

MEMO:

(2026/03/30)

ユーザーストーリーを書くのがかったるいので「背景・目的・対応内容」に落ち着いた話

要約:

■ 1. 概要と経緯

  • スクラム開発のPBIにユーザーストーリー形式を使う煩雑さを問題視しAIとの対話を通じて「背景・目的・対応内容」という3点セットに辿り着いた備忘録
  • ユーザーストーリーはケント・ベックが1990年代のクライスラーC3プロジェクトで導入した概念
  • ユーザーストーリーの本来の目的は完璧な書類の作成ではなく「チームの認識を揃えること（対話への招待状）」であり形式へのこだわりは本末転倒

■ 2. 各要素の役割と不足点

  • 背景・目的・ストーリーの位置づけ:
    • 背景: なぜ今これが必要か（広域）
    • 目的: これによって何を実現したいか（中域）
    • ユーザーストーリー: 誰が何をすればその目的が叶うか（詳細）
  • ストーリーだけでは不足する点:
    • ストーリーのWhyにはミクロな目的が入るがマクロな背景は抜け落ちやすい
    • 例: 「コストを削減したい」は書けるが「来月までに削減しないとプロジェクトが凍結される」という背景は伝わらない
    • この背景を知っているかどうかでチームの動き方が変わる
  • 背景・目的だけでは不足する点:
    • 具体的な対応内容がないとチームが迷走し実装に入れない
  • Howだけを書く場合に陥る3つの罠:
    • 対応内容の目的化: 「チケットにこう書いてあるから」と非効率なやり方に固執する
    • レビューの質低下: Whyがないとコードが動くかのスペルチェックしかできない
    • 属人化: 後から「なぜこうしたのか」が分からなくなり先祖返りが起きる

■ 3. 「背景・目的・対応内容」の構造

  • 各項目の定義:
    • 背景（Context）: 現状の課題・制約条件（今何が起きているか）
    • 目的（Why + Goal）: 理由と目指す状態（どうなれば成功か）
    • 対応内容（How）: 作業手順・チェックリスト（具体的に何をするか）
  • 目的の書き方:
    • WhyとGoalの両方を1文に含める
    • 「[痛み]を解決するために[目指す状態・数値]を実現する」の型を使用
    • Whyだけでは終了条件が不明 / Goalだけでは実施理由が伝わらない
  • 日本語の「目的」には理由と目標の両方のニュアンスが含まれ英語のContext/Why/Howより直感的に書ける

■ 4. 階層ごとの使い分け

  • エピック:
    • 背景: 厚めに記述
    • 目的: 最重要
    • 対応内容: 記載しない（方針のみ）/ 役割: 北極星
  • PBI:
    • 背景: 補足程度
    • 目的: あり
    • 対応内容: あり / 役割: ロードマップ
  • タスク:
    • 背景: 不要
    • 目的: 不要
    • 対応内容: 詳細に記述 / 役割: 足元の作業
  • エピックに対応内容を書かない理由:
    • 最初にやり方を固定すると改善の余地が失われる
    • 背景と目的があればエンジニアが自律的に考えられる
    • 対応内容まで指示するとチームが作業者になる
  • タスクに背景・目的を書かない理由:
    • 親PBIで合意が取れていればタスクは実行レベルで書く方が親切
    • 迷ったら親PBIに戻れれば十分

■ 5. テンプレート

  • PBIテンプレート:
    • 背景（Context）: 現状の課題や依頼の経緯を1〜2行
    • 目的（Why + Goal）: 「[痛み]を解決するために[目指す状態・数値]を実現する」
    • 対応内容（How）: 具体的な実装・改修の方針 / 満たすべき受け入れ条件
  • エピックテンプレート:
    • 背景（Context）: プロジェクト全体の背景や技術的負債の状況
    • 目的（Why + Goal）: 「[痛み]を解決するために[目指す状態・数値]を実現する」
    • 対応内容はPBIに委ねる
  • タスクテンプレート:
    • 対応内容（How）のみ: 設定変更・動作確認・プルリク作成などを列挙
    • 対応内容が10行を超えた場合はPBIが大きすぎるサインであり背景と目的を共通にしたままPBIを分割する

■ 6. dbt-coreのPRテンプレートとの比較

  • dbt-coreのPRテンプレートはProblem（何が起きているか）とSolution（どう解決するか）の2項目で構成
  • ProblemはContextとWhyに相当 / SolutionはHowに相当
  • チケットもPRも「何が問題でどう対処するか」を伝えるという点で構造は同じ
  • OSSメンテナが大量のPRを捌くために削ぎ落とした結果の形であり説得力がある

■ 7. 壁打ちで得た気づきと導入のポイント

  • ユーザーストーリーの「〈価値〉のためだ」は部分最適になりやすくマクロな背景は別途必要
  • 目的はWhyとGoalを1文で書く（「〇〇のために〇〇を実現する」の型）
  • エピックの対応内容を書かないことでチームの自律性を維持する
  • タスクは対応内容だけで十分であり親PBIへのリンクさえ切れなければよい
  • 導入時は引き算が有効:
    • 背景が自明なら1行でよい
    • 目的が前と同じなら「〇〇と同じ」でよい
    • 対応内容がその場で決まらないなら「調査する」から書き始める

(2026/03/30)

なぜステータスが混在するテーブル設計が生まれるのか

要約:

■ 1. 概要

  • 業務システムのDBに複数のステータスカラムが混在するテーブル設計が生まれる原因と防止策を解説する
  • 問題の根本はイベントとリソースを区別しないまま設計を始めることにある

■ 2. ステータス混在テーブルが生まれる原因

  • イベントとリソースを区別せずに設計している:
    • リソースとは現在の状態を表す「物」であり、イベントとは「何かが起きた」という事実の記録である
    • ステータスはイベントの移り変わりを現在の視点から表したものである
    • この認識がないとステータス変化をUPDATEで上書きする問題として捉え、管理したいカラムを一つのテーブルに追加し続ける結果になる
  • カラム定義から設計を始めている:
    • 「何を保存したいか」から設計を始めると保存したいものをすべてカラムとして並べることになる
    • 本来の順番は逆であり「このシステムでどんなイベントが起きるか」を先に列挙してから「イベントの結果として何がリソースとして残るか」を決める
  • 外部システムの仕様をそのままDBに持ち込んでいる:
    • 外部コードは数値の飛び番・機関ごとの差異・外部都合の値など自社の業務ステータスとは異質な特徴を持つ
    • 内部ステータスと同テーブルに混在させると自社業務ステータスと外部コードの関係が定義されず、外部仕様変更時の修正箇所の特定が困難になる
  • 連携元システムの設計を無批判に踏襲している:
    • 外部システムのDBをクローンして区分値テーブルなしに数値カラムだけを持ち込むと値の意味が自社コードベースのどこにも存在しない状態になる
    • この状態でスキーマを継ぎ足すと同じパターンのカラムが作られ続ける

■ 3. 防止するための設計手順

  • イベントを先に列挙する:
    • テーブルやカラムを考える前に「このシステムで何が起きるか」を書き出す
    • イベントを列挙することでテーブルの責務が明確になる
  • リソースとイベント記録を分離する:
    • リソーステーブルは現在の状態を表しUPDATEが発生する
    • イベントテーブルは発生した事実を記録しINSERTのみを原則とする
    • 外部コードは外部イベントテーブルに生データとして保持し、自社ビジネス判断を表す内部ステータスは別カラムで管理する
  • ステータス遷移を先に定義する:
    • リソーステーブルにステータスカラムを置く前に遷移図を作成する
    • 遷移図により「どの遷移で何のカラムを更新するか」「どの遷移は許可されないか」「どの遷移にイベント記録が必要か」が自然に決まる
  • 外部コードと内部ステータスを分ける:
    • 外部コード（生データ）はイベントテーブルにVARCHARまたは元の型で保持し変換しない
    • 内部ステータスはリソーステーブルにTINYINT＋Enum定数で管理し受信時に変換する
    • この設計により外部仕様が変わってもマッピング処理だけを変えればよい状態になる
  • 外部の区分値を持ち込む際は意味も一緒に持ち込む:
    • 区分値テーブルもクローンして自社アプリから参照できるようにする
    • またはクローン時点で自社の定数・Enumにマッピングして変換する
    • どちらも取らないまま数値だけを引き継ぐと値の意味が自社システム内のどこにも存在しなくなる

■ 4. まとめ

  • ステータス混在テーブルの問題はコードを書き始めてから気づくことが多い
  • 根本原因はほぼ常に設計の最初にイベントとリソースを区別できていなかったことにある

(2026/03/30)

40,000行のAPIテスト作成で学んだClaude Code Skillsの育て方

要約:

■ 1. 背景と目的

  • APIの動作保証にシナリオテストツール「runn」を使用していたが、サービス成長に伴うAPI増加により運用が困難になった
  • 1ファイルあたりのステップ数が膨張し、テストの追加・修正が心理的・技術的に高コストな作業となっていた
  • テストを以下の2種類に整理し直し、Claude Code + Skillsで生成する方針を採用した:
    • API単位テスト: 1ファイル = 1API、正常系・異常系を網羅的にカバー
    • ユースケースシナリオ: 複数APIにまたがる業務フローのE2Eテスト

■ 2. テスト生成の仕組み

  • API単位テストのフローは5ステップで構成:
    • Step 1 情報収集: API定義やバリデーションロジックなど関連コードを読み込む
    • Step 2 テストケース洗い出し: コードからエラーハンドリングを網羅的に抽出し正常系・バリデーション・権限・存在チェックなどのケース一覧にまとめる
    • Step 3 ユーザー承認: テストケース一覧をMarkdownで提示し過不足を確認する
    • Step 4 サブエージェントへの委譲: API単位で分割して渡し、ファイル生成・実行・エラー修正を自律的に繰り返させる
    • Step 5 セルフレビュー: チェックリスト（ファイル形式・テスト構造・命名規則）で品質を確認する
  • サブエージェントへの委譲はAPI単位で分割するルールとし、一度に渡すとコンテキストが膨れてテスト品質が低下するため採用した

■ 3. スキルの段階的な改善

  • Phase 1 基本構成の確立: 最初の数APIで基本構造と命名規則を決定し、生成フローの大枠のみを定義したシンプルなスキルを作成
  • Phase 2 runnスキルの切り出し: Claudeが繰り返す同一のrunn記法ミスのパターンが可視化されたため、runn記法ナレッジを独立スキルとして切り出した
  • Phase 3 サブエージェント導入と構造再設計: 1セッションで情報収集から実装・実行まで担う構成ではコンテキスト超過が頻発したため、スキル本体（情報収集・テストケース設計・ユーザー承認）とサブエージェント（ファイル生成・テスト実行・エラー修正）に役割を分離した
  • スキルの見通し改善として、テンプレートやチェックリストを参照ファイルに外出しし、スキル本体（SKILL.md）はフローの記述に集中させた

■ 4. ぶつかった壁と解決策

  • runnはYAMLベースの独特な記法を持ち、LLMにとって馴染みが薄く頻繁にミスが発生した
  • 主な記法ミスのパターン:
    • bind と include の実行順序: 同ステップ内でbindとincludeを書くと、bindの変数がincludeに渡らない
    • testフィールドのアサーション記法: expr-langの関数を知らず存在しない関数（例: startsWith）を使用してしまう
  • 最大の課題はrunnのエラー出力をClaudeが読めないことだった:
    • assertionの条件式が&&や||で組まれると、ツリー構造で深くネストされたエラーが出力される
    • 人間なら失敗箇所を容易に特定できるが、Claudeにはツリーの葉から「=> false」を探す困難な作業になる
    • 結果として、Claudeがツリーを読み解けず同じテストを何度も再実行する悪循環が発生した
  • 解決策としてアサーションをステップに分離する設計を採用:
    • 1つのtest:に全条件を詰め込まず、フィールドごとに独立したステップに分離する
    • 効果1: エラー出力がシンプルになり1ステップ=1条件でツリーのネストが発生しない
    • 効果2: ステップ名で失敗箇所が一目瞭然になる
    • 効果3: Claudeが失敗したverifyステップ名から修正箇所を正確に特定し自律的に修正できる
  • 人が手動でテストを書く場合は記述量を抑えるためアサーション分割を避けることが多いが、LLMにテストを書かせる場合は自律的な修正・デバッグの実現が大きな価値を持つ

■ 5. 振り返りと学び

  • うまくいったこと:
    • 段階的改善: 最初から完璧を目指さず数サービス実装後にパターンを抽出するサイクルが効果的だった
    • 委譲単位の制御: API単位でサブエージェントに渡すことでコンテキスト超過を防ぎテスト品質を維持できた
    • 暗黙知の明文化: Claudeが間違えるたびにNGパターン/OKパターンとしてスキルに蓄積し、LLMが「暗黙知の検出器」として機能した結果、スキルがテスト設計のナレッジベースになった
  • 次への学び:
    • 初期設計のコスト: 最初の数サービスは試行錯誤が多いが、実際にやってみないと見えないパターンも多い
    • サブエージェントのモデル選択: Sonnetを使用したがスキルの指示に従わないケースや同じミスを繰り返すケースがあり、チェックリスト強化やプロンプト調整で対処が必要だった

■ 6. まとめ

  • 約2週間でYAMLベース40,000行超のAPIシナリオテストをClaude Code + Skillsで生成した（数十API対象・100ファイル以上）
  • 取り組みから得た4つのポイント:
    • スキルは最初から完成形を目指さず実装しながら段階的に改善する
    • LLMが間違えるポイントをNGパターン/OKパターンとしてスキルに蓄積する
    • LLMにとって読みにくいエラー出力はテスト設計側の工夫で回避する
    • スキルの改善プロセスは暗黙知を形式知に変換するプロセスそのもの
  • テストの量産だけでなくテスト設計のナレッジが明文化されたことがこの取り組みの最大の成果

(2026/03/29)

イベント駆動を軸とした外部システム連携

要約:

■ 1. 要件と開発方針

  • 要件:
    • ニアリアルタイムでのトランザクションデータ処理が必要
    • トランザクション連携が事業の生命線であり可用性と回復性を高水準で実現することが求められる
    • 主体処理と付帯処理の整理および非同期処理のフル活用が前提
    • 複数の連携起点を1つの連携経路に集約し登録・更新・削除のデータライフサイクルを実現する
  • 開発方針:
    • 要件漏れが許されないためウォーターフォール型で開発
    • 先行システムの仕様を可能な限り踏襲
    • 開発手法の柔軟性を一定確保した上で進行

■ 2. システム特性

  • 獲得を目指す5つの特性:
    • 可用性
    • 回復性
    • 整合性
    • ニアリアルタイム性
    • 独立性
  • これらは妥協なく獲得を目指しトレードオフが発生する場合は相談の上で調整する

■ 3. システムデザイン

  • 初期構想から大きく外れることなく現在の構成に着地
  • 外部結合テストやシナリオテストの段階で構成上の欠陥が顕在化し最適化を実施
    • トラフィック量を意図的に増やした動作検証によって欠陥を発見
    • 取引先との期待値調整と交渉を経て設計変更を実現

■ 4. 工夫

  • PubSubのイベント発信基盤の活用:
    • コアシステムのイベント発火をトリガーとして連携フローを構成
    • サテライトシステム側がすべてのイベントを受信した上で連携対象を取捨選択
    • コアシステムは自システムの事実の送信に専念しサテライトが追従する主従原則を採用
    • PubSubによるシステム間の疎結合化により組織スケーラビリティも実現
  • 経路選択と連携実行の分離:
    • サテライトシステム内部で経路選択と連携実行を分離して処理
    • ノイジーネイバー問題の解決とAPI連携実行側の責務分離を実現
    • 経路選択で有効イベントを選別しA/B/Cといった経路へのデータルーティングを担う
    • 連携実行側は事前条件チェックと連携処理および付帯処理の実行を担う
  • Cloud Tasksのリトライとリクリエイト機構の活用:
    • サテライトシステム内の処理はCloud Tasksを用いて逐次処理する構成を採用
    • Cloud Tasksが呼び出すAPI処理は例外なく冪等性を担保する原則を設ける
    • 冪等性担保によりリトライ処理の恩恵を受け自然回復可能な状態を実現
    • 技術選択がシステム特性の獲得を容易にする代表例
  • 冪等性担保と差分チェックによる最小限のリクエスト送信:
    • 外部システムへのリクエストは連携の必要性を都度チェックし必要な場合のみ送信
    • 前回リクエスト時のパラメータをログ保存し差分チェックを行う
    • 不必要なリクエストを排除することでスループット低下とリソース過剰消費を抑制
  • サテライトシステムのPull型データ取得:
    • 連携に必要なデータはコアシステムへの参照APIで都度取得するPull型を採用
    • Cloud Tasksパラメータでは参照のキー情報のみを受け渡す
    • 常に最新データ状態で処理が実行される前提で処理を構成

■ 5. 発見

  • システム特性はテクニックと戦略で決まる:
    • テクニック: リトライ機構の整備やUpsertによる冪等性担保など即効性のある実装レベルの知識
    • 戦略: システム構成やクラウドサービスの選択など実装以前の設計判断
    • 戦略によってシステム特性の獲得容易性が規定されるためシステムアーキテクトは戦略にこだわる必要がある
  • 連携で価値を生む系SaaSはコア/サテライト構成が最適:
    • マルチテナントのコアシステムとシングルテナントのサテライトを分離する構成が有効
    • コアの純度を守りつつサテライトで顧客要望に対応することで事業競合優位性を確保
    • 非同期処理と結果整合性への習熟が技術の最適解選択の幅を広げた
  • クラウドサービスをフル活用する時代:
    • 2026年時点でクラウドサービスをフルで活用できる技術と思考が整った
    • 非同期処理系を中心に従来より低コストかつ柔軟性と拡張性を持った開発が可能になった
  • AIに代替されにくい領域:
    • プログラマーの職はAIに置き換えられる一方で開発の責任を人が取って推進する領域は残存する
    • 運用容易性や運用安全性の保証はAIには困難であり運用は点ではなく線で考える長い時間軸の世界
    • 少なくとも10年単位ではすべてがAIに置き換えられることはないと考える

(2026/03/28)

AnthropicがAI SREの限界を公式認定。「相関関係を因果関係と誤認し続ける」

要約:

■ 1. AnthropicによるClaudeのSRE活用実験と限界の報告

  • 2026年3月19日のQCon Londonにて Anthropicが ClaudeをSRE（サイト信頼性エンジニア）として活用する試みの限界を公式に報告
  • 「相関関係を因果関係と誤認し続ける」という根本的な問題が残存しており SREの完全代替には至らないと自社が認めた
  • AnthropicはClaudeを使ってClaudeのインフラ障害を修復する「AIがAIを管理する」構成を試みていた
  • ログやメトリクスを読ませ 警告アラートの原因を特定させ 修復アクションを実行させる流れで運用を試みた

■ 2. 判明した問題点

  • 警告の表面パターンは認識できるが 障害の根本原因を特定できないことが明らかになった
  • 相関関係の誤認例:
    • 「メモリ使用量が急増した後にレスポンスタイムが悪化した」という相関を見て「メモリが原因」と判断する
    • 実際の根本原因はメモリではなく 特定のクエリパターンによるロック競合だった
  • 人間のSREは過去のインシデント経験・システム全体の挙動パターン・チームが暗黙的に共有している文脈知識を総動員して根本原因の仮説を立てる
  • 現在のLLMにはこの文脈理解が欠けている

■ 3. 相関から因果への誤認が生じる理由

  • LLMは本質的にパターンマッチングで動作する
  • 学習データ内で「Aが起きた後にBが起きた」という事例が多ければ「A→B」という因果関係として認識する
  • システム障害の原因特定では 観測できる相関関係の背後にある「なぜ」を追う必要がある
  • これはLLMのアーキテクチャ上の根本的な弱点であり プロンプト改善やコンテキスト長の拡大で多少は改善できるが 現世代のモデルでは完全に解消されていない
  • Anthropic自身がこれを認めたことは注目に値し 技術的誠実さとして発信している姿勢が見られる

■ 4. AIが向いている作業と向いていない作業

  • AI活用の適性が高い作業:
    • ログのサマリー作成: パターン認識が得意
    • アラートの緊急度分類: 既知パターンの照合で十分
    • 過去インシデントの類似検索: テキスト検索に近い
    • エラーメッセージの意味解説: 定義の説明は得意
  • AI活用の適性が低い作業:
    • 障害の根本原因の特定: 相関から因果への誤認が起きやすい
    • 「なぜ今このタイミングで」の特定: 文脈依存の推論が苦手
    • 修復手順の最終判断: 誤った原因に基づく対処になるリスクがある
  • 「整理させる」用途はAIが得意で「判断させる」用途は人間のチェックが必要という整理が実態に近い

■ 5. AIによる誤認を確認するための方法

  • 原因の絞り込み確認:
    • AIが「Aが原因」と言ったとき「もしAが原因でないとしたら次に考えられる原因は何か」と追加で質問する
    • AIが自信を持って別の候補も挙げてくるなら 最初の断言は過信だった可能性がある
  • タイミングの確認:
    • 「このエラーは以前も起きていたか それとも今回初めてか」をAIに確認する前に 自分でログの期間を広げて確認する
    • AIは直近のログに引っ張られて「今回の変更が原因」と判断しやすい傾向がある
  • 変更との対応確認:
    • デプロイ直後のエラーに対しAIは自然に「デプロイが原因」と見なしやすい
    • 実際はデプロイと無関係に 外部サービスのタイムアウトや依存ライブラリのバージョン競合が原因だったケースが多い
    • 「デプロイを除いた場合の原因候補」という形で質問するだけで回答の質が変わることがある
  • 具体例:
    • Next.jsのビルドエラーをClaudeに貼り付けると 直前に編集したファイルや変更行数の多いファイルを原因として指摘しがち
    • 実際には無関係の依存ライブラリ間のバージョン競合だったりする

■ 6. 残る疑問と今後の展望

  • 今回の報告はAnthropicの自社インフラに限った話である
  • 異なる規模・構成のシステムや より詳細なシステム文書をコンテキストとして与えた場合に同じ問題が出るかどうかは不明
  • 「限界を認めた」というより「現時点の限界を正直に共有した」ととらえる方が正確かもしれない
  • 今後のモデル世代での改善状況を見ていく必要がある
  • 2026年のSRE領域でのAI活用は「支援ツール止まり」が現実的な見通しとなっている

(2026/03/28)

「COBOL」技術者はもういない、レガシーコードの読み解き方をAnthropicが解説：AIにより数カ月単位での...

要約:

■ 1. 背景と課題

  • AnthropicはCOBOLシステムのモダナイゼーションにAIを活用する手法を2026年2月23日に公開
  • COBOLシステムは金融・航空・政府系基幹システムで現役稼働を継続
  • 開発者の多くが引退し暗黙知はコード内にのみ残存
  • COBOLを扱えるエンジニアは希少であり教育機関も極めて少数
  • COBOLモダナイゼーションは単純なリファクタリングではなく数十年分の複雑な依存関係の解体が必要
  • 従来手法では大量のコンサルタントによる数年単位の工期と高コストが発生し移行に取り組む組織が少ない状況

■ 2. AI支援による自動化（Claude Code）

  • Claude Codeが最も工数のかかる探索・分析フェーズを自動化
  • 自動化される主要機能:
    • 依存関係のマッピング: エントリーポイント・実行パス・モジュール間データフローを解析し数百〜数千ファイルの関係を可視化
    • ワークフローのドキュメント化: 入力から出力までの処理経路を追跡し処理手順を文章・図として生成
    • リスク特定: 結合度の高いモジュールや隠れた依存関係・重複ロジックを抽出し移行障害要因を事前把握
    • 意思決定支援: 分析結果を基に優先順位や移行戦略の検討材料を提示
  • AIの活用により数年単位から数カ月単位へのモダナイゼーション期間短縮が可能

■ 3. 自動探索と依存関係の発見

  • AIはコードベース全体を読み取り構造をマッピングしてから分析を開始
  • 静的解析では検出不可能なファイル・データベース・グローバル状態を介した隠れた依存関係を自動発見
  • 隠れた依存関係の存在がCOBOLモダナイゼーションを高リスク化する主因
  • マッピング完了後に各コンポーネントの移行リスクを評価:
    • 結合度の高いモジュール: 高リスクと判定
    • 分離されたコンポーネント: 独立したモダナイゼーションの早期候補として抽出
    • 重複ロジック: リファクタリング機会として提示
    • 技術的負債: 移行前にドキュメント化

■ 4. 人間の判断との組み合わせ

  • 規制要件・ビジネス優先事項・運用上の制約・リスク許容度はAIが把握できないため人間の判断が不可欠
  • 計画フェーズにおける役割分担:
    • AIの役割: リスク・依存関係・複雑さに基づく優先順位付けの提案
    • チームの役割: ビジネス価値・技術的リスク・組織優先事項に基づく最終決定と目標アーキテクチャ・コード標準・統合要件の定義
  • コードテストと検証はコード変更前に定義:
    • AIが予備的な機能テストを設計
    • チームがテストの十分性・手動検証が必要なシナリオ・パフォーマンスベンチマークを決定

■ 5. 段階的実装と継続的検証

  • 実装はコンポーネント単位で実施し各ステップで検証
  • AIの実装支援内容:
    • COBOLロジックのモダン言語への翻訳
    • レガシーコンポーネントへのAPIラッパー作成
    • 移行中の新旧コード並行稼働用足場の構築
  • スコープを小さく保つことで失敗時の修正を早期に実施可能となり大規模なロールバックリスクを排除
  • 推奨される開始方法: 明確な境界と中程度の複雑さを持つ単一コンポーネントまたはワークフローから着手
  • 反復サイクル: AI分析・ドキュメント化 → 移行計画策定 → 段階的実装 → 各ステップでの検証

(2026/03/27)

ドメインとテーブルが同じなら、そのDDDは過剰かもしれない

要約:

■ 1. 概要

  • シンプルなランキング表示APIにDDDを適用した個人開発の事例を通じ「なぜ詰め替えが多いのか」という疑問から得た気づきを共有する記事

■ 2. 実装内容

  • 要件:
    • 入力: ランキングの開始位置（start）
    • 出力: ユーザーID・ユーザー名・スコア・順位
  • ロジック: Userテーブルからスコア降順で取得しstartをオフセットとして順位を付ける
  • DDDのリッチドメインモデルスタイルを採用しRankingEntry・Ranking・EntryWithPositionのエンティティを定義した

■ 3. 詰め替えへの疑問

  • データの流れに対して詰め替えが多すぎると感じた
    • DBモデル → RankingEntry → Ranking → EntryWithPosition → レスポンスDTO
  • DDDでは外部から取得した値をprivateにしてゲッターで公開し不正な値がユースケースに流れ込まないようにするという考え方がある
  • RankingEntryのフィールドがUserテーブルのカラムとほぼ一致しておりドメインがDBスキーマに依存しているように見えた

■ 4. 結論

  • ドメインはDBスキーマを知らないのではなく扱っていたドメインが非常にシンプルだったことが混乱の原因だった
  • DDDが活きる条件:
    • 複数のリポジトリから異質なデータを集約し複雑なビジネスロジックで価値を生むケース（例: 決済システムの詐欺判定ドメイン）
  • 今回のケースの特徴:
    • 単一テーブルからのデータ取得でロジックはforループによる順位付けのみ
    • ドメインが複数の関心事を統合して価値を生む複雑さを持っていなかった
  • アネミックモデルにした場合フィールドがpublicなためコンストラクタを経由せずに不正な値を入れられる問題があり守るべき不変条件がないなら実質的にただの構造体と変わらない
  • 複雑なドメインロジックがない場合はエンティティへの詰め替えよりシンプルな構造体（DTO）として扱う方が見通しが良い

■ 5. まとめ

  • DDDが活きるケースと今回のケースの比較:
    • データソース: DDDは複数リポジトリの統合 / 今回は単一テーブル
    • ロジック: DDDは複雑なビジネスルール / 今回はforループによる順位付け
    • ドメインとテーブルの関係: DDDは異なる概念 / 今回はほぼ一致
    • 詰め替えのコスト: DDDは払う価値がある / 今回はコストが目的を超える
  • パターンを適用する目的を忘れシンプルな問題を複雑にしてしまうことを避けるためには「なぜこれを適用するのか」を考え続けることが重要

(2026/03/26)

DDD×仕様駆動で回す高品質開発のプロセス設計

要約:

■ 1. 概要・ゴール

  • 発表者: 松岡幸一郎（株式会社ログラス / AI基盤開発室）
  • テーマ: DDD × 仕様駆動でAI駆動開発の品質を上げるプロセス設計
  • 持ち帰り項目:
    • sudoモデリング（4つの図のフレームワーク）
    • draw.io × AI（図を使ったAIとの協働）
    • 仕様駆動との接続（AIに「何を作るか」を正確に伝えるプロセス）
    • その他の品質向上のためのプラクティス

■ 2. DDDとは・DDDのアプローチ

  • DDDとは:
    • ドメイン駆動設計 = プロダクト開発で大きな価値を生むための手法（2003年〜）
    • 「ドメイン」= ソフトウェアで問題解決しようとする対象（業務領域）
    • 目的: 機能性（役に立つものを作る）× 保守性（長期間作り続けられる）
  • DDDの2つのアプローチ（AI時代にも有効）:
    • 機能性向上: ドメインエキスパートと共に行うドメインモデリング → 作るものを検討しAIに渡すために活用
    • 保守性向上: 頻繁なモデルの更新に耐えられる実装パターン → 実装のガードレールとして活用
  • モデルと実装の一致の重要性:
    • モデルと実装に乖離があると対応関係が見えにくくなる
    • モデルに変更があった時コードのどこに反映すべきかわからなくなる
    • コードは極力モデルと同じ形での表現を目指す（変更の反映先が一目でわかる）
  • ドメイン知識の位置づけ:
    • ドメイン知識があれば役に立つものが作れるわけではない
    • ただしドメイン知識がなければ役に立つものは作れない（必要条件）

■ 3. 仕様駆動開発とは

  • 定義: 仕様（完了条件・設計・テスト）を先に決め、AIに実装させる開発アプローチ
  • 設計で押さえるべき3要素:
    • 完了条件（受入基準）
    • 技術的な設計
    • テスト
  • 本質: 上流で品質を作り込み、手戻りを防ぐこと
  • DDD × 仕様駆動の組み合わせ:
    • DDDのモデリングが最上流で「何を作るか」を明確にする
    • 仕様駆動が各フェーズで品質を作り込む
    • 作ったモデルが仕様駆動の各フェーズのインプットになる

■ 4. フェーズ①: モデリング

  • モデリングの定義:
    • モデル = 問題解決のために作る抽象化物
    • モデリング = それを議論しながら作る活動
    • 成果物だけでなく、作るプロセスでの議論・認識合わせ・意思決定が重要
  • モデリングが役立つ理由:
    • 複雑な構造を整理しやすい（図なら2次元で関係性を一目で把握できる）
    • 「ちょうどいい抽象度」で構造を整理できる（画面の詳細項目だと具体的すぎる）
    • これが仕様駆動の各フェーズの精度向上につながる
  • モデリングのタイミング:
    • 新規機能開発・機能改修時: ドメイン理解を深め、わからないことを明確にして意思決定しやすくする
    • 後追いで実施する時: リバースエンジニアリング的に既存コードを理解し、現実と理想のギャップを明確にする
  • sudoモデリング（4つの図）:
    • S（システム関連図）: システムに関わるアクターと外部システムを明示する
    • U（ユースケース図）: ユーザーがシステムでどのような操作を行うか明示する
    • D（ドメインモデル図）: 概念と概念の関係を抽象的に描く
    • O（オブジェクト図）: 具体的なデータ例で理解を深め、モデルを検証する
    • 補足として業務フロー図・状態遷移図・シーケンス図も併用可
  • モデリング時のポイント:
    • 抽象と具体を行き来し、仮説を回し続ける
    • 具体例が出せない = ドメイン理解が足りていないサイン
    • 意思決定は常に仮説であると考える（モデル図はホワイトボードのように扱う）
  • ドメインモデル図のコツ:
    • オブジェクト図（具体例）からドメインモデルに抽象化していく
    • ルール/制約（ドメイン知識）を吹き出しに書き出す
    • 検討メモも積極的に記述する（疑問点も発見を誘発し認識を残す）
    • 多重度を定義する（ルール/制約として重要な意思決定）
    • 集約の範囲（リポジトリの範囲を決める）と英語名（ユビキタス言語のマスタ）を決める
  • AIとの協働（draw.io × AI）:
    • AIがdraw.ioファイルを直接操作できるSkillを作成（claude-drawio-skill）
    • draw.ioで描いたモデル図をAIに読み込ませて壁打ちしながらモデルを育てる
    • 「具体例を出して」と聞くだけでオブジェクト図（具体例）を生成できる
    • 「この図の懸念点は？」と聞くと1人では見落としがちな観点をAIが補完してくれる

■ 5. フェーズ②: 受入基準

  • 完了条件が曖昧だと意図と違う実装が進む（AIコードドリフト）
    • AIは経験や暗黙知で補完できないため、曖昧な仕様は乖離した実装を生み続ける
  • 完了条件を磨き込むことで手戻りを減らせる（AIが自己修正ループを回せ出力品質が上がる）
  • モデルで整理した構造が受入基準を書くインプットになる
  • 受入基準のアプローチ（4点）:
    • AIで磨き込む: 受入基準を決めたらAIによるレビュー（チェックポイント確認）・リファインメント（不明瞭な点を質問）を入れる
    • Question-First: 大量ドキュメントをレビューさせるより質問させることで論点を洗い出す（CLAUDE.mdに指示しておく）
    • Specification by Example（SBE）: 具体的な実例（Given/When/Then形式）で仕様を定義する
    • sudoモデリングのオブジェクト図がそのままこの「具体例」として活用できる
    • 具体例を書こうとすると自然にコーナーケースが洗い出される
    • AIにとっても具体例 = 入出力が明確 → 意図通りの実装になる
    • 図による可視化: draw.ioでSBEを可視化すると考慮漏れの状態遷移やロジックの分岐が一目で見つかる

■ 6. フェーズ③④⑤: 技術設計・テスト・実装

  • 技術設計フェーズ:
    • 意思決定の前倒し: Question-Firstで設計段階でAIに質問させ実装前に意思決定を済ませる
    • 固定観点レビューSkill: プロジェクトで重視する設計観点を言語化してSkillにし、毎回確実に同じ観点でチェックされる状態を作る
  • DDDの保守性アプローチ × AIガードレール:
    • ドメインモデルをコードで表現するルールをAIに守らせる
    • CLAUDE.md / .claude/rules/ にルールを定義（エンティティ・値オブジェクト・リポジトリ等のパターン、設計原則・アーキテクチャ制約・コーディング規約を事前定義）
    • AIはルールがあれば従ってくれるため「モデルを守ったコード」が自動的に生成される状態を作る
  • ビジュアルで設計を確認:
    • 複雑な仕様はテキストだけだとレビューが辛い
    • draw.ioでクラス図やデータフローにすると一目で把握できる
  • テスト分析設計フェーズ:
    • テストを明示的に検討させる: 実装計画と同じタイミングでテスト設計も依頼する（実装前にテストを考えることで仕様の抜け漏れ・矛盾に気づける）
    • テスト設計・レビューSkill: テスト観点をSkillとして言語化し毎回確実に同じ観点でレビューできる状態を作る（チームで育てることでQAの観点・過去の不具合パターンが蓄積される）
  • 実装フェーズ:
    • AIが自律的に実装・検証を回せる環境を整える
    • 自動テスト × ブラウザ操作（playwright-mcp等）で画面確認まで任せられると手離れが良くなる
  • コンテキストエンジニアリング（AIが必要な情報に確実に辿り着ける設計）:
    • FLOWとSTOCKに分ける: FLOW（開発中に書き留める一時的な情報）・STOCK（AIがまず参照する整理済みドキュメント）
    • 段階的開示: README.mdにインデックスへのパスを書いておきAIが段階的にたどれる構造を作る（大量のドキュメントを一度に読ませるのではなく必要な時に必要な情報だけ渡す）

■ 7. まとめ

  • DDDのモデリングは「ちょうどいい抽象度」で複雑なドメインを整理できる
  • その「ちょうどいい抽象度」が受入基準・技術設計・テストのインプットになる
  • DDD × 仕様駆動は一本のプロセスとして繋がり、開発全体の品質が上がる

(2026/03/25)

Re: ドメインサービスでrepositoryの実行は必要か？

要約:

■ 1. 結論

  • ドメインサービス内でのリポジトリ実行は避けるべきであるが実害の有無によって判断する
  • 実害が無視できない場合は避け そうでない場合は許容する

■ 2. ドメインサービスでリポジトリを実行すべきでない理由

  • アプリケーションレイヤとドメインサービスの責務が曖昧になるため
  • アプリケーションレイヤの責務:
    • 処理の流れを実装する
  • ドメインサービスの責務:
    • ビジネスルールを実装する
  • リポジトリをドメインサービスで実行すると起こる問題:
    • 処理の流れとビジネスルールが混在する
    • ドメインサービスがファット化する
    • トランザクション境界が不明確になる
    • アプリケーションレイヤが不自然に薄くなる

■ 3. ドメインサービスの適切な使用条件

  • 複数の集約にまたがる操作であること
  • その操作にぴったりな名前が付けられること
  • 上記条件を満たす実装は少ないためドメインサービスを使う機会は意外と少ない

■ 4. 実害の重要性

  • ドメインサービスでリポジトリを実行した場合の実害の程度が判断基準となる
  • 実害がなければそのまま維持し 困ったらリファクタリングする

■ 5. 回避策

  • パターン1: 妥協してドメインサービスでリポジトリを実行する:
    • 実害がない場合に有効（回避策ではなく許容）
  • パターン2: 1つの集約にまとめる:
    • 集約の境界を見直し 複数の集約を1つに統合する
    • 新たな集約の発見や入れ子構造の採用によって解決できる場合がある
    • 「xxxされたら」「xxxのあとで」という表現があるケースはドメインイベントの可能性が高くこのパターンに該当しない
  • パターン3: ドメインイベントとして扱う:
    • 「Taskが作成されたらActivityReportが作成される」のようなケースに適用
    • ユースケース内でドメインイベントを発行しイベント受信側が処理を担当する
    • イベントソーシングの場合は集約自体がイベントを保持する形になる
    • アウトボックスパターン等の実装が必要になる場合があり実装コストが高い
  • パターン4: アプリケーションレイヤでリポジトリを実行する:
    • ドメインサービスを使わずにアプリケーションレイヤで直接リポジトリを実行する
    • トランザクション制御との相性が良く自然に実装できる
    • ドメインサービスを乱用するよりこちらを選ぶ方が良い場合がある

(2026/03/24)

Claude Codeに長期記憶を持たせたら、壁打ちの質が変わった

(2026/03/24)

PO・PdMが感じるスクラムの限界

(2026/03/23)

伊藤淳一が考える「コードレビューの観点とアプローチ」

要約:

■ 1. 対象読者と記事の目的

  • 対象読者はコードレビューする側に回ったばかりの1〜2年目の新人エンジニア
  • リードエンジニアがチーム内でレビュー手順や観点を議論する際の叩き台としても活用可能
  • 記事の目的はコードレビューの観点を全網羅することではなく「先輩がレビュー時に何を見ているか」という気づきの提供
  • 可読性・保守性・堅牢性・正しさ・セキュリティ・パフォーマンスの6テーマに分けて各3点ずつ観点を紹介

■ 2. 可読性の観点

  • シンプルさ:
    • 標準ライブラリで代替できる自前実装は書き換えを検討する
    • 短縮しすぎて可読性を損なうのは不可
  • 命名:
    • わかりにくい変数名やメソッド名はNG
    • ほどよく具体的でほどよく抽象的な名前を付ける
    • 動詞と名詞の組み合わせ方で意味が変わる点に注意（例: upload_files vs uploaded_files）
  • 1行の長さ:
    • 人間がぱっと理解できない長さの1行記述はNG
    • 一度変数に代入してから使用する方が理解しやすい

■ 3. 保守性の観点

  • 責務の分離:
    • ロジックをコントローラに書くとfatコントローラ問題が発生し再利用性が低下する
    • ビジネスロジックはモデルに委譲することでコントローラを薄く保てる
  • カプセル化:
    • オブジェクト外部から内部状態を直接参照・変更するのはNG
    • 判断や操作はオブジェクト自身に任せることで再利用性と可読性が向上する
  • DRY原則:
    • 同一ロジックの繰り返しを発見した場合はDRY化を検討する
    • 将来的に別々の変更が入る可能性がある場合はあえてDRYにしないケースもある

■ 4. 堅牢性の観点

  • 配列とハッシュの使い分け:
    • 無関係なデータを配列に格納してインデックスで指定すると要素の増減時に不具合が起きる
    • ハッシュはキーで指定するため要素が増減しても既存コードの変更が不要
  • ハッシュのキーtypo問題:
    • ハッシュはキーをtypoしてもnilが返るだけでエラーにならない
    • 一定の複雑さを超えたら専用クラスを定義しメソッドで参照することでtypoを検出可能
  • 文字列結合によるフォーマット生成:
    • URL・HTML・XML・JSON・SQL・CSVなどを文字列結合で生成すると予想外の値でフォーマットが破綻する
    • 各フォーマットには専用のライブラリを使用する

■ 5. 正しさの観点

  • ゼロ除算:
    • 除数を動的に変更する場合はゼロ除算でエラーが発生する恐れがあるため考慮が必要
  • 丸め誤差:
    • 小数を含む計算ではFloat型特有の丸め誤差が発生する可能性がある
    • 金額計算では致命的な問題になるため RubyではBigDecimalを使用する
  • 要件の充足:
    • 実装がPRのdescriptionに記載された要件を満たしているかを確認する
    • 正常系だけでなく異常系（例: 決済処理の途中キャンセル）も考慮できているか確認する

■ 6. セキュリティの観点

  • 権限チェック:
    • フロントエンドでボタン表示を制御するだけでは不十分
    • Webアプリケーションではクライアントが自由にリクエストを送れるためバックエンドでも必ず権限チェックが必要
  • XSS・SQLインジェクション対策:
    • フレームワークやライブラリを素直に使う限りほとんど発生しない
    • SQLを文字列結合で動的構築するなどイレギュラーな実装を行う際は十分な注意が必要
  • クレデンシャル管理:
    • APIキーなどをコードに直書き（平文でgit管理）するのはNG
    • 環境変数やフレームワークが提供する仕組み（Railsの場合 config/credentials.yml.enc など）を使用する

■ 7. パフォーマンスの観点

  • 本番データ量の想定:
    • ローカルで一瞬で動く処理も本番のデータ量では異常に時間がかかる場合がある
    • 単純なデータ更新はプログラミング言語側でループするよりDBのSQL一発で処理する方が高速
  • 計算量の意識:
    • ループ内で毎回最大長などを求めると計算量がO(n^2)になり要素数増加時に無駄な処理が急増する
    • 最大長などはループの外で事前に求めておくことで計算量をO(n)に抑えられる
  • DBアクセス回数:
    • DBへのアクセスは基本的に遅く N+1問題や同一データの繰り返し問い合わせは本番環境の負荷に耐えられなくなる恐れがある
    • シンプルなループ処理に見えてもその裏側でDBへの問い合わせが大量に発生している場合があるため注意が必要

■ 8. その他の観点

  • 言語・フレームワークの考え方やベストプラクティスに沿った「○○らしいコード」を書いているか
  • プロジェクト固有のお作法に従ったコードを書いているか（お作法は暗黙知にせず明文化することが望ましい）
  • 成功・失敗を表すメソッドの戻り値を無視していないか
  • 例外処理が適切か（エラーを握りつぶしていないか/不要な例外キャッチをしていないか/条件分岐で実装できるものを例外でスロー・キャッチしていないかなど）
  • DBトランザクションを適切に利用しているか
  • アプリ側の変更に対応したテストコードが追加されているか
  • テスト設計手法（境界値分析など）を意識したテストコードになっているか
  • 複雑な条件分岐を持つロジックに対するテストコードのカバレッジが十分か
  • false negativeなテストコード（バグが発生していても検知できないテストコード）を書いていないか

■ 9. コラム：「5年後に自分がメンテできるか？」という視点

  • 業務コードの寿命は非常に長くPR作成者が退職した後に自分がメンテすることも現実として起こりうる
  • レビュー時の自問事項:
    • 5年後にこのコードを見てロジックをすぐに把握できるか
    • テストコードがない状態で既存機能を壊さずに自信を持って変更・追加できるか
    • 当時の仕様の背景を5年後にすぐ振り返られるか
  • 答えがNOの場合は「わかりやすいメソッド名への変更」「テストコードの追加」「PRのdescriptionへの詳細記載」などのレビューコメントを入れる

(2026/03/22)

Goで値オブジェクトをどこまで作るべきか〜コスパの良いDDD戦術設計〜

(2026/03/21)

学ぶのをやめて、つくることにした

(2026/03/20)

Coding Agent時代のドキュメントについて考えていること

要約:

■ 1. ドキュメントの基本的役割

  • ソフトウェア開発においてドキュメントは関係者全員が同じ方向を向くためのSingle Source of Truthとして機能する
  • 具体的な役割は関係者間のイメージ共有・実装との乖離検出の基準線・正しい挙動の拠り所の3点に集約される
  • これらはある時点での正しさを自然言語で記述して共有することに帰結する

■ 2. ドキュメント腐敗の根本原因

  • コードには型システムや依存関係グラフといった構造があり変更の影響範囲を機械的に特定できるが自然言語ドキュメントはそれが困難
  • 自然言語ドキュメントには機械的なフィードバックループが存在しないことが根本的な問題
  • Coding Agent時代では腐敗したドキュメントがAgentの行動を静かに悪化させる危険がある

■ 3. Agentが必要とするドキュメントの分類

  • 導出可能なもの（コードやテストから再構成可能なAPI仕様・型定義一覧など）: 書かない
  • 検証可能なもの（「レスポンス200ms以内」のように機械的にtrue/false判定可能なもの）: テスト・Linterに移す
  • 不変の記録（ADR・ポストモーテムなどある時点の決定と理由）: Append-onlyで保持
  • 還元不能な知識（外部制約・Why・組織判断などコードに落とせない知識）: 自然言語ドキュメントとして管理
  • ETH ZurichとLogicStar.aiの研究ではディレクトリ構造の概要をCLAUDE.mdに書いてもAgentのファイル発見速度は向上しなかったという結果が出ている

■ 4. 二層構造による提供方式

  • Layer 1（CLAUDE.md / AGENTS.md）:
    • セッション開始時に自動的にContextに注入される作業記憶として機能する
    • 禁止事項・ガードレール・アクティブなアーキテクチャ判断の要約・ビルド/テスト/Lintコマンドを置く
    • 約60行を上限としContext効率のためシンプルさを重視する
  • Layer 2（docs / docs/adr/）:
    • ADRやドキュメント群はAgentが必要に応じて参照する長期記憶として機能する
    • Context効率の観点からすべてをCLAUDE.mdに詰め込む必要はない

■ 5. ドキュメント管理・運用の実装

  • check-doc-freshness.shスクリプト:
    • CLAUDE.md/AGENTS.mdの行数制限（60行以上でエラー）を検査する
    • 壊れたパス参照の検出・last-validated日付チェック・古いADRへの参照確認を実施する
    • phase: currentのドキュメントは3日でWARNING・5日でERROR
    • phase: target（将来目標）は10日でWARNING・15日でERROR
  • PreToolUse Hook統合:
    • Claude CodeのHook機能を利用しgit commit前にドキュメント検査を自動実行する
    • exit 2とstderrを使用してブロック時のフィードバックを実装する
  • docs-auditorツール:
    • 各ドキュメントが読まれたタイミングを検出する
    • Agentの行動変化（beneficial/neutral/harmful/unnecessary）を分類する
    • ドキュメントごとのROI（impact_score / (content_tokens / 1000)）を計算する
    • 一度も参照されないドキュメントを検出する
  • 二段構えの運用:
    • check-doc-freshness.sh（軽量・高頻度）: 毎コミット時の時間ベースチェック
    • docs-auditor（重量・低頻度）: 定期的な実行と実際の行動改善度評価

■ 6. 人間向けドキュメントの扱い

  • 人間向けドキュメント（オンボーディング・運用手順・ユーザーマニュアル）はリポジトリの外に出す選択肢を検討する
  • Agent向けドキュメントとの混在を回避し各最適化に専念可能にすることが目的
  • コード変更に連動した自動更新の仕組みがないことが課題であり現状では試行錯誤中

■ 7. まとめ

  • Coding Agent時代でも基本的なドキュメントの役割は変わらないがフィードバックループの構築が必須
  • 検証可能性か不変性のいずれかを持つドキュメントを優先する
  • 導出可能なものは書かず検証可能なものはテスト化する方針を採る
  • 二層構造と二段構えの運用で腐敗対策を実装する
  • コード規模やチーム規模によって正解は異なり試行錯誤の余地がある

(2026/03/19)

急成長でぶつかったMySQLの罠とその向き合い方

要約:

■ 1. 概要

  • 発表者はTimeeのプラットフォームエンジニアリングチームに所属する徳富博
  • Aurora MySQLを使用するサービスの急成長で顕在化した7つの罠とその対処法を紹介する
  • 急成長の文脈として以下の3点が挙げられる
    • アクセス数の急増によりボトルネックが顕在化
    • データ量の急増によりクエリ処理速度が低下しインデックス設計の重要性が増大
    • 開発者増加によりMigration頻度が増加しALTER TABLEのロック影響が無視できなくなった

■ 2. 罠①: DDL実行時の落とし穴

  • メタデータロック（MDL）に関する誤解:
    • 「オンラインDDLならロックはゼロ」という誤解が存在する
    • アルゴリズムに関わらずMDLは必ず発生する
    • ALGORITHM=COPYは開始から完了まで排他MDLを継続保持しDMLが完全にブロックされる
    • ALGORITHM=INPLACEは初期化・実行・最終フェーズの3段階でMDLを取得する
    • ALGORITHM=INSTANTは最終フェーズ（commit table definition phase）でのみ排他MDLを取得する
  • MDL待機の発生フロー:
    • DMLが共有MDLを取得した状態でALTER TABLEが排他MDLを要求し待機する
    • 後続のSELECT/UPDATEが共有MDLを取れずキューに詰まる
    • アクセス数が多いプロダクトではこれが大きな問題になる
  • Aurora固有の挙動:
    • Vanilla MySQLではMDL待ちがレプリカ側に溜まり待機する
    • Aurora MySQLではDDL反映がクラスターボリューム共有によりほぼ即時反映される
    • Auroraリードレプリカでは実行中のクエリが強制終了（Lost connection）される
    • MDL待ちは溜まらないが単発エラーが発生する
  • Aurora lost connectionへの対応:
    • Rails 7.1から導入された自動リトライ機能を活用する
    • lost connectionエラー発生時に一定回数クエリを自動リトライするよう設定する
    • ALTER完了後にリトライが成功しアプリ側にはリカバリされる
  • 外部キー制約追加時の注意（COPYアルゴリズム強制）:
    • foreign_key_checks=1（デフォルト）のまま外部キーを追加するとCOPYアルゴリズムが強制される
    • COPYアルゴリズムではテーブル全コピーの間INSERT/UPDATE/DELETEが完全停止する
    • migration実行前にSET SESSION foreign_key_checks=0を実行することでINPLACEになりDMLを止めずにオンライン実行できる
    • ただしforeign_key_checks=0は整合性チェックをスキップするため実行前にデータ整合性を確認する
  • 外部キー追加時の参照先テーブルへのSロック:
    • COPYアルゴリズムでは既存データを新テーブルへコピーする際に参照先テーブルの整合性チェックが走る
    • InnoDBはその間参照先テーブルにSロック（共有ロック）をかけ続ける
    • 親テーブルへのUPDATE/INSERT/DELETEはXロックが必要なためSロックと競合しタイムアウトが発生する
    • foreign_key_checks=0でINPLACEにすることで子テーブルのCOPYが走らず参照先テーブルへのSロックも発生しない

■ 3. 罠②: Drop Table中にMDLによるデッドロックが大量発生

  • MySQLのレイヤー構造の理解:
    • MySQLサーバーレイヤー（SQL Layer）がメタデータロック（MDL）を管理する
    • InnoDBストレージレイヤーが行ロック・ギャップロック・ネクストキーロックを管理する
    • 一般的にイメージするデッドロックはストレージレイヤーのものだが今回のデッドロックはサーバーレイヤーのもの
  • SHOW ENGINE INNODB STATUSに出ないデッドロック:
    • MDL（メタデータロック）はサーバーレイヤーで管理されInnoDBロックモニターの対象外
    • SHOW ENGINE INNODB STATUSやinnodb_print_all_deadlocksには出力されない
    • Datadog/CloudWatchにも何も出ない
    • Performance Schemaのmetadata_locksテーブルで確認可能
  • MDLデッドロックの発生メカニズム（DROP TABLE + FK）:
    • セッション①がordersテーブルをSELECTし共有MDLを保持する
    • セッション②がFKを持つ子テーブルcustomers_ordersをDROP TABLEしようとする
    • DROP TABLEはcustomers_orders・customers・ordersの排他MDLを順次要求する
    • ordersの排他MDLはセッション①の共有MDLが邪魔し待機する
    • セッション①がcustomersをSELECTしようとするがセッション②がcustomersの排他MDLを保持中
    • セッション①はcustomers待ち・セッション②はorders待ちとなり相互待機（デッドロック）が発生する
  • 再発防止策:
    • DROP TABLE前に外部キー制約を先に削除することで排他MDLの競合対象を最小化する
    • Migration前に本番環境で参照先テーブルへのDMLが走っていないことを確認してから実行する

■ 4. 罠③: Auroraの場合レプリカの重いクエリがWriterに影響する

  • 問題の概要:
    • Redashによる数時間の集計クエリがReader上で実行されていた
    • AuroraはWriter/Reader間でクラスターボリューム（Undoログ）を共有する
    • Readerで長時間トランザクションが実行されるとUndoログがパージできなくなる
    • 古い行バージョンが蓄積しRollbackSegmentHistoryListLengthが増大する
    • 共有ボリュームを通じてWriter側のクエリ劣化が発生する
  • 対策（トランザクション分離レベルの活用）:
    • 集計クエリには分離レベルをREAD COMMITTEDに設定することでUndoの肥大化を抑制できる
    • SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED を実行してから集計クエリを実行する
    • REPEATABLE READ（デフォルト）はNon-repeatable readとPhantom readを防ぐがUndoログ蓄積が多い
    • READ COMMITTEDはNon-repeatable readとPhantom readが起きうるがUndoログ蓄積が少ない
    • 集計系はリアルタイム整合性より安定稼働が重要でREAD COMMITTEDで十分なケースがほとんど

■ 5. 罠④: 同時リクエストによるデッドロック

  • パターン①: ギャップロックデッドロック:
    • ギャップロック（Gap Lock）はインデックス上の「レコードとレコードの間の隙間」に対してかかるロック
    • SELECT FOR UPDATEでレコードが存在しない場合その検索範囲に他トランザクションがINSERTできないよう封鎖する
    • Gap Lock同士は競合しないため複数トランザクションが同じギャップにGap Lockを取れてしまう
    • INSERTはGap Lockと競合するためお互いのGap Lockに阻まれた状態で相互ブロックが生まれやすい
    • 発生シナリオ: TxAとTxBが同時に「email3を検索してなければINSERT」を実行する
    • 両者がGap Lockを取得後INSERTを試みると相手のGap Lockに阻まれ相互待機（デッドロック）が発生する
    • 対策①: INSERT IGNOREまたはINSERT ON DUPLICATE KEY UPDATEを使い1クエリで完結させGap Lockを取らないようにする
    • 対策②: FOR UPDATEをやめ存在確認のみなら共有ロックまたはロックなしにしXロックが本当に必要かを設計から見直す
  • パターン②: S→X昇格デッドロック:
    • SロックはSELECT LOCK IN SHARE MODEで取得し他のSロックとは競合しない
    • XロックはSELECT FOR UPDATE/UPDATE/DELETEで取得し全てのロックと競合する
    • SロックをXロックに昇格しようとすると相手のSロックが邪魔になり相互ブロックが発生する
    • 発生シナリオ: TxAとTxBがFKを持つ子テーブルにINSERT後親テーブルをUPDATEする
    • FK INSERTでInnoDBが親テーブルの参照行にSロックを自動取得する（S同士は競合しないので両方成功）
    • その後UPDATEでXロックが必要となるが相手のSロックが邪魔で待機する
    • TxAはTxBのSロック待ち・TxBはTxAのSロック待ちとなりデッドロックが発生する
    • 対策①: UPDATEを先に実行することで先にXロックを取得し後続のFK INSERTのSロック取得を同一TX内のXで成功させる
    • 対策②: INSERT前にSELECT FOR UPDATEで先にXロックを取得し順番待ちにすることで相互ブロックを回避する

■ 6. 罠⑤: 意外に広いロック範囲

  • パターン①: UPDATEでテーブル全体がロックされる:
    • インデックスなしのUPDATEではテーブル全体をスキャンし全行に排他ネクストキーロックがかかる
    • 本来1ユーザーだけ更新したいのにテーブル全体がロックされ他トランザクションのINSERT/UPDATE/DELETEがほぼ停止する
    • 対策: 適切なインデックスを追加することでロック範囲を劇的に狭める
  • パターン②: 外部キー制約で親テーブルにSロックが伝播する:
    • group_usersにINSERT/DELETEするとInnoDBが参照整合性チェックのため参照先の親行にSロック（共有ロック）を自動取得する
    • バルク処理が大量のSロックを保持し続けると退会・更新系APIのXロック取得がブロックされる
    • 対策: バルク処理を小さいバッチ（例: 100件ごと）に分割して途中でCOMMITしSロックの保持時間を短縮する

■ 7. 罠⑥: 急成長でじわじわ悪化するスロークエリ

  • 問題の構造:
    • リリース直後はデータ数が少なくフルスキャンでも数msで問題なし
    • 数ヶ月後にデータが数百万件に増加し同じクエリが数秒に悪化する
    • 急成長期にそのエンドポイントへのアクセスも急増し処理が詰まりはじめる
    • 最終的にタイムアウト多発・接続枯渇・DB負荷急上昇という障害に至る
    • データ量の増加×アクセス数の増加が「無害だったクエリ」を障害の引き金にする
  • 気づきにくい理由:
    • リリース時のレビューでは少量データでテストしており問題が見えない
    • データ増加は緩やかなため劣化が少しずつ進み気づくのが遅れる
    • コード変更なしで突然遅くなるため原因特定に時間がかかる
    • AIコードレビューでもクエリの実行計画までチェックできない
  • Datadog Database Monitoringによる改善体制:
    • 発見〜改善のフローは「トレースで検知 → 実行計画を確認 → AIが仮説を提示 → チームが修正」
    • スロークエリの検出: 実行時間・頻度でランキングし問題クエリを一目で特定できる
    • 実行計画の可視化: EXPLAINの結果をUIで視覚的に確認しFull Scan/非効率な結合を検知する
    • AIによる改善提案: 実行計画をもとに適切なインデックス構成をAIが自動提案する
    • チームの自律改善: SREを介さず各開発チームが自分たちのクエリを改善できる

■ 8. 罠⑦: データ増加でBuffer Poolが足りなくなる

  • InnoDB Buffer Poolとは:
    • テーブルのデータページ・インデックスページをメモリにキャッシュする領域
    • クエリ実行時MySQLはまずBuffer Poolを確認しヒットすればメモリから返す
    • ミスすればストレージから読み込みBuffer Poolに保存する（Read I/O発生）
    • AuroraではBuffer Poolサイズ = DBInstanceClassMemory × 3/4で自動計算される
  • 急成長期に起きること:
    • データ量の増加によりワーキングセットがBuffer Poolを超えはじめる
    • 一度読み込んだデータが追い出され次のクエリでまたストレージから読み直す
    • インデックスの増加によりBuffer Poolを消費しインデックス自体もページとしてキャッシュされるため無計画な追加は逆効果になりうる
    • 結果として毎クエリでストレージから読み直しが発生しRead I/Oが急増しクエリが急激に遅くなる
  • 監視すべきメトリック:
    • Buffer Pool Hit Ratio: キャッシュヒット率でここが下がるとストレージ読み取りが急増する
    • Read IOPS/Read Latency: Buffer Poolミスが増えると連動して悪化する
    • Buffer Pool使用率: 100%張り付きはワーキングセットがBuffer Poolに収まりきれていないサイン
  • チューニングのアプローチ:
    • インスタンスサイズアップ
    • パラメータチューニングでbuffer poolサイズを増やす
    • 不要なインデックスを削除する

■ 9. まとめ: どう向き合うか

  • レイヤーを意識する:
    • サーバーレイヤー（MDL）なのかInnoDB（行ロック）なのかで観測方法・対策が全く異なる
    • 「どのレイヤーで起きているか」を最初に問う習慣を持つ
  • 仕組みを理解してから運用する:
    • 「InnoDBバッファプール」「MVCC/Undoログ」「メタデータロック」の概念を知っているだけでトラブルシューティングの精度が格段に上がる
  • 高トラフィックは「通常では起きない」競合を日常化する:
    • 理論上起きにくい競合もリクエスト数が増えれば確率論的に必ず発生する
    • 設計段階から競合を想定したロック設計・インデックス設計を行う
  • 改善を積み重ねる:
    • 単発の対応で終わらせずポストモーテム→再現実験→予防策→モニタリング追加のサイクルを回す
    • Aurora運用知識そのものがプロダクトの継続性に直結する

(2026/03/18)

メンバーの「主体性の無さ」に悩むEMが知っておきたい四つのマネジメント術【安斎勇樹『冒険する組織の...

要約:

■ 1. 現代マネジメントの根底にある「軍事的世界観」

  • 「戦略」「戦術」「VUCA」など日常的なビジネス用語の多くは軍事用語が起源
  • 目標設定・フィードバック・人材育成研修などのマネジメント手法も戦争の文脈で発展
  • 軍事的マネジメントの目標は個人を視野狭窄な歯車（ボット）にすること
  • 上層部の計画を末端まで正確にインストールし効率よく遂行させる手法が現代マネジメント理論のベース

■ 2. キャリア観の「地動説的」転換

  • かつては会社への滅私奉公・理不尽な異動への耐性が標準的な価値観
  • 現代は「自分の人生をどうハッピーにするか」という個人の問いが根底にある
  • 会社は個人の人生の構成要素の一つに過ぎないという価値観へと転換
  • 旧来の「危機感を煽る」手法は現代では離職を招くだけ
  • 人材流動性が高まり恐怖や危機感による統率が不可能になっている

■ 3. 「冒険的世界観」へのパラダイムシフト

  • あらゆるマーケットが飽和し「何を作れば正解か」が誰にも分からない時代
  • トップダウンの命令で人を機械のように動かす軍事的世界観は限界を迎えている
  • これからは働くメンバーの「好奇心」や「内発的動機」を資源とした組織づくりが求められる
  • 会社の事業成長と個人のキャリア・やりがいの異なるベクトルをすり合わせシナジーに変えることが現代EMの役割

■ 4. 冒険的な組織になるための四つのアプローチ

  • 【1】SMARTの呪縛を解きALIVEで意味付ける（目標のマネジメント）:
    • SMARTの法則（Specific・Measurable・Time-bound等）は管理側には有効だが被評価者の内発的動機を高めない
    • ALIVEの法則（Adaptive・Learningful・Interesting・Visionary・Experimental）で内発的動機を引き出すバランスをとる
    • EMの役割は目標そのものをALIVEに変えることではなく目標をALIVEなものとして解釈できるよう「意味付け」すること
    • 変化が激しい時代には「Adaptive」が特に有効でキャリアへの汎用性を対話で紐付けるとよい
    • 前期の振り返りでメンバーの「興味の芽生え」をヒアリングし次期目標にストーリーテリングで紐付けることが重要
  • 【2】メンバーと自分の「興味の偏り」をメタ認知する（興味のマネジメント）:
    • 変化が激しい時代に「3年後どうなりたいか」と聞いても「特にない」という反応が返るのがリアル
    • 将来目標ではなく「現在進行形で何を面白いと思っているか」という興味を育成の手掛かりにすることが現代的
    • 好奇心（瞬発的・散漫な感情）と興味（好奇心が特定対象に定着・深化した状態）は異なる
    • 散漫な好奇心を興味として定着させる技術の有無が問われる「興味格差の時代」になる
    • 成果を出してEMになった人は「事」への関心が強く「人」への関心が薄いため「マネジメントが罰ゲーム」と感じやすい
    • 「事」寄りのEMは人間のメカニズムを工学的・システム的に捉え直すことで「人」への技術的な興味が芽生えることがある
    • それでも困難な場合は「人に興味があるメンバー」を右腕として連携マネジメントを行う方法がある
  • 【3】オープンクエスチョンがメンバーの主体性を削ぐ（会議のマネジメント）:
    • 人間の主体性・創造性が発揮される最小単位は「目の前の選択肢から選ぶこと」や「対象に点数をつけること」
    • 真っ白な状態からオープンクエスチョンに答えるには高い主体性と創造性が必要
    • 会議では「100点満点で何点か数字だけ書いてください」と問いかけることで全員の参加を促せる
    • 数字が出揃った後に「なぜその点数か」「あと何点上げるには何が必要か」と深掘りすることで具体的な意見が引き出せる
    • 1on1でも同様に「A・B・Cのうち一番面白かったのはどれ」と過去の案件から選ばせることで主体性が引き出せる
    • 選択肢から選んだ理由こそがメンバーのやりたいことや今後増やしたい仕事の種
  • 【4】風土に流されず独自の価値基準を意図的に作る（文化のマネジメント）:
    • 風土（Climate）はチームが感じる雰囲気であり文化（Culture）はその組織固有の「価値基準」
    • 価値基準とは「AよりもBを大事にするという判断の集合体」
    • EMが「自分のチームは何を一番大事にするか」という価値基準を定めメンバーに意図的に刷り込み続けることが必要
    • 重視したい価値観を日常のルールや習慣に組み込み体現しているメンバーを称賛することでカルチャーが醸成される
    • チームの価値基準をEMが意図的に構築することがメンバーの判断の迷いをなくし自律的なチームの土台となる

■ 5. 「半径5メートル」から冒険をはじめる

  • 現代のEMがマネジメントに苦戦するのは個人のスキル問題ではなく軍事的マネジメント手法と現代の価値観のズレが原因
  • 組織全体を変えることは難しくても自チームの「半径5メートル」であれば今すぐ変えられることは多い
  • メンバーの小さな好奇心に目を向け問いの投げかけ方を変えることが次の時代のマネジメントへの第一歩

(2026/03/17)

エンジニア出身PMのための開発見積もり入門

要約:

■ 1. 見積もりが難しい理由

  • 見積もりは未経験・未確定の事柄を数値化する行為であり本質的に精度が低い
  • 人は無意識に最良シナリオを基準とする楽観バイアスを持つ
  • 「早くしてほしい」という圧力に根拠なく応じるとバッファのない計画が生まれ破綻時にエンジニアが責任を問われる
  • 見積もりは「予測であって約束ではない」とステークホルダーと共有することがPMの重要な役割

■ 2. 代表的な見積もり手法

  • ストーリーポイント:
    • スクラム開発で使用し工数を時間ではなく複雑さ・不確実性の相対値で表現する
    • フィボナッチ数列（1・2・3・5・8・13・21）を使用する
    • チームのスプリント消化ポイント数（ベロシティ）を計測しスケジュール予測精度を向上させる
    • プランニングポーカーで全員が同時にカードを出すことで認識齟齬を検出し議論する
  • 三点見積もり（PERT見積もり）:
    • 楽観値・最頻値・悲観値の3シナリオから期待値を算出する
    • 計算式は「（楽観値 + 4×最頻値 + 悲観値）÷ 6」
    • リスクを織り込んだ結果が得られるためステークホルダー説明やスケジュール表作成に適する
  • 類推見積もり:
    • 過去の類似タスク実績をもとに見積もる
    • 見積もりと実績の継続記録が精度向上の前提となる

■ 3. バッファとスコープ管理

  • バッファは水増しではなく仕様認識齟齬・外部API変更・レビュー修正など想定外事象へのリスク対策
  • MoSCoW法で要件をMust have・Should have・Could have・Won't haveの4分類に整理する
  • プロジェクト開始時にステークホルダーと分類を合意しておくことで圧縮要求に対してスコープ取捨選択で応じられる
  • 圧縮要求への対応方針:
    • スコープ削減交渉として「工数削減は困難だが特定機能をフェーズ2に回すことで納期短縮できる」と提示する
    • リスク明示として「短縮にはレビュー簡略化が必要であり品質リスクが上昇する」と許容可否を確認する

■ 4. 見積もり精度を上げるコツ

  • タスクを1〜2日以内の小単位に分解することで不確実性を低下させる
  • 見積もり後に実際の工数を記録しスプリント振り返りで差分を分析して次回精度を向上させる
  • プロジェクト開始時に不確実性の高いタスクを早期特定しスパイク（調査タスク）を先行して実施する

■ 5. 手法の使い分け

  • ストーリーポイント: スクラムなどイテレーション開発・チームベロシティ管理に向く
  • 三点見積もり: 納期重視・ステークホルダー説明が必要な場面に向く
  • 類推見積もり: 過去実績あり・素早く概算を出したい場面に向く
  • 見積もりは「当てるものではなく不確実性を管理するためのツール」であり外れることを前提にバッファを持ち実績記録で精度を継続改善することがPMに求められる

(2026/03/16)

アーキテクチャモダナイゼーションを実現する組織

要約:

■ 1. 概要・目的

  • 本資料はNick Tune著「Architecture Modernization」の組織論に関する章を中心に解説した講演資料
  • モダナイゼーションを技術ではなく組織の視点で説明し明日からの行動に繋げることを目的とする
  • 対象読者はモダナイゼーションに迫られたビジネスリーダーと会話をするエンジニア・モダナイゼーションに知見をつけたいエンジニア・エンジニアとの折衝を行うビジネス職

■ 2. モダナイゼーションと「組織」の問題（第1・2章）

  • モダナイゼーションの障壁は技術の問題ではなく組織の問題である
    • マイクロサービスに移行したのにデプロイは遅くなった
    • 技術的負債の返済を始めたが半年で元の優先度に戻った
    • 新アーキテクチャを設計したがチーム間の調整コストが爆発した
  • モダナイゼーションが必要な理由は変化が必ず起きて競争優位性を保てなくなるため
    • 業界の変化（新規参入・新製品・既存市場）
    • 自社組織と外部技術の変化（メンバー離脱・技術シフト）
    • 国内・世界情勢の変化（法律・関税・調達コスト増加）
  • モダナイゼーションの定義は技術の刷新だけではなく技術・組織・文化の変革である
    • 目指すのは「持続可能な高速フロー」
    • アイデアから本番環境への迅速かつ安全なデリバリー
    • 複数年にわたって維持できる能力
  • コンウェイの法則によりソフトウェアの高速なフローを実現するには組織構造が密接に関係する
    • システムを設計する組織はその組織のコミュニケーション構造をコピーした設計を生み出す（Melvyn Conway 1968）
    • コンウェイの法則の力を無視してアーキテクチャを考え出そうとするとミスマッチが生じ多くの摩擦と問題が生じる（Martin Fowler）
  • コンウェイの法則が裏目に出た事例（旅行会社）
    • マーケティングIT部門とIT部門（プラットフォーム）が断絶していた
    • プラットフォームAPIの信頼性が低くてもマーケティングIT側が責任を押し付けられた
    • 技術的回避策（プラットフォームのデータ同期機能の構築）を選んだ結果として同期維持に認知負荷の大部分が消費された
    • 教訓：ソフトウェアアーキテクチャが組織のコミュニケーション機能不全を反映してしまった
  • 組織の準備確認として5つの問いを経営層に投げかける必要がある
    • ビジネスリーダーは新機能開発の速度を落とす覚悟があるか
    • レガシーシステムの変更が複雑で時間がかかることを理解しているか
    • 予期せぬ事態が発生し大幅な遅延やコスト増加が生じた場合どう反応するか
    • 予算の仕組み・作業の優先順位付けを変えチームに権限委譲する準備があるか
    • 学習とスキルアップに十分な時間と資金を投資する意思があるか
  • 経営層との合意形成には技術用語をビジネス言語に翻訳することが必要
    • 技術的負債 → 機会損失コスト（競合は2週間で出せるものが自社は3ヶ月）
    • リファクタリング → 市場投入速度の改善（新機能の開発に本来の3倍の時間がかかっている）
    • アーキテクチャ刷新 → 事業継続性のリスク低減（現行システムを理解する人が2名のみ）
  • 合意形成の実践アプローチは3つのステップで構成される
    • ステップ1：現状を可視化する（DORAメトリクスによるデリバリー速度の定量化・障害対応コストの集計・技術的負債による機会損失の列挙）
    • ステップ2：小さく始めて信頼を得る（いきなり全面刷新を提案せず3〜6ヶ月で成果が見えるパイロットを提案・成果をビジネス指標で報告）
    • ステップ3：継続的にコミットメントを維持する（定期的な進捗報告をビジネス言語で行い・割り込みによる影響を可視化し数字で示す）

■ 3. モダナイゼーションに必要な組織の姿（第11・13章）

  • チームトポロジー（Matthew Skelton & Manuel Pais 2019年）はソシオテクニカルなアプローチ
    • 組織とソフトウェアの設計を同時に最適化する体系的なアプローチ
    • 目的はチームの自律性と高速なフローの実現
    • 4つのチームタイプと3つのインタラクションモードで構成される
    • ソシオテクニカルとは社会システム（人間・組織）と技術システムを別々のものではなく相互依存し合う一つのシステムとして捉える概念
  • 5つの基本原則
    • 持続可能な高速フロー：速度と品質はトレードオフではない
    • 小規模で長期的なチーム：5〜9人の安定したグループ
    • チームファーストの考え方：人は「リソース」ではない
    • You build it you run it：開発から運用まで一貫した責任
    • 認知負荷の最小化：チームが扱える範囲に責任を制限
  • 原則の実践（フローとチーム）
    • 持続可能な高速フロー：高パフォーマンスチームは1日に複数回デプロイしダウンタイムも少なく回復も迅速（DORAの4つのキーメトリクスで自組織の現在地を測定可能）
    • 小規模で長期的なチーム・チームファースト：5〜9人で信頼を維持しすべての作業は個人ではなくチームに向けられ目標設定と評価もチーム単位でチームはなるべく解散をしない
  • 原則の実践（責任と認知負荷）
    • You build it you run it：運用性を考慮した機能開発が自然に行われ他チームとのデプロイ調整が不要になりフローが大幅に高速化（7digitalの実例では各チームが毎朝ダッシュボードで確認し運用しないチームでは見たことがない良い品質が達成できている）
    • 認知負荷の最小化：認知負荷には課題内在性（軽減困難）・課題外在性（削減すべき）・学習関連（増やしたい）の3種類があり高い兆候は過度のコンテキストスイッチとデリバリーペースの低下であり対処法はサブドメインが大きすぎる場合に複数の小さなサブドメインに分割すること
  • 4つのチームタイプ
    • ストリームアラインドチーム：バリューストリームに端から端まで責任を持つ（組織の大多数）
    • プラットフォームチーム：ストリームアラインドチームの認知負荷を軽減する共有機能を提供
    • コンプリケイテッドサブシステムチーム：高度な専門知識を要する複雑なサブシステムを担当
    • イネーブリングチーム：新しい技術やプラクティスの習得を支援（終了条件あり）
  • 内部開発者プラットフォーム（IDP）のポイント
    • プラットフォームチームの役割はストリームアラインドチームの認知負荷を軽減すること
    • セルフサービスで利用でき開発者体験（DX）が優れていることが重要
    • 「薄いプラットフォーム」から始めチームの実際のニーズに基づいて段階的に成長させる
    • 既存のクラウド（Google Cloud・AWS・Azureなど）を組織構造に合わせてカスタマイズして利用する
  • 3つのインタラクションモード
    • コラボレーション：2チームが密接に協力して共通目標を達成（認知負荷：高い）
    • X-as-a-Service：明確に定義されたサービスを提供しinterfaceに従い利用（認知負荷：低い）
    • ファシリテーティング：一方が他方のスキルアップや目標達成を支援（認知負荷：中程度）
    • ポイント：コラボレーションは有用だが認知負荷コストが高くメリットが正当化できなければXaaSに切り替えるべき（チームの疎結合）
  • チームトポロジーの設計は一度設計して終わりではなく継続的な見極めが必要
    • 進化が必要なサイン：過度のコラボレーション（ドメイン境界が最適でない）・過度のコンテキストスイッチ（認知負荷が高すぎる）・デリバリーのペースが遅くなっている・過度なデリバリー調整（境界と変化が整合していない）
    • 数年ごとの大規模な組織再編ではなく絶えず見極めて進化できる組織を構築すべきである

■ 4. モダナイゼーションを推進する組織（第15章）

  • AMET（アーキテクチャモダナイゼーションイネーブリングチーム）の定義
    • モダナイゼーションの慣性の力に立ち向かう一時的なチーム
    • ワークショップ開催・コーチング・優先度の維持を通じてモダナイゼーションを推進
    • 最終的にAMET自体が不要になる状態を目指す（一時的な足場）
    • AMETではないもの：全モダナイゼーション作業を担う「モダナイゼーションチーム」・すべてのアーキテクチャを設計する「中央集権的アーキテクトチーム」
  • AMETが解決する6つの課題
    • 着手できない・分析麻痺 → モダナイゼーションを始動させる
    • 他業務との競合で進捗が遅れる → 高い勢いを維持する
    • 設計の知識・経験不足 → よりよい設計を支援する
    • 従来手法への後戻り → 持続可能な変化を促進する
    • 関係者がモダナイゼーションの価値を理解できない → ビジョンを周知し続ける
    • ある分野の学びが他で活かされない → 学びを共有・展開する
  • AMETの活動プロセス（3〜6ヶ月で始動し役割を終えたら外す）
    • ヒアリングとマッピングのツアーで問題とモダナイゼーションの機会を発見
    • キックスターターワークショップ（数日間対面）でビジョンの認識を合わせる
    • 3〜6ヶ月以内で成果を出す具体的な行動計画を策定
  • AMETの関与度は時間とともに低下し最終的に組織自身がモダナイゼーションを主導する
    • 意思決定と方向性を主導
    • ファシリテートから見学に後退
    • 1対1コーチングでリーダーの能力を確認
    • リーダー自身が主導・AMET解散
  • 意思決定の分散にはアーキテクチャアドバイスプロセスを適用する
    • 誰でもアーキテクチャに関する決定を下せるが影響を受ける人々と専門家に事前に相談することが条件
    • ADR（Architecture Decision Records）で議論と決定を記録する
    • 原則と社内版テクノロジーレーダーを意思決定の指針にする
    • 週1回1時間のアーキテクチャ相談フォーラムを開催する

■ 5. モダナイゼーションを根付かせる組織（第17章）

  • モダナイゼーションの成否は学習にかかっている
    • モダナイゼーションが野心的であるほど学習への投資がより必要
    • 継続的に「進化」を続ける必要がある
    • 多くの新スキルの習得には数ヶ月を要する
    • 計画・予算の段階で学習コストを考慮しないと将来の問題になる
  • 学習の始め方は種をまき育てること
    • 読書会のような小さな種から始める
    • 同僚から尊敬されているインフルエンサーに権限を与え「トレーナー養成」方式でスキルを伝播
    • 小さな成功体験を積み重ねる
  • 主な学習手法
    • コミュニティ・オブ・プラクティス（CoP）：共通の関心を持つ人々の定期的な集まり
    • バイトサイズアーキテクチャセッション：月2回・45〜60分でチーム間の知識を広め集団的理解を深める
    • メンタリングプログラム：明示的なプログラムとして確立し人事評価と同等に扱う
    • モブ/ペアプログラミング：実践を通じた最も効果的な学習
    • 社内テックカンファレンス：年1〜2回の知識伝播と一体感の創出
  • 事例：PayFit（フランス/HRテックユニコーン/約1000人）
    • エンジニアリングディレクターがDDD読書会を開始（隔週）しスタッフエンジニアと数名のマネージャから他のメンバーを巻き込んだ
    • 2年かけて成長し経営陣を通し全社的な「単一の給与計算ドメインに対して」ドメインディスカバリーとモダナイゼーションを実施
    • 「給与期間」を「6人が7つの異なる意味で使う」状態を解消
  • 事例：Infor（CloudSuite）（アメリカ/Eコマース/約20人）
    • アーキテクチャ変更の前にまず技術的卓越性の構築に注力
    • Samman Methodで学習文化を育成しボトムアップでコアドメインを特定
    • 逆コンウェイ操作（理想のアーキテクチャに基づきチームを組成）を段階的に適用
  • Samman Method（Emily Bacheによる）
    • ラーニングアワー（Learning Hours）：日々の業務から意図的に切り離された短時間（通常1時間程度）の集中学習セッションでコードカタなどを使い安全な環境で新しい技術や概念を練習する
    • アンサンブルワーキング（Ensemble Working）：ラーニングアワーで学んだ技術を実際のプロダクションコードに適用していく実践プロセスでチーム全員（3〜6人程度）が一つの画面を共有し協力してコードを書くモブプログラミング形式
  • 学習を組織のDNAに組み込む実践ポイント
    • 学習活動は通常の勤務時間内に組み込み他の業務と同等に扱う
    • メンバーのメンタリングを追加業務ではなく人事評価で同等の重要度として扱う
    • 経営陣や上位層が学習を奨励していると感じさせる環境をつくる
    • 7digitalの事例：月に2日間の学習時間・毎週数時間の議論タイム（CTOが強く奨励）によりすべてのチームが毎日プロダクションにデプロイし入社初日にデプロイしバグは昼食前に解決
  • 学習文化のアンチパターン（優秀な人材の流出につながる）
    • CTOがカンファレンス参加費を半額しか出さない
    • チーフアーキテクトがカンファレンスを公然とバカにする
    • メンタリングを追加業務として課しつつ同じ作業量を期待する
    • 変革を技術的なものだけと考え合意形成なしに進める
    • 逆コンウェイ操作を現在のシステム制約を無視して適用しようとする

■ 6. AI Agent時代の組織を考える

  • 2025年以降Coding AI Agentが急速に発展
    • Claude Code・GitHub Copilot・Gemini CLI Agent mode・Devin・Cursor Agentなど
    • コード生成だけでなく調査・設計・テスト・リファクタリングまで一貫して実行
    • 「エンジニア1人あたりの生産性」の前提が変わりつつある
  • AI Agentでも変わらないもの：モダナイゼーションの本質的な難しさはコードではなくコンテキストにある
    • ドメイン知識のヒアリング：「給与期間」を6人が7つの意味で使う問題はAIでは解決できない
    • 組織間のコミュニケーション：部門の断絶・責任の押し付け合いは人間の課題
    • ビジネスコンテキストの理解と意思決定：何をモダナイズすべきか・優先順位は何か
  • AI Agentで加速できること
    • 現状の可視化：レガシーコードの構造分析・依存関係の整理・ドキュメント生成
    • PoCの高速作成：新アーキテクチャの検証用プロトタイプを数時間で構築
    • 移行の自動化：コードの機械的なリファクタリング・テストの自動生成
    • 学習の加速：コードベースの説明・ペアプログラミングの相手としての活用
    • ポイント：AI Agentは「手を動かす速度」を上げるが「正しい方向」を決めるのは組織であり効率の良い「作業環境」を作るのも組織
  • AI Agentを入れただけでは変わらないことが調査で示されている
    • チームレベルでは改善あり（タスク完了数+21%・マージされたPR数+98%・1日あたりのPR処理数+47%）
    • 組織レベルでは改善なし（全社スループート有意な相関なし・DORA指標改善なし・品質KPI改善なし）
    • PRレビュー時間+91%・バグ発生率+9%という下流のボトルネックが価値を吸収（Faros AI 2025・10,000名以上の開発者テレメトリ分析）
  • AI Agentを武器にするための組織の条件
    • AI Agentの効果は組織の成熟度に比例する
    • ドメイン知識が属人的 → Agentに正しい指示が出せず的外れな成果物が量産される
    • チーム間にコミュニケーション不全 → Agentが生成したコードが他チームの前提と矛盾する
    • 学習文化がない → Agentの使い方がチーム間で共有されず効果にばらつき
    • ドメイン知識が共有されている → Agentに的確な指示を出せ高品質な成果物が得られる
    • チームの自律性が高い → Agentを活用した素早い意思決定と実装が可能になる
    • 本書の組織論を実践することがAI Agent時代の競争優位に繋がる
  • AI Agent導入を経営層に伝える際のビジネスインパクト
    • AI Agentを導入したい → モダナイゼーションの投資対効果を数倍に高められる
    • 開発者の生産性が上がる → 新機能の市場投入を現在の半分の期間で実現できる
    • 注意：Agentの導入にもコストがかかる（ライセンス・ガバナンス整備・学習時間）のでパート1で述べた合意形成のアプローチが必要

■ 7. まとめ：明日からできること

  • 持続可能な高速フロー（ゴール）を実現する全体構造
    • 土台：リーダーシップのコミットメント
    • 必要な組織の姿（チームトポロジー）：5つの原則・4つのチームタイプ・3つのインタラクション
    • 推進する組織（AMET）：始動・勢いの維持・段階的縮小
    • 根付かせる組織（学習文化）：種をまく・CoP/メンタリング・DNAに組み込む
  • 個人・複数人として明日からできること
    • 読書会を始める（1冊・2人から）
    • バイトサイズアーキテクチャセッションを試す（月2回・45分）
    • 自チームの認知負荷を振り返る
  • チームとして明日からできること
    • DORAメトリクスで現在地を測定する
    • チームの自律性レベルを確認する（ロードマップの決定権はあるか）
    • You build it you run itを始める（小さく・1つのサービスから）
  • 組織として明日からできること
    • リーダー層に5つの問いを投げかける
    • AMET的な役割を検討する
    • 学習を通常業務と同等に扱う制度を設計する

(2026/03/15)

なぜ、SOLIDのリスコフ置換の原則(LSP)はもはや不要なのか？

要約:

■ 1. LSPの歴史的背景と意義

  • LiskovとWingの1994年論文で行動的型付けとして定式化された概念
  • 事前条件・事後条件・不変条件を含む振る舞いの保存を要求
  • マーチンは1996年にC++のパブリック継承を律する原則として説明
  • 当時の再利用は抽象基底クラスと継承が主役であったため有用な実務原則だった
  • LSPが有効だったのは継承中心の設計世界という前提が存在したためであり普遍原則ではない

■ 2. LSPが継承前提の原則であった理由

  • 長方形と正方形の問題の本質:
    • 数学の包含関係を可変オブジェクトに移植したことが誤りであり正方形が悪いわけではない
  • ソフトウェア設計は分類学ではなく契約の設計:
    • 設計で問うべきは「同じ仲間か」でなく「同じ契約で扱えるか」
    • 共通の操作がなければ親型は不要であり共通の操作があるならそこだけを抽象化すれば足りる
  • 古いOOP教育のAnimal-Dog-Catのような例が抽象化の誤解を招く:
    • 抽象化の入口が逆向きとなり役に立たない巨大な親クラスが生まれる

■ 3. 現代言語における継承の扱い

  • Java:
    • sealed classとsealed interfaceでpermitsにより継承できるクラスを明示制限
    • ライブラリのクライアントが任意の新種をぶら下げることを防ぐ設計方針
  • Kotlin:
    • 委譲パターンを実装継承の良い代替として明言しbyによる委譲を言語機能としてサポート
    • シールドクラスとシールドインタフェースで直接の下位型をコンパイル時に既知にし外部からの拡張を防ぐ
  • C#:
    • sealedで他クラスからの継承を禁止
    • デフォルトインタフェースメソッドで既存インタフェースを壊さずに拡張する仕組みを提供
  • 継承を持つ現代言語でもLSP問題が発生しやすい野放し継承を推奨していない

■ 4. LSPが吸収された先

  • ISP（インタフェース分離原則）:
    • 利用者が必要とする操作だけを小さく切り出すことで長方形と正方形のような破綻が入口で消える
  • DIPと委譲:
    • 依存方向を抽象へ向け実装の再利用を継承でなく委譲で行うことで下位型が親の可変状態を持ち回らずに済む
    • 委譲中心設計では親の意味を壊しにくい構造になる
  • 型検査と閉じた階層:
    • TypeScriptの構造的型付けが名前でなく形で互換性を判定
    • JavaやKotlinのsealedが階層の増殖を閉じる
  • テスト:
    • 契約テストや回帰テストとして利用者側の期待を書き代替可能性を確かめる

■ 5. LSPをSOLIDに残し続けることの問題

  • 初学者がAnimal継承の例から入ることで設計の最初の問いが「親クラス名は何か」になる
  • 抽象化が契約の設計でなく分類の命名にすり替わる
  • 実際には半分以上の派生先でアンサポートになる巨大な基底クラスが生まれる
  • 「継承を正しく使えば世界をきれいに表現できる」という幻想が延命される
  • LSP違反以前の問題として継承構図そのものを最初に作ってしまうことが問題

■ 6. LSPが残る限定的な場所

  • 有効な文脈:
    • 継承ベースのAPIや古いフレームワーク
    • 基底クラス参照で差し替えを前提にしたライブラリ設計
    • JavaやC#の標準ライブラリ・既存の業務システム・GUIフレームワーク
  • 現在のLSPの位置づけ:
    • 「万人向けの基礎教養」でなく「ある設計条件で再登場する専門注意事項」
    • SRPやISPのように毎日意識する原則とは性格が異なる

■ 7. まとめ

  • LSPはもともと行動的型付けとして生まれ継承中心だった1990年代に有用な実務原則だった
  • 現代は継承あり言語でもシールドクラス・委譲・デフォルトインタフェースメソッドでLSP問題を言語機能側で吸収した
  • 置換可能性はISP・DIP+委譲・型検査と閉じた階層・テストへと分散吸収された
  • LSPは理論として尊重すべきだが現代の一般的な設計においてSOLIDの独立した柱として常設する必要はない
  • 継承中心時代の歴史的文脈とともに位置づけ直し必要な場面でだけ取り出して使うほうが筋が通っている

(2026/03/14)

次のトヨタ生産方式を作る

(2026/03/13)

LLMの台頭により、品質の高いコードレビューをできる人は今後いなくなる、ちゃんとソフトウェア設計を...

LLMの台頭により、品質の高いコードレビューをできる人は今後いなくなる、ちゃんとソフトウェア設計を理解している人は今後いなくなる、などなどは長期的には正なのかもしれないが（それも若干懐疑的ではある）、それで良いとなるかというとそうでは無いと思ってて、結局資本力等のパワーがある組織はその辺わかってる人材を獲得することで競争力とするのだろうし、「どうせいなくなるのだから知識がなくても良い」と楽観視（悲観視かもしれない）するのは短絡的なんではないかと思いますね

@moznion

(2026/03/12)

Goでクリーンアーキテクチャを導入するとinterfaceが爆発する問題への処方箋

要約:

■ 1. 概要

  • Goプロジェクトにクリーンアーキテクチャをそのまま適用するとinterfaceが過剰に増殖する問題が生じる
  • 問題の本質はinterfaceの個数ではなく「大きすぎるinterface」と「Goの言語特性を活かせていない設計」にある
  • Go的思想に則った再設計により問題を解消できる

■ 2. Goの思想との3つのズレ

  • 提供側でinterfaceを定義している:
    • Go公式Wikiは「interfaceは利用側のパッケージで定義すべき」と推奨している
    • 提供側での定義はGoのイディオムに反する
  • interfaceが太すぎる:
    • Rob Pikeの言葉「The bigger the interface, the weaker the abstraction」に反し1つのRepositoryに5〜8メソッドが存在する
    • 抽象化の粒度が大きすぎるため再利用性と柔軟性が低下する
  • Preemptive Interfaceが残存している:
    • 実装が1つしか存在しないinterfaceはGoコミュニティではアンチパターンとされる
    • 不必要な抽象化がコードの複雑性を増大させる

■ 3. 4つの処方箋

  • Input Portの廃止:
    • usecase/port/input/ディレクトリを削除する
    • Handler層のみでinterfaceを定義しGoの暗黙的interface満足を活用する
  • Output Portの選別保持:
    • 複数のInteractorが共有する外部サービス連携はOutput Portとして維持する
    • 単一Interactorにしか使われないものは廃止対象とする
  • RepositoryをReader/Writerに分離:
    • 単一の太いinterfaceを読み取り用と書き込み用に分割する
    • 各Interactorは必要な操作にのみ依存する設計とする
  • ディレクトリ構成の整理:
    • port/input/を廃止し出力ポートのみ残す
    • ディレクトリ構造を簡潔に保つ

■ 4. よくある疑問への回答

  • 依存性注入の方法:
    • structを直接渡すだけでimplicit interfaceにより要件が自動的に満たされる
    • 明示的なinterface指定は不要
  • interfaceが散らばる懸念:
    • private interfaceは利用箇所の直近で定義されるため実運用では管理上の問題になりにくい
  • 小規模プロジェクトへの適用可否:
    • CRUD中心のアプリケーションではこの複雑な設計は不要との見解が示されている

(2026/03/12)

リレーションとリレーションシップの誤用に注意

要約:

■ 1. 概要

  • リレーショナルデータベースにおける「リレーション（Relation）」と「リレーションシップ（Relationship）」の混同・誤用に対する注意喚起
  • E.F. Coddが1970年に定義した用語の正確な意味を踏まえ技術的な精度を高めることを目的とした解説

■ 2. 用語の定義

  • リレーション（Relation）:
    • ある時点における全行を含む単一のテーブルのこと
    • E.F. Coddが1970年の論文で定義した概念
  • リレーションシップ（Relationship）:
    • 2つのリレーション間の関連・結びつきのこと
    • 「2人のfriendの間にfriendshipがあるように2つのrelationの間にrelationshipがある」という類比で説明される

■ 3. 誤用が生じる原因

  • 翻訳上の問題:
    • 「リレーショナルモデル」を日本語で「関係モデル」と訳すとRelationとRelationshipのどちらを指すかが不明瞭になる
  • 日本語語彙の不足:
    • 両概念を自然に区別できる日本語の語彙が存在しない
  • ソフトウェアの誤用:
    • 旧バージョンのMicrosoft Accessがテーブル間の関連を「リレーション」と表記していた（正しくは「リレーションシップ」）

■ 4. 正確な用語使用の重要性

  • 個々の誤用は些細に見えることがあるがCoddの基礎的な研究を尊重し誤りを避けることが技術的議論の精度向上につながる

(2026/03/12)

Goが15年でバックエンドの標準になるまで。偉大なる“退屈さ”が世界の開発文化を変えた理由

要約:

■ 1. Goとの出会いと初期評価の変遷

  • 松木氏がGoを意識し始めたのはGo 1.0リリース直後の2012年頃
  • きっかけは面白法人カヤック在籍時に同僚のtypester氏（村瀬大輔氏）が「次はGoが来る」と推薦したこと
  • 当時カヤックではPerlからの移行先言語を模索していた
  • 最初の印象は「かったるい言語」であり動的型付け言語に慣れた身には型定義や制約が面倒に感じた
  • 評価が一変したのははてな転職後のサーバー監視サービス「Mackerel」開発への参加
  • Mackerelのエージェントはメモリ消費を最小限に抑える必要があり数メガバイト程度で動作するGoが採用された
  • コンパイルでシングルバイナリが出力されるため依存ライブラリを気にせずユーザー環境への配布が容易
  • この「用途に対する圧倒的な適合性」を目の当たりにしてGoへの評価が一変した

■ 2. Goの開発者体験と静的型付け言語としての強み

  • 言語標準でフォーマッターや依存管理などツールチェーンが整備されており環境構築に時間を割かず開発に集中できる
  • 開発規模が大きくなるほど型の存在が安心感につながる
  • 「ビルドが通ればある程度正しく動く」という信頼感が長期運用において重要
  • JavaやScalaと比較した最大の強みはビルド速度とランタイムの軽量さ
  • JVMベースの言語はコンテナ技術やマイクロサービス化の流れで起動フットプリントが問題になる
  • Goは静的型付け言語でありながらビルドが一瞬で終わり「書いては動かす」サイクルを高速に回せる
  • このリズムはスクリプト言語に近く動的言語出身のエンジニアがストレスなく移行できる要因となった

■ 3. インフラ領域からWebバックエンドへの普及拡大

  • 初期のGoは並行処理を活かしたマイクロサービスやシステム記述言語用途で採用されインフラ領域から浸透した
  • HashiCorpがRubyからGoへシフトしConsulやTerraformといった重要インフラツールをGoで開発した
  • DockerとKubernetesがGoで開発されたことがエンジニアコミュニティに決定的なインパクトを与えた
  • Webアプリケーションバックエンド開発のメインストリームへの普及は松木氏本人にとっても意外だった
  • 当初は「コアとなる複雑なシステムは表現力の高い言語で構築しGoは周辺ツールに使う」構成が最適と考えていた
  • 現在はバックエンドのすべてをGoで開発する企業も珍しくなくこの適用範囲の広がりは想定以上

■ 4. Go普及の背景にある言語設計の優位性

  • 10年前はGoとScalaが新進気鋭のサーバーサイド言語として二強の時代があった
  • Scalaは表現力が高い一方で高度な抽象化が難解さにもつながりチーム全体での保守が多くの組織にとって予想以上に困難だった
  • 2010年代前半のWeb業界には静的型付け言語への回帰を求める渇望があった
  • 求められていたのは「文法がシンプルでコンパイルが速く安全に書ける型付き言語」であった
  • Goは機能が少ない分誰が書いても似たようなコードになりやすく学習コストが低い
  • この乗り換えやすさと実用的な型安全性のバランスがWeb開発現場の課題にフィットした

■ 5. 「Less is More」の設計哲学

  • Goの設計思想の根底には「一つの目的を達成する方法は一つ（または少数）に限定されるべき」という考え方がある
  • 複数の構文やライブラリが存在するとコードスタイルがバラバラになり読み手の負担が増す
  • ライブラリ設計においても機能のオーバーラップを避け単一責任の原則が徹底されている
  • 「全部入りの巨大フレームワーク」よりも小さな道具を組み合わせる文化
  • これはUNIX哲学そのものであり設計者のKen ThompsonやRob Pikeが培ってきた「シンプルさを保つ規律」が反映されている

■ 6. エラーハンドリングの設計

  • Goは例外処理機構を持たず戻り値としてエラーを返す仕様
  • 最も画期的な点は関数が多値（複数の値）を返せる設計
  • C言語では関数は一つの値しか返せず処理結果とエラー情報を扱うためにポインタ渡しが必要だった
  • Goでは「戻り値の最後にエラー型を置く」というシンプルなルールで解決した
  • Result型やパターンマッチといった関数型言語的エッセンスの導入には慎重な判断が下された
  • それらの導入は表現力を上げる一方で言語仕様の複雑化・コンパイル時間の肥大化・学習コスト増大のリスクがある
  • 誰が書いても「退屈でつまらないコード」になるよう強制することでチーム開発の可読性と高速ビルドを守っている

■ 7. 長期運用における優位性とAI時代との親和性

  • Goの最大の利点は「ゆっくりと着実に進化している」点
  • 標準ライブラリや言語機能への追加は厳選されており非互換変更によるコード書き直しが発生しない
  • 5年間Goに触れていなかったエンジニアでも現在のGoコードを違和感なく読み書きできる
  • Googleという巨大企業が自社開発でGoを使い続けていることがOSSとしての持続可能性を保証する
  • Goは「生成AI時代に最も親和性が高い言語」の一つと松木氏は考えている
  • gofmtによるコードフォーマットの統一を初期から強制した結果AIが出力するGoコードは品質が安定しブレが少ない
  • Goが大切にしてきた可読性はAIが書いたコードを人間がレビューする際にも役立つ
  • 学習コストと運用負担の低さおよびAIとの高い親和性からエンジニアの道具箱に入れる価値がある言語である

(2026/03/11)

なぜ、SOLIDの単一責務の原則(SRP)は理解しにくいのか？

(2026/03/11)

AI拡張開発と組織の再考

(2026/03/10)

AI生成によるchardet再実装におけるライセンス変更の是非に関するメモ

要約:

■ 1. 本稿の概要と分析範囲

  • AIによって既存ソフトウェアとほぼ同じ機能を再実装しライセンスを変更する「ライセンスウォッシュ」とも評され得る行為の是非が本稿の主題
  • 対象事案はPythonの文字エンコーディング検出ライブラリchardetにおいて2026年3月に起きたAI支援による再実装とGNU LGPLからMITライセンスへの変更
  • 分析の対象はリリースノート・再実装プラン・イシューその他の公開ファイルの外形に限定しソースコード全体の実質的類似性の精密比較は行わない
  • 本稿は確定的な法的結論ではなく公開資料から見える範囲での法的・実務的な整理である

■ 2. chardetで実際に起きたこと

  • chardetはPythonの文字エンコーディング検出ライブラリであり2006年の1.0がMozilla系の実装をPython 2に移植したものであり原作者はMark Pilgrim（以下Mark）
  • 2026年2月22日に6.0.0がリリースされ依然としてGNU LGPLが適用されていた
  • 2026年3月2日に7.0.0がリリースされ「Ground-up MIT-licensed rewrite of chardet. Same package name same public API」と説明されGNU LGPLからMITライセンスへ切り替えられた
  • 2026年3月4日には7.0.1が通常のバグ修正・改善リリースとして公開され7.x系は継続的な開発として位置づけられている
  • 現在のメンテナーDan Blanchard（以下Dan）の主張は「同じpublic APIを持つ別実装を一から作ったのだからMITライセンスとして扱える」というもの
  • 2026年3月4日にMarkがイシューを立て自らをchardetの原作者と名乗ったうえでrelicenseする権利はなくGNU LGPLへの明示的違反であると主張した
    • Markはこれをclean room implementationではないと述べ元のライセンスへ戻すよう求めた
    • イシューは2026年3月9日時点でOpenのままでありAssigneeもMilestoneも付いていない

■ 3. 問題点の整理

  • 本件の中心的論点は著作権侵害であり7.0.0が旧chardetのderivative work（派生物）に該当するかが核心的争点
  • 著作権侵害以外にLGPLを契約と捉えた場合の契約違反やコモンロー上の商標権・不正競争の観点での主張も考え得る
  • 7.0.0が旧著作物の複製でも翻案でもない独立実装であればLGPLの拘束をどこまで及ぼせるかは難しくなる
  • 複製または翻案が認められればLGPLは一気に重く効いてくる

■ 4. 依拠性から見た評価

  • 著作権侵害成立の検討にあたっては日本法では「依拠性」と「類似性」米国法では「access copying substantial similarity protectable expression」が核心的判断軸となる
  • 米国法では17 U.S.C. §102(b)によりソフトウェアのアイデア・手順・プロセス・システム・操作方法そのものは保護対象外であり保護されるのは表現のみ
  • 依拠性についてはMark側の主張がかなり筋が通っている:
    • rewrite planのTask 3においてchardet 6.0.0のcharsets.pyをauthoritative reference（権威ある参照）として使う指示が明記されている
    • scripts/utils.pyではtests/dataを旧プロジェクトのtest-dataリポジトリからshallow cloneする仕組みが採用されている
    • test-dataリポジトリのREADMEにはライセンスの問題が発生する可能性を認識した記述があり再実装側がライセンス問題を意識していたことが示される
  • Dan自身は「古いソースツリーにアクセスできない空のリポジトリから作業を開始しClaudeにはLGPL/GPLライセンスのコードをベースに一切作業を行わないよう指示した」と述べているがrewrite plan側で旧版を参照している以上依拠がないとは言い難い
  • AIのトレーニングデータとして旧chardetが含まれていた可能性があり慶應大学の奥邨教授が指摘する「二段の依拠」という観点からもクリーンルーム実装が成り立たないという考え方がある
  • 公開資料だけでも旧プロジェクトへの接触と参照は確認でき強い意味でのクリーンルーム実装と呼ぶことは困難

■ 5. 類似性から見た評価

  • 米国法における著作権侵害判断では保護される表現の取り込みが必要であり単にプログラムの論理構造や機能が似ているだけでは侵害とはならない
  • Computer Associates v. AltaiのAFCテスト（抽象化・濾過・比較テスト）によれば保護されない要素を先に除いた上で類似性を判断する
  • rewrite planで参照が指示された旧6.0.0のcharsets.pyはCharsetデータクラスにname is_multi_byte encoding_era language_filterを持つメタデータ表であり新7.0.0のregistry.pyはEncodingInfoにera is_multibyte python_codec languagesなどを持つより拡張された構造になっている
  • charsets.pyの多くはメタデータの表であり事実に近い性質のものであるが選択・分類・割当に創造性が認められれば類似性判断が成立する余地はある
  • Dan側はJPlagを使用した分析により7.0.0と過去バージョンの最大類似度は1.29%であり他バージョン間の43%から93%と比較して定量的には類似性が低いと報告している
  • コード全体の類似性評価では独立実装と受け取ることが可能であるが著作権上はごく一部の保護される表現の取り込みでも侵害が成立し得る点に留意が必要
  • 保護される表現の取り込みの程度については公開資料のみでの判断には限界があり法的な観点からの専門的なコード比較分析が必要

■ 6. 結論 - 法的評価

  • 公開資料からの暫定評価として本件は「独立実装と断言するには苦しいが直ちに著作権侵害と断定するには足りない」事案
  • Mark側に有利な材料:
    • rewrite planで旧charsets.pyをauthoritative referenceとして使う指示があることはクリーンルーム実装の主張を弱める
    • 少なくともaccessおよび依拠性に近い事情についてはMark側の主張の方が説得力がある
  • Dan側の反論として有効な材料:
    • charsets.pyは6.0.0系リリースにてDanが新規作成・整備したファイルでありDan自身の著作物と主張し得る
    • 旧版参照は機能互換やデータ整合のための参照に過ぎず保護される表現の取り込みを意味しないという反論が可能
    • 再実装において保護される表現は含まれていないという反論もできる
  • ただしcharsets.pyが旧著作物に依拠したderivative workであればDanに認められるのは新規付加部分に限られ既存権利者の権利を消すことはできない
  • 仮に著作権侵害が全面否定されてもLGPL 2.1の受諾を前提とした契約論での争点も残り得る
    • Artifex v. HancomやSFC v. VizioなどGPL/LGPLをめぐる法的争点事例が参照される
  • 明確に言えることは今回の再実装は強い意味でのクリーンルーム実装とは言い難いということであり法的確定判断には専門的分析が必要

■ 7. 結論 - コミュニティ運営および倫理面の評価

  • 同じリポジトリ名・頒布経路を維持できることと旧プロジェクトの実装全体を自己の判断だけで再ライセンスできることは別問題
  • 仮に法廷で著作権侵害が認められなかった場合でも同じ機能を持つ全く異なるソフトウェアを同名の同一プロジェクトのアップデートとして扱うことの妥当性が自動的に正当化されるわけではない
  • Markの異議表明後も7.0.1が継続リリースされており現時点ではMarkの主張が受け入れられないまま新系統がプロジェクトの後継を名乗って走っている状態
  • AIによる全面的な再実装を行い内部アーキテクチャも完全に変えライセンスまでコピーレフトからパーミッシブへ変更するのであれば別のツールとしてリリースすべきであった
  • どうしても同じプロジェクト名を維持するなら少なくとも元のライセンスへ戻す方向が混乱を最小化する選択であった

■ 8. AI再実装に関する今後の論点と提言

  • AIによる再実装はこれから激増すると考えられるが既存のプロジェクトを同名のままアップデートとしてリリースすることの適否はその事実とは別問題
  • コピーレフトからパーミッシブへの変更が歓迎される側面があるとしてもオープンソースから非オープンソースへの再実装も同じ手法で可能になることへの認識が必要
  • AIによる全面的な再実装は原則として別ツールとして扱うべきであり人間による継続的開発物とAIによる別実装を同じプロジェクトの同じリリース系統の下で混ぜるべきではない
  • AIによる全面的な再実装を既存プロジェクトの後継としてリリースする場合には以下の情報を公開時点で明示する説明責任がある:
    • コードの来歴
    • 参照した旧資産の範囲
    • ライセンス変更の根拠
    • 旧権利者との関係
    • 互換性と非互換性の範囲

(2026/03/09)

AIコーディングの原則

要約:

■ 1. AIコーディングツールとAI Slopの問題

  • AIコーディングツールは急速に進歩し利便性が高い
  • OSS界隈ではAI Slop（AIが生成する低品質なコードやテキスト）が問題となっている
  • チームではSlopが人数分だけ増幅され レビューとリワークがチーム全体に波及する
  • AIコーディングのメリットを上回る生産性の低下を招く

■ 2. コードの責任と所有権

  • LLMがコードを生成しても コミットに名前が刻まれるのは人間である
  • 深夜の障害対応で呼び出されるのも人間であり「AIが書いたから」は通用しない
  • AIは7〜8割のコードを書けるがプロダクション品質に仕上げるのは人間の仕事である

■ 3. コンテキストの共有とドキュメントの役割変化

  • 良いコードには設計の選択理由や棄却した選択肢のコンテキスト共有が必要である
  • 従来のコンテキスト共有:
    • 隣のシニアエンジニアとの会話やコードレビューで行われていた
    • ドキュメントは書かれても読まれないことが多くコンテキストの本体は人の頭の中にあった
  • AIへのコンテキスト提供の要件:
    • AIには雑談ができないためコンテキストを言語化して書くことが必須である
    • AIが必要とするのはコードそのものには書けない設計の選択理由・制約・前提である
    • コンテキストウィンドウの制限があるためドキュメントは適切なサイズに整理する必要がある
    • 長すぎるドキュメントが読みづらいのは人間も同じであり簡潔さの要件は両者に共通する
  • AIの登場によってドキュメントはオーバーヘッドではなく開発のスループットを決める重要な要素となった

■ 4. チームで守るべき原則

  • 判断は人間がする:
    • AIの提案をそのままコミットしない
    • オンコールで呼ばれたとき1000行の変更を説明できる状態を保つ
    • コードの品質は時に低くセキュリティ境界（認証・認可・入力検証）はAIが見落としやすい
  • 人間が読めるドキュメントを優先して書く:
    • 設計意図・制約・決定理由を人間の言葉で記す
    • ドキュメントは人とAIが共有するコンテキストである
    • AIだけが読む専用ファイル（CLAUDE.mdなど）はあくまで補助であり本体ではない
    • 人間向けのドキュメントを充実させればAIへの指示は自然と最小化される
  • AIへの指示は「発見できないことだけ」書く:
    • コードを読めばわかることを繰り返す必要はない
    • AIが繰り返し失敗したこと・プロジェクト固有の制約・ツール選択の理由など「コードベースの外にある知識」だけを補助的に書く

■ 5. まとめ

  • コードの責任を取るのは人間である
  • 判断は自分で下しコンテキストを言語化し人間が読めるドキュメントに投資する
  • AI専用の指示はいずれ陳腐化するが人間のために書いたドキュメントの価値は残る

■ 6. 参照・エビデンス

  • 責任の原則:
    • Simon Willison（2025-12-18）: コンピュータはアカウンタビリティを持てないためhuman in the loopとしての判断が人間の仕事である
    • Matteo Collina（Node.js TSC Chair・Fastify作者 2026-01-18）: コードを出荷するとき名前がついており AIで速く動けても自分の判断を外注することはできない
    • Birgitta Böckeler（Thoughtworks Distinguished Engineer 2025-07-09）: 深夜にオンコールで呼ばれるのは人間であり LLMはコンパイラではなく推論器であり使用は常にリスクアセスメントである
  • AGENTS.md・コンテキストファイルの実証研究:
    • Gloaguen et al.（ETH Zurich 2026-02-12）: 138リポジトリ・5694件のPRを対象とした実証研究。LLM生成のコンテキストファイルはエージェント性能を2〜3%低下させ 開発者が書いても4%改善に留まる一方コストは20%以上増加。不要な要件がタスクを困難にするため人間が書くファイルは最小限の要件のみ記述すべきと結論づけた
    • Vercel Engineering（2026-01）: 発見できない知識だけを書いた圧縮インデックスが100%のpass rateを達成
    • Upsun Developer Center（2026-02）: CLAUDE.mdは.gitignoreのように扱い エッジケースを発見するたびに育て不要になれば刈り込む
  • コミュニティの議論:
    • Hacker News（Evaluating AGENTS.md 2026 76ポイント・36コメント）: 論文著者のnielstron本人がスレッドに参加。モデルがセッション開始時にREADMEとCONTRIBUTING.mdを自動でインジェストすべきという提案に著者が賛同。ユーザーpamelafoxがエージェントが失敗したときだけAGENTS.mdに追加し変更を戻して再実行して改善を確認するという実践的な運用法を共有した
    • Hacker News（Compressed Agents.md 2026 72ポイント・34コメント）: SkillsよりAGENTS.mdが有効な理由はエージェントが取得するかどうかを判断する必要のない確実な文脈提供にあるという議論が展開された
  • ドキュメント・仕様駆動開発:
    • GitHub Blog（2025-11）: 2500以上のリポジトリ分析。成功するコンテキストファイルの共通点は「具体的なコマンド・明確な境界・コードで示すスタイル例」である
    • Addy Osmani（Google Chrome 2026-01）: 仕様はwhatとwhyに集中すべきであり 巨大な仕様を一度に渡してもコンテキストウィンドウとattention budgetが邪魔をする
    • Thoughtworks（2025-12）: 仕様はGateではなくエージェントがリアルタイムで消費し行動するための会話であり 従来のデザインドキュメントと異なり仕様が実際に使われるようになった点が決定的な違いである

(2026/03/09)

まだAIコードをレビューするか、しないかで言い争ってるの？

要約:

■ 1. 結論

  • AIが生成したコードのレビューを継続するかを議論する段階はすでに終わった
  • 品質を維持したままコードレビューを大幅に削減し続けるよう開発プロセス全体を改善する必要がある
  • レビューを軽量化し他の手段に置き換えた組織は品質自体も高くなっていく可能性が高い
  • いち早くその状態に到達した組織が大きく飛躍し遅れた組織は淘汰されていく

■ 2. コードレビュー削減が必要な3つの根拠

  • 今後コードレビュワーは育てられない:
    • コードレビュワーの育成方法としてコードを書いて経験を積む以外の道は確立されていない
    • 現行レビュワーと同程度にコードを書く時間を今後確保することはほぼ不可能
    • 現在のレビュワーと同程度のコードレビュー能力を持つ人材を今後育てることは難しい
  • AIはレビュワーを物量で圧倒する:
    • 生成AIの速度は現時点で限界ではなく今後さらに高速化することが確実
    • 現時点でもAIが生成するコードの物量に人間のレビューは押され気味であり今後さらに生成量が増加する
    • 人間中心のレビューを続けるにはAIによる生成量にブレーキをかける必要がある
  • 人間中心のレビューを続ける組織は淘汰される:
    • レビューをしない・もしくは軽量なレビューで同等の品質を保てる組織が作れた場合その組織はレビューを続ける組織を淘汰する
    • レビュー軽量化による品質維持の実現は十分に可能という手ごたえがある

■ 3. コードレビュー削減に必要な3つの要素

  • 高品質なコードを生成できるコンテキストを開発・維持する開発プロセス:
    • AIが高品質なコードを生成できる状態を作ることがレビュー軽量化の大前提
    • 品質の高い入力コンテキストが重要な要素の一つ
    • サービスの性質によってアプローチは異なり単一の形に収束することはない
    • 比較的高い頻度で改善が求められるサービスと社会インフラに近いサービスとではまったく異なるアプローチになる
    • ビジネス要件の可視化からソフトウェアの手前までを文書化しその文書化自体もAIが支援する形が想定される
    • 生成AIの文書化能力はすでに多くの人間の能力を超えており旧来より高いレベルで均質な文書化をすでに実現できている
  • 高品質なコードを生成できるハーネス:
    • 同じコンテキストを与えてもAIが生成するコードの品質はハーネスの品質に大きく依存する
    • ハーネスにはClaude CodeやCodex CLIのような汎用ツールだけでなくプロダクト固有のアーキテクチャやアプリケーションフレームワークも含まれる
    • lintや静的解析ツールもコード品質を保証するためのハーネスの一部
    • 高品質なローコードプラットフォームがハーネス兼サンドボックスとして機能する可能性がある
  • コードより高いレイヤーの評価基準で品質を評価・保証するプロセス:
    • コードレビューのような低レイヤーの評価からより高いレイヤーの評価基準への移行が重要
    • コンテキスト自体をインプットとしてコード生成とは別プロセスで評価システム自体もAIが生成することが想定される
    • 言語化された領域の評価はすぐに人よりAIの方が高い精度でできるようになると予測される
    • 最終的に人が評価するのは要求もしくは最上位要件への適合度のみになる可能性があり言語化されていない領域が中心になる可能性もある
    • lintや静的解析のような自動化されたコード品質保証プロセスによって人がレビューしていた部分を置き換えていくことが重要
    • レビューという考え方自体がプロセスから消えるわけではなく自動化された形で継続する

(2026/03/09)

マネージャー版 "提案のレベル" を上げる

要約:

■ 1. 発表の概要

  • KyashのVPoE @konifarが2026年EMConf JPで発表したセッション
  • マネージャーに役割が変わった際に提案レベルを上げるための方法を解説
  • メンバーから管理職への転換後も提案レベル自体はリセットされず継続して高められる

■ 2. 提案のレベル定義

  • レベル0「どうすればいいですか」:
    • 提案ではなく指摘で止まっている状態
    • 気づきはあるが解決策の選択肢を出せていない
  • レベル1「どれにしましょうか」:
    • 複数の案を整理して提示できる状態
    • 実施スケジュールやリカバリプランなどPros/Consをまとめて伝える
  • レベル2「自分はこれがいいと思います」:
    • 選択肢の提示に加えて自分の意見と判断根拠を添えられる状態
    • 評価軸を設け意思決定に必要な材料を集め思想をのせて伝える
  • レベル3「これでいいですか」:
    • 複数の立場の意見を考慮したうえで意思決定を促している状態
    • 意思決定者が「いいと思う」「じゃあそれで」と短いやりとりで決定できる

■ 3. マネージャーにおける提案の難しさの要因

  • 関わる範囲の広がり:
    • 横は他部署縦は経営と関わる範囲が拡大し考慮すべき変数が増加
    • 「何をどこまで考えて提案すればいいかわからない」「どこで誰と話せばいいかわからない」状態になりやすい
  • 考える時間軸の広がり:
    • 1年以上先を想像して正解に近づけ続けていく仕事に変わる
    • 「そもそも何を提案すればいいかわからない」「不確実すぎて自信が持てない」状態になりやすい
  • 取りうる選択肢の広がり:
    • 正社員や業務委託の採用を含め組織体制や予算も調整しうるレバーになる
    • 「どこまで選択肢を広げて考えるべきかわからない」「どこまで踏み込んで考えていいかわからない」状態になりやすい

■ 4. 適応の方針：理解と覚悟

  • 役割と意思決定プロセスの理解:
    • 自チームと他チームの役割目標価値観を把握する
    • 物事を決め遂行されていくプロセスを理解する
  • 決めてやりきる覚悟:
    • 正解に近づき続けるマインドセットを持つ
    • 宣言と報告軌道修正のリズムを確立する

■ 5. 組織理解のための4つのTips

  • 組織図:
    • 組織図と職務権限規程を知ることでどこが何の役割を担っているかが見えてくる
    • 各チームのマネージャーへの1on1申し込みや食事などで直接把握するのが効率的
  • 目標:
    • 事業計画や各チームの目標を知ることで価値観や考慮すべきことが見えてくる
    • 事業計画を経営や上長にわかるまで聞き隣接チームの目標をマネージャーに確認する
  • 会議体:
    • 協議と意思決定の会議体の設計を知ることでどこで誰と何を話すべきかが見えてくる
    • 他マネージャーのカレンダー確認やアジェンダのAIサマリなどで把握する
  • 予算:
    • 予算の全体感と決定プロセスを知ることでコントロールできる選択肢が見えてくる
    • 予算の考え方や決定プロセスを経理チームや経営メンバーに直接聞く

■ 6. 理解不足による失敗事例

  • 失敗例①（2022年頃）組織状態を見て経営への提言:
    • 当時はエンジニア含むプロダクト開発組織の立て直しが急務で経営のコミットメントが必須だと考えていた
    • 当時の経営目標とのアラインや意思決定プロセスを理解しておらずただ意見をぶつけただけの提案レベル0の状態だった
    • 今なら経営目標を確認してそこに到達するための建付けで整理し意思決定前の会議体で起案して組織としての意思決定をリードする
  • 失敗例②（2023年頃）インフラコストの削減:
    • 会社年間予算における自チームの固定費変動費を全く意識していなかった
    • 2023年に250万円/月のコスト削減を実施したが予算全体を理解できていなかったためもっと早く実施できた可能性がある
    • 意思決定プロセスも理解できておらず今は定例ミーティングを活用してこのような提案を気軽に上げられる環境にある
  • 失敗例③（2025年頃）AIコーディングエージェントの予算確保:
    • 予算を理解し意識するようになったことで本当に意義のある予算のかけ方を考えすぎた
    • やってみないとわからないものに対して過度に費用対効果の説明準備をしていた
    • 経営チームや経理は「予算は少なくすればいいものではない」「お試し期間と振り返りを前提に別途継続判断しましょう」とすぐに前進させてくれた
    • 提案レベル2の準備に過剰な時間をかけてしまった原因は予算の意思決定プロセスへの理解不足

■ 7. マインドセットの変え方

  • いきなり高い提案レベルを目指さない:
    • これまでより不確実で正解のない課題に取り組んでいる事実を認識する
    • 範囲時間軸選択肢が広がっているため一人ですべて考慮した提案を出せないのは当然
    • レベル0から3のどこまで考えて話を持っていくかの引き出しを増やすことが大事
  • 振り返りと軌道修正を前提とした提案をする:
    • 正解がない提案と意思決定が増えるため振り返りと軌道修正のプロセスが重要
    • 期間と振り返りタイミングやレポーティング方法もセットで提案することで提案レベル2以上がしやすくなる
    • 軌道修正の話を伝えないと「後戻りのできない未来永劫にわたる意思決定」として議論されてしまう危険性がある

■ 8. 提案レベルを上げる実践方法

  • 一人でいきなり高いレベルを目指さず巻き込んで意思決定するためにレベルを使いわける
  • 範囲時間軸選択肢の広がりによる変化を自覚する
  • 組織図目標会議体予算から組織の役割と意思決定プロセスを把握する
  • 最初に持っていく提案レベルを状況に応じて使いわける
  • 一発の提案でスパッと決まらない課題が多いため自己体験と他者の提案を観察する疑似体験を重ねていく

(2026/03/08)

ソフトウェアアーキテクトのための意思決定術

(2026/03/07)

サービス統合で行った 選択と意思決定

(2026/03/07)

作るべきものと向き合う - ecspresso 8年間の開発史から学ぶ技術選定

(2026/03/07)

失敗できる意思決定とソフトウェアとの正しい歩き方_-_変化と向き合う選択肢

要約:

■ 1. 登壇者プロフィール

  • 氏名: 曽根 壮大（41歳）
  • 所属:
    • Have Fun Tech LLC 代表社員
    • 株式会社リンケージ CTO 兼 COO
  • 著書: 「失敗から学ぶ RDBの正しい歩き方」
  • 経歴: 警察官 → 派遣社員 → 社内SE → インフラエンジニア → Webエンジニア → フルスタックエンジニア → CTO（第1期）→ Customer Reliability Engineer → CTO（第2期）→ 独立 → CTO（第3期）→ COO & CTO

■ 2. 失敗できる意思決定

  • 意思決定の本質:
    • 意思決定に正解はなく 自分で正解にするしかない
    • 失敗と成功は二項対立ではなく地続きの世界である
    • 正解に近づく仮説を検証して最終的にゴールにたどり着くことが重要
  • 意思決定の難しさ:
    • ビジネスモデル・要件・法律・技術的制約・組織の状態はすべて変化する
    • 継続した成長が求められる中でチャンスは何度も与えられるわけではない
    • 致命傷だけは避ける必要がある
  • 判断と決断の違い:
    • 判断: 情報を集めれば理屈で答えが出せる
    • 決断: 情報が揃わない中で答えを出さなければならない
    • リーダーがやらなければならないのは決断である
  • 標準化による仕組み化:
    • インプット・スループット・アウトプットの各ステップを標準化することで決断を判断に変えられる
    • 具体的には作業のマニュアル化や受け入れ基準のガイドライン策定が該当する
  • 失敗できる意思決定のコツ:
    • 失敗できる状態にすることで決断が可能になる
    • 素早くアクションして失敗のフィードバックを受け取ることで新しい決断ができる
  • 決断のステップ:
    • 決断するために必要な条件を整理する
    • 決断が難しい場合は素早く始め小さく失敗できるように考える
    • 失敗が難しい場合は社内外も含めて多くの知見を集める
    • それでも難しい場合は結論をできるだけ先伸ばす
  • 仮説検証で重要な3要素:
    • 失敗しても致命傷にならない: やり直せる・代替がある・失うリスクに対して許容できる（ビッグバンリプレースはリスクが高く段階的な置き換えやカナリアリリースを検討する）
    • 失敗から学ぶことができる: 仮説が観測可能である・結果に対して客観的に分析・判断が可能（「流行っている」は仮説として弱くサンクコストが高くなると失敗を認めづらくなる）
    • すぐ試せる: 結果が素早く出る・実行までの投資リソースが少ない・実行後の影響範囲が明確（大きな変化は合意形成に時間がかかり結果が出るまでも時間がかかる）
  • 後に変更可能な技術選定の例:
    • コンテナ: 実行環境の依存をコンテナで分離することで実行環境を変更できる
    • REST: インターフェースの先はバックエンドの分割やフロントの差し替えが可能
    • イミュータブルなデータとCQRSアーキテクチャ: 更新と参照の責務を分けつつ変化に追従できる
    • 認証と認可の分離: SSOでまとめることで社内システムのIdPを活用できる

■ 3. ゆっくり考えて素早く実行する

  • 基本原則:
    • 失敗したプロジェクトの共通点は「すばやく考えゆっくり動く」こと（BIG THINGS引用）
    • 成功したプロジェクトはいずれも「ゆっくり考えすばやく動く」を徹底している
    • プロジェクト期間が長くなるほどブラックスワンが飛び込んでくるリスクが増大する
  • 計画と実行の対比:
    • 素早く考えてゆっくり実行: 計画（短）→ 実行（長）= 外部起因の影響を受けやすい
    • ゆっくり考えて素早く実行: 計画（長）→ 実行（短）= 外部起因の影響が少ない
    • 実行フェーズでのブラックスワン発生時の見直しはハイコストだが計画段階での見直しはローコスト
  • ゆっくり考えるとは:
    • 実行前の計画段階で仮説検証を行いリスクを事前に排除すること
    • 参照クラス予測法の活用: 類似事例を参照し複数のデータを元に予測し悲観的に考える（ファットテール分布を想定）
    • 反証に耐えられない仮説は基本的にリスクが高い
    • ロードマップを分解して大きなリスクを防ぎ小さな成果の積み重ねでゴールになる計画を立てる
  • 素早く実行するとは:
    • 最初から想定通りに行くわけではなくフィードバックを受け取ったら素早く変化に合わせる
    • 「初めて」を極力減らす: 技術の研究・検証とプロダクト開発を同時に行わず別々のプロジェクトにする
    • 小さな成果物はコントロールしやすい（WBSは作業分解のTODOリストではなく小さな成果物の定義）
    • アジャイルはハンドルであってアクセルではない（素早くフィードバックを獲得して変化に対応する）
  • 学習ループ:
    • シングルループ: 実行結果をもとに行動を変える
    • ダブルループ: 結果から前提を変えて根本から変更する
  • 素早く実行するために必要な技術:
    • テスト・オブザーバビリティ・CI/CDはコアコンピタンスである
    • マイクロサービスは小さく実行するためのhowの一つに過ぎずモノリスなシステムでも交換可能であれば良い

■ 4. Simple is Beautiful

  • SimpleとEasyの違い:
    • 「難しい」には「理解できないから難しい」（知識を積めば解決できる）と「構造に無理があるから難しい」（根本的な改善が必要）の2種類がある
    • この違いを理解しないとEasyとSimpleの違いが見抜けない
    • SimpleとEasyは両立する
  • Small is beautiful（UNIX哲学）:
    • 小さなプログラムはわかりやすい
    • 小さなプログラムは保守しやすい
    • 小さなプログラムはシステムリソースに優しい
    • 小さなプログラムは他のツールと組み合わせやすい
  • シンプルであることの利点:
    • 小さくシンプルな方が仮説検証しやすい（変数は少ないほうが仮説検証しやすく原則はOne change at a time）
    • 最小構成のWBSがマイルストーンになる
    • 小さなリリースの積み重ねが大きなプロダクトになっていく
  • 意思決定との関係:
    • 意思決定の選択に悩んだら小さくてシンプルになる選択肢を選ぶ
    • ゆっくり考えることと意思決定できないことは違う
    • 仮説を意思決定して実行するために小さくシンプルになるまで考えること

■ 5. おわりに

  • 「ゆっくり考える」チェックリスト:
    • 5Wをしっかりと整理する（WhyとWhatが方向性を決める・ユーザー/業務の「困りごと」は具体的か・撤退条件は明確か）
    • リスクは何か
    • 先行事例は何と比較したか
    • データは反証に耐えることができるか
  • 確証バイアスへの注意:
    • 仮説を補強する情報ばかり集めると確証バイアスに陥り誤った意思決定につながる
    • WhyやWhatを検証するときは反証（falsification）を必ず考える
    • 例: Why「売上を伸ばす」What「新規顧客を増やす」に対する反証は「売上が伸びないのは顧客単価の低下が主因では？」「新規顧客は増えても解約が悪化していないか？」
  • 組織と個人の意思決定:
    • 組織は意思決定しない
    • 意思決定は人がする
    • 他人が決めないなら自分が決めるしかない
  • 本気の失敗の価値:
    • 本気の失敗をすることで失敗が好きになる
    • 昨日の自分に誇れる今日の自分になることが重要

(2026/03/07)

技術選定の不確実性に向き合うための アーキテクト思考

(2026/03/07)

看護長が退職され、アカウントの停止処理をしたら即日病棟から鬼電きて「システムが使えなく...

MEMO:

(2026/03/07)

ドメインサービスでrepositoryの実行は必要か？

MEMO:

(2026/03/07)

「不満と復讐心」勤務先に強制シャットダウンのプログラム仕込む、元IT会社員を逮捕　被害額は約2000万円

勤務先のファイルサーバーに強制的にシャットダウンさせるプログラムを組み込むなどしたとして、大阪府警サイバー犯罪捜査課は3月5日、偽計業務妨害容疑などで滋賀県長浜市の元IT会社社員の男（38）を逮捕したと発表した。容疑を認め「社長に対する不満と復讐（ふくしゅう）心からやった。社員のセキュリティ意識の低さを知らしめたかった」と供述しているという。

逮捕容疑は2025年8月、大阪市内のIT会社のファイルサーバに、ランサムウェアに感染したと誤信させる偽の警告画面を表示させたり、起動から3時間後に自動でシャットダウンするプログラムを組み込んだりして業務を妨害したとしている。

同課によると、男は当時、この会社のシステム担当者で、後に自主的に退職していた。会社は業務を停止して原因調査などを余儀なくされ、データ復旧の委託料などで少なくとも約2000万円の被害が生じたという。自身の業務用パソコンを使ったとみられ、府警が詳しい経緯を調べている。

MEMO:

(2026/03/06)

動的型付け言語はそろそろ淘汰されるべき

要約:

■ 1. 概要と著者の立場

  • 著者は22歳の高卒エンジニアであり「動的型付け言語が嫌い」と明言
  • Jupyter NotebookやGoogle Colabのようなセル単位実行環境では動的型付けにメリットがあると認める
  • 一般的なプロダクト開発においては動的型付けは「過去のもの」と主張

■ 2. 型システムの歴史的変遷

  • 1970〜1990年代（静的型付け期）:
    • C・Javaが代表言語
    • メモリ制約と実行速度重視の背景から静的型付けが必須
  • 2000〜2010年代（動的型付け期）:
    • Ruby・PHP・JavaScript・Pythonが代表言語
    • Web普及とアジャイル開発による開発速度重視で動的型付けが流行
  • 2010年代後半〜現在（漸進的型付け・静的回帰期）:
    • TypeScript・Go・Rustが代表言語
    • ツールの進化・システムの大規模化・保守性重視により静的型へ回帰

■ 3. 動的型付け言語が淘汰されるべき4つの理由

  • 保守性の限界:
    • 複数開発者による長期保守において型情報の欠如が深刻な技術的負債を生成
    • 結果として開発速度が低下する
  • ツールの進化による優位性の逆転:
    • 動的型付けの「手軽さ」という優位性はすでに失われている
    • コード補完: 動的型は推測ベースであるのに対し静的型は正確な型情報に基づく
    • リファクタリング: 動的型は手動確認が必要であるのに対し静的型は安全な自動化が可能
    • エラー検出: 動的型は実行時であるのに対し静的型はコンパイル時に検出可能
    • ドキュメント性: 動的型はコメント依存であるのに対し静的型は型が仕様書として機能する
  • AIとの相性:
    • AIコーディングアシスタントは型情報が豊富なほど精度が高まる
    • 厳密な型システムがAIによる自律的エラー検出を可能にする
    • 動的型付けではテストとデバッグの手作業が増加する
  • オブジェクト指向との相性:
    • 型注釈なき動的型付けでOOPを採用するとコードの複雑性が増加する
    • 型のないオブジェクトは単なる「データの塊」であり静的にプロパティを把握できない
    • 著者はOOPの本質を「構造を明確にすること」と定義する

■ 4. 動的型付けが再評価されうる将来シナリオ

  • AIが型定義不要な高度なコード生成能力を獲得する場合
  • インタプリタのオーバーヘッドが無視できるレベルにまで低下する場合
  • AIがリアルタイムでコードを生成する動的システムが主流化する場合

■ 5. 結論

  • 動的型付け言語の完全な消滅は予想しない
  • 中規模以上のプロダクト開発で型のない言語を新規採用する合理的理由はほぼ存在しないと主張
  • Python利用時は型ヒント（Type Hints）の積極的活用を推奨
  • 型はコードの仕様書であり保守性向上のための重要なドキュメントと位置づける

MEMO:

(2026/03/06)

Claude Code に向いているプログラミング言語

要約:

■ 1. 概要

  • Claude Codeを用いて13〜15言語で「簡易git」を実装し生成時間とコストを比較した実験的調査
  • 著者はYusuke Endoh（遠藤祐介）氏
  • 動的型付け言語が静的型付け言語と比較して速く低コストであるという結果が得られた

■ 2. 実験方法

  • 使用モデル:
    • Claude Opus 4.6 (high effort)
  • タスク構成:
    • v1: init / add / commit / log の基本4機能を実装
    • v2: status / diff / checkout / reset の追加4機能を実装
  • 試行回数:
    • 各言語20回 × 2タスク × 15言語 = 計600回実行
  • 対象言語:
    • 動的型付け: Python / Ruby / JavaScript / Perl / Lua
    • 型検査付き動的言語: Python+mypy / Ruby+Steep
    • 静的型付け: TypeScript / Go / Rust / C / Java
    • 関数型: Scheme / OCaml / Haskell

■ 3. 実験結果

  • 上位3言語（最速・最安）:
    • Ruby: 73.1秒 / $0.36
    • Python: 74.6秒 / $0.38
    • JavaScript: 81.1秒 / $0.39
  • 静的型付け言語の結果:
    • Go: $0.50
    • Java: $0.50
    • Rust: $0.54
    • 上位3言語と比較して1.4〜2.6倍の時間・コストを要した
    • 標準偏差も大きくばらつきが増加した
  • 最低パフォーマンス:
    • Ruby+Steep: 186.6秒 / $0.84 で最も遅く高コスト
  • テスト失敗数:
    • 600回中3回（Rust 2回 / Haskell 1回）のみ失敗
  • コード行数:
    • OCaml: 216行
    • Ruby: 219行
    • Haskell: 224行
    • 行数が少ない言語が必ずしも速く安いとは限らない（OCaml・Haskellは行数少ないが時間・コストは高め）

■ 4. 考察と結論

  • 速度・コスト差の要因:
    • 型システムの有無による制約の差
    • 言語ごとのコード簡潔性の差
    • 言語固有の複雑な仕様の影響
    • AIの学習データ量の差
  • 型システムとバグ防止:
    • 静的型付けでもテスト失敗は発生しており型システムが必ずしも失敗を防ぐわけではない
  • 著者の戦略提案:
    • 初期段階ではRuby / Python / JavaScriptの採用が向いている
    • 規模拡大時に静的型付け言語へ段階移行する戦略が現実的
    • AIエージェントは言語移植に強いため段階的な言語シフトが実現可能

(2026/03/06)

リモートワークからの出社回帰でも「出社させたがるのはマネージャーの怠慢」っていう極論をぶちあげる...

リモートワークからの出社回帰でも「出社させたがるのはマネージャーの怠慢」っていう極論をぶちあげるエンジニアの人が多かったです（日本ですごく代表的な「とあるエンジニア」も公式インタビューで語ってて頭いたくなりました）。

実態はといえば、シリコンバレーでも出社回帰の流れはあったし、MSRの研究でもリモワには多くの副作用があることが既に示されてたんですよね。この辺は出社回帰についていえば相当の合理性があるって話。

ただ、それより何より、管理職の人に対して「お前は普段仕事してない」と言わんばかりの言い草は単純に相手を見下していて、失礼きわまりないんですよね。

あのときに「管理職は仕事してない」と大合唱してた人たちは覚えてますが、本当に人としての礼節を欠く人たちだなって思いました。

@kmizu

MEMO:

(2026/03/05)

マイクロソフト・コーポレーションらによる独占禁止法違反被疑行為に関する審査の開始及び第三者からの...

公正取引委員会は、マイクロソフト・コーポレーション（法人番号8700150090374）、日本マイクロソフト株式会社（法人番号2010401092245）及びMicrosoft Ireland Operations Limited（以下、これら３社を併せて「マイクロソフト・コーポレーションら」という。）による独占禁止法違反被疑行為について審査を開始しました。この審査の一環として、本日、第三者からの情報・意見を募集することとしました。

本件情報・意見の募集は、当委員会が令和４年６月に公表した「デジタル化等社会経済の変化に対応した競争政策の積極的な推進に向けて　―アドボカシーとエンフォースメントの連携・強化―」に基づき、個別事件の審査の初期段階において実施するものです。

なお、当委員会が本件審査を開始したこと及び本件情報・意見募集を行うことは、独占禁止法に違反する行為が存在することを意味するものではありません。

(2026/03/05)

要求定義・仕様記述・設計・検証の手引き - 理論から学ぶ明確で統一された成果物定義

要約:

■ 1. 概要と目的

  • 背景: 要求・仕様・設計・テストケースの定義は人によって異なり統一されていない
  • 目的: 理論に裏付けられた統一的で明確な定義を提示し成果物の品質向上とコミュニケーションエラーの削減を図る
  • 目的: 成果物を機械的に処理可能にすることで少ない労力で目的を達成できるようにする
  • 理論的基盤: Jackson の要求の考え方・Hoare の CSP の安定失敗モデル・Meyer の DbC の定義を実務向けにアレンジしたもの

■ 2. 基礎概念

  • イベント:
    • 状態遷移の引き金となるもの
    • UIイベント・時間経過・通信・内部イベントτ の4種類がある
  • 内部イベント:
    • 状態機械の外から観測できず発生を制御できない特別なイベント
    • タイムアウトやシステム内の通信のような隠蔽されたイベントをτで表現する
  • 同期イベント:
    • 複数の状態機械が1つのイベントで同時に状態遷移する場合のイベント
    • τは同期イベントにはできない
    • 典型例はクライアントとサーバー間の通信・ユーザーとシステム間のUI操作
  • 並行合成:
    • 2つの状態機械と同期イベントの集合から1つの大きな状態機械を作る操作
    • 同期イベントの場合は両方の状態機械が同時に遷移できる場合のみ遷移可能
    • 非同期イベントの場合は一方のみが遷移できれば遷移可能
  • トレース:
    • 初期状態から連続的に遷移可能なイベントの列のうちτを取り除いたもの
    • 状態機械が出せるすべてのトレースを集めた集合をトレース集合という
  • 安定状態:
    • その状態からτで遷移できない状態
  • 失敗:
    • 安定状態に至るトレースとその安定状態で拒否されるイベントの集合の組
    • 状態機械のもつすべての失敗を集めた集合を失敗集合という

■ 3. 詳細化の連鎖

  • 上流の成果物から下流にいくにしたがって実装するシステムの姿は徐々に明らかになる
  • 機能要求では振る舞いの一部分だけ定義する
  • 仕様では機能要求で言及されていなかった部分の振る舞いを定義し実装に自由度を残す
  • 実装では許された自由度の範囲内で正常系・異常系の振る舞いを定義する
  • 詳細化の順序: 機能要求 → トップレベル仕様 → コンポーネント仕様 → コンポーネント実装
  • 非機能要求は遷移にかかる時間や使用性などの定量指標によって実装を制約する

■ 4. 機能要求

  • 定義: 失敗集合やトレース集合の満たすべき性質の定義
  • 悪い失敗:
    • 失敗集合に含まれていてはいけない失敗
    • あるトレースの後に実行できるイベントを定めることに相当する
    • 失敗集合に悪い失敗が含まれなければいいことを起こせることをいえる
  • 悪いトレース:
    • トレース集合に含まれていてはいけないトレース
    • 悪いトレースがトレース集合に含まれなければ悪いことが起こらないことをいえる
  • 機能要求の時点では言及されていないトレースや失敗がどうなっているかはわからない
  • 情報セキュリティの性質のうち安全性に関するものは非機能要求ではなく機能要求に含まれる

■ 5. 非機能要求

  • 定義: 量的な指標でしか記述できない性質（真偽で決定できない）の定義
  • 遷移にかかる時間・使用性などが該当する
  • 使用性の例: 主要なユーザーストーリーの達成に必要なUIイベント数や視線の動きの総量

■ 6. トップレベルの仕様

  • 定義: トレース集合と失敗集合の組（安定失敗方式）
  • 状態機械で構成することが一般的であり直接書き下すことは困難
  • 仕様の時点では実装に自由度を残す非決定性が残っている以外は振る舞いがわかる
  • 状態機械の記法:
    • 状態には状態変数を記述する
    • 遷移には「イベント [ガード] / 事後条件」の3つを記述する（ガードは真なら省略可）
  • ガード: 状態遷移できる条件でイベントと遷移前の状態変数を参照できる
  • 事後条件: 状態遷移前後の状態変数の関係を定義し遷移後の状態変数には ' をつける
  • 画面表示を伴う場合は各状態における画面の画像を返す関数（画面表示の条件）が加わる
  • シーケンス図による代替: QCDの面で状態機械が許容できない場合にシーケンス図で記述することがあるがトレース集合を誤解するリスクがある

■ 7. 機能要求と仕様の関係

  • トップレベル仕様の失敗集合とトレース集合は機能要求を満たさなければならない
  • 満たすべき条件1: 悪い失敗が失敗集合に含まれていない
  • 満たすべき条件2: 悪いトレースがトレース集合に含まれていない
  • 機能要求を満たす仕様は複数存在し最も優れたものを選ぶことが仕様記述の本質
  • 選択基準1: 非機能要求を高く満たすこと
  • 選択基準2: 実装コストの安い実装を採用できるように自由度が高いこと
  • 仕様インスペクション: 仕様のトレース集合に悪いトレースや悪い失敗が含まれないことを確認する

■ 8. 設計

  • 定義: トップレベルの仕様を人間の理解しやすい小さな状態機械（コンポーネント仕様）に分解する作業およびその成果物
  • 設計の時点でもトレースは実装に自由度を残してよいが仕様で許容された自由度を超えてはならない
  • コンポーネント仕様がトップレベル仕様を満たす条件:
    • 並行合成後のコンポーネント仕様のトレース集合 ⊆ 仕様のトレース集合
    • 並行合成後のコンポーネント仕様の失敗集合 ⊆ 仕様の失敗集合
  • 仕様を満たす設計は複数存在し将来にわたっての経済性が最も高いものを選ぶことが設計の本質

■ 9. API設計書

  • 定義: コンポーネント間の同期イベントの形式とリクエストとレスポンスの関係をシグネチャと事前条件と事後条件の組で定義したもの
  • コンポーネント仕様の部分的な別表現であり状態遷移図から機械的に導出できる
  • 事前条件: APIに規定の振る舞いを期待していい入力と通信前の状態の条件（満たされない場合の振る舞いは問われない）
  • 事後条件: リクエストとレスポンスの間の関係とAPI実行前後の状態の間の関係

■ 10. 実装

  • 定義: トップレベルの仕様またはコンポーネント仕様を満たす実行可能な状態機械またはそれを作成する作業
  • 仕様またはコンポーネント仕様の許した自由度の中で振る舞いを1つ選ぶ（疑似乱数生成器等による非決定性は許容）
  • コンポーネント実装がコンポーネント仕様を満たす条件:
    • コンポーネント実装のトレース集合 ⊆ コンポーネント仕様のトレース集合
    • コンポーネント実装の失敗集合 ⊆ コンポーネント仕様の失敗集合
  • 実装からは遷移にかかる時間や計算機資源にかかる負荷などの統計データを得られ非機能要求を満たさなければならない

■ 11. テストケースと検証

  • テストケースの定義: トレースと期待結果の組
  • 悪い失敗のサンプルに対する期待結果は受理
  • 悪いトレースのサンプルに対する期待結果は拒否
  • トレース集合や失敗集合は巨大でありすべての要素を調べきることはできない
  • 検証の本質: 与えられたリソースと時間の制約の中で最もリスクを下げられるサンプルを選ぶこと
  • 探索的テスト: 実装のトレース集合のサンプルがすべて仕様のトレース集合に入ることを確認するテスト（計画主導のテストケースとは対偶の関係）

■ 12. 成果物間の論理的保証

  • 機能要求をトップレベル仕様が満たしかつ並行合成したコンポーネント仕様がトップレベル仕様を満たせば並行合成したコンポーネント仕様は機能要求を満たす
  • 並行合成したコンポーネント仕様がトップレベル仕様を満たしかつすべてのコンポーネント実装がそれぞれのコンポーネント仕様を満たせば並行合成したコンポーネント実装もトップレベル仕様を満たす

(2026/03/04)

データテストフェーズ論

要約:

■ 1. 概要

  • テーマ: SaaS領域におけるデータ品質向上の取り組みとその段階的実装戦略

■ 2. データ環境

  • DWHにはGoogle BigQueryを採用
  • 内製ETLフレームワークによりデータ処理を実施
  • One Big Tableフォーマットのデータマートを約50個提供

■ 3. 課題

  • テスト不足によりバグが偶発的にしか発見されない状況
  • レガシーなロジックが継続使用されることによる品質低下
  • ドキュメントの欠落により保守性が低下

■ 4. 導入ツール

  • dbt:
    • トランスフォーム処理とテスト管理に使用
  • Elementary:
    • dbtネイティブの観測可能性サービス
    • テスト失敗時にSlack通知を送信
    • UIによるモニタリング機能を提供

■ 5. 段階的テスト実装戦略

  • Phase1（クリティカルエラーテスト）:
    • 重複チェックにより同一データの重複を検出
    • Nullチェックにより必須項目の欠損を検出
    • 値確認により基本的な異常値を検出
  • Phase2（整合性テストとサービスデータ変更検知）:
    • ビジネスロジック観点でカラム間の矛盾を検出
    • 例として「解約フラグが立てばステータスは解約」といった業務ルールを検証
    • 複数カラムの合計が特定カラムと一致するかを確認するカスタムテストを開発
    • 複雑な条件に対応するためカスタムテストを独自開発
  • Phase3（ディメンショナルモデリング）:
    • レイヤー別アーキテクチャへの移行を目指して進行中
    • 保守性の向上を目的とした構造改善

■ 6. 実装結果

  • 49マートに対してテストを実施
  • 合計3,076個のテストを構築
  • 120件の不具合を検知
  • 既存データの潜在的な問題を可視化

(2026/03/04)

「答え合わせ」ができないデータ分析SQLで品質を担保するためのバグ検知・プロファイリング手法

要約:

■ 1. 背景と課題

  • データ分析SQLは事前に定義された正解が存在しないためテストが困難
  • テスト観点が標準化されておらず品質が担当者の経験に依存する
  • エラーなく実行されるサイレントバグ（NULL計算による欠損等）が発生しやすい
  • データ整合性確認のレビューに多大な工数を要する

■ 2. 頻出するバグパターン

  • NULL/Unique仕様の乖離:
    • データ仕様と実態の不一致により計算結果が欠損する
  • Fan-out（レコード増幅）:
    • 結合時のキー重複により集計値が意図せず増幅する
  • 複雑ロジックのブラックボックス化:
    • Window関数など複雑な処理において実装ミスが見落とされやすい

■ 3. 解決策

  • ツール開発:
    • Google Colab上で動作するデータプロファイリングツールを開発
    • CTEの統計情報（NULL数・ユニーク数）を自動算出する機能を搭載
    • 実テーブル一括作成機能により中間データを可視化し複雑ロジックを検証可能にする
  • プロセスの標準化:
    • テスト観点を必須（MUST）と推奨（WANT）に分類する
    • 体系的な品質保証体制を構築し観点の属人化を解消する

■ 4. 導入効果

  • 品質保証のベースラインが向上する
  • 手戻りが削減される
  • レビュー工数が大幅に削減される

(2026/03/04)

Claude Code Agent Teamsの衝撃と実際

要約:

■ 1. Claude Code Agent Teamsの概要

  • 複数のAIエージェントが協調して複雑な問題を解決する新プレビュー機能
  • 2026年2月5日にClaude Opus 4.6とともにリリース
  • 従来のサブエージェント方式から大きく転換した設計となっている

■ 2. アーキテクチャ

  • Team Lead（メインエージェント）が複数のTeammateを統括する構成
  • 共有タスクリストは~/.claude/tasks/[チーム名]に保存される
  • エージェントはリーダーへの一方的な報告ではなく、ピアツーピアの直接通信により自律的に連携する

■ 3. 有効化方法

  • 環境変数による有効化:
    • CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claudeを実行する
  • 設定ファイルによる有効化:
    • ~/.claude/settings.jsonのenvキーにCLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: "1"を追加する

■ 4. 主な制限事項

  • 管理の複雑さ:
    • 明確な指示とフィードバックループ（リンティング・テスト・レビュー）の整備が必須となる
  • トークンコストの高さ:
    • プランモードで通常の約7倍のトークンを消費する
    • SonnetやHaikuモデルの活用や不要なMCPサーバーの最小化により軽減可能
  • 巻き戻し・再開機能の欠如:
    • 通常のClaude Codeとは異なり、以前の状態への巻き戻しやセッションの再開ができない

■ 5. 表示モード

  • in-process:
    • Shift+↑/↓でTeammateを切り替える単一画面インターフェース
  • tmux:
    • Tmuxのインストールが必要な分割ペイン表示
  • auto:
    • 環境を自動検出するデフォルトモード

■ 6. 主な活用場面

  • フロントエンド・バックエンドにまたがる大規模リファクタリング
  • 複数実装を並行して進める新機能開発
  • 多角的な視点によるコードレビューおよびバグ調査

■ 7. 成功のポイント

  • 人間が直接マイクロマネジメントするのではなく「明確な方向性・厳格な制約・フィードバックメカニズムの確立」がAgent Teams活用の成否を左右する

(2026/03/04)

一枚岩の「巨大SQL」から脱却するために。Airペイ新機能のデータ基盤を支える、ニジボックスの技術力

要約:

■ 1. プロジェクト概要と体制

  • Airペイの新機能「オンライン決済」（2025年3月リリース）に向けた分析用データマートの開発プロジェクト
  • リクルートが設計・要件定義を担いニジボックスが実装を担当
  • 開発フェーズ:
    • 第1フェーズ: 4名体制で最低限の分析が可能なデータマートを構築
    • 第2フェーズ: 岩井・村上の2名でディメンショナルモデリングによるリファクタリングを実施
  • 役割分担:
    • 岩井（リクルート）: プロジェクト管理・スケジューリング・ステークホルダー折衝・データマートのモデル設計
    • 村上（ニジボックス）: 実装担当
    • 林田（ニジボックス）: 村上のバックアップ

■ 2. データマート新設の背景

  • 既存のAirペイのデータマートは2015年のリリース以来 複雑化した処理を抱えており解消作業を進めている状況
  • オンライン決済とAirペイ（対面決済）は決済の仕組みが異なる
    • オンライン決済には「支払いリンク発行→送信→ID登録→決済」というファネルが存在
    • 取得するデータの量とバリエーションが対面決済と異なる
  • 社内の担当チームも分かれているためデータマートを分ける判断をした
  • データレイクのローデータ活用には高度なドメイン知識とデータ加工技術が必要
  • ビジネスサイドのメンバーが自律的にデータ分析・モニタリングできる基盤が必要
  • 分析者によって結果が異なるリスク（ロジックの違いや母集団のズレ）を排除する必要がある

■ 3. 採用技術と手法

  • ディメンショナルモデリング:
    • データを「ファクト（計測対象）」と「ディメンション（計測軸）」に分離するモデリング手法
    • システム開発における責務の分離をデータ開発に適用する考え方
    • 処理を段階的に切り分けた実装が可能になる
  • dbt（data build tool）:
    • モジュール単位でSQLを記述しロジックを積み上げる形で開発可能
    • テストが書きやすく処理の所在が一目瞭然になる
    • 従来の内製ジョブ基盤による巨大クエリに比べ開発効率性とメンテナンス性が向上
  • 品質管理:
    • データの整合性テストを入念に実施
    • データ異常を検知するテストをリリースと同時に稼働
    • データ環境・提供するデータ自体をプロダクトと位置付けている

■ 4. ビジネスサイドとの折衝

  • AirペイのKPI分析軸をある程度トレースできたため要件のすり合わせは比較的スムーズ
  • エンジニア側の厳密さとビジネス活用上の許容範囲に若干の温度差があった
    • 例: 加盟店のアクティブ・非アクティブ定義をKPIモニタリングの観点から協議して決定
  • セキュリティ・ガバナンス上の問題がない限りビジネスサイドの意向を優先する方針

■ 5. チームコミュニケーションと協業体制

  • リクルートとニジボックスはグループ会社として垣根なく協業する体制を構築
  • チーム内コミュニケーションの工夫:
    • メンバーの発言にスピーディーに反応する
    • 実装上の懸念点や要望を積極的に出しやすい雰囲気を意図的に作る
    • 設計に対するメンバーからのフィードバックを積極的に採用
  • Slackでの作業ログ・思考プロセスの共有が詰まりポイントの可視化に貢献
    • メンションなしにつぶやきを拾い疑問を解消する仕組みが機能
    • 同様の課題を抱えるメンバーにとっても参照可能な情報資産となる
  • マネジメント側の取り組み:
    • コミュニケーションが苦手なメンバーには個別フォローを行うとともにリクルート側にも受け入れ準備を依頼
    • プロジェクトの方向性とユーザーニーズをメンバーにしっかり共有

■ 6. キャリア成長と今後の展望

  • 村上の成長実績:
    • 初めてディメンショナルモデリングとdbtを習得
    • 新規開発からリファクタリングまで一貫して関与することでデータ設計と品質への意識が向上
  • 今後の目標:
    • 村上: 設計工程も自己完結できるスキルの習得
    • 村上: dbtの社内研修準備と社内エンジニアへの知識共有
  • ニジボックスのキャリア環境:
    • リクルートグループとして垣根なく協業できる環境がスキル・キャリア成長の強みとなる
    • 未経験の技術・業務に挑戦しやすい文化とマネジメント体制を整備

(2026/03/03)

「若手が育たない」—AI時代に浮上する“最も深刻な社会問題”。中島聡が予測する仕事が失われていく「10年後」

要約:

■ 1. AIXによる雇用構造の変化

  • パレートの法則（2:8の法則）の前提が崩壊する
    • AIX以前は8割の人材も定型業務・サポートとして組織維持に必要だった
    • AIXの時代にはAIが8割の人材の仕事をすべて代替する
    • 人間の能力もAIにより拡張されるため必要人数がさらに減少する
  • 組織は極限までスリム化される
    • 残るのは「AIを使いこなして意思決定できる少数の人間」のみ
    • 必要な人員は2割から2%以下になる可能性がある
  • 肉体労働もAI搭載の人型ロボットが代替する
    • 残る人間は農地所有の資本家・AI企業経営者・ごく一握りのプロフェッショナル
  • 雇用の消滅はすでに起きている現実である
    • Duolingo CEOのメールに象徴されるように世界中の企業が同じ決断を下しつつある

■ 2. 若手が育つ機会の喪失

  • 現在のAIは大卒の若手社員レベルの知能を持つ
    • プレゼン資料作成・データ集計分析・議事録作成・リサーチ等を人間と同等以上のクオリティでこなす
    • 24時間365日稼働し文句を言わない
  • 経営者にとって若手を雇わないことに合理性がある
    • AIが若手社員と同じ仕事をこなすため新規採用の必要がない
  • 若手はこれまで「下積み仕事」を通じてスキルを習得してきた
    • 若手弁護士は判例リサーチを通じ法的思考プロセスや訴訟戦略を学んだ
    • 若手コンサルタントはデータ分析という下積みを通じ問題解決スキルを習得した
    • 若手デザイナーはアシスタントとしてラフを清書しながら「暗黙知」を体得した
  • 一見退屈な単純作業はプロフェッショナルになるための「学びのはしご」であった
    • AIXはこの「はしごの1段目」を消滅させる

■ 3. バイブコーディングと個人の生産性爆発

  • 著者自身も人を雇う選択肢が極端に減っている
    • 以前はサービス実装のためエンジニアを採用していたが今はAI1つで完結する
  • バイブコーディング（Vibe Coding）という新しい開発スタイルが鍵となる
    • 厳密な設計図を書かずに「こんな感じの機能が欲しい」というバイブスをAIに投げてコードを生成させる手法
    • AIが書いたコードは使い捨てでよくエラーもAIに修正させる
    • 人間は指揮者のようにAIへ指示を出すだけで動くアプリケーションが完成する
  • AIと1人で100人分以上の生産性を発揮できる
    • 100名のエンジニアを雇っても100倍のパフォーマンスにはならない
    • コミュニケーションコストにより50倍のパフォーマンスすら難しい場合がある
    • 適切な指示を出せる1人+AIで100人以上の生産性が実現する
  • 若手エンジニアの居場所が消える
    • かつて若手に任せていた「簡単な機能の実装」がAIの方が早く正確にこなせる
    • 中途半端なスキルの若手を雇うことはコストではなくスピードを落とすリスクになった

■ 4. ベテランという概念の消滅と社会的混乱

  • 現在のベテランが優秀なのは若手時代の「下積み」経験があるから
    • 若手期に機会を奪われた現世代はどうやって将来のベテランになるかという問題が生じる
  • AIの進化が進めば「ベテラン」という概念自体が不要になる
    • 人間が経験を積んで成長する必要すらなくなる可能性がある
    • AIがすべてを完結させるなら仕事自体が人間社会から消滅する
    • 会社や組織そのものがなくなる可能性もある
  • 従来の人材育成システムとAIの効率性が衝突し社会的摩擦が生じる
    • 労働の8割がAIに置き換わる過程で社会のあちこちで激しい摩擦が起きる可能性がある
    • 混乱の先にどのような社会の形が待っているかは明確でない

(2026/03/03)

OSSは書き捨て御免が本来のはずで（そもそも「無償」とはそういうことである）、いつから開発者が...

OSSは書き捨て御免が本来のはずで（そもそも「無償」とはそういうことである）、いつから開発者が持続性に責任持たなきゃならなくなったのかな……と不思議に思っている。実際に社会がOSSで動くような力学はあるけど開発者が飽きたら終了、という出口は常にあった方がよい。

@odashi_t

気持ちはすごくよくわかるのですが、既にインフラになってしまったようなタイプのものについて誰が後をみるのかというのは考えないといけない気はしています（無償労働に寄ってたつインフラは不健全なのは倫理としてわかる一方で、マクロにみたときに難しいなとも）

@kmizu

それを考えるのはインフラとして依存している側の責任であり、個々の開発者ではない、という話でしょうね

@odashi_t

ただ、それはそれで他人事にするのはどうなのかなと感じもします。私たちは既に知らないところで膨大な他人の無償労働に「依存してしまっている」のであって。

@kmizu

開発者側に責任はない＝OSSライセンスに同意した以上責任を追求してはいけない、という契約上の話と、個人的な誠実性の話は分けて考えないとおかしくなると思います。

@odashi_t

そこはおっしゃる通りですが、契約上責任を追求してはいけないということはその通りでも、同調圧力というか社会的圧力は厳然として存在するわけで、個人的な誠実性というよりそこを問題にしたい感じですね。

私個人としては責任を追求するべきでないと思いますが、それとは無関係に「社会はパワーバランスでしか動かない」という事実があるわけで。

@kmizu

後者の論理で動く人が開発者に「無償であることに同意しないなら貴方がたがこのソフトウェアを使用する権利はない」と言われたらどうするんでしょうね。

@odashi_t

予想としては、そんな論理知ったことか。もう社会はそれで動いてるでしょ？あたりでしょうか（表現としてはもうちょっとマイルドに「とはいっても、今それでもう回ってるんでは？」的に言うでしょうけど）。

力を背景にすれば論理なんて無力というか、逆に責任を（過度に）要求してくるなら、それを逆手に取る法廷闘争とか色々手段は考えられる気はしますが。

@kmizu

そういう高圧的な会社は逆に身を滅ぼすでしょうねぇ

それはともかく、寛容ライセンスの受託者責任は結論の出なかった裁判は1件(Turip Trading v Bitcoin Association)知っていますが、他に何かあるかしら…

@odashi_t

(2026/03/03)

最も良い見積もり手法は見積もりをしないことだ

要約:

■ 1. 背景と前提

  • システム業界においてSIerの存在感が低下し自社プロダクト開発に携わるエンジニアの割合が増加している
  • 自社開発であっても工数見積もりの問題は依然として多くのエンジニアを悩ませている
  • 本稿は自社プロダクトをアジャイルで開発するシチュエーションを前提とする

■ 2. 見積もりをなくすという主張

  • 最善の見積もり手法は見積もりをしないことである
  • 自社プロダクト開発では作業粒度を小さくできるため「できた時が完成」方式が有効である
  • 見積もり自体が困難である以上見積もりをなくすことと比較する価値がある

■ 3. 見積もりをなくすための手法

  • 作業単位をなるべく細かくする
  • 管理者がある程度の作業量とリスクを判断できるようにする
  • 結果で判断する
  • チーム全体のスループットを定量的に測る
  • できないものはできないと認め諦める

■ 4. 見積もりをなくすことによるメリット

  • 見積もりにかかる時間がなくなる
  • 余計なバッファを積まなくて良くなる
  • 積んだバッファを無駄に消費しなくて良くなる
  • リスクの顕在化が早くなる
  • 結果に注目し正しい評価ができるようになる
  • 全体的に開発がスピードアップしスループットが向上する

■ 5. 管理者の役割

  • 管理者の仕事は経営陣や上司からの「見積もりしろ」という圧力をはねつけることである
  • チームのパフォーマンスを最大化するために必要な措置をとることがマネージャーの責務である
  • 現代のビジネスではスループットと柔軟性をもって組織の価値を判断することが求められる

■ 6. 締切が絶対である場合の対応

  • 締切がマストなタスクには締切の設定とともに内容の取捨選択を行う
  • 予算・品質・納期の三要素を同時に全て満たすことはできない
  • 納期が絶対である場合は予算と品質で調整するしかない
  • 締切から逆算する
  • リスク評価を最速で行う
  • バックアッププランを可能な限り用意する
  • 人員配置や補給など最善を尽くす

(2026/03/02)

絵に描いたようなSI炎上案件を見たので過去の経験から勝手に解説する

要約:

■ 1. 営業主導による炎上の起点

  • 受託開発の見積もりは画面数等を元にした経験則に基づき正確性を欠く
  • 30%OFFの受注は人件費の30%削減として現場に押し付けられる
  • 客は定価相当のシステムを購入したと認識するが実際には7割分の提供となる
  • 差額は「現場の頑張り」で補うことを前提としており炎上の構造的起点となる

■ 2. 増員による悪化

  • 人員不足によりスケジュールが遅延し客からの圧力が生じる
  • SIerは遅延が発生すると迅速に増員を決定する傾向がある
  • 炎上中のプロジェクトへの増員は以下のコストを発生させ状況を悪化させる:
    • 新規人員への教育コスト
    • タスク再配分コスト
    • 人員管理コスト

■ 3. 顧客との関係崩壊

  • SI側の進め方が崩壊すると顧客との信頼関係も失われる
  • 発注範囲の境界線が不明確になりカジュアルな仕様変更要求が発生する
  • SIerはシステム開発のプロとして顧客の意思決定を先回りしてコントロールすべき存在である
  • 多くのSIerにはこの思想が欠如しており顧客主導の主従関係が形成される
  • 日本のSI業界ではこの構造が数十年にわたり定常化している

■ 4. プロジェクトマネジメントと品質管理の崩壊

  • スコープマネジメントの欠如がリリース時の品質評価を実質不可能にする
  • 各工程のスケジュール遅延により前工程終了前に次工程が開始される状況（五月雨）が生じる
  • しわ寄せはテスト工程に集中し品質が崩壊する
  • 典型的な炎上案件では以下の5つの崩壊が連鎖的に発生する:
    • 体制の崩壊
    • 顧客との信頼関係の崩壊
    • スケジュールの崩壊
    • テスト工程の崩壊
    • 品質の崩壊

■ 5. 炎上後の構造的帰結

  • 現場担当者の一部が鬱になる
  • 案件終了後に燃え尽き症候群（デスマーチロス）が発生する
  • 会社は現場の疲弊をよそに価格交渉を開始する:
    • 超過した人件費を「赤字」として顧客に折半を要求する
    • スコープ管理不足を棚上げし仕様変更を根拠としてオプション費用を請求する
  • SIerの人件費は「売値」で積算されるため粗利率50%程度のマージンが乗っており折半でも原価回収が可能
  • リリース後の運用保守契約は5年から10年続く場合があり開発費用と同等以上の収益源となる
  • 近年は大規模SI案件の減少と労働環境改善の動きにより典型的な炎上案件は減少傾向にある

MEMO:

(2026/03/02)

Yes, and...

要約:

■ 1. コンピュータプログラミングはAI時代においても有望なキャリアである

  • プログラミングの本質はコンピュータを用いた問題解決と複雑性の制御の2点であり、これらのスキルの価値はAIの登場によっても変わらない
  • 現在のプログラマー就職市場は厳しいが、これは一時的な状況であり循環的な市場変動の一部である

■ 2. ジュニアプログラマーはAIにコードを生成させるべきでない

  • AIがコードを生成できるとしても、自分でコードを書かなければコードを読む能力が養われない
  • コードを読めなければ「魔法使いの弟子の罠」に陥り、理解も制御もできないシステムを生み出す危険がある
  • コードを書く経験が、ソフトウェアアーキテクチャの直感を育む唯一の手段である

■ 3. AIへのコード生成依存はアセンブリから高水準言語への移行とは異なる

  • コンパイラは決定論的だが現在のLLMは非決定論的であり、同じプロンプトに対して同一の結果が保証されない
  • 高水準言語は偶発的複雑性を排除したが、LLMが生成するコードは不適切なアプローチや近道によって偶発的複雑性を増加させることがある

■ 4. AIは優秀なティーチングアシスタントとして機能する

  • AIはコード生成ツールとしてではなく、概念や技術の理解を深めるパートナーとして活用すべきである
  • 学習中に「詰まる」問題、特にツールチェーンなどの環境に起因する偶発的複雑性の解消に有効である
  • 筆者はAIをTAとして機能させるためのAGENTS.mdファイルを学生に提供している

■ 5. AIによるプログラミングの変化と今後重要性が増すスキル

  • コミュニケーション能力:
    • LLMおよび人間との明確な文章による思考・伝達能力の重要性が増す
    • 読書や記事執筆などがこのスキルの向上に寄与する
  • ビジネス理解:
    • プログラマーがビジネスや業務上の実問題を深く理解する能力の価値が高まる
    • AIの活用によりプログラマーはコア業務を維持しつつ現実問題の理解に時間を割けるようになる
  • ソフトウェアアーキテクチャ:
    • 大規模システムを効果的に設計し複雑性を制御する能力の重要性が増す
    • アーキテクチャのスキルは小規模なコードを書く経験の積み重ねによって習得されるものであり、AI依存による経験不足は将来のアーキテクト能力の低下につながる
  • LLMの効果的な活用:
    • 既存コードの分析・理解、大規模プロジェクトの思考整理、小規模コードの生成、正規表現やCSSなど書きたくないコードの生成、デモや探索的コードの生成、テストの提案といった用途に限定して使用する
    • フルソリューションの生成やAPIの設計にLLMを使用すべきでない

■ 6. 就職活動における実践的なアドバイス

  • オンライン求人サイトはほぼ効果がなく、特にジュニアには宝くじ的な存在である
  • 「4つのF」として家族・友人・友人の家族といった個人的なコネクションを活用すべきである
  • 100人以上の企業にはほぼ必ず何らかの開発部門が存在しており、コネのある企業への就職は競争優位をもたらす
  • コスタコ社員の親を持つ学生の例のように、非IT企業でもプログラミングスキルは大きな強みになる

(2026/03/02)

【スゴ本】知らないと現場が燃え尽きる。システム障害対応で本当に優先すべき5つのこと

要約:

■ 1. はじめに

  • システム障害対応では「影響範囲の調査」「原因の特定」「復旧対策の実施」という一般論は広く知られているが実践的な指針は少ない
  • 実際の困難は部分的にしか見えない流動的な状況下で錯綜する情報を元に優先順位を判断することにある
  • 『システム障害対応の教科書』はシステム障害の検知から原因調査・復旧対応までの基本的な動作と現場マネジメントをまとめたものである
  • 本稿では同書をベースに著者の経験を交えた5つの勘所を解説する

■ 2. 旗振り（インシデントコマンダー）を決める

  • 旗振りとはシステム障害対応チームのリーダー（インシデントコマンダー）のこと
  • 主な役割:
    • 体制構築: 対応メンバーを集め役割をアサインする
    • 兵站: メンバーのシフト・食事・宿泊を割り振る
    • 情報の一元化: 原因解析・仮説検証・復旧対策の状況を集める
    • コミュニケーションのハブ: 顧客や関連チームと連携する
  • 旗振りはまず障害の対応方針（システム復旧優先かデータ汚染阻止優先か等）を決定する
  • 状況の変化に応じて優先度の再考も必要となる
  • 旗振り不在の場合:
    • 全員がボールに集まる「ちびっこサッカー」状態となる
    • 場当たり的な対応となり情報は断片的なまま集まるが解決に結びつかない
    • 情報錯綜により作業が重複しデータ破壊などの二次被害が発生する
    • 対応できる人に作業が集中し長期対応でその人が消耗・破綻するリスクがある
  • 旗振りと作業者は必ず分離する:
    • 2つの役割を兼任させると作業ミスや連絡漏れなどの二次被害リスクが高まる
    • 通常は「分かる人」「できる人」が作業者となるため上司が旗振りを担うことが多い

■ 3. メンバーの健康維持のための宿を確保する

  • システム障害の最大の特徴は「いつ終わるか分からないこと」である
  • ヤバそうなトラブルと感じた時点でまず宿泊手段の確保を検討する:
    • 会社泊か近隣宿泊施設かを判断する
    • 誰が泊まり誰を帰すかを決める
  • メンバーの休息サイクルを最初に設計しない場合:
    • 限界まで働いてから場当たり的な休息となる
    • 連泊連勤が続くとパフォーマンスが著しく低下し体調不良者が続出する
    • 復旧後に退職者が出るリスクがある
  • システム障害の終息時期は予測困難である:
    • 原因が判明しても復旧方法（データパッチ・ロールバック・プロセス再起動等）はさらに検討が必要
    • 業務担当との調整や上層部の判断も必要となる
  • 大きなトラブルと感じた時点で長期戦を覚悟し宿を予約する:
    • 空振りしても問題ない（重要なのはメンバーの体調とチームのパフォーマンス）
  • ホテルが確保できない場合はスパ銭利用の当番表を作成するなど代替手段を講じる
  • 「まだイケます」と申し出るメンバーも強制的に休ませる
  • システム障害時のリーダーの最大の役割はメンバーをどうやって休ませるかである

■ 4. War Roomをつくり情報を集約・可視化する

  • War Roomとはそこに行けば最新情報と状況が把握できる会議室（物理・ウェブ・ハイブリッド）のこと
  • ホワイトボードはフロー型とストック型の2種類を用意する:
    • フロー型: 時系列の一覧表
    • 発生事象・影響調査・解析状況を時系列で記録する
    • 「いつ」「どこで」「何が」「どこの情報か」を記載する
    • 記録は消さずに継続し満杯になったら別ボードを用意する
    • ストック型: 現在の最新状況のまとめ
    • 発生事象と影響・解析状況と直接原因（事実/仮説の区別含む）・復旧対処の準備と状況を記載する
    • 復旧リミットや復旧作業に伴う業務影響も記載する
    • 未確定事項もその旨を明記する
    • 更新時は右上に日時を書いて画像として保存する
    • 途中参加・交代メンバーはこのボードで状況を把握する
  • ホワイトボード周辺にはシステム全体図・連絡体制図・当番表を揃えておく
  • 情報更新タイミングをボードに明示し非同期でも情報が届く仕組みを作る
  • ホワイトボードはチームの盾としての機能を持つ:
    • 「どうなっているのか」と怒鳴り込む人にはストック型ボードを見せることで説明に代える
    • 無茶な要求や暴言はフロー型ボードにそのまま記録し後の責任問題への証拠とする
    • ウェブ会議の場合は全てレコーディングしておく
  • ホワイトボードは「人から問題を切り離す装置」として機能する:
    • 問題はホワイトボード上（当事者間）にあるという形にすることで経営層と現場の対立姿勢を和らげる

■ 5. 陥りがちな罠を見極め二次被害を避ける

  • システム障害の解析・復旧において二次被害は普通に発生するものとして認識する
  • 二次被害が発生しやすい理由:
    • 緊急・重要な状況でリソース・時間・情報が不足している
    • 普段しない作業を慣れていないメンバーが実施する場合がある
    • 通常は複数人でやるリスクのある作業をひとりで実施せざるを得ない場合がある
    • 疲労困憊した状態での作業となる
  • 二次被害の具体例:
    • 手順書のサーバ名誤り（IPアドレスとホスト名の食い違い）による無関係サーバのシャットダウン
    • 削除対象確認漏れによるシステム領域の全消去
    • 再実行禁止バッチ処理の誤実行によるデータ件数倍増と容量圧迫
    • 連携先システムでの確認漏れ
  • 対策:
    • 危険な作業は複数人でチェックする
    • リモートで画面共有しながら実施する

■ 6. 責任転嫁のための犯人探しをやめさせる

  • 犯人探しは障害対処中・ポストモーテム中を問わず必ず発生する:
    • 組織が大きくなるほど役職が上になるほど発生しやすい
  • 犯人探しの背景:
    • 不確実な状況下での恐怖を誰かへの責任転嫁によって解消しようとする心理的行動である
  • 犯人探しの悪影響:
    • 報告遅延・情報隠蔽が起きる
    • 解明が遅れ根本解決に至らない小手先の対処となる
    • 一時的な小康状態の後にさらに大きな事故が発生するリスクがある
  • 犯人探しへの対処法:
    • 原因調査の主語を「人」から「プロセス」に変える
    • 「誰が設定を変えたか」ではなく「いつどの手順に則って変更したか」と問う
    • 変更理由・背景・承認プロセスの欠陥を明らかにする
    • 問題はミスした「人」ではなくミスを防げなかった「プロセス」にあると強調する
    • 感情的になっている人から現場エンジニアを全力で守る
    • 怒りを人ではなく別の何か（ぬいぐるみ等）にぶつけることで責任所在を「誰か」から「何か」に転換する

■ 7. おわりに

  • システム障害における現場マネジメントの要点:
    • 旗振りを決め体制を構築する
    • 兵站に目配りしてWar Roomをつくる
    • 二次被害に注意しながら解析・復旧を進める
    • 犯人探しを厳に慎む
  • より具体的・網羅的な情報は『システム障害対応の教科書』を参照
  • いま余裕のある状況で「連絡体制図」を更新しておくことを推奨する:
    • 電話番号・メアドだけでなくメーリングリスト・SlackやTeamsアカウント名・担当窓口も最新状態に保つ

(2026/03/01)

30分でわかるアーキテクチャモダナイゼーション

(2026/03/01)

Goで実現する堅牢なアーキテクチャ：DDD、gRPC-connect、そしてAI協調開発の実践

(2026/03/01)

静的解析からみるGoの過去と未来

(2026/03/01)

NEXT