ソフトウェア・ファースト

3月頃に読了し読んでから少し期間が経ってしまいましたが、振り返りの意味も込め、学びの多かった『ソフトウェア・ファースト』という書籍を読み返し記事にしました。

 

本書を読もうとしたきっかけ

私は情報システム部門に所属しており、DX(デジタル・トランスフォーメーション)を追い求める立場の人間である以上、本書は読まなければならない一冊だと感じていました。

データ・ドリブン・エコノミーをちょうど読み終えそうな時に次の一冊として手に取らせていただきました。(データ・ドリブン・エコノミーとの順序性に意図はありません。)

 

著者について

及川 卓也さんという方の著書でMicrosoftやGoogleでご活躍された後、現在は独立されTably株式会社の代表取締役としてご活躍なさっている方です。IT業界で”ソフトウェア・ファースト”という言葉をよく耳にするようになったのも、及川さんのこの書籍できっかけであるというのが私の認識です。

 

参考までに先日のTOYOTAとNTTの間で行われた共同記者会見においても、このソフトウェア・ファーストという言葉が用いられています。

 

読書からの学びや気づき

ここからは、本書からの学びや気づきを書かせていただきます。

 

私の学びや理解ベースで記載をしていますので、必ずしも本書の表現と一致するわけではありません。本書はIT業界の状況分析や組織論、さらにはソフトウェア・ファーストを実践する上での具体的な方法論やキャリアプランニングと内容が多岐にわたります。

そのため、ここで書かせて頂いているものは、”今の私”に響いた内容に特化しています。他の方が読まれたら、異なる領域が刺さる方もいらっしゃると思います。それだけ示唆に富む一冊ですので、興味のある方は是非購入をお勧め致します。

 

産業のサービス化とSaaSの普及

  • 「所有」が価値を持つ時代から「利用」が価値を持つ時代へ、さらには「体験」が価値を持つ時代へと変化している
  • サービス化の流れを支え、一大分野にしたのがソフトウェア
    • SaaS(Software as a Service)は、ユーザが使う完成形としてのソフトウェアをクラウドの形態で提供するもの
    • Saasはユーザが利用し続けるかぎり継続的に収益が発生する。一方で使わなければ解約されてしまうリスクがあるが、使われ続けられるよう努力と改善を続ければ会社が成長し続ける

サービス化を支えるプロダクト開発手法の変化

  • サービス化する社会に合わせたプロダクトを開発するには、開発手法も変えていく必要がある
    • 変革が必要なのはプロダクトの企画、開発、運用手法、技術だけではなく、それらすべての変革を推進する人と組織も含まれる
  • 重要なのは今普及している手法を学ぶだけではなく、その背景にある思想を理解し、変化し続けること
  • 現在はユーザのニーズも多様化し、ユーザが存在しない市場、新しい市場を想像することが求められている
    • ユーザのニーズを追えば新たなプロダクトの企画が生まれるわけではない
      • 必要なのは、より深いユーザ理解。機能ではなく観察を通して得られる理解
      • ユーザの課題や求める価値を抽出し、それに対して最適な解決策を模索する必要がある

ソフトウェア・ファーストとは

  • マーク・アンドリーセン氏の「Why Software is Eating World」の世界が近づき、多くの産業がソフトウェアによってディスラプトされている
  • 「ソフトウェア・ファースト」とは、IT(とそれを構成するソフトウェア)活用を核として事業やプロダクト開発を進めていく考え方
    • 企業がソフトウェア・ファーストを実践するには、ソフトウェア技術を理解し、事業に活用できる人材が必要
    • このような人材を育て活かせる組織と失敗することを前提に、作っては壊すことを良しとする文化も大切
  • ソフトウェア・ファーストで最も大事なことは、変化しないものを理解すること
    • ビジョンやミッション、それに関連する社会課題や価値観といった”変わらないもの”を理解し、ソフトウェアという変化し続ける手段を用いて、目指すべき世界観を成し遂げるために考え続けることが重要

ここで言うソフトウェア・ファーストで大事なことを、私の中で理解できるようにするために、私なりのイメージを書いてみました。

ソフトウェアとは、成し遂げるべきビジョンやミッションを達成するために用いる手段の一つです。ビジネスの成功のために、まずはこの変わらない普遍であるものを理解します。

そこから生まれるソフトウェアはビジネスにおける中核となり、利用するユーザとともに変化し続けるものでなくてななりません。

一方で提供する側にとっては、より良いUX(ユーザー・エクスペリエンス)の提供に向け考え続けなければならないということを意味しているのだと理解しました。

「ソフトウェア開発力の競争」に破れた日本

  • 各事業会社に最適化されすぎたITシステムとSIerの功罪
    • 要求の要件化まではシステム担当者、以降のシステム設計と実装はSIerに委託するといった結果、ITシステムが現状の業務に最適化され過ぎて、これから導入予定のパッケージ(PKG)ソフトに大量のカスタマイズを施さなければならない
    • ITを駆使して事業会社の事業価値を高めるために存在するSIerが、自分たちのビジネスモデルの性質上、本当の意味での価値向上に向けて伴奏しづらい側面がある
        • 従来のSIerとの付き合い方では変化に追従できない。ITが事業の中核を支える存在を担っていく中で、ITをすべて外部に委託するのはリスク以外の何者でもない

  • デジタル・トランスフォーメーションは事業と組織の双方に変革を起こすことが目的
    • 組織変革にはITの専門家の育成や採用が必須であり、自ずと内製化比率を高めていくことが重要になっていく
    • 事業会社が自走できるようになたら、DXに対する外部からの支援は終了となる
      • DXの本質を突き詰めていくとSIerは関連する案件をやり続けることで存在価値を最小化していくことになる
      • 事業会社がITシステムの内製化を勧めていけばいくほどSIerは将来的に小規模化し数も減少していく
        • 私の感覚では現在の状況は自走の前段階で共走をしているという感覚が強いです。ですがここで述べられている内容について、SIerに近い業種に属している私も考えなければならない問題の一つであるかもしれません。

          事業会社がSIerの必要性を求めなくなった社会で何ができるのか。何を価値として提供できるのか。考え続けなければならない問題です。

DXの定義とその本質~バズワードに踊らされないために~

  • DXの定義(『DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~』より)
    • 企業が外部エコシステム(顧客、市場)の破壊的な変化に対応しつつ、内部エコシステム(組織、文化、従業員)の変革を牽引しながら、第3のプラットフォーム(クラウド、モビリティ、ビッグデータ/アナリティクス、ソーシャル技術)を利用して、新しい製品やサービス、新しいビジネス・モデルを通して、ネットとリアルの両面での顧客エクスペリエンスの変革を図ることで価値を創出し、競争上の優位性を確立すること
  • DXを進めるためには内製化が理想
    • DXのような新たな事業を興す時は、仮説検証を行うスピードと、企画から運用面まで一気通貫のIT活用が必須になる
  • DXの肝は”IT活用を「手の内化」できるかどうか”
    • 自社プロダクトの進化に関わる重要な技術を自分たちが主導権を持って企画・開発し、事業上の武器にしていく
      • この言葉は私の中に非常に響いた言葉です。私の所属チームは典型的な外部委託によるウォータフォール開発です。

        外注に至る論理としては、この言葉の裏を返すような表現ですが、情報システム部門管轄のシステム群は社内の重要度の位置づけが低く(自社プロダクトの進化に関わりが薄く)、多くの社員のリソースをかけてまで面倒を見る必要がないという考えが強いです。

        ですがこの論理が必ずしも間違っているとも思い難く、私達情報システム部門の人間に求められるべきは、どのシステムが自社プロダクトの進化に関わる重要な技術に該当するのかを見極め選定し、そこにリソースをかけられるようコントロールできるようになることなのではないかと考えています。

  • 「モード1」と「モード2」
    • 「モード1」はSoR、「モード2」はSoEと呼ばれ、IT調査会社のガートナーは企業のITシステムを2つのモード(バイモーダル)に分類して考えることを推奨している
      • このSoRとSoEの考え方は、いつかもっと深く考察をしてみたいと考えています。今回は必要最小限に留めます

これからの「強い開発組織」を考える

  • 従来型の情報システム部門の中には、自分たち自身で「事業サイドの指示を実行するだけの下請けチーム」にしてしまっているケースが散見される
  • あらゆる企業がソフトウェア・ファーストを実践する上で必要な一手は、できるかぎり開発を内製化すること
    • 内製化の最大のメリットはスピード
      • 変化の激しい現代において、完成度を高くする打ち手は実際に使われないとみえてこない、スピーディに対応し続けるのはもはや宿命
      • どんなに委託先のエンジニアが優秀で、発注者のビジネスを深く理解していても、過去の経緯や社内事情といったコンテクストを汲んで臨機応変に対応するのは難しい
    • 内製化の重要な理由はノウハウの蓄積にもある
      • 現代のプロダクト開発は仮説検証の繰り返し。その中でプロダクト開発の一部を外出ししていると、その知見が内部に蓄積されない
  • 重要なのは100%の内製化を目指すことではなく制御権を保持すること
    • 制御権を持つというのは、何を作るかを決定し、どのような技術を用いて作るかを決定し、開発の全体を指揮すること
    • 自社で巻き取れないということは、すなわち作ったその日から負債を抱えているようなもの


本書を読み終えて

本書は日本のIT企業や情報システム部門が抱える問題や状況においてどうすべきか・あるべきかを、筆者の方の視点で述べてくださっている一冊だと感じました。私も情報システム部門に長く在籍していますが本当に勉強になった一冊です。私自身も本書を読みながら、自社の状況においてどうあるべきかを自問するような事が多かったです。

私は長年情報システム部門に在籍しているにも関わらず、外注という甘えに流されこれまで内製化から逃げていた所があります。本書を読んだことで、「周りを変えるためにも、自分がまず学び行動を起こせるようにしなければならない。」とより強く思うようになり、ここ最近始めだしたプログラミング学習の背中を押してくれた一冊にもなってくれました。

当書籍はIT企業や情報システム部門に在籍されている方であれば、読んだほうが良いを通り越して、読まなければならないくらいのレベルの書籍ではないでしょうか。それくらい学びの多かった一冊でした。