人間は必ず間違える
プログラムを書くと、必ず、コンパイラー(アセンブラー）にかけて機械語に変換する。おそらくプログラマーで、コーディングミスをしたことがない、という人はいないだろう。だからコンパイラーという道具で間違いを検知する。
ところが、世の中は違う。人がやったことにミスがあると責める。責めれば、次はやらないと考えている。とくに日本は「緊張していればミスはしない」というエンジニアからすれば、極めて安直な考え方で仕事をしているといわざるを得ない。ビジネスという観点からすると極めて甘い。金庫という投資をせずに「金をもっていくな」といってるようなものだ。間違いがあっては困る場合に、なんの対策もせずに、作業者の個人的責任論に終始している現場を見ると「のんきでいいね。本当はどうでもいいんでしょ」と評価せざるをえない。
人間は必ず間違える。本当に間違えては困る場合は、間違えても検知できるようなシステムを考えるか、フェールセーフという発想で、もし、間違いが起きても救えるようにする、ものである。
デザインと変更
ところが、ミスなのかデザインなのかわからないことがよく起きる。わかりやすい例は、事故の対応である。停電で電車が止まった、その後の対応などというのは予定どおりなのかミスが発生しているのか混沌としていてよくわからない。
ただ、いえることは、なにか改善点があったらシステムを変更しなければならない、ということだ。しばしば素人はなんらかの仕組みを作る時に、「将来、変更される」ということを考えずに作る。逆にいえばデザインする時に、ありとあらゆるケースを盛り込んだらいいと思っている。これも甘い考えである。
なぜならば、ビジネスのやり方は将来も変わる。それは予測できない。つまり、システムとは変化するという前提でしか作ってはいけないのである。
変更に強くするために
ソフトウエアの世界では、どう解決してきたか？お客さんはシステムを作る時に一気になんでもかんでも詰め込もうとする。仕事のやり方が変わるとどうなるかは誰もわからないのに、プロジェクト担当者は分かったつもりになる。その上、開発したものには一定のミス（通称名：バグ）が混入する。結果、リリースしたら大混乱、ということを繰り返してきた。
そもそもシステムとは変更されるものである。再度、強調する。ビジネス上の理由であっても、ミスの修正という理由であっても、システムは変更される。認識が違っていても、やることは同じなのだ。
それゆえ、変更に強いシステムとはなにか？というテーマが長年、ITの分野では議論されてきた。経験上、もっともよい（これをベスト・エフォートという）であろうものが、オブジェクト指向だろう、と２１世紀初頭の現在は、いわれている。オブジェクト指向といえば難しく感じるが、あまりデータやプロセスを中心に考えないで、やっている人、組織を「機能単位」としてみたらどうか、ということだ。人は経験上、ビジネスが変化すると組織を変更する。つまり、機能単位を組み変える。それと同じことである。そして、ある機能単位がやることは他の機能単位は介入しない。（カプセル化という）そうやって、細かい変更が他に波及しないようにするのである。
この考えが出てきてから、システムを作る時に、まず最小限の機能を実装し、動かしてみて様子を見て、さらに機能を増やしていく、というスパイラルな方法が可能になった。言葉を変えると拙速が可能となったのである。素早く変更が可能となったのである。
