わかる。。
生成AIさんの実装が完了し動作確認しました。とかもまだ信用できない
フックやらCIやら何かしら外部チェックは前提として、問題がないと言える根拠まで出してもらう
「動作確認しました」の中身が、人によって違いすぎる問題。
動画のコメント欄が報告する側とされる側の実体験で埋まっているのでまとめます。
いいねが一番多かったのは、2件並びました。
「『このライブラリは、別のプロジェクトで動作確認ができています』という発言を聞くと、期待が持てそうだくらいの認識に留めています」
「企業側から『動作確認はしています。問題はありません』という報告があり、2年ほど致命的な不具合が直らなかった。実は企業側の下請け企業のモジュールに不具合があった。こちら側の最終動作確認も、その方法を文書に起こさず、現場のユーザの使用感だけでやってしまった受注元の責任があった」
「動作確認しました」の信頼度が、2年分の実害つきで示されています。
次に多かったのが、評価制度への恨み。
「ろくに動作確認しない人が『仕事早い』と評価される理不尽な職場の多いこと」
確認を省いた人が速く見えて、確認した人が遅く見える。
この構造がある限り、報告は薄くなる一方です。
対策として自分の言葉を変えた方。
「だから私は『動作確認しました』は言わない。『とりあえず1回動きました』で報告上げる」
これは正直で良い報告だと思います。
受け取る側の対策はこちら。
「規模によりますが『テスト設計書出せ』ということにしてます。設計書が出てきたら内容確認し、正常系と異常系の抽出試験をして、それが通ったらテストが行われたことを信頼する」
「だからテストケースというものが必要になる。未実施ケースのものは未実施理由と共に残しておく。まあ、ほぼザル承認されるんですけどね。他のやつが確認するからヨシ!前のやつが確認してるからヨシ!2人も承認してるからヨシ!」
正しい仕組みを作っても、運用で現場ネコになる。
言葉の定義が会社ごとに違う話には、実務的な処世術が届いていました。
「初めての現場では『こいつは馬鹿なのか?』と疑われるくらいに細かく具体的に聞き込みますね。『これくらいは分かりますよね?』と聞かれたら、『別の現場では違う解釈でした』と返答してます。同じ現場に長くいる人ほど、この傾向が強くなります」
「ユビキタス言語の実現の難しさを、IT現場自らが犠牲になって教えてくれているのだ!」
QAエンジニアの方からは、想定外への向き合い方。
「異常値でクラッシュすることが稀によくあって修正させます。ある特定の人に『そんな使い方は想定していない』と怒られるんですけど、『想定していない入力があったら動作を止める仕様書を書くのがあなたの仕事では?』と返しています」
確認する側のマインドについては、先輩世代の言葉が2つ。
「当時の部長が『必ずなにかおかしい部分があると思って動かすこと』って言っていました」
「後輩によく言った言葉『自分で作ったコードをテストするときはジキル博士からハイド氏になれ』。自分の作品にはどうしても『わが子可愛さ』が出るからだ。さあ、ここにAIが入ってくる。後輩に残す言葉は『AIは詐欺師と思え。最初は微笑みながら近づいてきて、信用して油断するとガッツリやられるぞ』だろうな」
そして一番短くて、一番本質的だったのがこれ。
「動作確認済み≠テスト済み」
最後に、動画で鉄道の指差喚呼の話をしたので、当然こうなりました。
「┏(`・ω・´)σ ヨシ!」











