#今日の30分 ログ

ツイート

ライト、ついてますか

#今日の30分 -1分。「ライト、ついてますか」120ページまで。当事者に思い出させる話と、問題の原因を考える話。ああしろこうしろと指示するのではなく、あなたは今こういう状況ですよ、と思い出させる。すると、当事者はその状況に応じて勝手に適応する。思い出させるだけで、問題が解決する。

— ざっきー dev (@zakky_dev) 2020年12月28日

#今日の30分 +5分。「ライト、ついてますか」147ページまで。自己増殖的問題と、問題を本当に解きたいかという話。うーん、どうにも相性が良くない……何がいいたいのかよくわからない……読解力が足りない……。出すことが目的の問題と、初見の問題と、実際に求めているもとは違う、という話かな。

— ざっきー dev (@zakky_dev) 2020年12月29日

#今日の30分 -2分。「ライト、ついてますか」読了。本当にその問題を解きたいか、という話。出題された問題を解いたところで、出題者が抱えている本当の問題を解決できるとは限らない。例えば、計算機によって解決できる計算を手計算する仕事をする人からすれば、計算機による解決など邪魔なだけだ。

— ざっきー dev (@zakky_dev) 2020年12月30日

ライト、ついてますか―問題発見の人間学

More Effective Agile

#今日の30分 -2分。「More Effective Agile」流し読みKindleでNo.886まで。目次からしてすでに良さそうな気配がある。より効果的なアジャイルの本。準備完了の定義、バーティカルスライス、ポートフォリオマネジメント、学習するチームの話あたりが特に気になるかな。あと境界の話も。 pic.twitter.com/2pjkbwh2c3

— ざっきー dev (@zakky_dev) 2020年12月31日

#今日の30分 -2分。「More Effective Agile」流し読みKindleでNo.2760まで。スクラムの話と関連して準備完了の定義の話が出てくる本は珍しい。あと「ストーリーをスライスする」という言い回しの意図の話が個人的にありがたい。もうちょっと踏み込んでみたいと思ってるんだよな、このへん。

— ざっきー dev (@zakky_dev) 2021年1月1日

#今日の30分 -2分。「More Effective Agile」流し読みKindleでNo.4531まで。今更だけど、この本はスクラムをベースに話をしてるんだな。Clean AgileはXPベースだったっけ。チームレベルの話だけでなく、組織レベルの話で予算管理の話とかも含めて書かれているのが嬉しい。

— ざっきー dev (@zakky_dev) 2021年1月2日

#今日の30分 -8分。「More Effective Agile」流し読み終わり。教科書的なアジャイルでなくとも、ビジネスを支えるためにアジャイルの思想を適用することができればいい。そのために、現実の組織、現実のビジネスを踏まえて、より効果的なアジャイルを探求するにどうするか、という話かな。

— ざっきー dev (@zakky_dev) 2021年1月3日

More Effective Agile “ソフトウェアリーダー”になるための28の道標

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • -

今回の追加活動

• タイミングを決めて「今日の30分」とは別枠で本を読む。
• 流し読みの目的から、この活動自体のやり方を考え直す。

#今日の30分 ログ

ツイート

INSPIRED

#今日の30分 +2分。「INSPIRED」344ページまで。スケールアップ時のアンチパターン、学習の共有と、良い製品開発チームの文化について。スケールアップ時に大企業の人材を無策で入れると、その大企業の文化が持ち込まれてしまう。文化を確立し、採用時点で文化の持ち込みを明確に断っておくと良い。

— ざっきー dev (@zakky_dev) 2020年12月21日

#今日の30分 -3分。「INSPIRED」読了。イノベーションが失われる理由、スピードが失われる理由、強い製品開発文化を作る。スタートアップのときには自然と持っていた文化が、スケールアップにつれて失われ、結果として速度が落ち、イノベーションも起こせなくなっていく。文化を作り、維持する。

— ざっきー dev (@zakky_dev) 2020年12月22日

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

ライト、ついてますか

#今日の30分 昨日分。+4分。「ライト、ついてますか」流し読み終わり。問題と、問題解決についての本かな。誰の問題なのか、何が問題か、その本質は何か。解決しても次の問題が生まれるため、問題は連鎖しなくなることがない、って話は納得感があるな。問題と見れば解決策をすぐ考えたがる傾向の話も。 pic.twitter.com/mkIhL7bggw

— ざっきー dev (@zakky_dev) 2020年12月24日

#今日の30分 今日分。-1分。「ライト、ついてますか」28ページまで。問題の全体像の話。特定の事実に依拠していても、視点次第で全く別の問題になる。問題を見つけたなら、解決策を考えるより前に、どういう種類の、誰にとっての、何が問題なのかを先に考える。さもないと、解決策は的外れになる。

— ざっきー dev (@zakky_dev) 2020年12月24日

#今日の30分 +1分。「ライト、ついてますか」57ページまで。問題は何なのかと、問題は連鎖することについて。問題解決の構造的原因、正しい問題の定義は決して得ることができず、どう解くかが問題の定義として扱われてしまうことも多い。それでも何が正しい問題かを考え続けることは必要になる。

— ざっきー dev (@zakky_dev) 2020年12月25日

#今日の30分 昨日分。-4分。「ライト、ついてますか」73ページまで。不適合を見落とす話、うまいレベルに着陸する話。問題解決の設計者は、自身の解決策の結果を経験しないケースが多い。そのため、実際に問題に直面する当事者と、解決策はうまく噛み合わないことも多い。噛み合わなさを不適合と言う。

— ざっきー dev (@zakky_dev) 2020年12月27日

#今日の30分 今日分。-4分。「ライト、ついてますか」98ページまで。問題の共通認識を作る話と、問題を自責化することで解消させる話。ネガティブな事実を前にした時、どのような問題として解釈するかは人によって違う。問題文として形作られていても、曖昧さによって解釈が変わることはよくある。

— ざっきー dev (@zakky_dev) 2020年12月27日

ライト、ついてますか―問題発見の人間学

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • -
• パーソナルトレーナーについて調べる
  • 料金が高すぎる

今回の追加活動

• タイミングを決めて「今日の30分」とは別枠で本を読む。

「INSPIRED」329ページまでの読書ログと今週のふりかえり #今日の30分

ツイート

INSPIRED

#今日の30分 -3分。「INSPIRED」272ページまで。ユーザビリティテストの話。製品発見段階にて、プロトタイプを使って早めにやること。後回しは無駄を生む可能性を高める。テスト実施中は被験者に手を貸さず、とにかく行動に注目する。どこで迷うのか、何を見ているのか。摩擦点を探す。

— ざっきー dev (@zakky_dev) 2020年12月14日

#今日の30分 -4分。「INSPIRED」281ページまで。価値のテストとリスク嫌い体質な企業の製品発見テストについて。製品を乗り換えるのは、乗り換え対象が格段に優れているときに限る。機能的に同等である程度では、慣れやらなんやらで乗り換えられない。本質の価値を追求すること。

— ざっきー dev (@zakky_dev) 2020年12月15日

#今日の30分 「INSPIRED」290ページまで。定性的価値テストと定量的価値テストについて。使いやすいものが予算的に問題なく、事業とのかみ合わせも悪くなく作れたとしても、顧客にとってどうでもいいものなら作る意味はない。ユーザビリティテストの次に価値をテストし、このリスクに対処する。

— ざっきー dev (@zakky_dev) 2020年12月16日

#今日の30分 「INSPIRED」300ページまで。データに基づいた製品開発と、実現可能性テストの話。ITにより、製品発見での分析の有用性が大きく上がった。市場の拡大、データ量の増大、分析ツールの進化。これらがチームに与える学習効果と、それに基づく高速な適応。宝の山を漁れるようになった。

— ざっきー dev (@zakky_dev) 2020年12月17日

#今日の30分 +1分。「INSPIRED」308ページまで。事業実現性テストと、プロトタイプの見せ方の話。ユーザーや顧客に愛され、エンジニアが作れたとしても、ビジネス的に意味がなかったり、あるいは逆効果であればやるべきではない。そのため、関係者と事業上の制約について話し、本当に作るか考える。

— ざっきー dev (@zakky_dev) 2020年12月18日

#今日の30分 -3分。「INSPIRED」319ページまで。トランスフォーメーションの話で、ディスカバリースプリント、ディスカバリーコーチ、パイロットチームについて。変化は難しい。そのため、フレームワークとしてのディスカバリースプリント、教師役としてのディスカバリーコーチがいると良い。

— ざっきー dev (@zakky_dev) 2020年12月19日

#今日の30分 -2分。「INSPIRED」329ページまで。ロードマップからの脱却と、スケールアップにおけるステークホルダーの管理について。企業が大きくなるほど、リスクを嫌うようになる。小規模なスタートアップは失うものが少なく、大企業になると多くなる。だからステークホルダー管理が必要になる。

— ざっきー dev (@zakky_dev) 2020年12月20日

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • 「クリストファー・アレグザンダーの思考の軌跡」21ページまで。
• ケーススタディはその場では読まず、まとめを書いてから読む。
  • ケーススタディがある本とない本があるため、ここからは削除。ある本では実施してみる。

今回の追加活動

• タイミングを決めて「今日の30分」とは別枠で本を読む。
• パーソナルトレーナーについて調べる

「INSPIRED」263ページまでの読書ログ #今日の30分

ツイート

INSPIRED

#今日の30分 +3分。「INSPIRED」187ページまで。製品発見とその原則について。製品発見はプロダクトマネージャの最大の責務だ。ゴミを作るムダを無くすために、製品発見に取り組む。これにより、4つのリスクに対処する。価値、ユーザビリティ、実現可能性、事業実現性。

— ざっきー dev (@zakky_dev) 2020年12月7日

#今日の30分 「INSPIRED」197ページまで。倫理、製品発見のイテレーション、製品発見のテクニックの概要。法ではなく、倫理的にそれを作るべきか否か。そういったものを見つけてしまったとき、できるだけ別の解決策を探すこと。できることと、やっていいことは違うのだから。

— ざっきー dev (@zakky_dev) 2020年12月8日

#今日の30分 -4分。「INSPIRED」210ページまで。製品のフレーミングテクニック、市場機会評価、カスタマーレター、スタートアップキャンバスについて。人間の性質として、問題よりも解決策の話をしたがる傾向がある。解決する必要のない問題を解決すべきと思いこむことは多々あることに注意。

— ざっきー dev (@zakky_dev) 2020年12月9日

#今日の30分 -5分。「INSPIRED」220ページまで。製品発見のプランニングテクニック、ストーリーマップと顧客発見プログラム。ユーザーストーリーマップ、随分前に読んだなあ。全体像がわかりやすく、発展予測がしやすい。フィードバックを反映し、価値のリスクを減らしていける。

— ざっきー dev (@zakky_dev) 2020年12月10日

#今日の30分 -2分。「INSPIRED」233ページまで。顧客発見プログラム、プロダクトマーケットフィットの定義について。PMFは、コンシューマー向けならショーン・エリス・テストが有効で、ビジネス向けなら顧客発見プログラムのリファレンスカスタマーが6つ見つかることが目安となる。

— ざっきー dev (@zakky_dev) 2020年12月11日

#今日の30分 「INSPIRED」248ページまで。製品のアイディエーションテクニック、顧客インタビュー、コンシェルジュテスト、顧客による不適切な使用、ハッカソン。それにプロトタイプの種類の話。リーン顧客開発あたりで読んだ記憶のある話も結構出てきたなー。経験が薄いのがなー……。

— ざっきー dev (@zakky_dev) 2020年12月12日

#今日の30分 -5分。「INSPIRED」263ページまで。プロトタイプの原則、実現可能性プロトタイプ、ユーザープロトタイプ、ライブデータプロトタイプ、ハイブリッドプロトタイプについて。プロトタイプの話なら、リーン顧客開発が詳しく書いてあったっけな。オズの魔法使いもあった気がする。

— ざっきー dev (@zakky_dev) 2020年12月13日

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • -
• ケーススタディはその場では読まず、まとめを書いてから読む。
  • -
• ハードな振る舞いの練習方法を相談する。
  • Done.

今回の追加活動

• タイミングを決めて「今日の30分」とは別枠で本を読む。
• ケーススタディはその場では読まず、まとめを書いてから読む。

転職します

いわゆる転職エントリです。おおよそ一年半ぶりですね。早い。
Twitter上では連絡済みでしたが、記録などのためにブログにも残しておきます。

どこからどこへ

from: 東京のC社
to: 東京のR社

2021年1月から働きます。すでに最終出社済みなので、これから半月ほどニート期間です。
詳細は飲みにでも誘って貰えれば答えます。またRuby書いてると思います。

Twitter上の連絡

下記ツイートへのお祝いの言葉、本当にありがとうございました。
嬉しかったです。次も頑張ります。

転職決まりました。現職は年末までで、年明けから新しいところになります。転職宣言ツイートの拡散、お声がけなどありがとうございました。次のところでも頑張ります。

— ざっきー dev (@zakky_dev) 2020年11月12日

退職なう

— ざっきー dev (@zakky_dev) 2020年12月11日

欲しい物リスト

ありがたいことに、すでにいっぱい頂いていますが、一応書いておこうと思います。
できればTwitterアカウントを付記していただけると、ご挨拶送りやすいです。
よろしくお願いします。

「INSPIRED」176ページまでの読書ログ #今日の30分

ツイート

INSPIRED

#今日の30分 -3分。「INSPIRED」118ページまで。デリバリーマネージャ、製品開発チームを構成する基本方針。決めないといけないことを決めさせたり、承認が必要なことを承認させたり、必要なものを用意したり。大規模になるほどそうした障害除去を担うデリバリーマネージャが有効に働く。

— ざっきー dev (@zakky_dev) 2020年11月30日

#今日の30分 -3分。「INSPIRED」124ページまで。スケールアップにおける自律性について。基盤を利用することによって、開発チームの自律性は減っていく。基盤利用によるレバレッジと、開発チームの自律性はトレードオフで、唯一の解は存在しない。考慮すべき要素を踏まえ、考えることが重要。

— ざっきー dev (@zakky_dev) 2020年12月1日

#今日の30分 +5分。「INSPIRED」139ページまで。大企業の変化、製品開発ロードマップの問題と代替について。Adobeの例が出てきた。サブスクリプション化はびっくりした覚えがあるし、実際に成し遂げたのもびっくりだったなー。ビジネスモデルの変革であっても、地道にやることは重要ね。

— ざっきー dev (@zakky_dev) 2020年12月2日

#今日の30分 「INSPIRED」149ページまで。ハイインテグリティコミットメント、製品ビジョン、製品戦略、市場の優先順位。ハイインテグリティコミットメント、言い方は違うけど、アジャイル関係で似たような話を見たような覚えがある。でもこれ、検証期間はどう合意取るんだろう。

— ざっきー dev (@zakky_dev) 2020年12月3日

#今日の30分 -4分。「INSPIRED」158ページまで。製品ビジョンの原則、製品戦略の原則、製品理念、目標管理について。製品ビジョンも、目標管理も、WHYから始める。背景、目的を理解し、解決策については自由に。考えることは難しくとも、そちらのほうが楽しい、ということなんだろう。

— ざっきー dev (@zakky_dev) 2020年12月4日

#今日の30分 -4分。「INSPIRED」165ページまで。OKRと製品開発チームの目標の話。目標は定性的、主要な結果は定量的。主要な結果はタスクの消化数やリリースの回数などではなく、ビジネス的な成果にする。評価基準は組織として合意する。そのために、組織的に一貫性のあるものを設定する。

— ざっきー dev (@zakky_dev) 2020年12月5日

#今日の30分 +2分30秒。「INSPIRED」176ページまで。製品のスケールアップ、製品目標のスケールアップ、エバンジェリズムについて。スタートアップの初期では、ビジョン、戦略、目標がなくてもなんとかなる。問題になるのはスケールアップしたときだ。対策がなければ開発能力が低下していく。

— ざっきー dev (@zakky_dev) 2020年12月6日

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • -
• ケーススタディはその場では読まず、まとめを書いてから読む。
  • -
• ハードな振る舞いの練習方法を相談する。
  • -

今回の追加活動

前回の活動を継続。

「INSPIRED」110ページまでの読書ログ #今日の30分

ツイート

INSPIRED

#今日の30分 「INSPIRED」49ページまで。基本的概念と製品開発チームについて。製品開発チームについての話を見るたび、営業の人とかどうなるんだろう、と思う。マーケティングは言及されるんだけど、ちょっと役割違う印象を自分としては持っている。見落としている他の役割もあるんだろうな。

— ざっきー dev (@zakky_dev) 2020年11月23日

#今日の30分 −4分。「INSPIRED」59ページまで。製品開発チームの原則と、プロダクトマネージャの話。自律的で、責任感があり、オーナーシップを持った製品開発チーム。専門性に対してではなく、製品に対して責任を持つ。ただ、専門性を極めたがる人もいる。こうした人はどうなるべきなんだろう。

— ざっきー dev (@zakky_dev) 2020年11月24日

#今日の30分 −4分。「INSPIRED」69ページまで。プロダクトマネージャの責任、プロダクトマネージャとして成功する人の特性について。成功する人の特性の話、頭がよく、創造的で、粘り強い人って、そういう人はプロダクトマネージャじゃなくとも成功するのでは。特異な性質ではないよね。

— ざっきー dev (@zakky_dev) 2020年11月25日

#今日の30分 +7分。「INSPIRED」81ページまで。プロダクトデザイナーとエンジニアとの付き合い方。プロダクトマネージャとプロダクトデザイナーは多くの関心事を共有している、というのはイメージに合う。製品にまつわる全体的な体験のデザイン。プロトタイプを作って検証する部分も同じく。

— ざっきー dev (@zakky_dev) 2020年11月26日

#今日の30分 昨日分。-3分。「INSPIRED」93ページまで。プロダクトマーケティングマネージャとサポートスタッフとの付き合い方、抵抗と向き合う、スケールアップ時のリーダーの役割。マーケティングマネージャのあたりが怪しい。再読するかな。いない場合にPdMerが地獄になるのはわかった。

— ざっきー dev (@zakky_dev) 2020年11月28日

#今日の30分 今日分。+1分。「INSPIRED」103ページまで。3人のリーダーについて、製品開発のトップ、デザインのトップ、技術のトップについて。彼らは製品を全体的な視点で見て行動する。システムの調和が取れているか、各々の領域の視点で考える。そのため、近くで働くことが望ましい。

— ざっきー dev (@zakky_dev) 2020年11月28日

#今日の30分 -3分。「INSPIRED」110ページまで。グループプロダクトマネージャ、技術部門のトップの役割について。最前線で戦う道、一歩下がって管理する道、その中間として緊密な協力が必要な範囲でのみ管理を行い、自分も最前線で戦う道。負担的には一番重そうだな、GPM。

— ざっきー dev (@zakky_dev) 2020年11月29日

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • -
• ケーススタディはその場では読まず、まとめを書いてから読む。
  • -
• ハードな振る舞いの練習方法を相談する。
  • -

今回の追加活動

前回の活動を継続。