“バカ・マジメ”をメンバーに入れるな!
2010/12/15
この法則は、チームメンバー人選に関する法則である。オペレーションズリサーチの初期の名著にあったと記憶している。
将兵は「リコウかバカ」「マジメとズボラ」に区分できるが、
- “リコウ・ズボラ”は将校にせよ
- “リコウ・マジメ”は下士官にせよ
- “バカ・ズボラ”は炊事当番にせよ
- “バカ・マジメ”は絶対にメンバーに入れてはならない!
というのだ。
|
![]() |
情報システムの開発や保守にかかわる費用は、ブルックスの法則により、規模の指数乗に比例して増大する。それに対して、情報システムの効果はパレートの法則により、機能(規模)の対数に比例して増大するだけである。このことから、上図に示すように「利益=効果−費用」が最大になる規模が最適規模だと言える。
「ユーザーが必要なニーズを上げてこない」と嘆いたのは昔の話だ。現在では、ユーザーが多様な要求をしてくるし、IT部門はそれを至上命令として受け入れる傾向がある。そのために、規模はますます増大(上図の右側へ移行)し、中には、限界規模を超えてしまうものもある。
- - PR -
このような状況にさせる元凶が、ユーザー部門からプロジェクトに参加した“バカ・マジメ”なメンバーである。“バカ・マジメ”なメンバーは、まじめなので新システムに取り組むべき機能を真剣に考える。利用部門の仲間に聞くだけでなく、他社の調査も行い、マスコミで取り上げた事例も研究する。なかには自分でニーズを「発明」したりする。そして、分厚い要求機能リストを作成する。
教科書では、ユーザーニーズは優先順位のランクを付けるべきだという。ところが、この“バカ・マジメ”なメンバーは、馬鹿なので自社の置かれている状況、利用者のレベル、費用対効果などの認識がない。しかも、まじめなので、これらのニーズはすべて自社にとって重要なランクであると主張する。そして、情報システム部のメンバーも“バカ・マジメ”だと、そのニーズを完全に実現することがプロジェクトの任務だと考える。
中には、“バカ・マジメ”でないメンバーもいるので、反対意見が出ることがある。ところが、“バカ・マジメ”な連中は、プロジェクト内で反対に合うと、猛烈に抗議するだけでなく、所属部門の部長にも実現をするよう圧力をかけるように依頼するし、トップに直訴して「いかにこの機能が重要なのか?」を他社の成功例なども引用して説得する。部長やトップは、彼らは改善に真剣に取り組んでいるように見えるので、その意見を支持する。
これにより、開発規模は過剰になってしまう。つまり、このようなメンバーが参加した時点で、プロジェクトの失敗は保証されるのである。
|
ERPパッケージの導入で成功する秘訣は、カスタマイズ(アドオン)を抑えることである。
導入当初は経営者の眼があるのでおとなしくしているが、経営者の関心が低下するのに従い、カスタマイズへの誘惑を抑えきれなくなる。そして数年後には、カスタマイズの多いシステムになっていることが多い。このカスタマイズ要求の首謀者が、“バカ・マジメ”であることは言うまでもない。
逆に、カスタマイズ排除への異常な伝道者になることがある。自社のコアコンピタンス業務ですら、パッケージに合わせべきだと主張し、反対者を非国民だと決めつける。
|
近年は、スパイラルモデルやプロトタイプモデルのように、システム開発のライフサイクルを繰り返して行う方法が普及してきた。ユーザーが満足するレベルに達したら打ち切ることができるので、手戻りを少なくして開発期間を短縮するのに適した方法だとされている。
ところが、“バカ・マジメ”な完全主義者がいると、「画面のフォントを変えたい」「棒グラフに影を付けたい」など多様な要求をする。「前回変更したものを以前のものに戻せ」などとも言う。この結果、このシステムは永久に完成しない。しかも、並行しているほかのシステムにも同様な連中がいると、ばらばらなシステムになってしまう。さらに、それを統一せよと言い出すようになると、スケジュールは絶望的になる。
|
“バカ・マジメ”でないメンバーは、最適規模での開発を主張するであろう。ところが、ユーザーの立場は多様である。全体的には優先順位が低くても、そのユーザーにとっては重要かもしれない。あるいは、将来的には価値のある機能かもしれない。それらをむげに否定するのは不適切である。
これを解決するのが、データウェアハウスのような情報検索系の普及である。すなわち、このプロジェクトでは、必要となる情報を得るためのデータの収集と整理までは行うが、それからの検索抽出・集計加工などは、EUC(エンドユーザーコンピューティング)に任せるのである。
このような対策により、ユーザー要求の多くを取り下げさせることができる。
|
第20回で「ユーザーの過剰体裁愛好症」を指摘したが、“バカ・マジメ”なユーザーは、EUCでもトラブルの種になる。
EUCは、自分あるいは自部門に限定した蛇口部分に限定すべきなのだが、それに飽き足らず、あるいは、要件定義で却下された自分の意見を実現するために、本管に関係する分野にまで侵略する。
内部統制におけるExcelシステムが問題になっているが、その原因は“バカ・マジメ”の仕業であることが多い。
東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士(情報工学)、中小企業診断士、ITコーディネータ、システム監査など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は『教科書 情報と社会』(日科技連出版社)、『もうかる情報化、会社をつぶす情報化』(リックテレコム)など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している。
法則186:“バカ・マジメ”をメンバーに入れるな
法則187:カスタマイズ・シンドローム
法則188:エンドレススパイラル・シンドローム
法則189:本管と蛇口を分離せよ
法則190:系:軒を貸して母屋を乗っ取られるな
情マネ流マーフィーの法則 バックナンバー 連載インデックスへ»
- 第1回 マーフィーの法則がIT版になって帰ってきた!
- 第2回 「他人のふんどし指向アプローチ」を考える
- 第3回 システム開発の可視化で何が見える?
- 第4回 標準化にメリットはあるのか?
- 第5回 ないものねだりのRFP
- 第6回 合併時の代理戦争には気を付けろ!
- 第7回 ERPパッケージの不思議あれこれ
- 第8回 経営者にITの費用対効果を説明するのは難しい
- 第9回 そもそも、IT計画が実現すること自体が奇跡だ
- 第10回 費用対効果を追求することで出銭が増える愚かさ
- 第11回 ITの効果とはプロジェクトの効果だ
- 第12回 納期とは遅れるものだ
- 第13回 “リスク管理のリスク管理”が必要だ
- 第14回 ITエンジニア今昔物語
- 第15回 そして、歴史は繰り返す − 2度目は喜劇として
- 第16回 羊頭狗肉のIT用語、誇大表示を告発する
- 第17回 “クラウドコンピューティング○×”の寿命
- 第18回 IT系アンケート結果は信用できない
- 第19回 ああ、上司と部下の悲しいすれ違い
- 第20回 ユーザーの過度依存症とIT部門の没我的愛情症
- 第21回 ユーザーの過度体裁愛好症が問題だ
- 第22回 役に立たないグループウェア
- 第23回 IT部門の社内的地位が低い“本当の原因”は?
- 第24回 なぜIT部門アウトソーシングがうまくいかないのか?
- 第25回 IT部門の戦略部門化は矛盾だらけ
- 第26回 日本にはびこる素人CIO
- 第27回 電子政府の研究はIT推進の教科書として最適だ
- 第28回 何かが足りない日本のIT教育政策
- 第29回 IT技術者、どう評価する?
- 第30回 成果の出ないIT戦略
- 第31回 ユーザーニーズを基にシステムを作るな
- 第32回 なぜIT部門は提案できない/しないのか?
- 第33回 “バカ・マジメ”をメンバーに入れるな!
- 第34回 なぜソフトウェアの部品化/再利用は進まないのか?
- 第35回 バグとの長い長い付き合い
- 第36回 コンピュータが発展すると人間はバカになる
- 第37回 自然科学法則の「情マネ流マーフィー」への適用
- 第38回 社会科学法則の「情マネ流マーフィー」への適用
- 第39回 情報科学の法則を復習しよう
- 第40回 情マネ流マーフィーの妖誤集
- 第41回 情マネ流マーフィーの妖誤集〜その2
- 最終回 情マネ流マーフィーの妖誤集〜その3
ホワイトペーパー(TechTargetジャパン)
|
|



