「気づいていたなら、なぜ言わなかった？」あの会議で黙った自分がつらかった

木曜16時10分、翌週のリリースに向けた会議が終わろうとしていた。業務委託で参加するエンジニアの紗季は、通知機能の仕様書を開いたまま、手を上げるか迷っていた。

仕様書には「対応していない人へリマインドを送る」とある。しかし、対応済みかどうかを判定する条件が書かれていない。今の実装案では、社内のテストアカウントを含む全員へ送る可能性があった。

「ほかに確認はありますか」とプロジェクトマネージャーが聞いた。紗季は一度息を吸ったが、別のメンバーが「大丈夫です」と答え、会議を閉じる空気になった。

ここで止めたら、いつも細かいところを気にする人だと思われるかもしれない。外から参加している自分が、決まりかけた話を戻してよいのかも分からない。紗季はマイクを入れず、「私も大丈夫です」とチャットへ打った。

翌週の検証で、リマインドが対象外のテストアカウントにも届いた。公開前に止められたものの、条件の確認と修正でリリースは一日延びた。その場で言われたのが、この一言だった。

「そこに気づいていたなら、なぜ会議で言わなかったんですか」

帰宅してからも、その言葉が残った。言えば空気を悪くすると思った。黙った結果、もっと迷惑をかけた。次の会議では、確信があっても「また止めたら嫌がられる」と考え、前より声を出しにくくなった。

黙ったのは、仕事を軽く見ていたからではない。関係を壊したくない気持ちが、確認を先延ばしにする行動へ変わったからだ。 必要なのは、強く言える性格になることではない。気まずさを抱えたままでも、見えた危なさを小さく渡せる形を持つことだ🗣️

会議では黙れたのに、その一言があとから残った

「いつも止める人」と思われるのが怖かった

仕様の曖昧さに気づいたとき、紗季が心配したのは通知の誤送信だけではなかった。指摘したあとの相手の表情、自分の契約更新、会議が長引いたときの空気まで、一度に想像した。

業務委託で参加していると、正しさだけでは動きにくい。「協力的な人でいたい」「任せやすいと思われたい」という気持ちは、次の仕事にも関わる現実的な心配だ。だから、懸念が小さいうちは、自分の中で処理したほうが穏やかに終わるように見える。

しかし、その場の空気を守るために確認を飲み込むと、チームには「懸念がなかった」という情報が残る。紗季の「大丈夫です」は、迷いを隠すための返事だったが、ほかの人には合意として届いた。

関係を守ろうとする気持ちと、見えた問題を共有する責任は、どちらか一方を捨てる話ではない。まず一行だけ伝えれば、会議を大きく止めずに確認を始められる。

問題が起きると、沈黙まで自分の能力に見えてしまう

検証で問題が見つかったあと、紗季は仕様より自分の性格を責めた。「私は肝心なところで言えない」「エンジニアとして信頼されなくて当然だ」と考えた。すると、次に必要な確認より、過去の会議を頭の中でやり直す時間が増えた。

ここで、心理状態を病名や性格の欠点として決めつける必要はない。Amy Edmondsonの1999年の論文では、質問や失敗の共有で気まずくなっても、このチームでは不利益を受けないという共通認識を「心理的安全性」とし、51の製造チームで学習行動との関係を調べた。これは「言えない本人が弱い」と評価するための研究ではない。

Harvard Business Schoolの2023年の記事も、助けを求めたり悪い知らせを伝えたりする行動には、恥ずかしさや不利益への心配が伴うと説明している。だから、声を出す人だけに勇気を求めるのではなく、リーダーが質問を招き、悪い知らせを罰しないことも必要になる。

紗季が一人でチームの空気を変えることはできない。それでも、自分の沈黙を責め続ける代わりに、「何が分からず、何を一つ決めてほしかったか」へ戻ることはできる。

指摘する前に、まだ分からないことを一行にする

見えた事実と、起きるかもしれないことを分ける

紗季は次の会議の前に、前回の懸念をノートへ書き直した📝

• 仕様書には「未対応者へ送る」と書かれていた
• 対応済みを判定するデータと条件が書かれていなかった
• 今の実装では全員を対象にする可能性があった

一つ目と二つ目は、資料から確認できる事実だ。三つ目は、起きるかもしれない影響である。「誤送信が起きる」「担当者が何も考えていない」と結論づける前に分けると、相手を責めずに話せる。

「この仕様は危険です」では、どこを見て何を心配しているのかが伝わらない。「未対応者を判定する条件が、仕様書では読み切れません」なら、相手も同じ箇所を確認できる。

指摘の強さを下げるのではなく、曖昧な「危ない」を、資料で確認できる一文まで具体的にする。そうすれば、強い口調に頼らなくても懸念を伝えられる。

仕様の曖昧さを先に切り分けたいときは、AIの実装前に「決めること」と「確認すること」を分ける方法も使える。AIが書いた実装でなくても、事実、仮説、判断待ちを分ける考え方は同じだ。

その場で決めたいことを、一つだけ選ぶ

懸念を伝えようとすると、関連する問題を全部説明したくなる。通知条件、テストデータ、個人情報、リリース日まで並べれば、話は正しくても重くなる。会議を止める怖さも増える。

紗季が前回ほしかったのは、完全な仕様ではなかった。「未対応者を誰が、いつまでに、どのデータで判定するか」の確認先だけ決まれば、実装を仮置きにできた。

そこで、次の一歩を一つに絞る。

• 条件を今日決める
• 決める人と期限だけ決める
• 決まるまで通知処理を無効にする

この中から、会議で最低限ほしい判断を選ぶ。答えがその場で出なくても、担当者と期限が記録に残れば、懸念は紗季一人の頭からチームの課題へ移る。

質問を出すタイミングで迷ったときは、質問が遅れて手戻りになる前に、確認を小さく出す方法も参考になる。完璧な質問を作るより、判断が必要な部分だけ先に見せるほうがよい。

強く言えなくても、三文なら会議に戻せる

事実、影響、お願いの順で伝える

次の打ち合わせで、紗季は同じように曖昧な条件を見つけた。胸の奥はまだ重く、相手の返事を想像すると手が止まった。それでも、次の三文だけを会議のチャットへ送った。

通知対象の条件が、仕様書ではまだ読み切れません。

このままだと、未対応者だけでなく全員へ送る実装になる可能性があります。

今日決め切れなければ、確認する人と期限だけ議事録に残せますか。

一文目は事実、二文目は起こりうる影響、三文目はお願いだ。相手の判断を否定せず、何を見ればよいかを示している。選択肢をたくさん並べず、まず記録に残すところまで求めている。

プロジェクトマネージャーは「今は決められないので、担当者を確認します」と返し、議事録に担当者と翌日の期限を加えた。紗季の緊張がすぐ消えたわけではない。ただ、「言ったら関係が悪くなる」という想像とは違う終わり方を一度経験できた。

伝える目的は、自分の正しさを証明することではない。見えた事実を、チームが次の判断に使える形で伝えることだ。

流されたら、決定、担当者、期限を記録する

三文を出しても、「いったん今のままで」「あとで見ます」と流されることはある。その場で何度も押し返すと、議論の勝ち負けになりやすい。まずは、決まったことを短く確認する。

本日は現行案で進め、通知条件は田中さんが明日17時までに確認する、という理解です。条件が変わる場合はテスト項目も見直します。

議事録、Issue、Pull Requestなど、後からチームが見られる場所へ残す。これは「私は言いました」と自分を守るためだけの証拠ではない。判断が変わったとき、どこから見直すかを共有するための記録だ。

IPAの「情報システム・モデル取引・契約書」第二版は、仕様、プロジェクト管理、検収などについて、ユーザーとベンダーが対話を通じて共通理解を作ることを想定している。契約書だけで日々の会話が整うわけではないが、曖昧な点を片方だけで抱えず、協力して確かめる考え方は実務にも使える。

誰へ渡すかが分からない場合は、エスカレーションの連絡先と判断条件を契約前に決める方法まで戻る。懸念を見つけた人が、最後の判断まで背負う必要はない。

全部を丸く収めなくても、見えた危なさは渡せる

通常の迷いと、すぐ止めるべき問題を分ける

すべての懸念を同じ温度で伝える必要はない。画面の文言や軽微な挙動で、あとから戻せるものなら、事実と確認期限を置いて進める選択もある。

一方、個人情報の外部送信、認証・権限の抜け、秘密情報の公開、法令や契約に反する可能性、安全へ関わる問題は、関係を悪くしない言い方を考え続けるより先に止める。担当者だけでなく、責任者や定められた窓口へ上げる🚨

この違いを、話し手の不安の強さだけで決めない。影響を受ける人、元に戻せるか、外部へ出るか、契約や法律に関わるかを見る。通常の不確実性は小さく共有し、重大な問題は明確に止める。

関係を守ることは、重大な懸念を丸く言い換えて弱めることではない。影響に合った相手と速さで、事実を渡すことでもある。

勇気が出る日を待たず、一行だけ先に置く

紗季は、前の会議で黙った自分を完全には許せていなかった。それでも、次の会議で三文を出せたことで、「言える人か、言えない人か」という二択から少し離れられた。

気まずさは、正しい言い方を覚えた瞬間になくなるものではない。相手の反応が怖い日も、契約更新が気になる日もある。だから、気持ちが整ってから話そうとすると、確認はまた後ろへ延びる。

まず、「仕様書では読み切れません」と一行だけ置く。それで会話が始まれば、影響とお願いを足す。声に出せなければ、会議のチャットやIssueに残す。自分の中に抱えた懸念を、チームが扱える大きさへ変える。

あのとき黙った自分を責め続けるより、次に見えた違和感を一行だけチームに伝える。その小さな行動が、仕事と関係の両方を守る次の一歩になる。

参考にした情報

• IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開、2025年6月17日更新）
• Amy C. Edmondson「Psychological Safety and Learning Behavior in Work Teams」（Administrative Science Quarterly、1999年6月）
• Harvard Business School Working Knowledge「Four Steps to Build the Psychological Safety That High-Performing Teams Need Today」（2023年6月14日）

※本文の人物と出来事は、現場で起こりうる状況をもとに構成した例です。