Tweet

ソフトウェアの複雑性を手なずける

IBMシニアコンサルタント
Chris Gerken

2008/1/15

前編へ｜　｜

複雑性への対応

　前回「ソフトウェアが複雑なのは仕方がない？」述べたように、複雑性を回避することはできず、これを最小限に抑えることが可能かどうかも分からないが、これに対処することは可能だ。同じサービスを提供し、同じニーズに合致する実体内でも、その複雑性には幅があり、よりシンプルなシステムや組織デザインを見つけることが非常に大きな経済的メリットへとつながる。チェックされないままだと、複雑性が要因となって保守や導入にかなりのコストが掛かり、すぐに古くなるシステムができてしまう。これらのシステムは、シンプルなシステムよりも有用性が低い。複雑な開発組織は規模の不経済に苦しみ、それらの活動の大半が、利害関係者に価値を提供することにではなく、内部のコミュニケーションに費やされてしまう。

　したがって、複雑性を打破することはできなくても、懸命の努力は継続する必要がある。ここでは、重要なテクニックをいくつか評価する。

■システムとソフトウェア

　システムとソフトウェアの複雑性を管理すべく確立されたテクニックが2つある。

• アーキテクチャとデザイン
  
  
• シミュレーションとテスト

　以下でそれぞれを説明する。

◎アーキテクチャとデザイン

　エンジニアや開発者がシステムに関して、推論および議論できるようにする際のアーキテクチャの役割についてはいろいろと書かれている。アーキテクチャには以下の2つの特性がある。

• カプセル化 -- 内部のデータと手法を隠す
  
  
• 凝集 -- カプセル化された実体の連結方法

本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

　下の図には、同数のコンポーネントを持つ2つの実体を表した2つの図がある。右上にはカプセル化も強い凝集も一切ない。左下は、コンポーネントが弱い凝集で3つの大きいコンポーネントにカプセル化されている。この実体はあまり複雑ではない。どの分野でも、優れたアーキテクチャはこの原則を当てはめることで複雑性の低下に努める。適切な量のカプセル化と凝集を達成するにはいまだに技術力を要する。凝集が強過ぎると、システムは複雑性の悪影響をすべて受けてしまう。逆にこれが弱過ぎると、システムは縦割りのもろいものになってしまう。

　複雑性の管理にアーキテクチャを役立てる2番目の方法は、変化を予想することだ。つまり、状況の変化に合わせる必要が出てくることを前提にシステムをデザインする。変更に合わせたデザインには以下の2つの作業で構成される。

　カプセル化したシステムと、その対話相手（「アクター」）が含まれるようモデルをデザインする。システムの属性とサービスをシステム要件までトレースする。これができれば、システムの状況変化の影響を素早く分析できる。

　避けることのできない変化にアーキテクチャがどのように対応できるかを定期的にテストする。その一例が、インターフェイ スの変更、機能の追加 、もしくは新しい状況実体によって生じるアーキテクチャの変化量の計測だ。複雑性への取り組みには努力と投資が必要だが、一般には複雑性に伴うコストの方がはるかに大きいことに注意したい。

右上と左下の図はいずれも同様の複雑な実体を示しているが、左下の図で示されているアーキテクチャは、カプセル化による複雑性の低減を示している。クリックすると拡大

◎テストとシミュレーション

　複雑なシステムと状況では、配置された状況とシステムの動作およびパフォーマンスを予測することが不可能であるため、システムで実現された機能とパフォーマンスを少なくとも統計的見地から見られるよう動作の分析、シミュレーション、およびテストが必要になる。開発ライフサイクルの初期段階では、シミュレーションと分析の両ツールを利用する。そして、システム開発が進んできたら、シミュレーションの代わりに機能／負荷パフォーマンステストを行う。このアプローチは何らかの形の反復開発が採用されている場合に最適であることに注意したい。

組織

　システムと同様に、組織と状況のやりとりについてもモデリングができる。それがビジネスモデリングの分野だ。ビジネスモデルの利用は、SOA 手法で特に魅力的だ。SOA は組織をサービスプロバイダーとしてカプセル化する。サービスを提供および消費することでほかの組織と対話するのだ。SOA は、予期せぬ変化に対する素早い対応で状況複雑性に対処できる組織にするサービスの導入を目標にしている。

　運用統治［注4］は社内の複雑性に対応するための手法をいくつか提供する。特に、RACI （Responsible、 Accountable、Consulted、Informed）フレームワークを設定することで、組織の凝集への対応手段が得られる。RACI フレームワークの設定で有効な方法の1つが、組織プロセスにおける意思決定ポイントを、特にプロセスの成果物の状況が変化時に特定することだ。これらの意思決定ポイントでは、どの役割の人物が判断を下し、どの管理者が責任を持ち、誰に相談し、誰に報告するかを特定もしくは決定する。この構造が緻密過ぎると、凝集が強過ぎて組織が複雑になり過ぎ、効率を追求できなくなる。

■開発チーム

　開発チームには複雑性に関する固有の懸念がある。彼らの状況では、多くの場合対立し、変化し続ける懸案事項を持った利害関係者（要件設定者、ユーザー、財務管理責任者など）が存在する。要件を設定する利害関係者が自分たちのニーーズをもっと詳しく把握できるようになり、要件をアップデートするときもあれば、状況の変化によってニーズが実際に変化する場合もある。いずれにせよ、開発チームは変化を予測したチーム手法を採用する必要がある。開発状況の安定を期待すると、決して妥当とはいえないシステムができてしまう。これはアジャイル開発の大前提だ［注5］。

　また、開発チームは大小さまざまな規模にスケーリングし、それ自体が複雑化する。チームの行動自体が予測が難しくなっていく［注6］。やはり、ここでもカプセル化と凝集が当てはまる。「Conway's Law」［注7］に従えば、カプセル化の実現に向けたチームのパーティション化で最適なのは、アーキテクチャの境界で区切る方法だ。チームにアーキテクチャのコンポーネントやサブシステムを開発させるようにすれば、必要なときに強い凝集を実現でき、あまり密接に凝集されていないチームで密接に結合されたモジュールに対応し、機能やインターフェイスをもっとうまく取り決められるようになる。また、カプセル化されて外部から見えるコンポーネントに話題を絞れるようにチームをカプセル化し、最適なコミュニケーション量を実現する。上の図を見直して、各ノードを人間、各図をチームデザインに例えてみていただきたい。どちらのチームに所属する方がよいだろうか？

古き良きメタファー

　海は誰が見ても複雑だ。今回の場合、組織は水の分子である。しかし、なかにはその予測できない動きに命を懸けるものもいる。サーファーだ。しばらくの間、「サーフィン」は複雑性に対処できるだけでなく、それを自分の目的のために利用できる能力を指すメタファーだった。1980年代にはWebをサーフィンし、変化するビジネス環境の中でもサーフィンが行われていた。確かに、未来は比喩的な意味でサーフィンができる人々のものだ。彼らは複雑性と争わず、それを大いに楽しむ。今日のビジネスの世界では、複雑性にうまく対応しながら作業し、可能な場合はそれを低減させ、できないときは身を任せることが絶対不可欠である。

　次回以降の The Rational Edge では、複雑性に対応するための具体的な手法についていくつか説明していく。リラックスし、用意だけはしておき、サーフィンを楽しんでいただきたい。

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）