「誰が決めるのか」が分からない現場の実態
Webシステム開発の案件で、発注者が「ディレクターに相談します」と言ったとする。しかし受託側のディレクターは「それはPMの判断です」と返し、PMは「デザインの話はディレクターに確認してください」と言う。
こうした三つ巴の状況は、実際の現場で珍しくない。結果として決定が遅れ、修正ループが発生し、発注者は「誰に連絡すればいいのか分からない」という状態に陥る。
ある受託案件では、デザインの変更承認にかかった時間が設計工程全体の40%を超えた。原因は、デザインリードがビジュアルの方向性を提案し、ディレクターが顧客ニーズとの整合性を確認し、PMがスケジュール・予算への影響を評価する——という三段階の確認フローが、どこにも明文化されていなかったことだった。各人が「他の人が決める話」と認識して判断を先送りし続けた。
役割が定義されていない状態が生む具体的損失：
- 判断遅延：誰に聞けばいいか分からないため、一つの確認に2〜3営業日を要する
- 二重指示：PMとディレクターが異なる指示を出し、制作チームが混乱する
- 責任の空白：「それは自分の担当ではない」と全員が思う領域が生まれる
- 対外的信頼失墜：発注者から見て「この会社は統率が取れていない」という印象を与える
プロジェクトマネージャー（PM）とディレクターの違い、そしてリードの役割は、「なんとなく分かる」レベルでは不十分だ。明文化されていない体制が、プロジェクトの失敗を構造的に生み出している。
PM・ディレクター・リードの定義と責任軸
三者の違いを理解するには、それぞれが「何を守るために存在するのか」という責任軸から整理するのが最も実用的だ。
プロジェクトマネージャー（PM）——予算・スケジュール・リソースの守護者
PMの責任軸は「制約条件の遵守」にある。プロジェクトが予算内・納期内・要員の範囲内で完了するよう、全体を管理する。
PMが主に扱う判断：
- タスクの優先順位と工数配分
- スコープ変更が納期・予算に与える影響の算出と承認可否
- リスクの特定と対応策の策定
- ステークホルダーへの進捗報告・エスカレーション
PM ディレクター 違いで混同されやすいのは、PMが「何を作るか」を決めるわけではない点だ。PMは「どのように、いつ、いくらで作るか」を管理する。成果物の内容・品質の責任は原則としてディレクターが持つ。
ディレクター——成果物の品質と顧客価値の責任者
ディレクターの責任軸は「顧客目標に対する成果物の整合性」にある。発注者のビジネス目標を理解し、それを達成できる成果物を定義・監修する。
ディレクター 役割の具体的内容：
- 要件定義：発注者の曖昧な要求を、制作可能な仕様に翻訳する
- 品質管理：成果物が発注者の意図・ビジネス目標に合致しているか確認する
- コミュニケーション設計：発注者と制作チームの間の情報伝達の仕組みを構築する
- 変更管理：仕様変更の影響範囲を特定し、PMへ情報を渡す
ディレクターは「制作内容の責任者」であり、技術的な実装方法には原則として踏み込まない。
リード（デザインリード・エンジニアリングリード等）——専門領域の技術的判断者
リードの責任軸は「専門領域の品質と技術的正確性」にある。デザインリードならデザインの一貫性・ビジュアル品質、エンジニアリングリードならコードの品質・アーキテクチャの健全性を担保する。
リードが主に扱う判断：
- 専門領域内の手法・ツール・技術の選定
- ジュニアメンバーの成果物に対するレビューと指導
- 技術的なリスクや制約のディレクターへの提言
- ベストプラクティスの維持と品質基準の設定
リードはプロジェクト全体の進行には責任を持たない。あくまで自分の専門領域で最良の成果を出すことが主務だ。
三者の責任軸まとめ：
| 役割 | 責任軸 | 主な判断対象 | 権限の限界 | |------|--------|------------|-----------| | PM | 予算・納期・リソース | スコープ・工数・リスク管理 | 成果物の内容・品質 | | ディレクター | 成果物の品質・顧客価値 | 要件・品質基準・変更管理 | 予算・工数の最終承認 | | リード | 専門領域の技術品質 | 手法・ツール・専門的判断 | 他領域・プロジェクト全体 |
役割混同が生む典型的トラブルパターン
プロジェクトマネージャー ディレクターの役割が曖昧なまま運用されると、現場では特定のトラブルパターンが繰り返し発生する。
パターン1：PMが品質判断をしてしまう
PMが「この成果物で問題ないか」という品質確認を行い、ディレクターを通さずに発注者に提示するケースがある。PMはスケジュールを優先するため、「今の段階で出せるもの」を承認しがちだ。ディレクターが後から確認すると品質基準を満たしていない、という状態が発覚し、差し戻しが発生する。
パターン2：ディレクターがリソース管理まで担う
成果物のクオリティに責任を持つディレクターが、スケジュール遅延に焦りを感じてメンバーの作業量を直接調整し始める。PMの知らない場所でリソース調整が走り、PM側の工数管理と齟齬が生じる。二重管理の状態でメンバーは「誰の指示に従えばいいのか」と混乱する。
パターン3：リードが顧客折衝に引き出される
デザインリードが直接発注者と打ち合わせるよう要求されるケースがある。リードは技術的に正しい提案をするが、発注者の事業背景や予算制約への配慮が薄い提案になりがちだ。発注者は「技術的な話は分かるが、自分たちのビジネスが反映されていない」と感じ、関係が悪化する。
パターン4：役割の空白地帯が生まれる
PM・ディレクター・リードそれぞれが「それは自分の管轄ではない」と感じる業務が生まれることがある。たとえば「発注者からの仕様変更依頼の受付と影響範囲の初期評価」が典型だ。PMは「品質の話はディレクターへ」、ディレクターは「スコープ変更の評価はPMへ」と回し合い、発注者は放置される。
パターン5：上流での役割混同が下流に波及する
PM ディレクター 違いが曖昧なまま進むと、制作チームも「誰の指示が優先されるのか」を迷い始める。指示の矛盾が発生したとき、判断基準がないため作業が止まる。この停止は上位の役割混同に起因しているが、見た目上は「制作チームが遅い」という評価につながりやすい。
発注者が確認すべき体制の読み方
発注者の立場では、受託先の体制が適切に設計されているかを事前に確認することが、プロジェクトリスクを下げる最も有効な手段の一つだ。
キックオフ前に確認すべき4つの質問：
-
「PMとディレクターは別の担当者ですか？同一人物ですか？」 兼任の場合、その判断がどのように分離されているかを確認する。「予算・工数に関する判断はPMとして、成果物の内容に関する判断はディレクターとして行います」という明確な説明ができる受託者は信頼性が高い。
-
「各領域のリードは誰ですか？リードとディレクターの関係は？」 リードが提案した内容をディレクターがどのようにレビューするかのフローを確認する。「リードからの提案はディレクターが発注者の視点でフィルタリングします」という体制があるかを見る。
-
「仕様変更が発生したとき、誰が窓口となり、誰が最終的に承認しますか？」 変更管理のフローが明確かどうかは、プロジェクト中盤以降のトラブル頻度に直結する。「ディレクターが影響範囲を確認し、PMが工数・費用への影響を算出して発注者へ提示する」という二段階の確認フローが標準的な受託体制だ。
-
「進捗報告はPMとディレクターどちらから行われますか？」 スケジュール的な進捗はPMから、成果物の品質・方向性はディレクターから報告される体制が分かりやすい。報告者が一人の場合、その人が両方の判断軸を持っているかを確認する。
体制図の提出を要求する：
受託先に体制図（誰が何の責任を持つかを示した図）の提出を求めることは、発注者として正当な権利だ。一般的な体制図には、PM・ディレクター・各リード・担当者の名前と役割、それぞれの報告ラインが記載される。
体制図を見るポイント：
- PM→ディレクター→リードという明確な階層か、フラットな構造か
- 発注者との窓口は誰か（複数いる場合は連絡ルールの確認）
- 体制変更（担当者変更等）の通知義務が明記されているか
受託者が明文化すべき役割定義の実務
受託者側では、役割定義を曖昧なまま着手することが、後のトラブルの最大の原因となる。提案段階・契約段階・キックオフ段階の三つのタイミングで、役割を段階的に明確化する。
提案段階——体制の概要を示す
提案書に「プロジェクト体制」のセクションを設け、PM・ディレクター・各リードの担当者名・役割の概要を明記する。発注者に「誰が何をするのか」を提案時点で伝えることで、発注者の安心感を高め、後の認識齟齬を防ぐ。
記載すべき最低限の情報：
- 担当者名と役職
- 発注者窓口となる担当者（原則1名に絞る）
- 主な責任領域（「品質管理担当」「スケジュール管理担当」など）
契約段階——役割と責任を文書化する
契約書または別紙「プロジェクト体制定義書」に以下を明記する：
- 各役割の責任範囲：何の判断について最終責任を持つか
- 意思決定フロー：変更・追加・問題発生時の判断経路
- 体制変更のルール：担当者が変わる場合の通知義務と承認プロセス
- エスカレーションパス：問題が解決しない場合に誰が最終判断するか
キックオフ段階——体制を関係者全員で共有する
キックオフミーティングの冒頭で、体制図を用いて全員の役割を共有する。受託チーム内部だけでなく、発注者側の担当者にも「どの相手に何を相談するか」を明示する。
実践的な確認項目：
- 「デザインの修正依頼はディレクターAに連絡してください」
- 「納期や予算に関する変更交渉はPMのBが窓口です」
- 「技術的な疑問はエンジニアリングリードのCに直接確認してもらえます」
この明示により、プロジェクト中に「誰に聞けばいいか分からない」という状態を防ぐ。
小規模プロジェクトでの兼任と限界ライン
小規模なプロジェクトや少人数のチームでは、PM・ディレクター・リードを一人の人間が兼任するケースが多い。フリーランスの受託案件や、2〜3人のチームでの制作では珍しくない。
兼任が機能する条件：
- 規模の条件：予算100万円以下、期間3ヶ月以内、関与人数5人以下が目安
- 案件の複雑さ：仕様変更が少なく、成果物の種類が限定的
- 発注者の体制：発注者側の窓口が1名に集約されており、意思決定が速い
- 本人の能力：PM的思考とディレクター的思考を状況に応じて切り替えられる
兼任が崩壊するサイン：
- 仕様変更の影響算出中に品質チェックを求められる——二つの判断軸が同時に走り始める
- 発注者からの直接連絡と制作チームからの相談が同時多発する——情報整理が追いつかなくなる
- 自分が「今PM的判断をしているのかディレクター的判断をしているのか」が曖昧になる——役割の分離意識が失われている
兼任から分離への移行判断：
プロジェクトが以下の状態になったときは、役割の分離または外部支援の投入を検討すべきだ：
- 週次の判断件数が20件を超え始める
- 発注者との会議と制作チームのレビューが重複するようになる
- 品質の問題とスケジュールの問題が同時に発生し、どちらを優先すべきか判断できない
一人で複数役割を担うことは可能だが、「今自分はどのモードで判断しているか」を意識的に切り替える習慣がなければ、役割混同によるトラブルを自分一人の中で再現してしまうことになる。
プロジェクトの規模や複雑さに関わらず、PM・ディレクター・リードの責任軸を理解していることが、プロジェクト品質の底支えとなる。発注者・受託者どちらの立場にいても、「誰が何を決めるのか」を問い続ける姿勢が、現場の混乱を防ぎ、信頼関係を築く基盤となる。