Udemyコース

手を動かして学ぶITプロジェクトの資料作成！システム開発のドキュメンテー…手を動かして学ぶITプロジェクトの資料作成！システム開発のドキュメンテーション技術と成果物テンプレート

１．プロジェクト計画

プロジェクト計画の目的と定義

なんのためにそのプロジェクトが必要なのかを説明するためのもの。

解決する課題を決める
プロジェクトの目的・責任範囲を決める。
プロジェクトの目的を実現するためのソリューションを決める。
マイルストーンを決める。※個別タスクではなく、もっと大きな単位でのイベントを単位として考える。
成果物を決める。※仕事の結果、最終的に何が完成していなければならないのか。
成果物の担当チームと責任者を決定する。
プロジェクトをすすめる上でのルールを決める。

プロジェクトの目的と責任範囲

背景と目的をまとめる。　　問題点　→　解決方法（プロジェクトを実行した結果なにが得られるのか。）
責任範囲を明確化する。　　プロジェクトの影響を受けるのは、特定の部門のみではない。そのため、今回のプロジェクトで対応しようとしている範囲がどこまでなのかを予め明確にして合意をとっておき、あとからあっちもこっちもと範囲がぶれないようにする。

ソリューションを考える

前節で明確化したプロジェクトで解決したい各課題について、より詳細な対応方法を示す。
「課題　→　ソリューション」のかたちでそれぞれを対応する形で記載するのがよい。

書かなければならないこと

課題：課題が顧客にとって納得感のある内容であること。
ソリューション：ただやることを書くのではなく、それをやるとなぜ課題が解決できるのかを理解できるような記載にする。

マスタースケジュール

フェーズごとのチェックポイント、ミッションクリティカルな事項の決定期限を設定する。
仕様確定のタイミングを明確にしておく。
リリース判断という作業が実際のリリースよりも前に必要となることを認識しておく。　（ステークホルダーへの最終確認）
すべてが確定してからだけではなく、各フェーズの終了時点でステークホルダーの承認を入れておくのが吉。
スケジュールの見積もりには下記参考資料、社内の熟練者などから聞き取るなどの準備が有効。

＜参考＞
ソフトウェア開発研究白書
https://www.ipa.go.jp/ikc/reports/2018.html

成果物一覧

各フェーズにおけるタスクと成果物を明確にする。
必ず各タスクに成果物を紐付けておくことで、本人、管理者それぞれがどの程度の進捗状況なのか明確に把握することが可能となる。
単一の資料として、すべてのフェーズのタスクと成果物をまとめた一覧資料もあったほうがいいが、各フェーズ単位、各タスク単位でどのような成果物が必要なのかを示しておく必要がある。

プロジェクト体制

書かなければならないこと

どのようなチームが存在するか
チームごとの役割
チーム内のメンバー、リーダー（責任者）

どのチームが何を決めるのかを明確にしておく必要がある。
スケジュールやタスクに問題が発生した場合に、上位にエスカレーションする。そこまでする必要がない事象については、そのチームの責任の範囲内で対応をおこなう。

進捗・課題管理方針

進捗会議やステアリングコミッティなど、会議を実施する基準、頻度（タイミング）などを明示しておくことで、毎回調整が必要となってしまうことを防ぐ。
課題のエスカレーション基準もルール化しておく。

品質管理方針

資料など成果物は人が作るものなので、ミスが有ることが前提としてレビューなどを行い品質を管理する。
品質を担保するためのルール、方法を全員で共有できるように定義する。

２．要件定義

要件定義の目的と定義

「何を作るのか」を定める。そのためにかかるコストを算出する。

決めなければならないこと

現在業務の整理
新しい業務の整理
システム化の内容を決める。
実現するための構成柄を決める。 →どのように実現するのか（外注、自作など）
外部との連携（インターフェース）を洗い出す。
洗い出しが不十分だと追加対応や修正が発生する原因になる。
データ構造を決める。連携先との連携に影響があるため明確にする必要がある。
画面構成の決定 →これは他と比べて後からでも対応可能
非機能要件（セキュリティ、ネットワーク等のインフラ、パフォーマンスなど）
調達（サーバーは？クラウドの契約プランは？ベンダーは？）

業務フローの決定

1.現在の業務をフローチャートに起票し、課題点を明確にする。
2.課題を解決するための対応を実施後の業務フローを作成する。

新業務フローで本当に改善となっているかの判断目安
→フローに登場する登場人物ごとに必要となるタスクが減っているかどうかが最もかんたんな判断指標となる。

業務要件をまとめる

作成した業務フローの各所でどのような業務を行っているかの詳細一覧を作成する。（仕事内容、担当者、改善後の状況（継続、システムに変わるetc) →業務の増減とステークホルダーの明確化

機能要件一覧の作成

業務フローからまとめた業務要件をもとに、システムで対応する内容についてまとめる。
システムとして対応することが必要な機能をまとめ、各機能について分類分けしておくとよい。 →分類・・・画面、帳票、インターフェース、処理　など

Fit&Gap分析

機能要件の実現可否を事前に確認・検討する。
パッケージシステムやCRMなどすでに存在するシステムを利用する場合は、各機能要件を実現することが可能か事前に動作確認する。
Fit&Gapの結果をもとに、機能要件一覧に記載した各機能要件について、作成するシステム、またはCRMなどの機能構成（画面構成）に合わせて再分類する。そのほうが対応関係がはっきりわかりやすくなる。
業務要件一覧と機能要件一覧を突き合わせて、どの業務用件に対してどの機能要件が対応しているのかが明確になるよう、業務要件一覧にまとめていく。

機能配置図

機能要件のどの機能を作成するシステムのどの機能で実現するのかを示す。

機能配置図に記載すること

どのようなシステムが存在するのか
どのシステム間で連携しているのか、何を連携しているのか。（インターフェース）
どのシステムでデータを管理するのか。（メールサーバーとデータベースで重複するデータを管理している場合、どちらを主としてデータを連携、利用すればよいのか。）

ここで作成した機能配置図からシステム間の関係を図にしたものがシステム構成図となる。

IF一覧（インターフェース一覧）

データを連携する必要があるシステムの一覧を作成する。

確認ポイント

どんなシステムと連携が発生するのか
それぞれ連携に使用するネットワーク
連携タイミング(いつ、どのような条件、頻度で)

連携する項目については、のちの開発フェーズで確認、決定すれば良いので、ここでは重要度が下がる。

テーブル一覧・ER図

システムに用意する（用意されている）データベース内のテーブル一覧を作成する。開発者に示す場合は、関係するテーブルすべてを記載する必要があるが、使用者（ユーザー）に示す資料としては、ユーザーに直接関係する（使用する）テーブルのみ記載する。

書くべきもの・・・マスターデータテーブル、利用に直接関係するテーブルなど　
書く必要がないもの・・・ログテーブル、ワークテーブルなど

パッケージシステムなどをカスタマイズせずに使用する場合は、無理にER図を作成する必要はない。

画面構成図

どんな画面があってどのように行き来することが可能なのかを示すもの。
実際の画面が完成するまではユーザーと画面の動きについて話をする際にイメージを共有できるものが存在しないため、画面構成図を作成することで画面がどのように遷移するのかを示す。（サイトマップ）

ER図と同様、パッケージシステムなどを標準機能のままてを加えずに利用する場合は、わざわざ作成しないほうがよい場合もある。

非機能要件一覧

IPAの非機能要件一覧を参考にする。（セキュリティ、ログ、パフォーマンスなど）

調達（ライセンス一覧）

開発に必要なツールや環境の作成に必要なものの一覧。
（開発ツール、AWSなどの環境のライセンス、パッケージなどのライセンス　等）

会社によっては調達にあたって申請から調達完了まで1ヶ月以上かかる場合もあるため、調達が必要なもの一覧（ライセンス一覧）には漏れがないように要注意する。

３．設計

設計の目的と定義内容

要件定義・・・何を作るのか
設計・・・どうやって作るのか（後は手を動かせば完成する状態を作成する。）

IF項目定義書

要件定義で作成したIF一覧の内容をもとに、IF連携に必要なより詳細情報を定義する。

データ型、サイズ、必須有無など、データベースに格納することを意識して検討する必要がある。
連携ファイルがCSVファイルの場合、ヘッダーをどう扱うか、キー情報がどのような形式のでーたでどこに入っているか、ダブルクォーテーションの有無などに注意する。

テーブル項目定義書

要件定義で作成したテーブル一覧をもとに、各テーブルで管理する項目の詳細一覧を作成する。

システム標準で用意されているテーブルについては作成しない場合もある。　（すべて把握することは難しいため、中途半端になるぐらいなら作成範囲から外す）
テーブルの和名と物理テーブル名は必ず記載する。
各項目がどのようなデータを格納するかを記載しておく必要がある。　→保守のため。
Indexを作成する場合はどの項目にIndexを作成しているか分かるようにしておく。

画面項目定義書

要件定義で画面を作成するとしたものの画面設計書を作成する。

画面イメージ

遷移元、遷移先の画面を明示しておく。　→テストパターンの洗い出しに利用できる。　→改修が必要となった場合に影響範囲の調査に利用できる。
画面イメージはテストを実施した時のイメージ（正しいことが確認できた画面）の画像を貼り付ける。　→後に画面がおかしいなどの指摘が入った場合に、現状が正しいことの証跡となる、

画面項目一覧

表示する項目名とその詳細設定情報を画面項目一覧として記載する。

処理概要

対象の画面において、アクションに対してどのような処理を実行するのか説明を記載する。
- 別途処理概要定義書を作成しする場合もある。（みやすさ、管理しやすさで判断する。）

標準パラメータ定義書

標準機能で設定可能な各項目を一覧化し、各設定値を記入する。

変更できない項目は記載しない、そもそもパラメータ定義書を作成しないなどの判断は各プロジェクトにおいて判断する。

処理概要設計書

プログラムの各処理内容を日本語に落とし込んで文章化したもの。

書き方には主に2パターンある

1.フローチャートで記載する（Excelのオブジェクトでフローチャートを記載する）
2.Excel方眼紙で記載する

コード定義書

プログラムでは、例えば条件分岐ではマスターの値（名称）をのものをプログラムに埋め込むのではなく、値（名称）に紐づくコードを使用する。そのため、後からプログラムを読む場合も使用されているコードの意味が分かるようにコードと名称の対応関係を明示する定義書を作成する。
マスター定義書と同意
単純にコードと名称を対応させた一覧表

環境設定定義書

AWSなどの環境構築において設定した設定項目と各設定値を一覧化する。

5.テスト

テスト計画書

計画→要件定義→設計→テスト

テストスコープ（いつどこをやるか）　を決定する。
実施するテストの内容と完了条件を決定する。
障害発生時の対応ルールを決定する。
進捗や課題の共有（報告）について決定する。 特に重要なのは、テストスコープと完了条件

テストスコープ

・単体テスト　・・・　各機能の動作を確認する。
・結合テスト　・・・　主に機能間のIFの動作を確認する。
・総合テスト　・・・　外部システムを含めた業務が正しく行えることを確認する。
・受け入れテスト　・・・　システムを実際に使用するユーザーが、実際の業務の要件を正しく満たしているかを確認する。

各テストの開始条件は、一つ前のテストがきちんと終わっていることが条件となる。

テスト完了の判断条件（不具合検出状況）

単体テストの場合　・・・　IPAのデータ白書を参考にする、初期は不具合が多く発生するものの、テストが進むに従ってバグ検出件数が減少していることで不具合が解消されていると判断する（初期にほとんどバグが発生しない場合は、テストケースに不備、不足がある恐れもある）　など
結合テスト以降の場合　・・・　前段階のテストで発見されるべき不具合が発生していないこと。左記不具合が発生している場合は、テストケースの不足、不備が考えられる。

テストスケジュール

各テストフェーズの期間とマイルストーンを設定する。
外部システムとのIFテストは結合テストの前に行う。
移行が必要な場合は、移行リハーサルを総合テストの前に設定する。本番データを総合テスト環境に実際に登録することで、総合テストにおいて移行が正しく行えていることも合わせて確認することができる。

その他

エスカレーションルール（障害管理）
テスト実施体制
テスト期間中の打ち合わせ計画

単体テスト

用意する項目：ID、区分、操作、入力データ、確認内容、確認者　etc
入力データは別紙にまとめて記載する。
テストは大まかに画面（表示）のテストと処理のテスト
項目が定義書通り正しく表示されることの確認、バリデーションの確認、ボタン押下時の処理確認
入力データの確認は各項目の最大値パターンと最小値パターンは必要。
処理のテストでは処理概要定義書で設計した処理が正しく行われることを確認する。
テストケースはプログラムを見ながらではなく、設計書の記載をもとにして作成する。
IFが必要な機能のテストはダミー機能（スタブ）を使ってテストする。

結合テスト

IFに着目し、送信元と受け手が正しく連携できることを確認する。(機能配置図参照）

単体テストの場合は、テスト対象機能１点のみを確認すればよかったが、結合テストの場合は１機能につき送信元と受け手の両方、計２件のテストが必要となる。
テストシナリオ・・・　テストケースを実施する処理の順に並べ替えたもの
１つのシナリオですべての機能を網羅する必要はなく、複数シナリオで対応する。

総合テスト

外部システムを含め、業務要件一覧に定義した要件を見たして業務を正常に行えることを確認する。

総合テストでは、できる限り本番のデータに近いデータでテストを行う。

障害一覧

テストで発生した障害を一覧管理する。
進捗報告などで利用する。

フェーズ、ケース、事象、起票者、起票日、状況（ステータス）

その他のテスト

○パフォーマンステスト
-　画面表示速度
-　処理実行速度
-　負荷テスト

○セキュリティテスト
- リクエスト強要
- クロスサイトスクリプティング
- ディレクトリトラバーサル
- SQLインジェクション/OSコマンドインジェクション

6.移行

移行計画

旧業務から新業務に移行する際に実施する必要があることはなにかを考える。

○検討すべきこと
- 業務フローの進行途中となっている業務の対応
　→現場の負担が一番少ない方法を検討する。
- IFの切り替え、公開されているサービス（例：お問い合わせフォーム）の切り替え
　→切り替えるタイミングを検討する。
- データ移行
　→旧システム内に存在するデータの新システムへの移行方法
　→そのまま移行するのか、移行に当たり加工が必要なのか。

移行方針は要件定義の段階である程度決めておく。

移行手順書

移行作業を行うための手順書を作成する。

移行リハーサルで手順を事前に確認する。

７．運用以降

運用作業一覧

新システムが稼働を始めたあとの業務における運用で必要な作業をまとめる。

運用作業一覧を作成することで、システムを運用するに当たり必要な作業量が見えるようになり、必要な作業と人員の見積もりが可能となる。（保守）

運用作業マニュアル

運用する際に必要な作業手順をマニュアルとしてまとめる。

初めて運用業務を実施するユーザーも問題なく利用できるように詳細な手順書を作成する。

障害報告

○障害報告書に記載すること
- どんな事象が発生したのか
- 発生した事象の原因はなにか
- 影響範囲の確認
- 暫定対応の内容
- 根本原因の調査
- 恒久対応の内容
- 恒久対応（本格対応）

WBS

いつ、だれが、どのようなタスクを実施するかを一覧化し、スケジュール管理する。

ToDO、課題一覧

ToDO ・・・　誰かが実施すれば完了できる作業。
課題一覧　・・・　解決に当たり作業を実施するだけでなく、対応方針の検討・決定してもらう必要があるものが"課題”となる。

レビュー

成果物を確認（レビュー）した結果をレビューレポートとして残しておくことで、成果物の品質を担保する。

８．まとめ