nwiizo

はじめに 私たちエンジニアの仕事はここ1年で大きく変貌しました。大きく変貌しましたよね？ 自分でコードを書く時間より、エージェントに仕事を渡し、戻ってきた差分を読み、次に何を任せるかを決める時間のほうが長くなった人も多いはずです。仕事術の本を出したのですが、修正をしなければ嘘だなって思ったほどです。 おい、とりあえず終わらせろ: そうすれば「動けない自分」が変わるから作者:nwiizo（ぬうぃぞう）ダイヤモンド社Amazon コードを書き、動かし、直すところまでは、エージェントがかなりこなせるようになりました。では楽になったかというと、なっていません。手を動かす時間が減ったぶん、差分を読み、承…

Herdrで、複数のエージェントを見守りたい

はじめに トラックバックをやります。河又さんも喜ぶはずです。 河又さんの記事「何者かになりたいなら打席に立ち続けなさい」で、私の「おい、〇〇」シリーズを取り上げていただきました。 note.com 何者かになりたいなら、打席に立たなければいけない。それはそのとおりです。河又さんは「何者か」を、特定の分野や仕事と結びつけてその人を思い浮かべてもらえる状態として説明しています。発信は義務ではなくやめてもよいとしたうえで、そうなりたい人には続けることを勧めています。私もその考えには賛成です。 何をしている人なのかを知ってもらうには、仕事や考えを人に見せる必要があります。私自身、できないことを人に知ら…

何者って、なんですか

がるさんの「魔法が使えるようになったプログラマたちへ」を読んで、『魔法使いの弟子』を思い出しました。ディズニーの『ファンタジア』で、ミッキーがほうきに水を運ばせる、あの話です。 ファンタジア スペシャル・エディション [DVD]ウォルト・ディズニー・ジャパン株式会社Amazon 記事は、AIで何かを作れるようになった喜びを認めながら、作ったものを理解し、面倒を見続けられるかを問いかけています。とくに好きだったのは、自分用だった便利な道具がほかの人にも使われ、いつの間にか業務から外せなくなる話でした。 水を運ばせることには成功した。 最初は魔法を動かせても止められない弟子と、よく似ていると思いま…

『魔法使いの弟子』を思い出した。AIで作ったものに責任を持つということ

はじめに AIに古いシステムを書き直してもらい、今と同じ動作を再現できたとします。テストも通りました。けれど、利用者は翌朝も同じ数字を転記し、別の表で確かめている。書き換えは終わったのに、その人の仕事は変わっていません。 『Domain-Driven Transformation』を読みながら考えたのは、何を残し、何を変えるかを、どこで判断するのかということでした。古いコードには業務を支えてきた知識があります。一方で、ソフトウェアの都合で続けてきた手順もあります。同じ動作を再現できても、それを今後も残す理由は、コードだけでは分かりません。利用者の要望をそのまま実装するだけでも、この判断はできま…

AIに実装を任せる時代に、何を残し、何を変えるのか - Domain-Driven Transformation の読書感想文

Rustで順序交叉（OX）を実装し、都市を重複・欠落させずに2つの親から子を作ります。循環して埋める手順と、区間の端や不正な入力の検査を確かめます。

Rustで順序交叉を書く

Rustで8ビットの遺伝的アルゴリズムを実装し、選択・交叉・突然変異とエリート保存を確かめます。全探索との比較や、探索結果を採用する際の条件も扱います。

Rustで遺伝的アルゴリズムを書く

はじめに PHP2Shellへの対応、お疲れさまでした。この記事は、更新や影響の確認が一段落し、今後の開発や保守を考える人に向けた読み物です。 2026年10月21日、PHPは外部からのリクエストによって、サーバー上で任意のコードを実行されうる2件の脆弱性を修正しました。PHP2Shellと呼ばれる問題です。PHP公式はWeb向けの各実行方式に影響し、Apacheのmod_phpではアプリケーションのコードが動く前から攻撃が成立すると説明しています。 www.php.net GMO Flatt Securityの解説がめちゃくちゃ良いので、何が起こったのかは、まずこちらを読んでみてください。 …

PHP2Shellから考える、Rustは何を防ぎ、何を防がないのか

はじめに 探索の答えを変えずに、調べる量を減らせるでしょうか。AIへ「速くして」と頼む時、自分でも省略の根拠を説明できるように、αβ枝刈りを追ってみます。 対戦ゲームを作り、コンピューターに先の手まで読ませるとします。自分の手の後には相手の応手があり、その後にも選択が続きます。読む範囲を広げるほど候補が増え、遊んでいる人は次の一手を待つことになります。途中で読むのをやめれば早く返せますが、不利な展開を見落とす可能性があります。 すでに有利な手を1つ見つけている時、別の手では相手がこちらを不利にできると分かったら、どうでしょう。その先に魅力的な展開があっても、相手がそれを選んでくれるとは限りませ…

Rustでαβ枝刈りを実装する

二枚の予約確認書 水野は、予約確認書が二枚あることより、梶原がそれを印刷してきたことを先に気にした。ふだんならチャットに予約番号が送られてくる。確認します、と返せば、そのあと何を確認するかを考える時間があった。 梶原は二枚とも、水野から読める向きに置いた。 開発を始めて五十九日目だった。どちらにも、土曜日の午前九時、折り畳み椅子六十脚、とある。届け先と予約番号が違い、下のほうの「予約が確定しました」だけが同じだった。水野は一度、その文の下に何か小さな注意書きがないか探した。 「倉庫には六十脚です」 「どっちが先ですか」 「先なら届けていいんですか」 梶原は、どちらを先に受け付けたかを知らないわ…

全テスト成功

はじめに AI時代でも、アルゴリズムや基礎を学んでおこうと若い人に話しています。そう勧める自分の復習も兼ねて、今回はRustでA*を実装します。「最短の経路を探して」とAIへ頼む時に、自分は何を最小にしたいのか。返ってきた答えを最小だと言える条件まで、小さな例で確かめます。 ある作業の担当者が、完了までの手順を選ぶ場面を考えます。2つの操作で済む案と、3つの操作を順に進める案があります。操作数で選ぶなら前者です。ところが所要時間を足すと、前者は9分、後者は3分です。待っている人へ早く結果を返すには、操作の回数より、各操作にかかる時間を比べる必要があります。 候補が増えると、どの手順から調べるか…

RustでA*を書く

はじめに アルゴリズムや設計を理解すると、同じ問題に対して立てる問いが変わります。サービスの障害調査でも、「次にどのサービスを確認するか」に加えて、「依存関係をどちら向きにたどれば、影響を受ける候補を集められるか」と考えられます。関係の表し方や調査を終える条件まで、検討できるようになります。 ただし、知識があっても、目の前の問題をそのように捉えなければアプローチは変わりません。さらに、問題を探索として捉えた後にも、何を求め、何を求めないかという判断が残ります。BFSとDFSの実装を通じて、選んだ方法の理由と、その判断を見直す条件まで考えます。 BFSとDFSは、調べる順序が違う 地点と、その間…

RustでBFSとDFSを書く

はじめに 「インフルエンサーのnwiizoさんです」と紹介されるのが本当に嫌だ。 インフルエンサーという呼び名からは、何を開発し、何を運用してきたかより、どれだけ人に知られているかが先に伝わるように感じる。ソフトウェアエンジニアとして働いてきた時間は、その呼び名のどこにも入っていない。開発者としての努力を無視されているような気がする。知られるように働きかけたのは自分で、会社にとってはそれが技術広報の成果でもある。だから、呼び名が間違いだとは言えない。嫌なのは、そこに入らない仕事が自分には大きいからだ。 それでも、去年よりは受け止められるようになってきた。書籍を書き、連載に取り組む中で、発信も自…

続続: 自分が書いたコードより目立つな - エンジニアがバズったので自戒

はじめに 「自分は成果を出した」と言い切ったあとに、まだ問いが残る。では、その仕事で、チームや組織は何を手にしたのか。 難しい問題を解く。仕事を早く終える。私の実績として並ぶそれらも、私たちの勝利につながっていなければ、シニアの仕事としては意味がない。 自分の成果を、チームや組織の結果に変える。チームや組織を勝たせることが、シニアエンジニア以上の役職の仕事だ。 自分で難しい問題を解くことも、周囲が力を発揮できるようにすることも、そのための働きになる。 そのために、目標と、どんな変化を成果とみなすのかを周囲と確かめたい。自分が手を動かすか、ほかの人が判断できるように情報や権限を整えるかを選ぶ。実…

シニアになりきれない中堅エンジニアは、何を読めばいいのか 2026年版

はじめに Rust Learning Labは、手元のRustコードを題材に、構文や型、所有権を説明してもらうためのCodex・Claude Code向けプラグインです。「この記号は何か」「なぜここで借用するのか」「この変更で何が変わるのか」といった疑問を、具体的なコードに沿って確かめられます。 github.com Rustを書き始めた人にも、コードは読めるけれど型や所有権を選んだ理由までは説明しきれない人にも使ってもらいたいと思っています。私が考えているのは、AIに何を任せ、何を自分で確かめるか、その判断を育てる機会を仕事の中にどう残すかということです。Rust Learning Labは…

AIに実装を任せながら、Rustを学び続けたい。「Rust Learning Lab」を作りました

はじめに 『Building Evolutionary Architectures, 2nd Edition』を読みました。要件や技術が変わり続ける中で、システムの設計をどう変えていくかを扱った本です。部品をどう分け、どうつなぎ、どこへデータを置くか。ここでいうアーキテクチャは、そうした全体の構造を指します。1か所を直すだけで済むか、ほかの部品や担当チームまで巻き込むかにも関わります。 中心となるのは、守りたい性質を確かめる「フィットネス関数」です。新しい機能が動くだけでなく、応答が遅くなっていないか、必要なセキュリティを保てているかも、日々の変更の中で確かめる。本書は、その検査の仕組み、変更…

AIに実装を任せると、設計の仕事はどう変わるか - Building Evolutionary Architectures, 2nd Edition の読書感想文

はじめに Codex CLIには、会話を要約する /recap、出力をコピーする /copy、会話全体を書き出す /export があります。いずれも会話に蓄積された情報を扱う機能ですが、対象と用途が異なります。 この記事では、3つのコマンドの役割と、関連する /compact・/status・/diff との違いを整理します。要約、コピー、保存で何が得られるのか。現在のコードや検証結果は、どこで確かめるのか。この区別を押さえると、作業の再開やPRの説明に必要な情報を選びやすくなります。 会話の要約、出力のコピー、会話全体の保存 3つのコマンドは、扱う情報の範囲で分けられます。 コマンド 扱う…

Codexを使うなら、/recap・/copy・/exportを押さえておきたい

はじめに 誰かの「やってみたい」に加わることは、仕事の中でも外でも、人生を豊かにすると考えています。人の誘いに応じて、自分だけでは選ばなかった場所へ行き、会わなかったはずの人と話す。興味のなかったものを、そこで面白く感じることもある。自分の関心だけで選んでいたら、選ぶものはだんだん似てきます。 それなのに、のる前は面倒です。予定を空け、知らない場所へ行き、慣れない人と話す。楽しめるかは分からないのに、手間は先に見える。今日はやめておこう。次に面白そうなものがあったら。その判断は一度ずつならもっともでも、繰り返していると、自分に何が起きるのでしょうか。 誘いを一度断っても、その日はいつもどおりに…

おい、のっていけ

はじめに Codexが修正している途中で、「なぜ、その判定を変えるのか」と聞きたくなることがあります。理由を知りたいだけなのか、その変更を止めてほしいのか。途中で送る一文にも、別の目的があります。 長い仕事を続ける /goal、途中の質問を分ける /side、実行中の指示変更と予約送信。それぞれ、作業を続ける条件、質問する会話、指示を送るタイミングを指定する操作です。9月のCLI更新では、下書きを残したままCodexからの質問へ答える機能も加わりました。 認証処理を直す仕事で考えてみます。修正は続けてほしい。でも、期限の判定については説明を聞きたい。必要なら仕様を決め直し、Codexへ変更を指…

Codexを使うなら、/goalとサイドチャットを押さえておきたい

はじめに Codexへ同じ種類の依頼を繰り返していると、会話を開いて文章を貼り付ける操作を省きたくなります。変更概要を作る、ログを整理する、確認すべき点を一覧にする。入力と出力が見えている仕事なら、codex execで既存のCLIの流れへ組み込めます。 JSONの形が正しくても、調査が成功したとは限りません。対象を読めなかった結果が「問題なし」の空配列になれば、後の処理は失敗に気づけません。この記事では、実行中のイベント、最後の回答、実行そのものの失敗を分けて受け取ります。 learn.chatgpt.com まず単発の仕事を渡し、次にJSONLのイベントと最終JSONを分けます。その後、保…

Codexを使うなら、codex execと構造化出力を押さえておきたい

はじめに 毎朝、前日に変わったコードを確認したい。レビュー待ちのPRも見に行きたい。繰り返す仕事には、手順が分かっていても、始めるのを忘れる問題があります。Codexの定期タスクを使うと、予定した時刻にその仕事を始められます。 毎朝同じ文章を送っても、前回の会話や対象ファイルがなければ、同じ仕事にはなりません。予定どおり始まっても、必要な情報を読めずに終わることがあります。実行する時刻と一緒に、何を渡して始めるかを決めます。 ここでは、ローカルプロジェクトの変更を朝に確認するタスクを作ります。ChatGPTデスクトップアプリ内のCodexから利用し、管理画面の Scheduled で予定と実行…

 Codexを使うなら、定期タスクを押さえておきたい

はじめに 会話を分岐しただけでは、ファイルは分かれません。修正案を2通り試していても、同じディレクトリを書き換えているなら、片方の変更はもう片方からも見えます。会話の中では別案でも、ディスク上では同じ実装を直している状態です。 Codexでは、会話の分岐にWorktreeを組み合わせ、作業場所も分けられます。共通の調査から別案を試し、それぞれの差分を比較できます。取り込む変更が決まったら、不要になった作業場所も片付けます。 Claude CodeのAgent viewの記事では、並行する仕事の編集場所をWorktreeで分け、最後に変更を統合する話を書きました。今回の主題は、Codexから会話…

Codexを使うなら、Worktreesと会話の分岐を押さえておきたい

はじめに 同じ仕事を頼むたびに、前の会話からうまくいった指示をコピーすることがあります。その手順を残す場所として、Claude Codeの記事ではAgent Skillsを紹介しました。続くPluginsの記事では、社内で共有するSkillをプラグインにまとめる方法を書きました。配布した後も更新が届くところまで管理します。今回はCodexで同じことをするために、Skillを作る基準と、Codex固有の配置・呼び出し方を考えます。 syu-m-5151.hatenablog.com syu-m-5151.hatenablog.com PR説明を頼んだときは使ってほしいけれど、変更方針を相談してい…

Codexを使うなら、SkillsとPluginsを押さえておきたい

はじめに これまで、settings.json、CLAUDE.md、Commands、Hooks、Subagents、Skillsについて書いてきました。それぞれ設定すると、毎回説明することを減らせます。その次に困るのが、直した設定を、使っている環境へ届け続けることです。個人的にPluginsで嬉しいのは、自分のSkillをパッケージとして管理できることです。Skillを配布しても、その後の更新を忘れてしまうので。 たとえば、変更の概要を書くSkillを3つのリポジトリへコピーしたとします。1つで説明を改善したら、残り2つも更新する。Hooksも一緒に渡したいなら、設定ファイルへ追記する場所を…

 Claude Codeの Plugins は設定したほうがいい

はじめに AIを使って仕事が楽になった、という人は定期的に現れます。どこかの偉そうな人から、エージェントに任せれば人は楽になる、と言われる。けれど、複数のエージェントを起動すると、減っているのは考える時間です。 セッションごとの入力待ちに答え、別worktreeの差分を読み、終わった変更を同じ状態で動かす。仕事の量が消えたわけではなく、労働密度が上がっていました。1つのターミナルを見続ける辛さとは、別の辛さがあります。 Agent viewは、この辛さを消す機能ではありません。複数セッションの状態を一覧し、入力を求めている仕事へ移るための機能です。セッション間通信は、決まったことを別のセッショ…

Claude Codeの Agent view とセッション間通信は使ったほうがいい

はじめに Codexにテストを実行してほしいのに、依存パッケージの取得や書き込みで止まることがあります。そこで権限を広げると、今度はどこまで実行できるのかを説明しにくくなります。確認画面の多さだけを見て設定すると、必要な権限も分かりにくいままです。 権限プロファイルでは、ローカルのコマンドが触れるファイルや通信先をまとめます。Rulesでは、コマンドの引数列から許可・確認・禁止の判断を決めます。Claude Codeの権限設定と比べると、「どの操作を許すか」と「どの範囲なら任せるか」を分けて考える意味が見えてきます。この記事では、その設計の違いを押さえてから、テストが止まった場所と直す設定を順…

Codexを使うなら、権限プロファイルとRulesを押さえておきたい

はじめに Codexで設定を残す場所は、主に2つあります。config.tomlは実行環境を、AGENTS.mdは仕事の進め方を決めます。 learn.chatgpt.com config.tomlにはモデルや推論の強さなど、実行時の条件を書きます。AGENTS.mdには検証方法や作業上の制約を書きます。別のファイルの設定が優先されたり、起動場所によって指示が読み込まれなかったりするため、保存した内容と実際の動作を照合します。 設定の優先順位、起動場所、読み込まれる指示を確認して初めて、同じ条件でCodexを使えます。この記事では、まず2つの役割を分け、次に設定の読み込み順とAGENTS.md…

Codexを使うなら、config.tomlとAGENTS.mdを押さえておきたい

はじめに 「今週は検証環境が使えない」と伝えた文が、来月の会話にも残っている。期限のある事情を覚えているだけなのに、いつの間にか恒久的な手順になる。そうなっていたら困ります。覚えてくれることと、今も正しいことは別です。 以前のモデルが何度も間違えたために足した指示も、モデルを替えた後まで同じ書き方で必要とは限りません。消してよいのか、残すべきなのか。その判断をしないまま、設定だけが増えていきます。 昨日の記事では、/skill-doctor でSkillsの使われ方を調べ、モデル更新時に指示を見直す話を書きました。今回は、その続きを .claude/rules/ とAuto memoryで考え…

Claude Codeの Rules と Auto memory は、書きっぱなしにしないほうがいい

はじめに 2025年12月に「Claude Codeの Agent Skills は設定したほうがいい」という記事を書きました。必要な手順を必要なときに読み込ませる仕組みとして、Skillsを紹介した記事です。ただ、後半では設定が増えるほど管理が難しくなる話もしました。どれが使われているのか。似た説明のSkillが、互いの出番を奪っていないか。 syu-m-5151.hatenablog.com 今回は、その続きです。Skillsをいくつも設定した人には、まず /skill-doctor を紹介したいです。設定を増やす前に、今ある設定の使われ方を見られます。 /skill-doctor はv2…

 Claude Codeの Agent Skills は、ときどき見直したほうがいい

Forkwell Library #133。書籍の5ステップを紹介し、AIとともに仕事を終え、次の判断を変える進め方を考える。https://forkwell.connpass.com/event/405587/

おい、エージェントを使って終わらせろ

技術的負債に向き合うConference 2026。AIによって変わる実装の費用、判断の負担、学び方を、オニオンモデルの5層と3つの負債から考える。概念のどこを捉え直し、エージェントとどんな開発へ進むかを語る40分。

AI時代の「技術的負債」の変質ー概念の終焉と再解釈、エージェントと共に向かう先

はじめに 『おい、とりあえず終わらせろ そうすれば「動けない自分」が変わるから』が、ダイヤモンド社から発売されました。 【DL特典付】おい、とりあえず終わらせろ そうすれば「動けない自分」が変わるから（特典：生成AIにおけるSkillとは何か データ配信）作者:nwiizo（ぬうぃぞう）ダイヤモンド社Amazon 初めて商業出版する自分の単著は、技術書になると漠然と思っていました。技術の仕組みや使い方を詳しく書くか、『達人プログラマー』みたいな、プログラマーの判断や仕事の進め方についての本を書く。そういうことに憧れていました。 それが、『おい、とりあえず終わらせろ』になりました。プログラマーに…

本を書きました。本だからできたこと、これからできること

はじめに ディレクトリの中身を一覧にしても、目的のファイルがすぐ分かるとは限りません。似た名前の画像を見比べる、PDFの内容を確かめる、複数の場所からファイルを集める。こうした作業では、名前を検索するだけでなく、中身を見ながら選ぶ画面が役に立ちます。 Yaziは、その画面をターミナルに用意するファイルマネージャーです。Rustで実装され、キーボードを中心にディレクトリ移動、プレビュー、複数選択、コピーや移動を操作できます。文字端末の中で画面を描く、TUIと呼ばれる種類のアプリケーションです。 特徴は画像を表示できることだけではありません。プレビューの準備中にも別のファイルへ移動できるよう、処理…

Yaziとは何か。ファイルを探し、確かめ、操作するTUIの仕組み

生成AIによって開発者の指は光の速さで動いている。なのに、リリースは相変わらず「来期のどこか」。では、犯人は AI なのか？ AI がコードを爆速で吐き出したあと、その成果物が「PdM 待ち」「デザイン待ち」「QA 待ち」「法務待ち」「偉い人の気分待ち」という職能ごとの待合室を巡り、気づいたら実装時間の10倍を待ち時間に費やしている——そんな光景に見覚えのある方、全員がこのスライドの対象読者です。本資料では「実装が速くなるほど、職能の壁がボトルネックとして浮き彫りになる」という不都合な真実を直視し、役割の境界線をなぞるのではなく、価値が流れる経路そのものを設計するという発想でプロダクト開発を組み立て直す方法を語ります。なお登壇者の nwiizo は、ネット上では「常に何かを読んでいる怖そうな人」として認識されているようですが、実物はめっぽう気さくで、話しかければ普通に喜びます。パブリックイメージと実装の間にギャップがあるのは、プロダクトや組織だけではないようです。📍 Product Engineering Conference 2026 https://product-engineering.jp/2026/ 登壇資料

AIで実装は速くなった。なのにプロダクトは速くならない。職能の壁を越えて価値のフローを設計する

このたび、はじめてマイナビ出版様より翻訳書を出版させていただくことになりました。原書は『Effective Platform Engineering』、邦題は『実践 プラットフォームエンジニアリング』です。発売日は2026年8月24日、いよいよ来週です。ぜひご予約いただけると嬉しいです。https://book.mynavi.jp/ec/products/detail/id=151794https://amzn.asia/d/0d4hfBcxこれに合わせて、「『実践 プラットフォームエンジニアリング』翻訳者と考える、開発者体験を加速する基盤のセルフサービス化」というイベントに登壇させていただきます。いつも機会をくださる Findy 様には感謝しています。セッションタイトルは「35分でわかるEffective Platform Engineering」です。書籍を読む際のガイドラインとして機能する内容になればと思っています。

35分でわかるEffective Platform Engineering

2026年8月7日に『セキュアAPI』翻訳者と考える、設計段階から組み込むセキュリティ というイベントで登壇します。https://levtechlab.connpass.com/event/399260/

20分でわかるセキュアAPI

**「バグを直す」のはもうやめませんか。**あなたのシステムにもいませんか。`is_paid = true` なのに `payment_id` が null という、支払ったのか払ってないのかシュレディンガーの注文。`status = "verified"` なのに `verified_at` が存在しない、検証された記憶のない検証済みユーザー。彼らはバグではありません。**型が「そういう存在」を許可してしまった、正規の住人**です。本セッションの主張はシンプルです。型は壁である。コンパイラのご機嫌取りでも、IDEの補完を効かせるための飾りでもなく、「なり得ない状態」を物理的にこの世に存在させないための壁。バグはテストで捕まえるものではなく、**そもそも書けなくする**ものです。実装言語はRustです。「関数型まつりでRust？」と思ったあなた、安心してください。代数的データ型、イミュータビリティ、パターンマッチ——中身はほぼ関数型の道具箱です。Rust未経験でも大丈夫なように、登場する言語仕様はその場で解説します。扱うのは以下の4パターン:- 状態ごとに型を分ける: 検証前の注文で価格計算しようとした瞬間、コンパイラに止められる世界- newtypeパターン: `CustomerId` と `OrderId` の取り違えを、レビュアーの目ではなくコンパイラが検出する- Smart Constructor: 「※必ずvalidateしてから使ってください」というお祈りコメントの卒業- Make Illegal States Unrepresentable: フラグ×Optionの組み合わせ爆発を、代数的データ型で根絶するおまけに、AIコーディングエージェント時代の話も。AIはコメントを平気で読み飛ばしますが、コンパイルエラーだけは無視できません。**型は「お願い」ではなく「壁」。** 人間にもAIにも等しく効く、最強の防壁の築き方を持ち帰ってください。DDDの知識は不要です。必要なのは「もうバグ調査で週末を潰したくない」という気持ちだけ。https://2026.fp-matsuri.org

型は壁、Rustでもバグを直すな、表現できなくせよ

前作では「何を守るかを決める」という視点から、非機能要件・分散システム・トレードオフの考え方を紹介しました。「面白そうだけど、実際のコードはどうなっているの？」——この続編はその問いへの答えです。概念として語っていたことを、今度はコードの上で見ていきます。リトライはどう書くか。タイムアウトをどこに置くか。冪等性はどう担保するか。「なんとなく知っている」を「動くコードで理解している」に変えることを目指した発表です。ただし、コードを読む会ではありません。一行一行を追うのではなく、「なぜそう書くのか」「何を諦めて何を得ているのか」に焦点を当てます。設計の判断はコードに刻まれている——その読み方を一緒に考えます。前作を見ていなくても楽しめますが、見ていると2倍楽しめます。知らんけど。そして今作も、20分で終わらせるのはとても難しい。前作https://speakerdeck.com/nwiizo/sisutemuha-dong-ku-dakedeha-zu-rinai-fei-ji-neng-yao-jian-fen-san-sisutemutoredoohunoji-chu

システムは「動く」だけでは足りない 実装編 - 非機能要件・分散システム・トレードオフをコードで見る

ソフトウェアエンジニアの仕事を、「コードを書く人」ではなく「何を守るかを決める人」の部分を紹介した発表です。非機能要件、分散システム、トレードオフを題材に、速さ、正しさ、止まりにくさが引っ張り合うなかで、日々どう判断しているのかをできるだけ身近な例で話しました。技術の基礎を知るための資料でありながら、この仕事そのものの面白さに触れてもらうための発表でもあります。唯一の問題は20分で終わらせるのがとても難しい。続編https://speakerdeck.com/nwiizo/sisutemuha-dong-ku-dakedehazu-rinai-shi-zhuang-bian-fei-ji-neng-yao-jian-fen-san-sisutemutoredoohuwokododejian-ru

システムは「動く」だけでは 足りない - 非機能要件・分散システム・トレードオフの基礎

2026年4月10日、「設計ナイト2026」というイベントで「アーキテクチャモダナイゼーションとは何か―技術・事業・組織で大事なこと」というタイトルの登壇をしました。まずお伝えしたいのは、このスライドを20分に収めようとしていた人間がいるということです。私です。前日、翻訳作業をほぼ徹夜で行っていました。朝、体調が完全に崩壊した状態で目を覚まし、それでも資料を修正しようとパソコンを開きました。起き上がったら更に悪化しました。起き上がらなければよかった、という感想だけが残りました。2026年、我々にはAIエージェントという心強い味方がいます。しかし彼らはインターネットがなければ何もできません。体調が崩壊した人間と、Wi-Fiのない空間に置かれたAIエージェント。これは個人の怠慢ではなく、時代とタイミングの悲劇です。資料は中途半端なまま、「会場にWi-Fiがあるから現地で仕上げればいい」という、締切前夜の人間だけが信じられる種類の楽観を胸に家を出ました。仕上がりませんでした。結果として、当日は前日までの暫定版の資料で発表するという形になりました。すべて言い訳です。本当に申し訳ありませんでした。削減途中なスライドもありますがこちらでは完全版の資料を提供いたします。ただ、こちらのほうが良いということでは決してありません。当日あの場で聴いてくださった皆さんの時間のほうが、何倍も価値があります。なお、まったく関係ありませんが、私の誕生日は来月5月10日です。設計ナイト 2026 https://kichijojipm.connpass.com/event/383313/書籍『アーキテクチャモダナイゼーション ―組織とビジネスの未来を設計する』は好評発売中です。https://amzn.to/3ZR5Bgv

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

自分の環境やマインドが変わったタイミングで社内で共有会をしています。やる気がある時に不定期で。

【社内勉強会】新年度からコーディングエージェントを使いこなす - 構造と制約で引き出すClaude Codeの実践知

かつて、ある愚かなエンジニアがいた。彼は意気揚々とマイクロサービス移行という壮大な計画を立ち上げ、2年という歳月を費やした。しかし完成の暁に彼を待ち受けていたのは、栄光でも賞賛でもなく、すでに陳腐化した設計と、ふたたび着々と積み上がる技術的負債という名の瓦礫の山であった。なんたる業か。なんたる滑稽か。nwiizoによるこのセッション「技術的負債の泥沼から組織を救う3つの転換点」は、そのような哀れな魂たちへの救済の書である。2026年3月4日、Engineering Management Conference Japan 2026のホールBにて、40分間にわたり語られる。氏が説くに、モダナイゼーションの失敗とは技術の失敗にあらず。組織構造を軽視し、意思決定を技術者のみで完結させ、ビッグバン式の大改革に酔いしれた者たちが、コンウェイの法則という冷酷な摂理によって粛清される、それだけのことである。古い組織は、新しいシステムを確実に、かつ静かに、腐らせていく。ならばいかにすべきか。氏はAMETという概念を持ち出す。答えを与えるチームではなく、組織が自ら考えられるよう手助けし、最終的には己の存在意義を消滅させることを目標とするチームである。なんと殊勝な自己犠牲の精神であろうか。EventStormingやWardley Mappingを駆使し、組織の内なる知性を呼び覚ます。また、経営層に「技術的負債がやばい」と訴えても暖簾に腕押しであることは、諸君もよくご存知であろう。Core Domain Chartによって複雑性を可視化し、それを「年間XX億円の機会損失」という経営者の母語に翻訳してこそ、初めて投資という名の援軍を呼び込むことができるのだ。そして何より肝要なのは、壮大な計画を立てないことである。3〜6ヶ月で成果を示せる小さな戦場を選び、勝利を積み重ね、信頼を醸成していく。Team Topologiesを携え、技術・組織・文化を同時に変革していく。レガシーシステムという名の泥沼で溺れかけている諸氏よ、このセッションはあなた方のために存在する。書籍『アーキテクチャモダナイゼーション ―組織とビジネスの未来を設計する』は好評発売中です。https://amzn.to/3ZR5Bgv🔗 https://fortee.jp/emconf-2026/proposal/cd55bd21-d2ef-448c-af5c-e02f0994e4ae🔗 https://x.com/emconf_jp🔗 https://2026.emconf.jp/

技術的負債の泥沼から組織を救う3つの転換点

3-shake SRE Tech Talk 特別回「アーキテクチャモダナイゼーション」にて、「30分でわかるアーキテクチャモダナイゼーション」というタイトルで登壇しました。https://3-shake.connpass.com/event/382086/書籍『アーキテクチャモダナイゼーション ―組織とビジネスの未来を設計する』は好評発売中です。https://amzn.to/3ZR5Bgv同日に発表した「意志を実装するアーキテクチャモダナイゼーション」の資料も公開しています。https://speakerdeck.com/nwiizo/yi-zhi-woshi-zhuang-suruakitekutiyamodanaizesiyon

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

Developers Summit 2026（デブサミ2026）にて、「意志を実装するアーキテクチャモダナイゼーション」というタイトルで登壇しました。https://event.shoeisha.jp/devsumi/20260218/session/6454書籍『アーキテクチャモダナイゼーション ―組織とビジネスの未来を設計する』は好評発売中です。https://amzn.to/3ZR5Bgv同日に発表した「30分でわかるアーキテクチャモダナイゼーション」の資料も公開しています。https://speakerdeck.com/nwiizo/30fen-dewakaruakitekutiyamodanaizesiyon

意志を実装するアーキテクチャモダナイゼーション

2025年12月5日に「おい、テックブログを書け」という登壇をした。「おい」である。命令形である。30分間、人前に立って「書け」と言い続けるという、冷静に考えるとなかなか傲慢な振る舞いをしてきたわけだが、登壇資料を作っている最中、ふと気づいてしまった。書けと言っている自分は、なぜ書いているのだろうか、と。技術ブログを書くことについて語ろうとすると、それは私が「書いてきた」ことを晒すことに他ならず、AIとの付き合い方を語ろうとすると、それは私が「どう仕事をしているか」を開陳することと紙一重になる。そうなると聞いている側からすれば、こいつは結局、自分の話がしたいだけなのではないか、登壇という大義名分を得て気持ちよく自分語りをしているだけなのではないか、と思われても仕方がない。いや、実際そうなのかもしれない。そう見られることへの嫌悪感と、そう見られまいと振る舞う自分への嫌悪感が同時に存在していて、どちらに転んでも結局イヤなやつなのである。しかし登壇というのは厄介なもので、「書け」と命令するからには、自分がなぜ書いてきたのかを明かさなければ説得力がない。説得力のない登壇ほど空虚なものはない。空虚な登壇をする自分を想像して、それはそれで耐えられない。結局、自己開示から逃げられない構造になっている。なんという罠だろうか。身体性という言葉を使った。AIに記事を書かせることについて話した。私の答えは明確で、記事はほとんどAIに書かせている、しかし価値の源泉は私にある、と。私が素材を提供し、AIが構造化し、私がレビューして調整する。編集者としてのAI。この協働こそが現代の執筆だと、そう話した。話しながら、これは本当にそうだろうかと自分を疑う自分がいて、でもそういう迷いごと引き受けて喋るしかないのだった。まず自分のために書け、結果として、それが誰かを救う。そう締めくくった。https://forkwell.connpass.com/event/377267/https://syu-m-5151.hatenablog.com/archive/category/%E3%81%8A%E3%81%84%E3%80%81自宅からの昼登壇だったので、終わってから昼飯を食べに外に出た。参考書籍として紹介した本をもう一度読み返そうと思って、鞄に入れてきていた。店に向かう道すがら、本を開く。

おい、テックブログを書け

2025年9月30日（火）、「バイブコーディングもくもく会 #03」というイベントで登壇することになった。https://aimokumoku.connpass.com/event/368935/正直に言うと、このイベントがどんな空気感なのか、まだ全然掴めていない。ゆるい感じなのか、ガチな感じなのか。笑いを取りに行くべきなのか、真面目にやるべきなのか。そういう「場の空気」みたいなものが事前に分からないのは、けっこう怖い。だから、とりあえず色々なパターンを想定して準備している。要するに、どんな状況になっても対応できるように、という保険をかけまくっているのだ。我ながら、慎重すぎるかもしれない。ブログとGithubはこちら。https://syu-m-5151.hatenablog.com/https://github.com/nwiizo一応、置いておく。見られるのは恥ずかしいけど、見られないのも寂しい。そういう矛盾した感情を抱えながら、当日を迎えることになりそうだ。Marp の資料はこちらです。https://github.com/nwiizo/3shake-marp-templates/blob/main/slides/2025/vibe-coding-continuous-deployment.md

バイブコーディングと継続的デプロイメント

2025年9月10日（水）、「Rustの現場に学ぶ〜Webアプリの裏側からOS、人工衛星まで〜」というイベントで登壇させていただきます。https://findy.connpass.com/event/359456/他の登壇者の話が聞きたすぎるけど調整能力の圧倒的な不足で登壇したらすぐに帰らなければなりません。今回の発表内容のベースとなったのはこちらのブログです。- 「RustのWebアプリケーションにオブザーバビリティを実装するインフラエンジニアのための入門ガイド」

Webアプリケーションにオブザーバビリティを実装するRust入門ガイド

2025年9月5日（金）、台風接近という悪天候の中でしたが、「CNCJ: コーディングエージェント × セキュリティ ミートアップ」に登壇させていただきました。天候の影響で現地参加が難しい方も多い中、オンラインでの参加や配信により、多くの方にお聞きいただくことができました。### 📍 イベント情報- 開催日: 2025年9月5日（金）- イベント詳細: CNCFコミュニティページ### 📹 録画・資料公開予定- 録画: CNCJのYouTubeチャンネルにて後日公開予定- 発表資料: Connpassページに掲載予定### 📝 関連ブログ今回の発表内容のベースとなった考え方については、こちらのブログ記事でも詳しく解説しています：- 「2025年夏 AIエージェントシステムに対する考え方」台風の中、ご参加・ご視聴いただいた皆様、ありがとうございました。

2025年夏 コーディングエージェントを統べる者

「 転職したらMCPサーバーだった件」というタイトルで登壇したことがある。本日は「JAWS-UG SRE支部 #13 つよつよSREの秘伝のタレ」というなんとなく強そうなイベントで登壇しました。🔍 イベント詳細:- イベント名: JAWS-UG SRE支部 #13 つよつよSREの秘伝のタレ- 公式URL: https://jawsug-sre.connpass.com/event/358781/- ハッシュタグ: https://x.com/search?q=%23jawsug_sre&f=live- 参考資料①: https://speakerdeck.com/nwiizo/zhuan-zhi-sitaramcpsabadatutajian

転職したらAWS MCPサーバーだった件

「Dapr の概念と実装から学ぶ Observability への招待」 というタイトルで登壇します。https://event.cloudnativedays.jp/o11y2022/talks/1382:embed:cite セッション概要Dapr は CloudNative な技術を背景に持つ分散アプリケーションランタイムです。本セッションでは Dapr の Observability に関する各種機能と、その実装について解説していきます。さらにスリーシェイクの Dapr と Observability への取り組みに関してもご紹介します。Dapr の機能でカバーできる点...