アーキテクト育成にパワースキルが不可欠な理由｜正解のない時代の上流人材の育て方
栗林 陽「DXに取り組むかどうか」を議論する時代は、すでに終わりつつあります。IPAの調査では、DXに取り組む企業は全体で75.7%、従業員1,001人以上では98.7%に達しました（IPA「DX動向2026」）。次の問いは「何を変えられたか」です。生成AIも急速に広がりましたが、活用の中心はまだ業務効率化にとどまり、事業成果への波及はこれからの課題とされています。
こうした環境で価値を生むのが、「何を・なぜ・どう変えるか」を設計する人材——ITアーキテクトや上流人材です。ただし、この役割は技術研修だけでは育ちません。本記事では、アーキテクト・上流人材の育成において「パワースキル（パーソナルスキル／ソフトスキル）」がなぜ中核になるのか、そして「正解のない問い」に向き合う力をどう育てるかを、公的な人材標準と海外の先進事例をもとに整理します。
アーキテクトの役割は「作る」から「変革を設計する」へ移っている
「作る」プロセスそのものが変わり始めている
生成AIやAIコーディング支援、AIエージェントの登場で、要求・要件・設計・実装・テストという開発プロセスの前提が動いています。DORA 2025の調査では、仕事でAIを利用する人は約90%、生産性向上を実感する人は80%以上に上る一方、生成されたコードの品質を低く評価する声も約3割ありました。実装の生産性が上がるほど、「そもそも何を作るべきか」を定義する上流工程の比重が増していきます。
「要件を聞いて作る」から「変革を一緒に設計する」へ
従来のシステム開発は、顧客のIT部門が要求・要件をまとめ、開発側が設計・開発を担い、正確性・品質・納期・技術力で評価される構造でした。これからは、経営・事業部門・IT部門・開発パートナーが「なぜ変えるか」「何を変えるか」「どう実現するか」を一緒に考え、事業・業務・組織・データまで含めて実装と定着、効果検証までを見る形へと変わります。
アーキテクトは「技術に一番詳しい人」ではない
アーキテクトの役割は、経営戦略・顧客価値・ビジネスモデルといった事業領域、業務・データ・システム・セキュリティといった技術領域、そして将来像・コスト・リスク・関係者という判断軸を、一本につなぐことにあります。しかも「アーキテクト」は一つの職種ではありません。エンタープライズ、ソリューション、アプリケーション、データ、クラウド、セキュリティ、AIなど領域はさまざまですが、共通するのは「全体最適とトレードオフの中で意思決定し、説明責任を負う」という部分です。
国の人材標準も「事業と技術をつなぐ役割」を重視している
デジタルスキル標準が示すパーソナルスキル
IPAの「デジタルスキル標準 ver.2.0」（2026年4月改訂）では、ビジネスアーキテクト、ビジネスアナリスト、プロダクトマネージャーといった役割が、経営・事業の意図を事業構造や施策に翻訳し、優先順位・投資対効果・ロードマップ・関係者の合意をつくる存在として位置づけられています。そして、リーダーシップ、協働、目標設定、創造的問題解決、批判的思考、適応力といったパーソナルスキルが、特定の職種ではなく全ロール共通で重要とされています。
パワースキルとは何か
パワースキル（Power Skills）は、プロジェクトマネジメント協会（PMI）が2019年頃から提唱している概念で、変化の激しい時代に対応するための考え方・振る舞いを指します。呼び方は「ソフトスキル」「パーソナルスキル」「ヒューマンスキル」とさまざまですが、指している中身は近く、アーキテクトの文脈では次のような力に整理できます。
- 課題を設定する
- 情報を構造化する
- 優先順位をつける
- トレードオフを判断する
- 仮説を検証する
- 学習し、考えを更新する
- 関係者を巻き込み、判断を説明する
これらは、AIがどれだけ実装を助けてくれても、人が引き受けなければならない部分です。関連してAI時代に求められるヒューマンスキルについても整理しています。
不足しているのは「人数」だけではない
DX推進人材については、量・質ともに不足しているという企業が8割を超えます。ただし内訳を見ると、「求める人材像が曖昧」「評価基準がない」「評価・育成制度が未整備」といった回答も多く、単なる採用難ではなく「育ちにくい構造」が課題になっていることがうかがえます（IPA「DX動向2026」。DX推進人材全般の調査であり、アーキテクト単独の不足率ではありません）。
「正解のない問い」に向き合う力は、経験からしか育たない
AI時代ほど「AIと何を考えるか」が問われる
パーソル総合研究所の調査では、生成AIを使いこなす人ほど成果につながりやすい一方で、重要なのは利用量そのものよりも「AIと何を考えるか」だと指摘されています。同社は、情報を広く集めて構造的に整理する「集める」、優先順位をつける「決める」、現場で検証する「確かめる」、失敗から立て直し考えを更新する「壊す」、学びを自分や組織に残す「蓄える」という5つのメタスキルを挙げています。これらはそのまま、課題設定・構造化・トレードオフ判断・検証・学習というアーキテクトの仕事に重なります。
リアルな経験の重要性が増している
同じ調査では、AI時代ほど「手触り経験（自分の手で試す）」「見渡し経験（全体を俯瞰する）」「踏み出し経験（一歩踏み出して関わる）」といったリアルな経験が重要になるとされています。知る→経験する→振り返る→試す、というサイクルを回せる場をどうつくるかが、育成設計の焦点になります。正解が一つに定まらないテーマを扱う問題解決フレームワークのような「共通の型」も、経験を振り返るときの足場になります。
研修だけでは育たない
アーキテクト育成の全体像は、知識・研修だけでは完成しません。ジョブローテーション、実案件でのOJT、アーキテクチャ・設計レビュー、経験豊富な人からのメンタリング、そして社内認定や評価・処遇といったキャリア制度——これらを接続して初めて「育成の仕組み」になります。研修は重要ですが、あくまで一部だと捉える必要があります。
海外先進事例に共通する5つの考え方
Siemensは2006年から全社的なアーキテクト育成に取り組み、約9か月かけて基礎学習と実案件での実践を行き来させ、「実務で使えるか」で評価しています。IBMは経験者→専門家→第一人者と段階的に認定し、上位者には「顧客・事業課題の理解」「複数の解決策の提示」「チームを率いること」「後輩の指導・知識共有」まで求めます。AWSは設計判断そのものを記録し対話で磨く文化を持ち、Productboardは部署を越えた「アーキテクト・ギルド」で会社全体の学びの場をつくっています。英国政府とThe Open Groupは、若手→一人前→上級→組織横断リーダー→第一人者という成長段階を明確にしています。
- 求める能力を明確にする
- 実案件を教材にする
- 自分の設計判断を説明させる
- 経験者・同僚から評価を受ける
- 育った人が次の人を育てる
共通しているのは、「研修の時間だけで育てるのではなく、日々の仕事そのものを学習の場に変える」という発想です。
自社の育成を点検する7つのチェックポイント
- アーキテクトに求める能力を、言葉にして共有しているか
- 架空案件などの安全な場で、「要求整理→複数案の検討→判断→発表→フィードバック」を繰り返せているか
- 実案件の設計判断を、「背景→選択肢→判断→理由→影響」の形で記述させているか
- レビューが「答えを教える」ではなく、「なぜ？」「他の案は？」「条件が変わったら？」と問いかける場になっているか
- 他の人の案件のレビューにも参加する機会があるか
- 個人の経験を組織の知識に変える場（設計相談会、事例共有、ギルドやCoE）があるか
- 評価が「どれだけ知識を覚えたか」ではなく、「実案件でどう判断したか」で行われているか
アーキテクトや上流人材の育成は、技術研修の延長ではなく、「正解のない問いに向き合い、判断し、説明し、関係者を巻き込む」というパワースキルを、経験を通じて育て続ける仕組みづくりです。いきなり制度を完成させる必要はありません。まずは自社の育成が「知識提供」で止まっていないかを点検し、小さくパイロットを回しながら、育成モデルそのものを検証していくことが現実的な一歩になります。日本企業が置かれた状況はDXと組織変革の課題の記事でも取り上げています。
