この記事で理解できることシステム発注プロセスの中での位置づけ標準機能を設定する外部インターフェース実装アドオン開発を行う業務改善を行う移行に向けた準備、結合/総合テストを実施する実装後はついに新システムリリースに向けた最終準備この記事で理解できること本記事では、新システムの導入や既存システムの刷新に向けて、システム開発会社との要件定義が終わり、システム開発会社側で実装作業に入った後に発注者側として実施すべきことや意識すべきポイントを解説いたします。システム開発会社に発注した後、発注者側はシステム開発会社側任せにしてよいわけではありません。システム開発会社に任せきりにせず、今後自分たちで使うシステムを完成させるために、適切な情報を伝える必要があります。パッケージを導入する際、標準的な機能で製品化されているパッケージを、自社システムとして利用するために設定作業を行います。システム開発会社側だけではなく、発注者側が主体的に実施すべきタスクも補足しながら解説していきます。システム発注プロセスの中での位置づけ本記事では、システム発注プロセスにおいて、「5実装」を解説します。前フェーズの要件定義で検討し決定した内容をベースに、実装作業に入ります。システム発注プロセスの全体について把握しておきたい方、前フェーズの「要件定義」について実施内容やポイントを知りたい方は、こちらの記事をご覧ください。標準機能を設定するまずは、要件定義フェーズで実施したFit&Gap分析において、Fitした機能に対して行う作業です。発注者側の要求に適合している機能もそのまま利用することはできず、基本的には自社で利用したい情報や設定を行った上で初めて利用することができるようになります。設定する内容としては、例えば、マスタ、アカウント、処理ルールなどがあります。通常は、システム開発会社側で設定するためのフォーマットシートを用意していることが多いため、受領したフォーマットシートに発注者側が内容を記入していきます。標準機能の設定については、「セットアップ」と呼ぶこともあります。今回導入するパッケージの新システムが、社内の他システムと連携している場合、他システムと連携するための作業も必要となります。(異なるシステム間のデータ連携を行うプログラムのことを、外部インターフェースと呼びます。)他システムから連携されるデータの中でもどのデータ項目を新システムに取り込むのかなど、データの1つ1つの項目を精査し、そのデータを新システム内でどのように処理をしていくのか整理します。場合によっては、連携先の他システムにおいて今回導入する新システム用にデータを新たに出力してもらう必要も出てくるかもしれません。そのため、連携先の他システムとの担当者との連携が必須です。アドオン開発を行う前フェーズでアドオン開発を行うことになった場合は、システム開発会社にてアドオン開発を行います。基本的には、前述の標準機能の設定や外部インターフェースの実装と、同じタイミングで並行して実施し、単体テストも行います。業務改善を行うパッケージを新システムとして導入する際、既存の業務をパッケージにあわせて調整しなければいけないことが大半です。場合によっては、業務のプロセスそのものを大きく変えることもあると思われます。そのため、新システムが稼働した直後から、新システムを利用した業務をこなしていけるように、システム開発会社側で開発作業などを行っている期間を利用して、発注者側で業務改善も進めていきます。前フェーズで作成した「BPR検討計画」をベースに、業務改革・改善の内容を検討し、業務の見直しを進めていきましょう。移行に向けた準備、結合/総合テストを実施する前述の、標準機能の設定、外部インターフェース実装、アドオン開発が完了すれば、移行の準備や結合総合テストを実施します。要件定義フェーズで作成した、「移行方針書」や「テスト全体方針書」をベースに進めていきます。発注者側においては、移行に必要なデータを準備する必要があります。現行システムから過去データを出力して新システムに取り込める形式に加工をする、手作業で作成していたデータで表記ゆれがある箇所を新システムに取り込める形式に修正をする、など移行対象範囲によっては非常に膨大な作業になることが予想されます。発注者側だけでは対応しきれない場合は、事前にシステム開発会社と分担できないか調整したうえで「移行方針書」に反映しておきましょう。発注者側は、システム開発会社側から結合・総合テストの結果について報告を受け、問題がなければ次のフェーズに移ります。移行準備が整い、結合総合テストが完了すれば、ついに新システムのリリースに向けて最終準備(受入テスト、移行)を行います。受入テストとは、発注者側が主体となって実施するテストであり、要件定義フェーズで定義した要件が新システムに反映されているか、新システムを利用して業務が問題なく行えるかを確認するテストです。受入テストにおいては、システム開発会社は何か不具合があった場合のみ対応するだけで、基本的には発注者側が主体的に実施するテストとなります。受入テストや移行については、次の記事で解説していますので、ぜひご覧ください。新システム稼働直前の受入テストや移行時に発注者側が実施することこの記事で理解できること本記事では、新システムの導入や既存システムの刷新に向けて、システム開発会社側で実施するテストが終了し、発注者側が行う受入テストや、本番リリース前に実施すべきデータ/業務移行やシステム切り替えの中で発注者側が実施すべきことや意識すべきポイントを解説いたします。システム開発会社に発注した後、発注者側はシステム開発会社側任せにしてよいわけではありません。現状調査・分析この記事の編集者GPTech編集者IT調達ナビの運営会社である、(株)グローバル・パートナーズ・テクノロジーに新卒入社。ITコンサルティング業務に従事しつつ、IT調達ナビでシステム発注に役立つ記事を展開するというメディア運営業務にも携わる。01IT戦略支援サービスITグランドデザインの策定やITプロダクト事業の計画策定を支援するサービスです。「受託開発モデル中心の事業から脱却したい」「自社のIT技術を活かした、ITプロダクト事業やクラウドサービス等の事業を立ち上げたい」と考える企業さまを支援します。02ITガバナンス構築・運営支援サービスITグランドデザインの実現に向けて、個別の情報システムの企画・整備・運用の指針やプロセスを整備し、モニタリングする体制を構築するサービスです。ITガバナンス業務の運営も支援します。03IT調達支援サービス個別のIT投資の成功に貢献するサービスです。ITを活用した業務改革やシステム導入の計画を策定し、システム会社選定から、開発工程のマネジメント、稼働後の中長期サポートまでのシステムライフサイクル全体のマネジメントを、企業さまと協働で実施します。