WBSの作り方と注意点

バリバリやる気のあるシステムエンジニアさんがいるらしく、マネージャからそのSEにWBSの作り方を教えてがて欲しいとお願いされました。

え、バリバリやる気のあるSEなら「WBSくらいできているんでしょ」と思うじゃないですか。ワタシもそう思いました。だから、「いいけどなんで」と。そうしたらマネージャさんは担当SEから技術のプロに持って行くなら今のままでいいんだけど、「その子をプロジェクトマネージャにしたいんだ」だって。なるほど、プロマネの目線でのWBSの作り方というか留意点などのノウハウを教えてあげられればいいのかな、と。その子は次のプロジェクトでサブプロマネのロールを兼務させるんですって。そのマネージャにしては、珍しく真面目に育成を考えているなぁ。

当のサブプロマネと一緒に来たのは技術SEと頼み込んできたマネージャの３人。おい、マネージャのキミはなんでいるのよ。「必要ないだろうし保護者なら不要だよ。仕事しろ仕事」と言ったら、一緒に勉強するですと。技術SEはWBSはサブプロマネが作ったものを技術リーダの観点で見るから「考え方を共有しておきたい」とこちらも前向き。すばら。

ワタシ「WBSはなんのために作るか知ってるかな」
サブPM「ドキュメントとかですよね」
ワタシ「そう、成果物を作る作業。それを作業の要素ごとに分解したものがWBSだよね」
ワタシ「基本的に IPO。。インプット、プロセス、アウトプットのIPO。PがWBSだね。Oが成果物。じゃあIはなに」
サブPM「えっと…」
ワタシ「何もインプットもなしでドキュメント作れるのかな」
サブPM「そうですね。要件がないと設計できないですね」
ワタシ「そうそう。プロセスで変換するには素材がないとね」
ワタシ「WBSの基本は、アウトプットのために作業をすることなんだね。その作業の要素を分解する」
技術SE「ものすごく当たり前ですね。基本中の基本、みたいな」
ワタシ「まあね、そういう表現選んでるから。でも、これさえ押さえておけばなんでもWBSにてきちゃう」

ワタシ「ところが、この知識だけでWBSを作ると実際の作業とずれてしまうだ」
サブPM「実際の作業とずれてしまう…」
技術SE「実際の作業とずれてしまう…」
ワタシ「だって、そこにはどんなシステム開発手法を採用するか考慮されていないから」
ワタシ「だから、システムの特性に合わせたシステム開発手法を選択する」
サブPM「選択する…」
ワタシ「次のプロジェクトはどんな開発手法を選ぶの」
サブPM「ウォーターフォールです」
ワタシ「じゃあ、局面の中はどんな業務フローにするの」
サブPM「業務フローですか」
技術SE「システム開発するのに私たちに業務フローはいらないですよね」
ワタシ「いやいや、プロジェクト期間中はメンバが様々な作業をするじゃない。そのとき好き勝手な手順で物作りしていいの」
サブPM「なんか出来上がる成果物がバラバラな品質になりそう」
ワタシ「そういうことだよね。だから同じ品質のものを作れるようにルールを作るんだよ」
サブPM「特に変わったことは考えていないです。普通に設計書を書いてレビューして」
技術SE「レビューはちゃんと内部と外部は分けたい。手直しは避けたいし」

ワタシ「そうすると今度はプロジェクトマネジメントの品質管理のやり方がWBSの成果物が期待通りの品質を持っているか確認したくなるよね」
サブPM「そうなりますね」
ワタシ「ただ、品質の観点やWBSを作る人の都合だけでスケジュールを引っ張ると大体が納期を超えちゃう」
サブPM「納期を超えちゃう…」
ワタシ「そこで生産性を向上するツールや技法が登場するんだ」
ワタシ「例えば、繰り返す作業を業務フローで想定しているならそれを機械化する、とかね」
サブPM「なるほど」
ワタシ「WBSを成果物で作ったらプロジェクト管理の観点と生産性の観点でも見るんだよ」

ワタシ「あと、成果物を作るWBSとそのWBSがスムーズに進むように付帯作業としてのWBSも入れておく。そうしないとプロジェクトにかかった本当の工数が見えないから。会議とかもね」
サブPM「わかりました。一旦作ってみます！」
技術SE「いままでWBSって変だなと思っていたんです。単純に分解しただけじゃダメなんですね」
ワタシ「そうそう、じゃあ時間になったので今日はここまで」