プロジェクトマネジメントは仕組み化が9割
- 1. プロジェクトマネジメントは 2016/2/8 第1回 京都・大阪WebPMの集い @ Open VersionUp Project 仕 組 化 が９割
- 4. 4プロジェクトにおける失敗例 ! 十分なテスト期間を設けられず、本番後も障害多発 ! プログラマに仕様が間違って伝わり手戻りが発生 ! リリース前のチェック不十分で本番公開してから修正するのが常態化 ! 仕様をドキュメント化しておらず、人が抜けると誰も分からない状態に ! 受注後にお客様からの要望が膨らみ、工数が大幅に超過 ! 要件通りに実装したが「そんな事言ってない」と言われた ! リリース直前になってお客様の上司の鶴の一声で仕様変更が発生 ! 進 管理がうまく機能せず、リリース前は深夜残業が常態化
- 5. 5 ! メンバーのスキルの問題？ ! メンバーのマインドの問題？ ! 十分な時間がないから？ ! 予算が少ないから？ ! 人が足りないから？ ! お客様が無茶を言うから？ ! お客様の社内事情のせい？ 失敗の原因は何なのか？
- 6. 6失敗原因の大部分を占めるもの プロジェクトにおける問題の９割は コミュニケーションが原因で起きている ! 要件が変わったことの伝え漏れ ! 指示が誤解されて伝わっていた ! 仕様の認識に相違があった ! 他の人がやるタスクだと勘違い ! 連絡フローの順番を間違えていた
- 11. 11「グループ」と「チーム」の違い グループ ! 共通の性質で分類した人や物の一団。群れ。 ! 個々のメンバーの貢献の足し算が成果となる チーム ! 共通の目的のために協力して行動する集団 ! 個々のメンバーの貢献の掛け算が成果となる
- 13. 13 KGI : 年間粗利益 xxxx万円 KSF KPI 売上：xxxx万円 （昨対：xx％） 提案本数 受注率 案件単価 粗利率：xx% （昨対：xxx％） 原価工数 外注比率 売価 1. チームの目標 浸透しなければ意味がないので、 目立つ所に貼っておく＆毎月MTGで進 共有
- 16. 16アシストの例 ! PMが休暇中、Webディレクターが進 管理 ! 営業が費用交渉しやすいよう説明資料を準備 ! デバッグ要員が足りないのでPMがヘルプ ! プログラマが技術面でPMの提案活動をサポート ! デザイナーが提案資料のダブルチェック
- 18. 183. 評価基準の定義 プロジェクトチームとしての目標達成（業績評価） KGI：年間粗利益 KPI：売上、粗利率 メンバーそれぞれの評価ポイント（行動評価） 下記に関連する行動を評価とみなす ! Safety：安全性向上に関する行動 ! Satisfaction：満足度向上に関する行動 ! Quality：品質向上に関する行動 ! Relationship：関係性構築に関する行動 ! Speed：効率化に関する行動 ! Sales & Profit：売上・利益向上に関する行動
- 19. 19 Knowledge Safety Quality Speed Satisfaction Relationship Sales & Profit 3. 評価基準の定義 - 行動評価の関係性
- 20. 203. 評価基準の定義 - 行動評価の記録 行動評価管理シートに各自が記録していく PMは各メンバーの上司にフィードバックする カテゴリ 内容 日付 担当者 Speed データの受け渡しフォーマットを作成し、 レポート作成のやりとりを短縮 14/11/19 山田 Quality メール内にGIFアニメを入れ、クリック率 アップに貢献した 15/10/15 鈴木 Satisfaction 急遽発生した修正に柔軟に対応した事につ いてお客様から感謝の言葉をいただいた 15/12/22 佐藤 評価対象となる行動を起こすことにより 自然とチームワークが生まれ目標達成へ近づく
- 22. 22仕組み化例 - 会話の円滑化 用語辞典を作成し、チームメンバー間で共有。 わからない用語は都度追加していく Apple to Apple 同一条件下で比較すること カニバる カニバリゼーション。競合すること ASAP As Soon As Possible = できるだけ早く IP Intellectual Property = 知的財産 FY Financial Year = 会計年度 カイ二乗検定 A/Bテストの検証等に用いられる統計学の手法
- 24. 24仕組み化例 - リサーチと共有 GoogleアラートとZapierでお客様の動向をチェックし、 チャットワークに通知する仕組みを構築 この仕組みの作り方をブログにまとめました！ Googleアラート編： http://goo.gl/HYdFLR Zapier編 ： http://goo.gl/pjc8yY 例）マイクロソフト社のニュース通知
- 28. 28仕組み化のポイント 大きな問題になる前の小さな問題を見つける あえて言う程でもないけど気になっている事を 朝会やランチ・飲み会の場などで積極的に吸い上げる 問題を言い合える風土を作る 人にフォーカスして誰が悪いと非難するのではなく、 問題点にフォーカスして何を変えればいいか話し合う 改善した仕組みがうまくいっているか確認する 問題発見 仕組み化 問題の解決 結果の検証の繰り返し 1 2 3
- 30. 301. 体制図 社内各部署のメンバーと役割、外注先を明記し メンバー間で周知しておく。 また、お客様側の体制図、レポートラインも見える化して おくことである程度リスクを想定することができる。
- 35. AD 353. 施策マップ アパレルブランド⃝⃝の施策マップ Conversion 自社EC ZOZO TOWN SNS 直営店 複合施設 Curation iQON WEAR リスティング広告 ディスプレイ広告 Magazine AneCan
- 38. 385. 障害発生時のレポートライン 事故・障害発生時に速やかに情報が伝達するよう レポートラインを策定する。 PJチーム内での共有と、各部署の上長への共有の優先度や PMや営業が不在の時のフローも決めておく事がポイント。 個人携帯を記載した緊急連絡網も整備しておく 役割 氏名 会社携帯 個人携帯 PM ○○○○ xxx-xxxx-xxxx xxx-xxxx-xxxx 営業 ○○○○ xxx-xxxx-xxxx xxx-xxxx-xxxx Webディレクター ○○○○ - xxx-xxxx-xxxx OSディレクター ○○○○ - xxx-xxxx-xxxx 外注先 ○○○○ xxx-xxxx-xxxx -
- 39. 39 案件毎に「売上」「粗利率」「営業利益率」「予実乖離率」を算出。 6. 予実管理表 案件名 売上 粗利率 営業利益率 見積工数 実績工数 予実乖離率 1月度メルマガ制作 30,0000 45% 25% 50h 50h 0% 商品AのLP制作 45,0000 30% 20% 60h 80h 33% Twitterキャンペーン 55,0000 5% 5% 70h 120h 70% 予実乖離の原因を調査し、備考欄に記載して振り返りMTGで共有。 次の案件の粗利率改善に役立てる。
- 40. 407. 振り返りシート（KPT) ! KEEP（続けたいこと） ! PROBLEM（問題点） ! TRY（今後やりたいこと） 案件終了後や期末などのタイミングでメンバー全員で振り返りを実施。 うまくいった事、問題点を洗い出して、次の施策に役立てる。 同じミスの繰り返しの防止、生産性の向上につなげることができる。
- 41. 417. 振り返りシート（KPT) 氏名 KEEP PROBLEM TRY 鈴木 毎朝15分の朝会 惰性での残業 夕会の実施 月一のペアワーク 設計漏れ 設計レビュー会 Backlogの導入 山田
- 42. 42事前にいただいた質問について ! プロジェクトのスケジュールについて ! お客様とのやりとりで気をつけていること ! チームメンバーとのやりとりで気をつけていること ! 成果物に対してのチェック基準 ! 炎上が起こりやすい案件の特徴 ! 炎上案件の火消し方法
- 44. 44プロジェクトマネージャーのある日の仕事 ! 朝会でチームメンバーと進 の確認 ! お客様からのメールチェックとメンバーへの共有 ! デザイナーからの相談に対してアドバイス ! デバッグ作業の手伝い ! 売上達成状況の確認 ! 次の提案へつなげるための情報収集 ! テスト作業の効率化のための仕組みを考える ! チーム内資料のメンテナンス ! チーム飲み会の手配
- 45. 45チームメンバーとのコミュニケーション " まず受け入れる 何を言われても頭ごなしに否定しない " 意見を引き出す メンバーがどう思っているのかを聞き出す " 任せる やりがいのある仕事を任せメンバーの手柄にする " 対等と平等 誰に対しても対等に、そしてメンバー全員に平等に接する
- 46. 46お客様とのコミュニケーション " まず受け入れる どんな無茶を言われてもまずは受け入れて対策を錬る " へりくだり過ぎない お客様は神様ではなく、共に目標を目指す「パートナー」 " 目先の売上を目指さない 売上につながらずともお客様に役立つ情報を提供していく " 出世させる 案件の成功を通じてご担当者様を出世させる
- 47. 47成果物に対するチェック基準 論理的に矛盾していないか 感情論で「ここは青い方が好きだな」等ではなく、 " メンバーの意図に矛盾がないか " お客様の要望を満たしているか " ユーザーにとって使いやすいか " 過去の失敗を繰り返していないか のように論理的に判断する。
- 48. 48こんな案件は炎上する あやふや " プロジェクトの目標があやふや " チームメンバーの責任範囲があやふや " チームメンバーの評価基準があやふや " 要件定義があやふや " 予算があやふや " スケジュール管理があやふや " 連絡フローがあやふや
- 49. 49炎上が起こりやすいフェーズ 要件定義 設計 実装 リリース なんとか なるっしょ あとで調整 しよう 想定外な ことが… もう無理！ あやふやにしてきたツケにより 後半フェーズで炎上する
- 54. 54 Appendix
- 56. 56 1. チーム形成の中で混乱期があるのは当たり前 2. 混乱期を避けては機能期に りつけない 3. 混乱期が長続きするとチームは崩壊する チーム形成のプロセス（タックマンモデル） 時間 成 果 形成期 混乱期 統一期 機能期
- 57. 57機能しているチームの特徴 ! 目的を皆が理解していて、そこへ向かう過程を楽しんでいる ! 仲間の間での意見の衝突を恐れない ! それぞれが責任を果たすことに誇りを持っている ! チームの中でも、個人がそれぞれに尊重されている ! お互いのよいところを認め合い、敬意を持って接している Team Building Japan http://www.teambuildingjapan.com/about/idea/