ということで、興味のあるかたは是非お読みください。
システム開発プロジェクトのプロセスとは
システム開発といっても、結局これだけ
システム開発の工程っていうと、いくつもの工程がならんで、Ｖ字になるとかＷ字になるとか、いやアジャイルだとかいろいろな話がでますが、結局システムというものをつくるプロジェクトです。
全部一緒で「やりたいこと決めて、どうつくるか決めて、つくって、テストする」。
プロセスっぽく書けば、こうなります。
やりたいことを明らかにする
つくる”もの”を決める
それぞれの”もの”をどう作るか考える
”もの”を作る
”もの”をテストする
”もの”を渡す
こういうことです。”もの”は、システムであり、それを実現するための個々の機能でもあります。
それをなんか難しい名前にしていますが、難しそうな専門用語にしたところで、実際には会社によってちがってたりします。
僕も複数のお客様といろいろなプロジェクトをやってきましたが。お客様によって呼び方がちがったりが普通にありました。
外部設計/内部設計という会社もあれば、概要設計/詳細設計といったり、お客様独自の呼び方があったりとバラバラです。
でも、やることは一緒です。
システム開発ってことで書くとこうなります。
（やりたいことを明らかにする）
企画構想
（つくる”もの”を決める）
要件定義
（それぞれの”もの”をどう作るか考える）
概要設計
詳細設計
ＰＧＭ設計
（”もの”を作る）
製作
（”もの”をテストする）
単体テスト
システムテスト
ユーザーテスト
（”もの”を渡す）
切替
運用
難しく考える必要はありません。
決めて、作って、テストして、渡す。
こうとらえると、システム開発も難しく考える必要がないことがわかります。
ウォータフォールというのは、作るものを全部決めてから、長い時間かけてつくって、はいっ！って渡すやりかた。
アジャイル開発というのは、少しずつ作るものを決めて、決めて、作って、テストして、渡す、を繰り返すやりかた。
それをまずは頭にいれてしまいます。
システム開発のプロセスに分けます
あんまり簡単にしすぎると、でも何をするのかって迷います。
いろいろな失敗を重ねた結果、こう分割したほうがうまくいくって分割されたのが、いまあるプロセスになっています。
それが、このようなプロセス。
企画構想
要件定義
概要設計
詳細設計
ＰＧＭ設計
製作・単体テスト
システムテスト
ユーザーテスト
切替・運用
限られた期間に目標を達成するためには、ゴールに到達するまでの段取りが重要になります。
目標を達成するためには、工程を分け、小さな目標をつみあげて最終ゴールを目指すほうがいい。
特にそれが、長い期間をかけて実施されるウォーターフォール（フェーズドアプローチ）であれば、特にそうです。
小さな目標をたてて、それに向かって積み上げていった方がいい、というのは、べつにシステム開発に限らず、他のビジネスだろうと、プライベートな目標だろうとかわらないと思います。
英語できるようになろう、まずは５００語レベルから、次は３０００語レベル、とかやりますよね。
それと一緒です。
あとは、どのようにわけるかということですが、システム開発の場合は、誰がやるかでプロセスがまず分かれています。
同じシステム開発会社が実施するにしても、それがお客様相手なのか、製作側のためにやっているか、という相手によって分けています。
つまり、お客様相手→製作者側→お客様相手、こういう順番になります。
ということで、お客様でやることきめて、製作して、お客様でテストする、つまりＶ字になるわけですね。
製作者側の開発も全体から段階的に詳細化されて、全体もどってくる「全体→部分→全体」となるので、これもＶ字ですね。
全体をこのように捉えてしてしまえば、システム開発の工程ややることも、例えお客様によってプロセスの名前がちがっていても応用がきくと思います。
この考え方は重要です。
というのも、プロジェクトにはいると、さまざまなお客様、ステークフォルダ（プロジェクトのキーマン）が発生するので、それに対応していく必要があるからです。
実際の利用者も、社内ユーザ、一般のお客様とわかれたります。
そうすると、ユーザテストも社内ユーザテスト、コンシューマ向けテスト、とわけてしまえばいいのです。
難しく考えずに、プロセスは、プロジェクトマネージャの裁量で決めてしまえばいいのです。
システム開発プロジェクトの工程
実施のプロセスについては、以下に書いておきます。
システム開発プロジェクトの実際のプロセス
企画構想
プロジェクトの目的・目標の定義
スコープの明確化
※ビジネス目標実現と予算承認、予算の明確化
要件定義
目的を実現するために業務として必要な機能（お客様目線）の定義
※要件定義書、機能一覧・説明
概要設計
システム構成、機能配置定義．定義された要件をシステムに実現する機能として定義
システム構成定義
詳細設計
概要設計で定義した機能の具体的な実現設計
詳細設計書
※機能配置、画面定義
PGM設計
詳細設計を具体的なプログラムとして実装するための設計
ＰＧＭ設計、クラス定義
実装・単体テスト
実装、設計通りの動作保証、テスト仕様書、ソースコード
テスト結果（エビデンス）
システムテスト
概要設計通りのシステム稼働保障、テスト仕様書、テスト結果
ユーザテスト、運用テスト
要件通りにシステムが動くかの確認
ユーザテスト仕様書
実際にそれで運用できるかの確認
切替・運用
ユーザﾞが利用可能な環境にシステムリリース、リリース後の継続利用保障
切替手順書、障害対応手順書
プロセスの歩き方（Ｖ字開発）
実際に、このプロセスは、下記のように流れます。
お客様が、企画・構想
「これからプロジェクトやるぞ！」
お客様が何をやりたいかを整理（お客様＋開発者側）、要件検討
「やりたいことは、これだ！」
お客様と開発側が実際のシステムでできることを確認、概要設計
「こんなものを、つくりますね！」
開発側が、どう作るかを決める、詳細設計
「こうやって作ろう」
開発側が、つくってテスト、製作・単体テスト、システムテスト
「つくったぞ、お客様の希望通りに動くかな？」
お客様側が、確認、ユーザテスト、運用テスト
「お願いした通りにできてるかな？、実際使えそうかな？」
最後に使えるように、切替・運用
「どうぞ！」
「ありがとうございます」
プロジェクトは、こんな風に、お客様と開発側が一緒になってシステムをつくるために動きます。
よく見るのが、こんなＶ字ですね。
開発を各プロセスに分割して、分割した工程ごとにしっかりと品質を確保していく、それがシステム開発では大切なことになります。
プロジェクトの工程も、難しくないものづくりの流れ、お客様と開発者側が一緒にタッグを組んで目標を達成するのが、システム開発のプロジェクト。
今回は、それが少しでもお伝えできていれば幸いです。
最後までお読みいただきありがとうございました。
