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

ツイート

LeSS

#今日の30分 +1分。「LeSS」168ページまで。プロダクトオーナーの役割の話。優先順位付け、増えすぎる仕事の対処、5つの関係。プロダクトオーナーの仕事は増えやすい。プロダクトオーナーが中心とすべきは優先順位付けであり、アイテムの明確化などはチームに委任していく。

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

#今日の30分 -1分。「LeSS」173ページまで。プロダクトオーナー周辺の関係性、プロダクトオーナーと顧客/ユーザー、チームと顧客/ユーザー、プロダクトオーナーと上級マネジメント、プロダクトオーナーとスクラムマスター。POってつまり、目的目標を考え、その方向性を示す役割なのか。

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

#今日の30分 -5分。「LeSS」178ページまで。顧客との協調、スプリントごとの出荷、「良い人」にならない、Undoneワーク、POが参加するミーティング、LeSS Hugeでの原理原則について。LeSS Hugeでもプロダクト全体思考と顧客中心は変わらない。要求エリアがあるため、POはチームを組む。

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

#今日の30分 -1分。「LeSS」184ページまで。LeSS Hugeのプロダクトオーナーと、LeSSにおけるプロダクトバックログ。LeSS Hugeではオーバーオールプロダクトオーナーとエリアプロダクトオーナーがいる。前者は全体の優先順位付け、後者はエリア内の価値最大化を主として担う。

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

#今日の30分 -3分。「LeSS」192ページまで。外部依存との付き合い方、プロダクトバックログアイテムの分割について。外部依存先が終わらないと特定作業ができないなら、依存先をスタブ化などでごまかし、そこを差し替える作業だけを後回しにする。ただ待つのではなく、できるところを作る。

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

#今日の30分 -1分。「LeSS」197ページまで。特殊なアイテムの扱いと大規模なプロダクトバックログを管理するツールについて。ツールを使っただけではアジャイルにならない。アジリティは組織的なふるまい。極論、できるところならスプレッドシートやwikiで十分アジリティが出る。

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

#今日の30分 -4分。「LeSS」204ページまで。アウトカムを多くアウトプットを少なくする、LeSS Hugeのプロダクトバックログとエリアバックログについて。アウトプットによる管理はやりやすいからそちらに流れやすい。インパクトマッピングなどの手法により、アウトカムに着目しやすくする。

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

大規模スクラム Large-Scale Scrum(LeSS)

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • あまり読めなかった。

今回の追加活動

前回の活動を継続。

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

ツイート

LeSS

#今日の30分 -4分。「LeSS」123ページまで。現地現物、LeSSのマネージャ、ドメインと技術力、メトリクス。ドメインと技術力を両立することでより良いプロダクトを作れるようになるため不均衡を均すこと。メトリクスはそれ自体ではなく、目的を考えて必要性に応じてチームが設定すること。

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

#今日の30分 -4分。「LeSS」129ページまで。LeSSにおけるスクラムマスターについて。原則、ルール、重視すること。LeSS導入ではまず組織に働きかけてLeSSの形を作る、チームやPOの能力を高める、さらなる改善のために組織に働きかけたり技術プラクティスのコーチングを行う。

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

#今日の30分 -2分。「LeSS」135ページまで。スクラムマスターのツール、巨大グループのファシリテーション。基本方針は「チームに任せる」。そのために必要なスキルを教育する。でしゃばりすぎない。チーム外でしか解決できない場合に、その問題に着手する。あくまでもチームを要素とする。

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

#今日の30分 -1分。「LeSS」144ページまで。スクラムマスターのサバイバルガイド、注意すべき領域、LeSS Hugeでの考慮事項、プロダクトの定義について。チームの排他主義、他責傾向、外への非難はありがちな問題の印象。遭遇したときのツールとして、この2つの質問は持っておいたほうがいいな。

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

#今日の30分 「LeSS」150ページまで。プロダクトの定義について。このプロダクトの定義ってのがいまいちちゃんと説明されておらず、どうにも掴みづらい。イメージ的には誰が使うどのようなものなのかを明確にする、ということだろう。できるだけ広くするが、共通性と既存構造により狭まる。

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

#今日の30分 −5分。「LeSS」156ページまで。プロダクトの定義の拡張について。プロダクトの定義を作り、それを徐々に拡張していく。定義を作るに当たり、定義を広げるものと制限するものを考えるが、広げる場合は制限するものを変えることになる。拡張を制限するものは何なのか？

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

#今日の30分 「LeSS」163ページまで。LeSSのプロダクトオーナーについて。大規模になっても個人というところは疑問だったんだけど、チームにどんどん仕事を委譲していき、優先順位付けに集中することで、ある程度軽減するのか。優先順位付けに使う情報もチームが集めてくることになるかな。

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

大規模スクラム Large-Scale Scrum(LeSS)

ふりかえり

前回の結果

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • あまり読めなかった。

今回の追加活動

前回の活動を継続。

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

ツイート

LeSS

#今日の30分 「LeSS」76ページまで。LeSS Hugeの導入と、顧客価値による組織化について。LeSS Hugeを導入する必要があるようなプロダクトは、その規模の大きさから、LeSS Hugeを一気に導入すると混乱や強い抵抗が生まれる。よってインクリメンタルに導入すると良い。

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

#今日の30分 -1分。「LeSS」84ページまで。顧客価値による組織化の話続き。フィーチャーチームとコンポーネントチーム。フィーチャーチームはE2Eで機能を実現する。スプリントごとにインクリメントを生むが、最初からそれができるとは限らない、というのはちょっと救いになる話だ。

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

#今日の30分 +1分。「LeSS」84ページまで。フィーチャーチーム導入マップ、顧客ドメインでの専門化について。導入マップはコンポーネントチームからフィーチャーチームに変わっていくに当たり、今どこにいて、次どこを目指すのかを考えるために有用なツール。一気に変えることはできない。

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

#今日の30分 +1分。「LeSS」98ページまで。LeSSの組織構造、拠点戦略の原理原則、LeSS Hugeについて。拠点戦略を考えると、都市部ほど大規模開発に向かないものはないな。オフィスの家賃が高すぎて、大人数を一箇所に集めるのは体力が求められすぎる。もっと分散したほうがいいのかもな。

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

#今日の30分 「LeSS」103ページまで。LeSS Hugeの要求エリア、フィーチャーチーム、組織構造の話。要求エリアは固定的なものではなく流動的なもの。顧客にとっての価値から見て、価値が薄れてきたエリアは統廃合されるし、新しい価値が見出されたらそのためのエリアが生まれる。

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

#今日の30分 -2分。「LeSS」110ページまで。LeSS Hugeの組織構造の続きと、LeSSにおけるマネジメントについて。テイラーしか知らなかったけど、他にファヨールって人もいたんだな。その時期においては有用なアイデアだったんだろうけど、その目的や背景を理解せずそのまま使うのは危険だ。

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

#今日の30分 +2分。「LeSS」116ページまで。X理論とY理論、LeSSの組織について。X理論は検証されていない仮定、Y理論は社会科学の研究結論とバッサリ。これまではなんとなく正しいと思われてきたことに基づき、組織を運営してきた。そう考えると、今の時代は変わりつつある時代なのかもね。

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

大規模スクラム Large-Scale Scrum(LeSS)

ふりかえり

前回の結果

• 「今日の30分」とは別枠で本を読む。
  • -

今回の追加活動

• タイミングを決めて「今日の30分」とは別枠で本を読む。
  • まずは朝食後から。週内に変更も想定。

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

ツイート

LeSS

#今日の30分 +4分。「LeSS」10ページまで。LeSSの概要。スクラムを大規模にしたものであり、新しいスクラムではない。複数チームにスクラムの原理原則、価値観を適用するためのフレームワーク。意図的に不完全にしておくことで、自律的に継続的改善を行い、状況ごとに最適化する。

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

#今日の30分 +1分。「LeSS」22ページまで。LeSSとLeSS Huge、そのうちLeSSの概要について。LeSS HugeはLeSSでは対応できない大きさのプロダクトに対応するためのフレームワーク。具体的には8チーム以上の場合LeSS Hugeが望ましい。これは経験則的な上限値。

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

#今日の30分 -1分。「LeSS」34ページまで。LeSSとLeSS Hugeの概要続き。本当にスクラムを大規模化したもの、って印象だ。ただそれだけに、プロダクトオーナーの負担が大きくなるような気もする。掘り下げをチームがやることで、ある程度の負担軽減になるのだろうか。

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

#今日の30分 -1分。「LeSS」44ページまで。LeSS Hugeの概要。要求エリアを導入したLeSS。要求エリア内では通常のLeSSのように見える。各要求エリアにはそれぞれエリアプロダクトオーナーと、エリアプロダクトバックログがある。所属するチームは4から8チームが望ましい。

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

#今日の30分 -2分。「LeSS」55ページまで。複数拠点のLeSS HugeとLeSSの導入について。複数拠点でやるなら、同じチームは同一拠点で組む、チーム間に主従を作らない、コミュニケーションコストが低くなるように拠点を選ぶ。このあたりは国内だと感じづらい部分でもあるかも。

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

#今日の30分 「LeSS」64ページまで。LeSSの導入原則とガイド。ボランティアって言葉、どうにもいい印象を持てなくて読むのに苦労した。文脈的には自発的な協力者というか参加者というかそんな感じ。このあたりは文化の違いを感じる部分。目的を伝え、自発的な協力を求める。

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

#今日の30分 -1分。「LeSS」70ページまで。LeSS導入にあたっての組織ビジョン、継続的改善、導入の拡大について。目指すべき遠い目標、あるいは北極星的な道標を描くことで、自分たちの現在位置や向かおうとする先を評価することができる。無策な改善提案より、ビジョンに近づく改善を目指す。

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

大規模スクラム Large-Scale Scrum(LeSS)

ふりかえり

前回の結果

• 「今日の30分」とは別枠で本を読む。
  • -

今回の追加活動

前回のものを継続。及び転職関係でのいくつかの活動を実施。

#今日の30分 ログ

ツイート

Lean UX

#今日の30分 +1分。「Lean UX」183ページまで。組織に必要な変化について。コラボレーションとスピード、そして変化時の話。外注を使うとやりづらい、というのはよく聞く話。いくら成果をゴールにしたくとも、彼らは結果がゴールのビジネスだから。ここを壊せるところがあるなら強いなあ。

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

#今日の30分 +4分。「Lean UX」読了。Lean UXのケーススタディ。Paypal、CarMax、ustwo、Hello Group。こうしていくつかのケーススタディを見てみると、原則を守りつつも実装はそれぞれ違う、という印象。職能横断、成果主義、共通理解、コラボレーションが鍵となる。

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

Lean UX 第2版 ―アジャイルなチームによるプロダクト開発 (THE LEAN SERIES)

LeSS

#今日の30分 「LeSS」目次まで。いい加減LeSSをちゃんと学ばねばならないのでこの一冊。LeSSの思想、原理原則、価値観、ルールとガイドも含めた内容っぽい。意図的に不完全にしておき、現場で適応していくだけの余白を残してある。組織を簡素化し、アジャイルになっていくための出発点。

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

#今日の30分 +1分。「LeSS」目次まで。LeSSの導入と、導入にあたっての組織構造の変化について。「プロダクト」を定義する、とか気になる部分。コンポーネントチームからフィーチャーチームへ。クロスファンクションの話を聞くたびに、コアチーム以外はどういう扱いなのか気になる。

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

#今日の30分 -4分。「LeSS」流し読み173ページまで。組織、X理論Y理論、スクラムマスター、プロダクトオーナー。X理論Y理論の話は発表で何度か聞いたけれど、具体的にどういうものかはちゃんと学んでなかったな。Xは性悪説的、Yは性善説的な印象。安易にそう括るのもよくないので仮置。

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

#今日の30分 -1分。「LeSS」流し読み258ページまで。Undoneワークの考え方が気になっている。書き出しておくことで、いずれDoneの定義に含めるための話し合いの題材にできる。便利。あとPBIの分割の話がよさそう。スプリント期間内に終わらないアイテムの扱い、まだ説明できない。

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

#今日の30分 -10分。「LeSS」流し読み終わり。眠気で無理。レビューバザール、時間についても言及あるかな。複数同時に走らせると、時間が足りなくなると思うんだけど。オーバーオールレトロスペクティブは参加者の関係上、チームに対する説明責任を追うことになりそうね。

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

大規模スクラム Large-Scale Scrum(LeSS)

ふりかえり

前回の結果

• 「今日の30分」とは別枠で本を読む。
  • -

今回の追加活動

前回のものを継続。及び業務関係でのいくつかの活動を実施。

「Lean UX」172ページまでの読書ログとふりかえり #今日の30分

ツイート

Lean UX

#今日の30分 「Lean UX」112ページまで。MVPとプロトタイプについて。効果的なMVPは、核となる体験のプロトタイプ。操作可能で、少ない労力で構築可能。構築に使う時間は最小限に、そして得られる学習効果は最大に。フェーズによって効果的なものは変わってくるため、学習曲線を意識する。

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

#今日の30分 「Lean UX」125ページまで。リサーチの話。プロトタイプを作ったら、次は前提や仮説の妥当性検証を行うことになる。実際にユーザーに触ってもらい、フィードバックを受け、それを反映していく。仮説検証が継続的なループであるため、リサーチも継続的に実施される。

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

#今日の30分 -4分。「Lean UX」134ページまで。リサーチの話。プロトタイプの種類と想定されるフィードバックと、調査技法の話。ユーザーからのフィードバックは多面的。競合との比較なども含まれる。そのため、その内容は宝の山である。調査分析することで活用できるようにする。

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

#今日の30分 -3分。「Lean UX」146ページまで。Lean UXとアジャイルの共存について。前段としての歴史の話。スタッガードスプリント、デザインスプリント。スタッガードスプリント、ウォーターフォール化しそうだなー、と思っていたら案の定そう誤解されてしまったらしい。

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

#今日の30分 「Lean UX」153ページまで。デュアルトラックアジャイル、スクラムとLean UXの話。ディスカバリとデリバリという2つのトラックがあり、デリバリがディスカバリの結果を受けて実施されるものという仕組みであるため、トラックごとにチームを分けたくなりがちなんだろうな。

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

#今日の30分 -3分。「Lean UX」164ページまで。アジャイルとLean UXの共存の話し続き。スケーリング周りの話、なんとなくこれだけじゃ足りない気がしている。どうしてもチーム間のコミュニケーションパスはある程度整備が必要なんじゃないか、って思ってしまう。

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

#今日の30分 -1分。「Lean UX」172ページまで。組織に必要な変化について。組織文化、チーム編成、プロセス、UXデザイナーの役割。職能横断、課題指向、コラボレーションあたりがキーワード。偏った視点かもしれないけど、このあたりは多くの本で言われているのと同じだな。

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

Lean UX 第2版 ―アジャイルなチームによるプロダクト開発 (THE LEAN SERIES)

ふりかえり

前回の結果

• 「今日の30分」とは別枠で本を読む。
  • -

今回の追加活動

前回のものを継続。及び業務関係でのいくつかの活動を実施。

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

ツイート

Lean UX

#今日の30分 -1分。「Lean UX」27ページまで。Lean UXのプロセスの話。成果を重視することと、前提や推測、仮定から始まるという話。プロダクトを作るときには何かしらの暗黙的な前提、推測があることが多い。それを検証することから、Lean UXは始まっていく。仮説検証。

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

#今日の30分 「Lean UX」37ページまで。Lean UXのプロセスのうち、推測や仮定の宣言と、仮説の構築の話。仮説検証、って言葉をよく聞くし使うけれど、よく考えてみれば仮説をこうして構築するメソッドというか、どういうものが仮説と言えるのかは深く考えたことなかったなー。

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

#今日の30分 -1分。「Lean UX」45ページまで。仮説の構築について。仮説には4つの要素がある。ビジネス上の成果、対象ユーザー、ユーザーにとっての成果、そして効果的と思われる機能。今回はビジネス上の成果と対象ユーザーについて。AARRR、初めて知った指標だなー。

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

#今日の30分 「Lean UX」52ページまで。対象ユーザーを考えるペルソナ作り、ユーザー成果、解決策の検討、機能的仮説の構築、優先順位付け。機能は他の項目と比較して具体的であり話しやすいから、ユーザー成果とか無視してそっちの話に流れやすいってのは体感でも一致するね……。

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

#今日の30分 +2分。「Lean UX」68ページまで。コラボレーティブデザインの話。共同して仮説を作り、その仮説をどう実現するか、どう体験をデザインするかも共同する。デザイナーの役割は見た目を作ることではなく、メンバーを関わらせるファシリテーターやリーダーとなる。

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

#今日の30分 -2分。「Lean UX」82ページまで。デザインシステムについて。構成要素、価値、作成時に考慮すべきこと、含めるべきものについて。今の会社で軽く聞いていた影響もあってか、ブランドイメージの共通言語という印象が強い。サービスを運営し続ければ、いつか必要になりそう。

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

#今日の30分 +1分。「Lean UX」94ページまで。コラボレーションの改善とMVPの話。専門性を磨くことがキャリアにおいて重要であるためか、他部門他職能の人とのコラボレーションは慣れていない人が多い。そのためレトロスペクティブやワーキングアグリーメントなどで改善が必要。

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

Lean UX 第2版 ―アジャイルなチームによるプロダクト開発 (THE LEAN SERIES)

ふりかえり

前回の結果

• 「今日の30分」とは別枠で本を読む。
  • -

今回の追加活動

前回のものを継続。及び業務関係でのいくつかの活動を実施。