知的生産性探求塾

koppe: ところで、失敗したプロジェクトの原因を聞くと、誰もが見積もりミスと要件定義の甘さを挙げますが、それが分かっていながらまた失敗を繰り返してしまう。なぜなんでしょう？ mokuren: 今の表現を借りると、ミス・甘さ、という言葉に問題があるんじゃないでしょうか？ koppe: というと？ mokuren: そもそも、ミスしているんでしょうか？　甘いんでしょうか？ ミスするということは、ミスしない方法が予め分かっている場合に初めて言えることですよね。それもわかっていないなかで、簡単にミスや甘さで片付けられる問題ではないように思えます。 koppe: そうですね。 われわれが実際に関わったプロジェクトでも、プロジェクトの開始後に当初の見積もりよりも大幅に作業が増えたことがありました。。 しかし、受注前に提示した見積もりに関しては次のことが言えます。構築側は（以降ベンダ）は構築依頼側（以降ユーザ）の予算と競合価格を考慮し、ユーザから提示された要求情報に基づいて、それを最大限満たせるシステムを想定して見積もりを出している。 これは、ミスしたわけではないですよね？ mokuren: そうですね。 koppe: でも、受注後に詳細な打ち合わせを行ったらずれた。 ベンダの立場から、結果として妥当な見積もりが出せなかった理由を考えてみると、要求の情報が不足していること、ユーザ予算（すなわち価値観）が実際に必要なシステム構築費用に比べて低いといえると思います。 そうなってしまうのはなぜでしょうか？ mokuren: 受注後に要求定義や要件定義を行っていくと、見積もり想定外の要求が膨らんでくるのですね。 でも、それはベンダ側の視点であって、ユーザ側にしてみれば、当初からの想定内であって、別に膨らんでいるわけではないのですね。 どちらも、主観で判断しているから、どちらも正しいという世界に落ち込んでしまう。 koppe: その主観での「想定内」の範囲のギャップが、見積もりがずれて後でもめる原因のひとつなんですね。 mokuren: そうですね。 問題は、先ほど述べた「主観」という言葉です。 「主観」が問題なのであれば、「客観」にすればいいのですが、それに対するよい方法が未だに存在していないのが実情ではないでしょうか？ まず、費用に関してですが、ユーザから見ると予算内に収めないと想

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

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

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

　「０からはじめる要求定義・要件定義」というブログサイトを立ち上げました。 　いままで、知的生産性ということで徒然なるお話をここでさせていただいたのですが、本職のITに今までの議論を当てはめて見るとどうなるのか一度試してみたくなりました。 　今までの議論のエッセンスも入ってくるでしょうし、はたまた、まったく違う方向へ行ってしまうのかもしれません。 　ご興味のある方は一度覗いてみてください。 　※「０からはじめる要求定義・要件定義」の記事は、このブログのカテゴリ「要件定義」の記事として掲載しています。