前提条件

それにしても老後２０００万の件は見苦しくて叶わんな。

この騒動から学べるのは、やはり人は前提条件まで見ないということだ。(´・ω・`)

数字の前提

確かに、報告書の中に２０００万という数字があるのは確かだろう。
でも、どういう前提と計算方法で２０００万という数字が算出されているのか、その根拠まで読み込んでいる人は滅多にいないのではないか？

僕も見ていないし、見るつもりも無い。

でも、２０００万という数字には絶対に前提条件があるわけよ。
例えば家が持ち家なのか、賃貸なのか。物価は現在の日本と同じで考えているのか、インフレを想定しているのか。独身なのか、夫婦なのか。などなど。

そういった前提条件を読み込んだうえで、自分の将来像と照らし合わせ、どの程度一致しているのかをある程度組んだうえで「２０００万」という数字を参考にする、という人であれば何の問題も無い。

でも、そんな人が現実にいるはずが無い。
現実は、ただただ「２０００万」という数字を鵜呑みにして、前提条件は勝手に思い込んでいる。
これが現実の人間だ。

この「人間は数字の前提条件まで考察しない」という性質は、非常に問題であるが、一方で利用することも出来る。
だからここは上手くやらねばならない。

テスト密度

例えば、テスト密度を例に挙げてみよう。

テスト密度というのは、プログラムのステップ数辺りにどれくらいテストして、そのうちバグは何件摘出された、とかそういうのだな。

このテスト密度には「指標値」があって、その指標値に適合しなければＮＧとなる。
しかし、その指標値の「前提条件」まで把握している人は滅多にいない。

例えば、同じ「〇〇ステップ辺り××件のバグ検出」でも、超巨大システムで実際に発生する数値と、小規模システムで実際に発生する数値は違う。
同じソースでも、白紙ベースで作ったソースならバグも出ようが、既に動いている別プロジェクトから使える部品をパクッたソースはバグなど出ない。

と言うように、「指標値」というのは、「指標値の前提条件」まで鑑みて、今回のプロジェクトとどの程度一致しているのか、そこまで吟味して初めて価値を生むもの。

ところが、現実にそこまで出来ている人などいるはずが無くて、ただただ、「我が社の指標値はこれだ」としか考えられない。こういう人は沢山いる。

このように「あっ、この人、前提条件まで頭が回ってないな」と察したら、騙す手段はいくらでもある。
上記のように指標値の前提を見ない人間であれば、テストの内実も見ないから、テスト数などいくらでも水増し出来る。

例えば、

• 入力可能な文字は半角英数字のみ

というテストは、

• 半角数字：正常
• 半角英小文字：正常
• 半角英大文字：正常
• 半角記号：正常

なんてケースにすればいくらでも増やせる。

「半角英小文字」と「半角英大文字」を別々のテストケースとしていることの正当性、とかそんなの相手は考えない。

エビデンスを取るのは簡単なテストケースを水増しして、いくらでも数字を操作して、相手を騙して納品できる。

そして障害が発生したら、

「テスト自体は指標に基づいて正当に行った」

と言っておけば、数字を操作した部分については責められる材料は無い。
瑕疵責任を持たないＳＥＳであれば、全く安全に生き延びることが出来る。

これがテクニックだ。

逆に自分がプロパーの側だったら、こういうふざけたことをするＳＥＳを見つけたら即刻ブチ殺さねばならない。

何事も同じ

このテクニックは如何なる局面でも応用出来る。

例えば、プロジェクトを受注したい時は、

• このプロジェクトは５０００万で完成出来ます！！（理由は無いけど）

なんて話に喜んで飛びつく顧客はいくらでもいる。

逆にポシャらせたい場合は、

• 根拠を説明しろ。
• もっと詳しく説明しろ。
• もっと詳しく。

と、際限なく詳しい説明を要求することでいくらでも遅延させることが出来る。

結局は匙加減でしか無いから、良いも悪いも、どのようにでも落とすことが可能である。

これが「根拠」とか「前提条件」の本質であって、この本質が分かってない相手はいくらでも好きなように操ることが出来る。

これがテクニックだ。

だから、この戦国の世で生き残る為には、漠然と数字や報告を鵜呑みにするのではなく、その「妥当性」「前提条件」をどれほど的確に見抜くことが出来るか、これに尽きる。

その点で言うと、老後２０００万なんて数字は、僕にその報告書の前提条件まで読み込んで分析する意思が無い以上は賛成も反対も無く、何も聞いていないのと同じである。

世の中はどこに計略が仕掛けられているか分からんからな。
こうやって計略合戦に勝利して生き延びていきたい。(´・ω・`)