ObectSquare

[ObjectDayパネルディスカッション]

「オブジェクト技術導入の落とし穴」実施報告 (前編)

オブジェクト第1事業部技術コンサルティング室　羽生田栄一

後編へ
後編へ

はじめに

先日行われたObjectDayの最後を飾る形で（などというと並行セッションの方々に申し訳ないですね。あくまでもその場で司会を務めた私の主観でそう感じたということでお許しあれ）パネルディスカッションが開かれました。普通このような１私企業主催のパネルということになると、あたりさわりのない事勿れ的なテーマが選ばれるのが常ですが、そこは大阪商人の伝統？と大衆芸能のセンスを分かち持つオージス総研ですから、お客さんがここが聞きたい、と思っていてしかも面白い、議論が白熱するテーマでやれ、というありがたいお達し(*)で、敢えてこのようなテーマが選ばれたわけです。

オブジェクト指向がどんなに優れているか今さら議論するのも興ざめだし、かといって事例紹介は他のセッションでいろいろ行われている。ここはやはり、実際にオブジェクト指向開発を経験した人々が集まって、どんなところで失敗したか・失敗しそうになったか、何に注意しないと破綻するか、以後プロジェクトを実施する人たちへの実践的アドバイスをパネル形式でやったら、上の条件を満たす聴衆満足度(**)の高いパネルになるのではないかと思い至ったのです。こうしたテーマは日頃の表面的なオブジェクト指向の解説の中では出てきませんが、みんな知りたいと思っていることでしょう。しかし失敗を話したり聞いたりする機会はいまの日本ではあまり多くありません。ということで、すんなり「落とし穴」がテーマのオブジェクト技術に関するパネルの登場となりました。

参加していただいたパネリストは以下のごとく、うちのエンジニアの2名を除くと(山口さん、重見さん、他意はありません。たぶんこのパネルの後では、パネル参加者にとって第1人者と思って頂けるようになっていればお互い幸いなのですが!?)どなたもこの分野の第1人者。面白くなかったらおかしい、司会者の無能のせいだというプレッシャーのもとで火蓋は切って落とされたのです。唯一の心配は5人のパネリストで1時間半はいかにも短いということだけでした。

パネリスト紹介

井上健さん：横河電機(株)ＩＴパッケージ開発部

一般論および技術移転，パターンの観点から
GE時代のRumbaughの下でOMTおよびOOの武者修業

山城明宏さん：(株)東芝ＳＩ技術開発センター

OOコンサル，モデリングの観点から
あのBoochの赤本の訳者

酒匂寛さん：Designer’s Den Corporation社長

システムアーキテクチャ，プロジェクト管理の観点から
あの言語Eiffelの作者B.MeyerのOO入門の訳者

重見剛さん：(株)オージス総研オブジェクト第1事業部

ＯＯシステム開発のコンサル、教育の観点から

山口健さん：(株)オージス総研オブジェクト第2事業部

ＯＯシステム開発経験の観点から

パネルの方向付け

まず司会のほうから今回のパネルの趣旨説明がありました。要は、オブジェクト指向技術は概念や教科書的な話のレベルでは定着したが、本格的な適用、特に大規模システムの開発プロジェクトはまさにこれからスタートしようとしている、そうした状況で、問題が起こる前にOO適用上の落とし穴を事前に点検しておこうじゃないか、というのがまさに目的です。

オブジェクト指向の3種の神器ともいうべき、カプセル化・継承・ポリモルフィズムだけでなく、OOADといった分析設計の重要性も認識され、さらにデザインパターンのような設計レベルの非機能的な要件を作りこむための技法の重要性も理解されるようになってきました。さらに何が欠けているというのだ、と思われても不思議ではありません。

ここで駄洒落好きの両H氏の片割れである司会者は「オブジェクト“しこう“の罠」ということを言い出します。次のようなことです。

つまり、世の中にオブジェクト指向フリークと呼ばれるようなオブジェクト技術のよさに惚れてそこに強い思い入れを持っている人たちの牽引していく時代から、徐々に良くも悪しくもビジネス指向で効率的に保守性よくアプリケーションが開発できるからたまたまオブジェクト指向を選ぶという実務派の時代にまさに移行し始めているということを上の文言は反映しているわけですね。

それともう１つ本パネルの趣旨を支えている大きな流れはパターンの普及です。4人組(Gang Of Four)の23個のデザインパターンのみならず、アナリシスパターンやアーテクチャパターン、プロセスパターンなどさまざまなパターンの有効性が認識され出しています。典型的な問題状況に対して有効な解決策がひとまとまりのノウハウとして提示できれば、それは技術的な知識カタログとしてみんなで共有できる、ということでパターン記述と共有の有用性がわかってきました。その流れの一環として、やってはならない手、反面教師的な落とし穴とその回避策をノウハウとして問題状況別にまとめた「アンチパターン」というものが提唱されてきています。そこで私たちも、ここで自分たちの開発経験、プロジェクトで失敗した経験をできるだけ共有できる形にまとめてみなさんの参考に資する形で提供する場を用意しようという思いもありました。そのような試みとしては、ウェブスターさんの「オブジェクト指向開発の落とし穴」(プレンティスホール)という名著が1995年に出ています。落とし穴的現象の生じる
　　　　　前兆、結果、検知法、回復法、予防法
をアンチパターン風にまとめたものです。

しかも次のようなOO概念からプロジェクト管理や政治的な問題まで含めてさまざまな観点から問題点を抽出してくれています。

できればその出版から5年後の現時点で、状況はどう変わったかを検証してみたいという希望もあったわけです(時間の都合で、そこまでは突っ込めませんでしたが）。

司会者からのこうした前振りの後、いよいよ各パネリストからのポジションの提示とそれに関するディスカッションがスタートしました。

システム開発における落とし穴

まず最初のテーマでは、オージス総研で主にFORTEを使ったオブジェクト指向開発の経験の豊富な山口さんから３つの事例が示されました。

いずれも本当によく目にする失敗プロジェクト事例です（いったい、どこでそんなによく目にするかというのは聞かないでください;-)。

かいつまんで言うと、事例1は、GUI中心に開発が進みコードは各ボタン等に(コールバック関数として）重たくぶら下がっている、つまりシステム全体での設計やアーキテクチャなどまったく考えていないケース。
事例2は、スパイラル開発でプロトタイプを作りながら開発を進めるのだが使い物にならずそれを捨ててやり直しになったという、プロトタイプの目的をわきまえずにきちんと目標管理したくり返し開発になっていなかったため失敗したケース。
事例3は、特定ミドルウェア（やツール)製品を選択し、その製品ベンダーの提供する設計方法(ホワイトペーパーやベンダーコンサルからの情報）にそのまま乗っかって開発を行う、しかし製品依存の偏った設計に陥りやすく拡張性・再利用性に問題が生じるケース。
どれも耳の痛いケースばかりですが、少しでも要求分析やアーキテクチャ設計に要員と時間を割いていれば回避できて、結局は時間的にも工数的にも節約できたはずの問題ばかりです。要は、オブジェクト指向分析設計の基本を押さえて、上流工程を軽視せず、安易なプロトタイプ中心開発ではなく、要求に耐えうる適切なアーキテクチャの設計をコアにしたくり返し型開発が必要だ、ということです。

特に、事例2にあるように時として「スパイラル開発」というスタイルの開発プロセスが一般に誤解されている向きがあるので、特にプロジェクト管理をする人はその点に気をつけましょう。スパイラルとかくり返し型というとき、好き勝手に気ままに分析・設計・実装をやり散らかしてプロトを実行してみてはその不具合や不足個所をまた同じようにアドホックにくり返し作業し…というイメージを持たれている場合がありますが、それは誤解です。オブジェクト指向で目指すくり返し型開発は、あくまでもユーザーのニーズと早期に検証したい技術課題によって優先順位づけられた少数のユースケース実現を目標に設定された期間限定の分析・設計・実装サイクルを毎回達成度と発見された課題の評価を得て次のサイクルに移行する、というきわめて整然と制御されたプロセスなのです。

この山口さんのポジション発表に対して、他のパネリストからも簡単なコメントを頂きましたが、結局、次のような教訓に落ち着きました。まじめに分析と設計をして開発を進めましょうね、というあたりまえの結論です。

OO教育・コンサルにおける落とし穴

さて次に登場したのが、オージス総研の技術コンサルタントの重見さんです。彼のポジションは、主に、クライアントさんに対してオブジェクト指向導入教育をしたり、パイロットプロジェクトにコンサルタントして参加する際の経験をもとにしています。

第1に、「なぜOO技術を導入するのか」がクライアントに明確に認識されていないとうまいOO技術導入はできないよ、ということです。これは、司会者が「オブジェクト嗜好」という言葉でアンチパターンとして提示したものに他なりません。この病にかかっていると、現場サイドがOOでやってみたいという熱意と管理者層の「いったいどんな効果が出たのかよくわからなかったので、OO導入は見送り」という安易な結論とが悲しい結合を起こすことに気がつきません。OO技術を導入する明確な目的と意思、および導入効果を評価する記述を明確にし、利害関係者の間での共通の認識としておく必要があります。

第2に、「OO技術に過度の期待をしていないか」という問いがクライアントさんに対して発せられました。OOは問題解決の有用な道具としては利用できるが、それ自身がソリューションなのではない、ということに気づく必要があるということです。ユーザーのニーズや組織のもつ制約、技術的な前提の中で、与えられた問題の解決をどのような枠組みとメカニズムで行うのか、そこにどんな形でOO技術が適用できるのか、そのトレードオフも含めて検討せよ、ということです。再利用性や保守性、生産性の向上のためにはオブジェクト指向以外にも、ツールの導入・ミドルウェアの共通化や構成管理や教育や環境整備やプロジェクト管理やらといったもろもろの要因がトレードオフを伴って利いてくるからです。

第3に、OOという新しいパラダイムの「技術移転を受けるに十分な体制」を整えているかが問われます。トレーニングや導入教育では、単に言語の知識だけでなく、UML、OOAD技法、開発プロセス、開発ツール、等の総合的なトレーニングが効果的であるにもかかわらず、概してクライアントは教育を軽視しがちです。また、経験者と初心者、プロジェクトリーダーとアーキテクトとデザイナとプログラマ、テスターの役割分担や構成比率もよくよく考えて適切なパイロットプロジェクトを企画せねば、導入教育としての効果、特に次期プロジェクトメンバーの養成は効率良く行えません。その意味で、コンサルを受ける際に最も重要なのはクライアント側の「主体性」だと重見さんは強調しています。コンサルタントの言いなりになっていないか、極力自分たちだけで開発する努力をしているか、要は自分の頭で考えて導入プロジェクトに臨んでいるか、ということです。

以上3点がオブジェクト第1事業部のOOシニアコンサルタントである重見さんからガツンと言ってもらった内容です。ここでの要点は、せっかくオブジェクト技術を導入しようとするのだから、もっと主体的に目的意識をもってトレーニングやコンサルタントをうまくしゃぶりつくすような体制のもとで臨んでくれたほうが、コンサルする側もクライアントさんも共により幸福になりますよ、という提言でした。ちょっと、会場がシーンとなってしまったような気もしましたが、こんなことお客さんに直言してしまっていいの？という内容にも関わらず、後で聞いてみると、聴衆のみなさんは結構真剣に納得して聞いておられることがわかってほっとしました。

次回は、後編：オージス外からのパネリスト3人のポジションと会場との質疑応答 です。
お楽しみに...

(*)まぁ、自分で出したのですが。

(**) アンケート結果から、回答を寄せてくれたパネル参加者の過半数の方々から内容に「満足」と答えていただけました。ありがとうございました。

© 1999 OGIS-RI Co., Ltd.
HOME　オージス総研[オブジェクト第一事業部] HOME TOP　オブジェクトの広場 TOP