書感：チェンジ・ザ・ルール（すべてのITコンサル＆SIerは、この本を読むべき）

書籍『チェンジ・ザ・ルール－なぜ、出せるはずの利益が出ないのか』を読み返しました。

エリヤフ・ゴールドラット博士による「Theory of Constraints (以後、TOC)：制約条件の理論」に基づいたビジネス小説第３弾です。

今回は、前回までの製造業の話とは変わって、IT企業の話になっています。成長著しいERP企業の社長のスコット氏が、同企業の成長を持続させるために悪戦苦闘する話です。

同社は、大企業向けERPソフトの大手企業ですが、同社を含め、業界全体であまりに急に成長したため、顧客候補となる大手企業の残りが少なくなり、このままでは市場が枯渇し、成長を維持することができないという事態に直面します。

同時に、顧客の要望に合わせて様々な機能をERPソフトに追加していった結果、あまりに複雑になり、ERPの導入にも、ちょっとした機能の追加や改善にも、ものすごく時間がかかるようになってしまいました。

更には、超大手顧客からは、多額の投資をして同社のERP製品を導入したのは良いけど、「利益がどのくらい増えるのか」と問われ、困惑する羽目になります。この顧客から「同社ERPを導入したのは失敗だった」と世間に宣伝されてしまっては、会社の存続に関わるので、何としても、導入＆利用費用に見合った以上に、顧客企業の利益増加に貢献できることを証明しなければならない・・・

と、このような状況からスタートし、ERPベンダー、システムインテグレーター（※）、顧客企業、それぞれに次々と起こる問題を目まぐるしく解決していくという流れです。

今回は、主人公の家族の話は出てきませんが、ソフトウェアベンダー、システムインテグレーター、顧客企業と、ITシステムに関わる主要関係者がでてきて、ITシステムにまつわる本質的な問題を様々な角度から見ることができます。

※．ERPソフトを顧客企業に導入する作業を行う企業。大型の機械で言えば、顧客企業に機械を運んで設置して必要な設定を行ってくれる企業に当たります。ERPのようなITシステムの場合、ソフトの開発会社と導入会社は分かれていることが一般的です。

ちなみに、このERPのモデルとなってる企業って、某ドイツのS〇P社なんですかね？　導入モジュールとかユーザー数ごとの課金体系とか、どう考えてもS〇P社にしか思えないのですが・・・

ともあれ、本書では、上記の物語を通じて、ITを導入して効率が良くなったハズなのに、導入企業の利益向上に全然貢献していないという、IT屋さんが苦手なこの問題をドストレートに問題提起し、答えも用意しています。

２０年近く前に出版された書籍ですが、いまだに（少なくとも日本の）SIの現場では、この問題を全然解決できていないと感じています。

少なくとも、私の周りにいた多くのITコンサル、プロジェクトマネージャー、SE、プログラマーは、顧客の利益どころか、メリットすら考えてないのでは？と、感じることがしばしばでした。（まぁ、ITの世界も変化が早くてキャッチアップは大変だし、でもベテランPM＆SEは新しいことやりたがらないし、お客様はお客様で、ITのことを全然わかってなくて話はかみ合わないことも多いし、ころころ意見が変わったり、意思決定してくれなかったり、できあがったのを見てからじゃないと判断できないと言って、仕方ないから分かる範囲で作るとやっぱり作り直しになるし・・・はっ！いかんいかん、闇の世界に引きずり込まれるところだった・・・）

ともあれ、では、なぜITを導入して効率があがったハズなのに、利益が増えないのか？なんですが、ポイントは以下の通りです。

今までと同じ作業をITで省力化するだけでは効果がでない
紙と鉛筆で手作業で情報を整理していた時代であれば、それを電子化するだけで1/10とか1/1000とかに作業時間が短縮されたかもしれません。そもそも手作業では大変過ぎて＆正確に実施できなくて諦めていたことを実現できるようになったことも多いでしょう。
けれども、一度でもIT化していることについては、システム刷新をする際に、前回と同じ内容であれば、業務の改善にはつながりません。
また、通常は、ITで担当者レベルの作業を効率化したからと言って、社員を削減することは稀です（非正規社員やパートナー企業の人員は減るかもしれませんが・・・）ので、人件費も減らないことが多いです。←実際、私があるシステムを作って導入した際に、これまでの作業が1/10の時間で出来るようになったことがありましたが、一人も人員削減されなかった経験があります。それまで同作業を担当していた社員の一人は、浮いた9割の時間を競馬の予想にあてていました・・・(苦笑)
ITの効果は、IT化することによって、それまでできなかった何らかの制約を取り払うことで発揮されます。逆を言うと、そこにフォーカスしないと、ITシステムを導入したり、新しくしても、大きな効果は期待できません。（そして、どうやって利益を向上させるか？という観点でフォーカスしないと、利益向上にはつながりません）
もちろん、より高性能なシステムにしてさくさく動くようになれば、システムを利用する人の作業効率は少しは上がると思いますが、大幅な人員削減につながらない限り、利益貢献という観点ではほぼ効果ゼロです（あまりに酷いITのせいで会社を辞める人が続出している様なら、それを止める効果はあるかも知れませんが・・・）
IT導入前に決まったルールを変えていない
企業のルールやプロセスは、基本的に、プロセスやルールを決める際の状況：業務内容とその時に使えるツールや人のスキルなどに依存して出来あがったと考えられます。
その為、ITシステムを導入して、できることが変わるのであれば、合わせて、プロセスやルールも変えないと、ITシステムの真の力を引き出す（中二っぽい）ことはできません。
その具体例を、本書ではいくつも挙げています。また、どのようにルールチェンジをするか？というところで、１冊目、２冊目で説明していたTOCが活用されています。

とまぁ、ITシステムを導入するなら、それまでのルールやプロセスも変えなきゃダメよ。という当たり前と言えば当たり前の話なんですが、ホントにこれができないんですよね。現場では。

プロセスやルールを変えるには、関係するプロセス全体を見渡せる人とそれを変える権限がある人が、しっかり理解して関与しないといけないのですが、多くの日本企業では、現場の声が大きい人が喚いて（笑）モノゴトが決まっていくので、これまでと同じものを高いお金をかけて作り直すだけになりがちです。

あと、何かを変えて失敗したくないので、とにかく保守的にノーリスクになるようにしたがる傾向も強いです。

まぁ、あまりにドラスティックに変えるのは大変だし、失敗したらどうしようと怖くなるのは分かるのですが、これまでホントに困っていたことを変えるために新しいシステムで決めたキーコンセプトすら亡き者にするのは、ホントに止めていただきたい。（そのくせ、導入後に効果がないと文句を言うのはもっとやめて欲しい）

さてはて、近年は、ITを始めたとしたテクノロジーで何ができるか分からない＆時間やお金を多大に掛けてITを導入しても効果がでるか分からないということが多いので、ITを細分化して、小さくトライ＆エラーをしましょうというのがトレンドなんですが、この書籍で書かれているチェンジルールの話や、会社全体を俯瞰したうえで、そのシステムで何を狙うのか？＝目的・目標が定まっていないで、トライ＆エラーしても、何をトライして、何がエラーだったのかが分からない、意味不明なプロジェクトになるので、気を付けましょう。

ともあれ、ITシステムの開発＆導入側の人はもちろん、利用者側の人も、ITが何のためにあって、そのポテンシャルを引き出すにはどうすれば良いのか、を理解するために、当書籍をぜひ読んで欲しいと思います。

当シリーズの第四弾は、「プロジェクトマネジメントがなぜ失敗するか」がテーマです。ITに限らず、ありとあらゆるプロジェクトの問題を解決するための手法が解説されているので、次作についても多くの人に興味を持って貰えたらなぁ・・・と、思っています（まぁ、この過疎ブログでは、ほとんど効果ないでしょうが）。

ではまた。