SINAPさん社内研修 - プロジェクトを"うまくやる"ためにできること

プロジェクトを“うまくやる”ために
できること

2014年1月20日 @ SINAP

今日話すこと＆やること
•  プロジェクトってなに？
•  プロジェクトを失敗させないために
–  心構え的なこと
–  手法的なこと

•  みんなでやってみよう

Copyright d-three All right reserved.

2

軽く自己紹介


3


4

大崎誠
makoto.osaki

•  2000年よりウェブ業界に従事
•  今で言うブラック企業に類する会社での下積み後、
SIer ⇒ Web制作会社 ⇒ 2006年からフリーランス
•  主戦場はウェブ開発案件におけるPM業務
（大型サイトリニューアルが得意分野）
•  2013年4月より、後進指導としての講師業および
プロジェクトマネジメント支援業務を開始

5

では本題へ


6

さていきなり問題です
みなさんおそらくご存じのPMBOK
PMBOKにおけるプロジェクトの定義で
特に強調されている2つの項目は？


7

プロジェクトの定義
•  独自性
–  まったく同じプロジェクトはない

•  有期性
–  明確な開始と終了がある

プロジェクトとは、独自のプロダクト、サービス、所産を創造す
るために実施する有期性のある業務である。
（PMBOK第5版日本語版より抜粋）

8

プロジェクトとは

これまでやったことがないことを
期日までにやり遂げなさい、ということ


9

わりとみんな失敗している
情報化プロジェクトの成功率
日経コンピュータ 2008年12/1号「特集1-成功率は31.1% 第2回プロジェクト実態調査」をもとに編集

出典：富士通総研情報システム改革を成功させるカギは“企画”と“定着化”にあり
http://jp.fujitsu.com/group/fri/column/opinion/201207/2012-7-1.html

10

プロジェクトを
失敗させないために
∼心構え的なこと∼


11

不確実性を認める
•  プロジェクトの状況は常に変化する
変化の兆候、そのニオイを嗅げるかどうか
•  計画のうち、特にスケジュールは「たたき台」
変化をシミュレーションするためのツール
•  ただし、計画をおろそかにしてよいということ
ではもちろんない

12

鬼が出るか蛇が出るか

出典：wikipedia 百鬼夜行絵巻 http://ja.wikipedia.org/wiki/百鬼夜行絵巻

13

プロジェクト計画で大事なこと
•  今わからないことが何か？を明確にする
–  既知：わかっていること。事実
⇒具体的な実行計画を立てる
–  未知：今はわからないこと
•  なにが未知なのか？
•  既知になるための条件は？
⇒リスクや前提として計画に盛り込む

14

負けるPM＝不確実性に弱い
•  常に受け身
–  受託畑、特に制作のみを請負う組織に多い気がする

•  複数の視点・視座で見るのがニガテ
–  目の前のことや相手とはうまくやれる

•  手法にとらわれる
–  PMBOKや、過去の資産であるテンプレートは有用。
だが、全く同じプロジェクトは2つとしてない

15

3つの「先（せん）」を意識する

先の先
相手の気持ちを認め、
仕掛けてこないうちに
動く

かなり難しい


対の先
相手の動きを察知し
て負けぬように動き、
同時に仕掛けつつも
先に打ち込む

後の先
相手が打ち込んできた
動きを読み、
応じ技を決める

難しい
16

見えないものは見える位置から

壁の裏を見たければ
回り込む or 壊す
かなり難しい

遠くを見渡したければ
俯瞰で見る

細部を確認したければ
近くに寄る

難しい

簡単
17

実は「壁」がやっかい
•  文化・風土の違い
•  目的の違い（一般論として）
–  顧客：公開までは投資
–  受託：公開がゴール

•  責任範囲


18

とはいいつつ、スコープの兼ね合いも
•  個人的な見解
–  契約ごとである以上、一定の責任分界はある
–  が、PMは本質的にプロジェクトの成功に寄与すべき
–  故にプロジェクトの成功に寄与するならば、
多少のことは必要悪として許容すべき
–  マネジメント≠管理
どうやりくりすればうまくいくかを考える

19

手法にとらわれすぎない
知識も大切だが、知恵をもっとだせ。

知識は比較的簡単に手に入るが、
知恵は大きな努力と体験がないと
なかなか手に入らない。
安藤百福 - 日清食品創業者

20

プロジェクトを
失敗させないために
∼手法的なこと∼


21

転ばぬ先の杖


22

プロジェクト計画は大事
•  Web開発案件だとこんな感じ？

長くなるので、興味があれば
PMBOKや解説書を参照して
ください。

–  プロジェクトの目的
–  前提条件／制約条件
–  スコープ／成果物
–  WBS／スケジュール

このあと扱うのはココ

–  体制
–  コミュニケーションルール
–  予算
–  リスクに対する考え方

23

ここから先の話の前提
•  プロジェクトの背景や目的はすでに共通認識
•  制約や前提もある程度見えている
•  その上で、プロジェクト推進していく上で
WBSとスケジュールを立てる際の手法を扱う
•  リソースの制約は大事だが、話を単純化するた
めに基本的には考慮から除外する

24

さてここでまた問題です。

WBSってなんでしょう？


25

WBSとは？
•  Work Breakdown Structureの頭文字
–  Work

：名作業

–  Breakdown ：動分類する
–  Structure

：名構造、体系

•  プロジェクトマネジメントの計画フェイズにおける主要なツールで、プロジェクトの
成果物あるいは仕事（work）を詳細区分（breakdown）して階層構造
（structure）化した図表、あるいはその図表によってプロジェクトのスコープ全体と
その中で作られる成果物ないしは作業の関係を体系的に集約・把握する手法のこと。
出典：ITmedia エンタープライズ情報マネジメント用語辞典 http://www.itmedia.co.jp/im/articles/0508/05/news117.html

26

要は
やることを書きだそう
ということ


27

WBS ≠ スケジュール
•  WBS
–  スコープマネジメントの領域
–  インプットは顧客の要求事項が主

•  スケジュール
–  タイムマネジメントの領域
–  インプットはWBSや各種前提・制約条件


28

超ざっくり言うとこの違い

WBS

スケジュール

例示：WebSig1日学校 2013のWBSの一部

29

WBSを作るときのコツ
•  適切な切り口でトップダウン
–  Web系で多いのは、時系列（工程）別と機能別
–  可能な限り詳細化。ただし管理できる範囲で
–  ざっくりしすぎても、細かすぎてもダメ

•  だれが見てもわかるように書く


30

WBSはスコープ定義のツール
プロジェクト定義
プロジェクトスコープ策定

サポートOS定義

WBS作成

サポートブラウザ定義

プロジェクト計画

…

ユーザー環境定義

スクリーンサイズ定義

サイトコンセプト策定

使用可能リッチコンテンツ定義

ターゲットユーザー定義

プラグインバージョン定義

ユーザー導線設計

ファイル命名規則定義

概要設計
ほげほげプロジェクト

技術要件定義

物理設計基準定義

パス記述方法定義

サイト構造設計

ファイル格納ルール定義

画面設計

XHTML仕様定義

テンプレート設計

CSS仕様定

詳細設計
…
…

実装技術定義

JavaScript仕様定義
コメントタグ記述定義

時間や費用の見積ができるレベルに

その他コーディングルール定義

31

三人寄らば文殊の知恵
•  トップダウンで詳細化すると
詳細がおろそかになりがち
•  その逆もしかり
•  分野や視点が異なる複数人で
作ると、ヌケモレが少ない


32

省略してはいけない項目
•  その項目が与える影響を考える
–  コスト
–  スケジュール
–  リスク

これらに影響する項目は
WBSに必ず記載しておく

–  スコープ
–  品質


33

だれが見てもわかるように
•  書類がひとり歩きしても問題ないように
–  WBS項目
–  識別コード
–  作業の内容
–  作業に必要なインプット、作られるアウトプット
...など。


34

WBSの意義
•  プロジェクトスコープを可視化できる
–  合意された事実に基づくもの
–  仮定にすぎないもの

•  可視化によって関係者間の認識の相違を防ぐ
–  顧客の期待のコントロールのための
ツールとしても使える


35

Work #1


36

お題
•  一ヶ月後に友人の誕生日があります
•  数人でパーティを企画することになりました
•  このパーティを開催するにあたってのWBSを書
き出してみましょう
•  制限時間
–  自分で作る：20分まわりと意見交換＋調整：10分

37

WBSの次はスケジュール


38

スケジュールを立てるときのコツ
•  タスクの依存関係と順序設定を適切に
–  複数のタスク間のつながりを意識する

•  いきなり期日ありきの逆算をしない
–  期日は大事だが、それありきだとわからないことも

•  クリティカルパスの本数は少ないほうがいい
–  複数のクリティカルパスがあるとやりくりが大変


39

タスクの依存関係
•  強制依存（ハードロジック）
–  作業の内容として自然と順序が決まってくるもの

•  任意依存（ソフトロジック）
–  過去の経験に照らし合わせるなどして、任意に順序
を設定できるもの

•  外部依存

契約ごとなど調整できない
ことが多いので注意が必要

–  プロジェクトの外から影響をうけるもの

40

タスクの順序設定
•  終了 ‒ 開始：FS（Finish ‒ Start）

基本は
これで

•  開始 ‒ 開始：SS（Start ‒ Start）
•  終了 ‒ 終了：FF（Finish ‒ Finish）
•  開始 ‒ 終了：SF（Start ‒ Finish）


41

料理に例えてみる

画像：レシピサイトぷちぐる http://oisiso.com/potesara.html


42

終了 ‒ 開始：FS (Finish ‒ Start)

茹でてから
つぶす

•  後続タスクの開始は、
先行タスクの完了に左右される
•  いわゆるウォーターフォール。
基本はこの順序設定で整理する

43

開始 ‒ 開始：SS (Start ‒ Start)

調理が始まったら

味見ができる

•  後続タスクの開始は、
先行タスクの開始に左右される

44

終了 ‒ 終了：FF (Finish ‒ Finish)

調理が終わったら

調理器具の片付けを終えられる

•  後続タスクの完了は、
先行タスクの完了に左右される

45

開始 ‒ 終了：SF (Start ‒ Finish)

•  後続タスクの完了は、
先行タスクの開始に左右される
•  実際に使用するケースは少ない

46

時間を見積もる
•  リソース観点で見積もる
–  投入する人員のスキルで所要時間が変わる
–  人員の投入時期が限られる

•  所要期間の観点で見積もる
–  機材購入などには一定の期間が必要


47

こうやってスケジュールを
立てていくと・・？


48

おそらく期日に間に合わない

だけど、
最初はこれでよい


こ
の
日
に
公
開
！

49

そのあと検証しながら調整
こ
の
日
に
公
開
！

調整したところは
進行上注意すべきところだと
明確に認識できる

50

「まずは積み上げ」がポイント
•  無理・矛盾を可視化することができる
–  期日逆算のスケジューリングは一種の希望的観測

•  不確実性に対処できる局面を認識できる
–  依存関係や順序設定を整理してシミュレーションを
行うなかで、スケジュールの弾力性やリスク度合い
を客観視できる


51

またまた問題です

クリティカルパスって
なんですか？


52

クリティカルパス
•  所要時間が最長の経路
•  プロジェクト全体の作業開始から終了までをつ
なぐ、遊び時間の全くない経路
•  この経路の遅れはすなわち完了日の遅れ
•  スケジュールの短縮の際はクリティカルパスに
注目する

53

どれがクリティカルパス？
作業B
2人日

作業A
2人日

作業C
3人日

作業E
4人日

作業F
3人日

作業D
1人日

作業H
2人日

作業G
5人日


54

正解はこれ
作業B
2人日

作業A
2人日

作業C
3人日

作業E
4人日

作業F
3人日

作業D
1人日

作業H
2人日

作業G
5人日

スケジュール調整時はクリティカルパスに注目

55

スケジュールの調整


56

スケジュールの変更是非の評価
•  現行のスケジュールでプロジェクトの目標を満
たせるか
•  担当者の負荷は現実的か。無駄はないか
•  各作業の時間的・技術的な制約または前提が変
化したか
•  作業実績によりクリティカルパスが変わったか

57

短縮手法① ファストトラッキング
•  本来は順を追って実行すべきものを
並行して実施すること。いわゆる「五月雨」
–  順序設定としては、SSまたはFF
–  短縮はできるが、手戻りリスクが高い

ファストトラッキング

58

短縮手法② クラッシング
•  コストをかけて（人員を投入して）スケジュー
ルを短縮する手法
•  プロジェクト終盤では、効果がないことも

クラッシング


59

後手に回らないために
•  基準計画を設定し、常に実績との差異を観察する
•  進行を妨げる課題は、管理表に記載して追跡する
–  ID・内容・重要度・期限・担当者・完了条件・状況など
–  5W2Hの一つでも欠けたら起票

•  基準計画との差異を見極め、現実に即していないと
判断したらすぐに妥当性のある計画に変更する


60

Work #2


61

お題
•  先ほど作ったWBSをもとに
実施可能なスケジュールを立てましょう
•  期日までに間に合わせるにはどのタスクに注意すべ
きかを特定しましょう
•  ワークを単純化するため、リソースの割当てはしな
くてよいです
•  制限時間
–  自分で作る：20分まわりと意見交換＋調整：10分

62

まとめ


63

•  プロジェクトは常に変化する。
不確実性からは逃れられない
•  故に受け身ではなく攻めの姿勢で
•  実現不可能な計画は存在意義がない。
妥当性があり、変化に対応可能な柔軟な計画を
•  知識と経験でプロジェクトを成功に導く知恵に


64

質疑応答


65

お疲れさまでした


66

SINAPさん社内研修 - プロジェクトを"うまくやる"ためにできること

Recommended

Recommended

More Related Content

Similar to SINAPさん社内研修 - プロジェクトを"うまくやる"ためにできること

Similar to SINAPさん社内研修 - プロジェクトを"うまくやる"ためにできること (20)

Recently uploaded

Recently uploaded (7)

SINAPさん社内研修 - プロジェクトを"うまくやる"ためにできること