プロジェクトマネジメントをはじめる前に大切なこと

Transcript

1. プロジェクトマネジメントを はじめる前に⼤切なこと クラスメソッド株式会社 ⼤橋 ⼒丈 1
2. 資料は後⽇ブログにて公開します https://dev.classmethod.jp/
3. 3 リモート登壇にあたっての懸念 吠えたら ごめんなさい
4. ⼤橋⼒丈(@riki0084) クラスメソッド株式会社 CX事業本部 本部⻑ 経歴 サーバーサイドエンジニア     ↓ プロジェクトリーダー     ↓ プロジェクトマネージャー その他 趣味：サウナ、ベビメタ、⽝、猫 4 ⾃⼰紹介
5. 5 会社紹介 オープンな発想と⾼い技術⼒によりすべての⼈々の創造活動に貢献し続ける
6. クラスメソッド CX事業本部 ビジョン/ミッション/バリュー 6 Vision  ・プロダクトを通じて⼈々をハッピーにする Mission  ・最⾼の「顧客体験」を創り上げる Value  ・プロダクトが提供したい価値を常に考え仕事をする  ・チームメンバーを尊重する  ・専⾨性を持って提案し続ける
7. 本資料の前提 7 ・プロジェクト開始前の準備段階に重点を置いている ・クライアントと⼀緒にプロジェクトを⾏っている ・クライアントを含めたワンチームのプロジェクト ・新規事業系のプロジェクトで、不確実性が⾼い ・⽐較的少⼈数チームの開発 ・特定のプロジェクトではなく、今までの経験を総合した話 銀の弾丸のような話はできません
8. 8 今⽇のアジェンダ 1.プロジェクト開始前 2.プロジェクト開始後
9. プロジェクト開始前
10. 10 案件概要や利⽤技術などがあ る程度分かる情報がある。 打ち合わせ前に、事前ある程 度ヒアリングを⾏う 問い合わせ 打ち合わせ 提案 プロジェクト概要を確認  ・実現したい世界  ・解決したい課題  ・期間/予算 以下のような内容を提案 ・実現⽅法 ・具体的な利⽤技術 ・開発チーム体制による⾦額感 受注までの流れ
11. 11 私の持論 クライアント、そしてユーザーに届ける価値に共感できるか プロジェクトは、開始前が⾮常に重要
12. 12 RFPとは • Request for Proposal（提案依頼書） •  ベンダー各社にシステムの導⼊や業務委託を提案/依頼する •  システムに求める要件を明確に記載した書類 • RFPで提⽰されてる情報 •  プロジェクトの背景・⽬的 •  達成したい⽬標 •  機能要件/⾮機能要件 •  想定予算とスケジュール
13. 13 RFPをどう読むか RFPは完璧で要求通りに提案する必要がある 不確実性の⾼いプロジェクトにおいて RFPは完璧には出来ない
14. 14 RFPどう読むか RFPは参考情報と考え、⾃社なりの提案をする 解決したい課題は何なのか？ 考えそこにフォーカスして提案
15. 15 As-IsとTo-Be RFP、企画書、システム検討書、ペライチ、⼿書きのイメージ 必ず解決したい課題がある To-Be As-Is 現状 あるべき姿 ギャップ
16. 16 As-IsとTo-Be To-Be As-Is 現状 あるべき姿 ギャップ
17. 17 As-IsとTo-Be To-Be As-Is 現状 あるべき姿 ギャップ ・資料、打合ででよく出る ・達成したい⽬的や⽬標 ・システムで対応しなくて良いものもある ・To-Beのみでここが無いことが多い ・ここが重要 ・ここを把握していないとブレる可能性がある
18. 18 ⾃社の強み/弱みを知る 0 2 4 6 8 10 企画 デザイン マネジメント 技術 ドキュメント ビジネス 要求 ⾃社
19. 19 ⾜りない部分をどうするか 出来ること/出来ない事を伝える 無理をするとプロジェクト開始してから⼤変になる ただし、出来ない事の代替案は考え伝える 正直に話をする
20. 20 具体的には（あくまで参考の⼀部です） • 技術的な話 •  課題管理のツールはBacklogを利⽤し、ソースコードはGithubで管理します •  〇〇部分の進め⽅は、技術的調査が必要なのでプロト作成し試しながら開発を進め ます • 成果物の話 •  本当にそのフォーマットでや粒度でドキュメント必要ですか？Wikiなど書きやすい 形で、必要最⼩限のドキュメントにしませんか？ •  CD-ROMでの納品とありますが、データでの提供を想定しています。 • 体制などの話 •  このプロジェクトにおいて、ガッツリ参加してもらうため週〇時間は確保してくだ さい 伝えるべきは、弱⾳では無く本⾳
21. 21 こういう時は、お断りもしていました • 開発ツールに制約がある •  ⾃社⽂化にあったツールを利⽤できない（似ているものは可能） •  課題管理：Backlog •  システム構成図：Cacoo •  and more •  エンジニアの体にあったツールを利⽤出来るかで、開発スピードが異 なる
22. 22 事例（LIXIL様） https://classmethod.jp/cases/lixil/
23. 23 事例（LIXIL様）解決したい課題 https://classmethod.jp/cases/lixil/
24. 24 事例（LIXIL様） •  RFP受領後、⾃社として出来ること/出来ないことを正直に伝えた •  出来ないことに対して、代替案を提⽰ •  RFPに記載されていた作業を、⼀部お客様側にお願いした 最初から腹を割って話をすることが重要 https://classmethod.jp/cases/lixil/
25. 25 提案時の注意点 • 解決したい課題は何かを認識合わせておく • 求められる要求が難しい場合は正直に相談をする • 無理なときは、無理をしない
26. プロジェクト開始後
27. 27 視座/視野/視点を合わせる 受注前に腹を割ることで 視座/視野/視点をクライアントと合わせやすくする
28. 28 視座/視野/視点を合わせると何が良いのか •  視座/視野を合わせる •  開発スタイルを理解してくれるクライアント •  解決したい課題を理解した開発チーム •  強み/弱みを正直に⾒せることで、⼼理的安全性が⾼まる •  隠し事などせず、透明性を⾼くすることで、適応の制御と改善が可能になる •  視点を合わせる •  ビジネス要件/仕様/設計/開発において⽅向性を合わせ決めていくスタイル •  ⽅向性がズレていたら、チーム内で議論 クライアントとワンチームになり プロダクトを作るための同じチームマインドを持つ
29. ⽬指したいところ
30. 30 QCDは誰が責任を持ってマネジメントする？ Quality Cost Delivery チーム全体でマネジメントをする
31. 31 チームの効果性の向上に関する5つの柱 参考：Google re:Work https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/help-teams-determine-their-needs/ 1.⼼理的安全性 「チームの中でミスをしても、それを理由に⾮難されることはない」と思えるか。 2.相互信頼 「チームメンバーは、⼀度引き受けた仕事は最後までやりきってくれる」と思えるか。 3.構造と明確さ 「チームには、有効な意思決定プロセスがある」と思えるか。 4.仕事の意味 「チームのためにしている仕事は、⾃分⾃⾝にとっても意義がある」と思えるか。 5.インパクト 「チームの成果が組織の⽬標達成にどう貢献するかを理解している」か。 チーム醸成とプロセスをマネジメント
32. 32 とはいえ こんなにピッタリ最初から合うわけない
33. 33 そもそも 所属、役割、⽴場が異なる 参画した時期が違う スキルレベルに差がある
34. 34 視座/視野/視点を合わせるために インセプションデッキ Cacooにもテンプレートがあります https://cacoo.com/diagrams/nsgCdwRZAHJBXTLy/5FF36
35. 35 チームの強みを把握するために（参考） https://www.amazon.co.jp//dp/4532321433/ 質問に答え、34の資質から強みを⾒つける こんな感じの⼈だなと思ってたのが、⾔語化された 才能を質問に答えて出してもらってから、本⼈に取 り扱い説明書的なまとめをしてもらい「この⼈はこ ういう特性があるから、こう接すると良さそう」と いうことがチームで共有された
36. 36 様々なプロセス/プラクティスは沢⼭ある
37. 37 それでも簡単にはいかない •  チーム内での振り返り •  ⽴ち⽌まり、現状を把握し受容する •  讃え、喜び合う •  問題を共有し把握し受容する •  チャレンジし、フィードバックを得る •  1on1などによる対話 •  困っていること •  楽しかったこと •  持っている価値観
38. 38 何をしても解決しないときは 思い切って合わない⼈を抜く チームに合わないメンバー 向いてる⽅向が違う 壁を作る 相性が悪い
39. 39 トラブルが発⽣した場合 •  責めても、何も解決しない •  起きた事象は取り返せないので、事象の解決策に対して陣頭指揮をとり整理する •  起きた問題をすぐに正確に報告 •  チームに起きた事象を整理して報告 •  全ての情報を集めるのに時間がかかる場合は、わかっている情報を報告 •  その時に、情報を隠さない、正直に伝える トラブル時こそプロジェクトマネージャーが ⼀番冷静であること
40. 40 何度も失敗しています •  キツかったプロジェクト •  社内状況的に選べない •  途中から⽕消しで⼊らざるを状況 •  クライアントとエンジニアから板挟み •  プロセス偏重になったこともあった •  座学で学びすぎ、インプットとアウトプットがあわない •  型に合わせようとしすぎて、チームを⾒ていなかった ⼿段が⽬的になっていた
41. 最後に
42. 42 プロジェクトの成功ってなんだろう？ チーム/ユーザーがこうなっている状態
43. 43 できることは全てやる •  視座/視野/視点を合わせる •  クライアントと正直な関係性を築く •  プロセス/プラクティスを有効的に活⽤ •  チームの効果性を⾼める •  チームが、効率的に動ける状態を考える •  ⾃チームで、出来ないことは外部コーチなどに頼む •  腹を割って話ができるチーム作り •  チーム、個⼈との対話を重ね改善する できることからコツコツと
44. 44 できないこともある どうしようもないことはキッパリ割り切る 思い切りの良さが必要
45. Letʻs enjoy project！ ありがとうございました