スタートページ＞ 主張・講演 マーフィーの法則（vol.2)はじめに・目次

Murphyology on Information Technology (vol.2) 2000s

０６　システム提案

システム提案には、経営戦略実現のための要求、業務部門からのシステム化要求、ＩＴ動向や他社事例などによるＩＴ部門からの提案などがある。それを総合的にまとめるのは面倒な仕事だ。

ユーザニーズ(2010/11/18)

システム構築では、ユーザーニーズを満足させることが必要だといわれている。ところが、そのユーザーニーズが曲者なのだ。

ユーザーニーズは偶然により決定される
　ＩＴベンダは「経営者の“想い”を実現すること」をウリにしている。そして、経営者の“想い”は明確だ。もうけたいのだ。しかし、その“想い”はただの願望であり、具体的なビジネスモデルになっていない。そこでＩＴベンダが協力するのだが、ＩＴベンダがユーザ企業の事業分野でもうける方法を知らないのは当然だ。
　“想い”は暗黙知である。暗黙知を正しく形式知に変換できる経営者は少ない。「例えば」の前提付きで「在庫が多過ぎる」と発言すれば、「在庫の削減」が重要な要件になる。
　また、コンサルタントがたまたま昨日雑誌で読んだことを思い出して、「流通の合理化は必要ですか」と質問すれば、それが特に重要ではなくても「まあ必要だね」と答える。これにより「流通合理化」が重要な要件となる。逆に、この対談でたまたま話題に上がらなかった生産分野は要件にはならない。
　ＩＴベンダは、この対談によって得た「在庫削減」と「流通合理化」だけを絶対的な要件だとして、美しい図表を盛り込んだ文書を提出して確認を求める。経営者は、確かに話題になったことだし、この文書は論理的に正しいのだから、正しいと答える。これが「もうけること」に最適な方法なのか、これを実現する情報システムが構築されれば本当にもうかるのかを確認したのではないのだが、これが経営者の方針だとされるのである。
ユーザーニーズはシステム要件に変換する段階で矮小化される
　先に指摘した「経営戦略はＩＴ戦略にブレークダウンするプロセスで矮小化される」と同じである。
　直接的に「在庫削減システム」を考えるのは困難である。そこで、在庫把握システムになり、そのための受注システムや出荷システムを構築することになる。同様に「流通合理化」は、運賃計算システムにすり替えられる。当然ながら、これらのシステムが構築されても、在庫が削減できたり、流通が合理化される保証はない。
　経営者がこれを懸念するようだったら、第1次、第2次に分けるのだと説明しよう。第1次が計画より大きな出費になるため、経営者自身が第2次を行う気持ちがなくなってくるので、“想い”が実現しない責任を回避することができる。
ユーザニーズはユーザすら分からない
　情報システムを計画してから廃棄するまでの寿命は長い。10年程度の寿命を期待するのであれば、5年後のニーズでなければならない。ところが経営環境は激変する。経営者が5年後のニーズを予測できないことは、5年前に設定した経営戦略が的外れであったこと、それに従い構築したシステムが、その後改訂を繰り返してきたことでも明白である。
　それをよく理解している経営者ならば、次のようにいうであろう。「私のニーズは1つだけだ。要求したら直ちに改訂できるシステムにしてくれ」。
　ところが、現在のニーズに固執して構築した情報システムは、固執すればするほど、改訂が困難なものになってしまう。カミソリのようなシステムにするのではなく、ナタのようなシステムにする方が良いのだ（これは社内ＩＴ部門への助言である。ＩＴベンダの立場では、むしろ固執すべきである。それにより、システム改訂の受注が保証されるのだから）。
ユーザニーズ半減・半増の法則
　しかも、要件分析の段階で要件が確定すると考えるのはナイーブ過ぎる。
　開発が進むにつれて次第にシステムの姿が見えるようになると、多様な意見が出てくる。その結果、計画時のユーザニーズの半分はシステム構築段階で取り下げられ、その分だけ新規のニーズが付け加えられる（半増程度ならよいのだが……）。その結果、222の法則や2423の法則（注）が顕在化されるのだ。
（注）２４２３の法則
・２の機能をもつシステムを２の金額で契約する。
・開発を進める間に、要件が膨らみ４の規模になる。
・ベンダは仕様変更だとして４に増額要求するが、ユーザは当初見積もりの２を主張する。
・交渉により、機能を３に減らし２の金額で構築する。
ベンダは２の金額で３の規模を作らされたと不満をもち、ユーザは４の機能を３に減らされたと不満をもつが、これが「公平」というものだ
ユーザーニーズはシステムを納入したときに明確になる
　「見える化」のために多くの図表が作成されているが、それらの図表を「読める」ユーザーはいない。何となく「まあ、これでいいだろう」と開発が始まる。開発途中での確認会議でも、欠席するか、出席しても真剣に検討しない。納入段階になり、自分の問題となった時点で、初めてじっくり検討する。そして、じっくり検討した結果、「振り出しに戻る」ような要求を出す。
　このメカニズムを熟知しているベテランは、システム設計書をSLAの交渉が始まる時点で作成する。決して、初心者のようにコーディング以前に作成するような無駄はしない。

ＩＴ部門と提案(2010/12/01)

経営者は「ＩＴ部門からの提案を期待している」という。ＩＴ部門自身も積極的な提案をするべきだと考えている。それなのに、どうして実現できないのだろうか？

まかぬ種は生えぬ
　消費者ニーズにマッチした商品を作る“顧客志向マーケティング”が主流であるが、消費者ニーズから革新的な商品が生まれたことはない。例えば、電球が発明されるまでは、消費者はもっと明るいランプが欲しいと思っただけなので、顧客ニーズを重視したら、せいぜいランプの芯の素材や形状の工夫だけで終わったであろう。ユーザーニーズの調査は“改善”には役立つが、“改革”には向かないのだ。
　ＩＴ活用で抜本的な効果を生むには、ニーズよりもシーズが重要なのだが、技術先行アプローチは厳重に規制される。種をまかせてくれないのだから、抜本的な提案ができるわけがない。
余裕は改革の父
系：忙しい部門のＩＴ化に手を出すな
　一昔前、NHKの人気番組「プロジェクトX」が放送されていた。その話の多くは、企業の環境変化や方針変更によって、閑職に追いやられた（失礼！）技術者たちがアンダーグラウンドで行っていた研究が、後になって革新的な成果を生んだ記録である。しかもその動機は、企業の将来への対策というよりも、技術者たちの好奇心による未知への挑戦が多かった。
　「必要は発明の母」だという。ところが、瀕死の病人が特効薬を発見した例はない。倒産に直面している企業は、新商品開発や新市場開拓をする余裕がない。
　ＩＴ部門でも同じである。与えられた業務が残業続きの状況では、抜本的な発想、ましてや他部門のための発想などが生まれるはずがない。抜本的な発想を求めるならば、ＩＴ部員を閑職に就かせる必要がある。
　ユーザー部門にも余裕が大切だ。降りかかる火の粉を払うのに四苦八苦している部門に、そのような状態を抜け出すためにＩＴ利用を考えないかと提案しても、「忙しくて検討するヒマがない。そっちで考えて開発してくれ。出来上がったら使わせてもらう」といわれる。このような状況でマトモなシステムができるはずがない。
偉大な成果は管理不在の賜物
　工業技術では試作品を作り、パイロットプラントで次第にスケールアップする。「小さく産んで大きく育てよ」は確立した方法論なのである。
　それなのに、ＩＴ部門には実験をさせてくれない。SOAを試してみようとか、Webサービスのひな型を作ってみようとしても、「目的を明確にせよ」「ユーザーニーズはどうか」「費用対効果を示せ」などといわれてしまう。
　プロジェクトXの技術者魂は多くの人に感銘を与えた。しかし観点を変えれば、有能な技術者を企業戦略業務に従事させなかった事例であり、プロジェクトマネジメントの失敗事例だと評価されるべきであろう。プロジェクトXでは工場の片隅を隠れ場所に使っていたが、ＩＴ部門はレガシーシステムが廃棄されて以来、隠れて仕事をする場所を失った。それに、行動の一切（費用・時間）を、自分の作ったシステムによって監視されている。
　また、プロジェクトXのアングラ研究で必要な研究機器や資材を調達できたのは、その研究の重要性を見抜いていた隠れパトロン（技術担当の上級役員）が存在したからである。いま、そのような隠れCIOが存在するだろうか？

そもそも、ＩＴ化を行うのではなく業務改革・改善を行うのが目的のはずである。それならば、問題に直面している利用部門が積極的になるべきなのだが……。

経営者や利用部門はＩＴ部門に提案をせよという。しかし、彼らがＩＴ部門に提案したことはない
　経営戦略や業務改革にＩＴを活用することの提案には、ＩＴからのアプローチと経営・業務からのアプローチがある。
　そして、ＩＴ化に関しては「経営主導」「ユーザー主導」であるべきだといわれている。それならば、ＩＴ部門に提案を期待する以前に経営者や利用部門が、ＩＴ部門に「EAの導入を考えたらどうか」「雑用を減らすために、ツールを導入したらどうか」と提案してもおかしくない。
　自分の任務について、「ＩＴ部門からの提案がない」と不満をいうのは、自分たちに企画能力がないからなのだろうか、あるいはＩＴ部門を買い被っているからなのだろうか。
痛い腹でも探られるのは嫌なものだ
　提案せよというが、提案は現状否定につながり、現在の担当者を批判することになる。そのため、求める提案とは自分が対象にならない提案なのである。
　経営者は自分が関与する経営戦略への提案よりも、在庫削減や生産コスト削減など中間管理職が担当する分野の提案を期待する。営業部門は、品切れを防ぐための流通システムや生産システムを期待するが、販売の平滑化や需要の早期確定のための販売システムは拒否する。それなのにＩＴ部門は愚直なので、経営者には経営戦略、営業部門には営業業務の提案をする。そして「実務を知らないたわ言だ」と一蹴されるのである。
　ＩＴ部門の責任か、経営者や利用部門の責任かなどと、責任をなすり付け合っても問題は解決しない。経営や業務からのニーズと、ＩＴ技術動向を相互に理解することが必要だ。業際的な取り組みが必要なのである。そのために、CIO、経営情報員会、ＩＴ部門の戦略部門化など、多様な取り組みが行われてきた。それなのに、「ＩＴ部門は提案を」は一向に解決されていない。その原因を根本的に検討する必要がある。

コミュニケーション(2009/9/15)

ＩＴ部門は、経営者や利用部門とコミュニケーションを図ることが重要だといわれている。コミュニケーションは双方向で成り立つのだが、ユーザーや経営者もＩＴ部門とコミュニケーションをするべきだという意見はあまり聞かない。マスコミの論調は片務的要求になっている。

●経営者・利用部門とのコミュニケーション

受益者負担の原則
　ＩＴが経営に役立たないと困るのは経営者だし、業務の改善にＩＴを役立てたいと願っているのは利用部門である。
　それなのに、特に困っていない（困ることに気付いていない）ＩＴ部門には、「経営者や利用部門とのコミュニケーションを図れ」というが、経営者や利用部門に「ＩＴ部門との接触を図れ」とはいわない。
下から上にアプローチするより、上から下にアプローチする方が簡単である
あるいは、「ＩＴ部門の片思い」「醜女の深情け」
　ＩＴ部門は従来より「ＩＴは経営戦略に密着している」ので、「トップとの意思疎通が重要だ」などといってきた。コミュニケーションは日常の接触が重要である。しかし、ＩＴ部員が社長と雑談しようと出かけるのには勇気がいる。
　それに対して、社長がＩＴ部門にふらっと行くのに勇気はいるまい。アポイントの必要もない。でも、そうしている社長はまれである。その理由は単純である。経営者はＩＴ部門あるいはＩＴ戦略を、それほど重視してはいないからだ。
1人に10の知識を教えるよりも、10人に1の知識を教える方が簡単である
　ＩＴ部門には多くのユーザー部門の知識を要求するのに、ユーザー部門には「ＩＴ部門をうまく利用する方法」を教えていない。それで、ＩＴ部門から適切な提案が生まれないのである。
合議による決定は、各意見の悪い部分を集めたものになる
　三人寄れば文殊の智恵とか、弁証法による正反合など、討論により全体最適化を図ることが重要だといわれている。ところが、実際には各案の共通する部分だけが合意事項になる。討論を重ねると、その共通部分は小さくなる。それで、全社統合的なシステムが作れないのである。

●ＩＴ部門内の上司と部下の関係

「部下育成」の記事の読者は部下である
　部下の育成はどの部門でも重要なはずであるが、営業や生産関連の雑誌に比べて、ＩＴ関連雑誌では非常に多く取り上げている。なかには「ＣＩＯの育て方」まである。営業担当専務や生産担当常務の育成などを取り上げた記事を見たことがない。
　ＩＴ雑誌では、コーチング、叱り方（ほめ方）などの記事が多い。一般社員は課長がこのようになってくればよいと思う。課長は部長がこうあってほしいと思う。部長はトップが……。誰も、部下へのアプローチは考えていない。
部下は、「部下との接し方」の例のようには反応しない
　上の記事では、部下のタイプに応じた叱り方（ほめ方）を事例で示しているが、事例のように反応することはまれである。部下もこの記事を読んで、叱られ方の勉強をしてほしいものだ。
上司に相談すると、無関係な答えが返ってくる
　トラブルが発生したので、その緊急対処の相談にいくと、未然回避の話題になる。品質改善のための標準化について相談をすると、緊急対策の話になる。

次へ進む