システム開発を外注するなら知っておきたい全工程を徹底解説!

こんにちは!

ITエンジニア・webディレクター・webデザイナーなどのIT人材の自立・キャリアを支援するITプロパートナーズのCTOの柳澤(やなぎさわ)です。 弊社は、独立精神旺盛な優秀なエンジニアの方々の独立・起業サポートや、フリーランス支援を行っている会社です。

こちらの弊社運営サイト、「スタートアップ開発ラボ STaP(スタップ)」では、企業の新規事業開発担当者の方や、システム開発責任者の方、事業責任者の方達に向けて、事業開発のコツや、自社プロダクトやWebサービスを立ち上げる際にポイントや注意点について、弊社ノウハウを包み隠さずにお伝えしています。

システム開発を外注したいけれど、

「どんな工程でなにが行われているのか?」、「発注側はどんなことをすればよいのか?」

今回はそんなシステム開発においての全行程について解説いたします。

それぞれの工程において、発注側と開発側のそれぞれの作業を分けて、わかりやすく解説します。

システム構築の全工程について

まずは、システム構築の工程について確認しておきましょう。

システム構築と単に言っても、そこにはさまざまな手順やテストが踏まれておこなわれています。

以下にその全行程を挙げてみました。

1. RFP(提案依頼書)を作成

2. 基本契約書

3. 要件定義

4. 基本設計

5. 詳細設計

6. 製造・単体テスト

7. 結合テスト

8. 総合テスト

9. 受入テスト

10. 納品

11. 稼働

12. 保守メンテナンス

これらがシステムが完成するまでの全行程です。

これだけ見ただけでは、どこで何をしているのかがイマイチわからないですよね。

では、次にこれらの工程でいったい何が行われているのかをチェックしてみましょう。

全工程のそれぞれを解説!

それぞれの工程で何が行われているかということはもちろん、発注者側、開発者側がそのタイミングで何をしているか・しなくてはいけないかということも解説しています。

では、順に見ていきましょう。

1. RFP(提案依頼書)を作成

システム開発を外注した際に一番最初にRFP(提案依頼書)を作成します。
開発の納品期限、予算、目的などを共有する目的があります。

発注者はこのタイミングでしっかりとイメージを伝えておかないと、時間をかけて出来上がったものの、イメージと違う・・・なんてことになりかねません。

しっかりと情報や方向性を共有しておきましょう。

・発注側の作業→情報の共有

・開発側の作業→開発に関する目的などの理解

2. 基本契約書

作成したRFPをもとに、契約書を交わします。

発注側の作業→契約書を交わす

開発側の作業→契約書を交わす

3. 要件定義

RFPで共有した情報をもとに、具体的にシステムにどう組み込んでいくかということを決めていきます。

どのような機能で、どのくらいのパフォーマンスをおこなうかということを決めていきます。

発注側の作業→情報の共有

開発側の作業→要件の定義

4. 基本設計

要件定義された内容をもとに全体像や概要をざっくりと設計します。

発注側の作業→プロトタイプの確認

開発側の作業→要件定義された内容をもとに設計

5. 詳細設計

基本設計の情報をもとに開発側がより細かな設計をおこないます。

発注側の作業→とくになし

開発側の作業→細かな設計

6. 製造・単体テスト

開発後にテストをおこないます。

多くの人手が必要とされ、時間がかかる工程です。テスト結果は「正常系」「異常系」と大きく分けてふたつに分けられます。

発注側の作業→とくになし

開発側の作業→テストをおこなう

7. 結合テスト

基本設計でさだめられた通りにシステムができているかを検証します。先ほどの製造・単体テストと比べて比較的人員は割きません。

発注側のスルコト→とくになし

開発側のスルコト→基本設計をもとに検証をおこなう

8. 総合テスト

先のテスト結果の改善を含めて、要件定義に基づいた総合的なテストをおこないます。また、これらはより実際の運用後を想定したテストがおこなわれます。

例えば、会計処理システムをつくっている場合、入金がおこなわれなかった場合はどうなるか、請求がしっかりと反映されているかなどありとあらゆる状況を想定して確認します。

発注側の作業→とくになし

開発側の作業→総合的なテスト

9. 受入テスト

開発の工程の大半を終え、これから納品をおこなうにあたり、発注側と開発側が顔を合わせて要件定義をクリアできているかということを確認します。

発注側の作業→要件定義をもとにシステムの確認

開発側の作業→発注側とともにテストの最終確認

10. 納品

受け入れテストに不備がなければ、検証の合格と定めて互いの合意のもとに納品をおこないます。

発注側の作業→納品を受ける

開発側の作業→納品をする

11. 稼働

社内、または運用する組織内で本稼働にあたる社内説明会や社内研修をおこないます。

発注側の作業→システムの社内共有

開発側の作業→とくになし

12. 保守メンテナンス

双方の会社で協力しながら、これからの運用にあたりシステムの保守体制を取り決めます。

発注側の作業→保守体制の取り決め

開発側の作業→保守体制の取り決め

まとめ

いかがでしたか?

今回はシステム開発においての全行程と、発注側と開発側のそれぞれの工程での作業についてまとめてみました。

開発側はもちろん、発注側であっても作業が必要ですし、開発側の作業の理解も多少必要です。

システム開発は外注したら終わり・・というわけではありません。

「専門的な知識をもっている会社と協力して一緒に良いもの、イメージ通りのものをつくっていく」と考えたほうがよさそうですね。

また、これらの発注側の作業を適当にしてしまうと、システム開発が失敗する可能性が高くなります。

発注側、開発側でしっかりと支え合い、イメージにより近い良いシステムをつくりあげましょう。