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年以上新しい記事の投稿がないブログに表示されております。