[ObjectDayパネルディスカッション]
「オブジェクト技術導入の落とし穴」実施報告 (後編)
オブジェクト第1事業部技術コンサルティング室 羽生田栄一
 前編へ |
では、｢オブジェクト指向の落とし穴｣パネル報告の続きです。今回はオージス以外から参加していただいた3人のパネリストのプレゼントじゃなかったプレゼンとそれに関連した会場との質疑が中心です。
OO技術導入に関する会場との質疑
外部パネリストの報告の前に、前半を総括する目的で、会場を含めてQ&Aの時間が取られました。「山口さん、重見さんの報告にあるように、オブジェクト技術をうまく組織に導入するのはなかなかむずかしいようだが、何か実効的な解決策は無いものでしょうか」との司会の問いかけに、パネリストから次のような実効的な回答がありました。要は「最初から完全を求めるな」というものです。
OO技術の段階的導入法
これは非常に重要なことで、初めから高いところを狙うというのは非常に危険です。組織の規模にも拠りますが、ある規模以上のチームを対象とする技術導入は、なだらかな学習曲線を設定して既存技術との連続性を強調し、その一方で先行する精鋭部隊に高いレベルでの技術習得をさせておく、という2フェーズ戦略が有効です。
井上さんの報告
次に、横河電機の井上さんからの発表がありました。タイトルは「オブジェクト指向技術は常識化する」というもので、ちょっと「正義は勝つ」のようなノリに聞こえますが、内容を聞いてみるとやはりこちらも落とし穴だらけ。まぁ、そういうパネルなんですからしょうがないですけど。
はじめに軽く井上さん自身のOO歴の披瀝（これがなかなかうらやましい経歴でして、井上氏はGEにおいてあのRumbaughから直接OMT法の手ほどきを受けているのです!）のあとで、OO技術適用の必然性を、ニーズ(言語、ツール、方法論、パターンといった発展)とシーズ(OOでないとどうにもならないほど複雑な分散やモバイル等の要求)の側面から説明しました。では、オブジェクト技術を導入すれば薔薇色の未来が、という風になるかというと、まだOOにはいろいろな問題点があると指摘します。
「オブジェクト指向では現実世界に素直に対応したオブジェクトを識別して定義すればよい」というが、自然でないオブジェクトの導入が結構必要になる場合が増えている、とくにデザインパターンは熟練したエンジニアでなければ思いつけないような設計上のオブジェクトを導入する技術だといえるという指摘は、重要でした。評者も常々、オブジェクト指向とパターンとは発想のベクトルが異なるのであり、パターンにはオブジェクトに欠けている協調や相互依存といったオブジェクト集団に関する制約を与えるための彌縫策という側面があることを強調してきました。今後のパターン研究の結果、もう少しフォーマルなオブジェクト協調の定義が可能になることを期待しましょう。（そのためには、インターフェースの概念に状態の概念を追加して補強した「プロトコル」概念が必要になることでしょう。しかし、それだけでは複雑な集団の相互作用記述には不充分ですが…実は、GOFの1人であるRichard Helmは今私が祖述したのと逆の方向をたどってデザインパターンに行きついたのですが、皮肉なことではあります。）
次に、「分析から設計，実装までオブジェクトが一貫して扱える」というテーゼが俎上に上げられます。いったい、どこまで分析を進めたら分析モデルは完了といえるのか、分析モデルはそのまま設計モデルの初期状態と考えてそれを詳細化するとナイーブに考えてよいのか、という問題です。実はこの問題は、この後の、山城さんや酒匂さんも取り上げており、オブジェクト指向開発の一番本質を問う疑問だということができるでしょう。評者自身の回答の一部は、『新人およびOO初心者に贈る「オブジェクト指向」本格入門 ４．開発プロセスとパターン/アーキテクチャ』およびそこに示された図5をみてください。
さらに、「クラス・コンポーネントの再利用はむずかしい」という指摘をします。なぜならば、事前にホットスポットを想定してフレームワークやコンポーネントを用意しておいても、予想していない部分の拡張が求められる可能性が常にあるからです。またライブラリやコンポーネントを保守管理していくのも意外にコストが掛かるわけで、そのための割り切りと適切な領域での集中的部品化コスト投下の両面作戦が必要です。そうした判断ができるためにも、マネージャクラスもOO技術の基礎やUMLダイアグラムの飛ばし読み程度はできるようになるべきだという主張は説得力がありました。
最後に、今後の課題として、オブジェクト指向は確実に常識化するが、その恩恵に本当に預かれるようになるためには、OO開発プロセス自身の可視化の手段の提供等、モデルや開発プロセスが今以上にわかりやすくハンドリングできる開発環境が必要ではないかと提案されていました。これは、開発自体を対象としたオブジェクト指向化ということで、第2オブジェクト指向化ともいうべき次世代の課題だと感じます。
井上さんへのコメント
この後、司会者のコメントとして、UML言語が話せるということとUMLを適切に運用して、ユーザーを理解したり説得したりプログラムを実現したりする実践的な運用能力とは別であり、それは日本語を話すことと小説や詩を書くことの違いに相当するので、そのためのUML綴り方教室のような実習形式のトレーニングがOO習得には欠かせないと述べていました。たぶん今後徐々に、アナリスト、アーキテクト、設計者、フレームワーク作成者、品質保証担当、などと分業化も進むでしょうが、その場合にも、論理的なUML文章運用能力が基本となることはいうまでもありません。井上さんの言いたかったことは、OOが真の意味で常識化するには、そうした基礎学力が前提になると言いたかったのだと思いました。OOは原理的にはよいものだが、うまく使いこなさないと思ったような効果は出ないですよ、という、これも先に重見さんの挙げたポイントの確認ということになります。
また、NJKの萩本さんからも、「世の中のものをオブジェクトとして自然に認識するときにはよいのだが、それをソフトウェアを使った仮想世界にマッピングしていく際にはどう設計すれば良いかのがわかりづらい」という現状のOOに対するコメントをいただきましたが、これは、アーキテクチャとドメインをどう繋ぐべきかということですね。OGISの重見さんが、Rational Unified Processにあるように、ドメインを含む分析モデリングと並行して、そのモデルの暫定情報も盗み見ながら第1次のアーキテクチャ検討を行っていき、そこに分析モデルを再参入する形で埋め込むようにする、という回答がありました。また、萩本さんからは再利用可能部品の技術トランスファーのむずかしさの指摘もあり、結局、組織的な計画のもとに無理のない範囲で段階的な技術導入を進めていく、生産性の｢革命的｣向上をもくろむ部品化もしょせんはそうした組織的な慣性の中での力学を踏まえた上でのコンポーネント化・フレームワーク化・パターン化にしないとすぐに挫折する、ということだと思います。
山城さんの報告
次に東芝の山城さんから発表がありました。山城さんの報告は、モデリングとコンサルティングという２つの視点から「落とし穴」問題を切ったもので、非常に明瞭にOOの現実が提示されたプレゼンでした。
まず最初に協調されたのはやはり、段階的導入の重要性でした。先ほどとは若干異なる切り口から、
という3段階を示されましたが、人間も組織もなにごとも正確な自己認識にもとづく分をわきまえた実践が結局は一番効果的であるということでありましょう。
次に、モデリングの切り口からいくつかの陥りやすい問題点を指摘されました。まず第1に、視点や対象、層や工程に応じてモデリングの方法は違うという点です。オブジェクト指向だからといって安易に区別しないで作業を進めると結局プログラムに繋がらないモデルになってしまうということです。ここでは、2種類の区別が重要です。いわゆる3層C/Sでいうところの「GUI、業務、DB」の各層の区別と、開発プロセスのフェーズに対応した｢ドメインモデル、アプリ分析モデル、アプリ設計モデル｣の区別の2種類です。3tierの設計法の普及に伴って、前者の区別は比較的に理解が進んできた観がありますが、いまだに後者のモデルの区別に付いては曖昧な理解のまま開発を進めている例を往々にして見かけます。「以前は、OOを使えば現実世界をシステムにマッピングできると思っていたが今はそう思っていない」と本音を吐露されたのも貴重でした。つまり、ドメインモデルと実装モデルは1対1ではない、ドメインは要求の表現、実装モデルは楽に実装できるためのガイドをするものである、ということで両者は目的が違うということですね。
モデリングに関して重要なもう1点として、「モデルはソースコードとは違うのだから、複雑さの管理に役立たないと存在意義がない」というのがありました。ソースコードより上位の設計情報や設計意図をモデルに表現すべきで、その点からも、ステレオタイプの利用は重要であるという指摘です。
次に、こんどは、コンサルティングという切り口からの指摘がなされました。個々では特に、チーム本体の教育に先行した少数精鋭部隊の立ち上げの重要性や、集合教育も馬鹿にしたものではなく「共通の言葉の共有」という点で最小限の有効性がある、共通の教育コース以外にさまざまな教育・学習資料を素材として用意しておくべきだ、といったような重要なアドバイスをいただきました。また、OO導入プロジェクトを成功させる最重要ファクターは、プロジェクトおよびシステム全体のアーキテクチャの適切な選択である、というコメントも身に沁みました。
この直後、会場から、「ドメインモデルと設計実装モデルは違うということだが、では、上流の能力は持っていない優秀なプログラマには前半フェーズで何をしてもらえばいいのか、遊ばせておくのか」との質問がありました。これに対し、2人のパネリストから「上流を無視した実装中心のプロジェクト運営で失敗して痛い目にあってもらうのも勉強になります」と「先行してツール作り・開発環境整備をしっかりやってもらう」という正負両方の回答をいただきました。
酒匂さんの報告
パネル最終を飾る酒匂さんのプレゼンは、最後ということもあり、今までのコメントの落ち穂拾いをしていただいた面が強かったように思います。ありがとうございました。その中でも特に、プロジェクト管理における人間的な側面とアーキテクチャ設計の重要性を協調されていたのが印象に残ります。
まず、コンサルの位置付けが要所要所でのアドバイザではなくプロジェクト管理までやらされたりと、プロジェクト担当者にもマネージャにも当事者意識がないことが多くそれがプロジェクトから成果を引き出せない大きな原因になっているという指摘です。また、ＯＯ以前のプロジェクト管理の手法やそこで培った経験ノウハウを利用せずに、OOはまったく違う開発方法なのだからと勝手に自己暗示に掛かって自分の持っているノウハウを破棄して管理の努力を放棄してしまう、というマネージャが多いという痛烈なコメントも頂きました。その時点でわかっている情報やメトリクスからおおざっぱな見積りとマイルストーンの設定を行う、常識的な意味でのプロジェクト管理を普通に行う、という言ってみれば「当たり前のこと」が単にオブジェクト指向開発だからという言い訳のモトにおざなりにされているということです。その一環として、簡単なものでよいにも関わらずメトリクスの収集利用の努力がほとんどなされていない、というものもあります（これは、まだ研究レベルでも定着したメトリクスがないといわれているOO特有の指標のことではなく、ごく一般的な人月や行数やクラス数やユースケース数といったその気になりさえすればほとんど負荷の掛からないものを少しでも収集して、少しだけ合理的なプロジェクト判断の材料にしましょうよ、というものです。注意して欲しいのは、あまりにもガチガチのメトリクス収集体制を敷くと今度はそれがプロジェクトの文化を歪めてしまうという別の要因になるのでそこは注意が必要です）。
以上の話とダブりますが、未だにくり返し型開発というものに対しての誤解があるようで、くり返し型になるときちんとした開発計画やマイルストーンが要らない、あるいはくり返し開発の見積りは不可能である、といったことを述べる人によく出会います。しかし、本来、ソフトウェア開発という困難な対象の複雑さを縮減するための「くり返し」なのですから、従来できていたことが全く通用しなくなる、と聞いた時点で眉に唾をつけてしかるべきです。将来情報が揃った時点で改定されることを予期した上でのおおよその工数見積りや開発計画とマイルストーンの設定は当然あってしかるべきです。逆に、くり返し型開発の罠としては、動くものが早期にリリースされるので、ユーザーに誤解を与え無理な過剰な機能追加要求を引き出しがちだ、という点があります。この点は、「くり返し」の意味とそこでのワークプロダクトの位置付けと目的をはっきりとクライアントに理解させた上で開発に入るべきという指摘がありました。
また、アーキテクチャ設計の不在という点もくり返し指摘されましたが、ここでも、分析から設計に繋がるシームレスなモデルはないのだから、業務分析はちゃんと行い、そこで出てきた業務モデルを、それと並行して検討されたアーキテクチャの中に埋め込むようにしていくという基本方針が述べられました。特に、業務分析は、オブジェクトモデルを作ることが目的ではないので、その業務の構造とダイナミクスを最大限表現できる手段を採用する必要があるということです。
以上まとめると、「十分な準備と訓練の上で当事者意識をもって開発を行え」ということになりそうです。この教訓は本日だけで何度聞いたことでしょう。ともあれ、プロジェクトを成功させるためには、技術者は最低10ヶ月、管理者も最低4ヶ月の訓練が必要だと酒匂氏は主張します。管理者でも、最低限、成果物の位置付けとある程度の評価ができることが必要だというのです。技術者に関しては、概念、プログラミング実習、分析・設計実習、プロジェクト、デザインパターン等の基本の習得と、パイロットプロジェクト形式のくり返し開発プロセスの実経験が必要であり、このメンバーが中核となって、以降のプロジェクト運営を進めていけるまでに成らねばならないわけですね。
最後の質問
以上で、すべてのパネリストの報告が終わり、最後に会場から1問だけ質問を受け付けました。その結果、「納期と予算の制約で、システムの一部にOOを適用し、残りは従来型というアプローチはありか？」という高度な質問を賜り、酒匂さんより、メトリクスの観点を強調した回答がなされました。回答の概要としては、まったくおっしゃるとおりであり、新しい分野であれば、一部にOOADを適用する、というのは行ってしかるべきである。ただし、真剣にメトリクスをとって、その値にもとづいて見積りを行い、判断すべき。OOでは測れるメトリクスはたくさんあるから、専門化と相談してその結果を利用すべきとのお答えでした。
以上で、時間は10分ほど超過した状況でありましたので、残念ながらここまでで本パネルを打ち切らざるを得ませんでした。とはいえ、会場よりは盛大な拍手を賜りましたし、アンケートの満足度のチェックも上々の点を頂きまして、一同、ほっといたしました。このような大観衆を前にしてのパネルディスカッションの有効な進行の仕方というノウハウをパターン化しておくことの重要さが身に沁みる一方で、ある程度のアドリブで場の状況で流れを切り替えていくことの醍醐味というものも感得したのであります。きっとこの両側面がプロジェクト管理というものにもあるだろうなぁ、と思いつつ、人生の究極の楽しみとしての「座談会」「連歌」「プロジェクト管理」というテーマはまだ誰も論じていないのではないか、しかし論じるに値する切り口を持っているな、と１つネタを見つけたところで、今回の報告を終わらせていただきます。
| © 1999 OGIS-RI Co., Ltd. |
|
![HOME オージス総研[オブジェクト第一事業部]](../img/green_l_small.gif){kind=small}