「オブジェクト指向発想」の目覚め
増田さんの「手続き的な発想、オブジェクト指向的な発想」を読みました。
オフィスでも、勉強会でこのことについて話しました。
話をして思い出したのは、昔金融コンサルと組んで、金融機関の収益シミュレーションシステムを作っていた時のこと。
—-
最初はスプレッドシートでマクロを組んでやっていた。
でも、結構壮大なシミュレーション仕様で、一回実行すると一時間以上返ってこなかったりした。
当時のPCとスプレッドシートでは荷が重いことがわかった。
で、UNIXサーバでCで組むことになった。
このころは増田さんが言っているような、
ネットワーク（ノードとエッジ）構造を扱うプログラムを、C 言語でうまくかけて実践できたときは、「オレすげー」と思ったのを思い出します。
そのために、ループ構造、関数呼び出し、再起呼び出しなどを駆使して、メモリ上のデータ操作の手続き記述に、どっぶりはまっていた。
なんて時代です。「オブジェクト指向」という言葉はありました。
たとえば、技術評論社のSoftwareDesignなんかでは、「オブジェクト指向って何がいいのか」なんて記事が書かれていたような時代。
日経コンピュータあたりでは、「業務アプリにはオブジェクト指向なんて不要。データ中心アプローチでやり直しちゃったよ」なんて記事が書かれていたような時代。
まだ、実際の開発現場で市民権を得る前の話ですね。
何せ、仕様の元がスプレッドシート＋マクロなので、構造体を使って大きなメモリイメージを作り、それに対して手続きを書いてまたメモリに壮大に展開していくようなプログラムを書いていた。
シミュレーション仕様は金融コンサルとエンジニアで一生懸命考えた。
金融コンサルの頭の中は基本スプレッドシートで考えられていて、私たちもそのイメージを一緒に共有して考えた。
当然、オブジェクト指向なんて考えはどこにもなくて、すごく手続き的に考えられていた。
で、実際作ってみると、思ったような「いい数字」が出ない場合が多かった。なにせシミュレーションなので、実際の動きをモデルに、ある程度簡略化した計算をしていた。
そのため、実際こうはならないだろうという数値が出る場合がある。そんな時は、また金融コンサルと一緒に新仕様を考えた。
また、実際のデータとシナリオが合わない時や、ユーザの計画方法が無茶な場合もいい数字は出なかった。
そんなときも、実際にプログラムで「いい数値が出るように」合わせに行った。
大変なのはこういう時で、時折とんでもない仕様変更になる場合がある。もとのデータ構造が変わり、精度が変わり、計算方法がガラッと変わる。
当時の作り方では、こんな変更に耐えられるだけの保守性は持ち合わせていなかった。「ほとんど書き直さないとダメなんですけど。。」という感じだ。
仕事としてやりがいはあったけれども、このころはやっぱり大変だった。夢でメモリイメージと手続きが出てきたのもこのころだ。
UNIXサーバのメモリ一杯に広げられたデータと手続き記述の海で溺れていましたね。
—-
これをブレイクスルーできたのは実は何年かたった後。
収益シミュレーションは、実は商品と経済イベント（ex:金利更改があった、手形の書き換えを行う、とか。）と、そこで起こることだけを書いておけばいいんじゃないか？
あるべき結果（いい数字）に向かって処理を羅列していくのではなくて、プログラム的にそういう整理をすれば、保守性高く、スマートにできるんじゃないか？
という発想がやっていくうちに出てきた。
で、実際にそのように書いてみたら、以前よりもずっとわかりやすく、スマートな作りになった。
一緒にプログラムを書いていたＣ言語の師匠も、その設計に手ごたえを感じていた。
おそらく、これが私にとってはじめての「オブジェクト指向発想」だったと思う。
でも、まだ難関が残っていた。
—-
一緒に仕事をする金融コンサルと、この考えは共有できなかった。
説明もしてみたが、どうやら分かってはもらえなかった。
そのあとも、スプレッドシート＋手続きイメージでしか、仕様を考えてはくれなかった。
実は、上司の理解も得られなかった。「イベント？何だそれ」「何でそんな作り方になるの？」と、かなり否定的だった。
当時の私たちには、ここで戦うだけの武器を持ち合わせてはいなかった。
この後は、金融コンサルと考えたスプレッドシート＋手続きイメージを、自分たちの経済イベントモデルに置き換えて実装していった。
—-
もう十年以上前の話だが、おそらくこれからもそういうことが起き続けるのだと思う。
業務領域を考える人たちは、ほとんどの人がやはり「手続き的」なものの考え方をしている。
そして、我々にもそういうように伝える。我々はそれを深く理解して、オブジェクト指向発想で設計する。
そして、変更に強いソフトウェアを作り上げる。
ビジネスルールや業務手順なんていうものは、実はあやふやなものなんだとも思う。
エンジニアはそのあたりを誤解していて、すごく固いものだと思っている。（実際に固いところもあるとは思いますが。）
今どきのビジネス書なんかには、「イノベーション」「ルールを変えた者が勝つ」なんて書いてあるわけだから、
むしろ、成長・発展するにしたがって、「変わって当然」「変わらなきゃダメ」なものになってきている。
「オブジェクト指向発想」を使って、保守性高い業務アプリを作ることはすごく価値があることだと考えている。
コメントはまだありません。