ベンダーとの定例会議の設計
発注者側のPMとして開発ベンダーと向き合うとき、定例会議が「報告を聞く場」になっていることがあります。ベンダーが40分かけて状況を読み上げ、こちらは聞いて終わる。
この形は、双方にとって損です。ベンダーは資料作成に時間を使い、こちらは判断の機会を逃しています。定例は、発注者側が判断を返す場だと位置づけると、性格が変わります。
■ アジェンダの型
この設計の要点は2つあります。
ひとつは、冒頭に前回のToDo確認を置くこと。会議の最後に決めたToDoは、次の週には忘れられがちです。冒頭で確認する形にすると、宿題が流れなくなります。
もうひとつは、会議時間の3分の1を「こちらが回答する時間」に充てること。ベンダー側が止まっている原因の多くは、発注者側の回答待ちです。ここを会議の中に組み込んでおくと、待ちが溜まりません。
■ 資料は前日までに受け取る
当日に初めて資料を見ると、その場で読む時間が発生します。前日までに受領し、目を通したうえで臨めば、会議は質疑から始められます。
あわせて、資料の分量に注文をつけておきます。「全項目の報告は不要です。赤と黄だけ説明してください」と伝えるだけで、ベンダー側の作成負荷も下がります。これは相手にとっても歓迎される話です。
■ 偽装請負に注意する
発注者側PMが最も気をつけるべき点です。ベンダーの要員に直接作業指示を出すことはできません。請負でも準委任でも同じです。
会議で直接会話することは問題ありませんが、作業の割り当てや優先順位の指示は、ベンダー側の責任者を通します。とくに同じ場所で働いている場合、境界が曖昧になりやすいので意識的な運用が必要です。
あわせて、勤務時間や休暇の管理に口を出さないことも重要です。「もう少し人を増やせませんか」という依頼は責任者に対して行い、個々の要員の働き方には踏み込みません。
■ その場の思いつきを要件にしない
会議中に「こうしたほうがよいのでは」と口にすると、ベンダー側は要件の追加と受け取ることがあります。善意のつもりが、後で「言われたのでやりました」という追加請求につながります。
思いついたことを言うのは構いませんが、これは要件か、検討の材料かを明示します。「これは正式な依頼ではなく、意見として聞いてください」と一言添えるだけで、行き違いが減ります。
■ 遅れの原因が自社側にあるとき
プロジェクトが遅れているとき、原因が発注者側にあることは珍しくありません。仕様の確定が遅れた、回答を返していない、レビューが滞っている。
このとき、自社側の責任を認めておくことが、その後の協力関係を左右します。「こちらの回答が3日遅れました。その分の影響を見積もってください」と先に言えるかどうかです。
逆に、原因を曖昧にしたまま納期だけを求めると、ベンダー側は防御的になります。記録を残すことに注力し、率直な情報が上がってこなくなります。
■ 良い関係を作るための3つ
回答を待たせない：判断に時間がかかる場合も、「いつまでに返す」だけは即答する
悪い情報を歓迎する：遅れの報告に対して詰めると、次から出てこなくなる。これは社内メンバーと同じ
先の予定を共有する：2〜3週先の予定を伝えておくと、ベンダー側も準備できる
■ チェックリスト
資料を前日までに受領しているか
冒頭に前回ToDoの確認を置いているか
こちらが回答する時間を確保しているか
指示をベンダーの責任者経由にしているか
思いつきと正式な依頼を区別して伝えているか
自社側に原因がある遅れを認めているか
ベンダーは、発注者にとって最も重要な戦力です。契約上は外部でも、プロジェクトの成否は同じ船に乗っています。定例会議をどう設計するかは、その関係をどう扱うかの表明になります。