昨日のブログ「ＷＢＳとスコープと要素技術とＲＦＰ」で書いたことの一部修正とか、訂正。
まず、「ＷＢＳに書きますが、ウィリアムのいたずらは、その作業を省略してしまっているので」って書いてしまったけど、じゃあ、ＷＢＳを書かないで、どーするの？っていう話。
これは、スケジュール表で代用してます。
「プロジェクト計画書に書かなくてはいけないこと、省いて手抜きできるとこ」で、のとはら先生のやつに、
４.プロジェクト全体作業フロー
（中略）
８.プロジェクトスケジュール
ってある。ＰＭＢＯＫにも
え・ＷＢＳ（コントロールレベルまで）
お・（ＷＢＳに対する）コスト見積もり、スケジュール、責任分担
ってある。
そこで、「スケジュール表の項目を書いた場合、ＷＢＳが想像できるものは、スケジュール表をいきなり書いて省略しています」という意味です。
とくに、スケジュール表をガントチャートで書くとき、一番左の見出し部分に、その作業内容を書きますが、その作業内容（見出し部分）を見れば、どういう行動をすればいいのか分かる場合（その項目を見ればＷＢＳが自動的にかけるから）、書かないという意味です。
たとえば、ＷＢＳとして、こんな表形式で書く人がいます。
ウィリアムのいたずらの場合は、この表形式の右側に、年月の線表を書いて、ガントチャートにして、スケジュール表として出して、ＷＢＳの図は、省略することが多いですね。
ＷＢＳの「図を書かない」という意味であって、（クラスが思いついたとしても、そこから）作業を考える→スケジュールに入っていくという頭のなかの流れは、踏んでいます。
あと、「なにをやったらいいのか、わかんない場合、ＷＢＳに分解して、安心しちゃうっていう危険もあるのよね。」って、文章的に変でしょ！と思うかもしれない。
なぜなら、コントロールレベルまでＷＢＳを落とす
っていうことは、行動できる範囲にまで、落とすっていうことだから
なにをやったらいいかわかんないわけ無いじゃん！
っていう話。お話は、もっともっす。
ここ、書き方が悪かったです。
書きたかったことは、
「その要件を満たすために、やるべきことの全てがわかっていない、
つまり、「なにをやるべきなのか」分かっていないときでも、
ＷＢＳに分解して、行動できるレベルに落としてしまうと、
なんとなく、その作業をやれば、できるような気分になってしまう
＝結果として、漏れが出てきたり、出来なかったりする危険もあるよね」
という意味です。
例を出します。
前の、「ヒアリングからＵＭＬのドキュメントを作成、Javaのクラス作成までを半自動化で行う手順」をみると、これで、システム設計は完璧！のように思えるよね。
で、これをＷＢＳに書けば、すぐ行動に移せる。バッチリです。
じゃあ、システムを作ってみましょう。
夕食支援システムを開発します。
社内従業員の夕食のために、出前を取るシステムです。
今後、残業が多そうなので。
業務手順を洗い出しましょう。ヒアリングです。
「夕食は、どのように決めていますか？」
「いやー、今、残業無くって、うちに帰って毎日食べているので、奥さんが決めています。」
。。。このヒアリング終了です。
今やってないことの業務手順は、答えられません（わかんないです）
でも、システム開発は、将来のために作ることも多いです（今やってない業務の開発）
極端な例だけど、こういうお間抜けな行動内容をＷＢＳで作っちゃうことがあるわけ。
例えば、「用語を調べる」って、必要ない用語を一生懸命調べて用語集作っちゃったり、
意味の無い業務分析をしてみたり。
で、肝心の部分の業務分析が抜けていても、ＷＢＳ上、見てもわかんないことがあるのよ。
でもでも、ＷＢＳをつくって、なんとなく、仕事していると安心してしまうっていうことがあるのよね。という意味です。
まず、「ＷＢＳに書きますが、ウィリアムのいたずらは、その作業を省略してしまっているので」って書いてしまったけど、じゃあ、ＷＢＳを書かないで、どーするの？っていう話。
これは、スケジュール表で代用してます。
「プロジェクト計画書に書かなくてはいけないこと、省いて手抜きできるとこ」で、のとはら先生のやつに、
４.プロジェクト全体作業フロー
（中略）
８.プロジェクトスケジュール
ってある。ＰＭＢＯＫにも
え・ＷＢＳ（コントロールレベルまで）
お・（ＷＢＳに対する）コスト見積もり、スケジュール、責任分担
ってある。
そこで、「スケジュール表の項目を書いた場合、ＷＢＳが想像できるものは、スケジュール表をいきなり書いて省略しています」という意味です。
とくに、スケジュール表をガントチャートで書くとき、一番左の見出し部分に、その作業内容を書きますが、その作業内容（見出し部分）を見れば、どういう行動をすればいいのか分かる場合（その項目を見ればＷＢＳが自動的にかけるから）、書かないという意味です。
たとえば、ＷＢＳとして、こんな表形式で書く人がいます。
ウィリアムのいたずらの場合は、この表形式の右側に、年月の線表を書いて、ガントチャートにして、スケジュール表として出して、ＷＢＳの図は、省略することが多いですね。
ＷＢＳの「図を書かない」という意味であって、（クラスが思いついたとしても、そこから）作業を考える→スケジュールに入っていくという頭のなかの流れは、踏んでいます。
あと、「なにをやったらいいのか、わかんない場合、ＷＢＳに分解して、安心しちゃうっていう危険もあるのよね。」って、文章的に変でしょ！と思うかもしれない。
なぜなら、コントロールレベルまでＷＢＳを落とす
っていうことは、行動できる範囲にまで、落とすっていうことだから
なにをやったらいいかわかんないわけ無いじゃん！
っていう話。お話は、もっともっす。
ここ、書き方が悪かったです。
書きたかったことは、
「その要件を満たすために、やるべきことの全てがわかっていない、
つまり、「なにをやるべきなのか」分かっていないときでも、
ＷＢＳに分解して、行動できるレベルに落としてしまうと、
なんとなく、その作業をやれば、できるような気分になってしまう
＝結果として、漏れが出てきたり、出来なかったりする危険もあるよね」
という意味です。
例を出します。
前の、「ヒアリングからＵＭＬのドキュメントを作成、Javaのクラス作成までを半自動化で行う手順」をみると、これで、システム設計は完璧！のように思えるよね。
で、これをＷＢＳに書けば、すぐ行動に移せる。バッチリです。
じゃあ、システムを作ってみましょう。
夕食支援システムを開発します。
社内従業員の夕食のために、出前を取るシステムです。
今後、残業が多そうなので。
業務手順を洗い出しましょう。ヒアリングです。
「夕食は、どのように決めていますか？」
「いやー、今、残業無くって、うちに帰って毎日食べているので、奥さんが決めています。」
。。。このヒアリング終了です。
今やってないことの業務手順は、答えられません（わかんないです）
でも、システム開発は、将来のために作ることも多いです（今やってない業務の開発）
極端な例だけど、こういうお間抜けな行動内容をＷＢＳで作っちゃうことがあるわけ。
例えば、「用語を調べる」って、必要ない用語を一生懸命調べて用語集作っちゃったり、
意味の無い業務分析をしてみたり。
で、肝心の部分の業務分析が抜けていても、ＷＢＳ上、見てもわかんないことがあるのよ。
でもでも、ＷＢＳをつくって、なんとなく、仕事していると安心してしまうっていうことがあるのよね。という意味です。
アクセス
トータル
ランキング
