『ソフトウェアファースト』のアウトプット

スポンサーリンク

はじめに

ソフトウェアファーストを読みました。
この本は日本のコンピュータ・サイエンスの第一人者 及川卓也さんが著したもので、ITを駆使したイノベーションやDX(デジタル・トランスフォーメーション)を有効に組織に取り込む方法について書いたビジネス書籍です。

技術書ではなくビジネス書なのが特徴的だと思っていて、経営層・人事などビジネスサイド向けに平易な文章で書かれています。

印象的な部分をピックアップして自分用のメモアウトプットとして残しておきます。

参考リンク:ソフトウェアファースト

サービス化する社会

音楽業界が、レコード→カセットテープ→CDとデジタルシフトし、MP3となりメディアが不要になり、iPod→月額課金サブスクリプションへと楽曲を購入する体験から利用権を取得する体験へと変化したように、いまやあらゆる業界がサービス化する社会になっています。その理由として以下を挙げています。

  • インターネットが社会基盤として定着し、あらゆる場所が「コネクテッド」になった
  • ミレニアル世代を中心とした「所有」から「シェアリング」への価値変化

このサービス化の流れを支えたのがソフトウェア技術の発展、中でもSaaSの台頭であり、IT事業者はパッケージソフト販売型からサブスクリプション型にビジネス構造を変化させたとしています。いかにして利用し続けてもらうか?がビジネスの重要指標となり、伴ってプロダクト開発手法もアジャイル開発やDevOpsが好まれるように変化してきました。

この技術変遷の整理はめちゃくちゃ勉強になります。LTVの概念は何も単品通販特有ではなく、社会のサービス化に伴って全業界的に重要になっていますし、ソフトウェア産業ではLTV向上のためのフレームワークや手法が単品通販業界よりも普及していることも分かります。エンジニアコミュニティが知識をオープンに公開して全員で幸せになろうとする文化である背景が大きいと思いますが、これらを取り入れることで事業をより推進できると確信して実践している最中だったので強く腹落ちしました。

凄まじい破壊力を持ちソフトウェアの特徴を理解し、プロダクトや事業開発のすべてを変えていくことが、これからの企業の競争力を左右します。また企業がソフトウェア・ファーストを実践するには、ソフトウェア技術を理解し、事業に活用できる人材が必要です。このような人材を育て、活かせる組織が必要です。さらには、失敗することを前提に、作っては壊すことを良しとする文化も大切です。

とも述べられており、めちゃくちゃ分かりみがあるものの、失敗を前提にスクラップアンドビルドを推奨し続ける文化は利益を出すことと相反するので難易度が高いとも感じます。それこそ経営層からのトップダウン的な文化創りが肝なんだろうなと思います。

日本がIT産業の競争力を失った理由

理由の一つとして記載があったITを「効率化の道具」と過小評価についてメモです。及川さんだからこそツッコミができる耳の痛い目を背けたい実情な気がしました(汗)。

  • 効率化や省力化だけがITの可能性ではない
  • ITには既存産業のルールを壊し、新たなビジネスに作り替えるだけのパワーがある。
  • これにいち早く気付いたのは米国企業だった
  • 日本企業の多くは、正常性バイアスで過去の成功体験(製造業による戦後復興)に囚われた
  • モノづくりこそが日本の「正業」であり、ITは「虚業」と誤認した
  • 結果、自社にIT活用ノウハウが蓄積されない「SIer丸投げ文化」が形成された
    • 多層下請け構造によって上流SIerには実装経験の乏しいエンジニアを生み、下流SIerには事業運営目線の乏しいエンジニアを生んだ
    • 事業会社はITを特別な技術と思い込み、成長に不可欠な要素は学んで活用するのにITだけはその発想がない

ソフトウェアファーストの実践に必要な変革

DXの本質的な意味

経済産業省がまとめた DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~ では、DXを以下のように定義しています。

企業が外部エコシステム(顧客、市場)の破壊的な変化に対応しつつ、内部エコシステム(組織、文化、従業員)の変革を牽引しながら、
第3のプラットフォーム(クラウド、モビリティ、ビッグデータ/アナリティクス、ソーシャル技術)を利用して、
新しい製品やサービス、新しいビジネス・モデルを通して、ネットとリアルの両面での顧客エクスペリエンスの変革を図ることで価値を創出し、
競争上の優位性を確立すること

ITを過小評価した事業会社は、必要なシステム開発を外部に委ねるしかなく、スピーディーな判断ができず、ITを事業の武器にできないためITを活用した新サービス展開が弱くなります。故に、DXを進めるためには内製化が理想だと説いています。開発ノウハウが自社に貯まる・仮説検証をスピードが高まる・企画から運用まで一気通貫で見れるなどのメリットがあるからです。

ポジション別に求められる意識の変化

  • 経営陣は先頭に立つ、ソフトウェアの理解を深めなければいけない
  • マネージャが変われば組織は変わる、担当組織のメンバーが活躍できるようにサポートするのがマネジャーの最も重要な役割
  • 現場社員が常に主役、しかし経営陣同様にソフトウェアの理解は深める必要がある

『組織はリーダーの器以上にならない』という言葉に近しいニュアンスな気がしました。まずは自分を変容させていきます。

変革で全員100%満足させるのは不可能

  • 目的に沿わない人、新しい方向性に同意できない人まで救わなければならない理由はない
  • 「今いる社員」を満足させるより「将来の社員」を満足させる
  • とはいえ、賛同者・協力者は必要。社会変容の閾値は25%の人々の変化
  • 変わりものが今までとは違ったことを始めると、必ず軋轢が生じる。経営陣のサポートが不可欠

自分が会社でやろうとしているのは変革ですがそれに賛同してもらうのは25%くらいで良いのだと気付かされ、肩の荷がいくらか降りました。

変革の拠り所となるミッション

  • 適度な抽象性を持ち、事業と強い結びつきを持たせる
  • 具体的すぎるとピボットしにくく、異なる事業を立ち上げる余地は少なくなる

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

開発の外部委託する問題点

  • スピード
    • 現代のソフトウェア開発の基本はイテレーション(=仮説検証サイクル)
  • ノウハウ蓄積
    • 企画、仕様、設計、実装、品質確認、リリースすべてにおける失敗体験こそが貯めるべき知見

外部委託しても通信不確実性が高まってしまうデメリットが大きいということだと思いました。

また、内製化してもエンジニアの雇用を維持できるのか?のよくある誤解に対して、心配は杞憂で終わる。もしエンジニアが不要になるならばその会社は潰れると言っても過言ではない。少なくともデジタル関連の事業は育たない。雇用の心配をする前に自社の将来を心配しましょう。と一蹴していたのは及川さんらしくて印象的でした。

全員がプロダクト志向

  • 事業サイドの人間がテクノロジーを学ぶ
  • 同様に、エンジニアリング組織もプロダクト志向で物事を考える組織に変わっていかなければならない
この記事の内容が役に立ったと思いました、SNSで記事を共有していただけますと幸いです。