こんにちは！
最近、お客様やパートナーより、
「システム開発をお願いしたいけど、どのように進めていけばいいの？」
というケースが増えてきました。
そこで、今回は、一般的なシステム開発の進め方と当社の工夫についてお伝えします。
一般的なシステム開発の進め方（ウォーターフォールモデル）
まず最初に、一般的なシステム開発の進め方を解説したいと思います。
規模の大小によって異なるものの、一般的にはウォーターフォールモデルと言われる開発プロセスに沿って進められることが多いです。
ウォーターフォールモデルは、おおまかにわけると、各工程ごとに以下の様になります。
- 基本契約書締結
- 要求定義
- 要件定義
- 設計～テスト
- 受入テスト
- リリース
- 運用・保守
では、具体的にどのようなことをするのでしょうか？また、お客様（発注側）の立場になった場合、どのような作業やアウトプットが必要になるのでしょうか？
各工程をフェーズごとにまとめて解説していきます。
要件定義フェーズ
要件定義フェーズでは、いわゆるシステムに求められる要件を洗い出す工程になります。
開発規模にもよりますが、要件定義フェーズはその後の工程と大きく性質が異なりますので、契約形態やお見積りが分かれるケースが一般的です。
基本契約書締結
システムの企画立案が進むと、まず最初に行うのは、「基本契約書」の締結になります。
システム開発の各工程を進めていく際は、フェーズによって見積や契約形態が分かれることがありますので、予め各工程共通の基本契約書を作成し、締結します。
★お客様が必要な作業、アウトプット
・基本契約書の法務チェック
要求定義
次に行うのは、お客様が求めるシステムへの要求をまとめる作業になります。
ここでは、開発を行うシステムに対してお客様のビジネスで何が必要か？や、ビジネスモデルをベースに各オペレーションをどうしたいか？を言語化、可視化していきます。
★お客様が必要な作業、アウトプット
・お客様がシステム上で実現したいビジネスモデルと、それに関連する情報
・お客様がシステム上で行いたいオペレーション（運用）と、それに関連する情報
要件定義
要件定義は、お客様との要求定義をもとに、システムに何が必要なのかをまとめる工程になります。
一般的には、
- システム上で必要な機能（画面、バッチ等の入出力処理）の定義
- システムの利用を前提とした処理フロー
- システムに必要とされる処理性能
- システムに必要とされる技術情報（アーキテクチャ）
といった情報をまとめ、要件定義書を成果物として提示します。
★お客様が必要な作業、アウトプット
・処理フローの確認作業、問題点や懸念点の洗い出しとフィードバック
開発フェーズ
要件定義フェーズで、システムの開発範囲（スコープ）が明確になりましたら、開発フェーズに進みます。
開発フェーズは、主にプログラミングやネットワークの構築を行って、実際にシステムを組み立てていく工程となります。
設計（外部設計、内部設計、デザイン）
設計工程では、主に２種類の作業を行います。
- 外部設計（基本設計）
外部設計は、要件定義の内容をもとに画面や帳票などのユーザーインターフェースを設計する工程です。利用者から見て、システムがどのように振る舞うべきか、操作する画面のレイアウト（入出力フォーム）や操作方法、帳票類の書式、データを入出力するデータベースの構造などを決めていきます。 - 内部設計（詳細設計）
内部設計は、全体の構成や行うべき処理の詳細など、実装に必要な仕様を定義します。外部設計を元に具体的な処理フローやプログラムの実装設計、ネットワークの設計を行います。 - デザイン
外部設計をベースに、画面のデザインを作成します。
ワイヤーフレームというデザインラフを作成し、フォントや色等といったデザイン要素を具現化していきます。
★お客様が必要な作業、アウトプット
・外部設計やデザインの確認作業、問題点や懸念点の洗い出しとフィードバック
プログラミング～テスト実施
プログラミング以降の工程では、設計情報をもとに実際にプログラミングやネットワーク構築を行います。
開発環境によっては、お客様からもご覧になれますので、画面等を操作しながら改善点等を洗い出すことができます。
この工程で要件や設計の変更をご要望される場合、修正の影響が少ない場合を除いて、次フェーズ以降の工程や保守フェーズで対応する形になります。
★お客様が必要な作業、アウトプット
なし
受入（運用）テスト
開発会社側でテスト工程が終わったら、最後は受入テストになります。
受入テストでは、お客様側で実際に運用して問題ないか？をチェックしていただく工程となります。
受入テストで運用上問題が発生した場合は、前の工程同様に修正の影響が少ない場合を除いて、次フェーズ以降の工程や保守フェーズで対応する形になります。
受入テストが終われば、無事リリースとなります。
★お客様が必要な作業、アウトプット
・運用を想定したテストデータの準備
・システムに必要なコンテンツ（画像、テキスト）
従来の開発プロセス（ウォーターフォールモデル）の問題点と、アジャイル開発
従来の開発プロセス（ウォーターフォールモデル）では、工程が進むほど以下の様な問題点が発生します。
- 開発範囲（スコープ）が大きいほど、ビジネスモデルの変化に対して変更が難しくなる
- 手戻り作業が発生すると、大幅にコスト（工数、費用）が増える
- 下流工程になればなるほど手戻りが深刻になる
- 修正要件が増えると、品質低下を招く可能性が高い
上記は、昨今の実際の開発現場でも頻発しており、現場のSE（システムエンジニア）を悩ませています。
最近では、ウォーターフォールモデルの問題点を解消すべく、アジャイルという開発手法をとるシステム開発会社も増えてきています。
アジャイル開発は、端的に言えばウォーターフォールを細切れにしたものです。
できるだけ開発範囲（スコープ）を小さくして、ビジネスの変化に可能な限り対応しようという狙いがあります。
当社の取り組み、工夫
当社もまた、従来のウォーターフォールモデルではなく、アジャイルといった開発手法をベースにしています。
ただし、アジャイル開発にも以下の様な問題点があります。
- 要求定義があいまいなまま開発が進む
- 全体の進捗状況やスケジュールの把握が困難な点
そこで、当社では、以下の様な取り組みを行っています。
システムを成長させるロードマップ（道筋）の作成
システム開発の初期段階で、システムをとりまくビジネス環境を十分に把握しないまま開発を進めてしまうと、システムの全体像や目的があいまいのまま工程が進んでしまいます。
場合によっては、お客様のご要望を十分にかなえられないケースも出てきます。
そこで、当社では、システム開発の初期フェーズにおいて、システム開発のロードマップを作成し、システムの将来像をお客様と共有するようにしております。
開発する範囲（スコープ）はできるだけ細かくする
当社は、初期フェーズの要件定義の後に進める開発範囲（スコープ）をできるだけ細分化し、開発途中における要件や設計の変更に対して柔軟に対応しやすい体制を組むようにしております。
昨今、お客様のビジネスを取り巻く環境は、以前にも増してよりスピーディに変わっておりますので、そういった環境の変化にいち早く対応できるシステム開発を心掛けております。
プロトタイプ（試作品）の開発
さらに、要求～要件定義の中で、実際に画面や操作イメージがわきやすいプロトタイプ（試作品）の開発を、可能な限り行うようにしています。
- 認識のすり合わせをしやすい
- ユーザのニーズを満たすシステムを開発しやすい
といったメリットがあります。
「システム開発のゴールは、どんなイメージなんだろうか？」
「システム開発に要した費用を、本当に回収できるのだろうか？」
「システム開発の途中で、ビジネス環境が変わったときに柔軟に対応できるのだろうか？」
といったご懸念点を解消することが可能になります。
最後に
このように、システム開発は、非常に工程が多く長い道のりに思えるかもしれません。開発の現場では、システムを取り巻くビジネス環境を十分に理解せず、失敗している開発プロジェクトが多いのもまた事実です。
当社は、このようなプロジェクトの反省を踏まえ、
システム開発だけでなく、ビジネスパートナーとして想いを一緒にカタチにする
ことを最重要視しております。
もし、システム開発をご要望の方は、ぜひお気軽にご相談ください。
