プロジェクトマネジメントは仕組み化が9割

21,383 views
19,431 views

Published on

Webプロジェクトマネジメントにおけるノウハウ集

Published in: Leadership & Management

プロジェクトマネジメントは仕組み化が9割

  1. 1. プロジェクトマネジメントは 2016/2/8 第1回 京都・大阪WebPMの集い @ Open VersionUp Project 仕 組 化 が9割
  2. 2. 2自己紹介 @Mharu 大手SIerでSEとして大規模基幹システム の設計・開発・運用に従事。 その後WebベンチャーにてWebサイト 構築やシステム開発を担当。 ディレクター、PMを経てマーケターに。 現在は企業のマーケティング活動を 支援するマーケティングプロデューサー として活動中。
  3. 3. 3自己紹介 運営ブログ 書評 日本酒 マーケティング io-diary.com sakeben.com marketing-pandora.com
  4. 4. 4プロジェクトにおける失敗例 ! 十分なテスト期間を設けられず、本番後も障害多発
 ! プログラマに仕様が間違って伝わり手戻りが発生
 ! リリース前のチェック不十分で本番公開してから修正するのが常態化
 ! 仕様をドキュメント化しておらず、人が抜けると誰も分からない状態に ! 受注後にお客様からの要望が膨らみ、工数が大幅に超過 ! 要件通りに実装したが「そんな事言ってない」と言われた ! リリース直前になってお客様の上司の鶴の一声で仕様変更が発生 ! 進 管理がうまく機能せず、リリース前は深夜残業が常態化
  5. 5. 5 ! メンバーのスキルの問題? ! メンバーのマインドの問題? ! 十分な時間がないから? ! 予算が少ないから? ! 人が足りないから? ! お客様が無茶を言うから? ! お客様の社内事情のせい? 失敗の原因は何なのか?
  6. 6. 6失敗原因の大部分を占めるもの プロジェクトにおける問題の9割は コミュニケーションが原因で起きている ! 要件が変わったことの伝え漏れ ! 指示が誤解されて伝わっていた ! 仕様の認識に相違があった ! 他の人がやるタスクだと勘違い ! 連絡フローの順番を間違えていた
  7. 7. 7プロジェクトマネジメントとは コミュニケーション問題の9割は 仕組みで解決できる 問題を未然に防ぐための仕組み作り プロジェクトマネジメント
  8. 8. 8プロジェクトマネージャーの役割 この問題の 原因は誰だ! 問題が起きない 仕組みを作ろう! ⃝✕
  9. 9. 9仕組み化例 今すぐ使える仕組み化例
  10. 10. 10仕組み化例 - チームワーク メンバーの向いている方向がバラバラ でチームワークが発揮できていない お互いアシストし合いながら チームが一丸となって目標へ向かう ための仕組みを構築
  11. 11. 11「グループ」と「チーム」の違い グループ ! 共通の性質で分類した人や物の一団。群れ。 ! 個々のメンバーの貢献の足し算が成果となる チーム ! 共通の目的のために協力して行動する集団 ! 個々のメンバーの貢献の掛け算が成果となる
  12. 12. 12「チーム」に必要な3つのこと チームの目標 メンバーの役割と責任範囲 評価基準 1 2 3
  13. 13. 13 KGI : 年間粗利益 xxxx万円 KSF KPI 売上:xxxx万円 (昨対:xx%) 提案本数 受注率 案件単価 粗利率:xx% (昨対:xxx%) 原価工数 外注比率 売価 1. チームの目標 浸透しなければ意味がないので、 目立つ所に貼っておく&毎月MTGで進 共有
  14. 14. 142. 役割と責任範囲の明確化 プロジェクトマネージャー チームの目標達成に責任を持つ 目標設定およびその進 管理、達成するための仕組みづくりと ソリューションの提案活動をおこなう 営業 お客様との契約内容に責任を持つ
 見積書、請求書などの書類作成やお客様との価格交渉をおこなう WEBディレクター クリエイティブの制作と品質に責任を持つ
 外注管理、お客様との制作物のやりとりやリリース・納品をおこなう
  15. 15. 15アシスト力の発揮 お互いの役割を理解した上で、 相手の領域に踏み込んでフォローしあう PMSales Web Director Programmer アシスト力
  16. 16. 16アシストの例 ! PMが休暇中、Webディレクターが進 管理 ! 営業が費用交渉しやすいよう説明資料を準備 ! デバッグ要員が足りないのでPMがヘルプ ! プログラマが技術面でPMの提案活動をサポート ! デザイナーが提案資料のダブルチェック
  17. 17. 17バトンの受け渡し バトンを渡す方、受ける方両者の歩み寄りが重要 自分の仕事をやりきる = 他人の仕事を手伝う PMディレクター
  18. 18. 183. 評価基準の定義 プロジェクトチームとしての目標達成(業績評価) KGI:年間粗利益   KPI:売上、粗利率 メンバーそれぞれの評価ポイント(行動評価) 下記に関連する行動を評価とみなす   ! Safety:安全性向上に関する行動   ! Satisfaction:満足度向上に関する行動   ! Quality:品質向上に関する行動   ! Relationship:関係性構築に関する行動   ! Speed:効率化に関する行動   ! Sales & Profit:売上・利益向上に関する行動
  19. 19. 19 Knowledge Safety Quality Speed Satisfaction Relationship Sales
 &
 Profit 3. 評価基準の定義 - 行動評価の関係性
  20. 20. 203. 評価基準の定義 - 行動評価の記録 行動評価管理シートに各自が記録していく PMは各メンバーの上司にフィードバックする カテゴリ 内容 日付 担当者 Speed データの受け渡しフォーマットを作成し、 レポート作成のやりとりを短縮 14/11/19 山田 Quality メール内にGIFアニメを入れ、クリック率 アップに貢献した 15/10/15 鈴木 Satisfaction 急遽発生した修正に柔軟に対応した事につ いてお客様から感謝の言葉をいただいた 15/12/22 佐藤 評価対象となる行動を起こすことにより 自然とチームワークが生まれ目標達成へ近づく
  21. 21. 21仕組み化例 - 会話の円滑化 業界に特化した用語やお客様の社内用語 の意味がわからず会話に支障が・・・ 対お客様、チームメンバー間で スムーズに会話ができるような 仕組みを構築
  22. 22. 22仕組み化例 - 会話の円滑化 用語辞典を作成し、チームメンバー間で共有。 わからない用語は都度追加していく Apple to Apple 同一条件下で比較すること カニバる カニバリゼーション。競合すること ASAP As Soon As Possible = できるだけ早く IP Intellectual Property = 知的財産 FY Financial Year = 会計年度 カイ二乗検定 A/Bテストの検証等に用いられる統計学の手法
  23. 23. 23仕組み化例 - リサーチと共有 お客様の製品・サービスの動向について メンバー間で情報格差がある お客様の製品に関するニュース記事 公式SNSアカウントの更新情報を 通知する仕組みを構築
  24. 24. 24仕組み化例 - リサーチと共有 GoogleアラートとZapierでお客様の動向をチェックし、 チャットワークに通知する仕組みを構築 この仕組みの作り方をブログにまとめました! Googleアラート編: http://goo.gl/HYdFLR Zapier編 : http://goo.gl/pjc8yY 例)マイクロソフト社のニュース通知
  25. 25. 25仕組み化例 - 状況把握 お客様側で頻繁にWebサイトを更新して おり、最新の状況が把握しづらい お客様のWebサイト更新情報を 自動で検知し通知する仕組みを構築
  26. 26. 26仕組み化例 - 状況把握 はてなアンテナでWebサイトを巡回し、 更新があったらチャットワークに通知 この仕組みの作り方をブログにまとめました! http://goo.gl/i4JNfC
  27. 27. 27その他の仕組み化例 ・外注先、お客様とのファイルのやりとりが煩雑  → Backlogでファイルを一元管理 ・イントラからファイルを見つけ出すのが大変  → フォルダ命名ルールを作成 ・社内の見積もり、外注フローが複雑で間違えやすい  → 申請フロー図の作成 ・お客様が多忙で電話やメールでのやりとりがしづらい  → 毎週定例MTGを開催してその場で決定していく ・ノウハウが暗黙知になっており、人が変わると運営に支障をきたす  → プロジェクトナレッジドキュメントを作成 ・休日にトラブルが発生した場合メンバーと連絡がつかない  → 緊急連絡網を整備 ・障害発生時に誰に何を報告すればいいのか曖昧  → 障害発生時のレポートラインを整備 ・他のメンバーがどんな作業をやっているのかよく知らない  → ペアワークの実施(一人が作業、一人が見る)
  28. 28. 28仕組み化のポイント  大きな問題になる前の小さな問題を見つける  あえて言う程でもないけど気になっている事を
  朝会やランチ・飲み会の場などで積極的に吸い上げる   問題を言い合える風土を作る  人にフォーカスして誰が悪いと非難するのではなく、  問題点にフォーカスして何を変えればいいか話し合う  改善した仕組みがうまくいっているか確認する  問題発見 仕組み化 問題の解決 結果の検証の繰り返し 1 2 3
  29. 29. 29プロジェクトマネジメント7つ道具 体制図 ガントチャート 施策マップ 業務フロー図 障害発生時のレポートライン 予実管理表 振り返りシート 1 2 3 4 5 6 7
  30. 30. 301. 体制図 社内各部署のメンバーと役割、外注先を明記し メンバー間で周知しておく。 また、お客様側の体制図、レポートラインも見える化して おくことである程度リスクを想定することができる。
  31. 31. 311. 体制図 PM 企画部 佐藤 Webディレクター デザイン部  鈴木 開発ディレクター システム部  山田 デザイナー 外注✕✕社  本田 プログラマ システム部  川村 Webチーム マネージャー  伊藤様(承認者) Webチーム  渡辺様 (窓口) マーケティング部 部長 森田様(決裁者) 社内 お客様
  32. 32. 322. ガントチャート 誰が何をいつまでにするのかを明確にする。 チームメンバーだけでなくお客様側のタスクも記載し、 遅れが出た場合は速やかに調整をおこなう。 全員で毎朝確認するなど、定期的に見直すことが重要。
  33. 33. 332. ガントチャート Googleスプレッドシートで作成して共有 日付を入れると自動でバーが入力され、営業日も表示される お客様の予定と自社の予定は色分けして表示
  34. 34. 343. 施策マップ お客様がWebサイトやSNS、広告、アプリ等どういった チャネルを利用していて、どこで収益を上げているのかを 一枚のマップに落とし込む。 メンバーがお客様のビジネスモデルや施策を把握するため、 また広い視野で課題を抽出して提案につなげるために活用。
  35. 35. AD 353. 施策マップ アパレルブランド⃝⃝の施策マップ Conversion 自社EC ZOZO TOWN SNS 直営店 複合施設 Curation iQON WEAR リスティング広告 ディスプレイ広告 Magazine AneCan
  36. 36. 364. 業務フロー図 ヒアリングから設計、実装、リリースに至るまでの 業務の流れを見える化する。 各メンバーがどのフェーズで何をするのかを 全員で共有することが、スムーズな案件進行につながる。 お客様の社内の承認フローも記載できえればなお良い。
  37. 37. 374. 業務フロー図 要件ヒアリング:PM 設計:Webディレクター 制作:デザイナー、コーダー 社内チェック:PM,Webディレクター お客様チェック:Web部門 お客様チェック:マーケティング部門 リリース:Webディレクター
  38. 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. 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. 40. 407. 振り返りシート(KPT) ! KEEP(続けたいこと) ! PROBLEM(問題点) ! TRY(今後やりたいこと) 案件終了後や期末などのタイミングでメンバー全員で振り返りを実施。 うまくいった事、問題点を洗い出して、次の施策に役立てる。 同じミスの繰り返しの防止、生産性の向上につなげることができる。
  41. 41. 417. 振り返りシート(KPT) 氏名 KEEP PROBLEM TRY 鈴木 毎朝15分の朝会 惰性での残業 夕会の実施 月一のペアワーク 設計漏れ 設計レビュー会 Backlogの導入 山田
  42. 42. 42事前にいただいた質問について ! プロジェクトのスケジュールについて ! お客様とのやりとりで気をつけていること ! チームメンバーとのやりとりで気をつけていること ! 成果物に対してのチェック基準 ! 炎上が起こりやすい案件の特徴 ! 炎上案件の火消し方法
  43. 43. 43プロジェクトスケジュール 提案:提案書の作成とプレゼン 見積もり:関係部署に見積もりを依頼 受注:お客様と費用交渉の後受注 キックオフ:メンバーを集めて概要説明 制作:進 管理 リリース:お客様へのリリース報告 振り返り:MTGを開催 要件定義:電話や訪問などでヒアリング
  44. 44. 44プロジェクトマネージャーのある日の仕事 ! 朝会でチームメンバーと進 の確認 ! お客様からのメールチェックとメンバーへの共有 ! デザイナーからの相談に対してアドバイス ! デバッグ作業の手伝い ! 売上達成状況の確認 ! 次の提案へつなげるための情報収集 ! テスト作業の効率化のための仕組みを考える ! チーム内資料のメンテナンス ! チーム飲み会の手配
  45. 45. 45チームメンバーとのコミュニケーション " まず受け入れる  何を言われても頭ごなしに否定しない " 意見を引き出す
  メンバーがどう思っているのかを聞き出す " 任せる
  やりがいのある仕事を任せメンバーの手柄にする " 対等と平等  誰に対しても対等に、そしてメンバー全員に平等に接する
  46. 46. 46お客様とのコミュニケーション " まず受け入れる  どんな無茶を言われてもまずは受け入れて対策を錬る " へりくだり過ぎない
  お客様は神様ではなく、共に目標を目指す「パートナー」 " 目先の売上を目指さない  売上につながらずともお客様に役立つ情報を提供していく " 出世させる
  案件の成功を通じてご担当者様を出世させる
  47. 47. 47成果物に対するチェック基準 論理的に矛盾していないか 感情論で「ここは青い方が好きだな」等ではなく、 " メンバーの意図に矛盾がないか " お客様の要望を満たしているか " ユーザーにとって使いやすいか " 過去の失敗を繰り返していないか のように論理的に判断する。
  48. 48. 48こんな案件は炎上する あやふや " プロジェクトの目標があやふや " チームメンバーの責任範囲があやふや " チームメンバーの評価基準があやふや " 要件定義があやふや " 予算があやふや " スケジュール管理があやふや " 連絡フローがあやふや
  49. 49. 49炎上が起こりやすいフェーズ 要件定義 設計 実装 リリース なんとか なるっしょ あとで調整 しよう 想定外な ことが… もう無理! あやふやにしてきたツケにより 後半フェーズで炎上する
  50. 50. 50炎上の火消し方法 出火原因を突き止める 燃えているからといって、水をかければいい訳ではない。 (天ぷら鍋に水をかけると油がはねて炎が広がる) 開発の進 が悪いからといって、人員をやみくもに 投入すればいいというものではない。
  51. 51. 51炎上時にPMがやるべきこと 原因究明 問題の本質的な原因は何か?を突き止める 開発が遅れている理由は「設計にミスが多いから」 では設計にミスが多い理由は? そこに本質的な原因がある。それを早く突き止め 表面的な対処と並行して根本的な対策を実施する。
  52. 52. 52参考情報(初心者編) ブログにまとめました! http://goo.gl/x9uGnv 大工の棟梁に学ぶプロジェクトマネジメント 大工の棟梁によるチーム作り、仕事の進め方、納期管理、 リーダーシップに関する知恵がつまった一冊 今いるメンバーで「大金星」を挙げるチームの法則 サッカー監督が主人公の漫画「ジャイアントキリング」を チームビルディングの視点で読み解いた一冊 ブログにまとめました! http://goo.gl/5KJ6I8
  53. 53. 53参考情報(上級者編) https://goo.gl/qf5o8i 偉大な指揮者に学ぶリーダーシップ / イタイ・タルガム 20世紀の偉大な指揮者5人のリーダーシップのスタイルを示し、 リーダーの立場にいるすべての人がどうあるべきかを語る
  54. 54. 54 Appendix
  55. 55. 55チーム形成のプロセス(タックマンモデル) 形成:メンバーはお互いのことや共通の目的も分からず模索している 混乱:目的や各自の役割と責任について意見を出し合い対立が生まれる 統一:行動規範が確立。目的、役割等が浸透し、関係性が安定する 機能:チームに結束力と一体感が生まれ、目標達成へ邁進する 成 果 時間 形成期 混乱期 統一期 機能期
  56. 56. 56 1. チーム形成の中で混乱期があるのは当たり前 2. 混乱期を避けては機能期に りつけない 3. 混乱期が長続きするとチームは崩壊する チーム形成のプロセス(タックマンモデル) 時間 成 果 形成期 混乱期 統一期 機能期
  57. 57. 57機能しているチームの特徴 ! 目的を皆が理解していて、そこへ向かう過程を楽しんでいる ! 仲間の間での意見の衝突を恐れない ! それぞれが責任を果たすことに誇りを持っている ! チームの中でも、個人がそれぞれに尊重されている ! お互いのよいところを認め合い、敬意を持って接している Team Building Japan http://www.teambuildingjapan.com/about/idea/

×