及川卓也のレビュー一覧

とても勉強になる1冊。OKRを使う会社の人もそうでない会社の人も、特にチームビルドを担う前に考え方を知っていると役に立つと思います。

「ソフトウェア・ファースト」は、エンジニアとしてのキャリア構築から組織のDXの実現方法に至るまでを、とてもわかりやすく紹介してくれる本でした。
私自身、エンジニアとして共感できる箇所が多くありました。特に、技術だけではなく、それをビジネスや組織にどう活かすかという視点が紹介さてれいるのが印象的です。...続きを読むIT業界で働くすべての人におすすめできる本です。

ロードマップは早めに公開し、関係者を早期に巻き込んでおくこと。
プロダクトマネジメントに必要と思われるあらゆることがまとまっている良書だと思う。ボリューミーすぎて、咀嚼できずにすり抜けていった内容も多いが、プロダクトマネージャー的な立場になったらバイブルとして手元に置いておきたい。しかし、求められる...続きを読むスキルが多くて高いなあ…

この本ならプログラミング自体が初めての人でも挫折せずに取り組めると感じました。
プログラミングの入り口に最適だと思います。

機能開発チームとエンパワードチームの対比からエンパワーされていることの重要性を説き、いかにエンパワーしていくか、そのうえでいかに目標を定めプロダクトを成長させていくか詳細に解説されている。
ここではBig Techを目覚ましい成功に導いたOKRが、なぜ多くの組織では機能不全を起こしているのかといった...続きを読む点にも触れており目標設定にうまくいかなさを感じている向きにはこの節だけでも読んでもらいたい。

プロダクトマネジメントについてかなり体系化されている。ただやったことない人にとっては、難しいと思うので、ケーススタディだけ読むことをオススメする。

最初に例となるわかりやすいストーリーが記述してあり、どういうものかの理解がしやすかった。OKRのとっかかりを知るには、比較的すぐ読めるし、いい本だと思いました。

プロダクトマネージャの仕事内容や心構え、スキルの伸ばし方など広く浅く書かれた本。
プロダクトマネージャを目指す人にとっては、４００ページもある大作ですがバイブルとなる本でしょう。
超お勧め。

書ききれないほど多数のTIPSがあるが、ここではその中の心に深く残ったいくつかだけメモ。

・チームビルデ...続きを読むィングの一貫としてキックオフ時に何を大切にするチームであるか認識を合わせる
→やらないことを決めたり、機能、品質、締め切り、予算の優先度を決めたり。。。

・値付けに関してはユーザーが本来必要としている以上の機能があったとしても、ユーザーは必要としている機能の価格しか払わない。コスト積み上げ方式による価格は提供者の一方的な論理となってしまい、NG
→ほんまそれ！　コスト積み上げ方式になりがちであるが、どうやってこれを突破するか。。。

辞書的に使うべき本ですね！
今後何度もお世話になります！！

■アプリケーションソフトウェアが登場して訪れた変化の特徴２つ
　一つは「おもちゃ」が世界を変えたことです。言葉がきついと感じるかもしれませんが、登場した当時は業界内でおもちゃのように扱われていた技術が、その後実際に産業構造を変えたのです。例えば、ダウンサイジングの始まりはパーソナルコンピューターでし...続きを読むたが、登場当時のパーソナルコンピューターはコンピューターマニアの週末の遊び道具でした。コンピューターサイエンスを学んで本格的なコンピューターの研究開発をしているようなエンジニアは、パーソナルコンピューターの担当をしたがらないようなこともありました。クラウドも同じです。インターネットの黎明期、Web技術は「ゆるい情報共有のツール」に過ぎず、これが進化して国や企業の基幹業務を支えるものになるとは誰も思っていませんでした。おもちゃと思われていたものが世界を変える。これが一つの法則です。そして、このおもち産業全体に変化をもたらす時は、先行してコンシューマー側で普及していたことも忘れてはいけませんパーソナルコンピューターもWebもそうです。
　もう一つの特徴は、コンシューマー側で先にイノベーションが起こることと深く関係しています。ユーザー体験の価値が飛躍的に高まったことです。当初は機能が備わっていることが重要でしたが、その次にユーザービリティ、つまり使いやすいことが求められるようになり、そして体験が価値を持つようになりました。


　Slerの顧客となる事業会社は今、物売りや労働集約型のビジネスモデルから、サービスモデルへと転換しようとしています。それを支えるITシステムも、「作って終わり」ではなく、変化に合わせて「育てる」ことが重要になっています。そんな状況下、SIerに開発を委託するスタイルは多くの不利を抱えてしまいます。意思疎通の難しさや開発の遅延、システムの変更のたびに必要となる契約など、従来のSIerとの付き合い方では変化に追従できません。1Tが事業の中核を支える存在を担っていく中で、ITをすべて外部に委託するのはリスク以外の何者でもないのです。


　筆者はDXを進めるためには、内製化が理想だと考えます。システム開発のノウハウが自社内に貯まるという理由だけではありません。DXのような新たな事業を興す時は、仮説検証を行うスピードと、企画から運用まで一気通貫のIT活用が必須になるからです。
　DXレポートにも似たような提言が書いてあるものの、なぜか結論は外部パートナーとの新たな関係構築というお茶を濁した形になっています。

　我が国のように外部のベンダー企業に開発を委託することが主となっている場合は、メンテナンスをある程度の間隔でまとめて行っていくことになり、ベンダー企業側にノウハウが蓄積される。この形態では、要求仕様を整理・調達し、契約を結び、ウォーターフォール型開発を行うので時間もか

　これまでシステム開発を外部パートナーに一任してきた企業が、いざDXに取り組むタイミングですべてを内製化するのは現実的ではないと思う方もいらっしゃるでしょう。割合だけで見た場合、実際のところ半分程度は外部パートナーに委ねるというケースもあるかもしれません。ただし、現実問題としそうせざるを得ないとしても、DXで肝になるのはIT活用を「手の内化」できるかどうかです。
　手の内化とはトヨタグループで使われている言葉です。トヨタ企業サイトの「トヨタ自動車15年史」によると、80年代に発展したカーエレクトロニクス分野の関連機能をグループ内で内製化したことを「手の内化」と記しています。筆者なりにその意味を解釈すると、自社プロダクトの進化にかかわる重要な技術を自分たちが主導権を持って企画・開発し、事業上の武器にしていくことを「手の内化する」と言うのでしょう。DXでもこの考え方がとても重要になります。仮に外部パートナーを活用するとしても、ITの企画、設計、実装、運用というすべてのフェーズを自らコントロール可能な状態にすること、つま手の内化していくことが大事なのです。それこそが本書で提唱しているソフトウェア・ファーストです。


　このブロックバスターの失敗から、次のような学びが得られます。まず、産業構造の変化に対して敏感でなければなりません。今まで資産だったものが負債に変わってしまうことを認め、自社事業のカニバリゼーションを恐れないことが重要です。また、トップのITリテラシーがいかに大切かも分かります。ブロックバスターのCEOはUSBメモリーへのダウンロードという時代錯誤のアイデアを無理強いし、社内の反対を押し切って実行しました。ここまでではないにせよ、デジタル戦略の目利きができな経営トップは日本企業でも多いのではないでしょうか。トップのITリテラシーが企業の存亡にかかわるということも覚えておきましょう。
　この2社のストーリーから学べることは、次のように整理できます。
1.手段が変わっても変わらない、高く掲げた企業理念を大切にする。
2.エンゲージメント強化への取り組みを妥協しない。
3.意思決定者が技術に対する理解を深める。　
　これらが企業の存亡にかかわることが、この2社の歴史からも分かります。


　…ソニーのサイトにある社史には、「企画書を提出して、試作を行ってという通常の手順を踏んでいたら、この商品は生まれなかったかもしれない」と書かれています。市場調査の段階で特約店の声を聞いていたら、企画段階でストップしていたかもしれません。

■アップルに学ぶ
1．ハードウェアはソフトウェアのためにある
2．ソフトウェアはユーザーエクスペリエンスのためにある
3．ユーザーエクスペリエンスは人々の感情を満足させるためにある


　また、「お困りなことはないですか?」という問いに対して、本当に困っていることを答えないのは、本人が自覚していない場合もあるでしょう。それ以外に日本では困っていることを伝えるのが恥ずかしいという価値観も根強く残っているように思います。筆者が東日本大震災でボランティアをしていた知人から聞いた話では、避難所でも同じようなことがあったそうです。その時の対策として知人に教わったのは、「周りでお困りの方はいらっしゃらないですか?」と質問することでした。本人以外の方の困りごとを聞く形を採ると、「本人を含む人たち」の困りごとを聞き出すことが可能となるそうです。筆者が災害ボランティア以外の場でこの質問をしてみても、有効に機能しました。回答者が勝手に想像して質問に答えてしまうリスクもあるので、状況に応じて使い分ける必要があるものの、本人が回答しにくいことを聞き出すテクニックの一つにはなりそうです。


■プロダクトの骨太の方針を決める
・製品要求仕様書(PRD=Product Requirements Document)
　・プロダクトの概要
　・開発の背景
　・プロダクト原則
　・スコープ
　・対象ユーザー
　・ユースケース
　・市場分析
　・競合分析
　・機能要求
　・その他の技術的要求
　　　システム要求
　　　セキュリティ要件
　　　プライバシー要件
　　　パフォーマンス要件
　・リリーススケジュールおよびマイルストーン
　・マーケティング計画
・ワンページャー
・プレスリリース
・インセプションデッキ
　1.我々はなぜここにいるのか？
　2.エレベーターピッチ
　　・（潜在的なニーズを満たしたり、潜在的な課題を解決したり）したい
　　・（対象顧客）向けの
　　・（プロダクト名）というプロダクトは
　　・（プロダクトのカテゴリー）です。
　　・これは（重要な利点、対価に見合う説得力のある理由）ができ、
　　・（代替手段の最右翼）とは違って、
　　・（差別化の決定的な特徴）が備わっている。
　3.パッケージデザイン
　4.やらないことリスト
　5.「ご近所さん」を探せ
　6.解決案を描く
　7.夜も眠れない問題
　8.期間を見極める
　9.何を諦めるのか
　10.何がどれだけ必要か

■全員を幸せにしなくていい
　他にも、進歩しないユーザーへの対応にも注意が必要です。これは実際にあった話なのですが、WindowsXPが登場した頃、一部のユーザーはユーザーインターフェイスの変更を極度に嫌いました。それ以前のWindowsでは、パーソナルコンピューターをシャットダウンする際にはラジオボタンが表示されており、上から何番目のボタンをチェックすればいいかを覚えていたのに、ドロップダウンリストに変更されてから、それが分からなくなったと不満を訴えていました。ユーザーインターフェイスも開発者の気まぐれで変更しているわけではなく、ユーザーのニーズに応える形で、プロダクトの進化とともに変更を加えています。こう言っては申し訳ないですが、進化を止めてしまったユーザーに合わせていてはプロダクトの進化も止まってしまいます。一部のユーザーの声に右往左往するのではなく、プロダクトがターゲットにしている正しいユーザー(この場合はプロダクトとともに進化し続けるユーザー)に向けてプロダクト開発をするのが大事です。


■エイリアンとミュータントを登用する
　このチームづくりの中でとても重要なのが、変革を主導する人材を社内外から登用・採用することです。筆者が以前に対談した経営者は、「エイリアンとミュータント」が重要だとおっしゃっていて、言い得て妙だと感じました。変革に向けて外部から採用する人材は文字通りエイリアンで、社内で登用すべき人材は突然変異的に生まれた異端なミュータントです。変革というのは過去の延長線上にはありません。変わり者に活躍の場を与えましょう。その際に必要となるのは、経営陣の強い後ろ盾です。変わり者が今までとは違ったことを始めると、必ず軋轢が生じます。変わり者がひるまずに変革を進め続けるためにも、経営陣のサポートは不可欠です。経営陣まで日和ってしまわないように強い覚悟を持ち、その覚悟に応える異能集団を構築するのがいいでしょう。それと同時に、精神論だけでなく、立ち返るべき原理原則を新たに用意する必要があります。前述した企業理念がもしあるならば、それに立ち戻りつつ、新たな変革に向けての理念を再定義します。変わり者である変革推進者も好き勝手に現状を否定するのではなく、この原理原則である新たな理念を判断軸とする必要があります。


■オープンソースプロジェクトの文化の特徴
・開発方針や機能開発について、誰がどんな発言をしても平等に扱われる。
・情報を一人で囲い込まず、横展開する人が尊ばれる。
・社会的な地位や経験値より、積極的に開発に参加する人が尊ばれる。
・他人が進めている開発を進んでサポートする協業も尊ばれる。
・結果、開発したソフトウェアの成果は「参加者全員の成果」と見なされる。

■インナーソース＝オープンソース開発のベストプラクティスと文化を企業内に根付かせる活動
　このインナーソースの特徴となっている、オープンソースプロジェクトのベストプラクティスとは何でしょう?それは、オープンなコミュニケーションと協業です。実際にどのようにそれが進んでいくのか、具体的に見てみましょう。
　筆者がインナーソースを知るきかっけになった場はギットハブのイベントだったので、登壇した企業各社はGitHub Enterpriseを社内のリポジトリとして使っています。リポジトリとはソフトウェアのソアースコードの置き場です。GitHubの誕生前からソースコードのバージョン管理は行われていましたが、それらとGitHubとの大きな違いは、GitHubがソーシャルコーディングと呼ばれる「人と人との協業」を重視している点です。その象徴がプルリクエスト(Pull Request)と呼ばれる仕組みです。
　開発者はプログラムの修正を行う場合、大本となるブランチ(バージョン管理のために枝分かれしたソースコードの集合)からコードをコピーして、自分だけのブランチに移動させてから作業します。そここでの修正作業が終了したら大本のブランチに反映させるのですが、その前に自分以外の人に修正箇所を確認してもらうプロセス=コードレビューが入ります。この確認依頼~反映処理のことを、大本のプランチから「引っ張ってもらう=プル(Pull)」と言うことから「プルリクエスト」と呼ぶのです。GitHubを使った開発はこのプルリクエストが中心になっており、日本人エンジニアの間では省略して「プルリク」と呼ばれています。
　オープンソースプロジェクトでは、同じ組織に属していない人たちがソフトウェア開発に貢献しているので、GitHub上でこのプルリク処理が大量に行われます。所属組織の思惑が異なっていても、オープンソースプロジェクトの方向性に合う限りは、多様性のある個人がプルリクを送ることでソフトウェアが進化し続ける。これがオープンソースの強みです。ただし、企業がGitHub Enterpriseを導入したからといって、オープンソースプロジェクトと同じように違う部署の人同士が頻繁にプルリクを送り合うようにはなりません。同じGitHubという場所は用意されていても、その中に部署ごとの入れ物が用意され、違う部署の人はアクセスできないか、アクセスできてもコードに修正を加えようとは思わないのです。GitHubが掲げるソーシャルコーディングには程遠い世界です。
　インナーソースはこの部署間の壁を壊し、業務担当外のプロジェクトに対してもプルリクで貢献する人を増やすための活動になります。アメリカン航空がやっていたように社内ハッカソンを行うなど、GitHubを使った社内のコミュニケーションを意図的に促進して初めて、協業が進んでいきます。
　これは必ずしもGitHubがなければできないわけではありません。GitHubはGitというオープンソースのバージョン管理ソフトウェアを使ったホスティングサービスなので、Gitを使えば同じようなことができます。他のホスティングサービスもありますし、自分でGitを運用することもできます。いずれの場合も、大事なのはオープンソースプロジェクトと同じように、社内のエンジニアが自分が担当するプロジェクト以外にも貢献したいと思える状態を作り出すことなのです。
　会社によっては、ソフトウェア開発を単に飯を食うための手段だと思っているエンジニアしかいないこともあります。彼らにとっては、ソフトウェア開発はあくまでも会社から指示された仕事なので、自発的に自分の担当プロジェクト以外を見に行くこともありません。よしんば修正を加えようなどとは思わないのです。そこまで消極的でなかったとしても、自分の担当プロジェクトに忙殺されていて、他のプロジェクトに興味を持つ時間が全くないということもあるでしょう。

■開発を外部委託する問題点
　しかし、筆者は3章でDXの本質を「IT活用を手の内化すること」と定義し、できる限り開発を内製化するのが理想だと述べました。これはDXに限らず、あらゆる企業がソフトウェア・ファーストを実践する上で必要な一手だと考えています。
　ここで言う内製化とは、プロダクトの企画、開発、運用に至るまでを社内で行うことです。内製化する最大のメリットはスピードです。すでに説明したように、現代のソフトウェア開発では反復(イテレーション)が基本になります。仮説検証サイクルと言ってもいいでしょう。プロトタイプができたら、それを実際にターゲットユーザーに触ってもらい、結果を元に修正をかける。プロダクトを世に出した後も、ユーザーの反応を見ながら改善を加えていき、より使われるものに育てていく。この反復作業をスピーディーに行うのが肝になります。
　今日、プロダクトの評価はすぐに広まります。ユーザーはTwitterなどのソーシャルメディアに使ってみた感想を投稿しますし、iPhoneのアップストアやAndroidのプレイストアのようなマーケットプレイスでは他ユーザーのレビューとコメントが見れます。ユーザーのフィードバックがすぐに得られる時代になったからこそ、ユーザーに使い続けてもらうための対応は迅速に行わなければなりません。マーケットプレイスでのレビューのように、一度付いたネガティブなイメージを払拭するのは難しくなっているのです。
　ユーザーからのフィードバックに対して迅速な対応ができないならば、むしろ時間をかけ、完成度の高いものを出すべきだという考え方もあるでしょう。とはいえ、変化の激しい現代において、完成度を高くする打ち手は実際に使われないと見えてこないというジレンマがあります。いずれにせよ、スピーディーに対応し続けるのはもはや宿命と考えなければならないのです。
　このような状況下、プロダクトを開発する人が別の場所にいたり、別の企業に属していると、スピードが出ません。机を隣に並べていれば、すぐに相談して3日もあれば対応できることが、週や月単位の仕事になってしまうことも珍しいことではありません。例えばECサイトにキャンペーン用の文言を1つ足すだけなのに、来週に持ち越されてしまってはせっかくの機会を逃してしまうでしょう。
　新規プロダクトの開発を外部に委託するとなれば、契約形態にもよりますが)新たに契約を結ばなければなりません。契約書を作成し、社内承認を得た後、先方にも確認してもらい、契約を締結する。これだけでも時間がかかる上、そのための作業コストは馬鹿になりません。開発と運用を一体化したDevOpsやグロースハックを進めていく時も、ユーザーの利用状況を分析して、そこから得られた仮説を即座に検証していく必要があります。これを外部に委託するのは実質的に不可能です。委託先のエンジニアが優秀で、発注者のビジネスを深く理解していても、過去の経緯や社内事情といったコンテクストを汲ん臨機応変に対応するのはとても難しい上、良かれと思ってやった行為が裏目に出た場合は責任を問われることになるからです。この点からも、社内で完結するオペレーションを持っている組織とはスピードが雲泥の差でしょう。
　内製化が必要なもう一つの、そして最も重要な理由はノウハウの蓄積です。何度も配しているように、現代のプロダクト開発は仮説検証の繰り返しです。多くの失敗の中から成功のきっかけをつかみ、それを育てていくことになります。結果だけ見ると成功しか見えないかもしれませんが、実はその裏にある多くの失敗と、そこから得た学びこそが財産となります。プロダクト開発の一部を外出ししていると、その知見が内部に蓄積されません。もしかしたら最も重要な部分が外部に蓄積されてしまうのです。
　システム開発を外部委託した場合、仕様や運用時の注意点などをドキュメント化して大量に納品させることもあります。しかし本来は文章として残すことが重要なのではなく、そこに何が書かれているか、そこから何を読み取れるかが大事なのです。正直、ベンダーから納品された文章を全部読んでいる人が社内にどれほどいるのでしょうか?開発に直接携わっていない人がそれを読んで、どこまで内容を理解できるでしょうか?もちろん、どちらに対しても問題のないドキュメントが提供されているケースがないとは言いませんが、多くの場合はそうなってはいないでしょう。加えて、本来残すべきノウハウは文章にされていない部分にこそあります。このように、知見を自社内にとどめておくには、内部の人間が実際に手を動かす形で携わっていないと不可能なのです。
　内製化をしていない多くの企業は、どのタスクを外出ししているのでしょう。ソフトウェア開発ライフサイクルを図4−1のように企画、仕様、設計、実装、品質確認、リリース(運用)と分けた場合、事業会社は企画を担当し、その後、品質確認の一部と運用も担当します。一次請け・プライムコントラクターと呼ばれるSIe「やITベンダー、コンサルティング会社は仕様と設計を担当します。そして、実装は二次請け・サブコントラクターと呼ばれる開発会社が担当します。さらに、QA(品質確認)や運用はその部分だけを請け負う専業ベンダーが担当することもあります。
　この構図は、それぞれの会社がシステム開発で何を重視しているのかを表しています。逆に言うと、どの仕事には価値がない(自社で対応しなくてもいいような、誰でもできる仕事)と考えているかが見えてきます。つまり、事業会社や一次請け企業は図の左側にある上流工程から、右側の下流工程に向かって重要度が下がるのです。しかし、この考えは間違いです。実装の差がプロダクトの機能や性能の差に出てくる以上、それほどまでに大事なタスクを外部に出すことはあり得ません。


　先に挙げた1や2のケースでも、リソースが不足しているからしょうがないと安易に手を出さず、外部委託するリスクは慎重に検討しましょう。事業やプロダクトの内容、開発フェーズによって、外部委託可能な領域は異なります。そして、重要なのは100%の内製化を目指すことではなく、制御権を保持することだと考えましょう。制御権を持つというのは、何を作るかを決定し、どのような技術を用い作るかを決定し、開発の全体を指揮すること。つまりIT活用を手の内化することです。この中に含まれる設計作業は、実装と表裏一体なので、実装に全くかかわらず設計だけを自社で行うのは不可能です。現状、SlerやITベンダーに依存している企業は、この問題を正さない限り、似たような過ちを繰り返してしまいます。採用技術の妥当性も判断できず、請求されるコストの相場観も分からない。結果、ベンダーの言いなりに近い状態になってしまっている企業は多いはずです。
　自社で巻き取れないということは、すなわち作ったその日から負債を抱えているようなものなのです。

■ソフトウェア開発に必要な職種
・プロダクトマネジャー
　ユーザーの求めるプロダクトの理想を追求する役割で、「ミニCEO」とも呼ばれます。ソフトウェアの仕様や設計を決めてエンジニアやデザイナーに開発方針を伝え、プロダクト開発を主導するだけでなく、継続的な成長にも責任を負います。
・ソフトウェアエンジニア
　プロダクトの仕様や方向性を理解し、プログラミングやその他のITテクノロジーを駆使して形にする役割です。ソフトウェアの実装フェーズで主役となるのがこのポジションです。組織によっては、この職種の中で「フロントエンドエンジニア」「バックエンドエンジニア」「インフラエンジニア」「モバイルエンジニア」などと役割を細分化しているところもあります。
・エンジニアリングマネジャー
　実装を担当するソフトウェアエンジニアを取りまとめる役割です。個人の成長を見極めながら適切な仕事を割り振るだけでなく、チームとしての総合力を最大化することに責任を負います。
・デザイナー
　ソフトウェアが提供したいユーザー体験を踏まえて、利用を促進させるユーザーインターフェイスをエンジニアと協力してデザインに落とし込む役割を担います。
・ＱＡ(Quality Assureance/品質管理)エンジニア
　ソフトウェアが想定通りの機能を果たしているか、想定外の不具合による障害を起こす危険がないかをさまざまなテストを通じて検証する役割です。

　整理すると、CTOの役割は次のようになり、VPoEを配置する場合には、このうち主に3つ目を担当することになります。
1.自社の技術ディレクション(どのような技術を採用するべきか。例えば、プログラミング言語やフレームワーク、インフラなど)の決定。
2.経営に対して技術面から関与。開発への投資判断やパートナー選定、事業に対して技術面からの判断など。
3.エンジニアリング組織のトップとしての組織マネジメント。


■ジョブ・ディスクリプションの構成要素
募集の背景：会社や事業の状況についての説明や、今回の募集の背景について、必要ならば説明を入れる。
職務内容：募集ポジションに期待される職務について説明。次の「責任」と被る内容であるため、どちらか１つの項目として説明されることも多い。もし別に項目を用意するならば、こちらの職務内容ではよりハイレベルな、そのポジションに期待される内容でも、部署全体で取り組んでいるような内容について記載する。
責任：募集ポジションの責任範囲。具体的にどのような役割を担うのか、どんな職能を全うすることが期待されているのかを記載する。
要件：「要件」で定義された責任を全うするために必要と思われる要件を記載する。必須とそれ以外を、Must/Want/Nice to haveのように分けて記載することも多い。


　よく、職能組織と事業主体組織はどちらがいいのか?という議論が起きますが、ケースバイケースとしか言えません。エンジニアリング組織を立ち上げたばかりで人数も少ない場合は、職能組織のほうが機能しやすいでしょう。仕事の進め方を暗中模索しているような状態では、エンジニアリングマネジャーと一緒に考えていくことが必要になるからです。一方で、複数プロダクトを開発・運営している企業では、プロダクトごとに開発方針や開発サイクルが違うため、職能組織で決めたルールが足かせになってしまうこともあり得ます。その場合は事業主体組織にして、それぞれの事業部で方針を定めて開発したほうがスムーズに進みます。
　ただし、この場合でも、全社的な技術方針は定めておく必要があります。そうでないと、プロダクトごとに異なる技術スキルが必要になり、エンジニアの社内異動さえ難しくなります。プロダクト間の連携を考える時にも問題になります。また、職能組織ではエンジニアリングマネジャーが上司となってメンバーの成長を考えた指導や技術的な評価が行う一方、事業主体組織では異なる専門領域を持つマネジャーが上司になる場合があります。メンバーから見れば、技術的な指導や評価が受けにくい状態になってしまうので、別の手段を講じる必要があります。
　これに関連して、職能組織はいわゆるマトリックス型組織と呼ぶこともできます。マトリックス型組織とは、職能と事業の両軸で構成した組織です。図4−12を参照しながら説明すると、「研究開発」や「製品開発」など職能軸に構成される組織がある一方、A～Cの事業軸で分かれた組織もあります。メンバーが複数の事業にかかわる場合は事業軸が2つ以上になることもあり、それに伴って2人以上の上司を持つ形になります。会社の方針にもよりますが、筆者はどちらかをメインの上司とし、もう片方をサブの上司とすることを勧めています。特にエンジニアの場合には、職能にあたるソフトウェア技術についてのフィードバックを与えられることから、職能組織の上司をメインとするのがいいでしょう。
　続いて紹介するのは、次頁の図4-13にある某ゲーム開発会社のマトリックス型組織です。ゲーム会社なので、事業軸はゲームタイトルになります。各ゲームタイトルには専属のプロデューサーとディレクターが所属していますが、数百人いるエンジニアは職能組織からアサインされる形となります。さらにこの会社はエンジニアの職能組織も細分化していて、サーバーサイドエンジニア、フロントエンドエンジニア、各OSごとのモバイルアプリエンジニア、インフラエンジニアに分かれています。各職能組織にはエンジニアリングマネジャーとそれを補佐するサブマネジャーが少数いるそうです。エンジニアリングマネジャーは組織運営に集中していますが、サブマネジャーは各ゲームタイトルの制作に自らもかかわります。技術的難易度が高開発であったり、開発で問題が生じていたり(いわゆる炎上案件)した場合に助っ人として参加するのです。
　大事なのは事業(プロダクト)価値の最大化と組織の成長のバランスです。組織は一度作ったら終わりではありません。自社の組織風土や事業の状況などに応じて、随時形を変える必要があります。一義的には事業価値を最大化するのを優先するべきですが、中長期にわたって事業を成長させるためには組織の成長も欠かせません。この2つのバランスを考慮した上で、そのステージに応じた組織デザインをしていくべきでしょう。

■予想外の出来事や偶然の出来事がキャリアに影響を与える必要な特性
・好奇心
・持続性
・柔軟性
・楽観性
・冒険心

■WEBサービス開発に必要なスキル
・フロントエンド開発
・バックエンド開発
・データベース
・インフラ
・ネットワーク
・セキュリティ
・iOS
・Android
・機械学習

①キックオフミーティング
ビジョン、Core Why Whatを伝える
コンセプトの理解　インセプションデッキ
チームとのテクニック
ドキュメンテーション
プレゼンテーション
コーチング
ファシリテーション

a.ビジネス
歴史、地理、政治法律、経済、民族文化、哲学思想
統計
知的財産
b.技術
Q...続きを読むA 品質を担保するために必要なすべての活動
狩野モデル
API,RPC
c.ux
ユーザーのためのデザインか？
デザインの意図がユーザーの期待通りか？
デザインがもつメッセージは適切か？
ドンノーマンのデザイン6原則
・統一感の4つの観点
美的統一感、機能性、内部性、外部性
ui ビジュアルの階層化
マーケティング
・AIDMA,AISAS
・アーンドメディア、オウンドメディア、ペイドメディア、オーガニックユーザー

JSって何？っていうど初心者なので、すごくわかりやすかった。

コードがそれぞれ何をしてくれているかを、ふりがなを読むことでわかる気になって、学習への意欲が増す！！
他の本だと、例文がむずかしくて挫折したけど、この本の例は、身近に感じられて、どんなことをやりたいのかをイメージしながら書くことができた...続きを読む。

勉強初めにはこの本を読んで正解だった。ざっくりとわかった気がする！ってハードルが下がるので、勉強の意欲が湧く。

「プロダクトマネージャーは知的総合格闘家」という言葉が刺さる。前職でPMをやっていた際に学んだことがおさらいでき、基本が網羅されている良著だと思う。

プロダクトマネージャーに求められる「計画力」について。ガントチャート作成や、リリースまでのマイルストーンを組み立てることは役割ではない。プロダクトマ...続きを読むネージャーに必要なのは、中長期的なロードマップ作成や指標の立案など、プロダクトを着実に成功へ向かわせる力である。

人々は、利用に価値を置くようになった。
ハードのスペックではなく、
ハードを使って何をするか。
ハードを使って、ユーザーがしたいことを
支えるのが、ソフトウェアであり、
ソフトウェアによって、顧客体験が向上する。
顧客体験により、感動につなげる。
ただし、ソフトがすべてではなく、
人の力を最大限つか...続きを読むったり、ハードでまかなう
べきこともある。

ユーザーを理解して、顧客体験を高め
続けるには、変わり続ける必要がある。
そのためには、アジャイル型で試しつつ進み、
開発と運用を同時に行うDevOpeの考え方が必要になる。

顧客体験を最大化する武器たるソフト領域を
外だしする手はない。
自分たちにノウハウがたまる、
すぐに試せる、と言ったメリットがある。

プロダクト開発に当たっては、
プレスリリースからはじめてみる。

と、大幅に意訳。

日本のIT業界で、依然としてウォーターフォールモデルが採用される事が多い。採用されるに至った背景やその問題点を分かりやすく説明されている。
開発方式を変化させるという短絡的で実現困難な課題提起ではなく、組織の在り方を変える、そしてそのために経営者だけでなく現場も変わる必要があると言う点が深く心に残っ...続きを読むた。
筆者の経験に基づく内容が多く、説得力があり熱い想いが伝わってくる。
何度も読み返したくなる名著。

　我々が属している業界において「名著」と語り継がれている本を読んだ。恐れ多いが、多くの方が好評する、という意味もよく分かった。さらに自分にとっては、（自分が勤務している）会社で技術顧問をしておられる及川さんの書籍を改めて拝読し、なんだか得したというか、いまこの本読んでんのかよ、と叱られそうな気もした...続きを読むり、複雑な気持ちでした。とにかくDXやソフトウェア・ファーストを学ぶ上では必読書、と言われている背景がよくわかりました。　おわりに（P354）にございますが「デジタル・トランスフォーメーションを解説した類書とは一味違う、泥臭いけれど実践的な内容を網羅している」本だと心から思います。

　及川さんとの輪読会に参加したり、技術顧問としていろいろとアドバイスいただける環境にある会社に勤めていることもあり、それこそ及川さんからこちらの本ができる際の何度も書き直したというブログの記事を案内いただき、この本を取ることになりました。ブログの記事にもありましたが、「ターゲット読者のペルソナを作成することで読者視点を常に意識しました」ということで、及川さんとのセッションで直接語りかけられているような、直接講義を受けているような、そんな感じを受けました。熱量を増してくると早口になって、ものすごいスピードでこちらのパッションも高めていかれる、及川さんが本に乗り移っているかのように思いました。こんなによい書籍を手にすることが遅くなり申し訳ございません。

　というぐらい、やはり、デジタル・トランスフォーメーション、というか、この変化の激しい世の中の環境を受けて事業変革を考えていかねばならない立場の人々にとっては、まさにバイブルとなるような本だ、というところは、実際に読んでみて納得感というか畏怖の念というか、腹落ち感・手触り感、満載でした。この本で網羅性を確認し、そこから次のより踏み込んだ本へ発展していくのがよいんだな、と改めて思います。　及川さん、改めましてありがとうございます。稚拙な表現でしかレビュー書けなくてすみません。オオハシらしい、ストレートな感想となります。


　さて、改めまして引用です。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
P36　ソフトウェアの力だけでは良いプロダクトは生まれませんが、凄まじい破壊力を持つソフトウェアの特徴を理解し、プロダクトや事業開発のすべてを変えていくことが、これからの企業力を左右します。
　また、企業がソフトウェア・ファーストを実践するには、ソフトウェア技術を理解し、事業に活用できる人材が必要です。このような人材を育て、活かせる組織が必要です。さらには、失敗することを前提に、作っては壊すことを良しとする文化も大切です。
　そして、ソフトウェア・ファーストで最も大事なことは、変化しないものを理解することです。ソフトウェア技術は日々進化します。ソフトウェアを活用したビジネスモデルも変化し続けます。変わらないもの―それはビジョンやミッションであり、それに関連する社会課題や価値観です。目指す世界観に対して、ソフトウェアという変化し続ける手段を用いる人間に必要なのは、成し遂げようとする執念であり、成し遂げるために考えること、考え続けることです。

P63　では、将来のSIerはどんな存在になるでしょうか？筆者は2018年に、ギットハブでテクノロジー担当の副社長を担当するジェイソン・ワーナー氏にこの質問をぶつけてみたことがあります。ワーナー氏は「SIerはより専門に特化していくことになるだろう」と述べていました。専門とは、業界特有のソリューションであったり、特定の技術領域を指しています。


P84　データ活用に感じる2つの違和感
　近年「Data is Oil」（データは石油）という考え方がさまざまな産業に普及していますが、一つ目の懸念はデータへの期待が先行し過ぎている点です。例えばAIによるユーザーの思考・行動パターン予測や画像認識などの精度を高めるためには学習用の膨大なデータが必要です。しかし、このデータは何でもいいというわけではありません。データの収集や前処理、蓄積にも莫大なコストがかかることを考えると、収集するデータの種類や用途を考えた上でデータを集める必要があります。そこまでやらなければ、“原油”は石油にはなりません。
　（中略）
　それに、ユーザーデータを取得・利用することに対する社会全体の受容度が低い状態で過度なデータ活用を進めると、ユーザーに気持ち悪がられてしまいます。
　（中略）
　本来は、こうした懸念を払拭するために、ユーザーのプライバシーをどう考えてデータを取得するか、取得したデータをどう活用するのが理想的なのかを考える人材が今以上に必要なはずです。


P177
　ソフトウェア・ファーストを実践し、DXを推進する際は、企画の段階から「自分たちが提供するプロダクトや事業が何を成し遂げたなら、ユーザーの課題を解決していると言えるのか」を考え抜くことが大切です。その上で、ユーザーに価値提供をしている状態をどうやって計測するか、を考えましょう。つまりKPI（主要業績評価指標）とそれを構成するKPIツリーを考え、それぞれのKPIを計測できるような基盤を整えておく必要があります。

P294
　ちなみに、このコネクティング・ザ・ドッツの概念は、スタンフォード大学のジョン・D・クランボルツ教授が計画的偶発性理論として提唱している内容とほぼ同じです。この理論は「慎重に立てた計画以上に、予想外の出来事や偶然の出来事がキャリアに影響を与える」という考えに基づくものです。この偶発性を起こすには、その人に次のような特性が必要であると教授は論じています。
　・好奇心
　・持続性
　・柔軟性
　・楽観性
　・冒険心
（中略）
　偶然性はともすれば流されるままに生きているだけのように見えるかもしれませんが、クランボルツ教授の理論にもあるように自らの興味や好奇心が必要であり、解釈の仕方次第では自分の意思が招いた必然とも言えます。


P344　
　グーグルは調べれば調べるほどよく分からない会社でした。それだけに好奇心が刺激され、入社するためにかなりの努力をしました。自分なりにグーグルのプロダクトをすべて調べ、SWOT分析をし、自分だったらこんなプロダクトを作ると仮説を立て、面接に臨みました。
　（中略）
　グーグルは今でこそ、検索だけでなく、クラウド含め様々な事業を持っています。IT業界のみならず、社会に影響を与える存在にもなりました。しかし筆者が入社した頃はまだ、ここまでの存在になるかどうかは未知数でした。ここでも筆者は自らの審美眼を信じ、リスクを取って、安定を捨て、新しい挑戦をしました。

P348
　このように自分のスキルを棚卸し、市場における差別化を考える中、外資系大企業経験の長い筆者があえて選択することに意味があるのは、「日本企業」であり「スタートアップ」であると考えました。
　（中略）
　グーグルのやり方はグーグルだからこそ活用できるものであり、日本のスタートアップは、グーグルを参考にしながらも、自ら作り上げていく必要があります。その作業をご一緒させていただきながら、筆者は引き出しを増やしていき、この引き出しに蓄えたノウハウを活用することで、さらにまた新たなノウハウが生まれるという好循環になっています。

P352
　この本をお読みになった皆さんには、ぜひとも変化を追い求めるようになっていただきたいと考えています。変わらずにいることに心地悪さを感じるようになり、常に変化を求める。そうすれば、きっと組織も社会も変わっていくことでしょう。
　ここで言う変化とは、すなわち進化です。人に喜んでもらえるものを提供する喜びを持てれば、社会課題を解決して救われる人を見られれば、きっと多くのことが変わっていきます。小さな変化がより大きな変化を生んでいくことでしょう。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

以上
　

「ソフトウェアプロダクトラインエンジニアリング」の「製品管理」の実践方法を理解するために読む本。

ケーススタディもあり理解しやすい。
ビジネスプランナーから、職場の便利ツール作成者まで幅広く活用できる知識。

分厚いが、明瞭でさらっと読める。

以前（かなり前）、著者の出演するテレビ番組を見て、
この方おもしろい人だな～と思っていたのですが、
ようやく著作を読むことができました。

で、実際に読んでみましたが、想像以上のクオリティの高さに驚きました。
とても勉強になります。
特に、自分のような非エンジニアで、今後DXなどの影響により、
IT...続きを読む領域も少しずつ勉強していかないといけないという問題意識を持っているビジネス系の人には、
まさにピッタリの書籍ではないかと思います。
IT用語も出てきますが、最低限に抑えられていますし、
脚注に解説が載っているので、本の中で大体解決・完結してしまいます。

最後の章のエンジニアのキャリアパスについては、
エンジニアの人（と著者のキャリアに興味を持った人）だけ読めばよいかと思いますが、
３章（できれば４章）まで読むとソフトウエア開発について、
網羅的に理解ができ、ビジネスサイドの考え（新規事業開発）と
接続することができるのではないかと思います。

これは絶対に買い！の一冊です。

OKR = Objective + Key Results
= １つの目標　＋　３つの主な結果
P1 やらなければならないこと、P2 やるべきこと
を、マトリックスの４つの箱に書いていく、シンプルな
目標管理方法です。

・KPI とは、ちがって、目標そのものを管理していることでシンプ...続きを読むル、項目数をしぼることで分かりやすく、継続もしやすい。
・私感ですが、PDCA でプロセスを重視しているのにたいして、目標に、焦点を当てている点が大きく異なっているとおもいました。
・時間がかからないですが、深堀りはむずかしく、別の機会を必要とするので、サマりとしての道具かと。

プロダクトマネジメントマネジメントとは何か、なぜ必要なのかなどが網羅的に示されている。
駆け出しのCSの人間が読んでもすごくわかりやすい。
経験を積んだら、また読み返したい本。