「謝罪」しすぎない技術

1. はじめに： なぜエンジニアは「すみません」を言いすぎてしまうのか

開発現場で、無意識に口癖のように出てしまう「すみません」。
心当たりはないでしょうか、私はあります....笑

資料の提出が少し遅れたとき、MTGの冒頭、あるいは相手からの指摘を受けたとき、他チームにお願い事をする時。
この 「反射的な謝罪」 は、果たして謙虚さからくるものでしょうか？
それとも、自身を守る為の便利なツールと化していないでしょうか？

真面目で責任感が強いエンジニアほど陥りやすいこの「ツールとしての謝罪」は、単なるコミュニケーションの問題に留まりません。

過度に謝罪することで、

• 過剰な要求も拒否できない、要求を飲み込みすぎる体質になる。
• 「謝る人」として見られ、エンジニアという専門職からの意見が軽視される
  （プロとしての発言力が低下し、流されてしまう）。

結果、自身の信頼感を損なうだけではなく、チーム(自社)の信頼感の低下、無理なタスク量を抱える事に繋がり、不健全なプロジェクト運営を招く要因の一端となってしまいます。

本記事では、過度な謝罪がもたらす悪影響と現場での具体的な課題について掘り下げます。
そして、技術者(担当領域に関わらず)として信頼を勝ち取るための、「謝りすぎない技術」が示す価値について執筆しております。

※あくまで『過剰な謝罪』について言及しています、適切な場面での誠意を持った謝罪もそれは責任だと思いますし、必要な事は承知しております、その上で本記事をご覧いただけると幸いです。

2. 「謝罪のコスト」：自己評価と信頼の低下

安易な謝罪は、無意識のうちに自身が行う自分自身への評価と、他者からの評価を低下させます。

2-1. 内部的問題：自身のエンジニアとしての「自己効力感」の低下

自己効力感は、「自分は目標を達成できる能力がある」という自信であり、課題に直面した時の解決能力につながります

しかし、自分の技術力や判断とは無関係な出来事(言い換えると自身が問題の原因ではない時に)、例えば「急な要求の変更」や「仕様の変更」が原因である事象に対し、「謝罪」を繰り返すと、次第に脳は「問題の原因＝自分」という誤った学習を繰り返します。

この学習は、自己評価の慢性的な低下を招き、自身の挑戦の意欲を低下させます。
慢性的な燃え尽き症候群を引き起こす心理的な土壌が完成していまい自身でキャリアの幅を狭めていく事になります。

ref: https://studyhacker.net/albert-bandura

2-2. 外部的問題：他者の「根本原因帰属」と影響力の喪失

コミュニケーションにおける帰属理論によると、他者は出来事の原因を「内因（個人の能力や努力）」か「外因（環境、運、難易度）」に求めるそうです。

安易に謝罪するという行為は、相手に問題の原因を 「内因（相手視点で自身に対する能力不足）」 とさせてしまうリスクになります。

問題が技術的な制約や仕様の曖昧さによるものであっても、自身の意見は「能力の低い人からの釈明」として片付けられてしまいます。
結果、プロのエンジニアとしての意見が軽視され、「これは技術的に難しいから次の提案を」「この制約は受け入れるべきだ」といった 「こちらの伝えたい事」が呑んでもらえなくなる可能性があります 。
そして、本来解決したかった課題に対するアプローチが出来ないまま、「この人では埒が明かない」と本当は正しい事を言っていたとしてもPJの進行を妨げる要因になってしまいます。

ref: https://daredemotukaeru.web.2nt.com/51.html

3. 過度な謝罪が引き起こす具体的なチーム課題

心理的なコストは、開発現場において具体的な負債として現れます。
これは、プレイヤーとしての自身の疲弊と、プロジェクトマネジメントの不全を招きます。

3-1. 要求を聞き入れすぎてしまう：スコープクリープの発生

謝罪は、無意識のうちに相手に対し「私は弱い立場です」「あなたの要求はすべて受け入れます」というメッセージを送ってしまいます。
この姿勢は、クライアントが持つ「この人は断らないだろう」という期待と認知バイアスをかけます。
また、自身に自信が持てない為、「相手の言っている事の方が正しいだろう」という自身へのバイアスもかけてしまいます。

現場で、締め切り直前に「この機能を追加できないか？」と問われた際、「すみません、厳しいです」と言うと、相手は「厳しいと言いながらも、謝っているから受け入れるだろう、非は向こうにあるのだから受け入れるしかないだろう」と解釈します。

これがスコープ拡大を招き、最終的にチームメンバーの疲弊とPJの失敗へとつながります。
健全なPJ・チーム運営には、プロとして「No」と言いきる必要があり、その責任があります。

無理に「YES」と答えてしまって結果、形にできない場合、本来価値を届けたいクライアントに何も還元できず
更にはチームメンバーを疲弊させるだけで誰も幸せにならない状況を生んでしまう可能性があります。

3-2. 謝罪による「自己保身」がNAを遅らせる

MTGで問題が露呈したとき、謝罪は「その場の緊張を緩和し、追及を避けるための自己防衛・保身の手段」として行なってしまう事もあると思います。
謝罪によって自身の感情を落ち着かせる事によって、本質的な議論を放棄してしまう状況が生まれます。

例えば、担当タスクが遅延しているとします。
そして遅延の理由は急な要求の変化であったり、ステークホルダーの意思決定のスピードの遅さであるとします。
で、あるにも関わらず「すみません、遅延しています、本当に申し訳ございません。。。。」で会話を終えてしまうと、
遅延の根本原因は別であるにも関わらず、本来の課題(急な要求の変化であったり、ステークホルダーの意思決定のスピードの遅さ)に関する 「Why（なぜ？）」 の議論に触れられないままになってしまいます。

結果、MTGの結論として残るのは「追って確認します」「再検討します」といった結論の出ないNAばかり。
問題の根本解決が遠のき、結局何も進まないという事態に陥ります。

自己保身の為の謝罪は問題を先送りにするだけではなく、本来自身が問題の原因ではなかったとしても結果として遅延の原因の一端に自身が介入してしまう事になります。

3-3. 本質的な議論ができない：リスクと制約の隠蔽

プロの責任は、技術的な制約やリスクを明確に開示し、解決策を提示することです。
しかし、謝罪癖がある人は、ネガティブな情報を伝える際、まず謝罪から入ります。

謝罪が先行することで、伝えたい重要な制約やリスクの情報が、単なる 「できない言い訳」 として受け取られ、真剣に検討されなくなります。

「すみません、この設計だとセキュリティリスクが高いです」と言うより、「この設計を採用した場合、セキュリティリスクが高まります。代替案Aを推奨します」と伝える方が、情報の重みが増します。
謝罪は、技術的な主張の重みを消してしまう要因の一つになりえてしまいます。

3-4. 報告ではなく「懺悔」になる：情報の歪曲と遅延

謝罪を繰り返すことで、問題報告の心理的ハードルが上がり、報告自体が「叱責を受けるためのイベント（懺悔）」というネガティブな行為にすり替わります。

「怒られたくない」という動機から、エンジニアは状況が深刻化するまで報告を遅延させたり、報告内容を自分に都合よく歪曲させたりするようになります。
これでは、ステークホルダーは正確な状況把握ができず、適切な意思決定のタイミングを失い、問題が致命傷へと発展します。

4. 今日から変わる！：「謝罪」を「共感・事実・提案」に置き換える技術

プロフェッショナルな対話は、感情的な謝罪ではなく、 共感と事実（エビデンス）と行動（提案） で構成されるべきだと私は考えます。
この三位一体のフレームワークで、対等な関係を築きましょう。

謝罪を避けたい場面	悪い例（感情的謝罪）	良い例（共感・事実・提案）	狙いと目的
納期遅延のリスク	「大変申し訳ございません、予定より遅れています」	共感： 「ご期待に沿えず心苦しいですが、」 事実： 「現在、〇〇機能の実装に設計上の想定外の複雑さが見つかりました。」 提案： 「B案（機能削減）で期日厳守か、A案（品質維持）で納期をX日延長か、ご判断をお願いします。」	プロとしての主導権を握る：感情ではなく、現在起きている事実と提案(選択肢)に基づいた議論を促す。 ただ自身(チーム)が悪いと話して終わるのではなく、客観的な事実を示す事。
困難な要求への拒否	「すみません、それは難しくて...」	共感： 「ご要望の背景は理解いたしました。」 事実： 「既存機能と連携する時、この機能を実装するには根本の要求から変わってしまいます。」 提案： 「当初のご要望から要件が変わってきてる為、改めて要求を整理させていただいてから実現可能かをお話しさせていただきたいです。」	専門性の主張：単なる拒否ではなく、代替案を示す(もしくは示すためのアプローチを行う)ことで課題解決に向けて発言しプロとしての地位を確立する。
他者のミスが原因の遅延	「すみません、連携が遅れました」	事実： 「XX部署からの連携が遅延しました。」 提案： 「今後の再発防止のため、連携期限を〇日に設定することを提案させてください。」	対等な関係と再発防止：責任を過剰に負わず、建設的な改善策に焦点を絞る。 ※ただし、相手がクライアントの場合等であれば内部的な事情は関係ないため、素直に謝罪する必要はある。 謝罪自体が悪いという話ではなくて、謝罪して終わってしまうと何も生み出さない。

5. 結論：プロの「責任」とは謝罪ではなく「問題解決」である

プロフェッショナルなエンジニアの責任は、完璧であることではなく、発生する問題に対して最も早く、最も効果的に解決策を提示し、再発を防ぐことにあります。

過度な謝罪をやめ、行動を伴う言葉に置き換える習慣をつけましょう。

• 「すみません」（資料が遅れました）→ 「資料をお待たせしました、こちらです」
• 「すみません」（確認します）→ 「承知いたしました、〇〇までに確認します」

心理的な知見に基づいた建設的な対話に切り替えることが、自身の専門家としての影響力とチームの生産性を同時に向上させるのだと感じます。
信頼は、謝罪からではなく、問題解決能力から生まれる事を忘れずにプロとして振る舞えるように私自身も精進していこうと改めて思いました。

※正直なところ、私自身執筆しておいて出来ていない事ばかりなので戒めとして刻もうと思います。

※最後に、謝る事自体が悪という話ではございません。
冒頭でも記述しましたが、明らかに非がある場合は誠意を持って謝るべきですし、
システム開発において沢山の人が絡む中で責任の所在が分散する時もあり自分が謝る事で仕事がしやすくなる瞬間があればそれもまた一つの手段でしょう。
ただ本来、開発を通じて行う事は「達成したい事」や「価値の創造」　について議論するべきだと私個人の価値観としては考えています。
そういった時に「過剰な謝罪」が本来やるべき事から逸れてしまうと勿体無いと、そう思っています。