お役立ち記事

開発会社（ベンダー）選びの重要性

システム開発やIT製品の提供を行う企業のことをベンダーと呼びます。
世の中には、実績豊富な大手企業から社員数人の小さなベンダー、特定の分野・領域に特化した開発会社まで、さまざまなベンダーがあります。

プロジェクトを成功させるには、数多くのベンダーの中から自社に合った最適な1社を選び出す必要があります。

システムとは？システム導入の背景・目的・効果の考え方でも述べましたが、システム開発には、長い期間と高額な費用がかかります。一度ベンダーを選定して開発が進み出したら、そのベンダーとは一定期間、あるいは納品後の運用フェーズまでずっとお付き合いをすることになるのです。

プロジェクトを成功に導くために、最適なベンダーを選ぶことは非常に重要です。

ベンダー選定のプロセスとポイント

ベンダー選定のプロセスと重要なポイントを解説していきます。

正しいプロセスを踏んで、最適なベンダーを選定しましょう。

1. ベンダーの候補をピックアップする

まず、自社のプロジェクトを実現できそうなベンダーを数社ピックアップします。

コーポレートサイトで事業内容や会社概要、実績などを確認しながらピックアップしていきましょう。信頼性を考えると大手の企業ばかりに目が行ってしまいがちですが、大手はどうしても費用が高くなります。そこで、大手のほか、中小企業やスタートアップなども候補に入れてみることをおすすめします。

少なくともトータルで5〜8社程度はリストアップしたいところです。

2. ベンダー選定の基準を、あらかじめ設定しておく

RFPを発行すると、各ベンダーから提案を受けることになります。その提案内容を比較検討するための選定基準を、あらかじめ設定しておきましょう。

以下の評価項目をベースとして、自社独自の選定ポイントがあれば追加し、表などにまとめておきます。

• 提案内容に、自社の要求がすべて盛り込まれているか。
• 提案内容に、自社の要求がすべて盛り込まれているか。
• 納期は自社の要望に合っているか。
• 十分な開発実績があるか。また、開発を担当した範囲や請け方（直請けなのか、孫請けなのかなど）も踏まえて実績を見る。
• ベンダーの経営状態は健全か。また、開発体制に不安はないか。
• 担当者のコミュニケーションや自社との相性はどうか。

この中でも「実績」は非常に重要な要素です。実績があるということは、その分野においてノウハウがあることを意味します。

では「実績」を、どのように見たらいいでしょうか。そのポイントを2つお伝えします。

こうした事態を避け、時間のロスなくスムーズにプロジェクトを進めるためにも、RFPは正しい順序で作成しましょう。

過去に似たようなシステムを開発したことがあるか

顧客管理システム、自社商品の販売サイト、店舗の予約システム、求人サイト……、「開発」と一言で言っても、その内容は千差万別です。

実績を見る際のポイントの一つとなるのが、自社に近いシステムの開発実績があるかどうかです。過去に似たようなものを構築した実績があれば、その分野・領域についてノウハウがあるということです。他社の事例も豊富に持っていることでしょう。そうしたベンダーであれば、何か相談したときに的確なアドバイスをもらうことができるはずです。

また、分野だけでなく、システム利用者の規模についても確認しておくことをおすすめします。自社では利用者「1万人」を想定しているのに、実績が「300人」規模のシステムだった場合、知見が十分ではない可能性があります。

システムのどの部分を担当したかを把握する

実績として提示された案件の、どの範囲を担当したかを確認することも大事です。 クライアントから直接依頼を受けたのか、一次受け（直受けの下請け）だったのか、そのまた下の孫請けとして案件の一部分に携わったのか。どの立場で、どの範囲を担当したのかを確認すると、ベンダーが持つ技術力やスキルの解像度が高まります。

3. ベンダー候補から提案を受ける

ベンダー候補各社から提案を受けます。

ベンダーからプレゼンテーションをしてもらうことになりますが、この場を密度の濃いものとするために、提案資料は事前に送ってもらうようにしましょう。

プレゼンの場で初めて提案内容を知るということになると、内容を理解することに時間がとられてしまいます。事前に資料を読み込んでおけば、プレゼンの場で発注側企業から能動的な質問ができるなど、時間を有効に使うことが可能になります。

また、事前に提案資料と自社の評価項目を照らし合わせ、ある程度の評価を進めておくこともできます。

4. 評価と選定を行う

各社からの提案をすべて受け終わったら、選定基準に基づき、1社を選んでいきます。選定のプロセスは文書にして残しておくといいでしょう。

5. 契約を締結する

ベンダーが決まったら、契約を締結します。発注側企業とベンダーは、契約書に明記されている内容にしたがって取引きを行います。両者の間で認識や意見の食い違いがあったときには、この契約書に記載されていることが「正」となります。

ベンダー選定のプロセスとポイント

ベンダーとシステム開発の契約をするとき、どのような契約形態にすればいいのでしょうか。

システム開発の契約においてよくある契約形態の種類と、その違いについて解説します。

「請負契約」と「準委任契約」

システム開発の契約には、大きく分けると「請負契約」と「準委任契約」があります。

「請負契約」とは、ベンダーが発注者に対して成果物を納め、発注側企業がそれに対してベンダーに報酬を支払うという契約です。

一方の「準委任契約」は、ベンダーが発注側企業の指揮監督のもと、特定の業務を行う（役務を提供する）という契約です。その業務を遂行すること自体が目的となり、成果物の完成については責任を求められません。

一般的に、システム開発の上流で行われる要件定義は「準委任契約」、その後の設計・開発は、「一括請負契約」にすることが多いです。

流動的なプロジェクトには「多段階契約」もあり

全ての工程を一括で1つの契約にするのが「一括請負契約」ですが、これ以外に、開発の工程ごとに契約を分ける「多段階契約」という契約形態もあります。

「多段階契約」は、流動的なプロジェクトや大規模なスクラッチ開発の場合に用いられることが多いです。そうしたプロジェクトは、要件定義や設計を進めていくうちに必ず新たな要件などが追加され、仕様が膨らんでいくものだからです。契約を区切ることで、発注側企業にとってはベンダーの切替えや中途解約の選択肢を持つことができるというメリットがあります。

一方で、デメリットもあります。多段階契約はそれぞれの工程で金額とスケジュールを確定させていくことになるため、最後の契約までプロジェクト全体の金額とスケジュールを把握することができません。

そうしたメリット、デメリットを考慮の上、「一括請負契約」にするか「多段階契約」にするかを選びましょう。

以上のように、契約形態にはいくつかの種類があります。ベンダーとのトラブルを未然に防ぎプロジェクトを成功に導くために、両者話し合いの上で適切な契約を結びましょう。

「契約不適合責任」は1年間に設定する

契約書に盛り込む重要な項目の一つに「契約不適合責任期間」があります。

「契約不適合責任期間」とは、「不具合があった場合に無料で修正対応してもらえる期間」のことです。（※旧民法の「瑕疵担保責任期間」のこと。2020年4月1日の改正によって「契約不適合責任期間」に変更）

契約書のドラフトをベンダーが作成した場合、この「契約不適合責任期間」は6カ月と記載されてくることがあると思います。

民法では「契約不適合を知ったとき」から1年と定められていますので、契約書にもそのように記載するといいでしょう。

以上、契約の種類や注意点を一部ピックアップして解説しました。実際に契約書を作成する際には、ここで記載した以外にも、もっと多くの押さえるべきポイントがありますのでご注意ください。

開発の失敗例と落とし穴　〜発注側企業は“お客様”ではない〜

ベンダーも決まり、契約も交わしました。これで事前の準備は万端……？　いいえ、開発フェーズに入る前にもう一点だけ、発注側企業の担当者が知っておくべきことがあります。

これを知らないがために、実に多くのプロジェクトが失敗の憂き目にあっているのです。

どんな失敗なのか、よくある例をご紹介しましょう。

---

開発の失敗事例　〜スタートアップA社の場合〜

スタートアップA社では、ある業界の予約サイトを作り、事業展開することになりました。そのビジネスアイデアに熱い思いを持っていた社長が自らプロジェクトの発注担当者として動き、ベンダーに開発を依頼。

最初に大まかなコンセプトを伝え、そのあとはベンダーにほぼ全てを任せることにしました。

開発が進む中、ベンダーからいろいろな提案や相談が来るようになります。しかし、社長に細かいことはわかりません。本業も忙しい。「良きにはからえ」とばかり、受け身の対応を続けました。

その結果……、

出来上がった予約サイトは、社長が想定していたものとは違うプロダクトになっていました。機能面でも足りないものがあるし、使い勝手が悪いのです。

社長がベンダーにそれを伝えたところ、ベンダーの回答は「うちは言われた通り作っています」。要件定義書や仕様書を確認すると、確かにそのとおり作られていることがわかりました。

費用は1500万円、かけた期間は1年間。A社はその後、2000万円をかけてサイトを作り直すことになりました。

---

ユーザーの協力義務とは

請負契約のシステム開発では、発注側企業がベンダーに対して積極的に開発に協力することが求められています。これを「ユーザーの協力義務」といいます。

システムとは、良いベンダーがいればそれだけで完成するものではありません。要件定義をレビューしたり、問題やリスクが発覚したときにはベンダーと一緒に解決したりなど、発注側企業に課せられる役割は実に多くあります。

ここで必要となるのは、プロジェクトを完遂させるために「主体的な姿勢を持つ」ということ。発注側企業は決して“お客様”ではありません。ベンダーと共に一つのプロジェクトを進める「チームメンバー」なのです。

発注側企業が協力義務を果たさずにプロジェクトが失敗し、ベンダーから損害賠償を請求されたという事例もあります。最悪はそのようなトラブルに発展する可能性もあるということを念頭に置いて、開発フェーズに入りましょう。

ベンダーとはしっかりと連携しながら、プロジェクトを進めていきましょう！

今回のまとめ

今回はベンダーの選び方とポイント、契約の種類などについて解説しました。

どれも大事なことばかりですが、最後にお伝えした「ユーザーの協力義務」は、このあとの開発フェーズからずっと必要となる考え方であり、姿勢です。これを常に忘れずに、ベンダーとお付き合いしていきながら、プロジェクトの成功を目指しましょう。

次回は「要件定義の作り方」について解説します。