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

Copyright© 2016 RAKUS Co., Ltd. All Rights Reserved Copyright© 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/1

0

5/1

1

5/1

2

5/1

3

5/1

4

5/1

5

5/1

6

5/1

7

5/1

8

5/1

9

5/2

0

5/2

1

工

数

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 「プロジェクトマネジメント」に大事なこととは？

Business