2007年12月09日

検討結果のまとめかた

 要件定義では、通常、顧客との打ち合わせのタイミングにあわせて、@検討資料の準備、A顧客との打ち合わせでの検討のための議論、B検討資料への検討結果の反映、というサイクルを繰り返しながら、検討作業全体を進めていく。
 このサイクルのうちの「B検討資料への検討結果の反映」を行う際に、1点注意すべきことがある。
 それは、決定した結果だけを反映するのではなく、決定に至る考え方を記載する、ということである。

 決定に至る考え方は、数学にたとえると方程式にあたり、決定事項は方程式で求めた答えの値にあたる。
 方程式が書いてあれば、同じ答えがいつでも出せるだけでなく、新しい課題が出てきても、方程式に当てはめることで容易に答えを導きだすことができる。

 たとえば、システムの利用実績出力対象項目を検討し、「項目A、B、C、D、Eのうち、A、B、Eを対象項目とする」と決定されたとしよう。
 しかし、決定されたことだけを記載したのでは、後日、新たな項目F、Gが出てきたときに、利用実績出力対象項目とすべきかどうかを、また一から検討しなければならなくなる。
 そうならないためには、この項目に決定した理由、決定に至る考え方を記載しておく必要がある。

 先ほどの利用実績出力対象項目の例ならば、以下のように記述をするとよい。

--------
利用実績対象項目の考え方

 ファーストリリースの開発規模を抑えるため、ファーストリリースで提供する利用実績出力機能の対象項目の考え方は以下の通りとする。

1.契約上の制限値に該当する項目
2.サーバリソースの消費量に直結する項目
  :
  :

-------

 考え方を記述したあと、実際の決定事項が確かにこの考え方にのっとっているかどうかをチェックすることにより、考え方の正当性を検証し、決定事項と共に記載する。
 このように考え方を記載しておけば、後で新たな項目の検討が必要になっても、この考え方に照らすだけで、対象とするかどうかを決定できるのである。

 ただし、検討結果の考え方をまとめるのは、思いのほか難しいことが多い。というのは、検討時の議論の中では、この考え方が明確に言葉になっていないことが多いからである。
 その場合は、言葉になっていない考え方を顧客に確認してもらうために、想定される考え方を「考え方のたたき台」や「考え方を引き出すための質問事項」などの言葉にして顧客にぶつけ、顧客の確認をとってから記載する必要がある。
posted by koppe at 23:01| Comment(0) | TrackBack(0) | 要件定義の現場から | このブログの読者になる | 更新情報をチェックする

2007年08月25日

パターンを洗い出すには

 要件定義では、通常、モレなく検討するためにパターンの洗い出しが必要になる。このパターンの洗い出しをちゃんと行うにはどうすればよいのだろうか。

 よくあるパターンの洗い出しは、考えられるパターンをただ列記したものが多い。この方法では、すべてのパターンが洗い出されていてモレがないということを示すことができない。つまり、一生懸命考えた洗い出しも、思いつくものを適当にピックアップしただけの洗い出しも、列記されたものだけを見るとその区別がつかないのである。
 では、列記されたものにモレがないということを、どう検証し、どう示せばよいのか?

 列記されたものは、それだけでは単なる点データの集合体になっている。点のままではモレが無いということは示せないので、それらをMECEを使って面にする必要がある。

 MECEを使って面にするには、まずそのデータを埋める表を作る。
表の縦軸、横軸は、ほとんどの場合最初から全部埋まることはない。しかし1軸は簡単に決められることが多い。そこでまず、1軸に分類を書き込み、空白の枠が2つだけの表をつくって、その表に列記されたものを仕分けしていく。表の分類はそれだけでモレがないということが明らかなものでなければならない。たとえば「社内」と「社外」、「新規」と「既存」、「利用前」と「利用中」と「利用後」というように。

 仕分けが終わったら、仕分けたデータを眺めて、枠内にあるデータの共通点に着目して、もうひとつの分類軸を見つける。共通点を見つけるには、このようにデータを近くに集めると考えやすい。

 余談になるが、ナンクロというパズルをご存知だろうか?ナンクロは同じ番号の白マスには同じ文字が入る、というルールだけをヒントにその番号の文字を決めていくパズルである。これを解くときによくやるのが、解決したい文字の部分を取り出して集めて試行錯誤しながらその文字を見つけるという方法である。たとえば「山○」、「○草」、「○外」をメモ用紙に書き出し、○に入る文字を探すと、「野」という文字が見つかる。同じことをそれぞれのマスがパズル面のあちこちに分散したままやろうとするとなかなか見つからない。
 このように、共通点を見つける作業は、共通点を見つけたい対象を物理的に近くに集めると見つけやすいのである。

 共通点を見つけてそれを分類軸にし、その分類軸にあわせてデータを仕分けする。データがうまく仕分けできなければ、分類軸を見直す。

 データを仕分けし終わったら、分類軸にあわせてデータを見直す。
・埋まっていない枠があるなら、そこに入るべきデータを見つけ出して埋める。
・枠に入っているデータがダブっていれば、1つに出来ないかを考える。
・枠に入っているデータの文言が、枠の意味づけにあっていなければデータの文言を見直す。
・それでもうまくいかない場合は、分類軸を見直す、または、新たな分類軸を見つける作業に戻る。

 また、分類軸の分類そのものが多数になり、見ただけで分類にモレがないことが分からない場合は、分類自体をMECEで分類する必要がある。

 こうして、分類軸と各枠に入るデータがすっきりと収まると、MECEの表は完成する。

 この表の縦、横の分類は2つまたは3つなので、見ただけで分類にはモレがないことが分かる。モレの無い分類で分類された表に、モレなく埋まっているデータはモレがないので、これでモレなくデータがピックアップされたことが示せるのである。

 もうひとつ、パターンの洗い出しの際によく陥る罠は、最初に思いつくものをあげることをせずに、いきなりMECEの表を作ろうとすることである。この方法では共通点を見つけ出すべきデータがないので、適切な分類軸を決めることができない。

 つまり、モレのないパターンの洗い出しは以下のステップで行い、モレがないということを示すためには完成した表を提示する必要があるのである。
 @思いつくものを列記する。
 A列記したものが枠内に収まる表をつくる。
 B表の枠内を表の軸にあわせて見直す。
posted by koppe at 23:33| Comment(1) | TrackBack(0) | 要件定義の現場から | このブログの読者になる | 更新情報をチェックする

2007年07月22日

複数案を提示する場合としない場合

 先日レビューした検討資料の中に、実現案を提示するテーマが2つあった。それぞれに実現案が複数書いてあったので、「1つめのテーマに対してはセキュリティという視点が漏れている、2つめのテーマに対してはこのケースでは複数の実現案を提示する必要はない」とコメントして修正を依頼した。
 するとその修正された資料は、なぜか両方のテーマとも実現案が1つになっていた。そのことを本人に確認すると、コメントを見て「セキュリティが一番重要」と思い込んでセキュリティ観点を重視した案に絞ったのだという。
 つまり、この資料を作った本人は、複数の実現案を提示する必要性の有無の判断基準を持っていないことが分かったのである。

 要件定義において、どんな場合に複数の実現案を提示すべきで、どんな場合に単一案でよいのだろう?

 要件定義の目的は、「後に続く設計工程で発生するブレを抑える」ことにある。
 したがって、複数案を提示すべきものは、「どの実現案を採用するかが後工程に大きく影響するもの、すなわち、複数の実現案の間で開発規模や機能性などの差が大きいもの」ということになる。言い換えると、どちらの案でも開発規模や機能性などにあまり違いがないものは複数案を提示する必要がないといえる。それは、後工程で決定すればよい話である。

 では、これらの案をどのように顧客に提示すればよいのだろうか?

 顧客は提示された複数案を評価し、どの案を採用するかを判断する必要がある。判断するための観点は複数存在するが、どの観点をどれだけ重視するかによってどの案を採用するかが決まる。が、それは、顧客でなければ判断できない。したがって、複数案の検討資料は顧客が速やかにその判断を行えるものでなければならない。

 そのためには、それぞれの案の概要と共に、それぞれの案に対する複数の比較観点と各観点での評価(メリット・デメリットや開発規模など)を比較しやすい形で提示する必要がある。
 また、複数案が存在するということは、すべての観点において特定の案が最適であるということはまずないはずである。
 もし、複数案の比較結果がそうなっているのであれば、それは比較観点が漏れているということを意味するので、漏れている比較観点を見つけて追記することが必要である。

 要するに、要件定義における複数案の検討資料の顧客価値は、「後工程への影響が大きい開発規模や機能性などの差が大きい複数の実現案の中から、顧客にとっての最適な案を、顧客自身がどれだけ短時間で選べるようになっているか」で決まるのである。
posted by koppe at 10:10| Comment(0) | TrackBack(0) | 要件定義の現場から | このブログの読者になる | 更新情報をチェックする

2007年05月26日

実現機能一覧の作り方

 パッケージベースのシステムの要件定義では、通常、実現機能一覧表、すなわち、実現機能とカスタマイズ内容を説明する一覧表を作ります。
 先日、他のメンバが作った表をレビューしていて、自分がどのようにこの表をチェックしているかの手順が明確になりました。

 まず横軸。カスタマイズの内容が妥当かどうかを判断できる論理構成になっているかどうか?
 そのための構成としては、横軸を実現したい機能(ToBe)、パッケージの標準機能(AsIs)、カスタマイズの内容(実現方法)にするのが一般的だと思います。すなわち、実現したい機能と事実としてのパッケージの標準機能を説明しつつ、その差分が、カスタマイズ内容の根拠となるように横軸を構成します。

 次は縦軸。縦軸は実現したい機能をリストアップするわけですが、適当に思いつくままリストアップしたのではなく、漏れなくリストアップしたことということが示されているかどうか?
 そのことをどうやって示すかというと、実現機能をMECEで分類し、分類が論理的に漏れていないことを示すしかありません。
 では、どのようにMECE分類すればよいのか?
 これには、オブジェクト指向的な分類が簡単だと思います。すなわち、システムに存在する論理的なオブジェクト(データ)をリストアップし、それぞれに対して、そのオブジェクトに対する一般論としての操作をリストアップする。それを分類として、実現したい機能を当てはめていく。
 オブジェクトは「ユーザ情報」「ドキュメント情報」というようにそのシステムで扱うオブジェクトを挙げていきます。これはシステムごとに違ってきます。これは一見すると至極簡単なことのように思えますが、パッケージベースの要件定義では往々にして陥る罠があります。それは、パッケージが提供しているデータモデルとしてのオブジェクトと、実現したい機能で扱う論理的なオブジェクトがよく似通っているために、両者を混同してしまうということです。このカテゴリを混同してしまうと本来1つの機能として表現されるべき内容が複数箇所に散在したり、同じような内容が何箇所にも繰り返しでてくるということになったりします。
 オブジェクトに対する操作は、特定の情報が格納されている場所に対して一覧・検索、登録、削除、更新、参照 が考えられます。
 windowsのファイルシステムで言えば、ファイル・フォルダ情報が格納されている場所がDドライブだとします。Dドライブに対しては、Dドライブ直下のファイル・フォルダの一覧、ファイル・フォルダの登録、特定のファイル・フォルダの名前などのプロパティ等の更新、特定のファイル・フォルダの名前などのプロパティ等の更新、特定のファイル・フォルダの削除ができますね。切り取りや貼り付けなどの操作も、この5つのどれかの分類に入れられるはずです。ここでポイントになるのは、フォルダのような入れ物のオブジェクトはそれに対してまた一覧・検索、登録、削除、更新、参照の操作ができるということです。
 オブジェクトとそれに対する操作の分類ができて、それに実現機能がきちんとマッピングされていれば、分類をみただけで漏れなくリストアップされていることが分かります。

 表の縦軸、横軸の検証が終わってから、最後に表の中身をチェックします。
 この表は、実現機能の1行1行について、実現したい機能は何々、パッケージ標準機能は何々、(つまりその差は何々)、だから(その差を埋めるための)カスタマイズ内容は何々という論理がきちんと成り立っている必要があります。そのためには、ただ実現したい機能とパッケージ標準機能を書けばよいというわけではなく、その差がひとめで分かるように書いてある必要があります。具体的には、それぞれで違うところだけを違うように書いて、それ以外の同じところはまったく同じに書いてあるかという観点で、2つの文章を比較してチェックすればよいわけです。

 つまり実現機能一覧表のチェックポイントは、「これで全部だという根拠」と「差分の根拠」がちゃんと示されているかということだと思います。
posted by koppe at 12:31| Comment(0) | TrackBack(0) | 要件定義の現場から | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。