複雑性を理解する（前編）：ソフトウェアが複雑なのは仕方がない？：The Rational Edge

The Rational Edge より：ソフトウェアシステムの複雑性は避けられないが、手に負えないものではない。IBMのDistinguished Engineerがアーキテクチャやチーム組織の立場から複雑性にどのようにアプローチするのか見ていこう。

» 2008年01月10日 12時00分 公開
[Chris Gerken（IBMシニアコンサルタント），＠IT]

　われわれの多くにとって、複雑性とは「行き当たりばったり」（IKITWISI）なものだ。われわれはソフトウェアの開発と配布において、一致した技術的定義のないまま「複雑性」という言葉を頻繁に使う。複雑性の定義が難しいことから、このことは理解できる。ソフトウェアデザイン［注1］をはじめ、さまざまな分野の幅広い技術的定義や対策［注2］から、その定義が簡単には1つに絞れないのは明らかだ。

［注1］　筆者のお気に入りは今もMcCabeの対策だ。「A Complexity Measure」 （1976年12月、McCabe, Thomas J. 著） IEEE Transactions on Software Engineering 、SE-2 No. 4（308?320ページ）参照。
［注2］　Googleで「Define: Complexity」をお試しあれ。

　本稿で解説をしていくが、複雑性はやむを得ないものであり、（対策には）費用もかかる。実際、複雑性は以下のようなさまざまな理由から、われわれの個人の世界でも技術の世界でも高まりつつある。複雑性は、さまざまな意味を持つことから、われわれの時代における技術上およびビジネス上の重大関心事の1つといって差し支えないだろう。

　そして、複雑性の影響を抑える一般的な方法はいくつかある。それが本稿のテーマだ。

複雑性について考える

　一般的にいうと、複雑なものには相互に接続され、やりとりをするパーツが多くある。その点を考慮に入れた複雑性軽減のための第一歩は、関連する複雑度を理解することだ。つまり、それを計測する手段が必要になる。ここに、その計測に関する複雑性と動機の特定に利用できる実用的基準が2つある。これらの基準はソフトウェア、システム、プロジェクト活動、そして組織（実際は、相互に対話するパーツのある実体であればどこでも）に適用される。

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

　予言。現状や過去の歴史から実体の将来の行動を知ることの難しさ。プロジェクト活動や組織にとって重要だ。

　回顧。実体が現状に至るまでを理解することの難しさ。これはシステムとソフトウェア、そしてシステムのデバッグにとって重要で、大半のシステム／ソフトウェアにおける複雑性対策の基盤になる。

　ここ数十年間で最も重要な洞察の1つは、これらの対策により、複雑性が驚くべきスピードで生じるということだ［注3］。シンプルなものがシンプルなルールと相互に対話していても、前述のいずれかの観点から早急に複雑化してしまう。以下のような例が考えられる。

［注3］　すべてが当てはまる、力学系理論、カオス理論、セルオートマトン理論に関してはさまざまな文献がある。例えば、ブログのComplex Systemsを参照のこと。

　アリやシロアリといった虫の群れ、ミツバチの巣、鳥の群れなどは、個々がごくシンプルなルールに従うことで構成されるが、集団的に彼らの行動を予測するのは不可能であり、これらが群れる行動の履歴を再現することも不可能だ。

　インターネットも、比較的シンプルな数百万ものノードによって構成されている。ところが、それが全く予測できない社会／企業行動を生み出している。

　規模の大きいソフトウェアプログラムは、たとえそれがうまくデザインされていても複雑なものだ。

　しかし、昔からの教訓がもう1つある。簡潔が望ましい、というものだ。アーキテクチャとデザインにとっての最大の目標は、利害関係者のニーズに合致し、実体にとって可能な限りシンプルなソリューションを見つけ出すことだ。一般に、シンプルであるほど堅牢で、壊れにくく、修理も容易だ。この原則はビジネスと組織のデザインに当てはまる。残念ながらコンピュータサイエンスでは、自分のデザインが最もシンプルなものかどうかを知るための実用的手段はない、とされている。

　相互に対話する可動パーツがある限り実体は複雑性を想定すること、を教訓にしたい。

複雑性の誘因

　われわれの職業では以下の部分に複雑性が関係してくる。

  • 配布するシステムとソフトウェア
  • 参加するチーム
  • 所属する企業

　いかなる場合でも、複雑性には以下の2つの誘因がある。

  • 状況。実体と、その外部実体との対話内容
  • デザイン、アーキテクチャ。実体内の対話内容

　前述の実体が対話をする世界の行動を予想する願望があるため、状況の複雑性は重要だ。将来の行動と、状況にかかわる関係者のニーズを理解できれば以下のようなことが可能になる。

　彼らの現在の実益に即したシステムを安心して計画およびデザインできる。

　企業と社員に安定性を与える組織を作り出せる。

　しかし、インターネットなどの各種ネットワーク技術の存在により、その状況の関係者に加え、間接的ではあるものの、無関係の部外者も全員が相互に結び付いている可能性が高い。これらの関係実体を結び付けると、対話の可能性を秘めた巨大なネットワークができあがる。この連結性が与える影響は、現実の世界からも、仮想の世界からも注目を集めた。例えば、未来の開発チームは付き合いの輪の中にいるような行動を取るようになる、との兆候が顕在化しつつある。重要なのは、関係実体は全員が群れの一員のようなものであることから状況の複雑性は避けられない、という点だ。

　一方、デザインの複雑性を強めている力は異なる。技術の進歩により、われわれはより詳細に処理状態を把握できるデバイスやシステムを持てるようになり、そこでは、より機能が高く、処理状態を把握できるソフトウェアの運用が可能になった。そのようなデバイスの例としては、各種市販製品の VHSIC（Very High Speed Integrated Circuits：超高速集積回路）ハードウェア記述言語（VHDL）モジュール、車両の電子コントロール装置、パーソナルコンピュータ、企業向けブレードサーバ、仮想化対応メインフレームなどがある。必要なときに何度でも機能を提供する、もしくは予測できない負荷に合致するよう処理のバランスを取るために、ソフトウェアはこれら各種デバイスすべてに分散することが期待されている。このような複雑性は、サービス指向アーキテクチャ（SOA）インプリメンテーションのエンタープライズソフトウェアで顕著だが、どの分散ソフトウェアアーキテクチャでも発生する可能性がある。これらの実体は両方の複雑性を示すため、パフォーマンスのデバッグや予測はかなり難しい。

《後編に続く》

本記事は「The Rational Edge」に掲載された「Understanding complexity」をアットマーク・アイティが翻訳したものです。

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

Copyright © ITmedia, Inc. All Rights Reserved.