オブジェクト指向システム開発での必須知識
プロジェクトマネージャならば理解しておこう

豆蔵　萩本順三
2003/9/3

　最近のソフトウェア開発では、オブジェクト指向技術が必須となりました。このような中、プロジェクトマネージャは、オブジェクト指向技術を理解する必要があります。しかし、現状においては、プロジェクトマネージャが、オブジェクト指向技術について、どの程度の知識を、どのように身に付けるべきなのか非常に不鮮明な状況にあるように思えます。

　そこで本記事では、なぜプロジェクトマネージャはオブジェクト指向技術を知らなければならないのか。そして、もし知る必要があるとするならば、何をどの程度知る必要があるのか、ということについて、その概要を説明しています。

■反復型開発プロセスの必要性

　オブジェクト指向型開発において、従来のような各工程が滝のように順序よく流れるウォーターフォールモデルとは異なり、各工程を反復させるスパイラル型開発モデルが採用されています。いや、これでは現在の開発環境を正確に表現する説明ではありません。

　現状を正確に説明すると、現在のソフトウェア開発に求められているのが、スパイラル型開発モデルであり、その開発モデルを最も適切に柔軟に実践できる技術がオブジェクト指向なのです。なぜ、オブジェクト指向技術がスパイラル型開発に適しているかというと、ソフトウェアを目に見える構造として表現しやすいため、開発の単位を明確にしやすく、繰り返しの単位、並行開発の単位を定義することが容易であるからです。

　先端的ビジネスアプリケーション開発のプロジェクトマネージャは、このスパイラル型開発モデルで採用されている反復型開発プロセスのプロジェクトコントロールを行う能力が必要とされます。この能力を身に付けるためには、まず、なぜ現代の開発においてこのような反復型開発プロセスが必要とされるのか、その背景について理解しておく必要があります。表1をご参照ください。

旧クライアント／サーバシステム Webサービスなどを利用する 先端的なWeb利用システム 対象範囲 部門内・企業内 複数の部門、企業間連携 アーキテクチャ クライアント／サーバの2層システム 1〜N層システム ネットワーク LANまたはWAN LAN、WAN、インターネット 標準化 クローズ オープン 開発環境 単一 複合 構成 単一システム 単一システムまたは複数システムを統合化 ユーザー数 初期計画からあまり変動しない 初期の計画から大きく変動する可能性 緊急対応 ハード／ソフトベンダ型保証型 ハード／ソフトベンダ無保証型

表1　システム要件と開発環境の変化。参考図書：『Webシステムのデザインパターン』（Jonathan Adamsほか著、日本アイ・ビー・エム、2003、翔泳社）

　表1は、旧来のクライアント／サーバ系システムと、現代のWebを利用した先端的なビジネスアプリケーションシステムとの比較です。この図で重要な個所は赤字で示しています。ソフトウェア開発を取り巻く環境は、劇的に変化しています。

　いまでは、低コストかつパソコンを主に、標準化されたネットワーク技術とインフラ技術をベースとして、昔は考えられなかったような広域大規模なシステムを開発できるようになりました。このような中、新たな開発パラダイムの潮流として、オープン化があります。オープン化の波に乗ってソフトウェアの低コスト化が進み、さまざまなOS、ミドルウェアを組み合わせて開発するという複合型の開発スタイルが主流となっています。

　この変化で絶対見落としてならないことが、ハード／ソフトベンダ保証型開発から、無保証型開発へと移っているという事実です。複合されたOS・ミドルウェアをベースとする開発では、誰がそのソフトウェアのあらゆる保証をするかというと、開発を担当した組織（システムインテグレータやユーザー）ということになります。旧来のシステムでは、システム開発で問題が発生した場合、ハード／ソフトベンダがその問題打開の解決法を提示するよう動いていましたが、他社のOS・ミドルウェアを組み合わせたシステム開発では、どのハード／ソフトベンダも保証のサポート範囲を超えた問題として真剣に取り扱ってはくれないでしょう。

　そこで頼りになるのがオープンな標準化という薄い保証なのです。つまり、標準化された技術であるならば、どこから出されたものであろうと、サポートされている機能・利用法はほぼ利用可能であるだろうという期待の上にオープン系開発は成り立っています。しかしながら「薄い保証」と書いたように、この保障を信用するのは危険です。なぜなら標準化の規定できる範囲は限界があるからです。よって、このような開発では、ソフトウェアの設計と実装に多くのリスクが潜んでいるものです。

　これを従来のウォーターフォール型開発モデルで開発していては、危険極まりありません。例えば、要求分析、基本検討を経過した10カ月後から設計に入り、その2カ月後に実装して、もし基本検討が対象となるアーキテクチャに適合しなかったらどうなるのか、考えただけでもぞっとします。実際の、ハードウェア、OS、ミドルウェアの上で、ビジネスアプリケーション開発で達成すべき課題を実装し、動かしてみることこそ、現在の開発では必須となっているのです。

　そこで、リスクの高い問題から先に繰り返しながら開発するというスタイルとしてスパイラル型開発モデルが注目されるようになり、現在では、スパイラル開発において、計画的に開発を反復させるプロセス（反復型開発）が誕生したわけです。

■反復型開発プロセスを制御する

　反復型開発プロセスが必要とされる背景については、前述したとおりです。ここでは、反復型開発プロセスのプロジェクトコントロールの能力について話をしましょう。反復型開発プロセスとして代表的なRUP（ラショナル統一プロセス）を例に説明しましょう。ほかのプロセスの場合でも反復の考え方については類似するものですので、読者が利用される反復プロセスにもこれから話すことは当てはまると思います。

　RUPでは、フェイズとして「方向付け（Inception）」「推敲（すいこう：Elaboration）」「作成（Construction）」「移行（Transition）」があります。このフェイズの中で、「ビジネス分析、要求分析、システム分析、システム設計、テスト」といった従来工程と呼ばれていたものが、反復または並行して実行されるといった開発モデルです。これはDisciplinesと呼ばれていますが、簡単にいうとサブフェイズのようなものであり、分析、設計、実装が各フェイズの目的に合わせて繰り返し実施されることになります。詳しくは図1を参照してください。

図1　RUPの概要。出典：『The Rational Unified Process』（Philippe Kruchten著、2000、Addison Wesley）

　このような開発モデルでは、おのずからテスト工数や管理工数は増大する傾向になり、プロジェクトマネジメント技術も複雑困難になってしまいます。しかし、反復開発におけるこのようなリスクは、反復を利用しない場合の多大なリスクとてんびんにかければ、必然的なものとして受け入れるべきことを、ここまで読んだ読者は理解していただけるでしょう。

　RUPの開発プロセスを語るとき、その重要なコンセプトとして、「ユースケースドリブン」「リスクドリブン」「アーキテクチャ中心」があります（注1）。この3つのコンセプトは密接な関係があります。

（注1）開発プロセスの具体的な説明は以下の記事を参考にしてください。
	いまなぜ開発プロセスを注目するのか　（＠IT Java Solution）

　プロジェクトマネージャの必須の技術として、反復計画を立てる際に、これら3つのコンセプトをどのようにしてプロジェクトに適用し、反復計画を立てるのかというテクニックが必要とされることになります。

　ユースケースドリブンとは、ユーザーから見える機能単位に開発を進めることです。また、リスクドリブンとは、リスクが高いものから開発を進めることです。そして、アーキテクチャ中心とは、ソフトウェアを動かすコア・アーキテクチャをできるだけ早い段階（具体的には推敲フェイズ：Elaborationにて）で確立させるアプローチです。この3大コンセプトをどのように反復計画に役立てればよいのでしょうか。

　そのヒントとなるのが図2です。これは、筆者がRUPの3つのコンセプトを実践する際に頭の中にあるイメージです。このイメージは、ほかの反復型開発プロセスに共通するものです（ただしXPではリスクドリブンという考えはあまりないようです）。

図2　反復開発における3つのコンセプトの考え方

　それでは、この図2を使って反復計画について説明しましょう。下記に反復計画を立てる際の筆者の思考過程を示します。

Step1：リスクの高いものから試す（リスクドリブン）

　開発の中で最もリスクが高いものを選出します。リスクにはリスク要因で書かれているようなものが挙げられます。例えば、「再利用性・拡張性」や「パフォーマンス要件」といった非機能的な要件が挙げられた際に実現可能かどうか怪しい場合は、それらがリスクとなります。

　また、「アイデア創出」という変わったリスクもあります。これは例えばユーザーにシステムの有効性を訴えるようなユーザビリティに関するようなアイデアを出さなければ、開発そのものの計画が中止となるといったリスクです。これは、非常に当たり前の話ですが、危険回避という守りのリスクと異なり、付加価値創出という攻めの弱さからくるリスクであるためあいまいにされがちなリスクでもあります。

Step2：アーキテクチャ中心

　このリスクは、どのようなアーキテクチャによって回避できるのかという、アーキテクチャの大枠を設計します。これは、実装するアーキテクチャをベースに検討されます。実装するアーキテクチャは、具体的なOS、ミドルウェア、フレームワークをベースとして、その上でどのように実現するかを考慮します。例えば、パフォーマンスに関するリスクがあれば、パフォーマンスを満たすアーキテクチャを実現できるミドルウェアやフレームワークの選定から、その上で、どのようなアーキテクチャを付加すべきなのかという設計を行い、その骨格部分を実際に開発し、検証するのです。もちろん、アーキテクチャとは無関係なリスクもありますが、そのようなリスクは、アーキテクチャと別次元で対策が講じられることになります。

Step3：ユースケースドリブン

　リスクドリブンによって選択されたリスクをどのようなアーキテクチャで実現するのかということを決めたら、次は、そのアーキテクチャをどのユースケース（ユーザーから見た機能）で検証可能かを決め、そのユースケースを反復計画によって開発の対象とします。 ユースケースは、リスクとかアーキテクチャに完全に対応するものではありません。要は、どれがリスクやアーキテクチャの検証に最適かでユースケースが決定されるのです。

　Step1〜3で、ようやく3つのコンセプトを融合させた反復計画が立てられるようになります。このような計画を分析者、アーキテクトといったプロジェクトのロールを持つメンバーが1つに束ねて開発計画を立てて、そのスケジュールの進み具合を監視・コントロールすることがプロジェクトマネージャに求められるのです。

　筆者も、このような考えを知り、マネジメント技術を向上させることができました。筆者の開発マネジメントのやり方は、Step1とStep2を重視しており、Step3の考えはあまりありませんでした。この問題は、実際のユーザーからの利用単位（ユースケース）で開発を進めていかなかったため、最終フェイズに行きつくまで、開発の進捗（しんちょく）がよく見えないという状況に陥ることが多かったように思います。私のように古いタイプのプロジェクトマネージャにとってみると、ユースケースドリブンは最初なじめないのではないでしょうか。

　しかし、実践してみると進捗がとても分かりやすくなります。少なくともユースケースXとYはユーザーとともに確認したので、進捗Zパーセントというように、定量的な把握ができるようになります。

　しかし、アーキテクチャ中心は、アーキテクチャ全体に対応しつつ中身を薄く作り、徐々に中身を埋めていくといった反復型（イテラティブ）になります。ユースケースは、ユーザーから見た単位で積み上げていく漸増型（インクリメンタル）という、異なる反復戦略を取っています。異なる反復戦略を並行して進めるという開発テクニックは難しい問題となり、この辺の開発の進め方について経験が豊富なエンジニアを開発メンバーに入れる必要がありますが、その詳細についてはまた別の機会にお話ししたいと思います。

■モデリング作業を制御する

　オブジェクト指向開発の経験のないプロジェクトマネージャは、オブジェクト指向開発では常識となるUMLモデリング主導の開発を制御することが困難となります。このことはプロジェクトにとって致命的です。

　では、プロジェクトマネージャは、どこまでUMLモデリングについて学べばよいのでしょうか。欲をいえば、ビジネスモデリング、要求モデリング、設計モデリングすべてを学ぶ必要があるでしょう。しかし、それは非現実的です。また、もしすべてを学んだとしてもプロジェクトマネージャとして成果を出せないこともあります。なぜなら、モデリング作業を制御することができなければ、モデリングが適当でもプロジェクト的には成功できないからです。

　では、モデリング作業を制御するとはどういうことでしょうか。それは、マネジメント的な視点を持ち、モデリング作業に投資対効果を見極め、モデリング作業以外の開発作業とのトレードオフを考慮しつつ、開発メンバーにモデリング作業を行わせる習慣をプロジェクトチームに植え付けさせることです。

　オブジェクト指向開発における失敗事例を分析すると、大抵はオブジェクト指向で導入される技術要素をマネジメント的に制御できなかったということが多いのです。その代表的な技術要素の1つとしてモデリング作業があります。モデリング作業は、優秀なモデラーによって問題領域を視覚的にとらえることができます。この効果はチーム開発において遺憾なく発揮されます。また、今後においてはビジネスとITを融合したモデルをユーザーと開発者で共有する道具として重要な役割を担うことになるでしょう。

　しかし、目的やコスト意識のないモデリング作業は、プロジェクトに多大なドキュメントと作業コストだけを作り出し、チーム内では消化不足を起こしてしまいます。やるべき作業も見失ってしまうことになりかねません。モデリングは明確な目的が必要なのです。モデリングの目的とは、先に述べた反復開発の「ビジネス分析、要求分析、システム分析、システム設計、テスト」といったDisciplinesの中で定められるべきものです。目的に応じてモデリング対象とモデリングのゴールを決める必要があります。プロジェクトマネージャは、反復開発のDisciplinesにおける目的に合わせてモデリング作業をコントロールするべきなのです。

　つまりは、プロジェクトマネージャは、モデリング作業をマネジメント的視点で観察・監視する目を養うことが、モデリングを学ぶことより優先すべきなのです。また、そのような目を、チーム全員に持たせることも重要なことです。

■いま、プロジェクトマネージャに必要なこと

　では、どのようにすれば、そのような目を養うことができるのでしょうか。それは、成果重視で物事を考えることです。例えば、開発を終えた際、または各フェイズのマイルストーン評価時に、その開発で作成したUMLモデリングにかかわるドキュメントの成果について、チーム全員で、「このドキュメントは開発に役立ったのか」「今後役立つ可能性があるのか」について評価することです。もし、役立っていないように思えるならば、「そもそもやりすぎ（工数のかけすぎ）」「モデリングスキルが足りないのに時間をかけすぎ」「目的がずれている」などの原因があるはずであり、今後、対象のモデリング作業を行う際に投資対効果の観点から、対策を立てる必要があるでしょう。

　これからのプロジェクトマネージャは、いままでのマネジメント能力に加えて、反復型開発プロセスの必要性を踏まえ、反復型開発プロセスを制御し、その中で行われるモデリング作業を統制することが重要です。そのほかにも、まだまだお話しすべきことはたくさんあります。しかし、オブジェクト指向開発も従来型開発の延長線上にある技術ですので、いままでのマネジメント技術を生かしつつ、ここでお話ししたノウハウを身に付けることが、先端開発を行うプロジェクトマネージャへの道のりとなることは間違いありません。筆者もこのようなマネージャを養成し、オブジェクト指向開発が無駄なく円滑に実施され、オブジェクト指向開発の有効性が業界で認知されるよう今後も努力していきたいと思っています。

筆者プロフィール
	萩本順三●豆蔵　取締役。20後半でエンジニアに転身。その後、泥臭い開発の中からソフトウェアの構造をとらえることに関心を持つ。それをきっかけとしてオブジェクト指向技術に出合う。最初は同技術を疑い続けていたが、いつの間にかオブジェクト指向の虜となってしまい現在に至る。今月下旬には、同社の取締役会長 羽生田栄一氏と2名で「達人養成塾」と題して「徹底モデリング講座」と「OOプロジェクトマネージャー養成講座」を開催する。現在その準備のために忙しい毎日を送っているという