はじめに
今回は、及川卓也さんの著書『ソフトウェア・ファースト』を紹介します。
<著者のプロフィール>
及川卓也
大学卒業後、DEC(ディジタル・イクイップメント・コーポレーション)に就職してソフトウェアの研究開発に従事する。その後、Microsoft や Google にてプロダクトマネージャーやエンジニアリングマネージャーとして勤務の後、プログラマーの情報共有サービスを運営する Increments を経て独立。2019年1月、テクノロジーにより企業や社会の変革を支援する Tably 株式会社を設立
著者である及川さんは、「Google日本語入力」の開発に携わった方です。
この本を読むことで、DXやITを駆使したイノベーションについて理解が深まります。
IT企業のみならず多くの企業で、ITを手の内化することの重要性が説かれています。
この本は、ITエンジニアなどを志望している就活生やDXを進めたいと考えている経営者におすすめです。
それでは、以下の内容に分けて本の内容をまとめ、最後に感想を述べたいと思います。
- ソフトウェア・ファーストとは
- GAFAMに置いて行かれた日本企業の課題と復活への提案
- ソフトウェア・ファーストの実践
- ソフトウェア・ファーストなキャリア構築
- 感想
※本の要約ではなく、僕が吸収したことのアウトプットです。多少内容が異なっている部分や僕の意見が混ざっています。記事の削除を希望される著作権者の方は、お問い合わせフォームよりお知らせください。即刻、削除いたします。
ソフトウェア・ファーストとは
まず、時代の流れについてです。
パッケージ製品の販売からサービスの提供へ
音楽の例を見てみましょう。
以前人々は、アナログレコードを使って音楽を聴いていました。
そこから、カセットテープに移行します。
この頃までは、情報をアナログとして扱っていました。
連続的に変化する量で表現する方式です。この方式で表されたデータをアナログデータといいます。
出典:『令和6年 イメージ&クレバー方式でよくわかる かやのき先生のITパスポート教室』
そして、CDの登場です。
僕は、小さい頃CDが家にたくさんあったことを覚えています。
CDは、データをデジタル方式で記録します。
連続する量を細かく区切って「0」と「1」に置き換えた不連続的な量で表現する方式です。この方式で表現されたデータをデジタルデータといいます。
出典:『令和6年 イメージ&クレバー方式でよくわかる かやのき先生のITパスポート教室』
CDが主流であったものの、その後、MP3の登場により、大きく社会構造が変化します。
ファイル形式の一つ。「音楽配信やポータブルプレーヤなどで使われる。国際標準規格。非可逆圧縮。」
出典:『令和6年 イメージ&クレバー方式でよくわかる かやのき先生のパスポート教室』
音楽をコンピュータ上でファイルのやり取りという形で交換できるようになったのです。
ウォークマンやiPodの流行もこの頃です。
ただし、まだこの時は音楽を iTunes で購入していたため、パッケージ製品を売買していました。
ところが、Spotify や Apple music など、サブスクリプションサービスが開始します。
パッケージ製品の売買から、サービスを受けられる権利の売買に変化したのです。
人々は、「体験」という価値を、より重要視するようになったと言えます。
これを象徴するのが、SaaS の普及です。
SaaS(Software as a Service)は,クラウド事業者が,アプリケーションをネットワーク経由で提供するサービスです。「サービスとしてのソフトウェア」という意味です。ソフトウェアの導入や更新,保守にかかる手間や費用を低減できます。身近な例では,「Microsoft 365」,「Gmail」や「Yahoo!メール」のWebメールなどがあります。
出典:『令和6年 イメージ&クレバー方式でよくわかる かやのき先生のパスポート教室』
僕も、このサイトのサーバーをレンタルして使用しています。
このように、サービス化したことで、ユーザーの情報をリアルタイムに分析することができるようになりました。
より、顧客が求めていることを把握しやすくなったのです。
プロダクトの開発手法も変化します。
以前は、ウォーターフォールと言われる開発手法が用いられることが多かったですが、アジャイル開発手法が導入されるケースも出てきています。
また、DevOpsといわれる、開発者が製品を開発して終わりではなく、運用にも継続的に関わっていく体制がとられるようになってきています。
(用語をここで解説するのがめんどくさいため、『令和6年 イメージ&クレバー方式でよくわかる かやのき先生のパスポート教室』を読むことをおすすめします)
サービス化によって、顧客のニーズをリアルタイムに把握できるようになり、プロダクト開発手法も合理的に変化してきたのです。
ただ、注意点もあります。
本書の言葉を借りますが、「ユーザーのニーズを追えば新たなプロダクトの企画が生まれるわけではない」という点です。
よって、「より深いレベルのユーザー理解」が必要になります。
これについては、以前紹介した『キーエンス解剖』にも似たような内容がありました。
ソフトウェア・ファーストの意味
「ソフトウェア・ファースト」とはなんでしょうか。
これは、「IT(とそれを構成するソフトウェア)活用を核として事業やプロダクト開発を進めていく考え方」だそうです。
本書に書いてあった大事そうなことを簡単にまとめてみます。
- 手法の理解より、思想や姿勢が大切
- プロダクト企画の前段階からプロセス最適化を図るべき
- ソフトウェアの特徴を理解した上で、プロダクトや事業開発の全てを変えていく
- 変化しないもの(ビジョンやミッション、それに関連する社会課題、価値観)を理解することが大切
- 考え続けることが何よりも大切
GAFAMに置いて行かれた日本企業の課題と復活への提案
よく「失われた30年」という言葉を耳にするようになりました。
日本はITの波に乗り遅れ、時価総額ランキングに名を連ねた日本企業はみるみるアメリカや中国の企業に越されていきました。
現在、僕は Apple が製造した MacBook で記事を書き、iPhone を手に Google で検索しています。
欲しいものがある時は、Amazon で購入し、暇なときは X を眺めています。
このように、日本の企業がITの波に乗れなかった要因を、著者は3つに分けています。
要因①:ITを「効率化の道具」と過小評価
ITには、事業を大きくスケールするポテンシャルを秘めています。
通常、何か新しいことがあると、多くの人は学ぼうとします。
しかし、ITのことになると多くの人は詳しい人に丸投げするようになります。
これが、日本のSIer文化を形作りました。
サービス化する社会で、顧客の情報をリアルタイムに分析してサービスをブラッシュアップし続けないといけないのにも関わらず、SIerに丸投げしていては、時代の変化に対応することができません。
著者は、IT企業に関わらず、事業会社は内製化比率を高めていく必要があると主張しています。
要因②:間違った「製造業信奉」から抜け出せない
日本は、昔製造業で多く世界を席巻していました。
トヨタの「カンバン方式」や「カイゼン」などは有名です。
それを、ソフトウェア開発の場に持ち込み「ウォーターフォールモデル」として採用しています。
ただし、製造業のプロダクト製造モデルとウォーターフォールモデルは、全てが共通しているわけではありません。
製造業においては、特定の部品を他社に外注することはよくあることです。
しかし、それは自分で製造するのに比べてコストが安くなる時だけです。
合理的な判断に基づいています。
一方、ソフトウェアの世界においては、何も考えずにとにかく外注する場面が多いそうです。
サービス化する社会において、SIerなどの企業に依存度が高くなってしまうのはリスクでしかありません。
要因③:サービス設計〜運用面での誤解
日本企業がITの波にうまく乗れなかった最後の要因は、ユーザーが本当に求めているものを作れなかったからだそうです。
これは、『新・生産性立国論』にもありました。
例えば、品質面では、技術ベースで製品を開発している節がところどころで見られます。
「こんな新技術が登場したから、新しい機能を搭載してみた」などです。
その機能は、顧客の体験価値を向上させているでしょうか。
また、セキュリティ対策についても同じことが言えます。
ただ単に、過剰なセキュリティ対策を施すことを顧客が本当に求めているのでしょうか。
例えば、Google や Amazon は顧客情報をたくさん収集していますが、そのことに不満を持っている人はあまりいないでしょう。
それは、情報を取られていても、それ以上に価値あるサービスとして対価を受け取っているからです。
今一度、顧客が何を求めているのかをしっかり考える必要があります。
本書には、日本の企業が今後どんな戦略を取るべきなのかなど、さまざまな提案が書かれていましたが、ここでは省略します。
ソフトウェア・ファーストの実践
心得
まず、社内でDXを進めるにしても、ソフトウェア・ファーストを実践するには、さまざまなものをITに置き換えていくだけでは足りません。
「第2の創業」に近い意識で挑まなければならないそうです。
根本の組織から変えていく必要があります。
内製化
事業を行う上で、内製化することはとても重要だそうです。
以下の2つの理由があります。
- 社内にノウハウが貯まるから
- 仮説検証を行うスピードをはやめられるから
- 企画から運用までの一貫した流れで考えることができるようになるから
仮に、外部に委託する場合でも、極力コントロール権を持った状態にしておく必要があります。
また、企業が大事にすべきことは以下の3つだそうです。
本書から丸々引用します。
- 手段が変わっても変わらない、高く掲げた企業理念を大切にする
- エンゲージメント強化への取り組みを妥協しない
- 意思決定者が技術に対する理解を深める
マネージャが変わる必要性
日本の多くの企業では、出世していくと人を束ねるマネージャー的なポジションにつくことが多いです。
例えば、学校の先生が教えるのがうまく、出世していくと子供と触れ合う機会が少ない教育委員会にいくことなどがあります。
他にも、プログラミングスキルが高く、優秀なエンジニアは出世して、プロジェクトリーダーになったりします。
ここで、注意する必要があるのは、マネージャーも専門的なスキルが必要になる職種であるということです。
マネージャーの最大の使命は、チームメンバーの力を最大限引き出すことです。
ただ単に、人事評価をすることではありません。
強い組織を作っていく必要があります。
漫画『ONEPIECE(ワンピース)』でも、強い組織は、一人一人が高いパフォーマンスを発揮しています。
『進撃の巨人』でも同じです。
団長になる前のエルヴィン部隊は、死人が少なかったそうです。
それも、エルヴィンというメンバーの力を最大限発揮させるマネージャーがいたからでしょう。
一人一人が強くなることの重要性を説いたメッセージにトヨタの豊田章男社長の言葉が有名です。
「トヨタの看板がなくても、外で勝負できるプロを目指してください」
まさに、組織内競争力が高まり、組織として強くなっていくための言葉です。
組織変革ステップ
ソフトウェア・ファーストな組織を構築していくために、著者は必要な職種をまとめています。
- プロダクトマネージャー
- ソフトウェアエンジニア
- エンジニアリングマネージャー
- デザイナー
- QA(Quality Assurance/品質管理)エンジニア
何より大切なのは、全員がプロダクト志向になることだそうです。
プロダクト志向とは、いかにユーザーの体験価値を最大化できるかを考えることを指します。
可能な技術ベースでサービスを考えるのではなく、顧客にとって価値あるものが何かを考えるのです。
では、プロダクトマネージャーとエンジニアリングマネージャーにはどんな違いがあるのでしょうか。
丸々本書から引用させていただきます。
プロダクトマネージャーとはプロダクトの仕様から機能開発、運用に至るまで全体の価値を高めることを職務とする「製品責任者」です。プロダクト開発は、エンジニアリング組織だけでなく法務、マーケティング、広報、営業、サポートなど多岐にわたる組織が連携しながら進んでいきます。これらを一つのプロダクトチームと見立てて、組織横断的にチーム運営していくことが求められます。
エンジニアリングマネージャーは、「開発組織の責任者」です。組織に所属する各種エンジニアに業務を振り分け、進ちょくを見ていくのはもちろん、エンジニア1人1人の成長を支えることが重要な役割になります。
よって、プロダクトマネージャーとエンジニアリングマネージャーには、時として利害対立が起こります。
プロダクトマネージャーとしては、品質の高い製品を作りたいため、経験豊富なエンジニアに参加してもらいたいと思っても、エンジニアリングマネージャーとしては、新人エンジニアに経験ん積ませたいと考えている場合があります。
そういった場合は、話し合うことが大事だそうです。
ここでの分類はあくまで抽象的なもので、同じ職種でも実際の企業の事業内容によって、求められるものは異なります。
経営陣の役職
次に、責任者についてです。
役職名 | 役割 |
---|---|
CIO(Chief Information Officer) | 社内のITシステム、デジタライゼーションを担当 |
CTO(Chief Technology Officer) | DX推進のような新規プロダクト開発の統括 |
CDO(Chief Digital Officer) | DX推進のような新規プロダクト開発の統括 |
VPoE(Vice President of Engineering) | 開発本部長やエンジニアリング組織の担当役員的立ち位置 |
小さいの組織の場合は、CIOを置かず、CTOが全てを統括する場合もあるそうです。
逆に大きい企業でプロジェクトも大きくなると、VPoEをCTOの下に置いたり、横並びで置いたりするそうです。
これらの組織の中における責任者は、本当に必要か考える必要があります。
組織によって必要な場合と、置かない方が良い場合があるそうです。
エンジニアの採用難をどう乗り越えるか
本書には、主に3つ取り上げられていました。
- 給与を見直す
- 評価制度を見直す
- 働き方を含めた組織文化を見直す
ソフトウェア・ファーストなキャリア構築
T型のスキル構築とπ型のスキル構築
例えば、エンジニアの例を挙げます。
特定の分野に絞って専門性を高めていく方法は、I型のスキル構築といいます。
とはいえ、何かを開発する際は、他の分野と連携する必要があるため、薄く広く全体的な知識が必要になります。
そこで、専門的なスキルと、教養全般的なスキルをあわせたT型のスキル構築が必要になります。
さらに、他社と差別化し、自分の強みを磨いていく方法はいくつか存在します。
- 専門以外にも深める領域を作る(π型のスキル構築)
- 専門を深める
- 専門を広げる
これに関しては、『ジェイソン流お金の稼ぎ方』がおすすめです。
著者の及川さんが本の中で述べていたフレーズがとても印象的でしたので引用させていただきます。
エンジニアは一生勉強し続け、新しいスキルを習得し続けなければならない
ソフトウェアエンジニアの3大キャリア
主に、3つのジャンル「技術」「人・組織」「プロダクト・ビジネス」があり、以下の3つのキャリアがあるそうです。
- エンジニアを極める
- エンジニアリングマネージャーを志向する
- プロダクトマネージャーを志向する
これらの職種にあった評価制度を用いるべきであり、昇格すると自動的にマネージャーになる人事制度は見直すべきでしょう。
それぞれのキャリアは独立しており、もしエンジニアからエンジニアリングマネージャーになる場合も、れっきとした職性転換になります。
ここで重要なのはやはり、全員がプロダクト志向を持つことです。
理想を諦め、技術的に可能なものに逃げてはいけません。
その他職種
この本では、他にもデザイナーやプロジェクトマネージャー・専門スキルを極めたデータサイエンティストなどについても触れられています。
感想
今回紹介した『ソフトウェア・ファースト』は内容が膨大で、全てを紹介することはできませんでした。
「ソフトウェア・ファーストの実践」において、主に組織改革についてまとめましたが、本の中には、企画から製品開発までに関する事柄も紹介されています。
この本を読んで、自分の所属する組織を見つめ直してみましょう。
僕自身、自分の所属している会社を見つめ直すと、かなり内製化している方だと思いました。
社内のインフラは全て社内のエンジニアの方が開発・運用しています。
それが絶対的な正解ではないかもしれませんが、ソフトウェア・ファーストな考え方の重要性はとても痛感します。
おわりに
この本は、特に就活をしている大学生に読んでほしい本です。
業界構造などは、インターネットで調べるとたくさん情報が出てきます。
しかし、俯瞰的な情報はなかなか手に入らないものです。
SNSなどで細かな情報を得ることも大事ですが、たまには読書で体系的な整理もしてみてはいかがでしょうか。
【著作権者(著者、訳者、出版社)の方へ】
当記事では、本が好きという方に対して面白い本を紹介することを目的としています。
書籍上の表現をそのまま使うのではなく、自分の言葉で描き直すように心がけています。
また、本に対してネガティブな印象を与えないことはもちろん、ポジティブな印象を与えられるように記事を執筆しています。
しかし、万が一行き届かない点があり、記事の削除を望む所有者様がいましたら、お手数ですが、
・Twitter DM:
・メール:
all.roads.lead.to.rome.shin@gmail.com
までご連絡いただけますと幸いです。
何卒よろしくお願いします。
コメント