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) | 要件定義の現場から | このブログの読者になる | 更新情報をチェックする

2007年04月07日

対談:なぜ新たなブログを立ち上げたのか?その4

koppe:
では、もうひとつの観点、ユーザ側の要求の情報が不足しているという点ですが、今まで、われわれが関わったプロジェクトでは、要件定義をすすめていくうちに、つぎつぎとユーザから聞いていない例外などの事実が明らかになってきたことがよくありましたね。
実は、ユーザは要求の元になっている自らの現状業務の事実をあまりよく知らないんじゃないかという気がしますが。
mokuren:
これは先ほども述べたように、ユーザ側が自分たちの要求をベンダに分かりやすいように伝えようとするあまり、できるだけITよりの表現で自らの要求をベンダに伝えようとするところに問題があるような気がします。
ところがこれだと、自らの業務の詳細を知らなくても要求を定義できてしまうことになります。
とくに、CRM領域の場合、ユーザ側の情報システム部門が要求定義した場合、その問題が大きくなるような気がします。
koppe:
つまり、こういうことですか?
たとえば英語が不得手な人が米国人に対して自分で使える英語の範囲で意図を伝えようとするとあまり細かいことは表現できませんね。だから、結果として細かいことに触れる必要がなくなる。それと同じように、ITに詳しくない人がITに変換するから、変換元の細かいことに触れる必要がなくなる。
逆にもし、ITに変換せずに業務をそのまま伝えようとするなら、自らが自らの業務を良く知らないことに触れざるをえなくなる。
mokuren:
そうです。
koppe:
では、ユーザ側が要求としてITに変換せずに現状業務をそのまま提示するなら、要求情報の不足は解決するのでしょうか?
mokuren:
半分は満たされると思いますよ。
koppe:
残りの半分は?
mokuren:
現状ではなくこれからの業務をどうするか、その情報がそこには存在しない。
koppe:
なるほど。
そこには新しいITがはいってくるから、ITへの変換が必要になってきますね。
mokuren:
そうです。
koppe:
ということは、見積もりが狂わないような要求情報は、現状業務がどうなっているのか、これからの業務を新しいITを含めてどうするのかが明確化されているもの、ということになりますか?
mokuren:
いや、これからの業務を新しいITを含めてどうするのかが明確化にさえなっていれば、ベンダ側から見れば見積もりはそんなに狂わないと思います。
それさえきっちり表現されていれば、現状業務をあえて知る必要は無いと思います。
koppe:
そういわれてみればそうですね。
mokuren:
よく見かけるRFPは、結局、その未来業務のITで実現するところを中心に書いてあって、未来業務全体を書いているわけではないのですね。
このような情報を元にベンダは見積もりをするわけですから、見積もりが狂わないはずがないともいえます。
koppe:
とはいえ、現状業務はどうなっているのか、これからの業務を新しいITを含めてどうするのかを、ユーザ自らが明確にして提示するのは難しいのも事実ですね。
mokuren:
そこなんです。
ユーザ側が、これからの業務を新しいITを含めてどうするのかを明確化にさえしておけば、失敗プロジェクトは大幅に減少すると思えますね。
でも、問題は、ITを含めて、というところなんですね。このキーワードが入ったとたん、ユーザ側では検討できないものとなってしまうのですね。それももっともだと思います。
ITでどこまでできるのか知らないのは事実なんですから。
実際、IT要件を検討しているときに出てくる追加要件は、現状業務の例外(=マニュアル化されていない)から出て来るのがほとんどですね。
その結果、ベンダ側はその防衛手段として現状分析をIT要件検討の前にやらざるを得ない状況になる。
koppe:
そのためにコンサルタントを入れるのではないですか?
mokuren:
そうですね。このことに気づいたユーザやベンダが、そのことを解決するためにコンサルタントなるものを参画させるんですね。
ところが、このコンサルタントが曲者なんですね。別にコンサルタントの悪口を言う気はなくて、コンサルタントというものの定義が曖昧すぎて、単にコンサルタントといっても本当にその問題に役立つかどうかが疑問だということを言っています。
この場合、この問題に結果的にフィットしたコンサルタントだと、さすがコンサルタントだということになります。またフィットしないコンサルタントだった場合は、所詮コンサルタントはこんなもの、になってしまう。
じゃあ、どのようなコンサルタントであればよいのか?それを知るためには、コンサルタントがどのような生業なのかを少し吟味してみる必要があるのではないでしょうか。
koppe:
うーん確かに、現状業務を例外も含めて明確にして、これからの業務をITを含めて明確化するコンサルタントが、どのようなコンサルタントなのかと聞かれると、即答できませんね。
ITコンサルに含まれる部分もあると思われますし、業務コンサルに含まれる部分もあると思います。
mokuren:
そのような切り口とは違う、別の形で定義されたコンサルが正解なのではないかという気がします。 
posted by koppe at 23:30| Comment(0) | TrackBack(0) | 対談 | このブログの読者になる | 更新情報をチェックする

2007年03月31日

対談:なぜ新たなブログを立ち上げたのか?その3

koppe:
ところで、失敗したプロジェクトの原因を聞くと、誰もが見積もりミスと要件定義の甘さを挙げますが、それが分かっていながらまた失敗を繰り返してしまう。なぜなんでしょう?
mokuren:
今の表現を借りると、ミス・甘さ、という言葉に問題があるんじゃないでしょうか?
koppe:
というと?
mokuren:
そもそも、ミスしているんでしょうか? 甘いんでしょうか?
ミスするということは、ミスしない方法が予め分かっている場合に初めて言えることですよね。それもわかっていないなかで、簡単にミスや甘さで片付けられる問題ではないように思えます。
koppe:
そうですね。
われわれが実際に関わったプロジェクトでも、プロジェクトの開始後に当初の見積もりよりも大幅に作業が増えたことがありました。。
しかし、受注前に提示した見積もりに関しては次のことが言えます。構築側は(以降ベンダ)は構築依頼側(以降ユーザ)の予算と競合価格を考慮し、ユーザから提示された要求情報に基づいて、それを最大限満たせるシステムを想定して見積もりを出している。
これは、ミスしたわけではないですよね?
mokuren:
そうですね。
koppe:
でも、受注後に詳細な打ち合わせを行ったらずれた。
ベンダの立場から、結果として妥当な見積もりが出せなかった理由を考えてみると、要求の情報が不足していること、ユーザ予算(すなわち価値観)が実際に必要なシステム構築費用に比べて低いといえると思います。
そうなってしまうのはなぜでしょうか?
mokuren:
受注後に要求定義や要件定義を行っていくと、見積もり想定外の要求が膨らんでくるのですね。
でも、それはベンダ側の視点であって、ユーザ側にしてみれば、当初からの想定内であって、別に膨らんでいるわけではないのですね。
どちらも、主観で判断しているから、どちらも正しいという世界に落ち込んでしまう。
koppe:
その主観での「想定内」の範囲のギャップが、見積もりがずれて後でもめる原因のひとつなんですね。
mokuren:
そうですね。
問題は、先ほど述べた「主観」という言葉です。
「主観」が問題なのであれば、「客観」にすればいいのですが、それに対するよい方法が未だに存在していないのが実情ではないでしょうか?
まず、費用に関してですが、ユーザから見ると予算内に収めないと想定される効果よりコストのほうが上回ってしまうので、提示できる目いっぱいの費用を提示しているということになります。
また、要求の内容に関していえば、ユーザ側から見ると、自らはITに関しては素人であるのだから、素人の範囲でできるだけITを前提とした要求を提示した、これ以上どうしろというんだ?という思いになっている。
逆に、ベンダ側から見ると、自らは顧客の業務に対しては素人だから、素人の範囲で顧客の業務を前提として要求を理解して見積もった、これ以上どうしろというんだ?という思いになっている。
どうも、相手の立場になって自らができる範囲を目一杯考えるという文化?が問題のような気がします。
koppe:
投資対効果の話がでましたが、IT構築のコストは、確かに単なる積み上げではなく、期待効果から算出されるべきものですね。それが実際にIT構築にかかる費用より少ないということは、CRMシステムは期待効果に比して難易度が高いということでしょうか?
mokuren:
結果的には、そのようなケースが多いと思います。
この期待効果そのものが仮説であり主観なんですね。
これにどのように客観性をもたせるかは、非常に難しい問題だと思います。
で、結局のところ期待効果に関してはユーザ側の主観をそのまま受け入れるしかない。
koppe:
確かに、CRMシステムは人件費がこれだけ減るとか、売上がこれだけ伸びるとかという具体的な効果を挙げるのが難しいので、基幹システムなどに比べると多額の予算をとることは難しいですよね。
それを元にしたユーザ側の主観としての期待効果に見合うコスト、それに抑えることがCRMシステム構築の大前提となるわけですね。でなければIT化をする意味そのものがなくなってしまう。
mokuren:
そうですね。
posted by koppe at 12:59| Comment(0) | TrackBack(0) | 対談 | このブログの読者になる | 更新情報をチェックする

2007年03月28日

対談:なぜ新たなブログを立ち上げたのか? その2

koppe:
私たちは、ここ数年、CRM領域、たとえば営業支援システムやコンタクトセンター、カスタマポータルなどのSIをやってきたわけですが、最近、この領域での失敗プロジェクトが激増しているような気がしませんか?
mokuren:
しますね。
koppe:
これらのシステムは今や目新しいものではありません。目新しいときならいざ知らず、目新しくなくなるまでの間にノウハウが蓄積され、生産性が上がり、失敗プロジェクトは減っていくはずなのに、なぜ増えているんでしょう?
mokuren:
そこなんですね。
そこに話の焦点を絞ると、つぎのようなことが言えると思います。
このCRM領域なんですが、当初は、だれもITとしてどのようなものにすればよいかわかっていなかった。それで、取り合えずこの予算の範囲で作ってみようかぐらいの感覚で、まずは典型的なシステムの導入にトライしてみたというのが実体ではなかったのでしょうか?
koppe:
まだCRMという言葉が目新しかった時代は、企業ごとの固有性を出そうといった要望は少なかったし、要求される機能も少なかったということですね。
mokuren:
しかし現在は、それらの初期CRMシステムがリプレース時期に来ているんですね。ところが、そのCRMという概念がITの枠を飛び越え、顧客視点の差別化戦略にまで結びつき始めたため、あの例外サービスもこの例外サービスもとなって収拾つかなくなってきているのではないのでしょうか?そのためITシステムも複雑度が一気に増してきた。そんな構図のような気がします。
koppe:
CRMは本来、企業の差別化の源泉ですから、企業ごとにみんな違う。その多様性がIT化を難しくしているでしょうか。
mokuren:
差別化にもいろいろあって、従来は製品での差別化が中心だったと思うのですが、現在は、製品での差別が難しくなってきたため、それに付随するサービスの差別化にスポットがあたってきていますね。
その観点でいうと、サービスでの差別化を実現する手段の一つとしてのCRMシステムが多様化するのは当然のことと思われます。
koppe:
つまり、初期のCRMは既製服、現在のCRMはオーダーメイドが求められているということなんでしょうか?
mokuren:
そうですね。
posted by koppe at 22:45| Comment(0) | TrackBack(0) | 対談 | このブログの読者になる | 更新情報をチェックする

2007年03月26日

対談:なぜ新たなブログを立ち上げたのか?

koppe:
今まで私達は、「知的生産性探求塾」のブログで知的生産性を向上させる方法について議論してきたわけですが、今回、新たにITシステム構築における「要求定義・要件定義」にフォーカスを当てたブログを立ち上げました。なぜ「要求定義・要件定義」にフォーカスすることにしたのか教えてください。
mokuren:
そもそも、我々の本職はITであって、その意味では知的生産性というのがどちらかというと寄り道だったのかもしれません。
koppe:
でも、そのITを実現するためには、知的生産性をあげる必要があるから、探求してきたんですよね?
mokuren:
そうですね。
ソフトウェアの生産性は、人によって10倍ぐらい平気で違うという実感があるんですね。
確かに、コーディングという局面だけ見ると、その生産性の差は2倍程度ぐらいかなとおもうのですが、最終的に望みどおり動くものができるまでと範囲を拡大した瞬間、10倍ぐらいの生産性の差を感じてしまうのです。
koppe:
コーディングの生産性の差は2倍、システム構築全体の生産性の差は10倍。その差はどこで生まれるのでしょうか?
mokuren:
それはずばり、どのようなものを作るかがきちんと決まっているかどうかだと思います。これが定まっていないと、工程が進むほど仕様調整や手戻り、追加修正など計画していない作業が激増して、生産性が急激に低下するのを我々は肌身で知っています。
koppe:
システム構築においては何を作るかをきちんと決めるフェーズが要求定義・要件定義ですから、システム構築における生産性を決定づけるのは、要求定義・要件定義だということですね。それで知的生産性向上のターゲットをもっとも生産性向上効果が高い要求定義・要件定義のフェーズに絞ったというわけですね。
mokuren:
そういうことです。

posted by koppe at 22:54| Comment(0) | TrackBack(0) | 対談 | このブログの読者になる | 更新情報をチェックする

2007年03月25日

はじめに

 ITの世界では、システムを構築にするにあたり、要求定義や要件定義が非常に重要であるとの認識が広がりつつあります。しかし、その実体はまだまだ曖昧で、そのために費やすコストの妥当性が未だにはっきりしていないのも事実です。
 そもそも、要求定義や要件定義とは、どのようなもので、どのように進め、どのような手段・手法で定義するのか、それを解明する必要があるのではないでしょうか?
 また、要求や要件は人間が作り出した欲望が基本となります。ですから、本来客観性のあるものではありません。主観の世界のものなのです。ですから、そこには知的創造とそれを効率に進めるための知的生産性向上が必要になります。
 今まで、「知的生産性探求塾」というブログを立ち上げ、その観点でいろいろ議論してきましたが、そろそろ実際に役立つ世界へとその議論を進めるときが来たように思えます。
 どのようにこの後議論が進むか、やじきた珍道中にお付き合いいただければ幸いです。

 
posted by mokuren at 00:07| Comment(0) | TrackBack(0) | 対談 | このブログの読者になる | 更新情報をチェックする
×

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