はじめに
本記事は、Udemyコース「手を動かして学ぶITプロジェクトの資料作成！システム開発のドキュメンテーション技術と成果物テンプレート」(講師：箕輪 旭氏)を受講し、学んだ内容を体系的に整理したものです。
受講の背景・目的
- システム開発プロジェクトにおいて、何をいつ決め、どのような資料を作成すればよいかを整理したかった
- 要件定義から運用まで、各フェーズでのドキュメンテーション技術を理解し、実務に活かせるテンプレートを習得したかった
- 自身が今後、上流工程やプロジェクト管理に携わるための基盤を築きたかった
1. プロジェクト計画
プロジェクト全体を俯瞰し、「どのような目的で」「どの範囲を」「いつまでに」「どのように」実行するかを明確にするフェーズです。
主な検討内容
| 項目 | 内容 |
|---|---|
| 目的・背景・スコープ | プロジェクトの対象範囲を明確化 |
| プロジェクト体制 | 役割・責任・ガバナンス構造の定義 |
| スケジュール・マイルストーン | 成果物の定義とタイムライン |
| 管理方針 | 進捗・品質・リスク・変更などの管理方法 |
| 成果物管理 | テンプレートの選定・共有・レビュー体制 |
重要ポイント
リスク管理シート・変更管理シートを早期に準備することが、手戻りを減らす鍵です。このフェーズで「いつ何を決めるか」を整理しておくことで、後続フェーズ(要件定義〜運用)をスムーズに進める土台が整います。
2. 要件定義
システム化対象の業務を可視化し、どのように変えるかを整理し、それに基づいてシステムが実現すべき機能を定義するフェーズです。
2.1 業務フローの作成
- 現行業務をフローチャートなどで可視化し、課題を明確化
- 課題1つ1つについて将来業務フローを作成し、改善・変革の方向性を整理
実務でのコツ
改善案を描いた後に「なぜその改善が必要か」を明文化すると、関係者への説明力が格段に上がります。
2.2 業務要件
- 業務フローを落とし込んで、「業務として何をどう変えたいか」を整理
- 現状と将来のギャップを明らかにし、改善すべき点を業務視点で定義
2.3 機能要件
- 業務要件を実現するために、システムとして備えるべき機能を洗い出し
- 業務フローと機能を「業務 ↔ システム機能」という視点で紐づけて整理
2.4 機能配置図
- どのシステムがどのような機能を持ち、どのような情報のやり取りが発生するかを図示
- システム間の境界・役割分担を見える化
2.5 IF(インターフェース)一覧
外部システムやモジュール間で発生するデータ連携を一覧で整理します。
整理すべき項目:
- 送受信データ
- 連携方式(API、ファイル転送、DB連携など)
- 頻度(リアルタイム、バッチ、定期など)
- 責任範囲
2.6 テーブル一覧・ER図
- システムで取り扱うデータを、テーブル(エンティティ)とそれらの関係で整理
- 機能配置図で定義されたデータが、どのように繋がっているかを明示
2.7 画面構成図
- 利用者が触る画面、画面間遷移、サイトマップなどを作成
- 利用者視点(UX/UI)での導線を確認するために重要
非機能要件の重要性
このフェーズで「非機能要件(性能、可用性、セキュリティ、拡張性など)」を明確にしておくと、後工程での抜け漏れが大幅に減ります。
3. 設計書
要件定義で整理された「何をやるか」を、システムとして「どのように実装するか」に落とし込むフェーズです。
主な成果物
| 成果物 | 内容 |
|---|---|
| IF項目定義書 | システム間連携データの項目定義(項目名、形式、制約など) |
| テーブル項目定義書 | DBテーブル・カラム、型・制約・説明などを整理 |
| 画面項目定義書 | 画面ごとの項目(入力/表示)、操作要件、バリデーションを整理 |
| 標準パラメータ定義書 | 共通的に使用する設定値、コード、共通定数などを定義 |
| 処理概要定義書 | バッチ処理や画面遷移・ロジックの流れを整理した概要設計 |
| コード定義書 | システム内で使用するコード体系(区分コード等)を整理 |
| 環境設定定義書 | 開発/テスト/本番環境の構成、設定内容、運用環境要件を明記 |
基本設計と詳細設計
多くの現場では以下の区分があります:
- 基本設計(外部設計): 要件定義と設計の橋渡し
- 詳細設計(内部設計): 実装に向けた仕様の具体化
品質担保のポイント
レビュー体制を設け、設計書の整合性・抜け漏れを早期に発見することが重要です。設計フェーズでの手戻りは、実装・テストフェーズでの手戻りよりもコストが低く抑えられます。
4. テスト
設計内容・実装内容が要件どおりに動作するかを検証し、品質を担保するフェーズです。
4.1 テスト計画
テスト実施前に以下を明確化します:
- テストスコープ: どの機能・範囲をテスト対象とするか
- 開始条件・完了条件: テストを開始/終了するための基準
- テスト実施スケジュール: 誰が、いつ、何を実施するか
- 障害管理プロセス: 発生した不具合をどのように管理・対応するか
- テスト実施体制: チーム構成、役割、レビュー・報告の流れ
- 情報連携: テスト期間中の進捗・障害状況・修正状況の共有方法
4.2 単体テスト
- 画面単位やプログラム単位での確認
- 設計書を元にテスト条件・期待値を定義
- 外部システムがないと動かない処理は**スタブ(Stub)**を作って仮実行
4.3 結合テスト
- 機能間・システム間のインターフェース(連携)に注目して整合性を確認
- 「本番と同じ流れ」でデータが期待どおりに流れるかを検証
4.4 総合テスト
- システム全体として、最初に定義した将来業務フローが再現できるかを確認
- 要件定義で整理した業務要件一覧が満たされているかを業務視点で検証
4.5 障害一覧
テストを実施する中で発見した障害(不具合)を記録・管理します。
管理項目例:
- 障害ID
- 発生条件
- 影響範囲
- 暫定対応
- 根本原因
- 本格対応
実務での追加成果物
「テスト観点表」「テスト結果報告書」「テストサマリー」「エビデンス(画面キャプチャ、ログ等)」も成果物として求められる場合があります。
5. 移行計画書
旧システムから新システムへの切り替えを、安全かつ確実に実行するためのフェーズです。
主な検討事項
| 項目 | 内容 |
|---|---|
| 業務移行 | 稼働中の業務を停止せずに移行を行うか/段階的に切り替えるかなどプロセスを整理 |
| システム移行 | インターフェースの切り替え、並行稼働、切替手順、ロールバック手順などを定義 |
| データ移行 | 旧システムのデータをどのように変換し、新システムに投入するか(移行ルール・検証・クリーニング含む) |
| 移行手順書作成 | 移行作業の具体的手順・担当・タイミング・確認項目を明記し、リハーサル(ドライラン)を実施 |
移行フェーズの注意点
移行フェーズは想定外の障害が発生しやすいため、「並行稼働」「バックアウト/ロールバック」「緊急対応体制」の整備が重要です。移行リハーサルは本番と同じ環境・手順で複数回実施することを推奨します。
6. 運用計画
システムの本番稼働後、安定的に運用・保守していくための準備フェーズです。
主な成果物・検討事項
- 運用作業一覧: 定期/随時実施する運用作業を洗い出し
- 運用マニュアル: 各作業について手順を明確化
- 障害報告書: 発生した事象、直接原因、影響範囲、暫定対応、根本原因、本格対応を記録
- 運用監視: システムの稼働状況、パフォーマンス、リソース使用状況の監視体制
- バックアップ・ログ保守: データ保護とトレーサビリティの確保
- 問い合わせ・ヘルプデスク対応: ユーザーサポート体制の構築
災害復旧計画の重要性
可用性やバックアップ体制に加えて、災害復旧(DR: Disaster Recovery)計画も運用設計では重要です。RTO(目標復旧時間)とRPO(目標復旧時点)を明確に定義しましょう。
7. プロジェクト管理
プロジェクトを計画どおりに進め、品質・課題に対応しながら目的を達成するための管理体制・手法です。
7.1 WBS(Work Breakdown Structure)
- プロジェクト開始〜完了までの全タスクを分解・一覧化
- スケジュールや責任を割り当て
- ガントチャートなどで可視化
7.2 TODO・課題一覧
| 種類 | 定義 | 例 |
|---|---|---|
| TODO | 誰かが手を動かせば終わるもの | 「○○資料の作成」「テストケースの追加」 |
| 課題 | 誰かに何か(判断/承認)をしてもらわないと解決しないもの | 「仕様の決定待ち」「予算承認待ち」 |
7.3 レビューシート
各フェーズの成果物に対して、様々な視点から評価を行い、品質を担保します。
評価観点例:
- 目的適合性
- 記述品質
- 網羅性
- 可読性
- 整合性
その他の管理ツール
- 進捗報告書: 定期的なステータス報告
- リスク登録簿: 潜在的なリスクの特定と対応策
- 変更管理表: スコープ変更や仕様変更の管理
- ガントチャート: スケジュールの可視化
プロジェクト管理の本質
プロジェクト管理はドキュメンテーションだけでなく、「コミュニケーション/意思決定/変更対応」がカギとなります。定期的なステークホルダーとの対話を忘れずに。
総括・実務活用に向けて
この講座で学んだ内容は、「ITプロジェクトにおける全フェーズを通じて、ドキュメントを通して品質を支える技術」です。
要件定義から運用まで、各工程で何を考え、どんなアウトプットを作るかを体系立てて理解できました。
実務に活かすために
-
テンプレートのカスタマイズ
- 学んだ資料テンプレートを自身のプロジェクトで使える形にカスタマイズしておくと、現場で即活用できます
-
作成タイミングの明確化
- 各成果物の目的・作成時点・レビュータイミングを自分のプロジェクトの実情に落とし込んでおくと、手戻りや混乱が減ります
-
関係者との連携
- 特にプロジェクト管理/要件定義/テストのフェーズでは、ドキュメントと関係者(開発チーム/運用チーム/ユーザー)の連携が重要
- 作成だけでなく「誰が/いつ/どのように使うか」を意識することが大切
今後のアクションプラン
- 学んだ資料テンプレートを使って、自分の案件で「プロジェクト計画書から運用マニュアルまで」のアウトラインを作成してみる
- 過去の自分のプロジェクトを振り返り、この学びをもとに「ドキュメントが足りなかった/改善できる箇所」を整理する
- 次回新規案件に参画する際、上流工程(要件定義・設計)に早期から関わり、「ドキュメント駆動の進行」を実践してみる
- プロジェクトメンバーとテンプレートを共有し、チーム全体でドキュメンテーション品質を向上させる
参考リンク
おわりに
ドキュメンテーションは「面倒な作業」ではなく、「プロジェクトの成功を支える重要な技術」です。
適切なドキュメント作成により、チーム間のコミュニケーションが円滑になり、手戻りが減り、品質が向上します。
ぜひ、この記事が皆さんのプロジェクト成功の一助となれば幸いです。
#ITプロジェクト #ドキュメンテーション #要件定義 #システム開発 #プロジェクト管理