本記事は以下のような方を対象に書かれています。
- 「会社に配属されたばかりでITシステムの開発の流れが掴めず混乱している」
- 「スケジュール管理が苦手なのでITシステムの開発の流れを理解したい」
- 「数ヶ月や１年といった期間がかかるプロジェクトの開発見積もりが苦手」
そんな方でも本記事を読むことで、下記のようになれます。
- システム開発の基本的な流れを理解できる
- 各フェーズで何をすべきか事前に把握できる
- システム開発の見積もりができるようになる
何度か繰り返して読む事で自然と身につくので、システム開発の仕事をしながら復習すると自然と身につきます。
ITシステムの開発の流れとは？
基本的には、以下のような流れで開発します。
順番に見ていきましょう。
要件定義 – どんなモノを作るのか？
要件定義とは、簡単に言うとシステムの仕様をまとめる作業のことです。
「どのようなシステムを作りたいのか？」
「誰に需要があるシステムなのか？」
「どのような人に提供するのか？」
そして仕様をまとめることによって、「どんな機能が必要なのか？」が決まります。
- ユーザーの登録＆ログインする機能
- 宿を検索する機能
- 宿を予約する機能
- 決済する機能
- ････
どこまで詳しく決めるかはクライアントによって異なりますが、主にこの工程は、クライアントからの依頼されたシステムやサービスを作る時に重要になる作業です。
クライアントからの要望と全く異なるサービスを作ってしまうような事を避けるために、要件定義はしっかりします。
設計 – どのように作るのか？
要件定義がクライアントからの要求を元に実装する機能を決めていく作業なら、設計は実際にシステムを動かす部分の仕様を決定する工程です。
- 画面デザイン
- 画面遷移図
- API設計
- ネットワーク設計
- データベース設計
など具体的にどのような見た目、仕組みで動くのか決めていく作業になります。
最初に設計した内容から小さな変更はあるかもしれませんが、基本的には設計書に忠実に開発を勧めていきます。
開発 – 設計を元に作る
設計を元にプログラミングを組んでいき、開発するフェーズです。
設計が細かく決まっていればいるほど、このフェーズで考えることは少なく、迷ったりもしづらいです。
なので、基本的には設計を見ながら無心でプログラミングを組んでいくのがこのフェーズです。
ただ、どうしても当初の予定通りにいかない部分もあり、予想外な要因によって開発の予定を変更せざる負えない場合もあります。
- クライアントの都合で納期を早めなければならず、一部の機能を削る必要が出てきた時
- タクシーの配車アプリでGoogleMapの機能を使う予定が、予算の都合で使えなくなった場合
トラブルは絶対無いわけではないので、ここを臨機応変に対応できるかは経験次第と言えるでしょう。
仕事をこなした数が少ない場合、適切にトラブルの対処が出来ないのは当たり前なので経験豊富な方に相談するのが良いです。
テスト – 作ったモノの動作テスト
開発のフェーズで作ってきた機能のテストしていきます。
- 新規登録した時に案内用メールが送信されるかどうか？
- タクシーが配車されたタイミングで、管理会社へ通知メッセージが送信されるか？
- ユーザーの退会フォームを送信した時に、ユーザーのデータは削除されるか？
これらを機能ごとにテストしていき、問題なさそうだと確認できたらサービスを公開していきます。
サービスの公開 – 人に使ってもらう
サービスのアプリやWebサービスを公開します。
- サーバーへプログラムのリリース
- GoogleやYahooなどの検索エンジンに登録
- AppleストアやGooglePlayストアなどにアプリを登録
この時点で、不特定多数のユーザーの目にとまることになるので、事故らないように事前にバグ（不具合）などは直して完璧な状態にしておくのが基本です。
サービスの公開後のトラブルの例を少し紹介するとこんな感じになります。
- セキュリティが甘く、ユーザーの個人情報が盗み取れてしまう
- 課金したのにプレミアムユーザー用のサービスが使えない
- 膨大な宣伝費用を投じたのに不具合によってアプリが使えないためユーザーが離れる
会社にとっては大損害になるようなトラブルは絶対に避けなければなりません。
これはプログラミングの技術力の以前に大切なことです。
まとめ
- 「要件定義」はクライアントから、どのようなシステムを作りたいのか引き出すフェーズ
- 「設計」は実際に作るシステムの具体的な仕様をまとめるフェーズ
- 「開発」は「設計」で決められた仕様でシステムを作るフェーズ
- 「テスト」は「開発」で作成したシステムに不具合がないか、実際に動かして確認するフェーズ
- 「サービスの公開」はシステムを多くの方に使ってもらえるように公開するフェーズ
いかがだったでしょうか？
これらのフェーズはスケジュール管理をする上で最低限、必要な指標になるので抑えておきたいです。
ただ実際の現場では同じ「テスト」でも、もっと細かく「単体テスト」や「結合テスト」「ユーザー受け入れテスト」など分ける事の方が多いです。
もし、自分でスケジュール管理したり、システム開発の見積もりをする立場になった場合は、もう少し細かいフェーズも頭に入れたいところですね。
