2026年、PMはアーキテクトへ回帰せよ ── 「現場の工夫」という名の『失敗の本質』を越えて

■2025年の不協和音

2025年も年の瀬。

今年、我々IT業界を取り巻いていたのは、ある種の熱狂と、それを上回るほどの「徒労感」ではなかっただろうか。

ソフトバンクグループの孫正義氏が「日本はAI革命において周回遅れだ」と叱咤し、経営層はその言葉に突き動かされるように「我が社でも生成AIを活用せよ」と号令をかけた。しかし、現場から聞こえてくるのは、歓喜の歌ではなく、軋むような叫びが多数だった。

X（旧Twitter）を開けば、連日のようにエンジニアやPMたちの声が流れてくる。「RAG（検索拡張生成）の精度がどうしても上がらない」「PoC（概念実証）ばかり繰り返して本番導入に至らない」「データが汚すぎてAI以前の問題だ」。

筆者もいくつかのプロジェクトに関与したが、2025年の終わりを覆っている空気は、技術そのものへの失望ではない。むしろ、「何か根本的な構造が噛み合っていない」という閉塞感である。最新のNVIDIA製GPUを確保しても、最新のLLM（大規模言語モデル）を導入しても、現場の疲弊はいっこうに解消されない。

これは個人のスキル不足だろうか。あるいは、AIという技術がまだ未成熟なのだろうか。

そうではない、と筆者は考える。これは明らかに「構造」の問題である。

■『失敗の本質』の再現

かつて、日本の組織論における金字塔とも言える書籍『失敗の本質』では、旧日本軍の敗因を「戦略の不整合を、現場の精神論と工夫で埋め合わせようとしたこと」にあると分析した。驚くべきことに、2025年のDXやAI導入の現場では、これと全く同じ構図が再現されていると思う。

経営層は「AIで生産性倍増」という抽象度の高い戦略（というより願望）を掲げる。しかし、それを実現するための兵站（データ基盤）や作戦要綱（業務プロセスの再定義）は驚くほど軽視されている。結果として何が起きるか。「プロンプトエンジニアリングでなんとかしろ」「RAGの検索ロジックを現場でチューニングして精度を出せ」という、戦術レベルでの強引な突破が現場に課されることになる。

これは、補給路を断たれた部隊に「現地調達と気合で戦え」と命じているに等しい。

現場のエンジニアは優秀であるから、なんとか工夫を凝らす。複雑怪奇なスパゲッティコードを書き、手作業でデータを整形し、徹夜でチューニングを行う。一時的には動くものができるかもしれない。しかし、それは属人性の塊であり、少し条件が変われば破綻する砂上の楼閣だ。

余談だが、私がかつて汎用機（MシリーズやAS/400）の時代に経験したプロジェクトでも似たようなことがあった。経営の無茶な要望を、熟練プログラマーがCobolやアセンブラ言語の神業的な記述で実現してしまったのだ。そのシステムは確かに高速に動いたが、彼が退職した後、誰もメンテナンスできない「呪いの遺産」となり、数年後に数億円をかけた再構築を余儀なくされた。

2025年の今、我々はAIという最新鋭の武器を手にしながら、昭和の時代から変わらぬ「現場の工夫という名の無理」を積み重ねている。この構造的欠陥に気づかぬまま2026年を迎えても、待っているのはさらなる消耗戦だけではないか。

■技術的論拠としてのアーキテクチャ

では、具体的に何が欠落しているのか。

それは、技術の論理と経営の意志を統合する「設計図（アーキテクチャ）」である。

例えば、AIプロジェクトで最も頻発する「RAGの回答精度が低い」という問題を取り上げてみよう。多くの現場では、これを「LLMの性能不足」や「プロンプトの書き方が悪い」と捉えがちだ。しかし、深く掘り下げれば、真因の多くは「データの品質」と「ドメイン定義の曖昧さ」にある。

企業内のドキュメントは、往々にして非構造化データの墓場となっている。同じ「売上」という言葉でも、営業部と経理部で定義が異なることは珍しくない（出荷基準か、検収基準か、など）。

また、バージョン管理されていない古いマニュアルや、個人フォルダに散逸したExcelファイルが、そのままAIの学習データとして放り込まれる。

これでは、いかに高性能なAIを用いても、正しい答えが返ってくるはずがない。「Garbage In, Garbage Out（ゴミを入れればゴミが出てくる）」は、コンピュータサイエンスの不変の真理である。

ここで必要になるのは、小手先のプロンプト技術ではない。「データモデリングによる正規化」や「マスタデータの整備（MDM）」、そして処理の「冪等性（べきとうせい）」を担保したパイプラインの構築といった、極めて基礎的で地味なエンジニアリングだ。

「冪等性」とは、ある操作を1回行っても複数回行っても結果が変わらない性質のことだが、データ基盤においてはこの考え方が極めて重要になる。データの取り込み処理が途中で失敗したとき、何度やり直してもデータが重複したり欠損したりしない構造を作れているか。AIが参照するデータは、常に最新かつ正当な状態（Single Source of Truth）に保たれているか。

こうしたアーキテクチャの議論を抜きにして、「AIに聞けばわかる」環境など実現できるはずがない。PMの役割は、エンジニアの尻を叩いて進捗を管理することではなく、データが淀みなく流れる「水路」を設計し、システムの整合性を担保することにあるはずだ。

■視点の転換：管理から設計へ

2026年、プロジェクトマネージャー（PM）やDX推進担当者に求められるのは、役割の再定義である。

これまでのように、WBS（作業分解構成図）を引き、進捗率をExcelで埋め、遅れているタスクの担当者を詰めるだけの「管理者」であってはならない。そのような仕事はいずれAIエージェントがより正確にこなすようになるだろう。

人間が担うべきは、経営戦略を技術の骨格に落とし込む「アーキテクト」としての役割だ。

経営層が「顧客体験の向上」を掲げたとき、それを「CRMとコールセンターシステムのデータ統合」に翻訳し、さらに「リアルタイムでのデータ同期基盤の構築」へと具体化する。その際、法務的なリスク（個人情報保護法など）やセキュリティ要件、そして運用の持続可能性を考慮し、全体が調和する青写真を描く。これこそがアーキテクトの仕事である。

組織の中で、経営と現場、営業と開発、攻めと守りの間には常に摩擦が生じる。その摩擦は、放置すれば「熱（炎上）」となり、プロジェクトを焼き尽くしてしまう。しかし、適切なアーキテクチャがあれば、その摩擦をエネルギーに変換し、「光（価値）」に変えることができる。

現場から「キリキリ」という異音が聞こえたとき、「もっと頑張れ」と油を注ぐのではなく、機械の蓋を開けて設計図を見直し、「ここのギア比が合っていない」と構造的な解決策を提示する。それが、2026年のリーダーに求められる姿と思うがいかがだろうか。

■2026年への羅針盤：摩擦を光へ

最後に、2026年に向けて読者諸氏に持ち帰っていただきたい行動指針を3つ提示したい。

1. 「現場の工夫」を疑え

一見美談に見える「現場が頑張って対応しました」という報告こそ、アーキテクチャの敗北であると疑うこと。なぜその工夫が必要だったのか、標準機能やプロセスで解決できなかったのか、構造的な欠陥を深掘りすること。

2. データモデリングへの回帰

AI時代だからこそ、枯れた技術であるデータモデリングや正規化を見直すこと。AIは魔法の杖ではなく、データを食べる関数に過ぎない。綺麗な食事（データ）を用意するのは人間の責務である。

3. 調和（Harmony）の設計者たれ

PMの仕事は対立を調整することではない。対立が起きない構造を設計することだ。技術、ビジネス、法務、組織。これらの異なる論理を、一つの美しいシステムとして調和させることに注力せよ。

2025年の痛みは、無駄ではなかったと思いたい。それは我々が「小手先のDX」から卒業し、本質的な「構造改革」へと向かうための通過儀礼のようなものだったのかもしれない。

時代は、汎用機からクライアントサーバー、Web、クラウド、そしてAIへと移り変わってきた。しかし、システムを構築するという営みの本質──カオス（混沌）の中にコスモス（秩序）を作り出すこと──は、いつの時代も変わらない。

2026年、貴方のプロジェクトから軋む音が消え、代わりに美しい旋律が奏でられることを願っている。摩擦を熱にするか、光にするか。その分水嶺は、貴方が描く設計図の中にある。

よいお年を！

【本質を深く知るための推奨図書】

失敗の本質――日本軍の組織論的研究 (中公文庫) 戸部 良一、野中 郁次郎 他 (著)

本文中で引用した、組織論の金字塔。 太平洋戦争における日本軍の敗因を、「戦略の欠如」「現場への過度な依存」「学習棄却（アンラーニング）の失敗」といった観点から冷徹に分析している。

書かれているのは70年以上前の歴史だが、そこで語られる構造的欠陥は、驚くほど現在の「AI導入プロジェクト」や「DXの現場」に酷似している。 なぜ我々は、同じ失敗を繰り返すのか。2026年、アーキテクトとして組織を変革しようとする者にとって、必読の「教科書」である。