株式会社WAP tech blog

東京の企業コンサルティング会社 | 株式会社WAP

初めてのプロジェクトマネージメント(2)立ち上げ

プロジェクトを立ち上げよう

startup.png

自分のプロジェクトマネージメントの考え方が整理できたら、具体的にプロジェクトの立ち上げを進めていきましょう。何も難しく考える必要はありません。一番最初にやることはプロジェクトの関係者は誰か、どのような体制で進めるか、各人の役割は何か、定期的な会議体はどうするかです。

サンプルプロジェクトに対して、PMBOKの5つのプロセスに沿った形で解説していきます。今回は(2)立ち上げです。

ステークホルダー特定

このプロジェクトのステークホルダー(利害関係者)は誰か?を特定します。特定したステークホルダーの情報をステークホルダー一覧にまとめておきます。

収集する情報は名前、所属、部署、役職、連絡先などになります。

資源マネジメントの計画

ステークホルダー一覧をもとに、プロジェクト組織図(体制図)にプロットします。まずはプロジェクトマネージャーが叩き台として作成します。その後、全員に抜け漏れがないかを確認してもらって完成となります。

コミュニケーション・マネジメントの計画

体制図をもとに、プロジェクトメンバー全員を集めて以下の内容を確認し合意を得ます。確認点はこんな感じです。

  1. ステークホルダーに過不足はないか?
  2. 体制図に問題はないか?
  3. 体制図に登場するステークホルダーの役割は何か?
  4. プロジェクトにおける最終的な意思決定者は誰か?

これら合意が取れたら、次はプロジェクトの定例会議について合意を得るといいと思います。内容はこんな感じ。

  • 目的
    • 進捗の共有
    • 課題の共有
    • 課題の解決
    • プロジェクトオーナーによる意思決定
  • 参加者
    • 必須
      • プロジェクトオーナー
      • プロジェクトマネージャー
      • 各部のリーダー(プロジェクトリーダー)
    • 任意
      • その他のプロジェクトメンバー
  • 開催日時
    • 毎週火曜日 11:00〜12:00

要求事項の収集

まず初めに行うのが要求事項の収集です。これはプロジェクトマネージャーが一人で行うのではなく、プロジェクトメンバー全員で行い、プロジェクトマネージャーがリストにまとめます。

「要求事項の収集」という文字面だけみると小難しいことをやる必要があるという印象を受けがちですが、簡単に表現すると「このプロジェクトで実現したいこと」を挙げていけばいいだけです。

この段階では実現可能性・予算・期間などを考慮する必要はありません。まずは記入者、何をやりたいか、具体的な内容までをメンバーに記載してもらいます。次にディスカッションの場で上がった意見を検討し、実現するための課題を洗い出すという流れで進めるのがいいと思います。

要求で考慮した方が良さそうな点

webサービスの表現方法などは知的財産権(特許権、実用新案権、意匠権及び商標権)に抵触する可能性があります。(例えばAmazonの1-Click購入など)抵触した場合、知的財産権を所有する会社の弁護士などから期限付きの利用停止依頼がきたりします。特許情報プラットフォームなどで事前に調査しておくとリスクを回避できると思います。

また見落としがちな点としては、利用規約などで収集したデータの第三者提供について言及されていない場合、データを社外に出すことができないというケースがあり得ます。そのため法務担当やコンプライアンス担当にどのようなデータを外部に提供するのか、その際のルールや受け渡しに関わるレギュレーションがないか、また利用規約などの変更が発生するかなどは先んじて相談しておくといいと思います。

調査

システム、データ、分析、業務、データの受け渡しなど要求を実現するために必要と思われるものについては事前に確認を取るといいでしょう。

これらの調査をせずにプロジェクトを進めた結果、リリース直前に行われる受け入れテストで発覚し大きな手戻りになったり、リリース後に運用でカバーした結果運用メンバーの業務コストが膨大になってしまうといったことが良くあります。

調査した結果、考慮していなかった機能や今まで人手で対応していたがゆえにヒューマンエラーの原因になっていた部分も可視化されることになります。これらを要求に追加しておくことにより、手戻りが起こる確率を減らすことができる可能性が高くなります。

品質マネジメントの計画

品質マネジメント計画では以下の内容について定義をしておきます。プロジェクトが大規模になればなるほど品質マネジメント計画は重要度を増して行きますが、サンプルプロジェクトくらいの規模であればそこまで難しいものにはなりません。

品質の評価基準について

バグ検出数などを設定する場合が多いですが、サンプルプロジェクトの基準としては過大だと考えます。今回は以下のように定義することとします。

  • 受け入れテスト完了の項目数が受け入れテスト全項目の95%以上となること。

バグの管理方法

バグ管理シートについて、以下の内容を定めておきます。

  • 誰が管理するか(ステータス管理含む)
  • 誰が記載するか
  • いつ確認をするか
  • バグの解決はいつどこで行うか
  • 管理シートの記載項目はどのようなものか

バグ管理シートのサンプルを掲載しておくので、参考にしてください。ステータス変化は以下のようなイメージです。

最後に

いかがだったでしょうか。耳慣れない用語が多く登場したかとは思いますが、過去やったことがないことはほとんどないのではないかと思います。ですがこの立ち上げプロセスをおろそかにしてしまうと、プロジェクト終盤に何倍もの工数で跳ね返ってくるケースが多々あります。

労力はかかりますが、非常に重要なプロセスだと思うので気合を入れて臨みましょう。かく言う私も立ち上げプロセスはかなり気合を入れて望むようにしています。

宣伝

株式会社WAPでは「日本企業が世界と戦うための伴走型リーダー育成」をミッションに掲げています。この困難なミッションに共に立ち向かってくれるプロジェクトマネージャーを募集しています。ちょっと気になったので話を聞いてみたい!という方も大歓迎です。Meetyにてお気軽にお申し込みください。