2022年後半に読んで特によかった本

　10月に「2022年度上期」版を書いてしまったのですが、こういうのって「年度」じゃなくて「年」単位で書くっぽい！
　なので、2022年10月～12月の3か月分で書きます。年度上期分は以下。

www.kzsuzuki.com

漫画

ピアノの森

ピアノの森（１） (モーニングコミックス)

　もう、この秋はこれがブッチギリです。
　Wikipediaによると、連載開始は1998年。休載・廃刊・移籍などを経て2015年に完結したとのこと。
　とにかく、「完結してくれてありがとう」「この物語を最後まで届けてくれてありがとう」、そう言いたくなるのに一方で、「終わらないでくれ」「ずっと物語を続けてくれ」とも言いたくなる、そんな素晴らしい作品なんです。
　どこがいいのか、どう感動したのか、何を言ってもネタバレになりそうで言いづらいのですが・・・、

　「森のピアノ」と育ち豊かな才能をもつカイと、偉大なピアニストを父にもち、ピアノの英才教育を受けてきた雨宮。物語はこの2人の少年の成長を軸に進んでいくのですが、彼らを取り囲む人たちそれぞれが、とても丁寧に描かれています。
　どんな時期に読むかで、心を寄せるキャラクターが変わるのではないでしょうか。わたしはどうしても「親」キャラクターに自分を重ねずにはいられませんでした。こどもが思っているほど完璧ではない、むしろ完璧などほど遠い、それでも子どもを思う気持ちだけは嘘ではない、ままならなさにもがき続ける親という・・・。

　わたしはマンガアプリで読みましたが、滂沱の涙にまみれた中年たちがコメント欄に多発していました。マンガアプリのコメント欄ってどこかしら荒れたコメントが入りがちなのですが、『ピアノの森』ではそれがほぼないというのも印象でした。

　連載開始が20年以上前ということで、序盤はけっこう不愉快なシーンも出てきます。絵柄も最近のものではないので、合わないと感じる人もいると思います。
　それでも、ぜひ、読み進めてください。忘れられない作品になると思います。
　わたしも、物理スペース問題が解決したら、物理本購入しようと思います・・・！

IT技術系

量子コンピュータが本当にわかる！

量子コンピュータが本当にわかる！ ― 第一線開発者がやさしく明かすしくみと可能性

　量子コンピュータについて、一般の人がふんわり「理解」していることの多くが誤解であるという話をしたうえで、では実際に量子コンピュータとはどういうもので、どこまで進んでいて、この先どうなっていくのか、そして現場ではどんなことをしているのか、ということをかなり丁寧に説明した本です。

　たとえばわたしは、「重ね合わせの原理」という性質を使って、多数の計算の答えが同時に得られる、だから速い、みたいなイメージをもっていましたが、それはだいぶ違うようです。重ね合わせ方を工夫することで、正解に対して波を振幅を強く、不正解に対しては弱くすることで、正解に近づいていく・・・というもののようで、何となく考えていたものとはだいぶ違ったのです。
　また、量子コンピュータには想像以上に欠点が多いこともよくわかりました。従来コンピュータでは、データがゼロイチで表現されているためノイズや誤差に強いのに対し、重ね合わせた波の振幅や位相*1が連続値であり、ノイズや誤差に弱い、など。

　「本当にわかる」ということで、スリットの実験から量子計算の原理まで、数式ゼロ、専門用語もできるだけ使わず多くの図解付きで丁寧に説明してくれているけれど、それでもまだまだ難しい。でも面白い！
　2周目でようやく、とっかかりが理解できたように思います。量子コンピュータに興味のある方は、この本を最初の一冊にすることをお勧めします。

フィクション

新装版 炎環

新装版 炎環 (文春文庫)

　2022年の大河ドラマ・『鎌倉殿の13人』、素晴らしかったですね。とにかく、硬軟の交え方が絶妙すぎる。むしろ、緩いシーンの後にはしんどいシーンがくる、そういう警戒まで生まれてしまいました。
　わたしは高校時代、日本史がもっとも嫌いだったのですが、大河のおかげで各人物が映像付きで再生されるようになり、歴史の資料集のもっともつまらない「家系図」もすっと読めるようになり、ドラマのパワーのすさまじさを思い知らされました。日本史はもう平安時代以降全部ドラマ化してしてほしい。大・大河ってことで。

　もちろん、ドラマはドラマ、多くの部分がフィクションでしょう。
　それを踏まえて、今読みたいのがこの『炎環』。北条義時、梶原景時、阿野全成、その妻阿波局（大河では「実衣」）に焦点を当てた短編です。
　1年前のわたしなら、3行も読めなかったでしょう。でも今なら！ 漢字2文字のキャラクタが、現代日本の俳優の顔で動き出す！

　とはいえ、『鎌倉殿の13人』とは人物の解釈が違います。
　『13人』での全成は大きな野心はなく、ドジなお調子者、気が弱く周りに流されてしまい最後には・・・というキャラでしたが、『炎環』では自分の野心を隠し、台頭する北条氏の陰でそっと駒を進めていく人物として描かれています。
　その違いを楽しむのも、今だからこそできる楽しみ方ではないでしょうか。

2022年の読書をふりかえって

　今年もたくさんの本に出合えたなあと思うと同時に、さくっと読み終えられるフィクション・漫画・自己啓発本に対して、腰据えて読む必要のあるビジネス書や技術書をきちんと読み込めず、地に足がついていないなあという反省もあります。
　前者も必ずしも悪いわけじゃないのですが、「なんかたくさんインプットした気になる」というのがよくないところです。

　2023年は乱読に走らず、本当に読むべき本に絞って、筋肉質なインプットを心掛けたいと思っています。

*1:なお本書では、「振幅」「位相」といった用語をあえて避けていると思われ、使われていません。

JaSST nano vol.19で『ISO/IEC/IEEE 29119-11からAIシステムのブラックボックステストについてメモってみたの』というタイトルで発表しました #jasstnano

　タイトル長すぎてすみません。
　発表資料はこちらです。

speakerdeck.com

　vol.19は、わたしが発表予定を確認した時点では石川冬樹先生の「画像生成AIのQAを考えてみる」しかエントリーされておらず、「専門家の話を聞く前の前座として、AIのテストについての初歩的な話をするのはいい考えなのでは！？」と思って準備し始めたのですが、当日に準備が間に合う自信がもてたのが2日前で、あまりに遅すぎました・・・。

jasst-nano.connpass.com

　ということで、石川先生のご発表と、JaSST実行委員会メンバーたちによる熱いディスカッションの間に堕ちた謎のおみそ発表になってしまいました。
　が、イベントドリブンで勉強できたのでいいとしましょう！

　将来の（自分の）検索性のため、中身の一部をリサイクルして、ブログ記事にしておきます。
　以下の情報は、ISO/IEC/IEEE 29119-11の第5章「5. AIシステムの特徴」、第6章「6.1.12. AIベースシステムのテストオラクル問題」、第8章「8. AIベースシステムのブラックボックステスト」の一部を参考にし、自分の解釈を追加したものです。

テストオラクル問題

　AIベースのソフトウェアではしばしば、「テストオラクルがない」ことが問題になります。
　そもそもテストオラクルとは何で、それが欠けるというのはどういうことなのでしょうか。

テストオラクル

　ざっくりいうと、テストにおいて「この結果は正しいね」と判断するための根拠のことです。
　わかりやすいのは「仕様書」ですが、それだけではありません。

　ISTQB用語集から引用します。

テスト対象のソフトウェアの実行結果と比較する期待結果のソース。
オラクルは、実在する（ベンチマーク用の）システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。
（ISTQB用語集）

　テストオラクルの種類の例は、以下の通りです。

• そのソフトウェアをふるまいを記述したドキュメント: 仕様書、ユーザーマニュアルなど
• 比較対象にできるソフトウェア: 競合製品など
• 過去の履歴: 過去のテストケース実行結果など
• 人間の知識: 「専門家がOKと判断すればOK」など。
• その他

www.kzsuzuki.com

テストオラクルが不足しがちな理由

　6.1.12では、5章は6章で述べられたAIシステムの特徴や課題から、テストオラクルが欠落してしまう原因について説明しています。

仕様がない！

• 仕様の記述が、従来以上に不完全・非形式的になりがちで、期待値を決めるのが難しい。
• 「未知の洞察」を得ることが目的のシステムであれば、本質的に期待値は未知となる。

　「今まで誰も知らなかった特徴を見出す」といったことを目的としていた場合、その期待値を「誰も知らない」のは必然ですよね。

複雑！

• 典型的なニューラルネットワークでは、一つの判断を行うだけでもパラメタの数が1億超えだったりする。

　規格策定時でこれなので、今だともっと多いのかもしれません。

確率的・非決定的

• AIベースシステムの多くは確率的（probabilistic）な実装をしているため、非決定的（non-deterministic）になる。
• 非決定性にともなう変動を考慮に入れた、「賢い期待値」（smarter expected result）が必要。

　たとえばある位置から別の位置へのルートが複数ある状況で「最短ルート」を求める*1場合、厳密な解を見つけることが困難であるため、初期値を元に選ばれたルートから導かれる「準・最適な解」（sub-optimal）をヨシとすることがあります。この初期値をランダムに与えている場合、実行のたびに別の結果が出ることになり、出力の再現性の欠如がもたらされます。

自己学習する！

• システムが新しいデータを学ぶことでふるまいが変化していく。

　新たな学習データをモデルに取り込むことで、精度を上げたりデータの新しい傾向に追随していったりするので、当初うまく通ったテストが、後のシステムでは通用しないかもしれません。

29119-11で説明しているブラックボックステスト

　Part11では、以下の5つについて説明しています。
　ただし、このすべてがテストオラクル問題を解決できるわけではありません。

• 8.1. 組み合わせテスト
• 8.2. バックツーバックテスト
• 8.3. A/Bテスト
• 8.4. メタモルフィックテスト
• 8.5. 探索的テスト

組み合わせテスト (Combinatorial Testing)

　要件に合致していることを完全に証明するには「全数テスト」が必要ですが、非現実的です。ペアワイズなどの組み合わせテストの技法によって、システマティックかつ効果的に、テストケースを大きく削減できます。テストケースを合理的に減らすことが目的であり、テストオラクル問題は解決できません。

　組み合わせテストの技法は既存のソフトウェアテストでも利用されていますが、AIベースシステムにおいて適用する場合には特に、以下の2つの課題があるとしています。

1. AIベースシステムではパラメタの数自体が膨大で、組み合わせテスト技法を使ってもなおテストセッが巨大なので、自動化と、仮想的なテスト環境が必要である。
2. そもそも、ペアワイズ（2因子間網羅）で十分なのかも議論の余地がある。

バックツーバックテスト (Back-to-back testing)

　そのシステムの「代替バージョン」*2を、擬似的なオラクルとして用いる方法です。
　過去のJaSSTで、あまりに複雑なJR料金計算の答え合わせをするために、このような手法を取ったことが報告されています。

www.publickey1.jp

テスト対象となる実機用の運賃ソフトウェアと、検証用の運賃ソフトウェアは別のチーム、別のアルゴリズム、別のプログラミング言語で作ります。実機用はC++ですが、検証用はJavaで言語特有のバグをなくそうとしています。

　2つのシステムの独立性が高いことがこの手法の条件なのですが、AIベースシステムの場合、利用するOSSが似たり寄ったりになり、独立性を保つのが難しいとしています。

A/Bテスト (A/B testing)

　WebサービスのUIデザインの優位性を評価する、統計的な手法としてよく聞くものです。
　2つを比較するという意味で、バックツーバックテストに少し似ているようにも思えますが、バックツーバックテストは2つのシステムの実行結果を比較するのに対し、A/Bテストはモデル全体の性能を比較するものです。

　AIで何かを判定する場合の「性能」については、以下の記事に書きました。

www.kzsuzuki.com

メタモルフィックテスト (Metamorphic testing)

　正しいとわかっている元テストケースから、後続テストケースを生成する手法です。
　これだけでは全然意味不明なので、2018年に書いた記事を載せておきます。

www.kzsuzuki.com

　ある入力と出力のセットに対し、「入力をこう変えれば、出力はこう変わる（あるいは変わらない）」ということの関係を、「メタモルフィック関係」といっています。これを利用して、1つのメタモルフィック関係から、複数の後続テストケースを得ることができます。
　新しいテストケースの期待出力まで生成することができるので、テストオラクル問題を解決する方法の1つと言えます。

　規格では、「従来のテストオラクルを使うことで検出できるバグの90%が、3～6種類のメタモルフィック関係でカバーされるとの研究がある」としています。にわかには信じられず誤訳の可能性もあるので、ちょっと原典を当たってみようと思います。

探索的テスト (Exploratory testing)

　みんな大好き探索的テストです。
　テストケースや手順を事前に記述しておくのではなく、対象のソフトウェアを触って学習しながら、次に行うべきテストをその場で定め、実行していくものです。
　得られた結果が妥当かどうかは都度、人間が判断するので、ある意味ではテストオラクル問題を解決している・・・と言えるかもしれません。

おわりに

　ISO/IEC/IEEE 29119-11で説明されている、5つのブラックボックステスト技法について紹介しました。
　この5つしか技法がないというわけではなく、AIの進化に伴ってテストの技術も進化していく（いかなければならない）ものと思います。

　次はこの本をちゃんと読みましょう！

AIソフトウェアのテスト――答のない答え合わせ [4つの手法] (AI/Data Science実務選書)

*1:巡回せぇるすまん問題

*2:back to backは、「背中合わせの」という意味っぽい。

五匹の猿と、テストの「意図」

　最近、「5匹の猿の実験」（the Five Monkeys Experiment）という話を知りました。有名な話なのかもしれませんが、全然知らなかったので紹介してみます*1。
　本当の実験というよりは、寓話的なもののようですが、ともかく以下のような内容です*2。

5匹の猿の実験

科学者グループが、5匹の猿をケージに入れた。ケージの真ん中にはハシゴがあり、それを昇るとバナナにありつける。
猿がハシゴを昇るたびに、科学者たちは残りの猿に、冷え切った水を浴びせた。
そのうち、猿がハシゴを昇ろうとするたびに、他の猿たちがその猿を殴るようになった。
しばらくすると、バナナの誘惑に負けてハシゴを昇ろうとする猿はいなくなった。

科学者たちは、猿を1匹入れ替えることにした。その猿ははじめ、ハシゴを昇ろうとしたが、すぐさま他の猿たちに殴られることになった。
何度か殴られるうちに、新しい猿はハシゴを昇ろうとするのをやめた。なぜ昇るべきでないかはわからないまま。

2匹目の猿が入れ替えられ、同じことが起こった。1匹目の猿も、2匹目の猿を殴るのに加わっている。
3匹目の猿の入れ替えでも同じことが繰り返された。
4匹目の猿が入れ替えられ、また殴られ、最後の5匹目の猿も入れ替えられた。

ケージに残る5匹の猿は誰も、冷水を浴びたことがないにもかかわらず、ハシゴを昇ろうとする猿を殴ることはやめない。
ハシゴを昇ろうとする猿をなぜ殴るのかと問うても、その答えは「わからない。ただ、それがここのやり方なんだ」となるだろう。

他にやり方があるのに、なぜ今していることを続けるのか。それを問う機会にしてもらいたい。
結論: 他の人のやり方に従うのではなく、従う前に考えよ。

　「理由はよくわからないけれど、そう決まっているから、従う」という方法は、それほどハズレない処世術だとは思うのですが、一方で非効率の温床になりがちです。職印を傾けて押すとか！

　また、世の中のコンプライアンス事件って、こういう「現場はずっとそうやっていた」「誰も疑問を差し挟めなかった」に起因するものも多いんですよね。当事者は「悪いことをしてた」という意識もなく、むしろ「規則よりも現場の実践知に従って、正しくやっていた」という認識だったりします。
　だからこそ、「ずっとやってきたこと」＝「正しい」ではないことは、折に触れて見つめ直すことが大切です。

2つの疑問

　さて、この話を読んで、「あれ？」と思ったことが2つあります。

会話すればよくない？

　「なぜ、そうなっているのか」を、猿同士は話せないとしても、人間同士は話せるんじゃない？人間だもの。と思ったのですが・・・、
　不特定多数に適用されている暗黙の社会規範みたいなものは、会話する「相手」がいないんですよね。

　たとえば、エスカレーター右側*3空けちゃう問題。
　これはもう一種のマナーになっていて、立ち止まる（これが本来の乗り方）人は左に寄る。「そうすることが望ましい」じゃなくて、「そうしないと悪」くらいになってる。たとえ、右側を昇っていく人がいなくても。なので輸送効率が常時、スペックの半分くらいになってしまう・・・。

　でも、たとえこのやり方を改善すべきと考えたところで、誰とそれを合意できるのか。
　たまたまエスカレーターに乗り合わせた人に言ったところで・・・ちょっとした不審者ですよね。
　「猿は言葉をつかえないけど、人間はそうじゃないから、改善できる」わけじゃないんだなと。会社組織も同じようなものかもしれません。

元の猿も「理由」をわかってなくない？

　この話、「なぜバナナを取ろうとしてはいけないか」、残った猿は誰も知らないという話なのですが、実は「最初にいた5匹」も、その理由は知らないんですよね。
　直接的には「他の猿に殴られるから」で、なぜ殴るかといえば「冷え切った水をかけられるから」なのですが、「誰かがハシゴを昇ろうとすると、水をかけられる」なんて論理不明の理不尽であって、理由にはなっていないという。

　猿がやるべきだったのは、「冷水をかけてくる科学者どもを殲滅する」だったのではないでしょうか。

猿の惑星 プリクエル ブルーレイコレクション (3枚組) [Blu-ray]

テストでも同じことが起きていないか？

　さて、ここから無理やりテストの話にもっていきましょう。

　「なぜやっているかわからない」になりがちなものの一つに、リグレッションテストがあります。
　リグレッションテストは、作戦と意志がないと、ひたすらに増えていってしまいます。集約・剪定など、継続的・積極的な合理化が必要です。

　そんなときに一番困るのが、「なぜやっているのかわからないテスト」です。
　なんかすごく具体的な値や手順が指定されていて、その条件に特別な意味がありそう。でもその組み合わせが何を意味しているのか、過去どんな経緯でこのテストケースがリグレッションテストセットに組み込まれたかわからない。だから削除できない。削除して何か問題が起きたら、「冷たい水を浴びせられる」から。

　なので、テストケースには、「なぜそれが必要なのか」という「意図」を残しておくことが大切です。「意図」を残しておくことで、後世の人は、「今もなおこのテストが必要なのか」をあらためて判断することができます。

　「意図」の重要性は、テストケースにとどまるものはありませんね。
　なぜ、そのテスト観点が必要なのか。なぜ、この値を同値クラスであるとしたのか。なぜ、このテストや他のテストより優先度が高いのか。

　「意図」は、成果物そのものとセットになる、重要な情報です。
　ケージの猿のように、後の人が「よくわからんけど従う」ことにならないよう、しっかりと残していきたいものです。

*1:ソフトウェアテストの小ネタ アドベントカレンダー はもう埋まっていた。

*2:以下のサイトを参考に、自分で翻訳しています。 www.throwcase.com

*3:はい、そうですね、関西では左側を空けるんでしたね、すみません。

テストエンジニアのジョークを調べてみた

　みなさん、こんにちは。
　この記事は、「ソフトウェアテストの小ネタ Advent Calendar 2022」 9日目の記事です。

qiita.com

　ChatGPTに生成させたと思しきジョークが、テストエンジニアのブログで紹介されていました。
　以下は、その日本語訳です。

天国行きと地獄行きの分かれ道に立った、プログラマーとテストエンジニア。

テ「いちかばちかはごめんだ。両方をテストして、安全な方を行くよ」
プ「そんな時間はないよ！ どちらかが天国と信じて選ぶしかない！」
テ「信頼せよ、されど確認せよ」

　まあ、そこまで面白くはないですね。
　ということで、テストエンジニアジョークをネットから探してみました。
　日本語訳は、ジョークの本質部分を変えないように、文章を変えているものがあります。

テストエンジニアのジョーク

勇気あるテストエンジニア

　ソフトウェア開発企業が、航空機用ソフトウェアを完成させた。
　そのソフトウェアを搭載した飛行機の最初のフライトが、社員に無償で提供されるという。

「希望者はいるか？」

　名乗り出る者はいない。

　しかしついに、一人の男が名乗り出た。
　勇気あるそのテストエンジニアはこう言った。

「わたしが乗りますよ。着陸できないってわかってるんで」

引用元: Software Testing Jokes

　わかっててリリースしていることの方がよっぽど勇者だぜ・・・。

サンドイッチ

　二人のテストエンジニアが、レストランで飲み物を注文した。
　そしてカバンからサンドイッチを出し、食べ始めた。

「お客様、ご自分で持ち込んだサンドイッチを食べるのはご遠慮ください」

　テストエンジニアは、サンドイッチを交換した。

引用元: Software Testing Jokes

　これ多分、オリジナルはテストエンジニアじゃないでしょうけど、仕様の穴を見つけにいくのがテスト屋さんっぽい。

バーにきたテストエンジニア

　ソフトウェアテストエンジニアが、バーにやってきた。
　バーに走り込んできた。
　バーに這いよってきた。
　バーにおどり込んできた。
　バーに飛び込んできた。
　バーに跳ね入ってきた。

　そして注文。

　ビールを1杯。
　ビールを2杯。
　ビールを0杯。
　ビールを99999999杯。
　ビールジョッキにトカゲ1匹。
　ビールを-1杯。
　ビールを"qwertyuiop"杯。

　テスト完了。

　そして、「本物の顧客」が、バーにやってきた。

「トイレはあるかな？」

　バーが炎に包まれた。

引用元: A software tester walks into a bar.

　Redditがオリジナルではないかもしれませんが・・・。
　「やってきた」後にあらゆる方法で入ってきて、激しい注文をしまくるテストエンジニア、でもその奮闘むなしく、本番環境で普通にありうるシナリオであっさり障害・・・というところですね。

　これはいわゆるbar jokeの一種で、bar jokeの説明が先に必要なんですよね。
　せっかくなのでこの後で、bar jokeも。

息子の名前

教師「もしもし、息子さんの学校の者です。コンピュータで問題が起こりまして・・・」
母親「まあ。息子が何か壊してしまいました？」
教師「はい、ある意味では・・・。息子さんの名前、本当に Robert'); DROP TABLE Students; -- なのですか？」
母親「ええ、うちでは小さなボビーテーブルって呼んでいますの」
教師「そうですか・・・ 今年の生徒の記録が消えてしまいました。満足ですか？」
母親 「そうね、データベースへの入力をサニタイズすることを知っていればよかったのだけど」

引用元:Top 10 Programmer Jokes, Explained for the Rest of Us

　プログラマージョークのサイトなのですが、こういうことやるのってやっぱりテストエンジニアかなって。

バージョーク

　順番が前後になりますが、bar jokeというのは、「〇〇がバーに入ってきた」という定型フォーマットから始まるジョークのことです。〇〇には、実にいろんなモノが入ります。
　コンテキストがわからないと理解できないモノものありますが、Reader's Digestにたくさんまとまっているものを、いくつか紹介します。

www.rd.com

数学者

　無限に多い数学者がバーにやってきた。

1人目「ビールを1杯」
2人目「ビールを1/2杯」
3人目「ビールを1/4杯」

　それ以上何か言わせる前に、店主はぴったりグラス2杯分のビールを出してこう言った。

「限度ってものを知るんだね」

　1 + 1/2 + 1/4 + ... の無限級数が2になるので、無限の数学者に対してはこれで十分。
　というのと、limitという単語が「人間の限界」と数学の意味の「極限」のダブルミーニングになっているものと思います。

中性子

　中性子がバーにやってきた。

中性子「ビールは1杯いくらだい？」
店主「あんたは無料だよ」

　日本語だと完全に意味不明ですが、店主の回答は英語で「No charge.」です。
　これも、chargeが「代金」という意味と、「電荷」という意味をもっている（そして中性子は電荷がゼロである）ことを生かしたジョークですね。

プログラマーのジョーク

　こっちはもう無数にあって一生時間が溶けるので、短文で終わる美しいものを、以下のサイトから3点。
　詳しい解説も以下のサイトにあるので、意味が分からない方はぜひ。

www.idtech.com

プログラマーはなぜ、ハロウィンとクリスマスをごっちゃにするのか。
Oct31とDec25が等しいからだ。

　進数表記。 　

世の中には10種類の人間がいる。
二進法を理解している者と、そうでない者だ。

　進数表記。 　

コンピュータを速くするのにベストな方法。 9.8m/s2で加速する。

　物理的。

まとめ

　切れ味するどいQAエンジニアジョーク、きみも考えてみないか！？

ソフトウェアテストで学ぶ比喩表現

　みなさん、こんにちは。
　この記事は、「ソフトウェアテストの小ネタ Advent Calendar 2022」 8日目の記事です。 qiita.com

　唐突ですが、比喩表現って種類が多すぎますよね。
　文学的なみなさんは、その使い分けにお困りのことと思います。

直喩、暗喩、換喩、提喩 、諷喩、活喩の違いが言えたらOK。

— あきやま🧣 (@akiyama924) 2022年7月4日

　とすると、わたしはまったくOKではないようです。
　今日は、ソフトウェアテストを題材に、いろいろな比喩表現を学んでいきましょう。

　なお、各比喩表現の定義は、以下のサイトから引用しております。

www.nihongo-appliedlinguistics.net

直喩（明喩、simile）

定義

直喩は、「～のような」「～みたいな」などの直接的な表現を使って、わかりやすく例える方法です。

例文

商用本番系システムで、悪夢のような障害が発生したとの連絡がきた。
関係者全員、石のごとく身じろぎもしない。流れる冷や汗はまるで滝のようだ。

　これは特になじみのあるものですね。動かざること山のごとしとか。
　障害対応お疲れ様です。

隠喩（暗喩、metaphor）

定義

隠喩は、「～のような」「～みたいな」などの表現を使わずに、あるものを別のもので例える方法です。

例文

このプロジェクトは、まさにデスマーチだ。それに参加する我々は、ソルジャーである。

　言いなれている「デスマーチ」ですが、実際には死の行軍はしていない（していないことを祈る）ので、これは隠喩ですね。

諷喩（allegory）

定義

諷喩（ふうゆ）は、例えだけを示し、例えられているものが何かを推測させるものです。

例文

テスト自動化の銀の弾丸が見つかったよ。

　隠喩と似ているのですが、隠喩の例で「デスマーチ」が「プロジェクト」の比喩であることを明示しているのに対し、諷喩では何を喩えているのかを明示しないという違いがあるようです。
　銀の弾丸（Silver Bullet）も魔法の杖（Magic Wand）も、「問題を完全に解決するもの」という意味が共有されていますね。
　おそらく、パーフェクトな自動テストツールが発見されたのでしょう。うらやましいことです。

　考えてみると、プログラムに入り込んだ欠陥を「バグ」というのも、もともとは諷喩なのかな。そしてそのバグを「ドラゴン」と呼ぶのは、諷喩の諷喩だ。

konifar.hatenablog.com

提喩（synecdoche）

定義

提喩（ていゆ）は、上位概念を下位概念で、または下位概念を上位概念で表す方法です。

例文

ネットワークの疎通確認するから、アドレスのリスト作っておいてね。

　ここでいう「アドレス」は、地理的な住所やメールアドレスではなく、IPアドレスのことでしょう*1。
　また、ネットワークの文脈で「IPは？」と聞かれたら、その「IP」はまず、Internet Protocolというプロトコルそのものではなく「IPアドレス」のことであって、知的財産*2でも、海外調達*3のことでもないでしょう。　

換喩（metonymy）

定義

換喩は、何かを表現するとき、その事柄と隣接しているもの（深く関係しているもの）で置き換えることです。

例文

バグを再現させました！

　元ツイートが実は、この換喩だったということで・・・。

　バグは（おそらく）プログラムの中にじっとして潜んでいたはず。この人が再現させたのはあくまでも、そのバグによる「事象」の方でしょう。
　けれど、「非再現のバグ」なんてそんなに違和感ない表現ですよね。

活喩（prosopopoeia）

定義

活喩は、無生物を命があるもののように扱うことです。

例文

隠していたバグがついに牙をむいたようだ。本日が最終出勤日となります。

　怖すぎる退職エントリー。

*1:MACアドレスなどセンもあるのか？ そういえば、ARP（Address Resolution Protocol）のことを、謎のコダワリで「アルプ」って発音していたネットワークエンジニアの先輩、元気かな・・・。NECのことを「ネック」って発音していた大学の先輩もいた・・・。

*2:Intellectual Property

*3:International Procurement