ＷＢＳとスコープと要素技術とＲＦＰ

　「業務標準のマネジメント技法の幻想と、ソフト開発見積もりの現実」で、プロジェクトの始まりを、こんなふうに書きました。
（１）スコープ計画
（２）スコープ定義
（３）アクティビティ定義
　　　：（以下省略）

で、普通の本をみると、この（２）のところで、ＷＢＳと要素分析とか、作業分解という話がかならず出てくる。たとえば、こことか、こことか。。。

　でも、ウィリアムのいたずらは、見積もりのとき、はじめに要素に分解したあと、ＷＢＳを書いていない。なぜか。。。

---

　まず、WBSは、書いたほうがいい。しかし、小さいシステムの場合、クラスが決まれば、やるべきことが標準として決まっていて、さらに、ＲＦＰと納品物から、クラスが明確にわかってしまう場合、わざわざＷＢＳを書かなくてもいいかな、というか、実際には、書いてないと思う。

　つまり、（１）のスコープ計画で、納品物とかが決まる。
　この、納品物を決めるということは、絶対しないとまずいでしょ。
　これは省略不可。

　で、その納品物を作るために、どうするかということを考えるのが、（２）のスコープ定義ということになると思う。そして、その（２）の作業の検討結果をＷＢＳで表現するということになると思う。

　でも、ＲＦＰで、ほしいもの（成果物＝出力）が明確にわかっていて、入力画面が決まっちゃう場合、ＳＥさんの頭の中に、オブジェクトが切れてしまう（＝クラス図（とＥＲ図）ができてしまう）場合があるのよ（これが「読みきった」という状態。ウィリアムのいたずらの場合、読みきった仕事を受けるのが、ふつう。フリーの場合、そうでないと、仕事が出来ない可能性があるので危険）。

　で、オブジェクトがきれて、クラスわけまでいっちゃうと、そのクラスを、分析する→つくる→テストするっていうのが、作業になる。つまり、クラス図（とＥＲ図）が自動的に頭の中に広がっちゃうと、そのクラス図（とＥＲ図）を元に全作業工程が、わかってしまうので、その場合、ＷＢＳをわざわざ作るか？それとも、もう、クラス（プログラムに発展）とエンティティ（＝これがＤＢに発展）ごとに管理したほうが早いじゃん！っていうことになっちゃうのよ。それが、よいか悪いかは別にしてね。

　で、ウィリアムのいたずらなど、ＳＥさんの場合、そういう状態のとき、ＷＢＳをわざわざ書くかあ？っていうことになる。でも、プロジェクトマネージャーさんは、きっと書いてほしいんだろうね。つーか、書くべきだ。見落としとかもあるかもしんないし。

　一方、なにをやったらいいのか、わかんない場合、ＷＢＳに分解して、安心しちゃうっていう危険もあるのよね。たとえば、ここに書いてある最後の図って、ＷＢＳに割ってあっても、何も言っていないのと同じでしょ。なにやったらいいか、よくわかんないもん。

---

　っていうわけで、本来は、（１）のスコープ計画で成果物を定義した後、その成果物をつくるための要素に分解し、作業範囲と内容をきめ、その結果をＷＢＳに書きますが、ウィリアムのいたずらは、その作業を省略してしまっているので、今回も省略しましたというだけの話です。本当は、やったほうがいいんだろうね（つーか、やるべきだ）。

　ただ逆にＷＢＳにかけたからといって、必ずしも作業に入れるほど分解されているとは限らない（さっきのよくわかんないやつのケース）し、作業がスムーズに進むとも限らない。その点は注意ですな。

ＲＦＰと提案内容が違う場合の対処法－ウィリアムのいたずらの場合

前のブログで、今後、以下の３つの話題を書くといいました。

　　１つは、プロジェクト計画書に書くこと、
　　２つは、ＷＢＳとスコープと要素技術とＲＦＰ、
　　３つは、ＲＦＰと提案内容が違う場合の対処法

　１つめの「プロジェクト計画書に書くこと」は、このブログと、このブログでとりあげました。

　３つめの「ＲＦＰと提案内容が違う場合の対処法」について、このブログの後半で書いているんだけど、はっきりとしてないので、ここでまとめます

---

　ＲＦＰは、「提案依頼書」だから、これに基づき、提案するのは前提なのですが、以下の場合、ＲＦＰとは提案内容を、変えて書きたい場合があります。

１．会社のきまりで、こういうときは、こういう提案と決まっているので、ＲＦＰの提案依頼を満たせない
　→コンサルティングファームなどで、売り物が決まっている場合。
　　ただし、そういう場合、提案のしかたもたいてい決まっているので、まあ、そのやり方に従ってください。ここでの話の対象ではありません。

２．ＲＦＰを満たすことが、会社のためにならない
　→もっと、安い提案がある場合とか

３．そもそも、ＲＦＰの内容は実現できないので、これを満たす提案がありえない。
　→ユーザーが身の程知らずの場合のＲＦＰとか、キーワードを並べただけのときにある。
　　サーバーってなに？っていう状態のユーザーが、自分で、ＷｅｂとＤＢを管理してＥＣサイトを作りたいとか。

こんなとき（２．３の場合）、どうするか。

---

　はじめから自分の案を書くことは、まずいです。お客さんがついていけません。
　そこで、
（１）まずはじめにお客さんの案でやると、こうなる（こういう問題が出る）
（２）「そこで」、「ところが」、などの接続詞をいれ、話を転換させる
（３）あとは、自分の提案を書く

というスタイルになると思います。
　こういう感じであれば、自分の案を提案することも可能と思います。

---

　で、この場合、（１）が実現可能である場合、（３）を自分が提案したいのに、（１）になってしまうことがあります。（３）になることも、もちろんあります。
　それは、出たとこ勝負です。ただ、（３）のほうが後に言うし、「ところが」とかいって、話をひっくり返すわけなので、（３）のほうが、有力とは思いますが。。。

　まあ、どっちにころぶかは、わかんないっすね。

---

　なお、「コピーされるほど儲かるシステム」第１４話で、２つの案をあげ、あとから出てきた案に勝手に決まるところがありましたが、そこは、上記のような提案をして、後の方に決まったと考えてくださいませ。

---

ということで、「ＲＦＰと提案内容が違う場合の対処法」も終わったこととします。
のこるは、「ＷＢＳとスコープと要素技術とＲＦＰ」ですね。

要件定義は何からはじめるか－世代の断絶が、業界の病理と開発の教祖を生み出した

　要件定義には、どのようなやり方があるか。
　「要件プロセス完全修得法」
スザンヌ・ロバートソン＋ ジェームズ・ロバートソン／著　苅部英司／訳
http://www.sangensha.co.jp/allbooks/index/111.htm
のＰ１００～Ｐ１１４に、そのやり方が、以下のように書かれている
１．徒弟制度
２．ユーザーとのインタビュー
３．ビジネス事象ワークショップ（シナリオを含む）
４．ブレインストーミング
５．マインドマップ
６．ビデオ
７．電子的要件収集法
８．文書考古学
９．スノーカード

　問題は、この中で、何からはじめるのかが明記されていないことだ。
　これでは、勉強のやり方を列挙して、教育ママ（ふる！）に「勉強しなさい」としかられているようなもんだ。
　出さなきゃいけない成果はわかってる（勉強の場合、宿題を終わらすとか、テストでいい点ｗ撮るとか、システム開発なら、要件定義書とかユースケースとか）。でも、どの順番で、やったらいいのか分からなければ、いくらしかられても、手をつけられない。

　で、わからない結果、どうするか。。。
　一番非効率な方法を、なぜかとってしまうのだ。それは、いきなり
　２．ユーザーとのインタビュー（ヒアリング）
　からはいる。
　でも、何をきいたらいいかわかんない。その結果、ユーザーへのコーチング、愚痴を聞くカウンセリングや、あたりまえの用語を説明してもらう勉強会になってしまう。
　これを続けると、ユーザーは、「本当に出来るのか」と不安になる（ひどいと、聞いてるＳＥ自身が、「先が見えない、できるのかなあ？？」と思ってしまう）
　結果として、関係が悪くなり、見切り発車状態で、ヒアリングを終えて、開発に入らなければならなくなる。

---

　では、どこから手をつけるのか。それは、ずばり、
８．文書考古学
からだ。これは、昔、帳票分析と呼ばれていたものだ。
　やり方は、上記の「要件プロセス完全修得法」のＰ１１１～１１２に書かれている。
　ドキュメントから名詞を取り出し、その名詞からエンティティを抽出するってこと。
　この方法は、まさに、佐藤正美氏のＴ字型ＥＲ図の作り方と同じだ。なんで、詳しくは、佐藤正美氏の（早稲田のエクステンションセンターなんかの）講義とか、著作を参考にして欲しい。
　ウィリアムのいたずらからより、直接本人から聞いたほうがいいだろう。名講義だ！

　ただ、そこまでやらなくても、このブログの「ＵＭＬでやりにくいもの。確定申告を例に」プラスアルファでＯＫだ。
　ただし、実際にやるには、まず、いろんな帳票やドキュメントをもらってきて、それをてきとーに整理して。。。といろいろな作業がある。これは、別の機会に取り上げよう。

　そして、帳票からわからない言葉を取り出し、帳票が出来る手順を（確定申告の例のように）追っていく。ヒアリングのときは、この分からない用語の確認や、帳票ができる手順にそって、物とかねの流れを追い、さらにそこに対する担当者を聞く。
　（ただ、ここまでできれば、あらかじめ質問紙の形でヒアリング内容を事前にまとめておき、ユーザーに見てもらうことが出来る。そのほうが、ヒアリングしやすい）

　で、あとは、このヒアリングをもとに、物、金、帳票等のに関する動詞を取り出し、プロセスとし、そのプロセスと、情報や物、金、人（＝データの源泉か、データになる）を図示すると、ＤＦＤが出来てくる。ＤＦＤのプロセスからメソッドを取り出すとユースケースがかけるし、ＤＦＤのデータ（エンティティ化していることが多い）とプロセスを適当にまとめると、クラス図がかけ、ＵＭＬのドキュメントに変形できる。

---

　問題はこの流れ、つまり、ドキュメントをみて、ヒアリングの下準備をするという仕事のやり方をおさえているかどうかだ。
　むかしの８０年代のＳＥは、帳票分析というのを、よくやらされた。私たちの世代も、そのやり方を受け継いだ。
　しかし９０年代、オフコンの文化が否定されて、このやり方自体が否定されてしまった。
　（ちなみにＣＯＢＯＬ文化も全否定された。この結果の弊害も大きいが、今回は、それを書ききれるほどひまでないので省略）

　その結果、新しいＤＯＡからオブジェクト指向の考え方が正しいということになり、このやり方で世の中がやるようになってきた。しかし、オブジェクト指向の問題点は、ユーザーが、ヒアリングで必要な情報をしゃべってくれるということを、暗黙の了解にしていることだ。
　でも、ユーザーは、必要な情報はなにか、分からない。

　うそーと思う人へ。あなた、少なくとも一生のうちに１度以上、夕飯食べましたよね。
　さて、質問です。夕飯って、どうやって、決定されるんでしょう？
　必要な情報を、「すべて挙げなさい」
　無理でしょ。家に帰る場合、外食の場合、夕飯抜きの場合。。。
　全てのケースどころか、なにから話していいか、体系すら、語れないでしょ。
　ユーザーの状況って、そんなもんなんですよ。

　だから、下準備が必要なわけで、その下準備の方法がわかんないと、仕事が進められないわけ

---

　ところが、世間はＵＭＬの提唱者やエバンジェリスト（広める人のことね）を教祖のようにあがめ、一流企業の研究者や管理職は、その教祖の主張を全面的に受け入れて、これができれば、システム開発ができるように思い込んじゃってるのよ。

　だから、「要件仕様はＵＭＬのユースケースで入れましょう！」ってなると、管理職は部下に、ＵＭＬの書き方とか、ＵＭＬの試験とかにお金をだすだけで、どうやったら、もらった資料から、ヒアリングにもっていけて、さらにそこから、ユースケースがかけるのかの、一連の作業の流れを教えない（ヒアリングからメソッドを出す手法はＯＭＴでは言われてたんだけど、ＵＭＬになるときに、その手法は、なぜか伝えられなくなった）。

　結局そのため、部下は一生懸命がんばっても、どうやったらいいのかわかんなくって、精神的に（うつ病とかで）まいってしまう。
　その一方、開発論の提唱者は、教祖的に「この方法でやるといい！」って訴えて、みんな信じちゃうのよ（この下準備の部分を説明してもらえば、理性でわかるんだけど、その部分を説明しない限り、感性で信じ込むしかない＝教祖化する）。
　つまり、下準備からの一連の流れを教えなくなった、技術の断絶が、業界の病理と開発の教祖を生み出したといえるね。

　で肝心の、下準備からの一連の流れを、このブログで。。

　取り上げられるようだったら取り上げようと思う。。。