Pocket

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

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

失敗談

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

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

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

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

【表】エラーの場合、画面最下部にエラーメッセージを表示する。
チェック種別 登録ID カナ姓 カナ名 金額 エラーメッセージ
必須チェック {項目名}は必須項目です
型チェック 半角数字 半角カナ 半角カナ 半角数字 {項目名}の文字種別が不正です
重複チェック 登録ID重複時、エラー 登録IDが重複しています

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

問題点

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

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

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

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

改善案

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

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

結論

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

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

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

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

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

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