及川卓也のレビュー一覧

OKR（オーケーアール） シリコンバレー式で大胆な目標を達成する方法

クリスティーナ・ウォドキー / 二木夢子 / 及川卓也

OKRについて知らないといけなかったので読んだ。

社会人になって一番実感したのは自分の時間があまりにも有限ということ。
ただダラダラ生きるだけなら誰でもできるけど、その上で何かがしたい場合は、何かを諦めなければならないということを実感した。

OKRはシンプルな目標でいろんな立場の人を同じ方向に向けて動かすための手法。
手法として金曜日のみんなで讃えあう会はめっちゃ楽しそうだった。

前半物語で後半解説って頭に入ってきやすくて良いね。

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

及川卓也 / 小城久美子 / 曽根原春樹

プロマネのあるべき姿の専門書はあまりないのでとても勉強になりました。かなり網羅的。オーディオブックで聴いたので本も購入して手元に置いておきたいです。

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

及川卓也 / 小城久美子 / 曽根原春樹

タイトルの通り、プロダクトマネジメントについて網羅的に学べる一冊。とてもボリュームがあるため、手元に置いておいて辞書のように関連トピックについて調査するのに活用しやすいのではないだろうか。

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

及川卓也

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

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

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

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

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

プロダクトマネージャーになりたい人のための本 エンジニアからプロジェクトマネージャー・事業企画・経営コンサルタント・デザイナー・現役PMまで

及川卓也 / 松永拓也 / 山本航 / 武田直人

なんもわからん未経験の自分が読むには端的でわかりやすかった。もっともここからの努力の積み重ねと戦略設定が大事なので、手元に置いて何度か読み返しつつ進めていきたい。

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

及川卓也 / 小城久美子 / 曽根原春樹

プロダクトマネジャーの仕事の概観を知るのに良い良書。
また、プロダクトマネジャーが自分の仕事を網羅的に振り返る/対応事項を探す指針としても良さそうな本。
あくまで概要を記載した本なので、各項目の詳細については別の書籍を参照しつつ、該当領域の理解を深めるのが良さそう。
目次として横に置いておきたい一冊。

OKR（オーケーアール） シリコンバレー式で大胆な目標を達成する方法

クリスティーナ・ウォドキー / 二木夢子 / 及川卓也

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

ソフトウェア・ファースト

及川卓也

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

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

及川卓也 / 小城久美子 / 曽根原春樹

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

スラスラ読める JavaScriptふりがなプログラミング

及川卓也 / リブロワークス

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

EMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダーシップ

マーティ・ケーガン / クリス・ジョーンズ / 及川卓也 / 二木夢子

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

OKR（オーケーアール） シリコンバレー式で大胆な目標を達成する方法

クリスティーナ・ウォドキー / 二木夢子 / 及川卓也

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

OKR（オーケーアール） シリコンバレー式で大胆な目標を達成する方法

クリスティーナ・ウォドキー / 二木夢子 / 及川卓也

四半期で達成できるかできないかくらいの
○O:定性目標ひとつ
○KR:定量目標みっつ
欲張ってたくさん立てない
毎週確認
KRの自信度は半分くらいのものであるか。上がったり下がったりしていないか。その要因はなにか。
立てるとき↓
他部門との整合
測定可能か（過去は参考になる）
タスクではなく結果を見る
ゴールが達成できる方向性にする
ポジティブにする
状況報告メール↓
OKRと自信度
今週の重要項目の達成
来週の重要項目
メモ

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

及川卓也 / 小城久美子 / 曽根原春樹

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

書ききれないほど多数の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
・機械学習

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

及川卓也 / 小城久美子 / 曽根原春樹

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

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

スラスラ読める JavaScriptふりがなプログラミング

及川卓也 / リブロワークス

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

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

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

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

及川卓也 / 小城久美子 / 曽根原春樹

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

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

ソフトウェア・ファースト

及川卓也

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

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

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

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

と、大幅に意訳。

ソフトウェア・ファースト

及川卓也

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