システム開発の見積書 ｜ 比較・評価ポイントを押さえて失敗しない業者選び

一番安い会社に頼んだら、安物買いの銭失いに！

美容院をチェーン展開する「アーク社」は、顧客管理のWebシステムをリニューアルすることになった。担当の羽山さんは、3社のシステム開発会社に提案を依頼。アーク社の経営トップはコスト増に対して非常に厳しいため、羽山さんは決裁が得やすい一番安い会社でよいだろうと判断。出揃った見積もりのなかで、最も低価格だったA社に発注を決めた。

しかし、いざ開発が進むと、さまざまなトラブルが発生。リニューアルの目玉の1つであるWeb予約システムが、同時刻に重複して予約を受付ける美容院の業態に合っていない仕様だったり、新システム移行のために必要となる既存の顧客データの修正作業が見積もりに入っていないことが判明したのだ。結局、大幅な修正作業や追加作業の発生で、予定外のコストが発生したうえ、スケジュールにも遅れが出てしまった……。

※社名や登場人物は架空のものです。

Webシステム開発全体の流れ
第5回は「見積・見積書の比較、発注先の決定」を解説

オリエンテーションでシステム開発会社と提案内容を詰めたら、いよいよ具体的な提案・見積もりへと移っていく。しかし、システム開発会社から出揃った提案と見積もりをどのように評価し、最適な開発会社を選定すればいいのか、その判断は経験がなければ難しい。

見積もりの比較ポイントがわからないがために、価格優先で選定されるケースは往々にあるものだ。最終回では、経験の少ない、中小企業の発注担当者が見積もりの内容を評価し、発注先を判断するためのポイントを解説する。

価格だけで開発会社を選ぶと、ほぼ間違いなく失敗する

システム開発会社から出揃った提案と見積もりを並べて比較すると、どうしても価格が高いか安いかに目が向きがちだ。もちろん、昨今の経済情勢から、どこの企業もコストにはシビアになっているし、当然、相場からかけ離れた割高な費用を支払うことは避けなければならない。

しかし、システム開発の発注の場合、単純に見積価格だけで判断すると、その開発プロジェクトは失敗に終わる可能性が高い。なぜなら、見積価格だけでは、その会社が自社にとって最適なパートナーとなりえるかどうか判断ができないからだ。

では、システム開発会社の提案と見積もりをどう評価すればよいのだろうか。次の表は、著者が作成したシステム開発会社の発注先選定用の評価シートだ。こちらをベースに、どのような視点でチェックするべきか解説する。

発注先選定用評価シート（エクセルシートをダウンロードする）

機能（提案内容の評価）：示した課題に応えた提案になっているか

• 要件の網羅性

  まず、提案内容が発注企業の課題や要件に対してどこまで網羅されているか、発注企業の課題を開発会社が正確に理解し、包括的に対応できている提案になっているのかチェックする。もし、網羅されていない要件があれば、その理由や代替案などがセットになっている必要がある。

• 要件の実現性

  次に重要なのは、それぞれ網羅された要件が、具体的かつ詳細にどこまでイメージされているかだ。いくら要件を網羅していても、実現性がないものであったら、「絵に描いた餅」になってしまう。

  たとえば、提案の細部や例外的な処理をどの程度想定しているのか、開発会社に質問をしてみるのもいいだろう。詳細に練られているのであれば、明確な回答が返ってくるし、さまざまな処理を想定して、発注企業が考えていなかった機能の提案が加えられていたりするものだ。

• 要件の拡張性

  さらに、将来必要となる要件を想定して、機能や性能がどの程度拡張可能になっているのかチェックする。単に発注企業に要求された要件に対応するのではなく、開発会社の知見を生かし、発注企業の将来を見据えたプラスアルファの提案があるかが、積極性を見るためにも重要なポイントである。

価格の評価：根拠のある価格算定になっているか

• 価格の妥当性

  価格は初期開発費の高い安いに一番目が向いてしまいがちであるが、最も重要なのは、開発費の内訳がどのようになっていて、それらが明確な根拠に基づき積算されているかどうかである。

  見積もりに出てくる項目が一式となっていたり、聞きなれない言葉ばかりだったりした場合に、よく知らないからとあまり追求しない人もいるが、遠慮する必要はまったくない。システム開発のコストに対する疑問は、この段階で徹底的につぶすべきである。

また、一度作ったシステムはだいたい3年程度は使うものだ。開発会社間で価格を比較するにあたっては、初期開発費と3年分の保守運用費を合計して、総投資額がどの程度になるか計算するのもよいだろう。

納期の評価：実現性のあるスケジュールになっているか

• 納期の妥当性

  納期（スケジュール）は単に「机上の空論」ではなく、実現可能なものになっているかがポイントだ。企画、設計、開発、テストと、各フェーズで明確な期間が設けられているのはもちろん、万が一のスケジュール遅延に備え、どの程度バッファを持たせたものになっているかも見る必要がある。

• 体制の具体性

  そして、スケジュール通りに進捗させるために、開発体制が具体的に提示されているかも重要になってくる。よい人材は確保されているか、人的リソースが十分に確保されているか、メンバーの実績が豊富にあるか、それぞれのフェーズごとの役割分担がどうなっているのかを細かくチェックする。

また、中小零細のシステム開発会社だと、同時期に他の案件が立て込むと、人的リソースがひっ迫して、自社の案件が手薄になる可能性もある。他の案件の受注状況などをそれとなく確認するのもよいだろう。

能力の評価：本当に提案した内容を実行できるのか

• 技術

  開発会社が提案したパッケージや、使用する開発基盤を本当に習熟しているのかチェックするためには、過去に同様の開発実績がどの程度あるのか、その開発に実際に携わった人材が今回の案件にも割り当てられているのかをしっかりチェックする。

• ビジネスマインド

  「売上を伸ばす」「コストを減らすためにシステム投資を行う」といった、発注企業の本質的な目的を理解していないシステム開発会社も多い。たとえば、ECサイトのデザインであれば、「格好いい」「可愛い」という見た目の視点だけではなく、コンバージョンを上げるための工夫なども提案してくれる、「ビジネスマインド」の意識がある開発会社の方がパートナーとして最適である。

• 業界知識、業務知識

  発注企業の業界知識、関連する業務の知識や経験がどの程度あるのか、過去の具体的な実績からチェックする。具体的な知識があると、発注企業の考えが及ばない部分も先回りして考え、対応できる。

実績の評価：過去に同様の案件の実績が十分にあるか

発注するシステムのカテゴリ、発注企業の業界、業務に関連した開発実績がどの程度あるのか、過去の具体的な実績からチェックする。また、その開発会社が多く受注する案件が、自社の予算規模とかけ離れていないかも重ねて確認する。

企業信用度の評価：企業の信用度は十分に担保されているか

システム開発は受注から納品までの期間が長く、中小企業の案件でも長いものだと1年近くかかることがある。開発後の保守運用なども視野に入れると、開発会社の信用度の確認は必須である。

具体的には、財務面での与信確認を行うのが基本であるが、それ以外に、代表者の略歴や設立からの経過年数、主要取引先（一次請けが多いか、二次請けが多いか）などを確認しよう。また、人の入れ替わりが激しい会社だと、よい人材を割り当ててくれたと思っても、途中で担当が変わってしまうリスクもあるので、人材定着率がどの程度か、それとなく確認するのもよいだろう。

評価をどう採点するか、正解は発注企業によって異なる

前述の通り、評価シートをもとに重要なポイントをチェックしていくと、最後にはそれをどう定量的に比較すればいいのかという話になる。配点方法はいろいろな方法があり、たとえば、項目ごとに1～5の点数をつけ、その合計点で定量比較する方法もあるし、各項目に〇×を付け、〇の数で比較する方法もある。

ただ、どの方法もメリット・デメリットはあるし、発注企業の事情によって何の評価軸を優先するのかも異なってくる。よって、どれがベストな採点方法かは、ここでは言及しない。

リサーチやヒアリング、オリエンテーション、提案のプレゼンテーションなどを経て、候補のシステム開発会社とは少なくとも3回以上は面会し、合計5～6時間ほど対話の時間を費やしているはずだ。そこで得た開発会社のさまざまな情報、担当者個人の印象、柔軟性、レスポンスの早さなども見逃せない要素として加味できる。

最終的には、多面的な評価軸を持って開発会社を見ることで、自社に最もマッチした開発会社を選ぶことができるはずだ。

見積もりサンプルでチェックポイントをおさらい

ここまで、発注先の選定方法を見積もりの評価ポイントとともに紹介してきたが、最後に見積書サンプルを見ながら、おさらいをしておこう。見積もりにはフォーマットがないため、あくまで一例だが、最低限ここで示したような情報がきちんと書かれていないのであれば、見直しが必要だろう。

初期のシステム開発に関する見積書

ここまで説明してきたように、開発費の内訳が「ホームページ制作一式」などではなく、具体的に記されているのかわかるだろう。もし聞きなれない専門用語が書かれていたら必ず確認しておく。データ移行などの作業項目は漏れやすいので要注意だ。RFPにあった納品物が書かれているかも確認する。

また、備考欄には前提条件など、重要な情報が書かれている。追加作業やスケジュールが超過した場合の料金なども記載されており、プロジェクト途中で発生したトラブルの対応にも関係してくるものだ。

運用保守に関する見積書

Webシステムは開発して終わりではなく、長く運用を続けていくものである。開発費用とともに、運用保守費用をあらかじめ見積もっておくと、安定した運用につなげることができる。

この連載では、Webシステム開発の失敗原因になりがちな発注のスタートラインに絞り、システム開発会社の選定方法など、さまざまなノウハウを説明してきた。最後に2つのことをアドバイスしたい。

• 教科書通りの進め方やテンプレートにこだわらず、フェーズごとの目的を理解する

  システム開発の発注経験が乏しい中小企業の担当者向けに、リサーチやヒアリング、RFP作成、オリエンなどの方法論やさまざまな雛形を紹介したが、これらは参考情報の1つであり、フォーマットに縛られてしまっては本末転倒だ。時間的制約や人的リソースの問題で、すべてを完璧にこなすことはできなかったとしても、選定プロセスにおける各フェーズの意義や目的を捉えるために、可能な範囲で活用してもらいたい。

• 成功の鍵は、開発会社に高いモチベーションで取り組んでもらうこと

  第1回からの繰り返しになるが、良いシステムをつくるためには、いかに力のあるシステム開発会社をやる気にさせられるかどうかにかかっている。読者の方には、「なぜここまで発注する側が手間と時間をかけて頑張らないといけないのか？」と疑問に感じる人もいるかもしれない。しかし、「お金を払っているのだから、やってくれて当然」というように、業者扱いする姿勢で開発会社に丸投げしていると、筆者の経験上プロジェクトが成功する確率は限りなく低い。

  最終的には、ここぞという開発会社に「ぜひこの仕事をやりたい！　顧客の課題を解決するためにいいものを作りたい！」と思わせることが最も重要だ。そのモチベーションの醸成は、発注企業の情報提供の姿勢や熱意次第であり、発注先選定のプロセスの段階からすでに始まっている。さらに、良好な関係を維持するためには、発注後も変わらず努力を続けないといけないのだ。

  そういった意識を持って、開発会社の選定に臨めば、必ず自社にとって最高のパートナーを見つけることができるだろう。