« MVPen~愛用している電子文具 | トップページ | エンジニア的「夜の雪と人間の遺伝子」 »

2010年2月17日 (水)

巷で氾濫する間違いだらけの要件管理・構成管理作業の実態

巷で氾濫する間違いだらけの要件管理、構成管理作業について簡単に言及したい。

日本では要件管理、構成管理作業の専門家、コンサルタントという人もいるようだが、本当に意味で正しい知識と経験を保有しているのか怪しい人が多い。

日本に来日する外国のエンジニア、コンサルタントに聞くと日本で要件管理、構成管理作業のコンサルタントという人でまともな人は見たことが無いそうだ(もちろん、きちんとした人もいるはず)。

先日も要件管理、構成管理作業で非常に重要となる「開放閉鎖原理」、「依存関係逆転原理」「抽象度安定原理」を知らないという要件管理、構成管理作業担当のエンジニアや要件管理、構成管理作業のコンサルタントがいたので驚いた。

さて、要件管理、構成管理作業について語る前にアーキテクチャについて簡単に確認しておこう。

ソフトウエア開発においてアーキテクチャは非常に重要である。

アーキテクチャというのは、狭義の意味では設計成果物でありコードである。

しかし、アーキテクチャには広義の意味がある。

広義の意味は、狭義の意味である設計成果物やコードコードに加えて、アーキテクチャを中心とした開発作業プロセス(Architecture Centric Development)やアーキテクチャの保守・拡張・再利用を効果的に実施するアプローチまでを含める定義である。

「企業」が単に組織構成や資本などだけでなく、そこで働く従業員、取り引き先、業務フローの流れなどからその企業の本質が評価されるのと同じである。

アーキテクチャも同様で、アーキテクチャの開発をはじめ保守・拡張・再利用には、設計手法や支援ツールおよび開発作業プロセスが非常に重要となり、これら全てが揃って初めて効果的なアーキテクチャの開発、運用および保守が可能となるからだ。

さて、前置きはこのくらいにして要件管理、構成管理作業について言及すると、要件管理、構成管理作業のみに注目して必要な作業をプロセス化したり、規則およびツールを用いて運用方法を構築しても意味が無い。

要件管理、構成管理作業は、これら自身が中心的な位置づけにあるのではなく、アーキテクチャの保守・拡張・再利用を効果的に実施するアプローチの1つとして位置づけられるからだ。

Eiffle言語の開発者で世界的な有名なバートランド・マイヤーは、ソフトウエア開発において要件変更は避けられず、アーキテクチャを含め色々な開発成果物に変更が及ぶことを考慮して数々の設計ノウハウと要件管理、構成管理作業ノウハウを述べている。

アーキテクチャの保守・拡張・再利用を効果的かつ確実に実施するためのアーキテクチャの設計原則を多く紹介している。

これらの中には、アーキテクチャの変更管理、構成管理を効果的に実施するキーの1つとして「解放閉鎖原理」を述べている。

「開放閉鎖原理」により構成管理のベースラインを安定させるのだ。

「開放閉鎖原理」は柔軟な設計のアプローチとして有名だが、最初の目的の1つは構成管理のベースラインを効果的に行い、設計作業をスムーズに行うことが理由の1つであった。

「依存関係逆転原理」「抽象度安定原理」も同様である。

「依存関係逆転原理」「抽象度安定原理」は、変更箇所を特定し要件管理や構成管理に大きな作業上のメリットをもたらすばかりでなく、要件管理や構成管理のプロセスが大きく変化する。

このように要件管理や構成管理は設計・実装作業と極めて強く関連し、アーキテクチャの構造にも強く依存するので、要件管理や構成管理の戦略や作業工数ががらりと変わるのだ。

海外の要件管理や構成管理のコンサルタントや構成管理担当者で、開発方法論や手法に知識がない人はないない。

それはそうだろう、「開発作業」の中の1つの作業である要件管理や構成管理を設計と切り離して考えられないからである。

つまり、アーキテクチャ開発戦略、採用する設計技法との整合性と効果、これらのことを考慮しない要件管理や構成管理作業は、目的と手段を履き違えている。

要件管理や構成管理作業にばかり時間がとられれ、本質的なメリットがあまり授与できない組織が多すぎる。

要件変更テーブル(表)や追跡可能性の依存関係テーブル(表)とそのメンテナンス方法にばかりに気を取られる組織がいかに多いことか。

それにMDA(Model Driven Architecure)のようなアプローチを併用すると、アーキテクチャ開発は全く異なったものになることがある。

MDAでは開発支援ツールを用いるために設計成果物の要件管理・構成管理も支援ツール上で行う場合が多い。

単に支援ツールが連携されいるという意味ではなく、アーキテクチャの設計結果に大きく依存することになるツール間の連携も非常に重要となる。

要件管理・構成管理作業では、組織や開発する対象が異なっても実施しなければならない共通のこともあるが、アーキテクチャ設計や効果的な開発技法で著しく異なることがなる。

もっと具体的に言えば、構成管理や要件作業で対応しなければならない成果物や作業にかかる工数を大きく減らすことができるのだ。

そして、このような開発こそが優れたアーキテクチャなのだ(広義のアーキテクチャ定義)。

また、構成管理ではベースラインを確立することが求められるが、ベースラインの確立のやり方(ベースラインの構造)は実に色々あるのだ。

そして、どのようなベースラインのやり方が良いかは、アーキテクチャ構造や設計プロセスとその戦略に依存する。

これかも分かるように、要件管理・構成管理作業には、充分な開発技法のスキルや経験が必要なのである。

あなたの組織の要件管理・構成管理作業は、アーキテクチャ開発戦略と採用する技法とどのように連携しているか工学的な見地から明確に説明できるだろうか?

CMMIでも構成管理(CM)や成果物統合(PI)でも、アーキテクチャとの関連性(インターフェースの整合性やベースラインについて)について上記で述べたことに関連することが登場するから注意して欲しい。

=HSCI Takanari Hashimoto(URL:http://hsc-i.com/)=

|

« MVPen~愛用している電子文具 | トップページ | エンジニア的「夜の雪と人間の遺伝子」 »

「パソコン・インターネット」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/112989/47589684

この記事へのトラックバック一覧です: 巷で氾濫する間違いだらけの要件管理・構成管理作業の実態:

« MVPen~愛用している電子文具 | トップページ | エンジニア的「夜の雪と人間の遺伝子」 »