【No.3】事実と意見を明確に

【No.3】事実と意見を明確に

今回は、ドキュメント作成において、事実と意見を混合してしまったことによる
失敗と教訓をお伝えしたいと思います。

■失敗談

CSVファイルをアップロードしてデータベースに登録する機能について、顧客からの要件をもとにCSVファイルのチェック方式設計書を作成しました。

チェック方式の要件は以下の通りです。

• 登録ID、カナ姓、カナ名、金額が設定されれていること
• 登録IDと金額は半角数字、カナ姓とカナ名は半角カナであること

要件をうけ、以下のようにチェック方式の表を作成しました

この資料を提示した所、顧客から「重複チェックを実施するなんて頼んでないけど・・」とご指摘を受けることになりました。

■問題点

重複チェックについては、「登録IDが重複すると、DBに登録する際に一意制約で落ちてしまう」為
開発側で気をきかせて入れた内容です。

しかし、方式設計書には開発側の提案だという記載をしていませんでした。

他のチェックと同様に記述していた為
顧客側からすると「頼んでないのになぜ？」という不信感を抱く結果となりました。

顧客からの「要件」と開発側の「意見」の
区別が明確に記載されていなかったことが問題でした。

■改善案

顧客から求められていないことを
開発側で行うべきと判断した場合
それを上手に伝えることが必要となります。

今回の例で言うと
要件にはないが、必要な旨とその理由を吹き出しで記載する。
等です。

■結論

決して、開発側から余計な口出しをするべきでない
という話ではありません。

よいシステムに繋がることはどんどん提案すべきだと思います。

ただし、伝え方には注意する必要があります。

ドキュメントを参照した際に

• 要件を元にした記載なのか？
• 開発側からの提案事項なのか？

とういことが明確にわかるようにすることで
顧客側が判断しやすい資料になり、スムーズな仕様決定が繋がるでしょう。