業務システムの設計・開発を職業とする人々の間で、オブジェクト指向はいまだに一般的なものと受け止められていないように思える。しかし実際にやってみると、オブジェクト指向は業務システムにうまく馴染むし、システムの品質とメンテナンス性の改善につながる。
====
オブジェクト指向の適用例
具体的な例で見てみよう。仕訳を作成して記帳するという、会計システムのもっとも基本的な処理を、Javaでオブジェクトを使って書いてみる：
/**
* 7月度の「帳簿(book)」を取得する。
*/
1: Book book = application.getBook("2006/7");
/**
* 仕訳(JournalSlip)」を生成し、項目を設定する。
**/
2: JournalSlip slip = book.createJournalSlip();
//仕訳日
3: slip.setJournalDate("2006/7/3");
/**
* 「仕訳明細行(JournalDetail)」を生成し、項目を設定する。
*/
4: JournalDetail detail1 = slip.createDetail();
//部門コード
5: detail1.setDepartmentCode("2000");
//勘定科目コード
6: detail1.setAccountCode("1100");
//貸借区分
7: detail1.setDebit(true);
//金額
8: detail1.setAmount(10000);
････
････ （必要な件数だけ、仕訳明細行の生成と項目設定を繰り返す。
････
/**
* 仕訳を記帳(book)する（すなわち、仮仕訳を確定仕訳にする）。
**/
9: try {
10: slip.book();
11: } catch (JournalSlipNotBookableException e) {
12: displayErrorMessage(e.messages());
13: }
オブジェクト指向のおいしさは、このコード断片に書かれていない部分にある。順番に見ていこう。
仕訳番号の自動付番
確定した仕訳には一連番号を付与しなければならず、またこの一連番号には欠番が許されないとしよう（よくある要件だ）。そのため、確定前の「仮」仕訳には仮番号をいったん割り当て、確定時にはそれを捨てて正規の仕訳番号を付与することにする。このビジネスルールを満たすために、行(2)で仕訳が生成されたときには仮番号が自動設定され、行(10)で仕訳が確定したときには正規の仕訳番号が割り当てられる。これらは JournalSlipオブジェクトが行っている。
項目値のデフォルト設定
仕訳明細には「消費税区分」という項目もあるのだが、上記のコードでは設定されていない。実は、行(6)で勘定科目コードを設定したときに、JournalDetailは、設定された勘定科目に応じて消費税区分のデフォルト設定を行っているのである（必要なら上書きすることもできる）。
仕訳の妥当性検証
仕訳を記帳する際にはその妥当性を検証しなければならない。各明細行の必須項目がすべて設定されているか、仕訳日付が記帳可能期間の範囲内か、仕訳の貸借金額が一致しているかといったことを必ずチェックする。行(10)で仕訳を記帳(book)したときには、こうしたチェックが実行される。妥当性ルールに対する違反があれば、例外オブジェクト（JournalSlipNotBookableException）が投じられる。行(12)では例外オブジェクトからエラーメッセージを取り出している。
要は、仕訳にまつわる一群のビジネスルールを、JournalSlip オブジェクトとJournalDetailオブジェクトの中に隠蔽しているわけだ。だから上に示したコードにはそれらが表れていないのである。仕訳を使う側のコードはビジネスルールから解放されており、ルールが変更された場合にも影響を受けにくい構造になっている。
もちろん、オブジェクトを使わなくても、昔からある「モジュール」をうまく使えば、ある程度のことはできる。しかしオブジェクトを使ったほうが、ずっとすっきりとビジネスルールを局在化することができるのである。
なぜ敬遠されるのか
業務システム開発を仕事としている組織がオブジェクト指向を敬遠する理由は、主に二つある。ひとつは心情的なもの、もうひとつは業界構造的なものである。
心情的な方から言うと、オブジェクト指向が過度に「技術嗜好的」なものと受け取られているということがある。しかし、もっとも基本的なレベルで言えば、オブジェクト指向に「技術」的なところはあまりない。EDPシステムの分割に「責任」という視点を持ち込み、責任を基準としてコードを括ることでシステムを凝集性の高い島々の集まりとして構成しようとしているだけだ。上述の例でいえば「仕訳の（形式的な）正しさを担保する責任」などをJournalSlipとJournalDetailに担わせているということになる。
こうした思想はオブジェクト指向という用語が一般的になる前から「複合／構造化設計」として広く知られていた。僕はオブジェクト指向を、複合／構造化設計の自然な延長と捉えている。
状況をちょっと混乱させているのは、上述したような、システム分割指針としてのオブジェクト指向と、その実現手段のひとつであるオブジェクト指向言語を区別せずに説明している文献が多いという事情である。「データと手続きの一体化」「継承」「多態性（ポリモルフィズム）」といったキーワードがオブジェクト指向の特徴として挙げられることがよくあるが、これらは正確にはオブジェクト指向言語の特徴である。実際、上記の仕訳の例では、継承と多態性は用いていないし、オブジェクト指向設計の定石集である「デザインパターン」には、データを欠いた手続きだけのオブジェクトがたくさん登場する。だから「デザインパターン」はオブジェクト指向的でないのだ、という主張を見かけたことがあるが、これは本末転倒だろう。言語の特性と設計の特性を混同している。
もうひとつの要因、業界構造の問題についてはどうだろう。業務システム開発の業界では、プログラマとかシステムエンジニアを規格化し容易に代替可能な資源として扱いたいという願望が根強くある。ところが、現在のところオブジェクト指向設計は業界内で標準的なスキルと認められていない。そうしたスキルを要する設計をすると人員調達の幅が狭まる。従ってオブジェクト指向は望ましくない。
こうした理路が常に間違っているとは思わない。しかし常に正しい訳ではないし、他のプレイヤーの大部分がこうした行動をとるなら、その逆を突くことでなんらかのチャンスが生まれるかもしれない。
オブジェクト指向のハードルは、考えられているほど高くはないと思う。もちろん、いきなりすべてのコードをオブジェクト指向的に書こうとすると大変だろう。なにも大上段に構える必要は無い。ほんの一部を対象に、試しに適用してみるとよい。それだけでもかなりの効果がある。ちょっとだけ書いてみて、もしどうしても気に入らなければ、そのコードを捨てればよい。食わず嫌いはもったいない。試してみて、経験に基づいて判断するという、地に足のついたアプローチをそろそろとってもよい頃だ。
