この記事は、2019年に note で書いたものを転載したものです。（一部改訂）
Microsoft、Googleでソフトウェアエンジニアを歴任した及川卓也さん。NHK「プロフェッショナル仕事の流儀」でも取り上げられたので、知っている方も多いと思います。
世界のトップ企業で技術者を歴任してきた及川さんが、日本企業の失われた20年を嘆き、怒り、絶望し、それでも本気で会社を変えたい、自分を変えたいと思っている人たちに対してメッセージを送るために「ソフトウェア・ファースト」は書かれています。
Microsoft、Googleでソフトウェアエンジニアを歴任した及川卓也さん。NHK「プロフェッショナル仕事の流儀」でも取り上げられたので、知っている方も多いと思います。
世界のトップ企業で技術者を歴任してきた及川さんが、日本企業の失われた20年を嘆き、怒り、絶望し、それでも本気で会社を変えたい、自分を変えたいと思っている人たちに対してメッセージを送るために「ソフトウェア・ファースト」は書かれています。
この本を手に取ったあなたは、きっと自社の現状に危機感を抱き、自分にできることを探している、つまり「ボーっと生きていらっしゃらない方」だと思います。本書では、多くの企業が関心を持ち始めた「ITを駆使したイノベーション」や「デジタル・トランスフォーメーション」といった変化の種を、単なる流行りや徒労で終わらせないための取り組みを記します。筆者が経験、見聞きしたことを基に、テクノロジー、組織改革、必要な人材、キャリア形成の面から具体的に紹介しています。
この本は、この文章から始まります。
バブル経済崩壊後、日本は進化が止まっています。
この本の源泉は、マグマのように溜まった著者の怒りであり、それでも信じている未来への希望であると言えるでしょう。
第1章 世界はサービス化している 〜SaaSの台頭〜
この本は、全5章から構成されています。冒頭の2章は、いま世界で当たり前のように起こっている産業の大革命と、その本質をまったく理解できず、活用どころか理解することさえできなかった悲しい日本の現状を説明しています。
まず第1章では「サービス化」をテーマに、現在世界で起こっている大変革について説明がされています。サービス化を象徴するのが、SaaS（Software as a Service）の台頭です。
💡Saasとは？
ユーザーが利用するサービスをインターネットを介してクラウド上で提供するもの。例えば、GmailやGoogle Driveなどの gSuite、Dropbox、Slackなどが代表。一般的に月額課金型モデルが適応される場合が多い。
SaaSが一般的になる以前は、完成品のソフトウェアが入ったパッケージ（主にCD-ROMやDVD-ROM）を購入するのが一般的でした。Windows 95 の発売日に、家電量販店の前に長蛇の列ができている写真を見たことがある方もいると思います。当時は、高いお金を払って、ソフトウェアを買い切りで購入していたのです。
そこから、インターネット高速回線の普及などにより、ソフトウェアの提供方法が従来のパッケージ型からSaaSになることで、様々な大変革が起きました。
💥SaaSが起こした大変革 1. 売り切りモデルから月額課金モデルへ パッケージの場合、ユーザーがの購入時に高収益が見込めるが、その後の収益は小さい。SaaSでは、ユーザーと契約した直後の収益は落ちるが、ユーザーが利用してくれる限り収益が継続的に入ってくる。 2. 利用されないと儲からない パッケージの場合、一度購入して貰えば、利用率は収益に関係ない。SaaSでは、利用されなければ契約が切られ、収益が生まれなくなる。 3. 次期バージョンへのアップグレード誘導が不要 パッケージの場合、現行バージョンのユーザーに対して再度課金をしてもらって次世代バージョンへアップグレードしてもらうための営業活動が必要がある。SaaSでは必要ない。
SaaSに代表される社会のサービス化に伴い、ソフトウェア開発手法や運用手法なども大きく変化していきました。従来のウォーターフォール型の開発から、小さなアップデートや修正を積み重ねることでソフトウェアを継続的に改善していく「アジャイル開発」、開発チームと一度リリースした製品を運用するチームが密接に関わり合い、プロダクトを育てていく「DevOps」などに変化しました。
このように世界は猛烈な速度でサービス化し、それに伴い様々な新しい開発手法、組織論、運用手法が生まれて行きました。
✏️第1章で学べること ・現在世界で起こっている「サービス化」とは一体何か？ ・SaaSとは何か？どのような変化なのか？ ・SaaSの台頭により、ソフトウェアを開発する開発組織や企業全体にどのような変化が起こっているのか？ ・いま話題のアジャイル開発やDevOpsとは一体何なのか？
第2章 ソフトウェア時代の日本の没落、その3つの理由
たった30年前の話です。1989年の世界の時価総額ランキング上位50社を見ると、32社（64%）が日本企業でした。日本が誇るモノづくりの技術は、鉄鋼業、自動車、家電、半導体、コンピューターといった分野で間違いなく世界を席巻していました。
それが2018年のランキングでは、35位にトヨタ自動車が入っているだけです。
出典: https://twitter.com/tktnk/status/1032080914392567809
この30年、日本企業は明らかに世界から取り残されてしまいました。代わりに台頭してきたのが、GAFAM（Google, Amazon, Facebook, Apple, Microsoft）と呼ばれるアメリカシリコンバレーの企業群や、BAT（Baidu, Alibaba, Tencent)と呼ばれる中国の巨大IT企業であり、彼らが現在のソフトウェア時代を牽引していることは明らかです。
出典: https://twitter.com/tktnk/status/1032080914392567809
この30年、日本企業は明らかに世界から取り残されてしまいました。代わりに台頭してきたのが、GAFAM（Google, Amazon, Facebook, Apple, Microsoft）と呼ばれるアメリカシリコンバレーの企業群や、BAT（Baidu, Alibaba, Tencent)と呼ばれる中国の巨大IT企業であり、彼らが現在のソフトウェア時代を牽引していることは明らかです。
第2章では、ソフトウェア時代への大変革が起きている中で、日本企業はなぜ没落してしまったのか？ということについて書かれています。
本書の意見は、
😢日本企業がこれほどまでに没落してしまった最大の原因 この20年で「ソフトウェア開発力の競争」に破れたから
というものです。では、なぜ日本企業が「ソフトウェア開発力の競争」に破れてしまったのでしょうか？
😢なぜ日本企業が「ソフトウェア開発力の競争」に破れてしまったのか？ 1. ITは「効率化」の道具だから、とりあえずSIerに丸投げしておけばOKという誤解から抜け出せなかった 2. これまでの成功体験を捨てきれず、ソフトウェアを従来の車や家電と同じような工業製品としてみなしてしまったために、開発プロセスに圧倒的な差が生まれてしまった 3. 工業製品とソフトウェアの違いを正しく理解できず、チグハグな改善や本質的ではない品質管理が行われてしまい、ユーザーの期待を正しく理解できなかった
私なりに一言でまとめると、これまでの成功体験を引きずってしまい、すべては過去からの連続であるという誤解から、非連続に起こった産業構造の大変化に全く追いつけなかったからというわけです。
✏️第2章で学べること ・日本がソフトウェア時代に没落していったときに世界では何が起こっていたのか？ ・よく聞く「SIer」とはどんな人たちで、なぜ生まれたのか？その功罪は？ ・車や家電などを作る製造業と、ソフトウェア開発の開発プロセスの違いとはいったいどのようなものなのか？ ・マイクロサービス、スクラム、ソースリポジトリ、チケット管理、継続的インテグレーションなど近年でてきた新しい考え方は一体何で、どのような背景で生まれたのか？ ・日米欧のソフトウェア開発に対する考え方の違いとは？ ・品質と顧客満足の関係性とは？（高い品質ではなく）「いい品質」とは一体何なのか？ ・著者がGoogleで求められた「いい品質」とは？
さて、いよいよ第3章から、ソフトウェア時代を生き抜くための鍵についてプロジェクトマネージメント論、開発組織論、そして個々のエンジニアのキャリアまで、圧倒的熱量と豊富な経験で語り尽くされます。
第3章 ソフトウェア時代を生き抜くためのキーワード＝「手の内化」
まず、第3章でこれからの展開でもっとも重要であり、この本での中でもっとも重要なキーワードの1つである「手の内化」という言葉が出てきます。
⭐️「手の内化」とは？ 自社プロダクトの進化にかかわる重要な技術を自分たちが主導権を持って企画・開発し、事業上の武器にしていくこと
手の内化というと、「ソフトウェアの内製」と考える人もいるでしょう。たしかに全てを内製できれば最高ですが、仮に外部のパートナーを利用するとしても、自分たちの製品のすべてのフェーズに対してコントロールできる状態を維持し、経営者以下すべての人がソフトウェアに対して責任を持ち続けることが大切だと本書は述べています。
仮に外部パートナーを活用するとしても、ITの企画、設計、実装、運用というすべてのフェーズを自らコントロール可能な状態にすること、つまり手の内化していくことが大事なのです。それこそが本書で提唱しているソフトウェア・ファーストです。
では、それぞれの立場の人が何をすべきと述べているのでしょうか？まとめてみましょう。
ソフトウェア時代を生き抜くために経営者がすべきこと
👊経営者がすべきこと ・テクノロジーに対する理解、デジタルテクノロジーについての理解、ソフトウェアに対する理解を深める ・部下や外部パートナーに任せず、自分で調べ、手を動かし、理解するように務める ・若者が使っているアプリ、今話題のアプリをちゃんと使ってみる ・日本が直面している危機的な状況を認識する。
ZOZOの執行役員の田端さんも、このようにTweetしています。
「意識が高い」はずのG1経営者会議で参加者の挙手アンケート、ポケモンGO1度もやったことない人が7〜8割という結果に衝撃を受けました。休みの日に「お勉強」は大好きなのに、生活者としての健全な好奇心が皆無です。そりゃ日本企業のデジタル化がトンチンカンなわけだわ。まさかLINEも？。(Twitter)
また、最近ではこのようなニュースも話題になりました。
“ユナイテッドアローズが公式ECサイトの自社管理への切り替えに行き詰まって利用停止に追い込まれ、元の委託先であるZOZO傘下のアラタナに再委託を頼み込んだ” https://buff.ly/2C0PiTk ZOZOに後ろ足かけて離脱も、アクセンチュアに丸投げで失敗して、元の鞘に、だそう。太平洋戦争的な無残な感じ… (Twitter)
ソフトウェア時代を生き抜くために管理職（マネージャー）がすべきこと
日本企業の部長や本部長といった管理職の人は何をすべきなのでしょうか？
まず、日本の管理職と、海外のにおけるマネージャーの大きな違いについて紹介されています。外資系企業では、マネージャーはエンジニアやデザイナーと同じ専門職です。そのため、マネージャーは当然専門的なスキルを元に評価・査定されます。つまり、人事的なマネージャー（People Manager）は、組織運営における専門的な技術を会得しなければなりません。そのために外資系の多くの会社では、膨大なコストをかけてマネージャーに対して座学とロールプレイングを組み合わせたトレーニングプログラムを準備しています。
💡日本の管理職と、海外のにおけるマネージャーの違い ・マネージャーは専門職であり、特定領域の専門性を元に評価・査定される。 ・People Manager は、組織運営における専門的な技術を会得しなければならない。
マネージャーが会得すべき組織運営における専門的な技術とはどのようなものがあるのでしょうか？
👊管理職（People Manager）がすべきこと ・自分のチームメンバーが最大限に活躍できるようにサポートする ・チームメンバーの適切な配置を考える ・チームメンバーの成長のための専門的なコーチングやメンタリングを行う ・チームメンバーの成長のために適切なフィードバックや評価を行う（ただし給与を決めるだけではない） ・組織力を全体として底上げして、競合に対して優位性を作る ・メンバーが自分のチームに所属するインセンティブ（魅力）が何なのかを考え、その魅力を最大限に高め、チームメンバが離脱するリスクを下げる
Googleが行った大規模調査「Project Oxygen」とその驚くべき結果とは？
世の中では、フラットな組織がブームとなっておりマネージャーを置かないことがクールであるような風潮がありますが、Google は膨大なコストをかけて大規模調査を行い、これに対して真っ向から反対しています。
Google はこれまで、マネジメント業務の大切さを必ずしも正当に評価してきたわけではありません。2002 年、すべてのマネージャーを廃止して管理職のいない組織にするという「実験」を行いました。しかし、この実験は失敗に終わりました。2008 年には、調査チームが、マネージャーは重要な存在ではないという一部の意見を証明しようと試みますが、すぐにまったくの正反対であることがわかりました。つまり、マネージャーはきわめて重要な存在だったのです。
この大規模プロジェクトこそ、Googleが行った数々のプロジェクトの中でもっとも有名なプロジェクトの1つである Project Oxygen です。Project Oxygen の結果は公開されており、日本語の解説記事も多く出ているので、ぜひご覧ください。また、Googleの人事制度について詳しく学びたい方は、GoogleのPeople Operation上級副社長だった、ラズロ・ボックが書いた Work Rules がオススメです。
たいていの会社は、組織論になると「うちは違うから」「うちはフェーズが違うから」といって自己流を貫く傾向にありますが、Googleは、自分たちだけは例外であるというバイアスを捨てて、極めて学術的なアプローチにから様々な組織戦略を作り込んでいるところは本当に凄いと思います。元Techcrunch 編集長であり、Google Japanのスタートアップチームに所属していた（そしてつい最近まで私の後ろに座っていた）西村賢さんもこのように述べています。Work Rules に加えて re:Work もぜひ読んでみてください。
人材獲得合戦が激しいからカフェだの文化だの一生懸命という面もあるかもしれませんが、Googleでは文化人類学や心理学の学位をもった人事チームが何年にもわたってデータを集めた上で組織設計に落とし込むのが強いなと感じていました。結論はここから盗めます、超オススメ！（Twitter）
ソフトウェア時代を生き抜くために現場社員がすべきこと
残念ながら経営者やマネージャーがソフトウェアの本質を理解していない場合、現場社員ができることは限られてしまいます。それでも本書では次のようなことをお勧めしています。
👊現場社員がすべきこと ・どんな職種であっても今後の社会人の基礎教養となる最低限の技術知識を身に付けておく ・どんな小さなモックアップでもいいので、ソフトウェアの可能性や魅力を見せる
「創造性は、制約を好む」
次に本書では、サービス開発のための有効なフレームワークについて紹介しています。
・10X（テンエックス） = いま追っている指標（売り上げ・ユーザー数・ダウンロード数など）を120%成長ではなく10倍にするためには何が必要？という視点で考えてみる ・制約をかける = 絶対に0.1秒以内にレスポンスする、立ち上げから10秒以内にGmailにアクセスさせるなど、とんでもない高い要求を考えてみる ・制約を外す = 人を無限に雇えたら？予算を無限に使えたら？など当たり前の制限を外してみる
元Googleの上級副社長で、のちにYahooのCEOになったマリッサメイヤーは、「創造性は、制約を好む」と述べています。
サービス開発のためのフレームワーク
ソフトウェア時代に、サービス開発のための様々なフレームワークが生まれました。その代表的なものが、リーンスタートアップとデザインスプリントです。
✨リーンスタートアップとは？ ユーザーの求めるプロダクトを出すまでの仮説検証プロセスを、構築（Build）→計測（Measure）→学習（Lean）のサイクルとして定義し、仮説を元に検証のために必要な最低限の機能を構築（Build）し、その成果を計測（Measure）し、計測データに基づいた学習（Lean）から修正を加える。これを何度も何度も繰り返す
デザインスプリントとは、Googleの投資チーム（旧Google Ventures) でも推薦しているフレームワークで、5日間を使って短期間で一気にプロダクトの骨格を作り上げていく考え方です。Slackや、Blue Bottle Coffee、Facebook、AirBnB でもこのフレームワークが使われたそうです。日本語の詳しい説明は、この本に詳しく書かれています。
どちらのフレームワークも、ユーザーに寄り添いながら改善を高速回すことを重要視しており、ソフトウェア時代の開発プロセスとして確立されました。
プロダクト開発の骨格を定義するフレームワーク
サービスの骨格をリーンスタートアップや、デザインスプリントで作り上げたあと、それらを実現するためのプロダクト開発は、どのように始めるべきでしょうか？本書では3つの方法が紹介されています。
🗒プロダクト開発の骨格を定義するフレームワーク ・PRD (Product Requirements Document） ・プレスリリース ・OKR
PRD（Product Requirements Document）とは、製品における「What」を定義するドキュメントです。そのサービスを実現するために、どのような背景から、何を作るのかを明確に定義します。実際に製品を作り出すと、どこまで何を作ればいいのか？に対する認識がチーム内で乱れてきます。このような迷いが生じたときに、チーム全体として立ち戻れるためのドキュメントを準備しながら進めていくわけです。
地球上で最もお客様を大切にする企業を目指しているAmazonは、プロダクト開発の骨格もユーザー目線、プレスリリースという形で定義しています。プレスリリースで一般ユーザーに対して価値を示すことができないプロダクトは、はじめから失敗しているというわけです。
何をするのか？に連動する目標管理制度がOKRです。OKRとは、Objectives and Key Results の略で、目標を1つと、それに紐づく複数主要な結果を複数設定するというものです。OKRをセットするためには、当然Objectiveは言語化される必要があり、Key Results は達成率が計測できなければなりません。
これらのフレームワークを使いながら、プロダクト開発の骨格「What」を定義していきます。
ここから先はプロダクトの運用方法について、NPSの利用、ミッションステートメントの役割、抜擢・エグゼクティブ採用文化、CIOとCTO、社内開発のオープンソース化などについて、著者の経験を元に紹介されています。
第3章を読むだけでもたくさんのことが学べます！
✏️第3章で学べること ・手の内化とは何か？ ・Netflix がうまくいった理由は？ ・経営陣はソフトウェア時代に何が求められているのか？ ・マネージャーはソフトウェア時代に何が求められているのか？ ・管理職とマネージャーの違いは？ ・現場社員はソフトウェア時代に何が求められているのか？ ・ユーザーニーズを理解するときに陥る罠は？ ・マーケットインとプロダクトアウト、どちらが有効なのか？ ・10xとは何か？ ・Googleが新しいノートパソコン（Chromebook）開発したときに、Googleはどのようにサービス作りをしたいのか？ ・著者がGoogle日本語入力を開発するときにどのようにサービス作りをしたのか？ ・リーンスタートアップとは？ ・デザインスクリプトとは？ ・リーンスタートアップに反対する考えとは？ ・PRDとは何か？何をどのように書くべきなのか？ ・インセプションデッキとは何か？ ・OKRとは何か？ ・NPSとは何か？ ・ユーザーの要求にはどこまで答える必要があるのか？著者はMicrosoft時代にこの課題にどう立ち向かったのか？ ・ミッションとプロダクト開発はどうリンクするのか？ ・著者がChromebookを開発するときに設定したミッションは？ ・ソフトウェア時代のチーム作りに欠かせない要素とは？ ・CTOとCIOとは何か？ ・オープンソースとは何か？ ・インナーソースとは何か？ ・GitHubとは何か？Pull Requestとは何か？
第4章 手の内化を広げるための理想的な組織とは？
第4章では、ソフトウェア時代の組織論について考察が展開されます。
まず、ソフトウェアの外注についてです。著者は、外注の必要性を理解しつつも、ソフトウェア・ファーストを実践する上で開発の内製化は必要な一手であると述べています。
開発の内製化は、ソフトウェア・ファーストを実現する上で必要
これに同意し、いざ社内に開発チームを新設しようとしても、このような問題（誤解）がしばしば発生します。これについて筆者の考えをまとめてみましょう。
😱開発チームを内製化するときによくある誤解 1. 今後AIなどが発達すればエンジニアの価値が下がるのではないか？ 複雑な要件定義は人間にしかできないから大丈夫 2. エンジニアを採用するために大金を払わないといけないのではないか？ 高い能力を持っている人に報酬を払うのは当然。給与水準が市場と釣り合っていなければ変えるべき。そして何より「挑戦しがいのあるテーマ」を与えることが大切 3. 作る物が無くなったらどうするのか？ 作る物がなくなったら、あなたの会社は潰れているから大丈夫 4. マネージメントができるのか？ マネージャーは開発者が理想。いなければ採用すべき。
例外的に、誰が作っても同じものや、1度しか使わないソフトウェア、オープンソースの利用などで外部リソースを利用することは許容できますが、基本的には内製化すべきであると述べています。
ソフトウェアを内製化するために必要な人たちとは？
では、ソフトウェアを自作するためにいったいどのような人たちを雇用すべきなのでしょうか？
😃ソフトウェアを自作するために必要な人たち ・プロダクトマネージャー ミニCEOと呼ばれる。ユーザーの求めるプロダクトを追求する。ソフトウェアの仕様を決め、エンジニアやデザイナーとコラボレーションしながら具体的な開発方針を決定、ソフトウェアの継続的成長の責任を負う。 ・ソフトウェアエンジニア いわゆるエンジニア。プロダクトの方向性を理解して実際にモノを開発していく ・エンジニアリングマネージャー ソフトウェアエンジニアを取りまとめていく。エンジニア1人1人の成長にも責任を持ち、個人のキャリアアップを進めると共に、チームとしての総合力を最大化させる ・デザイナー ソフトウェアを提供したいユーザーのユーザー体験に責任を持つ。 ・QAエンジニア ソフトウェアが期待通りの動きをしているのか確認する。セキュリティやプライバシーなどのガイドラインが守られているのか検証する
いくつか重要なことをまとめてみましょう。
👍プロダクトマネージャー（PM）は企画、設計、品質管理、そしてリリース後のグロースまで、プロダクトに関する全責任を負う 👍エンジニアマネージャーは、自分の開発チームを持ち人事権を持つ一方で、プロダクトマネージャーは持たないことが多い 👍プロダクトマネージャーとエンジニアリングマネージャー（もしくはエンジニア）完全に別職種である。ただし相互に異動を行うことが多い 👍日本の場合、プロダクトマネージャーとエンジニアリングマネージャーが兼任していることが多い
私の実感では、日本におけるプロダクトマネージャーは事業責任者が兼任していることが多いように思います。しかし事業責任者は営業組織（つまりP/L）の責任も追っており、インセンティブが予算達成に連動している場合が多いため、日本においてプロダクト開発がマーケットイン、かつ短期的な視野になりやすいのは、そのようが背景もあるのではないかと考えています。
どのような役割の人が必要なのかについては、まず Job Description（募集要項）を作り、自分の会社が必要としている人材を言語化することを著者はお勧めしています。
📃一般的なJob Descriptionの形式 ・募集の背景 なぜこのポジションの人が必要なのか？ ・職務内容 どのようなことをしてもらうのか？ ・責任 具体的にどこの領域までの責任なのか？ ・要件 応募するにあたり必要な要件
出島戦略は有効
新しいことをはじめると、大抵社内で白い目で見られたり、抵抗勢力が生まれたりするものです。そのような状況を避けるために、本書では出島戦略を紹介しています。これまで当たり前のルールだったことを例外的に治外法権とする手法です。これにはいくつか大切なポイントがあります。
出島戦略で大切なポイント ・目標を明確にする ・達成率を計測できるようにする ・定期的に何をやっていて、どのような成果が出ているのか社内に周知する
給与テーブルを考え直す
必要な人材が決まったら、いよいよエンジニアをどのように採用すべきかという問題に直面します。
まず、日本企業がもっとも弱く、そして踏み込めない領域は、給与だと思います。著者は明確にこのように述べています。
人はお金だけで動機付けされるわけではないと前述しましたが、それでも他社の提示額より著しく劣っていては優秀な人材を獲得できません。そこで社内の給与テーブルの見直しを検討する必要があります。（中略）給与テーブルに関しては、社内の職種間の平等を考慮してばかりいると、外部から優秀な人材を獲得することは不可能ですし、社内の優秀な人材が外部流出するリスクも高くなります。
ジョブ型雇用か、メンバーシップ雇用か？
一体なぜ日本企業の給与が他の国に比べてこれほどまでに低いのでしょうか？その最大の理由は雇用スタイルの違いにあると私は感じています。
日本の多くの会社では、メンバーシップ雇用が一般的です。メンバーシップ雇用というのは「いい人であればどんなポジションにでも活躍できるはずだ」という大原則と、解雇不可の原則、終身雇用制度の元、職務を限定しない形で雇用をして、企業側の事業状況に応じて社員の配置転換を行う方法です。いい側面としては、抜擢人事（能力が足りてなくても将来性を見込んで昇進させたり、新しいチャンスとしてポジションを与えたりすること）が可能だったり、会社に対するロイヤリティが高まる傾向にあります。一方で、責任に対して給与が明確に紐づいていないため、地位や役職に対して給与が大きく変動せず、多くの場合、1つの給与レンジで運用され、給与が中央に寄ってあまり動かない傾向があります。
ジョブ型雇用というのは、おもに外資系企業を中心に使われている方法で、特定の専門的なスキルを持っている人を雇用するという考え方です。雇用がジョブに紐づいているため、ジョブが必要なくなれば解雇されますし、そのマーケットの市場価値に応じて給与レンジも個別にセットされます（つまり営業とエンジニアと法務と労務はそれぞれ市場価値に応じて別々の給与テーブルがあるということです）。もし別のチームに異動したければ、専門性を確認するために面接を受け直すことになり、給与レンジも再設定されます。
著者は、少なくともエンジニアのような高い専門性を持つ人を採用する場合、ジョブ型雇用への転換が必要であると主張しています。
「いいエンジニア」って何？ボトムアップのアプローチを使ったフレームワーク
次に、エンジニアの評価基準についてです。「いいエンジニア」というのはいったいどんな人なのでしょうか？著者は、それを考えるためのフレームワークを紹介しています。
👍ボトムアップアプローチの方法 1. 社内のエンジニアを簡単に優秀だと思う順番に並べて、その理由やエピソードを記載する（厳密に順位をつける必要はない） 2. 複数のマネージャーでランキングをつけて、それぞれのランキングと理由を見ながら、チーム全体としての順位を決定する（＝キャリブレーション） 3. ランキング上位のエンジニアと選ばれた理由を見ながら、「いいエンジニア」だと思う人の共通の特徴を抽出する。逆にランキング下位の人のエピソードから「ふさわしくないエンジニア」の例も抽出する
このようにして出てきた「いいエンジニア」と「ふさわしくないエンジニア」の共通点やエピソードから、適切な評価基準を作っていくのです。
組織文化を作る〜リモートワークを認めることは必要なことなのか？
次に文化の話です。近年では、リモートワークやフレックス制度は優秀なエンジニアを採用するための最低限のレベルのようになっています。しかし本書は、あくまで制度は何かの課題を解決するためにあるものであり、何を解決したのかを明確にすべきであると述べています。
ここで例に上がっているフレックスタイム制とリモートワークについてまとめてみます。
フレックスタイム制 👍個人のプライベートライフにおける事情にも配慮でき、ライフステージの変化にも対応が可能 👍首都圏での通勤ラッシュの時間帯を避けて通勤できる ❌コアタイムを短くし過ぎると、メンバー全員がそろう時間が短くなる ❌コアタイム以外に関係者全員にそろってほしい会議を設定するのは避けるべきなので、短くなったコアタイムの間に会議が集中しがち ❌コアタイムは通常日中の最も生産性が高くなる時間帯になっているが、この時間帯をすべて会議に取られてしまう可能性がある 💡個人に与える柔軟度と組織の論理は時としてトレードオフの関係にあるので、本質を忘れないように注意すべき 💡例えば育児や介護などの事情で勤務時間の変更が必要になった社員には、別制度を用意する 💡全社員に平等に与えるべき柔軟性と、特別な事情が生じた社員に対する対応との線引きも考える
リモートワーク 👍家族が病気になった場合や電車事故、天候悪化などで出社が難しくなった場合のリモートワークは、むしろ許可しない理由を探すほうが難しい 👍情報漏えいなどの懸念についてはガイドラインを設ければ済む 👍個人が最も成果が出ると考える場所から勤務できる 👍子どもを迎えに行き、夕飯を家族で食べ、子どもを寝かしつけた後にやり残した仕事をしたいときになど個人のライフスタイルに合わせられる ❌いくら通信技術が発達し、チャットで常時つながっていて、いつでもビデオ会議ができるとはいえ、同じ場所にいるという環境に比べたらつながりは希薄になる ❌オフィスにいる大多数の人とリモートワークしている少数の人との情報格差が生まれる 💡福利厚生の一環として考えるべきものと、それ以外を目的とするものがあるはずなので、どちらを目的としたものかを明確にすべき
ここで2点ほど紹介したいことがあります。
まず1点目は、Googleは定常的なリモートワークを推奨していないという点です。グーグルに対する様々な伝説が語られているようですが、実際は極めて現実的だということです。
グーグルも定常的なリモートワークに対して非推奨の立場を取っています。その理由は、チームが机を隣同士に並べて働くのに比べて、リモートワークでは生産性が下がり、創造的な成果も生み出しにくくなるからです。
もう1点は遅刻についてです。日本のIT企業の中には、残業代の計算などをしなくていいように裁量労働制を取っているにもかかわらず、「定時」（もしくは組織文化として明文化されてない精神的束縛を与える定時）が存在する会社があります。私の前職でも、5分、10分の遅刻にものすごく厳しいチームがありました。このような無意味で自己満足な管理は全廃すべきであると思います。
余談になりますが、勤務体系に関する持論として、筆者は１秒の遅れも許さないような勤怠管理こそ撤廃するべきだと思っています。さすがに最近は少なくなりましたが、勤務開始時間までにタイムカードを押さなければとオフィス街を走っている人を見ると、５分遅れたからと言って何があるのだろうと疑問になります。５分や10分の遅れを人事評価に使っている組織があったら、何のためにそんなことをするのか自問してみることをお勧めします。
✏️第4章で学べること ・ソフトウェアを外注することの問題点 ・ソフトウェアを内製化するとはどういうことは？ ・ソフトウェアを内製化するときによくある誤解は？ ・プロダクト志向とは何か？ ・ソフトウェアに必要な職種とは？ ・プロダクトマネージャーとエンジニアマネージャーの違いは？ ・プロダクトマネージャーとエンジニアマネージャー、エンジニアの標準的なキャリアアップとは？ ・CTOとVPoE（Vise-President of Engineering）の違いとは？ ・Job Description のサンプル ・事業部別組織か職能別組織か？ ・マトリックス組織は？ ・出島戦略とは？ ・エンジニアの給与設計はどのようにすべきか？ ・いいエンジニアを定義するボトムアップの手法とは？ ・リファラル採用から見える自社の強みと弱み ・人材エージェントに頼っていい人、ダメな人 ・最初の1名の重要性 ・フレックスタイム制の功罪 ・リモートワークの功罪 ・組織文化を作るときの大前提とは？
第5章 これからの開発者のキャリアを考える
最後の第5章は、人にフォーカスを当て、ソフトウェアに関わる人たちがどのようなキャリアを作っていけるのかについて紹介しています。
👊ソフトウェア職種のキャリアとリーダーシップの方向性 ・ソフトウェアエンジニア 技術を使った課題解決をリードしていく ・エンジニアリングマネージャー 人材育成やチームワークの醸成をリードしていく ・プロダクトマネージャー プロダクトの成功を通じた事業の成長をリードしていく
それぞれの職種の横への展開（キャリアチェンジ）について、どのような能力が必要なのかについても詳しく紹介されています。
日本ではエンジニアからプロダクトマネージャーやエンジニアリングマネージャーにキャリアチェンジしていくことに抵抗がある人も多いですが、それぞれの職種に必要とされている能力やミッションを正しく理解していない場合も多いようです。たとえば、エンジニアリングマネージャーとエンジニアはキャリアップの関係ではなく、キャリアチェンジの関係なのですが、キャリアアップの関係だと勘違いされている例もあるようです。
似て非なる3つのプロダクト開発に関わる職種に必要とされる能力、ミッション、そして違いを正しく理解することで、キャリア構築のイメージが格段に持ちやすくなるように思います。
最後に、どのようなキャリアパスを描くにしても、必要なことが3つあると紹介しています。
ソフトウェア・ファースト人材になるために必要な3つのこと 👊感度の高い人材になる 👊ITで武装する 👊作り手の気持ちを理解する
世間で流行っているプロダクトを実際に自分の手で使ってみること、IT技術を最大限に活用してみること、そしてエンジニアリングをよければ覚えてみることです。
第5章を読みことで、ソフトウェアが様々な職種の人たちの集まりでできていること、そしてそれぞれの専門性がどこに向かっているのかを体系立てて知ることができます。エンジニアはもちろん、事業責任者も一読の価値があると思います。
挑まなければ、得られない
第5章の最後には、著者のこれまでのキャリア、その時々の悩みや苦悩が事細かに書かれています。特に外資系を退職して、スタートアップ、そして独立の道を選択したときの様々な葛藤や苦悩や希望は、ここだけでも本書を手にとってよかったなと思える内容でした。
「グーグルを辞めて、同じように世界を変える仕事ができるのか」
グーグルは事業化の判断材料の一つとして「10億人のユーザーにリーチできるか」を考えています。世界を変えられるか、10億人規模の事業をしていた過去の自分に負けていないか、その視座を忘れないようにしたいと考えています。
✏️第5章で学べること ・T型スキルとI型スキルとは？ ・T型スキルからのキャリアアップの様々な方法 ・ソフトウェアエンジニアの3つのキャリアパス ・マネージャーに抵抗がある人はどうすべきか？ ・UX関連職のキャリアパス ・QAエンジニアのキャリアパス ・ソフトウェアエンジニアのキャリアパス ・エンジニアリングマネージャーのキャリアパス ・プロダクトマネージャーのキャリアパス ・さまざまなCxOの役割について
【感想】ソフトウェアに関わる人の必読書
1つ1つ書かれていることを読んでいくと、不思議と引っかかるポイントもなく、同意しながら簡単に読み進められる本書ですが、読み終わると、様々なトピックについて多彩なアングルから圧倒的にわかりやすさでまとめられていたことに気付きます。
日本ではプロダクトマネージャー職がまだまだ浸透しておらず、特にIT関連企業では、事業責任者がプロダクトマネージャー職を兼任しているケースで、事業責任者がエンジニア経験者ではないことがほとんどでしょう。そのような方にこそ、是非手にとって欲しいなと感じました。