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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「クラウドがやられる可能性」を考えているか

「クラウドファースト」などとして、日本のマスコミはクラウド事業者に情報システムを「すべて」預けることが今の常識だという論調でしきりに語りたがると思っているのは、わたしだけでしょうか。

もちろん、リスクを取ってでもクラウドに完全移行したほうがその企業にとって価値が高いと判断して、そのようにした事例も認められます。納得感のある判断です。ただ個人的な見解ではありますが、そんな目利きをしたようには思えないクラウドシフト事例ははるかに多数あると思っています。マスコミが生み出したそんな後者の企業を、マスコミが多数取り上げる結果、ますます拍車がかかっているように思えてなりません。

実際のところ、目が利くITユーザー企業は、自社管理であるオンプレミスとパブリッククラウドサービスを、うまく使い分けて利用しています。

両方を使い分けるのには、いろいろな理由があります。単にパブリッククラウドに移すのは都合が悪いという理由もあります。個別の都合は様々でしょうが、総合的に考えれば、選択肢がいろいろあるにもかかわらず「クラウド一択」というのは賢い選択とは言えないはずです。だから使い分けるのだろうと思います。

クラウド事業者やベンダーが示す事例はもとより、マスコミが紹介する事例も、有名企業が自社のシステムをすべてクラウドシフトしたなどと大々的に取り扱っていますが、その企業が考え抜いた末にそういう判断をしたのだとしたら、そのリスクについてどう考えたのか詳しく聞いてみたくなります。

クラウドも人が運用するシステムである以上、オンプレと同様に障害は起こりますしシステム停止も発生します。問題なのは、障害が発生した後から復旧するまでのところです。オンプレミスなら自ら手を下して復旧に取り組むことができますが、パブリッククラウドの場合は復旧を待っていることしかできません。

クラウド事業者のほうが技術に長けているから自分で直すよりましだ、という論もあるでしょう。それは否定しませんが、彼らが取り扱っているのは超巨大システムですから、技術力があるエンジニアがあなたの会社の面倒を見てくれるわけではありません。年間何億円も支払っているような、よほどのお得意様企業なら別かもしれませんが、障害が発生して「あなたの会社のシステムは救えませんでした」と言われても、全く不思議ではありません。実際、過去のパブリッククラウドの障害においては、ユーザーのデータがバックアップもろとも消去された事例が複数あります。

あまり論じられることがないように思いますが、パブリッククラウドもITシステムである以上、サイバーセキュリティ攻撃に常にさらされています。いつ何時、脆弱性を突かれて顧客情報に攻撃者の手が届くともわかりません。それはオンプレミスと同じです。クラウド事業者だからリスクゼロということはありません。実際、国内のあるクラウド事業者で、内部の脆弱性を突かれて攻撃者に不正アクセスされてしまったケースが報告されています。

脆弱性を突かれる外部からの攻撃でなくても、クラウド事業者の内部で特権を悪用して利用者のデータに影響を及ぼそうとする事件が起こらないとも言い切れません。内部犯行の脅威もまた、オンプレミスと同じです。もしそのようなことが可能だとしたら、場合によっては全世界の利用者にリーチできてしまうという、前代未聞の漏えい事件になりえることも想像できます。

攻撃や犯行の脅威に限らず、そもそも外国資本の事業者に、自社のデータや資産をすべて預けてしまうのはリスクが高いのではないか、という考え方も、あって当然です。ご承知の通り、いま3大クラウドと呼ばれるクラウド事業者はすべて米国資本の企業です。欧州の企業では当初から、米国資本の企業に完全に委ねるのは危険であるという考えのもと、利用においては重要資産はパブリッククラウドに預けないなどリスク分散させる考え方が根強くあることが知られています。

日本国内でもここ最近、経済安保というキーワードのもとで、行政システムのクラウドシフトに一定の歯止めをかけ、国内の事業者に重要資産を預けるよう義務付けるべきだという意見が出始めました。冷静に考えれば当たり前のことです。これまでそのような話が出なかったのは、政府や行政もまた、トレンドセッターを自任する識者諸氏やマスコミの論調に盲目的に同調していたことの表れなのではないでしょうか。

米国の政府がパブリッククラウド事業者に行政システムをどんどん預けていると知らされて、日本の政府もクラウドシフトの動きを強めたのかもしれませんが、実際の所、米国政府はパブリッククラウド事業者に、政府専用の「物理的領域」を設けさせて、そこに行政システムを置いています。最近そうし始めたのではなく、始めからそうしているのです。要するに、(政府の手が滞りなく及ぶ専用の)データセンターにシステムを預けるという、従来のやり方と実質変わりはありません。

そして、パブリッククラウドのおひざ元ともいえる当の米国内の企業においてさえも、パブリッククラウドに預けたシステムを再びオンプレミスに戻すという揺り戻しの動きが顕著にあることが(米国内では)伝えられています。

言い出せばきりがないことです。また、だからといってクラウドサービスが有用であることを否定するつもりもまったくありません。

クラウド一択の何が結局問題なのかと言えば、パブリッククラウドは利用者自身のコントロールが(特に利用者にとって一番肝心なところで)事実上効かないこと、パブリッククラウド事業者にコントロールの主体があること、なのです。それが、およそすべてのクラウド利用にまつわる利用者側のリスクを生み出しているように思います。

目が利くITユーザー企業はそのことを理解し、何があっても決して自分のコントロールを失ってはならない情報資産を、自分の支配が及ぶ領域に置いておこうとしている、ということです。

マスコミが記事として出すクラウドシフト事例の企業も、実はよくよく聞いてみると、ちゃんとオンプレミスをうまく使って資産保護しているケースが多数あります。要するに、記者が見たい事実にだけ着目して報道しているだけであることが多いのだと、わたしは理解しています。少なくとも、記事の見出しだけ見て鵜呑みにするのはリスクが高いと、心得ておきたいものです。

メタバースがビジネスになるのか、考える

海のものとも山のものともつかないバズワードに、「メタバース」があります。今月は、このメタバースとビジネスは相いれるものなのかについて、少しだけ考えてみたいと思います。

メタバースという言葉、実はその定義はあいまいです。それほどに、何ができるものなのか、そもそも何がしたいのかさえ、まだ誰もわかっていないように思います。だからこそ、何でもできるような位置づけで語られることが多いように思いますが、その一方で、大きな魅力を感じるようなキラーコンテンツが示されているわけでもありません。

イメージだけでざっくりとメタバースを捉えると、バーチャルな空間に社会が形成され、そのなかで自分の分身であるアバターが様々な体験や活動を行える、という感じでしょうか。かつて「セカンドライフ」という、似たようなコンセプトのものが話題になりましたが、やろうとしていることはその当時と同じようにも思えます。ただ、技術は当時よりもはるかに向上している分、現在のバーチャル空間のほうがより可能性を感じられるということで、再び注目されているということだと思います。

実際、社名まで変更してしまった旧Facebookはもとより、GoogleやMicrosoft、日本国内でもNTTドコモやKDDIなど多くの企業が、この分野をビジネスとして捉えようと取り組みを進めています。

いま現在語られているメタバースの具体的なケースは、バーチャル空間でイベントを行うとか、繁華街を再現するとか、コミュニケーションできる空間を作るとか、”斬新なデジタルワールド” といった世界観の話が多いように思います。それだけ聞いていると、特定のビジネスなら関係ありそうだけれど、その他ほとんどのビジネス領域には関係なさそうだ、と判断してしまうこともできそうです。

しかし、メタバースの本質的な部分は何だろうかと考えてみると、案外多くのビジネスと相性がいいのではないかとも考えられます。

例えばゲーム。これは言わずもがなかもしれませんが、考えてみればメタバースの空間で展開されるゲームは、従来のゲームとはかなり様相が違うものができそうな気がします。まるでそこで生きているか、戦っているか、というような状況でゲームが展開され、場合によってはゲームをしていながら、そのなかで実際に買い物をするかのようにアイテムの売買が行われ、案外幅の広い経済活動が成立することもできそうです。

エンターテインメントは想像しやすいですが、もう少しお堅いところで行けば、例えば「訓練」とメタバースの相性はかなり良いと思います。訓練というのは、職業に関連したトレーニングやOJTもそうですし、技能訓練、例えば航空機や工業機械、重機などの技能習得を行うのに、カスタマイズして構築したメタバースは使えそうです。もしかすると、一般の自動車教習のかなりの部分は、メタバースで代替できてしまうかもしれません。

体験の提供もできることを考えれば、建設や不動産関連とメタバースの相性もよさそうです。いま建設設計は、かなりの部分で電子化が進んでいます。3D CADで設計した設計データをメタバースに反映するということは容易でしょう。デザイン段階でメタバースにその建築物をリアルに再現し、バーチャル空間で顧客に体験してもらうことができれば有益です。また、街そのものを再現できるメタバースであれば、不動産物件そのものを空間に再現すれば、内見はかなりリアルにできそうです。

他にも、事前に体験することに価値があるような分野、例えば病院での検査や治療をバーチャルに再現するという用途もあるかもしれません。重い病気で長期療養する患者に向けて、どんなふうに検査や治療が進められるのかを事前に理解してもらえれば、患者の安心感は高まると思われますし、そういう情報を提供してくれる病院のほうが選ばれる可能性が高いでしょう。

医療関係つながりでいけば、メタバースはカウンセリングが必要な領域で効果的かもしれません。患者のカルテに加えて個人的なプロファイルをもとにすれば、学習済みの人工知能(AI)がその患者に適切なカウンセリングプログラムを自動で設計し、人あたりを患者に応じて最適化したアバターを介してAIが適切な対話を提供できれば、治療に役立つかもしれません。

メタバースの可能性のひとつは、パーソナライズできるところにあります。利用者の特性に応じて、同じ空間を使いながらも、見るものや触れるものを個人レベルで自在に変えられる特徴があります。それを活かせば、利用者ごとに異なった体験を提供したいものに有効に機能する可能性もあるでしょう。

メタバースは、いまのところバズワードの域をまだ出ていないと思いますが、本質的な特徴は何らかの形で今後実現していく可能性は高いと思います。みなさんも、いろいろと思考実験してみてはいかがでしょうか。

「アプリは自社で内製」がフツウになる時代

近年は、アプリケーションを内製開発する企業がずいぶん増えてきたように感じています。

背景には、ノーコード/ローコード開発ツールのようなプログラミングを簡易化するソリューションの充実、SaaSやPaaSの機能充実化などがあります。コードが書けなくても、専門知識があまりなくても、パーツを組み合わせるような形で処理を組み、データの器を用意することで、簡易で単純なものであれば、動くアプリケーションが短時間のうちに完成してしまうようになっています。

アプリケーション開発の敷居が下がったことで、モノによっては、現場の業務部門の人でも欲しいアプリケーションを自作できるような状況になっています。そうであるなら、外部のベンダーに頼んで何カ月もかかるよりもはるかにメリットがあるということで、ソフトウェアを内製する企業が増えているわけです。

かつてEUC(End User Computing)という概念が流行しました。そのときと同じような雰囲気があります。EUCはその後廃れましたが、なぜ衰退したかというと、各所であまりにも好き勝手にプログラムが作られて、会社としてそれらの管理が行き届かなくなり、作ったものを誰もメンテナンスできなくなった、ということが要因のひとつでした。エクセルのマクロにも、同じような話があることは有名です。

今回の内製化の動きでも、同じような事態に陥る企業はおそらくあるでしょう。ただし、過去の反省を踏まえて、制作したアプリをうまく管理する仕組みを導入したり、またはそれを意識したガバナンス体制を敷くなど、工夫する企業も多くあります。

さらには、アプリと共に使えるセンサーやモジュール、はてはロボットまでも、割と手軽に手が届く状況も生まれています。価格も比較的低下し、またインタフェースが標準化されてきたことで、アプリとの連携も随分しやすくなりました。一昔前までは大企業がおカネを相当かけてやっていたようなことが、それこそ個人レベルでも実行可能な状況なのです。

うまく内製してアプリを使いこなしている企業を見ていると、そうして自在に開発すること自体が、対応力・スピード・柔軟性などといった競争力に直結するようになってきていると感じます。こうした状況が定着すれば、そのうちに、どんな着想を得られるかというアイデアの勝負になっていくかもしれません。または、どのベンダーのプラットフォームを選んで開発しているか、という点で差がつくような事態も、生まれるかもしれません。

ただし、当然ながらうまい話ばかりとは言えません。ノンプログラミングで開発できるようなツールは、複雑で高度な処理の構築はあまり得意とはしていません。部署内の単純作業のような、小さく閉じる領域なら向いている傾向なのが現状です。また、ツールによって得意分野が異なる傾向もあり、選定のしかたも重要になります。

目利き力は要求されるものの、試すだけなのであれば、資金的なハードルもかなり低くなっています。できる人がいないと嘆くより早く、どんどんやってみることができる企業のほうが先に進む。そんな時代になっていることを、経営者の方々には十分認識していただきたいと思います。

困難な年の初めに、あるべき姿を問う

2020年は異例尽くしの1年になりました。そして、2021年もその流れは続きそうな雰囲気があります。毎年、いつもなら年頭は前向きな気持ちで始めていきたいところですが、今年はなかなかそんな気分になりにくい向きもあるような気がしています。

こんなときこそ、あるべき姿を改めて問い直す年頭にしてはいかがでしょうか。

先の見えない状況では、どうしても目の前の課題にフォーカスが向き、次々とそれらを片付けていく格好になりやすいものです。しかしながら、それに任せて誰も全体感を把握していないと、知らぬ間にあらぬ方向に舵を切りやすいものです。気づいたときには、自らの立ち位置を見失い、必要なことと必要でないことの区別も付けられなくなっていきます。

ビジネスというのは、売れてナンボであることは間違いありません。ただし、売れるためには世間に価値をもたらさなければならないことも、また事実です。なんのためにその事業を推進するのか。なんの価値を世間に提供しようとしているのか。結局はそうした社会的意義を常に持ち続けていることが、苦境の時代において唯一の道標になるものだと、わたしは考えます。

ITの分野においては、近年では多様なツールやソリューションが出回り、利用しやすい状態になっています。昨年もまた、RPA、クラウドAI、IoTソリューション、ローコード/ノーコード開発など、すぐに使えて便利なITが多く採用されていました。

しかし、そうしたツールを表面的に使い回すだけでは、本当の意味でのデジタル化にはなりません。ここ最近の企業事例を見るにつけ、わたしには、単にツールを使っているだけの企業と、ビジネスや業務の全体構造を見据えてグランドデザインし、そのうえで適所にツールを適用する企業とで、くっきりと分かれてきているような実感を持っています。

前者のような企業は、目の前の課題への解決しか見えていないでしょう。そうした取り組みは、いつか全体感を失い、ビジネスとして動きが鈍くなるフェーズがやってくるだろうと想像します。

あるべき姿を常に見据え、この先もぶれない進め方をしていくためにも、一度立ち止まってグランドデザインを考えるには、この時期はいい機会かもしれません。

また同時に、流行や雰囲気に流され過ぎないことです。DXという言葉がよく強調されていますが、これは概念としては重要です。ただし、この概念自体は、わたしが当社を創業した時から申し上げていることであり、かつ当社が創業されるよりもっと前から先人が教訓として述べていたことです。

いま「DX先進企業」と呼ばれる企業はDXなどという言葉がない頃から取り組んでいるからいま成功している、という事実を思い返してください。そしてそもそも、「DX」と称しているのは、わたしの知る限りでは世界の中でも日本人だけです。digital transformation という言葉は欧米でも使われていますが、特別な意味合いを持たせてバズワードのように使われている印象はありません。

その本質を見極めれば、それとは異なる表面的なポジショントークや売込みを見抜くことは容易になります。

苦境にある業種業態の企業も多いことと思います。しかし一方で、さまざまなアイデアや工夫を繰り出して元気に乗り切ろうとする企業もあります。元気な企業を見習って、今年良い兆しが見えるようになることを期待しましょう。

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

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

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

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

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

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

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

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

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

アフターコロナでは「ジョブ型雇用」なのか

アフターコロナにおける企業のスタイルとして、ジョブ型雇用も話題になっているようです。複数の大手企業が本格的にジョブ型雇用を実践すると宣言したといいます。

ジョブ型雇用というのは、職務記述書(ジョブディスクリプション)によって職務内容や期待する業務成果を規定し、それに基づいて社員が業務を遂行するという雇用形態で、欧米では一般的なスタイルとされています。そのジョブディスクリプションに基づいて、報酬も決定されます。

労働時間よりも成果によって評価を行おうとする流れにおいて、ジョブ型雇用というのはそれにフィットするように感じられるかもしれません。しかし、6月のコラムで論じた通り、成果主義に基づく制度にするなら的確な業務分解と設計が必要であり、同様のことがジョブ型雇用にも当てはまります。

加えて、ジョブ型雇用には、従来の日本型雇用スタイルでは考えもしなかった負の側面があることも念頭に置いて、その是非を議論すべきです。

例えば、あるITエンジニアをシステム開発要員として採用したとします。この人材をジョブ型雇用で採用した場合、ジョブディスクリプションには、従事してほしい開発分野や職務レベルに関して詳細な記述が盛り込まれ、会社と当人の間で合意が取られます。一種の契約です。

ご承知のとおり、ITの分野はシステム開発以外にも、システム企画・システム運用・技術調査・研究等々と幅広いものがあります。開発の分野だけでも、専門により細かい分解が可能です。

将来は社内のITリーダーになってもらおうと考えた時、日本の会社の管理職層のほとんどは候補の社員に対し、俯瞰できるだけの幅の広い経験を有することを重視するでしょう。会社によっては、技術だけでなく営業も経験してほしい、という意向を持つことも珍しくありません。

日本型の雇用スタイルなら、このような人事異動はなんら問題ありません。ところが、ジョブ型では問題になります。採用した人材は、ジョブディスクリプションの記述に基づいて職務を遂行しますが、それは裏を返せば、規定外の職務には一切対応しないということでもあります。先述のとおり、ジョブディスクリプションは契約です。その人材は、ジョブディスクリプションを盾に、異動を断ることができるのです。外国人社員ですと、実際にそうします。

ジョブ型雇用は、実力と経験を一定以上兼ね備えた、いわばプロ向けの制度です。プロは、成果で評価されます。プロは、成績が悪ければ報酬も減額になりますし、戦力外通告もありえます。その意味では、管理職やビジネスリーダークラスの人材、または特化した専門性を有する職種に対してであれば、機能する制度であるといえます。

一方で、まだ育成段階で安定した成果を企業にもたらすのは困難である若年層の社員に向いている制度ではありません。もし無理やり適用すれば、狭い領域の仕事しか知らない人材しか育成されないうえ、社内ではジョブローテーションがまるで成立しない状態になるでしょう。それはつまり、仕事が人に紐づく属人化の進行を意味します。属人化が進行した業務は、その担当者がいなくなることが経営リスクになります。

また、有能な人材を採用するならジョブ型雇用だ、というような論調も一部で見受けられますが、そういう考えもまた短絡的だと、わたしは思います。

ジョブ型雇用とはひとつの方法論であり、本来は、国籍も経歴も関係なく、社員が実績と努力次第で自ら望むポジションを得られる公平な人事制度を構築することが大きな目的になっています。有能な人材が興味を示してくれるかどうかは、本来その会社の事業や仕事が魅力的かどうかなわけで、ジョブ型雇用であることは2番目以降の理由にしかならないはずです。ましてや、報酬に惹かれて採用を決めるような人材は、数年もすれば報酬をネタにして他の会社に転職していくでしょう。

いかなる場合でも、先立つものは「どうあるべきか」「どうありたいか」という具体的な意志であって、ジョブ型か否かといった方法論やソリューションではありません。方法論など、自らの意志に従って好きなように使い分ければよいことです。

人材は、ビジネスのしくみをドライブする存在です。どれだけ素晴らしいしくみをデザインできても、それをドライブできなければ、仕組みは無用の長物と化します。マスコミに振り回されることなく、まずは人材に対する自らの考えを見える化するところから始めることをお勧めしたいと思います。そのうえでフィットするなら、ジョブ型はあり、ということになるでしょう。

蛇足ですが、去る6月24日に、ファーストリテイリングの柳井正会長兼社長が、京都大学における医学研究に個人として総額100億円を寄付すると発表しました。欧米では、大物の事業家や経済人が何億ドルという自己資産を新型コロナ対策に寄付する動きが多くあります。こうしたことなら、素直に欧米のマネをしてほしいと思う次第です。

DXというよりも、JX??

デジタルトランスフォーメーション(DX)という、新たなバズワードが最近世間を賑わせています。DXに取り組まない企業はアフターコロナを生き残れない、とまで言っている人もいるようです。

冷めた目でこれを見ている人たちは、昔から言われていることの焼き直しだろう、というくらいにしか捉えていないことと思います。そのとおりだと、わたしも思います。ただし、この言葉の本質はきちんと認識しておき、今後の行動につなげる必要があろうかと思います。重要なのは、「デジタル」のほうではなく、「トランスフォーメーション」のほうです。

そもそもトランスフォーメーションとはどういう意味でしょうか。もちろん英語の ”transformation” から来ているのですが、英英辞典でこの語の基になっている “transform” を引くと、次のように定義されています。

to change in form, appearance, or structure

出典:Dictionary.com

形・姿・構造を変えること。つまり、表面に留まらずに中身をまったく違うものに変えてしまうこと、を意味します。

定義だけ見ても、何も感じないかもしれません。ただし、注意して見なければならないのは「まったく違うもの」という部分です。いままでとまったく違うものに、自らの手で意図的に転換することが、簡単にできるという人は、なかなかいません。

過去を振り返ってみれば、これが容易でないということ「だけ」は、簡単に理解することができます。

例えば、江戸時代に伊勢参りが大流行したという話は有名です。江戸時代には関所が設けられており、移動は現代の我々が想像する以上に難しいものであったと思われます。それでも流行したということは、余程大きいムーブメントだったのでしょう。

江戸時代ですので、当然ながら伊勢神宮までは歩いて向かうことになります。Wikipediaによれば、江戸からは片道15日、岩手からは100日もかかったそうです。九州からも参拝者がいたといいますから、そういう人は1年がかりだったかもしれません。

では、みなさんがその江戸時代の参拝客であることを、タイムスリップして想像してみてください。歩いて移動するのが常識だったその時代の人たちが、伊勢神宮まで「電車」や「飛行機」を使って移動することが、果たして容易に想像できたでしょうか。

江戸時代の日本において最も高速で移動できる手段は、馬であったと思われます。できるだけ高速で移動することを考えようとした時、常識の域から逃れられない人は、馬を高速にすること、例えばサラブレッドに育て上げるようなことを考えるでしょう。

それは「トランスフォーメーション」ではありません。「トランスフォーメーション」とは、江戸時代に電車や飛行機を考えることを意味します。徒歩という移動手段を「まったく違うもの」に変えるとは、そういうことです。

DXで言及されているトランスフォーメーションとはどういうことなのか。その本質は「自らの常識を転換する」ということに他ならない、とわたしは考えます。人間は、常識やバイアスにまみれています。それを完全に取り払って、常識外のまったく違うことを発想し、それを具体化するというのは、容易ではありません。しかしながら、常識を覆すことが時代を変えることでもあるというのは、歴史が示しています。問わなければならないのは、デジタルの巧拙ではなく、自分の常識を変えられるか、ということではないでしょうか。

ですから、「デジタルトランスフォーメーション」というのは本質を突いた言い方ではなく、むしろ「常識トランスフォーメーション」(JX??)とでも称するようなものだと、わたしは考えます。

デジタルを活用することで、従来の常識を一変させるのが比較的容易になることは、間違いないと思います。大いに活用しましょう。ただし、本質はデジタルを使うことにはありません。デジタルは、常識を変えるシナリオを実現する「手段」にすぎません。ですから、テレワークにしたくらいで、紙をデジタルに変えたくらいで、RPAで仕事を自動化したくらいで、みなさんの常識が変わっていないのなら、それはDXとは言わないのです。

ちなみに、ネーミングのセンスは、放っておいてください。

テレワークは「ニューノーマル」になるのか

新型コロナウイルスの蔓延によって社会が停滞と不自由を余儀なくされるなか、新しい考え方が台頭する動きがあります。それらを「ニューノーマル」と呼んでいるマスコミや識者も見られます。テレワークもまた、新しい働き方としてそこに含まれているようです。

テレワークは「ニューノーマル」として、新型コロナ後の社会の前提になるのでしょうか。わたし個人は、遠隔勤務はひとつのオプションとして、多くの企業で抵抗なく使われるようにはなると思います。ただしいわゆる「ノーマル」になる、つまり第一義的な位置づけで遠隔勤務するようになるには、想像を絶するほどの社会変容が必要だと考えています。紙をデジタルにすればよい、というレベルではありません。

一般的な企業がテレワークを前提とした労働体制にするには、従来から前提としてきた働き方が「壁」となるため、それらを突破しない限り「ノーマル」にはならないと考えられます。

大きな「壁」のひとつが、「時間を基にした労働管理と給与体系」です。既に明らかなとおり、テレワークでは厳密な時間管理はできません。自由に行動できる環境に社員がいる以上、行動を業務のみに拘束することは事実上不可能です。時間外労働を正確に測定するのも、実務上困難です。にもかかわらず労働を時間で管理しようとすればするほど、社員の行動監視を行うことになります。意識のないやり方をすれば、必ずやハラスメントやプライバシーの侵害という問題に直面します。

時間での管理に無理があるのなら、では何で管理するのか。成果での管理となります。ここに、大きなマインドシフトの「壁」があります。「成果」とは何なのか。

この壁の突破は不可能ではありませんが、仕組みを具体的にデザインできる人材が多くの企業にはいません。結果、ほとんどの企業には、この問題が究極の難題に見えるでしょう。

さらに別の「壁」は、「チームでの協働作業による労働生産」です。従来、多くの企業では複数の社員がチームを形成し、協働作業によって労働成果を生み出してきました。特に日本の企業は、チームの協調を伝統的に重視します。ところが、これもまた多くの人が理解済みと思いますが、テレワークは協働作業には向いていません。

テレワークに関しては多くの実態調査が行われています。煽るマスコミをよそに結果を冷静に観察すると、管理職・部下ともにコミュニケーションストレスを増やしていることが見て取れます。あのGoogleやFacebookでさえ、テレワークになるとしても社員の半数程度までだとし、オフィスの拡張計画を継続して進めているそうです。

意思疎通の問題点を技術で克服しようとする向きもありますが、日本人が言うところの「協調」というのは、「阿吽の呼吸」「以心伝心」、そうした無意識なレベルで機能するような話です。アバターがどれほど進化しても、少なくとも近い将来に、技術でこれらと同等の意思疎通を実現するのは困難だろうと、わたしは考えています。

こうした欠点を飲み込んででもテレワークをノーマルとするのなら、チームワークで成果を出すのは諦める業務設計をしなければなりません。つまり、事業を細かく因数分解のうえ、小さい単位で完結する独立した業務にする。独立した業務とは、他人の助けが不要か、何らかの情報をもらえるだけで完了できるか、いずれかの形で処理ができるという意味です。そのような業務を、個人に割り振る。

こうすれば、テレワークでも業務遂行が可能になります。実はこれが実現すると、先ほど挙げた「成果での管理」も可能になります。究極の難題も克服できるわけです。

しかしこの業務分解は、一部の業種(すぐに思いつくところでは、理容美容など専門技術を持った人員が単独で遂行する業種)ではすんなり実現可能ですが、ほとんどの場合ではやはり「業務設計」が難題になるでしょう。また仮に業務設計ができたとして、それによって生まれる相当な数の小業務を、漏れなく管理できるマネジャーが必要、という問題も出てきます。

ここまで2つの壁と、それらをどう突破できるか、という話をしましたが、これはつまり何を意味するかというと、職種を問わずに「裁量労働制を採用する」ということなのです。テレワークと裁量労働制、直観的にフィットするように思えます。しかしあらゆる職種で裁量労働制を適用するというのは、現行の法律では認められていません。

つまり、テレワークを本当にノーマルにするのなら、法律の全面改正も必要になるわけです。これもまた大きな「壁」です。先にホワイトカラーエグゼンプションの是非について国会で激しく対立があった経緯から見ても、法律を変えてでもテレワークをノーマルにするエネルギーがこの国にあるとは考えにくいところです。

3密の回避、非接触の推奨、などをきっかけに、あらゆる業種でデジタルによる自動化・省人化はさらに進むでしょう。一方で働き方の面では、新型コロナの問題が終息するにつれ、大部分のビジネスパーソンはオフィスや現場に戻っていくだろう、とわたしは想像しています。

ただし、それを覆してテレワークがニューノーマルになるだけの社会変容がもし起こるなら、誰もが想像しなかったような「マイクロサービスによる企業社会」がそこに待っていると思います。