オルタナティブ・ブログ > プロジェクトマジック >

あるいはファシリテーションが得意なコンサルタントによるノウハウとか失敗とか教訓とか

なぜ「システムを作る技術」ではなく「作らせる技術」についての本が世の中に必要なのか

»

3年くらいかけて、ようやく「システムを作らせる技術」を出版することができた。
今週7/22が発売日だ。せっかくのオリンピック休暇なので、涼しいカフェでも行って読書に勤しんでみませんか!

僕は毎回違うテーマ、違う切り口で本を書いているのだが、仕事をしながら書いているので、それほどハイペースではない。だから毎回、執筆プロジェクトに着手する時には「本当にこれを書きたいのか?」「自分たちしか書けない本なのか?」「世の中にどういう貢献ができるのか?」をかなり考えて、テーマを選ぶ。
以下にこの本の「はじめに」を転載する。これを読めば、上記の問いへの解になっているだろう。
※本書を読んで気に入り、「他の人にも勧めたいな」と思った人がいらしたら、まずは白川からの大感謝光線を一身に浴び、後にこの記事のURLをシェアしてみてください。

******************

★「システムを作る技術」ではなく「作らせる技術」についての本
不思議なことがある。
世の中にはシステム開発についての本が何百冊もあるが、その全てが「システムを作る技術」の本なのだ。もちろんITエンジニアと呼ばれる専門職はたくさんいて、彼ら彼女らは勉強熱心なので技術書のニーズは高い。作る技術についての本がたくさんあるのは不思議ではない。

だがビジネスパーソンの9割はシステムを作る人ではなく、作ってもらい、使う側だ。この作ってもらう側の人々が、作らせ方を学ぶ本が一切ないのはかなり不思議なことだ。

住宅建築と比べると、その異様さが際立つ。住宅の分野でも、大工さんや建築家向けの専門書は多く出版されている。同時に「望み通りの家を手に入れる方法」だの「建築家と家を作る」だの「良い工務店の選び方」といった、家を作ってもらう施主に向けた本も無数にある。

なのにシステムの世界では、作らせる方法についての本が皆無だ。そこでこの本を書くことにした。この本はシステムを作ってもらう人が身につけるべき技術、知っておくべきことを学ぶための本である。


★あなたに必要なのは「作らせる技術」
なぜあなたがシステムを作らせる技術について学ぶ必要があるのか、改めて考えてみよう。一言で言えば、「会社を変えたい、社会を変えたい、新しい事業を生み出したい」と思っているならば、システムを作る技術か、システムを作らせる技術のどちらかが必要だからだ。

今や、システムを作らずに新しい事業を創造することはできない。
今ある組織や業務を抜本的に変える際にも、システムに大幅に手を入れたり、ゼロから作り直す必要がある。だから「システムを作る技術」か「システムを作らせる技術」のどちらかを持たなければ、変革を起こせない。

私たち(著者2名が所属するケンブリッジ・テクノロジー・パートナーズ)が事業立ち上げを支援したベンチャー企業、GROOVE Xを例にとろう。

彼らはLOVOT(Love+Robot)という、ペットのような家族のような「人の代わりに仕事はしないロボット」を創っている。展示作品ではなく事業化が目標なので、ロボットの開発と並行して、LOVOTを届け、修理を受け付け、課金をして・・という一連の業務とシステムを、発売までに作り上げる必要があった。

LOVOTは1回売っておしまいのビジネスモデルではなく、末永くかわいがってもらい、末永くユーザーからお金をいただく課金モデル。だからユーザーとの関係についても、「飼い主が亡くなった時に、新しい飼い主に引き継ぐには?」のように、様々な想定シーンを考えることになる。

具体的には、「飼い主が亡くなったら新しい飼い主に何をしていただくか?」「GROOVE Xは会社としてどう対応するか?」といった、人間の行動を設計する必要がある。そして「飼い主データをどう引き継ぐか?」「月額利用料の請求先をスムーズに変更するためにどういうシステム機能が必要か?」のように、人間の業務を支えるシステムについても、同時に構想しなければならない。

やりたい業務が決まれば、欲しいシステム機能が見えてくる。逆に、作れそうなシステム機能が分かってくると、それに合わせた業務を設計できる。業務とシステムはコインの表と裏の関係で、分けて議論することはできない
これが「新しいビジネスを設計する」ということだ。

この時に「オレ、システムのことは全然わからないから詳しい人に任せるよ」という人は、ビジネスの立ち上げに全く貢献出来ない。新しい事業を創造したり、既存の業務を変革する際に、システムに目をつぶることは許されない時代なのだ。

あなたがスーパーマンであれば、ビジネスを一人で構想し、一人でプログラミングしてシステムを作ってしまうのが手っ取り早い。だが複雑で進歩の速いITを学び続け、その上でビジネスにも精通した変革人材になることは、相当高いハードルだ。

だからこそ、あなたが「会社を変えたい、社会を変えたい、新しい事業を生み出したい」と思っているならば、システムを自ら作れなくても、「システムを作らせる技術」を習得して欲しい。
具体的には、
・「こんなシステムを使ってこんなビジネスをやりたい」を構想し、
・「A機能とB機能、どちらを優先すべきか」を判断し、
・「これを作るのにいくらまで投資する価値があるか?」を見極め、
・作ってくれる人を探し出し、適切に依頼し、
・構築段階で沸き起こる様々な課題を解決
していかなければならない。

意外と盛りだくさんだ。でもこれができない限り、何も変えられないし、何かを生み出すこともできない世の中になった。
本書はそれらの「システムを作らせる技術」を体系立てて学ぶための本である。


★「作らせる技術」の欠如がビジネスを停滞させている
残念ながら、「システムを作らせる技術」の重要性はあまり認識されていないし、そのことが日本企業の大きな弱点となっている。
この本を書いている2020年のビジネス界で大きな話題となった、新型コロナにともなうリモートワーク対応と、DX(デジタル・トランスフォーメーション)への取り組みを例に考えてみよう。
コロナが広がり始めた時、リモートワーク(在宅勤務)への適応は、会社によって明暗が別れた。リモート会議システムや、インターネット上で共同作業をすすめるツールを速やかに整え、オフィスと変わらないレベルで在宅勤務ができるようになった会社もあった。一方で緊急事態宣言から何ヶ月たっても、出社せざるを得ない会社も多くあった。上司との相談やハンコを押す仕事が会社でなければできなかったからだ。

これは小さめのITプロジェクトをスピーディにやり遂げる組織力が試された事例だった。自社専用のシステムを作り込まなくてもよいので、プログラミング能力は必要ない。むしろ自社のビジネスに一番フィットする製品を選んだり、使い方のルールやガイドラインを決めるなど、「適切にITを使いこなす力」が勝負を分けた。

ビジネスを止めないために予定外の出費でも急いで投資を決断したり、社員がツールをスマートに使いこなすフットワークの良さも問われた。これらは広い意味で「システムを作らせる技術」の一部である。


かたやDXは「デジタルの力を使って、ビジネスを抜本的に変革しよう!」といった変革を指す。このこと自体は当然重要なのだが、バズワード(流行り言葉)になってしまっているのが実態だ。
DXの本質を理解していない社長が「我が社もとにかくDXに取り組め!」と号令をかけると、現場はそれに従わざるを得ない。
「社長はもっと最新技術を使った画期的なことを望んでいるはず」
「とりあえず企画書にDXって書けば決裁を通りやすくなるから・・」
みたいな社内忖度が起きまくれば、本来やるべき地に足をつけた変革が遠のいてしまう。

わたし達も顧客企業とDXに取り組むことが多いが、それはあくまで「会社や顧客にとって、ベストな変革とはなにか?を考え尽くしたら、結果としてDXと呼ばれるような変革になっていた」というストーリーだ。
いまの世の中、ビジネスを抜本的に良くしようと思えば、システムを活用するのは当然だ。DXなどと流行り言葉に踊らされていないで、1つ1つの変革プロジェクトを成功させていくしかない。
だが問題は、DXをはじめとして、ITプロジェクトが成功しないことだ。

プロジェクトの失敗は企業の外に伝わらない。だが、実際にはたくさん起きている。日経コンピュータ誌の調査では、3年を超えるような大規模プロジェクトに限ると、成功率は16%しかない(日経コンピュータ2018/3/1号より)。

なぜこんなに成功しないのか。わたし達が見聞きした、よくある失敗原因を挙げてみよう。

失敗原因1)ゴールがバラバラ
プロジェクトの関係者ごとに、なんのためにシステムを作るのか、認識がバラバラ。目指すゴールが違うのだから、プロジェクトを進めていくと当然迷走する。

失敗原因2)システムをITエンジニアに丸投げ
本書で繰り返し述べるように、経営者や業務担当者がシステム構築に関わらないとプロジェクトは必ず失敗する。なぜならシステムは業務のためにつくるのであり、ひいては経営のためだからだ。

失敗原因3)システムを欲しがるが、業務を変えるつもりはない
新技術を使ったシステムを導入したら、仕事のやり方も変えなければ効率はあがらない。逆に「業務は現状のまま変えたくないが、便利な道具は欲しい」という要望に沿ってシステムを構築すると、構築コストは膨らみ、完成したとしても大きな成果は得られない。

失敗原因4)必要な機能がもれている
多額の投資をした割に必要な機能がない。代わりに誰も使わない機能がアレコレ用意されている。バカバカしい話だが、ほとんどの企業で起きている。この本の主要なテーマなので、後ほど詳しく説明する

失敗原因5)現場の声を聞きすぎてコストが膨らむ
システム構築にあたって経営者にインタビューすると、たいていは「現場の声を聞いて、使いやすいシステムを」と要望される。だが現場の声を聞きすぎると、投資額が膨らむ割に、ビジネスにとって役立たないシステムができる。これは(社内の評判とは裏腹に)失敗プロジェクトと言っていいはずだ。

失敗原因6)システムを作ってもらうベンダーやソリューションの選択に失敗
良い家を建てるためには良い大工に頼む必要があるように、良いシステムを作る際も、適した工法やITベンダーの選定が鍵となる。だが技術に詳しくない人が腕の良いベンダーを選ぶのは難題で、ここで躓くプロジェクトも多い。

失敗原因7)コントロールできない炎上プロジェクトとなる
構築を始めても中々前に進まない。それどころか、どれくらい作り終わったのか?いつ完成するのか?がよく分からない。そういった炎上プロジェクトは残念ながら大変多い。


システム構築に多少なりとも関わったことがあるならば、これらを見聞きしたことがあるに違いない。ズバリこうした失敗の当事者となった人もいるだろうし、こうした失敗に転がり落ちそうなところを必死でこらえた人もいるだろう。

実は「システムを作る人」に問題があって、こうした失敗が起こるケースは稀だ。ほとんどは「システムを作らせる人」、つまり本書を読んでいるあなたのような人が原因である。

例えば「失敗原因4)必要な機能がもれている」の場合。どんな業務のために、どんなシステム機能が必要かを語るのは、作る人ではなく作らせる人の責任である。システムを作る人はあくまでITのプロであって、ビジネスのプロではない。だからどんなシステムを作れば業務が良くなるのか分からない。

「失敗原因5)現場の声を聞きすぎてコストが膨らむ」についても同様だ。ある機能を作るのに1000万円かかる時、それを作る価値があるかどうかは、ビジネス上の価値で決まる。1000万円と見積もるのは作る人の責任だが、見積を見て要/不要を判断するのは作らせる人だ。
「システムを作らせる技術」が重要で、この技術がないとビジネスが頓挫したり停滞してしまう理由はこうした事情なのだ。


★「作らせる技術」に出会った頃の話
この本のベースとなったアメリカ伝来の方法論にわたし(著者の1人白川)が出会ったのは20年前。本に書こうと思ってからも7年がたってしまった。
20年前、わたしは若きシステムエンジニアとして転職活動をしていた。その当時は「ユーザーさんが望むシステムをCoolに作ることは、結構出来るようになってきた」と、やや天狗になっていた。

そして同時に「でも、もっとユーザーさんとガチで議論するところからプロジェクトに関わりたい。例えばこのシステム、何のために作っているんだろうか?この機能は本当に必要なんだろうか?これによってビジネスはどう良くなるのだろうか?先日ユーザーから指示された変更だって、単なる彼の趣味じゃないのか?」などと悶々と考えてもいた。これが転職の動機だ。

転職活動をしていくうちにたまたまケンブリッジ・テクノロジー・パートナーズというコンサルティング会社を見つけ、なんとなく気に入って入社することにした。極寒のケンブリッジ(ボストンの隣町)で行われた新入社員研修では多くのカルチャーショックを感じたが、一番ガツンと来たのは、ケンブリッジ方法論の根幹である「システムを作らせる技術」だった。

それまでもシステムエンジニアとして、
・システムに求める機能をもれなく洗い出したい
・声が大きなユーザーさんの言いなりではなく、本当に役に立つ機能を作りたい
・作って終わりではなく、ビジネスとして成果を刈り取るところまで関わりたい
・ユーザーとエンジニアは対立関係ではなく、同志としてプロジェクトに参加したい
などと、理想を思い描いて自分で工夫を重ねていた。

だがケンブリッジでは、それらがすべて合理的な方法論として「こうすれば達成できるよ」と示されていたのだ。
「合理的な」というのは、単なる心構えではなく、具体的な方法が示され、しかも理屈で裏付けられていたことを指している。「確かにこのツールを使えば、抜け漏れのない機能洗い出しができるな」「この議論の進め方をすれば、納得度の高い意思決定ができるな」のように。
そしてもう一つの衝撃は、全てがビジネス目線だったことだ。エンジニアの美意識でもなく、ユーザーのわがままでもなく、上司の気まぐれでもない。「ビジネスを良くするために、どんなシステムを作るべきか?」を当たり前に追求する方法論だった。
わたしが前職で自分で試行錯誤しながら見つけてきたワークスタイルは、竹槍でB29を撃ち落とすみたいなものだったのかもしれない・・。

あの衝撃から20年経つ。わたし自身、この「システムを作らせる技術」の方法論を使って、多くのプロジェクトを成功させてきた。さらに、戦略立案、業務改革、人材育成・・など、より難易度の高いプロジェクトにも効果を出せるように、方法論を磨くことも手掛けてきた。
それらの新しく作った方法論は講演や本を通じて多くの方に教えてきたのだが、当の「システムを作らせる技術」だけは、これまで本として出版する機会がなかった。今回ようやく本にまとめられ、うれしく思う。
この本に書いたことを愚直にやっていけば、上記の失敗は避けられる。逆に言えば、これを愚直にやらないと、わたし達プロでも失敗する。実例やエピソードを豊富に添えて説明しているので、じっくりと読み込み、実戦で試しながら身につけてほしい。

*************
GROOVE Xさんとのプロジェクトについてもっと知りたい方は、ケンブリッジのサイトに事例記事を載せています。
https://www.ctp.co.jp/case_study/case399/

また「システムを作らせる技術」のZ章では、ベンチャーや新規事業立ち上げのように、不確実性が極めて高い状況でシステム構築をする、いわば応用編の方法を紹介しています。その事例として、この「はじめに」よりも詳しくGROOVE Xとのプロジェクトについて紹介しているので、気になる方は是非どうぞ。

*************執筆こぼれ話
ちなみに、今日転載した「はじめに」は、原稿を校正してもらった奥さんから、「長くてびっくりした」とコメントを書き込まれました。

はい、自覚してます。
冒頭に書いたように、かなり考えて本のテーマを決めるので、それをぶつけるとつい長くなっちゃうんですよね。

他にも同僚から「はじめに、が長いので、後半の「作らせる技術」に出会った頃の話は削ったほうがいい」とアドバイスもらっていて、迷いました。

でも結局はまるっと長いまま残した。「本のテーマが著者にどういう思い入れを持っているか?」というのは、少なくとも読者としての僕には大事だから。そしてどうせ分厚い本なのだから、このくらいの長さで飽きちゃうような人は買ってくれても読み通せないと思ったから。

実は次の本もテーマはだいたい決まっていて、2年も前のサイクリング中に、なぜか冒頭が僕のあたまに降臨したので路肩に自転車をとめてiPhoneのメモ帳に書き付けてありあます。そいうわけで次の本の「はじめに」もきっと長め。

Comment(0)