![見出し画像](https://assets.st-note.com/production/uploads/images/98232854/rectangle_large_type_2_61e1972b84a1c55336986c6d6df97f89.jpeg?width=1200)
プロジェクト計画書の作り方
おはようございます。
前回に引き続き、プロジェクトマネジメントについて学習しております。
PMとしての役割や具体的な行動については前回までに整理できました。ここからは開発のプロセスごとに、どのような行動をしていけば良いのか、作成する成果物と共に整理して見ました。
以下の書籍以外にもUdemyやネット検索で調査しました。
その中でも、正式に関わったことがなかったプロジェクト計画策定のプロセスについて、今後関わっていくことが増えていくと思うので、この場でアウトプットしようと思います。
プロジェクト計画書に必要なコンテンツ
プロジェクト計画書は具体的な開発が開始する数日前には作成を完了し、ステークホルダーから商品を得ている必要があります。
この計画書に基づいて、プロジェクトは開始されます。
その計画書に必要なコンテンツを整理しましたので、いかに記録します。
背景と目的
スタート地点として間違えてはいけないのが、まずそのプロジェクトが発足した背景と目的を確認することです。
プロジェクトを通じて、参画する全メンバーにこの目的を認識しておいてもらう必要があり、それによって一貫性のある成果物やメンバー個々人のリーダーシップ発揮につながります。
しっかりと計画書に明記することによって、全てのステークホルダーに周知させる必要があります。
プロジェクトのスコープ
続いて、このプロジェクトのスコープ範囲を定める必要があります。どこからどこまではプロジェクトの対象であるかということ、逆にいうとプロジェクトの対象外の範囲を明記することによって、後からの追加要求や認識の齟齬によるクレームを防ぐ効果があります。
目標及び成功基準
目的を達成するための、プロジェクトの目標と成功基準を設定します。
プロジェクトの終了段階で、ここに明記した目標と成功基準を達成したかどうかでそのプロジェクトが成功したのか、失敗したのかが判断できます。
具体的で定量的な目標と成功基準を設定することでゴールが明確になり、目指すところの共通認識を持つことができます。
現状の課題とソリューション
業務システムの刷新のように、既存システムで発生している課題に対して、新規システムで解決するようなプロジェクトの場合は、これを記載しておくとスポンサーとの認識合わせになりますね。
要件定義レベルまでは行かないまでも、大きめの粒度でどのようなソリューションを提供するのかが明確になっていると、後続のプロセスの見積もりもしやすくなると思います。
タスク&成果物一覧
ここで登場するのがWBSですね。最終的な成果物を定め、そこからブレイクダウンしてタスクに分解していきます。基本的に一つ一つのタスクに成果物が紐づいていることが重要で、その成果物の作成完了によってタスクの完了を判断します。
この成果物一覧に漏れがないことをスポンサーから承認を得ることで、タスクに漏れがないことを確認します。
マスタスケジュール
ウォーターフォール型では要件定義・基本設計・詳細設計・実装のようにいくつかの開発プロセスに分かれます。このくらいの粒度で各プロセスの開始と終了時期をざっくりと定めます。
それ以外にもプロジェクトで考慮すべきマイルストンがあればそれを明記し、プロジェクトの全体スケジュールをざっと把握できるようにします。
プロジェクト体制
このプロジェクトにどんなチームがあって、それぞれのチームがどんな役割を担っていて、役割ごとの責任者が誰なのかを定めます。
ここで正式にプロジェクトにアサインされるメンバーが決まるとともに、各プロセスや成果物における意思決定権がどこにあるのかを明確にします。
適切に権限移譲することで、意思決定スピードが早まり、プロジェクトの効率化につながります。
管理方針
管理方針には、進捗管理・課題管理・品質管理の3つがあります。
進捗管理方針では、いつ・どのメンバーで・何の打ち合わせをするかを定めます。それと共に何を用いて進捗管理を行うかもここで定めますので、WBSの種類やフォーマット、進捗管理の対象や集計方法も定める必要があります。
課題管理方針では、WBSに記載されていない課題が発生した場合に、どのメンバーで会議を開催し、どのようなツールを使って管理するか、どのようなフローで課題解決を進めていくかを定めます。
品質管理方針では、各成果物について、どのタイミングで誰がレビューを行うのか、そしてレビュー結果(指摘と対策)をどのように記録に残して集計するのかを定めます。レビュー実績は最終的にスポンサーに報告書として提出することでしっかりレビューしましたよと伝えたりしますので、レビュー結果を丁寧に記録することは意外と重要です。
これら以外にも、プロジェクトの制約条件や前提条件、想定リスク一覧、概算予算など、必要に応じて項目を追加すれば、それなりに質の高い計画書が作成できそうです。
計画書作成時の注意点
上記のコンテンツを一つずつ定めて記載していくのがプロジェクト計画段階で必要なことになりますが、その際に注意すべきこといくつか挙げられていました。
①どこかで割り切ること
各タスクの工数や、必要なコストを計画段階で正確に見積もることはほとんど不可能だと思って良いです。
正確に・詳細に見積もろうとすればするほど計画に時間がかかってしまいますので、どこかで割り切りましょうということです。
プロジェクトを進めながら、段階ごとに見積を補正して正確性を上げていけば良いということを心に留めておきます。
②バッファの考え方
工数やコストを見積もる際、バッファをある程度仕込んでおくことはリスク対策として必要なことでしょう。
このバッファですが、各タスクにまぶしていくのか、最後に全体に対してまとめたバッファを設けるのとどちらが良しとされていると思いますか?
後者の方が好ましいそうです。
この裏付けとして、パーキンソンの法則が挙げられていました。
「パーキンソンの法則」
ヒトは与えられた時間を全て使い切るようにタスクの作業スピードを無意識的に調整する。
ということで、一つ一つのタスクにはバッファを設けずに、バッファなしの納期を目指して作業してもらうと。それでも何か問題が発生した場合には、バッファを見ながら解決していくという考え方が重要だそうです。
まとめ
ここまで、プロジェクト計画段階で定めるべき項目と注意点についてまとめて見ました。
こうやってあげてみると決めなければならないことがたくさんあってびっくりしました。
計画がその後の作業の質を決めるとはよく言いいますが、それだけ計画の重要性を再認識できました。
次は、ウォーターフォール型開発アプローチの要件定義について整理してみようかなと思っています。
それでは。
この記事が気に入ったらサポートをしてみませんか?