プロジェクトを始めるにあたって

プロジェクトを始める場合、まず、何をするかというと、プロジェクト計画を行い、プロジェクト計画書を記述します。
※ 企画、見積もりが終わっている体でのお話です

開発者の皆さんは、プロジェクトはすっと始まり、頑張って設計して、実装して、テストして、リリースして、完了する。というような考えを持っているかもしれませんが、まず、プロジェクトマネージャがプロジェクト計画を始めます。
そのプロジェクト計画について記述します。

各項目で、本が1冊出来るようなものなので、ここではざっくり理解が出来ればと・・・

プロジェクト計画書って何？

プロジェクト計画書とは、読んで字のごとく、プロジェクトの計画をするのもです。

大まかには、「企画をもとに、どんな目的で、どんな風に、どういうルールで、いつまでに、開発しますよ」ということを記述します。
企画に対しての5W1Hを書ければOK

小さいプロジェクトの場合や、歴史があるプロジェクトの場合、プロジェクト計画がある程度固まっていたりして、「こんな感じで！」と言われて終わるような場合もありますが、本来は作られて然るべきものです。

具体的な見出しとしては以下のような感じ

プロジェクトの目的・目標
開発手法
マイルストーンとマスタースケジュール
役職と役割
体制
管理手法
- 進捗管理
- 課題管理
- リスク管理
- 変更管理
- 品質管理
- 環境管理
- メンバ管理
テスト計画
工程ごとの納品物
WBS

これからは、上記をそれぞれの単位で説明します。

プロジェクトの目的・目標

これは、企画に記載されているものをそのまま記述で、問題ありません。
こちらを書く目的ですが、開発するメンバに当該プロジェクトに対し、
企画者（お客様）が求めているものを意識してもらい、何が必要なのか、
どんなことをしていくのかなど、プロジェクト全体のベクトルを合わせるために
記述します。

開発手法

これは、当該プロジェクトにあったの開発手法を記述します。

ウォーターフォール型、アジャイル型、スパイラル型、プロトタイプ型など、当該プロジェクトにあった手法を検討し決定します。
開発手法については【ソフトウェア開発入門】4つの主な開発手法についてなどを参考にしてください

記述する際には、なぜその手法としたかの理由も記述すべきです。

マイルストーンとマスタースケジュール

開発手法をもとにマイルストーンを決定します。
その後、見積もりを元にそのマイルストーンに対するスケジュールを決定します（マスタースケジュール）

マイルストーン

マイルストーンは開発手法が決定すればほぼ決定します。
ですが、後述する工程ごとのイベントについても一部記述する必要があります
※ 「ほぼ」と言っているのは、会社内の文化により、手法が決定したとしてもどのようなものを実行するかが分かれるためです。

例えば、ウォーターフォールの場合、

要件定義
基本設計（機能設計、外部設計）
詳細設計
製造
単体テスト
結合テスト
受入テスト
リリース
納品

というようなものが決定し、それぞれ、誰が担当するかを決定します。
これも、会社内の文化がありますが、受注した場合、

要件定義、受入テスト、リリース：企画者（お客様）
それ以外:受注者

となります。

マスタースケジュール

マイルストーンに対するマスタースケジュールを引く
これは、見積もりを元に引くことになるが、見積もりが間違っていることをは大いにあるため、
マスタースケジュールを引く際は根拠を考える必要があります。
※ 何も考えずに引くようなことがないようにする

また、マスタースケジュールの段階で、利用する環境を考えておく方が良いです。

なお、マスタースケジュールは工程ごとに変動することは問題ない。
※ マスタースケジュールを動かしてはならないという考えは捨てるべきです。
守らなくてはいけないのはリリース日（or納品日）であり、各工程のスケジュールについては理由があれば動かすことがあることを企画者には伝えておく必要があります。

役職と役割

役職

プロジェクトの役職を設定します。
プロジェクトの大きさなどにあわせて、兼任や、省略もあると思います。

役職は一般的には以下です。

PMO
PM
- 全体的なプロジェクト管理者
- リスク管理者
- 課題・品質管理者
- スコープ・変更管理者
PL
- 技術統括
- タスク・進捗管理者
TL
- チームリーダ
- テックリーダ
メンバ

役割

体制

体制とは体制図などを作成し、お客様との窓口やPM, PL, TL, メンバをどういう人数でどう進めていくかを記述します。
ByNameで書こうとしてしまうが、まずはどんな人が何人必要かを考えることが必要です。
簡単にいうと、Javaの開発なのにC#のスキルを持っている人間が居ても、PJの推進が難しくなるだけであるので、ちゃんとJava開発ができる人を入れられるように計画するというようなことです（単純なスキルマッチ）

その他では以下のようなことが考えられます

新規プロジェクトなら基盤を組める人、アーキテクチャが出来る人は必要
難しい案件なら新卒や若い人ではなく、中堅が必要
新卒や若い人が居るなら、フォロー体制が必要

管理手法

PMはPLをPLはTLをTLはメンバを管理するにあたり、どのように管理するかを決定します。
管理では、報連相が出来るフローを正確にしておく必要があります

進捗管理

進捗管理ではMSProjectやプロジェクト管理ツールなどを使い、タスクの進捗状況を管理します。
管理では以下を考える必要があります

毎日報告できるようにする
メンバの作業を極力する失くする
タスクの遅延、前倒しが一目でわかるようにする
報告が上にあげやすい状態にする

また、遅延、前倒しを確認し、遅延が発生している場合は、
「原因の究明」⇒「打開策の発見」⇒「遂行」
をする必要があります。

原因の例：

外部要因（別作業に時間を取られているなど）
スキルミスマッチ（若手など）
- 遂行不可状態
- フォローすることで遂行可能

打開策の例：

期間の延長
フォロー体制の強化
タスクの割り振り変更

遅延については、「相対工数に対する遅延」と「絶対工数に対する遅延」があります。

相対工数

相対工数とは、タスクの工数に対し、何日進んでいるかを表します。相対工数はタスクの工数までしか、遅延、前倒しが出ません。

例えば、5日間かかるタスクに対し、3日たったところで、1日分（タスクの20%）しか進んでない場合、相対工数としては2人日（40%）の遅延になります。
上記の例の場合、相対工数は5人日までしか遅延が出ません。

リスク管理

リスク管理ではプロジェクト管理ツールやエクセルで、プロジェクトに対するリスクを管理します。
// 今のご時世、エクセルとかでは管理しないと思いますが・・・

リスクとは、「将来的に、PJ内で品質、コスト、スケジュールに影響を及ぼす可能性がある事象」のことを言います。
そのリスクに対して、「軽減策」「受容策」「回避策」を考え、推進します。

例えば、インフルエンザでメンバが休んでしまった場合、スケジュールに影響がでることになります。
この、「インフルエンザで人が休む」というのがリスクとなり、
軽減策としては「ワクチン接種を推進」「アルコール消毒を置く」「うがい手洗いを心掛けるように言う」「加湿器を置く」「マスクの着用を心掛けるように言う」などがあります。
受容策としては「先行して、替えの要員を出してもらえるかを経営層に聞いておく」「WBSを余裕を持たせる」などがあります。
回避策としてはインフルエンザですのでありません。

リスクについては、まず、初回にPJとして汎用的なものを考え（大抵、会社内のナレッジがある）、次にプロジェクト固有のリスクを考えます。
それらをフェーズごとにトップダウン、ボトムアップするようにします。

管理としては、運用フローを決めます。以下のことを考えておけば良いでしょう。

リスクを上げるフローを考える（リスクを提示する口を用意する）
各リスクに対し、監視するフローを考える（誰が、いつ、どうやって監視するか）
課題化するフローを考える

課題管理

課題管理ではプロジェクト管理ツールやエクセルで、プロジェクトに対する課題を管理します。
// 今のご時世、エクセルとかでは管理しないと思いますが・・・

課題とは、「リスクが顕在化したもの」や「タスクを進めるにあたって、自分だけでは解決できないもの」を言います。

課題では、「課題内容」「対応案」「実際の対応内容」「デッドライン」「次のアクションの期日」「アクションを実施する担当」「課題に対する影響」を決定する必要があります。
課題に対し、重要なのは「次のアクション（すべきこと）は何か」「次のアクションの期日はいつか」という所です。

課題については、常時あげられるようにする必要があります。
管理としては、運用フローを決めます。以下のことを考えておけば良いでしょう。

課題を上げるフローを考える（課題を提示する口を用意する）
各課題に対し、監視・推進するフローを考える（誰が、いつ、どうやって監視・推進するか）

変更管理

変更管理ではプロジェクト管理ツールやエクセルで、プロジェクトに対する変更を管理します。

変更管理とは、お客様からの要求、要件が何かの理由で変更になり、コストがプラス、もしくは、マイナスになる事象を言います。

変更管理は、お客様との調整となるため、お客様と共有できるようにする必要があります。

お客様との調整をしている最中に変更管理が出ることもありますので、メンバにどのような時に変更管理になるかを伝える必要があります。
また、その変更を受容するかはPMが決定する必要がありますので、GOサインを出して変更の対応する、もしくは、しないところまでフローを決定する必要があります。

管理としては、運用フローを決めます。以下のことを考えておけば良いでしょう。

変更を上げるフローを考える（変更を提示する口を用意する）
各変更に対し、監視・推進するフローを考える（誰が、いつ、どうやって監視・推進するか）
- 見積、体制の決定、管理方法の決定、お客様との調整、Go　or NotGo の決定、推進
GOの場合、どう対応するか（課題管理など）

品質管理

品質管理は、各工程の品質指標、もしくは、実施方法を考え、その指標が保てているかを管理します。

指標は定量的、定性的に考える必要があります。
例えば、基本設計は1ページのレビュー時間が30分以上で、指摘事項が3件、その中でバグ指摘が1件などが定量的な指標となります。
その中で、定性的に、メンバの技量（若手、スキルマッチしている人、有識者など）とPJのレベルなどを当てはめることになります。

単純に定量、定性をしても、なかなか品質向上が出来るものではありませんので、
本来は、ナレッジがたまった状態、今までがこうだったので今後がこうというように
品質は少しずつ会社の中で方向性を決める必要性があります。

初めての場合はIPAなどのもので、一般的なものを使ってみるのも良いでしょう
ただし、その場合は、メンバとの調整をしつつやらないと、
メンバからの不満が爆発することになります。

品質は、PMOなどが品質を向上を目指すために、PMに指示をするものですので、
指標については「なぜ？」「これで品質向上できる？」など、疑問を持って行動する必要があります。

環境管理

権限管理は、製造から、テスト（単体、結合、総合、性能、システム、受入、運用etc）までをどの環境で実施するかを管理します。

プロジェクト計画の段階から実施しておかないと、これがボトルネックになり、単純にプロジェクトが止まります。
例えば、結合テストと性能テストを同じ環境でやることはまず無理ですし、結合テストと受入テストが同じ環境で良いのか？という疑問も生まれると思います。

マスタースケジュールを記述したときには環境も決定しておくと良いでしょう。

権限管理

権限管理とは、サーバ、DBなどに対する権限を管理します。
テスト環境などのDBも誰が触れるかなど、管理しておかないと、ボトルネックになります。

意外とこれは忘れがちになります
よくある権限は以下

メーリングリスト
バージョン管理ツール
チャットツール
プロジェクト管理ツール
サーバのアクセス権
DBのアクセス権

メンバ管理

メンバ管理とは、メンバの管理を行います
進捗、課題管理ができていれば、基本的には問題ないのですが、若手が居たりする場合には、
メンバ自体を見る必要があります。

例えば：毎朝、朝会でメンバの「今日やる事」「疑問点」「課題」を把握する（これは30分以内にすべき）
※ 毎日やることについては（時間など物理的に）少なくする方が良いです。

テスト計画

テスト計画では、以下を行います。

全体テスト計画
各テスト工程の計画

テスト計画では、どのスケジュールで、だれが、何を対象に、どの環境で、どうやってテストするか、および、どうなれば完了となるかを記述します
例えば、
- 1月～3月の間
- 結合テストは受託側、受入テストは発注側
- 修正した箇所に影響するシステム
- 結合テストはテスト環境、受入テストはステージング環境
- FireFox, GoogleChrome, Edgeブラウザからのアクセスをしてテストする
- テストはすべてが完了で、指標を満たし、発注側の承認を得たら完了
- テストがすべてOK出なかった、もしくは、指標を完全に満たせなかった場合はその理由を説明

工程ごとの納品物

各工程の納品物を決定します。

設計書
- レビュー記録表
テスト仕様書orテストコード
- テスト報告書
- エビデンス
- バグ分析報告書
ソースコードorリソース
- レビュー記録表

設計書についてはできれば、要件定義後には、ドキュメントレベルで納品物を決定しておくべきです。

WBS

WBS（Work Breakdown Structure）はMSProjectやプロジェクト管理ツールなどを使い、タスクを細分化したものです。
これを使い、進捗管理が行われます。

見積⇒タスク、工数⇒体制があり、それがどう進むのかがWBSでき、
WBSが出来ることで、ガントチャートを引くことができ
ガントチャートが出来ることで、PJの全体が俯瞰的に可視化出来ます。

タスク、工数の確認

WBSを引く場合（or工程の開始前）には、メンバからの意見を聞くべきです。
見積で出来たタスク、および、工数は、実際に来たメンバと合っているとは限りません。
Aさんが見積もりをした工数で、Bさんが作業するのに、その工数がマッチするかを考えればわかると思います。
また、タスク一覧は見積から出来るものですが、このタスク一覧について、各工程ごとにメンバと調整をしてください。

工程ごとのイベント

工程ごとにはイベントがあります。
これまでに話してきたものは省きます。

キックオフ（説明会）

メンバに工程が開始することを伝えます。
計画書やフォーマット、フローを提示し、どうしていくべきかのベクトルを合わせます。

メンバが多ければ多いほど、コストがかかりますので、出来るだけ時間を短くします。
TLに以上に連携して、周知してもらうのも良いです。

工程終了（移行）判定

品質指標が満たせているかの報告、判定を行います。
もし満たせていない場合は、別途メンバに作業を依頼することになりますので、
工程終了判定があることはメンバに伝えておきましょう。

準備作業（設計）

設計書のフォーマット決め

設計書を書くうえで、まずはフォーマットを決める必要があります。
それをやらないと各メンバが好きな設計書を好きに作り、統一感のないものが出来てしまいます。
フォーマットは以下のものを決めればよいです。

ファイル名のフォーマット
- 例えば：【PJ名】サブシステム名機能名設計書の種別[基本設計|詳細設計|DB設計]
内容のフォーマット
- 例えば：表紙、改版履歴、I/F、プロセス概要（詳細）、DTO（エンティティ）etc

フォーマットとして書くのが難しいのであれば、サンプルを作成し、「同じように書いてね」としても良いでしょう

準備作業（実装）

レビュー方法の決定

実装について、どのようにレビューをしていくかの方針を決定します。

開発環境の準備

開発環境の決定と、その構築手順の作成を行います。

CheckStyleやLint、FindBugsなど、ソースコードのチェックツールの選定、および、設定も行います。
また、フォーマッターの設定やコメントの粒度も決めておくと良いでしょう。

基盤の実装

基盤については、先んじて実装しておかないと、他の部分を作成するのに作りが違いが出てしまいます。

準備作業（単体）

レビュー方法の決定

単体テストについて、どのようにレビューをしていくかの方針を決定します。

テスト環境の準備

テスト環境の決定と、その構築手順の作成を行います。

JUnitやJacocoなどのUnitテストツールの選定、および、設定も行います。
テストコードでない場合はテスト仕様書のフォーマットなどを決めます。
また、フォーマッターの設定やコメントの粒度も決めておくと良いでしょう。
例えば、コメントには、JavaDocに、どのようなテストか、インプットは何か、アウトプットは何か、程度を記述するなど

サンプルの実装

単体テストについては、先んじてサンプルを実装することで、メンバのベクトルを合わせます。

準備作業（テスト）

テスト環境の準備

テスト環境の決定と、その構築手順の作成を行います。

環境はサーバだけではなく、テスト用のデータの準備も行いましょう。

テスト仕様書の作成準備

テストの観点を作成します。
テストの観点は必ず開発メンバとすり合わせをしましょう。

次に、テスト仕様書のフォーマットを決めておきます

最後に

自分のメモに近い状態で書いていますし、PJによっては全然違う所もありますので、
参考程度に出来ればと考えています。

プロジェクト計画がちゃんとしていないと、自転車操業的なPJとなり、
メンバにゴールを示すことが出来ず、不安と苛立ちが出てきてしまいます。

最近はアジャイル開発、プロトタイプ開発などになり、ちゃんとプロジェクト計画をしないのかもしれませんが、ちゃんとしてなくてもプロジェクト計画は必要だと考えてます。