こんにちは。
犯人はヤス。でお馴染みのBizpoko編集長の河上泰之です。
今回の記事は、DX推進をさせるための組織づくりについてです。
目的学にもとづき、DXを実現するための「組織のあり方」について語ります。
目的学は「目に見えている手段から目的を逆算して、別の手段を検討・提案する」学問で、システムズエンジニアリングから派生しています。
目的学をビジネスで使うと、目的が整理されきっているので、目的の要否の判断が最速でできる上、目的は合意するけど方法論が違う、というように議論をしやすくなります。編集長ヤス。が勝手に始めた学問ですが、便利なので使ってみてください。
さて話をもとにもどしましょう。
DXを実現するために必要な”組織”は、「ループを回し学習できる組織」です。
これまで日本人は、PCDAやアジャイルを取り入れようとしてきましたが、これですらうまく行きませんでした。なぜなのか・・・。
本投稿では、ヒトが行動する構造を紐解きながら、DX推進をさせるための組織づくりを解説していきます。
ちなみに、ITの知識なんていらない、というのが組織づくりの裏テーマです。
あと、書きながら適当に計算したのですが、ここで書いた組織づくりのため研修を作ると、法人単位で8万円/月のサブスクで、1000社に売り、年商9.6億円のビジネスがすぐにできます。
コストは最初に研修コンテンツを作り、撮影編集する部分で3000万円ぐらいでしょう。
自分で、国会図書館で情報を仕入れてコンテンツを作り、撮影もiPhoneでし、編集もするのならキャッシュアウトは交通費とランチ代で10万円ぐらいでしょう。
研修会社は、組織が成長するとクビになるビジネスモデルですが、このアイディアはデジタルベースで作ったコンテンツを、安く大量にデリバリーすることを前提としているため、結構儲かると思います。
さて、前置きが長くなったのですが、そろそろ始めたいと思います。
それでは、スタートです。
もくじ
人や組織が判断をするとは何か？
郡山 内閣危機管理官「総理。市街地での作戦なので、老人や病人等が残っている可能性があります。」
大河内 内閣総理大臣「だとしたら、現場を見ないことには判断しかねるだろう。」
赤坂 補佐官（国家安全保障担当）「現状では、国民の生命、及び私有財産への損害もやむを得ないと考えます。」
東 内閣官房長官「総理。ここは苦しいところですが、承認のご決断を。」
大河内 内閣総理大臣「・・・・・・わかった。」
（シン・ゴジラ@2016 TOHO）
「現実 対 虚構」をテーマに掲げた映画 、シン・ゴジラでの一場面だ。映画という虚構の中では、大河内総理は現地を見に行くことなく、自衛隊によるゴジラの駆除を許可した。
現実では、3.11の東日本大震災時に、当時の菅総理は原子力発電所を直接視察に行った。
9.11の米国へのテロ行為の際は、当時のブッシュ大統領が小学校訪問中に第一報が伝えられ思わず固まった姿が、のちに報道された。
組織から情報が上がり、トップがそれに基づいて判断する。これは簡単なことではない。
組織運営で行われていることは、限られた時間の中で集められるだけの情報を集め、伝えられた側はそれを正しいものとして判断を下し、その判断に基づき組織が動く。
組織の大きい、小さいに関係なく、必ずこの構造で動いている。
そしてその構造、1人の人間でも変わらない。例えば、自動車の運転は「認知・判断・操作」を永遠に繰り返す。視覚や聴覚を使い情報を集め、判断し、ブレーキを踏んだりハンドルを切るのだ。
ヒトは、欲しいものは目の前に出されるまでわからない生き物
ヒトや組織は、情報を集め、判断し、行動する。当たり前だが、忘れてしまいがちなことを思い出していただいた。
徐々に視点をDXや新規事業に目を向けていきたい。
DXは、奈良県三宅町の行政向けにも語ったのだけれど、経済産業省の定義を一言でいえば、金儲けをしてください、の一言に尽きる。
主語を事業者にすれば、金を儲けるために、お客様に新商品や新サービスを買ってもらわなければならない。
さらに、主語を一人のお客さまに変えて購買行動を考えると、
認知：商品やサービスを提示され（情報収集）
判断：買うか、断るか決め
行動：口と体を動かす
となる。
そう、ヒトは、その構造上、欲しいものは目の前に出されるまでわからない生き物なのだ。
「認知」がなければ、判断はできない。また、曖昧な認知であれば、曖昧な判断になる。
この構造が、冒頭に書いた大河内総理の「だとしたら、現場を見ないことには判断しかねるだろう。」という言葉が、映画の中の発言とは思えない重みを持つ理由だ。
本当かと、疑問に思う感覚もよくわかる。
少し記憶を探ってほしいのだが、なんの予定もなくぶらりと買い物にでて、お店を見て回るうちに、出かける前に思いもしなかった物を買い、ホクホクしながら帰ったことが1回はあるだろう。
あれだ。あの感覚が「目の前に出されないと欲しい物がわからない」ということだ。
逆に考えると、目の前に出されると、欲しいか、要らないかはこの上なく明確に語れるようになる。ヒトとはそういういきものなのだ。
そして、会社組織は、ヒトの集合でできている。
日本中のビジネスを席巻する「ループ」
ヒトは、欲しいものは目の前に出されるまでわからない生き物だと説明したが、この原理に基づくループが日本中のビジネス界を席巻してる。
DXやITでは、アジャイル。
新規事業では、デザイン思考。
事業経営では、PDCA、OODA。
場面や目的により単語は異なるが、全てに共通するものは「ループ」だ。実行→情報収集→判断→実行・・・というように永遠にループを繰り返しながら進める、ということだ。
アジャイルを例に、なぜループが出てきたのかを説明する。
アジャイルはシステム開発の手法の1つで、最近流行りのやり方だ。旧来のシステム開発では、何を作るのか要件を確定させ、作るための設計を固くやり、パーツを作り、組み合わせていく・・・というようにステップを区切り、順番に行っていた。旧来式のステップを順番に進めるやり方をウォーターフォールと呼称する。
編集長ヤス。はIBM時代に、日本を代表する航空会社の基幹システムのクラウド化に関わっていたことがある。その現場はまさにウォーターフォールで動いていた。
そこでは、例えば「XX月XX日までに要件を確定させます。現場の方は2週間前までに、業務で必要なことを整理して、IT企画部へ提出してください。受け取った内容は精査のうえ、改めてお話を伺いますのでお時間を・・・」というようなやりとりをしていた。
そう期限を区切り、要件：作って欲しいのは何かを決めて、次のステップに進むのだ。
システム開発を経験したことがある人は、そうだよねーとなる流れだと思う。経験していない方は、え？と思わないだろうか。「ヒトは、欲しいものは目の前に出されるまでわからない生き物」という原理はどこにいったのか、疑問ではないだろうか。
そうなのだ。結局開発するものの、実に開発した60%の機能は使わないという、無駄が大量に発生していた。
そして人類は原理に気がつき、新しく誕生した進め方がアジャイル開発なのだ。
Bizpokoの記事：トヨタの新規事業は、なぜパッとしないのかでも書いたが、要件定義の難しさを示すこの画像を見ておこう。
↓これはシステム開発界隈で散々笑った画像だが、システム開発は以下のようなことが本当によく起こる。
最も注目すべきは、左上「顧客が説明した要件」と右下「顧客が本当に必要だったもの」だ。顧客本人すらも、必要なものがわかっていない。これがヒトの限界であり、システム開発がウォーターフォールから、アジャイルに変化してきた理由でもある。
問題はここからだ。
システム開発の現場で、”人類が“気がついてしまった人間の原理「ヒトは、欲しいものは目の前に出されるまでわからない生き物」。
アジャイルに限らず、デザイン思考、PDCA、OODAを通じて、「ループを回すことで現実を認識し、状況から学習し、判断を変え、行動を変える」という基本行動原則は普及していく。
PDCAが「爆速PDCA」とか、さらに早くやる「OODA」と名前を変えたように、手法を売りたい研修屋や、コンサルによって名前はどんどん変わっていく。アジャイルや、デザイン思考も、名前が変わることはあるだろう。
しかし、「認知・判断・行動」の原理が変わらない限りは、「ヒトは、欲しいものは目の前に出されるまでわからない生き物」であることも変わらない。ということは、ループ形式で物事を進めるというやり方が、逆戻りする可能性はほぼないということだ。
一瞬だけ、ループがうまく回せない企業を見てみよう。新しいサービスや商品を考案したときのことを事例として書くが、業務改革案を提案した時も同様のことが起きているだろう。
事業会社：アイディアを出す。検証として顧客にぶつけてみる
↓
顧客：認識し、判断し、買う or 買わないを返答する
↓
事業会社：返答を受け取り、経営会議にかける
この流れの中で、事業担当者は「うちの役員はまったくものがわらない。馬鹿野郎しかない」と怒る。
何が起きているのだろうか。次の章で新しい時代に組織に求められる能力を紐解いていく。
ループ時代に求められるのは、「組織として学習できる」能力
いきなり企業、組織でのDXや事業開発を例にしても複雑性が高まるので、一人の人間が、誰かと食事場所を探すときことを考えてみよう。
Aさん：ねーねー。ランチ行こうよ。
Bさん：いいよ。どこいく？
Aさん：近所のイタリアンは？
Bさん：うーん。いいよ。（ちょっと困った顔）
Aさん：ん。他にする？その隣の、おにぎり屋さんは？最近できたトコ
Bさん：あ！いいね。そうしよ！
ポイントは、「うーん。いいよ。（ちょっと困った顔）」を、Aさんの視覚が捉え、違ったかと判断し、別の店を提案したことだ。
個人ではこのように、相手が発するシグナルを見落とさずにすくいあげられる。一瞬顔が歪んだのを見てから、別の提案をするまでの時間は0.2秒ぐらいだろう。時間の長短は問題ではない。重要なことは「相手のシグナルを認知」「判断」「別の提案をする」という構造が備わっていて、機能していることだ。
そして何度もAさんがBさんが誘い合う中で、「相手のシグナルを認知」【学習】「判断」「別の提案」というように、「学び」が入ってくる。この学びにより、相手の欲しいものを”察する”ことができるようになり、提案の精度が高まる。
改めていうが、重要なことは『相手のシグナルを認知 → 学習 → 判断 → 別の提案』という構造を持つことだ。この構造のどこが欠けても、ダメ人間だと言われる。
認知できなければ、察しの悪いヤツ。
学習できなければ、またそれ？
判断が間違っていると、アホなやつ。
提案がなければ、身勝手。
ループ型でビジネスをせざるを得ない中で、この構造を持っているかどうかが、最も重要なポイントだ。個人・フリーランス・組織と何が主語になろうとも、必要であることは変わらない。人間の原理が変わらない限りは、この構造を持たないと、誰かが欲しいものをラッキーパンチ以外で当てることはできない。
主語の中で、この構造を持つことが一番難しいのは「組織」だ。
現場担当者が、ブチぎれる仕組みが見えてきたのではないだろうか。
認知、学習、判断、行動の一連の構造のどこかが崩壊しているから、現場でとってきた情報が生かされず、トンチンカンな反応になり、現場担当がブチっとなるのだ。
役員や社長がバカだから、学習できなかったり、判断を誤るのだろうか。
いいや、違う。
思い出してほしい。人間の原理をひっくり返した「逆に考えると、目の前に出されると、欲しいか、要らないかはこの上なく明確に語れるようになる」ということを。
つまり経営会議にまで「シグナル」が届いていないのだ。いくら目の網膜が相手のシグナルを捉えていても、視神経が途中で切れていたら、情報は脳に伝わらない。
そのような破綻はどうして起こるのか。これまで編集長ヤス。が見てきた中で破綻理由で多いのは、アンケートで顧客の反応を探ったり、調査会社に丸投げしてレポートを上げさせたり、3ヶ月に1回の報告といった間違った経営者の巻き込み方だ。調査会社にアンケートでの調査を依頼し、数ヶ月に1回の役員会に進捗を報告する、といった完全にアウトな企業も多い。
なぜアンケートはダメなのだろうか。
例えば、Bさんにアンケートでイタリアンについて聞いたら、どう回答しただろうか。
「イタリアンか、5段階評価なら、4点かな」そうして4に丸をつける。書くほどでもないと思い、自由回答欄には何も書かない。
こうしてAさんが受け取った「うーん。」と「ちょっと困った顔」から発せられる”シグナル”が落ちる。
調査会社がやる、座談会でもこういった機微は見落とされる。
そういうと、デプスインタビューならどうだ？！という反応が返ってくるが、デプスインタビューの場で聞かれるのは事前に用意したアイディアばかりだ。つまり、イタリアンについてしか聞かない。そこで、間違ってもアジア料理の「おにぎり」なんて聞けない。
それは調査会社が何について調べるのか、という範囲を事前に合意してしまっているからだ。なので、事前に想定したイタリアンや、範囲を広げたとしてもヨーロッパ大陸からは出てこれない。
こういう仕組みなので、調査会社やアンケートに頼ると「認知、学習、判断、行動」の構造のうち、「認知」が破綻し失敗する。そのため、DXや新規事業では社員自らが顧客と接して、お客さんが発するシグナルを見落とすことなく取らなければならない。
ただし、とってきた情報を意思決定者に伝えるのが、3ヶ月に1回では話にならない。なぜなら、当初イタリアンだと言っていたものを、ヨーロッパ大陸を越え海を渡った東洋の島国の、しかもおにぎりの方が良さそうだというぐらいの大転換は、もはやイタリアンが失敗だったと言っているようなものだ。実際に失敗なのだが。
この当初想定が失敗だった、と素直にいえる現場担当者はどれくらいいるだろうか。「3ヶ月の仕事は全部無駄でした〜。てへぺろ」と言えて許される会社があるのなら、編集長ヤス。は勤めたい。今すぐ、勤めたい。笑
失敗することは問題ではない。確率の問題なので、失敗しないということはありえない。問題は”期間”だ。3ヶ月や半年という期間がプレッシャーになり、機微情報が落ちるのだ。落ちた結果、認知がうまく行かずに、その後の学習や判断の全てを間違える。
DXでは組織も変容しよう、とよく言われるが、一番変わらなければいけないのは、経営陣だ。彼らが率先して、お客様先の現場にいき、実際に自分たちが売った商品を使うヒトから機微情報をとってくれば間違いが起こる可能性を減らせる。実際、オイシックスの高島社長はそれをやり、サービスを大成功させている。
社長が聞き役、社員に響く「顧客の肉声」／オイシックス
「こんばんは。夜分遅くにお邪魔いたします」。2010年8月のとある夜。オイシックスの高島宏平代表取締役社長は、都内のマンションの一室を訪問した。モバイル事業部の岸本綾事業部長と、同部に配属された新入社員の石橋宏子氏が同行する。
部屋の主は同社の若い女性顧客。パソコンではなく、携帯電話などのモバイル機器で注文する顧客の中からこの女性を任意抽出し、自宅での1時間程度のインタビューを依頼した。
DX担当役員や、新規事業担当役員は、椅子に座って報告書をたまに読むだけでは十分に仕事をしたとは言えない。
経営陣には耳に痛いことだろうが、ヒトの原理を踏まえて、組織での失敗を考えるとこういう結論に落ち着く。
事実はそうだとして、会議室から出たくない人や、会議室から出てきてくださいなんて口が裂けても言えない会社員もたくさんいることだろう。
そこで、本稿のお題「組織開発から始めるDX」という話になる。
MBAでは到底不可能な、組織開発のために必要な教育・研修
さてここで目的学に戻り、DXをやり切るための組織開発の目的を明確にしよう。
ここまで書いてきたことだが、DXを成功させるため組織開発は「ループを正しく回せるようになること」が目的であり、目的達成のための方法論として「認知、学習、判断、行動の一連の構造を組織に導入し、維持し続けること」が重要だ。
この目的の意義をここまで書いてきた。目的学的には、上記に整理した目的に共感できないのであれば、ここでじゃぁね、となってOKだ。ここで踵を返せば、使う時間は半分で済む。
ループを正しく回せるようになるために、まずループを選ぶ
まず、ここから見ていこう。
そもそもループには、デザイン思考、アジャイル、PDCA、爆速PDCA、OODA・・・と種類があることを見てきた。
なので、自社がこれから行おうとする内容に合わせて、まずはどの「ループ」にするのかを決めなければならない。
アプリケーションやシステムの範囲内のみで、何かを提供していきたいのなら、アジャイルを選択すれば良い。◯◯Payみたいなアプリだけでいいならアジャイルだ。
アプリ以外の体験も含めて作りたいのなら、デザイン思考になる。編集長ヤス。はデザイン思考を勧めている。検討可能な範囲が人間が登場するあらゆる問題と、ものすごく範囲が広いからだ。
企業運営全般を対象とするのなら、PDCA、爆速PDCA、OODAだ。
こうして目的から、手法を選択する。最初の選択はえいやで決めて良い。やってみて選択が違っていたのなら、改めて別のループを選択すれば良い。それもループを回すということの一部だ。
また、サービス全般の開発をし、その中で使うアプリも開発したいという場合は、デザイン思考とアジャイルを統合する必要がある。どんなサービスとして、顧客に提供する体験を考える部分はデザイン思考で導き出す。その体験の中で、必要なアプリケーションの機能や画面遷移を整理したら、アジャイル開発を進めローンチし、ユーザーの反応をみながらスプリントを回せばいい。
編集長ヤス。が支援している日本有数の損保会社は、まさにデザイン思考とアジャイルを合体させようとしている。（編集長ヤス。は、デザイン思考とアジャイルを合体させる部分の業務フローと、ゲート管理の基準策定と、実際のアイディアをデザイン思考で研ぐ部分を担当している）
導入する組織の範囲を決める
どのループにするのかを決めたら、次は誰までを育成対象の”組織”とするか、対象範囲を決める。
ここで日本企業がよく間違えるのだが、優秀な社員を単独か、もしくは複数名でMBAに行かせたり、シリコンバレーに送り込む。この手段は全くもって無意味だ。
なぜかというと、組織を育てないといけないからだ。
野球でもサッカーでもいいのだけれど、例えば、草野球チームで一番優秀なピッチャーを巨人軍で修行させて戻しても、確率論的に必ず敵軍はヒットを打つし、打たれたら守備陣は守りきれない。そして、誰が点数をとるのだろうか。
サッカーも同じで、フォワードだけ育てても、強いチームにはならない。
そして何よりも致命的なことは、2年程度学術機関で勉強させても、卒業生/修了生になるだけで、先生にはなれない。
なので、本人はスキルアップできるが、学んだ内容を他人に教え、できるように育成することはできない。それができるのなら、日本中に大学教授相当の人材が溢れているはずだけれど、そうなっていないことが示している。
だから、MBA程度ではだめなのだ。あれでは、全く足りない。
さて、単独で学ばせても帰ってきてチームメンバーは育てられない、かつチームが育たなければ仕事で結果が出せない。
そういう理由で、チーム：組織を育てる必要がある。そのチームには意思決定者たる社長・役員も入るし、実働部隊として新卒がいてもいい。とにかく範囲を決めることが重要だ。
範囲選定で、じゃぁ全社導入だ！とやってもいい。実際に編集長ヤス。はIBM Japan全体にデザイン思考を導入するために社内講師としても働き、戦略コンサルディング部門の担当役員から、新卒まで教えていた。
アクセンチュアも、全社員にデザイン思考を教えきったし、超大手石油元売り会社も、アクセンチュアに支援されて全社に展開している。
導入を成功させる魔法：「8割」と「問合せ先」
一部か、全社かは別として、まず範囲を区切る。範囲を区切った中に対して新しい知識を導入し、きちんと実装するには、最低8割の人間に叩き込む必要がある。5人中4人が新しいやり方で仕事をしよう、といえば、残り1人はなんとなくついていく、と言うのが感覚的にわかると思う。
こうやって導入する際には、問い合わせ先が必要だ。ITデバイスや新しいツールを導入したときに、使い方を問い合わせできる先のようなものだ。知識も道具の1つなので、座学で勉強してわからない部分があれば、問い合わせる先が必要となる。
ちなみに、研修会社の研修が実務で使えないのは、問い合わせ先がないからだ。
ロジカルシンキングの研修をさんざんやっても、組織としてきちんと使えないのは、研修後に実務で使うなかで疑問に思っても問い合わせ出来ず、都合の良いように解釈してしまうからだ。これは、学んだ本人が悪いのではない。本人の責任だというのであれば、ITツールを売る会社がサポートセンターを開設するわけがない。
学びは常に、守・破・離だ。守ができずに、ノリでやって成果が出るほど、世の中は甘くない。だからこそ、きちんと使えるようになるために、サポートセンター：問合せ先が必要なのだ。
現状の洗い出し
ビジネス上の目的を達成するために、どのループを使うのかを決め、導入する範囲を決めたら、次に行うのはその組織が「ループを正しく回せているのか」の評価だ。1回だけ回せればいいわけではなく、複数回、回してみて、打率を見る必要がある。
これは実際に回す必要はなく、うまくいった例、失敗した例を洗い出してみるだけでもいい。重要なのはここからだ。
ループを正しく回すための方法として「認知、学習、判断、行動の一連の構造を組織に導入し、維持し続けること」と書いたが、洗い出した過去の失敗事例では、この構造のどこで破綻したのかを見極める必要がある。
これはザ・ゴールで言い尽くされているが、こういった一連の構造の一番レベルが低い部分に、全体の生産性が固定されてしまうからだ。
そして、この一番弱い部分から、順番にスキルアップをしていく必要がある。そこで学ぶべきは、ITではない*。
(*ITがなぜ不要なのかは、一番最後に書いた。読み進めてほしい）
学ぶべきことの見つけ方
この作業は、手間はかかるがやることは難しくはない。認知、学習、判断、行動を細かく分解し、動作と勘所を整理し、現状ではどこが弱いのかを見ていくのだ。これを行うと、学ぶべきポイントが浮かび上がる。
整理の仕方を例示する。
例えば、編集長ヤス。の専門領域のデザイン思考(DT)における「認知」は、対象者にアイディアを見せて、インタビューをする。一言でインタビューといっても、話を聞きだし、それを文字に落とし、学習のためのインテリジェンスになるように研ぐ。（聞き出した内容は、インフォメーション。そこから学習や意思決定に役立つように精査・加工したものをインテリジェンスと呼ぶ）
インタビューで行うこと、気をつけることは下記のようなことだ。
- 適当に作ったアイディアを顧客候補であるインタビュー相手に見せる（テキトーではなく、適当）
- インタビュー相手に、「認知 – 判断 – 行動」をさせる。具体的には、アイディアを見せて、買うか、買わないかを聞き、そう答えた理由を深堀りしていく。
- 最初に見せたアイディアのダメな部分を変えた、新しいアイディアを瞬間的に適当に作り、感想を聞き価値観を深掘りしていく。
- インタビュー相手がそのアイディアを、どう使おうとしているのかを把握する。場面を特定し、周りの状況、いる人、インタビュー相手がその中で何をしていて、どうしようとしているのか。そこで、アイディアはどんな意味を持つのかを、映像として理解できるまで聞く。（まるで映画を見ているように頭に思い浮かんだら、頭に浮かんだ内容であっているかを確認する。自分で理解しただけでとどめてはダメで、相手に自分の理解があっているかを確認した方がより良い）
- このインタビュー時に、表情や言い淀みといった「シグナル」をきちんと拾いながら、相手が本当はどう思っているのかを聞き出す。インタビュー相手が日本人の場合、質問者に都合がいいように回答する悪癖がある。そのため、欲しくなくても欲しいと言ってしまう。そういう偏りがあるので、本当に金を払うつもりがあるのか、金額感を聞いたり、教えてもらった金額感と似た金額で実際に購入しているものを聞きそこで感じる便益と比較してもらうなどして、本当に購入する意思があるかを聞く。
- 聞き出した情報を、生々しい表現で書き残しておく。本当はチーム全員がインタビューを生でみられればいいが、インタビュー相手への心理的影響もあるのでそうはいかない。なので逐語録的にメモをし、相手が使った単語や接続詞をメモする。簡単に言えば、相手が話した内容をそのままタイプすればいい。ただし、やってみればわかるが、実はこれは多少の訓練が必要となる。人間には、相手の発言を自分の頭の中で都合よく編集するクセがあるので、その機能をOFFにするスイッチをつける必要がある。ただし、一般的には必要な部分のみ抜き出す議事録作成よりは遥かに楽だ。あえて書くが、議事録みたいに書いたらアウトだ。
- 生々しく記録を残したうち、学習に必要な”文脈”を切り出す。切り出したときには、単語や接続を勝手に変えない。
- 記録内容をもとにインタビュー結果をメンバーに伝え、学習する。伝える際には、インタビュー相手のことを生々しくフレッシュに伝える。干からびたゾンビみたいな情報を伝えても、正しく学習できない。
↑このように、動作と勘所を列挙していく。（上記はだらっと書いているが、ちゃんと研修を設計するときには、整理した方がいい）
さて、こんなことを、認知、学習、判断、行動の各ステップ対して行い、整理する。ざっと整理したのが下記だ。
- 認知：インタビュー力、聞いた内容を映像として頭に思い浮かべる想像力、瞬発的にアイディアを作る力、日本語での描写力
- 学習：仮説構築力、認知での検証結果を踏まえた新たな知見の発見力、発見(=学び）を組織に共有する日本語の単語力と文章力
- 判断：判断基準の構築力、決断のサイズを小さくする創意工夫力、決めた責任に向き合う力、かじりついてでも前に進む意志の力
- 行動：実働者によって行動が変わらないような明確な指示を出す力、期限までに行動しきる/行動させきるマネジメント能力、想定外事案勃発時の計画変更力
(上記、力、と書いたものは全て能力を意味する)
少し細かく書いたが、これを1人で全てできる必要はない。またこれらを学ぶときや、身につけるときは目的学が役に立つ。何の目的を達成するために、どんな知識が必要なのかを整理するだけで、「足し算」のように明確な知識に落とすことができる。
例えば、過去にインタビューをしたが、情報をうまく整理できなかったヒトもいるのではないだろうか。こういう場合に、目的学が役に立つ。
そもそもインタビューを行う目的は、話を聞いた相手が「目的とすることは何かを探す」ことだ。
この話をする際に、いつも自民党のハンコ議連の人の話を引用する。
彼らハンコ議連の国会議員は「ハンコは個人が承認した証明になる」と言い、直後に「ハンコは信頼できる人に貸して、代わりに押してもらうこともできる」と言う。これは大いなる矛盾だが、この矛盾を正しいこととして話すには、その人なりの得たい利益（目的、インサイトとも呼ぶ）がある。この二つの矛盾を両立させる”目的”を、その人の背景も含めて探す。これがインタビューをして、情報を整理してインテリジェンスを導く目的だ。
いずれにせよ、テクニックあるということは、自然にできる人もいるということだ。
先にも書いたが、これはチーム戦だ。全員が大谷翔平である必要はない。そもそも、ピッチャーがいてもキャッチャーがいなければ「投球」は成立しない。
そのため、範囲を特定した組織：チームで弱い部分を補強していけばいい。
研修は、絶対に動画で配信する
ここの章だけは、この内容をサービスとして提供したい研修会社に向けて書く。冒頭に年商9.6億円と書いたからには、提供する際の重要なポイントを書く責任がある。
この研修を提供するための、絶対的な条件、それは動画で配信するということだ。これは、コストカットという側面があることは認めるが、そういうピントのずれた事業者側の都合でビジネスをしても、お客さまは幸せにならない。端的にいえば、売れない。
動画で配信する理由は、特定の動作になりにくい高度な概念を組織全員で共通の認識を持つ、ためだ。例えば、同期3人に「論理的に物事を考えるってなに？」と聞いてみてほしい。3人とも微妙に違うことを答えるだろう。この違いが、組織で物事を考える時に、絶望的なまでに効率が悪くなる原因だ。
同じ3人に「足し算ってなに？」と聞けは、必ず同じ答えが返ってくるはずだ。この様に、特定の動作になり、個人から出力されるものが一定程度に収まることが、組織で仕事をする際の効率を高める。
では、なぜ動画でなければならないのか。
ただしく学んでもらうためには、高度な概念を伝えるために単語、接続詞をきちんと設計して文章を構築し、そのままにデリバリーする必要がある。デリバリーされた内容を、学習者が意図した通りに学べたかを検証し、学べていなければ修正する必要がある。
これを繰り返すことで、高度な概念をただしく伝えることができるコンテンツを作ることができる。
こうして作り上げたコンテンツを、人間がライブで話すとバグが生じる。人間は機械ではないので、話す時々で単語が変わったり、説明順序が入れ変わったり、接続詞が変わり学習者が受ける理解や印象が変わってしまう。これでは、設計して作り込んできた全てが台無しになる。だから、ライブではだめなのだ。もちろんライブの方がいい研修もあるが、今回の場合は不適切だ。
このように、細部に気を配り設計して構築した録画を配信すると、おそらく質問が出るだろう。先に書いたが、問合せ先の提供は必須だ。顧客により価値を出すためには、問合せが来るのを待つのではなく、積極的に不明点がないかを探しにいったり、実際に学習者が行動した結果を収集して、研修提供者側の意図した行動をしているかを確認する。
このようにして、デリバリーした研修が正しく機能しているのかを、問合せ先、という皮をかぶり情報収集することが重要だ。受講後のアンケートではだめだ。アンケートがダメな理由は既に説明したので、別の理由を説明する。
そもそも評価すべき点は”研修”が良いか悪いか、ではなく、ループを回せているかどうかだ。そのため、研修直後にアンケートをしても全く意味がない。
受講者から質問があった場合の対応は2つだ。
1つは質問への回答と、そのログを文字や動画で残し公開することだ。これにより、同じ質問が出た時の対応時間を極小化できる。質問者には過去ログを見てもらい、ダメなら即対応だ。
もう1つは、質問が出た部分のレクチャー動画を修正することだ。こうすることで、質問の出ないよりレベルの高い動画コンテンツを作れる。間違っても、現在のイケてない研修のように、何十年も前に出版された本を適当にサマリーして、そのまま何年も使い続けるようなことはしてはいけない。このビジネスの肝は、顧客にきちんと価値を出すことだからだ。
価値を出すとはどういうことか。
電気で考えるとわかりやすい。電気を契約してお金を払っているのに、スイッチを押した時々で電気が使えたり、使えなかったりしたらブチぎれるだろう。
では、なぜ研修ビジネスだけは、提供した学習内容が実務で使えなくても許されると思えるのだろうか。
最後に、特定の動作になりにくい高度な概念を例示しよう。
例えば「この問題を解決したいから、まず仮説をだそう」という場合。編集長ヤス。にはユルユルの指示にみえる。
この状況で想定される仮説には7種類ある。
1解くべき課題の仮説、2改善策の仮説、3解決策の仮説、4解消策の仮説、5改善策/6解決策/7解消策の別の実現手段の仮説
これのどれを考えたいのかが明確ではないため、緩い指示にみえるのだ。
改善策の仮説と、改善策の別の実現手段の仮説、この違いがわかりにくいと思うので補足する。
例えば荷物が重くて辛いという状況を改善しようとすると、「感じる荷物の重さを半分にする」が改善策になる。改善策の実現手段としては、2回に分けて運ぶ、誰かに半分持ってもらう、台車を使う、反重力装置を使う・・・などいくつも出てくる。これらのどれが、問題を解く上で最適なのかは、検証せずにはわからない。なので、全てが”仮説”だ。
この改善仮説を考えるときの頭の使い方と、別の実現手段を考える時とは似て非なるものだ。なので本当は、何を考えたいのかを明確にして、考える順序までを決めて取り組んだ方がいい。
もしくは、AさんはXXの仮説を、Bさんは・・・と仕事を割り振ると効率的だ。
さて、これを例えば役員一人だけが知っていて、チームが動くだろうか。チームメンバーに、「改善策の仮説と、その別の実現手段の仮説を考えてほしい」と言って、一発で理解してもらえるだろうか。
だから録画で、共通の認識を持つ組織/チームを育てることが必要なのだ。そしてそれができた組織や会社は圧倒的に強いし、そういった組織を作れる研修会社は圧倒的に買われる。
このようにして、「認知、学習、判断、行動」を組織として行えるようになり、維持し続けられる研修コンテンツが、アカウント無制限で法人単位で年間100万円ならバカみたいに安い。
人事系の人たちは横のネットワークが強力なため、500社導入はあっという間だろう。
維持することの重要性
視点を、学習側に戻そう。
これまで、組織として認知、学習、判断、行動ができるようになろうという話をしてきた。企業によっては、こういった構造が存在し、機能していた会社もあるはずだ。この構造、チェーンが切れてしまうのには理由がある。一番大きいものは、人事異動や退職だ。
編集長ヤス。は、ある大きな電力会社にデザイン思考を導入し、1つの支社の80名でデザイン思考のループを回せるようにしたことがある。中核となるファシリテーターを3名育成し、一緒に議論できる仲間を上から下まで育成した。その結果として、本社が考えた業務改革案以上のアイディアを現場組織で考案し、本社を逆説得してその地域の出向指令を劇的に変えたことがある。
その支社はその後、どうなっただろうか。
お察しの通り、チェーンは崩壊した。
原因は、通常の人事異動がそのまま発動し、育成したチームがバラバラになってしまったことだ。その支社は、業務改革のための特別実験部隊に指定されており、だからこそ180日と、数千万円をかけて80名を育成し、結果も残した。だが、人事異動を止めるという意思決定がされずに、逆戻りしてしまった。
この、人事異動を止められなかったことを非難することは簡単だ。問題は、なぜそんなことになったか、だ。
これは編集長ヤス。の推察だが、彼らは「ループを回す組織」に変化する過程で、ループを回せなかったために普段どおりに判断をしたのだ。
つまり、特別実験部隊が積み上げた実績＝デザイン思考を効果的に行うためにはチームが必要という事実を認知はしたが、それを学習できなかった。良さを認知するまではいくが、それが自社にとってどういう意味を持つのか仮説がなく、ふーんすごいね、で終わったのだ。
また過去に積み上げてきた、過去には成功してきた社内のルールを変更することは容易ではない。それを変更したがために、組織が崩壊し、停電したら会社が潰れる。だからこそ、ループを回し、この難しい意思決定をできるだけの情報を吸い上げ、学習し、方向性を決めなければならない。
簡単なことではないが、我々は、この失敗から学ばねばならない。学ばねば、倒産し歴史の闇に消えるのは、我々だ。
先に、人類は「ヒトは、欲しいものは目の前に出されるまでわからない生き物」という原理にぶち当たったという話をした。これに基づき、アジャイル、デザイン思考など高速でループを回しながら、物事を進めていく仕事のスタイルが登場した。
このような状況において、有利だったのは個人や小さなチーム、つまりベンチャーだ。個人では当たり前のように、認知、学習、判断、行動の一連の行動を行える。運転免許を持っている人は皆できる。
組織が大きくなればなるほど、この構造を内部に構築し、維持し続けることが困難になる。先の電力会社の例のように、組織として重要性を理解できず構築したチームを崩壊させてしまっては、ループを回し学習できる組織には変化できない。
繰り返すが、世界は既にループを回すことが前提の世界に変わってしまった。そのため、ループを回し学習できる組織に変化できなかった企業は、滅びる道しかない。早いか、遅いかだけだ。
だからこそ、低コストで、しかも同じ内容を、全く同じに教えてくれて、実行できるまで支援し続ける、新しい研修会社が必要にな李、売れるのだが。
ITの学習が不要な理由
最後に、この投稿のタイトルを回収しよう。
「組織開発から始めるDX： ITしか学ばない企業は滅びる」
ここまで書いてきた通り、学習できる構造「認知、学習、判断、行動」を持った組織を会社内部に作るか、もしくは会社全体として変化して、その状況を維持し続ける必要性を語ってきた。
だが、これまで語ってきた中では、AWSや、Python、機械学習といった言葉は出てこなかった。なぜ登場しなかったのか。
これを語るには、”ビジネス”に立ち返る必要がある。
例えば、新しく和食定食屋をオープンしようとしている、としよう。コロナで良い立地に空き店舗が出たとでも考えて欲しい。和食定食屋なので、ご飯を炊くための炊飯ジャーが必要になる。さて、あなたはその炊飯ジャーの制御コードを書きたいだろうか。
必要なことは、自らが行うビジネスに必要な炊飯ジャーを選び、使える社員を育てることだ。
別の例でもいい。
Uberの配達員になるために、アプリケーションを作れる必要があるだろうか。いいや、ない。アプリが使えればいい。むしろ、出前館やmenuといった他のサービスのうち、どれが一番効率的に稼げるかを知ることの方が重要だ。
このように、ビジネスをする上では、ITが使えればそれでいい。ITで何かを作る必要がある場合は、かなり限られている。IT技術を使うだけであれば、多くのツールが自分たちだけで利用できるように作られている。例えば、LINEのアカウント開設をお金を払って依頼する人は限られている。
これと同様に、ある程度のことはお金を払うことなく、Google検索で調べれば使い方がわかるようにできている。この使い方を調べる程度のことは、当然のこととして行うべきだ。これは、ITを学ぶ、とはいえない。
ではなぜ、今更日本企業が慌ててITを学んでいるのかというと、自分たちに必要な炊飯ジャーすらも選べないからだ。
ITの世界では、欲しいものが何かを明らかにすることを要件定義と呼ぶ。これができる事業会社は、日本にはほとんどない。そのためこれまでは、ITコンサルタントがその仕事を担ってきた。
こんなことをしているのは、日本ぐらいなものだ。普通は自分たちのビジネスに基づき、必要なITシステムの要件を自分たちで決め、作る部分を発注している。
ベンチャーはもはや、発注すらしない。必要なサービスだけを買っている。Gmailを使うようなものだ。ビジネスに必要なのはITサービスであり、全てのシステムやアプリを自分たちで全てを手組みすることではない。
ITについて、少し視点を変えて議論を深めよう。
今年初に、丸紅が自社のDX推進と外販を目指した戦略子会社を作った。その丸紅の戦略子会社を、丸紅側からコントロールしていた知人からの指名で、編集長ヤス。はシステム開発にデザイン思考を導入する概念を教えて欲しいといわれレクチャーした。
彼らはシステム開発をする会社なのに、なぜデザイン思考を仕入れたかったのか。
理由は明白で、「ビジネスとして、何をすれば金になるのか」これが決まらなければ、必要なシステムやアプリがわからないからだ。
例えば、先に和食定食屋と書いたが、本当に和食定食屋は金になるのだろうか。
同じ和のジャンルの中でも、「大盛りうに丼屋」にしたほうがいいかもしれない。席数は何席だろうか。10席？それとも50席だろうか。席数が決まれば、1時間あたりの回転数を想定し1人前の米の量を決めると、必要な炊飯ジャーを決められる。このようにビジネスとして何をするのかが決まらなければ、必要な道具は決まらない。
間違っても、炊飯ジャーを作れるようになったら、じゃぁウニ丼屋を開こう、という順番で物事は考えられない。炊飯ジャーを作れるようになったら、そこで突き当たる悩みは「お米が炊けるようになったけど、何屋をやろう。牛丼？カレー？和食？寿司？・・・」だ。ビジネスで迷子になるだけだ。
丸紅本体もデザイン思考を取り入れようともがいている。その流れにのり、戦略子会社でもデザイン思考による要件定義にもとづくシステム開発のやり方を、自社業務として設計する必要があったのだ。
IT技術を知っていれば、売れるサービスが作れるかというと、決してそんなことはない。
編集長ヤス。が勤めていたIBMには、機械学習の専門家がいる。もちろん、他にもクラウドの専門家やアプリの専門家もいる。では、IBMはサービスをガンガン作って売っているかというと、そういうわけではない。そもそも、こんなビジネスを作りたい！！という依頼がなければ動けないのだ。
料理屋も、レシピを知らねば作れない料理もあるだろう。だがそれば、少なくともどんなお店を開くのかを決めてからレシピを整え、作るための手技を身につけるべきだ。何も決めずに、とりあえず揚げ物の温度管理技術を身につけても、なんの意味もない。
重要なので繰り返すが、目的も定まらないうちにITの勉強しても、DXの成功に直結するわけではない。あくまでも、儲けるためのビジネス案があり、そのビジネス案での儲けを加速させるためにITをうまく活用しなければならない。
「ヒトは、欲しいものは目の前に出されるまでわからない生き物」この原理に基づけば、売れるビジネス案を探すためにもループを回すことが必要だ。当初想定案で完璧にうまくいくほど、世の中は甘くない。だからこそ、ループを回すのだ。
そこで、本稿ではループを回せる組織になり議論できるよう、組織開発を推奨し、その進め方を書いてきた。くどいが、必要なことは、組織の中に「認知、学習、判断、実行」の一連のプロセスを導入して、組織として実行できるようになることだ。
この構造ができループを回せるようになれば、ビジネスアイディアを上層部にあげたときに「現場を見ないことには判断しかねるだろう。」と言われることもなくなる。
この売れるビジネス案を作る部分がデザイン思考なのだが、これを使うと、お金の匂いのするアイディアに辿り着けるようになる。便利なので、ウニ屋の成長シリーズか、ビジポコ相談室を覗いていただきたい。
組織開発から始めるDX： ITしか学ばない企業は滅びる。
１社でも多くの企業が、ループを回せる組織になることを願っている。
========
最後まで読んでいただき、ありがとうございます。そんな素敵なあなたに、1つお願いがあります。
この投稿を読んで面白かった！役に立った！という方は、ぜひコメントをつけてSNSでシェアをしてください。そうやって拡散してもらえると、”困っていることにすら気がついていない人”にまで届きます。
Googleは困っていて検索しないと効果が出ません。つまり、困っていることにすら気がつかない人はずっと不幸なままになってしまう。この、Googleの限界を越えるには、あなたの協力が必要です。
ぜひぜひ、よろしくお願いします！！
ではまた、次の投稿でお会いしましょう。またね！
編集長ヤス。