
ITが当たり前の時代、何か新しいことを始めるときに、あたらしいITシステムが必要となることは不可避です。システムを作っていく、システム開発のプロジェクトをどのように進めていくかは、ビジネスの変革を実現するためにも非常に重要です。
プログラマーが一人でプログラムを書いてシステムを作っていくならば、適当に試行錯誤してもいいですが、大規模システムを開発していく際は、ある程度一定のルールのもとに作業を進めていく必要があります。
特に大規模システム開発においては、きちんとあるタイミングタイミングで物事を固めて、試行錯誤ができるだけ発生しない様、ウォーターフォールで進めることが結果的に成功の要因となると私は思っています。
今の時代はアジャイル開発が普通ではありますが、私は、アジャイル開発は小さなウォーターフォール開発の繰り返しだと思います。
プロジェクト開始時点で、最初から最後まで全体としてどんなタスクを実施しなければならないかの全体俯瞰することが肝となると思いますので、まずは普遍的なウォーターフォール開発の進め方の中で、最低限どのプロジェクトでも忘れてはならないタスクを、過去の経験からピックアップしました。
1.アプリケーション領域のタスク定義

アプリケーション基本設計フェーズのタスク定義
# | タスク | 説明(タスク) | 成果物 | 説明(成果物) |
---|---|---|---|---|
1 | 画面の基本設計(レイアウト及び項目定義) | 画面の定義、システム権限の具体化を実施する。各機能ごとに、論理的な処理ロジックを定義する。 | 画面の基本設計書 | 画面一覧、画面イメージおよび項目定義書、メニュー構成、画面遷移、権限グループ定義、権限グループ・画面設定一覧、入出力処理ロジック(入力定義、処理内容定義、出力定義) |
2 | 帳票の基本設計(レイアウト及び項目定義) | 帳票の定義を実施する。各機能ごとに、論理的な処理ロジックを定義する。 | 帳票の基本設計書 | 帳票一覧、帳票イメージおよび項目定義書、入出力処理ロジック(入力定義、処理内容定義、出力定義) |
3 | IFの基本設計(レイアウト及び項目定義) | 外部システムとのインターフェースを洗い出し、連携方式やデータ項目を定義する。各機能ごとに、論理的な処理ロジックを定義する。 | IFの基本設計書 | インタフェース一覧、インタフェースファイルレイアウト、入出力処理ロジック(入力定義、処理内容定義、出力定義) |
4 | ビジネスワークフローの基本設計 | ビジネスワークフローを作成する。各機能ごとに、論理的な処理ロジックを定義する。 | ビジネスワークフローの基本設計書 | アクターの定義、ワークフロープロセス図・タスク定義書、入出力処理ロジック(入力定義、処理内容定義、出力定義) |
5 | ビジネスルールの基本設計 | ビジネスルールを作成する。各機能ごとに、論理的な処理ロジックを定義する。 | ビジネスルールの基本設計書 | ルールマトリクス、入出力処理ロジック(入力定義、処理内容定義、出力定義) |
6 | バッチ処理の基本設計 | バッチ機能ごとに、論理的な処理ロジックを定義する。 | バッチ処理の基本設計書 | ジョブネットグループ定義、入出力処理ロジック(入力定義、処理内容定義、出力定義) |
7 | ER設計 | 論理データモデルを作成する。 | データ基本設計書 | 論理ER図・エンティティ一覧・エンティティ記述、論理データベース仕様(テーブル一覧、テーブル定義)、論理コード仕様、データディクショナリ、CRUDマトリクス |
アプリケーション詳細設計フェーズのタスク定義
# | タスク | 説明(タスク) | 成果物 | 説明(成果物) |
---|---|---|---|---|
1 | 画面の詳細設計(項目詳細及びイベント定義) | 画面の基本設計書をインプットに、詳細設計(物理設計)を実施。 | 画面詳細設計書 | 項目詳細(物理名称/使用タグ名称等)、イベント定義(Action定義等)、物理権限グループ定義、物理的なプログラムレベルの仕様(API、引数、内部処理ロジック)等 |
2 | 帳票の詳細設計(項目詳細及びイベント定義) | 帳票の基本設計書をインプットに、詳細設計(物理設計)を実施。 | 帳票詳細設計書 | 項目詳細(物理名称/使用タグ名称等)、イベント定義(Action定義等)、物理権限グループ定義、物理的なプログラムレベルの仕様(API、引数、内部処理ロジック)等 |
3 | IFの詳細設計(項目詳細及びイベント定義) | IFの基本設計書をインプットに、詳細設計(物理設計)を実施。 | インタフェース詳細設計書 | 項目詳細(物理名称/使用タグ名称等)、イベント定義(Action定義等)、物理権限グループ定義、物理的なプログラムレベルの仕様(API、引数、内部処理ロジック)等 |
4 | ビジネスワークフローの詳細設計 | ビジネスワークフローの基本設計書をインプットに、詳細設計(物理設計)を実施。 | ビジネスワークフロー詳細設計書 | 物理タスク定義(物理名称/使用Function等)、イベント定義(Action定義等)、物理的なプログラムレベルの仕様(API、引数、内部処理ロジック) |
5 | ビジネスルールの詳細設計 | ビジネスルールの基本設計書をインプットに、詳細設計(物理設計)を実施。 | ビジネスルール詳細設計書 | 物理ルールマトリクス、物理的なプログラムレベルの仕様(API、引数、内部処理ロジック)等 |
6 | ジョブネット設計・スクリプト設計 | バッチ処理の基本設計をインプットに、詳細設計(物理設計)を実施。 | ジョブネット設計書・スクリプト設計書 | ジョブの単位、ジョブをまとめるジョブネットの単位、ジョブ間の前後関係、ジョブネット間の前後関係、カレンダー、実行サイクル等を定義 |
7 | データベースの物理設計 | データ基本設計書をインプットに、詳細設計(物理設計)を実施。 | データベースの物理設計書 | 物理DB定義、物理テーブル定義、物理ER図等 |
アプリケーション構築単テフェーズのタスク定義
# | タスク | 説明(タスク) | 成果物 | 説明(成果物) |
---|---|---|---|---|
1 | 各種プログラム実装/アプリケーション実行ミドルウェアの構築 | プログラムソースコードの実装、アプリケーションパッケージミドルウェア、実行基盤ミドルウェアの構築 | ソフトウェアコード、ミドルウェアの設定 | 詳細設計書に基づき、プログラミング言語によって、実装したプログラム。各種設定ファイル等 |
2 | ジョブネット作成 | ジョブネット製品に対し、ジョブ・ジョブネットの登録 | ジョブ・ジョブネット定義 | 登録したジョブ・ジョブネット定義そのもの |
3 | データベースの構築 | DDL(Data Definition Language)を実行し、DB・テーブルを作成 | データベースオブジェクト | データベースオブジェクトやテーブルそのもの |
4 | アプリケーション単体テスト計画の作成 | テスト全体計画書や各種設計書を基に、テストに関する詳細な計画(テストの目的、範囲、開始基準、完了基準、テスト方法、テスト環境、スケジュール)を立てる。 | アプリケーション単体テスト実施計画書 | テストの目的/範囲、開始基準/完了基準、テスト方法、テスト環境、スケジュール |
5 | アプリケーション単体テスト仕様(テストケース)の作成 | テスト実施計画書、各種設計書等に基づき、システム機能を検証するためのテストケースを作成し、テストデータを準備する。 | アプリケーション単体テスト仕様書 | テスト対象、テストデータ、予想される結果、実施者、実施日時、実施結果、OK/NG判定 |
6 | アプリケーション単体テストの実施 | 個別テスト計画書及びテスト仕様書(テストケース)に従って、テストを行い、テスト結果をテスト結果報告書としてまとめる。 | アプリケーション単体テスト結果報告書 | 実施件数、障害件数、障害内容、申し送り等 |
2.インフラストラクチャ領域のタスク定義

そもそもプロジェクトの実施計画書にて定義されるべき内容ではあるが、環境の作成にあたりについて何点か注意点を記載します。
まず、開発環境については、アプリケーションチームが開発作業を開始する前に開発環境を構築する必要があります。また、開発環境そのもの自体の日機能要件として、アプリケーションの機能の動作確認ができさえすればいいという場合は、必要な仮想サーバのスペックを最低限とし、フェイルオーバ構成も不要として仮想サーバを1台ずつとする、ということが多いです。
検証環境、本番環境については、大きく2パターンの構築タイミングが考えられます。1パターン目は、本番運用フェーズにて本番環境とする環境のみ構築し、当該環境上でアプリケーションの結テ、総テ、受テをやり、品質を積み上げたて本番移行を実施後に、本番運用フェーズでステージングとして利用するために検証環境を構築するパターンです。
もう1パターンは、本番運用フェーズにて本番環境とする環境で試行錯誤をしないために、検証環境を先に構築し、当該環境上でアプリケーションの結テ、総テ、受テをやりつつ、環境手順が確立したことを受けて本番環境を構築して本番移行を実施するというパターンです。どちらのパターンとするか自体はプロジェクトの方針に依存します。
インフラストラクチャ基本設計フェーズのタスク定義
# | タスク | 説明(タスク) | 成果物 | 説明(成果物) |
---|---|---|---|---|
1 | システム構成(ブループリント)の作成 | アーキテクチャとして提供する機能を整理し、機能構成図を作成する。また、基盤とアプリケーションの境界を定義する。 | インフラストラクチャ基本設計書(ブループリント編) | システムの機能構成図・機能定義・機能一覧、システム構成図概要・ノード一覧、SW/HWスタック図・SW/HWスタック一覧 |
2 | サーバ・ストレージ構成設計 | ブループリント策定での定義内容を基に、サーバ・ストレージの論理的な構成、サーバ・ストレージ装置で実現する機能の実現方式を定義する。整理した各機能を論理ノードへ配置し、システム概念図を作成する。 | インフラストラクチャ基本設計書(サーバ・ストレージ編) | 各サーバ・ストレージの構成と求められる仕様を定義したもの |
3 | ネットワーク構成設計 | ブループリント策定での定義内容を基に、ネットワークの論理的な構成、ネットワーク装置で実現する機能の実現方式を定義する。 | インフラストラクチャ基本設計書(ネットワーク編) | システムを構成するネットワーク機器と求められる仕様を定義したもの |
4 | システム運用機能の基本設計 | システム化により実現する運用機能を明確にし、その実現方式を定義する。 | インフラストラクチャ基本設計書(システム運用機能編) | 運用プロセス図(システムに求められるサービスレベルを定義し、それに基づき、運用業務のルールやフローを定義)、運用基盤の機能構成図・機能定義・機能一覧(システム監視、ジョブ管理、バックアップ・リカバリ機能など) |
5 | セキュリティ機能の基本設計 | システムで実装するセキュリティ対策の実現方式を定義する。また、業務上のルール、規則によって実現するセキュリティ対策の実現方法を定義する。 | インフラストラクチャ基本設計書(セキュリティ機能編) | 想定される脅威に対して、リスク分析・評価を行い、実現すべきセキュリティ対策を選定したもの。また、セキュリティ対策として実装すべき機能、及びその実現方式を定義したもの。 |
6 | キャパシティプランニング | 性能要件、可用性要件、拡張性要件等に対し、システムにて担保する性能(パフォーマンス、キャパシティ)を定義 | インフラストラクチャ基本設計書(キャパシティプランニング編) | 想定するシステム負荷(同時アクセス数、同時セッション数)、想定する拡張率をもとに算出される必要リソース(サーバ台数、ストレージ容量等)等 |
インフラストラクチャ詳細設計フェーズのタスク定義
# | タスク | 説明(タスク) | 成果物 | 説明(成果物) |
---|---|---|---|---|
1 | 各製品パラメータ設計 | サーバ及びこれに付随するOS、ミドルウェア、ネットワーク機器、ストレージ等の各製品に対して、実装に際して必要な各種のパラメータ等の設計を実施する。 | 製品パラメータ設計書(サーバ、ストレージ、各ミドルウェア製品、ネットワーク機器) | 各製品で実現する機能の詳細パラメータ定義、数量、構成ならびに仮想サーバ/物理サーバ配置構成を定義したもの。 |
2 | 環境構築方針の作成 | 環境構築に係る作業、体制、役割分担等の方針を策定する。 | 環境構築方針書 | 環境構築に関して、作業、実施体制等の方針を定義したもの。 |
インフラストラクチャ構築単テフェーズのタスク定義
# | タスク | 説明(タスク) | 成果物 | 説明(成果物) |
---|---|---|---|---|
1 | 環境構築(環境ごと) | 環境構築手順書を作成したうえで、開発環境、検証環境、本番環境といった各環境を構築する。 | 環境構築手順書、構築した環境そのもの | ー |
2 | インフラ単体テスト計画の作成(環境ごと) | テスト全体計画書や各種設計書を基に、テストに関する詳細な計画(テストの目的、範囲、開始基準、完了基準、テスト方法、テスト環境、スケジュール)を立てる。 | インフラ単体テスト実施計画書 | テストの目的/範囲、開始基準/完了基準、テスト方法、テスト環境、スケジュール |
3 | インフラ単体テスト仕様(テストケース)の作成(環境ごと) | テスト実施計画書、各種設計書等に基づき、システム機能を検証するためのテストケースを作成し、テストデータを準備する。 | インフラ単体テスト仕様書 | テスト対象、テストデータ、予想される結果、実施者、実施日時、実施結果、OK/NG判定 |
4 | インフラ単体テストの実施(環境ごと) | 個別テスト計画書及びテスト仕様書(テストケース)に従って、テストを行い、テスト結果をテスト結果報告書としてまとめる。 | インフラ単体テスト結果報告書 | 実施件数、障害件数、障害内容、申し送り等 |
5 | 環境テスト(インフラ結合テスト)計画の作成(環境ごと) | テスト全体計画書や各種設計書を基に、テストに関する詳細な計画(テストの目的、範囲、開始基準、完了基準、テスト方法、テスト環境、スケジュール)を立てる。 | 環境テスト実施計画書 | テストの目的/範囲、開始基準/完了基準、テスト方法、テスト環境、スケジュール |
6 | 環境テスト(インフラ結合テスト)仕様(テストケース)の作成(環境ごと) | テスト実施計画書、各種設計書等に基づき、システム機能を検証するためのテストケースを作成し、テストデータを準備する。 | 環境テスト仕様書 | テスト対象、テストデータ、予想される結果、実施者、実施日時、実施結果、OK/NG判定 |
7 | 環境テスト(インフラ結合テスト)の実施(環境ごと) | 個別テスト計画書及びテスト仕様書(テストケース)に従って、テストを行い、テスト結果をテスト結果報告書としてまとめる。 | 環境テスト結果報告書 | 実施件数、障害件数、障害内容、申し送り等 |
0 件のコメント :
コメントを投稿