クリティカルパスを意識する
俺が属している会社は職能制組織とマトリックス制組織が混ざったような組織構造を取っていて、恐らく、殆んどの中小
SIer は同じような組織構造だと思う。
俺は去年から 2 つの課を兼務しながら、開発プロジェクトの PM
を行っていて、さらにうちの会社にしては大きめな別プロジェクトの仕事の現場作業に割り当てられてるのだが、そのプロジェクトの
PM
の経験不足からか問題点が浮き彫りになってきている。ウォーターフォールモデル(以下、ウォーターフォール)で進んでいるプロジェクトを横目で見つつ思ったことを書き留めておく。
ウォーターフォールは悪なのか
最近はウォーターフォールは問題が大きいので、大手 SIer
も開発手法にアジャイル開発を取り込んでいると聞く。しかし、大成功しているという話は聞かない。
会社で行われるプロジェクトの殆どはウォーターフォール。これは偉い人がこれ以外をよく知らないから決められていると確信している。今回もご多分に漏れずウォーターフォールで行われている。
ウォーターフォールとは
ウォーターフォールとは、水が上流から下流へと流れていくようなモデル。
[営業活動] → [受注] → [設計] → [製造] → [検証] → [納品]
というように、工程が上流工程から下流工程へ流れていく。
システム開発で古くから使われていた手法で、20
年前に俺が専門学校で習ったのもこれだった。
ウォーターフォールの特徴
個人的に思うことを書き連ねてみるとこんな感じ。
- イメージが湧きやすいので、開発経験が浅くても参加しやすい
- 「いつまでに何ができている」というようなマイルストーンを立てやすい
- 後工程からの戻りを意識していない
- 前工程に戻らなければスムーズに流れる
- 前工程に戻ると大幅なコストがかかる
- 昔から行っているので、何となくマネジメントができる
- 過去に似たようなプロジェクトを行っており、参考資料が多い
- 過去のナレッジを活かすことができる
- 成功したかどうかも知らないプロジェクトを真似て劣化版プロジェクトが走る
- 一括請負契約と相性がよい
- 契約時に全体を想定して見積もれる
- 今までやったことのない案件だとリスクを多く背負う
ウォーターフォールでのクリティカルパス
個人的にはプロジェクトマネジメントで特に気にするのはクリティカルパス。
クリティカルパスを把握できていないのは、どの工程が重要なのかが判らないという事。
俺のマネジメントで取っ掛かりを大まかに書くと、フェーズごとのマイルストーンを立てて、タスクを落としながらクリティカルパスを探していき、そこからクリティカルなリスクを洗い出して行くという感じ。
クリティカルパスとは
クリティカルパスとは、プロジェクトを最短で回すために絶対にずらせないタスクとタスクの経路で最長(最も長く期間がかかる)のもの。
通常のプロジェクトではタスクは並行して動くが、その中でも、このタスクが遅延するとプロジェクト全体のスケジュールに影響するというタスクをつないだ線をクリティカルパスと呼ぶ。
今後考えているクリティカルパスの求め方、クリティカルフィーチャーパス
多分、俺なんかが考える手法なんて誰かが考えて実践しているだろうけど、今後はアジャイル的な要素を取り入れてウォーターフォールを回してみようと思う。スパイラル・モデルに近いかもしれない。
どういう事かと言うと、できる限りフィーチャー(特徴的機能と解釈)で分けて、フィーチャーをつないだ経路で管理する。フィーチャーをつないだ経路で最長のものをクリティカルフィーチャーパスと呼んでみよう。
イメージ的にはこのような感じ。
今までのウォーターフォールモデル
ざっくり過ぎてイメージが湧かない。 20
年前はこれで良かったかもしれないが、今はシステムも業務も複雑になっている。
要件定義をざっくり分けてもこうなる
その中でも細かくして、それぞれでイテレーションを回して、やり直しの期間を短くする。
そうすると、要件定義の中でも色々あるのがわかる。
(ちょっと契約を入れるのはおかしいけど)
そうすると、その中でも優先順位があるのがわかる。 
意味のある小さな単位を組み合わせていくのが大切。
何でこのようなことを考えたかと言うと、次のメリットを感じたから。
クリティカルフィーチャーパスのメリット
- 何が必要なのかが判りやすい
- プロジェクトメンバーで意識の統一が図りやすい
- スケジュールで 何が遅れているか が判りやすい
- 何のために何をするかが判りやすい
- 前工程に戻るリスクがフィーチャー内で閉じられる可能性が高い
- フィーチャー同士のインターフェースを決める事ができたら並行で開発を進められる
まとめ
この考えは最近の Restful なシステムとも相性がいいと思うんだけどな。