これからはじめる Webプロジェクトマネジメント

計画の立て方 Web  Project  Management  for  beginner

千葉 礼美 ‒ Chiba Reimi

自己紹介

2

はじめまして、千葉と申します。

新卒で入社しプロジェクトマネジメント部に配属、 多種プラットフォームでのWebサイト制作・アプリ開発に携わりました。 2012年には新規プロジェクト立ち上げメンバーとしてベトナムへ赴任し、現地でのプロジェクトマネージャーを務めて帰国。赴任先での交流や経験を活かし、帰国後は受託開発に携わっています。

株式会社バイタリフィ プロジェクトマネージャー 千葉礼美 ‒ Chiba Reimi

3

てぃば@rechiba3

4

このアイコンの人です。

http://www.slideshare.net/re_3_19/ss-13898179

2012年6月～9月、ベトナムへ赴任。

slideshareにて赴任レポートをまとめているので、興味ある方はぜひともご覧くださいませー！

5

http://rechiba3.net/

ブログやってます

イベント参加のこと/Webのこと/ベトナムのこと 6

http://www.slideshare.net/re_3_19/

外部勉強会によく出没します。

スライドはSlideshareにて共有中！ 7

プロジェクトマネージャー歴

8

2011年

Webディレクター

2012年 2013年

アプリPM

新規事業PM

学年でいうと3年生ですね！

PMの肩書ゲット

PM3年生から1年生へ向けて

9

Web  Project  Management  for  beginner

アジェンダ 1.　知識体系ガイド「PMBOK」

–  PMBOK(ぴんぼっく)とは –  PMBOK定義、“10個の知識エリア” –  “10個の知識エリア”に沿う理由

2.　5つのマネジメントポイント 1.  タイムマネジメント 2.  コストマネジメント 3.  リスクマネジメント 4.  コミュニケーションマネジメント 5.  品質マネジメント

3.　計画の立て方 –  計画のワークフロー

1.  プロジェクトチャーターの発行 2.  工数の見積もり、制作範囲の確認 3.  スケジュールの作成 4.  メンバーアサイン、リソースの確保

4.　質疑応答

10

10m

20m

10m

10m

1.　知識体系ガイド「PMBOK」

11

PMBOK(ぴんぼっく)とは

プロジェクトマネジメント協会が発行する、

「プロジェクトマネジメント知識体系ガイド」 のこと。 「プロジェクトマネジメント」は、建造、製造、ソフトウェア開発、アプリケーション開発などなど、様々な分野で広く適用され

ている国際標準です。 ものづくりに関わる方、ぜひ、目を通してみてください。

12

プロジェクトマネジメント, PMBOK

1-1

Q Q.　PMBOK知ってる人ー？

13

1-1

PMBOK定義、“10個の知識エリア” 1.  プロジェクト統合マネジメント 2.  プロジェクト・スコープ・マネジメント 3.  プロジェクト・タイム・マネジメント 4.  プロジェクト・コスト・マネジメント 5.  プロジェクト品質マネジメント 6.  プロジェクト人的資源マネジメント 7.  プロジェクト・コミュニケーション・マネジメント 8.  プロジェクト・リスク・マネジメント 9.  プロジェクト調達マネジメント 10. プロジェクト・ステークホルダー・マネジメント

14

10個の知識エリア

1-2

“10個の知識エリア”に沿う理由

プロジェクトの開始時点で、10個の領域を把握していなくては！と意識が働きます。

あらゆる要素を網羅し、「あ、忘れてた！」を防ぐことで、より正確なプロジェクトチャーターを定義することができるのです。 PMBOKは、世界中から寄せられた知識で作り上げられました。 先人のナレッジをありがたく活用させてもらいましょう。

15

プロジェクトチャーター

1-3

10個の説明は割愛して…

16

2.　5つのマネジメントポイント

17

5つのマネジメントポイント

1.  タイムマネジメント

2.  コストマネジメント

3.  リスクマネジメント

4.  コミュニケーションマネジメント

5.  品質マネジメント

18

これらポイントを説明をします。

タイムマネジメント

時間あたりの生産性を高める時間管理のこと。 作業項目とそれにかかる工数を把握し、時間効率を管理する必要があります。 さらに、時に応じて優先順位を即座に決定できることも大切です。

19

2-1

コストマネジメント

20

決められた予算を元に、成果物を実現させられる資源を調整すること。 金額、タスク、人員を、的確に予算内で提供できるよう調整する必要があります。さらに、プロジェクト進行中は見積に見合っているかを管理します。

2-2

リスクマネジメント

21

作業を進めるにあたり、どのような課題が発生し得るか事前に想定できること。 また、想定できる課題に対し、どのように対処すべきか対策を考えられることが求められます。

2-3

コミュニケーションマネジメント

22

チームメンバーやクライアントなど、プロジェクトに関与するすべて人とのコミュニケーションルールを定めること。さらに、各個人の考えや共有すべき情報を密接にできるよう働きかける必要があります。

2-4

品質マネジメント

23

成果物の達成度合いを定め、それが評価されるすべての条件が完了できている か確認、監視すること。 また、それらの完了に向けた工程管理をする必要とします。

2-5

5つのマネジメントポイント

以上、説明した5つのポイントを押さえながら、

計画の立て方を学んでいただきます。 24

3.　計画の立て方

25

計画のワークフロー

26

1.　プロジェクトチャーターの発行

2.　工数の見積もり、制作範囲の確認

3.　スケジュールの作成

4.　メンバーアサイン、リソースの確保

1.　プロジェクトチャーターの発行 プロジェクトチャーターとは・・・

27

プロジェクトを具体的に推進するための計画書です。 チームに関わるすべての人が、要件を理解している必要があります。 その要件がまとまっているのがこのプロジェクトチャーター。このフローがはじまった時点で、プロジェクトマネージャーがアサインされます。

3-1

1.　プロジェクトチャーターの発行

28

1.  プロジェクトの目的 2.  プロジェクトの発足理由 3.  制作物、成果物となるもの 4.  プロジェクトのゴール、達成すべき要求 5.  前提条件、制約条件 6.  懸念となること 7.  工期、工程外の作業把握 8.  プロジェクト体制

プロジェクトチャーターに必要な項目

3-1

1.　プロジェクトチャーターの発行

29

顧客がそのプロジェクトに期待すること、望む成果物、ユーザーの得られる満足体験などを共有します。

誰のためにどのような工夫をしていくのかを明確にするフェーズです。

1.　プロジェクトの目的

3-1

1.　プロジェクトチャーターの発行

30

プロジェクトの背景を全体で共有している必要があります。

どのような問題・課題があったのか、どのような理想を見てはじまったのか、洗い出しましょう。

2.　プロジェクトの発足理由

3-1

1.　プロジェクトチャーターの発行

31

設計書の作成はこちらの作業になるのか、ソースファイルだけなのか、ビルドファイルも含まれるのか、デザインは全画面分必要なのか、 などなど…

見込まれる作業は全て把握し、中間ごとの成果物・最終成果物の認識を共有しましょう。

3.　制作物、成果物となるもの

3-1

1.　プロジェクトチャーターの発行

32

納品までに審査や稼働判定があるのか、リリース後までプロジェクトの存続はひつようであるのかを事前に決めましょう。

バグのFix、OSごとの不具合対応など、具体的で明確な達成すべき要求の理解を行いましょう。

4.　プロジェクトのゴール、達成すべき要求

3-1

1.　プロジェクトチャーターの発行

33

開発テスト環境の有無、顧客が確認で使用するデバイスやOSの種類、ライブラリ、APIの仕様などなど…

確認すべき前提条件があり、それを理解した上で仕様を定義するようにしましょう。

5.　前提条件、制約条件

3-1

1.　プロジェクトチャーターの発行

34

そのプロジェクトにはどのようなリスク、懸念点があるかを把握しましょう。 •  バグの再現ができない。

–  特定の環境で発生するため、我々が確認できない。

•  納期が短い。 –  顧客の期末に合わせる必要があるため、リリースが決められている。

6.　懸念となること

3-1

1.　プロジェクトチャーターの発行

35

サーバーの用意やドメイン取得など、クリティカル・パスからはずれる作業はたくさんあります。 ただ、寸前まで忘れることのないように意識する必要があります。

作業ひとつひとつの粒度を細かく、忘れずにいましょう。

7.　工期、工程外の作業把握

3-1

1.　プロジェクトチャーターの発行

36

商流の把握をしましょう。 デザインの決定権、機能仕様の最終決定の権限を持つものは誰か、そ

して、権限者へ話がすべて共有されるまでどれほどの時間がかかってしまうのか… 機能や稼働フェーズによってたずねる人が変わってしまうので、それらの人の動くスケジュールを把握までできたら最高です！

8.　プロジェクト体制

3-1

1.　プロジェクトチャーターの発行

37

1.  プロジェクトの目的 2.  プロジェクトの発足理由 3.  制作物、成果物となるもの 4.  プロジェクトのゴール、達成すべき要求 5.  前提条件、制約条件 6.  懸念となること 7.  工期、工程外の作業把握 8.  プロジェクト体制

プロジェクトチャーターに必要な項目

3-1

2.　工数の見積もり、制作範囲の確認

38

3-2

1.  超概算見積もり –  「Instagramみたいなアプリ作るのにいくらかかりますか？」というときに算出する見積もりです。精度はそこまで高くありません。予算確保の感覚値です。

2.  概算見積もり –  精度はちょっと高くなります。クライアントから提示される資料や、打ち合わせでヒアリングした内容に基いて工数、必要なリソース、納品物、仕様の策定を行って算出します。

3.  本見積もり –  必要な機能で予算を超えてしまう、が無いように少しだけ工数を多めにみたり、精度を高めることも大事です。

見積もりの種類

3.　スケジュールの作成

No. 項目 担当 開始日 終了日

12月

16日  (月)

17日  (火)

10_要件定義

10-­‐01 サイト分析 千葉 2013/12/16 2013/12/17

10-­‐02 コンテンツ精査 千葉 2013/12/18 2013/12/19

10-­‐03 ディレクトリ構造設計 千葉 2013/12/20 2013/12/24  

10-­‐04 仕様策定 千葉 2014/01/6 2014/01/10

39

3-3

3.　スケジュールの作成

40

3-3

1.  スケジュール、画面仕様書、機能一覧表などなど、コンテンツ作成に関わるものには共通のIDを振る

2.  項目を大項目、小項目、内容、とカテゴライズする

3.  担当者を明確にする

4.  開始日、終了日をガントチャートに盛り込む

5.  クリティカル・パスを抑える

6.  タスクとタスクの関連性を予期しておく

クリティカル・パス

Q Q.　スケジュールが遅れたとき、 　　どうしますか？

41

3-3

3.　スケジュールの作成

42

3-3

スケジュール遅延時の対策　前

アクティビティ  A

アクティビティ  B

図のように、アクティビティ Aが終わってからアクティビティ Bを始められるという関係をずらします。

3.　スケジュールの作成

43

3-3

図のように、アクティビティ Aが終わってからアクティビティ Bを始められるという関係をずらします。

スケジュール遅延時の対策　後

アクティビティ  A

アクティビティ  B

アクティビティ  A-­‐2

アクティビティ  B-­‐2

4.　メンバーアサイン、リソースの確保

なるべく、「あー、あの人向いてるなあ」という特徴を掴んでアサインするようにしています。

誰にでも、経験に基づいた自信、得意なテイスト、得意な体制などがあります。 所属している組織、会社であるのならば、 その組織内でのメンバーのリソース自体把握しましょう。 プロジェクトにとどまらず、メンバー個人リソースを考慮できれば、不測の事態への対応もフットワーク良くなりますよ！

44

3-4

計画を立てるということ ちなみに・・・ よく、「IE爆発しろ！」とか「Android爆発しろ！」という つぶやきや叫びが聞こえますが、それって、明らかに

プロジェクトマネージャーか、プロデューサーの計画ミスだよねって、私は思うんですよ。

45

IE爆発しろ！, Android爆発しろ！

　　　❤　顧客の要望を落とし込んだ仕様 　　　❤　進行管理者、制作者、開発者の承認を得た仕様 　　　❤　ユーザーが幸せになれる仕様

すべてのプロジェクトが気持よくまわり、 ものづくりに関わる皆がご飯を美味しく 食べられますように！

46

あなたが考える、 案件をはじめる前に考えられるリスク を教えてください。

47

レポート課題の発表