昨今、システム開発会社が規模の大小を問わず多数存在しており、どの会社に頼んでいいか分からない一般企業も多くなっています。
事業に必要なWEBシステムの開発を依頼するにあたっては、コンペや直接依頼といった様々な方法が考えられます。本稿ではコンペ形式のシステム開発案件における、発注者・受注者のそれぞれが準備しておくことと事前に注意しておきべきポイントについて紹介します。
コンペ開催前には依頼側よりRFP(提案依頼書)が用意される
RFPとは「Request For Proposal」の略称で、提案依頼書といいます。
システム開発を行うにあたり、発注者が提案してほしい内容や要件を具体的にまとめた文書のことを指します。
コンペ開催時に発注者からRFPが用意される理由は単純に希望するシステムの要件が網羅されているだけではなく、両者の責任関係や役割分担を明示する重要な書類です。
提案依頼書が存在せず、口約束のままシステム開発のコンペが進んでしまうと、各開発会社から提出される見積もりに大きな乖離が出るだけではなく、実際にプロジェクトが始まった後で認識の齟齬が生まれトラブルの原因になってしまうケースも考えられます。
コンペ開催時には発注者側は必ずRFPを用意し、受注者側はRFPの有無を確認しましょう。
RFPで確認しておきたい情報
発注者側がRFPを用意しているからといって、安心してはいけません。
文書内に抜けや曖昧な表現があるとトラブルの原因になることがありえるからです。
RFPに書かれている内容を参考にするのはもちろんですが、両者の思い違いを防ぐために事前の質問会や打ち合わせでは認識のすり合わせを必要以上に行うことが大切です。
また、「RFP書いてあるから」といって思い違いを起こしたまま提案資料を作ってしまうと後に取り返しのつかない巻き戻しが発生してしまうリスクがあります。
では、コンペ開催前にRFPが提示された時、どの項目を抑えておけばよいのでしょうか。
以下に確認しておきたい内容を紹介します。
予算,スケジュール,要件などの基礎要件
何かを制作する際は「いつまでの・どんなものを・いくらで」希望しているのかは最低限抑えておくべき項目です。
期日と金額と作成要件のどれか一つにでも不備や不明瞭な部分があった場合、後ほど訴訟問題にまで発展するほど重要なポイントとなるでしょう。
また、要件に関しては、受注者側の委託範囲についてもよく確認しておきましょう。
両者の委託範囲を予め定めておくことで、開発進行中に役割が宙に浮いた要件が見つかった場合や新しい仕様が追加になった場合などの責任範囲の判断基準になるからです。
セキュリティや機能の拡張性などの付帯要件
ひとつのシステムを開発するとなると、単純な機能だけではなくセキュリティ対策はどのように実現するのか、今後のアップデートや運用計画はどうなっているかといった「先を見越したシステム開発」を求められる場合があります。
将来的に更新の必要のないシステムであれば杞憂に終わる可能性もありますが、よく見かけるケースとしては納品後に「次のアップデートの開発について」依頼される場合です。
こちらは、当初聞いていないアップデート計画であった場合、既存のシステムを根本から見直す必要があり工数が余計に膨らんでしまうリスクがあります。
一方で発注者側は一度システムの開発は完了しているのだから、機能追加であればコストを押さえられると考え、結果両者の費用間に大きなズレが発生してしまうのです。
また、個人情報を扱うシステムの場合、プライバシーマークやISMS認証、CMMIレベル3以上といった高いセキュリティを受注者側の開発環境に求める場合もあります。
納品後の保守管理体制
納品方法はサーバーに設置から紙や電子媒体で数を指定されますが、時に納品後のシステムの保守管理について役割が不明瞭となる場合があります。
発注者側でシステムメンテナンスを行う場合は、引き継ぎ内容をOJT形式で行うのか、管理マニュアルを別途用意するのかといった作業の有無を確認する必要がありますし、受注者側でシステム開発後も保守・点検を行う場合は別途契約を結ぶ必要があります。
システムは完成してからがスタート地点のようなものなので、開発終了後のシステムの取り扱いについてはRFPを確認する時点で抑えておきたいポイントです。
クライアント側がコンペ時に求めていること
発注者であるクライアント側が受注者側の提案内容に求めている内容について紹介します。
ベンダーとよばれる開発会社側はコンペへ応募する際、以下の3点に留意して提案を行うように心がけましょう。
費用や期間の妥当性
適切なRFPを作成できた場合、自ずと見積もり金額の範囲はある程度固まってきます。
発注者側ははじめに制作期間と費用が他社と大幅な乖離が起きていないかを確認します。
あまりに利益を上乗せしすぎると一気に他社より高額な見積もりを提示することとなり、クライアント側の心象も好ましくないでしょう。
独自性(差別化)
基本的にベンダー側はRFPに準じた提案を行いますが、より印象に残る提案にするためには独自性を加えてみるのはいかがでしょうか。
コンペ時には「プラスα」の要素を入れることで競合他社との差別化を図ることができます。
例えば、料金の支払いについて独特のビジネスモデルを提案するといったものです。
その他、機能面でもRFPを満たしながら自社の強みを活かせる機能を提案できれば魅力的な提案に映るでしょう。
運用性
システムは運用してから初めて成果を発揮します。
機能を満たすだけではなく、実際にシステムを使う現場の手軽さをクライアント側は特に重視する傾向があり、コンペにて提案を行う際は、ユーザー目線のUIやUXを意識した管理画面をサンプル画面として提示するのも一つの手です。
システム利用者は開発スタッフではなく、機械に疎い事務スタッフの場合も多いにありえます。
RFPの内容を読み込んで、想定される利用ユーザーに最適な運用方法を提案できるシステム開発をコンペ時に提案できると、先を見越した実装ができる開発会社としてクライアントに評価されるでしょう。
コンペに参加する方法
では実際にWEBシステム開発のコンペへ参加するためには、どのような方法が考えられるでしょうか。
大きく分けて、以下のパターンが考えられます。
依頼者側からの紹介
取引先経由でのコンペ参加の打診が最も多いケースではないでしょうか。
また、一度参加したことのあるコンペ企業の紹介から新規の依頼者を紹介されることもあります。
もし、取引先から直接もしくは間接的に紹介を受けたい場合、普段から様々な会社と交流しておくとよいでしょう。様々な人脈から間接的に自社の認知度が高まっていくにつれて、自然と声をかけてもらいやすい傾向があります。
また、人が人を呼ぶいい循環に一度乗ると、次から次へとコンペ参加の声がかかることはよくあるケースです。
セミナーや異業種交流会、カンファレンスなど業界関係者が集まりには名刺持参で積極的に参加するべきです。
自社サイトからの問い合わせ
新規のクライアントからコンペ参加への打診がある場合、WEBサイトに設置している問い合わせフォームより連絡を受ける場合もあるでしょう。
自社サイトからの問い合わせでコンペ開催の連絡を受けたい場合は、依頼者側が検索しそうな言葉「システム開発+業種名やエリア名」を意識したWEBコンテンツページを作成しSEO対策を行い、検索結果の上位に表示されるように試みましょう。
まずは、自社サイトのアクセス数を増やして、総合的な問い合わせ件数を増やして認知度を上げることが問い合わせフォーム経由でコンペ情報の連絡をもらう最短ルートといえるでしょう。
コンペ開催時に準備すること
システム開発会社がコンペに参加する場合、事前に準備しなければいけない内容は多岐にわたります。
ここでは、応募前に注意しておくべきポイントについて紹介します。
注意しておくべきポイント
要件が具体的に明確化されているか
受注後に要件が大幅に変更されてしまうと、それまでの開発スケジュールが引き直しになってしまったり、そもそもの仕様を見直しになってしまったりします。
まず、RFPに記載されている要件に不明瞭な点はないか、ふんわりした記述になっていて詳細が曖昧になっている部分がないかを確認しましょう。
もし内容の認識にズレが発生しそうな要件を見つければ、提案を行う前に事前に発注者側へ確認をとり、意思疎通をとるように心がけてください。
明らかに無理な要件でないか
受注してからの辞退は基本的にNGと考えましょう。数ある競合他社の提案から自社を選んでくれているということは、他社には既に断りの連絡が入っている可能性があります。
成約がほしいあまりに、無茶な要件を飲んでしまうと結果的に両者にとって不利益なことばかりでメリットは何も残りません。
コンペ参加前に少しでも考えうるリスクを減らす対策を取った上で提案を行う方がお互いの時間を効率よく使うことができてよいでしょう。
こういう業者に発注したら危ない
クライアント側がコンペ参加企業を見極める際、どのようなポイントに注意すればよいのでしょうか。
ここでは提案するベンダー側の要注意な開発会社の傾向を紹介するので、参考にしてください。
全てYESで回答する開発会社
こちらからの実現可能かという質問に即答で「はい」と答える開発会社は要注意です。
担当者が開発知識に乏しい営業専門のスタッフの場合、RFPをきちんと読み込まずに、勢いだけで回答している場合があります。もし、全ての要望に質問や仕様のすり合わせがなくYESと答えてしまう開発会社に遭遇した場合は、具体的にどのように解決するつもりか等の説明を求めるようにしましょう。
もちろん、実際に触ってみないと分からない部分はあるかもしれませんが、信頼のおける開発会社の場合では丁寧に解決手順を分かりやすく伝えてくれるはずです。
実働部隊が見えない開発会社
これも営業スタッフと開発スタッフで社内人員が分かれているシステム開発会社によく見られるパターンです。
営業スタッフはプレゼンや提案に特化したスキルをもっているため一見とても魅力的な内容に映るでしょう。
実働部隊が見えない開発会社ほど、実際にプロジェクトが動き始めた時にトラブルが発生する要因になる場合があります。
コンペに参加する際、技術に視野の開けたスタッフが同席しているかを確認してください。
また、提案をもらう際に社内開発体制図といった資料を併せて要求することも解決策のひとつです。
依頼者の質問に対して回答が不明瞭な業者
システムに関する質問をクライアント側が行った場合、
- 「システム開発に関しては、全て当社に任せてください」
- 「一般の方には理解が難しいと思いますので、この説明は割愛させてください」
といった発言をする開発会社が存在します。
確かにクライアント側はシステムに関する知識は開発会社と比べると情報量が不足していて当たり前です。しかしながら、依頼者の質問は不安でもあるので、その不安解消を怠り説明を疎かにする会社は注意してください。本当に信頼のおけるシステム開発会社であれば、非技術者でも分かるように噛み砕いて回答を分かるまで説明してくれる筈です。
まとめ
コンペ案件でWEBシステム開発を受注し、クライアントが満足するシステムを納品できると継続して仕事の受注につながる可能性が高いです。
発注者であるクライアント企業同士、受注者側であるシステム開発会社同士の独自のネットワークや口コミが流動しやすい環境が完成されつつあります。
そのため、成功すれば横断的に紹介という形で新しいクライアントを紹介してもらえる可能性も多いにあり得ますし、その逆も然りで悪評が広まれば新規案件の受注ハードルはぐんと高くなってしまうでしょう。
WEBシステム開発のコンペへ参加する際は、万全の事前対策をとってから当日に臨みたいものですね。
