なんか話題になっているぽい。
資料そのものはとても参考になるものの、
1ページがLTなみに薄く、ケータイ小説ばりに長い(合計285ページ)ので、
まとめてみた。今北は無理。
プロジェクトマネジメントについて
P170あたりまで、プロジェクトマネジメントとは何なのか、
どうしてプロマネが必要なのか説明されている。
- プロジェクトには当初に予想しきれないほど大きな不確実性が潜んでいる
- 従って不確実性とうまく付き合う必要がある
- イテレーションを重視しよう
- –こまめなPlan-Do-Checkサイクルで、不確実性から生まれる問題の早期発見と早期解決を繰り返そう
- 調査・戦略・設計・計画からは逃げない
–不確実性を下げ、見通しを良くするための地図を準備しよう
–それらはなるべくドキュメント化しよう
プロジェクトを計画しても、プログラマのスキルが思ったより低かったり、
仕様が思ったより複雑だったり、作業時間が思ったより少なかったり、
人員交代が思ったより多かったりなどが起因して計画は総じて期日より
遅れがちである。
個々の誤差は小さな誤差だが、それらが重なると当初の計画とは
大幅に違ったものにも成り得る。
これらの誤差は残業、増員、仕様変更でどうにかなるものかもしれないが、
それはどう考えてもデスマーチへの死亡フラグだ。
つまり、100%計画通りにいくプロジェクトなどこの世に存在しない。
しかしだからと言ってソフトウェアのプロジェクトに計画が必要ないという
わけではないし、プロジェクトは制御することが可能だ。
そのために、こまめなイテレーション(事後設計)を繰り返して、プロジェクトの
ズレを細かく軌道修正していく必要があるのだ。
しかし、建物などと違ってソフトウェアのプロジェクトはきちんと設計も計画も
なされないことが多い。不測の事態に対応するためにも計画や設計はきちんと
しておいたほうがよい。
なお、アジャイルとウォーターフォール、どちらにも長所短所はあるので、
アジャイルvsウォーターフォールといった対立構造ではなく、
アジャイル×ウォーターフォールというハイブリッド型で開発に臨むとよいだろう。
プロジェクトマネジメントの手順
P173以降からプロジェクトマネジメントの具体的な手順に入る
1. 調査する
2. 戦略を立てる(リスク一覧/開発戦略マトリクス/価値空間)
3. 設計する
4. 計画する(中長期計画)
5. スプリント(4週間単位の制作イテレーション)
調査は全ての起点のはじまりで、色々なものを調査する。
- 市場動向
–最新技術動向
–スタッフのスキルセット
–会社の財務状況
これらを調べることで、計画の不安定要素を出来るだけ排除する。
戦略を立てるときに、開発戦略を入念に考える。
重要度と開発の難易度を考慮して、
その機能やシステムがソフトウェアに必要かどうか、開発するとしてどのような
リスクがあるかを考える。
設計の際は、原則、頭の中で想像の出来得る限りは設計をとことん行い、思考検証し、設計を洗練させる。
作らすずとも頭の中で分かることはまず先に設計し尽くすべきだ。
本設計が固まっていないままプロジェクトを本格稼動させるのは大変危険である。
特に技術仕様は早期に固める。
計画する
タスクを洗い出して、期間やかかる金額を見積もり、優先度を決めて、開発を進める。
なお、期間の見積りは、期日を1つしか決めない一点見積りではなく、この期日までに
開発を終えたらパージェクトな理想的な締切と、この期日を越えても終わらなかったら
恥ずかしい最終的な締切の二種類の締切を用意する二点見積りのほうがよい。
開発者とそれ以外のメンバーで見積りを予想する見積りポーカーも面白い。
スプリント(階層的PDC)
毎日(朝会) 参加メンバー 5-8名
毎週(週報、週定例) 参加メンバー 各ユニットごと
毎月(月例) 参加メンバー 全員
ごとに、各メンバーが成果物と進捗状況を発表する。
各人のタスクは、タスク管理ボードを活用するとよい。
また、スプリントが終わる度にクライアントや上司へ進捗を報告する。
P268 まとめ
プロジェクトマネジメントの方法で得られる効果
- 不確実性を制御
– 不確実性が減る
– 見通しが立つ
– 早期に問題発見可能
– 計画修正や対策もしやすい
- メンタル効果
– スタッフ自身の作業と期間の見通しが立つので、無根拠になんとなく日々残業しないとならないのかもしれないというプレッシャーから解放される⇒残業や休日出勤が大幅減
– お互いの仕事を知ることができる
– 楽しくなる
- クライアントや上司からの信頼を得る
- 目標通りに満足行くプロジェクトの成果がしっかり出る
