はじめに

業務で初めてWBSの作成を行ったため、その時学んだことや教えていただいたことを記録したいと思います。
WBS作成初心者の方の参考になれば幸いです。

プロジェクトについて

今回、WMS（倉庫管理システム）の導入プロジェクトについてWBSを作成しました。
弊社ではWMSの標準パッケージを主力製品として持っており、あるお客さまに対してその導入を行うプロジェクトとなっています。

注意したポイント

各フェーズの役割を明確に把握する

WBSの大分類は、

要件定義 → 内部設計 → 外部設計 → 開発 → 単体テスト → 結合テスト → 統合テスト（他システム連携） → UAT → 移行テスト → ユーザー教育 → 導入

となっています。（ウォーターフォールの場合）
各フェーズにおける成果物や担当者、目的を意識することで、自然と細分化されたタスクが決まってくるはずです。
また、なるべく各フェーズで被りがないようにタスクを振り分けることも大切です。

カスタマイズが必要な機能を明確にする

標準パッケージの導入プロジェクトにおいては、標準機能で事足りる要望とカスタマイズが必要になってくる要望を分けて考えることが重要です。
標準機能で事足りるタスクは設計や開発の負担が少なく済みますが、カスタマイズが必要な機能に関しては細かく設計やお客様との検討を行っていく必要があるためタスクを細分化する必要があります。

開発フェーズのタスクは、エンジニアが開発しやすいような実装機能とする

エンジニアにとって、細分化された実装機能が提示されていると開発をスムーズに行うことができます。
内部設計までの段階でなるべく細分化された実装機能一覧を作成できるように、実際に開発が必要になりそうな機能をイメージしながら設計フェーズのタスクを考えていくことが大切だと思います。

要件定義書の内容が全て網羅されているか確認する

WBS作成時に要件定義書がある場合は、自分が作成したWBSと要件定義書の内容を比較して漏れがないかをチェックしましょう。
これはPMに提出するタイミングで最終チェックとして行うと良いと思います。

PMと認識のずれがないか確認する

ほとんどの情報は要件定義書に網羅されていると思いますが、場合によってはPMの頭の中で構想が練られている事項もあるかもしれません。
また、プロジェクト参加の経験が浅いと（筆者は初めてでした・・・）要件定義書だけ見ても理解できないことが多いはずです。
認識のずれが生じたまま、WBSを作成してしまうと危険です。ずれに気付いたタイミングが遅ければ遅いほど軌道修正に時間がかかってしまいます。
このような事態を避けるためにも、筆者は疑問に感じた点があればすぐにPMに聞くように心がけていました。また、WBSの大まかな流れ（分類の割り振りなど）などの作成方針が決まったら一度確認してもらうのもいいと思います。

最後に

以上、初めてのWBS作成で筆者が気をつけたポイントです。
会社やプロジェクトによってWBS作成の方針も異なると思うので、この記事はあくまで参考程度に、具体的なことは上司やPMに確認していただければと思います。
最後までご覧いただきありがとうございました。