web開発を失敗させないための外注戦略とは？【2024年最新版】

web開発を初めて実施するという企業では、どんな開発会社に見積もりを取ったらよいのかまったく分からない…というケースも多いでしょう。
会社としては初めてのweb開発であったとしても、社内にIT関連に詳しい人材がいれば一から相談に乗ってくれる良心的な開発会社と詳細を詰めていく、といういわゆる「走りながら考える」やりかたを取ることもできます。

しかし、一般的には自社独自のweb開発をやりたい、というだけで発注内容の詳細が決まっていない場合、システム構築会社はそれほど親切には対応してくれません。
社内で詳細を詰めるためのたたき台の提案すらもらえないというケースもしばしばあります。

例えば自社で開発している健康食品をネット上で売りたい、という目的のためにweb開発を行おうとして開発会社に連絡を取ったとします。
「健康食品の売り上げの規模は？」「納期はいつまでに？」「予算規模はどれくらい？」などの質問を受けることになりますが、「詳細は未定なので、とりあえずざっくりとした提案をお願いします」というような対応をしてしまうことが多いでしょう。

こうしたケースでは、概算金額だけが書かれた見積書がFAXで送られてきたり、詳細について詰めるには相談料金がかかると言われたり、ひどいときにはそのままいつまで待っても連絡がこない、などということもあります。

こうした状況になってしまうと、何らかのつながりがある開発会社に依頼をしてしまうということが往々にしてあります。
しかし、自分たちが開発したいシステムの具体像もなく、相手の力量もよく分からないという状態で走り出すというのは、すでにプロジェクトの成功に黄色信号が灯っていると言えるでしょう。

この記事では、外注でweb開発を成功させるためには発注側が必ず押さえておくべきポイントをお伝えします。

それでは、発注側企業が陥りやすい問題などを踏まえ、失敗しないwebシステム発注・開発のポイントを整理していきます。

web開発ではパソコンなどの物理的な製品を納品してもらうのとは違って、サービスをシステムに落とし込んだソフトウェア製品を納品してもらいます。
そのため特に初期段階においては、発注者がどんな製品を求めているのがつかみにくいという現実があります。
これはシステム開発側企業が「お客さんの要望をつかむことが難しい」というだけでなく、実は発注側企業も「自分たちが何をしたいのか本当は分かっていない」ということが背景にあります。

これは、発注側企業の本音としてあり得そうな話ですが、実は開発会社もお見通しといった現実があります。

発注側からすると「なんて高飛車な…」と思うかもしれませんが、ノウハウの提供にコストがかかるのは当然と言えば当然です。
「将来大きなお仕事発注するかもしれないから協力してね」というのは、中小企業の場合には、あまり使えない作戦だということを肝に銘じておきましょう。

こうした発注側企業の本音部分と、開発側企業の本音部分のギャップを埋める手法としてRFP＝Request For Proposal（提案依頼書）があります。
RFPとはあくまで、提案を依頼するためのドキュメントであって、見積もりや発注の依頼書ではないことに注意しましょう。

きちんとした提案書をもらうために、開発会社が提案をしたくなるようなフォーマットで、必要な前提条件を網羅した依頼書を発注側から出しましょう、というのがRFPです。

【発注者がRFPに書くべきこと】

1. プロジェクトの全体像

発注側では詳細が詰まっていないにしても、プロジェクト開始の発端となったできごとや、問題解決のイメージなどはなんとなく把握しています。
しかし当然のことながら、開発側企業にはそうしたレベルの情報すらありません。

まずは、基本的な部分も口頭ではなくしっかりとドキュメントにして伝えましょう。
基本的な部分をドキュメントに書き起こしているうちに、曖昧だった部分が見えてくるという効果もあります。

2. 提案してほしい要件

全体像を伝えたあとは、具体的にどんな提案をしてほしいかを箇条書きにします。

3. 確認事項

プロジェクトを推進するにあたっての留意事項などを伝えておきます。

ここまで準備しておけば、開発会社も発注側企業が本気でweb開発を行いたいのだ、と認めてくれるでしょう。
プロジェクトの実現性をきちんと提示することで、開発会社も本気でweb開発の提案を出してくれるようになります。

なお、RFPは１社にだけ出すのではなく、同じドキュメントを複数の開発会社に提出します。
そして同一条件のもとに作られた各社の提案書の中身を比較検討していくことになります。

こうしたRFPを作成した上で、補足事項を電話や対面できちんと伝えれば、開発会社ではRFPに見合った提案書を返してきてくれます。
逆に言えば、しっかりしたRFPを作っているにも関わらず、「概算金額だけを書いた見積書をFAXで送ってきたり、詳細について詰めるには相談料金がかかると言ったり、そのままいつまで待っても連絡してこない」という企業は、発注先候補から外しましょう。

各社の提案書を比較検討する場合、どうしても最初に見積金額に目がいってしまいますが、この段階では見積金額はあくまで参考程度に考えておきましょう。
実際に詳細を検討していくうちに当初の金額が２倍になったり半分になったりするというケースは普通に起こり得ますし、そもそも開発会社のほうでも詳細設計も済んでいないのに最終的な確定金額のつもりで提案書に金額を記入するということはあり得ません。

冒頭部分で、開発会社のノウハウをタダで利用しようとして失敗する発注側企業の例を出しましたが、きちんとしたRFPを出していながら、その内容を反映していない提案書を出してくるような開発会社は、時間の無駄なので早急に候補から外すべきです。
このときのチェックポイントは以下のようになります。

web開発と言っても、ECサイト構築から業務システム、顧客管理システムなど多岐にわたります。
基本的なプログラミング技術や開発手法は共通だとはいえ、経験をたくさん積んでいる分野であれば予想外のトラブルに対処するノウハウもありますし、発注側企業の疑問点にも的確に応えくれることが期待できます。

また、パッケージシステムなどを使う場合にも、過去に同じパッケージを使った納品実績があるかどうかは必須になってきます。
開発会社としてはいろいろな経験を積みたいという本音もあるので、自社が過去に手がけたパッケージを推薦するのではなく、業界での評判が急上昇中の経験のないパッケージを推薦する場合があり得ます。
必ず技術的なバックグラウンドについて、実績を含めて評価してください。

発注者はシステムそのものを作りたいのではなく、システムを使って利益を上げたり、顧客を囲い込んだり、現状よりもコストを削減したりといったビジネス上の目的を達成したいわけです。

こうした基本的な背景については、RFPの「プロジェクトの全体像」で伝えてあるはずなので、そうした部分に踏み込んだ提案がない場合には、期待したとおりの納品物は上がってこない可能性があります。
望ましいのは、例えば発注会社が食品会社であればその業界の基本的な商品流通の知識を持っている、アパレル会社であればアパレルの在庫管理のシステムを作ったことがある、などの経験があることです。
また、同業でのシステム構築の経験はなくても、業務システムの本質を理解していてBPR（ビジネスプロセス・リエンジニアリング）的な視点で提案書を出してくる開発会社もあります。

そうした背景知識を持って提案書を作ってくれているかを読み取りましょう。
発注者のビジネスに対する理解があれば、詳細設計の段階でも発注企業の考えが及ばない部分についても、先回りして考えシステムに落とし込む提案をしてくれることなどが期待できます。

具体的要件について一部分しか提案書に盛り込まれていないというケースもあります。
これは、開発会社が苦手な分野には手を出したくないということが理由の場合もありますし、端的にRFPをきちんと読みこなしてシステム提案に落とし込む能力が足りないということもあります。
一部分の提案だけ斬新で予算も安く詳しく提案してくれていたとしても、まずはこちらからRFPで伝えた内容がどこまで網羅されているか、包括的に提案内容をチェックしてください。

これは発注者側には判断が難しいところではありますが、例えば提案書を比較検討してみると、１社だけが他の会社とまったく違う方式でのweb開発を提案している、ということはよくあります。
そうしたケースでは、単に的外れの場合もありますが、その会社が独自技術を持っていたり、独自に海外企業からライセンスを受けていたりするといったことが理由である場合もあります。
提案内容は斬新で魅力的であっても、最終的に納品物が完成するかどうかについてはある程度のリスクを考えておくべきです。

この点については、開発会社に直接質問してみることで想定するべきリスクがどの程度であるかを把握できます。
他社での納品実績などを含めた明瞭な回答があればよいですし、回答自体が曖昧でよく理解できないなどの場合にはリスクは高いと見ておいたほうがよいでしょう。

web開発においては当初予定していた同時アクセス人数などによって見積もっていたサーバーのスペックでは正常にサービスが展開できない、というケースに陥る場合があります。
こうしたインフラ的なスケールアップに対して迅速に対応できるのかどうか、どのように対応するつもりなのかについての提案があるかどうかは必ずチェックしてください。
最近ではこうしたインフラ的な拡張性を容易にするためにIaaSなどをプラットフォームとして使い、必要に応じてIaaS上で簡単にスケールできるシステムを提案する企業も増えています。

また、インフラの拡張性以外にもRFPをきちんと読み込んで、「発注者のビジネスに対する理解」を重視してくれている場合には、納品時に必要な機能を将来的に発展させるための提案を入れてくれていることもあります。

例えば、当初のRFPでの要望段階では「顧客データはCSVでダウンロードして使いたい」とだけ書いておいたのに、「ブラウザを使ってオンラインでCSVデータを表示し、そのまま編集もできるシステムも同程度の費用で対応可能」などの提案をしてくれる開発会社などは、ぜひ発注先候補として残すべきです。

先程「提案書を金額で判断しては意味がない」と書きましたが、ここまでのポイントをチェックした上で、価格を比較検討してみましょう。
そうすれば、どんな根拠でその金額が出てきているのかが分かります。

もちろん、ここまでのポイントをしっかりとチェックして読みこなしたのに、「どうしてこんなに金額がかかるの？」と疑問を持つような提案書もあるはずです。
そうした場合には、直接聞いてみるのがよいでしょう。
もちろんそのときに明確な答えが返ってこなければ、発注先候補から外します。

納期の妥当性に関しても、発注側企業では判断しにくいところがあります。
提案書を比較検討しても、各社の提案内容が異なっている以上、納期の妥当性は分かりません。
こうしたケースでは、事前にその会社の業界の評判（短納期で無茶な開発をして、納品後にトラブル頻発など）などを知っておくことで判断の材料とすることができます。

人数などに関しては提案書に盛り込んでくれるかもしれませんが、提案してきた開発スケジュール通りに進捗させるための体制が本当にあるのか、それともこの開発会社自体が仕事を下請けに丸投げしているのかなどは分かりません。
こうしたケースも、事前にその会社の業界の評判（実はあの会社は営業会社で実際の開発は人件費の安い東南アジアに丸投げしているらしい）などを知っておくことで判断の材料とすることができます。

こうした体制的なことを知っていれば、納品後のトラブルに関してもどこまできちんと責任を果たしてくれるかどうかも分かります。
明確に外注先も使っているということを伝えてくれ、トラブル時の責任体制も契約書レベルで保証してくれるのなら問題はありません。
しかし、表向き自社でやっているフリをして、実際には社内に１人もエンジニアがおらず海外にすべて開発を投げている場合などでは、不具合に対応しようとしても事実上できないというケースも考えられます。

次に、提案書をもとに候補となる外注先を絞り込んだあとの注意点を見ておきましょう。
実際に発注をかけてしまってから、プロジェクト途中で開発会社を替えることは容易ではありません。
どんなトラブルが起こり得るのかをシミュレーションしておけば、トラブルを未然に防ぐことが可能です。

どんな機能が欲しいかについての「要求定義」「要件定義」「詳細設計」などは、RFPに基づいて提案されてきた提案書にもある程度まで書かれていますし、提案書の方向性さえ大きく狂っていなければ、この段階はスムーズに行くケースがほとんどです。

しかし、インタフェース設計（外部設計）の段階になると、発注側企業が思っていたイメージが開発会社にうまく伝わらない、という場面が出てきやすくなります。
web開発を行う企業はもともとデザイン会社ではありませんので、インタフェース部分で洗練されたデザインを行うことを苦手とする会社もあります。
多くの開発会社では社内にデザイン担当者をおいたり、社外のデザイン会社とパートナー契約をしていたりしますので、デザイン的に気に入らない場合には、インタフェース設計（外部設計）の段階で妥協することなくきちんと要望を伝えましょう。

また、最初からデザイン重視でライバル企業と差別化をしたい、などの要望がある場合には、RFPの段階でそのことを明確に伝えておくことも重要です。
web開発こそが自分たちのやるべき仕事で、デザインは二の次という会社の場合、何度もデザインの注文を繰り返しているうちに「これ以上やるなら追加費用をお願いします」という反応もありますので注意しましょう。

実際にシステム開発に入った段階では、発注側企業がタッチすることはそれほど多くありません。
注意しなければいけないのは納期遅れと、テスト段階で見せてもらうシステムがこちらで想定していなかったものになっていないかどうか、という２つです。

どちらのケースにおいても、「開発がスタートしたらすべて丸投げ」という状態にせず、途中段階でチェックを入れていくことでトラブルを避けることができます。
定期的なチェックについては、日にちを決めて開発会社の担当者に時間を持ってもらい途中経過の報告を受けるようにすることが望ましいでしょう。

ただし、そうした取り決めをしたにも関わらず、開発スケジュール優先で報告の時間を確保せず、結局納品間際になって「できません」と言われたり、納品はされたもののバグだらけで使い物にならなかったりということも起こり得ます。
発注前には十分その開発会社の評判についてチェックしておきましょう。

システム開発の場合、納品時のテストでは問題がなかったのに、その後に予期せぬバグが発生するというケースは珍しくありません。
加えてweb開発では、システムそのもののバグ以外にも想定していたよりも運用面で手間がかかることが判明して、当初予定していた社内の人員だけではサービスの維持ができない、というケースもあります。

納品後のバグに関しては、いつまでの期間であれば無償で対応する、などの法的な取り決めをきちんと締結しておくことが大切です。
そして運用局面での想定外の人的、金銭的コスト増に関しては、設計段階で自動化、半自動化できる部分を徹底的に詰めておくことで対応できます。

例えば、想定していた以上にwebサイトの更新に時間と手間、費用がかかるという場合、設計段階で使いやすいCMS（コンテンツマネージメントシステム）を導入しておくことで対応できたかもしれません。
また、コミュニティサイトを展開したところ、炎上事件が頻発して対処に追われてしまったというケースでも最初にそうしたリスクを予想しておいて、有料サービスで「炎上監視」をしてくれる会社向けに予算を割いておくべきだったかもしれません。

また、セキュリティ関連の対策が甘くて頻繁にトラブル対応が必要となり、その度に別途費用を要求されてしまうというケースも設計段階でセキュリティに強いシステム構築にすることで防げたかもしれません。
こうした納品後のトラブルの芽も発注段階で積んでおくことができるという点を肝に銘じておきましょう。

システム的には完璧なものを納品してもらったけど、肝心のお客さんが想定した人数に遥かに達しない…というケースもよくあります。
これは狭義の「web開発」の範疇を超えた問題なので、いわゆるトラブルというわけではありません。
しかし、発注側企業としてはお客さんが利用してくれることを想定してweb開発を依頼しているわけなので、集客が思わしくないという状況が続く場合にはサービス提供を中断しなければならないという事態に陥ることもあるでしょう。

web開発会社のなかにはそれまでの開発経験を活かして、webサイトのSEO対策やソーシャルメディアと連携したマーケティング施策を代行してくれる会社もあります。
集客について特別な実施アイディアを持っていない場合は、これもRFPの段階で提案リクエスト項目に付け加えておくとよいでしょう。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

いかがだったでしょうか。
発注側企業では社内のたたき台をまとめるためにも、開発会社からの情報が欲しいという状況もありますが、開発会社もビジネスですので無条件でノウハウを出してくれるわけではありません。
発注をちらつかせて情報だけもらおうというような態度では、パートナーとしてプロジェクトを成功裡に推進していくことは難しいでしょう。

やはり基本としては、自社できちんとやりたいことを整理してRFPをまとめて開発会社とやりとりをすることが望ましい進め方です。
そして、候補となる複数の開発会社についての評判をリサーチし、営業マンの「何でもやります！」という言葉が本当なのかを見極め、提案書の内容の不明点を直接質問して潰していくなどの作業が発注担当者には求められます。

とはいえ、web開発の外注にほとんど経験がない、ホームページ制作の依頼しかしたことがない、という会社ではこうした基本を押さえた段取りをするのにも莫大な時間と労力がかかってしまいます。
そして、社内プレゼンの納期なども迫ってきて、ついつい既存の取引関係のあるホームページデザイン会社の営業に頼ってしまう…などということになってしまうかもしれません。

web開発の外注に不安なことがある場合には、ぜひ「アイミツ」にご相談いただければと思います。
御社のやりたいweb開発についてお聞きして、案件にピッタリのweb開発会社をご紹介いたします。
「アイミツ」ではweb開発会社の業界の評判や会社の実績などの情報も持っておりますので、安心しておまかせください。