ソフトウェア開発タスクリスト

1. 要求分析

1.1 課題分析/整理

• 目的:
  • 現在抱える問題の整理/分析
  • 問題を解決可能なレベルに落とし込み
• 成果物:
  • 課題リスト
• NOTE:
  • 可能ならやっておくとよい

1.2 目標設定

• 目的:
  • 整理された課題を解決する為に何を行うかを決定する
  • 何を、どのように、いつまでに実現するか

1.3 ペルソナ定義

• どのような人が利用するのか、利用者イメージ
• 必要に応じて行うが、あまりやらない（往々にして自明である為、言語化する意味がなかったりする）

1.4 UIプロトタイプ作成

• 可能であれば作成
• 手書きやExcelにお絵描きでも可

1.5 アウトプット定義

• 目的:
  • プロジェクト全体の成果物の定義
• 成果物:
  • 成果物の一覧リスト
• NOTE:
  • 揉めそうな相手と仕事をする時は作る
  • 必要なさそうなら作らなくてもよい

2. 開発チーム立ち上げ

2.1 プロジェクト計画書作成

• 目的:
  • 開発のざっくりした計画を策定し、ドキュメント化する
  • キックオフミーティングで使用するようなやつ
• NOTE:
  • プロジェクト憲章、インセプションデッキと概ね同義
  • 好みに応じて呼称を決めればよい

2.2 マスタースケジュール作成

• 目的:
  • 概算のスケジュールを立てる
• 注意
  • このスケジュール自体はあくまで概算
  • 詳細がはっきりする毎に変化するものとする
  • 期日が固定の場合はリリース内容が変化することも合意しておく必要あり

2.3 キックオフミーティング

• 開発に関係する人間全員を集めたキックオフミーティング

3. 要件定義

3.1 技術選定

• プロジェクトで使用する技術の選定
• クラウドサービス、プログラミング言語、フレームワーク、DB、etc

3.2 アーキテクチャ設計

• システムアーキテクチャの決定
• アプリケーション・アーキテクチャの決定
• NOTE:
  • 大抵はフレームワークやクラウドサービスに依存する
  • 目標設定フェーズで大枠の方向性が決まっていることが多いので、その詳細化がメイン
  • アーキテクチャ設計は以降のフェーズでも随時修正が加えられていくことになることに注意（作りっぱなしではいけない）

3.3 機能要件整理

• システムが備えるべき機能の整理
• エンドユーザー側だけでなく、運用/管理、バッチ処理なども網羅する

3.4 非機能要件整理

• システムが備えるべき非機能要件の整理
• システム停止時間、メンテナンス時間、応答速度etc...

3.5 運用要件検討

• システム運用時に発生するタスクの検討

3.6 UIデザイン

• どのような見た目をしているか
• デザイナーにおまかせ

3.7 ユーザーシナリオ（ユースケース）作成

• ユーザーシナリオ/ユースケース
  • 呼び名はどっちでもいい
• ユーザーの利用シーンを網羅
• ある程度洗い出せたら優先度を付けて分類

3.8 外部システム連携検討

• 外部システムとデータ連携の必要性を整理
• 必要であれば、インターフェイス、タイミング、データ形式、失敗時のリトライ手順などを調査

3.9 システム構成検討

• システム構成図を作成

3.10 ビジネスルール抽出

• ビジネスルールのリストを作成
• 可能ならテストケースも作成するべき

3.11 データモデル作成

• DBのテーブル構造を検討

4. アプリケーション設計

4.1 機能設計

• 必要に応じてArchitecture Decision Records的なドキュメントを残す
• NOTE:
  • ユースケースの実装ではあまり必要ない
  • 認証/認可、特定のライブラリに依存するなど、後日の修正に必要な情報を残す

4.2 DB設計

• 要件定義フェーズで大体終わってるはず

4.3 外部システムI/F設計

• 必要に応じて実施する
• 作成するシステムがAPIである場合、どのようなクライアントから呼び出されるのか、呼び出し方式は何か、入出力フォーマットは何かなどが重要になる

4.4 データ移行設計

• データ移行が発生する場合、移行データの整理、変換処理の必要性、新DBの構造などが検討される

5. 実装

5.1 プログラム設計

• 目的:
  • プログラムの入出力、構造を検討する
• NOTE:
  • 基本的にソースコードが成果物となるのでドキュメントを作成する必要はない
  • 特筆すべき事項があればADRに追加してもよい

5.2 コーディング

• プロダクトコードとテストコードを実装する

5.3 ユニットテスト

• CIサーバで実行されるようにしておく

5.4 デバッグ

• T/O

5.5 コードレビュー

• コード品質、設計品質を担保する

5.6 結合テスト

• ステージング環境で動作させ、一通りの動作に問題がないことを確認する
• 結合試験はブラックボックステスト、ユニットテストはホワイトボックステスト
• 完了基準を事前に定めておく必要がある

6. テスト

6.1 テスト計画策定

• どのようなテストをどこまで実施するかを検討
• 最低限やること、可能な限りやること、余力があればやることに分類する

6.2 システムテスト

• 実運用時の状態に限りなく近い状態でテストを行う
• ステージング環境、または専用のテスト環境であることが望ましい
• データも匿名化した本番環境のデータを流用できることが望ましい

6.3 ストレステスト

• 負荷試験とも
• システムが設計時に想定した通りの同時処理を捌けることを確認する
• 高負荷時の挙動も検証

6.4 パフォーマンステスト

• システムが想定通りの処理件数を捌けることを確認する

6.5 回帰テスト

• 主に改修時に行う
• 既存の機能に影響が出ていないことを検証する

7. リリース

7.1 リリース計画策定

• システム停止を伴う、あるいは何らかのリスクを伴うリリースの場合は切り戻し手段含めて検討が必要
• 特にリスクのないリリースはガンガンやればいいのでは

7.2 リリース・チェックリスト作成

7.3 本番環境更新

8. 保守

• TBD