“バカ・マジメ”をメンバーに入れるな！：情マネ流マーフィーの法則（33）

プロジェクトの成否はメンバー選定で大部分が決まると言っても過言ではない。そんなメンバー人選で決して選んでは人種がいるという……。今回はチームメンバー人選に関する法則を紹介する。

　この法則は、チームメンバー人選に関する法則である。オペレーションズリサーチの初期の名著にあったと記憶している。

　将兵は「リコウかバカ」「マジメとズボラ」に区分できるが、

• “リコウ・ズボラ”は将校にせよ
• “リコウ・マジメ”は下士官にせよ
• “バカ・ズボラ”は炊事当番にせよ
• “バカ・マジメ”は絶対にメンバーに入れてはならない！

というのだ。

　情報システムの開発や保守にかかわる費用は、ブルックスの法則により、規模の指数乗に比例して増大する。それに対して、情報システムの効果はパレートの法則により、機能（規模）の対数に比例して増大するだけである。このことから、上図に示すように「利益＝効果?費用」が最大になる規模が最適規模だと言える。

　「ユーザーが必要なニーズを上げてこない」と嘆いたのは昔の話だ。現在では、ユーザーが多様な要求をしてくるし、IT部門はそれを至上命令として受け入れる傾向がある。そのために、規模はますます増大（上図の右側へ移行）し、中には、限界規模を超えてしまうものもある。

　このような状況にさせる元凶が、ユーザー部門からプロジェクトに参加した“バカ・マジメ”なメンバーである。“バカ・マジメ”なメンバーは、まじめなので新システムに取り組むべき機能を真剣に考える。利用部門の仲間に聞くだけでなく、他社の調査も行い、マスコミで取り上げた事例も研究する。なかには自分でニーズを「発明」したりする。そして、分厚い要求機能リストを作成する。

　教科書では、ユーザーニーズは優先順位のランクを付けるべきだという。ところが、この“バカ・マジメ”なメンバーは、馬鹿なので自社の置かれている状況、利用者のレベル、費用対効果などの認識がない。しかも、まじめなので、これらのニーズはすべて自社にとって重要なランクであると主張する。そして、情報システム部のメンバーも“バカ・マジメ”だと、そのニーズを完全に実現することがプロジェクトの任務だと考える。

　中には、“バカ・マジメ”でないメンバーもいるので、反対意見が出ることがある。ところが、“バカ・マジメ”な連中は、プロジェクト内で反対に合うと、猛烈に抗議するだけでなく、所属部門の部長にも実現をするよう圧力をかけるように依頼するし、トップに直訴して「いかにこの機能が重要なのか？」を他社の成功例なども引用して説得する。部長やトップは、彼らは改善に真剣に取り組んでいるように見えるので、その意見を支持する。

　これにより、開発規模は過剰になってしまう。つまり、このようなメンバーが参加した時点で、プロジェクトの失敗は保証されるのである。

　ERPパッケージの導入で成功する秘訣は、カスタマイズ（アドオン）を抑えることである。

　導入当初は経営者の眼があるのでおとなしくしているが、経営者の関心が低下するのに従い、カスタマイズへの誘惑を抑えきれなくなる。そして数年後には、カスタマイズの多いシステムになっていることが多い。このカスタマイズ要求の首謀者が、“バカ・マジメ”であることは言うまでもない。

　逆に、カスタマイズ排除への異常な伝道者になることがある。自社のコアコンピタンス業務ですら、パッケージに合わせべきだと主張し、反対者を非国民だと決めつける。

　近年は、スパイラルモデルやプロトタイプモデルのように、システム開発のライフサイクルを繰り返して行う方法が普及してきた。ユーザーが満足するレベルに達したら打ち切ることができるので、手戻りを少なくして開発期間を短縮するのに適した方法だとされている。

　ところが、“バカ・マジメ”な完全主義者がいると、「画面のフォントを変えたい」「棒グラフに影を付けたい」など多様な要求をする。「前回変更したものを以前のものに戻せ」などとも言う。この結果、このシステムは永久に完成しない。しかも、並行しているほかのシステムにも同様な連中がいると、ばらばらなシステムになってしまう。さらに、それを統一せよと言い出すようになると、スケジュールは絶望的になる。

　“バカ・マジメ”でないメンバーは、最適規模での開発を主張するであろう。ところが、ユーザーの立場は多様である。全体的には優先順位が低くても、そのユーザーにとっては重要かもしれない。あるいは、将来的には価値のある機能かもしれない。それらをむげに否定するのは不適切である。

　これを解決するのが、データウェアハウスのような情報検索系の普及である。すなわち、このプロジェクトでは、必要となる情報を得るためのデータの収集と整理までは行うが、それからの検索抽出・集計加工などは、EUC（エンドユーザーコンピューティング）に任せるのである。

　このような対策により、ユーザー要求の多くを取り下げさせることができる。

　第20回で「ユーザーの過剰体裁愛好症」を指摘したが、“バカ・マジメ”なユーザーは、EUCでもトラブルの種になる。

　EUCは、自分あるいは自部門に限定した蛇口部分に限定すべきなのだが、それに飽き足らず、あるいは、要件定義で却下された自分の意見を実現するために、本管に関係する分野にまで侵略する。

　内部統制におけるExcelシステムが問題になっているが、その原因は“バカ・マジメ”の仕業であることが多い。