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

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

[渡邉 信之，株式会社ゴルフダイジェスト・オンライン]

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

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

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

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

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

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

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

　順に説明します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　プロジェクトには達成すべき目的が必ずあります（参考記事：DXプロジェクトはなぜ頓挫するのか？　まず実施すべき「幹線の抽出」とは何か）。体制図を作成する際のアイデアとして「体制図を目的から逆算して定義する」という手法を紹介します。

　例えば「粗利率を5％改善する」という事業目標があるとします。そこからブレークダウンしたプロジェクトの目的が「物流コストを20％削減するためのシステム開発」だとします。プロジェクトのタスクの大半はシステム開発にはなるかもしれませんが、あくまでもプロジェクトの目的は「物流コストの20％削減」です。この20％の削減ができたかどうかを判断できる人をプロジェクトオーナーにします。

　プロジェクトオーナーは、このプロジェクトに対する資源分配や経営レベルでの意思決定が可能な人物を「ステアリングコミッティー」にアサインします。そして事業背景、業務を理解し「コスト20％削減を達成するためのシステム開発マネジメントができる人」をプロジェクトマネジャーにします。

　プロジェクトマネジャーは、仮に自身が「全ての作業をこなせるスーパーマン」であっても、自分を助けてくれる人物で構成したPMOを設置すべきです。

　PMOを設置している体制図はよく見掛けますが、ただ置いてあるだけ、というプロジェクトも少なくありません。PMOにも役割と責任範囲が存在しますので、単に情報を吸い上げる機関にならないようにすることが大切です。そのためには、各現場のキーパーソンをPMOにアサインし、その人物をプロジェクトの意思決定に巻き込むといいでしょう。「ひとごと」ではなく「自分事」にしてしまうということです。

「シンプルで機能的な体制図」はプロジェクトを成功に導く

　システム開発プロジェクトだからといって全てシステム部門のメンバーだけで構成する必要はありません。目的から逆算すると、余計な人を排除し、同時に他部門のメンバーも巻き込めます。そのため「シンプルで機能的な体制図」が描けるのではないかと思います。

　体制図はプロジェクトを成功に導くためにとても大切な役割を持ち、書き方、アサインの仕方を間違えるとプロジェクトマネジャーはとても苦労します。しかし日本のプロジェクトは実際の組織図上の上下関係が反映され、関係しそうな人はみんなアサインされることが多いのではないでしょうか。繰り返しますが、プロジェクトは有機的で独立性があるものなので、俊敏性と柔軟性を持った組織で対応する必要があります。

　荷が重いかもしれませんが「そんな体制ではプロジェクト運営できない」と伝える勇気をプロジェクトマネジャーには持ってほしいと思います。もちろんプロジェクトオーナーや経営層がプロジェクトマネジメントを理解することも必要です。

---

　次回は、既に立ち上がった上で難航しているプロジェクトなど「止まってしまったプロジェクト」のケース別に対策を紹介します。

筆者紹介

渡邉 信之（わたなべ のぶゆき）

株式会社ゴルフダイジェスト・オンライン

20年間IT業界に身を置き、ITベンダー時代はプログラマーからSE、プロジェクトマネジャーに従事。2016年に今のゴルフダイジェスト・オンライン（以下GDO）に入社。GDOではIT責任者として、多くの大規模プロジェクトの陣頭指揮を執る。現在は自ら新規事業を立ち上げ、タイにおけるゴルフ場予約サービスの事業責任者を務める。