関係者が多い案件で、全部の調整役にならないために
木曜16時20分、三つの指示が同時に届いた
木曜16時20分。翌朝のデモに向けて、申込管理画面の最終確認をしていた。
この案件には、発注会社の事業責任者、実際に画面を使う利用部門、契約の窓口である元請会社がいる。実装を担当する外部エンジニアは、三者が参加するチャットで連絡を受けていた。
最初に、利用部門からメッセージが来た。
申込の確定ボタンは、誤操作が怖いので今の位置から動かさないでください。
数分後、発注会社の事業責任者から別の指示が届いた。
デモでは導線の改善を見せたいので、ボタンを画面上部へ移してください。
元請の担当者へ確認すると、「両方の意見をうまくまとめて、明日までに調整できますか」と返ってきた。
指示を断れば、融通が利かないと思われそうだった。ここで「最終判断は誰ですか」と聞けば、話を止める人に見える気もした。頭の中では警報が鳴っているのに、指は先に動き、「こちらで整理します」と返信した。
その一文で、実装だけでなく、意見の取りまとめと最終判断まで自分の仕事になったように感じた。どちらを選んでも、誰かの希望を無視する。返事を考えるほど手が止まり、デモに必要な別の修正も進まない。自分が決められないのではなく、決める権限がないことまで、自分の能力不足のように抱え始めていた。😓
関係者が多い案件で苦しくなるのは、人数そのものが原因とは限らない。情報を出す人、選択肢を整理する人、最終的に決める人の境目がなくなり、善意で動く人へ判断が集まる時に苦しくなる。
まず契約と連絡の約束へ戻る
役割表を新しく作る前に、手元の事実を確認した。
- 契約上の作業範囲は、合意済みの仕様に基づく画面実装とテスト
- 仕様変更の窓口は元請の担当者
- 発注側で最終承認する人の名前は、契約書にも連絡資料にも書かれていない
- 翌朝のデモで、どの案を採用するかも決まっていない
ここから分かるのは、「外部エンジニアが判断すべき」ということではない。最終判断者が未確認のまま、実装だけが求められているということだ。
IPAの「情報システム・モデル取引・契約書（第二版）」は、ユーザ企業とベンダの役割分担、プロジェクト管理、複数のベンダが関わる場合の整理を見直しの論点にしている。アジャイル開発版でも、プロダクトの方向性を決める人が、開発チームへ必要な情報と意思決定を適時に渡し、関係者を調整する役割を持つとしている。
これは、現場の実装者が何も考えなくてよいという意味ではない。技術上の制約、必要な作業、各案の影響は実装者が説明できる。一方、利用部門と事業責任者のどちらの希望を優先するかは、事業側の判断だ。材料を出す責任と、選ぶ責任は分けられる。
判断を実装者から本来の場所へ戻す
「誰の仕事ですか」ではなく、決める依頼に変える
「これは私の仕事ではありません」とだけ返すと、相手には突き返されたように見える。そこで、止まっている判断を5行にした。
- 決めたいこと: 確定ボタンを現状の位置に残すか、画面上部へ移すか
- 最終判断をお願いしたい人: 発注会社の事業責任者
- 判断期限: 本日17時。以降は現状の位置でデモ版を確定
- 選択肢と影響: 現状維持なら誤操作対策を優先。上部へ移動なら導線改善を見せられるが、利用部門の再確認が必要
- 決定後に動く人: 実装とテストは私、利用部門への共有は元請担当者
この形なら、仕事を放り出していない。自分が確認できる技術上の影響を示し、判断が戻ればすぐ動ける状態にしている。📝
送信する直前は、まだ迷った。「そこまで書かなくても、空気を読んで進めてほしいと思われるかもしれない」。けれど、曖昧なまま片方を選ぶ方が、翌朝に説明できない変更を残す。5行をチャットへ貼り、元請担当者へ「最終判断者の確認と、利用部門への共有をお願いします」と添えた。
10分後、事業責任者から「今回は現状維持。導線改善は次回の検討項目にする」と返事が来た。利用部門もその結論を確認し、元請担当者が議事メモへ残した。
大きな会議は要らなかった。必要だったのは、三つの意見を自分の中で丸めることではなく、一つの判断依頼にして、選べる人へ戻すことだった。
最終判断者が分からない時は、名前を推測しない。まず契約窓口へ、「この変更を承認できる方はどなたですか」と確認する。窓口自身が決められない場合でも、その人から社内の責任者へつないでもらえる。外部エンジニアが発注会社の組織図を調べ、肩書だけで判断者を決めるより、連絡経路を一つ戻る方が早い。
期限までに返事が来ない場合の扱いも、判断依頼に入れておく。「返事がなければ現状の仕様で確定する」「デモを延期する」「影響しない部分だけ進める」など、勝手に決めるのではなく、未回答時に採る進め方を先に承認してもらう。返事を待つ間ずっと画面を見続ける必要がなくなり、別の作業へ戻りやすくなる。
役割は、肩書ではなく一つの判断ごとに置く
「プロジェクト責任者」という肩書だけでは、日々の細かな判断までは決まらない。案件全体の責任者がいても、画面仕様は利用部門、予算変更は事業責任者、技術方式は開発責任者が決めることがある。
そのため、最初から大きな組織図を完成させようとせず、迷った判断ごとに次の四つを置く。
- 決める人: 複数案から一つを選び、結果を引き受ける
- 材料を集める人: 意見、期限、費用、技術上の影響を並べる
- 決定後に動く人: 実装、確認、連絡などを実行する
- 確認または共有を受ける人: 決定前に意見を求める人と、決定後に知らせる人
一人が複数の役割を持ってもよい。ただし、決める人が二人いる状態は避ける。意見が割れた時に、また実装者のところへ戻ってくるからだ。
作業中に判断待ちが増えたら、一覧へ「誰の返事を待っているか」と「返事がない場合の進め方」も足す。止まっている理由が見えれば、実装者だけが遅れているように感じて焦る必要がなくなる。周囲も、どの判断を先に返せば作業が動くか分かる。
デジタル庁のデジタル・ガバメント推進標準ガイドラインも、情報システムの整備や管理について、組織ごとの役割を共通ルールとして定めている。政府向けの文書をそのまま民間案件へ当てはめる必要はないが、関係者の協力だけに期待せず、役割と手順を先に置く考え方は、小さな案件でも使える。
契約書だけで足りない時は、判断の経路を残す
契約書にすべての判断を書き切るのは難しい。実務では、契約書、発注書、体制図、定例会の約束、チャットの決定メモを組み合わせる。
最低限、次の三つがたどれればよい。
- 変更を誰へ相談するか
- 誰が最終判断するか
- 決まらない時、いつ、どこへ上げるか
「どこへ上げるか」は、問題を大きくするための手続ではない。権限のある人に判断を戻す経路だ。IPAのアジャイル開発版も、役割が果たされず開発が止まる場合に、権限のある責任者を交えた協議を開ける形を示している。
判断が口頭で出た時は、長い議事録を作らなくてもよい。
- 本日の決定: 確定ボタンは現状維持
- 決定者: 事業責任者
- 理由: デモ前は誤操作対策を優先
- 次の対応: 導線改善は次回の要件検討へ移す
これだけでも、翌日に別の人から違う指示が来た時、感情で押し返さず、決定した場所へ戻れる。チャットの投稿先が複数あるなら、決定を残す場所も一つに決める。個別メッセージで決まったことは、関係者が見られる議事メモへ移す。「誰かが知っている」状態から「後で全員が確かめられる」状態へ変えるためだ。
抱え込みそうな時は、気持ちから一段離れる
全部を調整しようとする時、背景には「役に立ちたい」だけでなく、「止めたと思われたくない」「分からないと言うのが怖い」という気持ちがある。だから、役割表の知識があっても、その場では即答してしまう。
そんな時は、返事の前に次の二つを分ける。
- 今、自分が説明できる事実は何か
- 自分には選べないことは何か
木曜の場面なら、実装時間と各案の影響は説明できた。しかし、どちらの部門を優先するかは選べなかった。選べないことを認めるのは、力不足の告白ではない。権限のない判断を、権限のある人へ返すための確認だ。
返事を急かされたら、まずこう言える。
影響を整理して17時までにお送りします。最終判断をお願いする方も、その時点で確認させてください。
すぐ結論を出さなくても、次に何を返すかと時刻を示せば、沈黙にはならない。気持ちを落ち着ける時間を作りながら、案件も止めずに済む。
送信後に「余計なことを書いたかもしれない」と不安になることもある。そんな時は、相手の反応を何度も読み返す前に、実装のために必要だった情報がそろったかを見る。決定者、期限、採る案がそろえば、確認は役目を果たしている。相手を説得し切れたかではなく、次の作業を説明できる状態になったかで区切ると、調整の気疲れを少し減らせる。
翌朝9時、説明できる状態でデモに入れた
翌朝、画面は現状のボタン位置でデモに出た。事業責任者は冒頭で「今回は安全な操作を優先し、導線改善は次の検討に回した」と説明した。外部エンジニアが、利用部門の反対を押し切ったように見えることはなかった。
デモ後、元請担当者と判断の経路を整えた。画面仕様は利用部門の意見を聞いたうえで事業責任者が決める。技術上の影響は外部エンジニアが整理する。費用や納期が変わる場合は元請担当者が契約変更を確認する。決定は同じ議事メモへ残す。
次に指示が割れた時も、胸がざわつかなくなったわけではない。それでも「こちらで何とかします」と反射的に返す前に、決める人と期限を確認できた。抱えていた仕事を誰かへ押しつけたのではない。自分が持つ仕事を実装へ戻し、事業の判断を本来の場所へ戻したのだ。🌱
着手前の質問で手戻りを減らす方法では、案件の最初に決定者や確認期限を聞く流れを整理している。すでに問題が起きて誰へ上げるか迷っている場合は、エスカレーションの条件を契約と運用へ置く方法も使える。
まず、今止まっている判断を一つ選ぶ。「決めたいこと」「最終判断をお願いしたい人」「期限」「選択肢と影響」「決定後に動く人」を5行で書く。空欄があれば、その空欄こそ次に確認することだ。
関係者が多い案件で必要なのは、全員の意見を一人で丸く収める力ではない。違う意見が出ても、判断が迷子にならず、決めた後にそれぞれが動ける経路である。
ValueGateでは、契約書だけでなく、日々の判断依頼、決定メモ、変更時の連絡経路まで、実際の案件に合わせて一緒に整えている。調整を抱え込まず、実装へ戻れる進め方を作ろう。
