キーパーソンへの集中をどう管理するか

DXプロジェクトでは、優秀な人材がプロジェクトを牽引することは避けられません。

むしろ、難易度の高いプロジェクトほど、業務とITの両方を理解し、複雑な状況を整理し、関係者の意見をまとめ、難しい意思決定を行える人材が中心になってプロジェクトを進める必要があります。

一方で、こうした人材には、自然と仕事が集中します。

• 難しい問題は、その人に相談する
• 判断に迷ったら、その人に確認する
• 関係者との調整も、その人が行う
• 成果物のレビューも、その人が行う
• 問題が起きれば、その人が解決する
• プロジェクト全体を見て、優先順位を決めるのも、その人である

結果として、プロジェクトを支えている優秀な人材が、プロジェクトそのもののボトルネックになっていきます。 これは、単純な「属人化の問題」として片付けることはできません。

優秀な人材への集中は、DXプロジェクトにある程度構造的に発生するものだからです。

重要なのは、集中をなくすことではありません。集中していることを前提に、その人材が過負荷になっていないかを継続的に把握し、問題が小さいうちにプロジェクトの進め方を修正することです。

そして、それでも状況が悪化した場合には、プロジェクトをスローダウンさせたり、場合によっては一度止めたりして、立て直しのための余力を確保する必要があります。

---

優秀な人材への集中は、DXプロジェクトの構造的な特徴である

DXプロジェクトの難しさは、単純にタスクの量が多いことではありません。業務、システム、組織、人材、経営、プロジェクトマネジメントなど、複数の要素が絡み合っています。

そのため、単に「決められた作業をこなす」だけでは、プロジェクトを前に進めることができません。状況を理解し、問題を構造化し、何を優先するかを判断し、関係者を動かす人が必要になります。

そして、そうした人材は非常に限られています。

DXプロジェクトを前に進められる人材は、そもそも希少である

DXプロジェクトで必要になる能力は、必ずしも一つの専門スキルではありません。例えば、

• 業務を理解する力
• IT・システムを理解する力
• プロジェクトマネジメント能力
• 問題を構造化する力
• 関係者を巻き込む力
• 意思決定する力
• 実行を管理する力

など、複数の能力が組み合わさって必要になります。

特に難しいプロジェクトでは、「ITに詳しい」「業務に詳しい」というだけでは十分ではありません。異なる専門性を持つ人たちの間に立ち、全体を見ながらプロジェクトを動かす能力が必要になります。そのため、こうした人材は社内でも限られます。

「問題が起きたので、別の優秀な人を一人追加しよう」と考えても、実際にはそのような人材が空いているとは限りません。コンサルティング会社などの外部組織であっても、難しいプロジェクトを立て直せる人材は希少です。

つまり、優秀な人材は、必要になったら簡単に追加できるリソースではないのです。

優秀な人材ほど、知識・判断・実行管理が集中する

優秀な人材には、自然と仕事が集まります。例えば、

プロジェクトで問題が起きたときに、「ちょっと、Aさんに相談してみよう」となります。

そして、一度相談すると、「では、Aさんに判断してもらいましょう」となり、

さらに、「Aさんに関係者との調整もお願いしましょう」となります。

こうして、本人が意図していなくても、徐々に重要な仕事が集中していきます。

この状態は、必ずしも悪いことではありません。むしろ、優秀な人材が中心になることで、プロジェクトが前に進んでいるケースも多いでしょう。

プロジェクトを牽引する人ほど、ボトルネックになりやすい

しかし、プロジェクトを引っ張っている人ほど、ボトルネックになりやすいという、一見すると矛盾した現象が起こります。

例えば、あるリーダーが10個の重要な判断を行っているとします。その人が能力を発揮している間は、10個の判断が素早く行われます。しかし、その人の処理能力を超えて20個、30個の判断が集まると、今度はその人のところで仕事が滞り始めます。

つまり、

「優秀だから仕事が集まる」
→「仕事が集まるからボトルネックになる」

という構造です。

💡 ポイント | ボトルネックになっていることは、「その人の能力が低い」という意味ではありません。むしろ、重要な仕事を担っているからこそボトルネックになっている場合があります。

問題は集中そのものではなく、集中した状態を放置することである

したがって、「属人化しているから、仕事を分散させよう」と単純に考えるのは適切ではありません。重要なのは、

「誰に仕事が集中しているのか」
「なぜ集中しているのか」
「その人にどの程度の余力が残っているのか」

を把握することです。

優秀な人材が中心になっていること自体は、むしろプロジェクトにとって必要な場合があります。

その状態を維持しながら、過負荷によってプロジェクト全体が壊れないようにする。これがプロジェクトガバナンスの重要な役割になります。

---

キーパーソンの過負荷は、プロジェクトの自己修復能力を奪う

キーパーソンが過負荷になることの本当の危険性は、「一人の作業量が増える」ことだけではありません。

より深刻なのは、プロジェクトを問題から回復させるために必要な能力そのものが、失われることです。

プロジェクトがうまくいかなくなったときには、

1. 何が起きているのかを把握する
2. 問題を構造化する
3. 真因を見つける
4. 対策を考える
5. 優先順位をつける
6. 関係者を動かす
7. 実行結果を確認する

というプロセスが必要になります。

ところが、この能力を持つ人が過負荷になっていると、目の前のタスクを処理するだけで精一杯になってしまいます。

過負荷になると、作業能力だけでなく「考える力」も失われる

過負荷になると、最初に失われやすいのは「考える時間」です。目の前の会議、メール、レビュー、問い合わせ、課題対応を処理していると、プロジェクト全体を俯瞰する時間がなくなります。すると、

「問題が起きていることは分かっている。でも、なぜ起きているのかを考える時間がない」という状態になります。

これは非常に危険です。なぜなら、プロジェクトの問題は、単純なタスク処理だけでは解決できないからです。

状況の構造化、立て直しの設計、実行管理も希少な能力である

「問題を整理する能力」は、誰でも同じように持っているわけではありません。さらに、

• 問題の優先順位をつける
• 複数の問題の因果関係を整理する
• 本当のボトルネックを見つける
• 現実的な立て直し策を考える
• その対策を実行に移す

という能力は、さらに希少です。

そして厄介なのは、これらを一人のキーパーソンがまとめて担っていることが少なくないことです。

キーパーソンを外して立て直すと、本質的な問題が見えなくなる

過負荷になっている人を守るために、「この人は忙しいから、立て直し策を考える場には入れないようにしよう」という対応を取ることがあります。

これは一見、合理的に見えます。

しかし、そのプロジェクトの実態を最も理解している人を外してしまうと、表面的な問題しか見えなくなる可能性があります。その結果、

• 会議を減らす
• メンバーを追加する
• タスクを細分化する

といった対症療法に終わり、本当の原因が残ってしまうことがあります。

キーパーソンが重要な役割を担い続けられるよう、負荷の構造を立て直す

だからといって、キーパーソンに「立て直し活動」という新しい仕事を追加すればよいわけでもありません。

重要なのは、キーパーソンが本来担うべき重要な役割を継続できる状態に戻すことです。そのために、

• 不要な仕事を減らす
• 優先順位を整理する
• 意思決定の方法を見直す
• 他のメンバーに任せられる仕事を明確にする
• 会議や報告を減らす
• プロジェクトそのものの速度を落とす

などを検討します。

つまり、「キーパーソンを外す」のではなく、キーパーソンが適切な負荷で重要な役割を担えるように、プロジェクトの構造を変えるのです。

「人を増やす」前に、過負荷の構造を見直す

過負荷が発生したとき、多くの組織ではまず「人が足りない」と考えがちです。しかし、DXプロジェクトの場合、これは必ずしも正しくありません。

そもそも優秀な人材は希少であり、簡単に追加できません。さらに、作業者を追加したとしても、それだけでキーパーソンの負荷が下がるとは限りません。

優秀な人材は社内にも市場にも余っていない

通常、重要な仕事を担っている優秀な人材には、すでに別の仕事があります。

したがって、プロジェクトで問題が起きてから、「誰か優秀な人を一人追加できないか？」と探しても、簡単には見つかりません。

外部のコンサルティング会社に依頼する場合も同様です。通常のコンサルティングサービスでは、すぐに立て直し能力の高い人を追加できるとは限りません。

「必要な時には、能力の高い人材を追加する」ことができれば助かりますし、期待したいところですが、残念ながら、アテにはできないのが現実です。

作業者を増やしても、指示・レビュー・調整が増えて負荷が高まることがある

例えば、5人でやっている仕事に3人を追加すれば、単純な作業量は増やせます。しかし、追加された3人に対して、

• 何をしてもらうのか
• どのように進めるのか
• 成果物はどう評価するのか
• 誰が判断するのか

を伝える必要があります。さらに成果物をレビューする必要もあります。その結果、キーパーソンの仕事が、

「自分で仕事をする」から「他人の仕事を指示・レビュー・調整する」

方向に増えてしまうことがあります。

💡 人を増やした結果、管理する仕事が増えて、キーパーソンがさらに忙しくなる。

DXプロジェクトでは、この逆転現象が起こり得ます。

人員追加ではなく、過負荷になっている真因を明らかにする

そこで重要になるのが、対策を急ぐ前に「なぜ過負荷になっているのか」を深掘りすることです。例えば、

重要なのは、「忙しいから仕事を減らす」という短絡的な対応をしないことです。

まず原因を見る。その上で、原因に応じた対策を考える。

真因に応じて、仕事・役割・意思決定・プロセスの構造を見直す

真因が分かれば、対応の選択肢が見えてきます。

例えば、キーパーソンに意思決定が集中しているのであれば、意思決定プロセスを見直します。チーム間の調整が原因なら、役割や責任範囲を整理します。不要なタスクが原因なら、そもそもその仕事をやめます。

重要なのは、人の頑張りで問題を吸収する構造を、仕組みとして変えることです。

必要であればプロジェクトをスローダウンし、立て直しの余力を作る

それでも解消できない場合には、プロジェクトの速度を落とす必要があります。プロジェクトをスローダウンすることは、一見すると後退に見えます。

しかし、過負荷のまま進め続けて、キーパーソンが倒れたり、プロジェクト全体が制御不能になったりするほうが、はるかに大きな損失になります。

「前に進み続けること」ではなく、「プロジェクトを成功させること」を目的にするなら、速度を落とすことも重要な選択肢です。

---

危機になる前に、プロジェクト運営を継続的に改善する

プロジェクトが危機的な状態になってから立て直すのは、非常に難しいことです。だからこそ、重要なのは、普段から小さな問題を見つけ、小さく修正することです。

そのためには、プロジェクトの「成果物」だけではなく、プロジェクトの運営そのものを観察し、改善する仕組みが必要になります。

リーダーミーティングを、率直に議論できる場にする

リーダーミーティングが単なる進捗報告会になっているプロジェクトは少なくありません。

「予定通りです」「○○を進めています」「課題はありません」

という報告を順番に聞いて終わるだけでは、プロジェクトの危険な兆候を捉えることはできません。

必要なのは、

「この進め方で本当に大丈夫なのか？」

「この人に仕事が集中しすぎていないか？」

「この問題は、実はもっと根本的なところに原因があるのではないか？」

といった議論です。つまり、リーダーミーティングを報告の場から、プロジェクトを良くするための議論の場へ変える必要があります。

リーダー以外のキーパーソンとも、非公式な接点を含めて頻繁に対話する

プロジェクトリーダーだけを見ていても、現場の問題をすべて把握できるとは限りません。むしろ、リーダーではないキーパーソンが、現場の問題を最もよく理解している場合があります。

そこで重要になるのが、公式な会議だけに頼らないことです。

• 定例会議
• 1on1
• プロジェクト後の雑談
• チャットでのちょっとした確認
• ランチやコーヒーなどの非公式な会話

こうした接点を意識的に増やします。

非公式な会話では、正式な会議では出てこない、

「実はちょっと気になっていることがあって……」

という情報が出てくることがあります。

こうした小さな違和感こそ、早期のプロジェクトガバナンスにおいて非常に重要です。

タスクだけでなく、プロジェクト運営上の課題も課題管理表で管理する

通常の課題管理表には、

• 要件が決まらない
• 開発が遅れている
• 不具合が発生している
• データが不足している

といった「タスクや成果物に紐づく課題」が記録されます。

しかし、これだけでは不十分です。例えば、

• 意思決定が特定の人に集中している
• リーダーの負荷が高すぎる
• 会議が多すぎる
• チーム間の調整がうまくいかない
• 課題解決が遅くなっている
• メンバーが懸念を言いにくくなっている

といったプロジェクト運営上の問題も、課題として扱うべきです。

これを課題管理表に載せることで、「なんとなくおかしい」という感覚を、正式な改善対象に変えることができます。例えば、以下のような管理です。

ID	プロジェクト運営課題	影響	対応方針	担当	状況
GOV-01	○○リーダーに意思決定が集中	判断待ちが増加	判断基準を整理	PM	対応中
GOV-02	リーダー会議が報告中心	問題が表面化しない	議論時間を確保	PMO	実施
GOV-03	チーム間調整が増加	リーダー負荷増	R&R見直し	PM	未着手

ここで大事なのは、「プロジェクト運営の問題も、プロジェクトの課題である」と認識することです。

---

状況に応じて、プロジェクトの運転モードを切り替える

どれだけ平時から改善していても、すべての問題を未然に防ぐことはできません。特に難易度の高いDXプロジェクトでは、想定以上の問題が発生することがあります。

そこで重要になるのが、状況に応じてプロジェクトの運転モードを変えることです。

モード	状態	基本方針
通常モード	自己修復できている	前進しながら改善
警戒モード	過負荷・問題集中が見られる	原因分析・負荷調整
危機モード	自己修復能力が低下	スローダウン・立て直し
リカバリーモード	内部だけでは困難	専門チームを投入

通常モード：前に進めながら、小さな改善を積み重ねる

通常時は、プロジェクトを進めることが中心です。

ただし、「問題がないから何もしない」のではありません。

リーダーミーティングで率直に議論し、キーパーソンと頻繁に対話し、プロジェクト運営上の課題も管理します。

つまり、前進しながら自己修復する状態です。

警戒モード：問題を深掘りし、仕事と負荷の構造を見直す

過負荷が目立ってきたら、通常モードから警戒モードに切り替えます。

この段階では、単純にタスクを消化することより、

「なぜ負荷が高まっているのか」

「どこに問題が集中しているのか」

を確認します。

必要であれば、キーパーソン自身にも状況整理に参加してもらいながら、負荷の構造を見直します。

危機モード：プロジェクトを止め、立て直しに集中する

プロジェクトの自己修復能力が失われてきたら、通常運転を続けること自体が危険になります。

この場合には、

• スコープを縮小する
• 新規タスクを止める
• 重要度の低い要求を後回しにする
• 会議や報告を削減する
• プロジェクトを一時停止する

など、明確に速度を落とす必要があります。

⚠️ 「止めること」が失敗なのではありません。

立て直せない状態のまま走り続けることのほうが、プロジェクトにとって大きなリスクです。

H3 内部で自己修復できなければ、リカバリー専門チームを投入する

一定以上に状況が悪化すると、プロジェクト内部のメンバーだけでは立て直せない場合があります。

その場合には、コンサルティング会社などにあるリカバリー専門チームを投入することが選択肢になります。

ただし、これは単純な「増員」ではありません。

通常のプロジェクトでは持ち込めない、

• プロジェクト診断
• 問題構造化
• リカバリー計画策定
• 経営層との調整
• 実行管理

といった、立て直しのための専門能力を投入するものです。

そして、この場合にも、通常運転を続けながら立て直すのではなく、プロジェクトを一度止める、または大きくスローダウンすることが重要になります。

---

プロジェクトガバナンスの目的は、「人を頑張らせること」ではない

プロジェクトが苦しくなったとき、組織はどうしても、「ここが正念場だから、もう少し頑張ってほしい」と言いたくなります。

実際、キーパーソンが頑張ることで、一時的にプロジェクトが持ち直すこともあります。しかし、それを繰り返していると、いつか限界が来ます。

プロジェクトガバナンスの目的は、優秀な人材の限界まで頑張ってもらうことではありません。その能力を、長期間にわたってプロジェクトに活かせる状態を作ることです。

優秀な人材の稼働率ではなく、「考える余力」を守る

優秀な人材が100％、120％稼働していることを「頑張っている」「貢献している」と評価してはいけません。

むしろ、重要なのは、

問題について考える余力が残っているか

です。

忙しすぎて目の前のタスクしか見えなくなっているのであれば、その人材を最大限活用できているとは言えません。

キーパーソンへの依存をなくすのではなく、依存を前提に管理する

DXプロジェクトからキーパーソンへの依存を完全になくすことは、現実的ではありません。

だからこそ、

「依存していることを認識し、その状態を継続的に管理する」

という発想が必要です。

例えば、

• 誰に判断が集中しているか
• 誰がいないと止まる仕事が何か
• 誰にレビューが集中しているか
• 誰の負荷が高まっているか

を定期的に確認します。

これは、人材を管理するというより、プロジェクトのリスク構造を管理することです。

問題を早期に発見し、小さく修正できる環境を作る

本当に強いプロジェクトは、問題が起きないプロジェクトではありません。

問題が起きたときに、早く気づき、小さく修正できるプロジェクトです。

そのためには、

• 本音を言える
• 違和感を共有できる
• キーパーソンと頻繁に話せる
• プロジェクト運営上の問題も課題にできる
• 小さな改善を実行できる

という環境が必要です。

最終的に目指すのは、人が潰れる前に自ら修正できるプロジェクトである

優秀な人材への集中を完全になくすことはできません。

しかし、集中していることを把握し、過負荷の兆候を捉え、問題の真因を考え、必要な対策を打つことはできます。

そして、通常の改善では追いつかなくなったら、スローダウンする。

それでも難しければ、専門的なリカバリー能力を投入する。

この一連の仕組みを持っていることが、プロジェクトガバナンスの重要な役割だと考えます。

最終的に目指したいのは、

「優秀な人が頑張り続けることで成立するプロジェクト」ではなく、「優秀な人が重要な仕事を担いながらも、潰れる前にプロジェクト自身が問題を修正できる状態」

です。

その意味で、プロジェクトガバナンスとは、プロジェクトを細かく管理するための仕組みではありません。

プロジェクトが自ら問題を発見し、考え、修正し続けられる状態をつくるための仕組みなのです。

---

難しいプロジェクトは、それができる人は少ないです。大変な状況では、だれか出来る人に頼りたくなります。

そして、それ自体は決して悪いことではありません。特定のできる人たちに委ねることは、良い点もあります。しかし、リスクもあります。

そういったリスクについても、十分に理解しながら、プロジェクトの状況を注意深く見ていくことが大事です。

最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。

ITプロジェクト研究会

---