システム開発におけるプロセスとは？システム開発を依頼する前に知っておくべきこと
- はじめに
- システム開発における主な開発手法
- システム開発におけるプロセスとは
はじめに
この記事は、これからシステム開発を検討しており、システム開発会社に依頼しようと考えている企業の方に読んでいただくことを想定し記載しております。
以下の記事と合わせて読んで頂くとより理解が深まるかと思います。
RFPとは？システム開発を開発会社に依頼する際に準備すべきこと
→https://rikesta.com/cms/system_column/what-is-rfp/
RFPを実際に記載する際に抑えるポイントや注意点
→https://rikesta.com/cms/system_column/rfp_point/
システム開発における主な開発手法
システム開発のプロセスといっても、１つではありません。
それは開発手法によっても変わりますので、まずは主な開発手法を解説します。
（これ以外の開発手法もありますが、まずは主なものの紹介に留めています。）
ウォーターフォールモデル
一番歴史があり、業務システム開発において最も適用されることが多いモデルとなります。
この記事では今後主にウォーターフォールモデルにおける開発プロセスを解説していきます。
アジャイル開発モデル
計画→設計→実装（製造）→テストを繰り返し、品質を上げて行ったり方針を微調整しながら進める方法になります。
外部要因によって方針が変わりやすい外部向けのWEBサービスであったり、業務システムであっても不確定要素がありつつも早く進めていきたい場合に採用される場合があります。
プロトタイプ開発モデル
最小の規模を計画し、設計開発を経てリリースします。
まずは出来るだけ短期間・低予算で作り評価したい、という場合に有効です。プロトタイプで開発したものを拡張し機能追加して使っていく場合もあれば、一度捨てて一から作り直した良いという場合もあります。
以下の記事も参考にしてください。
プロトタイプとは？その他にも類似したシステム開発や関連用語を徹底解説！→https://rikesta.com/cms/system_column/what_is_prototype/
システム開発におけるプロセスとは
主な開発手法を紹介したところでここから本題のシステム開発のプロセスを解説します。
開発手法によってプロセス・工程ももちろん違うのですが、大枠は変わりません。
また、想定読者であるシステム開発の依頼を検討するフェーズにおいてもやることにほとんど差はありません。
プロセス１：コンセプト設計
まずはなぜシステム化プロジェクトの検討がはじまったのか？
類似システムがあれば差別化のポイントは何なのか？
業務システムであれば、パッケージの導入ではなぜダメだったのか？
重要な要素は何なのか？スケジュールか？予算か？品質は高い方が良いと考えるのが当然だが、どこまで品質を求めるか？
スケジュール・予算・品質はまとめてQCD（Quality,Cost,Delivery）とも言われますが、これらの優先順位をつけておくことはシステム開発の提案を受ける段階でも、プロジェクト進行中に予期しない自体が発生した場合にも役に立ちます。
また、依頼者側のプロジェクト体制も明確にしておいた方が良いです。誰が責任者なのかも分からないプロジェクトでは期限も守られず、ずるずると予算と時間が消化され続けることにもなりかねません。
ここで検討したことをまとめる作業がRFPの作成です。
ここまでは基本的にはシステム開発会社に依頼する以前に行っておくべきことです。
ここがぶれているプロジェクトの場合、システム開発会社からするとリスクがあるプロジェクトとなり、対応してくれる会社が少なかったり、見積もりが高くなったりする可能性が高くなります。
RFP作成のポイントについては別記事を参照ください。
プロセス２：要件定義
システム開発プロジェクトが開始されてから大体はじめに行う工程です。
RFPに記載されているプロジェクトの課題・要求をどのように解決するかを検討していきます。
大まかには以下のものが記載されると良いかと思います。
１．プロジェクトのゴール、達成したい事の定義
２．システムの利用者の定義
３．（業務システムの場合）現状の業務フローとシステム導入後の業務フロー
４．機能一覧・機能概要
５．用語の定義
６．データモデル
７．非機能要件（性能や品質、想定稼働率など）
プロセス３：設計（基本設計、外部設計、内部設計）
ここで依頼者が意識していくべき点は外部設計、画面の設計部分です。
要件定義フェーズの機能一覧・機能概要では、「どんな機能があれば良い」程度の話で、具体的な画面イメージは含まれない場合が多いです。（簡単な画面モックは提示されるかもしれません）
実際に画面設計を開発会社から見せてもらうことで、はじめてイメージがつき始めるという依頼者も多いと思いますので、ここの工程で画面設計のレビューを行う事は非常に重要です。
また、この工程でデータベース設計やAPI設計というものも行われることになり、これらは今後のシステムの拡張性に大きく関わります。
依頼者側にある程度システムについて分かる人がいる場合、このあたりもレビューできると安心かとは思いますが、これらを理解するにはエンジニア的な人材が社内にいなければなりません。
プロセス３：開発〜テスト
開発とテストは別々のプロセスですが、依頼者からは分かりにくいため割愛して１つにしています。
設計フェーズが終わって開発フェーズに入ると、今まで頻繁に依頼者と開発会社でミーティングを行っていた頻度が減る場合が多くなります。開発会社からすると、開発をするための材料が一通り揃うのが設計フェーズの終わりで、開発フェーズに入ったらあとは作る作業がほとんどになります。
ただ、システム移行プロジェクトなどの場合、このあたりの工程で同時進行で既存システムのデータ移行設計を行ったりする場合もあるかもしれません。
その場合は、既存システムに対する調査を別チームで行ったりで、継続して依頼者と開発会社間でコミュニケーションが発生しているかもしれません。
プロセス４：外部結合テスト〜総合テスト
ここのプロセスの前提は、開発〜テストフェーズで一通りの開発が終わっていることが前提です。
外部結合テストとは、今回開発しているシステムと連携する他のシステムとをはじめて連携してテストすることです。
開発したシステムの開発会社と、別のシステムの開発/保守をしている開発会社を依頼者が調整し、テストをしてもらう必要があります。
外部結合テストが必要なシステムの開発は、それがないものと比べ工数は多くなりがちです。
それが終了したらあとは総合テストとして、実際の業務に即して一通りの機能をテストします。
本番に近いデータやインフラを使ってテストを行います。
プロセス５：受入テスト（ユーザテスト）
利用者側のテストです。ユーザを限定して使ってみたり、既存システムと同時進行で使ったりで、ケースバイケースになるかと思います。
システム移行の場合、この期間中にリリースリハーサルなどを行う場合もあります。
プロセス６：システムリリース
総合テスト・受入テスト、またリリースリハーサルを経てリリース作業を行います。
新規システムのリリースはアクセス制限の解除やデータのリセットを行うのみで簡単にリリース出来る場合もありますが、システム移行の場合は難易度が高く、失敗して切り戻し（リリース前の状況に戻す）になることもあります。
