手続き的な発想、オブジェクト指向的な発想

ずいぶん長い間、業務アプリの開発をやってきた。

最近、ようやく手続き的な発想から、オブジェクト指向的な発想に自分の頭がシフトした気がする。

アルゴリズム



プログラミングに目覚めたころ、プログラムとは「データ構造とアルゴリズム」である、に没頭。

ネットワーク(ノードとエッジ)構造を扱うプログラムを、C 言語でうまくかけて実践できたときは、「オレすげー」と思ったのを思い出します。

そのために、ループ構造、関数呼び出し、再起呼び出しなどを駆使して、メモリ上のデータ操作の手続き記述に、どっぶりはまっていた。

データフロー、業務フロー、画面遷移、エンティティのライフサイクル



業務アプリがメインの仕事になってからは、データフロー、業務のフロー、画面遷移、エンティティのライフサイクルなんてことばっかりやっていた。

業務系のアプリケーションは、基本的に、情報分析して、それをデータベースに実装したら、あとは、

  • 情報の流れる順番
  • 業務の流れる順番
  • 画面の遷移する順番
  • エンティティの CRUD の順番
...

処理を順々に記述していく、という「業務の手続き」を考えることに、どっぷり。

オブジェクト指向



ここ10年くらい、Java 中心で、UML とかもつかって、「オブジェクト指向系」の技術は使ってきた。
でも、いまにして思うと、やっていることは、アルゴリズムであり、業務手順のコード化(トランザクションスクリプト)。

まあ、StringTokenizer を見つけて、「すげー、自分でループ書かずに、文字列が分割できる」とか、Collection フレームワークで、「おお、for 文なんて使わなくても配列(集合)操作できるじゃん」というあたりで、オブジェクト指向的な発想に目覚め始めてはいた。

「オブジェクト指向ごっこ」はやらなかった。
実装で、継承なんて使うべきではないし、ポリモフォーイズムもだめだと思っている。
GoF のデザインパターンも、業務レベルの設計パターンとしては、ろくでもない。

わかりにくい、変更しにくい、副作用が恐い、...

目覚め



最近、業務のモデリングをしていて、突然「オブジェクト指向の発想」に目覚めてしまいました。
(オブジェクト指向プログラミングではないです。ねんのため)

手続き型の発想は、アルゴリズムにしても、データフロー、業務フロー、画面遷移にしても、一定の手順で、順々にステップをこなせば問題が解決する、という考え方。

だから、分析とは、正しい手順を発見すること・理解すること、を目指す。

分析していけば、かならず、「正しい手順」「いつでも有効な手順」がある、という価値観。

でも、オブジェクト指向の発想はまったく別。
もともとは、「熱力学の分子の動き」の研究用に作られた言語が、オブジェクト指向の原点の一つらしい。

この分野は、単純明快な動作のアルゴリズムがあるわけではない。
水蒸気になった、水の分子がどういう動きをするか、アルゴリズムや、業務手順があるわけないですよね?

でも、なんらかの論理的な動きはするはず、それをどうやって、研究するか?

そこででてきた発想が、「分子」というオブジェクトに、振舞を与えて、いろいろまわりから刺激を与えた時に、どんな挙動をするか、(ソフトウェア上の架空の世界で)実験してみよう、という発想。

全体のロジックはわからないが、「分子」という存在と、「熱エネルギー」という刺激はわかっているので、それを、実際の動作させながら、挙動を調べようと。

この知識と、仕事でやっている、業務アプリのモデリングが、ある日突然結びついた。

手順や構造やよくわからん。まず、何が存在するかの分析中心でいこう。



どうやって処理すべき情報かは、まだ、明確じゃないけど、こういう情報を扱う、という「情報」というのが、いってみれば、分子。 あるいは、情報そのものより、ヒトやモノとしてモデル化する。

業務手順とか、ビジネスルールとかはあるけど、実は、「熱力学」の世界といっしょ。 今の振舞が、いつでも再現する振舞ではない。
ヒトの振舞・判断は、いちおうビジネスの決め事があるけど、例外も多いし、そもそも、しょっちゅうかわる。
業務手順やビジネスルールは、実験的なルールの一つで、これから、いろいろ変えながら、全体としての振舞を解明していくという、熱力学のシミュレーションモデルが、業務アプリの世界でも有効な発想なんだ!

まずは、どんなオブジェクトが存在するかを分析する。
オブジェクトの振舞のルール、オブジェクト間の関係は、固定で強固なものではなく、いろいろ変動するもの。

こういうものの見方で、業務を捉えていくのが、オブジェクト指向的な発想なんだ。

うーん、わからないか



ちょっと読み直したけど、他のヒトには意味不明なんだろうなあ。
読み手を考えるべきなんだろうけど、とりあえず、自分の目覚めの記録、ということで、このままにします。




エンタープライズアプリケーションの例

ソフトウェア開発にもいろいろある。
具体的なアプリケーションをあげると...

エンタープライズアプリケーション



給与計算、診療記録、出荷管理、コスト分析、信用調査、サプライチェーン、
会計、顧客サービス、外国為替取引、...

エンタープライズアプリケーションでない



自動車用燃料噴射制御、ワープロ、エレベータ制御、化学プラント制御、
電話交換、OS,コンパイラ、ゲーム

簡単に言うと



データベースがあって、入力フォームがあって、裏でバッチ処理が走る。
これが、エンタープライズアプリケーションかな?

最近は、他のシステムとの連携も多い。
  • ファイル交換
  • データベース共有
  • リモートプロシージャコール
  • メッセージング


InfoQ と エンタープライズアプリケーション

知る人ぞ知る、アーキテクト向けのサイト、InfoQ を見ていて、ちょっと気がついたこと。

本家のInfoQ
日本のInfoQ

ページトップのキャッチを比べてみる。

本家:Tracking change and innovation in the enterprise software development community
日本:最新技術を追い求めるデベロッパのための情報コミュニティ

英語の enterprise が、日本では割愛されていますね。

日本のデベロッパには、Enterprise がキャッチではなくて、英語圏のデベロッパには、Enterprise というのがキーワードの一つになっている。

多くの日本のIT技術者にとっては、エンタープライズソフトウェアは、関心事じゃないんでしょうね。
Domain-Driven Design が、アメリカでの評判・影響と、日本での評判・影響にずいぶん違いがあると感じていた。

この InfoQ のキャッチの違いも、同じところに理由があるんでしょうね。






エンタープライズアプリケーションとは?

いろいろなエンタープライズ


ソフトウェアの世界では、いろいろ目に付きますね。

J2EE
エンタープライズエディション
EAA
エンタープライズアプリケーションアーキテクチャ
EIP
エンタープライズインテグレーションパターン
ESB
エンタープライズサービスバス


私は、自分の専門分野は、ソフトウェアシステムの中でも、エンタープライズ分野、であると自負している。

マーチン・ファウラー、かく語りき


著書、PoEAA ( エンタープライズアプリケーションアーキテクチャ ) の「はじめに」で、マーチンファウラーは、エンタープライズアプリケーションの意味を説明している。
明確に定義できないし、人によって使い方がいろいろある、あいまいな言葉。
私としては、このマーチンファウラーの説明が、いちばんしっくり来ている。

最初の段落の以下の2点にすべてが要約されている。
  • 複雑なデータに対処する
  • (論理的とはいいがたい)ビジネスルール


エンタープライズアプリケーションの関心事は、「データ」と「ビジネスルール」というわけだ。

永続データ、たくさんのデータ、同時データアクセス


データの問題を、三つの視点から、とりあげている。

永続性


ビジネスは、情報の記録と保管は、基本中の基本。アプリケーションソフトウェアを入れ替えても、既存のデータは「移行」して使い続ける。

たくさんのデータ


ビジネスで扱うデータは、どんどん増えている。なんでもかんでも、電子化・デジタル化の時代。
インターネット時代では、顧客のワンクリックまで、記録して、永続化する。
こういう膨大なデータを効率良く扱うのがエンタープライズアプリケーションの、重要な関心事。

同時データアクセス


これも、ネットワーク時代になって、加速している問題。
同じデータに多くの人が同時にアクセスする。同じデータを同時に書き換えることも起きる。
これをどうやって、うまくさばくか?

RDBMS と SQL


永続化、大量データ、同時アクセスを実現する技術としては、いまのところ、RDBMS と SQL が基本の技術。
RDBMS/SQLの使った、良い実践とはなにか? 良い設計とは? 良いアーキテクチャとは?
これが、エンタープライズアプリケーションの重要な関心事の一つ。

多くのユーザインタフェース画面


エンタープライズアプリケーションとは、極端に単純化すると、データベースを、CRUDするもの、と定義できる。

データの種類や量が多いということは、CRUDのための画面も多いということ。
また、いろいろなビジネス上のルールがあるために、ユーザによって、「できる・できない」「見える・見えない」を変えなきゃいけない。
Web アプリケーションを顧客に使ってもらうとなると、顧客ごとに、さらに、カストマイズした画面が欲しくなる。

検索フォーム・一覧・入力フォーム。基本はきまりきった単純な形式しかないのに、とにかく画面数が膨れ上がる。
どうやって、これを簡単に開発するか?
変更要求があったときに、どうやって、安全・確実に変更を適用するか?

電子メールというユーザインタフェースもいろいろ必要。
携帯電話や、PDA 用も。

画面の爆発です。
でも、ユーザにとっては、画面こそ、画面だけが、システム。
ここが、がんばりどころとなるわけだ。

バッチ


バッチ処理も忘れちゃいけいない。
ビジネスでは、日、週、月、四半期、半期、年度、というサイクル構造(=バッチ処理のタイミング)は、強固な枠組です。

他のエンタープライズアプリケーションと統合


あちこちで、爆発的に、ビジネスデータの電子化が進んでいる。
それも、同時多発ゲリラのように、さまざまなデータ形式、実装技術でやまほどエンタープライズアプリケーションが作られている。

社内だけでもたいへんなのに、最近は、ネットワークのおかげで、社外とのシステム連携も、日常的な課題になってきた。
ビジネス活動とは、人と人、組織と組織の相互作用。だから、ビジネスの道具である、エンタープライズアプリケーションも、他のアプリケーションとの連携・相互作用が必然。

しかし、...。
実装技術、データ形式、通信プロトコル。ハードルがやまほどありますね。
見ず知らずの開発チームと共同作業なんていうハードルもある。

概念の不一致


でも、統合の一番の難敵は、それぞれのシステムの「データ」の考え方が違うこと。

ビジネスルールは、いつも変化している。ある時点で造ったアプリケーションとデータは、その時点のビジネスルールの「スナップショット」を反映しているだけ。
社内システムといえども、アプリケーションごと、データベースごとに、異なる考え方を実装したもの。

他社のシステムとの連携ともなれば、根本のビジネスの考え方・決め事がまるで違っているのがあたりまえ。

ビジネスパーソン同士でも、いろいろなすり合わせを行い、契約書や合意書をやまほど積み上げていく。
でも、人同士だと、まだ融通が効く。

エンタープライズアプリケーションという融通の効かないモノ同士の連携は悪夢に近い。
昔のビジネスルール、部分的なビジネスルールを、がちがちに、変更不能な状態に組み込んでしまった「ソフトウェア」(どこが柔らかいんだ!)。

ビジネスロジック


これは、パラドックスです。

ビジネスロジックとは、ロジカルではない。

関係者があつまれば、だいたいの約束事は把握できるけど、緻密に、論理的にくみ立てられたものではない。
ヒアリングすれば、誰も説明できないルールがでてくるのは、みなさんご存知の通りです。

唯一の真実は、「ビジネスロジックは変更される」こと。

どんなにがんばって、その時点でなんとか整理したビジネスルールを実装しても、それは、たんなるスナップショットであり、ある一面のビューにすぎない。

実装してテストしている間に、業務の現場では、別のルールがいつのまにか常識になりつつある。

だから、どうする


格闘すべきテーマは、単純といえば単純。

最初に書いたように、
  • 複雑なデータに対処する
  • (論理的とはいいがたい)変化し続けるビジネスルール


この2点を効果的に実装する、実践的な技術、良い実践ノウハウ。これが、エンタープライズアプリケーションを造るエンジニアのもっとも重要な関心事であり、スキル。

育成型のソフトウェア

最近、ソフトウェア開発で、いろいろ考えているキーワードが、ソフトウェアを「育成」すること。

受託開発ビジネスだと、リリースが大きなゴール。昔は、リリースしたら、ソフトウェアはできればいじらないのが一番。


  • 変更のコスト

  • 期待できる効果

  • 変更のリスク



を勘案すると、リリースしたソフトウェアは、できるだけいじらないのが基本。

でも、最近は、このロジック、通用しなくなってきているみたい。

要求の変化



顧客も、競合も、インターネットやモバイルなどの IT も、変化しつづけている。

この環境だと、リリース時の状態でストップしたソフトェアは、あっというまに価値が下がっていく。

あるソフトウェアをリリースして、それまでは、できなかったことができるようになる。ユーザは喜んでくれる。
でも、そのソフトウェアが当たり前になると、今度は、もっと、こうならないの?という不満のネタになる。

まあ、浜の真砂はつきるとも、世に要求のタネはつきまじ。

技術・ノウハウの進歩



そういう、変化への対応の要求が強いと、造る側でも、いろいろな技術の改良が進む。


  • 変更のコストを下げる技術

  • 期待できる効果を大きくする技術

  • 変更のリスクを小さくする技術



技術的なキーワードは、


  • ドメイン駆動

  • アジャイル開発

  • 軽量なアーキテクチャ



ドメイン駆動



問題領域の知識を、いかに深めて、いかに、ソフトウェアに実装する。その哲学と実践ノウハウ。

知識は、その領域で、いろいろな経験を積めば積むほど、広く、深くなっていく。
環境が変われば、知識がさらに増えたり、変化していく。

こういう知識の変化・増殖を、絶え間なく、ソフトウェアに反映しつづければ、そのソフトウェアの価値は高まり続ける。

アジャイル開発



形式的なやり方ではなく、必要なことを、必要なだけ、必要な時にやる。その哲学と実践ノウハウ。

いまは、要件定義は、RDRA、開発は、 ICONIX 、ラストワンマイル(配置)は、CI (継続的インテグレーション) と、して取り組んでいる。

これは、開発のスピードをあげ、コストを下げるの方法として、手ごたえ十分。実践できていることは、Best Practice から、ほど遠くても、それでも、かなり効果が実感できている。

特に、ソフトウェア変更のスピードやコストの改善は、すごい。

軽量なアーキテクチャ



J2EE が、いちじ、ヘビー級指向だったけど、Spring フレームワークとかが、軽量であることの価値にこだわって活動をしてくれたおかげで、アーキテクチャも軽やかなものを選択できるようになった。

オープンソースの、サーバー、フレームワーク、ライブラリも、軽量指向のものが増えて、また、成熟してきている。

安心して使える、までは言いすぎだと思うけど、十分に実用的になっている。

ハードウェアやOSも、Amazon EC2 とかで、好きに時に、好きなだけ使える良い時代になった。

プロジェクトの初日に、フルセットの開発環境、リポジトリ、ビルド環境を、インターネット上からリソースかき集めて、インターネット上に構築する、なんていうことを、実際にやってみると、ほんと、時代が変わったと思う。

ハードの調達、ベンダーからソフトウェアの購入、...などにどのくらい貴重な時間をロスしていたことだろう?

ソフトウェアを育成する



要求側の変化への強い圧力、造る側の技術革新、これが、重なって、ソフトウェアを育成することが、良いソフトウェア、役に立つソフトウェアを提供する、有力な手段になってきた。

今は、まだまだ、変更のコストは高いし、リスクも大きい、期待効果は小さい、のが現実。
でも、あきらかに、経験を積むたびに、コストが下がり、リスクが小さくなり、変更の効果が大きくなっている。

この「ソフトウェア育成」の哲学と実践ノウハウの獲得にしばらくこだわってみようと思う。

calendar
    123
45678910
11121314151617
18192021222324
25262728293031
<< October 2009 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM