身近なもの、わかりやすいものに置き換えて意識／認識を深めるという考え方

このたび、城を建てました。

今、その城に対して敵が攻めてきています。
敵の数は、城の規模に比例します。

そしてあなたが持てる武器はあなた自身の能力に比例します。

あなたはどのような戦い方で防ぎますか？

と問われているとします。
そして頭の中で置き換えてみてください。

「城」は「システム」です。

「建てる」というのは、新たに「構築する」ことです。「設計する」「実装する」と置き換えてもいいかもしれません。堅牢な城（システム）にできるかどうかは、その城の設計のレベルに依存することでしょう。

「敵」一人ひとりは、対応するべき「検証」ケースパターン。城自体が堅牢であるかどうかを確認する要素…と言い換えてもいいでしょう。

「総数」は検証に要するケースパターンの「総件数」とします。

打ち倒せずに城までたどり着かれたら「不具合」となります。
守り切れなければ「トラブル」です。

あなたが持てる「武器」というのは、品質に対する知識やスキルです。

システムの規模が大きければ大きいほど、複雑であればあるほど、検証すべきテストケースパターンは当然ながら増えます。そして、それを防衛するメンバーの数やそのメンバーの質によって、防ぐことができる…すなわち城に辿り着かれる前に倒せる敵の数が決まると言っていいでしょう。

もちろん全員倒す必要はありません。要点を絞って指揮官クラスの敵を倒せばその周囲の敵（テストケース）は消化させることができるでしょう。いわゆるテスト技法（同値分割、境界値分析、直交表やオールペアなど）によって論理的にテストケースを圧縮すれば必ずしも全件テストを実施する必要は無くなります。

私は…まぁテストにしてもそうですし、レビューにしてもそうなのですが、ソフトウェア開発の検証と言う作業は冒頭にあったような城攻めに対する防衛線をしているイメージを持っています。

常にそう問われていて、自分自身が防衛する中でどのような役割を担うかによって、どのようなスキルを身につけなければならないのか、どのような知識を持っていなければならないのか考えます。そうしなければ、城を…ひいてはシステムの質を守ることができないからです。

モノづくりするだけにしか意識がおよばないままでは、決して城を守ることはできません。個人であればそれでもいいかもしれませんが、チームが、組織が、企業までが同じでは困ります。

ソフトウェア開発、システム開発というとどうしてもイメージしづらいものになりますが、目に見えてわかるモノに例えてみると如何に「意識」や「認識」に抜け漏れがあるか見えてくることも多いと思います。

だから、私はいつも何か身近なものや分かりやすいものに置き換えてイメージするようにするのです。