そこで今回は，太平洋を挟んだエンジニア同士が，少しでも意思疎通を円滑に行うためのヒントとなる英語表現をまとめてみたいと思います。
「障害」を手元の和英辞典で引いてみると，barrier, obstacle, blockという訳しか載っていませんでした。でもITプロにとっては，“event”が適訳なのです。そう，“event log”のイベント。出来事という意味ですよね。もし“event”が思い浮かばなければ“problem”でも通じます。
「障害」の一般的翻訳： barrier, obstacle, block
「障害」のITプロ的翻訳：event
開発環境や試験／評価環境でのダウンは「障害」とは言いません。本番環境，商用環境での問題のことを「障害」と言います。よって“An event
in the production network”とか“An event in the commercial
environment”とか言わなくても，“An event”で事足ります。
本番環境，商用環境： the production network, commercial network
ネットワーク障害が発生し「通信が切れてしまった」というニュアンスをうまく出すには，“Outage”が適訳です。“Service
outage”,“Network outage”と言えば，「サービスが止まった」「ネットワークがダウンした」という意味になります。“Power
outage”と言えば「停電した」ということです。“Disconnect”だとうまく通じません。
「ダウンじゃ通じないんですか？」という質問が出てきそうですね。“System
down”と名詞として使うと通じないことはないですが，アメリカ人にはあまりピンとこないかもしれません。“The system is
down”“The network is down”と形容詞として使うと英語らしくなります。
障害通知が入ってきたら，まず問題の切り分けをして，ハードウェアの故障なのか，ソフトウェアの問題なのかを判断しますね。これを次のように言います。
First, we have to troubleshoot to isolate the problem
この場合，“troubleshoot”は動詞です。
ハードウェアの故障で，目で見てすぐに壊れている不良個所を見つけられることがあります。この場合は次のような英語を使います。
目視検査： visual inspection
不良個所： defect，problem
品質： quality
信頼性： reliability
“bug（バグ）”といえばソフトウェアの問題を指しますが，“defect（不良，不具合）”といえばハードとソフトの両方に使えます。
“defective part”や“defective
component”はハードウェア故障であり，交換（replacement）されます。このような部品は“Field Replaceable
Unit;FRU（フルー)”と呼ばれることもあります。不具合品は返品して故障解析するとともに，修理してもらいます。返品する時は通常RMAという返品承認をもらってから返送します。
修理： repair, rework, refurbish
商品返品許可： Return Merchandise Authorization（RMA）
“Repair”は文字通り壊れた物を修理すること。“Rework”は，壊れてはいないかもしれないが不具合があるので加工し直して良品にするという語感があります。“Refurbish”は「新装」というニュアンスで，古くなったものを手直ししてまた新たに使えるようにするという意味です。中古市場で販売されているPCはさながら“Refurbished
PC”でしょう。
障害の原因で，一番てこずるのが再現しないタイプ。再現してバグだということが分かれば直してもらえる（maintenance releaseのリリースになる）のです。
商用環境で運用中に発見されたバグ： Customer found defect （CFD）
再現しない障害原因： Problem not found (PNF)，Non-reproducible
さて今年も，障害発生，バグ発見時に使う英語から始めましょう。
障害が発生すると，その原因を理解すべく調査が行われます。Root Cause Analysis (RCA)とかFailure Analysis（FA）と呼ばれる解析です。同義語として使われることが多いです。（RootとRouteのつづりを間違えないように注意！）
?調査 ＝ analysis ＝ 解析
調査とはいえinvestigationとは言いません。investigationには捜査のニュアンスがありますから。問い合わせにはinquiryを良く使います。interrogationが使われているケースを見かけたことがありますが，「尋問」のような印象を与えてしまい，IT分野には不向きです。
障害の根本原因が判明すると，対応措置を考えます。
?対応措置 ＝ corrective action, fix, solution
和英辞典では対策の訳語としてcounter measureをよく見かけますが，「対抗する手段」という固い，厳しい語感があり，テポドンを迎え撃つ場合ならいざ知らず，ITの分野ではまず使われません。その代わりにcorrective action （修正措置）という，とても便利かつ洗練された言い回しをお勧めします。
Workaround ：コード自体には手を付けず，運用上の工夫で対応する方法
Fix ：「パッチを当てる」のパッチに相当。コードに追加して，バグに対応する方法
Solution ：コードそのものを改修する根本的な解決策
Fixやsolutionは，正しく問題を解決し，リグレを起こさないことを確認してから，リリースされます。
?確認 ＝ validate, validation
日本人は確認にverificationをよく使いますが，validationの方が「確認結果がオフィシャルになった」というニュアンスを出すことができます。
障害報告には重要性，優先順位を付記しますね。
Priority ： 優先度
Severity ： サービスや商用環境への影響度の側面から見た重要性
この2つの側面からP1，P2，S1，S2のように優先順位を決めて対応します。
?緊急 ＝ Urgent ＝ 迅速な対応を必要とする切迫性を意味
この場合の「緊急」には救急や非常事態を意味するemergencyは使えませんので要注意です。蛇足ながら重要性が低いという意味でminorを使う場合は，minerではないので誤記に気をつけましょう。スペルチェックでは見つからない誤りです。
重要性の一環として予想される影響範囲を記述する場合
?予想される影響範囲 ＝expected impact, estimated impact area, potential impact area
estimateはちゃんと考えた結果の予想，予測という意味ですが，guessは単なる推測というニュアンスがあります。expectedやassumedを使えば影響の発生を前提としているニュアンスが伝わりますし，逆にpotential impact areaと言えば，影響が出る可能性のある（しかし発生確率は低い）範囲ということになります。影響はinfluenceではなくて，阻害要因としてのニュアンスを持つimpactの方がいいです。impact on the schedule，impact on servicesという使い方をします。
次回は単語レベルではなくて，バグを説明するセンテンスを推敲してみたいと思います。