シンプルな仕様の選び方

業務システムの仕様を選択する必要がある場合、こう自問しよう。

その仕様を、お客さまに3分以内で説明できるか?

一般にエンジニアは理論理屈を好み、それはそれで良いことだけど、理論理屈はお客さまにとって最優先ではない。お客さまにとっての分かりやすさを大事にしよう。お客さまに簡単に説明できなかったり、そもそも複雑すぎてユーザーマニュアルに書くのが辛くなるような仕様はダメだ。
理論上発生しうる全てのパターンを網羅した複雑な仕様よりも、「もっともよく起き得る、使われるパターン」をシンプルに実現し、お客様に提案できるほうがより良い。年に一回も起きないようなケースにお金をかけるのはもったいないのだ。

その仕様を、テストできるか?

発生する可能性があることはいつかは発生する。なので、複雑な状態を想定・定義・設計・実装すると、その複雑な状態はいつかは発生してしまう。
状態を仕様として定義してしまったからには、全てのケースをテストしなくてはいけない。例え発生する可能性が少なくても、だ。

その仕様を、何故選んだのか理由を説明できるか?

思いつき・なんとなく・それっぽいから、などといった理由で仕様を説明してはいけない。ちゃんとお客さまにとってのメリットを中心に説明できること。そして、シンプルな仕様・ルールは、結果的に論理的であり、だれにとっても覚えやすい。