今プログラムの勉強をしているけど実際業務ではどういうふうにシステムになっていくのかな？
自分でシステム開発したいけどどういう流れですればいいのかな？
そんな疑問をお持ちのあなたへ
今日はWebシステムをどうやって作って行ってるのか記事を書きたいと思います。
基本的に要望を受けたあとそのままプログラミングをすることはありません。
依頼者と開発物をすりあわせ、合意と取った後開発をはじめます。
そしてプログラムを書いた後もそのまま依頼者が使える状態にするのではなく、
きちんとプログラムが想定していた動きをしているかどうか確認する作業＝テストをします。
現場により工程の名前、順序は異なりますが大体今回説明をする工程を挟んでリリースすることとなります。
このページでは
自分でシステムを作ってみたいけど流れがわからない
今自分が学んでるプログラミングで就職するとどう仕事をするのか？将来何ができるのか？
そんなあなたの疑問をお答えします。
初学者が次何をすればいいかわからなくなった時もシステム開発の流れを理解しておけば自然と次学びたいことが浮かんでくるかなと思います。
一般的なシステム開発の工程と役割
まずは、一般的なシステム開発の工程と役割（誰が実施するか）を表で表しました。
| 工程 | 小工程 | 役割 |
| 企画 | 事業の人 | |
| 要求整理 | PM | |
| 要件定義 | PM | |
| 設計 | 外部設計 | ENG（上流） |
| 内部設計 | ENG（上流） | |
| 開発 | Programmer | |
| テスト | 単体テスト | Programmer |
| 結合テスト | ENG（上流）またはQAエンジニア | |
| シナリオテスト | ENG（上流）またはQAエンジニア | |
| 受け入れテスト | 事業の人 | |
| リリース準備 | リリース担当者 | |
| リリース | リリース担当者 | |
| 運用保守 | 保守担当者 |
役割の部分は、会社やチームにより一人の人が複数工程を担当したり、さらに細分化されていることもあります。
それでは各工程についてもうすこし細かく説明していきます
企画
企画のフェイズでは依頼者がこれをつくりたいと持って来ます。
要求整理
企画をみて開発工程にもっていきやすいように情報を整理します。
足りていない情報があれば企画者にヒアリングします。
また要望してきたものをすべて開発すると工数、予算とも膨大になってしまうことがあります。
優先順位、代替案等を依頼者と話し合い開発していくものを定めていきます。
要件定義
要求をもとに開発の進め方を決めていきます。
要求整理と似ていますが開発着手しやすいように、
システムの機能単位等にわけて何を作るかというのを書いていくことが多いです。
設計
要件定義をもとに、プログラムが書けるようにシステム視点でどうつくっていくか書いていきます。
外部設計 ・・・ 主にシステムの利用者に見える部分、WebサイトであればWebのUIを決めていきます。
内部設計 ・・・ 主にシステムの利用者から見えない部分、データの流れ方、各モジュールでの処理内容を決めていきます。
開発
設計をもとにプログラミングをして行きます。
テスト
単体テスト・・・書いたコードを用いてクラスやモジュール単位でテストをしていく
結合テスト・・・ 画面単位でテストをしていく
シナリオテスト ・・・ 複数画面を用いてユーザーの操作シナリオに合わせてテストしていく
受入テスト ・・・ 依頼者や利用者で依頼通りシステムができているか、運用上問題がないかを確認していく
各フェイズのテストをこなし設計やプログラムのミスを見つけ減らしていくことが求められます。
リリース
リリース準備・・・リリースのリハーサルやリリースの告知、手順書等を作成します。
リリース ・・・ 利用者がシステムを触れるように本番環境にデプロイします。
リリースには様々なリスクが伴います。
不具合時の対処方法も含めしっかり考慮し準備したうえでリリースに臨みます。
リリース情報の伝達ミスにより、依頼者ともめることは多々あります。
リリースする内容、スケジュール、リスクについては依頼者とも認識を合わせリリースすることが望ましいです。
PJの進め方、ウォーターフォールとアジャイル
PJを進めていく際に用いられる有名な手法が２つあります。
一つはウォーターフォールと呼ばれるものでもう一つはアジャイルと呼ばれるものです。
順に説明していきます。
ウォーターフォール
最初に作るものをかっちり決めてリリースまで一気にこなし進めていく。
メリット→最初に何をするかをかっちり決めるのでPJの進み度合いがわかりやすい
デメリット→一気に仕上がるので依頼者が出来上がりを見たときにギャップが生じやすい
PJ中さまざまな理由で仕様変更をしたい場合も対応が難しい
アジャイル
作るものを細分化し細かい機能単位に分けて、機能ごとに実装、テストを繰り返し作っていく。
メリット→細かい単位で開発していくのでつど仕様変更をすることが可能
細かい単位で依頼者側に出来上がりのギャップが生じにくいまたウォーターフォールより変更が容易な場合が多い
デメリット→依頼者の注文等による修正の工数をコントロールしていかないと工数が肥大化する。工数管理が少し複雑。
システム開発時の注意3点
ここではシステム開発時の注意点をお伝えします。
ポイントを抑えてシステム開発をしていくことによりトラブル少なくPJを終えることができます。
関係者とのすり合わせが大事
成果物のすり合わせ
システム開発では、
システムの依頼者と密に連携をとり意図したシステムが出来上がっているかどうか認識を合わせる必要があります。
またすり合わせたつもりでも、依頼者があまり理解できてなかったということもあります。
なるべくUIモック等を見せて依頼者が出来上がりを理解しやすい資料を用意します。
設計の着手前に関係者と合意を取りますが、
設計に入ってくると開発都合で修正が必要になってくることが多々あります。
修正が入る可能性が出てきた場合は都度関係者とすり合わせ、認識そごがないように努力する必要があります。
開発者にとっては小さな修正、でも依頼者にとっては大きな修正ということはよくあります。
スケジュールのすり合わせ
PJ遅延や追加リクエスト等によりPJのスケジュールに影響が出る可能性があります。
後々、リリース間近でスケジュール伸びますというのは心証が悪いです。
出る可能性がわかった段階で依頼者に報告しスケジュールを伸ばすか、機能を削減するか等話し合いましょう。
バッファを確保しよう
システム開発はエラーが長時間取れない、この機能はこう作ろうと思っていたのにうまくできないなど予期せぬことがよく起こります。
ただし依頼者は納期までにシステムが来ることを前提に他の作業に取り組んでいることもあります。
納期を遅れるというのは信頼関係から言っても大変好ましくありません。
なので、PJのスケジュールにバッファを持たせておく必要があります。
私はPJの難易度にもよりますが、全工数の20％程度をつけることが多いです。
バッファを持たないと、後半の工程に影響が出てテストを消化しないままリリースしないといけないことになりかねません。
よくテスト期間はバッファという言い方とする人がいますが、テスト期間に修正が入ったらその対応で一杯一杯です。
各工程にバッファをつけるか、PJとして最後にバッファをつけるかはPJの性質もよりますが必ずバッファを持たせてください。
バッファがあるとゆるくなっちゃう懸念はありますが、
余裕があるから〜ゆるくやろうと思わせないのはPMやリーダーの手腕かなと思っています。
テスト工程を重視しよう
上の項目でも書きましたが、テスト工程はPJの後半に当たることが多く、スケジュール的にもしんどい期間に当たることが多いです。
そのためスケジュールが押し、あらかじめ用意していたテスト期間を確保できず、テスト不十分なままリリースをするケースが見られます。
しかし、テスト不十分なままリリースをすると当然リリース後の不具合発生の確率が高くなります。
リリース後トラブルが起きると、トラブル調査、復旧作業、再修正、リリースなど多くの工数がかかるほか、
システムを使っている人からの信頼を勝ち取ることができません。
予期せぬことが起きてスケジュールに影響が出た場合は、あらかじめ確保していたバッファを使うほか、リリース日の見直し、リリース対象の変更等を行いテスト日数を確保した上でPJを進めていきましょう。
おわりに
システム開発を仕事として行うときはQCDの徹底（Quolity、Cost、Delivery）が求められ予算、期限内に一定の品質を確保して納品（リリース）する必要があります。
PJの各工程を理解し、進めていくことでより安定した品質の高いPJを遂行することができます。
ぜひ、個人で開発する際も、会社で開発する際もシステム開発の工程を意識してPJを進めて行ってもらえればと思います。
