「活動」は激変する。「ベース」は変わらない ～ 4つの軸で捉える_AI時代ソフトウェア開発マネジメント

AIを使えばすぐにソフトウェアが作れる時代が来ています。実装の工数がどんどん消えていく中で、マネジメントの役割とはと不安になることもありました。

しかし、現場でAIを使い色々な話を聞くほど、実はソフトウェア開発の根底にある価値が浮き彫りになってきました。

AIは「何でも作れる」けれど、「何を作るべきか」は決めてくれません。
AIは「爆速でコードを吐く」けれど、その「設計の意図」までは守ってくれません。
AIは「正解」は出すけれど、チームの「納得感」は作ってくれません。

この資料は、AIという強力な相棒を得た今、僕らマネージャーが向き合うべき「変わらない本質」について、4つの視点（プロダクト・プロジェクト・技術・人）で整理したものです。
本資料が、これからの開発マネジメントを、一緒に考えるきっかけになれば嬉しいです

Transcript

1. 「活動」は激変する 「ベース」は変わらない ソフトウェア開発のベースからみる AI時代のマネジメント
2. 辻 裕士 Hiroshi Tsuji • 経歴 ◦ 組込エンジニア (2009-2019年) ▪ 1社目: 実験用NWルーター開発 ▪ 2社目: ネットワークカメラ開発 ▪ ともに開発リーダーを経験 ◦ 国内データセンター事業者TL (2019-2022年) ▪ 自社グローバルポータル開発を牽引 ▪ PjM, チームビルディングなど幅広く担当 ◦ フリー株式会社 EM (2022年-現在) ▪ 権限管理基盤チームの EM を担当 ▪ 2025 年から PdM も兼務 • その他 ◦ 本資料の内容は個人の見解に基づくものであり、 所属組織とは関係ありません。 ニックネーム: sentokun/kikiさん 自己紹介
3. 今日のテーマ : AI によりマネジメントのなにが変わるのか？ 今⽇話したいこと AI により、マネジメントのやり⽅や価値観は激変した => マネジメントはなにを変えるべき‧変えないべきか？
4. 今日のテーマ : AI によりマネジメントのなにが変わるのか？ アジェンダ 1. AI でなにが起きたか 2. ソフトウェア開発とマネジメントの構造 3. 4 つのマネジメント軸（本題） 4. 最後に
5. 1.AIでなにが起きたか
6. 様々なツールを駆使して、⼈間がコードを書いていた ほんの数年⽬までは⼈間がコードを書いていた。 「AI？製品で使える品質になるわけないでしょ」 要件定義 ⼈間 設計 ⼈間 実装 ⼈間 デリバリー 1.AIでなにが起きたか AI 時代により移り変わるソフトウェア開発 CI/CD
7. 1⾏書いたら、続きを補完してくれるようになった 初期は実装⼯程の補助。主体は依然として⼈間であり、 AIは「⾼度な予測変換」として⽣産性を下⽀えする。 要件定義 ⼈間 設計 ⼈間 実装 ⼈間 (補完) デリバリー CI/CD 1.AIでなにが起きたか 2022-2023年: GitHub Copilotの登場 (IDEの延長)
8. 要件を⾔えば、リポジトリ全体を修正してくれるようになった 「どのように作るか（How）」の思考がAIへ移譲 思想も外部委託できることになったことで、⼈間 は「意図」の指⽰と結果の検証へとシフト 要件定義 ⼈間 設計 AI 実装 AI デリバリー 1.AIでなにが起きたか 2024年：AI Agent の進化 (人間の作業が置き換わる ) CI/CD
9. ほぼすべての⼯程を、AIがチームを組んで実⾏可能になった 要件定義 ⼈間 /AI 設計 AI 実装 AI デリバリー AI 1.AIでなにが起きたか 現在：Claude Code 全盛 (AI Agent のチーム化 ) チーム活動そのものを AI が回すレベルに進化。 「CLIからAIを召喚=>⾃律的にエラーを直す」 なんてことも
10. 「ソフトウェア開発」の内容が AI を中⼼としたものに劇的に変化 これまで開発者の「⼯数」が最⼤のボトルネックだった。しかし、「ソフトウェアを作り上げる」こ とが極⼩化。AI を前提とした素早い開発が求められる時代になった 1.AIでなにが起きたか
11. 「全体の構造は変わってないよね？」(まだ) 1.AIでなにが起きたか でも、「ソフトウェア開発」のベースはまだ変わっていない 要求定義 (なにが価値か) 設計 (どう実現するか) 実装 (実現する) デリバリー (届けて検証する) 主体がAIに置き換わっても、⽬的と必要な要素は変わらない AIは「実⾏の⾼速化」であり、「価値判断」の代替ではない
12. 「マネジメント」のベース => 変わらない 「マネジメント」の実現⽅法 => 劇的に変化している なぜそれを作るのか 意味付けと価値の接続 美しいシステムか 疎結合と持続可能性 チームで機能するか 個と組織のパフォーマンス 1.AIでなにが起きたか ソフトウェア開発にある普遍的な「問い」 ソフトウェア開発には普遍的に解決したい「問い」がある。それに答えるのがマネジメント
13. 2.ソフトウェア開発とマネジメントの構造
14. ソフトウェア開発のベース ↓ 価値あるものを、早く届け続ける
15. 2.ソフトウェア開発とマネジメントの構造 ソフトウェア開発生産性の構造 Foundation: 活動を⽀えるための⼒ (Capability) Level 1: 機能の実現 (Increment) Level 2: 機能の提供(Outcome) Level 3: 価値の創出(Value)
16. ソフトウェア開発生産性の構造 ユーザー価値を最速で届け続ける⼒があるか？ 機能を積み上げ続けているか？ 機能をユーザーに届け続けているか？ ユーザーに価値が生まれ続けているか？ Level 1: 機能の実現 (Increment) Level 2: 機能の提供(Outcome) Level 3: 価値の創出(Value) Foundation: 活動を⽀えるための⼒ (Capability) 2.ソフトウェア開発とマネジメントの構造
17. ソフトウェア開発サイクルの構造
18. マネジメントのベースとなる 4領域 📦Product 価値を決める 📅 Project 価値を届け切る ⚙ Technology 構造を作る 👥 People ⽂化を作る 2.ソフトウェア開発とマネジメントの構造
19. 4つのマネジメント軸の主戦場 レベル 主戦場とするマネジメント軸 Level 3 📦Product Level 2 📦Product, 📅Project, ⚙Technology Level 1 📅Project, ⚙Technology Foundation 👥People, ⚙Technology 2.ソフトウェア開発とマネジメントの構造
20. ソフトウェア開発の４つのマネジメント軸 📅 Project 👥 People ⚙ Technology 📦Product
21. 3. 4 つのマネジメント軸（本題）
22. 4つのマネジメント軸を思考する 以下観点で考える 1. マネジメントのベース < 各マネジメントで⼤切な要素を説明 2. 現在地 < 私⽬線での現在地を説明(できているとは⾔っていない) 3. 未来予想 < ありえそうな未来を楽観、悲観的に予測 ◦ 楽観的 ◦ 悲観的
23. 3-1. Product Management 📦Product
24. 3-1. PRODUCT MANAGEMENT 1. マネジメントのベース 以下を⼤切にした、理想のプロダクトを追い求める 1. 価値を届ける: 「なにが課題か」に執着し、ユーザー価値を届ける。 ユーザーや市場の深い理解から課題を追求‧特定し、解決にこだわる 2. 意味をつなげる: 「なぜ必要か」を問い、ビジョンと連動する。 なぜ今必要か、やらないとどうなるかを掘り下げ、ビジョン実現への道筋を作る 3. 筋を通す: 「なにを作るか」を選び、増殖する要求から守る。 「できること」でなく「やらないこと」を決め、刺さらない要求は捨てる覚悟を持つ。
25. 3-1. PRODUCT MANAGEMENT 2. 現在地：AIとの共創による仮説検証サイクルの高速化 1. DeepResearch による課題特定の⾼速化 市場調査、要約、データ解析をAIが担うことで、課題特定のリードタイムが劇的に改善 2. 「FDE(現場で解決する）」型の仮説検証への進化 PdM がAIでのプロトタイプ作成に染み出し、現場で直接ニーズを特定‧検証するスタイルが登場 3. AIの「できるはず」によるプロダクト構造への軽視と圧迫 「AIができると⾔った」という安易な⾔及により、技術マネジメントコストを増⼤させるリスク => 「できる」と「やってよい」は別。PdM の技術構造への敬意、理解、歩み寄りがより重要に
26. 3-1. PRODUCT MANAGEMENT 3. 未来予想: 楽観シナリオ 価値を届け、決め切り、ビジョンにつなげる活動に全⼒集中 ドキュメントの構造化や、ステークホルダー間の細かな仕様調整はAIが「よしなに」解決。 PdMは深いユーザー観察や熱狂する体験設計を追求した「問い」にリソースを全投下できる。 価値を⽣み出す構造との融合 AIが仲介役となり、ProductとTechnologyの距離が消失し「実⾏可能かつ精度の⾼い要求」が 実現。質の⾼い意思決定と仮説検証のサイクルが爆速化する。
27. 3-1. PRODUCT MANAGEMENT 3. 未来予想: 悲観シナリオ 「機能の作りすぎ」でプロダクト価値が崩壊 作るコストがゼロに近づくことで、機能が爆速でリリースされる。が、その検証が置き去りにさ れ誰も欲しがらない、ただ複雑化し続ける太り続けるプロダクトが産まれる。 結果として、プロダクト全体の「⼀貫性」が失われ、負債が制御不能なレベルに達する。 [対処] ⼈間が意思を持って「やらないこと」を決める なにを「やらないか」の決断⼒を磨く。ユーザー価値を念頭に機能を作り、計測する。 AI を介した「作れます」「できました」をすぐ受け⼊れず、⼈間がフィルタリングする
28. 3-2. Project Management 📅 Project
29. 3-2. PROJECT MANAGEMENT 1. マネジメントのベース 以下を⼤切にした、不確実性を飼いならす理想のプロセスを構築する 1. ⼩さく分ける：実⾏可能な単位に分け、巨⼤な課題を経験から把握する。 解像度の粗い巨⼤な課題を分割し、⼩さく試すことにより戦略的に解像度をあげる 2. ずれを検証する：サイクルを可視化し、予測とのずれを学びにする。 予実を可視化し⽐較検証するサイクルを回すことで、学びを得ながら先の⾒通しをあげる 3. 実現しきる：失敗要因を制御し、特に泥臭く決断し価値を出し切る。 リスク要因を早めに拾い制御する。制御しきれない場合も提供価値のラインを⾒極め実現しきる。
30. 2. 現在地：構造化スキルの二極化と「ボトルの移動」 1. 地道に「型」を作ってきたマネージャー程がハマるパートナー チケット分割やWBS作成を緻密に⾏ってきたPjMほど、構造化された指⽰を好むAIを相性抜群 2. ボトルネックの移動で「やるべき」が「やらなければ」に変化 AIによって「コード⽣成」が爆速に。APIテストや⾃動レビュー等、やるべきと思いつつ⼿が回りに くかった理想のプロセスが AI に MUST な世界に変わりつつある 3. 「泥臭い調整」からの脱却は⼈間側のプロセス成熟ありき AI の恩恵を受けているためには、⼈間が整理できる状態を作る必要がある。 => AI のベストプラクティスを参考に、泥臭くプロセス整理の先に、AI の真価がある 3-2. PROJECT MANAGEMENT
31. 3. 未来予想: 楽観シナリオ 学習サイクルの極限突破により飼いならされる不確実性 開発プロセスから得られるフィードバックがリアルタイム化。経験則に基づく「推測」ではな く、実データに基づく「即座の修正」が可能になる。 リスクの⾃動検知と解消により不確実性が表出しない 不確実性の芽（遅延の兆候や依存関係の⽭盾）をAIが先回りして発⾒。PjMは「リスクに怯え る」ことから解放され、「リソースの最適配置」に注⼒できる。 3-2. PROJECT MANAGEMENT
32. 3. 未来予想: 悲観シナリオ 爆速実⾏によるリスクの爆発 ⼈間が理解‧感知できる速度を超えてプロジェクトが進⾏。微細なリスクが「不可視」のまま積 み重なり、ある⽇突然、巨⼤な品質障害やセキュリティホールとして爆発する。 あるいは AI が実⾏するための構造づくりによる疲弊し、リスク管理が崩壊するパターンも [対処] 速度だけでなくリスクに⽬を向け、解像度を上げる活動を⼿放さない プロジェクトマネジメントの「不確実性を飼いならす」というベースを⼿放さず、リスクの解 像度をあげる活動から⽬をそらさない。 AI の判断に「なぜ？」を問い、AI と協⼒して様々な観点をいれリスクを拾い意思決定する。 3-2. PROJECT MANAGEMENT
33. 3-3. Technology Management ⚙ Technology
34. 3-3. TECHNOLOGY MANAGEMENT 1. マネジメントのベース 以下を⼤切にした、トレードオフで最善を尽くしたコードを磨きこむ 1. 意思を込める：コードでなにを実現したいかの思想を表現する。 機能実現を続けながら「なぜこの設計にしたか」にこだわり、ADR等で⾔語化 2. 質を作りこむ：コードが正しく機能することを仕組みで担保する。 CICD、コード規約の適⽤等、可能な限り⼈が介在しない仕組み化 3. 機能美を磨く: コードの性能や、原理原則が守られた美しさにこだわる 「動くものを爆速で作る」ことはもちろん、性能や変更容易性、ドメイン分離等にこだわり守る
35. 2. 現在地：あるべきとされていた活動が AIを育てる時代に 1. 思想の⾔語化により、 AIが「ずっとほしかった右腕」に ADRなどによるなぜの⾔語化がそのままAIの命令セットに転換。最強の右腕が誕⽣する世界に 2. 構造と事業の接続がより重要に 「動く」をAIに任せ「事業の選択肢を増やす構造（変更容易性‧ドメイン分離）」 3. ⽣産性の爆上がりが「構造を守る」シニアのレビュー疲れに AI製PRの量産により、シニアが「⾏間」の検品に忙殺。ボトルネックがシニアへ集中するケースも =>どれだけ仕組み(CI/CD、⾃動レビュー）で意思‧質‧機能美を守れるかが重要に 3-3. TECHNOLOGY MANAGEMENT
36. 3. 未来予想: 楽観シナリオ 「作る」がなくなり真に「事業ドメイン」に向き合う世界に Technology は「いかに業務を抽象化しドメイン構造に落とすか」に絞られ、それを実現するた めの⾏動は AI が⾃動で設計‧実装‧テスト‧運⽤のすべてを回す。 シニアの「勘」が資産化され、AIにより爆速で伝承される シニアの「勘」や「経験」がADRやレビューコメントを通じてコンテキストとして⾔語化され る。同僚は隣で⾒て盗んだシニアの「勘」を AI との並⾛により経験し、成⻑に還元される。 3-3. TECHNOLOGY MANAGEMENT
37. 3. 未来予想: 悲観シナリオ 「AIでできたよ」によるドメイン破壊 AIによって他⼈のコードが簡単に「解析‧修正できてしまう」。そこからよかれと思った修正に より、結果としてドメインの責務を無視した修正が爆速で繰り返される。 結果、認知負荷が⾼く全体を把握できない「無軌道なAI⽣成コード」が積み上がる。 [対処] AI によるガードレールやテストで「流⼊しない」仕組みを磨く 「なにをしてはいけないか？」のガードレールとなる AI レビューや⾃動テストを充実させ、流 ⼊しない仕組みを作る。それまでは⼈が守らなければいけないラインを抑え続ける 3-3. TECHNOLOGY MANAGEMENT
38. 3-4. People Management 👥 People
39. 3-4. PEOPLE MANAGEMENT 1. マネジメントのベース 以下を⼤切にした、⼈の流動性に向き合い理想のチーム‧組織を作る 1. 状態を観察する：⼈は変化するもの、という前提に⽴ち正しく理解する ⼈ならではの「揺らぎ」を理解し、ありのままの個⼈‧チームの状態を深く観察する。 2. 期待を形にする：価値を届けるプロとしての「期待」と「なぜ」を語る 価値貢献と個⼈へのHRTを⼟台に、期待しているふるまいに熱量を込めて伝える 3. 任せるを設計する： 振る舞いを設計し、挑戦が成長に繋がる構造を作る ⾃由と責任が共存した「ストレッチゾーン」を⽤意し、⾃律的にチームが育つ体制を構築する
40. 2. 現在地：AIの登場による期待値や役割の高度化 1. AI というチームを持った「プレイングマネージャー」が標準 全員がAIエージェントチームを「AIをどう動かし、成果を出すか」のマネジメントが求められる。 手がほしかったマネージャーはスキルの「AIチーム」構築へ活用できるのはポジティブな要素 2. 今までの視点を染み出す「役割の変化」を模索するフェーズ 実⾏コストの低下により、QAや企画など「価値実現のための染み出し」が求められる時代になった 3. マネージャー⾃⾝の⼈への向き合いもより強度が⾼く変化 役割の標準が「人とAIの共創」を観察し伸ばす「EM of EM」へ変化。ベース活動も強度が上がる 3-4. PEOPLE MANAGEMENT
41. 3. 未来予想: 楽観シナリオ 本質を追求する真の「ワンチーム」組織へ 作業コストが消え、全員が「本質的な価値」について議論できるチーム作りが可能に。それにより領域 の壁がなくなり、⾃律的に成果を上げる組織へと進化する。 AI で簡単にマネジメントが学べる時代に ツールを使いこなす延⻑で AI と協業開発を⾏うことで、⾃然と全員のマネジメントスキルが向上。 AI も含めたチームの成⻑に誰でも貢献できるようになる 3-4. PEOPLE MANAGEMENT
42. 3. 未来予想: 悲観シナリオ ⼈に求めることが爆上がりしパンク AI が定型業務を飲み込み、⼈間には認知負荷の⾼い「答えのない意思決定」だけが積もり続ける。対話の余裕が 失われ、⾼度な「パニックゾーン」の要求しか残らず育つ前につぶれてしまう [対処] つぶれない「半歩先の⾃律」を経験できる環境設計をし続ける AI で構築したガードレールの中で、失敗を許容しつつ自律的な意思決定の成功体験が重ねられる 「ストレッチゾーンの場」を意図的に作り上げる。 あえて効率化しない対話や振り返り、未来への思考といった「あそび」を保つ。 3-4. PEOPLE MANAGEMENT
43. まとめ: AI によるマネジメントの進化と、残る人間の意思 AI の進化により、マネジメントの仕事が劇的に変化 • 📦Product: 探索よりも「問う力」と「決断」 がユーザー価値を生み出す • 📅Project: 調整よりも「型」と「意思決定速度」 がデリバリーを加速する • ⚙Tech: やるべきだった「言語化」と「仕組み化」 が構造を守る • 👥People: 変化に向き合う「観察」と「設計」 に文化と熱量がにじみ出る 人間が意思を持って選び、言葉に残し、仕組みを作る => AI へ伝承 3. 4つのマネジメント軸
44. 4.最後に
45. マネジメントのベース「なんとかする」で AIに向き合おう AI は実行を変える。価値は人が決める AI が進化する一方で、私たちの現場は勝手に良くなりはしない。 銀の弾丸はなく、変化を受け入れて泥臭く「なんとか」するしかない。 まずは、1つ深く問う、言葉に残す、型化する、観察する。 いつかやりたいと思っていたその 1 つを、明日はじめてみませんか？