（読書メモ）ソフトウェアファースト
前回の読書メモと同じ及川卓也氏の著書、「ソフトウェアファースト」を読んだのですが、「DXの方法論」「エンジニアキャリア」についてわかりやすく記載あったため、改めて個人的に気になったところを抜粋します。
ソフトウェア・ファースト
近年はモノからコトへ、所謂産業のサービス化がすすんでいます。このサービス化の根幹を支えるソフトウェアの中でも、近年はSaaSが主流です。
SaaS以前はPKGが主流でしたが、PKGでは販売後の収益は保守費と追加ライセンス、新しいPKGへのアップグレード、といったもののみでした。一括購入で収益を得るため、極論購入後に使われなくても収益への影響はほぼないです。
しかしSaaSはサブスクモデルを導入しているため、ユーザーが継続使用することが重要で、そのため「（顧客）体験をよりよくする」ことが求められます。
SaaSはリリース後にスピーディーに育てていく発想なので、アジャイル×DevOpsといった手法がとられがちです。
なお、PKG開発は大口顧客の導入が重要なため、顧客が要求する機能があれば、顧客に本質的に最適解であるかどうかは考えずに、エンジニアチームに営業が開発依頼するケースがあります。
SaaSでは、顧客の継続利用に影響を与えない、所謂使われない機能に価値はないため、プロダクト開発も本来の顧客志向になります。また、PKGではユーザーの利用状況の把握は基本的に不可能でしたが、SaaSでは利用状況を即座に把握できるため、本質的に使われる機能の開発がしやすい状態です。
日本の課題と光明
世界時価総額ランキングのトップ50には、1989年には日本企業が32社あったのに対し、2018年ではトヨタ自動車（35位）が入るのみと、日本企業の存在感は明らかに減っています。
上記背景には、ハードウェア→ソフトウェアの時代の流れに日本企業がついていけなかったことが考えられます。
要因として、まずはSI至上主義（自社にナレッジをためない）があります。
事業会社側はITをコストとみなし、内製化ではなくSIerへの委託を行いました。SIerは人月商売のため、効率化／顧客企業の価値向上をしにくい側面がある／自社にITのノウハウがたまらない、といった問題を生み出しました。
DXの本質は事業会社の自走にあるので、SIerはDX支援をすることで自らの存在価値を最小化することになります。これからのSIerについては、「専門特化（Github副社長曰く）」や、「製品販売比率を増やし付随するサービスを手厚くする」といった方向に進むことになりそうです。
また、日本の強力な産業であった、製造業の生産方式に類似した、所謂ウォーターフォール開発をメインに使っていることも要因の一つです。
日本がこれから復権するには、「リアル領域（日本が得意な）×ソフトウェアの融合」や、「プラットフォーム構築」が重要です。
ソフトウェアファーストの実現に必要な変革
DXはデジタイゼーション（デジタル化）とデジタライゼーション（デジタルを用いたプロセス）を前提とし、そこからユーザーに新たな価値を提供する事業を生み出すことです。
少なくともデジタイゼーションができていない状況でのDXは難しいため、まずはデジタイゼーションを行い、そこからいきなりDXをするか、デジタライゼーションを既存事業で行って、そこからDXをするかの二択になります。
DX推進には、内製化（ITの手の内化）が必要です。外部パートナー利用するとしても、企画、設計、実装、運用の全フェーズを自らコントロール可能な状態にする必要があります。
経営陣はビジネスだけでなく、テクノロジー×クリエイティブ両面に一定の理解を深めるべきです。
マネージャーは単なる調整役ではなく、特定領域の専門性をもちながらマネジメントスキルを高めるべきです。
また、ディスラプティブなプロダクト開発には、マーケットインだけでなく、プロダクトアウトの発想（作ったモノや作りたいモノを売る）も組み合わせることが一つの方法です。
例えば仲間内でプロトタイプを作り外部公開し、その後は評価を検証しながらユーザーが欲しいものに育てていくやり方です。
ユーザーニーズの把握のためには、リーンスタートアップやデザインスプリントといった手法を用いて、仮説→MVPで成果計測→プロダクト修正の流れをスピーディーに繰り返します。
ただ、リーンスタートアップは小さく段階的な成長しかできず、大胆な打ち手が取れない、といった批判もあるため、日本企業はその他の手法も含め適切な手法をとる必要があります。
強い開発組織
スピーディーな開発×ナレッジの蓄積のために、まず内製化が前提となります。
内製化には、AIの台頭で今後エンジニアの価値が低下するのではないか、雇用維持できるのか（PJが落ち着いたらエンジニアはコストになる）、といった懸念が言われることがあります。
しかし、プログラムが自動生成されたとしても、要件定義や品質レベルの多様化／複雑化は進んでいるため、そうした問題を解決できるエンジニアは価値が低下することはありません。
また、雇用維持についても、これからのプロダクト開発は継続的な改善による品質向上が重要なため、エンジニアのやることがなくなる、といったこともありません。
内製化のためには、事業サイドのIT理解だけでなく、エンジニアサイドのプロダクト志向も必要です。Howだけではなく、WhyやWhatも意識し、ユーザーへの提供価値を最大化するために何が必要かを考えることが重要です。
マネージャー
技術の進化スピードは早いため、マネジメント層でも、新しい技術／手法を学び続けることは重要です。
PdMは製品責任者で、EMは開発組織の責任者です。プロダクトの重要性をPdMが重視するあまり、開発組織の中長期的成長に結びつかないこともあるため、PdMとEMがうまく協力することが求められます。
なお、人事的なラインとしては、PdMとエンジニア、EMは異なるラインのため、EMが昇進したらPdMになる、といったことはありません（勿論異動等でそれぞれのところになることはありえます）。
CTOとVPoE
所謂デジタリゼーションやデジタライゼーションを行うのはCIOですが、DX推進のような新規プロダクト開発はCTO／CDOが行います。
CTOはエンジニアリング組織のトップとして、プロダクトの出来そのものから改善の判断、技術選定、採用や組織見直し、人事評価といった広範囲にかかわります。
そこでVPoEを設け、CTOが担っていた人事／組織面の部分を担当させます。
※CTOとVPoEの立場は並列か、CTO＞VPoEになるケースが多いです。
組織体制
組織パターンとしては、
・職能組織：エンジニアやデザイナーを職能組織として組成し、他部署と連携
・事業主体組織：事業にかかわるすべての職種が一つのグループ
・出島戦略：既存組織とは異なるルールで動く治外法権な組織を用意
の3つがありえます。
職能組織と事業部隊組織はどちらがいい悪いではなく、ケースバイケースです。エンジニアリング組織立ち上げフェーズでは、仕事の進め方も定まりきらず、EMと一緒に連携する必要があるため、職能組織が機能しやすいです。
一方すでに複数プロダクトが開発されている場合は、各プロダクトごとに開発方針やサイクルが違うため、事業主体組織のほうがスムーズです。ただし、この場合も全社的な技術方針は決める必要があります。
また、上記出島戦略では、PoCを行うだけの部署にするのではなく、本社事業の変革を最終目標にしなければなりません。
ソフトウェアファーストなキャリア
一つの専門性×周辺知識をもったT型人材になることが、キャリア形成のベースです（専門性（I型）だけだと、他職種との連携ができないため）。
業務経験を積めば積むほど、T字の縦軸／横軸ともに広がりますが、さらに専門を増やすπ型人材となり、差別化をうむやり方もあります。
例えば一つの専門性をもって100人に一人の存在になり、それを3つまで専門性をもつと、100×100×100の100万人に一人の存在となり、希少価値が一気に高まります。
なお、軸を二つ以上持つ際の縦軸の選び方は、過去に関わった事柄や興味を持っていた内容を選ぶとうまくいきやすいです（スティーブジョブズの「コネクティングザドッグ」も、思いもよらない形で点と点がつながったことを表しています）
戦略的に縦軸を選びつつ、計画的偶発性理論も活用して、積極的に招く偶然をそこに組み合わせることで、うまくπ型人材として成長していきます。
数年に一度は縦軸横軸を棚卸し、どのスキルを身に着けるべきか、強みを把握する、といったことをしていくことも推奨されます。
その際、所謂技術スキル（バックエンド、インフラ、セキュリティ等）だけでなく、ソフトスキル（マネジメント、コミュ、ファシリテーション等）も重要なスキルになります。
将来のキャリアパスとして、エンジニアでは、「技術」「人／組織」「プロダクト／ビジネス」の3領域のどこかを強めていくことになります。それぞれ、スペシャリスト／EM／PdMといった内容です。なおアメリカでは、これらの3職種は完全に対等なものとして評価されます。
技術を極める（スペシャリスト）
T型の縦軸を伸ばしていきます。ただし、スペシャリストコースは楽ではないコースです。例えば同期が100人の部下をもつマネージャーになった場合、そこと同じくらい評価されるほどの貢献を専門性で発揮する必要があるためです。
同じ職位のEMやPdMと同等に認められるためには、例えば自社技術のエバンジェリストとして技術書の執筆や社外講演、プロダクトの認知向上、採用貢献、自社技術をOSSとして公開、といった道がありえます。
スペシャリストを進めていくと、テックリードとして、開発を技術的にリード（技術選定やアーキ検討含）、エンジニア育成が業務に加わります。
なお、スペシャリストとして、フルスタックが理想か、単一スキルの深さが理想かについては、組織ごとに考えが異なります。
人／組織に貢献する（EM）
スキルや経験に幅のあるメンバーの力を引き出し、組織の力で課題解決することにやりがいを見いだせる人が、EM志向といえます。
EMでもエンジニアを束ねるため、技術をキャッチアップする必要はあり、さらに組織論やマネジメント手法についても学んでいく必要があります。
EMのキャリアパスとしては、VPoEやCTOがあります（CTOについては、テックリード系の人がなることもあり）。
プロダクト／ビジネスに貢献する（PdM）
プロダクトやビジネスに興味がある人がこのコースになります。また、エンジニア派生の場合もあれば、最初からPdMとしてキャリアをスタートするケースもあります。キャリアパスとしては、CPOや事業責任者があげられます。
また、上記以外にも例えばPjM職（スクラムマスター含）のキャリアもありえます（PdMやEMが兼務することもあり）。PJ推進能力を高めつつ、PdMやEMへとキャリアをシフトすることも可能です。
この記事が気に入ったらサポートをしてみませんか？