要求開発では，多くのUMLのダイアグラムが使われており，オブジェクト指向ベースのクラス図なども出てきます。技術者/開発者として，おそらく最初に思う疑問は「オブジェクト指向とかUMLとか，こんな難しそうなものをユーザーが果たして理解できるのか？ 現場で使えるのか？ 得ができるのか？」といったことだと思います。
私も要求開発の可能性に気づいて，要求開発に取り組み始めたのですが，取り組みながらもぬぐい去れない疑問が，上記の内容でした。
この問題を整理していきたいと思います。ITをビジネスで活用するシーンを想像してみましょう。要求開発アライアンスでは，システム開発を大きく二つのフェーズに分けています。一つは，存在する要求やRFP（Request For Proposal）にしたがってシステム作る「システム開発」フェーズ。もう一つは，戦略からシステム化する要求を作り出す「要求開発」フェーズです（図1）。
|
|
| 図1●要求開発とシステム開発 [画像のクリックで拡大表示] |
そこで本稿では，下記の構成でお話を進めてい行きたいと思います。
1. システム開発におけるオブジェクト指向
2. 要求開発とオブジェクト指向
前編で，日本の開発シーンで“モノを作る”という部分におけるオブジェクト指向の現状と，「システム開発」におけるオブジェクト指向のトレードオフを明らかにします。そして後編で，「要求開発」つまりビジネスモデリングにおいてオブジェクト指向が本当に使えるのか？ という私自身の疑問を皆さんと一緒に考えていきたいと思います。
システム・ジェネレーションギャップ
要求開発に携わる以前から，私は日本の開発の現場には大きな問題があると考えていました。それを「システム・ジェネレーションギャップ」と勝手に呼んでいます。次の2点を意味します。
(1)テクノロジが発展して，システム開発における柔軟性・保守性・再利用性が技術的には向上したはずだが，開発者がついてこれず，効果を発揮できていない
(2)テクノロジの要求する基礎知識が変化したため，開発者が新しいテクノロジを正しく理解できていない
端的には「テクノロジが本来の使われ方をしていないため，効果がでない」という現象を指しています。具体的な例で言うと，Javaによる開発が考えられます。Javaは，変化に強い開発言語として鳴り物入りで登場しました。皆さんの周りでも，きっと多くのJavaプロジェクトが行われた，もしくは行われていると思います。
しかし，Javaで作ったシステムは本当に変化に強かったですか？ それどころか，かえって複雑になってしまい，開発者が「こんなんやったらCOBOLのほうがましや！」とぼやいているといった話を私は聞いたことがあります。
一方，私が実施したJavaプロジェクトでは，従来型の言語より圧倒的に変化に強いシステムが開発できました。これはどういうことでしょうか？ 私は何も特別なことはしていません。
こうなってしまう原因について考えると，技術的な面で一番大きい要因は「オブジェクト指向の不在」だと思います。また，技術的な面以外では「社会的な要因」が深く関係していると思います。
そこで，Javaを使った開発プロジェクトを例にとって「オブジェクト指向を使う場合と使わない場合」にどういうトレードオフが発生するかを見てみましょう（図2）。
|
|
| 図2●システム開発におけるオブジェクト指向の有無のトレードオフ [画像のクリックで拡大表示] |
Javaによる開発で使うフレームワークやJ2EE，UML，コンポーネントといったものは，もともとはオブジェクト指向で開発することを想定して作られています。一方，実際の多くの現場では，Javaを採用していても，オブジェクト指向で開発されているとは限りません。むしろまれです（もちろんオブジェクト指向を理解している組織はオブジェクト指向でやるのが当然と思っています）。
そういう現場では，フレームワークやJ2EEといった本来オブジェクト指向の上で使う技術を，無理やり従来型の土台で使っているというイメージになっています。すると，どうなるでしょう？
まず，システムで実現する機能やそれを記述したカタログについて考えてみましょう。実はこれに関しては「オブジェクト指向あり」でも「なし」でも変わりません。外部仕様が同じであれば，中身の作りが異なっていても，外から見たら違いはわかりません。カタログでも同様です。例えば，中身が「オブジェクト指向あり」でも「なし」でも，Javaを使っていればカタログにはおそらく“変化に強い”などと書いてあるでしょう。
車のカタログに例えるとこんな感じです。例えば，100馬力の車にも280馬力の車にも“加速がいい”とか“エンジンがいい”とか書いてありますが，実際の加速は100馬力のものと280馬力のものではものすごく違うと思います。しかし，ソフトウエアにおいては専門家でないユーザーにはそんなことはわからないでしょう。
ではどこに違いが出るのでしょうか？ それは「柔軟性・保守性・再利用性」に出ます。
Javaが「変化に強い」と言われている理由は，オブジェクト指向言語であり，ポリモーフィズムやカプセル化といったメカニズムを使えることに由来しています。しかし，Javaは「オブジェクト指向型」ではなく「従来型」でもコーディングできます（これは .NETなどでも同様です）。
結局，「オブジェクト指向なし」の場合は，たとえJavaを使っていても従来の方法で開発しているので「柔軟性・保守性・再利用性」は従来型とほぼ同じなのです。オブジェクト指向言語やオブジェクト指向を前提としたプラットフォームを使っても従来型で設計していたのでは恩恵は受けることができないのです。
それでは「オブジェクト指向なし」のJava開発プロジェクトは悪か？というとそうでもありません。トレードオフの問題です。「オブジェクト指向なし」プロジェクトの良いところは「オブジェクト指向技術者を必要としない」ことです。実際，今の日本の開発現場には，オブジェクト指向をきちんと使いこなせる人が少ないので，特に規模の巨大なプロジェクトではそれに見合う数の技術者を集めることはできないでしょう。
一方，「オブジェクト指向あり」の場合は，ちゃんと設計すれば「変化に強く，保守性がよく，再利用可能」なシステムになるのですが，それには「オブジェクト指向技術者」が必要です。これには教育コストも含まれます。
実際のところ新しい技術に関してはほとんどがオブジェクト指向ベースになっていて，現場の技術者からは「最近の技術は難しくてよくわからない」とか「最近の技術なんて結局現場では使えないんじゃないの？」という話はよく聞きます。
これは，新しい技術をちゃんと理解するために必要な「オブジェクト指向の知識」が足りないことが大きく影響しています。例えば，ソフトウエア・ファクトリなどの書籍でも（米国ではオブジェクト指向が当たり前なのかどうか知りませんが），UMLのダイアグラムやオブジェクト指向設計を当然理解しているという前提での記述が目立ちます。
このようなシステムジェネレーション・ギャップによって，多くの現場でユーザーやシステム開発者が本来享受できるはずのメリットが得られない状況になっています。
需要と供給の悪循環
では，オブジェクト指向ベースの技術だらけなのに，なぜ日本で「オブジェクト指向」が浸透していないのか，その理由を考えてみましょう（図3）。
|
|
| 図3●需要と供給の悪循環 [画像のクリックで拡大表示] |
例えば，最近のユーザー企業が出すRFPには「変化に対応できること」などの要求が目立ちます。ユーザー企業が「変化に対応できること」を望んでいるとした場合，開発側はどうするでしょうか？
「変化に対応できること」がユーザーの望みであって「オブジェクト指向で作れ」と要求されているわけではありません。とすれば，システム開発を行う企業は，なるべく教育コストをかけずに効率よく開発したいので「ツール」を導入しようと考えます。「ツール」のパンフレットを見ると「変化に強くなる」などと書いてあるからです。もちろん最新の技術にも対応したいので，最低限のUMLの教育などは実施しています。しかし，ツールを導入しても，UMLの表記法を覚えても，「オブジェクト指向」ができるようになるわけではありません。
現場の技術者の中にはオブジェクト指向をちゃんと勉強している人もいます。そうした人は「ツールやオブジェクト指向言語を導入したところで，きちんとオブジェクト指向型で開発しないと変化には強くならない」と理解しています。それを上司などに提言すると，「じゃ，それを説明してみろ」という話になるのですが，なかなか理解してもらえません。短時間でオブジェクト指向の必要性を説明し，理解してもらうのは難しいからです。しびれを切らしてそのような勉強熱心な開発者は退社するというケースもよく見られます。
結果的に，開発は従来型のまま進められて，ユーザー企業にリリースされるわけですが，新しい技術を使っていても従来型で行っているため「変化に強い」などのメリットはほとんど出ないという構造になっています。
つまり，ステークホルダーの誰からも直接「オブジェクト指向」は必要とされていないのです。
もちろんシステム開発企業も，標準化を取り仕切っている専門の部門などではこのような状況を理解しています。しかし，自社の大多数の技術者がオブジェクト指向を勉強していない状況で，リソースを最大限に活用するためには，従来型の技術者がわかる方法を採用するしかありません。ツールを使って変更を反映できるようなコードを自動生成するといった小手先の対応ではたいして変化に強くならないのはわかっていても，そのような手段を取ることが多いようです。
ツールなどを導入したからといって，それほど柔軟性・保守性・再利用性が良くなったりしない→効果を高めるためには，オブジェクト指向を導入する必要がある→しかし，今の日本ではオブジェクト指向を使いこなせる技術者が少ないので，教育コストがかかる，といったトレードオフの関係になっています。
オブジェクト指向以前の問題
もっとも，これはオブジェクト指向に限ったことではありません。
現場のアプリケーションを見ると，正しく構造化分析をされたものでないことがほとんどです。DOA（Data Oriented Approach）できちんと設計したものは，それを使ってないものの7割程度ロジックを削減できると言われていますが，データ・モデルがきれいなものはあまり見たことがなく，ホスト・コンピュータのレイアウトそのままということも頻繁にあります。そのような状況なのに，アプリケーション開発の部分でオブジェクト指向が入ってきて，さらにアスペクト指向などの新しいパラダイムも登場しています。
もちろんちゃんとしている組織もあります。しかし多くの現場では，ホスト・コンピュータ上でCOBOLでフラット・ファイルを使っていたころのやり方が，いまだに脈々と使われていることも多いのです。
DOAとオブジェクト指向の差はそれほど大きくないかもしれません。ちゃんと構造化分析を行ったものとDOAの差もそんなに大きくないのかもしれません。しかし，ちゃんとしていなかったツケが積み重なって大変な状況を作っているのが現在のシステム開発の現場だと思います。
誤解のないように言っておきますが，DOAや構造化分析が時代遅れの技術と言いたいわけではありません。どれもシステム開発の必要知識だと認識しています。そして現在のプラットフォームではオブジェクト指向もその同列に位置するということです。例えば，リレーショナル・データベース（RDB）はDOAの考えのほうがうまくいくケースもあるので，プロとしては，両方の技術を押さえて代替案を多くだせる必要があります。
システム開発の基礎としてのオブジェクト指向
今の技術を有効活用したり，新しい技術を理解しやすくするためには，「オブジェクト指向」が必要です。目前のプロジェクトで採用しないとしても，トレードオフを理解するためにやはり必要になるでしょう。
技術的には，オブジェクト指向はもう20年以上前からある枯れている技術なので，新しすぎて適用したら危ないというものではありません。実際に活用して得をしているプロジェクトもたくさんあります（私もたくさん得しています）。結局，残るは「人」の問題です。
「人」と「教育コスト」の問題はとても大きな問題です。しかし，ちゃんと使えている人は，同じお金を払ってもより多くの得ができます。だからこそ筆者は，全体が一気に転換するのは無理だとしても，少しづつでも「オブジェクト指向はシステム開発の基礎知識の一つ」という方向に向かっていくことが，日本のソフトウエア業界にとっては良いと考えています。
「オブジェクト指向」は専門書を見ると大変抽象的で難しそうですが，実際にやってみるとたいして難しいことを言っていないことがわかります。もともと人間にわかりやすくなるように開発されたものなのですから。本当に“オブジェクト化”した人は，開発がある意味でとっても楽になり，わかりやすくなります。そのため，オブジェクト化された人はオブジェクト指向がない世界には戻れないと言う人がほとんどです（当然私もそうです）。
オブジェクト指向の教育に関しても，どうしてもオブジェクト指向が理解できなかった人を“オブジェクト化する”教育テクニックもいろいろと生まれています。手前味噌ですが，筆者が開発した「オブジェクト・ゲーム」は，年齢や役職を問わず短時間でオブジェクト指向の良さをわかってもらえる方法です。日本にオブジェクト指向技術者が増えてほしいので，手法自体はオープンソースのような扱いにしています。
今回は，オブジェクト指向と現在のシステム開発の現状について書いてみました。要求開発は，ビジネスモデリングにおいて「オブジェクト指向」が導入されている手法です。次回は，システム開発に柔軟性・保守性・再利用性をもたらすオブジェクト指向技術を，ビジネスモデリングに適用するとどういうトレードオフをもたらすかを考えて見ましょう。
|
| （牛尾 剛＝要求開発アライアンス） |
