1. システム開発の基本

1.1. 基本の開発工程

システム開発は以下のフローを用いて開発が行われる。

1. 企画
2. 計画(要件定義)
3. 設計
4. 実装
5. テスト
6. デプロイ(リリース)/保守運用

1.1.1. 企画

企画ではどのようなアプリやサービスを開発するか決める。

企画で考慮すべき内容は以下の通り。

• 基本内容

  • どんなアプリ/サービスを作るのか明確にする
  • それがどのような価値/役割を提供する(何を解決する)を大まかにまとめる

• その他

  • Webアプリ/ソフトウェア開発の場合
    • ペルソナ(クライアントやユーザ)像を明確にする
    • 類似アプリやサービスがあればそれに関して調査する場合もある
  • ゲーム系の場合
    • 類似ゲームや元ネタ(世界感の構成材料)に関する調査
    • デザイン(ビジュアル)のガイドライン的なものを決める
    • 提供する世界観(ゲームカラー)を決める

1.1.2. 計画(要件定義)

要件定義

要件定義は初めに以下の項目を行う。

• 実装する機能の整理
  • 機能要件(実装機能一覧)を整理する
  • 非機能要件(UX, 性能, 拡張性, セキュリティなど)を整理する
• 技術選定 ・・・ アプリ/サービスの構築のために必要な技術を調査
  • 開発人員のバックボーンやスキル/意欲も踏まえる
  • 実装したい機能や特性も踏まえる
  • 開発期間や技術の学習コストも踏まえる
  • 非機能要件(UX, 性能, 拡張性, セキュリティなど)も踏まえる
• システムの構成(アーキテクチャ設計)を行う
• 開発人員の体制
  • PM(プロジェクトマネージャー)を決める
  • 開発人員が複数いる場合は担当や役割などを決める
• タスクの管理体制の確立
  • 開発ワークフローに用いるgitリポジトリの決定
  • 開発に関するドキュメント(機能/DB/API/コーディング規則などの書類)の管理や参照フローの決定
  • 開発する際のコミニケーションやり取りを行うツール(discord, slackなど)の決定

一般的(組織やプロジェクトにおける)な全体における実装順序は以下の通り。(2,3は同時に進む場合もある)

1. インフラストラクチャの構築
2. バックエンド(APIサーバ)の機能実装
3. フロントエンドの機能実装

個人開発のWebアプリでは「バックエンド」=>「フロントエンド」=>「インフラストラクチャ」の開発が無難である。

1.1.3. 設計

基本設計(外部設計)

基本設計では実装機能のドキュメント的なものを作成します。

• フロント/バック共通
• 機能設計 … 機能や動作のリストアップ(機能一覧表など)
• 方式設計 … フロント/バックエンド(DB含む)/インフラごとの技術選定
• バックエンド
• データベース設計 … データベースのスキーマの設計(ER図, CRUD図など含む)
• API設計 … 機能一覧からAPI設計(API仕様書など)
• フロントエンド
• 画面設計 … ワイヤフレーム, 画面一覧, ディレクトリマップ, 画面遷移図等
• インフラストラクチャ
• アーキテクチャ設計 … アーキテクチャ図など

詳細設計(内部設計)

詳細設計とは、基本設計で決定した内容を基に、ユーザーからは見えないシステム内部の動作・機能を設計して、実際にプログラミングできる内容に詳しく落とし込む工程。(Web系の場合は基本設計に含めてしまうことが多い)

• モジュール設計 ・・・ Webアプリの機能実装に必要なモジュールの選定や分割を細かく設計します
• データ設計 ・・・ Webアプリのデータを保存するデータベースの選定・データ処理の流れ・データの保存場所などの細かい設計を行います
• プログラム設計 ・・・ 設計した内容を実装できるように、プログラミング可能なレベルまで詳しく設計します。具体的には、実装内容・手順をドキュメントに直した設計書の作成等を行います

1.1.4. 実装

設計が完了したあとは開発作業に入って実際にプログラミングを行い実装する。

Gitを用いたタスク管理

Gitを用いた分散型開発の場合は基本的に以下の繰り返しで開発を進める。

1. タスクごとにブランチを作成
2. 何らかの機能や改修を実装
3. 単体テストや結合テストを実装
4. github上でプルリクエスト作成
5. レビューを受け修正
6. マージ7. 1に戻る

1.1.5. テスト

設計された内容を取りこぼし無く実装出来ているのかをテストする。

開発中のアプリをどういった方法でテストするか、どんなテストツールを使用するかを決める。

具体的には入力値のバリテーションチェックや複数の機能のユニットを連結した動作のチェックなどが含まれる。

単体テスト(ユニットテスト)

実装されたコードが設計書に記載された通りにきちんと動くのか検証するテスト。 画面上に見える部分と裏側のデータ双方で、細かい部分の洗い出しが必要となる。

結合テスト(インターフェーステスト)

結合テストとは、モジュール間の結合状態などについて確認するテスト。

統合テスト

全てのモジュールを結合した最終テスト。

1.1.6. デプロイと保守/運営

デプロイ

構築されたインフラストラクチャへ開発したアプリをデプロイする。

個人開発の場合はインフラストラクチャの構築と学習はデプロイする場合に行うと良い。

保守/運営

保守運営を行う。

1.2. 作成すべき設計資料

また設計にあたって作成する文書や図は以下のようなものがある。

Web系で基本的に使いそうなものには○がついてある。他は作るアプリやサービスによる。

図・文書	説明	Web系
機能一覧表	開発する機能を一覧にまとめます。新規アプリケーション開発の場合は外部設計のベースとなります	○
業務フロー図	要件定義フェーズで確定していない場合は外部設計として作成します
画面設計書	ユーザーが操作する各画面の構成、及び画面遷移図を設計します	○
帳票設計書	帳簿、伝票などの出力項目、レイアウト、出力タイミングなどを設計します
インターフェース設計書	アプリケーションが外部とインターフェースする部分を設計します	△
データベース設計書	データを格納するテーブルを定義します。一般的にはER図を用います	○
外部ファイル設計書	入出力するファイルのフォーマットを定義します
ハードウェアインターフェース設計書	ハードウェアの制御方法を記載します
他アプリケーションとの関連図	他アプリケーションとの関連、接続方法を記載します
セキュリティ設計	要件定義のセキュリティ要件に対する具体的な対応内容を記載します	△

1.2.1. 画面設計に関する資料

これらはフロントエンド設計でほぼ必ず使うはず。

• ワイヤーフレーム(画面レイアウト) ・・・ webページのレイアウトを決める設計図
• 画面一覧表 ・・・ 各画面にどういう機能や文があるかをまとめて一覧にしたもの
• ディレクトリマップ ・・・ webサイトを構成するすべてのwebページの情報をまとめて、一覧にしたもの
• 画面遷移図(サイトマップ) ・・・ システムの画面遷移を図で表したもの

1.2.2. データベース設計に関する資料

バックエンド開発におけるDB周りでは必須。

• テーブル定義書 ・・・ テーブルを作成するための定義書(最悪ER図のみでもよい)
• ER図 ・・・ 実体と関係という概念を用いてデータ構造を図にしたもの
• CRUD図 ・・・ 「Create」「Read」「Update」「Delete」の操作がどのテーブルに対して行われているかを画面(機能やユースケース)ごとに記載したもの

1.3. ソフトウェア開発工程のモデル

ソフトウェアの開発モデルにはウォーターフォール、アジャイル、プロトタイプ、スパイラルがある。

1.3.1. ウォーターフォールモデル

ウォーターフォールは上流工程から計画にもとづいてそれぞれの段階を経て1つのシステムを完成させる開発工程。

多くのシステム会社ではウォーターフォール型でシステム開発を行なっている。

向いているのは以下の場合となる。

• 作りたいシステムが明確
• 変更の可能性がない業務システム開発
• 大規模開発

メリット

• スケジュール管理がしやすい
• 予算が組みやすい

デメリット

• リリースまで時間がかかる
• 仕様変更やトラブル対応に難しい

1.3.2. アジャイルモデル

アジャイルはアプリ/システム開発を小さな単位に分け、実装とテストを繰り返しながら開発を行う工程。

優先順位の高い機能から順に、「設計」「開発」「テスト」「リリース」を繰り返すことで、システムの機能を充実させていくのが特徴となる。 Web系企業で多く用いられている開発手法。

向いているのは以下の場合となる。

• 要件や仕様が細かく定まっていない場合
• 市場の動向や顧客の反応などによって、システムに変更や修正が生じる可能性が高い場合
• 短期間でサービスをローンチしたい場合

メリット

• 短期間でリリース可能
• 仕様変更や不具合に対応しやすい
• ユーザの要望に反映しやすい

デメリット

• 方向性がずれやすい
• スケジュール/進捗の管理がしづらい

1.3.3. スパイラルモデル

スパイラルは機能ごとに開発の小さなサイクルを繰り返し、完成後にリリースする開発手法。

向いているのは以下の場合となる。

• スピード感よりクオリティが求められる場合
• 最初に要件や仕様が詳しく定まらず、途中で仕様変更が生じる可能性が高い場合

メリット

• 仕様変更や修正に柔軟に対応できる
• クオリティの高いシステムを開発できる
• 手戻りを最小限に抑えられる

デメリット

• プロジェクト全体を把握しづらい
• 開発期間が長期化する恐れがある

1.3.4. プロトタイプモデル

プロトタイプは試作品を作り発注者のレビューを受けて修正する開発手法。

Web制作系やゲーム系企業で多く用いられている開発手法。

向いているのは以下の場合となる。

• これまでにないシステムの開発
• 小規模開発や中規模開発
• 発注者側が開発に慣れていない場合
• 欲しいシステムの明確なイメージがない場合

メリット

• 作りたいシステムが具体的でなくても開発を始められる
• 機能の追加や変更に柔軟に対応可能
• 大きな修正や手戻りを防ぐことが可能

デメリット

• プロトタイプ作成のための期間とコストがかかる
• 計画やコストの予測を立てづらい
• 当初の目的とは異なるシステムができてしまう場合がある

1.4. アジャイル開発

1.4.1. アジャイル開発とは

アジャイル開発はアプリ/システム開発を小さな単位に分け、実装とテストを繰り返しながら開発を行うもの。

アジャイル開発では技術選定やアーキテクチャ設計は初めの計画で行うと良い。 機能要件を洗いざらい書きだした後はマイルストーン(開発サイクル)ごとに実装する。

1.4.2. アジャイル開発の種類

スクラム

チーム単位で開発を行う手法。

メンバー各自の役割を決めるが、明確なタスクや工程の振り分けは行われない。 メンバー自身がそれぞれ計画を立て進めるため、メンバー全員で責任を共有する。

スクラムマスター(リーダ)が内部の調整やインシデント管理を行い、他メンバーにもそれぞれ役割（ロール）を設定して開発する。

チーム主体の開発手法のため、コミュニケーションが重視となる。 メンバーのスキルをそれぞれが把握することにより、臨機応変かつ効率的な開発を実現可能。

エクストリームプログラミング(XP)

要件や仕様の変更に対して柔軟に対応するための手法。

エンジニアがペアを組み、コーディングをお互いにサポートしながら作業を行うペアプログラミングが基本となる。 エラーや仕様変更に対応しやすい点が強み。 エンジニアのスキルに依存しやすい手法であるため、未熟なエンジニアの場合、開発の効率が大きく低下してしまう場合がある。

ユーザ機能駆動開発(FDD)

ユーザーの目線から価値のある機能を選定し、その機能を中心に開発する手法。

発注側(システムのクライアント)にヒアリングを行い、必要な機能を適切な計画で開発する。 また、機能ごとにチームを編成して開発を行う。

価値が高い機能を実装しやすい手法だが、計画段階から発注側との入念なコミュニケーションが必要となる。

ドメイン駆動開発(DDD)

ドメインモデルをもとにコミュニケーションを取りコードを書いて開発していく手法。

以下の原則を守るように進める。

• 顧客の課題を正しく理解する
• 業務の専門家とソフトウェアの専門家が協力しドメインモデルをつくる
• エンジニアである方もそうでない者も理解できる共通言語を使ってコミュニケーションを進める

ドメインモデル : アプリケーションが対象とする業務領域

1.4.3. アジャイルの開発哲学

リーンソフトウェア開発(LSD)

無駄を省いて品質の高い開発を行うことを重視する。

名前はリーン生産方式に由来。 以下の7つの原則に当てはまるもの。

適応的ソフトウェア開発(ASD)

継続的な仕様変化に適応することを重視する。 複雑なシステムや状況変化の激しい場合に適した開発哲学。