未知を言語化し意思を持った航路に変える、ソフトウェア開発の本質に迫るAI時代のマネジメント

サマリ

本文の要約

• ソフトウェア開発とは、未知の世界に希望を抱き、未開の地を明らかにするための旅路である。その旅路を着実に突き進む行為が、マネジメントである。
  • 具体的に言えば、それは『概念』を『構造』へと少しずつ変換する格闘、あるいは言語化されていない事象を泥臭く言語化する行為に他ならない。
• AI という強力すぎる乗り物を得て、私たちの旅路は劇的に変わった。
• しかし、暗闇に希望を見出し、意思をもって未開の地を切り開く行為(概念の構造化への変換)は、まだしばらくは人間に支えられる。

伝えたいこと

とにかく深く思考し、ユーザーニーズや現在の状態、暗黙的な構造や思想・期待値といった本質的な要素を観察し、ひとつひとつ言語化すること。それこそが人間の仕事ではないかと思うのです。

1. はじめに

昨今、AI の進化により、私たちの開発現場は劇的に変化しました。
コードやドキュメント生成などの実行面は格段に早くなっており、開発プロセスでは仕様駆動の価値が再認識されています。
AI Agent を従えることでプレイングマネージャーの活動もやりやすくなるなど、組織体制の面への影響も出ています。
一方、シニアのレビュー疲れや意思決定の強度が上がり、マネージャーに求められる判断の『密度』は飛躍的に高まっているなど、今までにない負荷要素も増えています。

そのような AI 時代において、マネジメントはどう変わるのでしょうか？この記事では、私自身の実際に現場で起きている変化への悩みを通して、どう変わるのかを考えた結果をアウトプットします。

先に結論を伝えると、私は、AI時代においてもソフトウェア開発とマネジメントの本質は変わらず、その実現方法が変わっていくと考えています。

想定読者

• AI の登場により変わりつつある役割に直面しているリーダー
• AI の登場により変化することはなにかを思考したいメンバー

2. ソフトウェア開発の普遍的本質=「概念の構造化」

では、私たちが守るべき「ソフトウェア開発の本質」とは何でしょうか。
それは、曖昧な人間の願望を論理的な形に落とし込む 「概念の構造化」 です。
コアメッセージでは、比喩的表現として未開の地(概念)を明らかにする(構造化)と表現しています。

これは一般的な考えであり、『人月の神話』で知られるフレデリック・ブルックスは、著書（および論文『銀の弾丸などない』）において、ソフトウェア開発の困難さを次のように定義しています。

ソフトウェアの実体の本質（Essence）とは、データセット、データ項目間の関係、アルゴリズム、そして関数の呼び出しといった、互いに噛み合う概念の構成物（construct）である。……ソフトウェア構築において困難なのは、この概念的構成物の仕様策定、設計、およびテストであり、それを表現（コーディング）したり、その表現の忠実度をテストしたりする手間ではない
(The essence of a software entity is a construct of interlocking concepts... I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.)

つまり、コードを書く（表現する）労働よりも、「概念をどう組み合わせ、どう仕様化し、どう設計するか」という構築作業こそが、ソフトウェア開発の逃れられない本質（Essential complexity）であると語っています。

概念の構造化がなぜ不確実性の高いものなのか、例を出して考えてみましょう。
例えば、あるユーザーが予約サイトで「スムーズに予約したい」と願っていたとします。
この「スムーズに予約」という願いには、様々な解釈があります。例えば「手数の少なさ（速度）」な可能性もありますし、「納得感のある情報提示（安心感）」なのかもしれません。ソフトウェアに構造化して落とし込むにあたり、どれがユーザーにとっての「真実」かは、コードの書き方ではなく「概念の設計」の中にしかありません。

この曖昧な状態を探索し、一つの意思を持って「言語化」していく作業こそが、ソフトウェア開発の肝となります。

2.1. マネジメントの本質 = 「概念を構造化する道筋の言語化」

では、マネジメントとはなんでしょう？
それは、ソフトウェア開発を実現するため、本質である概念を構造へと少しずつ変換し具現化していく行為です。言い換えると、言語化されていない事象を泥臭く言語化して実現していく行為とも言えるでしょう。

AIは、すでに言語化・構造化された情報の処理は驚異的な速度で行います。そのため、言語化さえできてしまえば AI の領分となります。この変化は今までと比較しても劇的です。

しかし、「言葉になっていない概念」を、意味のある構造へと昇華させることは、まだ人間の領分です。

AIは開拓された道を高速で舗装する強力な重機のようなものです。今までは地球上での移動しかできなかった世の中で急に宇宙旅行ができるようになったようなものでしょう。しかし、霧に包まれた荒野に最初の一歩を踏み出し、そこに道筋を見出すのは、他でもない、あなた自身の思考と意思なのです。

3. AI が乗り越えた「思考」の外部化

なぜ今、マネジメントが劇的に変わっていると感じられるのか。その背景にあるAI進化の歴史を見てみましょう。

AI以前は、人の 行動がソフトウェアに置き換わっていく時代でした。しかしAI以後は、行動ではなく思考が外部化される時代に急速に変わっていきました。

以下がAI以前の概略です。この頃は思考は人間のもので、その手足となるソフトウェアがその領域を広げている段階でした。そのため、言語化非言語化によらず、都度思考しながら対話で対応していくことも可能でした。

• AI以前：年月をかけ人の行動->数年スパンでソフトウェアに置き換え
  • 1950s-：計算の解放（コンピューターの登場）
    • 数十年かけて、人間は「筆算」という苦行から解放された。
  • 1980s-：手続の自動化（ソフトウェアの一般化）
    • 約20年をかけ、紙の伝票や定型業務が「アルゴリズム」へと構造化された。
  • 1990s-：距離の消失（Webの発達）
    • 10年以上の歳月を経て、世界中の情報がネットワークで接続された。
  • 2010s-：行動の外部化（X as a Service）
    • 2010年代の10年間で、インフラ、決済、認証といった「実務行動」がSaaSという構造に切り出された。

その後、LLM の普及あたりから急激に変化が加速しました。思考する仕事も AI で代替が可能となり、知的労働に対して人間しかできないと思われていたことが、急激に脅かされることとなりました。

• AI以後：人の思考->AIに急速に置き換え
  • 第1段階（2023年〜）：汎用的思考の開放
    • LLMの普及により、一般的な正解や論理構成を人間が考える必要がなくなった。
  • 第2段階（2024年後半〜）：文脈の接続（MCPの衝撃）
    • MCP（Model Context Protocol） の登場により、AIが組織固有のデータやSlackの文脈を理解。社内事情を踏まえた「状況把握」さえもAIの領分となった。
  • 第3段階（2025年〜）：自律的実行（エージェント時代）
    • AIエージェント（OpenAI Operator等）が自律的に計画・立案・実行。かつての主業務だった「進捗管理」や「タスク分解」も含め、ソフトウェア開発の実行は自動操縦機能となった。

AI 以後は、人間には、未踏の地を明らかにするまでの仮説検証と意思決定が残された形となります。後は環境さえ整えていれば AI Agent が実行できる時代となります。

4. マネジメントはソフトウェアの本質に向き合う「旅路」

思考が外部化された今、マネージャーはソフトウェアの本質である「概念の構造化」に対して向き合い、その間を接続していく試行プロセスやその設計が重要となります。

この概念から構造化までの旅路そのものが、ソフトウェア開発を前進させる唯一の手段となります。

5. 4つのマネジメントにおける「旅路」

代表的なマネジメントにおける「概念から構造化までの旅路」の要素は以下である。これらの要素を「意思」をもってなんとかする行為こそが、マネージャーに重要なことではないかと考える。

マネジメント領域	旅路
Product	ユーザーの裏に隠された「課題（概念）」を見つけ出し、「価値（構造）」を言語化できるか？
Project	不確実性で囲まれた「旅路（概念）」を解きほぐし、「確実な進捗（構造）」を達成できるか？
Technology	トレードオフの末に選んだ「設計思想（概念）」を具現化し、「設計やコード（構造）」を保ち続けられるか？
People	流動的な「理想の組織（概念）」を深く観察し、「期待値にあった体制（構造）」を作り続けられるか？

6. Product Management：気配を「価値」へと結晶化させる

6.1. 概念の抽出：霧の中の「課題」と「意思」

プロダクトの始まりは、常に非言語な「違和感」や「期待」です。

• 現状把握（市場・ユーザー）: AIは統計的な「平均値」としての市場調査は得意ですが、特定のユーザーが流す一滴の涙や、現場に漂う「言葉にならない不便さ」 を掴むのは人間の越境的な視点です。
• 「意思」の注入: AIは「論理的に正しい案」を100個出せますが、その中から「我々のビジョンなら、この1個に賭ける」と非論理的なまでの情熱を込めて選択（トリアージ） することはできません。

6.2. 構造化：仮説を「要求」へと定着させる

霧のような課題を、AIというエンジンが点火可能な「構造」へと変換するプロセスです。

• 要求仕様・要件定義: ここでの「構造化」とは、単にドキュメントを書くことではありません。「この課題を解くために、データはどう流れるべきか？」という独自ドメインの設計を、AIが迷わないレベルまで詳細に規定することです。
• 独自情報の構造化: 誰でもアクセスできるネットの情報ではなく、自社プロダクト特有のユーザー行動や、そのビジネス固有の変数を「前提条件」として整理し、AIに与える基盤を作ります。
• 仮説検証思考・プロセスの言語化: 概念の抽出で行った非言語的な行動を可能な限り言語化。コンテキストとして蓄積し、トレース可能な状態にします。

6.3. AIとの「接続（Interface）」：見えない感覚との接続

AIの台頭により、PdMの仕事の性質は以下のように劇的に二極化します。

項目	Human's Role（人間：開拓と決定）	AI's Role（AI：拡張と試作）
探索	現場の一次情報からの「違和感」の抽出	市場データ・競合情報・過去情報の蓄積からの膨大な要約・抽出
定義	「課題はこれだ」と仮説を決め切る	仮説を検証するための多角的な壁打ち
設計	プロダクトビジョンに沿った優先順位の断罪	要件定義の素案作成、エッジケースの指摘
検証	ユーザーの表情から「刺さったか」を感じ取る	KPIの計測、データ分析、プロトタイプの高速生成

6.4. マネジメントの真髄：Accountability（結果責任）

「How」のコストがゼロに近づく世界では、「間違ったものを高速で作ってしまうリスク」 が最大化します。

AIは「指示通りに作った」ことには責任を持ちますが、「それが売れなかった」「ユーザーを不幸にした」ことに対して責任（Accountability）を取ることはできません。プロダクトビジョンとの整合性に対しても同じくです。

• 「なぜ、今これを作るのか？（Why）」
• 「それが本当に解決すべき課題なのか？（What）」

この問いに対し、宇宙船の船長として「私が責任を持つ」と署名すること。
AIが強力になればなるほど、この 「人間による最終的な意味づけ」 こそが、プロダクトに命（価値）を吹き込む唯一の手段となります。

7. Project Management：混沌（不確実性）を「航路」へと変える

7.1. 概念の抽出：霧の中の「リスク」と「気配」を察知する

プロジェクトの現場では、常に「目に見えない問題」が渦巻いています。

• 不確実性の把握: ソフトウェア開発は常に想定外の連続です。「何かおかしい」「このままだと間に合わない気がする」といった言語化される前の違和感（非言語的なリスク） を掴み取るのは、現場を歩く人間の越境的な感覚です。
• 文脈（Context）の読み取り: AIはログやチケットのテキストは読めますが、チーム内に漂う「疲弊感」や「心理的な壁」、あるいはステークホルダー間の「微妙な力学の変化」を読み取って軌道修正することはできません。

7.2. 構造化：混沌を「秩序」へと定着させる

霧を払い、AIや人間が迷いなく動けるための「器（構造）」を作るプロセスです。

• プロセスの設計（構造そのものの設計）: どのような会議体（コミュニケーション・パス）を置き、どのようなチケット管理（情報の粒度）にするか。この 「情報の流れの設計図」 を引くことが、マネージャーの最重要任務となります。
• 可視化の構造: マイルストーン、クリティカルパス、進捗の定義。これらを「AIが自動で更新できる形式」で定義し、誰がどこを見れば現在地がわかる状態を作り上げます。
• プロセスの標準化 : AIという自律的なパートナーに「どう交通整理すべきか」を正しく動機づけるための、プロセスをガードレールとして標準化することが重要です。これは、過去の設計や一般知識を利用することが可能です。

7.3. AIとの「接続（Interface）」：定型に落とし込み自動化する

AIは「構造化されたルール」に従って、膨大なデータを処理するのが得意です。

項目	Human's Role（人間：設計と調整）	AI's Role（AI：実働と予測）
設計	「構造」の設計（どう管理し、どう報告するか）	設計された構造（ボード、自動通知等）の構築
感応	チームの「空気感」や「非言語な詰まり」の検知	チケットの滞留やベロシティの統計的リスク予測
調整	ステークホルダーとの泥臭い交渉と納得解の構築	リソース配分のシミュレーション、観点のインプット
意思決定	「この機能は落として、納期を守る」という断罪	過去の蓄積データに基づいた完了予測の提示
標準への適用	このプロジェクトの標準をインプット	蓄積された情報の標準への適用、足りない情報の提示。あるいは標準の構築

7.4. マネジメントの真髄：構造という「舗装路」を引く

AI時代、進捗管理という「点呼」にマネージャーの時間は必要ありません。

AIという自律性（Agency）を持ったパートナーを最大限に活かすためには、彼らが迷わず、矛盾なく働けるための**「完璧な器（プロジェクト構造）」**が必要です。

不確実性という暗闇の中で、どのタイミングで誰が何を決め、どう情報が流れるべきか。その 「意思決定の回路」 を設計し、予期せぬ事態には泥臭く人間関係の糸を解きほぐす。これが、AI時代のプロジェクトマネージャーに求められる「開拓者」としての姿です。

8. Technology Management：正解なき問いに「賭け」を投じる

8.1. 概念の抽出：未開の地への「賭け」と「意思」

アーキテクチャ設計において、唯一無二の「正解」は存在しません。あるのは、常に痛みを伴うトレードオフだけです。

• 不確定な変数: 「将来のユーザー数」「求められる拡張性の方向」「チームの技術スタックの習熟度」。これら全ての変数は、まだ見ぬ「未開の地」に属しており、現時点では確定していません。
• 「正しさ」ではなく「意思」: パターン（マイクロサービスかモノリスか、など）はAIが提示できます。しかし、不確実な未来に対して「今回は運用の複雑さを引き受けてでも、スケーラビリティに賭ける」という主観的な意思を宿せるのは、責任を背負う人間だけです。

8.2. 構造化：賭けと意思を言語化し伝達する

正解がないからこそ、なぜその「賭け」に出たのかという「構造化された記録」が生命線になります。

• ADR（アーキテクチャ決定記録）の本質: ADRは単なる事後報告書ではありません。「その時点で見えていた未踏の地の景色」と「あえて捨てた選択肢」 を構造化して残す儀式です。
• AIへのガードレール: AIは「なぜこの不自然な設計になっているのか」という意図を、コードだけからは読み取れません。人間が下した「賭け」の内容をADRやConcept docとして構造化し、ある時は MUST/SHOULD/MUST NOTの意思を込めることで、AIはその「意思の延長線上」で正しく振る舞うことができるようになります。

8.3. AIとの「接続（Interface）」：意思の実行と、責任の所在

AIは「最も効率的な手段」を提示しますが、その手段が「我々の賭け」に合致しているかを判断するのはマネージャーの仕事です。

項目	Human's Role（人間：開拓と決断）	AI's Role（AI：提案と具現）
判断	トレードオフの決断（何を捨て、何に賭けるか）	過去の一般事例に基づいたメリット・デメリットの列挙
定義	「未開の地」を想定した、固有の制約条件の設定	制約条件下での、最適なコードパターンの生成
記録	「なぜその道を選んだか」という意思の言語化（ADR）	決定事項に基づく、詳細設計ドキュメントの自動生成
責任	「賭け」が外れた際のリファクタリングへの責任	仕様に沿った動作の保証、バグの検知

8.4. マネジメントの真髄：不確実性を引き受ける「署名」

AIがどれほど賢くなっても、道を誤り座礁したときに「私の判断ミスだった」とAI 自身が頭を下げて次の航路を描き直すことはできません。

マネージャーが担うべき構造化とは、正解のない暗闇の中で「今回はこちらへ進む」という座標（意思）を言語化し、構造としてコードに定着させることです。

技術選定は「唯一の正解を探すパズル」ではなく、「自分たちが信じる未来への投資」です。その投資の責任を引き受け、AIという強大なエンジンをその方向へ向け続ける。この 「決断の重み」 こそが、AI時代のTechnology Managementのコアとなります。

9. People Management：多重の流動性を「期待値と体制」へと構造化する

9.1. 概念の抽出：四重に重なる「流動性」の観察

People Managementの本質は、以下の4つのレイヤーで常に形を変え続ける「生のプロセス」を感知することにあります。

• 個人の流動性: スキル、キャリア観、メンタル、ライフステージ。これらは時代の流れや個人の経験によって刻々と上書きされる「揺らぎ」です。
• チームの流動性: 相性、文化、心理的安全。誰か一人が加わる・抜けるだけで、化学反応の結果としてのパフォーマンスは非線形に変化します。
• 組織の流動性: 拡大、代謝、フェーズ。短期収益か中長期成長かという戦略のシフトが、組織の「OS」を常に書き換え続けます。
• プロダクト（外部）からの流動性（理想の源泉）: 解決すべき課題、ユーザー特性、事業フェーズ。
  • 「人・組織の理想の姿」は常にプロダクトの状態から逆算されますが、そのプロダクト自体が不確実な旅路の途中にあり、刻一刻と変化します。

9.2. 構造化：流動性を「期待値と体制」に結晶化させる

マネージャーの役割は、これらの流動性を深く観察し、 「今、ここでの正解」 を仮説として形作ることです。

• 期待値の構造化: 激変するプロダクト状況と個人の状態を掛け合わせ、「今の君／チームに求める役割はこれだ」という一時的な役割と期待値を言語化します。
• 体制の構造化: 流動的な戦略を遂行するために最適なチーム編成や会議体、意思決定ラインという「器」を設計します。

9.3. AIによる「4つの構造的激震」：加速する流動性

AIという自律的なプレイヤーが加わったことで、この「人・チーム・組織」の適応速度は、かつてないほど引き上げられています。

変化のポイント	現象（ひずみ）	Human's Role（人間による構造化）
個人の変容	ジュニアでもAIへの指示能力が必須になり、全員がPM化する。	「マネージャーへのマネジメント」 を全階層の標準にする。
チームの歪み	AIが量産したコードのレビューがシニアに集中し、責任が偏る。	「読むコスト」を組織構造で分散し、シニアの枯渇を防ぐ。
組織の断絶	下積みがAIに奪われ、ジュニアの成長機会が喪失する。	シニアが仕事を渡す以外の経験ステップを設計する。失敗してもいい小さな成功体験が詰めるプロジェクト設計等
体制の再定義	AI Agentで足りる領域が増え、人間には高度な強度が要求される。	「共感・越境・意思決定」 を新たな組織評価軸に据える。

9.4. マネジメントの真髄：流動性の海に腹を決めて「足場」を作る

人、チーム、組織、そしてプロダクト。すべてが流動し、足場が常に揺れているのが現代のマネジメントの戦場です。

AIは「流動するデータの解析」は得意ですが、流動に翻弄され不安になるメンバーの手を握り、「大丈夫、我々の目的地はあそこだ」と語りかけることはできません。

すべてが流動するからこそ、マネージャーは腹を決めるしかないのです。 「変わらない意思」 という錨を下ろし、流動性を無理に止めるのではなく、メンバーが「自分は今、ここで、何のために泳いでいるのか」を見失わないための 「意味の足場」 を組み上げ続ける。その「決断の重み」と「共感の深さ」こそが、AI時代のマネジメントの本質です。

10. マネジメントの現在地

ここまでは、AI活用が最大限にされた先の「北極星」について語ってきました。しかし、理想を語るだけでなく、そこに至るまでの「航路」を直視することが重要です。現在の地平で起きている、プロダクトと開発組織への影響について整理します。

10.1 プロダクトへの影響：UIから「データと対話」へ

プロダクトにおける最大の変化は、ソフトウェアが解決できる領域が「実行」から「人間の思考」へと広がったことです。

わかりやすい例が SaaS is Dead というセンセーショナルな発信です。これまでのSaaSは、思考を表現するための「画面（UI）」を提供してきました。しかし現在は、自然言語によるAIとの対話インターフェースが求められています。これに伴い、プロダクトの価値の源泉は「UI」から「データ」、そしてそれらを接続する「API」へとシフトしています。
この強力な「思考のインターフェース」をいかに取り込み、プロダクトを再定義するか。各社がそのアップデートに心血を注いでいるのが現状です。

10.2 開発組織への影響：ボトルネックの移動

組織における最大の影響は、開発生産性の構造変化です。
生産性には以下の3つのレベルがありますが、組織がどれだけ「仕組み化・構造化」できていたかによって、AIによる加速の恩恵には大きな差が出ます。
（参考：開発生産性について議論する前に知っておきたいこと）

• レベル1：仕事量の生産性
  構造化しやすい「コードを書く速度」は劇的に向上しました。一方で、言語化しきれていない領域——要件の適切な評価（QA）、設計仕様や非機能要件のレビュー、中長期的なトレードオフ判断——は、相対的に向上が遅れています。
  昨今叫ばれる「シニアのレビュー疲れ」は、まさに 「作る速度」だけが先行し、非言語領域の「判断」がボトルネック化した結果 です。こうした「あるべき姿」の言語化・仕組み化が、今、急務となっています。
• レベル2：期待付加価値の生産性
  作るのが早くなったからこそ、「何をやらないべきか」 の判断がかつてなく重要になっています。
  流されるままに「作れるもの」を量産すれば、大量のコンテキストスイッチが発生し、本当に作りたいものにリソースが割かれず、結果として誰も喜ばないプロダクトになりかねません。プロダクトビジョン、実現戦略、ロードマップといった「意志」を出力する力の重要性が、かつてないほど高まっています。
• レベル3：実現付加価値の生産性
  作ったものが正しくユーザー価値や売上に貢献しているか。そのフィードバックを分析し、戦略をアップデートしていく「構造」自体の重要性が高まっています。

結局のところ、 「これまでどれだけのことを言語化し、仕組み化（構造化）してきたか」 という組織の貯金が、AIの変化にどれだけ早く適応できるか差となっているのではないかなと推測します。

最後に：残るのは、人間の意思である

正直に言えば、AI時代のマネジメントは「しんどい」と思います。

AIによって「How（どう作るか）」のコストが劇的に下がった結果、人間が向き合うべき課題は、より抽象度の高い、正解のない領域へと純化されました。今まで強度が高く目をそむけていた課題や意思の言語化に向き合い、よしなに対応していた暗黙的なプロセスを構造化する仕事に向き合う時間が長くなります。

すべてのマネジメント領域において、我々は「AIが快適に活動するための不確実な流動性」を観察し、自らの意思で「構造」という仮の正解を提示し続けなければなりません。

さらに変化のスピードは速く、求められる意思決定の強度も、背負うべき責任の重さも上がっています。AIで「楽になる」どころか、人間がやるべき「泥臭い仕事」の純度が高まっているのが、今の現場のリアルです。

しかし、立ち止まって考えてみてほしいのです。
AIは、「過去から予測すること」はできても、「未来を切り開く」ことはまだできません。

ソフトウェア開発が「未知の世界に希望を抱き、未開の地を明らかにするための旅路」であるならば、その暗闇の中に価値を見出し、リスクを取って「最初の一歩」を刻む行為は、これから人間の「意思」にしか支えられません。

銀の弾丸はありません。
目の前の流動的な現実に目を凝らし、一歩一歩、期待値と構造を組み替え、プロダクトとチームを少しずつ良くしていく。
その一見、地味で、時に報われないほど泥臭い歩みこそが、AIという宇宙船を真の目的地へと導く唯一の航路であり、マネージャーという「開拓者」にしか生み出せない価値だと思うのです。

未知の世界を切り開くために、AI という宇宙船のエンジンを点火しましょう。