いままでのヒアリング結果を要件定義書としてまとめ、レビューすることになった。いつも、ベンダー視点のベンダーしかわからない表現で記載されていることが多く、しかし情報システム用語も多い傾向がある。D社小林から、要件定義書レビューについて、事前レクチャーがあった。また、情報システム部向けに、アーキテクチャの設計書レビューについて、説明があった。
要件定義書レビューはとても大切！
設計書レビューの仕方で、後工程の出戻り、品質、生産性は大きく変わってくる。しかし、やらなければならない業務は多数あり、期限に追われ、読み込む時間が足りないのが、実態である。そこで、押さえるべき本当のレビューポイントを理解することが、現実的である。
ヒアリングされた内容・用語が正しく理解されて記載されているか？
ベンダーは、S社の業種経験者を担当させる努力はするが、どうしても頭数を集めるには下請け構造に頼るしかなく、全員が経験者になることは現実的ではない。どうしても、一部の従事者のみになってしまう。一部のメンバーがベンダー内での内部レビューを全部こなすわけにはいかない。納期を考えると実質的に放置状態になる。このようなベンダー側の都合があるため、レビューで確認して指摘をする必要がある。S社からすれば、開発ベンダの問題と思う人もいるが、目的はS社のビジネスの成長基盤を作ることなので、割り切って自分たちの業務として取り組むことが大切である。
業務フローに矛盾・無理（運用が困難であることが予想される）がないか？
業務フローのレビューでは、矛盾・無理がないか確認をする。たとえば、物流部門に13時に当日お届けするピッキングデータが届いても、運送会社は対応できない。つまり、現実的である業務フローでなければならない。基幹システムを入れ替えるため、業務を改善したいと思うし、実際に改善をする。そこで陥りやすいのが、常に気にしている業務に特化してしまい、他の関連業務が煩雑・負荷が上がってしまうことが往々にしてある。広く、影響範囲を含めて、確認する必要がある。
機能に過不足はないか？
各部門からのヒアリングをまとめてみると、案外と機能漏れが多い。ヒアリングする人の主業務は日頃から気にしているため、説明できるが、それ以外は難しい。曖昧な記憶で説明する。だから、業務の流れで過不足を確認する。実際に細部まで見えるようにイメージする。忘れがちが、月一のルーチンワークです。派遣にお任せしている処理は忘れがちである。
機能の目的に間違いは無いか？
機能は記載されているが、利用目的が間違っていると機能の細部に影響がある。たとえば、在庫一覧の機能があるとする。商品名順に在庫数量がわかる機能を想像するが、在庫一覧の目的が、機会損失をしないため都なると、違ってくる。在庫数量の少ない順・減り方の推移・在庫切れまでの予想残日数などの表示が必要になる。在庫管理といっても目的によって違いのである。
イレギュラー時の逃げ道は、機能としてなくてもあるか？
業務にイレギュラーはつきものである。予測不能のイレギュラーもあり、想像して機能を準備するのは、投資の無駄である。
コンプライアンスの視点から不正防止の仕組みを前提に逃げ道をつくることが必要である。通常発生では無いので、少し手間がかかっても良い。万が一の対応である。事例の多くは、情報システム部門が、手作業することである。
補足となるが、パッケージだからといってカスタマイズ分だけでは、設計書のレビューにはならない。理由は、業務は流れであり、流れがレビューできなければならないからである。ユーザー部門からは、あっていると思うけど、イメージがわかないとあった。実際に動かないと疑問や間違いに気づけない。対策として、HTMLで紙芝居を作り、説明することにした。
アーキテクチャ設計は、コストに大きく関係する
アーキテクチャは、知識が必要でベンダ任せになることが多い。しかし、設計書レビューをすることで、余計な開発コスト、運用コストを削減できる重要な意味がある。
観点は、運用性、メンテナンス性と性能がある。
