システム開発依頼の流れは？開発会社の選び方から運用開始後までポイントを解説！

最終更新日：2024/03/28

「システム開発を外注したい！でも、会社が多すぎてどう選べばいいかわからない……」
「初めてシステム開発を依頼するので、なにをしたらいいかわからない」
「システム開発は費用も時間もかかるので失敗したくない」
「システム開発は専門外なので、意思疎通ができるか不安」

このようなお悩みを持つ方に向けて、この記事を書きました。

システム開発は数ヶ月〜年単位でプロジェクトが進行するうえ、数百万〜数千万の費用がかかるため、失敗しないようにと情報を集めている企業がほとんどだと思います。また、自社の専門外の領域であるシステム開発はなにをしたらいいか全くイメージがつかないと不安な方もいらっしゃると思います。

そこで、会社選びから契約時、運用開始後まで発注側が押さえておきたいポイントをまとめました。この記事を読むことで不安が払拭され、円滑にシステム開発をすすめるコツが掴めるようになりましたら幸いです。

システム開発会社に相談する前に決めておくべきこと

システムを作るとなったらすぐにシステム開発会社に相談したくなりますが、いくつか準備した上で相談をしたほうが話がスムーズに進みます。

目的と予算をあらかじめ社内で決定したうえでご相談いただくといいでしょう。また、依頼するシステム開発会社の候補をいくつか決めておきましょう。

目的

「こんなことできたらいいな」という風にシステムを作りたい動機を伝えても、目的が曖昧なため開発のスケジュールや予算がなかなか決まりません。的を得たアドバイスも難しくなってしまいます。

なぜシステムを作りたいのか、作る目的を明確にしましょう。このとき、「どう解決したいのか」ではなく「何を解決したいのか」にフォーカスを当てて情報を整理していきます。「何を解決したいのか」を明確にすべく、現状の問題点と、解決した結果どのような状態にしたいのかをまとめましょう。

現状の問題点の整理

現状問題となっている、業務上の解決したい課題を整理しておきましょう。例えば、

○○処理に毎月5日間も時間を要している
ある書類はExcelで各自で作成しており、フォーマットがバラバラで作成・確認に時間がかかる

などといった具合です。

解決した結果、どのような状態になりたいかを描く

「システム的にどのように解決してほしい」を検討するのではなく、「解決した結果どのような状態になりたいのか」を明確にしておきましょう。

このとき、できるだけ定量化、定性化された目標数値を設定するのが望ましいです。システム開発会社側と認識のずれが少なくなり、より希望に沿った提案をもらうことができます。例えば、

〇〇処理を1日で終わらせられるようにしたい
Excelで作成していた書類を管理しやすくしたい

といった具合です。システム開発会社からは、その解決法について提案をいただくように商談を進めていきます。

依頼する側が「このように解決して欲しい」と実現手段を指定すると、システム開発会社側がその実現手段でのみ検討を行う場合があり、自社で思いつかなかったようなアプローチでの解決法の提案を受ける機会を損なうことにつながる可能性があります。

補足：RFPの作成について

現状の問題点の整理と、解決した結果どのような状態になりたいか、は明文化しておくと話がスムーズに伝わりやすいです。

目的や条件などをより細かく明文化した資料をRFP（提案依頼書）といいます。用意しておくと依頼側と受注側でのズレを極力減らせたり、複数の会社に同じ資料を送れるため比較検討がしやすいというメリットがあります。作成にはかなりの労力と時間がかかるため、RFPの用意はしてもしなくても構いません。

ただ、目的の設定時の参考になるかと思いますので過去に書いた記事を2つ紹介します。悩んだ時のヒントになりましたら幸いです。

関連記事システム開発の提案依頼書とは？作成のしかたは？

関連記事仮想の提案依頼書サンプルを作成してみた（基幹システムのリニューアル）

予算

どれくらいの予算が確保できそうか、相談前に社内で確認しておきましょう。

予算をはじめから伝える必要はありませんが、おおよその予算感を伝えておくとその範囲内で最も効果を得られる提案が得られる場合があります。

依頼するシステム開発会社の目星をつける

Web検索で「システム開発」「業務システム」「基幹システム」などといったキーワードで検索すると、大量のシステム開発会社がヒットすると思います。

会社規模が大きいところから小さなところまで多数ヒットするので、その中からいくつかピックアップして選定します。選定ポイントをいくつか示します。

会社規模

大きな会社がよい、小さな会社の方がよいということは一概に言えません。自社の要求にあった対応をしてくれるところが選定対象となります。大手企業と小規模な会社では予算感やサポート内容が異なることがありますので、検討段階では絞らずにバランスよく問い合わせる方が良いでしょう。

自社のスタッフに責任をもって対応してもらえそうか

システム開発会社の中には、仕事だけ受注して下請けに丸投げするケースがあります。このような場合に受注会社で不必要なマージンが発生することがあったり、トラブル時の対応が悪くなることが考えられます。また、システム完成後も責任をもって保守運用いただくには、他社に丸投げしない会社を選ぶのが望ましいです。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

システム開発会社選びのポイント

前項で、システム開発会社の目星をつけるポイントを紹介しました。少し重複しますが、ここではさらに理想的な会社を選ぶための3つのポイントを紹介します。

1.信頼できる（責任を持って対応してもらえる）

先ほどと重複しますが、下請けに出す前提の会社も中には存在します。仕事を下請けに丸投げしてマージンだけ取られてしまう、運用後に問い合わせしたら会社と連絡が取れないなど、トラブルに発展することもあります。開発体制を確認し、下請けに丸投げしない会社を選びましょう。

営業担当者のシステムの理解度も見極めポイントです。営業担当者のシステムの理解度が低いと、できるできないの判断も適当なので予定通りに仕上がらないという事態が発生します。また、社内のエンジニアからできないと言われ、追加費用が発生する場合もあります。

また、開発スキルもチェックしましょう。開発スキルが低い会社はそもそも要件を満たす技術力がなく、結果できないこととなってしまいプロジェクトが失敗しかねません。

2.予算内の費用で解決したい課題が解決できる

数社に見積もりを依頼すると、費用がまちまちになるかと思います。予算内（適切な予算感）で解決したい課題が解決できるかもチェックポイントに含めておくとよいでしょう。

3.プロジェクトの進行やプロジェクトマネジメントについても自社の状況にあった形で満足できる内容で進行してもらえる

システム開発会社とは長い付き合いになります。自社の伝えたいことを汲み取り、そのうえで双方にプラスとなる意見やアドバイスをしてくれる担当者がいる会社を選ぶことが大切です。

プロジェクト進行やマネジメントなどはどうしてもシステム開発会社が主体で進んでいきますが、一方的ではなく発注側の状況も汲み取って進行してもらえる会社を選ぶとよいでしょう。

以上がポイントとなりますが、なかなか条件にあう会社が見つからないこともあります。その場合、予算に対して要求が高すぎたりなどの理由が考えられます。

しかし、そのような場合でも親身になって同じ立場で別案を考えてくれるようなシステム開発会社がいれば、信頼性の面でプラス評価されると良いと思います。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

システム開発会社への相談〜契約時のポイント

候補の会社をいくつかピックアップしたら、相談をしていきましょう。ここでは相談〜契約の際に気をつけるポイントを紹介します。

相談

商談時には実現したいことを伝え、その解決策の提案を受けるために必要な情報を提示します。

作りたい機能
想定している画面数
想定しているサーバー環境

最初は主に上記について聞かれることと思います。システム開発会社主導でヒアリングが行われますので、どのような情報を揃えればよいか・何を用意すればよいかは聞いてしまってOKです。

このとき、具体的な仕様書を提示してほしい、希望を形にした資料を提示してほしいと言われる場合があります。そのような資料を作成できる人がいて、すでに用意ができているのであれば提示すればよいですが、提示してもらえないと見積もりが作成できない、というシステム開発会社はヒアリング力・提案力がないと判断しましょう。そのような会社は言われたことしかできませんので、後々トラブルになる可能性が高いです。

提案を受けたら数社比較し、予算面、提案内容、納期、納品後のサポートなどさまざまな角度で自社の要求を満たすところに絞ってゆきます。最終検討対象として2〜3社まで絞りましょう。

提案内容や見積の妥当性を自社だけで判断するのが難しい場合は、第三者のプロがレビューする「システム開発のセカンドオピニオン」を利用する方法もあります。

また、複数社に相談中は質疑応答などの窓口は一本化しましょう。類似する質問が上がった場合で、各社への共有が必要と判断した場合に情報共有できるようにするためです。

契約

2〜3社まで絞った段階で、契約内容を確認しておきます。費用の支払い方法や支払時期、契約形態の確認をします。

支払い方法について

分割での支払いになるのか、一括での支払いになるのか確認しておきましょう。

契約形態について

請負契約になるのか準委任契約になるのか、確認しておきましょう。

請負契約では完成責任や成果物を契約で定めますが、準委任契約では役務の提供を定めるため、システムの完成の責任がありません。システムの受託開発においては、完成責任がある請負契約が大体の場合は適切です。

ただし、要件定義やコンサルティングから入ってその後にシステムの形を定めてから着工する場合、要件定義やコンサルティングの部分は準委任契約が適切となることがあります。準委任契約となる場合は、提供される役務についてよく確認が必要です。

相談〜契約内容の確認を経て最終的には1社に絞り、契約手続きを行います。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

システム開発の工程

契約を行ったあと、いよいよシステム開発がすすんでいきます。お客様側でも開発工程を知っていたほうがスムーズにやりとりができるかと思いますので、ここでは開発工程をご紹介します。

一般的には、以下のように開発がすすんでいきます。

要件定義
基本設計（外部設計）
詳細設計（内部設計）
プログラミング
単体テスト
結合テスト
運用テスト
システム移行（運用開始）
保守・運用

要件定義〜設計の段階は、お客様側とシステム開発会社の共同作業で行います。

プログラミング〜結合テストまでの作業はほとんどをシステム開発会社側で行いますが、お客様側もなんらかの形で監督に携わるのがベターです。例えば定例ミーティングを開催し、進捗確認・状況把握をしておくと良いでしょう。

運用テストでは、お客様に実際の業務の流れに沿ってシステムを触っていただき、不具合がないか・使いにくいところがないかを検証していきます。システム運用開始前後については、次の項で詳しくご紹介します。

要件定義

何をシステム化して問題解決するか、何をシステム化しないかを明確にする工程です。欲しいもの・思いついたものをすべてシステム化してしまうとコストが膨れ上がるうえ、実際には使用しない機能を作成してしまうことになります。

システムに関することは、ほとんどが要件定義の段階で決定していきます。業務の流れ、データの流れを確認・決定しつつシステム化するものを決めていきます。要件定義では、業務を一番よくわかっていらっしゃるお客様の協力が不可欠です。

システム化するものを決めるほか、以下のような必要となるネットワーク構成も要件定義の段階で決定していきます。

ドメインやSSLの取得要否
システムを運用するサーバー構成
使用するプログラミング言語
ミドルウェア（システムが動作するために必要な、サーバー上で動くこととなるサーバーソフト）

要件定義では要件定義書、サーバー構成図、業務フロー図などが成果物となります。要件定義について詳しくはこちらの記事で紹介しています。

基本設計（外部設計）

要件を満たすために必要機能を洗い出して設計し、必要なUI（ユーザーインターフェース…画面のこと）の設計と、各画面の偏移の仕様を明確にする工程です。次の「詳細設計」に進むために、業務ロジック（目的の処理をするために必要な顧客特有の仕様）を明確にしておきます。

システムのUIを使いやすくするために、ここでも依頼されたお客様の協力が不可欠です。

基本設計では基本設計書（画面遷移図、処理概要、項目定義書）などが成果物となります。

詳細設計（内部設計）

具体的なプログラムの仕様を設計する工程です。

データベース設計
コード定義設計
API設計
バッチ処理設計
外部システム連携設計

お客様側にエンジニアが在籍していて運用は自社で行う場合、この工程にも積極的に参加することが望ましいです。

詳細設計では詳細設計書、プログラミング設計書などが成果物となります。基本設計・詳細設計について詳しくはこちらの記事で紹介しています。

プログラミング

システム開発会社のプログラマが、仕様書に沿って指定されたプログラミング言語でプログラムを作成する工程です。

ソースコードが成果物となります。

単体テスト

単体テスト・結合テスト・運用テストを行ってバグを検出し、修正を繰り返すことで不具合の数を減らします。また、要件を満たしていることを保証するためにテストは重要な工程です。

単体テストは一般的に、機能単位で機能単体の試験を実施することを指す場合と、プログラム単位で単体で試験を実施することの両方の解釈があります。解釈を区別するために、「プログラム単位で単体で試験を実施すること」を「ユニットテスト」と呼んで、機能単位の単体テストと区別することがあります。

機能単位で機能単体の試験は、主に画面を実際に操作して、あらかじめ作成したテストの仕様書通りの動きであるかを試験します。

ユニットテストの実施には、通常ユニットテストを実行するための仕組みが提供され、その仕組みに沿ってプログラムテスト用のコードを作成します。

結合テスト

機能間が連動して動作した場合に、仕様通りにシステムが動作するかを試験する工程です。
単体テストをクリアしたパーツ同士を合わせて、それらがきちんと動くかを確認します。

運用テスト

システムのリリース前に実際の業務の流れに沿ってシステムを運用し、試験することを指します。アクシアでは試験段階でお客様に見ていただき、随時フィードバックをいただきます。

仕様通りに出来上がっているかのチェックをしていただくことはもちろん、スムーズに運用をまわすための予行練習も兼ねています。また、運用前に不具合を発見して修正できるように、思いつく限りの業務の全ケースをテストしましょう。

この3つのテストについてはこちらの記事で詳しく紹介しています。

システム移行（運用開始）

システムの運用が開始されることを指します。「(本番)リリース」「カットオーバー」「ローンチ」などの用語で呼ばれています。

保守・運用

システムを運用していきます。保守はシステムが動き続けるために必要な、システム的なメンテナンスやシステムの監視を行います。

保守・運用についてはこちらの記事で詳しく紹介していますので、もしよろしければこちらもご覧ください。

関連記事システム保守・運用とは？保守の重要性について

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

システム運用にあたって依頼者側が準備しておくこと

システムが運用開始されるまでに準備をしておきたい事項をいくつか紹介します。運用開始については、システム開発のプロジェクトの中でスケジュールが組まれ、以下のような準備作業が想定されます。

新しいシステムにデータを入れる際は、新しいシステムの入力方法に沿ってデータを整理していただくことがあります。例えば、新システムの名前入力は姓と名に分けて登録するためそれに適応するようにデータを整形しなおす、などの準備が必要な場合があります。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

システム運用開始時のポイント

運用開始自体はシステム開発会社がリードしてくれます。依頼者側はシステムが運用に乗るように、社内のユーザーにきちんとシステムを利用させるように働きかけが必要です。仕事の進め方が変わることに抵抗を示す方もいるので、そのような方でもシステムを利用するように働きかけてください。

運用開始後のポイント

運用が始まると、依頼者側でもシステム開発会社側でも想定できていなかったイレギュラーが発覚することがあります。その際にはシステム開発会社に連絡し、どのように回避するかを両社で落ち着いて検討してください。

また、事前の検証では気づけなかった不具合が発覚することもあります。このような場合、仕様書通りの内容なのかそうでないのかを冷静に判断し、仕様書異なる動作による不具合についてはシステム会社に連絡し、修正を依頼してください。

通常の請負契約では契約不適合責任(⺠法改正前の瑕疵担保責任)がありますので、その範囲での対応となる内容なのか、そうでないのか、システム開発会社側とも協議の上、対応方針を決定してください。