前回,「ユーザー要求は,適当なところで切り捨てろ」と主張した。
 それに対して多くの関心をお持ちいただき,大変ありがたいことに有益な反応やコメントを頂いた。ご指摘のとおり,「ユーザー要求を切り捨てる」にもユーザーを納得させなければならないし,そのためのユーザー参加もひとつの方法である。一方,適当な切り捨てどころも必要になる。でないとシステムはレイムダック化(弱体化)から抜け出せなくなる。

 今回は,その辺について実例を紹介しながら考えてみたい。


手作業を残す代わりに期待効果を免除する

 稼働を始めたが機能しないシステムについて,「ユーザー要求の聞き取りが不充分だった」とか,「要求が曖昧だったので」とか,あるいはユーザー側から「要求が不充分だった」と言っても後の祭りであり,言い訳は無意味である。経営幹部はじめシステム構築側,ユーザー側がともに「不充分」だったこと,「曖昧」だったことを前提に,システム甦生の手を打たなければならない。

 前回 ,レイムダック化したシステムの甦生には3つの手段があることを説明した。このうち,まずシステムの強制甦生,すなわちユーザーの不満や要求変更を無視して,強制的にシステムを利用させる方法の具体例を紹介しよう。

 A社ではSCM(サプライ・チェーン・マネジメント)の一環として生産計画システムを導入した。このシステムには顧客の納期変更・部材の入手や在庫状況・製造の進度状況などを勘案してシミュレーションした上で,最適な生産工程を組む機能があった。A社の製造部は大きな期待を寄せていたが,いざ稼働してみると,週単位シミュレーションはともかく,日単位シミュレーションは用をなさなかった。シミュレーションに必要なデータ入力など,すべての要素がシミュレーションのスピードに付いていけなかったのだ。

 製造部の現場スタッフは,それでもなお日頃の業務で最も苦労をしている日単位シミュレーションにこだわった。しかし,製造部長は多品種少量生産での日単位シミュレーションは無理と判断し,シミュレーションは週単位まで,日単位の生産工程の作成は,引き続き手作業で対応することに決定した。その代わり,システム導入による期待効果の日単位部分(残業や人員の削減)は免除した。

 B社は月次決算と,その集積である期決算にかかる日程を大幅短縮することを,株主などへ公に約束した。従来は毎月25日を締日として,決算結果が出るのは翌月中旬だった。これを,締日から5日以内に月次決算の財務諸表を作成することにした。そのためには27日までに修正を含めた全データを入力する必要がある。これに対し,各部署からは猛烈な反対があったが,トップダウンで強引に踏み切った。

 結果は基礎データの入力が間に合っても,修正が間に合わない。各部署は音を上げて,せめて修正入力だけでも締日を1日延ばすように希望した。しかし決算日程の短縮は,公の約束事である。トップは絶対に譲らなかった。各部署は初期入力に注意力を集中することで修正入力を最小限に減らし,全入力を2日間で完了させることに成功した。システム稼働からは半年もの期間を要したが,トップダウンの指示で各部署はやり遂げた。


不正確なデータを利用する機能を除いて部分導入

 次に,レイムダック化したシステムを甦生させる2つ目の方法,ひとまず対症療法的な小手術を施した上で,ユーザー要求や業務改善などを視野に入れた大手術へ進む具体例を取り上げる。

 C社では,ERPの某パッケージを導入した。このパッケージは受注の引き合い以降,見積もり・受注・生産・出荷・売り上げ・検収・請求書処理・原価計算・債権債務処理・決算まで,論理的に一元化したデータを使用する。決算に必要なデータの自動仕分けも可能で,その導入効果には全社から大きな期待が集まった。しかし稼働が始まってみると,これでは使えないと,ユーザーからの機能変更要求や不満が相次いだ。

 例えば,部材費の変動,不良費把握の遅れ,生産標準時間の不正確さなどが原因で,データが実態を反映しなくなり,結果として,正確な原価計算ができなくなった。あるいは,債権債務は自動消し込みでスムースに処理するはずだったのが,分割回収・回収遅れ・長期未回収などが頻発し,混乱した。そこでC社では,関係者の打ち合わせで合意を得て,まず変動のない初期データを使えるところ,すなわち見積もりから請求書発行までを対象とするシステムを運用。それ以外の機能は,抜本的な業務改革に手をつけてから改めて利用することにした。

 D社では,SFA(営業支援システム)の入力方法に問題があって,営業第一線から総スカンを食った。入力ルールが複雑だ,入力ミスがあると致命的事態を引き起こす,入力に手をとられて本来の営業活動ができない,自分にメリットのない入力は拒否したいなどの不満が相次ぎ,システムは機能不全に陥った。CIO(最高情報責任者)は実態を調査し,システム構築側とユーザー側の意見を聴取した結果,「自分にメリットのない入力」以前の問題,すなわち入力方法そのものが異常に複雑であることを確認した。そこで,入力操作性に優れた別ソフトが安価で入手できるという情報を得て,導入済みシステムをプロトタイプと割り切り,出直すことを決断した。


定量的な切り捨てポイントは設定できない

 さて,ここに列挙したわずかな例で一般的法則を導き出そうとは思っていないが,一応参考にしながらユーザー要求の「切り捨てどころ」と「納得させどころ」を考えてみたい。

 「切り捨てどころ」は,前回 で考察した「ユーザー要求の切り捨て理由」に関連する。

 「切り捨てどころ」として最も多いケースは,それ以上受け入れると「全体最適」を損なうような要求だろう。上記のB社における,締日から財務諸表の作成日までの延長がそれに当たる。

 また,システムに致命的影響を与えるような欠陥への改善要求は拾うが,「末梢的な」要求は切り捨てる。これにはC社,D社の例が当てはまる。あるいはユーザーの要求をそれ以上聞き入れるとシステムが「硬直化」する恐れがある場合も,切り捨てる。それがA社の例である。A社のように「至難」な要求には,たとえ本質的内容でも切り捨て,手作業で対応すべきケースもある。「レアケース」な要求も同じである。あるいは「費用」との関係も,ユーザー要求を切り捨てるかどうかを判断する要素になる。

 ただ,時速120kmを超えた自動車で警告音を鳴らすようには,ユーザー要求の切り捨て点を定量的に設定することはできない。切り捨てを決定する者には,戦略的な経営思考が求められる。

 一方,ユーザーに対する「納得させどころ」も極めて重要になる。

 本来なら納得させるまでトコトン話し合うことが理想だが,いろいろな制約からそれは不可能だろう。しかし常に忘れてならないことは,目先の都合を考えているのではなく,あくまでも企業全体や将来のことを考えているということ,そして「要求切り捨て」事情の説明責任を果たすということである。それを前提に,納得させるための方法論を考えよう。

 言うまでもなく,C社のようなユーザーとの「話し合い」が望ましい。しかし,いつまでも話し合いを続けるわけには行かない。

 ユーザーも気づかない重要な「潜在的要求を見つけ出して実現して上げる」,あるいは切り捨てた要求に代る「代替提案」を示すことも説得力を持つ。D社の例である。

 要求を削り取る分だけ「期待効果やノルマについて相当分猶予を与える」ことも,納得させるには効果的である。A社の例である。いよいよトップダウンにより「大義名分」という大ナタを振わなければならない場合もあろう。これはB社の例である。トップの強力なリーダーシップは,大きな説得力を持つ。

 このほか,情報部門からユーザー部門に「人材を供出」して支援する,あるいは「ユーザーに主体性」を持たせてやらせてみるなどの方法も,時間はかかるが効果的である。

 ただ,どの場合も「要求切り捨て」という事が事だけに,トップの関与が決定的に重要である。


→増岡 直二郎バックナンバー一覧へ

■増岡 直二郎 (ますおか なおじろう)

【略歴】
小樽商科大学卒業後,日立製作所・八木アンテナなどの幹部を歴任。事業企画から製造,情報システム,営業など幅広く経験。現在は,nao IT研究所代表として経営指導・執筆・大学非常勤講師・講演などで活躍中。

【主な著書】
『IT導入は企業を危うくする』,『迫りくる受難時代を勝ち抜くSEの条件』(いずれも洋泉社)

【連絡先】
nao-it@keh.biglobe.ne.jp