プロジェクトマネジメントの現場から

ITプロジェクト経験から「凡事徹底」の実践知を発信します

「次の一手」が見えた後の仕事 〜 AI時代にプロジェクトマネージャが残る場所

プロジェクトマネジメント AI

「AIの波に乗れている気」になっていた

Claude Code を本格的に使い始めて2ヶ月が経ちました。段取り、壁打ち、ツール開発——たしかに業務は速くなりました。正直、AIを使えているつもりでいました。

ところが先日、自分が Claude Code をどう使っていたかを棚卸ししてみて、ひやりとしました。私がやっていたのは既存業務の中を整理する作業であって、現状のプロジェクトマネージャの仕事そのものを再設計しには行っていなかった。使えている気になっていただけだった、というのが正確なところです。進捗資料の効率化は前者、データから「次の一手」を導き出すところまでをAIに渡す判断は後者——同じAI活用でも階層が違います。

数字を一つ挙げます。パーソル総合研究所「生成AIとはたらき方に関する実態調査」（2026年2月3日発表）によれば、日本のマネージャの約6割が生成AIを業務で使っています（部長62.0%／課長58.3%）。けれども業務時間削減を実感したのは4人に1人。使ってはいるが業務に組み込めていない——多くのマネージャは、まだ「既存業務の中でAIを試す」段階を出ていません。私もまずその側にいて、さらに業務そのものを再設計する側に踏み込めていなかった——その認識から始めます。

「抱え続けるのが正解か」を疑う

クライアントワークをしている中で、いま正直に手放したい業務があります。代表的なプロジェクトマネージャの業務、例えば単純な進捗資料の作成と、データ集計などです。これらは、プロジェクトマネージャ自身が手を動かし、その過程で状況を深く掴み、自分なりの「次の一手」を見出すことに意味があると信じてきました。

けれども、2ヶ月AIと一緒に仕事をしてきた自分の仕事ぶりを見直して考えを改めました。AIが人間と同じ品質で仕事ができるようになる時代に、プロジェクトマネージャがそれを抱え続けるのは、果たして最適解なのか。むしろAIに任せるべき仕事はすべて任せたほうが、正しいのではないか。

AI に渡せる範囲は、思ったより広い

任せきれなかったのは「データ集計までは渡せても、そこから『次の一手』を導き出すのは人間の仕事だろう」という前提でした。その前提も、もう揺らいでいます。状況を読み解き、プロジェクトの「次の一手」を提示することまでを、AIが担える時代になりつつあるからです。

例えば、「過去の類似プロジェクトの稼働データから、特定のタスクで遅延が発生するリスクを予測し、回避策を出す」「チームメンバーのスキルと現在の負荷状況を掛け合わせ、最適なリソースの再配置案を提示する」といったことです。これまでは熟練のプロジェクトマネージャが経験則から導き出していたような次の一手すら、AIがデータから導き出してくるのです。

業界の追い風も鮮明です。米国プロジェクトマネジメント協会（PMI）は thought leadership レポート『Shaping the Future of Project Management With AI』で、「AIの基本を使いこなせることはもはや譲れない条件であり、プロジェクトマネージャーのDNAに組み込まれていなければならない」（"Fluency in the basics of AI is non-negotiable: it must be in the DNA of Project Managers."）と打ち出しました。一方で同レポートは「プロジェクトマネージャーの49%はAIの実践経験がほぼない」とも指摘しています。導入の旗は振られているが、現場の習熟が追いついていない。

市場側のスピードはさらに速く、Gartner は2026年末までに 40%の企業アプリケーションが task-specific AI agents を搭載すると予測しています（2025年時点では5%未満）。そのような中で、PMI は 2026年7月9日の PMP 試験改訂で、AI を3ドメイン（People、Process、Business Environment）横断のシナリオ・判断軸として正式に組み込みます。資格試験の構造変更は、職能の重心移動を遅れて追認するものです。

単純な進捗資料の作成やデータ集計の自動化が、既存業務の中の整理だとすれば、「次の一手」を導き出すところまでを渡すのは業務そのものを再設計する側の話です。プロジェクトマネージャがここまで踏み込む覚悟を持てるか——鍵はここにありそうです。

本丸は、「次の一手」が見えた後の仕事

では、AI が「遅延リスクへの回避策」や「最適なリソース配置」といった次の一手まで出してくれるとして、プロジェクトマネージャの業務はどこに残るのか。

データは「こうすべき」と指します。けれども組織は、そう動けない理由を山ほど抱えています。過去の人間関係、進行中の別案件、誰の顔を立てる必要があるか、何をいつ言えば飲み込めるか——「データが指す方向」と「組織が動ける方向」の間には、いつも段差があります。

この段差を埋める仕事は、関係者の利害・感情・タイミングを読みながら、合意を作り、動かす道筋を設計することです。いまのクライアントで標準プロセスの再設計を進めていますが、体感では実務の半分以上が「正しい標準を作ること」ではなく、「組織がその標準を受け入れて動ける状態を作ること」に費やされています。

ここで一つ事例を引きます。Klarna はスウェーデン発のフィンテック企業で、後払い決済（BNPL）を主力にグローバルで1億人を超えるユーザーを抱える、AI を業務に深く組み込んできた欧州テックの代表格です。その Klarna は2024年2月に「AIアシスタントが約700人分の業務量（顧客チャットの2/3）を処理している」と発表し、AI 活用の象徴企業として注目を集めました。ところが2025年5月、CEO Siemiatkowski はコスト偏重で品質が落ちたことを公に認め、人間カスタマーサポートを再採用する方針転換を表明します。AIを使って業務を再設計していた先駆者が、自ら方向を切り直した出来事です。

ここで読み解くべきは「AIはやはり力不足だった」ではないと思っています。

Klarna は AI 活用をやめたわけではありません。むしろ AI を使い続けながら、人間が担うべき領域を見直したのです。ここに、今回の論点があります。 つまり、何を残すかの設計を怠ったまま渡せば、組織からは静かに大事なものが蒸発する——という構造の話だと考えています。属人的な顧客理解、現場の判断ノウハウ、関係性の貯金。これらは置換と同時に静かに失われ、後から戻すのは容易ではありません。

思えば、PMIが「AIをDNAに組み込め」と言うのも、パーソル調査が「使ってはいるが組み込めていない」現状を示すのも、「何を渡し、何を残すか」を職能側が設計し直せという同じ問いの別表現です。

データから「次の一手」を導き出すことまではAIに任せられる。だとすれば「残すべきもの」の中心は、まさにその次の一手が見えた後の仕事——合意形成と組織変革の道筋を引く仕事——なのではないでしょうか。どれだけAIが進化し、人間を超えるスピードで正解にたどり着けるようになっても、「当事者同士の納得感」が不可欠である以上、この泥臭い実装作業は人間側に残ります。プロジェクトマネージャが残る場所は、このような場所ではないか。

明日から手放すこと、注力すること

現時点の結論を、自分に向けて書いておきます。

単純な進捗資料の作成やデータ集計などは手放し、AIに渡します。 データから「次の一手」を導き出すことも、渡せる範囲は積極的に渡します。その先の「次の一手が見えた後の仕事」——段差を埋める実装の領域——に、自分自身のリソースを集中させます。

出典

「同期しているはず」が、止まっていた

プロジェクトマネジメント AI

「同期しているはず」だった

設定はした。動いていた。確認もしたつもりだった。それなのに、止まっていた。

と言うのは、Mac間の自動同期スクリプトのことです。2台のMacが30分おきに裏側で最新の状態を取りに行く——そういう仕組みを組んでいました。組んだのは私自身ですが、書いたのは私の手ではありません。Claude Codeに対話で指示を出し、組み上げてもらった仕組みです。

気づいたのは、動かなくなってから3日後の朝です。片方のMacで編集したファイルが、もう片方に届いていない。記録を見ると、停止していたのは3日前からでした。

止まっていたこと自体より、3日経つまで気づけなかったことの方が、私にはショックでした。「動いている」という前提を、検証していませんでした。設定した本人である私自身が、その前提を疑わなくなっていたのです。

念のため、これは私の手元の作業環境を整えるための、個人的な自動化です。業務クリティカルな仕組みではなく、止まっていても顧客や案件に影響は出ていません。ただ、AIに仕事の一部を任せ始めた人間としては、止まっていることに3日気づけなかった事実そのものが、見過ごせないと感じました。

私は、AIを業務に積極的に取り入れています。Claude Codeも毎日使っています。だからこそ、記録として残しておこうと思いました。

AIに組ませた仕組みは、組んだ過程が薄い

なぜ、3日も気づけなかったのか。

技術的に言えば答えは単純です。死活監視を仕込んでいなかったから。それだけです。停止を通知する仕組みを最初から組み込んでおけば、3日も放置されることはありませんでした。

ただ、私がこの記録で本当に問いたいのは、なぜ私は、監視を仕込もうとさえ思わなかったのか。

振り返って気づいたのは、自分の手で書かなかった仕組みは、組んだ過程が薄いということでした。

自分でコードを書くとき、人は書きながら何度も「これは何のための処理か」を考えます。動作確認の手順を考え、失敗したときの挙動を想像し、止まったときに自分が困る場面を頭の中で何度も想像します。その過程で、自然と「止まったら困るから、通知を入れておこう」という発想が立ち上がります。コードを書く時間そのものが、目的を体に染み込ませる時間です。

AIに組ませると、その時間が抜けます。

「2台のMacを同期したい」と指示を出すと、Claude Codeは数分でコードを書き上げます。動作確認を通せば、それで完成。早い、便利、たいてい動く。けれど、書きながら何度も問い直す時間はありません。私の指示は「同期したい」までで、「何のために同期したいのか」「止まったらどう困るのか」を、私自身がよく考えていませんでした。だから、止まったときに通知を受け取る仕組みを足すという発想に至りませんでした。

動いていることが、目的にすり替わる

仕組みは動いている。動いていることが確認できる。すると次第に、動いていること自体が目的になっていきます。本来の目的——「2台のMacの間で迷わず作業を続けるため」——が、意識の表に上がってこなくなる。仕組みが目的を覆い隠していく、と言ってもよいかもしれません。

そうなると、例外が起きても気づきにくくなります。「動いているはず」という前提に意識が貼りついていて、「そもそも何のための仕組みだったか」が薄れているからです。

AIに任せる範囲が広がるほど、この距離は伸びていきます。コードを自分で書かないから過程が薄れ、過程が薄いから目的が薄れ、目的が薄れているから止まっても気づかない——順番に並べると、別々の出来事に見えて、実は1本の線で繋がっています。

AI導入の現場で、同じ構造を何度も見ている

私個人の話として書いてきましたが、PMO支援の現場でも、規模は違えど同じような構造を見ることがあります。匿名化したうえで、2つのパターンを挙げます。

1つ目は、判断をAIに委ねた結果、判断基準そのものが現場から消えたケース。最初は人が判断していた領域に、AIの提案を補助として入れる。便利だから、次第にAIの提案がそのまま採用されるようになる。やがて、人は「なぜその判断が正しいのか」を説明できなくなる。

2つ目は、自動化のための自動化が走り始めたケース。本来は業務効率化が目的だったのに、いつの間にか「自動化された範囲を増やすこと」が目的にすり替わる。目的が不明確な、止まっても気づかない仕組みだけが、静かに量産されていきます。

これは私の現場感覚だけの話ではありません。米国のITリサーチ会社Gartnerは、2025年6月のプレスリリースで、企業のagentic AI（自律型AI）プロジェクトのうち約40%が2027年末までにキャンセルされると予測しています。主因として挙げられているのは、コストでも技術でもなく、「不明確なビジネス価値」——つまり、何のために導入したかが現場で答えられなくなる状態です。AIプロジェクトの主要なつまずきの場所は、技術ではなく目的の漂流に移りつつあります。

これらの事例で、AIの導入そのものは原因ではありません。トリガーにすぎません。問題は最初から内包されていて、引き金が引かれるのを待っていただけです。

そして、いずれの現場にも共通していたのは、「そもそも何のためにこの仕組みを作るのか、使うのか」が、現場の意識から消えていたことでした。動かすこと、入れること、進めることに精一杯で、目的を問い直す余白がなかった——そういう順番でした。

AI時代の凡事徹底とは、目的を問い続けること

今回の出来事から得た学びを1行で言うと、AIに任せても、目的を持つのは人だということです。

AIは早く、正確で、たいてい疲れません。ただ、AIは今のところ「何のために」を問いません。私の指示通りにコードを書き、私の指示通りに同期し、私の指示通りに動き続けます。目的を持つのは、依頼した側の人間だけです。

私が大切にしている言葉に「凡事徹底」があります。あたりまえのことを、あたりまえに、徹底してやり続ける。AIに任せる範囲が広がる時代の凡事徹底とは、AIに任せた後も、何のためにそれを動かしているのかを、定期的に問い直し続けることだと、私は捉えています。

具体的には、次の3つを置くと効きます。

第一に、任せる前に、何のために任せるのかを1行で書く。 指示を出す前に、紙に書くか、メモに残す。「効率化のため」では曖昧すぎます。「誰のどんな状態を、どう変えたいのか」まで言葉にする。先ほどの私のMac同期で言えば、「同期したい」ではなく「2台のMacの間で迷わず作業を続けるため」と書く。前者は手段、後者が目的です。この1行があれば、止まったときに「届かなくなったのは何か」が見えます。「同期が止まった」ではなく、「迷わない作業が壊れた」と気づける。

第二に、任せた後も、定期的に立ち返る仕組みを作る。 例えば、週に1回、定例会議の冒頭5分でかまいません。上で書いた1行を読み返し、「この目的は今も生きているか」「この目的を果たすために、止まっていたら困ることは何か」を確認します。「このAI活用は、当初の目的を果たしているか」——この点だけを問います。意図を問い直すのは、人の側に残る仕事です。

第三に、AI自身に、AIを点検させる。 ここで一つ、書きながら痛感したことがあります。そもそも私が死活監視を仕込まなかった理由のひとつは、「個人の仕組みにそこまでの開発コストはかけられない」という、過去のエンジニアリングの常識に縛られていたからでした。しかし、組んでくれるのがAIなら、死活監視を1本足すコストは対話で数分です。技術のコストは下がったのに、私自身の判断基準だけが昔のまま残っていたのです。長年ITの現場にいる人間ほど、こうした「無自覚な常識の引きずり」には注意が必要です。

コストの常識が変わったからこそ、AIに点検させるという発想が成立します。もう一歩進めるなら、定例の問い直しの場に、AIを同席させる設計もあります。具体的には、「週に一度、AIに過去の稼働ログや利用状況を解析させ、『当初の目的から逸脱していないか』『放置されているエラーの兆候はないか』をレポートさせるプロンプト」を定期実行する仕組みです。AIを使う側の人間が、AIを使ってAIを問い直す——これがAI時代の凡事徹底の、もう一段進んだ形ではないかと考えています。

まず、自分のプロジェクトに「目的の見える目」を1つ足してみる

自分の関わるプロジェクトに、AIに任せている範囲があるか。 任せた後も、「何のために任せたか」を問い直す目があるか。 そして、止まったときに、気づける仕組みがあるか。

まずはそこから、と私は考えています。

AIを導入したその先に、目的を見失わないための「問い」を設計できているでしょうか。もし、そこに少しでも死角を感じるのなら、プロフェッショナルな外部の目——例えばPMO——を入れてみることも、プロジェクトを正しい軌道に保つための一つの「凡事徹底」です。

情報を「整える」だけでは、プロジェクトは動かない

プロジェクトマネジメント PMO 情報の可視化

ドキュメントはある。ツールも入れた。会議もやっている。
それなのに、なぜかプロジェクトが前に進まない。

こんな状態に心あたりはないでしょうか。

やるべきことはやっている。手を抜いているわけではない。
なのに、会議では毎回同じ話が蒸し返される。誰に聞けばいいのかわからない。
資料はあるのに、どれが正しいのかわからない。

このモヤモヤの正体は、「情報が足りない」ことではありません。
情報が、人を動かす形になっていないこと。
そして、整えた形を維持する仕組みがないことです。

体制図を1枚描いたら、会議の空気が変わった

あるプロジェクトに途中から参画したときの話です。

チームの人数は20名ほど。進捗会議は毎週やっている。議事録もある。
でも、会議中に「それは誰が担当でしたっけ」という確認が何度も入る。発言も少ない。
どこか他人事のような空気が漂っていました。

私がまずやったのは、体制図を1枚描くことでした。

特別なものではありません。
誰が何の責任を持っているか。
誰がどのチームに属しているか。
報告ラインはどうなっているか。
それをA3用紙1枚に整理して、会議室のホワイトボードに貼りました。

ただ、貼っただけでは何も変わりませんでした。

最初の会議では、誰もその体制図に触れなかった。
それでも、課題の確認や役割分担の場面で、私はそのたびに体制図を指しながら話しました。
「この部分の担当はここですよね」と。

何回か繰り返すうちに、少しずつ変化が出てきました。
「ここは自分の担当範囲です」と手を挙げる人が出てきた。
「この部分はAさんと連携が必要ですよね」と、横の繋がりを意識した発言が増えた。
情報は以前からあったのに、それまで誰も「自分がどこにいるか」を俯瞰できていなかったのです。

ただし、これには続きがあります。

数ヶ月後、メンバーの異動があったとき、その体制図は更新されていませんでした。
会議では再び「それは誰の担当？」が飛び交い始めた。

体制図があったことは覚えている。
でも、誰も更新しなかった。
つまり「あると便利」とは感じても、「自分たちで維持するもの」とは思われていなかった。

「誰が、何を、いつまでに」が見える状態を作る。
それだけで、人の動き方は変わります。

チャットの散乱を止めたら、「楽になった」と言われた

別のプロジェクトでの話です。

そのチームでは、チャットツールを導入していました。
情報共有のスピードは上がったはずでした。

でも現実には、重要な連絡が雑談の中に埋もれ、確認したい情報が見つからない。
「あの件、どこに書いてありましたっけ？」というやり取りが一日に何回も発生していました。

チャンネルの数を確認すると、使われているのかいないのかわからないものが大量にある。
一方で、本来分けるべき話題が1つのチャンネルに混在している。

最初は、段階的に整理しようとしました。
一部のチャンネルだけ新しいルールに移行し、残りは後から対応する予定でした。
結果、「この話題は新旧どちらのチャンネルに書けばいいのか」という混乱が生まれ、整理前より状況が悪くなりました。

そこで一度立ち止まり、チャンネル全体の設計をやり直しました。
「このチャンネルには何を投稿するか」を明文化し、技術的な課題はここ、スケジュールの相談はここ、雑談はここ。
シンプルなルールを決めてから、一気に切り替えました。

現場の反応は、「楽になった」の一言でした。

この運用は、今も続いています。

なぜ続いたのか。
後から振り返ると、「一気に切り替えたこと」が大きかったと思います。
段階的にやろうとしたときは、「どこに書けばいいか」の迷いが最後まで残った。
一気に切り替えれば、迷う余地そのものがなくなる。迷わないから、続く。
そういうことだったのだと思います。

やったことは地味です。
でも、「どこを見ればいいかわからない」という状態は、想像以上に人を疲弊させます。
可視化の効果は、情報がきれいに整うことではありません。
人が迷わなくなること。それが一番の変化です。

つまずく場所は、いつも同じ

30年近くこの仕事をしてきて気づくのは、プロジェクトがうまくいかなくなるパターンは、時代が変わっても同じだということです。

ツールは進化した。手法も増えた。
でも、「誰が何をやるのか曖昧なまま走り出す」「決めたことが共有されない」「課題を放置する」
——つまずく場所はいつも同じです。

結局、プロジェクトは人の営みだからです。

先ほど紹介した2つのエピソードも、そこが分かれ目でした。
体制図は、描いた時点では効果があった。
でも「自分たちで維持するもの」と思われなかったから、メンバー異動の瞬間に形骸化した。
一方、チャンネル整理は、迷いなく使える設計にしたから、運用が続いた。
違いは、「続く仕組み」を最初から組み込んだかどうかです。

可視化は作った瞬間がピークで、そこから静かに形骸化していく。
放っておけば、必ずそうなります。
続ける仕組みを先に設計しなければ、いくら整えてもいずれ元に戻る。

可視化は一度やれば終わりではありません。

体制が変われば体制図を更新する。
新しいメンバーが入ればルールを共有する。
課題管理表は毎週見直す。

運用し続けて初めて機能します。

つまり可視化とは、仕組みではなく習慣です。
日々のあたりまえの積み重ねが、プロジェクトを前に進める力になります。

まず1つ、可視化してみる

ここまで読んで、「うちのプロジェクトにも当てはまるかも」と感じた方へ。

まず明日からやってみること、行動を起こすことが肝心です。

たとえば、チームの体制図を1枚描いてみる。
チャットのチャンネル構成をシンプルに見直してみる。
あるいは、次の会議の後に決定事項を3行で共有してみる。

始めることと続けることは別の話です。
この記事で繰り返し書いてきたように、可視化は作った瞬間がゴールではありません。
更新し、共有し、習慣にする。本番はそこからです。

まずは小さく始めてみる。
そして、続ける仕組みまで考えたくなったら、一人で抱え込まず、周りの人の視点を入れてみるのも手です。