みなさま、こんにちは。おくむら(@nori_broccoli)です。
あるプロジェクトを始めたとき、まずは簡単なプロトタイプのようなものを作成してモニターに利用していただき、足りない機能、改善して欲しいところなどを洗い出しながらシステムを作り込んでいくという流れで進めることになっていました。ところが、プロジェクトが始まってみるといきなり製品版を作って導入していくという話にすり替わり、そもそも研究活動的に作っていくものと思っていたプロジェクトメンバーは、何の土台もないところからいきなり製品版を作らされることになりあたふたしたことがあります。
そもそも私は大学の教員であってソフトウェアエンジニアでも何でもないですから、売れるようなシステムを作るスキルはありません。そのことはプロジェクト立ち上げ当初から伝えていたもののリーダーは聞く耳を持たず、売れるシステムにするにはソフトウェアエンジニアを入れないとダメだと何度も言ってきたのに対応せず、こちらに製品版を作らせようとして大失敗しています。こちらの認識は、こちらが実証実験で得た知見に基づいて、スキルのあるエンジニアがシステムを組んでいくものと思っていましたから、そりゃ売れないですよね・・・という話になってご破算です。
そんな状況もプロジェクト立ち上げ当初から分かっていましたので再三リーダーにはきちんと舵取りしろと伝えてきましたが全くダメでした。営業先？にいい顔をするためだけに動いており、こちらの事情は全く汲むことがなく、作業が進まなければ怒鳴り散らすという困った人でした。そんな認識のズレを指摘しても動かないリーダーをうまく動かすにはどうすればいいか、Geminiに聞いてみました。
ご経験された状況は、プロジェクト管理における最も危険な落とし穴の一つです。初期合意からの逸脱は、最終的にプロジェクトの頓挫やスコープクリープ（スコープの肥大化）を引き起こします。あなたがそのズレを察知したことは非常に正しかったものの、リーダーが推進を止めなかった点に、コミュニケーション戦略と文書化の課題があったと考えられます。
プロジェクトの認識ズレを察知した時に即座に取るべき初期行動
プロジェクトの認識ズレを察知した際にリーダーに再考を促すには、「事実と初期合意」に基づいた客観的な対話を記録に残すことが不可欠です。感情的な訴えではなく、初期スコープ文書、議事録、リスク評価という客観的な証拠を用いて、現状の進捗が「プロジェクトの成功定義」から逸脱していることを論理的に示し、早期にエスカレーションの準備をすることが重要です。
認識のズレを察知した場合、まず感情的に「違う」と訴えるのではなく、次の具体的な手順を踏み、状況を公式化することが極めて重要です。
- 初期合意事項の「再確認」と「比較」: プロジェクト憲章、SOW（作業範囲記述書）、または最初のキックオフ会議の議事録など、初期に合意した「最終目標」や「成果物の定義」を即座に引き出します。
- 乖離点の客観的な記録: 「聞いていた話」と「現在推進されている内容」の具体的な相違点をリストアップします。この際、「私は不満だ」という主観ではなく、「初期合意では機能Aだったが、現在は機能Bが実装されている」という事実のみを記述します。
- 懸念事項を公式な場で提起（非難ではなくリスク報告として）: 1対1ではなく、チームミーティングや公式なチャネル（メール、チャットではなくプロジェクト管理ツール）で、初期合意とのズレがプロジェクトにもたらす「リスク」（納期遅延、コスト超過、目標未達）として提起します。
リーダーに「再考」を促すための効果的なコミュニケーション戦略
リーダーが自分の判断を固執している場合、感情や個人的な意見で説得することは困難です。彼らに再考を促すには、論理的かつ客観的なデータに基づいたコミュニケーションが必要です。
感情論を避け、論理的にリスクを提示する
リーダーはプロジェクトの「成功」に対して責任を負っています。彼らに訴えかけるべきは「このままではプロジェクトは失敗する」という論理的な危機感です。以下の3つの視点から、現在の進め方がいかに危険かを伝えます。
- コスト視点: 「この変更により、当初予算からX万円の追加コストが発生する見込みです。」
- 納期視点: 「初期スコープからの逸脱により、合意された納期までに完成させる可能性はY%に低下します。」
- 成功定義視点: 「この機能は初期のKFS（重要成功要因）を満たしません。ステークホルダーが求める成果とは異なります。」
意思決定の歴史（監査証跡）を文書化する重要性
口頭での「そう言う話ではなかった」という訴えは、後で水掛け論になりがちです。プロジェクトにおいては、全ての重要なコミュニケーションを文書として残し、誰が、いつ、何を決定したかを明確にしておく必要があります。
リーダーとの対話や、方向性の変更に関する議論は、必ず議事録として作成し、参加者全員に共有し、承認を得てください。これにより、リーダーの判断が「個人の思い込み」ではなく「公式の決定」として記録され、リスクが顕在化した際に誰が責任を持つべきか（または再考すべきか）が明確になります。
第三者を巻き込むエスカレーションパスの設定
リーダーが認識ズレの指摘を無視し、プロジェクトを危険な方向に進め続けている場合、次のステップとしてエスカレーションが必要です。これはリーダーへの不満をぶつけることではなく、プロジェクトを救うための行動です。
正式なリスク報告書を作成し、プロジェクトスポンサーやPMO（プロジェクトマネジメントオフィス）など、リーダーの上位にいる意思決定者に状況を報告します。この報告には、初期合意文書と現在の進捗状況の乖離を示す客観的な証拠を添付し、「このままでは当初目標が達成できないリスクが非常に高い」と伝えます。
再発防止のための「認識合わせ」の徹底チェックリスト
今後のプロジェクトで同様の失敗を避けるためには、開始時に「曖昧さ」を徹底的になくす仕組みが必要です。
- KFS（重要成功要因）の明確化: プロジェクトの「成功」を具体的に数値化し、関係者全員がこれにサインオフする。
- 議事録の承認プロセス: 全ての会議で議事録を作成し、決定事項については参加者全員（特にリーダー）の「承認」を得て、文書として保管する。
- スコープ固定と変更管理プロセスの確立: スコープを変更する際は、必ず「変更要求書（Change Request）」を作成し、コスト、納期への影響を分析し、スポンサーの承認を経るルールを徹底する。
- 定期的なヘルスチェック（現状確認）: 定期的に初期スコープと現状の進捗を比較するミーティングを設け、乖離がないか客観的に評価する時間を設ける。
FAQ（よくある質問）
Q1: 認識ズレを伝える際に避けるべき表現は？
「あなたの判断は間違っている」「前と言っていることが違う」といった感情的、または非難的な表現は避けてください。代わりに、「初期の合意に基づくと、この方向性は目標達成のリスクを高めます。データを見ると…」のように、常に客観的な事実とプロジェクトの目標達成を主軸に置いた表現を使いましょう。
Q2: リーダーが頑なな場合、いつエスカレーションすべきですか？
公式な場で懸念を2〜3度提起し、文書化したにもかかわらず、リーダーがリスクを無視して進捗を変えようとしない場合、速やかにエスカレーションすべきです。エスカレーションは「プロジェクトが取り返しのつかない状況になる前」に行うことが、プロジェクトを救う最後の手段となります。
Q3: プロジェクトが破綻する前に、メンバーとして他にできることはありますか？
リーダーを再考させることが難しい場合でも、あなたはプロジェクトの健全性維持に努めることができます。具体的な行動として、変更された内容を文書化し続け、自身のタスク範囲がどこまでか明確に線を引き、初期合意に基づいた成果物と、現在の逸脱した成果物の両方を記録し続けることが、後に発生する責任問題や教訓の抽出に役立ちます。