みんなでアジャイル読書メモ

Agile for Everibody.md

推薦の言葉

• 💭 推薦の言葉見てるとエンタープライズ感あるな。。‪
• "インパクトではなくてベロシティに注目するという役に立たないやり方"‬
  • 💭 ‪痛快な表現だ‬

はじめに

• はじめに
  • スプリントはトップダウンの新しい要求と優先順位変更によっていつも脱線したのだ
  • 💭 スクラムは現状を明らかにするためのフレームワークなので。。
• xxvii
  • サブウェイマップ

1章 「アジャイル」とは何か？　なぜ重要なのか

• p4
  • 💭 アジャイルマニフェストに触れてるのはいいね
• p5
  • リソースという言葉のない環境
  • 💭 be agile
  • 💭 XP はソーシャルチェンジ
  • 💭 ソフトウェア特性に触れて欲しい。。
• 成功指標
  • 効率性
  • ベロシティ
  • ユーザビリティ

2章 自分たちの北極星を見つける

• p22
  • 💭 SpringBootなら。。MSAなら。。みたいなのと似たようなもん
  • 💭 開発プロセスは不当に評価をされがち
  • 💭 手段の目的化、手段のプロは手段を正しく使うこと
  • ２週間周期で作業はできても、計画は2年サイクルだ

3章 顧客から始めるのがアジャイル

• p35
  • アウトプットより成果
• p36
  • 速度に焦点を合わせていて、成果の品質に焦点を合わせていない
  • 「ステークホルダーを幸せにするもの」と「顧客に価値をもたらすもの」は常に一致するわけではない
  • 💭 これはとてもいい話
• p37
  • スケジュールや予算などの企業由来のゴールで評価される個人にとって、顧客に向き合うことは気を散らすだけ
  • 日々の責任やインセンティブと整合性がなければ、顧客と向き合う仕事を避ける
  • 💭 これは最近考えてる構造の話と一緒だ！
  • UXや顧客サポートの担当者たちが、重要な決定がなされる場にいることはめったにない
  • 顧客の前に集まる
  • 💭 みんなでプロダクトを触る時間を作る取り組みとかは近いのかな
  • 💭 顧客の声を聞きすぎるリスクはあるよね
• p40
  • アウトプットの速度を速めるためではなく、価値提供の速度を速める
  • 💭 ボトムアップの限界への筆者のフラストレーションを感じる
  • 💭 本来やりたいのは ROI の最大化ですよね
• P46
  • 💭 フェンダーの UX 素晴らしいものがあるよね
• p48
  • 顧客に何が欲しいか聞くことと顧客から学ぶことは同じではない
  • 💭 フォードの話出てきた
• p50
  • どうして顧客との会話に時間を浪費するのだろう？
  • 最終的な成功を決定するのは顧客だからだ
  • "大規模な計画を、顧客を含まない２週間のチャンクに分割したところで、スプリントで仕事をしていることにはまったくならない"
  • 💭 声に出して読みたい日本語
• スプリントをうまくやるヒント
  • 顧客のフィードバックをすべてのサイクルで必須にする
  • 自分たちの「動くソフトウェア」の定義を見つける
  • 今やった仕事を捨てる覚悟をしておく
  • 細部にとらわれすぎないようにする
• 正しい答えは試行錯誤によってのみ明らかになる
• p56
  • 顧客中心の質問とは対照的な質問
  • 時間も予算も収まるか？
  • マネージャーは承認したか？
  • 企業中心の質問
• p58
  • ネガティブフィードバックを受けとる
• p59
  • 運用指標のみで計測しない

4章 早期から頻繁にコラボレーションするのがアジャイル

• p63
  • 早期から頻繁に協力しよう
  • 仕掛かり中の作業を共有しよう
  • 答えを知る前に質問しよう
• 💭 Issue 立てよう、って話
  • まず場を作ろう
• p64
  • すぐ近くにいる人としか仕事をしない人は多い
• p65
  • 仕事を台無しにするかもしれないし、手柄を横取りされるかもしれない
  • チームやサイロの外に出るのは危険性が高い
  • 💭 これも構造の話だ！
• p66
  • 💭 早い段階から頻繁に協力する話はペアプロと通じるものがある
• p67
  • 本当の機能横断チームがあれば、レポートラインは意味をなさなくなる
• 💭 文化は大事なんだけど、スキル文脈も大切にしたい
• p68
  • 評価がサイロの中や個人レベルで行われているなら、個人はその評価を求めるようになる
  • チームワークを評価しなければいけない
  • 💭 これも構造の話
• p69
  • 💭 会議は意思決定の場だよね
    • 解決したい課題
    • 選択肢
      • ProsCons みたいなテンプレはよかった
    • 事前準備はそんなになくてもいい派
• p70
  • 次の会議まで待つ必要なんてありません。
  • いつでもお互いが非公式に話せばよいのです。
  • 💭 いい話
• p71
  • 全員の合意が必要なのだろうか？
  • フィードバックがなければ、承認されたことにしてよいだろうか？
• 💭 非同期コミュニケーション、送り手が圧倒的に楽なので受け手の設計を考える必要がある
• p71
  • 10人を超えると意思疎通が難しくなる
  • 意思決定者と信頼されたリーダーはいるべき
  • コカコーラのキャンペーンプロジェクト
• 💭 同じ場所と時間（と少ない人数）という制約はコラボレーションを生みやすくするんだよね
• 💭 ‪「仕事を進めたい」じゃなくて「成果を出したい、なんだよなぁ‬
  • いや、「確実に前に進める」っていうことに執着はあるタイプなんですが
  • あぁ、「早く進めたい」じゃなくて「早く成果を出したい」ってことか
  • https://twitter.com/su_kun_1899/status/1246844462073958401?s=21
• p75
  • 「同じ場所にいる」ことと「同期して行う」ことを区別する
• p77
  • 動いているものを見つけて、サポートする
  • 動いているネットワーク同士をネットワークする
  • 💭 透明性的な話かな
• p80
  • 💭 タイムボックスもっと意識しないとダメだな。。
• p84
  • 💭 非公式なイベントに偉い人が参加するって大事だよなぁ
• p85
  • 💭 「ランチ・アンド・ラーン」面白そう
    • おいしいコーヒーの入れ方とか、素晴らしい休暇を探す方法など、業務以外の関心を共有する
• p88
  • 💭 会議の出席を任意にして誰が来るか見てみるとっていうの、エッジが効いてるけど効果高そう笑
• p90
• 💭 完成する前に共有されているか、っていうのが目安になりそう
  • 企画、仕様、デザイン、戦略、設計、etc

5章 不確実性を計画するのがアジャイル

• p93
  • 進行中のプロジェクトは、それを承認したいちばん上の人が止めない限り、止まることはない
  • 💭 やめられるのがタイムボックスのいいとこなんだがな。。
• p95
  • 「このプロジェクトを聞いた瞬間にワクワクし、ユーザーにとって素晴らしい価値が提供されると確信しているか？」
    • 💭 と尋ねてみるといいかもしれない
      • ODSCとかもいいよね
• p95
  • 組織計算では、人前で恥をかくことは、上司が承認したアイデアは間違っていると言うよりも、リスクが低いように思えてしまうのだ
• 💭 リリースはできたけれど失敗だった、みたいな話もあるあるだよね
  • 失敗したやつと悪い報告するやつの給料あげろというのはその辺にある
• p95
  • 組織が数年単位の計画サイクルを止めることはできないが、四半期ごとのビジネスレビューを追加してもらうことはできる
• p96
  • 組織の言葉を使うのが成功の秘訣 -「素晴らしいアイデアだけど、今ではない」
• p99
  • 💭 この章は「アジャイルに中長期計画はない、という誤解」を解こうとしているように読める
• p101
  • チームや組織は、絶対値で定量的に評価するのが一番簡単な実験に、不釣り合いな時間を費やす
• p102
  • 統合データ思考モデル
• p103
  • いつも数字が手に入るとは限りません。ですが、知りたかったことはわかります。
• 💭 こういう本ですら、もはやアジャイルをプロセスとして言及するんだな。。すこし悲しい
• p105
  • "自分たちがやっている作業のインパクトを理解することよりも、実際のチケットをクローズすることに重点を置いていました"
  • 「これは実際のところどう役に立つのですか？」
• p108
  • 適切な答えを持ち合わせていなければ、遠慮なく「よくわかりません。みなさんはどう思いますか？」と答えよう
  • 💭 時に自分のことを棚に上げるのって大事よね
• p110
  • ふりかえりをキャンセルしたいと思っても、その誘惑には抵抗することだ
• p112
  • チームが多少の不確実性と理解の及ばない点を抱えている
• 💭 マネージャーやスクラムマスター的な観点だと、安定と不安定のサイクルみたいなのは割と考えてる
• p113
• 💭 やめたこと、作らなかったものを評価する必要はあると思う
  • 指標にしてもよい
  • フェーズによっては「機能があること」そのものに価値がある場合もある
  • toB とか割と
• p114
  • 💭 不確実性、ワードが拡大解釈されるリスクがあるので、コミットメントとストレッチみたいな表現をするようにしてる
• p115
  • 💭 重要な情報が公式の場にならないと出てこないのは危険の兆候かも
    • Daily だったとしても

6章 3つの原則に従い、早くて柔軟で顧客第一なのがアジャイル

• p120
  • トレーニングを何時間受けても、それがなぜかを全く理解できない人がたくさんいる
  • 💭 研修の類、「問いを持っているか」で効果の差が大きい
• p122
  • 批判ではなく共感から始める
• p123
  • 組織変革の熱狂は長くても６ヶ月しか持たない
  • 💭 ３年後も同じ不満を言っていたら自分のせいだよ
• p128
  • 質問をする。プッシュではなくプルでチームを繋ぐ
• p131
  • 何も変わらないとしても、何かできる可能性はあるのじゃないか？
• p140
  • 💭 プロトタイプほどペアプロとかでやった方がいいんじゃないかなぁ
• p142
  • 💭 プレゼンテーションをあまりたとえに出さない方がいいのでは笑
• p144
  • 報酬やインセンティブの構造がアジャイルの価値観とあっていると感じるか
• p147
  • 「私たちは市場のためでなく、CEO ジェフ・ベゾスのための電話を作っていました」

7章 あなたのアジャイルプレイブック

• p161
  • "透明で勇敢であれ"
• p163
  • 💭 結局のところ、アジャイルが方法論としてのみ理解されているということなんだろうな