Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

第3回 【参】口頭での要件、修正変更のやり取りを行わない。

  2007/10/25 12:00

 トラブル発生時など、口頭でやり取りした時も、必ず文書で確認をすることが大事です。ドキュメントを軸に仕事を進めることがトラブル発生防止の鍵といえます。

文書で確認することが基本動作

 

 トラブル発生時など急ぐ時、口頭で要件を聞いて修正をしてリランなどということはよくあることです。

 口頭では要件を絶対受け付けるな…などと言っているわけではありません。しかし、伝言ゲーム状態になるとは言わないまでも、口頭での伝達には漏れ、抜け、勘違い、決め付け、了解違い…といった不幸なことがたくさん起こります。

 聞いた、聞かない、言った、言わない、ああ言った、こう言ったというトラブルも、口頭ならではの出来事といえましょう。間違いは聞く方だけに発生するわけではありません。話す方も口頭の時は思考に漏れが生じやすいと言えます。

 もちろん、文章にすれば、漏れや、抜け、勘違い、決め付け・・などが完全に排除される。とは言いません。書いても、よく読まない人もいます。口頭の方が誤りを生みやすいと言うことが定量的に実証できているわけではありませんが、しかし、経験的には間違いなく、口頭の方がミスを生みやすいようです。

 ということで、口頭でやり取りした時も、必ず文書で確認をすることを基本動作としましょう。

 口頭での要件、修正変更のやり取りを行わない。

 が原則なのです。

 さらに、文章とする場合も、聞き手が書き起こして依頼者に確認するより、やはり依頼者自らが書いた方がミスは少ないでしょう。文章にすることにより不明確なところが明確になります。文章を書くのに必要な時間は、物事を過不足なく捕らえるために人間が必要とする長さなのです。

 ところで、私が勤めていた損害保険会社には、「リスク管理シート」というプロジェクト管理ツールがありますが、そこに、次のような一項があります(少しだけ用語を変えてあります)。

□主要な要件について、開発依頼者との会話の中から推測している、または口頭のみの確認である(要件が文書化されていない)

 いかがでしょう。

  ちなみに、この項目についてはリスク評価の係数が他の項目より高く設定されています。他の項目よりリスクが高いというわけです。

 依頼者が実現したいことを自分で書かない、そこからして人の道を外れている…とまでは言いませんが、やはり伝言ゲームにならないよう、依頼者自らが責任を持って自分の実現したいことを書く。これがトラブル削減に向けた出発点ですね。

仕様が不十分なまま発注

 JUAS(日本情報システムユーザー協会)が一般事業会社のシステム部門に対し行った「IT動向調査2005」に、要件定義についての興味深いアンケートがあります。システム開発の、開発依頼側当事者としての要件定義作業に係る反省点を調査したものですがアンケートに回答した651社中606社が、「システム仕様定義が不十分なまま発注してしまった」392社が「要求仕様条件を明確に提示しなかった」と回答しています。

IT動向調査2005より
IT動向調査2005より

 解決策としても、仕事の進め方について標準化を進め、開発依頼側と、開発受託側がうまく連携して、合理的な役割と責任分担をしてシステム開発を行わないとシステム開発はよくなっていかないと正しく認識しています。

 開発依頼側、開発受託側も協力してミスが発生しない体制を作り、しっかりとしたプロセス定義にしたがって、ベースラインドキュメントを軸に仕事を進めることがトラブル発生防止の鍵ですね。

 ※JUASが行った各種調査は、サイトからで入手できます。



著者プロフィール

  • 菊島 靖弘(キクシマ ヤスヒロ)

    独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター(SEC) リサーチフェロー。 1975年東京海上火災保険に入社。以来30年間、損害保険、生命保険、確定拠出年金といった業務システムの開発に携わった他、東京海上日動システムズ取締役品質管理部長として、トラブル削減や、開発品質管理の向上を実現。2005年から株式会社アイネス。経済産業省・プロセス改善研究部会主査、同・開発プロセス共有化部会副主査。東京海上日動システムズ技術顧問。情報処理学会IS研究会委員。JUAS主席研究員。JISA要求工学調査委員会委員。 著書:SEC BOOKS「経営者が参画する要求品質の確保―超上流から攻めるIT化の勘どころ」(オーム社・共著)、「実務で役立つプロジェクトレビュー」(翔泳社)

バックナンバー

連載:開発担当者必携!トラブル削減のための原則拾七ヶ条

もっと読む

All contents copyright © 2007-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5