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人ゲーム、調査報告の記述例を紹介しよう。
- 1:要求工学の概要
- 2:第12回要求工学国際会議 RE2004
- 3:要求仕様
- 4:要求工学プロセス
- 5:要求抽出
- 6:要求分析
- 7:要求確認
- 8:要求管理
- 9:要求追跡
- 10:要求工学の課題
- 11:ジャクソンの問題フレーム
- 12:シナリオ分析
- 13:要求工学国際会議RE2005
- 14:ゴール分析
- 15:iスター・フレームワーク
- 16:要求インタビュー
- 17:ゴール分析 応用編
- 18:ゴール分析 応用編つづき
- 19:ゴール分析の視点
- 20:ソフトシステム方法論 再考(その1)
- 21:ソフトシステム方法論 再考(その2)
- 22:ソフトシステム方法論 再考(その3)
- 23:非機能要求
- 24:信頼性要求
- 25:コミュニケーションの構造
- 26:組織とコミュニケーション
- 27:論理思考プロセスと現状分析ツリー
- 28:対立解消図と未来実現ツリー
- 29:前提条件ツリーと移行ツリー
- 30:特性要因図とゴール思考分析
- 31:i*フレームワークの書き方
- 32:i*フレームワークの危険な曲がり角
- 33:目的思考
- 34:要求工学の研究動向
- 35:アジャイル開発の要求工学
- 36:アジャイル開発の要求工学
- 37:要求レビュ
- 38:要求の曖昧さ
- 39:アクタ関係分析
- 40:要求工学の現状と課題
- 41:セキュリティ要求工学
- 42:ソフトウェア品質要求工学
- 43:イノベーションと要求工学
- 44:Wikiと要求工学
- 45:要求工学プロセスの改善
- 46:アクタ関係から見るユースケースと要求獲得
- 47:要求エンジニア
- 48:要求モデリングと誤り
- 49:要求を軸としたこれからのソフトウェア社会
- 50:ゴール指向とアスペクト指向要求工学
- 51:サービス指向要求工学
- 52:要求質問
- 53:試験工程での要求発見
- 54:要求とテスト
- 55:すりあわせの技術と価値星座
- 56:学生からの質問
- 57:SysMLの要求図
- 58:アシュアランスケースとGSN
- 59:組込み要求工学
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 10G-EPONの概要 その4-10G-EPONの課題と今後の動向-
【新ネットワーク】 - やっぱりおかしいよね?メモリの使い方
【通信ソフトウェア開発】 - 猿でもわかる”フレッツテレビ”その2
【猿でもわかるICT】 - 10G-EPONの概要 その3-10G-EPONの特徴2-
【新ネットワーク】 - 10G-EPONの概要 その2-10G-EPONの特徴1-
【新ネットワーク】 - 開発支援ツール
【通信ソフトウェア開発】 - 猿でもわかる“フレッツテレビ”その1
【猿でもわかるICT】


