NTTデータ
技術開発本部
副本部長
山本修一郎
会話構造の具体例
次では、会話構造の具体例として、質問回答、問題発見、2人ゲーム、調査報告の記述例を紹介しよう。
質問応答の会話モデル(図2)
図2 質問応答の会話構造
まず、質問者が回答者に質問を提示する。回答者が回答するまで、回答待ち状態になる。ここで、回答待ち状態の背景を無色として他の状態と区別している。回答者が回答しないと、質問者が督促する。回答者は回答を拒否するかもしれない。また質問者が、質問することを辞退するかもしれない。このときは質問者の理解不足状態になる。
回答者による回答を質問者が受け取って、回答内容が理解できると、了解を回答者に伝えて、質問者は理解状態になり、終了する。一方、ここで質問者は新たな質問を回答者に提示するかも知れない。この場合、また質問者は回答者からの回答待ち状態に遷移する。回答待ち状態では、回答者が回答することを延期したいという提案を質問者にすることがあるかもしれない。この場合、質問者が賛成すれば延期状態になる。いったん延期状態になっても新たに質問者がやはり質問したいということになるかもしれない。
このように、質問者と回答者の会話には、多様なブレイクダウンの可能性とそれに対する反応を会話モデルで記述できる。この例では、筆者が最近経験したあることについての電子メールでの質問と回答の事例をモデル化した。
問題発見の会話モデル(図3)
この事例は、職場での問題を把握するためのコミュニケーションを会話モデルで記述したものである。
図3 問題を発見するための会話構造
まず、上司が部下に何か問題はないかと問いかける。このとき、聴取状態となり、部下からの問題提起を上司が待つことになる。部下からの問題提起に対して、上司が了解すれば、問題を理解した状態になる。また上司は部下からの問題提起に対する回答を部下に提示するかもしれない。一方、上司が問題提起への回答を放棄すれば、理解不足という状態になる。ここで、上司は部下からの問題提起に対して、逆に新たな問題を部下に提示するかもしれない。たとえば、部下から「組織のミッションが良く分からない」という問題提起に対して、「組織に対して君自身が社員として何ができるか考えたまえ」というような場合である。いつの時代も受身の社員がいるものだ。しかし、それでは上司と部下で堂々巡りになるかもしれない。それはさておき、この場合には部下が上司からの問題再提起に対して、考察状態になる。ここで部下はそんなことに答えるのはいやだと拒否するかもしれないし、まじめに考えてまた問題を提起するかもしれない。
社員からの問題提起がそれ以上なければ、問題がないことを理解して問題理解状態になる。
このように職場での口頭によるコミュニケーションも会話モデルで簡単に記述できる。職場ではこの他にどんなコミュニケーションの問題があるだろうか?みなさんのコミュニケーションに対する理解をぜひ会話モデルを使って、深めてみていただきたい。そうすることでコミュニケーションのベストプラクティスやべからず集ができることを期待したい。
ゲームの会話モデル(図4)
図4 ゲームの会話構造
次に、将棋や碁、チェスなどの対戦型のゲームはどう記述できるだろうか?この場合も簡単に記述できる。詳細な説明は省略するが、ポイントは、正常な手の差し合いだけでなく、待ったや中断というブレイクダウンを考慮した点である。このような機能は、ゲームソフトでも用意されている。逆に言えば、対話型システムの設計では、このような会話構造の分析が不可欠になるということだ。
調査報告のための会話モデル(図5)
図5 調査報告のための会話構造
最後に、少し複雑な例を紹介する。この例は、調査報告の作成を依頼者から提供者に注文するために生じる会話モデルである。この例では、図1で紹介した約束についての会話状況とブレイクダウンを含んでいる。また、報告内容に不備があれば提供者が修正して再納入することや、調査を実施している過程で新たな調査項目が発生して依頼者が調査内容の変更を依頼するための会話構造を記述している。また、この一連の会話過程で調査の取り下げや辞退などのブレイクダウンが発生する可能性がある。
この例を見れば、SEと営業のコミュニケーションの構造も表現できることが分かるだろう。
今回は要求工学だけでなく日常のマネジメントでも重要なコミュニケーションについて言語行為展望論とそれに基づくWinogradの会話構造モデルを紹介した。また会話構造モデルの有効性を示すため、具体的に4つの典型的な例を紹介した。これらの例からもわかるように会話構造モデルを用いれば、システムの利用シナリオに関する要求を抽出することもできる。また顧客との要求獲得プロセスにおけるコミュニケーションや、システム開発全体のコミュニケーションを分析することができることもわかるだろう。会話構造モデルはこのような幅広い応用領域を持つにもかかわらず、日本ではあまり十分に知られていないのが残念である。その理由の一つとして、Winogradのオリジナルな会話構造モデルでは、状態が番号だけで区別されているとこや状態遷移のラベルが言語行為展望論で用いられる専門用語であり、そのイメージから、一般のソフトウェア技術者にとっては近づきにくい印象があったからかもしれない。しかし、今回紹介したように、会話構造モデルは極めて一般的で扱いやすいモデルであり、シナリオ分析やユースケース分析との併用も容易ではないかと考えられる。またプロジェクトマネジメントにおけるコミュニケーションのあり方やリスク分析にも応用できる。実際のシステム開発では、このような点を参考にしてぜひコミュニケーションについての展望を持つことで、顧客満足度の高いシステムの構築につなげていただきたい。
参考文献
- [1] Winograd, T. and Flores, F. Understanding Computers and Cognition: A New Foundation for Design. Ablex, Norwood, NJ, 1986. (平賀譲訳、コンピュータと認知を理解する-人工知能の限界と新しい設計理念-、産業図書, 1989.)
- [2] Terry Winograd., A language/action perspective on the design of cooperative work. Journal Of Human-Computer Interaction, vol.3, No.1, pp.3-30,1987.
- [3] Terry Winograd, Designing a new foundation for design, COMMUNICATIONS OF THE ACM, Vol. 49, No. 5, pp.71-74, 2006
- [4] Raul Medina-Mora, Terry Winograd, Rodrigo Flores, Fernando Flores, The action workflow approach to workflow management technology, Proceedings of the ACM conference on Computer-supported cooperative work, Pages: 281 -288, 1992
- [5] PETER J. DENNING and ROBERT DUNHAM INNOVATION as LANGUAGE ACTION - by learning seven foundational practices, anyone can become a skillful innovator, COMMUNICATIONS OF THE ACM, Vol. 49, No. 5, pp.47-52, 2006
- 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:保証ケース作成支援ツールの概要