モデルと作戦盤
モデルと作戦盤・ソフトウェアテストアドベントカレンダー 2018/12/23編
にし やすはる
この記事は「ソフトウェアテスト Advent Calendar 2018」の23日目記事です。22日目の@mty_mnoさんからバトンを受け取りました。
実はこの記事、姉妹編の「ソフトウェアテスト #2 Advent Calendar 2018」がまだスカスカだった頃に埋め草で書いたものなんです。ところが、書いたらすぐにドシドシみんな登録し始めましてね、あれよあれよという間に全日登録されてしまったわけです。まぁそれならそれで業界の健全な発展を考えると素晴らしいことでしかないため、オレのクソみたいな埋め草なんぞは闇に葬ろうと思ったわけですよ。
そしたらWordPressの設定を間違えて一般公開にしてしまい、間の悪いことに@akiyama924がそれを偶然読んでツイートしやがったことによって、存在が知られることになりました。もちろん即非公開にしたけど時すでに遅し。だって埋め草のクソ記事だぜ。そしたらソフトウェアテスト界のガンジーこと@ToshiManaPlus1から載せろとのリクエスト。ガンジー物好きだなオイ。
そうこうしてる間に#1も#2も小ネタも完売したので放っておいたら、アインパメちゃんがリザーブしてた#1の12/23分を頂けることになったので、お恥ずかしながら載せてみるか、と思うに至る。なんか今年も力作が多いので、箸休めにどーでもいい記事が一つくらい載っていてもいいかな、と思った次第。書き直そうかな、とも思ったんだけど、そのまま載せることにした。しかも@akiyama924が内容を読んだ上で「Hほげほげ法は作戦盤じゃなくて手順書」とツイートしやがったので、いつか決着を付けねばならぬは人のなさぬなりけり。
まぁそんなわけで、21世紀になって目にすることも珍しい阿部寛ばりの<hr>タグの先に埋め草をそのまま載せておきますので、連休がヒマでヒマでしょうがない人は鼻クソでもほじりながら読んでやってくださいませ。 m(_)m
23日目のアドベントカレンダーはテストラジオのパーソナリティで有名な@okauchiwaniさんです。お楽しみに！
モデルと作戦盤・ソフトウェアテストアドベントカレンダー#2 2018/12/某日編の草稿
にし やすはる
テストやQAは一般に、WordやExcelで何か手順書を書くものという相場があるらしい。試しに、皆さんの組織で用いられる手順書や社内標準、過去の成果物などをチェックしてみてほしい。.doc(x)や.xls(x)という拡張子のはずだ。まぁ皆さんが「TDDこそテストであるキリッ」と主張されるのであればその限りではないが、別にこの後の議論は拡張子が.cでも.cppでも.javaでも.pyでも、何ならCOBOLでもアセンブラでも同じである。何が同じかというと、それらを書く際に多分モデルのようなものは描かないだろう、という点において同じである。オレはModel-based testingのプロだからモデル描いてるぜ、という方も、話の骨子は似たようなものだったりするので途中を飛ばしても構わないから結論から読むとよいだろう。
手順書というのはなかなか罪作りな奴で、二つの意味で皆さんの心を捉えて離さない。一つは、手順書があるとそれに洩れなく従いたくなるという気持ちが発生する。洩れ？漏れ？モレ？初めてこの「洩れ」という感じを使ってみたが、漏れよりも洩れの方がモレが少ない感じがして、一生懸命頑張ったのにそれでもモレてしまったという悲しさを引き起こしている感じがして大嫌い。まぁそんなことどうでもいいや。空いてるアドベントカレンダーを埋めたくなったという理由を隠れ蓑に、実はやらなきゃならない仕事から海外出張先のオーストラリアで逃避するという最悪の心理的危険を、珍しく技術的にあんまり内容が濃いわけじゃないエモい文章を書くことで見ないようにしているだけだからな。砂漠で天敵が来たら頭だけ隠すラクダみたいなもん。こんなことしてると確実に木曜日にStuart Reidにコロサレルけど、一度書き始めてしまったので使命感も逃避行動に拍車をかけている。これがポジティブフィードバックという奴か。心は超ネガティブなのにな。どうでもいいけどコロサレルってエルサレムに似てる。そう書くと何だか深遠に見えるから不思議だ。
第2段落から脱線とは先が思いやられる。でも別にいい。速攻で埋まったソフトウェアテストアドベントカレンダー本体を尻目に一向に埋まらないアドベントカレンダー#2の哀しみを分かち合って、誰も書く人がいない日が訪れる地球最後の日的な恐怖をほんの少し先送りするだけの文章だからだ。というよりも、現実逃避で書き始めた文章から現実逃避しているという再帰的現実逃避を皆さんは目の当たりにしている。こんなクズなかなかいないから、こんなクソ文章を読む機会もなかなかない。皆さん運がいい。クソ忙しい年末の貴重な時間をムダにしているのだから。
何の話だっけ。そうそう、手順書が罪作りだって話。手順書があると従いたくなる。皆さんの心の中に潜むマゾヒスト性、もしくは被緊縛願望を刺激するわけだ。手順書に従う度に、なんだか縄目がちょっとずつ肌に食い込んでくるような、痛いような抱きしめられているような、抗いたいような安心するような、そんな捕まった女潜入捜査官のような気持ちになる。共感したかい？共感した人はAVの見過ぎだから、今すぐ動画サイトのサブスクリプションを解除しよう。そしてもう一つの意味で手順書が皆さんの心を捉えて離さないのは、皆さんの心の中に潜むサディズム性、もしくは緊縛願望。手順書の項目を一つ一つ書きながら、なんだか心の中の肉奴隷に一周ずつ縄をかけて絞り上げていくような、支配欲を満たすような背徳感を感じてしまうような、縄に力を込める自分の手の痛みを通して相手の肌の痛みを感じ取ってしまうような、そんな女潜入捜査官を捕まえた麻薬王のような気持ちになる。共感したかい？共感した人はAVの（以下略）。
手順書は奴隷を作るが、安心も与える。自分が何か他に頼る対象を持っている時、もしくは自分自身を頼れる時は、奴隷は手順書から逃れようとする。しかし自分が何も他に頼る対象を持っていない時、奴隷は信者に変わる。この世に何か唯一絶対の正解があってそれに従っていると幸せになるのであれば、それに従いたくなるのが人間というものではないか。例えその正解が他人を不幸に陥れるものであったとしても。
テストやQAを生業とする人は、どうも暗黙的にこのことを知っているのだろう。だからすぐに手順書を作ろうとする。手順書を作るという行為にすがり、作った手順書にすがる。そして他人である開発者にもすがることを強制する。なぜならそれは、宗教だからだ。もし開発者がすがることを拒否したらどうなるか。自分が信じるものを冒涜したものとして徹底的に攻撃すると同時に、もしかしたら自分自身を頼れる強い心を持つものに激しく嫉妬する。そして頑なになり、意固地になり、周囲もろとも煉獄の業火で焼かれてしまう。残るものは灰だけである。
手順書には、手順書を作る手順書がある。手順書を作る手順書のことを方法論と呼んだりする。方法論と聞くと何だか難しそうだが、どうということはない。手順書を作る手順書に過ぎない。もっとも方法論を構築した人は例外なく手順書と呼ばれることを嫌がるけどな。ともあれ方法論は、手順書としてのカッチリさ（方法論としての決定性）の多少はあれど、手順書と同じ性質を備えている。どんな性質かって？分からない人はこのコラムを最初から読むがいいわオホホホホ肉奴隷めピシッ。従うと安心する、という特性である。
世の中にはモデルを用いる様々な方法論がある。開発方法論はあまた星の数ほどあろう。テストでは手前味噌ながらNGT/VSTeP。システム安全性であればSTAMP/STPAなどがそれにあたる。ちなみにソフトウェア安全性という用語を使う人がいるが、ソフトウェアは物理的実体を持たないので人を殺したり怪我させたりしない。よってソフトウェア安全性という言葉は論理矛盾を起こしている。ソフトウェアがシステムのごく一部のふるまいしか担っていないのであれば、機構部位で安全性は担保できる。したがって厳密に使う時は、ソフトウェアが多くのふるまいを規定するシステムの安全性、と言うべきだよワトソン君覚えておきたまえ。NGT/VSTePではテスト観点図、STAMP/STPAではコントロール構造図といったモデルを用いる。しかしcontrol structureってすっげぇ一般的な英語だよな。ワープロに"Word"って付けちゃうくらいのオレオレセンス。日本人はそのオレオレセンスを微妙に回避するために、一般的用語としてはきっと制御構造となるところを、カタカナにして固有名詞っぽくするカウンターセンスを存分に発揮する。だからコントロールストラクチャー。チャーだぞチャー。ストラクチャじゃないんだぞ。IPAという雲の上の国の組織がチャーって言ってんだからチャー。ランチアストラトスじゃなくてチャー。日本で一番ギターが上手い人チャー。ちなみに二番目はゴンチチな。（諸説あり）
日本人のカウンターセンスは嫌いではないが、このコラムではあんまりチャーの話を続けたくないので折衷案を採用する。STAMP/STPAのコントロール構造図では制御関係やガイドワードが、NGT/VSTePではテスト観点という概念の抽象具体関係が、それぞれ描かれる。言い換えると、STAMP/STPAは制御関係やガイドワードの手順書であり、NGT/VSTePはテスト観点と抽象具体関係の手順書であると言える。提案者たちは虫酸が走るほど嫌がる表現だろうけど、真実だから仕方が無い。STAMP/STPAは手順書だぞナンシー。やーい手順書作ってやんの。どうでもいいけどナンシーって書くとシドとナンシーみたいでカッコイイな。実際のところNancy Leveson（STAMP/STPAの提唱者でMITの偉い先生）も結構パンクだけどな。カッコイイぞ。ちなみにオレに向かって「NGT/VSTePって手順書ですよね所詮」とオレの目の前で少しでも口にしやがったらその場でギッタンギッタンのバッタンバッタンにしてやるので気をつけるように。
HAZOPやFTA、FMEAなどのシステム安全性の技術を修めた人は皆STAMP/STPAの心もとなさを口にする。皆さんの周りにキラキラした目をして1オクターブ高い声で「STAMP/STPAって最高ですよね！」と尻尾を振る奴がいたら無視して構わない。もしくはこのコラムを100回音読させろ。NASAがうんちゃら米軍がどうちゃらトヨタがほにゃららと言われても、おいおいこんな雑な方法論で洩れなく安全性が確保できるのかよ、と心配になるのがまともなエンジニアである（初見ね）。同様に、Hほげほげ法やゆもふがふがメソッドなどの他のテスト方法論を修めた人は皆NGT/VSTePの自由度の高さに不安を覚える。テスト観点って何だよ定義を教えろよ。第1レベルの観点（全体像）はどう決めればいいんだよ。抽象度を落とすって何だよ。子観点は網羅できてんのかどうやったら分かるんだよ。それに比べてラルフほげほげや論理的ふがふがはオレたちに安心を与えてくれる。あんな風にできないのかこのクソ白髪コンサルがっ！みたいな。うんできないごめん。それはオレの完全なる力不足であり、他の方法論提唱者の方が優れているからに他なりません。なのでここからはSTAMP/STPAの話だけします。
この件についてNancyと話したわけじゃないから分からない。片平さんと話した時に感じた表現なんだけど合意できてるかどうかも分からない。だから正しいことを言ってるというエビデンスなんかない。これはオレのモデリングやコンサルティングの経験から感じたポエムに過ぎない。でもね多分、STAMP/STPAはあえて自由度や拡張性の高い方法論に留めていて、手順書のレベルには落とし込んでいないんだよね。やろうと思えば適用ドメインを何らか分類してかなり細かい手順書レベルまで落とし込むことはできると思う。でも大事なことは、そこじゃないってこと。「あえて」自由度や拡張性を高く保っているってこと。
そう言われると手順書信者は叫び出すと思うし暴れ出すと思うし血管ブチ切れると思う。George Boxって知ってるかな？イギリスの統計学者。時系列解析におけるモデル同定のBox-Jenkins法のBoxさんと言えば分かるね。彼はこう言ってる。"All models are wrong".そう、モデルってのは常に間違ってる、ってこと。まぁこう書くと英語厨が「それはall～not的意味だから部分否定で～」とか言い出す気がするので、受験英語大好きな人は調べてみるといい。この構文は全部否定。大事なことだからもう一度言う。モデルというのは常に間違っている。どんなモデルであっても。
数学や物理学だととても分かりやすく直感的である。モデルというのは常に近似である。Boxは1molの理想気体の状態方程式PV=RTを例にしたようだが、プラモデルだってモデルルームだってファッションモデルだって近似である。読者モデルなんてモデルのモデルすなわち近似の近似だから真実からえらい遠いところにいるぞ。しかしソフトウェアの世界ではその直感が通じない。なぜなら、モデルはプログラムすなわち実行コードを導き、コンピュータはその実行コードどおりに動くからだ。言い換えれば、モデルは正確にコンピュータの動作を写し取っている（厳密には実行コードがモデルを写し取っているんだけどね）。従ってモデルが実世界を正確に写し取らないと、コンピュータは正しく動作しない。したがってモデルが近似なんてありえない。Q.E.D.
ここって結構、理系の中でもスタンスが分かれるところなんだと思う。だからかもしれないが、アメリカの大学の情報系のカリキュラム標準では、工学的常識（ちょっと言いすぎかな）という講義がある。ひっくり返すと、情報系の学生や先生には工学的常識が欠けている傾向があるわけだ。これは情報系の先生に聞かせると確実に怒られるやつだからナイショね。
そう、モデルは近似なのだ、どんなに方法論を手順書に近づけたとしても。すなわちSTAMP/STPAにおいてどんなに詳細で膨大な手順や知識ベース、実例を作ったところで、そこから作られるモデルは近似に過ぎず、不安全な部分が必ず存在するわけだ。これは怖い。考えれば考えるほど怖い。どんなに一生懸命やっても安全を「保証」することはできないのだから。どんなに一生懸命やっても自分の関わったシステムによって誰かが怪我をしたり命を落としたりする。それは自分かもしれないし、自分の大事な誰かかもしれない。そう考えると怖くてたまらない。何かにすがらずにはいられない。
でもそんなSTAMP/STPAを盲信する程度の技術力や経験の安全技術者は、何かを「保証」するということを軽く考えすぎている。どこか遠くの救世主が考えてくれた何かに従っておけば、不安全なところを洩れなく指摘して安全を保証できるに違いない。だからその何かである手順書は細かく書いて欲しい。なぜなら、正解がないことを知ってるから。すがりたいから。ユーザに安心を提供するのではなく、自分自身が安心したいから。手順書の奴隷に成り下がっているから。そして手順書の奴隷は、自分が盲信して作った成果物を盲信することを強制する。盲信した結果を実際に見せろと迫る。エビデンスという名の踏み絵によって。
違う。違うよきっと。STAMP/STPAは手順書じゃない。あえて自由度や拡張性を高めているんだ。それはきっと、安全エンジニアを信じているから。そして「保証」という行為は結局のところ、開発エンジニアが劣った考えをする可能性よりも、安全エンジニアが優れた考えをする可能性を高めることに他ならないと分かっているからだ。安全エンジニアが劣った考えしかできなければ、どんなに厳密にトレーサビリティを確保してもSPOF（単一故障点）分析を行っても膨大なレビューやテストを行っても必ず事故は起こる。大事なことは手順書に従うことや従わせることじゃなくて、安全エンジニアに優れた考えをしてもらうことであり、その環境をつくることなんだ。
作戦盤、って知ってるかな？団体スポーツを経験した人は、どこかで目にしたことがあると思う。競技固有の白線の引かれたコートやフィールドを模した鉄板と、選手を模したマグネットのこと。試合中の作戦タイムの時に監督やコーチが作戦を指示したり、練習中に選手同士でフォーメーションを考える道具である。英語ではTactic(s) boardと言ったりCoaching boardと言うらしい。ちなみに、消える魔球が投げられる野球盤のことではない。発想が昭和だなオレ。
STAMP/STPAのコントロール構造図は、きっと作戦盤なんだと思う。監督やコーチが一方的に作戦を支持するための作戦盤じゃなくて、選手も監督もコーチもみんなで、こいつが動けば敵がこう動く、そしたらあいつはこう動けばいい、でも敵がこう動いたらどうする、あーだこーだどーだこーだとケンケンガクガク議論する作戦盤。皆が自分の考えをビジュアライズしてリアライズしてシミュレートしてエネミーにリアクションしてディスカッションをファシリテートしてトゥギャザーしようぜ的なルー大柴的な。皆が自分の考えを作戦盤の上に図示し盤上で敵味方の動きをダイナミックに検討することで、どんどん新しいアイデアが出てきて勝利の可能性の高い作戦が創られるような。そういう作戦盤なんだと思う。
モデルは常に間違っている、とするならば、作戦盤で創ったモデルもまた間違っている。そう、間違っている。それでいい。まず僕たちは、モデルは常に間違っているということを受け入れなくてはならない。そして作戦盤を使い、自分たちの知恵や発想、想像力の限りを尽くして考えなくちゃいけない。開発エンジニアが考え落としたところ、考えが及ばなかったところ、到底考えるわけがないところ、ありえないと最初から考えなかったところ、ありとあらゆるところに考え至るように議論しなくちゃいけない。安全を保証しきった自信は正直無いけれど、開発エンジニアよりも考え尽くした自信はある。そういう状態を目指さなきゃならない。
そしてもしそれでも事故が起きたなら、それはとてもとても不幸なことで、自分たちの技術力の低さを痛感し、二度とそんなことを起こさないように原因を分析して改善しなくてはならない。その話はまたいつかどこかで。
テストも同じ。手順書はモデルの一つであり、方法論だってモデルの一つである。したがって、あらゆる方法論は常に間違っているし、あらゆる手順書は常に間違っている。だから方法論にすがっちゃいけないし、手順書にすがっちゃいけない。その方法論を使って十二分に検討しきった自信は持てるのか。開発エンジニアが考え落としたところ、考えが及ばなかったところ、到底考えるわけがないところ、ありえないと最初から考えなかったところ、ありとあらゆるところに考え至るように議論したか。手順書に書かれていないところは無いか、手順書は本当に正しいのか、手順書を作る時の前提は今も成り立っているのか、いつも考えながら仕事をしなきゃいけない。これはしんどい。すがれない。気が抜けない。だからこの、高度に人間らしい仕事に集中するために、人間らしくない単純（にできる）作業は自動化しなきゃいけない。その話もまたいつかどこかで。
モデルは作戦盤。手順書は作戦盤。方法論も作戦盤。ついでに言えばプロセスも作戦盤。大事なことは、開発エンジニアより優れた考えをするために考え尽くしたという自信を持つこと。自分たちの外に正解なんか無いって思い知ること。誰かにすがっても自信は持てないって実感すること。「保証」は、結局のところ自信を持つことだってこと。
もう十分現実逃避したし、なんかこう飽きてきちゃったからもういいや。コラムっていいね。いつでも好きなときに終われるから。別に昨日からバトンをもらった覚えはないし、別に明日にバトンを渡す気はないけど、何かよいバトンが知らないうちに渡ってるといいな。あれ、埋まってる…。このまま埋まるとこのポエム公開されないぞ…。まぁいいか別に現実逃避の産物だし…。
おしまい。