DXプロジェクトの意思は誰が握る? 「体制図を制するものがプロジェクトを制す」理由現場から見た「DXの真相」(3)

目指すべき目的が明確になり、いよいよDXプロジェクトが始まる……。そう思っていたのに気が付けばプロジェクト内調整しかやっていない。これはDXプロジェクトで陥りがちな「体制図の落とし穴」だという。

» 2019年12月13日 05時00分 公開
[渡邉 信之株式会社ゴルフダイジェスト・オンライン]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

 本連載は「真のデジタルトランスフォーメーション(DX)とは何なのか」というテーマで、第1回「単なるバズワードではない『DXの正体』とは何か」、第2回「DXプロジェクトはなぜ頓挫するのか? まず実施すべき『幹線の抽出』とは何か」と上流工程における考え方や進め方について解説してきました。第3回となる今回は「無事に目的を定義し、身の丈に合ったプロジェクトスコープが定義された後にどのような体制でプロジェクトに挑むべきか」を解説します。

誤解されがちな「プロジェクト体制図」の重要度

 プロジェクトが始まる際には、どのような形であれ必ず「プロジェクト体制図」があると思います。プロジェクト体制図は単なるプロジェクト名簿ではありません。アサインされた人がどんな役割で何の権限を持ち、誰に対して何の報告をするのか、誰とどの頻度でコミュニケーションを取るのかをセットで考えなければいけません。

 プロジェクト体制図作成で最低限守るべきルールをまとめると以下のようになります。

  • 役割と責任範囲、会議体設計をセットで定義する
  • レポートライン(縦の線)を熟考する
  • 組織図の横に伸びる線には意味を持たせる

 そして多くのプロジェクトはツリー型の体制図になりますが、3つの注意点があります。

  1. プロジェクト意思決定ラインに沿ったものか
  2. 不要なメンバーがアサインされていないか
  3. 深い階層構造になっていないか

 順に説明します。

1.プロジェクト意思決定ラインに沿ったものか

 プロジェクトには、さまざまな意思決定タイミングがあります。例えばプロジェクト要件や総合計画(マスタープラン)の決定などです。これはプロジェクトを進める上でのマイルストーンでもあります。

 ありがちな話ですが、こうしたマイルストーンで意思決定をするメンバーとして、プロジェクトマネジャーやプロジェクトリーダーの「組織上の上司」が名を連ねることがあります。つまり「上司の上司」が体制図上に現れ、プロジェクトの体制図が会社組織の体制図のようになってしまうのです。

 こうした体制はなるべく避けなければいけません。簡単に言うと「直接関係ない人は入れない」ということです。プロジェクトは有機的で横断的な性質を持つため、プロジェクトの体制(体制図)は俊敏性と柔軟性が確保されたものにする必要があります。

 著者はプロジェクト推進においては俊敏性や柔軟性、独立性に優れた「マトリクス型の組織が理想である」と考えます。

2.不要なメンバーがアサインされていないか

 組織図によっては、プロジェクトオーナーやプロジェクトマネジャーから派生する形で、複数の委員会(コミッティー)が設置されるケースがあります。

 大規模なプロジェクトになれば関連する人数が多くなるのは仕方ありませんし、こうしたコミッティーに対して「お伺い」や「相談」といった調整を事前にしておかなければ、後からトラブルやプロジェクトの中断につながることもあります。円滑にプロジェクトを進める上でこうした事前調整はプロジェクトマネジャーの大事な業務です。ただ、言葉を選ばずに言えば、こうしたコミッティーの調整はプロジェクトマネジャーにとって「面倒な仕事」です。

 このようなケースでは、できる限りプロジェクトマネジャーの負荷を減らす交渉を初期の段階で実施することを勧めます。具体的にはプロジェクトマネジャーが応対するコミッティーは1つに限定し、そのコミッティーのメンバーに「円滑なプロジェクト運営のための社内調整」という役割を設定するといいでしょう。プロジェクトマネジャーの解決すべき課題は山積みです。その上で直接関係のない「面倒な人たち」の相手をする余裕はありませんし、プロジェクトの成功確率を下げる要因となります。

3.深い階層構造になっていないか

 図の「コミッティーC」はプロジェクトマネジャーとプロジェクトリーダーの中間に位置しています。コミッティーBは「プロジェクトオーナーのサブ組織(コミッティーA)のサブ組織」という位置付けです。

画像 図 不要な「横に伸びる線」を作らない

 体制図においてこのような「横に伸びる線」には注意が必要です。基本的には「プロジェクトマネジメントオフィス」(PMO)の組織以外に横に伸びる線は不要と著者は考えます。役割や責任範囲が不明確になる原因になるためです。

 複雑で、深い階層を持つ体制ではマネジメントリスクが高まります。現場で発生する問題が隠蔽(いんぺい)されたり、気付くのが遅れたりする可能性がありますし、俊敏性も損なわれます。コミュニケーションロスや問題の解決に対し迅速に対応できるのは「プロジェクトマネジャー配下が2階層以内」と著者は考えます。

 プロジェクトの途中で体制図を変更することほど大変なことはありませんので、プロジェクトマネジャーは細心の注意を払って線を引かなければなりません。

体制図は目的から逆算して設計する

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。