QCDを理解してシステム開発のプロジェクト管理を最適化しよう〜PMが押さえるべき重要なポイント〜

![Q5HTFz9のコピー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3870510/4991576e-1fb6-3775-d92e-1dd52bf481ba.png)



こんにちは、タビアン採用広報の木下です。

プロジェクトマネジメントを体系立てた学ぼうとするとき、まず頭に浮かぶのはPMBOKではないでしょうか。ですが、IT用にカスタマイズ出来ておらず、カバー範囲も膨大な為、キャッチアップに時間がかかってしまうのも実状です。また、表現が難しい為、習得してから実際のプロジェクトに落とし込むのも大変です。

本記事では、システム開発の要件定義からリリースまで、各フェーズごとにプロジェクトマネージャー（以下、PM）がすべきことや、各工程における重要なポイントについて、紹介していきます！

#### この記事の想定読者
- 現在進行系でプロジェクトマネジメントを行っている開発マネージャーやPMの方
- 将来上流工程やプロジェクトマネジメントをやってみたいエンジニアの方

## プロジェクトとプロジェクトマネジメント
プロジェクトマネジメントとは、

:::note info
「プロジェクト」を成功させる為に必要な各種施策を企画し、遂行し、円滑に推進すること
:::

また、プロジェクトとは、

:::note info
独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務
:::

と定義されています。（PMBOK第6版より）


要するにプロジェクトとは、 **ゴールが決まり、予算が決まり、期間が決まっているもの** と言えます。

プロジェクトマネジメントとは、突き詰めると **Quality（品質）、Cost（コスト）、Delivery（納期）** の3点を高いレベルで満たしていれば、プロジェクトの成功であると言えます。


![4ePTTmt.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3870510/196accfc-0eaa-412d-8604-b1d6b4e2493c.png)


### プロジェクトで大事な3つのP
プロジェクトで大事なことは、

**精度の高い計画（Plan）** を立て、
**正しい成果物（Product）** を考え、
**混乱せず効率的な業務（Process）** を遂行することです。

#### Plan

全体計画や個別管理計画、各フェーズの計画等を網羅的かつ精度高く考えることができているか？

#### Product

プロジェクトで作成する成果物（システム）について、詳細かつさまざまな事象を鑑みて設計・構築出来ているか？

#### Process

各メンバーの各作業について、どこまで想定できているか？定常作業が分かりやすく、ルールが策定・徹底されているか？

3つのPが、何か1つでも欠けてしまうと、プロジェクトの遂行は困難となります。PMはプロジェクトメンバーと協働し、3つのPのバランスを取りながらプロジェクトを円滑に進行していく能力が必要です。

## 適切なスケジュールを作成するために
プロジェクトの進行において、スケジュールは必要不可欠です。
スケジュールの作成はPMが担いますが、作成で困ったことはありませんか？

以下は一例ですが、このようなことはよく起こり得ます。

:::note warn
- 共通スケジュールの記載内容がチームによってバラバラ
:::

:::note warn
- テストスケジュールが、そもそもバグがない前提
:::

:::note warn
- 単体テストと結合テストの実施範囲がチーム毎でバラバラ
:::

:::note warn
- フェーズ完了時の検収が一切入っていない
:::

:::note warn
- 1か月以上遅延のチームがあるが進捗報告上は順調
:::

:::note warn
- ベンダー間でリリース日に認識差異があった
:::


実はこれらはほとんどが、ハイレベルスケジュールが作成されていなかったり、進捗管理の方法が確立されていないことによる問題です。

全体の進捗管理を行うために、まずPMはハイレベルスケジュールの作成・進捗管理のフォーマット・方法定義から行いましょう。

### ハイレベルスケジュール作成
まずは各フェーズ・大きなイベントの日程を確定させていくことから始めます。その後、大日程を踏まえた各種成果物の締め切りや大きな会議体の日程を確定させていきます。

進捗管理についても、フォーマットから具体的な方法定義をしていく必要があります。さらに、詳細なタスクレベルを小日程に落とし込む際のフォーマット・ツールの定義も必要です。

![sPNhnfi.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3870510/869f3620-8519-fcc3-db85-1fdf1466bb31.png)

### WBS作成
ハイレベルスケジュールを作成したら、小日程となるWBSの作成を行います。WBS作成時は、記載粒度について大きく2つのアプローチがあります。

#### アウトプットベース

プロジェクトで作成する成果物から逆算し、必要な作業を落とし込むアプローチです。成果物がある程度決まっている場合に有効な手段となります。一方で、成果物定義が曖昧な場合にこの手法を取ると、本来作る必要のないものを作ったり、作るべきものを作らないことがあります。

#### 作業ベース

プロジェクト目標を達成するために必要な作業から逆算するアプローチです。成果物は各作業の結果として作成されます。

マルチベンダーなど、やり方や進め方が明確に決まっていない場合に有効な手段です。ただし、作業の目的や依存関係が曖昧なまま推進すると成果物が出ません。ステークホルダー間での成果物に認識の齟齬が発生してしまうなどのリスクが発生しやすいため、注意が必要です。

プロジェクトの性質やプロジェクトメンバーの規模により、有効な作成方法を取ると良いでしょう。

### スケジュール作成のポイント
スケジュール作成において、重要なチェックポイントとなります。

:::note 
- 大日程は **マネジメントが見てわかるレベル** になっているか
- 中日程は **チーム間のタスクの依存関係が明らか** になっているか
- 小日程は **日々の進捗が把握できるレベルまでタスクが明確** になっているか
- 進捗が **定量・定性的に把握** できるようになっているか
- 進捗管理者は **各タスクの意味合いを理解し、進捗を管理** できているか
- **スケジュールのバッファ** は確保されているか
:::

押さえておくべきポイントをしっかり把握し、スケジュールの作成を行いましょう。

## 課題・ToDo・リスクを常に管理する
スケジュールの作成を終え、進行管理のフェーズに入ってから以下のような問題はつきものです。

:::note warn
- いつまでもクローズされないタスクチケット
:::

:::note warn
- 誰がやるかわからない、担当者のいないToDo
:::

:::note warn
- 何をするかわからない、顕在化していない課題
:::

:::note warn
- いつまでにやるべきかわからないToDo
:::

これらも、そもそも課題・ToDo・リスクなどの分別が正確に定義されていないため、または管理ルールが明確に定まっていないため、発生することが非常に多いです。

リスクと課題は混在されがちですが、潜在的なものが「リスク」、顕在しているものが「課題」です。リスクには予防策が必要であり、課題には解決策が必要です。解決策にも暫定対応と恒久対応があるため、細分化が必要です。

また、課題の規模・影響範囲を明確にしていないと、PMが各チームの非常に個別な課題までを把握しなければいけなくなってしまいます。または全体レベルなのに、チーム課題で終わらせてしまうという事象も発生するため、各課題についての詳細化をしておくことは非常に重要です。

### 課題・ToDo・リスク管理のポイント
課題管理をする際、明確にすべき内容は以下の通りです。

:::note info
- ゴールを明確にする（どうやったら課題がクローズとなるのか）
- 担当者を明確にする（少なくとも主担当をアサインする）
- 期限を明確にする
:::

課題管理を作成するだけでなく、形骸化させないために、以下にも注意が必要です。

:::note warn
- ステータス・担当者・期限の更新漏れ
- 変更箇所が不明瞭
- 会議で発生した課題が管理表に起票されず、放置されている
- 文章がわかりづらく、プロジェクト関係者ごとに認識齟齬が発生している
- 複数の原因の課題を1つの課題として管理している
- 課題の重複がある
- 期限だけが更新され、アクションがない
- 記載者自身が何を課題としていたかを忘れてしまう
:::

課題管理は進行管理のためのものなので、作って終わりではありません。
都度更新を行い、ステータスを管理することが目的です。明確にすべきポイントを押さえ、デイリー・ウィークリーなどでプロジェクトメンバーと確認を行う場を設けると良いでしょう。

## 何を作るのか、成果物を定義する
プロジェクトにおいて、成果物の定義は非常に重要かつ、PMが主体的に推進すべき事項です。

成果物を漏れなくダブりなく作成するためには、まず **納品すべき成果物を明確すること** から始めましょう。
特に、 **納品成果物についてはプロジェクト最序盤で合意形成を行う** ことが重要です。
曖昧にしてしまうと、スコープ外の追加要望を求められるなど、場合によっては炎上に繋がってしまうこともあります。

納品すべき成果物以外でも、一覧系の成果物は必ずメンテナンスを忘れない仕組みを作りましょう。作成して終わり、メンテナンスがされないまま最新情報が曖昧になってしまうと元も子もありません。たとえば、テストのエビデンスを更新しておらず、そのためだけに再テストとなってしまうことはよくあります。提出の可否に関わらず、効率的にエビデンスを取れる方法を確立しておくことは成果物定義の重要なポイントと言えるでしょう。

## ステークホルダーマネジメント
プロジェクトはさまざまな人（ステークホルダー）が関わっています。その中でいかに上手くステークホルダーを取り込み、前向きかつ効率的に動いてもらうかを考えることはPMの重要な役割です。

![cdoTrfj.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3870510/c1f8890d-9fa6-3f25-5de2-4620cd180cb4.png)

権限も強く、関心度も高いが、他業務で忙しく関与率が低い役員への報告などは、ないがしろになりがちです。しかし、そのために後々決定事項がひっくり返ってしまう…ということもよくある話です。それぞれのステークホルダーに対し、最適な接し方を見極めることがステークホルダーマネジメントの基本的な方針です。

![L9JzDJD.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3870510/ce423017-73a0-a16e-8395-f71e955a4e41.png)

## さいごに
今回はPMに向けた、システム開発の要件定義からリリースまでの工程で、PMが押さえるべきポイントを紹介しました。PMは自身のタスクを遂行するだけでなく、エンジニアからクライアントの調整役として、プロジェクトの土台となる非常に大事なポジションです。PMのみなさんの気づきや学びになれれば幸いです！

なお、タビアンでは、開発PMやエンジニアメンバーを積極採用中です。ぜひ気軽にご応募ください！

https://www.wantedly.com/projects/1364782

https://www.wantedly.com/projects/1319283