NTTデータ
技術開発本部
副本部長
山本修一郎
概要
今回はコミュニケーションの構造について考える。コミュニケーションはソフトウェア開発やマネジメントの中でもとくに重要だと考えられている。たとえば、ソフトウェア開発のリスクの原因は「コミュニケーションがうまくとれていなかった」ことだとよく言われる。では、良いコミュニケーションとは何であろうか?
以下ではコミュニケーションの成立条件や会話とはなにかについて、Winogradの会話構造モデル[1][2][3]を用いて何をどのように管理すればいいのかを考えよう。
言語行為展望論
言語行為展望論(Language Action Perspective Theory)では、会話には将来の行為への約束(コミットメント、Commitment)を形成するための基本的な構造があると考える。コミットメントの意味には、委任、委託、約束、責任などがある。ここでは、コミットメントを主に約束ということにしておこう。
たとえば、話し手と聞き手の会話を考えると、話し手があること(行為)を聞き手に依頼する、依頼内容を変更する、依頼を取り消すことが考えられる。聞き手側には、その依頼を受容する、拒否する、依頼条件や内容を変更するなどの行為が考えられる。
Winogradはこのような行為を対象とする会話の基本構造を、話し手から聞き手への要求や依頼に関する会話構造を状態遷移図で表現できることを示した[1]。実は、このモデルは要求や依頼だけでなく、複数の担当者や組織間の行為についての様々なコミュニケーション構造を表現できる。
Winogradは、組織内のコミュニケーションが、反復的な言語行為のパターンの集まり(コミットメント・ネットワーク[4])でモデル化できるとしている。たとえば、管理者が何をしているかを分析していくと、組織で何が起こっているかを考えて、どんなトラブルの可能性があるか、部下に委託した仕事は順調に進んでいるかなど、部下や上司と日常的にコミュニケーションしていることが分かる。このような会話の過程で、想定外の反応つまり、意思疎通の断絶に遭遇すると、この断絶を解消するための新たなコミュニケーションとしての会話のプロセスが必要となる。ここでは、意思疎通の断絶をブレイクダウンという。言語行為展望論では、このような会話のブレイクダウンが重要となる。
会話モデルは人と人との会話をモデル化しているが、対話型の情報システムのデザインにも応用することができる。情報システムを擬人化して考えるということだ。たとえば、会議室予約システムを考えてみよう。会議室の予約を社員がシステムに依頼してシステムから承認されるということを言語行為と考える。このとき、システムは依頼者に対してどんな応答を返せばいいだろうか?システムが依頼者の想定外の反応を示せば、依頼者にとっては、そこでブレイクダウンが発生する。「なぜ、このシステムはこうも言うことを聞いてくれないのだ」と怒りを感じるかもしれない。システムがエラーメッセージ「ERROR:999」などと一般社員にとって理解できない表示をだせば混乱してしまう。そうではなく、次にどういう回復の可能性があるかをシステムが分かりやすく説明できれば、依頼者の怒りを少しは和らげることもできるのではないだろうか?
言語行為展望論の会話モデルでは、行為に関する約束を実現するための会話を想定している。同時にまた相手に委託したはずの行為に関する約束が守られないというブレイクダウンの問題が顕在化した場合には、その断絶を解消するための新たな行為が必要になり、そのための会話もまた管理することになる。このように、どこにブレイクダウンの可能性があるかを分析していくことにより、将来何ができるのかを発見することにつながる。この点で、言語行為展望論は単にコミュニケーションの構造を理解するだけでなく、最近ではイノベーションの方法論としても期待されているのである[5]。
コミュニケーションの成立条件
コミュニケーションの目的は相互理解にあり、コミュニケーションの相手との意思疎通が相互に断絶しないことだろう。
たとえば、次のようなことが保証されなければ、良いコミュニケーションが成立しているとはいえないのではないだろうか?
- 「相手の言うことが信じられる」
- 「相手と合意を形成することができる」
- 「相手との約束を守る」
しかし、このような状況を定常的に維持することは難しい。したがって、意思疎通が断絶してしまう、つまりブレイクダウンの可能性を考慮することが必要だ。もし意思疎通が断絶した場合には、それを解消するための新しい一連の会話が成立するかどうかを考えておくことで、仮にブレイクダウンが生じても、約束についての持続的な相互確認ができるようになると思われる。
約束についての会話状況とブレイクダウン
約束についての依頼者と提供者の関係を図1に示す。
図1 約束についての会話の状況
約束が成立するまでには、まず依頼者が約束事を提供者に要請し、提供者が要請内容を検討して、約束事に合意するという行為とそのための会話が必要だ。約束が成立するまでを外部的な会話だと考える。これに対して、約束した後は、約束の実施とその結果を受理するという、依頼者と提供者の当事者同士としての内部的な会話になる。また約束の実施では、依頼者は提供者による実施内容について進捗を管理するための会話が必要になる。実施結果の受理では、同様に実施報告を検査するための会話が必要だ。
このような4つの段階で、会話のブレイクダウンが発生する可能性がある。たとえば、そもそも提供者が依頼を拒否するかもしれないし、契約条件について、合意できないかもしれない。進捗管理の過程で、約束の実施が困難であることが判明して、中断することになったり、報告内容が不十分で受理できなくなる可能性がある。
会話構造モデル
表1 会話構造モデルの構成要素
ここでは、Winogradの会話構造モデルを分かりやすく拡張したモデルを紹介しよう。まず、会話構造モデルの構成要素を表1に示す。表1から明らかなように、会話構造モデルは状態遷移図の一種である。このモデルには次のような特徴がある。
- 状態名を名詞で記述できるので、理解しやすい
- 状態遷移のラベルとして、発言の向きを矢印で発言の種別とともに表現することにより、遷移の向きとラベルとの一貫性を確認しやすい。複数の発言を同時に記述できるようにするとともに、発言間の関係も明記できるようにしている。たとえば、両方の発言がともに必要なのか、どちらか一方の発言だけでいいのかを記述できる。これにより状態や状態遷移の個数を削減できるので、簡潔に表現できるようになる。
- 状態を人の役割に応じて色付けすることで区別する。たとえば、状態ごとに次に発言するのは話し手なのか聞き手なのかは自然に決まってくるので、それを明記することで会話の全体構造を展望しやすくできる。
会話構造の具体例
次では、会話構造の具体例として、質問回答、問題発見、2人ゲーム、調査報告の記述例を紹介しよう。
- 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:保証ケース作成支援ツールの概要