システム導入プロジェクトが失敗する要因の1つに、システムの発注先に仕事を丸投げすることが挙げられます。システム導入は自分たちの業務を支えるツールになるため、メインで動くべきはむしろ発注側です。
当記事ではシステム導入プロジェクトにおける発注者側のやるべきことについて解説します。
発注者側のタスク
システム導入プロジェクトにおいて発注者側が行うべき主なタスクは以下の通りです。
- RFI・RFP作成
- ベンダー選定
- 要件定義の準備と参加
- システム設定や基本設計の確認・承認
- データ移行の準備・調整
- システム移行準備・調整
- 運用設計・運用テスト
- 受入テスト
- 本番移行
プロジェクトの規模や特性によって発注者側が行うべきタスクは増減しますが、一般的には上記のようなものが挙げられます。
この記事では、上記の中でも発注者側の関わりが必須となる「要件定義の準備と参加」「設計の確認・承認」「データ移行の準備・調整」「受入テスト」について解説していきます。
要件定義の準備と参加
システム開発のベンダーは発注側の業務について何も知りません。一般的な業務の流れや課題解決のためのソリューションは持ち合わせていますが、独自の業務については全くの素人と言えます。
要件定義は業務に必要な機能の洗い出しなどを行うため、業務を詳しく知っている発注者側の参加は不可欠です。
ただし、参加だけでは要件定義はうまく進められません。要件定義を効率よく進めていくためには、業務を可視化したドキュメントが必要になります。例えば業務フロー図です。
業務フローなどのドキュメントを作成し、内部で認識を合わせておかないと、担当者が変わるたびに要件がズレてしまい、要件定義がうまく進められません。
要件定義への参加だけでなく、業務に関するドキュメントを揃えておくのも発注者側がやるべきタスクになります。
設計の確認・承認
要件定義が終わると次は基本設計書を作成していきます。
基本設計書は画面設計や帳票設計など、ユーザーが実際に触れるものの設計を行う事が多いため、設計の内容に不備が無いかをチェックすることが求められます。
この確認を疎かにしてしまうと、実際にシステムが出来上がったときに、操作性が悪かったり要求通りの動きをしなかったりしてしまいます。ベンダーから要件定義通りに作りましたと言われてしまえば、ウォーターフォール型の開発プロセスにおいては、手戻りなどの余計なコストがかかってしまうことになるわけです。
中には設計書では判断できないものも出てくるかもしれません。その時は納得できるまでベンダーにきちんと説明してもらうようにましょう。その説明の議事録や録音をとり、ベンダーと発注側の双方で合意を取っておけば、後々の揉め事を回避する事ができます。
要件定義よりもシステム的な話が多くなる基本設計のフェーズですが、毛嫌いせず1つ1つ丁寧に確認・承認していくことが重要です。
データ移行の準備・調整
データ移行にも発注者が行うべきタスクがあります。主に以下のようなタスクです。
- 移行要件定義
- データクレンジング
- 過渡期業務調整
一部はベンダーに依頼することも可能ですが、その分工数がかかるため費用が多くなります。
移行要件定義
データ移行は、現行システムに登録されているデータをどこまで新システムに移すかを検討する必要があります。
他にもデータベースのどの項目にデータを移すかなどデータ移行にも要件定義というものがあるため、発注者側が主体となってデータ移行における要件を決めていく必要があります。
データクレンジング
データクレンジングは登録データの表記の揺れを正したり、不要なデータを削除したりする作業です。
データクレンジングはまず最初に方針を定め、データに直接手を加えていくことになりますが、そのデータをシステムから出力したときにどう使いたいかを考えて、方針を決めていく必要があります。
このタスクにも発注者側の意見は不可欠であるため、ベンダーに丸投げすることは避けるべきです。
過渡期業務調整
過渡期業務調整は、新システムに移り変わることに伴う現行システムの停止やデータ登録の凍結、稼働後の訴求入力などが挙げられます。
新システムに移り変わることによって、通常では行わない作業や調整が入るため、事前にどう言うことが必要になるかを検討して計画を立て、それを遂行出来るだけの要員を確保していきます。
これはベンダー側だけでは行う事が出来ないため、発注者側も検討に加わり、システム停止期間中のデータ登録の方法や訴求入力などについては落とし所を模索する必要があります。
受入テスト
受入テストはUAT（User Acceptance Test）とも言われますが、発注者側が主導して行うべき最も分かりやすいタスクです。ベンダーが開発したシステムで業務を行うことができるかを確かめ、発注者側がシステムの納品を受け付けるかを判定するためのテストです。ここで潜在しているバグや仕様漏れを見つけることが出来ないと、稼働後に発見されることになり、システムを使う現場は困ることになってしまうため、慎重に進めていく必要があります。
受入テストを効果的に進めていくためには、やはり準備が重要になります。要件定義によって新たに作られた業務フローや機能一覧から、更新や削除登録などのイレギュラー処理を考慮して、業務シナリオ一覧を作成していきます。
受入テストでは、この業務シナリオ一覧に則り、全ての業務と機能が網羅できるようにテストを進めていきます。
システム開発工程の最後に行うテストである受入テストは、システムの納品を受け付けるかを判定する検収と等しい位置付けにあります。
最後の砦にもなりますので、準備を怠らずたくさんのバグを見つける気持ちで挑みましょう。
まとめ
ここで説明したもの以外にも発注者側が行うべきタスクは他にもあります。プロジェクトが大規模になるほど、発注者側が行わなければならないタスクは増えていきます。
また、すべてのベンダーが発注者側に対して行動を促してくれる訳ではありません。ひどい時には、発注者側が何も分からないことを良いことに、レビューや承認を全く受けず、開発完了しましたと言ってくるベンダーも中にはいます。その後受入テストをしてみたら業務を回すことができない状態だったと言うことは珍しくありません。
そうならないためにも発注者側はやるべき仕事を理解し、逆にベンダーの行動を促していく必要があります。
しかし、発注者側の人的リソースにも限りがあるため、ベンダー任せにしてしまいがちなのが現実です。外部のコンサルタントなどをうまく使いながら、ベンダーをコントロールし、発注者側が主導してプロジェクトを成功に導いていくことが大切です。
