普通の地方公務員が、ある日突然システム担当になったら（開発テスト編）

テストを発注者がしないといけないのか？

結論から言うとテストは必要です。

発注者がテストをする意味としては、
　①発注者と受託者間の認識のずれの回避
　②本番の運用を想定したリハーサル
　③履行（受入）の確認
などがあります。

①発注者と受託者間の認識のずれの回避

　部下や同僚に資料作成をお願いしたら、自分のイメージした資料と異なる資料が出てくることはありませんか？
　他の人に自分の思っていることを正確に伝えるのはなかなか難しいことです。
　同様に、システム事業者と設計書を作り、念入りに打合せしたとしても、そもそもの認識がずれていたら、システム事業者がテストを完ぺきにやったとしても、意図したものと違うものができあがってしまいます。

　普段から税にかかわる役所の担当者からすれば、「所得」と「収入」の違いは分かって当然ですが、普通のシステム事業者はシステムのプロであれ、税業務のプロではありません。
　そのため、「所得」と「収入」が同じものだ思いこみ、システムを作ってしまうと想定と違う計算結果が出てくることになります。

　発注者が早々にテストを行い、こういった認識のずれをつぶしていかなければなりません。

②本番の運用を想定したリハーサル

　業務運用を想定して行うテスト（運用テスト）は、システム事業者が行うことは難しいです。先も言いましたが、システム事業者は業務のプロではないからです。

　業務担当者は、本番を見据えて、テストを行う必要があります。
　本番を想定してテストを行うといろいろと問題が出てきます。

　国の特別定額給付金のシステムでは、末端の自治体を含めた運用テストはなかったと思います。
　規模が大きすぎて、運用テストの実施が難しいこともあったかもしれませんが、結果的には、本番の運用が、運用テストのようになってしまって、本番後に、いろいろな課題が噴出しました。
　こうなると、利用者からは使えないというレッテルを張られてしまい、以後、システムが使われなくなります。

　システムの利用者が役所の業務担当者の場合は、テストに参加してもらい、操作性も併せて確認してもらいます。
　これによって、運用開始後に、業務担当者からクレームが出るのを軽減できます。

　システムの利用者が、市民の場合は、市民になったつもりで、一連の操作がスムーズに行えるかテストを行います。
　この場合でも、いろんなパターンを想定してテストをする必要があるため、テストの協力者は多いほうがいいです

③履行（受入）の確認

　最終的にシステム事業者が作ったシステムに問題がないか確認します。

「システム事業者がテストをしてから、完成したものを納品すべきだ」、という意見もあります。
　しかし、委託契約であれば検収や履行確認が必要ですので、システムが発注した通りになっているか確認する必要があります。

　マンションやアパートを借りて、引き渡しの時に、壁紙が破れてないか、カギはきちんとかかるかなど確認すると思います。
　同じように、システムに問題がないか確認します。

　検収が終わったあとに、不具合が見つかったとしても、システム事業者の完全なミスであれば、システム改修を要求できますが、ちょっとした機能改善などは、基本的には有償になってしまいます。

　履行（受入）の確認はシステム引き渡しの大事な確認になりますので、決して、業者に丸投げせずに、自らテストを行い、確認を行ってください。

まとめ

　システムのテストには多くの人手が必要です。
　上司やシステム利用者の理解と協力が必要となりますが、ここが一番難しいかもしれません。
　使えないシステムが出来上がらないようにするためには、多くの人の協力をえて、業務の流れに沿ったテストを行う必要があります。
　本番でのトラブルをできるだけ減らすためにも、念入りにテストを行ってから、システムを稼働しましょう。