現行データを過信しない
10件ほどプロジェクトの中身をチェックしていると１つや２つ存在しているのが
「現行の生データを使ってテストをすれば品質が担保される」
という発想のリーダーやマネージャー。
この言質からわかってくるのは「あー…この人は論理性が低いんだなー」ということ。もちろん可能性だけで言えば、セリフ通りの品質担保が可能となるケースもあります。ただ、逆にそうでない可能性も必ずあるんです。100-0ではないということ。
つまり『リスクがある』ということです。
しかも、そのリスクも決して「低い」とは言えません。
リスクが残ったままにプロジェクトを進行させる行為というのは、品質保証の観点からはオススメできません。論理的にリスクが無いと証明することを品質保証というからです。
「リスクが低い」
という話をするとついつい
「発生確率が低い = だからそこまで心配する必要はない」
と考えてしまいがちなのは日本人の悪い癖ですね。
ここでもお伝えしていますが、リスクとは
発生する確率 × 発生時の影響度
で算出されます。
そして日本人はその風土、文化から「万が一」という言葉があることからもわかるように「確率を下げれば安全」と思いがちです。ですが欧米では逆です。万が一でも発生してしまうと致命的な影響が出るのであれば確率をゼロにするか、影響度を下げないと安心ができないと考えるのです。
実際、日本人のその根拠のない自信によって、東日本大震災の際、福島原発は津波に対する万全の態勢が整えられていませんでした。また、そうなる可能性がゼロではないことを考えず、東芝がアメリカの原子力事業で7000億円を超える巨額損失を計上し、一気に経営危機に陥ったのもそうです。
「可能性が低いなら、懸念する必要はない」
と言っているうちは品質を語る資格はありません。品質を語るうえで重要となるのは
・致命的な問題が起きないようにすること
・可能性をゼロにできないなら致命的とならない対策を講じること
です。
これが理解できないうちはおそらく品質を保証することはできないのではないでしょうか。まぁ、私もそうと理解したのはやはり震災(2011)前後…いやリーマンショック(2008)前後だったかもしれません。昔から理解していたわけではありませんでした。ちょうど、トラブルプロジェクトの支援や立て直しに一番奔走していた時期でもあったため、そういう理解に自ずと辿り着いたような気がします。
さて。
では「現行の生データ」を使っているにもかかわらず、品質が保証できない理由ですが、
そもそも現行にあるデータが、
システムのインプットデータとして
全パターンを網羅しているとは限らない
ということを考慮していないことが問題です。
システムにはバリデーション等の機能ではじいてくれるわけでもなく、受け入れてしまえる値の範囲というものがあります。
たとえば、『年齢』という項目があったとして
現行システムの仕様 ：整数型３桁であればなんでも入力可
現行システムのデータ：15～75までのデータが蓄積されている
となっていた場合、0歳や999歳などのパターンは原データからでは検証できません。さらにいえば、何件あるのか知りませんが原データの全件をテストしているわけでもないでしょうし、さらに絞り込まれることを考えれば、よりリスクの発生確率は上昇するものと考えられます。
それに、現行の原データを全件用いて検証したところで、そこから保証できるのは
「現行データのパターン分だけ」
でしかなく、次期システムの入力仕様のなかにそれ以外のデータパターンも許容するしようとなっている場合、結果的に次期システムで障害が発生する可能性が残ります。今後想定外のパターンが混入する可能性が一切考慮されていないわけです。
それでは品質が担保できているシステムとは言えません。
品質を担保したければ
論理的に品質が保証できるパターンを洗い出し、
それらのパターンを漏れなく実施する
しかありません。
そのことを考える力量が無いのか、あるいは考えたくないのか、どちらにしても抜けもれなく大丈夫だという根拠を証明する論理性を持ち合わせていないまま、経験則や感覚に頼って判断してしまったことがうかがえます。
仮に原データを多用するにしても、事前にデータ調査をさせていただいてデータパターンを洗い出して、抜け漏れがないことを確認する等しておかないと「原データだけチェックすれば十分」という発想は危険です。
昨今では、情報セキュリティや個人情報保護の観点からも、原データをそのまま借用させていただく…というのも難しくなりました。
第三者提供に関する法律を理解していないと法令遵守違反となりかねません（というか、めちゃくちゃ面倒くさいんです）。ＩＴエンジニアはシステムを用いる業務仕様や業務に関わる法律についても詳しく調べておくべきだと思うのですが、「モノづくり」だけが仕事だと勘違いしている人も多く、法令や規格に疎い傾向があります。そのため、よくわからないまま徐々に、探り探り「より楽な方」へとスライドしていきます。
元々、顧客の「（効率化を図り）楽をするため」「便利にするため」を実現するためにＩＴを駆使する職種なわけですから、常により楽な方へという思考が根付いてしまうのも仕方がないとは思いますが、同じ発想をそのまま用いることで顧客からのデータを借用する際などで案外マズいことをしていたりするんですよね。
とはいえ、顧客の原データを調べる方法はいくらでもあります。
一番手っ取り早く"楽"なのは、調査用のDMLを作成し、現行運用の担当者に実行していただき、その結果をいただくことです。
SELECT DISTINCT(項目A) FROM テーブル名;
SELECT DISTINCT(項目B) FROM テーブル名;
SELECT DISTINCT(項目C) FROM テーブル名;
…といったように、各項目ごとの重複行をまとめるSQLを実行してもらうわけです。個人を特定できる情報にしない単位で抜き出せば困りません。複数項目の組み合わせにすると情報量が増えてしまうので、単項目ずつ実施していただく方がいいでしょう（まぁだからこそDMLなんですけど）。
特定の文字種が存在しないか調べる場合などにはCOUNT関数で件数が0件かどうか調べるだけでも十分です。
私がエンジニアをしていた頃には、テーブル定義書を読み込んで自動的にDMLを作成するマクロとかちゃちゃっと作ってました。そうやって原データのパターンでどれだけ品質が保証できるかを調べ、不足パターン分は事前のテスト工程などで検証するようにするわけです。
こうして、実際にシステムが許容する「範囲」のなかから品質が保証できる最適なパターンおよびパターン数を検討して実施しないと、本当の意味での機能せ品質は保証することができません。
ゆえに、「現行の生データを使ってテストをすれば品質が担保される」という発言を聞くたびにモヤモヤとしてしまうんですね。
なまじ相手がリーダーやマネージャーにもなるとそれなりにプライド？があるため、いくら説明しても真摯に聞いてくださる方は決して多くありません。理解なんてもってのほかです。事実、これまでにまともに取り合ってくださった方は皆無でした（その背景には、すでにスケジュールの大半を使い果たしてしまっていたり、すでに次工程に進んでしまっていたりして、後戻りができないから…というのもあったのでしょうが）。
まぁ実際のところ、望んでいるわけではありませんが結果としてあとだしジャンケンとなってしまうケースでは、聞き入れられるとも思っていませんので、ますますモヤモヤしてしまうんですけどね。
だからこそ
以前説明していたような開発モデルを、一部の技術要素向けだけでなくソフトウェア開発全体で導入したいと10年以上も前から考えているわけですが、なかなか同意をいただけないみたいです。
いずれそういう時代が来るのかなー。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。