コンサルタントの日々学び

日々のデリバリーで得た体験、ノウハウ、教訓とかを週次ベースで書き留めていきます。

書籍「システムを作らせる技術」に込めた実体験からの思い

学び

先日7/22に、3年（もしくはそれ以上？）期間をかけた、「システムを作らせる技術」がやった書店に並んだ。
嬉しいことに発売からすでに重版が決まったそうで、読んでいただいている方がいるのはとても嬉しい。

今回この本を書いたのは過去の苦い体験がある。
お金と労力をかけてシステムをつくって、結局使われない無用の長物になった経験だ。
重版になったということは、同じような苦労や失敗をまだ多くの人が経験しているのだろう。
それをできるだけ防ぎたくこの本を書いた。

以下にこの本の「おわりに」の文を転載しよう。ここに、上記に対する自分の思いを詰めている。
「こんな経験したくないな」
「もしかしたらうちの会社でもこんな事態があるかもしれない」
そう思った方はまずはこの記事を、そして本気で解消したい方は「システムを作らせる技術」の本を当事者に紹介してほしい。

 

ーーーーーーーーーーーーーーーーーーーーー

個人的な執筆動機

ケンブリッジへの入社以前に参加したある大企業でのプロジェクトが、本書執筆のきっかけだった。

私は途中から参画したのだが、間接部門を効率化した上で、より付加価値の高い業務へのシフトを目指すプロジェクトだった。当時は政府が「日本の生産性向上」を重要施策として掲げ、それに伴い各社でITシステム・ツールの活用が取り上げられており、その時流に乗っていた。経営陣からの期待も大きく、中期経営計画の一端を担うプロジェクトだった。

わたし自身も、大々的に発表されて社外からも注目を集めるプロジェクトへの参加に期待を膨らませていた。わたしはプロジェクトの途中から参加したのだが、その時点で技術部門の設計や開発、人事部門の定型業務を効率化するためのシステムをすでに構築済みだった。利用を開始して、具体的な効果が上がり始める時期である。

だが参加してすぐに見えてきたのは、華々しい発表とはかけ離れたプロジェクトの現実だった。特に問題だと思ったのは、（本書で説明した）組織受入態勢をないがしろにしてシステムで効率化する対象業務を選定していたこと。それなのに導入のフォローを全然していなかったことだ。

開発したシステムは実際には、「技術担当者がこのツールを利用して進める案件と手作業が残る案件を判別する必要がある」「ツールを利用する案件の中でも、ツールだけで完結する部分と手作業で補う部分の把握が必要」など、活用にかなりの注意が必要だった（組織受入態勢が低い機能）。

だがユーザーに使ってもらうための説明が不十分だったので、現場の方は「使う機会がなかなか恵まれなくてねー」「利用する担当者がこういったツールに慣れていなくてねー」といろいろ理由をつけて、利用を避けていた。

途中からの参加とはいえ、わたしもこの状況をなんとか改善しようと「こういう案件なら活用できるでしょ」「1つでいいから使ってみて。ほら効果あったでしょ」と、普及活動を行っていった。だがなかなか現場の熱は高まらない。そもそもこのシステムは彼らが望んで作ったわけではないのだから、当然かもしれない。

こうして当初発表していたほどはツール導入による改善効果は上がりそうになかったが、「○○時間の業務効率化！」と発表してしまった以上は引き下がれない。「経営目標必達！」を理由に、導入効果の上積みに奔走することなった。

つまり「ムダをなくして業務を良くする」という観点でなく、「なんでもいいからこのツールを適用できる箇所を探す」というプロジェクトになってしまったのだ。例えば、開発が大変な割に効果が低いのは分かっているので見送っていた領域も「適用できるのだから、この際作るしかない」と開発をすすめることになった。

ツールが適用できる部分をもう一度探すためのヒアリング会も全国で行った。本当は「ムダ業務をなくす」という観点だと、伝書鳩みたいなコミュニケーションをなくすとか、設計変更のやり方を標準化するなど、もっと効果的な方法もあった。だがあくまでツール導入が目的になってしまっていたので、それらに着手することはなかった。

効率化は二の次という、そうした姿勢は現場の方々も感じていて、説明会や開発にもだんだん協力的でなくなった。もちろんプロジェクトメンバーも冷ややかな目で見られるようになっていった。経営陣肝いりのプロジェクトなのに・・。

こういう経験があるので、この本で当たり前のこととされている方法論が、どれだけプロジェクト、ひいてはその会社全体に有効かを認識できた。Whyから考える重要性、システム機能の優先順位付け、現場の巻き込みなどはすべて、こういう事態を防ぐためにあるのだ・・と身に沁みてわかった。

そして、わたしがあの経験から得たもう一つの教訓は「プロジェクトの基本を無視してシステムを作ってしまうと、完成後にいくら現場に懇願しても無力だ」である。

カネと労力を使っても、使われないシステム、使えないシステムは最悪だ。誰も幸せにならない。システムは企業活動をより良くし、よりよい会社をつくるためにあるはずだ。

ケンブリッジに入社してからもこの経験が自分の中にくすぶっており、ケンブリッジでこれまで学んだこと、やってきたことをまとめたいと思った。私が経験したような悲しいプロジェクトを一つでも減らすために。この本に記載したことを読者が実践することで、少しでも幸せになるプロジェクトが増えるよう心から祈っている。