システム開発の発注先を選ぶためにやるべきこととは
目次
この記事で理解できること
本記事では、新システムの導入や既存システムの刷新を担当することになった方へ向けて、具体的に新システムへの要求内容を検討し、発注先のシステム開発会社を選ぶまでに、実施すべきことや意識すべきポイントを解説いたします。
新システムへの要求を検討すると言っても、どのような観点で何を決めればよいのか分からない、自社のことをよく理解してくれるシステム開発会社に発注したいが、どのように選べばよいのか分からないという悩みを抱えている方が多いと思います。
システム開発会社はシステム開発のプロではありますが、システム化する業務や課題を一番理解しているのは自社です。そのため、システム開発会社に任せきりにせずに、まずは発注者側である自社で新システムへの要求内容を検討し言語化することは、システム導入の成功に繋がるはずです。
どのように新システムへの要求内容を検討すればよいのか、どのようにシステム開発会社を選べばよいのか、説明します。
システム発注プロセスの中での位置づけ
本記事では、システム発注プロセス（下記画像参照）の内、「要求仕様策定・システム開発会社選定フェーズ」を解説します。
前フェーズで策定したプロジェクト導入/刷新計画に基づき、機能要求（システムにどのような機能を求めるか）の検討やRFPを実施します。
要求仕様策定・システム開発会社選定フェーズ全体の流れ
「機能要求策定・システム開発会社選定フェーズ」の全体の流れを下図に示します。
各実施内容において、どのようなことを検討・協議するのか、どのような資料を作成するのか、詳しく解説していきます。
システム導入/刷新計画の認識合わせ
プロジェクトに参画するメンバーでキックオフ会議を実施し、前フェーズで作成し承認されたシステム導入/刷新計画報告書をもとに、今後のプロジェクト計画の認識合わせを行います。
システム導入/刷新計画報告書を作成するまでの解説は、「システム導入/刷新計画策定フェーズ」の記事をご参照ください。
システム導入/刷新の目的や各プロジェクトメンバー自身が与えられた役割を理解しないまま要求仕様策定を進めてしまうと、検討の方針がぶれてしまい、スケジュールの遅延や手戻りのリスクが増大します。そのような事態を防ぐためにも、経営層～現場（業務部門）のプロジェクトメンバー全員で方針の認識を合わせることが大切です。
要求仕様の策定
次に、新システムの要求仕様（機能要求仕様・非機能要求仕様）を策定します。
ここでご注意いただきたいのは、本作業はユーザー個人の要望を闇雲に反映させる作業ではないということです。システム導入/刷新の目的を踏まえたうえで、新システムに求められる機能は何かを検討する作業であるということを念頭においてください。
機能要求仕様の策定
「機能要求概要」の検討で作成した機能要求概要一覧について漏れがないか、業務担当のメンバーを中心に検討を重ね、補足情報（機能説明・開発優先順位など）を追記し、機能要求一覧として取りまとめます。
業務を実施するうえでシステムにどのような機能が必要かを策定する非常に重要な工程ですので、業務担当者は一つ一つの機能について丁寧に検討していきます。
機能要求概要検討についての説明は、下記記事を参照ください。
非機能要求仕様の策定
「非機能要求概要」での検討結果をもとに、非機能要求仕様を検討し、非機能要求一覧として取りまとめます。
非機能要求概要検討についての説明は、下記記事を参照ください。
非機能要求は、大きく以下の2つに分けられ、それぞれについて検討が必要です。
- システムに関する非機能要求
- プロジェクトの進め方に関する非機能要求
システムに関する非機能要求は、システムの規模や性能などが該当します。クラウド環境で構築すること、100名の業務担当が使えるシステムであること、○件の処理を○秒でできることなどです。
プロジェクトの進め方に関する非機能要求には、移行範囲や方法、教育などが該当します。例えば、過去○年分のデータをシステムに移行する、システムを利用する担当者へは操作説明会を実施するなどです。
上記の非機能要求の例は、デジタル・ガバメント推進標準ガイドラインに記載されている17項目に加え、「18 プロジェクト管理に関する事項」を追加したものです。
検討を進める材料として、政府・業界団体などが提供する非機能要求のフォーマット（非機能要求グレード、デジタル・ガバメント推進標準ガイドラインなど）がありますので、そちらを参照しながら策定すると、要求漏れを防ぐことができます。
RFPの実施
発注者側で機能要求仕様・非機能要求仕様を策定した後は、RFP発出し、候補会社に対して提案を依頼します。RFPにおけるポイントは、RFP文書を一方的に開発会社に送付して終わりではなく、RFPの中身をできれば打ち合わせを開催して説明します。
候補会社に対しては、RFP文書の内容を正しく理解しているかを含め、認識合わせのためのコンタクトを密にとることが重要です。具体的な作業と共に説明していきます。
RFPについて詳しく知りたい方はこちらをご覧ください。
RFPの作成・送付
RFP（提案依頼事項、提案様式、プロジェクト概要、業務委託要件）を作成し、候補会社から提出される提案の評価方法の検討を行い、プロジェクトメンバー内の承認を得ます。
その後、候補会社へRFPを送付します。RFPの添付資料としては、前フェーズで作成した機能要求一覧、非機能要求一覧も送付します。
開発会社からの質問対応
候補会社がRFP文書を確認する中で発生した質問事項についての回答を行います。
基本的には、（質問リストという形で）文書でやり取りしますが、詳細確認のための打ち合わせを設定する場合もあります。
要求仕様の実現可否の確認
RFPの添付資料として送付した機能要求・非機能要求一覧をベースに、各機能要求・非機能要求の実現可否を候補会社に回答していただきます。
このように、プロジェクトで検討している機能要求・非機能要求と、各候補製品の持つ機能要件・非機能要件を照らし合わせて実現可否を確認することを、「Fit＆Gap分析」といいます。ここでのFit＆Gapは、文書をベースに行い、機能要求・非機能要求の調整とシステム会社の評価・選定を目的に実施します。
詳細デモの確認
自社からRFPに示した要求仕様について、候補会社に要求仕様の実現可否の詳細を確認します。
具体的には以下の観点について詳細確認の打ち合わせを実施します。
- 候補会社が現状実現できないと回答した要求について、対応策を検討する
- 実現できると回答した要求について、具体的にどのように実現する想定なのか確認する
（※全要求について確認すると時間がかかってしまうため、特に重要と考える要求や、現行システムで課題に感じていた要求などをピックアップして確認します。）
特にパッケージの場合は、詳細デモとして、画面操作デモを開発会社に実施いただきながら打ち合わせをすることで、要求仕様の実現方式のイメージをつかむことが重要です。
要求仕様の修正・確定
詳細デモの結果を踏まえ、必要に応じて要求仕様を修正・確定します。
要求仕様に修正が発生した場合、再度機能要求仕様・非機能要求仕様一覧を候補会社へ送付し、実現可否を確認します。
システム開発会社選定
RFPを踏まえ候補会社から提案書を受領できれば、全候補会社の提案内容を確認します。候補会社が複数ある場合は、コンペを実施して最終候補を決定します。
提案書の確認
候補会社から受領した提案書の内容を確認します。不明点があれば候補会社へ確認し、必要に応じて提案書の再提出を依頼します。
提案内容・プレゼンの評価
提案書の内容で候補会社が絞り切れない場合、コンペを実施します。提案内容のプレゼンを受け、設定した提案評価方法に従って提案内容を評価し、最終候補を決定します。
評価の観点の例としては、大きく以下の分類が挙げられます。
① 技術：発注者側の要求をどの程度実現できるか
→機能要求・非機能要求の実現可否を中心に、実現方式も含めて評価します。
② 進め方：①を実現するための進め方を策定できているか
→①の提案を実現するためのスケジュールやプロジェクトメンバーの体制、プロジェクト管理の方法が適切であるかを評価します。
③ 発注者側の実施業務：（実装フェーズで）発注者側が実施すべき業務を明確にしているか
→後続の実装フェーズにおいて、発注者側の協力は不可欠です。各フェーズにおいて発注者側が実施すべきことを具現化できているかを評価します。
④ 費用：システム開発、運用/保守にかかる金額
→発注者側の予算内に収まっていることを前提に、システム開発、運用保守にかかる金額を評価します。
どの評価項目に重きを置くかは、プロジェクトによって様々ですが、ここでもシステム導入/刷新の目的をベースに検討することが重要です。
提案内容の調整・確定
最終候補ベンダとの提案内容の調整を実施した上で、発注先となる開発ベンダを決定します。提案内容について調整が付かなければ、次点で評価の高い候補ベンダを最終候補とし、調整を進めます。
契約
契約書を作成し、発注先となるシステム開発会社との調整を経たうえで契約を締結します。
契約単位としては、まず要件定義フェーズを一区切りとして、準委任契約を締結するケースが多くあります。現在より詳細な要件定義を経た上で、最終的にシステム導入にかかる見積もりを算出してもらうことができるため、費用にブレがないように進めていくことができます。
契約後は
契約を交わした後は、開発会社の提案内容に基づきプロジェクト実施計画（スケジュール、体制）やプロジェクト管理要領（定例会の実施要領,WBSやタスク管理表の運用方法など）を具体化します。具体化した計画にのっとり、発注側と開発側が一体となって要件定義を開始します。
要件定義フェーズで実施する内容や意識したいポイントについて、以下の記事で解説しています。ぜひ、続けてお読みください。
この記事の編集者
GPTech編集者
IT調達ナビの運営会社である、（株）グローバル・パートナーズ・テクノロジーに新卒入社。 ITコンサルティング業務に従事しつつ、IT調達ナビでシステム発注に役立つ記事を展開するというメディア運営業務にも携わる。
