「システムデザイン」タグアーカイブ

ITの垣根が下がり、デザインのハードルが上がる

投稿日時: 投稿者:

IT 分野の技術進化の速さは、もう何十年も前から言われていることですが、その技術レベルの急速な向上とともに顕著なのは、利用するハードルが急速に下がってきていることです。インターネットの登場、クラウドサービスの台頭、プログラム開発のローコード・ノーコード化、AI の席巻、といった経緯を経るごとに、数十年前であれば大企業でも難しかった技術を、いまでは小規模な企業でも操ることが不可能でなくなっています。

IT を操るハードルが低くなってきたことで、企業が IT を操る領域が急速に拡大することにつながり、また、事業を構成する基盤としても IT が当然の存在として位置づけられるものになりました。近年、IT を駆使したスタートアップ企業が、創業間もない段階から社会に存在感を示し、分野によっては大企業に技術で対抗しうるベンチャーが登場する状況になっているのも、ハイレベルの IT を活用するハードルが低くなっている証左であると言えるでしょう。

ただし一方で、IT を扱うのが容易になってきたことと共に、企業が IT をコントロールする難易度を同じ速度で上げてしまっている現実もあることを、忘れてはいけないと思います。

企業にはいま、IT を扱うにあたってあらゆる選択肢を取り得る状態にあります。自由度の高さは、やりたいことが叶えられる可能性を高めます。一方で、IT に関して今も昔も変わらない現実のひとつに、「デジタルは曖昧な状態を許容しない」という特性があります。物事に対して曖昧なままに IT に手出しをすれば、焦点の定まらない無駄な行動を重ねたうえに、最後には失敗を見るか、後戻りできないほどに技術にロックインされてしまうか、大きなコストをかけながら結局人力対応が減らず成果に乏しいか、企業にとってネガティブな状況に陥るということが往々にして発生します。

最近では AI が急速に企業に浸透していっていますが、それによって同じく急速に課題になってきたのが、データアクセスに対する権限です。なにも制約がなければ、AI はあらゆるデータを学習し取り込みます。社外はもちろんのこと、部門間でもアクセスする権限に制約を付けたいデータが会社にあるとしたら、その企業は無防備に AI を使わせるわけにはいきません。すでに運用中の情報システムでアクセスコントロールできればまだよいですが、AI が関わる世界では、ファイル単位より細かいデータや非構造化データ（データベースに格納できないようなデータ）までが、コントロールの対象になり得ます。いままで管理が曖昧でもよかったデータに対して、そこまで考えた権限管理にどう取り組むのでしょうか。

また、これも昔から変わらない IT の特性ですが、IT というのは導入したら終わりではなく、運用していかなければなりません。ただ便利そうなものに次々と手を出して使い回し、やめたくなったら止める、という振る舞いは、利用レベルの低い「お試し段階」でしか通用しません。依存性の高い IT を事業に適用すればするほど、それを企業としてどのように使い、どう利用を発展させ、どのように利用価値を確保し、利用をやめる場合はいかにして撤退を図るか、考え抜かれた IT 基盤の「デザイン」が必要になってきます。

こうしたアーキテクチャー設計には、現在手元で使える技術およびその技術の今後の進展を見通しながら、その企業に適した技術のポートフォリオを組み、グランドデザインを描けるだけの、視野角の広いスキルを社内に持っていなければ対応できません。簡単に使えるようになった IT を使いこなせる程度で獲得できるスキルでは、残念ながらありません。自社ではできないからといって外部に丸投げできる仕事でもありません。そうかといって、勝手気ままに使うだけで「設計なし」では、前述したとおり、企業にとってネガティブな状況に陥るリスクは相当に高くなるのです。

こうした自覚がある企業や経営者は、まだ少ないのではないかと思われます。それどころか、ローコード開発でうまく行った程度で他社にコンサルティングを始めるようなユーザー企業がいるほどです。

自覚するきっかけになるのは、興味の視点の違いだと思います。真似したくなるような会社が、どのようにして、他社がマネしたくなるようなビジネスを生み出すことができたのか。その本質に興味を持つのか、単に表面的なノウハウにしか興味を持たないのか、という違いです。後者であれば、ビジネスのしくみのメカニズムや、それを支える基盤のデザインに、興味を持つことはないでしょう。

いま、多くの企業は喜々として、巷にあふれる IT サービスに飛びついているようにも見えます。そして、それを横目に焦りを募らせる企業も多くいるように感じられます。わたしとしましては、こういう時代において、IT という道具を「使いこなすのがうまい」ことより「グランドデザインが上手い」企業を目指すべきであることを、重ねて強調したいという思いです。

イーロン・マスクとロックイン

投稿日時: 投稿者:

去る4月、KDDI はスマートフォンと米 SpaceX が運営するスターリンクの通信網を接続するサービス「au Starlink Direct」を正式に開始しました。これにより、KDDI のスマホがスターリンクの衛星に直接つながり、基地局が配置できなかったエリアでも衛星経由で通信できることになりました。テキストベースの通信がまだ主体のようですが、そのうちデータ通信、さらには音声通信やビデオ通話まで展開されていくかもしれません。これに対して競合他社も、同様な「圏外をなくす通信サービス」を目指した動きを見せています。

ただし、KDDI と同様に衛星とスマートフォンを直接つなぐサービスを具体的に明らかにしているのは、楽天モバイルだけです。NTTドコモとソフトバンクは、意向は表明しているようですが、細かい内容は明言していません。

両社があまり対抗心を表に出さないのは、もしかすると、これとは別の方法で「圏外をなくす」ことを考えているからなのかもしれません。両社共それぞれ、HAPS と呼ばれる通信ネットワークの構築を推進しているのです。

スターリンクが低軌道衛星を使って通信網を構築しているのに対し、HAPS は、成層圏（地上20㎞）に飛行体を常駐させ、それを中継局として通信網を構築します。低軌道衛星は地上から 200㎞～300㎞ にあるのに対して、HAPS はその 10 分の 1 程度ですから、そのぶん通信遅延が少なく、通信速度も速い、つまり、始めから音声通話もビデオ通話も可能な、KDDI より質の高い新型通信網が構築できる可能性があるわけです。

利用者の立場で言えばサービスの質や通信のレベルに注目が行きますが、事業者の視点で見ると、別の重要な点にも気づきます。つまり、サービスを提供する基盤をいかに自らがコントロールできるか、という観点です。

KDDI の場合、スターリンクという確立した他社通信網に接続する形でサービスを提供している格好になります。これはつまり、スターリンク側でサービスが提供できなくなる、契約が打ち切られる、等の状況でサービスが丸ごと止まってしまうリスクがある、ということになります。人口カバー率 99% の携帯通信網は自前で構築していますから全体的な影響は軽微でしょうが、「圏外ゼロ」がいっぺんに失われるリスクは物理的にはあるということです。「スターリンク依存」というのは、場所を変えれば、ウクライナ軍がその状況にあり、結果的に政治的なカードとしてそれを使われてしまっている状況から見ても、リスクの高さをうかがえるところだと思います。

一方、HAPS のほうは、飛行体こそ特殊な技術を要することから欧米の企業が開発したものを調達し運用するものの、通信網の構築と運用は、各社が自ら行う計画です。HAPS が商業的に成功すれば飛行体を製造する企業は他にも出てくることが期待でき、事業の安定的な継続の面から考えて、通信網の運用を他者から影響される可能性が小さいのは重要と思われます。

自ら提供する事業にもかかわらず、他社の意向次第でその運用が大きな影響を受けることを、俗に「ロックイン」と呼びますが、ビジネスを企画するにあたり、何が事業の「首根っこ」にあたるのか、どの部分は確実に自前で賄い、どの部分はパートナーや外部の専門家に預けるのがよいのか、そうした戦略的な判断は、経営者が当然に行わなければなりません。

ちなみに、IT の世界でも「ベンダーロックイン」という用語があります。ここまで読み進めていただけていれば想像できると思いますが、自社の IT についてベンダーに首根っこをつかまれてベンダーの言うことに従うしかなくなることを指して、昔から使われています。最近ではベンダーではなくクラウド事業者にそうされることから、クラウドロックインという派生語も聞こえてきます。そのうち、生成 AI も同様になるでしょう。

ロックインを避けるには戦略的な発想が必要になりますが、技術者というのは往々にして、技術的に便利であること、技術的に優れていること、を重視し、ロックインされるというような戦略的発想は後回しに（または無視）する傾向があります。経営者が IT 技術者の言っている通りにしていると、知らぬ間にベンダーロックインされます。その IT がもし事業の「首根っこ」だったら、どうしますか？

そうした戦略的発想は経営レベルで補い、何が自社にとっての「首根っこ」なのか、しっかり見極めようとしなければなりません。

ちなみに HAPS は、25 年くらい前にわたしが会社員だった頃、電波干渉や通信技術のフィージビリティスタディに関わっていたプラットフォーム構想でした。当時は「巨大な飛行船を極寒の成層圏に 1 か月以上無着陸で滞留させておくなんてできるのかなぁ」と思いながら、机上シミュレーションをしていたものです。どうやら現実のものとなりそうで、個人的には感慨深いものがあります。

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

投稿日時: 投稿者:

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

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つほど紹介します。ちなみに以下で紹介するものは、ビジネスシステムの設計理論の研究からヒントを得たものばかりです。

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

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

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

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

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

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

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

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

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

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

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

投稿日時: 投稿者:

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

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

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

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

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

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

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

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

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

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

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

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

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

投稿日時: 投稿者:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

投稿日時: 投稿者:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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