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

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

[木暮 仁，＠IT]

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

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

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

というのだ。

情マネ流マーフィーの法則その186

“バカ・マジメ”をメンバーに入れるな

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

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

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

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

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

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

情マネ流マーフィーの法則その187

カスタマイズ・シンドローム

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

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

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

情マネ流マーフィーの法則その188

エンドレススパイラル・シンドローム

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

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

情マネ流マーフィーの法則その189

本管と蛇口を分離せよ

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

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

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

情マネ流マーフィーの法則その190

系：軒を貸して母屋を乗っ取られるな

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

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

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

著者紹介

▼著者名　木暮 仁（こぐれ ひとし）

東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士（情報工学）、中小企業診断士、ITコーディネータ、システム監査など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」（日科技連出版社）、「もうかる情報化、会社をつぶす情報化」（リックテレコム）など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している

「情マネ流マーフィーの法則」バックナンバー

• 情マネ流マーフィーの妖誤集〜その3
• 情マネ流マーフィーの妖誤集〜その2
• 情マネ流マーフィーの妖誤集
• 情報科学の法則を復習しよう
• 社会科学法則の「情マネ流マーフィー」への適用
• 自然科学法則の「情マネ流マーフィー」への適用
• コンピュータが発展すると人間はバカになる
• バグとの長い長い付き合い
• なぜソフトウェアの部品化／再利用は進まないのか？
• “バカ・マジメ”をメンバーに入れるな！
• なぜIT部門は提案できない／しないのか？
• ユーザーニーズを基にシステムを作るな
• 成果の出ないIT戦略
• IT技術者、どう評価する？
• 何かが足りない日本のIT教育政策
• 電子政府の研究はIT推進の教科書として最適だ
• 日本にはびこる素人CIO
• IT部門の戦略部門化は矛盾だらけ
• なぜIT部門アウトソーシングがうまくいかないのか？
• IT部門の社内的地位が低い“本当の原因”は？
• 役に立たないグループウェア
• ユーザーの過度体裁愛好症が問題だ
• ユーザーの過度依存症とIT部門の没我的愛情症
• ああ、上司と部下の悲しいすれ違い
• IT系アンケート結果は信用できない
• “クラウドコンピューティング○×”の寿命
• 羊頭狗肉のIT用語、誇大表示を告発する
• そして、歴史は繰り返す − 2度目は喜劇として
• ITエンジニア今昔物語
• “リスク管理のリスク管理”が必要だ
• 納期とは遅れるものだ
• ITの効果とはプロジェクトの効果だ
• 費用対効果を追求することで出銭が増える愚かさ
• そもそも、IT計画が実現すること自体が奇跡だ
• 経営者にITの費用対効果を説明するのは難しい
• ERPパッケージの不思議あれこれ
• 合併時の代理戦争には気を付けろ！
• ないものねだりのRFP
• 標準化にメリットはあるのか？
• システム開発の可視化で何が見える？
• 「他人のふんどし指向アプローチ」を考える
• マーフィーの法則がIT版になって帰ってきた！