【新人SE講座】 第１回『WBSがないのは死亡フラグ』

主に新人システムエンジニア向けに、業務で必要になる知識やテクニックを解説していきます。
第１回のテーマはプロジェクト管理の基本である__「WBS」__です。
（評判がよければ第2回もやります。。。）

#まとめ

WBSはタスク管理の基本。プロジェクトの関係者と協力して円滑に作業を進めるためのもの。

タスク管理ツールを使う前に、仕事のゴールを細分化してタスクに落とし込んでいく必要がある。

WBSの原則
１．すべてのアウトプットを洗い出し、最上位に定義する。
２．下位タスクに細分化するときは、上位タスクの達成に必要なすべてのタスクを洗い出す。
３．タスクは完了条件を明確にする。
４．１つのタスクは担当者が１人になるまで細分化する。
５．タスクは進捗がわかる程度まで細分化する。
６．作業進捗はパーセントではなくタスクの完了数で管理する。
７．WBSは関係者でレビューして認識のズレをなくす。

WBSは状況に応じて適宜修正する。
（最初から完璧なWBSを作ろうとしたり、最初の計画に固執しないこと）

#登場人物

	先輩。中堅SIerでシステムエンジニア歴10年目。

	新人の伊藤さん。本社のキラキラオフィスを見て就職を決めたが、配属先は事業部の古臭いビルだった。 新人研修で初めてプログラムを書いた。

#WBSって何

	新人ちゃんが参加しているプロジェクトがどうもうまくいっていないようです。 先輩は上司から、新人ちゃんにアドバイスするように頼まれました。
	なんかうまくいってないって聞いたけど、どんな感じ？
	協力会社の田中さんと２人で作業してるんですが、なかなか思ったように作業が進まなくて…
	作業が進まない原因は何か思い当たることある？
	作業の全体像がつかめてないんですよね…あと、田中さんの担当だと思ってた作業が自分のだったりして、それで結果的に進捗が遅れてたりしました…
	タスク管理とか進捗管理に問題がありそうだね。 まず、二人の作業ってどうやって管理してるの？
	話し合って決めてます。特に管理とかはしてないです。
	そうなのか…（リーダーはいったい何をやってたんだ？） じゃあまずは、必要な作業がわかるようにWBSから作ろうか。
	WBS…って何ですか？
	Work Breakdown Structure の略だね。日本語で言うと作業細分化構成図かな。 簡単にいうと、タスクを洗い出して、一覧にしたものだよ。
	もしかして、いつも、えらいおじさん達が難しい顔して見てるエクセルのことですかね？ …なんか、昭和っぽいですね。もっとこう、オシャレなツールとかないんですか？
	進捗遅れてるくせに余裕だな。 WBSは確かに50年以上前からある考え方だけど、まだまだ現役だし、重要だよ。
	はぁ。そういえば本社の同期から聞きましたよ、本社ではtrelloとかいう今風のツールでタスク管理してるって。私もオシャレなツールが使いたいです。
	どんなツールを使うとしても、__タスクを定義するのは使う側の人間__だよ。 まずは、__仕事をどうやってタスク落とし込んでいくか__を学んでいこうね。
	いずれオシャレツールを使うために今は耐えます。 ちなみにリーダーから作業の進捗が遅いって注意されてるんですが、作業進めるよりWBS？作るのを優先しちゃって大丈夫ですかね？
	大丈夫だよ。__WBSなしで作業するほうがよっぽどヤバイ__からね。 WBSなしのプロジェクトとか__初めての首都高でカーナビなしで運転する__ようなものだよ。
	それはやばい
	まぁそんなわけだからWBS作ってみよう。リーダーには俺から言っておくよ。 サーバに過去のプロジェクトのWBSがあると思うから、それを参考に作ってみて。
	りょ

#WBSの原則

	（３０分後…）
	先輩、とりあえずつくってみました。
	どれどれ…うーん…これ、よくあるダメWBSだね。 参考にした元のWBSがよくなかったかな。
	がーん。
	まぁ、学びながら修正していこう。 WBSは作る上での原則があるんだ。 １．すべてのアウトプットを洗い出し、最上位に定義する。 ２．下位タスクに細分化するときは、上位タスクの達成に必要なすべてのタスクを洗い出す。 ３．タスクは完了条件を明確にする。 ４．１つのタスクは担当者が１人になるまで細分化する。 ５．タスクは進捗がわかる程度まで細分化する。 ６．作業進捗はパーセントではなくタスクの完了数で管理する。 ７．WBSは関係者でレビューして認識のズレをなくす。
	重要なものから確認していこうか。 まずは「①すべてのアウトプットを洗い出し、最上位に定義する」。 新人ちゃん、今回のプロジェクトで作成するアウトプットのリストある？
	リーダからもらったメールにリストがありました。
	意外と__プロジェクトの最終アウトプットが抜けてたりする__んだよね。 最近でも聞くよ、__納期直前に試験エビデンス作るの忘れてたのに気づいた__とか。
	さすがにそんな初歩的なミスしないですよ。
	まぁ、そういうミスを防ぐためにも、WBSの最上位は必ずアウトプットにするんだ。今回だとこんな感じかな。 ●詳細設計書 ●プロジェクト・ソースコード ●試験規格書 ●試験成績書
	作るものリストって感じですね。
	そうだね。そして次は、アウトプットを作るために必要なタスクに細分化するんだけど、そのとき注意しないといけないのは「②下位タスクに細分化するときは、上位タスクの達成に必要なすべてのタスクを洗い出す。」。 これは、下位のタスクをすべて実施すれば、上位のアウトプットが完成する状態にするってことね。
	当たり前のことに聞こえますね。
	その当たり前が意外と難しいんだよ。 じゃあまず「詳細設計書」について、下位タスクの洗い出しをやってみようか。
	えー詳細設計書作成に必要な作業…こんな感じですかね。 ●一覧表示処理の詳細設計 ●ユーザ登録処理の詳細設計 ●データ登録処理の詳細設計
	詳細設計書のレビューはしないの？
	やるって聞いてます。
	じゃあそれもWBSに書かないと。
	えっそんなことまで書くんですか？
	「細分化するときは上位の達成に必要なすべてのタスクを洗い出す。」だよ。 例えばアウトプットがソースプロジェクトの場合、開発環境構築とかビルドバッチ作成とかも、タスクとしてWBSに書いておいたほうがいいね。
	へーなるほど。 でもどこまで細かく細分化するか悩ましいですね。
	そうだね。タスクをどこまで細かくするかは、プロジェクトの期間とか作業内容応じて変わるね。 「タスクは進捗がわかる程度まで細分化する」に従うと、今回は毎週進捗報告があるなら、少なくとも１つのタスクが１週間以内で終わる量に細分化しようね。
	「〇〇機能の全画面実装　３週間」で１タスクとかはダメってことですね。
	そうだね。その場合は個別の「〇〇画面実装」程度まで細分化して進捗がわかるようにしようね。 タスクをどこまで細分化するかは結構個人の趣味がわかれるね。 たとえば__「1タスクが15分以下になるように細分化しろ」って過激派__もいるよ。
	ヒェ…どんなにスクロールしても終わらないWBSができあがっちゃう。
	まぁ__WBSばっかり作っててもアウトプットはできない__から、ほどほどにね。 「１つのタスクは担当者が1人になるまで細分化する。」 「タスクは進捗がわかる程度まで細分化する。」 ができてれば最低限いいと思うよ。
	了解です。 「ちょっと疲れたからTiktok見る」は詳細設計書を作るのに必要なタスクですよね、書いておきます。
	要らないだろ。
	か弱い私のメンタルを維持するには、ネズミが手作り罠にかかってる動画が必要なんですよ！
	なにそれこわ…

#タスクの完了条件を明確にする

	次に大事なのは「タスクの完了条件を明確にする。」だね。 WBSでタスクにしたときは、何をもってそのタスクを完了とするかが決まっている必要があるよ。 下位のタスクの完了条件を決めるには、上位のタスクの完了条件が必要だから、一番最初は__最上位のアウトプットの完成条件__を決める必要があるよ。
	完成条件は、リーダーがＯＫって言ったら完成です。
	__そーゆー曖昧な条件をやめよう__って話ね。先に完成イメージを合意してないと後で苦労するよ。 そしてWBSの全タスクが完了したら、アウトプットがすべて完成するのが正しいWBSだね。
	理想はわかるけど、新人のぺーぺーには荷が重すぎるような。
	まぁ最初から完璧なWBSを作ろうとしないで、作業をやりながらWBSを修正していってもいいんだよ。
	そうなんですか？ てっきり最初にしっかり全部計画しないといけないものかと。
	最初から全部完璧に計画しようとしても無理だからね。 むしろ、後半の作業は最初はざっくりで書いておいて、状況にあわせて詳細化するほうがうまくいくよ。作業すればするほどプロジェクトへの理解度が上がって、より正確なWBSが書けるようになるからね。 あとは、全部一人で書かないで、タスクの細分化は詳しい人に頼んだりしてもいいし。
	そうなんですね。__私の書いたWBSに作業漏れがあって、進捗が1日でも遅れたら周りから詰められるのか__とびくびくしてました。
	__心理的安全性に問題がある__なぁ… WBSは予定の基準を作ったり、周りの人と分担して作業するために作るものだよ。WBSの内容は適宜見直して修正しようね。 反面教師としては、「俺のWBSは正しいんだ！作業がうまくいっていないのはお前らの作業が遅いからだ！WBSのとおりに作業が進むよう努力しろ！」って言って、かたくなにWBSを修正しなかった人が過去にいるとかいないとか。
	うわぁ…
	__WBSは、周囲と協力して作業を進めるために作るもの__だってことを忘れないようにね。 あと進捗遅れに対しては、WBSはただその遅れを管理できるだけ。 __どれだけWBSを編集しても進捗遅れは解消しない__のだ…
	？当たり前ですよね？
	そう、本来は当たり前のことなんだよ…（遠い目）

#進捗管理について

	あとは「進捗はパーセントではなくタスクの完了数で判断する。」も大事だね。 パーセントにしちゃうとどうしても主観的な表現になっちゃうから、タスクは未着手／着手／完了ぐらいで管理するのがいいと思うよ。
	いっつも雰囲気のパーセントで報告しちゃってました。
	毎週進捗90%って報告するやつね。
	よく勘違いされるんだけど、よくあるWBSの右側のほうに書いてある日付と横棒はガントチャートで、WBSとは別物なんだ。
	そうなんですか？
	WBSは、純粋にタスクを細分化したものだよ。 作業進捗をどう管理するかは人によるけど、個人的にはガントチャートよりも、作業の予定と実績を日付で記載するほうが好みかな。 そのほうが関数とか条件付き書式も設定しやすいし。

#WBS完成？

	先輩のアドバイスのおかげでなんとかWBSが完成しました。
	うん、いい感じだね。
	これなら作業の全体像もわかるし、田中さんとの作業分担で迷うこともなくなりそうです！
	それはよかったね。 今後のタスク管理はこのままExcelでやってもいいし、TrelloやRedmineなんかのツールを使ってもいいと思うよ。その辺はリーダや田中さんと相談して決めてね。
	はーい。
	あとは最後に「⑦WBSは関係者でレビューする」。 タスクの認識にずれがないか、一応みんなにWBSをレビューしてもらおうね。
	了解です、レビュー依頼出しときます。 まぁ毎週ミーティングしてるし、そんな認識ずれてることないと思いますけど。
	（翌日...）
	先輩…課長にWBSをレビューしてもらったら…アウトプットの認識がずれてて…__実は操作マニュアルも作らないといけない、でも期限は変わらない__って…

参考文献

• 『なぜ、システム開発は必ずモメるのか？』 細川義洋／著 ISBN:9784534051158

---

WBSの書き方は、会社とか職場によって結構違うと思います。
上記はあくまで一例ということで。

「俺の思う最強のWBSはこうだぜ」の意見があればコメントまでお願いします。