https://amzn.asia/d/cufGoil

第2部 ステークホルダーが求めるものを作る

第5章 症状と原因

ゾンビスクラムだと…

開発者とステークホルダーの間に距離を取っている

探すべきサイン

• 実際にプロダクトを使って課題を解消したい人が、スプリントレビューに参加することはない
• 代わりに、CEOなど、プロダクトに利害関係のある組織内の人が参加している

ビジネスとITは別物と考えている

• 機能別の役割に分断すると、スクラムチームは組織の顧客やプロダクトのユーザーよりも、「内部のステークホルダー」のニーズに焦点をあてるようになる
• 「ビジネス」は本当の顧客に代わってプロダクトを購入していると勘違いし、自分たちがプロダクトの顧客であると思いこんでしまう

プロダクトオーナーが実際にプロダクトのオーナーになることを許されていない

• ゾンビスクラムでは、POはやりたいことや順番をほとんど話すことなく、要件をプロダクトバックログアイテムに変換するだけ
• スクラムガイドには「プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任をもつ」と書かれている

価値よりもアウトプットを測る

探すべきサイン

• ベロシティ、完成アイテム数などの作業量を把握するためのメトリクスを報告している
• スクラムチームのメトリクスは作業の価値を捉えたものではない。例えば、品質やパフォーマンスがどれだけ向上したか、ステークホルダーからどのように評価されたかなど
• スクラムチームは、他のチームとアウトプットを頻繁に比較されたり、もっと頑張れと言われたりする

報告させる目的は各人の効率をチューニングし、組織全体の効率を向上させること。だがこれは個人の効率が上がるにつれシステム全体の効率が上がるという前提がある。これは多くのコラボレーションを必要とする複雑な環境には当てはまらない。

複雑な環境では、個別の効率化に力を注ぐと、全体のアウトプットが減少する。
各部門が忙しくなり、コラボレーションが損なわれる

開発者はコードだけ書いてれば良い

• 開発者はコードを書く時間以外は無駄たと思っている
  -「コードを書くためにここにいる」と思ってると自分の職責以外の当事者意識が低下する

探すべきサイン

• コード書く時間ばっかりで、スクラムイベントに参加しない
• 開発者はステークホルダーと会話するために必要な社会的スキルが不足していると思われている
• 開発者の職務経歴書には技術的なことしかかかれてない

関与なくても良いと思っているステークホルダーがいる

• スクラムチームは、ステークホルダーに迷惑をかけたくないという理由で、ステークホルダーを巻き込まない場合がある。(貴重な時間を無駄にしちゃうんじゃないか、とか)

探すべきサイン

• ステークホルダーは、スプリントレビューに参加する時間をいつも確保してくれない
• 顧客は最初に要件を説明した後、開発中になぜ自分たちが関わる必要があるのかと首をかしげる

健全なスクラムの場合

• 健全なスクラムチームでは、自分たちの作業がどれだけ効果的か、つまりその作業がステークホルダーと組織にどれだけの価値を届けているかに関心をもつ

誰がステークホルダーのことを理解するべきか

• これまでの組織構造だと接点はプロダクトマネージャーか営業の人で、スクラムに切り替えると大体POがそれになる
• が、スクラムチーム全員がステークホルダーのことをよく理解する必要がある
  • POはプロダクトに必要なことと並び順を決定するためにステークホルダーと話すが、そこに開発チームも参加するべき
• POはこれから対話するはずのリストであるプロダクトバックログをつくる
• 大事なのは、開発者とステークホルダーが一緒に仕事をしたときに最高のプロダクトが生まれるということ
• POがステークホルダーと開発チームの相互作用を促進する役割を担う。スクラムチーム全員の知性を使うことで、何が必要でどの順番でやるかを明確にできる

ステークホルダーをいつ巻き込むか

1. プロダクトの目的を作成するとき
   • ステークホルダーとプロダクトを作る人達の異なる意見を集め、明確にする
   • 「このプロダクトは〇〇のために存在している」「このプロダクトは□□のために存在していない」という文章を完成させる
   • 変化するのが当然なので、定期的に見直す
2. プロダクト開発のキックオフ時
   • プロダクトを開発する人、使う人、お金を払う人、期待してる人たちの間に、コラボレーションの土台を作ること
   • パワポでの説明ではなく、相互に対話が弾むようなファシリテーションをする
   • ゲームを使ってお互いを知ったり、何を期待しているかを話し合ったり
3. スプリントレビュー
   • 一番わかり易いタイミング
   • 誰を呼べば最も価値が高められるのか、決定はPOに委ねられている
   • 話を聞いてもらうのではなく、マウスとキーボードを渡して積極的に巻き込む
   • 目的はデモしてFBを集めるだけではなく、その後に作るプロダクトバックログの内容や並び順を検査することも必要
4. プロダクトバックログリファインメント
   • リファインメントでは、大きさ作業の塊を小さな作業の塊に分割することがおおい
   • プランニング中にリファインメントもできるが、疲弊しがち。なので次スプリント分のリファインメントを前スプリントで済ませておく
   • ステークホルダーを招待したり、ニーズについてインタビューするためにステークホルダーを訪問して一緒に作業分割を行ったりすると良い

第6章 実験

ステークホルダーのニーズを知るための実験を見る

実験: ステークホルダーを知る

ステークホルダートレジャーハントを始める

• 誰が実際のステークホルダーなのかを知る必要がある
• これをすることでプロダクトに関心があるひとを見つけるのに役立つ

手順

• チームを集め次のような質問をする
  • 「私達が作っているプロダクトはなんですか？存在意義はなんですか」
  • 「このプロダクトを作るのをやめたら、何が失われますか？」
  • 「私達の貴重な時間、お金、精神力を使ってまで作る理由はなんですか？」
• その後は次の質問をしてトレジャーハントを始める
  • 「私達のプロダクトを実際に使っているのは誰ですか？」
  • 「私達のプロダクトで恩恵を受けているのは誰ですか？」
  • 「私達が解決しようとしているのは誰の問題ですか？」
  • 「この人たちをどうやって巻き込みますか？」
• これらにすぐ答えられないときは次のように聞く
  • 「何に取り組むべきか、私達に伝えてくるのは誰ですか？」
  • 「何に取り組むべきか、その人たちに伝えてくるのは誰ですか？」
  • 「その前は、どうなっていますか？」

誰がステークホルダーかわかったら、対話を始めるために他の実験を試す

発見

• ゾンビスクラムチームは、自分たちの要件がどこから来ているかを知らないことが多い。これらの質問をすると答えられないことがおおい。まずはPOに聞いて、チェーンを遡る
• ステークホルダーの中には、対話を始めれば素直に受け入れてくれる人もいるが、懐疑的でメリットを感じてくれない人もいる。開発チームとの密なコミュニケーションが、いかにステークホルダーのメリットになるかを理解してもらう方法を見つけよう

ステークホルダーとの距離を測って透明性を作り出す

手順

• ステークホルダーからの質問やフィードバックが通過(ホップ)しなければならない人、部門、役割の平均数を追跡する。ステークホルダーとは、プロダクトにお金を払ったり、使ったりしている人
  1. プロダクトバックログから、チームがやっている典型的なアイテムをいくつか選ぶ
  2. 一度に一つずつ、実際のステークホルダーと一緒にアイテムをテストするために通過すべき人、部門、役割のチェーンを描いてみる
  3. ホップごとに、そこを通過するのに何時間、何日かかるかを概算する
  4. 別のアイテムを選びそれを繰り返し、平均ホップ数とホップにかかる平均時間を出す。できれば時間とお金も。
  5. 全員の目に止まるように、大きなボードやパネルにホップ数と所要時間を書く。定期的に更新する
  6. チームが正しいことに取り組む際にどんな影響を与えているか？どれだけのお金と時間が無駄になっているか？など話す

ゾンビスクラムから回復しつつあるチームは、ステークホルダーに対する恐怖心が徐々になくなっていく。
この指標を測れば回復状況を追える

発見

• 指標はそれ自体に意味はなく、文脈と会話によって意味が与えられる。またチームの審査、比較、評価に使ってはいけない
• 距離を縮めようとすると、既存の開発プロセスを壊す必要がある。

ステークホルダーの席をスクラムチームの近くに用意する

• ステークホルダーまで距離があると巻き込まない口実になる
• ので、近くにつれてくることでチームが言い逃れできないようにする。

手順

1. ステークホルダーが気楽に仕事できる席を用意する。
2. 「スクラムチームに時間を避けるときはいつでもこの席を使ってください」と招待する。積極的に使っている or たくさん投資しているステークホルダーを招待する。
3. ステークホルダーが席にいる予定表をチームと一緒につくり、みんなの目に留まる場所に貼る。
4. 何が起こるか観察する

• 距離の近さに慣れてないと、ある種の気まずさが起こる。けどこれは自然なこと。
• すれ違いがつづくなら、チームとステークホルダーとの関係が作れそうなタイミングで両者を自然につなぐ。
• 新しいデザインや機能などの仮説を、ステークホルダーと一緒に検証するといい
• これによって何が開発を複雑にしているのか理解が深まる。

発見

• ステークホルダーの中には、スクラムチームが仕事をしている間は自分にできることはないと思う人もいる。そのときはスプリント中1,2回背負いたいし、参加を継続するか判断する
• 小さな成功を祝う前項の機会になる。ランチだけでもいこう
• 逆に、開発チームの席をステークホルダーの近くに用意してもこれは試せる。顧客のところで一緒に作業できるようにしてもいい。

オンラインだとどうするんだろう

• まずはslackに入ってもらう？
• huddleかgatherでやってれば、そこに入ってもらう
• 少なくとも出社の日だけでも来てもらうとか

プロダクトの目的に合わせてチームの部屋を飾り付ける

ゾンビスクラムチームは、「すべての作業を完成させること」「コードをたくさん書くこと」以外の目的を、何も思い出すものがない環境に現れがち。

手順

1. チームでやりたいようにやる。チームが動かない時はPOに主導権を握らせる
2. プロダクトの目的が明確でないなら、他の章の実験を使って、明確化する
3. チームの部屋に飾り付けたら、「このプロダクトバックログは、その目的にどう役立ちますか？」などの会話ができるようになる

飾る方法

• プロダクトの目的がプリントされたマグカップ
• ステッカー
• バナーにプロダクトの目的を書き、スクラムボードにはる
• ユーザーの声を掲載する
• チーム名やモットーをはる

発見

• 厳しいゾンビスクラムでは、不要だと言われることもある。レジリエントな人になろう
• 優れたプロダクトの目的は、なぜそのプロダクトがユーザーにとて重要なのかを捉えている。「このプロダクトはフレックスで働く人のタイムカードを処理するために存在する」だと不十分で、「このプロダクトはフレックスで働く人がタイムカードの入力に費やす時間と、管理職がタイムカードの確認に費やす時間を削減するために存在する」だといい

プロダクト開発にステークホルダーを巻き込む

フィードバックパーティーにステークホルダーを招待する

ユーザーサファリに行く

• ユーザーがたくさんいそうな場所を見つけて、観察する
• どんな質問をするのか、メモを取るのか、音声など記録するか決めとく
• ユーザーを圧倒しないようにペアで行動するのがベスト
• 聞き終わったら、スクラムチーム全員で気づいたことを共有する

ゲリラテスト

• 実際のユーザーや潜在的なユーザーに近づくことで、遊び心あるユーザーテストを行う
• ユーザーに会えそうな場所(コーヒーショップや公園)にいって見つける
• ペアを組んで歩き回る。ユーザーに特定の操作などをお願いし、許可があれば撮影する

実験: 価値あるものに集中しつづける

プロダクトバックログの長さを制限する

• 短く保つには、たくさんのことがキチンと整っている必要がある

手順

1. POと一緒に、プロダクトバックログがそれ以上長くなるとアイテムを捨てなければならない上限をきめる。ひと目で見ることができ、これからなにをするかがわかる数がよい。30~60アイテムを上限にするチームが多い
2. 優先度付けが必要なら、PO、チーム、ステークホルダーで協力してつける
3. POを呼んで、上限を超えたアイテムを全部捨てる。別のリストに移動ではなく、本当に捨てる。心が痛むが、することとしないことを明確にすることで、ステークホルダーの期待に対する透明性が生まれる
4. プロダクトバックログの上限を可視化する。
5. POには、プロダクトバックログに載せられるアイテムを活用するために、こまめに整理してもらう

発見

• たくさんの障害を浮かび上がらせる

  • POがプロダクトバックログに何を乗せるか口を挟めないこと
  • チームがプロダクトバックログの下の方にあるアイテムの詳細化に時間をかけすぎている
  • プロダクトに指針となる明確な目的がないこと
    など

• 捨てるアイテムを明確にしつつ、敬意を払おう。可能性を秘めたアイディアになる。もしプロダクトにとって優れたものなら、捨ててもまた現れる

第3部 早く出荷する

第7章 症状と原因

速く出荷しないのはゾンビスクラムのサイン

• ゾンビスクラムは、速く出荷することがリスクを減らすことを理解していない
• 速い出荷のメリットがわかっていても、それの阻害要因を取り除かなければいけない
  • スプリント完了後も、QAやリリース告知などの別作業が発生する
  • チームのスキルが、ボトルネックが起きるほど分散している
  • 作業の質が低すぎて、次スプリントで手直しが発生する
    など
• ゾンビスクラムでは、作業開始から出荷までのサイクルタイムに注意が払われてない

スプリントで扱うアイテムが非常に大きい

• アイテムが大きすぎて、スクラムチームが一回のスプリントで完成できない場合、残りの作業はたいてい持ち越すことになり、新しいアイテムに取り組む時間が減る
  • スプリントは出荷はおろか、実際には何も完成できない意味の無いタイムボックスであると感じるようになってしまう
• なので可能な限り小さく分割しよう。開発チームが獲得すべき重要なスキルの一つが、分割するスキルと創造性。
  • 「多くのことを学び、届けるものの価値を高めるために、構築してデプロイできる最小のものはなにか」と問う
• リファインメントがそれを身につける機会を与える。Tシャツサイズの見積もりを使うのなら、XLやXXLは分割しLやMに分割しよう

第８章 実験

継続的デリバリーに投資するための説得材料を集める

• 継続的デリバリーがないと速い出荷は難しい

手順

1. 現在のデプロイプロセスを時系列順に図示したタイムラインを作成する。「リリースノートの記述」「リリース前のテスト手順の確認」など
2. 可能であればそれぞれの手作業にかかる時間を測定する。
3. 集めたデータにもとづいて、手作業ごとの平均時間を計算して、一回のリリースにおけるすべての手作業を合計する
4. 実際のデータがあれば、バグの修正や手直しの時間も含む
5. 開発者の時給を計算する。欧米諸国では30ドル/hくらい
6. 一回のリリースにおけるすべての手作業のコストと時間がわかる
7. POと一緒に、その時間でより多くのプロダクトバックログアイテムに取り組んだとしたら、どれくらい価値を届けられたか考える
8. 自動化できるところを聞く。最も大きな効果が得られるところから自動化を始める

• リリースコストが高いと、頻度を減らそうとするのは自然な流れ。だがまとめてリリースしたとしても、変更が増えるほどリスクとコストが増える
• 手作業が必要なのに先送りされやすい

インテグレーションとデプロイ自動化への第一歩を踏み出す

• 自動化しないと手作業が増えて障壁になる

• 手動テストの手抜きに繋がりプロダクトの完全性を低下させる

• いきなり全部自動化は大変だから、自分でコントロールできるものから始める

• バリュー/エフォートキャンバスを書く。縦軸に労力、横軸に価値を書く

• そこに実現できそうな解決策をマッピングしていく

• 「時間とお金の無駄」(労力が多く、影響が小さいもの)は避け、「素早い成功」(労力が少なく、影響がおおきいもの)から始める。多い場合はドット投票で決める

• 必要に応じてこれを繰り返し、継続して自動化を進める。「素早い成功」で変化を起こせるという自信を持ち、そこから「簡単に達成できる」や「大きな成功」に挑戦していく

  

  発見

  • 「高い労力」にあるものが多くなりがちなので、最初のステップを見つけるためにもう一回やって洗練するとよい
  • 解決策を実現するために、POの協力がいる。何に最も価値があるかみてもらいつつ、参加してもらうようにしよう

完成の定義を強化する

• 完成の定義をうまく使うためには３つのステップがある
  1. 完成の定義をもつ
  2. 実際に完成の定義を使う
  3. 完成の定義を少しずつ強化し、プロにふさわしいものにする

このための手順

• 現在の完成の定義をよく理解する。現在行っていることを定義が正確に表しているか確認する。レトロスペクティブでこれを検査する
• 「スプリント後すぐにリリースするなら、高い品質を確かなものとするために完成の定義にどんなルールが必要ですか？」と質問する。スプリント後すぎにリリースできるくらい「完成」しているには、現在の定義に加えてどのようなルールが必要だろうか
• 現在の定義と、まだ守れてない定義の２つができたので、そのギャップリストの項目に取り組んでリスクを減らしていこう
• 「スプリント後すぐにリリースできるようになるための最初のステップはなんですか？」とチームに質問する。それを解決するために自動化したり人を巻き込んだりしてアクションアイテムを考える
• 次回以降のスプリントバックログに、１，２個のアクションアイテムを追加する。完成の定義とギャップリストの両方を、チームの部屋に見えるように張り出しておく。
• 「ギャップリストの項目を完成の定義に含め、関連するリスクの発生を防ぎたいのですが、なにかうまい解決策はありそうですか？」と継続的に問いかける

発見

• 大きな改善項目は、スプリント内で達成できる大きさに分割する。大きな飛躍よりも、小さな一歩を重ねる
• すでにスプリント直後にリリースできている場合は、スプリント中にここのPBIをリリースする能力を向上させる。ルールや手順の追加をチームに見当してもらう
• 改善活動がビジネスニーズにあっていることを確認する。スプリントの大部分を改善に当てるのは、スクラムチームとステークホルダー全員が同意している場合に限る