new_window arrow_01 arrow_02 arrow_03 arrow_04 arrow_05 arrow_06 arrow_07 arrow_08 arrow_09 menu close metaphase facebook instagram twitter tumblr logo_metaphase

円滑な進行を行うために必要なプロジェクト計画書の作り方〜その2〜

PM

2022.02.10

前回の記事ではプロジェクト計画書とはどのようなものか、役割は何か、記載項目の一部を紹介させていただきました。今回は記載項目の続きで「マイルストーン及びスケジュール」から「プロジェクト体制」までを紹介します。

プロジェクト計画書の記載項目

 

5.マイルストーン及びスケジュール

各工程ごとにどの程度の期間を要するのかを定義をします。

タスクを細分化した詳細なスケジュール(WBS)であればスケジュールの策定が綿密になりますが、プロジェクトが始動したばかりの計画段階では全体的なスケジュールが伝われば十分です。(多少粗くても)プロジェクト完了までの妥当な進行が見通せる、また重要な節目や不可逆なポイントとなる部分にマイルストーンを設定して合意を得ることが大切です。
長期的なプロジェクトであれば、マイルストーンを設置することで、スケジュール通りに作業が進んでいるかどうか、遅れている場合は、どのタスクがどのくらい遅れているのかを把握することができます。一方で、2日で完了するような短期的なプロジェクト、イラストを1点描くといった単純なプロジェクトであれば意味をなさない可能性があるため、必ずしもマイルストーンを設ける必要はありません。

プロジェクト計画書を通して全体的なスケジュールやスコープが決まり次第、詳細なスケジュールを作成します。

(例)

6.制作仕様(検証OS・ブラウザ・端末)

大抵のWebサイト制作のプロジェクトにおいて、最終的な成果物・納品物になるのはhtml/css/jsといったウェブブラウザに表示するためのファイルになります。品質を保証するために表示や動作などのテストを実施しますが、事前に基本的な制作の仕様(保証範囲)について認識を合わせておくことは大切です。世の中にあるOSやブラウザ、端末の数は多く、OSやブラウザのマイナー/メジャーのバージョンまで掛け合わせると凄まじいです。仮に自社の都合で検証・保証対象を決めずに受け入れテストを実施した結果、想定もしていないOSや端末で表示崩れなどを指摘された場合には、作業負荷やスケジュール、コストに大きな影響を与えてしまうことも考えられます。保証範囲を各所と合意しておくことでリスクヘッジになるためプロジェクト計画書の1項目として決めておきたい項目になります。

決め方については様々方法がありますが、例えば自社で所有している範囲で検証可能な環境を策定したり、リニューアルであればGoogle Analyticsなどの解析ツールを使ってデバイス/ブラウザ/OS別の分析を行ったり、世の中のOSやブラウザのシェアを調べたりして策定するなど要件や環境に応じて検討します。

(例)
■PC
・Windows 10;Google Chrome、Microsoft Edge
・Mac Big Sur;Safari、Google Chrome
※ブラウザは検証時点での最新バージョン

■スマートフォン
・iOS 15.0;Safari;iPhone 13
・Android OS 12;Chrome;Google Pixel 6
 ※タブレット端末は非検証。

<参考>
StatCounter」では、OSやブラウザのシェアを簡単に調べることが可能です。

【注意】
マイクロソフトが標準のウェブブラウザとして搭載してきた「Internet Explorer」は、2022年6月15日をもってサポートの終了が発表されています。
しかし、業界や業種によっては利用をInternet Explorerを継続して使用している方も少なくありません。その場合はInternet Explorerについて対応が可能かを事前に確認するようにしましょう。

7.プロジェクト体制

プロジェクトの目的やゴール、スコープが見えてくればそれらを熟すために必要な役割と人材が見えてきます。その役割と人材を書き出して図にした「体制図」を作成します。

(例)

箇条書きでも体制を示すことは可能ですが、図の方が全体が一目で見渡せてプロジェクト立ち上げ時の利害関係者の理解を助けます。例えば、体制図を作成しておくことで、キックオフMTGなどで利害関係者が集まった際に体制の説明がしやすくなります。

体制図を一見すれば責任者や役割を一意に捉えることができる状態が作成時のポイントです。自分の担当以外がどのような役割をしているのかが把握できるため、メンバー間でコミュニケーションもとりやすいという副次的なメリットも生まれます。

また、プロジェクトに参加する人材とそれぞれの役割を定義できるだけでなく、メンバー間の指揮命令系統が明確になるようにすることも大切です。原則一つの箱に向かってくる線は複数書かずに原則1本にします。

プロジェクト始動段階でメンバー間で責任や役割を明確にして合意形成をしておかないと、問題が発生した際に混乱が生じます。そのためにもプロジェクト体制図をしっかり作ることはとても重要なことです。

なお、プロジェクトは進行の途中で新しくメンバーが追加になったり、交代するなど、体制が変更されることがあります。その際に利害関係者全員に変更点を周知するには図式化された体制図は便利です。

次回の記事では、プロジェクト計画書の残りの記載項目「コミュニケーションルール」から「リスク管理」についてお話ししたいと思います。

最新のブログ記事