【前回までのおさらい】
■ PMは技術者出身でなくともなれる。
■ PMは向き不向きがハッキリ分かれる。
■ プロジェクトマネジメントは、受注段階から始まっている。
■ キックオフミーティングが、PMの腕の見せ所である。
PMBOKでは、プロジェクトの時系列を5つのプロセスで定義しています。
立ち上げ→計画→実行→管理・監視→終結
2回目でお話したのは、「立ち上げ→計画」段階。
3回目でお話したのは、「実行」フェーズの始まりのキックオフ。
今回は、「管理・監視」の部分にフォーカスしてお話します。
ここで登場するキーワードは、コントロールです。
計画に従って実行に移すわけですが、計画通りに進めば誰も苦労はしませんし、もっとPMは人気職種になるでしょう（笑）
ここが、一番多くのPMが悩むところかと思います。
では、まず「プロジェクトをコントロールする」ということは、どういうことかを考えてみましょう。
プロジェクトは生モノですから、刻一刻と状況が変化します。
まず、前提条件として「プロジェクトは変化する」ということを、理解するところから始めなくてはいけません。
完璧な計画を立てれば、うまく行くと思いますか？
残念ながら、人間という生き物はそんなに完璧ではありません。
考え方も感じ方も違う人たちが、同じシステムを作りこんでいくのです。
設計→実装と進むにつれて、同じ要件でも解釈の違いから、色々な課題が出てくるのが普通です。
また、実装へ落とすに当たって、曖昧なことを全て具体的にしなければ、作業者は作業出来ません。
では、どのような課題が想定されるのでしょうか？
1. 顧客要件の変化
普通のプロジェクトならば、要件定義の時間を設け、どのようなシステムを作りたいかを顧客と一定期間会話をし、要件定義書にまとめます。
しかしながら、この段階では顧客もあまりシステムイメージが把握出来ていませんので、極めて抽象的な要件しかまとめられていないことが多々あります。
またある程度キッチリ要件定義をやっても、顧客の気が変わることもよくあることです。
プロセス管理として、要件定義フェーズでしっかり要件を詰めることは重要ですが、その要件は「なぜ」発生したのか、どのような経緯で決めたのか、しっかり記録をし、顧客の気が変わった時に「立ち戻れる場所」を作りましょう。
そして、予め「要件を変更する際の取り決め」をし、変更管理台帳で管理できるようにしましょう。
その際には変更した際の影響範囲と工数を明記し、それらを考慮して要否を判断するプロセスを踏みましょう。
2. 設計方式の見直し
実際に設計に移ると、要件を実装するためのパターンが複数あり、メリットデメリットが発生することは、よくあることです。
その度に方式検討をし、メリットデメリットを顧客に丁寧に説明して、「なぜ」「どの」方式を採用するか握りましょう。
そして、設計書にその考え方のプロセスを明記し、その方式を採用した経緯が、後で第三者が見た時にも明らかになるように、記述しましょう。
万が一顧客(若しくは上位のベンダー)の気が変わった場所も、「立ち戻れる場所」として有効です。
3. 実装方式の見直し
設計通り実装するのがセオリーですが、新規に作り込むならともかく、改修案件だと既存のソースの記述方式との整合性に悩むこともよくあります。
基本的には、分岐条件(if～ elseにするか、andで並べるか等)や共通変数定義などの実装方式を統一しないとソースが汚くなるばかりか、障害の原因にもなるので、まずは方式を統一することが大前提です。
ただし、既存のソースに手を入れると、余計にテストが必要になるので、その辺りのバランスも考慮して改修を進める必要があります。
今後の保守性と拡張性を考慮した結果、「なぜ」「どのように」を決め、この結論に至った経緯がわかるように、詳細設計書や補足資料に記述しておきましょう。
また、実装の見直しを行うと、必ず設計の見直しもセットで考慮する必要があります。
原則的には、必ず設計に立ち戻って設計と実装の整合が取れるようにしましょう。当然、テストもやり直す必要があります。
上記で挙げた通り、それぞれのフェーズで都度変更要件は発生します。
まずは、「プロジェクトは変化するもの」という前提で、余裕を持ったスケジューリングをするのが重要です。
そのために考慮すべきプロジェクト管理項目は、以下の通りとなります。
1. スケジュール策定
先ほど申し上げた通り、何か変更があっても対応出来るだけのバッファ(余裕)を持ちましょう。
顧客と納期を詰める際にも、しっかり品質確保が出来るスケジュールを逆算し、デッドラインを設けてスケジュール上の制約を顧客にも見える化しましょう。
間違っても、顧客の指定納期を丸呑みするのはやめましょう。
とは言え、タイトなスケジュールを組まざるを得なくなる現実は多々ありますので、必ず品質確保に関する考え方を顧客と握りましょう。(暫定対処、恒久対策など)
2. タスク管理
タスク管理の要点は、「必要な時に役割分担を変更出来る」ことです。
状況に応じて、タスクを入れ替えたり、稼働を分散したり柔軟な運用が出来ないと、変化に強いプロジェクトマネジメントは出来ません。
併せて、タスク一つ一つの工数見積もりと、各個人のタスク消化スピードを把握しておくことも、必須です。
3. 課題管理
課題を抜けモレなく抽出することも大切ですが、もっと重要なのは完了条件の設定です。
課題が抽出された背景と、どのような状態になれば完了なのか、明確にしましょう。
そして、その課題がどのように検討されたか、経緯を記述し、あとで立ち返った時にも分かるようにしておきましょう。
横展開が必要な事案も、影響範囲を併せて整理する必要があります。
「変化に強いプロジェクトマネジメント」と一言で言っても、実際の現場運営は千差万別です。
必ず、一つ一つの現場はユニークなものであり、同じ運営の仕方は通用しないと心に留めておきましょう。
その上で、ケーススタディとして経験値を積んで、決断の裏付けにしていけば、現場で使える実践的なプロマネ力が身につくと思います。
次回は、終結フェーズで必要なことについて、考えてみたいと思います。
本日も最後までお読み頂き、誠に有り難うございました！
皆様との良きご縁に深く感謝申し上げます m - - m
初月無料ですのでお気軽にお試しください。
バックナンバーも購入可能です。
【弊社のHP】
【弊社のFacebookページ】 ICT Solution合同会社