« 「Smart UI」から「Smart DB」へ向かう道も険しい | トップページ | スタンプ属性や更新履歴テーブルの無駄っぽさ »

2010.10.31

個別案件にオブジェクト指向は要らない

 「ウォーターフォールかアジャイルか」をはじめとして、ソフトウエア開発手法に関してさまざまな議論があるが、すべてのソフトウエアをいっしょくたにすべきではない。たとえば「ECサイト」と「業務システム(基幹業務支援システム)」とは、同じ「データベースシステム」に分類可能だとしても、専門性が大きく異っている。両者をまとめて議論しても実りが多いとは私には思えない。

 私の専門は「業務システム」なのだが、次のように勘定科目と密接な関係を持つ複雑なデータ構造を扱う点が特徴的である。

<サービス業向け販売管理システム>
・発注、買掛残高、仕入実績、支払
・受注、売掛残高、売上実績、原価実績、請求

<物販業向け販売管理システム>
・発注、買掛残高、仕入実績、支払
・受注、売掛残高、売上実績、請求
・在庫残高、受払実績、棚卸、倉庫移動

<生産管理システム>
・発注、買掛残高、仕入実績、支払
・受注、売掛残高、売上実績、請求
・在庫残高、受払実績、棚卸、倉庫移動
・製造指図、製造原価実績

 これは、基幹業務の結果が決算書の形で報告される必要があるためだ。したがって、簿記を知らないままでは業務システムの設計はできない。「会計」と「データベース設計」の知識とスキルが、この分野における専門性の核と言っていい。言葉で説明すると簡単そうだが、これらの知識を統合的に理解・習得して応用力を発揮するまでに至る筋道は平坦ではない。

 いっぽう私の専門ではないデータベースシステムの一分野である「ECサイト」あたりについてはよく知らない。やはりその分野も独特な専門性で満たされいるはずだが、もしかしたら「ちょっとずつ作りながらリリースする」というアジャイルなやり方でも開発できるのかもしれない。まあ、数回関わっただけなので私にはよくわからない。

 他の分野についてはよく知らないが、私の専門である業務システムの分野に関してなら、確信を持って言えることがある。アジャイル主義者である私の主張の肝は次のようにまとめられる。

業務システム向けの専用ドライバをオブジェクト指向開発することで、個別案件をオブジェクト指向開発する必要がなくなる。結果的に、個別案件におけるアジャイル開発が可能になる。

 私に言わせれば、業務システムの分野において「健全なアジャイル」を阻害しているものは他でもない「個別案件でのオブジェクト指向開発」である。これは、アジャイルの考え方がオブジェクト指向コミュニティで発展したことを思うと、どんでん返しのような主張に思えるかもしれない。

 しかし実際問題として、業務システムの開発が「会計とデータベース設計のエキスパート」ではなく「会計とデータベース設計とオブジェクト指向のエキスパート」によってしか担当できないのでは困るのである。そんな希少でスゴい人物ならドメイン駆動でvery agileに開発してくれそうだが、保守まで面倒見てくれるのか。面倒見てくれるとしたら、体のいいベンダーロックインが成就しただけではないのか。それはアジャイルではあっても「(ユーザーにとって)健全なアジャイル」ではない。

 他の分野についてはよく知らないと書いたが、事情は似ているような気もする。つまりこれは、「オブジェクト指向の使いどころ」に関する一般的な議論でもある。以前にも書いたように、個別案件毎にいちいち洗練されたクラス構造を追求しながら作るやり方は「マイケルジャクソンが場末の居酒屋で流しで歌う」とか「F1カーで通勤する」ようなものだ。そんなコストパフォーマンスの悪いやり方はやめて、「個別案件をオブジェクト指向開発しないですむようなミドルウエア」を、それぞれの分野向けにオブジェクト指向開発してしまえばいい。

 幸運にも「会計とデータベース設計とオブジェクト指向のエキスパート」を見つけることができたのなら、個別案件をまかせてはいけない。そんな逸材には「業務システムの個別案件をオブジェクト指向開発しないですむようなミドルウエア」を作ってもらうべきだ。それを用いることで個別案件の全工程からオブジェクト指向の要素を除去できるからだ。そのためにこそオブジェクト指向のパワーを活用しよう。「ウォーターフォールかアジャイルか」の議論などその後でいい。

|

« 「Smart UI」から「Smart DB」へ向かう道も険しい | トップページ | スタンプ属性や更新履歴テーブルの無駄っぽさ »

コメント

オブジェクト指向と書かれていますが、これって一昔前はオブジェクト指向設計呼ばれていたドメイン駆動設計のことですよね? 今となっては、オブジェクト指向言語でない言語で開発することは困難というか、String型禁止、char[]で書けとか言われても困ってしまうわけで。

投稿: arn | 2010.10.31 14:11

arnさん

おひさしぶりです(^^) たしかにここで言う「オブジェクト指向」は「オブジェクト指向言語」ではなく「ドメイン駆動設計」と考えてもらってかまいません。「個別案件にオブジェクト指向言語は要らない」という話ではなく、「個別案件でのオブジェクト指向プログラミングを不要にしてしまうミドルウエアをオブジェクト指向プログラミングしようではないか皆の衆」という話ですから。

ちなみに私の開発しているミドルウエア(XEAD Driver)では、個別案件で使えるのはJavaScriptだけです。型付けが弱いのが難点ですが、業務ロジックの手続き型プログラミングには手頃なんですよね。

投稿: わたなべ | 2010.10.31 16:30

勘違いが、勘違いを生む様な話ですね。
現在の業界、あまりにもオブジェクト指向が出来てなさすぎることこそ、問題だと思いますよ。
でなきゃ、数学や論理学なんて、学ぶ必要無いって言ってるのと、変わらないから。(泣)
無理な人達が沢山居ることは承知してますが、できないから不要というのは、違うと思う。
何だか、技術の問題と、能力の話が、グチャグチャだ。
ま、まともに組めないなら、楽々Frameworkを使おうよ、と私も言ってますけどね。

投稿: いなみ | 2010.11.01 12:58

いなみさん

わお、おひさしぶりです。ずっとおしゃべりしてませんねぇ(^^)

「できないから不要」とは思いませんが、もともと要らないのかもしれませんよ。

「演奏シーケンスの作成」を考えた場合、個別楽曲のシーケンスを作成する際にその「クラス構造」なんて悩まないですよね。ミドルウエアであるシーケンサソフトはバリバリのオブジェクト指向で開発されますが、個別楽曲のシーケンス作成者にオブジェクト指向の知識は要らない。しかも、作成の過程は完全に「アジャイル」に見える。

同様に、すぐれたミドルウエアを使えば、「個別の業務システムのシーケンス」の作成者にもオブジェクト指向の知識は要らないはずなんです。楽々Frameworkはまさにそんなミドルウエアですよね。こういうものを開発するためにオブジェクト指向があると考えると、オブジェクト指向のエキスパートって個別案件の開発現場ではもともと要らないのかもしれません。「役割が違う」といいますかね。

投稿: わたなべ | 2010.11.01 19:23

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 個別案件にオブジェクト指向は要らない:

« 「Smart UI」から「Smart DB」へ向かう道も険しい | トップページ | スタンプ属性や更新履歴テーブルの無駄っぽさ »