プロダクトマネージャーの仕事/スキルとエンジニアとのスキルギャプ

デブサミ2017でパネルディスカッション形式で登壇させていただいた。

event.shoeisha.jp

エンジニアからプロダクトマネージャーへのキャリアがテーマで、私自身どうやってなったのか振り返るキッカケになった。また別の機会でもエンジニアのキャリアについて考えることが多く、改めてエンジニアからプロダクトマネージャーへのキャリアについてまとめてみた。

 

プロダクトマネージャーの仕事と必要なスキル

まず、プロダクトマネージャーの仕事とスキルについて言語化を試みた。プロダクトマネージャーの教科書であるINSPIREDにもあるように、プロダクトマネージャーの任務は2つ、「製品の市場性を評価する」ことと「製品を定義する」こと。少しわかりにくいので、下記の3つのプロセスを定義した。

• 市場の分析
• STP（セグメンテーション/ターゲティング/ポジショニング・コンセプト）
• 製品要求の定義

Webの製品開発には、初めて市場に導入する際のような大きな粒度の仮説検証もあれば、成長フェーズの少し小さな粒度の仮説検証もある。どんな粒度でも結局は市場を分析し、その中で同じような悩みや問題を抱えるユーザーセグメントに切り、どのセグメントを優先して扱うかをターゲティングし、優先セグメントの本質的な課題設定とその解決策を価値として提案するプロセスを経る。プロダクトマネージャーにとってそのアウトプットが「製品要求」である。

また、プロダクトマネージャーのスキルについても言語化を試みた。上記の仕事をこなす為に必要なスキルとして定義している。この辺りは漏れもあると思うし、製品ドメイン特有の知識も必要だとは思う。ぜひ指摘してほしい。

• 市場分析 → STP：マーケティング力、分析力、課題解決力
• 製品要求の定義 → 具体化：UX/UI基礎力、開発運用ノウハウ
• 施策評価、業績評価：財務会計基礎知識と評価力
• すべてのプロセルに必要スキル：巻き込み力

このように定義するとプロダクトマネージャーはマーケターであることがわかる。プロモーションを担当しているマーケターは市場分析>STPを経て、広告広報などのコミュニケーション戦略がアウトプットになる。要はアウトプットが製品なのかコミュニケーションなのかの違いで、どちらも顧客の課題を正しく掴み、解決策として新しい価値提案を行うという意味ではマーケターである。

エンジニアとのスキルギャップ

次にやっと本題であるエンジニアからプロダクトマネージャー へのキャリアについて考えていきたい。上記のプロダクトマネージャースキルの中でエンジニアなら持っているスキルをリストアップしてみよう。

• 開発運用ノウハウ
• 分析力のなかの分析ツールやSQLのスキル

たったこれだけ。。。初めからわかっていたことではあるが、エンジニアとプロダクトマネージャーは全く役割や求められるスキルが違う。要するにジョブチェンジなのだ。0からキャリアをスタートさせるぐらいの覚悟がないとできない。エンジニアの延長線上にあるキャリアではない。ただ、開発運用ノウハウを知っていて同じ言葉でエンジニアと話せること、SQLを使えるということは、他の職種から見るとかなりハードルが高いので、それだけでもかなりのアドバンテージと捉えるべきか。

上記からエンジニアとプロダクトマネージャーのスキルセットにはかなりのギャップがあることがわかった。全員に勧められはしないが、弊社のエンジニアチームを見てもプロダクトマネージャーに向いてそうなエンジニアもいる。次はそこを言語化してみよう。

 

 ソリューション志向のエンジニアがPMに向いてる

エンジニアチームの中にソリューション志向タイプのエンジニアは必ずいるようにいるように思う。ソリューション志向のエンジニアとはどんなタイプだろうか。言語化してみる。

• 蓄積された技術力が一定ある
• 技術は課題解決のための手段という強い認識がある
• そもそも課題解決能力が高い
• 本質的な価値を追求するあまり、自分で分析やヒアリングをしてしまうような能動性をもっている
• ステークホルダーへの説明責任を果たしながら、チームメンバーへのも説明し、周りをうまく巻き込んでいけるリーダーシップをもっている

技術力もあり、課題解決能力が高く、コミュニケーションハブにもなれるこういうタイプのエンジニアはどこの会社でも重宝される。要はソリューション志向のエンジニアは、プロダクトマネージャーに必要なスキルである、課題解決能力、巻き込み力の素養が高いといえる。

さらにレアケースだが、ビジネス感度が高かったり、デザイン感度が高いソリューション志向エンジニアも存在する。ビジネス感度が高いタイプは全体のビジネス構造を理解する力が高く、担当事業のKPIモデルや収益構造を感じ取る力が長けている。普段から競合他社の財務3表をよみ競合の収益構造なども理解していたりしているようなエンジニアだ。デザイン感度が高いタイプは自分でデザインの基礎を勉強していたり、モックレベルであれば自分で作ってしまうエンジニアだ。そういうエンジニアは財務会計知識や、UX/UI基礎知識も持っているのでさらにプロダクトマネージャーの素養が高い。

 

まとめ

• エンジニアからプロダクトマネージャーで求められるスキルにはかなり大きなギャップがある
• ソリューション志向のエンジニアはプロダクトマネージャーの素養がある
• ソリューション志向のエンジニアの中で、さらにビジネス感度やデザイン感度が高いレアエンジニアは、さらに高い素養がある

（番外編）他職種からプロダクトマネージャーへのキャリアを考察

営業系職種やカスタマーサポートからプロダクトマネージャーになるケースも多いと聞くが、顧客インサイトを経験上多く持っている職種だからだろう。その場合、顧客理解度の高さがアドバンテージになる。デザイナーはもともとUI/UXのノウハウを持っているのでそれがかなりのアドバンテージになる。

障壁になりそうなのは、やはり開発プロセスと技術的な理解度や分析ツールとしてのSQLを使ったりするところだろうか。特にエンジニアとうまく会話ができないということをよく聞いたりする。このようなケースはPMチームの分析官として分析業務をやりながら、トレーニングとして簡単なプロダクトのサンプルを作らせたり、技術知識のインプットを研修プランに落とし込めればうまくランディングできそうだ。

 

スライド

speakerdeck.com

参考文献

プロダクトマネージャーを目指す人にはぜひ読んでほしい一冊。大切なことがたくさん書いてあります。

Inspired: 顧客の心を捉える製品の創り方

Webクラウド時代のプロダクトライフサイクルマネジメント

2016/12/13に株式会社ビズリーチのD3勉強会で発表した内容を公開。

ビジネスサイクル、テクノロジーサイクルがどんどん早くなる中で、Webクラウド時代のプロダクトライフサイクル全体のマネジメントの難易度はどんどん高くなっている。プロダクトの各ライフサイクルの中で適切な投資判断が行われなければプロダクトの成長は止まり、競争に負けてしまうだろう。勉強会を機にどのように考えるべきかまとめてみた。

Webクラウド時代のプロダクトライフサイクルマネジメント

• プロダクトライフサイクルについて
• Webクラウド時代のプロダクト開発アプローチ
• 成長フェーズ別、プロダクト開発体制テンプレート

speakerdeck.com

＜サービス企画者向け＞思考の枠の外し方

人間、自分の思考の癖やバイアスには気づきにくいもの。

売上予算、既存の組織、ステークホルダーへの説明コストなどの外的な制約（しがらみ）や、今までの経験からくる内的な思考のバイアスなど、様々な要因が複雑に絡み合い、思考が制約、歪められる。

企画者としては、バイアスや気付いていない制約に気づくためにチェックツールを持っておくべきだろう。

最近の企画でハッと気づいたことが多かったので、そこでの学びをまとめてみた。

◯◯◯って、一言でいうとなに？

◯◯◯のところに、自分が担当しているサービス名、プロダクト名を入れると、サービスの原点を確認できる。手元の課題に注力し近視眼的になっている時、複雑な問題を同時に扱っている時、サービスの本質からずれた企画を進めたりしてしまうことはよくある。そもそも俺たちって何者なんだっけ？何を目指していたんだろう？サービスの原点を改めて確認しなければいけない時に有効な質問だ。

プレスリリースから考える

企画担当者は当然、マーケティングフレームである3C, STP, 4Pなどの整合性は考えている。しかし、自社都合の制約など加味しすぎていて複雑でパッとしない、言っていることはわかるけどなんかボンヤリしているなど、ソリッドにまとめきれないことが多い。この方法、実はあのAmazonでもやっている手法で、"Working Backward"というデザイン手法。プレスリリースから考えれば、どうしてもターゲットに刺さるメッセージから考える必要があり、必然的にターゲットセグメント内のポジションや、訴求メッセージ、サービスビジョンが明確になる。詳しくは下記の参考リンクを。

Amazon流の開発術では、まずプレスリリースを作る | fladdict

news.mynavi.jp

もし、ど新規でサービスを作るとしたらどうする？

サービスのリニューアル時など、売上予算や組織がすでにあるなかで大規模に変えなければならない場合、投資家や現在の組織などのステークホルダーに対してかなり説明コストを払わなければならない。こういうケースにおいては既存の制約事項がある前提で企画を進めてしまっていることがよくある。この質問はそういう制約事項を抜きにして、理想のサービスにするためにどうするべきなのか？考えるきっかけを与えてくれる。

アップルの何が凄いのか？（前編）

最近読んだジョナサン・アイブの伝記的な本をきっかけに、アップルがどのようにして世界を変えるほどのイノベーションを起こしてきたのかとても興味を持ったので、いろいろアップル関連の本を読み始めた。

1997年にスティーブ・ジョブズはアップルの暫定CEOに復帰。倒産寸前だったアップルを立て直し、iMacを発表、そこからiPod, iTunes, iPhone, iPadと続く快進撃は、イノベーティブなプロダクト開発をしたいと思っているプロダクトマネージャーやエンジニア、デザイナーの方々にとって、とても参考になるモデルケースであることは間違いない。

なんだか凄すぎてよくわからない会社という印象だったが、何が凄いのかをまとめることで得られる学びもあるだろう。

今回まとめる内容は1997年以降のアップルを対象にしている。また、読んだ本や、参考にしたページは一番下にリスト化した。

原点回帰

ジョブズ復帰前、アップルは迷走し、製品ラインナップもめちゃくちゃで、赤字を垂れ流していた状態だった。ジョナサン・アイブはそんなアップルに見切りをつけようとしていたが、ジョブズが復帰して状況は一変する。

ジョブズは復帰後、一番はじめに行った幹部ミーティングでみんなにこう聞いたようだ。

「アップルのどこが悪いか教えてくれないか？」

誰も返答しないでいると、ジョブズは大声で怒鳴り始めた。

「プロダクトだ！プロダクトが最悪じゃないか！！！セクシーさがどこにもない！！」

（引用元：ジョナサン・アイブ　偉大な製品を生み出すアップルの天才デザイナー ）

ジョブズは復帰後の一番はじめに行ったミーティングで、幹部に対し、アップルの目標は金儲けではなく、偉大な製品を作ることだと宣言した。ジョナサンはこれを聞いて踏みとどまったようだ。

会社の再建を考える時、普通だったらリストラからやりそうだが、それだと企業の魅力がさらに低下して負のスパイラルに陥ることをジョブズは知っていたのだろう。

その企業が何をするために存在するのか、会社の存在理由（ミッション）が一番大切でその企業幹になることを忘れてはいけない。迷走している時はそこがぶれていることが多いのではないか？

徹底的なリストラ

ジョブズはリストラも尋常ではないぐらい徹底的に行った。ジョブズの前CEOアメリオ時代からリストラは始まり、アメリオは350程度あるプロジェクトを50まで減らしたが、ジョブズは就任した後はそれをさらに10まで減らした。また、すぐに役立つテクノロジー以外はことごとく抹殺された。人員に関しては、プロダクトラインナップ整理されるタイミングで、全社員1/3以上の7,000人弱が段階的にレイオフされている。

 

ここで大事なのは、経営者自身がどのテクノロジーに投資するべきか判断している点だ。ジョブズ自身が、直近利益を産まないテクノロジーやプロダクトラインナップは全てこのタイミングで抹殺した。日本にこの判断ができる経営者がどの程度いるのだろうか？今の家電業界やインターネット界隈でこういう判断ができる経営者は少ないと思う。

 

戦略的業務提携

ジョブズは復帰した年にマイクロソフトと特許のクロスライセンス及び業務提携を結んだ。アップルは標準WebブラウザとしてInternet Explorerをバンドルことを引き換えに、マイクロソフトにはMicrosoft OfficeをMacintosh用に最適化させ、Macintosh版とWindows版を同時リリースすることになった。さらにマイクロソフトは1億5000万ドル以上と言われる出資（額は非公開、議決権のない株式を発行）を行っている。

 

この業務提携により、当面の運転資金を捻出し倒産の危機を脱した。また、ビジネス界隈でスタンダードになっていたMicrosoft Office製品をMacでも使えるようになったことが、後々Mac自体のシェア拡大に大きく寄与していると思う。

 

シンプルな製品戦略

上記にも記したが、ジョブズ復帰前のアップルの製品ラインナップは全体戦略がなく、40以上の製品群があり、混沌としていた。コンピューターは4つのラインがあり、それぞれのラインに10以上の異なるモデルがあった。また、アップルはコンピューター以外にもプリンター、スキャナ、モニーター、ニュートンの携帯デバイスまで、ありとあらゆる製品を手当たり次第なんでも市場に投入していた。

 

この状況を見かねてジョブズは復帰後にシンプル且つ明快な製品戦略を打ち出している。

ジョブズは先ほど書いたものを消し、簡単な十字を描いた。上段にコンシューマー、プロフェッショナルと書き入れ、下段にポータブル、デスクトップと書き入れる。

これがアップルの新製品戦略だ、と言った。売るマシンは4種類だけ。ノートブックとデスクトップ、それぞれプロ用と家庭用だ。

（引用元：ジョナサン・アイブ　偉大な製品を生み出すアップルの天才デザイナー ）

 

（僕がアップルで学んだこと-環境を整えれば人が変わる、組織が変わる、のP293を参考に作成 ）

 

製品戦略は非常にわかりやすく、どんなミッションステートメントよりも社員の力を一つの方向にフォーカスさせることに役に立ったようだ。その結果、iMacの発売からわずか１年足らずで残り3製品をもたてづつけに発表していく。

 

いい経営者の条件の一つに、市場と社員に対して「明快でシンプルな方針」を示せることがあるだろう。トップの方針が曖昧だと、社員はどのような方向に進めばいいかわからないし、市場もこの会社の商品を買っていいのかわかりにくい。

 

責任感

ジョブズ復帰前のアップルは失敗してもなんの責任も問われない、悪い意味で自由な会社だったそうだ。責任を問われないので、ちょっと面白いものであればなんでも製品化された。当然、最後までフォローもしないので失敗する。

 

ジョブズは復帰後に、個々の役割と責任を明確にして、結果が出なければ責任を問うということを徹底した。その結果、仕事に緊張感が生まれ、仕事へ集中するようになり、常に前年度を上回る成長をするように努力する組織になったそうだ。

 

"僕がアップルから学んだこと"の中に書いてある面白いエピソードで、著者の方が管理職に抜擢されたタイミングで「お前はこのグループの独裁者になるんだぞ」と、上司から言われたそうだ。要は、自分の部署の独裁者になる代わりに、自分の部門の失敗には全責任を取らされる立場になるというとこ。日本でこういう感覚でやっている管理職の方は少ないだろう。アップルほどの企業になれば常に世界中の優秀な候補者が応募してくるので、代わりなど世界中にいくらでもいるのだろう。企業側としては、責任を追求できる環境を作るためにも優秀な候補者が入りたいと思うような採用ブランディングを徹底して作っていくことが大切だ。

 

 

長くなってしまったので、 続きは後編で書こうと思う。 後編はデザイン思考や、開発プロセスなど、より現場に近い部分の話になりそうだ。

 

参考図書

ジョナサン・アイブ

僕がアップルで学んだこと 環境を整えれば人が変わる、組織が変わる (アスキー新書)

スティーブ・ジョブズ 驚異のプレゼン

スティーブ・ジョブズ 驚異のイノベーション

アップル 驚異のエクスペリエンス

アップルのデザイン

インサイド・アップル

 

 

あなたのプロダクトチームは機能してますか？

プロダクトのチームでは、プロダクトマネージャー、エンジニア、デザイナー、マーケッター、営業、カスタマーサポートなどなど、本当に様々な役割の人間が関わりながらプロダクト開発を行っている。

これらの人達が１つのチームになり、有機的に連携しながらパフォーマンスを出すのが理想的だが、その環境を作り出すのは本当に難しい。

 

優秀な人達が揃っていても陥ってしまう罠みたいなものがあるので、過去の成功や失敗を振り返って、プロダクトチームをマネージするに辺り大切にしていることをチェックリストにしてみた。

  

1. 企画担当、エンジニア、デザイナー、関係部署のメンバーが毎日雑談しているか？

良好なチームのベースには信頼と結束が必要だが、それらが揃っているチームは日常的なコミュニケーション量も自然と増える。結構プライペートにも突っ込んだ話もしたりするんじゃないだろうか？挨拶から始まり、週末の話や家族の話、この本何？とか、ホットトピックなど。雑談ができるということはお互いの背景や大切にしている価値観などを相互理解できているということ。まず、この状態を作り出すことが大切だ。チーム結成時などにはまず下記のようなツールを利用して相互理解を深め、信頼と結束の土壌を作るといい。

 

• そもそも席が近い、遠いと自然なコミュニケーションが生まれない
• 自分の出自の紹介
• メンバー間でのランチ
• キックオフや飲み会
• 定期的な1 on 1
• 営業同行
• カスタマーサポート体験

 

2. 雑談の中で自然に議論をしているか？

自然な議論がうまれるという事は、チームの課題共有と目標設定が共有できているという事。また、サービスの未来をお互いに語り合ったりする事で、目の前の問題だけではなくメンバー全員がサービスの目指すべき方向や、より本質的な課題についての理解が深まる。

 

チーム全体の課題設定や目標設定などの共通認識を作るためには、下記のようなツールを使って、課題について共有、議論するといい。

• 週一定例ミーティング
• チームオフサイト合宿

3. 他のチームメンバーが今日何をやっているか把握しているか？

変化の早い時代、スピーディーな意思決定が求められる。それに対応するためには、毎日の適切な情報共有は必須となる。これができていれば、自然と他のメンバーが何をやっているかについても共有できているはずだ。

 

逆に毎日適切な情報共有ができていない場合、チームの意思決定やチームの置かれている状態をメンバーが理解できないため、メンバーは変化への対応が遅れる。結局は大きい無駄が発生することが多い。例えば、優先順位が下がった案件についてデザイナーやエンジニアが作業し続け、優先度が高い案件についてリソースが割かれないなど、こういう事故が発生する。

 

• スタンドアップ朝会
• タスクの可視化ツール（カンバン、タスク表） 
• チャットなどのコミュニケーションツール

4. 出社したらまず数字を確認するか？

チーム全員の役割分担が明確になっていて、各自数字にコミットしている状況であれば、メンバー全員が自然と数字を確認するようになる。そのためにはメンバー全員が数字を確認できる環境を整える必要があるが、今の時代、Google Analyticsなど様々な分析ツールを安価な価格で利用できるので、工夫次第では比較的簡単に環境を整えることができると思う。

ここで大切なのが、すぐに誰でも数字確認できるということである。少しでも集計が必要だと、数字を見るのが億劫になってしまう。特に、デザイナーやエンジニアは主務が物作りなので、簡単に確認できる環境しないと見ない人も出てくる。

5. スピーディーに仮説検証サイクルを回せているか？

1から4を実施できていても、スピーディーに仮説検証サイクルを回せなければ、結果は出ない。その場合は、スピーディー施策を回すことができない原因を分析して、対処する必要がある。多くの場合、次のうちのどれかがスピードを阻害している原因ではないだろうか？

• 意思決定プロセス（最終責任者が不明瞭で、現場のメンバーで意思決定できないなど）
• プロダクト制約
• オペレーション制約

一番厄介なのが一つ目の意思決定プロセスだ。よくあるのが経営陣や影響力がある人間が横からチャチャを入れるパターンだ。横からチャチャを入れている人は良かれても思ってやっているがそれがよくない。現場の責任者に任せるのであれば一定期間任せてみて、結果が出なければ現場の責任者を変えるべきだ。これがひどい状況になると現場のメンバー自分たちで意思決定できないので、自分たちは何も決定できないことを悟り、上からの指示を待つようになってしまう。結局チームパフォーマンスを下げてしまう。

6. 最後に、全員が結果に対して執着しているか？

いいチームでは目標設定に対して絶対に達成したい！という、非常に高いモチベーションが保たれている。これはリーダーだけが思っていても達成不可能で、メンバー全員で想いを共有し、全員の知恵と努力を結集しなければ達成できない。1から5を実践できていると自然とそういう空気感が生まれてくる。エンジニアもデザイナーも関わっているメンバー全員が結果に対して執着していれば、そのチームはとても大きなことを達成できると信じている。

まとめ

要するに、チームに関わるメンバー全員が全員のやっている事を把握し、全体の課題や個々の課題をみんなで認識し、役割を明確にし、チームメンバー全員がチームパフォーマンスを意識した行動ができていればいい。しかし、その状態を保つの非常に難しい。マネージャーは常にそこに注視し、問題が発生したら対処しなくてはならない。

参考図書

あなたのチームは、機能してますか？

 最近読んだチームビルディングの本の中で、一番参考になった。このブログタイトルもこの本のタイトルを参考にさせてもらっている。この本の中で出てくる下記のフレームワークはどんなチームでも同じだと思う。チームビルディングで悩んでいる方は是非読んでみてほしい。

1. 信頼の欠如（完全無欠）
2. 衝突への恐怖（表面的な調和）
3. 責任感の不足（あいまいな態度）
4. 説明責任の回避（基準の低さ）
5. 結果への無関心（地位と自尊心）

 

プロダクト開発に関する良書

最近どんな本を読んでるんですか？と質問を受けることが多いので、

テーマ別にプロダクト開発に関連する良書と思うものをリスト化しよう。

私は、テクノロジー全般からプロダクト開発プロセスまでを広く網羅していこうとしているため、テーマが多岐にわたるが、エンジニア、デザイナーの方や、プロダクトマネージャーの方にも参考になると思う。

プロダクト開発プロセス  

テストから見えてくる グーグルのソフトウェア開発

スクラム　仕事が４倍速くなる“世界標準”のチーム戦術

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

リーン・スタートアップ

デザイン・UI/UX

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

UXデザイン入門

 

思考法

仮説思考 BCG流 問題発見・解決の発想法

論点思考

21世紀のビジネスにデザイン思考が必要な理由

なぜあの人の解決策はいつもうまくいくのか?―小さな力で大きく動かす!システム思考の上手な使い方

哲学

情熱プログラマー ソフトウェア開発者の幸せな生き方

シンプルに考える

 マーケティング 

ポイント図解　マーケティングのことが面白いほどわかる本<ポイント図解　マーケティングのことが面白いほどわかる本> (中経出版)

100円のコーラを1000円で売る方法―マーケティングがわかる10の物語

インサイト

USAMIのブランディング論

Hooked ハマるしかけ 使われつづけるサービスを生み出す[心理学]×[デザイン]の新ルール

 

トヨタの秘密 

「タレント」の時代 世界で勝ち続ける企業の人材戦略論 (講談社現代新書)

トヨタ生産方式―脱規模の経営をめざして

トヨタ 仕事の基本大全

情熱プログラマー

6年前、ITコンサルタントをやめて、Web系のソフトウェア技術者になること、マンションの一室でやっていたベンチャーに飛び込むことを決めた頃に読み、非常に影響を受けた本を再度読み返した。改めて、ソフトウェア技術者にとって、とても大切な事が書かれてると思ったので紹介する。

Chad Fowler氏の「情熱プログラマー」。

偉大なソフトウェア技術者になるためのキャリアを、製品のライフサイクルと同じように考え、4つの側面から分析した本である。

1. 市場を選ぶ
2. 製品に投資する
3. 実行に移す
4. 製品を売り込む

情熱プログラマー ソフトウェア開発者の幸せな生き方

Ruby業界では知らない人がいないレベルの有名人で、開発マネージャーや、CTOなどもやってきた人が書いている内容なので、6年経って様々な経験をしてきた今でも様々な発見があった。

6年前駆け出しのエンジニアだったころに響いた言葉と、今読んで響いた言葉は自分の成長もあり少し変わってきていると思うが、いいこと言ってるな〜と思うトピックをピックアップしてみる。

• コーディングはもう武器にならない
• 一番下手くそでいよう
• 万能選手になろう
• スペシャリストになろう
• ビジネスの仕組みを学ぶ
• 師匠を探す
• 師匠になる
• 業界で名を売ろう
• 自分のブランドを築こう
• 世界を変えよう
• 君は既に職を失っている

一貫して「技術者として自分の分野においては一流でいよう」、「自分の技術をビジネス価値に変換しよう」、「自分を売り出そう」ということを言っていて、改めその通りだなと思った。ビジネスの仕組みを学ぶため「MBA系の本を一通り読め！」って書いてあるところは面白い。

この本の中でブログを書くことは、文章力のトレーニングや自分を売り出すことにも繋がる、と書いてあるので4回目になるがブログを改めて始めようと思う。今度は挫折せずに続くか？

私は「プロダクトとユーザーをつなげ、ビジネスを生み出す」ことに情熱を傾けているので、ブログのタイトルを「情熱プロダクト開発」にしようと思う。