連載
» 2014年05月23日 13時00分 UPDATE

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

ソフトウェア開発プロジェクトで致命的な失敗を引き起こす、「仕様の誤解」が発生するメカニズムを詳しく解説します。

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授(工学博士),MONOist]
山浦恒央の“くみこみ”な話(63)

 ソフトウェア開発プロジェクトが失敗する2大要因が、「見積もり」と「仕様」のミスや誤解です。両方で失敗原因の95%を越えます。

 オフショア開発など、こちら側で仕様を書き、その仕様を外部の組織に送って外部のプロジェクトで開発する形態では、「見積もりミス」はこちら側の責任ですが、仕様関連の失敗は、こちら側と向こう側の両方が原因となります。

「レバーを90度回してください……」

 仕様書を読んで、「ここは、十分に理解できない」とか、「この機能を実現するには、複雑な処理が必要になりそうだ」という箇所は、お互いに注意をするのでミスは意外に多くありません。ですが、「自信を持って誤解する機能」は非常にタチが悪く、致命的な大問題に発展する場合も少なくありません。

 例えば電車のドア付近に「非常時は座席の下のレバーを90度回すと、ドアを手で開けられます」と書いたメッセージを見て、普通の人は、「時計回りに(あるいは、逆方向に)4分の1周分、レバーをひねればいい」と考えますが、「レバーを90周グルグルと回せば、ドアが手で開けられるのか。90回も回転させるのは、子どものいたずら防止のために違いない」と解釈することも可能です。そんな誤解をなくすためにキチンと書くと、契約書のように、何ページにもわたって文字がビッシリと並ぶ「誰も読まない注意書き」になります。

 これほど極端ではないにしろ、誰しも仕様書で「相手に誤解を与えた」「勘違いした」という経験があるでしょう。例えば、「プロジェクトマネジャーの指示通りにしたつもりが、全く関係のないことをした」「自分が頼んだことを正確に実行してもらえなかった」など、日々、経験することです。

 この問題が厄介なのは、勘違いしている人は、「自信たっぷりに誤解をしている」ことです。誤解している意識が全くありません。作家、曽根綾子は、「悪意から被る迷惑より、底抜けの善意から発生する迷惑の方がタチが悪い」という趣旨のことを書いています。

 相手のために一生懸命やったことが実は相手の迷惑になっているのに、そのことにはなかなか気が付きません。こんな「小さな親切、大きなお世話」のケースは、自分が気が付いていないだけで少なくないのです。

 ソフトウェア開発では、この種の「誤解」が判明するのは、最悪の場合、出荷を間近に控えた「受け入れテスト」時になります。出荷直前に、「レバーを90度回してください」的なバグが出ると、プロジェクトは崩壊します。

 以下では、自信たっぷりに仕様を誤解したり、勘違いをさせたりしてしまうメカニズムについて、解説します。

コミュニケーションモデル

 なぜ、相手に自分の言いたいことを伝えられなかったり、伝わらなかったりするのでしょうか。プロジェクトマネジメント知識体系集(PMBOK)では、他人とのコミュニケーションのモデルを図1のように表しています。

図1 図1 コミュニケーションの基本モデル

 図1は、送信者(話す人)と受信者(聞く人)の間で、アイデアや情報がどのように受け渡されるかを表しています。表1に図1の用語を説明します。

表1 コミュニケーションの構成要素
構成要素 意味
コード化 考えやアイデアを他者が理解できる言語に翻訳すること
メッセージ コード化のアウトプット
媒体 メッセージの伝達に使用する手段。例えば、対話、メール、音声通話、文書
ノイズ メッセージの伝達や理解を妨げる要素。例えば、開発文化の違い、技術力の違い、言語、時差、距離
解読 メッセージを意味のある考えやアイデアに戻すこと
       1|2|3 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.