気づいても言わないコンサルタント

すべてのコンサルタントがそう振る舞うと申し上げるつもりはありませんが、少なくともわたしの場合は、顧客企業を視察して膨大な課題事項を発見した時に、そのすべてを一度に指摘することはほぼありません。意図的に、問題があることを「言わない」ことがあります。

通常、コンサルティングではその支援案件における達成目標や支援範囲を予め設定します(当社ではスコープと呼びます)。そのうえで顧客の現況を把握しに行くと、当然ではありますがスコープ外の課題にも気づくことが往々にしてあります。そういう場合は、スコープ外のことですので触れることはありません。

これは、契約上範囲外だから、というのが主な理由ですが、実は当社には、顧客の課題の全体像を客観的に捉えて分析整理する、という目的の調査サービスがあります。このサービスは調査分析による課題整理が目的ですので、スコープは対象企業の業務全体になることがあります。結果として、膨大な課題事項を発見することになるわけですが、その場合でも「言わない」課題事項を意図的につくることはあります。

もちろん、隠そうとしているわけでも、もったいぶっているわけでも、ありません。

外からやってきた人間に、会社の中をくまなく覗かれて、「あれもない、これもない、なにもできていない」などと言われたときに、その会社の責任者はどんなことを思うでしょうか。わたしが考えるに、大きく2つのパターンがあります。

ひとつは、言い訳の出来ない事態に直面した不安感や焦燥感にかられて、押しつぶされそうな気分をどうにかして振り払いたいというような気分になる。そういうとき、過去の所業の誤りを素直に認め、その先の振る舞い方を考えようとすることができる人は、比較的少数ではないでしょうか。それよりも、間違っていた事実に耐えられずに不機嫌になったり、場合によっては怒り出すような人のほうが、多いように思います。

もうひとつは、手の施しようがない事態を目の前にして圧倒され、茫然自失となってしまう。考えてもみなかったような問題点を次々と突き付けられて、途方に暮れてしまう。そういう気分になるとき、多くの人は思考が停止します。思考が停止すると、次に試みることはおよそ、課題を闇に葬り去ろうとするようなアクションです。現実逃避を試みる、見なかったことにしようとする、その場は納得したように見せて後々知らぬ存ぜぬで通す、等々。

いずれのパターンにしても、その企業にとって良い結果を生まない行動を創り出してしまう。わたしはそのように考えています。

課題を指摘するのなら、俎上にあげた課題は、時間をかけてでも必ず解決してもらいたい。そのためにはどう対応していくべきで、その対応策はその企業のポテンシャルから見て現実的かどうか。そうしたシナリオを想定しようとすると、提示すべき課題事項は自ずと絞られるように思います。優先して考えるべき課題のセットだけ(それでもたくさんありますが)を相手に伝えて、それ以外は「言わない」選択をします。

「言わない」ことが裏目に出るリスクは、当然にあります。触れなかった課題のほうが、まず解決すべきとして優先的に触れた課題よりも、リスクが先に顕在化してしまうかもしれません。その場合は、わたしの選択眼が的確ではなかったという結果になります。

その失敗を避ける簡単な方法は「気が付いたすべての課題に言及しておく」ことでしょうが、それはこちらの体面と都合しか考えていない愚策だと、わたしは考えます。ですので、コンサルティング案件に対応するたび、課題を「言わない」戦略は常に念頭に置いています。

同じような考え方をするコンサルタントや外部支援者は、きっとほかにもいるだろうと思います。ですから、経営者のみなさんは、「専門家に委ねて課題を指摘してもらい、解決策も練ることができたから安心」などと思わないほうがよいと、わたしは思います。彼らがあなたに「言っていない課題」が存在している可能性があるからです。隠さず全部言えと要求されても、わたしならば、言うべき時が来ない限り、一度言わないと決めた課題は、条件が揃うまで決して言わないでしょう。

デジタル化したいなら、まず「因数分解」

わたしがお客さまの前でよく使う言葉で、通じないことが多いもののひとつが、「因数分解」です。

しかし、この因数分解、デジタル化においては極めて重要なスキルだとわたしは思っていますので、めげずに使っています。

ここでいう「因数」というのは、かみ砕いた言い方になっているかどうか自信はありませんが、対象になるものを構成する要素、というような意味です。物事の本質を見極め、課題解決の糸口を見つけ、課題を突破する新しい方法論や構想を構築しようとするとき、ぼやっとして捉えられている対象物を、根幹を構成している要素にどうにかして分解し骨組みを見極めることが必要になります。それを「因数分解する」と言っています。

因数分解する試みというのは、その対象に対する一種の研究のようなものであり、またある意味では、その対象の全体像を知り尽くそうとするこだわりが表れることではないかと思います。

例えば、ある食品製造業の場合。品質にこだわるその会社が、自分たちが納得のいく商品だけを作りたいと考えたら、どうするでしょうか。

製品出荷前に官能検査をするのは当然でしょうが、その検査が属人的では、テイスティングする専任の担当者の「勘」がすべてになってしまいます。その勘がどのように機能しているのか見えるようにしなければ、社内で納得感が共有されませんし、その人以外に優れたテイスターも育ちません。

そこで、検査に合格となる味の要素を因数分解するわけです。因数分解するなら、科学的に測定できる要素に分解したいものです。成分を分析し、合格品に備わる特性を導き出します。おそらくこうした調査は、専門機関などに依頼すればそれほど難しくはないでしょう。

本当の問題は、ここからです。では、そうした合格品を製造するには、どういう条件がそろっている必要があるのか。それがわかれば、安定的に合格品を製造することができます。合格品を生み出す特性が生産過程でどのように生み出されるのかを調べ、その要素をまた因数分解します。食品ならば、水分量、原材料の配合や重量、調合や加工のタイミング、場合によっては工場内の室温や湿度も影響するかもしれません。

その因数分解に成功できれば、それらの要素をモニターする仕組みをつくりこむという道筋が見えてきます。因数分解できているのなら、一連の仕組みを仕様として表現するのは、比較的容易です。品質のつくり込みに必要な要素が管理できるなら、品質検査で合格できなかった場合は原因を分析し、その対応策を製造現場に数字ですばやくフィードバックすることができるでしょう。現場はその数字を基に、即座に改善対応が取れることになります。勘に頼った改善対応よりも、はるかに精度の高い改善が、誰でもすぐに打てるようになります。

このようにして仕組みが完成して稼働すれば、それはまさしくシステムです。

先月のコラムでも、データは自分で作らなければ存在しないと述べました。データを生み出すために必要なスキルが、上記のような「因数分解」なのです。

仮に、既に使えそうなデータがすでにある場合でも、そのままでは用を満たさないことが往々にして起こります。そうした時にも「因数分解」が必要になります。

例えば、建設業では最近BIMを活用するケースが増えています。BIMによれば、建設物の設計データが余すところなく保存されており、それが3Dモデルとして利用可能です。これを用いれば完成後の建築物の施設管理にも使えそうだ、という発想が容易にできます。

しかし、実際はそうは簡単に行きません。設計時に構成したデータと、施設管理に使いたいデータでは、中身が大きく異なるのです。設計データは、主に建物の構造に着目したデータセットになっているわけですが、施設管理ではそんな細かい寸法などが知りたいわけではありません。一方で、施設内で使われている設備や装備のメーカーや品番といった保守に必要な情報は細かく知りたいわけです。

では、施設管理にはどんな情報が必要なのか。それを因数分解する必要があります。そのうえで、持ち合わせているデータがどのくらい流用できるか、流用できない情報はどこから引っ張ってくるか、という取組みができなければいけません。それがうまく行かなければ、大量にあるけれど用はなさないデータが壁になって、施設管理はままならないでしょう。

このコラムでは端的な話しかできないのですが、業務改革やデジタル化の取組みにおいて「因数分解」が大事であることが、少しでもご理解いただければ嬉しいです。引き続き、この言葉は多用させていただこうと思っています。

DXの前に、まずアナログからはじめよ

業務のやり方が固まっていないのなら、DXと言う前に、まずはアナログから始めるのが無難でしょう。

デジタル化を実現するツールやソフトウェアというのは、良くも悪くも「出来上がって」います。いったん使い始めると、そのツールによって仕事のやり方は事実上規定されてしまうところがあります。場合によっては、そうしたツールによって組織に合わないやり方を強制されることもあります。

ツールやソフトウェアの選定が上手くない会社に限って、「ウチには合っていないな」と気付くのは、たいていはそれを使い始めてからです。

情報システムというのはその会社の文化をも決めてしまうもの、と言っても決して大げさではありません。そうした側面があることを念頭に置いて、ツールやソフトウェアの選定は慎重に、かつロジカルに行うべきです。経営者が理解すべきITというのは、技術知識では必ずしもなく、こうした大局的な視点での理解であると考えれば間違いはありません。

アナログとは極端な、と思われるかもしれません。もちろん、アナログのままにしてデジタル化しなくてよい、という意味ではありません。仕事のしかたを固めるために、まずはアナログベースで試行錯誤する、ということを意味しています。

アナログなやり方というのは、大規模化することや複雑な処理をこなすことには向いていません。一方で、小さく取り組むぶんには、むしろアナログのほうが、人間の裁量に任せて自由に試行錯誤ができます。最悪、全部やめて最初からやり直すことも躊躇しなくてよいのです。

どうあるべきなのかをまずアナログベースで追ってみて、自社なりの業務のあり方を固めたところで、デジタルのアイデアや能力を取り入れる。こうした順番のほうが、DXを実現していくにあたっては遠回りなようで確実だろうと思います。

最適な業務のアウトプットを出す方法論というのは、中堅中小企業だけでなく、案外大企業でも部門によっては、考え抜かれていないことがよくあるものです。DXというキーワードを契機にして、今の仕事のやり方そのものを見直すことから始めてはいかがでしょうか。

「しくみ」と「マニュアル」、全然ちがいます

わたしはよく、ビジネスのしくみをデザインすることの意義を強調するのですが、時として、仕組み化することとマニュアル化することを同一のものと捉えている方を見かけることがあります。

これらはまったく異質のものであるばかりか、危険な誤解とさえ感じます。

ビジネスのしくみは、単純化すると、「インプット」「プロセス」「アウトプット」のまとまりが、連鎖してつながっている構造をしています。

ビジネスのしくみをデザインすることとは、つまり、その事業を実行する一連の流れを要素に分解し、要素ごとにどのような「インプット」をもって「プロセス」を実行し、どのような「アウトプット」を出して終了するかを決め、その要素の連続をどのように組み合わせて、最終的な価値を創出するのか、を考えることです。

そのデザインを司るのは、その事業を全体俯瞰する立場にある経営者や事業責任者です。デザインにあたっては、要素を分解し、要素に対して「インプット」「アウトプット」を決めながら、「プロセス」にはその実行の目的を定義します。こうして決めた一連の要素の連鎖を、全体俯瞰しながら管理していくことで、出したい事業価値を生み出すしくみを確実にするのです。

全体俯瞰して事業をリードすることが重要なのは言うまでもありませんが、そうするには、事業の全体が見えるようにデザインしなければなりません。それもせずに、全体が見えている気になって采配を振るうリーダーの下では、危険な失敗を犯しかねません。

一方、現場の実務のうえでは、誰でも正確にまたは迅速に「プロセス」を実施するために、「プロセス」を手順化して整理しておくことがあります。これが、いわゆる「マニュアル化する」ということです。

このように、仕組み化することとマニュアル化することは、次元が異なる行為です。

マニュアル化が求められるケースは、現実には大いにあるでしょう。ただし、マニュアル化に関して留意すべきことがあります。例えば、マニュアルがあることによって従業員が思考停止しやすくなること、また、マニュアルから外れた行動をしたときの危険性を従業員が考えなくなること、などが挙げられます。

認識しておかなければならないのは、「プロセス」の目的に適う行動であって「アウトプット」を確かに出せるならば、「プロセス」のやり方は一つではない、ということです。技術の進化で変わるかもしれないし、時代の変化で替える必要が出るかもしれません。もっと良いやり方があるなら進化させなければならない、という発想を、常に現場が持っていることが重要です。そうでなければマニュアルは「考えない現場」を生むリスクがあります。

一方で、いくらその意識を持っていたとしても、一般に事業全体が見えていない現場の従業員によって、局所にしか適していない方向で進化させようとしてしまう問題が起こります。また別の問題として、マニュアルに従業員が慣れてしまうと、今度は「少しくらいは大丈夫だろう」と手間を省いたり手を抜いたりするケースが出てきます。始めは些細なことであっても、そのうちに、慣れがいつしか怠慢に変わり、失敗や事故につながるわけです。

事業に責任を持つ者が「プロセス」に目的を設定するのは、それらを抑止するためでもあります。

「プロセス」に目的が設定してあれば、もし従業員がマニュアルから外れた行動をしようとした時、目的に照らして自分の行動が正しいのか顧みる材料にもなります。これは逆に、「プロセス」を現場で変更したくなった場合にも言えることです。

「プロセス」に目的が設定されていないと、時間が経つにつれて、その作業を実施している意義が意識されなくなっていきます。信じがたいかもしれませんが、自分のビジネスであるにもかかわらず、「なんでこれ、やってるんだっけ?」と忘れるのです。

そこに例えばコスト削減のニーズが発生した場合、削ってはいけない領域まで削減対象として、事業責任者でさえそれに気づかないということが起こります。結果、現場にミス回避のしわ寄せが行き、人によるケアが余計に増え、それがクオリティの低下や事故につながる、というわけです。

このコラムでは「さわり」の話しかできませんが、ここではぜひ、全体俯瞰でデザインして価値創出を担保する「ビジネスのしくみ」と、現場レベルで仕事の実効性を担保すべく作る「マニュアル」は、まったく質が異なるものである、ということをご理解いただきたいと思います。

お客さまの話なのに半分くらいしか信用しない理由

わたしのような、業務分析を行うスキルを持つコンサルタントは、企業の支援に入る際に、その前段として「監査」と呼ばれる行為を行うことがあります。なにぶん言葉が威圧的ですので、お客さまに直接「監査します」と申し上げることはほぼありません。そう言わずに、そういう調査活動をしています。

これは、初めて関わる顧客について深く知るということが主目的ですが、この「深く知る」にはいろんな意味が含まれます。

例えば、訪問先の企業において経営者やリーダーの方々からお話をうかがいます。すると、出てくるのは9割がた「素晴らしく優秀な話」です。素晴らしい実績、優秀な人材、機動的な体制、クオリティの高い仕事、高度な技術、興味深い取り組み、獲得した褒賞資格認証、等々。

感心しながらお聞きしていますが、その時点では内心、話半分で聞いています。本当にすごいのかは、客観的に検証する必要があるためです。

見下すような気持ちは毛頭ないのですが、話を聞いただけでは、コンサルタントはまだ疑っているのです。これは個人的な性格の問題でもありません。一応、理由があります。次のエピソードを例に説明したいと思います。

ことしの2月、産業総合研究所(産総研)は、標的型攻撃により外部から不正アクセスを受けたことを明らかにしました。その後、去る7月にその詳細と対応方針をまとめた報告書を公表しています。

A4用紙50枚にわたるその報告書によれば、不正アクセスは昨年10月末から今年2月にかけて継続的に実行され、研究所管内のあらゆる業務システムに不正にアクセスをされたとのことです。犯人は、4カ月間かけて不正なログインを次々と成功させていったようです。

不正アクセスを許すに至った大きな要因としては、脆弱なパスワード設定をしていたアカウントの存在、サーバー設定の甘さ、などと結論付けています。

産総研といえば、著名なセキュリティ研究者が在籍するなど、国を代表する研究機関のひとつです。従前から、世間並み以上の情報セキュリティマネジメント体制がありました。CISO(最高情報セキュリティ責任者)もいて、委員会組織もあり、各部門にも情報セキュリティ責任者がいました。外部委託して運用監視もしていましたし、パスワード設定の所内規定もきちんとありました。

このインシデントが起こる前に、産総研の情報セキュリティ対策について(単に)話を聞けば、(専門家を含めて)ほとんどの人が「十分な体制だ」と評価したに違いありません。おそらくその気になれば、情報セキュリティ分野で国際的に価値が認められている「ISMS(ISO27001)」認証が取れるくらいのマネジメント体制だったと思われます。だからこそ、おそらく犯人の最大の目的であったであろう、機密情報の漏えいには至らなかったのでしょう。

しかしながら現実は、標的型攻撃には少なくとも4カ月間気づかず、気づいたきっかけは監視の結果ではなくまったくの偶然、不正を許した最大の要因は(報告書曰く)「キーボード配列をなぞっただけの安易な」パスワードやサーバー設定の甘さでした。

このエピソードから教訓として得られるのは、シゴトの仕組みというのは「実際に実行されて初めてその意味を成す」ということです。体制がある、ルールがある、機能がある、手順がある、だけでは不十分で、組織が完全に実行しなければ(または実行できないならば)、決めていることのすべてが無意味になりかねないのです。

産総研でも今回、その点に大きな反省を示しています。報告書には今後の対策が整理されていますが、その多くは管理体制の見直しと強化です。

わたしのようなコンサルタントが、話を聞いただけでは信じない理由が、ご理解いただけたでしょうか。話を聞いた後、それを裏付ける行動が実際に示されるかどうかを、必ず確認しに行きます。「監査」とは、かみ砕いて言い換えれば、「言っていることとやっていることが一致しているかを確認する」調査活動のことです。一致していない場合、そこに克服すべき問題があることが多いのです。

「ウチはそこそこイケてる」という認識は、だいたい甘い

自分の会社の実力について、一流とまでは思わないが少なくとも平均以上ではあるだろう、と思っている人は多いようです。

わたしは仕事柄、少なくない企業の業務の実態を観察していますので、拝見すればどの程度のレベルなのかは判断がつきますが、過去には「ウチはそれほどレベルが低いとは思っていない」とはっきりおっしゃる方もいました。

しかしながら、私見では多くの方々の自己評価はおおむね「甘い」と言わざるを得ません。世の中の会社の半分は「平均以下」であるという真理を、一度認識することが必要だと思います。

何らかの根拠をもって「ウチは十分イケている」とおっしゃるなら、問題はありません。もし根拠になるものを持ち合わせていないなら、ほかの会社の仕事ぶりを積極的に観察しに行くことをお勧めします。

経営者であれば、いろいろなツテをお持ちだろうと思います。訪問したいと思えば多くの機会があるでしょう。業種業態をえり好みせずに、多くの企業の業務をご覧になるとよいと思います。

会社訪問のほかにも、経営者がほかの会社を観察する方法はあるでしょう。自分が動きさえすれば、あらゆる機会において、ほかの会社の実力をうかがい知ることができるはずです。

たとえば、株主総会などもそうです。

株主総会では、その会社のトップが議長を務めて議事を進行していきますが、その会社の実力がうかがい知れるのは、質疑応答の時間です。多くの株主から、様々な関心ごとについて質問が投げかけられます。

その会社の実力が見えるのは、その受け答えです。質問の内容によって誰が回答者として登壇してくるか。想定問答に従って通り一遍の言葉をいわば「読上げ」しているだけなのか。的確な理解のもとにわかりやすい言葉で回答しているのか。厳しい質問にどう答えるか。議長は補足説明などにどう対応するか。

優れた企業は、延々と投資家の質問を受け続け、どの回答もレベルが高い。それに加えて議長が的確な補足をすると、トップの実力が高いことまで理解できます。

ある金融系の企業では、ブロックチェーンに関する質問を受けて、担当役員が回答した後、議長であるCEOが補足で、事業面と技術面から極めて的確な説明を行いました(もちろんカンペなどありません)。表面的な理解では決してできない説明をしたのは、すぐにわかりました。そういう受け答えを聞くと、この会社はしばらく問題ないなと納得するものです。

会社訪問に行ったとしても、ただ案内されたものを見て感心しておしまい、では何も見抜けません。その会社の業務について、またその会社を支える仕組みについて、どれだけ関心があるかが問われます。関心があれば、ほかの会社の実力、さらには自社の真の実力も、見えてくると思います。

「ビッグデータ」で見かける、あぶないカン違い(2012年7月)

ときどき、企業の業務改善に関する事例やストーリーを目にする方も多いことでしょう。参考になる話がたくさん盛り込まれており、わたしもよく勉強させてもらっています。

そうした業務改善に取り組むに当たって必須になるのが、業務分析と呼ばれる作業です。ところで、この業務分析には、置かれた状況に応じて 2 つのアプローチのしかたがあることをご存知でしょうか。

ひとつは、あるべき(ありたい)姿やあるべき(ありたい)シナリオがわかっている状態で使うアプローチ、もうひとつは、それがわからない状態で使うアプローチです。

言われてみれば当たり前に聞こえるかもしれません。しかし、この違いをはっきり意識して使い分けないと、間違った取組みに邁進することが実際によくあります。

先日、こんな話を耳にしました。

ある企業に、モノには自信があるのになかなか売れない商品がありました。なんとか売れるようにしたいということで、その企業は、売れない商品を売るための対策を立てることにしました。

具体的には、現状の営業の業務プロセスを見える化し、「~数」とか「~率」などの数値を割り出しながら、科学的に業務分析をしたのだそうです。その結果から、成果を上げるプロセスを設計したとのことでした。

その話では、設計したプロセスを実践してみた結果が語られなかったのですが、わたしはこれを聞いて「いまいちうまく行かなかっただろうな」と直感しました。

なぜなら、アプローチが間違っているからです。

先ほど、2 つのアプローチがあると述べました。これらをどう使い分けるかというと、端的にいえば「あるべき姿が理解・共有できているかどうか」でアプローチを変えます。

つまり、理想のフォームが明確なのであれば、科学的な手法で業務を分析し、理想との違いを浮き彫りにして成果を出しやすい個所を特定し、理想に近づける方策を実践します。

一方、理想のフォームが明確でないのなら、リファレンスがないので採るべき方針が明確にできません。その場合は、仮説検証型のアプローチを採ります。仮説検証型のアプローチでもし科学的な分析をするのなら、仮説を実践した後の検証のパートにおいてです。

先ほどのケースに戻りましょう。売れない商品を売る、という場合、みなさんには「売れる営業プロセスのあるべき姿」がわかるでしょうか。わかるのなら、そもそも売るのにあまり苦労しないのではないでしょうか。このケースの場合、採るべきは仮説検証型のアプローチです。

ところがこのケースでは、仮説を立てずにいきなり「科学的な分析」を始めています。それでも何らかの「成果を上げるプロセス」は導出され、分かった気になるのですが、いわゆる机上の空論になりやすく、やってみても思ったとおりには行かないことがほとんどなのです。

これが、わたしが「うまく行かなかっただろうな」と直感した理由です。

ここでぜひ強調したいのは、「知りたいことが何かがわかっていないのなら、分析しても意味をなさない」ということです。これは、巷で話題の「ビッグデータ」に関しても言えます。

ときどき経営者のインタビューなどで、「欲しい情報をすぐに見たい」を発言されているのを見つけることがあります。このとき、「欲しい情報」とは何か、それによって何を見出しどういう判断を下せるのか、そうしたシナリオまで語れるのなら、このセリフには説得力が出ます。しかしそうでないなら、それは「ビッグデータ失敗予備軍」の傾向です。

よく「データは語る」などのかたちで、さも万能であるかのように、マスコミも「ビッグデータ」を少々煽るようなストーリーを展開することがあるように感じています。データは語るかもしれませんが、実際は使う側から働きかけなければ何も語りませんし、使う側がデータを見抜こうとしなければ、何も見えません。ベンダーが提供する技術によってデータを出力すれば勝手に語りかけてくれると思ったら、確実に間違えます。

それは、今も昔も変わらないことのはずです。「ビッグデータ」によって新しくなったのは、技術の進化によってかつて不可能だったような大量のデータが簡単に処理できるようになった、ということ。誤解を恐れずに言ってしまえば、そのことだけなのです。