AI時代にプロジェクトマネージャーはどこへ向かうべきなのか？ 日本のJSOLにおける「利益」の定義を巡る論争からPMの新たな5つの基本スキルを理解する
同じ会社、同じ「利益」という言葉、管理部門が計算した数字と事業部門の手元にある報告書は同じではありません。 どちらの意見も正しく、意味が異なるだけです。
これは、日本のシステムインテグレーターである JSOL のプロジェクトマネージャーである坪内進氏が、大手メーカーの原価管理プロジェクトで直面したボトルネックです。 人々が他の人と会議をするとき、この曖昧さは暗黙の理解と経験によって克服できます。しかし、AI にデータ分析を依頼すると、AI は暗黙の理解をまったく持ちません。定義の異なる数値を文字通り混合して一緒に計算するだけです。
この事例から始めて、多くの PM が考えている質問に答えたいと思います。 AI によって物事の処理速度が大幅に向上しても、企業には依然としてプロジェクト マネージャーが必要ですか?
私はプロジェクトマネージャーとして働いていたので、このトピックには特に興味があります。
まず、AI がどの部分を奪ったのかを明確に確認します
2019 年 3 月、Gartner は、2030 年までに今日のプロジェクト管理業務の 80% が AI に引き継がれるだろうと予測するプレスリリースを発行し、その後何度も引用されました。 多くの人は 80% という数字だけを覚えていて、Gartner が名付けたデータ収集、進捗状況の追跡、出力レポートを忘れています。 これらは PM の多くの時間を費やしますが、機械によって迅速かつ正確に実行されるのが最も簡単です。
つまり、奪われたのはPMの仕事のうち「情報を伝える」という層だった。 あとは、何を、どこに、誰に移動させるかを決めるだけです。
PMI (Project Management Institute) は 2023 年の プレス リリース（新しいタブで開く） で別の数字を示しました。AI ツールに関する確かな、または十分な実務経験があると答えたプロジェクト マネージャーは 18% のみで、49% はプロジェクト管理の文脈における AI の経験や理解がほとんどありませんでした (PMI は、これは非公開の内部調査であると指摘しました)。 仕事の内容は変化しており、ほとんどの人はついていけません。
これら 2 つの数字を組み合わせると、質問は非常に具体的になります。 情報を伝達する仕事が引き継がれた後、PM は現場に留まるために何を頼りにできるでしょうか?
坪内伸志の答え：「実は、あまり変わっていないんです」
2026 年 10 月に Ledge.ai によって公開されたこの 独占インタビュー（新しいタブで開く） の中で、記者は坪内氏に AI が PM の仕事を変えたかどうかを尋ねました。 彼の答えは予想外でした。「PM としての仕事のやり方は、以前とあまり変わっていないと思います。」
まず記事の内容を説明しますと、これはJSOLの採用面接です。記事の最後には採用リンクがあるので、これを読むときは採用目的があることを忘れないようにしましょう。 ただし、ここで説明されているプロジェクトのプロセスは非常に具体的であり、一見の価値があります。
坪内（新しいタブで開く） が「変わっていない」と述べたのは、顧客を理解し、問題を特定し、仮説を立て、プロジェクトを進めるという PM の中核的なタスクのことです。 変わったのは、これらのタスクの重さです。 これまで、PM はスケジュールの調整と進捗状況の追跡に多大な労力を費やしていました。現在、それらはツールに引き継がれ、最初のいくつかのことがプロジェクトの成功または失敗を直接決定します。
彼のプロジェクトから、AI時代にPMが実践すべき5つの基本スキルを整理しました。
基本スキル 1: ビジネス言語をデータ言語に翻訳する
再び「興味」の壁へ。 坪内氏のチームは、AIが信頼できる分析を行うためには、まず「ビジネス用語」と「実際のデータフィールド」を1対1で照合する必要があることを発見した。 日本の業界ではそれを「ビジネスセマンティクス」と呼んでいます。テクニカルキャリアはセマンティックレイヤーです。つまり、どの数値が何を表しているのか、企業は粗利益をどのように定義しているのか、営業利益はどのレベルで計算されているのかなどです。
坪内の原文は「AIが高度な分析を行うためには、ビジネス用語と実際のデータを結びつける必要がある」だった。
この件は以前からあったのですが、先輩社員の頭の中に隠蔽され、皆が暗黙の了解で回避していました。 AIが登場すると、こうした暗黙の了解はすべて書き留めておかなければなりません。 誰がそれを書きますか？ エンジニアはビジネスを理解しておらず、ビジネスもデータ構造を理解していません。首相はその真ん中に立っている。
したがって、PM は SQL を書ける必要はありませんが、「同じ言葉、2 つの部門が異なることについて話している」ことを聞き、定義を明確にするための対話を主催することができなければなりません。
基本スキル 2: まず仮説を立て、次に顧客に間違いを尋ねる
定義を明確にするにはどうすればよいでしょうか?坪内氏のチームも当初は顧客に直接「定義してください」と尋ねたが、答えはなかった。 マネージャーや事業部門の責任者は皆、異なるビジネスに注目しており、必要な数値も異なります。 「どの数字が正しいか」について合意に達することは困難です。
そこで、実際のデータから考えられるモデルをいくつか挙げ、次にユーザーの役割や業務に基づいて、どのモデルがより適しているか仮説を立てて顧客に提示するというアプローチに変更しました。 坪内氏は「最初から100点を取ることはもちろん不可能。まず仮説を提示して相手にフィードバックを求め、その結果をもとにモデルを追加したり集約したりする」と語る。
これはインタビュー全体の中で、PM がコピーバックするのに最も価値のあるセクションだと思います。 顧客にニーズを一から述べてもらうと、相手が説明できないことがよくあります。具体的にダメなところをあげれば、「これはダメだ」「この状況はこうなる」「じゃあ、私もこれが見たい」とすぐに分かります。
坪内氏は、覚えやすい言葉として「顧客が言ったら、その裏にある仮説を 10 個思いつくことができますか」と述べました。 PMの価値は、顧客が自らニーズが現れるのを待つのではなく、顧客が次の判断を下すためのものを手にできることにあります。
基本スキル 3: 最初にどのプロトタイプを作成するかを決定する
仮説を検証したい場合は、何かを作成する必要があります。 これまでのプロトタイプは静的な画面表示がほとんどで、核となるロジックや動的なインタラクションが欠けており、ユーザーエクスペリエンスを効果的に検証することが困難でした。いくつかの画面図を見ただけでは、顧客は外観についての意見しか得られず、「これが本当にビジネスに役立つのか」を判断する方法がありませんでした。
このプロジェクトでは、坪内氏のチームは Databricks を使用して、顧客の実データに直接接続するプロトタイプを短期間で作成しました。また、AI/BI Genie 機能を使用して、ユーザーが自然言語を使用してデータについて直接質問できるようにしました。 顧客が自らの数字で結果を確認すると、当初は気づいていなかった課題が浮かび上がってきます。
モノの製造コストが下がるとPMへのプレッシャーが減るように思えますが、実際はその逆です。 記事の中に私も同意する一文があって、コストが低ければ低いほど、「何をするか」「どの問題を最初に解決するか」という判断の価値が高まるというものです。 10 個の解決策を試すことができますが、どの 3 つを最初に試すか、そして有用なフィードバックを得る前にそれぞれの解決策をどの程度詳しく説明するかを決定する必要があります。 このような選別能力については「答えが無価値になったとき、判断こそが唯一の複利資産」でもお話しましたが、それはプロジェクト現場のPMの日常でもあります。
基本スキル 4: チーム分けがどのように変化するかを事前に確認する
このセクションは比較的注目されていません。 坪内氏はプロジェクト開始前にDatabricksのAI機能をテストし、「データを収集してデータを加工する」といった従来のデータエンジニアリング作業が圧縮されると判断した。 そこで同氏はチームを結成する際、通常のようにデータエンジニアの集団をあえて配置せず、顧客と直接指標について議論できるアナリストを見つけ、データ処理も外部委託するよう依頼した。
プロジェクトが進行した後、この構成は実際に機能しました。 坪内氏は「狭義のデータエンジニアリング、つまりデータ処理だけを行う部分は、それ自体ではますます価値が薄れていくだろう」と判断する。
PMにとってこれは新たな仕事内容であり、他の人が人員報告書を作成し続ける前に、まずは自らツールを触って、どの役割が減り、どの役割が拡大するかを予測し、それに応じてチームを編成しなければなりません。 この問題を AI に委託することはできません。なぜなら、AI には自分自身のプロジェクトや従業員について判断する必要があるからです。
基本スキル 5: 現在のラインからもう 1 歩横に移動する
最後の段落では、この仕事に向いている人はどんな人なのかと坪内さんに尋ねた。その答えは「今までのスキルを他の分野で掛け合わせたい人」でした。
彼は二つの方向を指さした。 エンジニアリングのバックグラウンドを持つ人は、SAP や顧客業界に精通した同僚とプロジェクトに取り組むことができ、その専門知識をビジネス面にまで拡張できます。企業内で特定のビジネスを行ったことがあり、顧客の話を聞いてその背後にある 10 の事柄を想像できる人は、AI、システム開発、プロジェクト管理を追加して、自分のビジネス知識を別の方法で使用できるようになります。
AI により実装の敷居が下がるため、PM はツールを自ら使用して仮説を検証でき、エンジニアは顧客のビジネスに深く入ることができます。 ポジション間の壁が短くなり、もともと一つの専門に特化していた人が両側から攻撃されやすい。
「PM にはソフトスキルしかないのではないか?」と疑問に思う人もいるかもしれません。
これを読んで、この記事は「コミュニケーション、共感、リーダーシップが最も重要」という決まり文句について話しているのではないかと思う人もいるかもしれない。 しかし、私は全く逆のことを考えています。
坪内氏のアプローチが成立する理由は、坪内氏がDatabricksのAI機能をまず自らテストし、何ができるかを知っているからだ。彼は、顧客に「まずは実際のデータでプロトタイプを作りましょう」とあえて言います。 それは、これが 2 ～ 3 週間で完了できることを知っているからです。 対象に対する実際的な感覚がなければ、保守的すぎるとチーム編成が同じままになり、判断が不正確になります。
PMIの18％という数字は、このギャップを示している。 AI 時代の PM は、ツールを理解するビジネス翻訳者でなければなりません。 手はツールに触れ、頭はビジネスを理解し、口は部門を超えた定義に関する会話をホストできなければなりません。どれか一つでも欠けていると、この5つの基本スキルを練習することができません。
今月から始められる 3 つのこと
この3つは予算も必要なく、企業のAI導入を待つ必要もありません。 PM は自分で始めることができます。
- 取り組んでいるプロジェクトで最も頻繁に言及される指標 (収益、粗利益、アクティブ ユーザーはすべて許容されます) を選択し、2 つの異なる部門の担当者にその計算方法を尋ねます。 答えが異なる場合は、最初のセマンティック レベルのジョブが見つかったことになります。
- 次の要求面接では、手ぶらで「何が必要ですか?」と尋ねないでください。 まず仮説の大まかなバージョンを持参し、相手に間違いを修正してもらいます。
- 週末を使って、AI データ ツールやプログラム開発ツールを使用して、実行できる小さなものを作成します。 転職してエンジニアになることが目的ではなく、次回仕事を見積もったり、チームを結成したりするときに、現在のツールで何ができるのかを知ってもらうことが目的です。
ものづくりはどんどん早くなっていきますが、プロジェクトは勝手に前に進みません。坪内氏はインタビューの最後に、ビジネスの成功に標準的な答えはない、と語った。 PMの仕事は、顧客が振り返って「あの選択が最善だった」と思えるまで、顧客と一緒に試していくことです。この文はAI時代にも同様に当てはまります。
参考文献
- Ledge.aieのない目をつぶって、どう前に入るか。 AI 時代の PM のクエスト、2026 年 10 月 27 日: https://ledge.ai/articles/jsol_career_interview_pm（新しいタブで開く）
- Gartner、「ガートナー、人工知能の普及に伴い、今日のプロジェクト管理タスクの 80 パーセントが 2030 年までに廃止されると発表」、2019 年 3 月 20 日: https://www.gartner.com/en/newsroom/press-releases/2019-03-20-gartner-says-80-percent-of-today-s-project-management（新しいタブで開く）
- PMI、「AI スキルを持つプロジェクト プロフェッショナルの需要が増加しているが、PMI の調査では実務経験があるのは 18% のみであることが判明」、2023 年: https://www.pmi.org/about/press-media/2023/demand-increases-for-project-professionals-with-ai-skills（新しいタブで開く）
