プロジェクトマネジメントの七ヶ条

社内勉強会用に作成した私的プロジェクトマネジメントの七ヶ条のスライドです。
「プロジェクト」「マネジメント」とはそもそも何かを知り、グレーゾーン抱えながらもなんとか前に進む気概と行動力でプロジェクトという荒波を超えていきましょう！

Transcript

1. プロジェクトマネジメントの 七ヶ条
2. 自己紹介 川岡 潤（かわおか じゅん） https://www.facebook.com/jun.kawaoka https://github.com/mongamae-nioh https://qiita.com/mongamae-nioh • フュージョン株式会社 企画・推進3部 所属 • 旭川市生まれ • 大学で哲学を専攻したところ思春期が長くなり28歳で社会人に • ネットワークエンジニア > インフラエンジニア > 管理職 • プレイング3割、マネジメント7割 1
3. わかること • プロジェクトマネジメントとはなにか • プロジェクトをマネジメントするときに気をつけること 2 わからないこと • プロジェクトメンバーの気持ち • 人に動いてもらう方法 • プロジェクトの具体的な進め方
4. プロジェクトマネジメントとは？ 3
5. そもそもプロジェクトとは？ 4 • 終わりがある初めてのこと(有期性と独自性) • ゆえに恋愛はプロジェクトじゃない （といいですね）
6. 5 恋愛は 終わった途端に プロジェクト
7. そもそもマネジメントとは？ 日本語で「管理」という言葉に対応する英単語が、 - Management - Control - Administration の３種類あることを知る必要がある。 英語でI can manage.というと、「わたしが管理する。」ではなく、「何とかやり遂げるよ。」というニュアンスにな る。それはうまく行く保証のない、けっこう大変なことなのだ。Manageすべき対象には予期しがたい部分があって、 どこかに、暴れ馬を乗りこなすようなイメージがある。あるいは、航海に出る船長のような。 それに比べて、I can control.はもっと精密さを感じる。日本語で「制御」とか「統率」にちかい。なすべきことは計画 で決まっていて、それをきちんと達成する。現実の状態を把握して、計画と実際に差があったらそれを正して行く、そ んな感じだ。 6 https://brevis.exblog.jp/10625203/
8. プロジェクトマネジメントとは 7 やったことがないのに なにが起こるかもわからないのに 費用と期限を約束して なんとかやりくりしながら終わらせること
9. 8 19世紀後半 • アメリカの大陸横断鉄道プロジェクトで何千人もの従業員の労働および大量の原材料の組み 立てをどうやるかという課題。生産性向上の唯一の方法は、厳しい労働と長時間の作業を求 めることだった。 20世紀初頭 • 労働作業に科学的な理由付け始まる。ガントチャート誕生（ガントさん考案）。 20世紀中頃 • 第二次世界大戦中は、複雑な軍事関連プロジェクトや労働力不足で新しい管理方法が必要だ った。1960年代はじめに、企業がその理論をビジネスに適用。 （参考）https://support.office.com/ja-jp/article/プロジェクト管理の歴史の概要-a2e0b717-094b-4d1e-878a-fcd0978891cd プロジェクトマネジメントの歴史
10. プロジェクトマネジメント 七ヶ条 9
11. 10 • クライアント担当者ご自身が何をしたいのかはっきりしていない事が多いが、そのまま にしておくと後々大変なことになる。 • 「これが欲しいわけじゃない」「いえ仕様です」 • クライアントを巻き込んで合意形成する。 • 何に対してどれくらい協力してほしいのか事前にクライアントへお願いする。 一、クライアントを巻き込むべし 「あなたの顧客のためにやるんですよね？」
12. 11 https://www.casleyconsulting.co.jp/blog/engineer/4334/
13. 12 • 上流に問題があると後の工程で欠陥が発見された場合に修正するコストが大きい。 • 「やっぱりこうしたい」「今言われても難しいです」 • プロジェクトが終わりに向かうにつれて修正するコストは急激に増加する。 一、品質は上流で決まると心得るべし 下流で水をキレイするのは大変
14. 13 https://prtimes.jp/main/html/rd/p/000000015.000030691.html
15. 14 • 目的が設定されていないプロジェクトは失敗する。 • 問題が起きたときに判断基準がわからず迂回路を取れなくなる。 • モチベーションを保つのが難しくなる。 一、目的を定めるべし 「そもそも何のためにやるんですか？」
16. 15 なぜ大聖堂を 建てるのか？
17. 16 • 流通する情報量が多いチームが成功する。 • 情報量が一番多いのが「ぶっちゃけ」た会話。 • メンバーの人となりや価値観をみんなで共有しておくと情報量は増加する。 • 「空気」に支配されると情報量は低下していく。 一、腹を割って話すべし 「私はこういう人間です」
18. 17 https://slmt.co.jp/team_building/
19. 18 • プロジェクトに必要な人材の質と量に対して最初から100％だと破綻する。 • リソースは70％ぐらいの稼働率で回る程度に確保できるのが理想的。ある程度の遊びが必要。 • プロジェクトの期間や必要なリソースは自分の想定よりも多く見積もる。 一、余裕を持つべし 「なんかあったら終わりじゃないですか？」
20. 19 https://www.sbbit.jp/article/cont1/33359#&gid=null&pid=1
21. 20 • 不具合の芽はすべてここで潰すという覚悟でテストする。 • スケジュールが遅れてくるとテストの工数が削られていく。 • テストは品質の検査であり、繰り返すだけでは品質はあがらない。 • 品質はテストと修正の繰り返しで向上させるものではなく上流工程で作り込むもの。 一、テストを重んじるべし 品質は上流から
22. 21 • 「空気」を読まない。メンバー間の情報量が低下する。 • 「到底言える雰囲気ではなかった」が蔓延しているとプロジェクトは破綻する。 • 「このまま進めるのは危険です」>「リスクが顕在化しており、スケジュールが遅延していま す」>「非常に難しい状況だ…だが納期目前なのでがんばろう」 一、違和感を大事にすべし 「あの時やばいと思っていました」
23. プロジェクトマネジメントの七ヶ条 22 一、クライアントを巻き込むべし 一、品質は上流で決まるものと心得るべし 一、目的を定めるべし 一、腹を割って話すべし 一、余裕を持つべし 一、テストを重んじるべし 一、違和感を大事にすべし
24. 参考書籍 • 外資系コンサルが教えるプロジェクトマネジメント（山口 周 著、大和書房） • プロジェクト・マネジャーが知るべき97のこと（オライリージャパン） • プロセスデザインアプローチ 誰も教えてくれない「プロジェクトマネジメント」（芝本秀徳 著、日経BP社） • ソフトウェアエンジニアリング講座2 ITトップガン育成プロジェクト（ＩＴトップガン育成プロジェクト 著、 日経BP社） 23