プロジェクトマネージャーに抜擢されたが、右も左も分からないぜ！
というあなたに向けて、プロジェクト進行の骨子を説明するよ！
この記事は3部構成でお届けしています。
前編で、一般的なシステム開発プロジェクトの全体像を、
中編で、プロジェクト開始直後の具体的な進め方を、
後編で、プロジェクトマネージャーが力を入れるポイントと考え方を説明します。
前編がまだの方は、前編からお読みいただければと思います。
- 前編記事でやることの全容は分かった！ で、何からやれば・・？
- RFP（提案依頼書）と提案書の読み込みと理解
- プロジェクト憲章の作成
- プロジェクト計画書の作成
- WBSの作成
前編記事でやることの全容は分かった！ で、何からやれば・・？
＜この章の前提＞
ここでは、プロジェクトの受注活動は済んだものとします。（つまり契約済み）
受注活動は、プロジェクトのコントロールのために押さえておくべき重要なパートなのですが、
PMBOKには含まれない領域ですので、一旦スキップして別途解説します。
さて、何から手を付けようか？
まずは以下の順番でやってみましょう。（一部、前編でお伝えした順番と変えてますが、今は気にしないで。）
- RFP（提案依頼書）と提案書の読み込みと理解
- プロジェクト憲章の作成
- プロジェクト計画書の作成
- WBSの作成
１．RFP（提案依頼書）と提案書の読み込みと理解
まずはRFP（提案依頼書）と提案書から、以下を理解します。
- プロジェクトの概要
- 目的、目標（成果物）
- 課題、背景
- 予算
- スケジュール
- ステークホルダー
- 具体的にやること
なぜこのプロジェクトが立ち上がったのか。背景にある課題は何か？
何をやれば（作れば）その課題が解決するのか？誰が幸せになるのか？
予算とスケジュールはどうなっているか？本当にその予算とスケジュールで実行可能なのか？
プロジェクト全体のステークホルダーマップはどうなっているか？
また、RFPと提案書の間に矛盾点がないことも確認します。
RFPの要求事項に対して、提案書の内容に過不足があるのはよくあることです。
RFPに対して過大な提案も問題有りなのですが、まずは抜け漏れを全力で防ぎます。
※抜け漏れがあると、「この人たち、ちゃんと読んでくれてるのかな？」と不安に思われてしまうし、気づくのが遅れると、予算不足や開発の手戻りが発生してしまう。
RFPと提案書はプロジェクトの頂点に位置するドキュメントです。
そのため、プロジェクト全体の工程に渡って、言った言わないの論争になった際などに絶大な威力を発揮します。
ところでRFPって何よ！略語やめて！
すみません、説明してませんでした。
RFPは「Request for Proposal」の略で、日本語では「提案依頼書」と言います。
これは企業（クライアント）がベンダーに対して、提案や見積もりをお願いするために作る資料です。
通常は企業側が作成します。
このRFPを何社かのベンダーに渡して、一番良い提案をしてくれたベンダーを選ぶわけですね。
RFPには企業側の夢や希望が詰め込まれていますので、プロジェクトの源流にあたる情報の宝庫です。
私はプロジェクトの途中でも度々読み返しています。
余談ですが、RFPの存在しないプロジェクトにはご注意ください。
企業側が、自分たちがやりたいことを言語化できていない（言葉で説明できない）状態ですので、
目的や目標をはっきりさせるところから始める必要があります。（これをやらないと、安定したプロジェクト進行が難しくなる）
２．プロジェクト憲章の作成
次にプロジェクト憲章を作成します。
憲章（けんしょう）・・・、聞き慣れない言葉ですね。
プロジェクト版の憲法みたいなものだと考えてOKです。
これからプロジェクトを始めるにあたって、まずは法整備的なものが必要ということですね。
主な目次は以下です。
- プロジェクトの概要、目的、目標、主な要求事項
- 成果物一覧の作成
- 全体スケジュール（主要なマイルストーン）の更新、精緻化
- その他色々
これ、あまり難しく考える必要はなくて、
「１．RFP（提案依頼書）と提案書の読み込みと理解」で理解したRFPや提案書の情報を言語化して書いていけばOKです。
しかし、単にコピペすればよいわけではなく、
RFPをあなたの頭で一旦咀嚼したうえで、誰が読んでも同じ解釈となるような文章で記載していく必要があります。
ここで勘の良いあなたは気づいたことでしょう。
「RFPとプロジェクト憲章って、一部内容ダブってないか・・・？」、と。
答えはYESです。
じゃあ何でプロジェクト憲章を作る必要があるのかというと、
RFPって、「クライアント語」で書かれていることがほとんどで、略語も多く、ベンダーの中の人の解釈が定まらないものが多いんですよね。
この章の冒頭で、プロジェクト憲章は「プロジェクト版の憲法みたいなもの」と書きました。
つまり、これからプロジェクトに関わる人たち全員にとっての「憲法」となるわけです。
その「憲法」が、読んでも理解できない代物だったり、人によって解釈の異なる文章では困るわけです。
RFPとプロジェクト憲章は、以下の関係にあると理解して良いでしょう。
＜RFP＞
クライアントが作る、「この内容でお願いね！」という文章
＜プロジェクト憲章＞
ベンダーが作る、「私たちはこう解釈しました！」という文章
３．プロジェクト計画書の作成
次はプロジェクト計画書の作成です。
- 主な目次は以下です。
- プロジェクトスコープ定義書の作成
- マスタースケジュールの作成
- コミュニケーション計画の作成
- 主要リスク一覧表の作成
- テスト計画の作成（暫定版）
- トレーニング計画の作成（暫定版）
- システム導入（移行）計画の作成（暫定版）
- その他色々
これはプロジェクト憲章の内容を基に、上記のような内容をざっくり取り決めます。
この時点では分かっていない情報の方が多いので、ある程度は仮定の上で書いていきます。
（テンプレート化しておくと、次から楽です）
資料の性質としては、プロジェクト憲章の続きのような性格のものです。
さらっと書いてますが、プロジェクト計画書も作るのがまぁまぁ大変な資料です。
これは別の記事で詳しく解説しますね！
４．WBSの作成
次はプロジェクト進行の三種の神器の一つ、WBS（Work Breakdown Structure）の作成です。
内容はとてもシンプルで、プロジェクトでやること（とその予定日など）が、一挙一動レベルで箇条書きされているだけのものになります。
しかし、プロジェクトマネジメントにおいて正しく理解されていない、正しく使われていないドキュメントランキングがあったとしたら、
WBSはナンバーワンなのではないか、と思うくらい作るのが難しく、手のかかるドキュメントです。
かくいう私も、毎回四苦八苦して作っています。
ではここで、Webサイトを新規作成する際のWBSの例を見てみましょう。
1 ウェブサイトプロジェクト
1.1 プロジェクト管理
1.1.1 プロジェクト計画
1.1.1.1 プロジェクト目的を明確化する
1.1.1.2 スケジュール作成のためのタスクを識別する
1.1.1.3 必要なリソース（人員、予算、設備など）を決定する
1.1.1.4 リスク管理計画を作成する
1.1.2 スコープ定義
1.1.2.1 サイトマップを作成する
1.1.2.2 サイトの目的、機能、および特徴を定義する
1.1.2.3 開発範囲の範囲を決定する
1.1.3 スケジュール作成
1.1.3.1 各タスクの期間を推定する
1.1.3.2 各タスクの依存関係を特定する
1.1.3.3 プロジェクトの全体スケジュールを作成する
1.1.4 予算作成
1.1.4.1 必要なリソースの費用を見積もる
1.1.4.2 経費予算を作成する
1.2 ウェブサイト設計
1.2.1 サイトマップ作成
1.2.1.1 サイトの階層構造を決定する
1.2.1.2 サイトのメインナビゲーションを決定する
1.2.2 ワイヤーフレーム作成
1.2.2.1 各ページのレイアウトを決定する
1.2.2.1.1 ページA
1.2.2.1.2 ページB
1.2.2.1.3 ページC
1.2.2.2 各ページの要素（画像、テキスト、ボタンなど）を決定する
1.2.2.2.1 ページA
1.2.2.2.2 ページB
1.2.2.2.3 ページC
1.2.3 デザイン作成
1.2.3.1 デザインスタイルを決定する
1.2.3.2 サイトのロゴ、色、フォントなどの要素を作成する
1.3 ウェブサイト開発
1.3.1 フロントエンド開発
1.3.1.1 HTMLコーディングを実装する
1.3.1.1.1 ページA
1.3.1.1.2 ページB
1.3.1.1.3 ページC
1.3.1.2 CSSスタイリングを実装する
1.3.1.2.1 ページA
1.3.1.2.2 ページB
1.3.1.2.3 ページC
1.3.1.3 クロスブラウザ対応を実装する
1.3.2 バックエンド開発
1.3.2.1 サーバーサイドのプログラミングを実装する
1.3.2.2 データベースの作成および設定を実装する
1.3.2.3 APIの作成および設定を実装する
1.3.3 コンテンツ作成
1.3.3.1 サイトのコンテンツを作成する
1.3.3.2 SEOに最適なキーワードを使用する
1.3.4 ウェブサイトテスト
1.3.4.1 単体テストを実行する
1.3.4.2 統合テストを実行する
1.3.4.3 ユーザーテストを実行する
1.4 ウェブサイト公開
1.4.1 ウェブサイトのデプロイ
1.4.1.1 サーバーへのファイルのアップロード
1.4.1.2 ドメイン名の設定
1.4.1.3 SSL証明書の設定
1.4.2 ウェブサイトの監視
1.4.2.1 ウェブサイトのトラフィックの監視
1.4.2.2 ウェブサイトのアップタイムの監視
1.5 プロジェクト完了
1.5.1 プロジェクトの納品
1.5.1.1 クライアントとの最終納品物の承認を取得する
1.5.1.2 クライアントへのファイルの引き渡しを実施する
1.5.1.3 クライアントとのサポート契約を締結する
1.5.2 プロジェクトの閉鎖
1.5.2.1 サイトメンテナンスのためのドキュメントを整理する
1.5.2.2 プロジェクトのアーカイブを作成する
1.5.2.3 プロジェクトに対する報告書を作成する
まぁ、、、思考停止しますよね（笑）
ただ、落ち着いて一行ずつ読んでいくと分かると思いますが、
先頭から順番に処理していけば、プロジェクトが完了するイメージが持てませんか？
WBSの目的は大きく２つあります。
- 作業の抜け漏れを防ぐこと
（タスク一覧としての性質） - ゴールまでの道筋を見えるようにすることで、プロジェクト関係者の心の平安を保つこと
（目的地までの地図みたいな性質。期間の長いプロジェクトでWBSが無いと、「一寸先は闇」の状態になってしまう。）
重要なのは、最初から細かい粒度で書き始めないことです。
最初は粗い大項目くらいで書き始めて、社内外のレビューを経ながら（プロジェクトを進行させながら）徐々に詳細を書き加えていけばOKです。
そう、WBSはプロジェクト初期に完成させる必要があるものではなく、プロジェクト全体を通して育てていくドキュメントになります。
冒頭で「手がかかる」と書いたのはこういう意味で、プロジェクト全体を通じて、その内容に改廃が発生し続けます。
また、WBSの運用で躓くのは、大体以下の４点です。
- 抜け漏れなくタスクを書き出すこと
- 全体の粒度を合わせること
- 誰が読んでも同じ解釈ができること
- 日々のアップデート
おさらい。
WBSは、そのプロジェクトでやることが、一挙一動レベルで箇条書きされたものです。
やることが毎回大体同じというプロジェクトでもない限り、WBSが無いとストレスフルなプロジェクトになります。
まとめ
いかがでしたでしょうか。
この時点で既に脳みそフル回転だと思います。
後編の記事で書きますが、プロジェクトマネージャーはプロジェクトの開始時点が一番大変なのです。
少し休憩してもらって、後編の記事にお進みください。
中編は以上！あなたのプロジェクト運営の一助になれば幸いです。
当記事のステップアップ図書
マンガでわかるプロジェクトマネジメント
プロジェクトマネージャーの仕事を追体験できる良書です。
漫画と侮るなかれ。プロジェクトマネジメントの実務に必要な要素は網羅されています。
この本で、プロジェクトマネジメントの仕事のとっかかりは掴めます。
私は躓くたびに読み返しています。
「プロジェクトマネジメント」実践講座
私が勝手に敬愛する伊藤大輔さんの本です。
実践寄りの本ですが、未経験者が読んでも理解しやすいと思います。
（この方は、物事をかみ砕いて説明するのがとても上手です。）
困ったところだけをピンポイントに読めるようになっている構成も秀逸です。
当記事の関連記事
このブログは、日本のプロジェクトマネージャーの仕事のレベルを底上げし、
本人とそのチームの人々の人生を幸福にすることを目的に、プロジェクトマネージャーの仕事に関する記事を書いています。
私自身も道半ばゆえ、至らぬ点も多々あるかと思いますが、記事の感想やリクエストをいただければ
できるだけ記事にしてお応えしますので、皆様の忌憚のないご意見をいただけますと幸いです。
コメント