はじめに

Udemyで「手を動かして学ぶITプロジェクト（講座名省略）」を受講したので、本記事でその内容をまとめます
- 受講講座：https://www.udemy.com/course/it-yugtl/
この講座を受講することで分かること
- プロジェクトを進める上で、「いつまでに」「何を決めなければいけないか」についての考え方
受講した内容が実務でどのように活きるか
- どんなプロジェクトでも対応できる開発技術が身につく
- プロジェクトの全体像（いつ、何を決めないといけないのか）が分かり、自信を持ってプロジェクトを進めることができる
- 決めなければいけない内容を明記した資料を作成できる

ITプロジェクトの流れと検討内容

※講座から画像を抜粋

一般的なITプロジェクトの流れは上図のようになっており、各フェーズごとで検討すべき内容がある
- ※開発フェーズはプログラミング技術やインフラ技術に関する内容であり講座の範囲対象外のため、本記事での記載はなし
以降で各フェーズごとに決めるべき内容や資料に落とし込む観点を記載
- 以降は講座内で例として解説されている「業務課題を解消するためのシステムの導入」に沿って、検討すべき内容を記載

プロジェクト計画

プロジェクトを始める前に計画書を作成する
解決したい課題を決め、プロジェクトのゴールを設定し、ゴールに向かうためのマイルストンを決めるフェーズ
プロジェクト計画の目的はプロジェクトの必要性を説明し、関係者を巻き込むこと
- 決裁権を持った人に、計画書を持っていき予算を取ってもらう
- 関係部署に計画書を見せて協力を募る
プロジェクト計画書には型がある。型に沿って計画書を作成する
- 下記のような順番で考えていくことが重要
  - 解決する課題とプロジェクトの目的を決める
  - プロジェクトの責任範囲を決める
  - ソリューションを決める
  - プロジェクトのマイルストンを決める
  - 成果物を決める
  - チームと責任者を決める
  - プロジェクトのルールを決める

解決する課題とプロジェクトの目的（ゴール）を決める

プロジェクトが終わったときに、どんな状態になっている必要があるかを明確にする

プロジェクトの責任範囲を決める

責任範囲を明確にしておかないと後になって収集がつかない事態になる可能性がある
- 大きな会社であればコントロールできる範囲が変わる
- コントロールの範囲内でプロジェクトを進めていくのか、コントロール範囲外（他部署）の協力を募るのか

ソリューションを決める

読み手が解決したいと思う内容になっていること
ソリューションを通して、なぜ課題を解決できるかが明記されていること

プロジェクトのマイルストンを決める

フェーズの開始日と完了日を明記すること
- 要件定義：1月〜2月
- 設計：3月
行われなかったらプロジェクトが丸ごとひっくり返るようなインパクトを持つチェックポイントを洗い出すこと
- 仕様確定
- システムリリース

成果物を決める

マイルストンで設定したフェーズごとに、どんなタスクがあるか、そしてどんな成果物を作るのかを定義する

チームと責任者を決める

下記の内容が確認できるプロジェクトの体制図を作成する必要がある
- どんなチームがあるか
- それぞれのチームがどんな役割を担っているか
- チームの責任者は誰か

プロジェクトのルールを決める

進捗管理方針、課題管理方針を決めることが重要
- 進捗管理方針
  - いつ、何の打ち合わせをするかを決めておく
  - 進捗会やリーダー陣MTGの頻度、参加者、議題を確認する。
- 課題管理方針
  - 何か課題が発生した際にどうするかを決めておく
    - 進捗会で課題共有 → 進捗会で解決できない場合はリーダー陣MTG等の課題をエスカレーションする基準を決めておくことが重要
  - 決めておかないと、いつまでもチーム内で難しい課題を抱えてしまったり、何でも上に課題が上がってしまい自分で考えろという状況になったりするケースがある

要件定義

今の業務がどうなっているかを分析して、新しい業務がどうなるべきなのかを決め、その業務を実現するための機能を考えるフェーズ
要件定義の目的は「何を作るのか？」を定め、開発にかかるコストを算出すること
- 要件定義が終わるとタスクの細かい一覧ができて、1つ1つのタスクにかかる時間を見積もることができる
- 要件定義をしっかり行い正確な見積もりが出せれば、要件定義以降のフェーズもうまくいく
要件定義で決めないといけないことの基本的な流れ
- 現在の業務と新しい業務を整理する
- システム化する機能を決める
- システム構成を決める
- 外部との連携タイミングを洗い出す
- データ構造を決める
- 画面構成を決める
- 非機能要件を決める
- 調達するものを洗い出す
  - この基本的な流れを元に不要なものを取り除いたり、必要なものを加えたりすることが重要

現在の業務と新しい業務を整理する

現在の業務と新しい業務を整理し対比を行うことで、「どんなふうに業務が新しくなるか」を可視化することができる
- 可視化するために、業務フローと業務要件一覧を作成する。
- 業務フローと業務要件一覧を組み合わせて、業務がどうなっていて、どういう風に変えたいかを整理する
  - 業務フロー（現在）
    - 業務マニュアルを読んだり、現場の担当者にヒアリングを行いながら業務のフローチャートを作成し、何が課題かを明確にする
  - 業務フロー（将来）
    - 現在の業務フローで課題が明確になったら、課題を解決するための業務フローとはどんなものかを定義する
  - 業務要件一覧
    - 業務フローで可視化した業務の業務詳細を記述し一覧化する
    - 業務フローで可視化した業務の概要や担当を、現在と将来でそれぞれ書き出す

システム化する機能を決める

新しい業務を推進するためにどんな機能が必要なのかを洗い出す
業務フローと業務要件一覧を確認しながら、機能要件一覧を作成する
機能要件一覧が完成したら業務要件一覧に、その業務の課題解消を実現するために使用する機能を書く

システム構成を決める

機能要件一覧で書き出した機能を、どんなシステムで実現するのか、どんなシステムが必要なのかを洗い出す
- ゼロからプログラムを書いて作るのか、クラウドサービスを当てはめるのか
上記の内容が決まったら、機能配置図やシステム構成図を作成する

外部システムとの連携タイミングを洗い出す

外部システムとどんな連携が発生するのかを洗い出す
- どんな情報を接続しないといけないのかを洗い出す
必要に応じて、下記のポイントおさえたIF一覧を作成する
- どのシステムと接続しないといけないか
  - 既存のシステムとのデータ連携することを考慮する
  - 書き出したシステムの担当者とやりとりをするため、漏れがないようにシステムを洗い出す
- ネットワーク
  - どういうプロトコルで繋いでいくか
  - データ形式は何か
  - 相手側のシステムで準備する内容が変わるため決めておく必要がある
- 連携のタイミング
  - 1時間に1回なのか、1日に1回なのか

データ構造を決める

機能配置図で定義したデータがどんな関係でつながっているかを書き出す
テーブル一覧とER図を作成する
- テーブル一覧：使用するテーブルデータをまとめる
- ER図：テーブル同士の関係を図で表したもの

画面構成を決める

システムにはどんな画面があって、その画面がどのように行き来できるかを表すための図を作成する

非機能の要件を決める

裏側の仕組みを検討することが重要
- セキュリティ
- ネットワークをどうやって繋ぐか
- 画面を表示させるスピード
情報処理推進機構IPAが用意している非機能要求グレードと呼ばれるフレームワークを使用するとよい
- https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
- このフレームワークに非機能の要件として検討しないといけないことが記載されている

調達するものを洗い出す

ここまでの要件定義で明確にした「どんなものを作るのか」ということを踏まえ、調達しないといけないものを洗い出す
- サーバーが何台必要か
- クラウドサービスの何のプランを契約するか

設計

要件定義で考えた機能をどうやって実現していくかを定義するフェーズ
- 「どうやって作るのか？」を定め、「手を動かせば完成する」インプットを揃える
ユーザーと話し合わないと決まらないものを洗い出しておく
- 画面/処理設計であれば、画面に何の項目を表示させるか、レイアウト（画面項目の順番）、どこにボタンを配置するか等

IF項目定義書

要件定義で作成したIF一覧にプラスして決めなければいけないことを定義する
- httpの場合のAPIの場合、どんなURLで連携するか等
どんなインターフェースでも必要なのは項目の定義
- リクエストボディの項目名、属性、桁数等

テーブル項目定義書

要件定義で作成したテーブルに、どんなデータ項目を管理するのかを定義する
テーブル定義書で一般に定義するもの
- テーブル名
- 項目名（和名/項目名）
- キー
- インデックス
- データ型
- 桁数

画面項目定義書

要件定義で作成した機能要件一覧の中で画面に関連するものの項目を定義する
定義内容は画面名、遷移元、遷移先、画面イメージ、表示する画面項目、処理
- 遷移元と遷移先を書くことで、将来画面改修をする際の影響範囲として前後の画面を調査する上で役立つ

処理概要定義書

機能要件一覧で新たに追加する機能の処理詳細を定義する。
- 処理概要定義書にはプログラムの内容を日本語で記述するイメージ

コード定義書

システムの中で使うコードとその意味をまとめて定義する
- プログラムや本物のデータを見て、コード値があったときに、そのコード値をすぐ確認できるようにする

環境設定定義書

インフラの設計を定義しておく定義書
- クラウドサービス（AWS等）の設定項目と設定値を定義する

テスト

作ったものが仕様通りできているかということを確認するフェーズ
- 出来上がったシステムに対して、どのテスト実施し、そのテストをOKとする条件は何なのかを考えるフェーズ
定義する項目はプロジェクトによるが、必須となる項目は以下の通り
- テストスコープを決める（それぞれのテストフェーズでどこをテストするか）
- テストの開始条件と完了条件を決める
- テストスケジュール
- テスト実行時のトラブル（障害管理プロセス）
- テスト実施体制
- テスト期間中の情報連携

テストスコープを決める（それぞれのテストフェーズでどこをテストするか）

単体テスト：機能一覧に定義した機能1行1行の単位で設計通りに実装されているかを確認
結合テスト：主にインターフェースを確認。インターフェースのインになっている機能とアウトになっている機能が整合性の取れた設計になっているかを確認
総合テスト：外部システムを含めた業務全体を見たときに、もともと計画していた業務（機能）が行えるようになっているかを確認

テストの開始条件と完了条件を決める

開始条件（何ができたらテストを開始できるのか）
- 開発がちゃんと全部終わっている状態、前のテストが完了している状態
完了条件（何をもってテスト完了とするのか）
- 前のテストで発見されるべき不具合が発見されない状態

テストスケジュール

いつからいつまで何のテストを行うかを決め、スケジュール通り実行するためのマイルストンの設定を行う

テスト実行時のトラブル（障害管理プロセス）

システムの不具合があったときに、どういう順序でエスカレーションしていくのか、どういうときにエスカレーションするかを明確にする

テスト実施体制

チームのリーダーが誰なのかを明確にする

テスト期間中の情報連携

テストの進捗や発生した課題に対して、いつ、誰が、どういうタイミングで集まって話していくのかを考える

移行(システムを本番環境に移行)

移行計画書を作成することが重要
要件定義の1番最初で考えた業務フロー（今の業務から新しい業務に移行していくために、何を考えなければいけないのか）を検討するための計画書
移行を考えるときに検討しなければいけない観点は主に3つある
- 業務の移行（既存業務→新業務に切り替えるために何をしなければいけないか)
- システムの移行（既存システム → 新システムに切り替えるために何をしなければいけないか）
- データの移行（システムに溜まっている既存データを、既存システムに残すか、新システムに移すか）
移行方針を考える上で押さえておくべきポイント
- 業務の移行ではプロセスの途中になっている業務をどうするかを考えることがポイント
  - 旧業務フローでスタートしているものは進める方法
  - 一定ラインまで進んだものは旧業務フローで終わらせ、一定ラインより手前の業務は新業務フローで進める方法
  - 一番現場の負担が少ない方法を選んでいくことが重要
- システムの移行ではインターフェースの切り替えのタイミングがポイント
  - 全く新しいインターフェースの場合はあらかじめ準備しておき、切り替えの日からインターフェースを使用する
  - 旧システムがある場合には古いシステムのインターフェースはいつから使えなくなるのか、古いシステム自体がいつから使えなくなるのかも考えていく必要がある
  - どのインターフェースがいつの何時何分から使える/使えないようになるのか1つ1つ丁寧に考えていき、決める必要がある
- データ移行では旧システムに入っていたデータをどうするかを考えることがポイント
  - 新システムで扱うデータを並べ、データを移行するかどうかを決める。
  - 移行する場合は全データ移行か、一部移行か
  - 移行する場合に、どうやって新システムに入れるか
移行計画をしてどんな移行作業があるのか明確になったら、実際に移行作業を行う人のための作業マニュアル（移行手順書）を作成するとよい

運用

「運用」とはシステムの稼働が始まったあとに発生する作業のこと
- 障害対応は運用の一つ
この運用時の作業を一覧にまとめておくことが重要
この一覧を作ることによって、システムを運用していくのに「どのくらいの作業が発生するか」というのを見積もることができる
- システムに対して、常時何人の人員が必要かが分かる
運用作業一覧ができたら、一つ一つの手順を運用業務マニュアルとして詳細にまとめる
- 画面キャプチャを並べながら、操作手順をまとめるとよい