誰向け：AI時代のエンジニア初学者の感想が気になる人
AI駆動開発（＝AI にコードを書かせながら進める開発）の知見を軽く入れたい人や「越境」「決定負荷」みたいな言葉に興味がある人。
書いている私：2025年9月からエンジニアリングを独学している1年目です。
わかること：
- 3本の登壇（決定負荷／越境／海賊と建築家）の感想
- 「海賊と建築家」というモデルの出どころ（一次ソース付き）
- AI時代における、エンジニアとしてのエンジニアリング
きっかけ
2026年9月1日、Algomatic 主催の勉強会「現場で効いたAI駆動開発の実践知」に行きました。
登壇は3本。
| 誰 | 会社 | 話のテーマ |
|---|---|---|
| 望月さん（PdM/開発者） | Ubie株式会社 | AI で成果を出す仕組みづくりと越境 |
| 北浦さん（Lead SRE） | KDDIアジャイル開発センター | AI を使ったら越境せざるを得なくなった話 |
| 坂本さん（VPoE） | 株式会社Algomatic | 決定負荷（＝決めることの疲れ）をどう減らすか |
知識は体感で覚えるタイプなので、ほぼ手ぶらで参加するパワースタイルの私が
メモ帳に書いたのがこちら↓
・自分が作り続けてる限りボトルネックって考え方いいね。
・"すぐ使えるようにして配る"いい取り組み。
・実装したときの、説明責任果たせるのか。
・隣の工程は自分の仕事じゃないだとAIの効果は弱くなるよね。
・魔法の言葉 "他と同じにして" 決めてないことをAIに任せちゃお
・海賊と建築家？
Ubie株式会社 ｜ 望月 駿一 さん
AIから事業に効く成果を引き出す舞台装置という考え方
〜AI駆動開発における越境と実践〜
・Ubieさんでは踊り手と舞台装置という考え方があること
・海賊と建築家の話
が印象に残りました。
Ubieさんの 舞台装置とは
課題を見つけ、価値を検証・提供する人を踊り手、その人が最大限力を発揮できる仕組みを作る人を舞台装置と呼びます。
海賊と建築家 とは
下記をご覧ください
Dan Shipperさんという方が提唱した、エンジニアリングの比喩
2026年3月22日に X に投稿されていたポストに辿り着きました。
つまりは：
| 海賊 | 建築家 | |
|---|---|---|
| 仕事 | 価値のある機能をとにかく速く出す | 海賊が見つけた「製品の表面」を、信頼できる構造に作り直す |
| 速度 | 速い | ゆっくり、根拠を詰めながら |
| 道具 | vibe coding | vibe coding（同じ） |
| 要る時期 | 最初から | PMF の後 |
ということらしいです。
どちらも、価値のあるロールである事は大前提でお話をしていました。
ですが、向いている方向は同じでも、その価値そのものの質が違ったりすることもあるんだなと思いました。
まだ感想ありますが、このモデルを頭に置いて、残り2本の話を追います。
KDDIアジャイル開発センター株式会社 ｜ 北浦 智也 さん
越境は私の中でデフォルト装備でした！
というか、そもそも越境とは漠然とふわっと意味はわかっても、自分の口で説明できないなと思ったので調べた
エンジニアにとっての 越境とは
自身の専門領域（開発言語、職種、あるいはITと他業種など）の境界を飛び越えて、新しい分野に挑戦するキャリアや働き方（諸説あるかも）
とのこと。
そもそも私は、出身が音楽業界なので、越境も越境です。
学び始めたタイミングが1年ほど前で
「AIに任せる事と、人間が負わなければいけない責任の境界」
を最初から考える習慣が付いていました。
そのため初めから、フロントエンド・バックエンド・インフラみたいにロールで自分を区切る発想を、学習の時点で持っておらず、境界がないのでそもそも、越境という発想すらなかったです。
（本当はどこからどこまでフロントエンドで、バックエンドで〜って曖昧だったのは内緒）
が、ここで、エンジニアにとっての越境とはを知る機会を経て、今度は意識して、越境することの楽しさと大事さを感じました。
AI-DLC について軽く
北浦さんのチームは、開発プロセスをスクラムから AI-DLC（＝AWS が提唱する AI 駆動開発のライフサイクル）に移行したとお話をされていました。
AWS Summitが初見だったので、再度調べてみた
| セクション | やること |
|---|---|
| Inception | 作るものを決める |
| Construction | 実装できるレベルまで詰めて、作る |
| Operation | 運用する |
大事だなと思った Inception のこの一文。
判断に必要な人が、その場に集まるようにしている。PO やステークホルダーをモブに招き、AI を使って意思決定を行う。「待つ」から「呼ぶ」へ
ここには並々ならぬビジネススキルがありそう
それに、私のようなまだ能力（チカラ）を持たない人間が、要のステークホルダーを呼びつけるハードルの高さがありますね。
ここは、信頼を勝ち取る別の話になりそう。
AI は増幅器である
仕様駆動開発（＝仕様を先に書いて、それを元に AI に実装させるやり方）は
AI-DLC（Construction）の中身として出てきました。
AI は「増幅器」である。与えられたものを増幅する装置であって、ゼロから正解を当てる装置ではない。
元（素）（目的・制約・仕様）が無ければ、出力はギャンブルである。
↓おまけ↓
SRE 視点の補足：良いシステム設計とは
SREが好きな私は、北浦さんの知識や技術を日々盗もうとしています！そこで余談にある
「良いシステム設計とは、不可逆な部分をできるだけ小さく削り出し、そこにいま分かっている事実を集中投下し、残りは間違えても安く直せる形にしておくこと」
や
「設計の話をしているつもりが、事業の話になるのはより本質的な議論ができている可能性が高い」
に首が千切れるほどの頷きを心で行いました。
ユーザー目線でどうあるべきなのか、ここに立ち返るのがどれだけ大事なのか身に沁みますね。
〜AI から Why を問われた〜
仕様を作ろうとすると、何が起きるか。
AI は HOW なら無限に出してくるが、WHY は一切持ってこない。
これも説明責任を果たすのに大事。
AIが実装したものを説明できないのは、ここから破綻していると言っても過言じゃないと思った。
AIを活用するメンタリティとエンジニアリング
- 隣の工程は自分の仕事じゃないというメンタリティだと、AIの効果は弱くなる
- AI-DLCやモブプログラミングなどのベストなプラクティス群の設計そのものが、エンジニアリングを育てるという相乗効果を生んでいるんだなと思った
- 越境そのものがプラクティスとなる可能性もなんだか見えた
株式会社Algomatic ｜ 坂本 一樹 さん
あの木の絵って有名なんやな
「Tree Swing Cartoons」
「作る側が頑張っても、そもそも作るものを間違えていたら価値は生まれない」
ってことらしいです。
軽く調べてみたら、なんやら私が生まれる前からある話っぽいですね驚き。
長い年月、ずっとこうして受け継がれているのは、どれだけ大事で、どれだけ難しいことなのかが伺えます。
エンジニアは、コンピューターと人間、どっちとも会話しなくてはならない翻訳者だと思いました。
意思の疎通と開発スピード
例として、代表的な2つの開発手法を比較していました。
- ウォーターフォール：最初に細かく決めてから作る
- アジャイル：細かく決める代わりに、早く触れるものを作って確かめる
Algomaticさんは、ここでもう一歩踏み込み
「じゃあ、もっと早く触ればいいじゃん」。
目から鱗とはまさにこのこと。
私はアジャイルこそ最速だと思っていたので、それ以上があるのかと
仕様駆動開発でかつ、画面（フロント）を先に作る。
画面が先にあるから、全員がモノを見て確認できる。
全員が意思決定者になる
AIを使って決定負荷を分散しよ。
AIを使う＝デジタリーな用途
と勝手に決めつけていた節が心のどこかにありましたが
対個人の越境へと導くツールにもなりうるのだなとも思いました。
また、スライドにはこう書いてありました。
全員が意思決定者になることで自分事化して愛着も湧く
「自分事化」って、どんな会社でも伝えたくて、感じて欲しい、言葉だと思うんです。
経営者が「働く人にそう思っていてほしい」と願う言葉。
坂本さんはそれを、願うのではなく、仕組みで起こしていました。
決定を配れば、一人ひとりが「自分が決めた」部分を持つ。
自分が決めたものには責任感が生まれるし、愛着も湧く。
AI で画面を先に作って、人の責任感と愛着を育てている。 ここに脱帽しました。
決めないことは AI に任せる
決めないことは AI に任せよう。
魔法の言葉は「他と同じにして」。
家に帰って個人開発のアプリを管理してるClaudeCodeにこう言いました
【ベストプラクティスに則って、他と同じにして】
- 人間同士のズレはどんなに時代が進んでも起きるもの
- エンジニアは、人間とAIの翻訳者
- AIを使って、個を越境させる仕組みを作る
- 【他と同じにして】という最強のプロンプトを獲得
まとめ
私からしたら僥倖
AI時代に突入した頃、ClaudeCodeでいうとopus4.5リリース直後頃に、知識を入れ始めました。
- そんなおかげで "海賊と建築家" のようなロールがきっちり分かれている意識もさほどなく学習を進めることができている点。
- AIは増幅器であり、越境プラクティスやAIからのWhyがデフォルトステータスである点。
- AIを活用した決定負荷を分散術、特に、価値を生み出すために自動的に越境するような仕組みや、決めないことは思い切ってAIに任せる点。
それぞれ、とても勉強になりました。
AI-DLCやモブプログラミング、越境術などのベストなプラクティス群。
それらの設計そのものが、エンジニアリングを育てるという、相乗効果を生んでいるのかもしれないと思った。
AI時代において 越境 は、デベロッパーなら持つべき、マインドセットに近いのかもしれない。
ということなのかも（図がわかりにくいですね）
越境することにより、チームが、個のエンジニアリングが向上していくという流れ、相乗効果を伝えたかった。
以下はClaudeCodeでまとめさせました。
今回の調査で知れたこと
- 海賊と建築家：Dan Shipper（2026-03-22）。海賊は価値のある機能を速く出す人、建築家はそれを信頼できる構造に作り直す人。道具は同じ vibe coding で、違うのは速度と要る時期（建築家は PMF の後）
- 踊り手と舞台装置（Ubie）：課題を見つけて価値を検証・提供する人と、その人が最大限力を発揮できる仕組みを作る人
- 越境：自分の専門領域の境界を越えること。私には最初から境界が無かったけど、意識して越える楽しさと大事さを知った
- AI-DLC：AWS 提唱。Inception → Construction → Operation の3つ。Inception のモブで「待つ」から「呼ぶ」へ
- AI は増幅器：元（目的・制約・仕様）が無ければ、出力はギャンブル
- AI は HOW を出し、WHY は持ってこない：WHY に答えられないコードは、説明責任を果たせない
- Tree Swing Cartoons：人間同士の認識のズレは、時代が進んでも起きる。エンジニアは人間と AI の翻訳者
- 「もっと早く触ればいいじゃん」：仕様駆動開発で、しかも画面を先に作る。全員がモノを見て確認できる
- 決定負荷の分散：全員が意思決定者になると、自分事化して愛着が湧く。AI は個を越境させるツールにもなる
- 「他と同じにして」：決めないことを AI に任せる魔法の言葉
- 越境はマインドセット：AI-DLC・モブ・越境などのプラクティス群の設計そのものが、エンジニアリングを育てる。AI 時代のデベロッパーが持つべきもの
参考
- 現場で効いたAI駆動開発の実践知: 越境を支える体制と仕組みづくり（connpass）
- AIを上手に使っていこうとしたら越境せざるを得なくなった話（北浦智也・Speaker Deck）
- 毎日同じシャツを着よう 〜AI駆動開発における決定負荷について〜（坂本一樹・Speaker Deck）
- Dan Shipper の X 投稿（2026-03-22）— 海賊と建築家の一次ソース
- AI & I（Dan Shipper がホストのポッドキャスト）— 本人による補足説明
- awslabs/aidlc-workflows（GitHub）
- Open sourcing adaptive workflows for AI-Driven Development Life Cycle (AI-DLC)（AWS DevOps Blog）
- 顧客が本当に必要だったもの（ニコニコ大百科）— Tree Swing Cartoons