Forkwellキャリア談義17 「プロジェクトマネジメント」に大事なこととは？

Copyright© 2016 RAKUS Co., Ltd. All Rights ReservedCopyright© 2016 RAKUS Co., Ltd. All Rights Reserved
「プロジェクトマネジメント」
に大事なこととは？
株式会社ラクス
鈴木勇
Forkwell キャリア談義#17
1

Copyright© 2016 RAKUS Co., Ltd. All Rights Reserved
鈴木勇（すずきいさむ）
• 32歳、既婚
• Node.jsコミュニティで微力ながら活動中
• 休日は料理したり、海外ボードゲームしたり
• 2010年プロジェクトマネージャ試験に合格
2

鈴木勇（すずきいさむ）
• 2006年にCSK（現SCSK）に入社
– オンライン証券システムの開発
• 2013年にラクスに中途入社
– の開発
– 新卒採用のハンズオンで講師、など
3

今日話すこと
• プロジェクトを
「マネジメント」するとは
4

の前に
5

前提
• 実装上の問題、課題に気付かない
– 報告しても理解されない、時間がかかる
• アドバイスできない
• ヘルプに入れない
プログラミング能力がない人間に
プロジェクトはマネジメントできない
6

「俺はプログラミングできない」と
公言するPMからは逃げましょう
不幸になる未来しかありません
7

前提2
• 言われなくてもみんな頑張ってます
解決策として
「頑張れ」は言わない
8

本題
興奮しすぎたので話を戻します
9

プロジェクトマネジメント
10

11

management = manageすること
• manage (他動詞)
1. （物事を）うまくやる
（困難があっても）なんとかする
2. 管理する、運営する、監督する
12

13

面倒事なことをなんとかすること
14

話の流れ
• 達成すべきこと
• 何が難しいのか
• どう取り組むべきか
• ノウハウの共有
15

話の流れ
16

プロジェクトをなんとかする
17

プロジェクト＝利益を生むもの
18

＝利益の達成
19

現場の視点は？
20

メンバーを最大効率で稼働
21

メンバーの最大効率とは
• 作業待ちがない
22

• 河原の石積みをさせない
–前提が曖昧な作業をさせない
23

• 繰り返しによって効率は上がる
–自動化を検討することも含めて
24

• レベルにあった作業を行う
–今できることではない
–次に出来るようになるべきことをやる
25

これは違う
• 出来る人にタスクを積む
–余裕を与えてフォロー（教育）役にする
–簡単な作業はコストにあわない
26

これは違う
• 「とりあえずやっておいて」
–だいたい前提ひっくりかえってやり直し
27

効率の向上は
各メンバーの守備範囲拡大で
成し遂げられる
28

＝メンバーを最大効率で稼働
＝メンバーを最大効率で成長
29

話の流れ
30

話の流れ
31

プロジェクトは変化するもの
この事実を意識して対応することが大事
32

プロジェクトが変化するなら
開発計画も変化するのが当たり前
当初の開発計画を一度も見直さないプロジェクトがあったとしたら……
33

変化に合わせて開発計画を
変更するのはすごく大変
じゃあどうする？
34

事前に起きそうなことを予測する
＝リスクマネジメント
35

リスクマネジメント
• 起きうる事態に対する
必要なヒト、モノ、カネの準備
36

たとえば
• スケジュールのバッファ
–「不安だから○人日」というのはよくない
–発生確率と対処コストのバランス
37

たとえば
• 契約書の免責事項
–災害時とか、特に発生確率の低いものに
38

何かが起きても手遅れになってから
動き出すことはよくある話
嫌なことは認めにくいものです
39

リスク発生時の動きは事前に決める
• チェックするタイミング
消滅するタイミング
–環境構築完了日
–実装開始予定日
–テスト開始後1週間経過
40

• 判定条件
–仕様が未確定
–N件以上のタスクが遅延
–重要タスクが未完了
–追加要件が発生
41

• 対処方法
–仕様確定のために役職者を動かす
–バッファを使ってN日スケジュールを
ずらす
–ベテランメンバーをサポートにつける
–段階リリースに分割する
42

事前に決めることで
いつ起こるかわからないものが
コントロール下に置かれる
完璧はない
ダメだったら次回への反省点としてノウハウ蓄積
43

扱いにくいものを扱えるようにする
見える化と一緒
44

話の流れ
45

話の流れ
46

さあプロジェクトが動き出した
何を見る？
47

基本は
タスク進捗とコスト消化の計測
48

永遠の進捗90％問題
進捗をパーセンテージで報告してもらってもあまり意味ない
49

なぜ90％で止まるのか
• 100％の状態がわかっていない
• 地味な付随タスク
• 進めていくと必要な作業が増えていった
1タスクが大きすぎて把握できていなかった
50

どうするか？
• タスクを小さく分ける
–全体を見渡せるようにする
–目安は5人日以下
51

そもそも進捗度を
100分割する必要ある？
52

どうするか？
• 未着手 (0%)
• 着手 (10%)
• 実施中 (50%)
• 完了 (100%)
の4段階で報告
53

完了かどうかを計測する
• タスクの件数（1軸）で
進捗を評価できるようになる
54

もう一歩進めると
55

EVM
Earned Value Management
国のプロジェクトだと義務付けられていたりするようです
56

計画との差分で完成時を予測する
57
0
10
20
30
40
50
60
70
5/9
5/10
5/11
5/12
5/13
5/14
5/15
5/16
5/17
5/18
5/19
5/20
5/21
工
数
PV：計画出来高
EV：実績出来高
AC：消化工数
EAC：完了時工数予測
BAC：完成時総予算
タスク完了が
ちょい遅れ
完了までに
更に広がる
実コストは
オーバー

スケジュールのブレをとらえられる
• 「○日遅延です」の精度が上がる
• 「今の遅延」から「完了時の遅延」
が見えるようになる
58

「単価」の概念
• 誰が（単価）
• 何日間で（時間）
• いつまでに（完了予定日）
59

時間ではなく、コストで考えられる
• 「○日遅れ」ではなく
「□円分の遅れ」で考えられるよう
になる
60

EVMまでやるとなると
人力計測は大変
各メンバーが自分で
タスク単位の稼働記録、日々の進捗更新する必要がある
→メンバーに対してもコスト意識を植え付けられる
61

計測が自動化されれば
リアルタイムに進捗の予測が出来る
「計画通り」である進捗報告も不要になるので
課題やトラブルの解決にフォーカスできる
62

計測が自動化されれば
リアルタイムに進捗の予測が出来る
「計画通り」である進捗報告も不要になるので
課題やトラブルの解決にフォーカスできる
63

で、計測したら何に注目すべきか
64

見るべきは計画とのブレ（差分）
遅延だけではなく、前倒しも注目する
65

ブレ＝想定外の何か＝対処が必要
66

想定外の何か
• 見込みよりもタスクの難易度が高かった
• 前工程が終わっていない
• 必要な入力（資料）が揃っていない
• 作業漏れで早く終わった
• 見込みよりもメンバーの能力が高かった
67

遅延だったら
ヒト、モノ、カネのどれかが必要
ガッツで遅延は解消しない
68

前倒しだったらフォローや
タスク割り当ての見直しなどが必要
ブレの内容に応じて対処を考える
69

課題はいったん引き取る
課題の発見には感謝を
70
このあたりはPMスタイルによりけり

課題発見者自身で
解決することが良いとは限らない
担当が違うメンバーならすぐ解決することがすごく多い
71

日々の進捗報告は
課題や困ったことを吸い上げる場
予定通りのことを報告するのは時間のムダ
72

見つかった課題＝タスク
最適な人に割り振るのがPMの仕事
自分に割り振ることも多いですが
73

メンバーが集中出来る状況を作る
最大効率で稼働させるため
74

余談
• タスクの文脈を伝える
–腹落ち感がないタスクは効率上がらない
–前提がわからない作業はムダにつながる
75

余談
• 余裕を与える
–作業待ちはダメ
–しかし余裕がないのもダメ
• 余裕がないと改善が生まれない
• 現場の不安感が放置されてしまう
76

どうやってもダメなとき
• 会社、上司に「無理」って言う
–無理なものは無理
–ただし数字を出す
• 助けようにも上司も助けるための材料が欲しい
• 時間や金でなんとかなるなら代替案も
77

話の流れ
78

話の流れ
79

そもそも共有不要な手法を選ぶ
80

IT業界は標準／規格がある世界
1. 国際的な標準化団体 ISO, IETF, W3C...
2. 国内の標準化団体 JIS, (IPA), ...
3. 公開されている企業標準
4. 社内の標準最終手段
→参照が多いものを優先して採用するべき
81

社外のエンジニアとも共有される
のでメンバー調達が楽になる
「うちは社内独自言語で開発しています」っていう会社に
積極的に入社したい人なんていますか？
82

ただし標準を盲信してもダメ
違いを吸収するためにPMがいる
各プロジェクトに類似性はあっても同一のプロジェクトはない
83

と、大まかには共有不要な枠組み
で仕事しようという話ですが
84

とはいえ
細かな業務ノウハウの共有は必要
必要なツールは整備しましょう
85

現場で利用するツールは
現場が使いたいと言い出したものを
一方的に押し付けられても使わない生き物です
86

クラウドサービス使えないなら
クローンOSS探しましょう
有名なサービスなら大抵出来のいいクローンOSSがあるはず
87

ノウハウの蓄積は更新前提で
• Wikiなどは最初の1行が高コスト
• 最初からしっかり書かない
• 概要と関係者が誰かを共有する
だけでも有意義
88

話の流れ
89

☺
ご清聴ありがとうございました
90

Forkwellキャリア談義17 「プロジェクトマネジメント」に大事なこととは？

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie Forkwellキャリア談義17 「プロジェクトマネジメント」に大事なこととは？

Ähnlich wie Forkwellキャリア談義17 「プロジェクトマネジメント」に大事なこととは？ (20)

Mehr von Isamu Suzuki

Mehr von Isamu Suzuki (6)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)

Forkwellキャリア談義17 「プロジェクトマネジメント」に大事なこととは？