ソフトウェアファースト第２版　あらゆるビジネスを一変させる最強戦略

投稿元：

レビューを見る

ソフトウェアには、事業やプロダクトのあり方を根本的に変える力がある。

クラウド化されたことで、顧客につながり続けることができるようになったためである。

従い、どんなプロダクトも、継続的に提供する価値を進化させることが、可能となった。
これにより、作って終わり、という一度限りのビジネスは、継続的に利用してもらうリカーリングビジネスに進化する。

これを実現するためには、ソフトウェアの特徴を理解して手の内化して、すばやく進化させていくことが、重要となる。

プロダクトの開発にあっては、プロダクトマネジメントを行い、プロダクトを育てる意識を醸成させる。また、アジャイルによりすばやく試すこと。リリースして終わりでなく継続進化のためにDevOpsの思想を取り入れること。

投稿元：

レビューを見る

　これまで述べてきたように、体験価値が重要性を増し、すべての企業が事業のサービス化を考える時代になりました。それを進めるには、ソフトウェアの活用が不可欠です。
　そのためには、高い能力を持つ社員を多く抱えることを目指すだけでなく、人の知見をソフトウェアで加速かつ増幅させることが必要です。
　ソフトウェア活用というと、単にシステムを開発、運用すれば良いと思われがちですが、ソフトウェア技術の進化は激しく、作ったアプリケーションやシステムも常に変化が求められます。言わば生き物のような存在です。必要なのは、技術や手法の理解だけではなく、思想や姿勢です。これが本書のタイトルにもなっている「ソフトウェアファースト」なのです。


　ホンダの成功は、新規事業開発に必要な心得がつまったベストプラクティスと言えます。新規事業開 発を成功させるには、その事業でのビジョンの明確化、リーダーシップの発揮、そして、必要な専門能力の獲得が不可欠です。いずれか1つが欠けていたら新規事業はうまくいきません。
　さて、DXではどうでしょう?ITやデジタルの話になった途端、「私はITの専門家じゃないから分からない」と思考停止し、あるべきものを見失ってはいないでしょうか。DXに失敗している企業は、DXに取り組む強い意志とビジョン、組織全体の協力体制や文化の醸成、それを率いるリーダーシップ、知見に基づいた技術的スキル、そして主体性――これらのどれか、もしくはいずれもが欠如しています。
　つまり、DXに失敗する企業には、「DXとは何か」への基本的な理解が不足しているのです。DXとは、単にデジタルを活用することでも、新しい技術を導入することでもありません。ビジネスモデルや業務プロセスを根本的に見直し、デジタル技術を活用してこれらを変革することです。しかし、多くの日本企業は、まだDXをただのITプロジェクトと捉える傾向にあり、真の意味での理解には及んでいないように思います。DXは「変革」です。どんな形であっても、トップが自分の言葉で明確に言語化し、それを全社員に伝える必要があるのです。


　しかし、GEの試みは失敗に終わりました。その理由を調べてみると、以下の複合的な要因が複雑に絡み合っていることが分かります。
1.組織内の抵抗:GEの各事業部は、それぞれ独立した情報システム部門を有しており、既存のレガシーシステムが確立していました。これらのシステムはすでに機能的に十分であるため、新システムであるプレディックスへの移行に対して見るべきメリットが少なく、プレディックスの機能不足が明らかになると、管理職層からの抵抗が顕著になりました。
2.外部人材への依存による軋轢と調整の失敗:GEデジタルはプレディックスを社内に普及させようとしましたが、外部から招聘したデジタル専門家たちは社内の既存文化や政治に疎く、内部のIT部門との間で意見の不一致が生じました。
3、ビジネスの統合失敗:GEデジタルは独立して運営されていましたが、これが他の主要事業部との 間で連携を欠き、デジタル戦略が全体の事業戦略と融合しない問題が発生しました。
4.財務的ブレッシャー:GEデジタルは自身の利益を追求する立場にあったため、短期的な収益が長 期的な戦略より優先されがちでした。これが、持続可能な成長より即効性のある結果を求める動き を強め、根本的なデジタル変革を阻害しました。
5、技術的な課題:既存のシステムと新技術の統合が困難であり、この急激な変更が組織内で混乱を引 き起こしました。特に、実証されたビジネスプロセスに対する影響が大きく、目に見える利益をもたらすことなく問題が生じました。
　こうしてGEのデジタル変革は、多くの教訓を残す結果となりました。
　GEの失敗からは、「組織文化を丁寧に醸成すること」の重要性も伝わってきます。専門技術や新しい 視点を持った外部人材を積極的に採用することは、競争力を高める上で見習うべき点です。しかし、GE の例から明らかなように、採用を急ぎ過ぎると問題が生じることもあります。GEでは、既存の組織と の間に対立が生じ、組織全体としての調和が取れなくなってしまいました。仮に、外部人材が持ち込ん だ新たなアイデアや技術が、既存の組織文化に適切に融合できていれば、より良い変革につなげられたかもしれません。 組織文化を変えるには、外部人材と内部人材が互いに理解し合い、共通の目標に向かって協力できる環境を整えることが必須です。このプロセスを慎重に進めることで、持続可能な成果を期待できるでしょう。
　DXに「早急なビジネス成果を求めたこと」も問題です。筆者が支援する日本企業でも、事業開始前 から「3年で単年度黒字、5年で累積黒字」という具体的な収益目標が設定されていることがあります。
　しかし、新たな事業がそもそも顧客のニーズに合っているか確認するだけでも、ある程度時間が必要で す。顧客にもまた、新たな提案に価値を見いだし、変化を受け入れてもらわなければなりません。この検証過程で、何度も方向転換(ピボット)を行う必要がある場合もあります。事業の初期段階は、試行 錯誤の連続が予想されます。成功の方程式を見つけるまで、収益目標に固執することは現実的ではありません。


図2-2:日米欧のソフトウェアに対する考え方の違い
日本企業：“標準化された設計パターンに従い、元の条件からはほとんど変更しない力 スタムまたはセミカスタム・アプリケーションの複数バージョンを大量生産 するのに向いており、現在も活躍している。(中略)しかし、それが世界を変 えることはないし、だれかが大富豪になるということもない”
米国企業：“米国人ほどソフトウエアをビジネスとして捉えている国民はほかにはいま い。(中略)会社を作って「まあまあ良質」の製品を作り、業界標準を打ち立 て、その過程で大儲けしようとしている”
欧州企業：“製品をマス・マーケットに出荷して、自分たちの素晴らしい技術からなるべく多くの利益を生み出そうとするよりも、むしろソフトウェア設計における美 を達成することに多くの力を注いでいる”


　以前、日本企業の幹部から「マイクロソフトやグーグルは100%内製しているのですか?」と聞か れた際、筆者は「当たり前です」と答えそうになりました。しかし、よく考えてみると、マイクロソフ トもグーグルもオープンソースソフトウェア(OSS)を利用しています。OSSはすべて自社が作っ た���のではないと考えると、100%内製しているわけではありません。しかし、彼らはOSSをブラッ クボックスとして扱うことはありません。自社の制御下で、必要に応じて自社のエンジニアがOSSに貢献し、必要な修正を行なっています。


◾️「ソフトウェアの手の内化」を妨げる要因
・低位安定に甘んじて挑戦しない姿勢
・間違った製造業信奉（中途半端な模倣も含む）
・製造業とソフトウェア産業のプロセスの違いに対する理解不足
・品質に関する誤解


　すでに説明したように、プロダクトの成功は、事業価値と顧客価値の最大化です。顧客価値を最大化 するには、顧客を深く理解する必要があります。顧客のニーズや課題を徹底的に分析し、それらを解決 する製品やサービスを開発するプロセスを「プロダクトディスカバリー」と言います。
　従来の製品開発では、開発チームが考案したコンセプトに基づいて製品を市場に投入する流れが一般 的でした。しかし、このアプローチでは、実際の顧客のニーズと合致しない製品が開発されるリスクが ありました。この問題を解決するため、顧客のニーズを出発点として製品開発を行うプロダクトディスカバリーが用いられるようになってきました。
　プロダクトディスカバリーを採用することで、以下のようなメリットが期待できます。
・顧客ニーズに合致したプロダクトの開発が可能になる。
・開発コストの削減や開発期間の短縮が実現できる。
・製品の市場での成功率を高めることができる。


　ただし、便利さの裏には、ベンダーロックインのリスクも存在します。特定のベンダーや技術に依存 することで、将来的な選択肢が制限される可能性があるのです。しかし、ロックインを必要以上に恐れ、 「ロックインを避けたいからXaaSは使わない」と拒むのは本末転倒です。筆者の経験からも、進化し た最新技術の恩恵を享受するには、ある程度のロックインは許容する必要があります。
　過剰なベンダーロックインを避ける一方で、選択する技術の持続可能性と将来性をしっかりと見極め ることが重要です。


　リフト&シフトの例としては、本書でも2章でも紹介したミスミが挙げられます【6】。ミスミは、 既存の基幹系システムを刷新するため、二段階にわたる「リフト&シフト」戦略を実施しました。まず、 メインフレームからクラウドへと移行し、その後アプリケーションのマイクロサービス化を進めました。 これにより、システムのアジリティ(俊敏性)を高め、Eコマース企業としての事業転換を図りました。
　ミスミの新基幹系システム「ニュートン」は、社内外のユーザー向けアプリケーション、業務ロジッ クを実装したマイクロサービス、販売・在庫管理や財務会計の機能を持つエンタープライズ層の3階層 に分けられています。ニュートンは、ローコード開発ツールを使い、開発効率と保守性を向上させ、ク ラウド環境ではAWSとグーグルクラウドを利用しています。そのため、大規模障害が発生しても、影響を最小限に抑えることが可能になりました。
　まず、クラウド移行の「リフト」は、従来のCOBOL (コボル)をそのままクラウドに載せ替える 「リホスト」で行い、その後、基幹系の全プログラムをJava (���ャバ)で書き換える「リライト」を 実施しました。これにより、2020年にはすべての基幹系システムをクラウドに移行し、その後マイ クロサービス化を進めました。受発注や入出荷、売掛金・買掛金の管理機能を共通のマイクロサービス として開発したのです。


　ネットフリックスが使っていることで有名になったのが、カオスエンジニアリングです。こちらは、テストインプロダクションのさらに先を行くとも言える、システムの耐障害性を直接検証する手法です。 テストインプロダクションでは、システムの機能や性能を検証することはできても、実際に障害が発生 した場合のシステムの挙動を検証することはできません。カオスエンジニアリングは、耐障害性を試す ために意図的に障害を発生させることで、システムの弱点を発見し、それを改善することを目的としています。
　ネットフリックスは、カオスエンジニアリングを用いて、その広範な分散型システムの耐障害性を大 幅に向上させています。彼らはカオスエンジニアリングのために開発した独自ツールを用い、ランダム にシステムの一部を停止させることで、システムが自動的に回復できるかどうかを検証します。この実 践を通じた検証で得られた課題に対応することで、システムのダウンタイムを最小限に抑え、ユーザー 体験を向上させているのです。カオスエンジニアリングは、このネットフリックスでの採用が有名にな り、さまざまな企業で導入されています。日本でも、クックパッドやヤフーが導入しています。


◾️外部依存する際の注意点
　このように、自社で開発しない場合でも、OSSを単に利用するだけでなく、積極的に貢献すること で、プロジェクトの方向性に影響を与え、自社のニーズに合った形でOSSを活用しているのです。これは、制御権を保持した状態であり、一種の手の内化と言えるでしょう。
　外部パートナーへの丸投げで足りないのはこの部分です。自社でできないタスクを外部に委託する場 合、将来的に自社で対応できる可能性を考慮しなければなりません。例えば、A社に委託した場合、そ の会社に依存することになります。A社への委託がうまくいかなければ、そのタスクを自社で引き取る か、他の会社に再委託する必要がありますが、そもそも自社で制御できていないければ、そのような選 択が難しくなります。
　筆者の知人がある大企業のシステム開発にかかわった際、まさにこの問題に直面しました。有名ベン ダーが開発したシステムには、そのベンダーの事業戦略上必要とされる特定のプロプライエタリな技術 が使われていました。しかし、その技術は当該ベンダーのエンジニアしか扱えないため、機能変更には 多大なコストと時間がかかりました。その後、同じシステムをOSSで再構築したところ、コストは劇 的に低減し、改修も迅速に行えるようになりました。


　内製化を積極的に検討すべき領域は、次の通りです。
　まず、コアビジネスに直結する領域。この領域は、自社の競争優位性を確保し、迅速な対応が求めら れます。また、コアビジネスに直結はしないものの将来にわたって自社で必要とされる技術や知識が求 められる開発プロジェクトも内製化が望ましいです。外部に依頼するよりも、自社内で専門性を高める ことで、長期的な技術力の向上が期待できます。
　さらに、素早いフィードバックやイテレーションが必要なプロジェクトも内製化を検討すべきです。顧 客の要望や市場の変化に迅速に対応するためには、開発チームが密接に連携し、迅速にプロトタイプを 繰り返し改善していくことが重要です。

　
◾️職能組織と事業主体組織の違い
　ジョブディスクリプションを作成することで、自社のエンジニアリング組織が果たす役割や、メンバー に求めるタスクがだいぶ見えてきたと思います。次は、自社の組織図全体でエンジニアをどう位置付け、 どのように組織を構成するかを考えてみましょう。
　当然の話ですが、プロダクト開発はエンジニアリング組織だけで行うわけではありません。営業やマー ケティングなどの多部署と連携しながら、大きな「プロダクトチーム」を構成して企画、開発、運営を行います。その際、エンジニアリング組織は大きく2つのパターンで連携します。
　1つ目はエンジニアやデザイナーを「職能組織」として組成し、他部署と連携するパターンです。名 前の通り職能ごとに組織化する形です。エンジニアリング組織の中でさらに職能を細分化して、フロン トエンドエンジニアやバックエンドエンジニアなどのグループを作ることもありますし、担当する事業 領域ごとにグループ分けすることもあります。いずれにしろ、当該プロダクトの開発・運営で必要とな るスキルや経験を持ったメンバーが適宜アサインされます。
　2つ目は「事業主体組織」で、事業(プロダクト)にかかわるすべての職種が1つのグループになる ように組成されます。職能組織との違いは、同じエンジニア職でも人事上の所属先が異なるという点で す。例えば自社内にエンジニアが10人いるとして、複数の事業が同時に走っている場合、事業規模が大 きく人手が必要なA事業にはエンジニアが6名、事業規模の小さなB事業とC事業にはそれぞれ2名ず つ配属されます。A~Cそれぞれに「事業部」があり、各事業部には営業職やマーケティング職なども 配属されるので、異なる職能の社員と常に一緒に動く形になります。
　よく、職能組織と事業主体組織はどちらがいいのかという議論が起きますが、ケースバイケースとし か言えません。エンジニアリング組織を立ち上げたばかりで人数も少ない場合は、職能組織のほうが機 能しやすいでしょう。仕事の進め方を暗中模索しているような状態では、エンジニアリングマネジャー と一緒に考えていく必要があるからです。一方で、複数プロダクトを開発・運営している企業では、プ ロダクトごとに開発方針や開発サイクルが違うため、職能組織で決めたルールが足かせになってしまうこともあり得ます。その場合は事業主体組織にして、それぞれの事業部で方針を定めて開発したほうが スムーズです。
　ただし、この場合でも、全社的な技術方針は 定めておく必要があります。そうでないと、プ ロダクトごとに異なる技術を使うことになり、 エンジニアの社内異動さえ難しくなります。プ ロダクト間の連携を考える時にも問題になります。また、職能組織ではエンジニアリングマネジャーが上司となってメンバーの成長を考えた指導や技術的な評価を行う一方、事業主体組織では異なる専門領域を持つマネジャーが上司になる場合があります。メンバーから見れば、技術的な指導や評価が受けにくい状態になってまうので、別の手段を講じる必要があります。
　これに関連して、職能組織はいわゆるマト リックス型組織形態を採ることもできます。マ トリックス型組織とは、職能と事業の両軸で構 成した組織です。図5-16を参照しながら説明すると、「研究開発」や「製品開発」など職能軸に構成される組織がある一方、A~C製品の事業軸で分かれた組織もあります。メンバーが複数の事業にかかわる場合は、事業軸が2つ以上になることもあり、2人以上の上司を持つ形になります。会社の方針にもよりますが、筆者はどちらかをメインの上司とし、もう片方をサブの上司とすることを勧めています。特にエンジニアの場合には、職能にあたるソフトウェア技術についてのフィードバックを与えられること から、職能組織の上司をメインとするのがいい でしょう。


◾️責任の所在を明確にする
　責任の所在を明確にすることは、プロダクトを成功に導く上で極めて重要です。ただ、日本企業の方と話をしていると、プロダクト責任者が複数人いる、もしくは極めて職位の高い方が責任者であること が少なくありません。複数の方で役割分担されているため、全員で相談して決めることは、1人では全 貌を把握しきれない場合に良いことのように思われるかもしれません。しかし、往々にしてリスクを取 らない、無難な結論に落ち着きがちです。多くの関係者の意見を聞き、議論を尽くすことは悪いことで はありませんが、全員が賛成するまで議論するのは時間の無駄ですし、そのようにして出た結果はどこ の誰もが考えつくようなものになります。同じ理由で多数決なども愚策です。
　また、責任者が事業部長1人というのも現実的ではありません。現場で日々起きる粒度の小さい意思 決定ごとに事業部長にお伺いを立てていては、迅速にプロジェクトを進めることはできません。しかし、 実際には、事業部長定例が月に一度あるからといって、それまで意思決定が先延ばしにされるようなこ とも起きてしまっているのです。
　責任者のアサインは、適切なレベルで行う必要があります。これは、プロジェクトの規模や複雑性に 応じて、責任の範囲と職位のレベルをバランス良く設定することを意味します。つまり、プロジェクト の大小や影響範囲に応じて、現場のマネジャーやチームリーダーが責任を持つべき場合もあるのです。
　例えば、アマゾンではシングルスレッド型のオーナーシップという考え方が導入されています。これ は、1つのプロジェクトやプロダクトに対して、専任の責任者を明確に決めることです。シングルスレッ ドとは、コンピューターの処理において1つのスレッド(コンピューターがプログラムを実行する際の 処理の最小単位)が連続して動作する様子を指します。つまり、シングルスレッドという表現は、責任 が一貫して1人に集中することを意味します。このシングルスレッド型オーナーシップという考え方に より、責任の所在が明確になり、迅速な意思決定と効率的な問題解決が可能になります。
　さらに、アップルのDRI (Directly Responsible Individual、直接責任を持つ個人)という手法も効果的です。DRIは、特定のタスクやプロジェクトに対し��、最終的な成果に対して直接的な責任を負う個人を指します。このアプローチにより、各プロジェクトやタスクには明確な責任者が設定され、その責任者がプロジェクトの進捗を管理し、必要な意思決定を迅速に行うことができます。これにより、プロジェクトの透明性と効率性が向上し、全体の進捗がスムーズに進むのです。
　責任の所在を明確にし、適切なレベルで責任者をアサインすることは、組織のスピードと柔軟性を保 ちつつ、プロジェクトの成功を確実にするために不可欠です。


　さらに、このSIerのビジネス構造は、そこで働くエンジニアにも悪影響を及ぼします。SIerが収益率の高い領域である上流工程を担当しようとすることは説明しました。ただ、SI産業に属するの会社すべてが上流工程を担当できるわけではありません。上流工程を担当するSIerはプライムコントラ クターと呼ばれ、要件定義や設計以降は下請けとなる開発会社が担当します。結果、大手SIerにいろ エンジニアは実装経験も乏しく、かと言って自ら事業運営を担当するレベルの当事者意識を持って要件 を整理できるわけでもないという中途半端な人材になりがちです。SIerから事業会社への人材流動も 進みつつありますが、事業会社に転職しても、自らやり抜くことに対して意識が低い人が多いということも聞きます。その一因はSIerのビジネスモデルにもあるでしょう。
　なお、ここまで列挙してきたような課題が、企業のIT活用全体の問題として取り上げられる機会 は、諸外国の中で日本がダントツに多いです。図5-23を見ると分かるように、日本ではSIerを含 む「IT企業」に所属する情報通信系人材の割合が非常に多く、「それ以外の会社」つまり事業会社で 働く人材の2倍以上になっています。このデータは2015年のものですが、この傾向は変わっていま せん。2020年のデータでも日本ではIT企業に73.6%、IT企業以外に26.4%が所属しています(IPA「DX白書2023」【編注16】より)。
　 なぜなのか。筆者が考える理由は3つあります。
　1つは、事業会社側がITをなぜか特別な技術と思い込み続けていることです。事業の成長 に不可欠な新しい要素があれば自ら学んで活用 するのに、ITになった途端にそのような発想 をしなくなり、専業のIT企業に委託してしま うのです。また、それが成立するほどに日本の IT業界が成長し、機能し続けてしまったというのも要因の1つでしょう。さらには、IT業界が製造業の構図を模倣した多重下請け構造で案件を回すようになり、事業会社がこの多重下請け構造化した「コミュニティ」に入っていくのが難しかったという点も挙げられます。


◾️同意しないがコミットする
　一方、全員が完全に同じ意見になるまでには時間がかかりますし、現実的でもありません。
「同意しないが、決定には従う」 【編注1】と聞いて、読者の皆さんはどう思うでしょうか? 同意できな いなら、その提案に協力しないのは当たり前。決定に従うとは言っても嫌々従うのだろうと思われるか もしれません。
　しかし、この「同意しないが、決定には従う」は、インテルやアマゾンなどが行動方針として定めて いるものです。これは、意思決定プロセスにおいて、チームメンバーが意見の相違を持ちながらも、最 終的な決定には全員がコミットするというアプローチで、無限の議論に時間を浪費することなく、迅速 な意思決定と効率的な実行を促進しています。
　ソフトウェアファーストな変革を成功させるには、この「同意しないが、決定には従う」の精神が重要 です。変革の過程では、新しいアイデアやアプローチに対して多様な反対意見が出ることが予想されま す。しかし、この原則に則ることで、チームは意見の相違を乗り越え、迅速に前進することができます。
　そもそもどんなアイデアにも異論や反論はつきものです。むしろ、万人が反対しない案とは誰もが考にえつくような無難なものになりがちで、大きなインパクトを生む要素に欠けています。特にソフトウェ ア開発の分野では、技術や市場のトレンドが絶えず変化し、すべてのアイデアに何らかのリスクがあり ます。トレードオフの判断が求められることも多々あります。それでも変革を成功させるには、激しく 議論を交わした後でも、全員が一致団結して進んでいくことが不可欠であり、「同意しないが、決定には 従う」は、それを強力に後押しします。


　本書で一貫して主張してきたのは、ソフトウェアが現代のビジネスにおいて最も重要な要素であると いうことです。ソフトウェアファーストのアプローチは、単なる技術的な選択ではなく、企業戦略の根幹に据えるべき考え方です。
　第一に、ソフトウェアは顧客価値の最大化に直結します。顧客が真に求めるものを理解し、それを実 現するための手段としてソフトウェアを活用することで、競争優位を築くことができます。
　第二に、ソフトウェアは事業価値の最大化にも直結します。ソフトウェアを使ったリカーリング(継 続課金)ビジネスモデルは、持続可能な収益を生み出し、ビジネスをスケールさせる力を持っています。
　第三に、ソフトウェアは企業の適応力と迅速性を高めます。変化する市場環境や顧客ニーズに迅速に 対応するには、柔軟かつスピーディーなプロダクト開発が不可欠です。ソフトウェアを中核に据えるこ とで、企業は変化に対する耐性を持つだけでなく、変化を起こす側に回ることも可能になります。既存の仕組みや業界構造を抜本的に変革する、いわゆるディスラプター(破壊者)となり得るのです。 最後にお伝えしたいのは、ソフトウェアファーストだからと言って、ソフトウェアだけを考えれば良いわけではないということです。本書はソフトウェアに焦点を当ててきましたが、ハードウェアも大事 です。ソフトウェアとハードウェアは対立するものではなく、どちらかを採用したらどちらかを切り捨 てるものでもありません。両者は連携して機能する技術です。
　実はハードウェアで実現したほうが良いケースもあります。ソフトウェアは柔軟性が高く、更新が容 易な一方で、消費電力や実行速度の面ではハードウェアに劣ります。そのため、消費電力を抑えたい場 合や高速な処理が必要な場合には、ソフトウェアでもできることをハードウェアにオフロードする(肩 代わりさせる)のが有効です。
　重要なのは、ソフトウェアとハードウェア、2つの選択肢を持ち、目的に応じて最適な選択ができる ことです。そして、どちらを選んでも自社で対応できるのが一番強い。日本は伝統的にハードウェア分 野に強みを持っています。従って、ソフト���ェアの力を強化すれば、相乗効果でさらに競争力を高めることができるのです。
　ソフトウェアファーストとは、ソフトウェアを最初から考えようということであって、ソフトウェア がハードウェアよりも大事ということではありません。ソフトウェアを新たな武器に企業競争力を高め ることで、日本がもう一度発展していくことを望んでいます。

投稿元：

レビューを見る

なかなか読んだことのない本
色々と仕事に活かせそうな気はする

プロダクトマネージャがいない会社はヤバいのかもしれない。内製化しないとか。
周りにススメて仲間を増やすところから始めてみよう。。

投稿元：

レビューを見る

IT業界で有名な及川卓也の著書ということもあり読んでみた。
全体的にIT業界に働いていればよく聞く話が多い印象で、こういった知識や考え方は大事だよなと再認識しながら読むことができた

後半の組織論やキャリア論は参考になる話も多く面白かった

エンジニアだけでなく、営業、企画などそれぞれ職種に応じた視点の学びが得られる本だと思う