知的生産性探求塾

　先日レビューした検討資料の中に、実現案を提示するテーマが２つあった。それぞれに実現案が複数書いてあったので、「１つめのテーマに対してはセキュリティという視点が漏れている、２つめのテーマに対してはこのケースでは複数の実現案を提示する必要はない」とコメントして修正を依頼した。 　するとその修正された資料は、なぜか両方のテーマとも実現案が１つになっていた。そのことを本人に確認すると、コメントを見て「セキュリティが一番重要」と思い込んでセキュリティ観点を重視した案に絞ったのだという。 　つまり、この資料を作った本人は、複数の実現案を提示する必要性の有無の判断基準を持っていないことが分かったのである。 　要件定義において、どんな場合に複数の実現案を提示すべきで、どんな場合に単一案でよいのだろう？ 　要件定義の目的は、「後に続く設計工程で発生するブレを抑える」ことにある。 　したがって、複数案を提示すべきものは、「どの実現案を採用するかが後工程に大きく影響するもの、すなわち、複数の実現案の間で開発規模や機能性などの差が大きいもの」ということになる。言い換えると、どちらの案でも開発規模や機能性などにあまり違いがないものは複数案を提示する必要がないといえる。それは、後工程で決定すればよい話である。 　では、これらの案をどのように顧客に提示すればよいのだろうか？ 　顧客は提示された複数案を評価し、どの案を採用するかを判断する必要がある。判断するための観点は複数存在するが、どの観点をどれだけ重視するかによってどの案を採用するかが決まる。が、それは、顧客でなければ判断できない。したがって、複数案の検討資料は顧客が速やかにその判断を行えるものでなければならない。 　そのためには、それぞれの案の概要と共に、それぞれの案に対する複数の比較観点と各観点での評価（メリット・デメリットや開発規模など）を比較しやすい形で提示する必要がある。 　また、複数案が存在するということは、すべての観点において特定の案が最適であるということはまずないはずである。 　もし、複数案の比較結果がそうなっているのであれば、それは比較観点が漏れているということを意味するので、漏れている比較観点を見つけて追記することが必要である。 　要するに、要件定義における複数案の検討資料の顧客価値は、「後工程への影響が大きい開発規模や...

　パッケージベースのシステムの要件定義では、通常、実現機能一覧表、すなわち、実現機能とカスタマイズ内容を説明する一覧表を作ります。 　先日、他のメンバが作った表をレビューしていて、自分がどのようにこの表をチェックしているかの手順が明確になりました。 　まず横軸。カスタマイズの内容が妥当かどうかを判断できる論理構成になっているかどうか？ 　そのための構成としては、横軸を実現したい機能（ToBe）、パッケージの標準機能（AsIs）、カスタマイズの内容（実現方法）にするのが一般的だと思います。すなわち、実現したい機能と事実としてのパッケージの標準機能を説明しつつ、その差分が、カスタマイズ内容の根拠となるように横軸を構成します。 　次は縦軸。縦軸は実現したい機能をリストアップするわけですが、適当に思いつくままリストアップしたのではなく、漏れなくリストアップしたことということが示されているかどうか？ 　そのことをどうやって示すかというと、実現機能をＭＥＣＥで分類し、分類が論理的に漏れていないことを示すしかありません。 　では、どのようにＭＥＣＥ分類すればよいのか？ 　これには、オブジェクト指向的な分類が簡単だと思います。すなわち、システムに存在する論理的なオブジェクト（データ）をリストアップし、それぞれに対して、そのオブジェクトに対する一般論としての操作をリストアップする。それを分類として、実現したい機能を当てはめていく。 　オブジェクトは「ユーザ情報」「ドキュメント情報」というようにそのシステムで扱うオブジェクトを挙げていきます。これはシステムごとに違ってきます。これは一見すると至極簡単なことのように思えますが、パッケージベースの要件定義では往々にして陥る罠があります。それは、パッケージが提供しているデータモデルとしてのオブジェクトと、実現したい機能で扱う論理的なオブジェクトがよく似通っているために、両者を混同してしまうということです。このカテゴリを混同してしまうと本来１つの機能として表現されるべき内容が複数箇所に散在したり、同じような内容が何箇所にも繰り返しでてくるということになったりします。 　オブジェクトに対する操作は、特定の情報が格納されている場所に対して一覧・検索、登録、削除、更新、参照　が考えられます。 　windowsのファイルシステムで言えば、ファイル・フォ...

　先日、客先で資料をレビューしているとき、自分がやたらと言葉を区別したり定義したりするための発言をしていることに気がつきました。たとえば、「このポリシー設定には、みんなで使う物を設定する場合と、特定の人が一時的に使うものを設定する場合とが含まれていますね。前者を共用ポリシー設定と呼ぶことにしませんか？」とか、「マイポリシー設定という言葉は、パッケージで使われている言葉ですが、要求される機能と一致しているかどうか現時点では分からないので、要求される機能のほうは別の言葉にしませんか？」というように。 　そういえば、ＳＩの仕事を始めたころ、一緒に仕事をしていたmokurenさんが常にそういう発言をしているのを見て、うるさいと感じるほどやけに厳密に言葉を使うなということと、この言葉が今あいまいだというのがなぜ即座に分かるんだろう、と思っていたことを思い出しました。 　開発の仕事をしているときは、長年同じ人たちと同じような仕事をしていたので、都度都度言葉を厳密に定義しなくても、各自が勝手にそこで使われている言葉の意味を調整・学習することで会話が成り立っていました。 　しかし、短期間で新しいお客様と開発するシステムを検討・合意してシステムを構築するＳＩの仕事の場合、言葉があいまいなままお客様と合意したと思っていても、それは合意したことにはなりません。私は、ＳＩの仕事でお客様とのコミュニケーションを繰り返すうちに、いつの間にか、言葉があいまいだということが判断できるようになっていたのです。 　では、私はどうやって言葉があいまいだということを判断しているのでしょうか？実際には、あいまいな言葉に遭遇すると、判断しているというよりも「気持ち悪い」と感じて反応しているようです。以前は言葉があいまいでも「気持ち悪い」と感じられなかったのに、なぜ今は「気持ち悪い」と感じるのでしょう？ 　そのときに私の頭の中でやっていることをイメージしてみると、たとえば、電球を換える時の踏み台に椅子を使おうとしてその椅子に乗っても大丈夫かを確認しようとするとき、椅子をゆすってみてぐらぐらしないかどうかを確認しますね？　それと同じようなこと、つまり「言葉をゆする」ようなことをしているようです。 　では、言葉をゆする、とは具体的にどういうことをして何を確認しているのでしょう？ 　これは、ちょっと簡単には言葉にでき...

koppe: では、もうひとつの観点、ユーザ側の要求の情報が不足しているという点ですが、今まで、われわれが関わったプロジェクトでは、要件定義をすすめていくうちに、つぎつぎとユーザから聞いていない例外などの事実が明らかになってきたことがよくありましたね。 実は、ユーザは要求の元になっている自らの現状業務の事実をあまりよく知らないんじゃないかという気がしますが。 mokuren: これは先ほども述べたように、ユーザ側が自分たちの要求をベンダに分かりやすいように伝えようとするあまり、できるだけＩＴよりの表現で自らの要求をベンダに伝えようとするところに問題があるような気がします。 ところがこれだと、自らの業務の詳細を知らなくても要求を定義できてしまうことになります。 とくに、CRM領域の場合、ユーザ側の情報システム部門が要求定義した場合、その問題が大きくなるような気がします。 koppe: つまり、こういうことですか？ たとえば英語が不得手な人が米国人に対して自分で使える英語の範囲で意図を伝えようとするとあまり細かいことは表現できませんね。だから、結果として細かいことに触れる必要がなくなる。それと同じように、ＩＴに詳しくない人がＩＴに変換するから、変換元の細かいことに触れる必要がなくなる。 逆にもし、ＩＴに変換せずに業務をそのまま伝えようとするなら、自らが自らの業務を良く知らないことに触れざるをえなくなる。 mokuren: そうです。 koppe: では、ユーザ側が要求としてＩＴに変換せずに現状業務をそのまま提示するなら、要求情報の不足は解決するのでしょうか？ mokuren: 半分は満たされると思いますよ。 koppe: 残りの半分は？ mokuren: 現状ではなくこれからの業務をどうするか、その情報がそこには存在しない。 koppe: なるほど。 そこには新しいＩＴがはいってくるから、ＩＴへの変換が必要になってきますね。 mokuren: そうです。 koppe: ということは、見積もりが狂わないような要求情報は、現状業務がどうなっているのか、これからの業務を新しいＩＴを含めてどうするのかが明確化されているもの、ということになりますか？ mokuren: いや、これからの業務を新しいＩＴを含めてどうするのかが明確化にさえなっていれば、ベンダ側から見れば見積もりはそん...

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: そういうことです。