追記：このスライドの16スライド目の後に1枚「プロジェクトマネジメントの難しいところ」を加えて、その他いくらか文言を修正したプチ20201026改訂版がありますので、よろしければそちらをご覧ください。 https://www.slideshare.net/hysmrk/20201026-238970880 プロジェクト的な立ち回りに経験の浅いビジネスパーソン向けの「プロジェクトマネジメント」の入門知識をまとめたスライドです。内輪向けにこしらえたβ版で、途中で息絶えた感が否めない仕上がりではありますが、ざっと概観するのにお役立ていただけるところがあればと思い、ネットの片隅に置いておきます。 編集後記は、筆者ブログ（心のうち）にて。 https://hysmrk.cocolog-nifty.com/blog/2020/10/post-79dcfe.html

1. 誰もが持っておきたい
プロジェクトマネジメント基礎知識
林 真理子
@hysmrk

2. プロジェクトマネジメントの機能不全
Mariko Hayashi (@hysmrk)

3. PMの機能不全とは、どういう状態か
「○○プロジェクト」と掲げて
キックオフ的集まりは持つものの、
プロジェクトとは何か知らない
なんとなく走り出し、タスク発生
時に都度、誰がやるのか決める
誰の何の仕事の後に、自分が何の
仕事をいつまでにして、誰にどう
いう状態で引き継ぐのか、メン
バーがイメージできていない
個別作業も引き継ぎもずるずる、
だらだら
2020/10/25 3Mariko Hayashi (@hysmrk)
誰かに期待している何かをやって
もらえなくて、いらいら
すれ違っては調整しての行ったり
来たりで、ぐったり
ゴール設定なく走り出すため、途
中から間に合わせのゴールに向か
い出したり、終結後にちゃっかり
達成したことをゴールだったこと
にして丸くおさめたり
反省もせず改善点の収穫もなく、
なんとなく終わっていく…

4. PMなしに、現代の仕事は成り立たない
現代はプロジェクト型で仕事を動かす時代、PMの知識は仕事の基礎知識
「プロジェクトマネージャー」としての業務に得意・不得意はあれど、プ
ロジェクトに参画する以上、1メンバーとしてPMの基礎知識は不可欠
2020/10/25 4Mariko Hayashi (@hysmrk)

5. PMの知識基盤は、どこでも役立ち、自分の市場価値に
PMの基礎知識を備え、「プロジェクトメンバー」としての基本所作が備
わっていれば、きちんと仕事できる人だという評価を得やすい
「プロジェクトマネージャー」としての手腕が発揮できれば、自身のキャ
リア上も一定の市場価値をもて、長期的につぶしがきく能力基盤をもてる
プロジェクトメンバーとしてもまともに動けないと、プロジェクトの中で
自身の得意とする職能も発揮できないし、プロジェクトにアサインされな
くなる（圧倒的な専門技能なり作家性でもない限り）
2020/10/25 5Mariko Hayashi (@hysmrk)

6. PMの基礎知識を獲得し、実践しよう
2020/10/25 6Mariko Hayashi (@hysmrk)

7. プロジェクトとは何か
Mariko Hayashi (@hysmrk)

8. これじゃない、そういうことじゃない
規模の大きさ
期間の長さ
メンバーの多さ
ゲームとかサイトとかアプリとか、何かを作る案件
招集者が「プロジェクト」と言っている
2020/10/25 8Mariko Hayashi (@hysmrk)

9. プロジェクトを定義づける2つの要素
有期的であること
＝期限があること
独自性があること
＝ルーチン業務ではない、機械的な作業の反復では済まないこと
※米Project Management Institute(PMI)が発行するPM知識体系「PMBOK」より
2020/10/25 9Mariko Hayashi (@hysmrk)

10. Q. これはプロジェクト？
 社内ガイドラインに沿って、3末まで○○DBに入力するプロジェクト
 日々の○○DB入力を通じて、3末までに社内ガイドラインの改善点を提
案するプロジェクト
 マニュアルに沿って、3末まで新規開拓の営業活動をするプロジェクト
 オンラインで効果的に新規顧客開拓する方法を、3末までにマニュアル化
するプロジェクト
2020/10/25 10Mariko Hayashi (@hysmrk)

11. 個人でも、仕事はプロジェクトに転換できる
漫然とルールにのっとって機械的に作業をこなす非プロジェクト的アプ
ローチの仕事は消失していく
仕事を自らプロジェクトとして捉え直し、マネジメントする意識が重要
2020/10/25 11Mariko Hayashi (@hysmrk)

12. プロジェクトマネジメントとは何か
Mariko Hayashi (@hysmrk)

13. プロジェクトマネジメントを一言でいうと
プロジェクトを確実に成功させるための
道筋づくり
※米PMIがプロジェクトマネジメントの知識体系を「PMBOK」としてフレームワーク化している
2020/10/25 13Mariko Hayashi (@hysmrk)

14. プロジェクトマネージャーとは
プロジェクトを計画し、始動させ、進行を管理し、品質、プロジェクトの
最終的な成功に責任を負う
「プロジェクトマネジメント」及び「プロジェクトのテーマ」に関する専
門知識・スキルを持ち、「制約条件のもと要求水準の成果物を仕上げる」
のと「状況に応じて柔軟に変化に対応していく」バランス感覚を要する
2020/10/25 14
※プロジェクトマネージャーがいないと、プロジェクトは成り立たない。明示的な位置づけでなくと
も、成功するプロジェクトにはその役割を担っている人が必ずいるもの
Mariko Hayashi (@hysmrk)

15. プロジェクトの全容を把握する「9つの知識エリア」
プロジェクトを行う際は、最初にプロジェクトを進める活動の全容を描き
出し、そこで必要なもの、やらなければならないことを確認した上で始動
2020/10/25 15Mariko Hayashi (@hysmrk)

16. プロジェクトマネジメントで大事なのは
着実なステップを踏む
• インプット（情報収集）→分析（解釈・構造化）→アウトプット（共有）のステップ
• このステップを踏まないと、プロジェクトのプロセスも成果物もクオリティが雑になる
始動段階で、網羅性高く計画立てること
• 初期段階では具体的に詰め切れなくてもいい、9つのエリアを網羅して全体像を見える化する
• プロジェクトメンバーやステークホルダーとやりとりし、段階的に細部を詰めて精緻化していく
• 問題は、始動時点にこれらを網羅した計画工程がない、やっているようでも実質していないこと
「網羅性」と「柔軟性」のバランスをとる
• 計画段階：抜け漏れをつくらない（網羅性）
• 実行段階：抜くべきところを抜き、状況に応じて最適な変更を加えること（柔軟性）
ステークホルダーと認識合わせ＆合意形成をとり続ける
• プロジェクトメンバーはもちろん、多様なステークホルダーに合わせて簡潔明瞭なアウトプットに落とし込み、
適切なタイミングと手段でコミュニケーションをとり、認識合わせ＆合意形成を図る
2020/10/25 16Mariko Hayashi (@hysmrk)

17. プロジェクトマネジメントの方法論［計画段階］
Mariko Hayashi (@hysmrk)

18. 1) プロジェクトマネージャーを決定・権限付与する
プロジェクトオーナー
決めないプロジェクトは、ぐだぐだになる覚悟で…
プロジェクトメンバー
役割をかって出ることも or ひそかにその役割を担って実践経験積むことも
2020/10/25 18Mariko Hayashi (@hysmrk)

19. 2) プロジェクトの目的・目標を明確にする
プロジェクト立ち上げの経緯・背景
（市場の要求／顧客の要求／法的な要求／ビジネスニーズ／技術の進歩／社会的なニーズ）
プロジェクトの目的
（最終的に達成すべきもの、青写真、グランドデザインなど）
プロジェクトの目標
（目的を成し遂げるためのゴール設定）
※都度、関係者の意識共通化、仕様や品質とコストのバランスなどを判断する場合の根拠になる
2020/10/25 19Mariko Hayashi (@hysmrk)

20. 2-i)目標設定のガイドライン「SMART」
2020/10/25 20Mariko Hayashi (@hysmrk)
S
M
A
R
T
出典：「Webプロジェクトマネジメント標準」（共著：林千晶、高橋宏祐 出版社：技術評論社）
※SMARTの法則…最初の提唱者 George T. Doranは「There’s a S.M.A.R.T. way to write management’s goals and objectives」(1981年)の中で、後半3つの構成
因子を「Assignable」「Realistic」「Time-related」として構成している。後に「Achievable」「Relevant」「Time-bound」とする提唱者もいる
pecific 具体的か
easurable 測定できる定量的な指標か
ccurate 目的と整合しているか
ealistic and Tangible 現実的か
ime bound 期日が定められているか

21. 2-w)担当プロジェクトの目標をSMARTに書き直す
1. 「いつまでに／誰が／どの範囲で／何を／どのレベルでできている状態
にする」というように、プロジェクトの目標を書き直してみる
2. SMARTの目標設定ガイドラインをすべて満たすかチェックしてみる
3. 他の人とも見せ合いっこ、目標がSMARTに書けているか意見交換する
4. 不足点を修正して、よりSMARTな目標に書き直す
※最初からSMARTな目標を記述するのは難しい。ガイドラインに照らして目標の内容をブラッシュ
アップするプロセスを大事にする
2020/10/25 21Mariko Hayashi (@hysmrk)

22. 3) プロジェクトの「3大制約条件」を明確にする
コスト
スケジュール
* 最終期限
* ずらせないマイルストーン
スコープ
* 期限内にやる工程・作業範囲はどこまで？
* 最終成果物は何？
* 中間成果物は何？
* ステークホルダーの要求水準・要望事項、適切な納品形式など
2020/10/25 22
※マイルストーン…プロジェクトにおいて重要な意味をもつ時点やイベント（PMBOKより）
Mariko Hayashi (@hysmrk)

23. 3-i) 「3大制約条件」以外のグレイゾーンもつぶす
プロジェクトの境界（範囲外）の明確化
（「何をどこまで」が曖昧になっていることはない？）
制約条件
（プロジェクトやプロセスのパフォーマンスに影響を与えうる制限や制約はない？）
前提条件
（ステークホルダーが、常識・当然と思っている未確認事項や不確証なことはない？）
2020/10/25 23
［制約・前提条件の例］
• 当然、誰それがやると思っていた
• 業界慣習・ルール
• 関連法規への配慮
• 社内の運用ルール、ガイドライン
• 権利の帰属先
• サーバー環境、ネットワーク環境、ドメイン、ソフトウェア関連
• 社内の承認フロー、承認にかかる期間
• サービス公開後の運用体制（運用担当者の有無、割ける時間、能力など）
Mariko Hayashi (@hysmrk)

24. 4) ステークホルダーを洗い出して分析する
プロジェクトに関わる利害関係者を網羅的に洗い出す
リテラシー度合い、関与度や影響力、決裁者、力関係、承認フローを把握
進行中の適切なコミュニケーション時期・頻度・手段・ツールなどを想定
2020/10/25 24
※ステークホルダー…プロジェクトに関わる利害関係者
Mariko Hayashi (@hysmrk)

25. 5) チーム編成・役割分担を定める
2020/10/25 25
プロジェクトメンバーの選定・役割分担
個々人の経験値、スキルの特性・レベル、興味、パーソナリティ、仕事の忙しさ、勤務場所やコ
ミュニケーション手段、コスト、プロジェクトを通じて各人が得られるスキルなどを総合的に考察
の上、選定メンバーを必要な役割に割り当てる
役割分担の表記方法
階層型、マトリクス型、テキスト型
役割分担で明確にすべき要素
各人の役割（肩書き）、権限、責任、コンピテンシー（プロジェクト完了に必要な能力）
Mariko Hayashi (@hysmrk)

26. 5-i) 役割分担の表記例
2020/10/25 26
責任分担マトリックス（RAM: Responsibility Assignment Matrix）
誰がどの作業に対してどのような責任を負っているのかを明確にする表
Mariko Hayashi (@hysmrk)
RACIチャート
出典：「Webプロジェクトマネジメント標準」（共著：林千晶、高橋宏祐 出版社：技術評論社）

27. 6)リスクを洗い出し、回避策・対処法を考えておく
想定しうるリスクを洗い出す
プロジェクトメンバーで集まって想定リスクを出し合ったり、有識者にヒアリングするなど
リスクを一覧表にまとめて優先順位づけ
想定リスクを一覧表にまとめ、影響度と発生確率で優先順位づけ
優先度高いリスクの対策・監視体制を決める
優先度高いリスクは、回避・転嫁・軽減策を講じたり、監視体制・発生時の対処法を考えておく
2020/10/25 27Mariko Hayashi (@hysmrk)
※プロジェクト進行中、未知のリスク（不慮の事故など）も十分に起こりうる前提でいることが肝要
［リスク回避の例］
・スコープから外す
・スケジュールを延ばす
・目標を下げる
［リスク転嫁の例］
・第三者に移管（外部委託）する
［リスク軽減の例］
・高スキル人材をアサインする
・チェック工程を多く設定する
・修正期間を長めに設定する

28. 7) 品質基準を明確にする
品質基準を明示
プロジェクトの目的・目標に合致し、ステークホルダーの期待に応え、洗い出した制約・前提条件
を満たす形で、具体的で現実的な品質基準・尺度を記述する
品質マネジメントの対象は成果物に限らず
成果物のほか、プロセス、コミュニケーションを含む
品質基準は実行に入る前に設定
基準を満たすための作業フローを組んでから実行に移る
2020/10/25 28Mariko Hayashi (@hysmrk)
※品質基準をどのように規定・記述するかは、プロジェクトのテーマによって大いに異なる

29. 7-i) 「品質」と「等級」を分けて理解する
品質
あるものの、明示された、あるいは暗黙の
ニーズを満たす能力に関する特性の全体
飛行機を落ちないようにするのは品質マネジメント
等級
同一の用途を有するが、技術的特性が異な
るようなものに対して与えられる区分また
は順位
飛行機で、ビジネスクラスやエコノミークラスのよう
にコントロールして設定するのは等級マネジメント
2020/10/25 29Mariko Hayashi (@hysmrk)

30. 8) WBS（Work Breakdown Structure）を作る
2020/10/25 30
先に定義したスコープを、個別の作業単位に分解・階層化して記述する
プロジェクト終結までに必要な作業を把握し、スケジュールやコストを確
定するためのベースになる
Mariko Hayashi (@hysmrk)

31. 8-i) WBSの作成例
2020/10/25 31Mariko Hayashi (@hysmrk)
出典：「Webプロジェクトマネジメント標準」（共著：林千晶、高橋宏祐 出版社：技術評論社）

32. 8-ii) WBS作成のポイント
2020/10/25 32
作業項目はMECEに
スコープ定義をもとに、漏れなくダブりなく整理する
作業項目を適当な粒度で分解・階層化
作業が具体的にイメージでき、細かすぎず一覧性を確保
役割分担を明確に
作業項目ごとの責任の所在がわかるように担当を明記
リソース算出に使えるように
必要な人員・時間などのリソース算出に使える状態に
関係者に確認して精緻化
プロジェクトメンバーやステークホルダーに「抜け漏れがないか」「誤解をうむ曖昧さがないか」
といった確認をとってブラッシュアップ
Mariko Hayashi (@hysmrk)
※MECE（ミーシー）：mutually, exclusive, collectively, exhaustive

33. 9) 実行段階のコミュニケーション方法を決めておく
2020/10/25 33
プロジェクト始動後に必要なコミュニケーションとは？
* 誰と誰の間で？
* どういう内容を？
* どのタイミング・頻度で？
* 何の手段・ツールを使って？
* 記録の残し方は？
コミュニケーションの種類（例）
* 情報共有や通達
* 意見交換や議論
* 合意形成や承認
* PJ進行中の変更の要望出し、記録・共有
Mariko Hayashi (@hysmrk)

34. 10) スケジュールを策定する
2020/10/25 34
スコープ、WBS、品質、リソース、リスクなどを十分に検討してから作る
PJ期間を設定（開始、最終期限、必須のマイルストーン）
WBSをもとに各作業に適切な期間を割り当て、時系列でガントチャート作成
縦軸に、「識別子／工程／作業項目」を並べ、必要に応じて階層構造にする
横軸に、作業ごとの「開始日／終了日／所要時間／担当者」などを並べる
－所要時間の単位は 「時間」「日数」「週」など、適当な詳細度にする
－進捗状況といった枠を設けて（未着手／作業中／完了）などの選択肢を用意、メンバーに定期的に
入力してもらって進捗管理する使い方も
身近な作成ツールはExcelなどの表計算シート。専用のPJ管理ソフトもある
Mariko Hayashi (@hysmrk)

35. 10-i) WBSをもとにしたスケジュールの展開例
2020/10/25 35Mariko Hayashi (@hysmrk)
出典：「Webプロジェクトマネジメント標準」（共著：林千晶、高橋宏祐 出版社：技術評論社）

36. 10-ii) スケジュール策定のポイント
2020/10/25 36
作業間の関係に着目し、合理的なステップを時系列で組む
作業Aが終わらないと、作業Bに手をつけられない
作業Aが終わった後に、作業Bに入ったほうが安全
作業Aが終わらないと、作業Bを終わらせられない
時間に余裕をもたせる
時間的に遊びを一切設けないで作業を連ねてしまうと、一つの作業の遅延が全体に影響し、大幅な
遅れに発展しかねない。余裕をもったスケジュールを組む
リスクを含む作業項目を切り分け
リスクを含む作業は、リスクコントロールしやすいように作業項目を切り分けておく。ステークホ
ルダーの承認、フィードバックを受けての修正作業なども見込んでおく
マイルストーンを設定
最終期限の前にも適宜「スケジュールの節目」を設け、メンバー全員で進捗状況（スケジュール遅
延、予算超過、スコープ変更などないか）を確認したり、中間成果物の完成（関係者への説明や意
見聴取、承認、検収など）を確認するといったタイミングを設ける
Mariko Hayashi (@hysmrk)

37. 11) 計画書に落とし込み、皆を巻き込んで実行段階へ
2020/10/25 37
計画書の作成
以上の「何のために、何を、どのようにして」について、各要素を行ったり来たりしながら矛盾点
を解消して全体の整合性をとり、各ステークホルダーに合ったプロジェクト計画書に落とし込む
関係者と計画内容のすり合わせ
各ステークホルダーにプロジェクトの概略を説明し、意見聴取や協力要請・交渉を行い、プロジェ
クトメンバーとも相談しながら計画書の内容を見直し＆精緻化
変更点を関係者に周知して承認を得る
計画書の内容に変更点があれば各ステークホルダーに再度周知して、実行段階に移る承認を得る
⇒プロジェクト実行段階へ
Mariko Hayashi (@hysmrk)

38. 補足：このスライドで言及していないこと
2020/10/25 38
プロジェクトマネジメントの方法論［計画段階］
調達（契約・発注）
コストの算出
Mariko Hayashi (@hysmrk)
プロジェクトマネジメントの方法論［実行段階］
※全般的に割愛
※「品質基準」についても、汎用的なノウハウの言及はしているものの簡易な内容に留まっている

39. 参考書籍
2020/10/25 39
「Webプロジェクトマネジメント標準」
（共著：林千晶、高橋宏祐 出版社：技術評論社）
Mariko Hayashi (@hysmrk)
Web制作プロジェクトを前提にしており、2008年発刊の古い本
だが、壮大な「PMBOK」の知識体系を一般のビジネスパーソン
が取り入れて活用できる平易なノウハウに落とし込んでおり、プ
ロジェクトマネジメントの基礎知識を学ぶのにお薦めの一冊。
ロフトワークにて、全文をPDFで無償公開中
書籍『Webプロジェクトマネジメント標準』を全文PDF無償公開
https://loftwork.com/jp/news/2015/10/08_pmbok