システム開発の流れを徹底解説！【2023年最新版】

システム構築を外注したい会社の担当者は、業務を遂行するプロであっても当然のことながらシステム構築のプロではありません。したがって、システム関連の言葉が出てきても、開発会社の人に「それは、お任せします」と言ってしまいたくなります。

しかし、システム構築を成功させたいなら、プログラミングを行ううえでの細かなプロセスは別としてプロジェクト全体の状況は発注側でしっかりと把握しておかねばなりません。

そうでなければ、最悪のケースでは納期直前になって「やっぱりできません」「追加予算が必要です」といった、当初の計画をひっくり返すような出来事が起きないとも限りません。

実際に有名地方銀行の仕事を請け負った日本を代表するようなSIerが、その地銀に対してこれに近い対応をして訴訟問題に発展したこともあります。
「相手はシステム構築のプロなんだから、専門的なことは任せました」という態度では、そうした悲劇が自分の会社で起きることもあり得るわけです。

システム構築の流れは、下記のようになります。

まずはその全体を見てみましょう。

専門用語がズラッと並んでいる印象ですが、個別に理解していけば、もちろん全体を発注者側で管理できるようになります。特に正確な見積手法についてはしっかり確認しておきましょう。技術的な分野なので項目などがわかりづらい場合もありますが、後々の予算管理が非常に楽になります。

それでは、次章でその個々の工程を解説していきます。

まずは、ざっくりで良いので自分の作りたいシステムの機能・デザイン・納期・費用などをまとめてみましょう。

次に、発注先を探しましょう。発注先を「探す」→「相見積もりをする」→「選定する」これらの作業は時間がかかる上に、ある程度の知識がなければ良い発注先かどうか判断するのは難しいでしょう。

アイミツでは、審査済みの優良企業のみをご紹介しており、初心者の方でも安心して優良企業とマッチできるようにサポートしています。

審査済みの優良企業を紹介してもらう

「RFP（Request For Proposal）」を普通の言葉にすると「提案依頼書」となります。
欲しいシステムの概要や目的、希望納期などを伝えるためのA4用紙で１枚ほどのドキュメントです。わかりやすいRFPを書くことで発注もスムーズになります。システム開発依頼書（RFP）の書き方についてもある程度勉強しておきましょう。

「オリエンテーション」とは前項目である１のRFPを開発業者に説明するプロセスです。個別にRFPなしに打ち合わせをすると開発会社の担当によって打ち合わせ内容にバラつきが出てくるので、各社共通に、RFPで説明するのがオリエンテーションだと考えておきましょう。

「相見積もり」は一般的な言葉ですが、金額だけでなくRFPに対する回答、提案内容をしっかりと見比べてください。費用相場はどれくらいかについても確認しておきましょう。

「基本契約書締結」は、開発が進行したときの役割分担などは後回しにして、ざっくりとした金額や保守対応などの枠組みについての合意事項をドキュメントにします。その名の通り「基本契約書締結」にすぎませんので、必ず項目11の「個別契約書作成」を行ってください。

「要求定義作成」は一般的な言葉にすると、RFPをもっとかみ砕いて、どんな場面でどんな問題が生じていて、それをどんな風に解決したいか、を開発者に伝えることです。提案依頼書(RFP)・要求定義・要件定義の違いについても解説していますのでご覧ください。

「要件定義作成」は平たく言うと、「要求定義」を開発者側から見て、システムに落とし込んだ必要機能などを指します。

「外部設計」は一般的な言葉にすると、全体のインターフェースや業務フローの画面遷移、データベース入出力画面などの外見的な見た目を設計することです。システムが使いやすいかどうかの鍵になりますので、しっかり打ち合わせをして、その内容を詰めてください。

「内部設計」簡単に言うと、プログラミングの設計です。この部分についてはシステム開発会社に任せてしまってかまいません。

「個別契約書作成」詳しく言うとと「作業分担内容」「共同作業内容」を明らかにし、「最終的な請負金額」を明記する契約書です。これがないままに開発が見切り発車してしまうと、大きなトラブルを呼ぶことにもなりえますので、十分な注意が必要です。

「テスト計画」は簡単に言うと、「納品時にどんな検証項目を設定するか」です。Excelなどでチェックリストを作るのが一般的です。

「プログラムコーディング開始」は文字通り、発注先での作業開始を指します。
システム開発の外注プロセスでは、すでにここまで１2の項目があったわけですが、この項目13の「プログラムコーディング開始」を外注のスタートと考えてしまいがちなので要注意です。

「単体テスト」は簡単に言うとと、分割して作成したプログラムが動くかどうかのテストです。これは開発側に任せてしまって構いません。

「結合テスト」は簡単に言うと、分割して作成したプログラムを合体させたときに動くかどうかのテストです。こちらも開発側に任せてしまって構いません。

「システムテスト」は簡単に言うと、納品先の環境でプログラムが動くかどうかのテストです。こちらも開発側に任せてしまって構いません。

「受入テスト」は簡単に言うと、項目12の「テスト計画」で作ったリストを元に、納品物の検収作業を行うことです。項目19の本稼働後に、システムを動かしながら修正するのは困難が伴います。
期待された動作が正しく行われるかを漏れ無く確認しましょう。

文字通り納品です。物品の注文とはことなり、システムの場合は稼働してこそ意味があるものです。
ここで気を抜かず、次の項目19の本稼働に向けて、社内での導入体制や手順を整えておきましょう。

「本稼働」は、「現場で業務を開始すること」です。この段階で問題が明らかになった場合には、すぐに開発会社に報告して対応するようにしてください。

項目11の「個別契約書作成」に、納品後どのくらいの期間まで無償で不具合に対応するかが書かれているはずです。期間を過ぎると明らかにプログラムのバグだと思われる場合であっても、有償の対応となる場合もありますので注意が必要です。

文字通り保守・メンテナンスとなります。こちらは基本的には有償となりますので、契約書にて保守・メンテナンスに関わる金額を決めた上で対応してもらうようにしましょう。

いかがでしたでしょうか?
一見難しそうに見えて、システム開発の言葉も一般的な言葉に翻訳すれば、一部のプログラミング作業などを除いて、発注者がキチンとおさえて置かなければならないものばかりでしたね。

こうした部分を押さえて置き、開発側の担当者と密なコミュニケーションを取ることがシステム開発成功のコツです。

日本最大級の発注業者比較サイト『アイミツ』ではシステム構築に関する専門知識を持ったコンシェルジュが、信頼のおける会社を完全無料で紹介することができます。

システム開発には、大きな期間とコストが掛かるものです。

一度大きく切り替えると、もとに戻すことは現実的には不可能です。

外注の進め方や外注先の選定についてなど、まずはお気軽にお問い合わせください。
すぐれたコンシェルジュが、あなたの会社に合った企業選びを全力でお手伝いさせていただきます。