複雑性を理解する(前編):ソフトウェアが複雑なのは仕方がない?:The Rational Edge
The Rational Edge より:ソフトウェアシステムの複雑性は避けられないが、手に負えないものではない。IBMのDistinguished Engineerがアーキテクチャやチーム組織の立場から複雑性にどのようにアプローチするのか見ていこう。
われわれの多くにとって、複雑性とは「行き当たりばったり」(IKITWISI)なものだ。われわれはソフトウェアの開発と配布において、一致した技術的定義のないまま「複雑性」という言葉を頻繁に使う。複雑性の定義が難しいことから、このことは理解できる。ソフトウェアデザイン[注1]をはじめ、さまざまな分野の幅広い技術的定義や対策[注2]から、その定義が簡単には1つに絞れないのは明らかだ。
本稿で解説をしていくが、複雑性はやむを得ないものであり、(対策には)費用もかかる。実際、複雑性は以下のようなさまざまな理由から、われわれの個人の世界でも技術の世界でも高まりつつある。複雑性は、さまざまな意味を持つことから、われわれの時代における技術上およびビジネス上の重大関心事の1つといって差し支えないだろう。
そして、複雑性の影響を抑える一般的な方法はいくつかある。それが本稿のテーマだ。
複雑性について考える
一般的にいうと、複雑なものには相互に接続され、やりとりをするパーツが多くある。その点を考慮に入れた複雑性軽減のための第一歩は、関連する複雑度を理解することだ。つまり、それを計測する手段が必要になる。ここに、その計測に関する複雑性と動機の特定に利用できる実用的基準が2つある。これらの基準はソフトウェア、システム、プロジェクト活動、そして組織(実際は、相互に対話するパーツのある実体であればどこでも)に適用される。
予言。現状や過去の歴史から実体の将来の行動を知ることの難しさ。プロジェクト活動や組織にとって重要だ。
回顧。実体が現状に至るまでを理解することの難しさ。これはシステムとソフトウェア、そしてシステムのデバッグにとって重要で、大半のシステム/ソフトウェアにおける複雑性対策の基盤になる。
ここ数十年間で最も重要な洞察の1つは、これらの対策により、複雑性が驚くべきスピードで生じるということだ[注3]。シンプルなものがシンプルなルールと相互に対話していても、前述のいずれかの観点から早急に複雑化してしまう。以下のような例が考えられる。
アリやシロアリといった虫の群れ、ミツバチの巣、鳥の群れなどは、個々がごくシンプルなルールに従うことで構成されるが、集団的に彼らの行動を予測するのは不可能であり、これらが群れる行動の履歴を再現することも不可能だ。
インターネットも、比較的シンプルな数百万ものノードによって構成されている。ところが、それが全く予測できない社会/企業行動を生み出している。
規模の大きいソフトウェアプログラムは、たとえそれがうまくデザインされていても複雑なものだ。
しかし、昔からの教訓がもう1つある。簡潔が望ましい、というものだ。アーキテクチャとデザインにとっての最大の目標は、利害関係者のニーズに合致し、実体にとって可能な限りシンプルなソリューションを見つけ出すことだ。一般に、シンプルであるほど堅牢で、壊れにくく、修理も容易だ。この原則はビジネスと組織のデザインに当てはまる。残念ながらコンピュータサイエンスでは、自分のデザインが最もシンプルなものかどうかを知るための実用的手段はない、とされている。
相互に対話する可動パーツがある限り実体は複雑性を想定すること、を教訓にしたい。
複雑性の誘因
われわれの職業では以下の部分に複雑性が関係してくる。
- 配布するシステムとソフトウェア
- 参加するチーム
- 所属する企業
いかなる場合でも、複雑性には以下の2つの誘因がある。
- 状況。実体と、その外部実体との対話内容
- デザイン、アーキテクチャ。実体内の対話内容
前述の実体が対話をする世界の行動を予想する願望があるため、状況の複雑性は重要だ。将来の行動と、状況にかかわる関係者のニーズを理解できれば以下のようなことが可能になる。
彼らの現在の実益に即したシステムを安心して計画およびデザインできる。
企業と社員に安定性を与える組織を作り出せる。
しかし、インターネットなどの各種ネットワーク技術の存在により、その状況の関係者に加え、間接的ではあるものの、無関係の部外者も全員が相互に結び付いている可能性が高い。これらの関係実体を結び付けると、対話の可能性を秘めた巨大なネットワークができあがる。この連結性が与える影響は、現実の世界からも、仮想の世界からも注目を集めた。例えば、未来の開発チームは付き合いの輪の中にいるような行動を取るようになる、との兆候が顕在化しつつある。重要なのは、関係実体は全員が群れの一員のようなものであることから状況の複雑性は避けられない、という点だ。
一方、デザインの複雑性を強めている力は異なる。技術の進歩により、われわれはより詳細に処理状態を把握できるデバイスやシステムを持てるようになり、そこでは、より機能が高く、処理状態を把握できるソフトウェアの運用が可能になった。そのようなデバイスの例としては、各種市販製品の VHSIC(Very High Speed Integrated Circuits:超高速集積回路)ハードウェア記述言語(VHDL)モジュール、車両の電子コントロール装置、パーソナルコンピュータ、企業向けブレードサーバ、仮想化対応メインフレームなどがある。必要なときに何度でも機能を提供する、もしくは予測できない負荷に合致するよう処理のバランスを取るために、ソフトウェアはこれら各種デバイスすべてに分散することが期待されている。このような複雑性は、サービス指向アーキテクチャ(SOA)インプリメンテーションのエンタープライズソフトウェアで顕著だが、どの分散ソフトウェアアーキテクチャでも発生する可能性がある。これらの実体は両方の複雑性を示すため、パフォーマンスのデバッグや予測はかなり難しい。
《後編に続く》
- トランザクション管理の複雑性を克服する(パート1)
- アジャイルとシステムテストの新たな関係(後編)
- アジャイルとシステムテストの新たな関係(前編)
- アジャイル開発の広範な普及を目指して
- 見積もりの精度 Accuracy of Estimation
- 複雑性を理解する(後編):ソフトウェアの複雑性を手なずける
- 複雑性を理解する(前編):ソフトウェアが複雑なのは仕方がない?
- 鈍重な開発チームは鈍重なシステムを作る?/パート3:役割とポリシー(後編)
- 人事評価と開発者のモチベーション/パート3:役割とポリシー(中編)
- 自己管理型チームの利点と弱点/パート3:役割とポリシー(前編)
- プロセスはチャンスが訪れるたびに改善する/パート2:プロセスと基準(後編)
- 開発プロセス導入のアンチパターン/パート2:プロセスと基準(中編)
- 反復開発の「ここはぜひカバーしたいポイント」/パート2:プロセスと基準(前編)
- 開発プロジェクト「統治」のピンポイント解説/パート1:原則と組織(後編)
- 開発プロジェクトを「統治」するベストプラクティス/パート1:原則と組織(前編)
- 初歩の「Perl」「Python」「Ruby」
- ビルドが全滅する原因/プロジェクトの状態を評価する:パート2(後編)
- 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する:パート2(前編)
- UMLを使ったビジネスモデリング(後編):そうだったのか! システムユースケース
- UMLを使ったビジネスモデリング(前編):なるほど! ビジネスユースケース
- 「この開発プロジェクトは中止!」の基準/プロジェクトの状態を評価する:パート1(後編)
- プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する:パート1(前編)
- 専門家に聞くモデル駆動開発のメカニズム
- 「設計」や「構築」よりも重宝されるスキル
- キミのコードが汚い理由
- 汎用グラフィカルモデリング言語「SysML」 パート2:グラフィカルなモデル言語で製品構造を記述
- 汎用グラフィカルモデリング言語「SysML」 パート1: 要件、ユースケース、およびテストケースのモデリング
- ウォーターフォールから反復型への移行手順
- ソフトウェアアーキテクティングのメリット
- ソフトウェアアーキテクティングのプロセス
- ソフトウェアアーキテクトの役割
- ソフトウェアアーキテクチャって何なの?(後編)
- ソフトウェアアーキテクチャって何なの?(前編)
- ITプロジェクトを見える化する
- ユーザー要件を引出すテクニック: ユースケースかストーリーボードか
- オブジェクト指向を超えて
- ルネサンスの巨匠たちに学ぶエンジニアリングの技
- ソフトウェア開発の「いま」と「近未来」の話
- 中国のソフトウェア開発現場はこんなにスゴイ
- 隣のテストチームが優秀ないくつかの理由(後編)
- 隣のテストチームが優秀ないくつかの理由(前編)
Copyright © ITmedia, Inc. All Rights Reserved.