といっても、ワールドビジネスサテライトとは何の関係もありません。
トレンドたまごの話です。違!、Work Breakdown StructureのWBSの話。
見てて、あまりにも気になったので・・・
■WBSの詳細化の2つの方法
WBSは、ツリー上(あるいは表形式)で、仕事をブレークダウンしていくわけだけど、
(字のまんまや^^;)その分割の仕方には、大きく2とおりあります。
・成果物によるわけかた
・作業にやるわけ方
成果物によるわけかたは、
「要求仕様書」、
はじめに
全体説明
機能要件
非機能要件
制約等
資料その他
「外部設計書」、
「詳細仕様書」
「プログラム」
「テスト仕様書」
のように、成果物を挙げていき、さらに、「要求仕様書」の中を、その章立てに分けていき・・・・という手順で詳細化していく。
作業の場合は、
「ユースケースを作成する」
アクターを出す
ヒアリングする人を決める
ヒアリングする
ヒアリングの日程を決定する
ヒアリングを行う
ユースケースシナリオを作成する
ユースケース図を作成する
のように、作業を羅列して、詳細化していく。
気になったのは、作業に分けた場合の話。
■WBSの詳細化のルール
ここで、WBSには、詳細化する場合にルールがある。
WBSには、守るべき3つのルールがある
http://www.atmarkit.co.jp/im/cpm/serial/wbs/02/01.html
に書かれている、100%ルールというもの。
これは、網羅性とかいうやつで、
子の要素を全部足したら、親の要素にならないといけない
(漏れがあってはいけない)
というもの。
■作業の網羅性と成果物の網羅性
作業の網羅性を確認する場合
その作業を行う前に、入力がすべてそろっているか?
その作業を行った後に、成果物が作成されるか?
というのを確認(同レベルでの、事前・事後条件チェック)した後で、
手順どおりに行うと、入力値を元に、親要素で期待される成果物が
作成できるか?
というのを確認(詳細化チェック)をするんだけど、
気になったモノは、詳細化された要素を足しても、親の要素にならないし、
親の要素に対して、子の要素は必要か??と思ってしまったから。
実は、作業の網羅性を行うのは、かなり難しい。
成果物の網羅性は実は簡単で、そのドキュメント→章立て→項立て
と分解していけばいいので。
■WBSの書き方
といっても、成果物がいっぱいのときがある。このとき、成果物を羅列すると、
わけわからなくなる。
そこで、組織とか、構造とか、場合によっては、工程・フェーズなどによって、
荒く分類しておくことがある。
たとえば、
ETLシステム
会計システム改修
販売システム改修
生産システム改修
データ連携システム
と分かれていて、それぞれにドキュメントがある場合(とくに章立てとか内部が違う場合)は
ETLシステム
会計システム改修
「要求仕様書」、
「外部設計書」、
「詳細仕様書」
「プログラム」
「テスト仕様書」
販売システム改修
「要求仕様書」、
「外部設計書」、
「詳細仕様書」
「プログラム」
「テスト仕様書」
生産システム改修
「要求仕様書」、
「外部設計書」、
「詳細仕様書」
「プログラム」
「テスト仕様書」
データ連携システム
「要求仕様書」、
「外部設計書」、
「詳細仕様書」
「プログラム」
「テスト仕様書」
と分けてしまったほうがいい。
■つまり・・・
網羅性を高めるには
・組織・構造・工程・フェーズ等
・成果物
・作業
によって分けたほうがいいということになる。
これと、ゴール指向なんかとの関係については、別に書く。
トレンドたまごの話です。違!、Work Breakdown StructureのWBSの話。
見てて、あまりにも気になったので・・・
■WBSの詳細化の2つの方法
WBSは、ツリー上(あるいは表形式)で、仕事をブレークダウンしていくわけだけど、
(字のまんまや^^;)その分割の仕方には、大きく2とおりあります。
・成果物によるわけかた
・作業にやるわけ方
成果物によるわけかたは、
「要求仕様書」、
はじめに
全体説明
機能要件
非機能要件
制約等
資料その他
「外部設計書」、
「詳細仕様書」
「プログラム」
「テスト仕様書」
のように、成果物を挙げていき、さらに、「要求仕様書」の中を、その章立てに分けていき・・・・という手順で詳細化していく。
作業の場合は、
「ユースケースを作成する」
アクターを出す
ヒアリングする人を決める
ヒアリングする
ヒアリングの日程を決定する
ヒアリングを行う
ユースケースシナリオを作成する
ユースケース図を作成する
のように、作業を羅列して、詳細化していく。
気になったのは、作業に分けた場合の話。
■WBSの詳細化のルール
ここで、WBSには、詳細化する場合にルールがある。
WBSには、守るべき3つのルールがある
http://www.atmarkit.co.jp/im/cpm/serial/wbs/02/01.html
に書かれている、100%ルールというもの。
これは、網羅性とかいうやつで、
子の要素を全部足したら、親の要素にならないといけない
(漏れがあってはいけない)
というもの。
■作業の網羅性と成果物の網羅性
作業の網羅性を確認する場合
その作業を行う前に、入力がすべてそろっているか?
その作業を行った後に、成果物が作成されるか?
というのを確認(同レベルでの、事前・事後条件チェック)した後で、
手順どおりに行うと、入力値を元に、親要素で期待される成果物が
作成できるか?
というのを確認(詳細化チェック)をするんだけど、
気になったモノは、詳細化された要素を足しても、親の要素にならないし、
親の要素に対して、子の要素は必要か??と思ってしまったから。
実は、作業の網羅性を行うのは、かなり難しい。
成果物の網羅性は実は簡単で、そのドキュメント→章立て→項立て
と分解していけばいいので。
■WBSの書き方
といっても、成果物がいっぱいのときがある。このとき、成果物を羅列すると、
わけわからなくなる。
そこで、組織とか、構造とか、場合によっては、工程・フェーズなどによって、
荒く分類しておくことがある。
たとえば、
ETLシステム
会計システム改修
販売システム改修
生産システム改修
データ連携システム
と分かれていて、それぞれにドキュメントがある場合(とくに章立てとか内部が違う場合)は
ETLシステム
会計システム改修
「要求仕様書」、
「外部設計書」、
「詳細仕様書」
「プログラム」
「テスト仕様書」
販売システム改修
「要求仕様書」、
「外部設計書」、
「詳細仕様書」
「プログラム」
「テスト仕様書」
生産システム改修
「要求仕様書」、
「外部設計書」、
「詳細仕様書」
「プログラム」
「テスト仕様書」
データ連携システム
「要求仕様書」、
「外部設計書」、
「詳細仕様書」
「プログラム」
「テスト仕様書」
と分けてしまったほうがいい。
■つまり・・・
網羅性を高めるには
・組織・構造・工程・フェーズ等
・成果物
・作業
によって分けたほうがいいということになる。
これと、ゴール指向なんかとの関係については、別に書く。