ウォーターフォールにおける WBS 入門 研修コースに参加してみた
今回参加した研修コースは ウォーターフォールにおけるWBS入門 です。
いつもはテック系のコースばかりですが、今回はマネジメント系です!
ウォーターフォールなプロジェクトではWBSとガントチャートは必須のものですが、このコースではその分解や演習だけでなく、プロジェクトが失敗するポイントも合わせて紹介頂きました。
近い将来にプロジェクト計画を考えるポジションにつく、プロジェクトリーダーやプロジェクトマネージャの方にはオススメの内容です!
では、どんな内容だったのかレポートします!
もくじ
想定している受講者
- システム開発に携わったことがある方
受講目標
- WBSがつくれる、工数見積りができる
講師紹介
テック系だけでなくマネジメント系でも登壇できる 大石 宏一さん が登壇されました。
略歴紹介とともに、日本の開発モデルに関して小話されました。
- 日本だけが圧倒的なウォーターフォール主義
- 欧米ではアジャイルが増えているというのに
- 契約書からそうなっている
- 何をいくらでいつまでに作る、という契約
- 課題解決に向いてない
- 欧米ではインハウスでエンジニアがいる
- 一応日本でも総務省が頑張って情シスの人口を増やそうとしている
なかなか契約スタイルは変わりませんが、とはいえ時間契約にしても、いつまでに開発できるのか、というのがアジャイルでは見積もりにくい、というのも大きな背景にあります。 難しいところですね。
今日の狙い
- 主にはWBSとガントチャート
- WBSをうまく作るというより、システム開発を成功させるという視点でお話します
圧倒的なウォーターフォール
- 96%がウォーターフォール
- 計画重視型
- 計画を作る上で必要になるのがWBS
- ウォーターフォールは計画でミスできない構造
- 夏休みの宿題すら計画的にできないのに?
- 計画するのは難しいのです。。
- WBSが開発に役立っていない
- プロジェクトマネージャだけのツールになっている
なぜWBSが必要なの?
では、WBSやめればよいのでは?
- WBSが無い世界
- 何からやるのか見えない
- 誰がやるのかわからない
- スケジュールが見えない
- などなど
やっぱりWBS必要ですね。
WBSとは?
- 現場ではツリー構造を見ることはないでしょう
- なぜならガントチャートになってるから
- ただツリー構造を見ると 100% ルール が見える
- 100% ルール
- 分解したら子要素を足すと親ノードが100%になる
- 分解しっぱなしではなく、検算しましょう
- 検算するときレベル別に横串で見るとヌケモレに気付きやすいです
- 親ノードから数えて 7段階までしか分解してはいけない
- 超えると失敗可能性が高い
- 7段階を超えると、多段階リリースなどでプロジェクトを分けるとよいです
- 100% ルール
- 要件定義後に再見積もりしましょう
- 営業が契約しているので、モレがあることが多いです
- 契約のときに必ずこの条項を入れましょう
- 普通のことなので、何ら恐れる必要はありません
要件定義後で再見積もりするのは、ちょっと意外でしたが、当たり前なんですね。確かに、精度の悪い見積もりのままではお互い不幸になってしまいます。
7 × 7 ルール
- 個人的には 10 × 6 ルールを使っている
- ウォーターフォールではレベル2がフェーズ
- 基本設計、詳細設計、実装、テストなど
- フェーズを高次元にしておくと、子要素を展開しやすいです
- タスク完了の成果物を書いておきましょう
目的と目標
目的と目標は違うんですね。
- 目的: 的、ゴール
- 目標: チェックポイント
- 計画: 目標を繋いでゴールにする
目標の立て方
目標の立て方にはいっぱいありますが、SMARTというオススメの方法を教えていただきました。
日本人にはA、Rがとても重要。ちゃんと背景を説明して、納得してもらいましょう。欧米では実はあんまり関係ない。。。
計画の立て方
- 無理、無駄、ムラを排除しましょう
- ただ、日本のプロジェクトでは無駄、ムラはあんまり発生しない
- 無理が一番多い
WBSでチーム演習 !!!
ここからは実際にある仮想の開発プロジェクトをもとに、実際にWBSを作ってみます。
セミナー会社のwebシステムが題材
- データ移行はなし
- 基本設計以降からプロジェクト開始
- 各フェーズでお客様が捺印して承認
4名1グループでWBSを書いてみました。
回答例と質問応答
大石さんから回答例を挙げてもらって質問応答に移りました。下はその回答例の一部です。
Q. 末端のノードのサイズはどれぐらいがよい?
A. それはこれからやります!
WBSのサイズと工数見積
ここからはWBSの分解レベルと漏れがちなところ解説いただきました。
8/80 ルール
- 末端ノードのサイズ
- 8時間 ~ 40時間
- 8時間未満はキリが無くなる
- 80時間を超えると、途端に人間は精度が悪くなるので、分解しましょう
- 複数人で見積もりしましょう
不確実性のコーン
- x軸が時間
- プロジェクト初期では誤差が16倍あります
- なので要件定義後に再見積もりするというのは理にかなっている
- 複数人で見積もりすると、精度が上がります
ちなみに、この不確実性を減らすために、どんどんやって学習していく、というスタイルがアジャイルですね。
ガントチャートに品質を盛り込む
- 45%~80%が上流にバグがある
- 40~60%が手戻り工数
- 以上はIBMが発表
- ちゃんと上流でレビューをタスクに入れましょう
- バグをテストで取ろうとするのでは遅い
受講者の中にもレビューを入れて、後半の開発時間がうなぎのぼりにならない方がいました。
誰が工数見積をするのか
実際に大石さんが会場で誰が見積もりするのかアンケートを取ってみました。そうするとPM、メンバーそれぞれ約半数ずつという結果でした。どちらもやるべきということですね。
- PMがやる
- 初期フェーズで計画できる
- 現実的ではない
- メンバーがやる
- スケジュールが立たない
- 現実的になる
- PMがWBSを悲観的に作って、メンバーが作ったものとで差分比較する
- PMの見積より多ければ確認しましょう
体制
- 成果物を作ることがプロジェクトを前に進める // 会議ではない
- 作る人が100%専念できるよう、PM･PLが立ち回る
- PMはメンバーと一緒に走るのではなく先を見ておきましょう
見積の単位
1日8時間ではなく6時間で計算しましょう
ガントチャートを運用する
計画したらそれで終わりでなく、ちゃんとチェックしようというお話です。
WBS の見直すときの注意
- 計画は計画通りにいきません
- ヌケモレがあれば、スグに反映しましょう
- スナップショットを取るとよいです
- 100%ルール / 7×7 / 8/80ルール とかチェック
- 余裕があれば検算しましょう
この運用方法を解説頂いたあと最後の質問コーナーに移ったので、私も質問してみました。
Q. ガントチャートだけではクリティカルパスが分かりませんが、どうするとよいのでしょうか?
A. クリティカルパス。。情報処理技術者試験ではよく出題されますが、現場では見たことがありません。
なるほどー、と一人合点しながら、このコースは終了しました。
まとめ
WBSの分解するときのルールだけでなく、要件定義後に再見積もりなどプロジェクト計画で失敗しがちなところも解説いただきました。
伺っていて、超計画的ということは、極端に失敗することを嫌う、という意識の現れかも知れません。AIの開発プロジェクトがなかなか立ち上がらないというニュースも、このあたりが背景にあるのかも知れません。
とはいえ、メンバーが開発を進めないことにはプロジェクトが終わらない、なので100%集中できる環境を作ろうというメッセージは、当たり前なんですが、忘れがちなことに気づけました。
プロジェクトリーダーやマネジメントに近い将来携わるかたにはとてもオススメのコースです!!
label SE カレッジの無料見学、資料請求などお問い合わせはこちらから!!
label SEカレッジを詳しく知りたいという方はこちらから !!
SEプラスにしかないコンテンツや、研修サービスの運営情報を発信しています。