スクラム研修で学んだこと

この記事の概要

今月から事業部で大々的なスクラム開発が始まりました。
導入の前にまずはインプットということで、外部講師の方からみっちり「スクラムとはなんぞや？」を教えて頂きました。
今日の記事は学んだことを整理した内容です。

スクラム開発が生まれたビジネス的な時代背景

【昔】大量生産時代

• マーケット: XXが枯渇している時代
• KPI: アウトプットの量、薄利多売が成立していた

【現代】マーケットディスカバリー時代

• マーケット: かゆいところに手を届かせたい時代、競合と競合のすきまを探す時代
• KPI: 品質、面倒なことを解消してくれる度合い、ROIを高める・コントロールする

【今】マーケットクリエイト時代

• マーケット: 情報が入りやすい時代、新しく生み出す時代
• KPI: 他にないものを生み出す、ROIを高める・コントロールする

ROI

• return on investment (投資した資本に対して得られた利益のこと)

ROIを高めるときの注意点

• 結果を判断するための材料と高めるための材料は全く異なる
• なぜ、いつ、それに投資するのか？が重要

スクラムとは

プロジェクトの現状を把握するためのフレームワーク

• 現状を把握するのはとてもむずかしい
  • 把握するものが多い
  • 状況は刻一刻と変化する
• 性悪説の観点でルールが定まっている
• スクラムがフォーカスしているのは、investmentをコントロールするために必要な情報を収集するためのフレームワーク
• 🙅returnを高めるためのものではない🙅

スクラムの組織体制

中央集権型組織は今のマーケット時代にそぐわない

• メリット: 統制を取れる
• デメリット: 意志判断が遅い・情報が古い、不適切になることがある
  • 刻一刻と状況が変わる今のマーケット時代にとって、このデメリットは致命的な影響をプロダクトに及ぼす

スクラムではTeam Based Organization (チーム中心型組織)を採用している

• 第二次世界大戦のときにアメリカの人たちが使った体制
• マーケットの市場変化を察知してゴールを変える権利を持つ人たち(Product Owner)、ゴールまで最短で推進する権利を持つ人たち(Teams)で分ける
• Product OwnerとTeamsの間には上下関係はない
• 会社は中央集権型が当たり前
• 中央集権型の中で、どのようにチーム中心型組織を作っていくのか？を考える必要がある

Product OwnerとTeamsの役割

• Product Owner | ROIの最大化
• Teams | 生産性を向上

スクラムでは結果主義、手段はなんでもOK

• つまり視点を変えると | 誰もが同じアウトプットになるように結果の定義を明確に、HOWは人に任せる

スクラムの考え方

• 他の人が1時間かかる仕事を5分にするにはどうすればいいのか？
• 様々なHOWについて寛容になる | 「経験上、XXの方が早く終わると思う」という価値観を捨てる

演習

2分間で60歩歩くプロジェクトを実践

• 作業者に適宜歩き方を管理者として指示してみる => まるで歩けなくなることが判明
• 何が問題だったのか？
  • 作業者の気持ち | なんでこのタイミングで？「止まれ」「右」というの？的確な指示を出してよ！
  • 管理者の気持ち | なんでこの指示でそうなるの？「右」といったら90度でしょ。

「やり方について口を出すのはやめよう」という考え方がスクラムでは大事

• 口を出さないでプロジェクトが危機になったら？
  • みんなで仕事を進めていく中で、「気にしている」ことを言い合って、ケアしていけばいい
  • やり方を指摘しない
• バウンダリーを明確にすることがファシリテーリングに最も重要
  • はみ出てはいけないラインを明確にする

質疑応答

ゴールはどう置けばいいのか？

• ゴールがどんなものであるかというよりも、「なぜ？」を明確にしたり、チームに合った粒度にするのが大事

結果の評価は？

• 速度と360度評価(チーム間でお互いに高めていく)

Product Ownerのあり方とは？

• Product OwnerはROIの影響するかどうかのみ見る、優先順位の「判断基準」を伝える
• Product BacklogやSprint BacklogはTeamがやる(Howだから)、「判断基準」を元に優先順位を付ける
• 中間コストを減らすこと、「判断基準」を適切に伝えられることが大事

技術品質とDONE

品質には、製品品質と技術品質の2つがある

• 製品品質 | マーケットが対価や価値を検証するモノ
  • 単体として担保、ユニーク性
• 技術品質 | サービス提供者として担保しなければならないモノ
  • 社として担保、効率化
• いくら癌にならないことが保証されていても、ユニーク性はない
• しかし、癌になる可能性があればユニーク性がいくらあっても買ってもらえない
  • 技術品質が担保されていないと、ユニーク性はマーケットに受け入れてもらえない
• マーケットの流動性を考えると、製品品質は技術品質になることがある
• 技術品質は時代とともにどんどん増える
  • 効率化を考えないと、製品品質を考える時間がなくなる

技術品質の考え方

• 一般論で考えると良い
• 機械的に評価できるものでないといけない
• 透明性がある

DONE

• 自分たちで考えた技術品質定義
• 「私達のプロダクトは最低限、これは絶対に担保しなきゃだめですよね」というもの

スクラム開発で大事なこと

TransparencyとInspectとAdapt

• Transparency
  • その時点で正しい情報が一箇所に集められており、次の行動が誘発され続けている状態
  • 意味が理解できる状態
  • その時点で必要な情報がある
• Inspect
  • RealityからGoalまでの差分を検証する
• Adapt => 実際に実行した実績
  • 現状維持もAdaptした結果と考える
  • 「あなたは何のために行動しているんですか？」と言われて答えられる状態がAdapt

計画

• 計画を立てる力を育む
  • 様々な想定外を包括した力強い計画
• スクラムでは、想定外も踏まえた上でいくつかのプランを計画する
  • 想定外をどう取り扱うかの判断基準を考えることが先決
  • 1つのプランというのは意味がない
• スプリント ... デイリースクラム以外の時間で一人で突っ走れるのが望ましい

総括

• スクラムとは、プロジェクトの現状を把握するためのフレームワークである
• ROIでいうと、investmentをコントロールするための情報収集をするためのフレームワーク
• Product OwnerはROIの最大化、Teamsは生産性を向上させることに集中する
• スクラムで大事な意識
  • 他の人が1時間かかる仕事を5分にするにはどうすればいいのか？
  • 様々なHOWについて寛容になる | 「経験上、XXの方が早く終わると思う」という価値観を捨てる
  • やり方について口を出さない、その代わりバウンダリーを明確にする
• 製品品質は時代とともに技術品質になり、技術品質は膨れ上がる
• 「技術品質をどう効率的に担保していくのか？」がまさにinvestmentをコントロールするための要
• スクラム開発ではTransparencyとInspectとAdaptが大事
  • Transparency | その時点で正しい情報が一箇所に集められており、次の行動が誘発され続けている状態
  • Inspect | RealityとGoalとの差分が適切に評価できている状態
  • Adapt | 目的に向かって実際に実行できている状態
• 刻一刻と変化するプロダクト開発の中で大事なのは、様々な想定外が洗い出された力強い計画
  • 想定外をどう取り扱うかの判断基準が存在していれば、みんなスプリンターになれる