プロジェクト管理において、ユーザー（お客様）からの要求を的確に把握し、それを元にどのような要件を満たすシステムを開発すべきかをシステム要件としてまとめること、すなわち要件定義はシステム開発の成功を左右する大元となります。
ところが、ユーザーの要求を把握する際に注意すべきことがあります。
例えば、ユーザーは今までの仕事のやり方に固執しがちであるということです。
かなり古い話になりますが以前の職場でほとんど手作業で行われていた業務を開発者としてシステム化する業務に就いていた時のことです。
システム化以前には注文書に記載する注文番号は年初にリセットしていました。
その理由は、年初に受けた注文は注文されたお客様に初出荷を印象付けるためということでした。
ところが、この年初のリセットは業務の機能的側面からみれば全く意味がありません。
しかもこのようなリセット機能をシステムに持たせることはそれだけ開発コストが増えてしまいます。
そこで、その旨をユーザーに何度か説明したのですが、しばらくは今までのやり方に固執して納得してもらえませんでしたが、結果的には注文番号はシステムの稼働後リセットしないことに収まりました。
このような事例はその後も何度か経験しました。
また、こういうこともありました。
ユーザー部門の担当者とある作業についてシステム化後のやり方について検討を重ね一定の結論に達しました。
そしてその方向で関連作業を進めていたのですが、暫くして担当者の上司にそのやり方について説明するとそのようなやり方では駄目だと否定されてしまいました。
ですから、それに関連した作業方法は全て練り直しです。
お互いに経験不足で適切な上司への報告を怠っていたのです。
また、システム設計の元となるシステム要件についても注意すべきことがいろいろあります。
そこで、ユーザー要件定義、およびシステム要件の関連作業を進める際に注意すべきことを以下に簡単にまとめてみました。
・ユーザー（お客様）の声は常に正しいとは限らないこと、すなわち”お客様は神様”ではないこと
・ユーザーは今までの仕事のやり方に固執しがちであること
・定期的にユーザー部門、開発部門の作業者はそれぞれの上司に作業状況（進捗、決定事項、問題点など）について報告すること
・ユーザーはそれぞれ自部門の立場から要求を出してくるので全ての部門からみると必ずしも整合性が取れていないこと
・従って、だれが最終的にシステム要求を決断するのかをあらかじめ明確にしておくこと
・最新の技術やツールの活用の可能性を探ることで最終的なシステム要件は大きく良い方向に変わること
・既存のツールに拘らず、必要に応じて自分たちでツールを開発することも検討すること
・ユーザー要求、システム要件は文書化しておくこと
・文書化したユーザー要求、システム要件については、ユーザー、開発者双方の最高責任者が承認すること
今回お伝えしたユーザー要件、あるいはシステム要件の注意点はシステム開発に限らず、業務改善なと何か新しいことを考える際にも参考になると思われます。
ですから、少しでも参考になればと思います。
