ソフトウェア開発プロジェクトが大ごけする“カラクリ”：山浦恒央の“くみこみ”な話（63）（3/3 ページ）

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），MONOist]

STEP.5　聞き手が理解する

　聞き手（受信者）は、本人の背景に従って解釈（解読）します。図6では、「プロジェクトの状況は今のところ問題ない」と理解しています。しかし、話し手が将来の状況を考えた上でのプロジェクトの状況を聞いている場合はどうでしょう。聞き手は完全に誤解しています。これが「勘違い」のメカニズムです。

図6　誤解のメカニズム

STEP.6　確認する

　話し手（送信者）の考えが正しく伝わるとは限らないため、話し手は「受信者がどう理解しているのか」を確認（フィードバック）する必要があります。図7では、聞き手が「現在の状況という意味ですか？」と確認しています。この例では、聞き手が「現在は、問題はないという意味ですか？」と聞き返していますが、現実には、相手が再度誤解し、「問題ありません」と答える可能性があります。その場合、「あの時、確認したじゃないか……」という「言った言わない」論を延々と繰り返すケースに発展することも容易に想像できます。

図7　理解の確認

終わりに

　今回は、ソフトウェア開発プロジェクトで致命的な失敗原因になる「仕様の誤解」が発生するメカニズムを解説しました。コミュニケーション上の誤解は、本人が間違いに全く気が付いていないというタチの悪い問題です。

　コミュニケーションのノイズから発生する誤解は、身近な兄弟や親とのコミュニケーションでも起こります。これを防ぐ方法として、（1）相手と定期的に、頻繁に、コミュニケーションを取る、（2）相手が設計に入る前に、仕様書をベースにして、テスト項目を作ってもらい、誤解がないかチェックするなどの対策があります。

　「自信たっぷりの誤解」は、「自信たっぷりの仕様記述」から生じます。「簡単なことだから、誤解の余地はない」と思わず、「レバーを90度回してください」のような問題が常に生じることを意識していただければと思います。

	参考文献：
⇒	『はじめてのPMBOK』NECラーニング株式会社（2012/9/25）
⇒	第『プロジェクトマネジメント知識体系ガイド第3版 A Guide To The Project Management Body Of Knowledge』Project Management Institute（2005/2/14）