DXナレッジ

DXを一言でいうと「〇〇〇〇〇〇ファースト」になることだ。

 

「雇用リスクがあるから」

エンジニアの自社雇用をためらう企業がよく挙げる理由ですが「この理由を挙げること自体DXを理解していない証拠」になってしまうってご存じでしたか?

そもそも正しいDX理解が進まないのは、情報が膨大かつ複雑だから。
セールスフォースを入れること?基幹システムを刷新すること?デジタルディスラプターに対抗できる企業になること?…と一人一人理解がバラバラという状況が、どの企業でも起きているようです。

すべて間違いではない。けれど、それが答えではない。というモヤモヤ。

ずばり、DXを一言でいうならば

『ソフトウェア・ファースト (出版社:日経BP 著者:及川卓也)』

になることだと、DX理解に一本の軸を通してくれる頼もしい本がありました。

 

DXとは、ソフトウェア・ファーストに転換すること【本の概要】

Switchが欲しくてSwitchを買う人はいません。
Switchのソフトで遊びたくてSwitchを買う人がいるだけです。

つまり重要なのはソフトウェアだという当たり前の話なのですが、日本企業は真逆。ハードウェア志向であり、そのことが日本のDX推進を大きくおくらせている原因になっていることをとてもわかりやすく解説してくれている一冊です。

著者 及川卓也さんは、マイクロソフト・グーグルのプロダクトマネージャー・エンジニアリングマネージャーを歴任してきたエンジニアですが、本書は、専門用語をほとんど使うことなくわかりやすく書かれています。DXの「なぜなに」がよく分かるようになり、やらなければいけないDXが、やるべきDXに変わる名著です。

 

ソフトウェア・ファーストは自社雇用が必須

日本は、ITを「製品」と捉えています。
米国は、ITを「ビジネス」と捉えています。

日本にとってITは「製品」であり、一度作ったら完成するモノです。作るべき製品がなくなればエンジニアの仕事はなくなるため、自社で雇用するのはリスクであるというのが日本企業の考え方です。

ですが、米国にとってITは「ビジネス」であり、改善・改良を重ね続け永続的に強化していくモノです。仕事がなくなるという前提はありません。仕事がなくなる時はビジネスが行き詰まった時、つまり倒産する時です。

そのため、米国ではエンジニアの仕事がなくなるという前提がそもそもなく、雇用リスクという考え自体も存在しません。営業が営業トークを磨いて成果を上げていくように、エンジニアも同じくITをアップデートして成果を上げていく存在として認識されているということです。

DXとは「米国に習ってITをビジネスとして活用する企業に変革していきましょう」という話なので、「エンジニアの自社雇用を通常化していきましょう」ということでもあります。

 

ソフトウェアを、ハードウェアのように考えている日本

ここで一点、不思議に思うことがあります。

日本は、IT開発プロジェクトを「システム開発」と呼びます。
米国は、IT開発プロジェクトを「ソフトウェア開発」と呼びます。

ですが「システム開発」と聞くと、まるで「ハードウェア」「装置」を開発しているイメージになりませんか?
(感覚の問題なので、人それぞれちがうとは思いますが)

 

 

一方「ソフトウェア開発」と聞くと、「アプリ」「Webサービス」を開発しているイメージになりませんか?

「システム開発」という言葉から連想されることは、「ハードウェア開発」であり「仕事の効率化を図る装置」であり「基幹システム」です。

実際、現状日本のシステム開発はかなりの割合、基幹システム開発です。「IT=ビジネスそのもの」という米国のイメージとはズレを感じます。日本が「DX=仕事を効率化し、労働力を削減するモノ」という連想で止まってしまいがちになるのは自然なことなのではないでしょうか。

ですが「ソフトウェア開発」という言葉から連想される「アプリ開発」「Webサービス開発」なら、「ビジネスに直結する」イメージがすぐにわきます。

LINEのような多くの人に使われるアプリを作ったり、NetFlixのようなWebサービスを作っていくことだと理解できるからです。アプリ、Webサービスが収益を生むことはもう世の中の周知の事実です。「ビジネスそのもの」と言われても違和感は一切ありません。

実は、このイメージのズレを感じたのは本書の下記記載でした。

日本企業への問題提起②
日本企業は、ソフトウェア開発をレバレッジの効くビジネスとしてではなく、工業製品のように捉えたため、イノベーティブなソフトウェアを産み出せなかったのではないか?

ソフトウェア・ファースト 出版:日経BP 著者:及川卓也 P.76

上記「システム開発をレバレッジの効くビジネスとしてではなく、工業製品のように捉えたため」と書かれていません。「ソフトウェア開発を」と書かれています。

そうです。ITの開発というのはそもそも、ソフトウェア開発です。それがなぜか日本では「システム開発」と呼ばれ、どこか「ハードウェア開発」のように感じてしまっている。

つまり、ソフトウェア・ファーストとは、

ソフトウェア開発を、ハードウェア開発のように勘違いしてしまっていることに気づき、ソフトウェア開発として向き合い直すこと

でもあるのではないでしょうか。

イメージの話を長々してしまいましたが、勘違いを正すためには、なぜこのような勘違いが起こるのかについても知っておく必要があります。

 

日本は、ソフトウェア軽視・ハードウェア重視の浦島太郎

日本はかつて製造業大国でした。現在も製造業が強く、日本企業の時価総額ランキングトップはトヨタ自動車です。ですが、世界の時価総額ランキングではトヨタ自動車は49位 (2020年11月)。それより上、1~48位に日本企業はいません。上位は海外のIT企業が独占している状態です。

いまから30年前、日本の自動車や電機メーカーが世界を席巻。製造業市場を奪われたアメリカは、その打開策としてITに力を入れ始めます。そして徐々に、ITを駆使する世代が台頭し強い企業が産まれはじめます。

日本は依然として製造業が日本の輸出産業をリードしており、アメリカで頭角を現し始めていたITに目もくれず。IT企業が上場を果たしても、製造業が産み出す売上には遠く及ばないと、古い世代のIT軽視は続きます。

当然、大手企業内部のIT事業部はコスト扱い。グループ会社として外部に切り出されます。そうしてうまれたNTTDATAなど大手システム開発企業を筆頭に出来上がったのが、世界最大規模のシステムインテグレーション業界です。

ITをビジネスだと重視し、成功させるために躍起になっていたアメリカ。
ITを文房具だと軽く見て、正面から取り合わなかった日本。

このような流れから、日本はITを「複製可能な工業製品」と捉え、アメリカはITを「ビジネス」として捉えるようになりました。その影響もあってか、システムインテグレーション業界やウォーターフォール開発手法は製造業界をやり方の模倣です。
 

日米欧のソフトウェアに対する考え方の違い

日本企業●カスタムまたはセミカスタムで大量生産するのに向いている
●しかし、それが世界を変えることはない
米国企業●ソフトウェアはビジネス
●「まあまあの良品」をつくり業界標準を打ち立て、その過程で大儲けできる
欧州企業●なるべく多くの利益を生み出そうとするよりも、
 ソフトウェア設計における美を達成することに多くの力を注ぐ
引用:『ソフトウェア・ファースト』発行:日経BP社 著者:及川卓也 ( 図2-9 著者が『ソフトウェア企業の競争戦略』を参照して作成したモノを変更して使用)

 

ちなみにこの、成功体験が足かせになってしまうという話は、国レベルでも企業レベルでも起きてしまうことです。

世界ではじめてオンラインDVDレンタルをスタートさせたネットフリックス。競合巨大DVDレンタル企業ブロックバスターもまたネットフリックスに追随し、オンラインレンタルを行っていたのですが、その後セブンイレブンから迎え入れたCEOによって事態が悪化します。CEOは自身の小売業での成功経験をブロックバスターに持ち込み、オンラインレンタルから店舗ビジネスに回帰する方針を打ち出します。店舗でUSBメモリーに動画をダウンロードするなど時代錯誤のアイディアを実行に移した結果、倒産してしまいます。

日本も、かつての栄光を引きずり「ITなんてハードウェア・ビジネス効率化のツールだ」と勘違いを続けていると破綻してしまうかもしれません。

 

とりあえず、システム開発ではなくソフトウェア開発と言ってみる

本書の観念的な部分だけまとめて記事にさせていただきました。肝心のソフトウェア・ファーストな企業になっていくための組織変革の方法などは、本書をお読みください。「あーそういうことか」という発見・納得できる情報が多い名著です。

補足として「狩野モデル」という品質の基準のお話がおもしろかったです。

●当たり前品質 (充足されてても当たり前とされる品質)
 ホテル予約アプリ > 検索・予約機能

●一元品質 (充足されていれば満足につながる品質)
 ホテル予約アプリ > 表示されるホテルの数

●魅力品質 (充足されていれば満足につながるが、不足しても仕方ないと思われる品質)」
 ホテル予約アプリ > チェックアウト当日朝プッシュ通知でチェックアウト時間を教えてくれる

と、品質を段階に分けて考える方法なのですが、とてもわかりやすいですよね。「魅力品質は、他社が真似をすれば「当たり前品質」になり下がってしまう」と説明されれば、すぐにソフトウェア開発の永続的改良の必要性が理解できます。

 

仮のモデルによる品質の5分類

当たり前品質
(基本品質)
「あって当たり前」「ないと不満」と感じられる品質要素アクセル・ブレーキ・ハンドル
一元品質
(性能品質)
「あれば満足」「ないと不満」と感じられる品質要素燃費・車内の広さ
魅力品質「あれば満足」「なくても仕方ない」と感じられる品質要素インターネット接続
無関心品質「あってもなくてもかまわない」と感じられる品質要素見えない部分の塗装
逆品質「あると不満」「ないと満足」と感じられる品質要素
(人によって感じられ方が異なる)
エンジン音
引用:『ソフトウェア・ファースト』発行:日経BP社 著者:及川卓也 ( 著者が作成したモノを変更して使用)

 

筆者は、日本は品質の考え方を捉え違えているとも説明しています。たしかに日本は、当たり前品質を高めることに躍起になり、魅力品質を磨くことをおろそかにするなど、未だ「Made in japan」という過去の栄光に足を引っ張られている傾向があります。

日本のDXがなかなか進まないのは、DXとはなんぞやを強く説明できる人が少ないからということもあると思います。本書は、その答えを非常に分かりやすく解説している本です。ぜひ本書をなんども読み返し、一人でも多くの日本人がDXなんたるやを強く話せるようになっていただければと思います。

 

■参考
『ソフトウェア・ファースト (出版社:日経BP 著者:及川卓也)』

 

執筆者
リビルダーズ編集部

-DXナレッジ
-