ITの発展に伴い、新規プロジェクトにとってシステム開発は今や欠かせないプロセスとなりつつあります。プロジェクトの成功確率を高めるためには、基本的な開発工程について理解することが大切です。今回の記事では、システム開発の工程・流れをご説明します。

1. システム開発の工程とは

システム開発は、決められた工程に沿って進められます。開発工程とは、システム開発におけるレシピのようなもの。この工程のおかげで、計画通りに、品質を保ちながら、システム開発を進めることができるのです。

実際の現場では、開発工程は、計画（要件定義）、開発（設計やプログラミング、テスト等）、運用・保守などの工程に分けられ、これらの工程を通じて、顧客が必要とするシステムを開発します。

なお、開発モデルや担当する企業ごとに、具体的な開発の工数（作業ステップ数）は異なります。しかし、何らかの業務を別の企業に外注するなどの場合であっても、計画的にシステム開発を進めるために、原則として開発工程をもとに進めます。

2. システム開発の工程

以下では、システム開発の際に経る10の工程をご紹介します。

要件定義 (RD)

システム開発は要件定義から始まります。要件定義では、要件定義書と見積もり書という２つの書類を作成します。要件定義書とは、システムの目的や開発期間、システムの性能、導入や運用方法など、システム開発に必要な「要件」をまとめた書類のとこを指します。システム開発会社との打ち合わせを重ね、要件定義書の内容を整理・確定します。システム開発は要件定義書に基づいて進行していくため、トラブルを防ぐためにも双方が納得できるように内容をすり合わせることが重要となるのです。

外部設計 (BD)

要件定義の内容をもとに、ユーザーインターフェースを設計します。基本設計書は、図やデータなどを入れて作成されたシステムの設計図のことで、ユーザーインターフェースと呼ばれる外的な見た目に関する設計図になります。

ユーザーにとって使いやすいシステムを作るためにとても重要な工程になり、ユーザーの使い勝手においてダイレクトに影響します。

企業は基本設計書を見て、システムの仕様やシステム導入後の業務改善方法を理解します。基本設計書は、システムの機能ごとに作成され、各機能を担当するシステム開発会社のエンジニアが設計書を完成させ、システム開発会社のなかで相互にフィードバックし改善します。その後、完成した基本設計書がシステム開発会社から共有され、システムの完成図を把握するのです。

内部設計 (ID)

外部設計が決まりましたら、次は内部設計、つまりプログラミングの設計を行います。外部設計はユーザー側からの視点でしたが、内部設計においてはプログラムの設計など、開発者側からの視点でシステムを設計します。

プログラミング (PG)

内部設計で、ある程度のプログラミングが設計できましたら、それに基づき、プログラムの作成を行います。

単体テスト (UT)

ここでは、実際に作成したプログラムの1つひとつが、最初の要件定義で求められている基準を満たしているかを確認します。単体テストでは、プログラミングの対象単位、いわゆるモジュールごとにテストを行い、不具合が見つかったら修正しシステムのルールやテスト結果のフィードバックを行います。

結合テスト (IT)

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

システム（総合）テスト (ST)

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

運用テスト (OT)

無事システムテストをクリアしましたら、実際に業務に取り入れることができるかを確認します。運用テストでは、実際にシステムを運用する環境下においてシステムに不具合がないかをテストします。つまり、今までのテストと比較すると、非常に実用性に重点を置いたものとなります。

システム移行（リリース）

実際に使えるよう、旧システムから切り替える工程です。一気に切り替える一斉移行や、徐々に切り替える順次移行などの移行方法があります。

運用・保守

「運用」はマシンの起動や停止、現行のシステムを日々動かしていく作業です。運転状況の監視や、CPUやメモリの利用状況などシステム資源の監視も行います。

「保守」とはシステムを改善・変更する作業です。主にシステムの障害や改善要望に伴うプログラムやデータの改修を行います。また周辺機器のリプレースやアップデートなども行います。

3. システム開発の２つモデルとは

3.1. ウォーターフォール開発の流れ

• 要件定義：

上流の工程から、下流の工程へ、順におこなっていくのが、このウォーターフォールモデルというシステム開発の種類の特徴です。

まず、顧客と打ち合わせを行い、どのような機能を持つシステムを開発するのかを決定します。ウォーターフォールモデルでは工程の逆流はできず、さらに工程の後半にならなければユーザーの要求を検証できません。そのため、特に要件定義でしっかりヒアリングを行うことが重要です。

• 開発

要件定義の後、開発に移ります。

まず、システムの全体構成や、システムの外見を構成するUI（ユーザーインターフェース）など、外部から見たシステムの全体像を設計します（外部設計）。

次に、システム内部ではどのような実装を行えばよいかを考え、ユーザーにとって使いやすいUIやデータベースなどの詳細設計を行います（内部設計）。

それをもとに、システムをモジュールと呼ばれる単位に分割し、モジュールの仕様やモジュール間のインターフェースを決定（プログラム設計）。

最後に、実際にシステムが動くようコードを書きます（プログラミング）。

• テスト

プログラミングが終わると、まずはモジュール単体で動作するかを試験します（単体テスト）。そして、問題がなければ各モジュールを統合して全体の動作確認を行います（結合テスト）。

予定通りに動作すれば、ユーザーの要求と照らし合わせて性能試験を行い（システムテスト）、最後に、実際にユーザーが使用するのと同じ環境下で不具合が無いかどうかをテストします（運用テスト）。

• リリース～運用・保守

すべての工程が終わればシステムはリリースされ、運用・保守に移ります。 ただし運用開始直後に、バクや仕様上で修正した方がよい箇所が見つかることも多くあります。

リリース後はサービスの改善のため、中・長期的にシステムの修正を行います。

メリット

• プロジェクト全体の計画が立てやすい
• 進捗管理がしやすい
• 品質の担保がしやすい

ウォータフォールモデルでは後戻りせず一方通行で工程が進むため、プロジェクトの計画が立てやすく、進捗状況も分かりやすいため管理もしやすいです。お金や人員などのリソースも、前もって準備がしやすいです。

また、一つひとつの工程をしっかりと完了させてから次の工程へ進むため、品質の担保がしやすいという点もあります。

デメリット

• プロジェクト計画に柔軟性がなく、要望の変更がしにくい
• 手戻りが発生した場合、大幅に遅れが生じる

一度ウォータフォールモデルで進み出したプロジェクトにおいては、基本的に前工程へ後戻りすることができないため、プロジェクトの初期段階でまとめた要望を後から大きく変更することが困難です。

またプロジェクト後半の下流工程になって手戻りが発生した場合、これまで行った途中工程も再度やり直しになってしまうため、納期にも多大な影響が出てしまいます。

3.2. アジャイルモデル開発の流れ

ウォーターフォールモデルでは、1つひとつの工程を順におこないますが、アジャイル開発では、そのような決まりはありません。アジャイルモデルでは、イテレーションと呼ばれるサイクルを繰り返すことで、システム開発を行います。

• リリース計画の策定

はじめに、顧客の要望をヒアリングし、開発するシステムの概要を決定します。

工程途中で発生する仕様変更に対応するため、ここでは、まだ細部までは決定しません。

• システム計画の分割

開発するシステムを機能ごとに分割し、各機能の性質を鑑みて、開発する手順を決定します。

それぞれの機能は1週間から4週間程度で開発できる規模に設定されることが多く、機能ごとに要求定義、設計、テスト、実装、リリースを行います。

• イテレーション

上述した「要求定義→設計→テスト→実装→リリース」をイテレーションと呼び、各機能においてイテレーションを行うことで、システムの完成を目指します。

イテレーションが終了すると、さらに機能を追加するか、開発を終了するかを顧客とともに判断します。

メリット

• システム開発期間を短縮できる
• 仕様変更や不具合に柔軟に対応できる

重要な機能から先に開発を行うため、システムとしてすぐに形に現れます。

また、ウォーターフォール開発と違い仕様変更や不具合が後から出てくる前提で進めるため、不測の事態にも柔軟に対応できます。

デメリット

• プロジェクト管理がしづらい

ここの機能を切り分けて小さく開発を進めるため、プロジェクトの全体像が見えにくいのがアジャイル開発の欠点です。

柔軟に対応できることはメリットですが、全体像が見えない中開発していると、結果としてスケジュールが伸びたり開発費用が膨れ上がったりするのが注意点です。

4. システム開発の工程での略語

5. ラボ型開発とは？システム開発との違いとは？

システム開発に関する詳細についてご紹介してきました。実際のビジネスでは、システム開発会社を見つけること自体が１つの障壁となるでしょう。以下では、システム開発会社との契約形態の１つであるラボ型開発について見ていきます。

ラボ型開発（ラボ契約）とは、ある一定期間(半年〜数年)の間、特定のエンジニアを確保し自身のプロジェクトを担当させる契約形態のことを指します。また、ラボ型開発はオフショア開発における契約形態のひとつでもあります。

オフショア開発とは？

オフショア開発とは、ソフトウェア開発やWebシステム開発、スマホアプリ開発などを海外の開発会社や海外子会社にアウトソースする手法のことを言います。近年では、人工知能開発やブロックチェーン開発などの最先端技術までもオフショア開発の対象となっています。オフショア開発に関する詳細は以下の記事にてご紹介しています。

関連記事：ベトナムオフショア開発を選ぶ理由

６.「ラボ型開発」のメリット

コストが安い

ラボ型開発で得られるコストメリットは、オフショア開発におけるコストメリットとほぼイコールです。プログラマの単価をみてみると、日本を1とした場合ベトナムでは1/4、ミャンマーは1/8といった費用で開発を委託することも可能です。技術面で日本人と比べて劣るといったこともありません。

関連記事：ベトナムオフショア開発の価格はいくら？他国との比較 

仕様変更や機能追加の際に見積り調整が不要

通常、請負契約の場合、初期開発が完了し、その後追加開発が発生した場合、その都度見積もりを調整して・・・ということが発生してきます。ラボ型開発（ラボ契約）の場合には、期間契約ですので、その期間中は契約のエンジニアチームを、言わば自由に管理することができます。

ノウハウを蓄積しやすく、優秀なエンジニアを常に確保できる

ラボ型開発（ラボ契約）では、中長期的に固定でチームを確保できるため、ノウハウが蓄積しやすく、優秀なエンジニアを常に確保できるといったメリットがあります。

ラボで契約したチームはその期間中、発注者の専属チームとなります。そのためノウハウを蓄積しやすく、またそのノウハウが溜まっていくほどに、開発スピードの向上も実感することができます。自社のメンバーと同じように、チームとしての結束力が徐々に上がっていくことや、開発スキームが次第に完成されていくことなども開発スピード向上に寄与するでしょう。

プロジェクト単位で人員調整でき、実際の雇用よりもリスクを抑えることができる

ラボ型開発（ラボ契約）の最後のメリットは、固定費である人件費を変動費にすることができることです。

通常、中長期でアプリやWebを利用したサービスや新規事業を開発する際は自社で人員を採用するのが良いでしょう。ただ、日本ではエンジニアが枯渇しているため採用がままならない上に、優秀な人材をいざ採用しようものなら相応の固定費がかかります。多くの人数をかけて一気に開発をするフェーズもあれば、それほど人数を必要としないフェーズもあるでしょう。

そこで、自社の人材と同じように管理ができ、でも半年や1年といった一定期間の契約なのでプロジェクト単位で人員、人件費を変動費として調整できるという点で、ラボ型開発がメリットを発揮します。

7. まとめ

今回は開発モデル毎に、システム開発の工程と流れをご紹介しました。

ウォーターフォール開発とアジャイル開発は主要なシステム開発工程であり、それぞれのメリット、デメリットを把握しておき、適したシステム開発工程を採用することが大切です。

今回ご紹介した情報が、開発会社とのコミュニケーションに役立つと幸いです。

無料見積もりはこちらから▶

※以下通り弊社の連絡先

アカウントマネージャー: トゥイ(日本語・英語対応可)

電話番号:　(+84)2462 900 388

メール:  konnichiwa@hachinet.jp

お電話でのご相談/お申し込み等、お気軽にご連絡くださいませ。

Tags

ご質問がある場合、またはハチネットに協力する場合
こちらに情報を残してください。折り返しご連絡いたします。