システム開発の仕事を開発ベンダーに発注する場合の、手順や気を付けるべきポイントをまとめます。
発注までの流れ
システム開発の発注は、以下の順番で進めていきます。
１．業務の整理（業務分析）
今の業務内容を整理して、システムを作ることで何を実現したいのか、現行業務(AsIsモデル)と、理想の業務の姿（ToBeモデル）のギャップを資料にまとめます。
２．要件の整理
１．で作成した業務分析の資料に加え、システム障害でサービスが止まってよい時間、対象業務のデータ量、いつまでにシステムを作る必要があるかを整理します。
システム障害でサービスが止まってよい時間は、最終的に、SLA(Service Level Agreement)契約を締結し、開発ベンダーに保証してもらいます。SLAは、一例として、お客様に影響が出る決済系サービスなら1分以内、社内業務なら2日以内に必ず復旧させる、また、その基準未達が1年に3回以上発生してはならない、といった内容になります。
SLAの条件が厳しいほどシステムの構築費用は高くなります。システムを止めないようにするには、ハードウェアの各パーツを2つ以上配置した冗長構成にするのが基本的なアプローチになります。また、DR環境(災害対策環境)を考慮する必要もあり、そういった機能を追加で開発する分、費用が増大します。
データ量については、最近は大容量の記憶装置が安価で入手可能なので、大量データを短時間で処理するという要件がないのなら、費用的にはあまり差がでないはずです。
３．開発ベンダーへの説明
上記の業務分析・要件整理結果を提案依頼書（RFP：Request for proposal）という形で、資料に反映します。RFPには他にも色々と盛り込むこともできますが、最低限、上記の情報があれば問題ありません。必要があれば、開発ベンダーから別途、質問が来ると思います。むこうは開発のプロですので、ちゃんとした開発ベンダーであれば、こちらの出す情報が少なくても、開発全般をリードしてもらえるはずです。
また、Tobeモデルの要件とSLAなどの条件を提示すれば、開発ベンダーは概算見積もりできますので、こちらが用意できる資金の上限を話す必要はありません。むしろ、話してしまった場合、開発ベンダーがそれを意識した価格設定をしてくる可能性があるので、話さない方がよいと思います。
RFPができたら開発ベンダーに提示しますが、契約金額が大きくなりそうな場合は、複数の開発ベンダーに相見積もりを依頼するのが普通です。依頼する数が多いと後で審査も大変ですので、3社くらいがよいと思います。
４．提案書の確認、受注
RFPを元に開発ベンダーは提案書を作成します。その際、RFPで記載不十分だった内容について、開発ベンダーからいくつか質問が来ると思いますので、速やかに回答できるように準備しましょう。
開発ベンダーの提案書について、開発範囲・SLA(非機能要件)・システムの利用開始時期（リリース時期）・契約金額に納得できたなら、契約を締結します。
この提案書提示の段階では、細かいシステム仕様について認識があっておらず、詳細な開発規模はわからない、つまり開発にかかる総費用は確定できません。従って、契約形態・契約金額については、細かいシステム仕様を確認するまでの間、つまり、要件定義終了頃までは準委任契約、基本設計以降は一括請負契約を締結することが多いです。
５．ユーザー体制の構築、ユーザー側スケジュールの作成
契約が締結出来たら、あとは全て開発ベンダーにお任せ、というスタンスでは、システム開発は失敗します。システム開発は開発ベンダーとユーザーの共同作業ですので、ユーザーも相当な時間を費やすことを覚悟して下さい。
まず、構築するシステムのTobeモデルの詳細を理解しているユーザーに参画してもらい、ユーザー体制を構築します。システムの開発規模が大きいほどユーザー負担も大きくなるので、通常業務とシステム開発にそれぞれどれくらいの時間を費やすのか、ユーザーの上司も巻き込んで、計画段階で調整しておきましょう。
また、開発ベンダーが作成した開発スケジュールを元に、ユーザー側のスケジュールを作成しましょう。設計段階では要件詳細の説明、テスト段階ではUAT（最終確認のユーザー受入テスト）、移行段階では、事務手続きの変更や業務マニュアルの作成、移行データの作成などが、主なユーザー側の作業になります。
相見積もりを行なう場合の比較ポイント
RFP提示段階で、複数の開発ベンダーに相見積もりを依頼する場合、平等に扱うこと、評価基準を設けることが大事です。
1つ目の平等に扱うとは、依頼している全ての開発ベンダーに同じ情報を提供するということです。例えば、ある開発ベンダーだけからユーザー要件の追加質問を受けて回答したとします。その開発ベンダーは、それを元に、より正確な見積もり金額を出そうとするので、その情報をもらっていない他の開発ベンダーと見積もり精度が変わってしまい、金額面で正しい評価ができなくなってしまいます。追加の質問に回答することは必要ですが、その情報は全ての依頼先の開発ベンダーに公開して下さい。
2つ目の評価基準ですが、選定基準は複数の要素の総合評価で決まります。例えば、金額、開発体制、会社実績などの要素です。各要素に評価のウェイトを付けて、最も総合評価の高い開発ベンダーに決めていきます。注意点として、多くの場合、最も重要な要素は金額なのですが、必ずしも金額が低いからよい、というわけではありません。つまり、要件やSLAへの理解度が浅いことが理由で低い金額になっている可能性があります。金額を評価する際は、要件やSLAをどの程度理解しているのかチェックすることも合わせて行ってください。（要件やSLAに関する質問をいくつかすれば、その回答内容から理解度は判断できると思います。）
準委任契約と一括請負契約
準委任契約とは、成果物責任を負わず、かかった作業時間の分だけ費用請求する契約です。一方、一括請負契約とは、作業範囲をしっかり決め、その範囲内で成果物責任を負う契約です。
ユーザー企業側からすると、社内決裁を取る上で、開発範囲と金額、その費用対効果が明確になっている方が望ましいので、最初から一括請負契約で進めたいところです。しかし、RFPの段階では、開発範囲がはっきりしておらず、無理に開発ベンダーに依頼すれば、開発ベンダー側からすればバッファを上乗せした多めの金額を提示するしかありません。それはユーザー企業側も本意でないはずですので、開発範囲がしっかり決まったら一括請負契約、それまでの間は準委任契約を締結する方法が無難なやり方となります。
また、保守フェーズなどで、最初から開発範囲が明確なケースであれば、最初から一括請負契約1本を締結するやり方で何ら問題はありません。
まとめ
システム開発でよく発生するトラブルは「思っていたものを作ってもらえなかった」というものです。しかしながら、開発ベンダーとユーザーはコミュニケーションを取りながら一緒に開発を進めているわけですから、一方的に開発ベンダーが悪いケースは稀です。ユーザー側のコミュニケーションの取り方や開発への関わり方に問題があるケースも非常に多いです。
同じ目標に向けて、開発ベンダーと協力し合いながら、システム開発を成功させて欲しいと思います。
