普通に言うと#

欠陥、不具合、バグ。

ITの現場だと、

「納品されたシステムに瑕疵がある」
「瑕疵担保責任（契約不適合責任）の期間が〜」

みたいな会話で出てくる。

「要はバグのことでしょ？」って思いたくなるけど、単なるプログラムの凡ミスというより、「契約上つくると約束したレベルに達していない不具合」 というニュアンスが強い。

ここにはシステム開発ならではの「責任問題」がガッツリ絡んでくるっぽい。

システム開発って、基本的には発注側が「どんな技術があるか教えて（RFI：情報提供依頼書）」と情報を集めて、「こういうシステムを作ってくれ（RFP：提案依頼書）」と具体的にリクエストを出して契約を結ぶ。

で、受注側（エンジニア・ベンダー）が「作れます！」って引き受けたのに、納品されたものがRFPで決めた要件を満たしていなかったり、動かなかったりすると「瑕疵（契約不適合）」になる。

単に「あ、バグありました〜直しまーす」で済めばいいけど、瑕疵と認定されると 「契約違反だから無償で納期までに直せ」「損害賠償を払え」といった法律上の責任を追及されちゃう。

民法改正で言葉自体は「契約不適合責任」に変わりつつあるけど、契約書や現場の会話ではいまだに「瑕疵」が大量に残ってる。

だから、仕事で「これ瑕疵だよね？」って言われたら、単なるバグ報告じゃなくて 「お前ら責任取って無償で直せよ」という重いプレッシャーが裏に含まれてる可能性があるから注意した方がいい。

普通に言うと#

そうなる確率の高さ。確からしさ。

例えば、

「この障害が再発する蓋然性が高い」

と言われたら、

「この障害、また起きる可能性がかなり高いっぽい」

と脳内変換すればOK。

「『可能性』でよくない？」って本気で思うんだけど、どうやら「可能性」だと1%でもあれば「可能性がある」と言えちゃうのに対して、「蓋然性」は**「客観的に見て、そうなる確率がかなり高い」** というニュアンスを出したい時に使うらしい。

個人的には、今回調べた中でもトップクラスに「普通に『高い確率で〜』って言えよ」と思った言葉だった。
(初めて聞いたよ。。。)

普通に言うと#

何回同じ処理を実行しても、最終的な結果が変わらない性質。

これはイキり日本語ではなく、正真正銘のガチなIT技術用語。

例えば、

PUT /users/1
name=佐藤

というリクエストを1回送ろうが、ボタン連打して3回送ろうが、最終的にDB上の名前は「佐藤」のまま。結果は変わらない。

この性質を「冪等性（idempotent）」と呼ぶ。

HTTPの仕様（RFC 9110）でもバシッと定義されていて、決済システムやAPI設計では超重要。

これは「難しく言っている」わけじゃなくて、「この重要な性質を一言で言い表す単語がこれしかない」 から使われてるパターンの代表格。

普通に言うと#

食い違い、認識のズレ。

例えば、

「ユーザーと開発者の認識に齟齬がある」

なら、

「ユーザーと開発者で言ってること（思ってること）がズレてる」

という意味。

IPA（情報処理推進機構）の資料とか見ても「発注者と開発者の認識の齟齬がプロジェクト炎上の原因」みたいに書かれてる。

「認識のズレ」って言えば一発で伝わるのに、、、って思うけど、

要件と実装に齟齬がある

って書き慣れると、確かに短いしなんかプロっぽく見えるから使われがちなのかも。

普通に言うと#

アクセスや通信が集中しすぎて、処理が追いついてない状態。

例えば、

「現在、アクセスが輻輳しています」

なら、

「アクセス殺到してサーバーパンクしかけてる」

ということ。

これも単なる難しい日本語というより、ネットワークや通信の専門用語。

単に人が混んでいるだけじゃなく、「通信回線やサーバーの処理能力を超えてパケットが詰まってる」という状態を表している。
インフラ回りで、あえて使う場合が多い気がする。
障害連絡とかでよく出てくる言葉。

普通に言うと#

大きなギャップがある、離れすぎている。

例えば、

「見積もりと実績に大きな乖離がある」

なら、

「見積もりと実際かかった工数がズレまくってる」

ということ。

単なる「違い」というより、「本来あるべき姿や計画から、現実が大きく離れてしまっている」 というネガティブなギャップを表す時によく使われる。

普通に言うと#

モレがなく、ダブりもない状態。

「Mutually Exclusive, Collectively Exhaustive」の頭文字をとったコンサル用語。

例えば、

社員
├─ 正社員
└─ 非正社員

みたいに分ければ、漏れもないし重複もない。

ただ、現場で「これMECEに整理しといて」って言われた時は注意が必要。
どこまで細かく分ければ「漏れがない」と言えるかは人によって違うから、単に「綺麗に分類して」くらいの意味でアバウトに使ってくる人も多い。
正直、現場レベルでは「綺麗に分類しといて」という意味で使ってる人が多いイメージ。

普通に言うと#

誰が読んでも解釈が1つにしか決まらないこと。

設計書とかで、

「一義的に解釈できるように記載すること」

と言われたら、

「読む人によって受け取り方が変わるような曖昧な書き方はするな」

という意味。

「Aとも取れるしBとも取れる」みたいな仕様書は事故のもとになるから、設計の現場では割と大事な概念だったりする。

普通に言うと#

ずっと隠れていた問題が、目に見える形で表に出てくること。

例えば、

「潜在していたリスクが顕在化した」

なら、

「前からヤバそうだった問題が、ついに表に出ちゃった」

という意味。

ただ「問題が発生した」と言うのと違って、「もともと裏に潜んでいたものが、ついに吹き出した」 というニュアンスが含まれている。

普通に言うと#

過去の日付にさかのぼってルールや契約を適用すること。

契約の変更とかで、

「4月1日に遡及して適用する」

と言われたら、

「いまは6月だけど、4月1日からの出来事として扱うよ」

という意味。

これもIT用語じゃなくて完全に法律・契約用語。
保険とか、契約更新が遅れた時とかに、現場でよく耳にする。

普通に言うと#

話や資料の「細かさ」のレベル。

「この資料、粒度が細かすぎる」

なら、

「細かく書きすぎて全体像が見えない」

ということ。

ただし注意したいのが、「粒度を上げる」と言われた時。

• 「もっと具体的に細かくする」という意味で使う人
• 「もっと抽象化して全体像をまとめる（粗くする）」という意味で使う人

が現場に混在してる。
「粒度を上げてください」と言われたら、「具体的にはどのレベルまで書けばいいですか？」って絶対確認したほうがいい。
じゃないと大変なことになる。(実体験)

普通に言うと#

必要なパターンが漏れなく揃っているか。

「テストケースの網羅性を確認する」

なら、

「テストの抜け漏れがないか全パターンチェックする」

ということ。

「全パターンやった？」って聞くより「網羅性は？」って言った方がプロっぽく聞こえるからか、テストの現場では日常茶飯事で使われる。

普通に言うと#

その判断や仕様が、目的・条件に合っているか。

「この設計の妥当性を検証する」

なら、

「この設計で本当に問題ないか、条件に照らして確かめる」

という意味。

単に「正解か不正解か」ではなく、「今の状況や予算、目的に照らし合わせて適切と言えるか？」 というニュアンスがある。

普通に言うと#

今までのやり方や前例をそのまま引き継ぐこと。

「既存システムの方式を踏襲する」

なら、

「前のシステムのやり方をそのまま真似してつくる」

ということ。

ゼロから考えるのが面倒な時や、前例と同じにしてリスクを減らしたい時に大活躍する言葉。

普通に言うと#

システムが止まらずに、いつでも使える状態をキープできる度合い。

「可用性を高める設計にする」

なら、

「サーバーが死んでも予備に切り替えて、システムを落とさない作りにする」

ということ。

これもITインフラの超重要ワード。
「信頼性」とか「堅牢性」と一緒にセットでよく出てくる。