Linuxエンジニアが非エンジニアの上司に障害を説明できるようになった日の話｜現役講師が語る技術力より大切な「翻訳力」の鍛え方

「なぜ、そんな説明では伝わらないんだ」

SE時代に、上司からそう言われた夜のことが今も記憶に残っています。深夜に発生したWebサーバーの障害対応を終えた直後のことでした。「Apacheのプロセスが落ちていたので再起動しました。原因はメモリ不足で、スワップも枯渇していました。PHPのメモリリークが疑われます」と報告したとき、上司の顔は曇ったままでした。そして一言。「それで、今サービスは大丈夫なの？」

技術的には正確な報告だと思っていた。でも上司が聞きたかったのは、「今どういう状態か」と「いつ元に戻るか」だったのです。

この記事では、20年以上Linuxサーバーを運用してきた経験から、エンジニアが現場で信頼されるために必要な「翻訳力」の鍛え方を解説します。セミナーで3,100名以上を指導してきた中で気づいたことは、技術力はあるのに評価されないエンジニアと、信頼を着実に積み上げるエンジニアの間には、この「翻訳力」に明確な差があるということです。

「技術的に正確な報告」がなぜ伝わらないのか

私が現場でよく見かけるのが、「正確に話したのに伝わらなかった」と首をかしげるエンジニアの姿です。

これには理由があります。エンジニアと非エンジニアの上司は、同じ「障害」という言葉を聞いても、頭の中で動いている思考が根本的に違うからです。

エンジニアは「なぜ起きたか」「どう直したか」から考えます。一方、経営層や営業職の上司が最初に気にするのは「お客様への影響は？」「いつ再開できるのか？」「また起きるのか？」という3点です。

技術的な原因を正確に話すことは、その後に必要になります。でも最初の15秒でそこから話し始めると、相手の頭には「で、今どうなの？」という疑問が残ったまま、話を聞き続けることになる。これが「伝わらない」の正体です。

SE時代の私はこのことに長い間気づきませんでした。技術的に正確であること、それ自体が「良い報告」だと信じていたからです。

エンジニアが上司への説明でやりがちな3つのパターン

20年以上の現場経験で、私自身が何度も失敗し、受講生の話を聞いていても共通して出てくるパターンがあります。

1. 原因から話し始める

「メモリリークが原因で、スワップが枯渇し、Apacheがクラッシュした」という説明は、原因追跡としては完璧です。しかし、上司が聞きたいのは「今どうなっているか」です。

会話の構造を変える必要があります。まず「現在は復旧しています。お客様への影響は発注画面が15分間停止しました」と状態を先に言う。原因の話はその後です。

「PREP法（結論→理由→具体例→結論）」という話し方のフレームワークがありますが、障害報告においては「状態→影響→見込み→原因」の順で話すことを私は推奨しています。

2. 「わかりやすく」のつもりが言い換えにとどまる

「メモリリークを噛み砕いて言うと、プログラムがメモリを使い続けて解放しない状態です」。これは技術的には正しい説明ですが、上司に必要なのは「このサーバーの処理能力が限界に達した」という業務文脈での説明です。

「専門用語を言い換える」のではなく、「業務への影響に変換する」という発想の転換が「翻訳力」の本質です。技術用語そのものの解説を求めている上司はほとんどいません。「自分たちのビジネスに何が起きたか」を知りたいのです。

※注意：技術的な詳細の説明を省くわけではありません。「いつ話すか」の順序を変えることが大切です。上司が「今の状態」を把握した後であれば、原因の詳細も落ち着いて聞いてもらえます。

3. 「解決しました」で終わらせる

「対応が完了しました」と伝えたとき、上司の頭には「また起きないの？」という疑問が残ります。解決報告には必ず「次の一手」を添える必要があります。

「今回の根本原因はメモリリークで、再発防止として明日の午前中にPHPのバージョン更新と監視アラートの設定を実施します」という形で、次の行動まで伝えることが信頼の積み上げにつながります。

「翻訳力」を鍛えるために私が実践してきたこと

SE時代の失敗経験から試行錯誤し、20年かけて積み上げてきた3つの習慣を紹介します。

1. 最初の15秒は「状態」と「見込み」だけ

障害報告のときは、最初の15秒で以下の3点だけを言うと決めました。

・現在の状態（「サービスは現在正常稼働しています」等）
・影響範囲（「受注システムが20分間停止し、注文処理が一時的に止まりました」等）
・次の見込み（「根本原因の調査を翌朝8時までに完了し、報告します」等）

これだけ言えば、上司は「状況を把握した人間が対応している」と感じます。技術的な詳細は、「原因については説明してよいですか？」と一言確認してから話せばよいのです。

2. 例え話の引き出しを日頃から作っておく

「メモリリーク」を「水道の蛇口が少しずつ開きっぱなしになって、最終的に水があふれる状態」に変換する、という例え話のパターンを日頃から準備しておくことが大切です。

私のセミナーでは、「エンジニアとして使う技術用語を、上司・家族・小学生に説明するとしたらどう言うか」を考える習慣を推奨しています。この「3段階変換」の練習が、現場での説明力を着実に鍛えます。

最初は難しく感じますが、障害のたびに一つ例え話を考える習慣をつけるだけで、半年後には引き出しが豊富になります。

3. 「次の一手」を必ず手元に置く

障害対応中は、復旧作業と並行して「再発防止策の候補」を頭の片隅に置いておくことが重要です。

「調査しないとわかりません」は誠実ですが、「メモリリークが疑われるため、PHPのバージョン確認とpruning設定の見直しを検討しています」という形で言えると、上司の安心感がまったく違います。技術的な不確実性を認めながら、行動の見通しを示すことが翻訳力の実践です。

まとめ

「翻訳力」は天性の才能ではありません。練習で鍛えられるスキルです。

Linuxのログが読めるだけで現場の信頼が変わる理由でも書いたように、技術的な情報を「現場の言語」に変換できるエンジニアは、単に技術に詳しいだけのエンジニアより遥かに高い信頼を獲得できます。また、Linuxの現場で「質問が下手な人」が損をする理由と同様に、コミュニケーションの質がキャリアに大きく影響するのです。

以下に、今日から実践できる翻訳力の対応表をまとめます。

場面	エンジニアが言いがちなこと	翻訳後（上司が聞きたいこと）
障害発生直後	「原因は△△でした」	「現在は復旧済み。影響は20分・受注停止でした」
技術的な説明	「メモリリークが発生しました」	「サーバーの処理能力が上限に達しました」
対応完了報告	「対応しました」	「対応済み。再発防止として明日の午前中に△△を実施します」
不確実な状況	「調査しないとわかりません」	「△△が疑われます。△△を確認し、△△の対応を検討中です」

セミナーで3,100名以上を指導してきた経験から言うと、「翻訳力」を意識し始めたエンジニアは、半年も経たないうちに上司からの評価が変わったと実感することが多いです。技術力を高めることと並行して、「誰に、何を、どう伝えるか」を意識する習慣をぜひ持ってみてください。

---

• 前のページへ：「再現しない」で済ませていたLinux間欠障害が突然本番を止めた話｜現役講師が語るログ記録の大切さ
• この記事の属するカテゴリ：Linux学習ガイドへ戻る