メディア

鈍重な開発チームは鈍重なシステムを作る？/パート3：役割とポリシー（後編）：The Rational Edge（4/4 ページ）

» 2007年11月20日 12時00分公開

[Scott W. Ambler, Per Kroll，IBM]

柔軟なアーキテクチャ

　高効率ソフトウェア開発ガバナンスの目標の1つが、ビジネスの中での柔軟性と応答性の実現だ。そうすれば、ITシステムの整理と進化に柔軟性と応答性が必然的に伴ってくる。高効率ガバナンスは、柔軟なアーキテクチャによって実現される。それは、変化するビジネスニーズに開発チームが効果的に対応できるようになるためだ。現在最も柔軟なアーキテクチャに対するアプローチは、オープンコンピューティングとサービス化によるものだ。

　オープンコンピューティングには以下の3つの主要コンポーネントがある。

　オープン標準。標準は、API、プロトコル、そしてデータとファイルフォーマットのオープンで公開された仕様を利用することによって相互運用性を推進する。

　オープンアーキテクチャ。優れたアーキテクチャを利用すれば、疎結合で、柔軟で、再構成が可能なソリューションを構築できるようになる。サービス指向アーキテクチャ（SOA）は、オープンで柔軟なアーキテクチャスタイルの一例で、戦略的適合を保証するビジネスプロセスとソフトウェア機能の密結合を実現する利点も持っている。

　オープンソースソフトウェア（OSS）。OSSツールはコミュニティーによる開発とコラボレーションを活用した技術革新を推進するために極めて重大なものだ。

　SOAはオープンコンピューティングをベースに構築され、これがサポートするビジネスプロセスと密接にリンクされた一連の疎結合サービスにより、システムがダイナミックに構成可能となっている。これにより、IT資産とビジネスニーズがうまく適合しつつ、アジャイルのビジネスに必要な柔軟性と応答性も実現する。

　SOAには明らかにメリットがあるが、垂直サイロからSOAへの移行には、資金調達、SLA管理、そして要件管理で事業部とIT資産との多対多の関係を管理する必要が出てくるため、ガバナンスプロセスが複雑性を増すことも指摘しておきたい。

　IBM Software Groupは、製品の基盤であるアーキテクチャの変更を最近実施した多くの企業の1つだ。IBMのソフトウェア製品はこれまで、プロプライエタリなハードウェア、OS、そしてアプリケーションコンポーネントを基盤に構築されていた。IBM Software Groupは標準とオープンソース活動を幅広く採用してSOAに取り組んでいる。これが次々に革新を生み、統合ソリューションの投入へとつながり、われわれと、われわれの顧客により高い柔軟性と責務を提供している。一例として、先ごろ発売した「IBM WebSphere（R）Service Registry and Repository」という製品は、開発に1年もかからなかったが、顧客から多くの反響を得た。このような開発にはいままで数年を要していた。

メリット

　柔軟なアーキテクチャには以下のような複数のメリットがある。

　進化するビジネスニーズのサポート。急速に進化するビジネスとITの組み合わせがビジネスの中で極めて重大な位置を占めるようになり、それが急速な進化に向けた大きなプレッシャーをITに掛ける。柔軟なアーキテクチャは、それを引き出す技術基盤を提供する。

　商品化までの時間削減。柔軟なアーキテクチャは疎結合であるため、再利用可能なコンポーネント／サービスからアプリケーションをもっと素早く組み立てられるようにする。これにより、幅広い再利用が可能になり、結果的に商品化までの時間が大幅に短縮される。

　ROIの向上とTCOの削減。再利用を促し、アプリケーションの組み立てを簡単にすることで、全体の開発コストが削減される。業界標準への依存も、ニーズに合わせた複数製品の発売を保証し、プロプライエタリな技術ソリューションよりも価格を低く抑える。

　技術リスクの低減。柔軟なアーキテクチャは業界標準への依存度が高まるため、単一ベンダへの依存度を引き下げてくれる。これにより、運用の自由度が高まる。

トレードオフ

　柔軟なアーキテクチャの導入には以下のような多数の代償がある。

　投資の必要性。柔軟なアーキテクチャは無償では手に入らない。スキル、技術、そして今日の資産から未来の疎結合資産への転換に対する投資が必要になる。再利用が約束するものを達成するには、アーキテクチャの中の一部の可動例であるリファレンスアーキテクチャへの投資も必要になる。

　進化の必要性。柔軟なアーキテクチャは技術と標準に合わせて進化する必要がある。それには、スキルと技術への継続的投資が必要になる。

　品質の必要性。柔軟なアーキテクチャは再利用を促進するが、再利用ではもっと品質を重視する必要がある。品質が十分でないと、再利用可能なコンポーネントに対し、再利用で削減した分以上の保守やサポートのオーバーヘッドが掛かることになる。

アンチパターン

　柔軟なアーキテクチャに関しては以下のようなアンチパターンがある。

　煙突型アーキテクチャ。垂直あるいは「煙突型」のアーキテクチャを用意すると、再利用性とビジネスの柔軟性が低下する。技術が世界中のビジネスとビジネスチャンスを同じ土俵に立たせたように（Thomas Friedman著の「The World is Flat: A Brief History of the 21st Century」参照）、われわれのアーキテクチャも、ソーシャルネットワーキングの最新の流行（例：Web 2.0）と、分散されて365日ノンストップの運用が可能な、アウトソーシングの大きく進んだビジネスモデルを取り入れる必要がある。

　プロプライエタリ技術。プロプライエタリな技術を使って柔軟なアーキテクチャを構築することができても、それによりベンダに縛られることになり、将来のソーシングに対する柔軟性が低下して、TCOの増大につながる可能性が高い。その結果、プロプライエタリなソリューションの範囲を超えて技術が進化すると、後に取り残されてしまうことになる。

　1つの技術に入れ込まない。1つの技術に絞ることは難しい。それは、何を選択しても、次の日にはそれが最適ではなくなる可能性があるためだ。しかし、進化のための決断をする必要があるため、のめり込むことはもっといけない。

推奨デフォルト

　デフォルトでは、サービス指向アーキテクチャ、今後有望なアーキテクチャ、Eclipseなどのオープンソース技術、そしてJava 2 Enterprise Edition（J2EE）、Object Management Group（OMG）、およびIEEE（米国電気電子通信学会）関連の標準を推奨する。

　どのIT部門も開発ガバナンスプログラムを用意しているが、このプログラムが明確でない場合があり、効率的でない場合がある。これまで、開発ガバナンスに対する従来のアプローチはネコの番をするのに似たところがあった。管理者が一生懸命命令しても、開発者は勝手に行動していた。開発者は指揮統制型のアプローチではうまく機能しない知的オフィスワーカーであることから、開発ガバナンスに対する従来のこれらのアプローチはうまくいかなかった。ガバナンスプログラムをうまく機能させるためには、これが応用される実際の環境を反映したものでなくてはならなかった。また、こと管理に関しては関係者が最大の要因だった。

　効果的ガバナンスは指揮統制ではなく、協調的で協力的なテクニックによる実現を重視する。これは、これはネコを先導するようなもので、何かを強制するのではなく、やる気にさせる方が一段と効率的であるはずだ。

　本シリーズでは、現代のソフトウェア開発の現実を反映した高効率開発ガバナンスのさまざまな手法を簡単に見てきた。これらの手法は、適切なことが可能な限り簡単にできるよう、ツール、プロセス、そして開発指針にガバナンスを組み込む方法を示していた。これらは高効率ソフトウェア開発、IBM Rational Unified Process、Extreme Programming（XP）、Dynamic Systems Development Method（DSDM）、およびScrumなどの開発に対する現代のアプローチを反映した開発ガバナンスの新しい考え方だ。開発ガバナンスはIT全体のガバナンスのほんの一部にすぎないが、重要なものである。引き続き注目していきたい。

本記事は「The Rational Edge」に掲載された「Best practices for lean development governance　Part III: Roles and policies」をアットマーク・アイティが翻訳したものです。

著者プロフィール

Scott W. Ambler,

Practice Leader, Agile Development,

Rational Methods Group, IBM

Per Kroll

Manager of Methods, IBM Rational, IBM

「The Rational Edge」バックナンバー

前のページへ 1|2|3|4 　　　　　　