文書で確認することが基本動作
トラブル発生時など急ぐ時、口頭で要件を聞いて修正をしてリランなどということはよくあることです。
口頭では要件を絶対受け付けるな…などと言っているわけではありません。しかし、伝言ゲーム状態になるとは言わないまでも、口頭での伝達には漏れ、抜け、勘違い、決め付け、了解違い…といった不幸なことがたくさん起こります。
聞いた、聞かない、言った、言わない、ああ言った、こう言ったというトラブルも、口頭ならではの出来事といえましょう。間違いは聞く方だけに発生するわけではありません。話す方も口頭の時は思考に漏れが生じやすいと言えます。
もちろん、文章にすれば、漏れや、抜け、勘違い、決め付け･･などが完全に排除される。とは言いません。書いても、よく読まない人もいます。口頭の方が誤りを生みやすいと言うことが定量的に実証できているわけではありませんが、しかし、経験的には間違いなく、口頭の方がミスを生みやすいようです。
ということで、口頭でやり取りした時も、必ず文書で確認をすることを基本動作としましょう。
口頭での要件、修正変更のやり取りを行わない。
が原則なのです。
さらに、文章とする場合も、聞き手が書き起こして依頼者に確認するより、やはり依頼者自らが書いた方がミスは少ないでしょう。文章にすることにより不明確なところが明確になります。文章を書くのに必要な時間は、物事を過不足なく捕らえるために人間が必要とする長さなのです。
ところで、私が勤めていた損害保険会社には、「リスク管理シート」というプロジェクト管理ツールがありますが、そこに、次のような一項があります（少しだけ用語を変えてあります）。
□主要な要件について、開発依頼者との会話の中から推測している、または口頭のみの確認である（要件が文書化されていない）
いかがでしょう。
ちなみに、この項目についてはリスク評価の係数が他の項目より高く設定されています。他の項目よりリスクが高いというわけです。
依頼者が実現したいことを自分で書かない、そこからして人の道を外れている…とまでは言いませんが、やはり伝言ゲームにならないよう、依頼者自らが責任を持って自分の実現したいことを書く。これがトラブル削減に向けた出発点ですね。
JUAS（日本情報システムユーザー協会）が一般事業会社のシステム部門に対し行った「IT動向調査2005」に、要件定義についての興味深いアンケートがあります。システム開発の、開発依頼側当事者としての要件定義作業に係る反省点を調査したものですがアンケートに回答した651社中606社が、「システム仕様定義が不十分なまま発注してしまった」392社が「要求仕様条件を明確に提示しなかった」と回答しています。
解決策としても、仕事の進め方について標準化を進め、開発依頼側と、開発受託側がうまく連携して、合理的な役割と責任分担をしてシステム開発を行わないとシステム開発はよくなっていかないと正しく認識しています。
開発依頼側、開発受託側も協力してミスが発生しない体制を作り、しっかりとしたプロセス定義にしたがって、ベースラインドキュメントを軸に仕事を進めることがトラブル発生防止の鍵ですね。
※JUASが行った各種調査は、サイトからで入手できます。
