ムーアの法則とビジネスロジック

本日も、過去に書いたブログからの再掲です。原著は2006/9/1です。

====================================

昔のプログラム（たとえば、20年近く前に書かれたcobolプログラム）をたまたま修正する必要があってコードを追って見ると、どうしてこんなロジックになっているのだろうな、と思うことがあります。

また、ビジネスを革新するプロジェクトにおいて、現状分析をしてみると、どうして昼間オンライン処理すべきデータを、夜間にバッチ処理してるんだろうと思うことがあります。

こういったことの理由は、往々にして、そのシステムを構築したときのHWやネットワークの制約であったりするものです。

15年前のホストコンピュータといえば、現在のPCサーバ以下の処理能力でも何億円という大変な金額がしました。

MDSやCIMといったコンセプトが流行った時代は、こういうHW環境を背景にしています。
メモリーの制限やCPUの処理能力に大きな制限がある中で、ホストコンピュータに大きな投資をし、それを何とか仕事に役立てようと（今からみると）トリッキーなプログラムを書いて、処理時間の短縮を図ったりもしました。それが、昔のプログラマの腕の見せ所だったりしました。

よく知られるムーアの法則は、インテルの創業者の一人であるゴードン・ムーア博士が1965年に提唱したもので、これまで40年以上にわたって結果的に正しいことが示されています。その内容は、

「半導体の集積密度（性能）は１８ヶ月で倍になる」

というものです。

つまり、半導体の性能は指数関数的に高くなっていくということですが、今から過去を振り返ったとき、当時のコンピュータの性能は「（現在と比較して）指数関数的に低かった」ことになります。

SEとしてコンピュータシステムを構築し、ビジネスプロセスを革新する際には、こういったコンピュータそのものの歴史の認識が非常に重要であると思っています。
うっかりこれを忘れてしまうと、当たり前のように先人達と同様なコードを書いたり、そういうコードを作ることで、ビジネスロジックを無意味に非効率なものとする可能性があるからです。

ビジネスありきのコンピュータシステムですから、そういった旧来からのプログラムやそれに束縛されたビジネスロジックは、最初からなかったものとして、一から考え直すことが寛容です。

そのためには当然、日々の勉強や観察に基づいて、自分なりのto beモデルを持っていなければなりません。
それは、最低限、コンサルタントや業務系SEに求められる用件です。

そして、現場にあっては、（無の境地になって）自分の懐にあるto beモデルとの比較において、ビジネスロジックの効率や正当性を評価しなくてはなりません。

昔は夜間バッチだったものが、今はオンラインで瞬時に計算できるのですから、当たり前のことなのですが、忘れがちなことでもあります。