新旧比較のミスディレクション

ミスディレクション

「観客の視線や思考を事実とは違った方向に向けさせる」手法。マジックやミステリー小説に使われる手法。漫画「黒子のバスケ」でおなじみの手法。ミステリー小説の場合は、「ミスリード」といった方が自然かも。

ミスディレクションは三つに分類されます。

①サイコロジカル(心理的)ミスディレクション
②フィジカル(身体的)ミスディレクション
③タイム(時間)ミスディレクション

・・・って、なんでこんな書き出しなのかというと、ミスディレクションと障害原因がつながった感じがして、特に、①と②のミスディレクションにハマったのだなぁと思うところがあり、ちょっと興味深かったのでご紹介。③タイムミスディレクションのネタがあると投稿ネタ的にはもっと良いんだけれど・・・。

サイコロジカルミスディレクション

エンドユーザ：「この前のAシステムのコード追加修正で、
Aシステムに入力した「△△金額項目」がBシステムの「□□帳票」に印字される筈なんだけど、
印字されていない。なんで？」

私：「確認いたします。」

私：「確かに印字されていない。Aシステムを調べていくと・・・
あれ？この間●●さんのテスト結果レビューしたけれど、
そこで「■■項目」のコード追加してた。でも、このif文の条件分岐だと印字されないじゃん。」

●●さん：「ごめん、ごめん。この前の「■■項目」のコンボボックスコード追加で修正漏れ。」

私：「・・・」

遡ること数日前。
Aシステムのとある項目に新たに運用するコードを追加するというもの。Web画面の入力チェックを追加、変更して、コンボボックステーブルに新コードのレコードを追加して・・・後続のBシステム向けファイルIFもコード追加があるので、関係者にも連絡してと、修正箇所が多岐にわたる案件。

●●さんの他にレビューアが2名。レビューアの内の1名が自分。

●●さん：「・・・ということで単体テストの結果は以上です。」

私:かれこれ1時間。まだ続くのか？！・・・

●●さん：「現状保証は、後続Bシステム向けファイルの新旧比較で行いました。
**立ち上げ以降全トランザクションデータがありましたので、
それで新旧比較を行いました。**これがdiff結果です。
**今回のコード追加で影響を受けた箇所が差として出ています。
余計な影響は出ていません。**」

レビューア、私：「・・・差がｎ箇所と。問題なさそうですね。OKです。」

レビューイ、レビューア共に色々問題ありなのですが(影響調査はどうだったのか？とか)、ミスディレクションになっているところはと言うと・・・。

「立ち上げ以降全トランザクションでテスト」という言葉から、レビューイ、レビューアの皆の心理がどうなったか？「過去データ全部使っているんだから、現状保証できている」と安心してしまった。(本当は「■■項目」に新コードを追加した結果、別の項目との関連で修正漏れがあって「△△金額」が計算されないのに)。

「余計な影響は出ていません。」という言葉も、「余計な差が出ていない＝余計な修正をしていない＝現状保証できている＝安心」というサイコロジカルミスディレクション。

フィジカルミスディレクション

さらに、フィジカルミスディレクション(視覚に作用)もありました。
それはdiff結果です。視覚的に差が見えるので、その差の部分に誘導されてしまいました。
本当は、差がでる項目があった筈なのに、差が出たところだけを一つ一つ確認してOK,NGを判断してしまいました。

ミスディレクション例

これらのミスディレクションは、形を変えていろんな所に潜んでいます。

例えば、テスト機から本番機に3件データ移行。データ移行後の新旧比較のdiffで3件のレコードが差として出て移行OKとしたが、その後、ユーザ指摘で障害。なぜか？そもそもテスト機から抽出したデータが間違ったレコードだったから。

例えば、10個のソースのうち5個を修正。本当はその要件を満たすには、6個目も修正が必要。
diffの結果、5個差が出る。レビューイは余計な修正して無いと言い、レビューアは5個の差が出ている結果を見せられて、それに引きずられてOKと言ってしまう。

振り返り

「立ち上げ以降全トランザクションでテスト」「余計な影響は出ていません。」という言葉から、皆が安心してしまいました。
「差が出たところだけ」を見て、皆が安心してしまいました。
どちらも、「聞く」や「見る」から「始まっている」ところに問題がありそうです。
「無防備な状態」で聞いたり、見たりしてしまうと、それにロックオンされてしまい、別のルートがあるのに気づかず、結果しくじっています。

教訓

では、どうするか？見落としとか完全に防げないので100点取れないですが。。。

①「予め、期待値=合格条件を持つこと」

です。当たり前すぎるけれど、これです。「テストファースト」といってもいいかも。

レビューアは、結果を聞いたり、見る前に、「期待値=合格条件を持つ」ことができれば気づくチャンスが生まれます。

レビューイも「予め、期待値=合格条件を持つこと」ってから、影響調査していれば、その後の実装漏れが防げたかもしれません。

②「期待値=合格条件と結果で2回レビューする」

何もかもが終わって最後に全部の結果をレビューすると、その結果がミスディレクションになることもあります。「期待値=合格条件」が正しく定義できているか1回目のレビューを行う。「結果が期待値=合格条件通りか」2回目のレビューを行う。

です。