(前NTTデータ フェロー システム科学研究所長)山本 修一郎
概要
これまで、本連載ではコミュニケーションについて、コミュニケーションの成立条件(25回)、組織とコミュニケーション(26回)、ソフト製品開発における要求コミュニケーション(65回)と、3回にわたって紹介してきた[1][2][3]。今回は要求抽出段階におけるコミュニケーションのプロセスについて考えてみる。
コミュニケーションの基本構造
はじめに、これまでも紹介してきたことだが、コミュニケーションの基本構造を図1を用いて復習する。コミュニケーションには送り手と受け手がいる。送り手は、受け手に行動させることで目的を達成したい。そこで送り手は、ある表現を受け手に対して明示的に伝達する。この表現によって送り手は、受け手が行動を遂行してくれることを期待する。受け手がこの表現を受け取ることで、対応する行動を遂行する。この遂行された行動によって、送り手が目的を達成する。ここでは、送り手と受け手を分けて説明したが、同一人物でもかまわない。たとえば、予定帳に記録するメモによって、自分がすべき仕事を明確に記録することで忘れないように実施できるようになる。また送り手や受け手は複数でもかまわない。
図1 コミュニケーションの構造(クリックで拡大)
送り手が指示しても、受け手が指示された内容を理解できなければ送り手の期待する行動は遂行されないことは良くあることである。とくに、組織間で周知される文書にはこういう伝達ミスが良く発生する。そういう意味でこのコミュニケーションの基本構造は、実はコミュニケーションのリスク分析にも使える。後述するが、この基本構造からコミュニケーションの欠陥は、目的、表現、行動の逸脱から生じることが分かる。したがってコミュニケーションの欠陥には、この3つの逸脱に応じた対策が必要になる。
要求抽出コミュニケーションプロセス
要求抽出についてのコミュニケーションプロセスを、計画と実施、対話と検討という2つの軸で整理すると、図2のようになる。
図2 要求抽出コミュニケーションプロセス(クリックで拡大)
コミュニケーション相手を識別することは、コミュニケーション計画を検討することである。メディアを選択することは、コミュニケーション相手に対して対話手段を計画することである。コミュニケーションすることは、相手と選択されたメディアを用いて対話することである。コミュニケーションの結果、対立が生じたら解消するための検討を実施することになる。
◆コミュニケーション相手の識別
要求抽出では、コミュニケーションが必要なすべての関係者が、最初から明確になっていることは少ない。しかし、誰もいなくては要求を抽出できない。たとえば、要求抽出を実施する担当者がまず中心になって要求抽出チームを構成することができれば、この構成員がまずコミュニケーション相手として識別される。次に、要求抽出チームが抽出した要求を提示すべき相手や、要求を聴きだす相手などが段階的に識別されていくことになる。
◆コミュニケーションメディアの選択
コミュニケーションメディアには、対面会議やインタビュー、電話などの同期的なメディアと、電子メールやメーリングリスト、アンケートなどの非同期的なメディアがある。
コミュニケーション相手によっては予め、これらのメディアが決まっている場合がある。たとえば、要求抽出チームが中間結果や最終結果を報告すべき上部の会議体などは定められている。また要求抽出チームの構成員同士のコミュニケーションでは、対面会議とメーリングリストや電話など、複数のメディアが併用される。
また、メディアごとにコミュニケーションを記録する適切な書式をテンプレートとして用意すると、コミュニケーション内容に基づく要求の抽出や管理を容易化できる。
実際、対面会議では議事録や資料管理簿、インタビューでは調査票などを用いることで作業を効率化できる。
◆コミュニケーションの実施
コミュニケーションの実施では、連載26回で書いたように、「送り手の依頼に対して受け手がそれを理解し、送り手を信じて受け手に行動して欲しいという送り手の願望がある。言い換えれば、送り手の願望や価値観を受け手が受容して行動すれば、送り手によるコミュニケーションの目的は達成されることになる」。
つまりコミュニケーションには、①送り手の目的、②送り手から受け手へ伝達されるコミュニケーションの表現、③受け手が送り手から期待されている行動がある。
このとき、コミュニケーションの構成要素としての①目的、②表現、③行動ごとに、コミュニケーションの対立が発生する可能性がある。
◆コミュニケーション上の対立の解消
コミュニケーション上の対立には、
- ①目的の理解不足
- ②表現の誤りと誤理解
- ③行動のの実行不能性と行動誤り
などがある。
このような送り手と受け手の間で生じるコミュニケーションの関係構造を図3にまとめる。通常のコミュニケーションでは、図1の説明でも示したように、送り手の表現と受け手の行動は明示されるが、送り手の目的、送り手が期待する行動、受け手が理解した表現や目的は必ずしも明示されるとは限らない。このため、次のように目的、表現、行動の各層で誤解に基づく対立が発生する可能性がある。
- 送り手の目的と、受け手が表現から理解した目的とに差異がある。
- 送り手による表現と、受け手が理解した表現とに差異がある。
- 送り手が期待する受け手の行動と、受け手が実施する行動とに差異がある。
続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要