及川卓也のレビュー一覧
-
-
Posted by ブクログ
これはプロダクトチームのメンバーとなる人の必読書。
勉強になった。
最善を尽くしたにもかかわらず、あるチームメンバーについて、成功への道筋がイメージできなくなることがある。この段階に達したら、決然と行動するのが重要である。
多くのマネジャーにとっては、この原則が最も実践しづらい。コーチングとは人を育てることなので、必然的に問題点を成長の機会として見ることになる。それ以上に、部下に仕事ができていないと伝えるのは、精神的に最もきつい会話の1つだ。いっそのこと、目を背けてサボったほうが気が楽だろう。
しかしそうすると、マネジャーも、チームも、本人も傷つく。まず、マネジャーは他の人を犠牲にして、この人に必要以上の時間を割いている可能性が高い。次に、他のチームメンバーにはハードワークを求めながら、その人には凡庸であることを許すというシグナルを出してしまっている。それは信頼を損ない、モチベーションを失わせるための確実な道のりだ。最後に、パフォーマンスに問題のある本人が、もっと成功できる可能性のある他の職場に移るチャンスを与えられていない。
■プロダクト担当者らしい行動
傾聴し、協力し、共同学習し、啓蒙し、鼓舞し、手柄を渡し、責めを引き受け、責任を取り、知りえないことを知り、知らないことを認め、謙虚さを示し、会社全体にわたってさまざまな関係を築き、個人レベルで顧客を知り、リーダーシップを発揮することをいう。
■マネジャーのアンチパターン
・マネジャーが無関心
・マネジャーがマイクロマネジメントに回帰する
・マネジャーが話してばかりで相手の話を聞かない
・マネジャーが厳しいフィードバックをしない
・マネジャーが不安定か、あるいは能力不足である
・マネジャーが損切りをしない
つまり、デザイナーやエンジニアと協力して、価値、ユーザビリティー、実現可能性、事業実現性を備えたソリューションを編み出すことだ。それがプロダクトディスカバリーであり、毎日４時間専念すべき仕事である。
■プロダクトチームの４大リスク
１．顧客はこのプロダクトを買うか、あるいは選ぶか？（価値のリスク）
２．ユーザーはこのプロダクトの使い方がわかるか？（ユーザビリティーのリスク）
３．私たちはこのプロダクトを製造・構築できるか？（実現可能性のリスク）
４．ステークホルダーはソリューションを支持するか？（事業実現性のリスク）
５．私たちはこのプロダクトを製造・構築するべきか？（倫理的リスク）
■私が気に入っている面接の質問
１．実行力―どのくらいうまくものごとをやり遂げ、言われなくても正しいことを実行し、複数の目標を同時に追求できるか。
２．創造力―その場にいる人の中で、あなたが一番多くのアイデア、または最も優れたアイデアを提案できたケースはどの程度頻繁にあるか。
３．戦略―現在取り組んでいる内容を俯瞰的に、より広いマーケットやビジョンのコンテキストでとらえ、それを他の人たちに対して明確に提示することが、どのくらいうまくできるか。
４．成長―プロセスの賢い使い方やチームマネジメントなどを通じて取り組みの成果を倍増させる能力に、どのくらい優れているか。
しかし、多くの企業にとっては、問い自体が変化している。
いまや、私に寄せられる問いは、「プロダクトチームが分散し、一部または全体がリモートワークに従事しているという前提で、自分たちが継続的なイノベーションを起こす可能性を最大限に高めるために、ベストプラクティス（最良の方法）をどのように活用するか」に変質している。
■トポロジーとデザイン
ほとんどの企業は、職能横断型プロダクトチーム、少なくともエクスペリエンスチームには、専任のプロダクトデザイナーが必要であることを理解しているこれは、優れたプロダクトをつくるために、プロダクトデザインがどれほど決定的に重要かという認識を示している。
ただし、デザイン部門のリーダーが、「社内エージェンシーモデル」という別の形を好む場合もある。…
…
社内デザインエージェンシーモデルでは、重要な意思決定が行われるときに、デザイナーは通常その場にいない。したがって、デザイナーは―そして最終的にはユーザーが―そのツケを払うことになるのだ。
デザインは社内サービスとして運営するには、あまりに重要だ。デザインマネジャーは、プロダクトマネジャーやテックリードと同様に、プロダクトチームの中でも特に優秀なメンバーが務めなければならない。
スタートアップ企業の創業者やCEOの多くは、有能なエンジニアリング組織と協力して仕事をしたことがありません。そのため、テクノロジーの役割や、エンジニアがプロダクトマネジャーやプロダクトデザイナーのパートナーとして果たすべき貢献について、根本的に誤解していることが珍しくありません。
■チームに答えを導かせるほうが優れている理由
・最も適切なソリューションを判断するのに適した人々は、問題に最も近く、必要なスキルを備えた人々―つまり、プロダクトチームである。
・会社としては、求められるアウトカムを達成するために、チームに責任を持ってもらいたい。
・構築すべき機能を会社からチームに指示してしまったら、その機能が必要な結果をもたらさなかった場合に、チームの説明責任を問えない。
・解決すべき問題と、その問題を最適と思える形で解決するための余地をプロダクトチームに与えれば、チームは問題に対し、はるかに高いオーナーシップを感じるようになる。
・チームが考えついた初めてのソリューションによって求められるアウトカムが生まれなかった場合、チームは、そのソリューションを引き続き繰り返すか、別のアプローチを試すかして、求められるアウトカムを生み出すソリューションを見つけなければならない。
■実在の急成長企業の事例からの最重要ポイント
１．トポロジー、プロダクト戦略、チームの戦略から、四半期中に発生する問題や障害の臨機応変なマネジメントまで、プロダクトリーダーが果たすべき重要な役割。
２．フォーカスとインサイトに基づく真のプロダクト戦略の重要性。
３．チームの目標を積極的にマネジメントする重要性。
４．エンパワーされたチームと伝道師のチームの価値。
５．知ることができる情報とできない情報に関する制約。
６．一部しか功を奏さないとわかっていても複数の方法に賭ける、というリスクマネジメント要素。
７．インサイトを行動に変える際にチームトポロジーが与えるインパクト。
８．リーダーとプロダクトチームに必要なギブアンドテイク。
９．すべてのプロダクトチーム間のおける広範囲の戦略コンテキストの共有の重要性。
10．不確かなことは面倒で、うまくいく保証はない。しかし賢いリーダーはたいてい、うまくやる方法を見つける。それは、チームを信頼し、不確かさを受け入れ、リスクを適切に管理するからである。
■エバンジェリズム10のテクニック
１．プロトタイプを見せよう。
２．ペイン（痛み、悩み）を共有しよう。
３．ビジョンを共有しよう。
４．学びを共有しよう。
５．貢献してくれる人々の名前を気前よく共有しよう。
６．素晴らしいデモをする方法を学ぼう。
７．自己学習をしよう。
８．心の底からときめきを感じよう。
９．熱意を表に出すやり方を学ぼう。
10．プロダクトチームと時間を過ごそう。 -
-
Posted by ブクログ
前半はある企業でベンチャー企業を導入した際の様子が小説式で書かれている。
後半はOKRそのものの解説だ。
「Measure What Matters」も各企業のOKR例を出してくれていたが、本書は1社のみ。
しかも架空のベンチャー企業を題材としていた。
そういう意味では、「Measure What Matters」の方が現実的だし、説得力があった。
一方で、架空のベンチャー企業の物語は、それはそれでアリかもしれない。
おそらく数々の企業のエピソードを総合して物語として完結させたのだろう。
このとあるベンチャー企業の起業の様子が、違和感なく想像できたのだ。
本当に会社を運営していくのは大変だ。
そういう意味でサラリーマンというのは、何と楽なことか。（誤解を恐れずに表現してみた）
経営者というのは、胃がキリキリする思いで、毎日を過ごしているのだろう。
何でこんな思いしてまで会社経営しなければいけないんだ、と自問自答しながらの日々。
部下は想像以上にポンコツで、仕事への意欲もない。
渾身の商品も顧客にはそっぽを向かれ、売上が立つ見通しもない。
そんな日々から必死で抜け出すために、藁にもすがる思いでOKRという幻想を追い求める。
そんな頼りないものでもすがってしまうほどに、経営者というのは孤独なのだろうと思う。
しかし、決してOKRはすべてを解決する魔法の呪文ではない。
必死に前を向くため。
ともすれば忘れてしまいがちな理想の形をハッキリとさせるため。
脇目もふらずに真っ直ぐ進んでいけるように。
心が折れないように。
そんな願いが詰まっているのがOKRというものなのだということを、この本書で見ることが出来た。
だから、OKRをただの制度として取り入れようとは思わない方がいい。
そこに「思い」が無い限り、OKRは形だけのものになってしまうだろう。
不思議なもので、企業は生き物である。
根性論は否定されがちであるが、人間が集まって共同で成し遂げようとしている集団的生き物に、「思い」はものすごく大事ではないだろうか。
それら「思い」を案外と分かりやすく形にしたのがOKRなのだと思う。
だからこそ、経営トップがOKRにコミットしなければいけないし、経営トップこそがストレッチな目標を追い求めないといけない。
サラリーマン社長で、出世が人生のゴールになってしまっている経営者が、果たしてOKRを正しく運営できるだろうか。
正直難しいと思う。しかしながら、これらストレッチな目標を頑張って追い求めていける企業でないと、今後は絶対に生き残れないだろう。
これだけの時代の変化が激しい中で、一歩でも二歩でも意地でも前に進んで行ける気持ちがない限りは本当に負けるぞ。
本書を読んでそう感じてしまった。
つまり個人の人生にとっても、OKRは非常に必要なツールなのだと思った。
（2021/7/14） -
-
-
-
-
-
Posted by ブクログ
JavaScriptを勉強したくて購入。エンジニア歴1年で、プログラム歴は2年弱くらいの俺。ある程度プログラムの仕組みが分かっていたから、変数や条件分岐や繰り返し、などそこまで新しい言葉が出てきた訳ではなかった。「あぁ、JavaScriptではそうやって書くのね」くらいの感じ。
内容は先生と生徒の対話を中心に進められる。生徒の質問がなかなか的確。コードの読み方とか、それが何を意味するのかとか分かりやすく書いてある。プログラムって英語と記号が並んでるやつでしょ？と思っているプログラミング初学者でも、その壁を取っ払ってくれる。
ただ、もしもプログラミング未経験の自分が、プログラミングを学ぶための最初の一冊としてこの本を手にしたとき、果たして最後まで読み切れるだろうか？という疑問はある。プログラミングのプの字も分からない状態で、前半から関数やメソッドやオブジェクトの話をサラリと出されても分からないのではないではないだろうか。「consoleオブジェクトは〜」の話をする必要はあったのか。
言語の仕様の話は他の本に譲って、もう「このコードを書いたら、こういう動きをしますよ」だけに止めておいたらいいのではないかと感じた。 -
-
-
-
-