NTTデータ
技術開発本部
副本部長
山本修一郎
情報の質と量とコミュニケーションの関係
情報には、量の大小と客観的か主観的かという質の側面がある。図2では、この2つの側面から、コミュニケーションのあり方を次の4つに分類してみた。
図2 情報の質と量によるコミュニケーションの分類
◆対面型コミュニケーション
小量の主観的情報に対するコミュニケーションである。この場合、経験に基づく対面コミュニケーションとなるであろう。最も完璧なコミュニケーションは経験の共有である。以心伝心というように、客観的な言葉によって意思を伝えなくても受け手が行動してくれるようなコミュニケーションが最も効率的である。しかし、あらゆることを多くの人との間でこのような主観的な方法で理解しあうことは難しい。
◆手順型コミュニケーション
小量の客観的情報に対するコミュニケーションである。この場合、情報に対する行為を限定してマニュアル化するなどの手順化することにより、効率的なコミュニケーションが可能である。
◆価値共有型コミュニケーション
大量の主観的情報に関するコミュニケーションである。多様な価値観に基づく主観的な情報が多くなり、断絶が増加するので、相互理解のためにより多くのコミュニケーションが必要となる。
◆目的展開型コミュニケーション
大量の客観的情報に関するコミュニケーションである。情報が客観的に定義されればされるほど、その目的と意味を理解するために、より多くのコミュニケーションが必要となる。たとえば、専門知識の増加とそれにともなう専門家の増加と、専門家同士のコミュニケーションや連携が必要になることはその例である。
また大きな組織になればなるほど、組織の構成単位間でのコミュニケーションは客観的でなくては連携できない。組織の構成要素には全体の目的に応じたそれぞれの目的が必要になる。
前述した4種類のコミュニケーション型の組合せも考えられる。たとえば価値共有型コミュニケーションは、目的展開型コミュニケーションの結果として提供されるサービスに対する要望を具体化するしくみとして利用できるかもしれない。たとえば、同じ価値を共有するコミュニティの中でのコミュニケーションから、新しいサービスに対する要求が明確化できるだろう。また、目的展開型コミュニケーションでは組織の壁を越えるコミュニケーションも必要になるだろう。この場合、コミュニケーションには必ずしも十分に客観的な情報ではなく、主観的な価値を共有するコミュニケーションも必要になると思われる。
また、目的展開が限定された範囲の情報と組織に対して具体化されれば、手順化できるだろう。対面型コミュニケーションも特定のサービスのような場面を限定することで、やはり手順化できるようになる。最近、丸の内オアゾにある丸善に行った。端末があったので、探していた本のキーワードを入れて検索したら、その本が、何階のどの書架にあるかを印刷できるようになっていた。非常に便利である。すべての書籍の名前やそれがどこにあるかを記憶して、たちどころに答えるえことのできる書店員は極めて優秀な本のソムリエであろう。しかし、「私が探している本がどこにあるか教えてほしい」という限定されたコミュニケーションなら、このように客観的に記号化できるわけだし、顧客としても満足度が高いのである。
断絶の解消
コミュニケーションの断絶を解消するための手法には次のような方法が考えられる[3]。
- (1)送り手が知覚や期待の差異を認識する
- (2)受け手に対して、送り手の置かれた状況の複雑さや責任を理解させる
- (3)受け手の期待や価値観などに対して、送り手がどう対処するか意思決定する
この方法の留意点は、受け手に対して送り手とコミュニケーションする気にさせるという点であろう。送り手は一方的に伝えたいことを受け手に強制するのではなく、受け手の知覚範囲がどうなっているのか、送り手はどんな意味を持つ情報をなんの目的で受け手に伝えようとしているのかなどについてのお互いの背景を理解するためのコミュニケーションの準備としてのコミュニケーションの必要性を説くべきである。もしこのようなコミュニケーションが実施されれば、コミュニケーションの断絶を解消できる可能性は高まるだろう。少なくともお互いのコミュニケーションの断絶の理由を知ることができるはずである。
では、このようなコミュニケーションを実際にはどうすればできるだろうか?たとえば、組織のミッションを社員に理解して実践してもらうという状況を考えよう。ミッションが、社員の具体的な日々の行動とどういう関係にあるのかについて議論してもらうのである。その中で、様々な疑問や課題が発生することだろう。これらの課題についてミッションの送り手の立場で社員が考えることが重要だというわけである。このような議論の過程で相互理解の準備が醸成されていく。一方、送り手は、この議論の内容を知ることで、社員の知覚範囲や組織への期待を知ることができる。送り手としては、断絶を解消できないとしても、より適切な指示をより多くの情報に基づいて判断できるようになる。
コミュニケーションに対して、このような取り組みができている組織は、そうでない組織に比べてより緊密なコミュニケーションを実践できているといえるのではないだろうか?
「コミュニケーションとは組織のあり方そのものなのである。」(ドラッカー[3])
情報システムとコミュニケーション
情報システムとコミュニケーションの関係には、2つの側面がある。まず情報システムをコミュニケーションの送り手、情報システムの利用者を受け手と考えることができる。
情報システムが有効に機能するためには、情報システムを使う立場に立って情報の意味についての十分なコミュニケーションが必要になる。情報の意味は、情報システムの利用者にとって明確に定義されたものでなくてはならないからである。もし情報システムの操作が難解であるとすれば、情報システムの利用者としての受け手の知覚の範囲を考慮しないで、情報の送り手としての情報システムが実現されているからである。逆に利用者の期待通りの入出力動作を情報システムがしてくれれば、操作性の良い情報システムであるといえよう。先のドラッカーの言葉を拝借すれば、次のように言えるのではないだろうか?
「コミュニケーションとは情報システムのあり方である」
また情報とコミュニケーションの関係で明らかなように、情報の質と量に従ってコミュニケーションのあり方が異なるから、情報システムがどのようなコミュニケーションの型を対象とするかを理解しておくことも重要である。すなわち、コミュニケーションの型に依存して情報システムのあり方が変化するのである。
さて、もう一つの側面としては、情報システムの発注者と開発者との間のコミュニケーションが考えられる。この場合、開発者の提案は、発注者が想定する範囲内で、発注者の期待に応えることで、発注者からの開発依頼として、コミュニケーションが完結する。このようなコミュニケーションのあり方を観察することで得られる要求分析に対する知見としては、発注者のスコープ、期待としてのゴールを明らかにすることで具体的なシステム要求を明確化できるということではないだろうか?
まとめ
今回はドラッカーによる情報とコミュニケーションについての考察に基づいて、前回紹介した言語行為展望論と対比しながら、組織におけるコミュニケーションのあり方について述べた。コミュニケーションの断絶を解消するには、新たなコミュニケーションによって人間関係を再構築していく必要がある。
ドラッカーに従ってまとめれば、次のようになる。
- コミュニケーションとは受け手の行為である
- 受け手に耳を傾けるだけではコミュニケーションは機能しない
- 情報を集めるだけではコミュニケーションの断絶を埋めることはできない
参考文献
- [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]P.F.ドラッカー、すでに起こった未来、10章 情報とコミュニケーション、ダイヤモンド社,1994
- 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:保証ケース作成支援ツールの概要