Vol.5 No.1 2012

6/84

研究論文:高品質なプロジェクトマネジメントを実現するトレーサビリティ・マトリックスの構築(榮谷ほか)−3−Synthesiology Vol.5 No.1(2012)が、それは暗黙知のままでは情報粘着性が高くその情報移転コスト、つまり社内のある社員のもっているノウハウを他の社員に習熟させるためのコストがとても大きくなってしまう。ノウハウを引き出す、または学ぶために何度も情報のやり取りをする必要が生じることが考えられる。またはそもそも他の社員に移転することすらできないかもしれない。その結果、企業全体の能力を底上げするための障壁になってしまう。そのため、社員のもっているノウハウを形式化(見える化)することで、情報をやり取りする回数を削減し、情報移転コストの低減を図ることが必要なのである。一方、プロジェクト等組織の中の1:nの関係において、情報移転コストを説明するには情報粘着性だけでは不十分であると考えた。なぜならば、送り手が別々ならば、受け手との関係も一意に決まり、その送り手のもつ情報粘着性を合計することで情報移転コストは得られる。しかし、送り手が同じ場合は、送り手のもつ情報粘着性を個々の受け手に合わせるためのコストも加味しなければならない。言い換えれば、ある受け手から別の受け手に情報移転先を変えるときに準備を行うためのコストを考慮しなければならないと考えたからである。そのコストを加味するために多義性という概念の導入を考える。多義性とはある情報は受け手の観点により多くの意味をもってしまうことを言う。例えば一人の受け手に情報を移転するときに一つの情報が意味A、Bの2種類の意味付けがなされるかもしれない。しかし、複数人の場合はその意味付けがA、Bだけでなく、他の人からはC、Dとして捉えられるかもしれない。そのように情報移転先が増えれば、その分多義性も増す。情報の送り手は、複数の受け手に正しい意味付けをしてもらうために、例えば説明用の資料に複数の受け手からも正しく理解されるような情報をあらかじめ盛り込んだり、または受け手に応じて説明用資料を作り直す等を行う。受け手が特定され情報移転が始まれば情報粘着性の問題で処理できるが、受け手が特定されなかったり、情報移転が始まる前には、情報粘着性ではなくこのような多義性による移転コストを考慮する必要があると考えた。以上のように、1:nの関係で生じる多義性によるコストは、その受け手の数に依存している。多義性を抑えるためには受け手の数も低減することが必要なのである。また次に、n:1の場合は移転されたn個の多義的な情報を統合して、一つの意味付けにするという思考の整理が必要になる。n個の情報の意味について整合性をとり、一つの意味をもった情報として統合するのである。その統合作業もnに依存して情報移転コストも変わってくると考えられ、1:nと同様にnの数は少なくすることが望ましい。さらに、限られた予算や時間のもとで行うプロジェクトでは、情報移転コストが高くなればその制約上、情報移転が完全に終わらないまま作業を進めてしまうケースが考えられる。そのような状況を避けるためには、極力移転コストを下げた状態をプロジェクト内に作り出し、それをマネジメントしていくことが必要になってくる。したがって、情報中心であるソフトウエア開発プロジェクトにおいては、情報粘着性と多義性をマネジメントすることが、送り手と受け手でやり取りされる情報の正確な移転を促し、より高品質なプロジェクトマネジメントを実現する上で重要であると考えた。3 プロジェクトのアーキテクチャ(トレーサビリティ・マトリックス)の構築情報中心のプロジェクトにおいて、情報粘着性と多義性をマネジメントするには、プロジェクトを構成する要素にどのようなものがあり、それぞれの要素がどのような関係性にあるのか整理する必要がある。そのためのモデルを構築する。3.1 構成要素の抽出を実現する概念オブジェクト指向によるビジネスモデリングにより要素を抽出する。特にオブジェクト指向を概念に取り入れた要求工学[10]によるとプロジェクトというシステムを構成する要素として、ニーズ(Needs)用語1、基本要件(Feature)用語2、要求条件(Requirement) 用語3が抽出される。ニーズは基本要件と、基本要件は要求条件と関係する。機能(Function)用語4、実体または部品(Component)用語5は「全てのものは機能をもつ」[11]により、要素として抽出される。部品は機能と関係する。そして、プロセスフローから、成果物(Artifact)用語6、作業(Activity)用語7、担当(Team)用語8を要素として抽出する。担当は作業と、作業は成果物と関係する。3.2 要素間の関係性整理を実現する概念と関係性の事例プロジェクトというシステム全体のアーキテクチャを定義する上で、機械工学の「公理的設計」[12][13]と、組織科学の「ビジネスアーキテクチャ」[14][15]という概念の二つに着目した。組織活動を設計する上ではEA(エンタープライズアーキテクチャ)が類似したものと考えられるが、EA手法では参照アーキテクチャ用語9までは示してはいない[16]。そのため、自分でシステムを構成する要素とその関係性を定義する必要がある。しかし、この二つの概念ではものづくりのプロセスからものづくりに携わる組織、そしてそもそもどのようなものを作るべきなのかという顧客要求までも考慮し、その要素間の関係性について指針まで示しているものであることに大きな特徴がある。公理的設計の考え方は、顧客領域・機能領域・実体領域・プロセス領域の各領域間で情報が写像され設計活動

※このページを正しく表示するにはFlashPlayer9以上が必要です