利用者の出力から分析して、DOAでも、オブジェクト指向でも、どっちにでも展開して、プログラムまで落とし込める業務をまとめたシートと、入出力についてまとめたシートを作る方法について書く、シリーズ(になってしまった)利用者の出力から業務を分析していく手順の5回目です。
今回は、いままでやってきたことと、ヒアリングとの関係についてです。
とくに、ヒアリングについては、要求をヒアリングしてから、DOA,オブジェクト指向の各種の図に展開するまとめかたというところで、書いています。それとの関係です。
■ヒアリングの場合
上記に挙げたところでは、こんな風にまとめていました。
(A)要求をヒアリングして、その要求に関連する業務を挙げる (B)「業務をまとめたシート」を作成し、業務の上下(親子)関係を決める (C)各業務をヒアリングし、「業務をまとめたシート」を埋めたり、追加する (D)同時に、現在の帳票、画面から、「入出力についてまとめたシート」をうめる (E)「業務をまとめたシート」の入出力から「入出力についてまとめたシート」を補完する (F)確認する |
ただし、順番は、あとで分かりやすくするため、ABCDにしてあります。
で、いままでの利用者のところでは、こうやって書いていました。
(1)利用者を体系づけて分けます (2)今回対象の利用者について、システム利用(入出力)場面を考え、業務シート作成 (3)利用者が利用する一場面をとって、入出力を、まず出力から確認します (3-あ)まず、外部に対して出力になっているものを取り上げます。 (3-い)その外部出力の具体的内容を考え、入出力のシートに書きます。 (3-う)その外部出力を出すために必要な情報が、入力されているかどうか、確認 (3-えお)(3-う)までで、入出力のシートはできているので、それに対応する 業務シートがなかったら追加、完成させます。 (4)利用者からの入力を受け取ってから、利用者への出力まで、 システム内の業務を追加します (4-あ)まず、システムトップを書き加える (4-い)中間のアクティビティとデータ加工を追加する (4-う)出力から考えて、足りない部分のアクティビティがないか、確認する (5)利用者への出力ごとに、シナリオをつくります (6)利用者の範囲を広げていきます。 |
なお、(4)に関しては、それを説明したところから、付け加えました。
上記2つの体系が、どのようにあわさるかについて書きます。
■あわせたかんじ
あわせると、こうなります。
<<要求分析段階>> ・要求を出す(ここ) →「(A)要求をヒアリングして、その要求に関連する業務を挙げる」が、コレに相当します。 <<ヒアリング準備段階>> できれば、ヒアリング前に、入出力関係の資料をもらっておいて、 ここまでやっておきたい(でも、できなきゃしょうがないけど。。。) (1)利用者を体系づけて分けます (2)今回対象の利用者について、システム利用(入出力)場面を考え、業務シート作成 (3)利用者が利用する一場面をとって、入出力を、まず出力から確認します (3-あ)まず、外部に対して出力になっているものを取り上げます。 (3-い)その外部出力の具体的内容を考え、入出力のシートに書きます。 (3-う)その外部出力を出すために必要な情報が、入力されているかどうか、確認 (3-えお)(3-う)までで、入出力のシートはできているので、それに対応する 業務シートがなかったら追加、完成させます。 →ここで、入出力は完成させます。 つまり、ヒアリング前に、入出力を抑えておくということです。 そうしないと、ヒアリングのときに入出力がもれたり、 言ってることがちんぷんかんぷん 。。はひどいけど、誤解したりします (営業報告が月ごとだと思ったら日報だったとか) <<ヒアリング>> ・ヒアリングする。とくに、入出力の関係について、相手の言っている話に、矛盾や 漏れがないか(事前に(3)までで確かめているはず)、 自分の想像と、ぜんぜん違うことをしているとかないかを、確認する <<ヒアリング後>> (4)利用者からの入力を受け取ってから、利用者への出力まで、 システム内の業務を追加します (4-あ)まず、システムトップを書き加える (4-い)中間のアクティビティとデータ加工を追加する →ここが (B)「業務をまとめたシート」を作成し、業務の上下(親子)関係を決める (C)各業務をヒアリングし、「業務をまとめたシート」を埋めたり、追加する になります。ヒアリングの内容をもとに、業務をまとめたシートを埋めていきます。 ●なお、ここで、前の手順では書かなかった (D)同時に、現在の帳票、画面から、「入出力についてまとめたシート」をうめる (E)「業務をまとめたシート」の入出力から「入出力についてまとめたシート」を補完する が入ります。 つまり、入出力について、ヒアリングのときにはじめて知った(@_@!)とか、 矛盾を追及してきたら、出てきた!っていうのがあります。 そいつを書き加えます。で、入出力を完成させます。 (4-う)出力から考えて、足りない部分のアクティビティがないか、確認する →ここが (F)確認する になります。 <<シナリオ作成など>> (5)利用者への出力ごとに、シナリオをつくります (6)利用者の範囲を広げていきます。 |
こんなかんじです。
つまり、大きくまとめると、
●要望を聞く
●ヒアリングする前に、事前準備として、入出力関係はもらっておいて、
一通り、確認して、まとめておく
→ヒアリングのとき、相手の言っていることが入出力レベルで確認できるくらい
→ここからどんな業務がありそうで、ヒアリングのとき、何を聞くかまで
考えられれば、ベスト!
●ヒアリングする
入出力ベースに一連の動作を確認する
→そのときヒアリング前の入出力で、もれていたら追加する
●シナリオの形でまとめる
理解しているかどうかまとめる
ってかんじになります。
問題は、事前準備です。この準備がないと、結局、お客さんのいっていることをうのみにすることになり、おきゃくさんが、言い忘れたことがあったり、余計なこと(他の部署の話を想像で言う、上司が理想論を語るなど)を言われると、仕様に矛盾が出て、仕様変更が頻発になり、デスマーチになったりします。
ってかたちですかね、だいたいのところは。。。