デジタル化とは「最新のアプリを使うこと」ではない

最近では中小規模の企業でも、クラウドサービスやアプリ開発ツールなどを積極的に活用するケースが増えてきたと実感しています。

ITを道具としてどんどん試してみようという機運が盛り上がっていること自体は、歓迎すべきことです。ただ一方で、それに伴って厄介な相談を受ける機会も増えてきたような気がしてなりません。

困ったことになっている企業の傾向として、大きく2つの特徴があると思います。

ひとつは、次々とアプリやサービスを使い始めたけれど、いろいろなものがありすぎる状態になってしまい、会社での管理が行き詰まっているという状態です。ひとつひとつのアプリは相応に便利だとは思っているものの、「こんな使い方でいいのだろうか」と薄々感じ始めています。

もうひとつは、あるひとつのプラットフォーム上で、便利だからといって次々と新しい機能を追加し続けているうちに、「なんだか使いにくくなってきた」「違和感を持ち始めた」という状態です。始めのうちは新しい機能がすぐに追加出来てよかったものの、そのうちに、何かをしようとすると別のことを考える必要が増えてきたり、追加した後に不具合が出てきたりなど、いろいろと問題を感じるようになってきます。

いずれのケースにも共通するのは、一言で言えば「カオス状態」とでも呼べるでしょうか。要するに、アプリやサービスを「使う」ことしか考えていなかった結果、複雑で分かりにくい状態になってしまった、というものです。

デジタル化というのは、「最新のITを使いこなすこと」ではありません。以前からこのコラムでも、企業にとっての IT というのは電気屋でモノを買ってきて使うこととは違う、と述べてきましたが、同じ趣旨のことがこの場面でも当てはまります。

始めにしなければならないのは、デジタルを前提に仕事のしかたを設計することです。このことへの意識が乏しいゆえに、設計を怠ってまず何かを買ってしまう、使い始めてしまう、ということなのでしょう。会社の中のシステムやデータの構成を設計できる人がいないと、だいたいこうした事態になります。

例えば、近年ではロボットや自動運転技術を導入しやすくなっており、モノによっては10万円台で買えるような製品があります。それを受けて、うちにもロボットを入れようと言って購入し使い始めたのはいいけれど、導入後に保守できない、トラブルが出ても対応できない、定期的なメンテナンスに苦労する、という事態になりがちです。

始めのうちは自動で動いてくれて便利だったけれど、周辺の配置が変わったり現場環境が変わったりしたことでロボットが上手く動かなくなり、よく考えてみたらその修正ができる人がいなかった、などという事態も聞かれます。

ロボットの他にも、例えばAIカメラによる画像判定などでは、現場の光加減や陰が少し変わっただけで、判定がうまく行かなくなることも実際にあります。

ITを導入するのは、案外簡単です。知識がなくても買うことはできます。ワクワクするような便利ツールを買うのは楽しいものです。しかし問題は、買った後の運用なのです。その技術の癖や特性を踏まえて、会社の中での運用が的確に設計され、中長期的にどう維持発展させていくかのシナリオができていることが重要なのです。

そして、設計するというアクションは、単にアプリやサービスの組合せや利用する技術を選べる、決められる、というだけでは用事が済みません。会社の戦略や方針を踏まえて、業務の将来像を設計することでもあります。現有の人材と今後の人材獲得の方針を見極めて、使いこなせるものを判断することでもあります。最新であればよいわけでもなければ、流行に乗ればよいわけでもありません。設計するというアクションができる人は、かなりハイレベルで広範な知見が要求されるわけです。

たちが悪いのは、聞きかじった程度の知識や経験で「自分は知っている」と思い込んでいるけれど、実際には知見が足りないので、設計や方針の判断を誤る人です。先月のコラムで述べたような「知らないを知る」ことに取り組んでほしいと切に願いたくなるような人です。こういう人が周囲の期待を集めて裁量を与えられてしまうと、ITに疎い人でも見てわかるほどに派手にコケるまで突き進んでしまいます。そうなってから取り返すのは、なかなか難しいのです。

最終的には、経営者に問いが突き付けられます。「ビジネスのしくみが設計できる人材を育てて、確保する努力をしていますか?」と。会社としてデジタルを使いこなそうと思うのなら、持たざる組織能力を得る努力もしないで丸投げしているのでは、いつまで経っても状況は変わらないし変えられないのです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「何でもできます」がウリのビジネスは、売れない

最近、地方銀行発のデジタルバンクとして、(少なくともIT業界や金融業界の周辺では)鳴り物入りで事業をスタートした「みんなの銀行」が、3年連続赤字で事業存続の危機と報道されたのが注目されていました。

同行は、勘定系をはじめとしたすべての業務システムをパブリッククラウド上に構築し、システム設計もクラウドネイティブが前提と、銀行のシステムとしては前例のないものを構築するということで、事業開始当初から注目を集めていました。決済や預金といった金融サービスに必要な機能を、小さく分割して実装するマイクロサービスと呼ばれる手法を採用し、必要なマイクロサービスを組み合わせて連携することでサービス提供を実現する作りになっており、サービスの提供・追加・修正・更新などが柔軟に行えるということをウリにしていました。

その柔軟性を活かして、モバイルアプリだけで完結できるバンキングサービスを展開したけれど、口座数こそ増やせたものの、預金残高が積み上がらず、ローンの貸出も伸びずに、収益が思うように上がっていない、ということなのでしょう。

危機と報じられた後の会社幹部のインタビュー記事などを見ると、「当初からBaaS(Banking as a Service)を事業の軸と考えていた」「黒字化はいまから4年後だ」などという発言で、事業撤退観測を打ち消しているようです。よく言えば「ピボット」というのかわかりませんが、僭越ながらいささか都合の良い言い回しにも感じられます。

私自身、ビジネスとは何か、売れる商品やサービスとはどういうものか、繁栄や成長を果たしている企業とそうでない企業では何が違うのか、ということにずっと悩みと課題意識を抱えてきました。いまはその悩みが消えてなくなったと言いたいところですが、残念ながらそうではありません。しかし、10年以上かけて事例研究や試行錯誤を繰り返していると、気づきも多く得られます。そうした気づきを体系化したフレームワークが、いまの当社がお客さまに提供する助言の根幹の考え方になっています。

それを踏まえて申し上げれば、「柔軟」、すなわち「何でもできます」というビジネスに接した顧客は、たいていの場合、そのサービスをおカネを出して買おうという魅力は感じません。なぜなら、「何でもできる」会社には具体的になにができるのかが、よくわからないからです。

「何でもできます」というサービスは、顧客の側においてすでに実行したいことの構想がかなり明確に描けていて、あとはその実現方法を確立するだけ、という場合には有効かもしれません。卑近なたとえをするなら、家の掃除の仕方は完璧に想定できているが、あとは掃除を実行する人が欲しい、という状態でしょうか。

しかし、たいていの場合、顧客の側でそこまで構想が描けていることはありません。簡単に言えば、顧客は自身が具体的に何をしたいのかがわかっていないことが多いのです。

そうした背景から、典型的に売れていく商品やサービスというのは、顧客の困りごとの解決や、顧客が得られる心地よい体験が、その提供シナリオが具体的にわかるかたちで明確に打ち出されているサービスなのです。

勝手な想像かもしれませんが、このデジタルバンク事業を始めに企画した段階で念頭にあったのは、どんな顧客にどのような価値を提供する「ビジネス」をつくるのか、ではなく、どの金融機関でも実現できていない画期的な「システム」をつくる、ということではなかったか、懸念されます。パブリッククラウド上でマイクロサービスによるシステム設計を行って、過去に前例のない金融システムを構築する、ということにばかりフォーカスが行ってしまっていなかったのか。当然ですが、情報システムの構築は事業の「手段」であって、事業の「目的」にはなりません。

そうではないという反論があるとしたら、では、ターゲットとしていた顧客はスマホだけで口座の操作や取引手続きが完結する金融サービスがないことにどれほど困っていたのでしょうか。BaaSの顧客は、スマホアプリを使って取引する顧客とはまったく異なる種類の「ターゲット顧客」になりますが、BaaSの顧客は何に困っていると考えていたのでしょうか。そしてなぜ、異なる2つの種類の「顧客」を、始めから同時に相手にしようとしたのでしょうか。ぜひ説明を聞いてみたいところです。世間にない(または認知度が低い)画期的なサービスを打ち出そうというときに、異なる顧客を同時に扱う、すなわち複数の異なるビジネスを同時に立ち上げる、という行為は、わたしの目には無謀に映ります。

BaaSという事業環境においても、すでにライバルのプレイヤーは群雄割拠の状況です。同行が「ピボット」してBaaSを軸に事業を進めるとしても、「柔軟」というだけでは4年後の黒字化も難しいのではないかと、わたしは見ています。まあ、わたしの予想なので、外れることを願っています。見事に外れた暁には、また勉強させてもらいます。

「一生懸命に働く」のは、美徳ではない

「身を粉にして働く」「艱難辛苦を耐え抜き成功する」「懸命に取り組む」。少なくともかつての日本の職場では、こうした精神は美徳として扱われていたようなところがありました。現代ではどうなのかはっきりしませんが、いろいろな職場を見てきた個人的な経験から申し上げて、いまでもそんな精神が少なからず残っている傾向はあると感じています。

一意専心で打ち込み、様々な難題を克服して目標を成就する姿は、美しいものです。アスリートや職人などを見ているとそう感じます。しかし、こと企業の組織においては、「一生懸命に働く」ことは美徳ではないと思います。

誤解を恐れずに言えば、優れたパフォーマンスを出せる組織とは、同じ成果を他の組織よりもラクして生み出せる組織のことだと、わたしは思います。そういう状態のことは、一般には「生産性が高い」と呼ばれます。

努力を重ねることが無駄であると言うつもりなのではありません。努力の方向性を問題にしようとしています。一生懸命に頑張るのなら、「いかにラクをして、いまと同じ、さらにはいまよりも高い成果を生み出せるか」を考えることに力を注ぐべきなのであって、そうではない方向に注力すべきではない、ということです。仮に成果が挙がっていたとしても、ラクではないやり方で実現されているのなら、それは何かがおかしいのです。

ところが、ありがちな傾向として、一生懸命に頑張っている人に対して「その内容は問わず」ポジティブに評価する、ということがよく見られます。個人の評価がそれでよくても、組織のパフォーマンスという観点では、「一生懸命頑張る個人にその仕事をさせていていいのか」という評価をしなければならないのですが、問題を直視せずに満足している組織が少なくありません。

例えば、ある事業や業務において、組織にいる特定の人物の能力が著しく高いおかげで成果が生み出されていることが、小さい組織ではよくあります。そうした「スーパーエース」(時に経営者自身だったりします)を組織は称え、周囲は尊敬のまなざしを送るわけです。しかしそうしたスーパーエースは、組織にとっては “SPOF”、 つまり「単一障害点」です。属人化は、組織を脆弱にします。スーパーエースが活躍するような企業やチームは、わたしに言わせればシゴトを仕組み化する努力をしていません。努力を正しい方向で実行していないツケは、スーパーエースが何らかの理由で稼働しなくなった時(会社を辞める、病気で仕事できなくなる、家庭の都合に身体を取られる、職場を異動する、等)に顕在化することになります。

毎日押し寄せる問題を、次々さばくのに一生懸命になっている組織もよくあります。こういう組織は往々にして、計画を立てる能力が弱いことが要因でそのような状態になっています。毎日一生懸命に仕事していますから、周囲はポジティブに捉えます。しかしそのような仕事は、まるで RPG のように、出会った敵を順番に次々やっつけているだけのことです。果てしなくモグラたたきを続けるよりも、そもそもモグラが出ないようにするにはどうしたらよいのかを考えるべきなのですが、「没入」してしまっているとそういう発想はできないものです。

業務効率化のつもりで IT ツールを導入していても、ラクに仕事をしていないケースはたくさん見受けられます。例えば、会社や部署に「エクセルマスター」のような人物がいることがよくあります。この人物は確かに、スプレッドシートの取扱いに長けている達人です。しかし、取り組んでいる実作業はというと、大量のデータの打ち込み、転写転載、比較、正常性確認、流し込み、ファイルの送受信、といったものだったりします。コマンドや関数を駆使して作業そのものは高度であっても、つまるところ「デジタルツールを使ってマニュアルワーク」しているわけです。「そもそもその作業をやめられないのか」というようなことを考えるべきなのですが、達人は往々にして、その道具を使うこと自体をやめるという発想ができません。

なにか突発的な問題が勃発した時に、すぐに人海戦術で突破を図ろうとする組織も、よく見かけます。人が頑張って取り組むのが一番近道である、という考えです。確かに、稼働する人を増やして解決するほうがよいこともあるでしょう。しかしそれは、対象となっている業務の仕組みが的確に設計されていて、新しい人が入ってきたとしても短時間で業務をマスターし処理を担えるように完成されていることが前提です。イレギュラー対応だらけ、例外処理だらけ、の業務では、新しい人たちの頑張りは希薄化されてしまいます。そして、そういう現場ほどマニュアルも整備されていません。仕組みが弱い組織の業務に単に人を増やしただけでは、内部が混乱し、指示が滞り、下手をするとコントロールできなくなってチーム管理が崩壊します。人を増やせば増えた分だけ工数は掛け算で増やせる、というのは幻想です。

繰り返しますが、一生懸命に仕事を頑張るのは、個人のレベルでは美しい努力ですが、組織のレベルでは美徳ではありません。生物であるヒトの進化を原始人の時代から振り返れば、それはつまるところ、「どうしたらもっとラクに生きられるか」を一生懸命に考えて取組み、解決をしてきた歴史なのです。極端な例えですが、従業員の1日の勤務時間を4時間にしてもなお他社以上に収益を挙げるにはどうしたらいいか、ということを一生懸命考えるのが、生産性を高める方向に向かう正しい努力なのではないでしょうか。

「変われない自分」を「変われる自分」に変えるコツ

”最も強い者が生き残るのではなく、最も賢い者が生き延びるのでもない。唯一生き残ることが出来るのは、変化できる者である。”

進化論を唱えたイギリスの科学者ダーウィンが言ったとされるこの名言は、実はダーウィンが発言した言葉ではないという指摘があるようですが、その意味するところに関しては、多くの人が納得するものだろうと思います。

一方で、この言葉が多くの人々の教訓となり得ている理由は、そもそも人間というのは変化を嫌うという特性があるからだと、わたしは考えています。いままでのやり方、考え方、習慣などを変えたくない性質は、年齢が高くなるほどに顕著になる傾向があるようで、脳科学の分野でもこれを裏付ける研究があります。

わたし自身にも、これは大いに心当たりがあります。考えた末、工夫した末に、一度固めてしまったやり方、もしくは慣れてしまったやり方は、基本的に変えようと思いません。一方で、考え抜いたつもりでも、だいだいそれは100点満点の方法ではありません。仮にそれが、考えた時点では100点満点だったとしても、時間が経ち状況や条件が変わると100点ではなくなるのです。常に、自ら問題を探して発見し、やり方を変えるべきなのです。しかし、アタマではそう理解していても、いろんな「できない理由」を付けて、変える行動にはなりません。

そしていざ、外堀を埋められて、慣れ切ったやり方に対する変更を余儀なくされると、そこでものすごく抵抗を感じて、まだ立ち止まるわけです。

しかし、わたしの場合はこの悪癖に対策を打つことを考えて実践し、まだ道は半ばではありますが、一定の成果を得ています。抵抗がささやかなうちに、それを押して変更を実行できる自分になるように仕向けています。生活習慣やトレーニング方法など、大小何度も改善を実践してきました。そして、自身のなかの抵抗勢力を克服して変化を断行してみるとやはり、変えてよかったと思うことがほとんどです。

どうやって実践しているのか、現時点でのわたしの工夫を3つほど紹介します。ちなみに以下で紹介するものは、ビジネスシステムの設計理論の研究からヒントを得たものばかりです。

ひとつめが「数字で見えるようにする」。いま目指している物事の目標値、その目標に到達するうえでの中間指標や補完指標になるような事項の数値など、取組みの全体像が数字で見えるようにします。怠ける自分、目をそらしたい自分、を動かそうとするとき、数字が見えた時のインパクトは絶大です。特に、それまで全く気にしていなかったことが数字になって表れて、それが無茶苦茶な結果だったときのショックは、計り知れないものがあります。

もちろん、その測定方法は自ら納得するように設定し、数字が意味することが自分で明確に理解できていることが前提です。他人によって設定された測定ではインパクトもショックも感じません。会社で健康診断を受診して、結果の数字を見ただけではなんとも思わないのと同じです。

また、可能なのであればその数字を周囲に全面公開し、「その数字をいつまでにこう変える」などと宣言したりすれば、より逃げられなくなります。

ふたつ目は「手法や方法を多く知る」。いざやり方を変えようと思っても、どう変えたらよいのかを知らないと、そこで思考が停止します。やり方が分からないと、変える行動に移ることはありません。変えるならどういう方法が取れるか、どのような考え方をすればいいのか、多くのノウハウを知っていることが重要です。

こうした方法の獲得では、信頼できる情報源から得られた情報を基に、普段から自分なりにできるだけたくさん分析していることが大事です。ただ見聞きしただけ、ネットで調べただけ、知り合いに聞いただけ、という程度では、自分がやりたい工夫に適合しないことが多々あります。変えなければならないと示唆される対象に自らが拘っていればいるほど、または決断が重要な局面であればあるほど、これは当てはまります。選択できる方法を知っているほど、具体的な行動を発想しやすくなります。

三つ目は「常に新しい情報を取り込む」。新しい情報のインプットは、「変えなければならないかもしれない」と思い至る大きなきっかけになり得ます。おそらく自分が関心を持つトピックには、他にも多くの人が関心を持ち、日々研究や実践が行われ、工夫がされています。その結果としてベストプラクティスが継続的に更新されていきます。昨年まではこれがベストと言われていた方法でも、翌年になったらそれを上回るベストが出てくることはしばしばです。常に新しい情報が得られるようにしておくことが大事です。ふたつ目とも重なりますが、信頼できる情報源や支援者を持ち、継続的に情報が得られるような状態を作っておくことです。

そして、これらの工夫の根底には、自らの取り組みかたが「仕組み化」されていることがあるのを、忘れてはいけません。

そもそも、明確なロジックがなければ測定ポイントを設定できず、数値化はできません。また、仕組みがないところでなにか工夫をしようと思っても、どこをどのように改善すればよいのか見当はつかないのです。当てずっぽうな勘に頼った変更をしてみたり、他人が薦めたやり方を盲目に取り入れたりする人というのは、だいたい仕組みを持っていません。

さてここまで、ライフハックのようなことが書き綴られてきたように思われているかもしれません。もちろんライフハックとしても有効だと思いますが、「会社」や「組織」に置き換えても同じ論理が成り立つと、すでにお気づきでしょうか。

そうお気づきになられたら、このコラムが「会社経営」の話であると意識を置きなおして、ぜひもう一度冒頭から読み直してみてください。

「企業理念」と「ミッション」と「パーパス」は、どう違うのか

わたしは、3つとも同じことを言っているのだと思っています。ですから、企業理念を持っていた会社がわざわざミッションを定義する必要はないと思いますし、ミッションを定義していた会社がわざわざパーパスを定義する必要もないと、思います。

ただし、それが会社にとってどういう意味をもつものなのか、どういう目的で定めるものなのか、その定義は明確にしておくべきでしょう。

私見ですが、そうした定義があいまいなままに「流行しているから決めておこう」とそれっぽい言葉を置くことが目的になって定められてしまったような、魂のこもっていない「企業理念」が横行したから、次々と新しい用語が登場してきたのではないでしょうか。元から的確な決定と運用がされているのなら、別の言葉は生まれてこなかったはずだと考えています。

企業理念が的確に定められているなと感じるとき、その言葉からは、その会社が顧客、ひいては社会に対して、どのような価値を提供しようとしているのかが、端的にイメージできるものです。法人の存在意義は、その法人が社会に提案する価値が人々から支持されることで、表されるのだと思います。人々から支持されていることの証しは、結果として売上と利益によって量られるわけで、その意味で企業理念は、その会社の商売の根幹をなすものです。企業理念はビジネスの成果に直結するものであり、そこに並ぶ言葉が単なる絵空事であれば、それは世間に見抜かれてしまいます。

その意味でわたしは、利益を出すこと自体に苦労している小さな企業であっても、企業理念を明確にし、社会に対して何を成したいと思っているのか表明することには、意味があると思います。

理念を何も示さない会社は、「売れれば何でもよい」「ビジネスが大きくなればそれでよい」と思っている会社、と見られても仕方ありません。もちろん、利益があがらない会社は、立派な理念があろうとも淘汰されるまでです。そんな綺麗事は売れてから考える、という事業家も実際にいますが、後から人がついてくるリーダーとしては相応しいだろうかと、個人的には思います。

また企業理念が的確に定められている会社では、社員がそれを誇りにし、その言葉に啓発されています。自分の仕事に対するモチベーションや業務上のポリシーとして深く根付いています。

採用の時点で企業理念が示され、それに共感してくれる人材が採用されるので、当然といえば当然ではあります。ただ、そもそも採用の時点で企業理念が示されることがない会社、もしくは企業理念に根付いた価値観の共有が具体的に確認されないで人材の選考が進む会社のほうが、圧倒的に多い印象があります。そうしないのは、企業理念が会社の提供価値を示すという意識がないからなのでしょう。

企業理念が浸透している会社は、日常から企業理念を意識するような取り組みが実施されています。経営者から幹部へ、幹部から現場のリーダーへ、現場のリーダーから従業員へ、または経営者から直接従業員へ、様々なパスが実際に運用されて、理念が伝わり、日常の業務遂行へと結びついています。そうした機会を通して、社員が様々な場面で、企業理念に謳われている内容について深く考える機会があります。そうした個人レベルの学びが蓄積されることで、一貫した行動が生まれます。

そして企業理念が明確な会社ほど、会社の中で実行される仕組みが、その理念に基づいています。企業理念がその会社が顧客に提供する価値を謳っているのであれば、それを具体的にどう創出するのかが、ビジネスの仕組みの設計です。結果として、企業理念を具体化したものが、ビジネスの仕組みと言えます。ビジネスの仕組みによって、企業理念が絵空事でなくなるわけです。

このようにしてすべてが企業理念を軸につながっていれば、その言葉は企業理念として魂を持つと思います。そういう企業理念が存在しているのなら、ミッションも、パーパスも、必要はありません。

同様な話として、「ビジョン」という言葉の位置づけもよく議論になります。会社によっては、ミッションとビジョンの位置取りを互い違いに解釈して定義している向きも見受けられますが、どちらでもよいと個人的には思っています。ただし、企業理念と同様に、会社がビジョンをもつ意味、ビジョンを定める目的、その定義を明確にして、言葉を選ぶべきでしょう。そして、定めたからには、ビジョンを具体的な行動によって実現していくことが経営者に求められることも、忘れないでいただきたいと思います。

どんなやり方にも「向き不向き」がある

先日耳にした話です。某官庁でシステム基盤の統括をしているという人物が、政府の情報システムのグランドデザインやそれに伴う業務変革について語っていました。そのなかで、次のような趣旨のことを述べていたのに、いささか驚きました。

もしかするとご本人はそういう趣旨で述べたつもりはないのかもしれませんが、少なくともわたしには、次のような発言内容だったと理解されました。

いま想定している情報システムの設計方針は、マイクロサービスによる疎結合、APIドリブンで設計、開発スタイルはアジャイル。なぜならば、それが「トレンド」だから。

専門知識のない方々には上記の言葉はピンとこないでしょうが、ひとまず放置して先をお読みください。

情報システムを設計したり構想したりするにあたって、設計者が取りうる考え方はいくつか存在します。

それらのアプローチには、時節柄と言っていいのかわかりませんが、話題によく上るものが確かにあります。そうしたものを「トレンド」と呼ぶのなら、トレンドはあるのでしょう。

ただし、これまでに登場したどのような設計アプローチにも、それを採用するにあたっての前提や条件があり、結果として向き不向きが存在するのが現実です。情報システム設計における万能アプローチともいえる決定版は、個人的にいろいろ勉強してきましたが残念ながらわたしは知りません。

よって、少なくともわたしの理解では、設計アプローチは「状況に対応して適切に選択するもの」なのであって、採用する方針は「何を実現したいのか」「アプリケーションをどう動かすべきなのか」というポリシーに従って決定されるものです。トレンドで選ぶものではありません。

例えば、冒頭の引用にある「マイクロサービス」について考えてみます。簡単に言いますとこれは、他とは完全に独立した小さな機能を「サービス」という単位にしてまとめ、それらの小さな「サービス」をたくさん配置して、その「サービス」の間を通信で連携させることで一定の目的を果たそうとする、情報システム設計の考え方のことを指します。

この考え方では、ひとつの単位を占めるサービス(機能)は小さいので、入れ替えることが容易です。作り替えようとした時でも、個々のサービスは独立しているので、他への影響範囲を小さく抑制することができます。新しく追加しようとするときも、他のサービスに影響を与えずに開発して、あとから通信で連携すればいいので、柔軟にシステムを拡張したり改善したりできるのです。

ただし、難点はたくさんあります。大雑把な説明をしますと、「独立した小さな機能」というのは理想的ですが、これを実際につくるのは案外難しいのです。「独立した」とはつまり、他のサービスからは完全に切り離されていなければならないのですが、一切の相互干渉がないように完全に切り離す設計をするのが難題なのです。

それが的確にできないままにマイクロサービス化していくと、重複した機能やデータを持つ複数のサービスが知らぬ間に出来上がり、それが増殖していくことになります。次の難点は、増殖しやすい分運用管理がしにくくなりやすいこと、さらには、増殖するたびに通信のパスが増殖すること、です。無秩序に拡大してしまうことも考えられ、全体としては、品質要求が高いシステムにはあまり向いていない作りになりやすい特徴があります。

もうひとつ、冒頭の引用にある「アジャイル」についてはどうでしょうか。

これは、情報システムの開発手法の一形態です。ざっくり言えば、予め要求を決められないシステムに対して、まずは大事そうなところから小さく作ってみて、それをどんどん改善しながら大きくしていこう、というようなシステム開発のしかたのことを言います。

世の中には、どういうものが欲しいのか?と言われても、ざっくりとした要望以外に何も細かく決められないことがたくさんあります。そうした場合であっても無理やり要求を固めようとするのは、現実的ではありません。アジャイル開発は、そうした状況に対応できるシステム開発のやり方です。

ただし、ご多分に漏れず万能ではありません。要求を固めずに開発を進める以上、始めからパーフェクトな機能が揃ったシステムは、当然完成できません。アジャイルでつくるシステムは、始めはいまいちですが、だんだんと良くなっていきます。つまり、システム完成当初から一定の品質以上の動きをしてもらわないと困るようなシステムの開発には、向いていないのです。そういうシステムは、やはり設計の時点で要求を固める努力が必要になります。

2020年10月のコラムでわたしは、国のシステムは超巨大で一筋縄ではいかない旨を記しています。どの領域でどのような設計思想を採用し、どのようなアプローチで最適化していくのかは、本当に大変な作業だろうと想像します。少なくとも、そうした方針を「トレンド」で選定すれば解決するような話ではないと思います。

デジタル庁は発足当初から、ITスキルの高い外部人材を大々的に募集し、働き方も柔軟に対応できるようにしたことで、多様なスキルを持つ優秀な人材が多く集まってきていると聞きます。それは大変喜ばしいことですが、昔の某プロ野球チームのように4番バッターばかり集まってきてはいないでしょうか。みんなトップ人材、みんなリーダー格、みんなその筋ではスゴイ人、では、船頭多くして船山に上る、ということになります。まあ、わたしにとっては要らぬ心配なのですが。

小売業のダイナミックプライシングは、悪手でしかない

「ダイナミックプライシング」とは、需要に応じて売り手側が価格を柔軟に変動させる仕組みのことです。

従来は価格の表示が紙で行われていたため、価格を変更することは時間も労力もかかる作業になっていました。これが、近年はITによって価格表示をデジタル化することができるようになり、ダイナミックプライシングは一気に現実味のある取り組みになりました。現在、宿泊業、航空、娯楽施設では一般的に実用されています。

こうした取り組みを、最近真似しようとしている小売業がちらほら見受けられます。しかし、小売業がダイナミックプライシングを実施するのは、先進的どころかむしろ不利益をもたらします。やめたほうがよいと、わたしは思います。

小売業でダイナミックプライシングを採り入れようと考えている企業は、きっと顧客の立場で物事が考えられていません。

例えば、ホテルに宿泊する顧客の場合を考えてみます。その顧客がホテルに宿泊の予約をするとき、先だって予定が決まっているケースも、突然宿泊する必要が出てしまったケースも、いろいろとあるでしょう。ただいずれにしても、その顧客は、特定の日程で特定の場所に宿泊する必要があって、そのホテルに予約をしに来ています。ある意味、選択の余地はほぼありません。

他の例では、野球の試合を観戦したい顧客の場合はどうでしょう。その顧客が試合のチケットを購入するとき、通常なら、特定の日取りで行われる、ひいきの球団の試合を見たいと思って購入するはずです。自分の予定も、連れ立っていく人の予定も、それぞれあるでしょうから、どの日でもいいということにはあまりなりません。つまりその顧客は、特定の日程で特定の試合を見ようとして、チケットを買いに来ます。やはり、選択の余地はほとんどありません。

航空のチケットも、ほぼ同じ論理になります。つまり、こうした顧客は「その時その場で、特定のものを買う必要がある」のです。このようなケースでは、ダイナミックプライシングがうまく適合します。その時その場で利用したいから、その価格が少々高くても選択せざるを得ないし、価格の比較をしたところで他は選択肢になりにくいので、高額な理由が理解できるのなら抗議したくなる余地があまりないわけです。

一方、小売業はどうでしょうか。

小売店に並んでいる商品は、基本的に毎日ほぼ同じです。顧客は、明日に来てもそれを購入できますし、その時その場でどうしても買わないとまずいようなケースはそれほどありません。

さらに、関心のある商品ほど、店に来るたびに買う商品ほど、比較的高額な商品ほど、顧客はその商品の価格を「覚えて」います。

そこに、その小売店がダイナミックプライシングを導入したらどうなるでしょうか。当然、価格が上がれば顧客は買い控えます。

それどころか、「この店は来るたびに値段が変わる、しかも昨日よりも今日のほうが価格が上がっている」と気づきます。それに気づいた顧客は、その店に信頼を置かなくなり、警戒心を持ちます。

ダイナミックプライシングに魅力を感じてやまない小売業者は、消費者は価格が変動していることを知らないと思っているのかもしれませんが、まったく浅はかです。賢い消費者ほど、どの店で何がいくらで売っているのか(場合によっては「いつ」までも)、よく覚えています。同様の話で、食品メーカーはかなり以前から常套手段として、価格を据え置いて内容量を減らすこと(いわゆるステルス値上げ)を頻繁に行っていますが、それも多くの消費者(特に主婦の方々)は気づいています。

さらに言えば、ECの世界ではすでに、特定のサイトの特定の商品が時間経過でどのような価格変動をしているのか、自動的にトラッキングしてくれるサービスまで登場しています。利用者は安くなったところで通知をもらえるように設定しておき、通知が来たところで注文できるというわけです。

そのような自動トラッキングを使わないとしても、その小売業がECサイトを展開しているのなら、顧客はそのサイトに、関心のある商品を ”何度も” 見に来ます。訪問するたびに価格が変わっていれば、それで分かってしまいます。1週間のあいだに何千円や何万円も価格が上がっていることに一度でも気づけば、もう顧客はそのECサイトでは、一見で購入ボタンを押すことはなくなるでしょう。

消費者の信頼をなくしてまで、「最適な価格」で利益追求したいのでしょうか。小売店は正々堂々と、一度決めた価格で勝負すべきだと思います。もし価格をダイナミックに変えたいなら「下げる方向にだけ」にするべきです。上げる方向に変えるなら、きちんと理由を説明すべきだと思います。

実際、現在のような価格高騰のご時世の中、そうした説明は、小規模な小売店ほど危機意識をもって丁寧にやろうとしています。値段を上げたり下げたりを恣意的に行っていることに消費者が気付けば、企業規模に関係なく、小売店は簡単に信頼を失うことを、忘れてはいけません。

「表現力」がビジネスシステムの根源

昨年は幸いにも多くの企業様と出会い、支援させていただく機会にも恵まれました。

世間では「DX」ということばが流通し、一般の企業でも随分トピックに上がっていたように感じました。ただ、わたしが実際に支援をしていて一番感じたのは、デジタルの活用力がどうなのかではありません。「”表現力” がそもそも根本的に大事な力だな」ということでした。

表現力というと、なんともアートな世界に思えるかもしれませんが、実のところどんな企業でも、普段のシゴトの中で使わなければならない能力です。社長が経営方針を発表する、今期の売上に直結する事業企画をプレゼンする、顧客に対応を行った経緯を社内で説明する、トラブルの原因を分析してまとめる。あらゆる立場の人が、あらゆる場面で必要とするのが、表現力です。

表現力が乏しいと、周囲には理解してもらえません。根を詰めて考え抜いた思考も、他人に伝わりません。本当は的を射た良いアイデアであっても、理解できません。大事なことを定めて周囲と意思統一したくても、気持ちをひとつにできません。ほかの人にやってほしいことがあっても、うまくやってもらえません。

表現力のようなアナログな話と、ITを扱うデジタルな話は、まったく別世界のことに思えます。しかし、ことビジネスシステムにおいては、企業が何を達成したいのか定められたところに、あるべき姿のデザインが行われます。そこで、情報を基にしたビジネスロジックが設計されます。そうしたデザインを経て初めて、役に立つシステムが具体化されるものです。

そうであるとすると、そもそも根源にあるのは、「何をしたいのか」「何がなされるべきなのか」ということですが、それは誰かによって「表現」されないと、日の目を見ることはありません。日の目を見ないということは、根源が生まれないことになるわけですから、何も起こらない、ということです。

当たり前のことに聞こえるかもしれません。しかし、「何をしたいのか」「何がなされるべきなのか」がどれだけうまく表現できているか、そこで差がついているケースが非常に多いように思えたのが、わたしが昨年中の支援を通じて最も感じたことでした。

ぼんやりとしかイメージがない物事を言葉で表現する、まだ具体化できていない内容を図式で表す、課題の根源を探るためにからくりを見える化する。こうした表現力があるかないかは、企業の組織力さえ左右する極めて貴重な能力だと思います。

わたしも他山の石とすべきことですが、経営者のみなさんもまた、ご自身また社内の人たちの表現力を一度見つめなおし、また磨く機会を豊富に設ける取り組みをされてみてはいかがでしょうか。みなさんの会社の社員は、他人が抱えているモヤモヤをスイスイ図式化できますか?ご自身がつくる経営会議の資料は、気づけば文字だらけで、誰にも読んでもらえそうにないものに仕上がっていませんか?図や表は書いてみたけれど、レイアウトや言葉が稚拙で何が言いたいのかよくわからないことはありませんか?

組織の表現力がいまより倍増するだけで、決して大げさではなく、会社のビジネスシステムのあり様が大きく変化するかもしれません。

新年にあたり、わたし自身も改めて心掛けていきたいと考えています。

成長させたい事業なら、トップが動かないとダメな理由

ビジネスがデジタル前提となる時代にシフトしつつあります。そんななか、これまでの事業の常識を変える取り組みや、切り口を変えた事業を推進するといった、新しい取り組みに挑戦する企業は増えているように思います。

こうした取り組みは、すなわちビジネスシステムを描きなおすこと、設計しなおすこと、でもあります。根本的なレベルから事業の仕組みを構築する必要があるならば、それはトップが主導し、トップが絵を描き、トップが指導して仕組みを構築することです。そうでなければ、一貫した組織行動のもとに、実現したい提供価値を実現することはできません。

トップが本気でやらない事業がうまくいかないのは、当たり前のことです。

例えば、自社の強みを生かして新規事業を立ち上げることを考えたとします。その場合、強みを生かすのは良いとしても、事業の戦略立案はもちろん、ビジネスシステムをイチから設計し、実行に移し、軌道に乗せなければなりません。

誰も描いたことのない絵を描き、未開拓の地に道を作らなければならないわけですから、その事業の総責任者であるトップがそれを描かなければ、トップより下のメンバーはリアルなイメージを持つことができません。

こういう時に、心得のないトップは往々にして、自分の得意分野ではないところを、権限委譲という聞こえの良い言葉で「全面的に」他者に丸投げします。全面的でなければ救いようがあるのですが、残念ながら全面的であることがほとんどです。そうやって、全体設計もせずに自分からその部分を切り離すのです。それが、業務の属人化の始まりになります。

業務の属人化というのは、始めのうちはあまり問題になりません。権限委譲された人が成果を出せば、うまく行ったような気になるものです。しかし、年を追うごとに、事業が拡大するごとに、属人的な業務をつくってしまった問題は顕在化していきます。

気づいたときには、修正しようにもしがたい、修正するとしたら多大なるコストとエネルギーを伴う課題と化すのです。そしてたいていは自力で修正できず、ある日、依存度を増した特定の人物が機能しなくなることで、事業の成長は止まります。

他にも例えば、トップが本気で取り組まないがために、現場における過去の成功体験からくる考え方や、染みついたカルチャーを変えられないケースがあります。

モノ売りを得意としていた会社が、これからはコト売りだと宣言してサブスクビジネスを始めようとしたとします。

言うまでもありませんが、モノの販売とサブスクビジネスは、似て非なる事業です。モノの販売では、売ってしまえば顧客との関係はそこでいったん区切りを迎えます。一方でサブスクビジネスは、顧客が商品やサービスを継続して利用することによるLTV(Life Time Value)を最大化することを目指す事業です。

つまりサブスクは、商品やサービスを売ってからが本当の勝負の始まりです。顧客と定常的に接点を確保し、使用状況を把握し、困っていることがあれば企業側から手を差し伸べ、必要ならばアップセルやクロスセルを勧奨し、新機能やサービスの開発を間断なく進めて提供し、顧客が自社の商品やサービスによって成功を収めてくれるように、継続的に働きかけることが重要だとされます。

そうした一連の取り組みを「カスタマーサクセス」と呼ぶわけですが、これはモノを売って終わっていた企業からすれば、かなりのマインドシフトを伴う取り組みです。

マインドシフトが組織としてできないまま、モノ売りのカルチャーでサブスクに取り組もうとすると、口で言うこととは裏腹にまったく行動が伴いません。

言葉ではコト売りしよう、顧客のカスタマーサクセスを実現しよう、などと言っているわりに、KPIは相変わらず商品やサービスの販売数や販売時の利益で測定する。事業施策もモノ売りの販促と何も変わらない。カスタマーサクセスなどと一応称しているけれど、行動の実態は従来の「カスタマーサポート」と何も変わらない。なにより顧客の情報を自分で持っていないし集めようともしない。顧客のLTVを向上させることの重要性は頭では理解しているのに、現場では「商品の手離れがよいのが営業的にはベスト」などと指示が出ている。そんなことがフツウに起こります。

それもまた、トップが従来から染みついたカルチャーを根本から変えようと本気で取り組まないから、起こることです。

本当に成長させたい事業なのであれば、トップが主導してビジネスシステムを設計するべきだと、わたしは思います。