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