新しいPJ発足時に「何を管理するか」をどうやって決めるか
新しいチームでPJを始める時、PJの特性やらなにやらでそれぞれ最適な回答が異なります。
今回は体系だっていなくても、個人のスキルなどでごり押しできてしまいがちな少人数のチームを新設したときに、組織（チーム）としての成熟度を可能な限り高めるためにどうしたらいいのかを考えてみました。
PMBOK知識管理体系
PMBOKが生まれる前は、「プロジェクト管理とは」という命題に対しての明確な答えがない状況でした。人によってスケジュール管理をイメージしたり、原価管理をイメージしたり・・・。
PMBOKは、この「プロジェクト管理」を体系的にまとめたものになります。PMBOKは何を管理するとプロセスをマネジメントすることができるのかの強力な手助けになります。
５つのプロセスと１０の知識エリア
PMBOKには以下の５つのプロセスと１０の知識エリアが定義されていています。各プロセスごとに必要なる知識エリアがあり、それぞれ「何をインプットに、どんなツール・技法をつかって管理しましょう」というナレッジがかかれているわけです。
| 知識エリア＼プロセス群 | 立ち上げ | 計画 | 実行 | 監視・管理 | 終結 |
|---|---|---|---|---|---|
| 統合マネジメント | 〇 | 〇 | 〇 | 〇 | 〇 |
| スコープ | 〇 | 〇 | |||
| スケジュール | 〇 | 〇 | |||
| コスト | 〇 | 〇 | |||
| 品質 | 〇 | 〇 | 〇 | ||
| 人的資源 | 〇 | 〇 | |||
| コミュニケーション | 〇 | 〇 | 〇 | ||
| リスク | 〇 | 〇 | |||
| 調達 | 〇 | 〇 | 〇 | 〇 | |
| ステークホルダー | 〇 | 〇 | 〇 | 〇 |
ステークホルダー管理は最近更新されてきたやつなのでよくわからない・・・
何をどこまでやっておくべきか
基本的に、「管理されている」状態にあるかないかに依らず、PMBOKで語られている観点はすべて考えていないとプロジェクトはうまく回りません。とはいえ、これらのすべての観点をすべて体系的に管理するのはしんどくて仕方ないのが実情かとおもいます。
そこで各プロセスごとに、この辺りを最初から管理しておくと早い段階で成熟度の高いチームを構築できると考える項目を考えてみます。
立ち上げプロセス
立ち上げで重要なのは、顧客の課題（ニーズ）をシステムが解決できる状態になっていることの確認です。顧客のオーダーした製品が顧客が解決したい課題とイコールになっておらず、オーダー通りのものを作ればいいとおもっていたら、運用に即しておらず仕様変更の嵐で大炎上なんてことケースが後を絶ちません。
プロジェクトの上流工程でミスを犯すと取り返しがつかないので、スタートの段階でプロジェクトの目的と意義を明確にしましょう。
また、経験則ですが、開発者も社会的意義を理解しているとモチベーションが上がる傾向にあります。製品の品質は意外とモチベーションに左右されるため、メンバ全体で共有しておきましょう。
計画プロセス
このプロセスが一番重要です。精度の高い計画を立てることができればプロジェクトはほぼ間違いなく成功するからです。しかし、新規チームの場合この計画を立てるための物差しがないことがほとんどです。なので初期段階としては、終結プロセスにて物差しが作れるよう、物差しのもととなるデータを作っておくことが重要になります。
作業を決める
まず、なにをするのかを決めましょう。PMBOKではWBSの作成をすることでプロジェクトスコープ（なにをするのか）を決めることを推奨しています。WBSを作るうえでのポイントは以下の通りです
- WBSをつくる
- プロジェクトの終わりを明確にする
- タスクの依存関係を明確にする
WBSはメンバーのモチベーションを維持するためにもチームで常に確認できるような状態にしておくことがのぞましいです。終わりが見えることは精神的な安心につながります。タスクの依存関係を見せることは、作業順序や納期に裁量権を与えることにつながります。自分でコントロールしている感覚を与えないと人は能動的に動くことはしません。
成果物を決める
開発の成果物として何を作らなくてはいけないかを決定していきます。代表的な成果物としては「ドキュメント」と「ソースコード」になります。
ドキュメントが「役に立つ」情報をキープするには、ドキュメントの役割を明確にすることが重要です。ドキュメントを使用するユースケースが見つからないとき、そのドキュメントは必要ありません。
- 読者がだれなのかを決める
- どんな時に読むものなのか決める
ソースコードはなきゃ動かないので作ってください。
ちなみに、成果物のフォーマットや記載ルールを定めることを開発標準化といいますが、これらの標準は形骸化することが非常に多いです。理由は標準が複雑になりすぎて個人の許容量を超えてしまうこと。そしてプログラマの文章能力の低さにあります。個人的にはやりすぎた標準化は手段の目的化を招くだけであり無意味であると考えています。「この目的を達成する文書を書け」という想像性を刺激するドキュメントを作ることでチームメンバの文章力の向上を図っていくことを推奨します。
実行プロセス
品質保証をする
※記載中
管理・監視プロセス
スケジュールを管理する
※記載中
バグを管理する
※記載中
変更を管理する
※記載中
リスクを管理する
プロジェクトは生ものです。どんなに頑張って計画しても当たることはほぼありません。リスクが見えていない状態は非常にストレスであり、不安という名の妄想が湧いてきます。リスクは常に見える状態で管理されているのが望ましいです。
ここで管理されるべきリスクは対処可能なリスクで十分です。明日地球が爆発して人類が絶滅するリスクが対処不能であることのように、自分でどうすることもできないリスクについては、管理しても意味がないのでやめましょう。
終結プロセス
振り返りと評価
次回のプロジェクトのインプットとしてかつ、効果が絶大なやつ・・・
- かかった工数から見積もりの指標を作る
- バグの傾向から問題の多い工程を洗い出し、開発プロセスを改善する
- リスクの傾向から初期で防止する方法を考える
まとめ
この辺を抑えておけば、大炎上はしないであろうというポイントを整理してみました。
ご指摘や意見などあればコメントお願いします。