本末転倒（プロジェクトの人間学）

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

プロジェクトではさまざまな本末転倒が起こる。例えば十分条件の必要条件化。確かにそこまで出来れば素晴らしい。十分である。だがやる必要があるのか。他にやるべきことがあるのではないか。そういった要件に意識がとらわれてしまう。

例えばウィルスに感染した場合にどのような対応を取るか。確かに重要だ。ウィルスの種類や拡散状況によっては信用問題となる。すなわち経営レベルのリスクだ。だが、それを例えば設計フェーズで議論するか。設計が十分煮詰まっているのならまだよい。だがまだなすべきことがある段階で「ウィルスが発生したら」という仮定の元に議論するのはほどんど無駄である。

「むやみに仮定を増やしてはならない」というのはオッカムの格言である。一般には自然科学について用いられるが、議論する時にもこれは有効である。一般にはシステム開発の前提で二重障害には対応しないと謳われる。議論や会議にもこの原則は当てはめるべきである。全くありそうなケースにもう一つ二つ仮定を積み重ねるのは構わないが、可能性の低いケースにさらに仮定を置くのは無駄である。また障害や不安を誘導する方に仮定を置く人がいる。「ウィルスがまさにこのシステムで検知されたとしたら」という仮定も、今このフェーズで議論すべきなのかどうか。冷静に優先順位をつけるべきであろう。

あるいは「あるべき論」にこだわり過ぎて、却って不自然な運用やルールを定めてしまう。挙句のあてには「あるべき」の目的（何のための「あるべき」か）が忘れられ、単に厄介な運用とルールのみが残る。具体例を上げると「システムテストは全て自動化されるべきだ」という主張。正しい。もっともである。確かにオンライン打鍵以外は全て自動化出来るシステムもある。しかしそうは行かないシステムも存在する。制約や現状をちゃんと評価せず、あるべき論が一人歩きする。その結果システムテストのためだけに自動運用を作りこむことになる。まさに本末転倒である。そもそも本番を想定した自動運用でのテストがシステムテストの目的である。システムテストのためだけに自動運用を作りこんでしまえばシステムテスト本来の目的からは逸れてしまうことになる。むやみに細部や手段にこだわり目的を忘れてしまうと、容易に本末転倒が起こりうる。いつでもどこにでも存在し得る落とし穴である。