システム開発会社の提案を正しく評価するためのポイントを紹介
システム導入において、システム開発会社の選定は１つのターニングポイントとなります。
本記事では、新システム導入や既存システム刷新の担当者になった方へ、自社にあったパッケージのシステムを選定するためのポイントを紹介いたします。
特に新システム導入の際は比較するものが少ないため、どのような評価項目を設定すべきか
また、既存システム刷新の場合にも、各システムのメリット・デメリットを定量的に評価するにはどのようにすべきか
悩まれる方がいらっしゃるかと思います。
選定時の根拠がはっきりしていると、システム導入で目指す“あるべき姿”に迷うことなく、社内展開時にも説明がしやすくなります。是非、本記事を参考に役立てていただければと思います。
目次
1. システム導入の目的に沿って評価する
まず、「導入の目的」は、常に振り返り、意識する必要があります。
システム選定時は複数社について様々な要素について調査し、まとめ、評価を行います。
特にシステムに対する要望を１つ１つ機能に落とし込んだもの（機能要件）に対しての評価などは、細分化された要望が満たされているかに目が行きがちで、本来の導入目的から逸れてしまうことがあります。
細かい要望を満たすかも重要ですが、システム導入の目的に沿っているか、俯瞰で見直してみることも大切です。
2. 評価の構成要素
各システム開発会社からの提案を評価するためにはどのような情報が必要でしょうか。
まず評価をするための情報源となる評価材料が必要です。
そして、何を評価するのかという「評価項目」と、どのようなことが可能ならば要求を満たすのかという「採点基準」を定めることで定量的に評価ができます。
また、「評価項目」については、何を評価するのかの観点（評価観点）を検討することが必要になります。
次章から順に各項目で必要となる要素や検討において注意すべき点を説明します。
2-1. ２つの評価材料
評価材料は、主に以下の２つです。
（1）提案書
システム導入にあたり発注先を選定するために、候補となるシステム開発会社に具体的な提案を依頼するための文書としてRFP（提案依頼書）を作成します。
RFPには、システムの導入目的や概要、要件や制約条件など、自社が知りたい情報、システム導入によって実現したい要求を記載しています。
このRFPについての回答を、システム開発会社は「提案書」として作成し、発注者側に導入提案を行います。
つまり、評価を行うために知りたい情報をRFPに記載し、「提案書」として回答してもらうことで評価材料を集めます。
RFPについては、以下の記事で詳しく説明しておりますのでご覧ください。
（2）プレゼン
提案書の内容で候補会社が絞り切れない場合、システム開発会社に「（１）提案書」を用いてプレゼンを実施してもらいます。
プレゼンでは、提案書の内容はもちろんですが、提案書からは評価ができないプロジェクトメンバーのコミュニケーション能力や、会議進捗の方法、要望への対応の姿勢などから自社との相性を確認することができます。
また、提案書で記載できていなかった点や他社と比較して情報収集しきれていない点などを確認する場としても利用できます。
2-2. ４つの評価観点
評価観点は大きく４つの分類が挙げられます。
各評価観点の内容と、その評価項目、採点基準について説明します。
評価観点 ①技術
発注者側の要求をどの程度実現できるかを確認するための観点で、機能要求・非機能要求に分けて、実現可否を中心に実現方式も含めて評価します。
（1）機能要求
機能要求とは、業務に直接的に関係する機能（例：発注機能や請求書発行機能）です。
これはRFP（提案依頼書）の中に含まれる「機能要件一覧」として、プロジェクトの目的を達成するために必要となる機能要求を一覧化したものをシステム開発会社に送付し、「提案書」としてシステム開発会社から返ってきた回答を用いて評価を行います。
そのため、評価項目は機能要件一覧の各項目と一致することになり、
採点基準は各機能が、実装済みか／開発が必要か／実装不可能か になります。
（2）非機能要求
非機能要求とは、機能要件以外のユーザビリティやセキュリティなどの要望（例：システムの稼働時間、画面遷移にかかる秒数、災害時の復旧時間）です。
機能要求と同様に、RFPの中に含まれる「非機能要件一覧」の各項目が評価項目となります。
採点基準については、自社のセキュリティ規定等により譲歩できない評価項目と検討の余地がある評価項目とで大きく異なります。
譲歩できない項目については、稼働までに実装されていることが絶対条件になり、実装不可の場合は足切り条件となります。
検討の余地がある項目については、自社の業務担当者や情報システム担当者を交えてシステム開発会社と検討し、
ユーザビリティやセキュリティが著しく損なわれないのであれば、当初の要求通りでなくても減点をしないという採点基準とする場合もあります。
注意する点としては、パッケージ製品の非機能については、多くのユーザーへ同じ機能を利用してもらう形式をとっていることが多く、自社の要求に応じてカスタマイズすることができない場合があります。候補会社が全て足切り条件に該当してしまう場合は、非機能要求自体を再考することも選択肢となります。
評価観点 ②進め方
契約後のシステム導入における、プロジェクトの進め方を評価します。
評価要素としては下記があります。
これらの情報も基本的には提案書に記載されることが多いですが、実際に候補会社の担当者とやりとりをする中で、コミュニケーション能力や、会議進捗方法など自社との相性を確認することも重要です。
上記の「②進め方」の評価項目は変更の余地があるため、提示された方法が自社と合わない、不足しているから減点するのではなく、自社の要望を伝えシステム開発会社と擦り合わせを行うべきです。
ただし、自社に合った手法で実行する方が慣れている分進めやすくなることはありますが、世間一般的な管理方法（システム開発会社の提案方法）を学ぶこともできる機会なので、双方がスムーズに進められる方法をとることが重要です。
評価観点 ③発注者側の実務業務
システム導入に関する作業内容が明示されていて、実行可能かを評価します。
実行可能かどうかは下記の３点から判断します。
（1）作業内容詳細
稼働前/稼働後について、実施作業が記載されていて、その内容が理解できるか。
システム選定後の作業は、現場の担当者など新たに参画してもらうことが多いため、資料を読んで新メンバーが理解できるようなレベルで再度作成してもらうようにシステム開発会社に依頼する。
（2）作業工数
（1）について、自社で必要となる工数が記載されているか。
工数の内訳もなるべく明示されているほうが良い。
（例えば、資料作成という作業でも、内訳/作成/確認/修正/再確認と段階を踏んで作業を実施する。その全ての工数を計算しているか内訳が記載されていれば確認ができる。）
（3）作業主体
（1）について、誰が主体で実施するのか、サポートはどの程度受けられるか。
特に自社が主体となっている作業については、重点的に確認し、必要に応じてサポート範囲を増やす、作業期間を調整する等の交渉を行った方が良い。
評価観点 ④費用
費用は、予算／他社費用との比較で評価します。
評価項目としては純粋に金額が予算内かどうか、候補となる製品の金額を比較して大きな違いがないかを確認します。
費用内訳の例は下記の通りです。
「①技術」、「②進め方」、「③発注者側の実務業務」への要求を実現させようとすればするほど、費用が膨らんでいきます。
少し費用を積むことで業務効率が図れる機能を開発してもらう、自社の工数と稼働時期からシステム開発会社側に作業委託をするといった様々な調整が、費用に跳ね返ってきます。
金額は１番わかりやすく順位が付き、特に経営層は目が行きがちです。
しかし、上記のように他の評価観点と関連しあっているため、報告時には金額の内訳を明示し、費用がどうしてその金額になったのか、根拠と合わせて評価することが重要です。
3. 評価項目と採点基準の作成タイミング
システム導入を進める際は、まずは現状分析を行います。その後、下記の「要求仕様策定・システム開発会社選定フェーズ」を実施します。
全体の流れについては、以下の記事で詳しく紹介しておりますのでご覧ください。
ここで重要なのは、評価材料を収集する前に評価項目と採点基準を作成しておくことです。
事前に作成するメリットは以下の2点です。
（1）「RFP」と「プレゼン」の目的の明確化
上記でも説明しましたが。RFPとは評価材料となる「提案書」を受領するために、候補となるシステム開発会社に具体的な提案を依頼するための文書で、つまり、評価材料を集めるための依頼書です。
また、プレゼンは提案書だけでは確認ができないコミュニケーション能力や、他者と比較して収集できていない情報を穴埋めできる場として利用できます
どちらも“どのような情報を得たいのか“に基づいて作成が必要であり、”どのような情報＝評価するための情報”であるため、事前に評価項目と採点基準を定めておくことが重要です。
例えば、「提案書」の一部として「①技術」を知るための機能要件/非機能要件一覧がありますが、一覧化された内容がそのまま評価項目になり、システム開発会社へ送付する際に採点基準（標準機能として実装されていればA、開発が必要であればBなど）も合わせて記載しておけば、システム開発会社の回答が評価しやすい形で返ってくるので、確認がしやすくなります。
また採点基準を作成する段階で、機能の優先度やどの程度の機能を要求しているのか１つ１つ定義されていくので、システム開発会社との要求に対する共通認識が図りやすくなります。
「プレゼン」においても同様に、提案書の説明をシステム開発会社に実施してもらう際に、どこに重点を置いて説明してもらうのか、アジェンダやスピーカー等を指定することで、確認したい内容にずれが起きず、評価がしやすくなります。
（2）採点者の共通認識の形成
採点基準を決めておくことで、提案書の確認やプレゼンの評価時に採点者が評価項目に対しどのように感じたのか共通認識を持つことができ、適切な採点を実施できます。
また、採点基準を事前に検討することで提案書やプレゼン終了後、実際に評価する段階において特定製品に偏った採点になることを防ぐことができます。
4. システムを評価、選定できたら
上記の観点を意識して評価を行う、自社に合うシステムが選定出来たら、具体的なシステムの利用方法の検討を行う「要件定義フェーズ」に移ります。
要件定義フェーズについては、以下の記事で解説しています。ぜひ続けてお読みください。
この記事の編集者
坪井 夏花
IT調達ナビの運営会社である、（株）グローバル・パートナーズ・テクノロジーに新卒入社。 同社のシステム発注側に立って支援するITコンサルティング業務で得られた経験から、システム発注に関わる人々の役に立つ記事を執筆する。
