暗黙の仮定、特に自分自身ものを疑え

ウェザーンの判断保留の法則は、ちょっと皮肉っぽく、「暗黙の仮定は、すべての立ち往生の母だ」と言っています。「仮定する(assume)のは、u(you)とmeをばかにする(ass)ことだ」という言い方もあります。しかし、暗黙の仮定によって数百万ドルでなくても数千ドルもの損害が発生するようなら、笑い話では済みません。

意思決定について、特にトレードオフ(パフォーマンスかメンテナンス性か、コストかリリースの早さかなど)が含まれている場合には、かならずその理由をドキュメントにすべきだということは、前項でも書きました。より厳しいアプローチでは、個々の決定について、最終判断の「要因」など、決定に至るまでの文脈を添えるのが普通です。要因は、機能的なものでもそうでないものも含まれますが、意思決定者が重要だと感じた「事実」(または疑似事実…)が含まれている場合があります(技術的な制約、必要なスキルセット、政治環境など)。

この習慣はとても役に立ちます。さまざまな要因を書き留めておくと、アーキテクトが知らず知らずのうちに仮定していたことが、ソフトウェア設計の重要な決定に影響を及ぼしていることがはっきりとわかることがあります。これらの仮定は、「歴史的な理由」、個人的な見解、デベロッパーの口コミ、恐怖戦略によるもので、ひどい場合は「廊下で耳にしたこと」が入り込んでくることさえあります。

• 「オープンソースは信用できない」
• 「ビットマップインデックスは、良いところよりも悪いところの方が多い」
• 「顧客は、ロードに5秒もかかるページを決して受け入れない」
• 「CIOは、大手ベンダーが販売しているもの以外は拒否する」

後の世代のため、また将来の見直しのために、これらの見えない仮定を見えるようにしておくことは大切です。しかし、もっと大切なことがあります。しっかりとした経験的証拠があるわけではない仮定や、何らかの政治的な理由による関係者のい込みは、決定が容易に覆せなくなる前に、正しいかどうかをチェックしなければなりません。カウンターさえ用意すれば、顧客が重要なレポートの作成のために5秒待ってくれるとすればどうしますか。正確なところ、一体どのオープンソースプロジェクトに信頼が置けないのでしょうか。あなたのアプリケーションのトランザクションやクエリーを使い、自分のデータでビットマップインデックスをテストしてみましたか。

そして、「しっかりとした」という単語を見落とさないようにしてください。あなたのソフトウェアの古いバージョンでは正しかったことが、今のバージョンでは正しくない場合があります。Oracleのあるバージョンのビットマップインデックスの性能は、他のバージョンの性能とは異なるかもしれません。古いバージョンのライブラリは、今のバージョンならフィックスされているセキュリテイホールを持っているかもしれません。以前信頼できるソフトウェアベンダーだったところが、倒産す前になっている可能性もあります。技術の風景も人も日々変わっています。誰にその変化がわかるでしょうか。ひょっとすると、CIOはLinuxの熱烈なファンに転向したかもしれません。

事実と暗黙のうちの仮定は、ソフトウェアを支える柱になります。それが何であれ、基礎はしっかりとさせておかなければなりません。