AI 時代の Developer Experience — 競争力のあるエンジニアであり続けてもらうために

Claude 研修の講師をしていたとき、参加者のエンジニアから「AI 時代の Developer Experience（DevEx）の向上についてどう考えますか」と問われ、その場で考えを答えました。この問いに、フルリモート組織の CTO として、あらためて正面から向き合います。従来の DevEx とは何だったのか、AI で何が変わったのか、環境をどう与えるか。目指すのは、転職しても「あの会社出身は優秀だ」と言われる、市場で競争力を持ち続けるエンジニアを育てることです。

進捗報告はもう人間から要らない — AI 時代に人間が語るべきは未来だけ

過去と現在の進捗は、コミット・PR・CI・オブザーバビリティといった成果物にすでに刻まれていて、AI エージェントに聞けば要約が返ってきます。だとすれば、人間がわざわざ進捗を報告する意味は薄れる。人間にしか持てない情報は、まだどこにも書かれていない「未来」の側にある。フルリモート組織を率いる CTO の立場から、進捗報告という慣習を解体し、会議とレビューを未来中心に組み替える設計を考えます。

AI ファーストな開発組織への進化 - 2026 年に起きている 5 つの構造変化と実践ステップ

Block が AI 活用を理由に組織の 40% を再編し、Meta が AI ツール導入後の生産性データを元に組織を見直し、Atlassian が R&D 体制を刷新する。2026 年、テック業界では AI を起点とした組織進化が加速しています。本記事では、これらの動きから 5 つの構造変化パターンを抽出し、自組織で段階的に再現するためのステップを整理します。

AI Slopper — 方向性を理解できない人が AI ネイティブ開発で生み出すコスト

LLM や AI コーディングエージェントの進化で、コードを書く速度は上がった。一方で、プロジェクトやプロダクトの方向性を理解しないまま AI を回す人（AI Slopper）は、高速で AI Slop を量産する側になる。従来型の開発なら細かくディレクションすれば軌道修正できたが、AI ネイティブ開発では方向性のズレがそのままアウトプット量に増幅される。結果として AI Slopper への依頼コストは、依頼者が自分で AI を使うコストを上回り、AI Slopper に回る仕事は消えていく。

AI Vampire と 3〜4 時間労働論に懐疑的な理由 — 労働強度を毎日上げ続けるという選択

Steve Yegge が The AI Vampire で、新しい 1 日の労働時間は 3〜4 時間が sweet spot になると論じました。私はこの sweet spot 論に懐疑的です。AI とエージェントの進化に日々追随するには労働強度を上げ続けて慣らしていくほうが安全ですし、労働強度の高い人が AI をフル活用して長時間労働できてしまう以上、3〜4 時間側に均衡することはないと考えています。

[資料]「変化の時代で勝つための開発組織のあり方」株式会社Aiming 小林俊仁 氏

株式会社 Aiming 小林俊仁氏のスライド「変化の時代で勝つための開発組織のあり方」を紹介しました。

副業解禁にするメリット 〜 採用力向上、スキル向上、離職防止

副業解禁がエンジニア採用や離職防止にどう効くのかを、Engineering Manager 目線でまとめました。

1on1 にベストな日時は木曜午後3時から5時

『ヤフーの1on1』の「1on1 にベストな日時は木曜午後3時から5時」という説を紹介します。

Block「From Hierarchy to Intelligence」から学ぶ - 日本のスタートアップ CTO が考えるべき組織設計の転換点

Block が発表した「From Hierarchy to Intelligence」は、2,000 年にわたるヒエラルキー型組織の歴史を振り返りながら、AI が情報のルーティングを担うことで組織構造そのものが変わると主張しています。日本でスタートアップを経営する CTO の立場から、この論考の主張と実践的な示唆を整理します。

読書メモ『転職2.0　日本人のキャリアの新・ルール』村上臣（著）

村上臣氏の『転職2.0』を採用側の視点も踏まえて読んだ読書メモです。

読書メモ『クリエイティブ人事～個人を伸ばす、チームを活かす～』曽山哲人（著）

サイバーエージェント社の人事責任者・曽山哲人氏の『クリエイティブ人事』を読んだ読書メモです。

読書メモ『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』 株式会社VOYAGE GROUP監修

VOYAGE GROUP のエンジニア組織を扱った『Engineers in VOYAGE』の読書メモです。

読書メモ『爆速成長マネジメント』イラッド・ギル（著）

イラッド・ギル『爆速成長マネジメント』から、経営幹部の採用や取締役会、爆速成長期の組織構造について印象に残った箇所をまとめました。

読書メモ『リーダーの仮面――「いちプレーヤー」から「マネジャー」に頭を切り替える思考法』安藤広大（著）

安藤広大『リーダーの仮面』を読み、識学のマネジメント観について印象に残った箇所を引用とメモでまとめました。

読書メモ『未来を共創する 経営チームをつくる』鈴木義幸（著）

鈴木義幸『未来を共創する 経営チームをつくる』を読み、経営チームでの対話について印象に残った点をまとめました。

読書メモ『人月の神話』フレデリック・P・ブルックス，Jr.（著）

『人月の神話』からブルックスの法則、外科手術チーム、マイルストーン論などのメモをまとめました。

読書メモ『ＮＯＩＳＥ　組織はなぜ判断を誤るのか？』ダニエル・カーネマン（著）

ダニエル・カーネマン『NOISE』を読み、組織の判断に潜むノイズを減らすための知見をメモしました。

読書メモ『リモートワークの達人』ジェイソン フリード (著), デイヴィッド ハイネマイヤー ハンソン (著), 高橋 璃子 (翻訳)

『リモートワークの達人』を読み、リモートワーク運用や採用、コミュニケーションについて印象に残った箇所を引用と所感でまとめました。

読書メモ『科学的な適職』 鈴木祐（著）

『科学的な適職』を読み、仕事選びの大罪と徳目、心理的安全性など印象に残った箇所を引用と所感でまとめました。

読書メモ『できないとは言わない。できると言った後にどうやるかを考える』丹下大（著）

SHIFT 社創業社長 丹下大氏の著書を読み、内発的なモチベーションについて印象に残った引用と所感をまとめました。

読書メモ『小さな会社がITエンジニアの採用で成功する本　自社にピッタリの人材がみつかる』大和賢一郎（著）

小さな会社のエンジニア採用について、自社に合った人材の見極めと定着のポイントを引用と所感でまとめました。

読書メモ『経営者・従業員・株主がみなで豊かになる 三位一体の経営』中神康議（著）

『三位一体の経営』を読み、事業経済性、リスクテイク、集団意思決定、M&A について印象に残った箇所を引用と所感でまとめました。

読書メモ『突き抜けるまで問い続けろ――巨大スタートアップ「ビジョナル」挫折と奮闘、成長の軌跡』 蛯谷敏（著）

『突き抜けるまで問い続けろ』を読み、ビズリーチ / ビジョナルの要素分解や採用、草ベンチャー方式について所感をまとめました。

読書メモ『ビジョナリー・カンパニーZERO ゼロから事業を生み出し、偉大で永続的な企業になる』ジム・コリンズ（著）

『ビジョナリー・カンパニーZERO』を読み、リーダーシップやハリネズミの概念、イノベーションについて印象に残った箇所をまとめました。

読書メモ『他者と働く──「わかりあえなさ」から始める組織論』宇田川元一（著）

宇田川元一『他者と働く』の読書メモ。ナラティヴの溝と対話について印象に残った引用を整理しました。

読書メモ『若手育成の教科書――サイバーエージェント式　人が育つ「抜擢メソッド」』曽山哲人（著）

曽山哲人『若手育成の教科書』の読書メモ。サイバーエージェント式「抜擢メソッド」の要点を整理しました。

bosyu でエンジニア募集ページを作成するための調査まとめ

bosyu でエンジニア募集ページを作るために調査したサービス概要と参考記事、事例をまとめました。

エンジニア採用目的で Tech Podcast を始めました

エンジニア採用施策としてのスカウト・勉強会・技術ブログを振り返り、社内 Tech Podcast を始めた経緯をまとめます。

CTO のネクストキャリア — ユニコーン創業者が AI ラボへ移る潮流と、9 ステップの撤退設計

会社の作り方・資金調達・スケールの記事は何千とあるのに、辞め方を扱う記事はほとんどない。Super.com の共同創業者で CTO 兼 COO だった Henry Shi 氏は、そう書いて、9 か月かけて準備した自分の退任プロセスを 9 ステップのプレイブックとして公開しました。行き先は Anthropic、目的は安全な AGI。本記事では、このエッセイを題材に、CTO のネクストキャリアという問いを、潮流・オペレーターの価値・撤退設計の 3 点から考えます。

開発チーム体制の振り返り（2015年1〜5月）

2015 年前半の開発チーム体制を振り返り、良かった点と課題を整理しました。

最近の仕事内容と所感（2014年8月版）

コードを書く時間が減り、マネジメント業務に追われる 2014 年 8 月時点のエンジニアリングマネージャーの日常です。

エンジニア PC リニューアルの社内承認を得るためのお役立ち情報

1on1 で PC リニューアルを承認してもらうときに使える他社事例と切り口をまとめました。

2018年 目標・方針

開発チームリーダー兼 PM としての 2018 年の目標・方針と、あえてやらないことをまとめます。

Engineering Lead (エンジニアリングリード) という役割

『エンジニアのためのマネジメントキャリアパス』を参考に Engineering Lead の役割を自分の仕事と照らし合わせました。

The Great Engineering Leader Career Break を新陳代謝と新しい CTO 像で読む — Pragmatic Engineer の 6 つの理由への現場からの応答

Pragmatic Engineer の Headed for the Exit は、CTO や VPE が high-status なポジションから相次いで降りている現象を 10 の理由で解剖しました。私はこの記事に書かれていることは概ね理解できるという立場で、個々人の生き方の問題だと思っています。そのうえで、代表的な 6 つの理由に対して、新陳代謝と新しい CTO 像という 2 つの軸から現場の反応を書きます。

フルリモートワークなエンジニア組織での Engineering Manager

フルリモートな組織で Engineering Manager をやるときのツール・1on1・勤怠運用の実例です。

Engineering Manager へオススメしたい本

EM ポジション引き継ぎに合わせてまとめた、エンジニアリングマネージャー向けおすすめ本のリストです。

初めて Engineering Manager になった方からの相談と回答

1on1 の運用、頻度、メンタリング、参考書籍など、初めて Engineering Manager になった方への回答をまとめました。

[GitHub] Pull requests 作成ユーザー, Reviewer で絞り込む方法

GitHub Pull requests を author と reviewed-by で絞り込む URL の書き方を、nodejs/node の例で紹介します。

[GitHub] 特定の期間に close した issue, pull request を検索する

GitHub で特定期間に close した issue / pull request を検索するクエリの書き方を紹介します。

『非機能要件』をどうやって満たしていくか？

非機能要件が満たされていなかった初期リリースを踏まえ、Sprint Review と GitHub issue でどう改善していくかの反省と方針です。

インシデント対応のスタンスと動き方 — 責めない、しかし当事者がリードする

システムを運用していれば障害は避けられません。問われるのは、起こすかどうかではなく、起きたときにどう動くかです。私がチームに伝えているスタンスは 3 つあります。起こしたこと自体は責めない。しかし原因を作った当事者が責任を持って対応をリードする。そして肩書きの有無にかかわらず、その場の誰もがリーダーシップを発揮する。blameless postmortem・Just Culture・incident command を補助線に、動き方の型まで整理します。

リーダーシップ・アンチパターン

現場で見かけたリーダーシップ・アンチパターンを 5 つのポイントに整理しました。

2020年を振り返る

共同創業一年目の 2020 年を、開発・バックオフィス・情シス・採用・経営の観点で振り返ります。

『【エムスリー×MonotaRO】急成長メガベンチャーのエンジニア組織づくり最前線』参加レポート #エンジニア組織_findy

エムスリー社と MonotaRO 社のエンジニア組織づくりに関する Findy 主催イベントの参加メモです。

マネージャーがエンジニアに求めるたった 1 つのこと — コンテキストを GitHub repo に残してほしい、要約は AI が吸収する

社内 Discussion をマネージャー視点で眺めて「結局何をやるんだっけ」と読み取りにくい場面が頻繁にあります。これはエンジニアの書き方の問題ではなく、書き手と読み手の粒度が違うという構造的な話です。「コンテキストを GitHub の repo に、フローでもストックでもいいので残しておいてほしい。マネジメント向け要約はこちらで AI 活用して吸収する」という、マネージャー側からエンジニアへのお願いを記事として残します。

職場では「お友達の関係」を望まないタイプの人間

『エンジニアのためのマネジメントキャリアパス』の一節を引きながら、職場ではお友達の関係を望まない理由を書きました。

本人に「メンター制度をやる必要がある」という認識がないと良い結果にはならないのでは？

メンター制度は、メンティ本人にやる必要があるという認識がないと機能しないのでは、と考えたメモです。

コーディングエージェントのモデル選びは機会コストで決める — Fable 5 Low・Codex 5.6 Sol Light を速度に振る理由

最近、Claude Code では Fable 5 を推論レベル Low、Codex では 5.6 Sol を推論レベル Light・速度レベル Fast と、意識して軽く速い設定をデフォルトにしています。今の高知能モデルは推論トークンを絞っても、ミスの傾向に大差がありません。だとすればレビュー工数は変わらず、効いてくるのはトークンコストより待ち時間、つまり機会コストです。機会コストは見えにくいけれど、人間がボトルネックである以上その支配は自明だ、という話です。

技術的負債を返却するには何をすればいいか？

「技術的負債の返却が上手な人を雇って権限を与える」という hsbt さんの意見に触発された所感メモです。

「ピアコードレビューの実践的レッスン」を取り入れてみた

「ピアコードレビューの実践的レッスン」から、開発時間の 25% を目安にレビューする考え方など実務に活かす点をまとめました。

褒めるのは人前、叱るのは 1on1 で

『The Manager's Path』の「褒めるのは人前、叱るのは 1on1 で」というプラクティスを紹介します。

プロダクト開発とヒトモノカネ

プロダクト開発を「ヒトモノカネ」の三つの観点で整理して、技術選定や ADR に活かす考え方の紹介です。

実績がない人の提案は、アイデアはあるけど実行できない起業家みたいなもの

他チームへの提案を通すには実績と自分の仕事の完遂が不可欠、というテーマの同僚宛メールの抜粋です。

読書メモ『LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する』

『Accelerate（LeanとDevOpsの科学）』から、ケイパビリティ・4 つの指標・トランクベース開発などをメモしました。

読書メモ『ALLIANCE　アライアンス』

『ALLIANCE』から、コミットメント期間・整合性・ネットワーキング予算・卒業生ネットワークについてメモしました。

読書メモ『エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング』広木大地（著）

『エンジニアリング組織論への招待』から、経験主義・情報の非対称性・技術的負債についてのメモをまとめます。

読書メモ『デザイン組織のつくりかた』ピーター・メルホルツ（著）

『デザイン組織のつくりかた』から、限定型リーダーシップと集権的パートナーシップについてのメモを紹介します。

読書メモ『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』

『チームトポロジー』から、認知負荷・チームAPI・4つのチームタイプと3つのインタラクションモードのメモを紹介します。

読書メモ『HIGH OUTPUT MANAGEMENT』アンドリュー・S・グローブ（著）

『HIGH OUTPUT MANAGEMENT』から、テコ作用・1on1・タスク習熟度別マネジメントについてのメモを紹介します。

エンジニア採用前に考えたい、サービス・機能を終了させて仕事を減らすアプローチ

エンジニア採用を決める前に、サービス終了や機能削減で仕事量そのものを減らせないか検討するアプローチを紹介します。

「チームメンバーとの信頼関係を築く：定期個人面談の薦め」を読んで 1on1 実践してみたらとてもよかった！

クックパッドの記事を読んで 30 分の 1on1 を試してみたら、普段しない話ができてとてもよかった記録です。

退職駆動開発 (Retirement-Driven Development = RDD)

退職を機に暗黙知の形式知化や無駄な業務の削減が進む「退職駆動開発 (RDD)」の考え方をまとめます。

ソフトウェアエンジニア採用に関連した社内インタビュー用メモ

ソフトウェアエンジニア採用の社内インタビュー用に準備した、価値観や働き方についての事前メモです。

ソフトウェアエンジニアがプロダクトオーナーを担うときに調べた情報まとめ

ソフトウェアエンジニアが PO を担うときに調べた役割の考え方と参考リンクのまとめです。

サポートタイプのリーダーを目指すあなたにやってほしいこと

サポートタイプのリーダーを目指す人に、実務の引き継ぎからキャッチアップ、他チーム調整までを優先度順に伝えた記録です。

Tech Lead (テックリード) の役割がよく分かる記事まとめ

テックリードの役割を具体的に理解するために参考にした記事や Podcast をまとめました。

Technical Product Owner（テクニカルプロダクトオーナー）

Technical Product Owner の役割や、Technology Officer / Tech Owner との違いについて調べたメモです。

master に merge できる pull request が大量に存在すると・・・

溜まった pull request の Conflict 解消がつらい、チーム体制を見直しているという話です。

ドキュメント化するとメンテナンスコストが掛かるので「社内の誰が専門家か？」だけ分かればとりあえずOK

「誰が何を知っているか」を把握するトランザクティブ・メモリーの考え方について、社内共有の例を交えて紹介します。

良いチームを作るノウハウを知りたい

20 人規模の開発チームに変わっていくなかで、良いチームを作るノウハウを模索している近況です。

Web Developer Roadmap がエンジニア採用情報を書くのに参考になった

エンジニア採用情報を書くときに、Web Developer Roadmap のロードマップ図が参考になった話です。

新人エンジニア研修用の教材として「WEB+DB PRESS 総集編」を購入した

新人エンジニア研修の教材として「WEB+DB PRESS 総集編」を購入した話です。

2018年を振り返る [仕事, 家庭, 学習]

Engineering Lead として過ごした 2018 年の仕事・家庭・学習を振り返り、来年に向けての所感をまとめました。