ソフトウェア・ファースト ― あらゆるビジネスを一変させる最強戦略
著 : 及川卓也
Amazon で購入 : https://amzn.to/2opW4io
読書開始 : 2019-10-26
読書終了 : 2019-11-04
TL;DR
内容
はじめに
本書では、多くの企業が関心を持ち始めた 「IT を駆使したイノベーション」 や 「デジタル・トランスフォーメーション」といった変化の種を、単なる流行りや徒労で終わらせないための取り組みを記す
どのような条件がそろえば会社を変えることができるのかを本書では述べていく
キーワードは 「ソフトウェア・ファースト」
1 章 ソフトウェア・ファースト
必要なのは、手法の理解ではなく、思想や姿勢 : ソフトウェア・ファースト
2 章 IT・ネットの “20 年戦争” に負けた日本の課題と光明
世界の時価総額ランキングを見ると、平成元年に日本企業は存在感を持っていたが、現在は全くない
筆者の分析では、日本企業はソフトウェア開発力の競争に敗れた
1990 年代以降 (?) の世界の変化の 2 つの特徴
おもちゃのように扱われていた技術が、その後産業を変えた (それがひとつの法則)
パーソナルコンピューターだったり、iPhone だったり
ユーザー体験の価値が飛躍的に高まった (上記に関連して、コンシューマー側で先にイノベーションが起こるため)
日本企業はこの波に乗り遅れた
なぜか？ → 1990 年代以降に日本企業が世界で存在感を失った理由
日本企業復活の糸口
「フィジカル × サイバー」 領域の新規事業
サービスとして移動を捉える考え方
本来、自動車の提供価値は移動すること
車という手段の提供だけではなく、歩行や公共交通機関、飛行機などを組み合わせた移動全体の構想が必要
成功のためには？
課題を明確にする
フィジカル×サイバーシステムは多くの技術を組み合わせて提供するものになる → 技術ありきで開発しがち
だが、課題がないところに需要はない
ユーザーの使い勝手、ユーザー体験の最大化を考えること
コンシューマー向けのサービスではこれが価値の源泉
BtoB においても操作する人の体験をより良いものにしていく流れは年々強まっている
サイバーとフィジカルのバランス
フィジカルの進化をサイバーに合わせる
OTA の活用やパーツ交換を容易にするなど
プラットフォームの構築
プラットフォームビジネスとは、不特定多数を対象に製品やサービスを提供する場所を構築すること
ユーザーはプラットフォーム上にある複数のサービス (ソフトウェアなら機能) を目的に応じて利用できる
最初の一歩はバーティカル (垂直) なサービスづくりから始めるべき
特定の領域、またはごく少数の企業が確実に使えるものを提供する
課題ありきで物事を考える習慣がないと、開発中にエンジニアがコードを書くことを目的化してしまい、オーバーエンジニアリングになってしまう
3 章 ソフトウェア・ファーストの実践に必要な変革
Objectives and Key Results (OKR) から学ぶ
運用について最初から考えておく
アクティブユーザー : アクティブな (使っている) ユーザー
Web サービスやスマートフォンアプリケーションの評価指標としてよく知られている
CPA (Cost Per Acquisition) : ユーザー獲得の費用
いくらコストを使えばいいかの判断にはファイナンスの知識が必要
その際に用いられる指標が LTV (Life Time Value) と呼ばれるもの
「顧客生涯価値」 とも呼ばれる
ユーザーがそのプロダクトを使い続けている間に生み出す価値 (企業側からすると利益)
ソフトウェア・ファーストの実践では 「使われないプロダクトはゴミである」 という意識を持つ必要
全員を幸せにする必要はない
一部の極端なユーザーは〝声〟が大きい
満足しているユーザーは、わざわざ声を挙げて満足していることを表明しない
カスタマーエクスペリエンス : 体験がどのようにデザインされるべきかを考える
ソフトウェア・ファーストの実践には組織変革も同時に進めることが不可欠
使われ続けるプロダクトを生み出すために、企画の立て方・育て方と同じくらい大事なのが、それを実行する人と組織
企画を生むのも人、それを形にしていくのも人
社会変容のティッピングポイント (集団の行動が大きく変わる) の閾値はおおよそ 25 % の人々の変化
企業が DX のような新しい事業を起点に商習慣や組織文化を変えていく際も 25 % 程度の人たちに同志になってもらう必要
適藤な抽象性と事業との強い結びつきが重要
ミッションが具体的過ぎると以下のような影響
後にピボット (戦略転換) する場合の振り幅が小さくなる
異なる事業を立ち上げる余地が少なくなる
ミッションを変更すべきと思っても難しい場合
担当者が直接関係する事業やプロダクトだけでもミッションを再定義すると良い
変革の中心を担うチームメンバーを集める時にも、ミッションにふさわしい人かどうかを見極める必要
経営陣の中で誰が変革をリードするか？
IT 活用に関しては、従来なら CIO (Chief Information Officer) が担当するのがほとんど
デジタライゼーションを担当する組織は CIO 管轄の情報システム部であるケースが多い
DX 推進では情報システム部と異なる新しい組織を作ることが多いよう
CDO が新設されるのは、その企業が IT 以外の技術を本業としていたりするケース
組織変革の事例 : コニカミノルタ
異なる仕事現場に適したソリューションを提供していくには 「物売り」 から 「サービス」 への転換が必要
ソフトウェアエンジニアの力が求められる
先行事例を、機会を見つけて共有していく
組込みソフトの開発しかやっていなかったような現場エンジニアも、価値創造について考えるように
こうした価値創造の大切さが社内に浸透するまでに 3 年くらいはかかった
4 章 これからの 「強い」 開発組織を考える
エンジニアリング組織はプロダクト開発・運用の主役になるだけでなく、事業サイドと正しい形で連携の取れる組織である必要
従来型の情報システム部門の中には、自分たち自身で 「事業サイドの指示を実行するだけの下請けチーム」 にしてしまっているケースがある
Amazon の事例
実店舗がビジネスの主戦場だった書籍販売や物販を EC に置き換えて成長してきた
フィジカルなビジネスをデジタル化、サイバー化してきたと言える
多くの日本企業が取り組む DX の良いモデルケース
タレント・アクイジョン (タレント人材獲得を目的とした買収)
技術力の高いスタートアップを買収することでエンジニアリング組織ごと社内に取り込む
あらゆる課題をソフトウェアで解決すべきと思い込んでしまう
事業の方向性に即した開発を行えるエンジニアリング組織をつくっていくべし
開発組織におけるマネジャーの役割は、メンバーのパフォーマンスを最大化し、成長を助け、成長し続ける組織を通じて事業に貢献すること
> エンジニアの中から 「テックリード」 と呼ばれる開発を技術的にリードする人を選ぶこともあります。
VPoE をあえて意訳するなら開発本部長やエンジニアリング組織の担当役員という感じ
CTO が担っていた人・組織面の戦略遂行を切り出して担う立場
エンジニアの生産性と成長を最大化する
> 整理すると、CTO の役割は次のようになり、VPoE を配置する場合には、このうち主に３つ目を担当することになります。
> CTO を置く利点 ・経営陣の中に技術担当が存在することで、技術をどのように経営に活用するかを考えられる。技術部門の意見を経営陣に届けることができる。 ・技術面での戦略を統括できる。 ・エンジニアのキャリア形成に関して、社内にロールモデルを示せる。 ・自社技術に関しての対外的なスポークスパーソンを用意できる。
> 申し訳ありませんが、この形式のコンテンツは表示できません。
> 黄色のハイライト | 位置: 3,266
> ジョブ・ディスクリプションを作るための決まった様式はありません。 構成要素としては図 4-7 に示す項目が必要です。 各項目を埋める時は、誤解を生みそうな曖昧な表現はできるだけ排除し、簡潔かつ明快な言葉で言語化していきましょう。
> エンジニアリング組織を立ち上げたばかりで人数も少ない場合は、職能組織のほうが機能しやすいでしょう。仕事の進め方を暗中模索しているような状態では、エンジニアリングマネジャーと一緒に考えていくことが必要になるからです。
> 職能組織ではエンジニアリングマネジャーが上司となってメンバーの成長を考えた指導や技術的な評価が行う一方、事業主体組織では異なる専門領域を持つマネジャーが上司になる場合があります。
> の組織構成として、新しいプロダクトチームを立ち上げる際、一部の企業で支持を集めているのが 「出島戦略」 です。 これは江戸時代に長崎にあった出島が外国の技術や文化を国内に取り込む役割を果たしたように、既存組織とは異なるルールで動く 〝治外法権〟 な別組織を用意する戦略
> この流れを確実に生み出すためには、次の３つのポイントを押さえる必要があるでしょう。 ・何をもって成功とするのか目標を明確に定める。 ・目的達成の度合いを正確に測定できる KPI (重要業績評価指標) を設定する。 ・四半期ごとに何らかの成果を出し、周知を徹底する。
ユーザー向けのプロダクト開発につながらないことに終始していては、いずれ出島の持つ特権に対して批判の声が挙がる
出島の最終目標は、必ず本社の事業を変革するものにする必要がある
組織文化について
コアタイムを短くし過ぎると、メンバー全員がそろう時間が短くなる
短くなったコアタイムの間に会議が集中することになる
日中の生産性が高くなる時間帯に設定されがちなコアタイムをすべて会議に取られてしまっては元も子もない
代案として、勤務時間の変更が必要になった社員のために別制度を用意する方がいいかもしれない
全社員に平等に与えるべき柔軟性と、特別な事情が生じた社員に対する対応との線引き
理由 : チームが机を隣同士に並べて働くのに比べて、生産性が下がり、創造的な成果も生み出しにくい
オフィスにいる大多数の人とリモートワークしている少数の人とのコミュニケーションは根深い問題
どうしても情報格差が生まれる
意思決定への関与度が異なってしまうという問題も
リモートワークする人やリモート拠点の人にも情報を共有し、意思決定のループに含めるよう配慮するべきだが、コストがかかる
あまりにも平等を追求し過ぎると全体の開発スピードが低下
さくらインターネットの事例
インターネットで社員が能動的に開発に取り組む文化を醸成するまで、信頼の重要性を見誤っていた
「当社で仕事をする中で、いつでも転職できるようなスキルや経験を身に付けてください」 と言っている
転職できないということは、市場価値が低い → 会社も困る
会社としては、転職すればもっと良い給与をもらえるレベルの人たちにも残ってもらえるよう、努力し続ける必要
5 章 ソフトウェア・ファーストなキャリアを築くには
部下の育成にも
部下の育成というのは、会社や組織が求める仕事ができるように型にはめることではない
部下の目指すキャリアが会社や組織の目指す方向と多少ずれていたとしても、全力で支援すること
過去にかかわった事柄や興味を持っていたことが将来になって生きてくることを、多くの人が自らの経験を基に語っている
コネクティング・ザ・ドッツの概念は、計画的偶発性理論として提唱している内容とほぼ同じ
> 数年に一度は自身のキャリアの縦軸・横軸になっているスキルを棚卸ししてみるのをお勧めします。その際、これから紹介するような表組みにして棚卸しすると現時点の強みと今後伸ばしたい部分が分かりやすくなるでしょう。
マネジメントに拒否反応を示す人が少なくないが、食わず嫌いで選択肢を狭めないでほしい
多くのエンジニアが考えるよりも、マネジメントの仕事は魅力的
自らが育てた人や組織が大きくなり、偉業を成し遂げるようになっていくのを見ることは、自分が書いたコードが世の中を変えるのを見るのと同じくらい魅力的
本来、マネジメントというポジションは魅力あるポジション
その魅力を打ち出せるようにし、魅力を削いでいる仕事を見直すべし
プロジェクトマネジメント関連職としては、プロジェクト管理を行うプロジェクトマネジャーが代表的
職種として用意されるケースと、役割として用意されるケースがある
テックリードの話
及川卓也氏からのキャリアパスについての助言
部下の配置について、組織の都合で配置を考えるのではなく、適性と本人のキャリアの志向性を考慮するべし
高い目標を常に掲げる
自分が手を伸ばせば届くレベルよりも高い目標を掲げれば、それに向かってスキル習得は進む
部下を持つ人にも、部下に常に高い目標を与えるべし
常に変化を求めることの意味合い
人それぞれの価値観はありますが、安定がすべてではない
変化が激しい社会、昔ながらの安定はもうないのかも
自らが変化を起こす側になったほうがいいのではないか
自分でレーダーチャート状のスキルチャートを作って、自身の価値を分析
「Google を辞めて、同じように世界を変える仕事ができるのか」
Google は事業化の判断材料の一つとして 「10 億人のユーザーにリーチできるか」 を考える
常に成長することを考える
おわりに
付録 : モダンなプロダクト開発を行うための技術と手法
開発・運用手法の進化