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

by cm-oohashi

Embed

Start on current slide

Slide 1

Slide 1 text

プロジェクトマネジメントをはじめる前に⼤切なことクラスメソッド株式会社⼤橋⼒丈 1

Slide 2

Slide 2 text

資料は後⽇ブログにて公開します https://dev.classmethod.jp/

Slide 3

Slide 3 text

3 リモート登壇にあたっての懸念吠えたらごめんなさい

Slide 4

Slide 4 text

⼤橋⼒丈(@riki0084) クラスメソッド株式会社 CX事業本部本部⻑経歴サーバーサイドエンジニア ↓ プロジェクトリーダー ↓ プロジェクトマネージャーその他趣味：サウナ、ベビメタ、⽝、猫 4 ⾃⼰紹介

Slide 5

Slide 5 text

5 会社紹介オープンな発想と⾼い技術⼒によりすべての⼈々の創造活動に貢献し続ける

Slide 6

Slide 6 text

クラスメソッド CX事業本部ビジョン/ミッション/バリュー 6 Vision ・プロダクトを通じて⼈々をハッピーにする Mission ・最⾼の「顧客体験」を創り上げる Value ・プロダクトが提供したい価値を常に考え仕事をする・チームメンバーを尊重する・専⾨性を持って提案し続ける

Slide 7

Slide 7 text

本資料の前提 7 ・プロジェクト開始前の準備段階に重点を置いている・クライアントと⼀緒にプロジェクトを⾏っている・クライアントを含めたワンチームのプロジェクト・新規事業系のプロジェクトで、不確実性が⾼い・⽐較的少⼈数チームの開発・特定のプロジェクトではなく、今までの経験を総合した話銀の弾丸のような話はできません

Slide 8

Slide 8 text

8 今⽇のアジェンダ 1.プロジェクト開始前 2.プロジェクト開始後

Slide 9

Slide 9 text

プロジェクト開始前

Slide 10

Slide 10 text

10 案件概要や利⽤技術などがある程度分かる情報がある。打ち合わせ前に、事前ある程度ヒアリングを⾏う問い合わせ打ち合わせ提案プロジェクト概要を確認・実現したい世界・解決したい課題・期間/予算以下のような内容を提案・実現⽅法・具体的な利⽤技術・開発チーム体制による⾦額感受注までの流れ

Slide 11

Slide 11 text

11 私の持論クライアント、そしてユーザーに届ける価値に共感できるかプロジェクトは、開始前が⾮常に重要

Slide 12

Slide 12 text

12 RFPとは • Request for Proposal（提案依頼書） •  ベンダー各社にシステムの導⼊や業務委託を提案/依頼する •  システムに求める要件を明確に記載した書類 • RFPで提⽰されてる情報 •  プロジェクトの背景・⽬的 •  達成したい⽬標 •  機能要件/⾮機能要件 •  想定予算とスケジュール

Slide 13

Slide 13 text

13 RFPをどう読むか RFPは完璧で要求通りに提案する必要がある不確実性の⾼いプロジェクトにおいて RFPは完璧には出来ない

Slide 14

Slide 14 text

14 RFPどう読むか RFPは参考情報と考え、⾃社なりの提案をする解決したい課題は何なのか？考えそこにフォーカスして提案

Slide 15

Slide 15 text

15 As-IsとTo-Be RFP、企画書、システム検討書、ペライチ、⼿書きのイメージ必ず解決したい課題がある To-Be As-Is 現状あるべき姿ギャップ

Slide 16

Slide 16 text

16 As-IsとTo-Be To-Be As-Is 現状あるべき姿ギャップ

Slide 17

Slide 17 text

17 As-IsとTo-Be To-Be As-Is 現状あるべき姿ギャップ・資料、打合ででよく出る・達成したい⽬的や⽬標・システムで対応しなくて良いものもある・To-Beのみでここが無いことが多い・ここが重要・ここを把握していないとブレる可能性がある

Slide 18

Slide 18 text

18 ⾃社の強み/弱みを知る 0 2 4 6 8 10 企画デザインマネジメント技術ドキュメントビジネス要求⾃社

Slide 19

Slide 19 text

19 ⾜りない部分をどうするか出来ること/出来ない事を伝える無理をするとプロジェクト開始してから⼤変になるただし、出来ない事の代替案は考え伝える正直に話をする

Slide 20

Slide 20 text

20 具体的には（あくまで参考の⼀部です） • 技術的な話 •  課題管理のツールはBacklogを利⽤し、ソースコードはGithubで管理します •  〇〇部分の進め⽅は、技術的調査が必要なのでプロト作成し試しながら開発を進めます • 成果物の話 •  本当にそのフォーマットでや粒度でドキュメント必要ですか？Wikiなど書きやすい形で、必要最⼩限のドキュメントにしませんか？ •  CD-ROMでの納品とありますが、データでの提供を想定しています。 • 体制などの話 •  このプロジェクトにおいて、ガッツリ参加してもらうため週〇時間は確保してください伝えるべきは、弱⾳では無く本⾳

Slide 21

Slide 21 text

21 こういう時は、お断りもしていました • 開発ツールに制約がある •  ⾃社⽂化にあったツールを利⽤できない（似ているものは可能） •  課題管理：Backlog •  システム構成図：Cacoo •  and more •  エンジニアの体にあったツールを利⽤出来るかで、開発スピードが異なる

Slide 22

Slide 22 text

22 事例（LIXIL様） https://classmethod.jp/cases/lixil/

Slide 23

Slide 23 text

23 事例（LIXIL様）解決したい課題 https://classmethod.jp/cases/lixil/

Slide 24

Slide 24 text

24 事例（LIXIL様） •  RFP受領後、⾃社として出来ること/出来ないことを正直に伝えた •  出来ないことに対して、代替案を提⽰ •  RFPに記載されていた作業を、⼀部お客様側にお願いした最初から腹を割って話をすることが重要 https://classmethod.jp/cases/lixil/

Slide 25

Slide 25 text

25 提案時の注意点 • 解決したい課題は何かを認識合わせておく • 求められる要求が難しい場合は正直に相談をする • 無理なときは、無理をしない

Slide 26

Slide 26 text

プロジェクト開始後

Slide 27

Slide 27 text

27 視座/視野/視点を合わせる受注前に腹を割ることで視座/視野/視点をクライアントと合わせやすくする

Slide 28

Slide 28 text

28 視座/視野/視点を合わせると何が良いのか •  視座/視野を合わせる •  開発スタイルを理解してくれるクライアント •  解決したい課題を理解した開発チーム •  強み/弱みを正直に⾒せることで、⼼理的安全性が⾼まる •  隠し事などせず、透明性を⾼くすることで、適応の制御と改善が可能になる •  視点を合わせる •  ビジネス要件/仕様/設計/開発において⽅向性を合わせ決めていくスタイル •  ⽅向性がズレていたら、チーム内で議論クライアントとワンチームになりプロダクトを作るための同じチームマインドを持つ

Slide 29

Slide 29 text

⽬指したいところ

Slide 30

Slide 30 text

30 QCDは誰が責任を持ってマネジメントする？ Quality Cost Delivery チーム全体でマネジメントをする

Slide 31

Slide 31 text

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.インパクト「チームの成果が組織の⽬標達成にどう貢献するかを理解している」か。チーム醸成とプロセスをマネジメント

Slide 32

Slide 32 text

32 とはいえこんなにピッタリ最初から合うわけない

Slide 33

Slide 33 text

33 そもそも所属、役割、⽴場が異なる参画した時期が違うスキルレベルに差がある

Slide 34

Slide 34 text

34 視座/視野/視点を合わせるためにインセプションデッキ Cacooにもテンプレートがあります https://cacoo.com/diagrams/nsgCdwRZAHJBXTLy/5FF36

Slide 35

Slide 35 text

35 チームの強みを把握するために（参考） https://www.amazon.co.jp//dp/4532321433/ 質問に答え、34の資質から強みを⾒つけるこんな感じの⼈だなと思ってたのが、⾔語化された才能を質問に答えて出してもらってから、本⼈に取り扱い説明書的なまとめをしてもらい「この⼈はこういう特性があるから、こう接すると良さそう」ということがチームで共有された

Slide 36

Slide 36 text

36 様々なプロセス/プラクティスは沢⼭ある

Slide 37

Slide 37 text

37 それでも簡単にはいかない •  チーム内での振り返り •  ⽴ち⽌まり、現状を把握し受容する •  讃え、喜び合う •  問題を共有し把握し受容する •  チャレンジし、フィードバックを得る •  1on1などによる対話 •  困っていること •  楽しかったこと •  持っている価値観

Slide 38

Slide 38 text

38 何をしても解決しないときは思い切って合わない⼈を抜くチームに合わないメンバー向いてる⽅向が違う壁を作る相性が悪い

Slide 39

Slide 39 text

39 トラブルが発⽣した場合 •  責めても、何も解決しない •  起きた事象は取り返せないので、事象の解決策に対して陣頭指揮をとり整理する •  起きた問題をすぐに正確に報告 •  チームに起きた事象を整理して報告 •  全ての情報を集めるのに時間がかかる場合は、わかっている情報を報告 •  その時に、情報を隠さない、正直に伝えるトラブル時こそプロジェクトマネージャーが⼀番冷静であること

Slide 40

Slide 40 text

40 何度も失敗しています •  キツかったプロジェクト •  社内状況的に選べない •  途中から⽕消しで⼊らざるを状況 •  クライアントとエンジニアから板挟み •  プロセス偏重になったこともあった •  座学で学びすぎ、インプットとアウトプットがあわない •  型に合わせようとしすぎて、チームを⾒ていなかった⼿段が⽬的になっていた

Slide 41

Slide 41 text

最後に

Slide 42

Slide 42 text

42 プロジェクトの成功ってなんだろう？チーム/ユーザーがこうなっている状態

Slide 43

Slide 43 text

43 できることは全てやる •  視座/視野/視点を合わせる •  クライアントと正直な関係性を築く •  プロセス/プラクティスを有効的に活⽤ •  チームの効果性を⾼める •  チームが、効率的に動ける状態を考える •  ⾃チームで、出来ないことは外部コーチなどに頼む •  腹を割って話ができるチーム作り •  チーム、個⼈との対話を重ね改善するできることからコツコツと

Slide 44

Slide 44 text

44 できないこともあるどうしようもないことはキッパリ割り切る思い切りの良さが必要

Slide 45

Slide 45 text

Letʻs enjoy project！ありがとうございました