はじめに
情報システム部の方で、ITに詳しいだろうからという理由で、ビジネス用のシステム開発のマネージメントをするように依頼されることはないでしょうか？
実際は情報システム部の仕事と、ビジネス用システムの開発は大きく異なるものかと思います。
また、非IT企業では、システム開発を依頼する機会も少なく、一発勝負になることも多いです。
そんなお悩みを解決できるよう、いち非IT企業の情報システム部メンバーとして、実体験に基づくシステム開発の依頼の流れをまとめさせていただきました。
システム開発でお悩みの方は、是非見てみてください！
またITベンダーの皆さんにも企業側はこんなこと考えてるんだなーと思ってみていただければ嬉しいです。
受入試験（UAT）とは？
受入試験とは、システム開発を開発ベンダーに発注するなどし、納品されたときに、受注者の目的・意図通りに稼働するかを検証するための試験。不具合を見つけ出す目的ではなく、「実際に使うことができるシステム」であることを確認する。
発注する場合は最終防衛ラインとなる。要求者では書ききれない可能性があるため、情報システム部は支援者として、代替して作成してあげることが好ましい。また、受け入れ試験で差戻の可能性がある場合は、RFPに明記すべきである。
受入試験書類は、保守性開発に備え、次回リリース時に転用できるものとするとなお良い。
保守性開発とは？
保守しながら軽微な改修もしてほしい場合にお願いする保守形態である。非IT企業においては人的リソースの問題から改修がしづらいこと、また改修を受け持つと瑕疵担保責任が切れる可能性があることから、ベンダーに継続依頼することが非常に多い。
瑕疵担保責任とは？
システムに欠陥が発見された場合に、その欠陥がシステムベンダー側の不備によるものであれば、無償で改修してもらえるというものである。一般的にはシステム受入後1年とする場合が多い。
実際は、システムベンダー側の責任であると言い切れるケースは少ない。都度判断となり、結局は発注者側が泣きを見るケースが多い。少しでも可能性を上げるためには打合せなどはキチンと議事録を取り、双方で回覧するといった対応をすることが望ましい。
受入試験の観点
以下のような試験を実施することが望ましい。
- 動作確認試験：要求定義と照らし合わせ、達成できていることを確認する。
- マニュアル試験：システム運用マニュアルなどをもとに、運用担当者に動作確認をしてもらう。
- βベスト：実利用者・利用を模擬したメンバーに使用してもらい、使用感・不具合が無いかを確認する。
受入試験が終わればシステム開発としては、ひと段落が着くことになります。保守運用のメンバーに引継ぎを行い（結局自分が保守運用メンバーとなることも多いが）終結に向かうことができます。
振返り
受入試験が完了し、システムリリースが終了し、保守運用動乱期が落ち着いた頃に、振り返りを行うことが望ましい。
検収等の作業も終わっているため、開発にてベンダー契約が終了した場合は、営業対応として実施いただけるかを相談する必要がある（ないしは、RFPに明記する）。
振返りでは、ビジネス側・ベンダー側の双方に正直ベースで会話をし、良かった点・悪かった点の洗い出しを行う。そして、次回よりスムーズな開発ができるよう、ナレッジ化し社内共有すべきである。
また、情報システム部門としては、開発成果物や議事録を含め、プロジェクトによって生まれたすべてをプロジェクト管理ツールなどで保存・凍結しておくことが望ましい。これは次回同様のシステムを構築する際に、担当者が事前に確認することで、全体の見通しを持て、危険なポイントを察知することができるからである。
コメント