2015.3.19 社内勉強会資料 「プロジェクトとプロジェクトマネジメントの基本」

1. プロジェクトと
プロジェクトマネジメントの
基本
ばばとしあき @netmarkjp

2. Disclaimer
● プロジェクトメンバー/プロジェクトマネージャの初心者向け資料です
● ハートビーツ社内勉強会向けに作りましたが公開できそうなので公開しちゃいま
す
● ばば個人が知ってること、意識していることを書きました
○ 個人の見解です
○ プロジェクトマネジメントについてのインプットは実務+大学院での授業いく
つか
○ 担当領域予算数百万円、工期〜1年程度の小規模プロジェクトを主に扱っ
ています

3. プロジェクト

4. プロジェクトとは
「独自の成果物、またはサービスを創出するための
期限のある活動」
(Project Management Institute定義)
・・・噛み砕くと
● 明確に定義された目標がある
○ 明確に＝計測・判定可能
● 明確に定義された予算がある
○ (確保されるという意味ではなく定義されるという意味合い)
● 明確に定義された期限がある
○ 期限を決めずやるのはライフワーク/趣味
という要件を満たす活動
※HBの場合は契約期限を定義し独自のサービスを創出しているのでプロジェクトと言
える(ようにしているつもり)

5. プロジェクトの成功要件
外的判定軸
● Goal: プロジェクト開始時に定義した目標を達成すること
内的判定軸
● Q: Quality=品質
○ 成果物・サービスの品質が要求水準以上であること
○ 成果物・サービスの品質が適正であること
■ 過剰もNG
● C: Cost=費用
○ 原価(仕入費、加工費、人件費等)が規定値以下であること
● D: Delivery=納期
○ 期限内に遅滞なく完了すること

6. 翻って：プロジェクトが体を成
す要件
以下の要件を明確に定義する
● Goal
● Quality
● Cost
● Delivery
明確に定義できない？
→プロジェクトを発足させるだけの情報の整理ができていない

7. プロジェクトマネジメント

8. プロジェクトマネジメントとは
「プロジェクトを成功させるための活動」
プロジェクトの成功＝外的判定軸・内的判定軸を全て満足する結果となること
● Goal
● Quality
● Cost
● Delivery
を満たすこと(そのための手法)

9. プロジェクトマネジメントの鉄則
(1)
GoalとQuality・Cost・Deliveryは必ずバランスす
る！
● Gが増える(やることが増える)
○ QCDいずれも増える
○ Qそのまま→CD増える
○ CDそのまま→Qが減る
● Qが増える(品質を上げる)
○ Gそのまま→CD増える
○ G、CDそのまま→Qが減る
● ・・・
※銀の弾丸はない！

10. プロジェクトプロジェクトの鉄則
(2)
Goal、Quality、Cost、Deliveryから逆算すべし！
● Goalを達成するためには？
○ 何をしなければならないか洗い出す必要性=WBS作成
○ ・・・
● Qualityを達成するためには？
○ 水準の定義、工程・要員の確保
○ ・・・
● Costを達成するためには？
○ 適正な見積り
○ 生産性の担保
○ 資源の確保
○ ・・・
● Deliveryを達成するためには
○ 工程・進捗管理
○ 調達管理
○ ・・・

11. プロジェクトマネジメント手法
代表的なものがいくつか
● PMBOK=Project Management Body of knowledge
● PERT=Program Evaluation and Review Technique
● CPM=Critical Path Method
● ISO 21500
↓↓↓似ているけど違うもの↓↓↓
● ウォーターフォール
● アジャイル
○ スクラム
○ XP
→これらは開発手法であり、プロジェクト管理手法ではない

12. さらに深堀りしたい方向け：
PMBOKの考え方概要
プロセス(≒工程)、知識エリアの2軸で状況を整理し、漏れなく・バランスよく管理する
ことで成功率を上げる
【プロセス】
● 立ちあげ
● 計画
● 実行
● 監視・管理
● 集結
【知識エリア】
● 総合管理
● スコープ管理
● スケジュール管理
● コスト管理
● 品質管理
● 組織管理
● コミュニケーション管理
● リスク管理
● 調達管理
プロセス × 知識エリア のマトリックスのそれぞれの箱ごとに、すべきこと、見るべきポイ
ントは違う！

13. 注意点

14. Goalの定義は難しい
● 発注側が表現できない
● 受注側が引き出せない
↓↓↓
無理！！！現実を受け入れる
↓↓↓
早期にずれを修正することで対策
● ソフトウェア開発ならアジャイル開発手法
● 建築なら立体模型や3Dレイアウト

15. Qualityの定義は難しい(1)
発注側が素人orセミプロフェッショナル、受注側がプロフェッショナルである以上「何を
すべきか」を発注側が出し尽くすのは不可能
→善管注意義務が発生
デジタル大辞泉の解説
ぜんかんちゅうい‐ぎむ〔ゼンクワンチユウイ‐〕【善管注意義務】
《「善良な管理者としての注意義務」の意》業務を委任された人の職業や専門家として
の能力、社会的地位などから考えて通常期待される注意義務のこと。注意義務を怠
り、履行遅滞・不完全履行・履行不能などに至る場合は民法上過失があると見なさ
れ、状況に応じて損害賠償や契約解除などが可能となる。善良なる管理者の注意義
務。
[補説]民法第644条に「受任者は、委任の本旨に従い、善良な管理者の注意をもっ
て、委任事務を処理する義務を負う」とある。

16. Qualityの定義は難しい(2)
善管注意義務＝平たく言うと「プロならこのくらいはやっとかないとマズい」
※基準が曖昧※
IT業界で参考になりそうなもの・・・
● 各官庁が出しているアナウンス
○ 情報通信系は主に総務省だが、内閣府や警察庁などもあり
● IPA(情報処理推進機構)が出している各種アナウンス
○ 安全な〜
○ 非機能要求グレード
○ ・・・
● 徳丸本・子鹿本などの定番書籍

17. Qualityは計測も難しい
● 用途から期待される最低水準を満たす
○ 最低水準は善管注意義務に倣うとして、通常期待される程度は定義し難い
● 評価が主観的になりがち
○ 人によってバラバラ
↓↓↓
● 計測手法を用いた評価が模索されている
○ テスト密度
○ バグ収束曲線
● 善管注意義務の文脈で引用される文書や、定番書籍を指名する
※Quality評価として満足感を主眼に据えるのは基本的にNG→癒着・不正の温床(た
だし「個人宅の内装」のような発注主個人にフォーカスしたサービス提供の場合は、品
質評価は満足感主眼でOK)

18. プロジェクト評価

19. プロジェクト評価とは
● プロジェクトの結果を評価し、次回への糧とする
● 評価軸は「プロジェクトの成功要件」をそのまま使う
○ 別の軸を繰り出すウルトラCはやってはいけない(評価にならない)
プロジェクトの成功要件
● Goal
● Quality
● Cost
● Delivery
※Qualityは計測しづらいが、必ずなにがしかの方法で客観的に計測する

20. プロジェクト評価の注意点
● プロジェクト評価と事業評価は別
例1: 機能が膨らみ、過剰品質、コスト超過、納期遅延だったが、できた製品はすごく
売れて利益が出た
● プロジェクトは失敗
○ 見積り、進行に課題
○ 計画のブレにより苦しむ人を無視してはいけない
● (企業体力など諸般の事情が許せば)事業としてはアリ
例2: 定義した機能を適正品質、予算内、期限内に完遂したが、できた製品はちっとも
売れなかった
● プロジェクトは成功
● 事業としてはアレレ
○ 定義の段階＝プロジェクトをスタートさせる前の段階で失敗している
※適正に評価し、失敗を明らかにし認めることが改善・成長の第一歩

21. まとめ

22. 要点
● Goal、Quality、Cost、Deliveryを明確にすることが出発点
● プロジェクトの成功・失敗はG/Q/C/Dで決まる
● G=QCDのバランスをとる
● 定義して計測し評価する
● 逆算思考でアプローチする
● 管理手法・プロセスはプロジェクト成功のためのもの

23. QA