要件定義には、どのようなやり方があるか。
「要件プロセス完全修得法」
スザンヌ・ロバートソン＋ ジェームズ・ロバートソン／著 苅部英司／訳
http://www.sangensha.co.jp/allbooks/index/111.htm
のＰ１００～Ｐ１１４に、そのやり方が、以下のように書かれている
１．徒弟制度
２．ユーザーとのインタビュー
３．ビジネス事象ワークショップ（シナリオを含む）
４．ブレインストーミング
５．マインドマップ
６．ビデオ
７．電子的要件収集法
８．文書考古学
９．スノーカード
問題は、この中で、何からはじめるのかが明記されていないことだ。
これでは、勉強のやり方を列挙して、教育ママ（ふる！）に「勉強しなさい」としかられているようなもんだ。
出さなきゃいけない成果はわかってる（勉強の場合、宿題を終わらすとか、テストでいい点ｗ撮るとか、システム開発なら、要件定義書とかユースケースとか）。でも、どの順番で、やったらいいのか分からなければ、いくらしかられても、手をつけられない。
で、わからない結果、どうするか。。。
一番非効率な方法を、なぜかとってしまうのだ。それは、いきなり
２．ユーザーとのインタビュー（ヒアリング）
からはいる。
でも、何をきいたらいいかわかんない。その結果、ユーザーへのコーチング、愚痴を聞くカウンセリングや、あたりまえの用語を説明してもらう勉強会になってしまう。
これを続けると、ユーザーは、「本当に出来るのか」と不安になる（ひどいと、聞いてるＳＥ自身が、「先が見えない、できるのかなあ？？」と思ってしまう）
結果として、関係が悪くなり、見切り発車状態で、ヒアリングを終えて、開発に入らなければならなくなる。
では、どこから手をつけるのか。それは、ずばり、
８．文書考古学
からだ。これは、昔、帳票分析と呼ばれていたものだ。
やり方は、上記の「要件プロセス完全修得法」のＰ１１１～１１２に書かれている。
ドキュメントから名詞を取り出し、その名詞からエンティティを抽出するってこと。
この方法は、まさに、佐藤正美氏のＴ字型ＥＲ図の作り方と同じだ。なんで、詳しくは、佐藤正美氏の（早稲田のエクステンションセンターなんかの）講義とか、著作を参考にして欲しい。
ウィリアムのいたずらからより、直接本人から聞いたほうがいいだろう。名講義だ！
ただ、そこまでやらなくても、このブログの「ＵＭＬでやりにくいもの。確定申告を例に」プラスアルファでＯＫだ。
ただし、実際にやるには、まず、いろんな帳票やドキュメントをもらってきて、それをてきとーに整理して。。。といろいろな作業がある。これは、別の機会に取り上げよう。
そして、帳票からわからない言葉を取り出し、帳票が出来る手順を（確定申告の例のように）追っていく。ヒアリングのときは、この分からない用語の確認や、帳票ができる手順にそって、物とかねの流れを追い、さらにそこに対する担当者を聞く。
（ただ、ここまでできれば、あらかじめ質問紙の形でヒアリング内容を事前にまとめておき、ユーザーに見てもらうことが出来る。そのほうが、ヒアリングしやすい）
で、あとは、このヒアリングをもとに、物、金、帳票等のに関する動詞を取り出し、プロセスとし、そのプロセスと、情報や物、金、人（＝データの源泉か、データになる）を図示すると、ＤＦＤが出来てくる。ＤＦＤのプロセスからメソッドを取り出すとユースケースがかけるし、ＤＦＤのデータ（エンティティ化していることが多い）とプロセスを適当にまとめると、クラス図がかけ、ＵＭＬのドキュメントに変形できる。
問題はこの流れ、つまり、ドキュメントをみて、ヒアリングの下準備をするという仕事のやり方をおさえているかどうかだ。
むかしの８０年代のＳＥは、帳票分析というのを、よくやらされた。私たちの世代も、そのやり方を受け継いだ。
しかし９０年代、オフコンの文化が否定されて、このやり方自体が否定されてしまった。
（ちなみにＣＯＢＯＬ文化も全否定された。この結果の弊害も大きいが、今回は、それを書ききれるほどひまでないので省略）
その結果、新しいＤＯＡからオブジェクト指向の考え方が正しいということになり、このやり方で世の中がやるようになってきた。しかし、オブジェクト指向の問題点は、ユーザーが、ヒアリングで必要な情報をしゃべってくれるということを、暗黙の了解にしていることだ。
でも、ユーザーは、必要な情報はなにか、分からない。
うそーと思う人へ。あなた、少なくとも一生のうちに１度以上、夕飯食べましたよね。
さて、質問です。夕飯って、どうやって、決定されるんでしょう？
必要な情報を、「すべて挙げなさい」
無理でしょ。家に帰る場合、外食の場合、夕飯抜きの場合。。。
全てのケースどころか、なにから話していいか、体系すら、語れないでしょ。
ユーザーの状況って、そんなもんなんですよ。
だから、下準備が必要なわけで、その下準備の方法がわかんないと、仕事が進められないわけ
ところが、世間はＵＭＬの提唱者やエバンジェリスト（広める人のことね）を教祖のようにあがめ、一流企業の研究者や管理職は、その教祖の主張を全面的に受け入れて、これができれば、システム開発ができるように思い込んじゃってるのよ。
だから、「要件仕様はＵＭＬのユースケースで入れましょう！」ってなると、管理職は部下に、ＵＭＬの書き方とか、ＵＭＬの試験とかにお金をだすだけで、どうやったら、もらった資料から、ヒアリングにもっていけて、さらにそこから、ユースケースがかけるのかの、一連の作業の流れを教えない（ヒアリングからメソッドを出す手法はＯＭＴでは言われてたんだけど、ＵＭＬになるときに、その手法は、なぜか伝えられなくなった）。
結局そのため、部下は一生懸命がんばっても、どうやったらいいのかわかんなくって、精神的に（うつ病とかで）まいってしまう。
その一方、開発論の提唱者は、教祖的に「この方法でやるといい！」って訴えて、みんな信じちゃうのよ（この下準備の部分を説明してもらえば、理性でわかるんだけど、その部分を説明しない限り、感性で信じ込むしかない＝教祖化する）。
つまり、下準備からの一連の流れを教えなくなった、技術の断絶が、業界の病理と開発の教祖を生み出したといえるね。
で肝心の、下準備からの一連の流れを、このブログで。。
取り上げられるようだったら取り上げようと思う。。。
「要件プロセス完全修得法」
スザンヌ・ロバートソン＋ ジェームズ・ロバートソン／著 苅部英司／訳
http://www.sangensha.co.jp/allbooks/index/111.htm
のＰ１００～Ｐ１１４に、そのやり方が、以下のように書かれている
１．徒弟制度
２．ユーザーとのインタビュー
３．ビジネス事象ワークショップ（シナリオを含む）
４．ブレインストーミング
５．マインドマップ
６．ビデオ
７．電子的要件収集法
８．文書考古学
９．スノーカード
問題は、この中で、何からはじめるのかが明記されていないことだ。
これでは、勉強のやり方を列挙して、教育ママ（ふる！）に「勉強しなさい」としかられているようなもんだ。
出さなきゃいけない成果はわかってる（勉強の場合、宿題を終わらすとか、テストでいい点ｗ撮るとか、システム開発なら、要件定義書とかユースケースとか）。でも、どの順番で、やったらいいのか分からなければ、いくらしかられても、手をつけられない。
で、わからない結果、どうするか。。。
一番非効率な方法を、なぜかとってしまうのだ。それは、いきなり
２．ユーザーとのインタビュー（ヒアリング）
からはいる。
でも、何をきいたらいいかわかんない。その結果、ユーザーへのコーチング、愚痴を聞くカウンセリングや、あたりまえの用語を説明してもらう勉強会になってしまう。
これを続けると、ユーザーは、「本当に出来るのか」と不安になる（ひどいと、聞いてるＳＥ自身が、「先が見えない、できるのかなあ？？」と思ってしまう）
結果として、関係が悪くなり、見切り発車状態で、ヒアリングを終えて、開発に入らなければならなくなる。
では、どこから手をつけるのか。それは、ずばり、
８．文書考古学
からだ。これは、昔、帳票分析と呼ばれていたものだ。
やり方は、上記の「要件プロセス完全修得法」のＰ１１１～１１２に書かれている。
ドキュメントから名詞を取り出し、その名詞からエンティティを抽出するってこと。
この方法は、まさに、佐藤正美氏のＴ字型ＥＲ図の作り方と同じだ。なんで、詳しくは、佐藤正美氏の（早稲田のエクステンションセンターなんかの）講義とか、著作を参考にして欲しい。
ウィリアムのいたずらからより、直接本人から聞いたほうがいいだろう。名講義だ！
ただ、そこまでやらなくても、このブログの「ＵＭＬでやりにくいもの。確定申告を例に」プラスアルファでＯＫだ。
ただし、実際にやるには、まず、いろんな帳票やドキュメントをもらってきて、それをてきとーに整理して。。。といろいろな作業がある。これは、別の機会に取り上げよう。
そして、帳票からわからない言葉を取り出し、帳票が出来る手順を（確定申告の例のように）追っていく。ヒアリングのときは、この分からない用語の確認や、帳票ができる手順にそって、物とかねの流れを追い、さらにそこに対する担当者を聞く。
（ただ、ここまでできれば、あらかじめ質問紙の形でヒアリング内容を事前にまとめておき、ユーザーに見てもらうことが出来る。そのほうが、ヒアリングしやすい）
で、あとは、このヒアリングをもとに、物、金、帳票等のに関する動詞を取り出し、プロセスとし、そのプロセスと、情報や物、金、人（＝データの源泉か、データになる）を図示すると、ＤＦＤが出来てくる。ＤＦＤのプロセスからメソッドを取り出すとユースケースがかけるし、ＤＦＤのデータ（エンティティ化していることが多い）とプロセスを適当にまとめると、クラス図がかけ、ＵＭＬのドキュメントに変形できる。
問題はこの流れ、つまり、ドキュメントをみて、ヒアリングの下準備をするという仕事のやり方をおさえているかどうかだ。
むかしの８０年代のＳＥは、帳票分析というのを、よくやらされた。私たちの世代も、そのやり方を受け継いだ。
しかし９０年代、オフコンの文化が否定されて、このやり方自体が否定されてしまった。
（ちなみにＣＯＢＯＬ文化も全否定された。この結果の弊害も大きいが、今回は、それを書ききれるほどひまでないので省略）
その結果、新しいＤＯＡからオブジェクト指向の考え方が正しいということになり、このやり方で世の中がやるようになってきた。しかし、オブジェクト指向の問題点は、ユーザーが、ヒアリングで必要な情報をしゃべってくれるということを、暗黙の了解にしていることだ。
でも、ユーザーは、必要な情報はなにか、分からない。
うそーと思う人へ。あなた、少なくとも一生のうちに１度以上、夕飯食べましたよね。
さて、質問です。夕飯って、どうやって、決定されるんでしょう？
必要な情報を、「すべて挙げなさい」
無理でしょ。家に帰る場合、外食の場合、夕飯抜きの場合。。。
全てのケースどころか、なにから話していいか、体系すら、語れないでしょ。
ユーザーの状況って、そんなもんなんですよ。
だから、下準備が必要なわけで、その下準備の方法がわかんないと、仕事が進められないわけ
ところが、世間はＵＭＬの提唱者やエバンジェリスト（広める人のことね）を教祖のようにあがめ、一流企業の研究者や管理職は、その教祖の主張を全面的に受け入れて、これができれば、システム開発ができるように思い込んじゃってるのよ。
だから、「要件仕様はＵＭＬのユースケースで入れましょう！」ってなると、管理職は部下に、ＵＭＬの書き方とか、ＵＭＬの試験とかにお金をだすだけで、どうやったら、もらった資料から、ヒアリングにもっていけて、さらにそこから、ユースケースがかけるのかの、一連の作業の流れを教えない（ヒアリングからメソッドを出す手法はＯＭＴでは言われてたんだけど、ＵＭＬになるときに、その手法は、なぜか伝えられなくなった）。
結局そのため、部下は一生懸命がんばっても、どうやったらいいのかわかんなくって、精神的に（うつ病とかで）まいってしまう。
その一方、開発論の提唱者は、教祖的に「この方法でやるといい！」って訴えて、みんな信じちゃうのよ（この下準備の部分を説明してもらえば、理性でわかるんだけど、その部分を説明しない限り、感性で信じ込むしかない＝教祖化する）。
つまり、下準備からの一連の流れを教えなくなった、技術の断絶が、業界の病理と開発の教祖を生み出したといえるね。
で肝心の、下準備からの一連の流れを、このブログで。。
取り上げられるようだったら取り上げようと思う。。。
アクセス
トータル
ランキング
