私が輝く、夏がはじまる。
私が輝く、夏がはじまる。

システム開発の工程・流れをご紹介!よく使う略語も解説

Akemi

こんにちは、LIGのAkemiです。「BiTT開発」というオフショア開発事業のコンサルタントをしています。今回は、システム開発の進め方を知りたい! といった声に答えるべく、開発の工程を解説していきますので、ぜひ参考にしてください。

システム開発の全体の流れ

システム開発を成功させるためには、発注者も最低限の開発の工程を理解しておくと、開発がスムーズに進み、リスクの回避ができます。まずは、システム開発においての全体の流れを把握していきましょう!

まず初めに

システム開発を行う際に、システム化の方向性やシステム化の計画を立てます。これは、RFP(提案依頼書)とも呼ばれています。発注側がシステム開発をする際に、必要なシステム構成に関しての要件や保証条件などが記載されているものです。

RFPの準備がしっかりできている場合は、発注先候補に対してオリエンテーションを開催し、見積りや提案までを比較的容易に受けることができます。しかし、多くの場合はRFPがなかったり、RFPの内容が不十分なケースがあるでしょう。その場合は、発注候補の開発会社と打ち合わせを重ねて、作りたいものをしっかり理解してもらうことが成功への第一歩となります。

こちらの記事では、おすすめシステム開発会社を得意領域別に紹介しています。ぜひ参考にしてみてください。

提案を受ける

作りたいものの方向性が決まったら、発注先候補の開発会社にご連絡しましょう。その際に、RFPや提案依頼事項に対する回答(提案書及びお見積もり書)を取り寄せます。

依頼事項に対してしっかりと回答がもらえているか、作業スケジュールや費用の概要を評価したうえで、発注先を決定します。

契約の締結

発注先を決定したら、システム化の範囲の概要、費用、各当事者の役割分担等を契約書にて決定します。

契約形態には、依頼した仕事を完成させ、完了した仕事や成果物に対して報酬を支払う請負契約と、依頼した仕事に対しての労働時間に対して報酬を支払う準委任契約があります。

開発の工程

システム開発は、主に以下のステップで行われます。

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

それでは、それぞれのステップを簡単に説明していきたいと思います。

要件定義(要求定義)

要件定義は、システム化すべき範囲を文書にまとめたものです。一般的には発注側の責任で行うべきとされることが多いのですが、要件定義が不十分で、納期の遅れや費用の増大などのトラブルが生じることが少なくありません。専門的知見が必要ですので、ベンダが要件定義の支援を業務として行ってくれるのかなど、事前に確認をしておきましょう。

基本設計(外部設計)

要件定義の内容をもとに、ユーザーインターフェース(画面などの外見的な見た目)を設計します。UIと呼ばれ、ユーザーにとって使いやすいシステムを作るためにとても重要な工程になります。これにより、ユーザーの使い勝手が決まりますので、開発会社との打ち合わせの際にはしっかり内容を詰めましょう。

詳細設計(内部設計)

基本設計(外部設計)が決まったら、次は詳細設計(内部設計)、プログラミングの設計を行います。基本設計(外部設計)はユーザー側からの視点が求められますが、内部設計においてはプログラムの設計など、開発者側からの視点での設計が必要です。

プログラミング

プログラミングの設計ができたら、コンピュータへの指示を記述していきます。この時、コンピューターは人間の言葉をそのまま理解できないため、コンピューターが理解できる「プログラミング言語」を用いて命令を出します。「プログラミング言語」にはいくつかの種類があり、どれも、人間にとって分かりやすい書式になっています。しかし、そのままではコンピューターはその内容を理解することは出来ませんので、人間が「プログラミング言語」で書いたソースコードを、機械語に翻訳する必要があります。

単体テスト

作成したプログラムの1つひとつが、最初の要件定義で求められている基準を満たしているかを確認していきます。単体テストでは、プログラミングのモジュール(対象単位)ごとにテストを行います。

結合テスト

単体テストの次は、複数のプログラムを組み合わせた状態で、それらがうまく機能するかを検証します。先程の各モジュールを結合してテストを行うということです。データの受け渡しなどでプログラム同士が正常に連携するかをテストします。

総合テスト・システムテスト

単体テスト、結合テストが完了したら、それらすべてを含めた総合テスト・システムテストをおこないます。すべてのプログラムが、要件定義の通りに動くのかを確認する工程です。このときに、アクセスへの耐久性や処理速度などもテストします。

運用テスト

運用テストでは、実際にシステムを運用する環境下において、システムに不具合がないかをテストします。ここでは、実際に業務に取り入れることができるかという点をテストしていきます。

システム移行(リリース)

実際に使えるように、旧システムから新システムに切り替える工程です。

運用・保守

作って終わりではなく、開発したシステムを持続的に活用し続けるためには、常にシステムを監視する必要があります。問題なく運用できるように、メモリの利用状況などを確認したり、随時アップデートをおこなうことも、この工程に含まれます。

開発モデルの種類

開発に取り掛かる手順には、いくつかの種類がありますが、代表的な開発モデルとしては、ウォーターフォールアジャイルというモデルがあります。

ウォーターフォール開発とは?

開発の工程に対して、要件定義に近い上流工程から、保守や運用に近い下流工程へと順番に進むように計画し、プロジェクトを進めます。これが、このウォーターフォールモデルというシステム開発の種類の特徴です。

この開発方法は、プロジェクトによって例外はありますが、計画的に工程が進みます。進捗状況の把握が容易であることや、品質が担保しやすいという特徴を持っています。

アジャイル開発とは?

アジャイルとは、日本語で「素早い」という意味を持ち、とにかくスピード感のある開発方法です。ウォーターフォールモデルでは、一つひとつの工程を順におこないますが、アジャイル開発では、そのような決まりはありません。開発を進めながら、随時変更や修正をおこなっていく開発の進め方です。

この開発方法は、要件定義が明確にできておらず、まずは作りはじめてみて随時修正をしたいときには最適な開発方法です。スタートアップや新規事業に向いている開発モデルといえるでしょう。

「ウォーターフォールモデル」「アジャイル開発」のメリット・デメリットに関しては、ともぞうさんがまとめていますのでこちらもぜひご覧ください。

開発用語集

システム開発の現場では多くの略語が用いられます。代表的な略語を覚えて、コミュニケーションロスを防ぎましょう。

工程 略語 英語表記
システム企画 企画 SP System Planning
要求分析 SA System Architectural design
System Analysis
System Analyze
要件定義 RD Requirement Definition
基本設計 BD Basic Design
UI基本設計 UI User Interface
外部設計 ED External Design
詳細設計 DD Detail Design
内部設計 ID Internal Design
構造設計 SS System Structure Design
機能設計 FD Function Design
プログラム設計 PD
PS
Program Design
Program Structure Design
プログラミング PG Programming
コーディング CD Coding
単体テスト UT Unit Test
結合テスト IT Integration Test
総合テスト PT Product Test
システムテスト ST System Test
運用テスト OT Operations Test

さいごに

開発の工程においては、ドキュメントの作成・管理も欠かせません。

ドキュメントは、コミュニケーションギャップを埋め、コミュニケーションの質を高めるための最重要な手段となります。人によって解釈が変わることがないよう、完結に必要事項が記載されていることが望ましいです。そのため、仕様や要件の変更が即座に反映されている必要があります。

全体の工程を理解したら、次は、ドキュメントの重要性をしっかり理解し、開発を成功に導きましょう!

なんだか、不安だなぁという方は、ぜひご相談ベースでも構いませんので、気軽にお声がけください!

システム開発について問い合わせる

システム開発資料ダウンロード

「BiTT開発」導入事例

オフショア開発に関する記事

▼BiTT開発について詳しくはこちらから!

3 0 0 0