ここ最近、OKR(Objectives & Key Results)が話題を集めていますね。

Scrumを実践する人も、そうでない人も、組織に属している限りは、なんらかのやり方で目標を設定し、
その結果を受けて、業績評価、個人への査定を受けるのではないでしょうか。

OKRのよって運営される組織、Scrumによって生み出されるプロダクトは
どっちが欠けてもうまくいかない両輪のようなものだと、僕は考えています。

僕が所属している組織では、OKRもScrumも数年前から導入しているという状況でしたが、
そのどちらも「何かがおかしい」「どこかがおかしい」「いや、全体的におかしい」といった
どこにでもありそうな、伸びしろのある状態だったのです。

例えば、次のようなことがあったとします...
(あくまで例えばですよ、例えば)

  • OKRなのに、数値管理として、その達成度をそのまま評価に用いられている
  • チーム開発のはずなのに、OKRで定めた目標以外の全てが軽視される
  • 開発プロセスではインパクトを出している人の査定評価が高くない

そんな中、ProductOwnerの役割のProduct Managerとして、
OKRもScrumも合わせて幸せになれるよう、取り組んだことをお話しできれば
と思います。

  • OKRに興味がある、導入しようとしている、導入したけどうまくいかない
  • ScrumMasterだけど、組織改善がうまくいかない
  • Product Ownerだけど、組織関連はSMに任せっぱなし/もっと任せたい
  • まっとうに評価されたい(!)

という方にぜひ、共有したいなと思っています!

 
 

Outline/Structure of the Talk

  • 発表者について
    • Product Ownerの役割がベースのProduct Manager
    • ScrumMaster経験あり
    • (やむなく)People Managerでもある
  • OKRについての基本的な概念説明
    • フォーカス
    • ストレッチゴール
    • 目標数値管理との違い
  • シーン設定 / 問題と思われた状況
    • 単なる数値管理を抜け出せないOKR
    • どこかおかしいScrumらしき何か
    • 「それOKRに持ってないんで」発言
    • アクションが実行されないふりかえり
  • 問題の原因
    • OKR=ストレッチな数値管理という誤解
    • 数値管理でない場合の評価の考え方が弱い
    • Product BacklogとOKRの関係性の浸透不足
    • Sprint ReviewとWinSessionの役割整理の不足
    • OKRで明示されない基盤業務や差し込み依頼の位置づけ整理
    • 評価を気にせず頑張り続けるいけてる仲間、それゆえに起きる失敗
  • 諦めずに改善する
    • 望ましいOKRを浸透させる
      • 仲間を見つける
      • 有識者から刺激を受ける
    • OKRは原理的に達成がかなり難しいものということを広める
      • だからこそROI最大化(小さく検証、大きくチャレンジ)
      • もともと定義されていた職能要件を活用する
    • セレモニーは、楽しい方へ持っていく
      • 目的や成果が同等以上なら、名前にこだわらない
    • 組織の内側からの状況の変化を受け止める
      • 誰だって完璧に計画できるものではない
      • 差込やトラブルは当然、発生する
    • 当たり前の改善を評価する
      • チームで働くことの価値浸透に投資する
      • 改善の積み上がりこそ、査定時の自己評価に言語化する
  • まとめ
    • OKRに興味がある方へ
      • 理解は容易、習得は困難と言われるScrumと同じくらい大変さで実現できると思います
    • 組織改善に取り組む方へ
      • マネージャーや経営者に負けない理論武装と、柔軟な段階的改善がオススメです
    • 評価されたい方へ
      • 評価指標によりますが、根本的には、自分が達成したと考える成果をどれだけ言語化できるかに寄ります
      • 成果とは、個人的な達成、チームへの影響、組織や事業へのインパクトといった観点が整理しやすいです

Learning Outcome

  • OKRでありがちな問題を理解し、とある解決ストーリーを知ることができる
  • Scrumっぽい何かが、改善していくストーリーを知ることができる
  • OKRであれ、他の管理手法であれ、一般的により評価される成果とは何かを理解できる
  • 組織問題に悩むScrumMasterにとって「こんなPOもいましたよ」というネタになる
  • 今後の活動に向けて、ちょっとだけ勇気がもてる

Target Audience

OKRに興味がある方、導入したがうまくいかない方。「組織改善に参画せねばいけない」という意識がある方。Scrumにおける評価や査定のあり方を学びたい方。

Prerequisites for Attendees

  • Scrumを理解している
  • OKRについて、さらっとは知っている
schedule Submitted 1 year ago

  • Koji Shimada
    keyboard_arrow_down

    Koji Shimada - 招待講演「Agile Sapporo: Learn from experience and continue to repair wholeness」

    Koji Shimada
    Koji Shimada
    CEO
    Enishi Tech Inc.
    schedule 6 months ago
    Sold Out!
    60 Mins
    Presentation
    Beginner

    スクラムフェス札幌2020、開催おめでとうございます。

    オンライン開催ではありますが、こうして札幌という場所に各所からさまざまな方が訪れ、交流する機会が生まれること、とても嬉しく感じています。また、そうした場に招待講演という形で参加する機会をいただけたことも、とても光栄に感じています。

    以前に運営の方とお話しした際、札幌でこうしたイベントに参加される方の中には、スクラムを始めてみたけれど、うまくいかずに困っている現場の方や正解が分からなくて悩んでいる方がいらっしゃるという話を伺いました。

    うまくいかなかったということが分かったっていうのは、実はとても良いことですよね。分からなかったら次を始められないですが、うまくいかないことが分かったのなら、それを踏まえて次を始められるんですから。ぼく自身も、そうやって何度もわからないことを分かって、少しずつ今日まで歩んできました。

    このトークでは、そうやって札幌で10年、ソフトウェア開発の会社を続けながら私なりに学んできた、大事だと思う4つのことについてお伝えできればと思います。

  • Kazutaka Matsusaki
    keyboard_arrow_down

    Kazutaka Matsusaki - アジャイルな組織を創っていくには?地銀で取り組むアジャイルな組織創り

    20 Mins
    Talk
    Beginner

    Reginal Scrum Gathering Tokyo 2020 にて講演させていただいた内容の再講になります。
    ぎゅっと圧縮してお話しさせていただきます。


    ふくおかフィナンシャルグループ(FFG)では、2018年4月、DevOps・アジャイル開発を実践していくための組織が立ち上がりました。
    昨今厳しいと言われる銀行業界でイノベーションを起こしていくための組織です。

    2018年5月にゲーム会社から銀行へと異色の転職で入社以降、このアジャイル開発チームに携わってきました。

    古くからある大きな企業でのアジャイル開発を進めていくには、技術的な面・組織的な面で非常に多くの問題が存在していました。
    そもそも外注開発しかしたことのない組織が内製開発に取り組むということで、その問題の大きさは想像に難くないでしょう。
    実際、前職とはかけ離れた環境やフローが存在し、多くのカルチャーショックにぶちあたってきました。

    このセッションでは、そんな組織の中で、ゼロからアジャイル開発を進めてきた1年半の歴史を余すことなく紹介していきたいと思います。
    取り組んできたこと、失敗したこと、成功したこと、たくさんあります。
    地銀という古い体制の組織・規制の厳しい金融業界、そんな世界で経験してきた内容が、少しでもみなさんの今後に役立つことができれば幸いです。

    • アジャイル組織の変遷
    • 現行ルールのしがらみとの闘い
    • アジャイル開発を少しずつ組織に浸透させていく方法
    • 組織を拡大していくための対内・対外的な取り組み
    • 拡大していく組織で発生した問題
    • 成果を出し続けていくための組織やチームの意識改革
  • 50 Mins
    Talk
    Intermediate

    大事な活動である「ふりかえり」。だが、難しい活動でもある。

    スクラムの重要なイベントの一つである「スプリントレトロスペクティブ/ふりかえり」。
    チームを自己組織化へと導く大事なステップでもあり、スクラムの中でも一番「チームによるチームのための活動」だと言えると考えています。

    スクラムを始めたとき、多くの人が直面するのは、「ふりかえりがうまく機能しない」ということです。
    ふりかえりが反省会のようなムードになってしまう。
    チームのためのアクションが出ず、なかなかチームがまとまらない。
    アクションは出たものの、なかなかカイゼンされているように思えない。
    こういった悩みを持つ多くの現場を見てきました。

    ふりかえりは、難しい活動の一つとして考えられがちです。
    時間対費用効果が出ているのか、なかなか計測がしづらいですし、効果がすぐに現れない場合もあります。
    他のイベントと違い、ふりかえりがうまくいかなかったときに、「この活動は価値がないものだ」と感じ取られてしまいがちなのです。
    そのまま、ふりかえりが行われなくなってしまうのは、とても悲しいことです。

    ふりかえりとファシリテーション

    ですが、ふりかえりにはチームが成長するために大事な要素がたくさん詰まっています。
    そのうちの一つが「ファシリテーション」という考え方です。

    進行役としての「ファシリテーション」ではなく、促す者としてのファシリテーション。
    スクラムマスター一人がファシリテーターなのではなく、チーム全員がファシリテーター。
    チームが「ファシリテーション」を意識したとき、あなたたちのふりかえりはきっと良い方向へと変わります。

    ファシリテーションというものをあなたがどうとらえるか。
    そのとらえかたが変わると、きっと新しく見えてくるものがあるでしょう。

    COVID-19とふりかえり

    COVID-19の影響を受け、チームの姿は大きく変容しました。
    ふりかえりも、著しい影響を受けたイベントの一つです。
    ニューノーマルな世界が形成されていく中、ふりかえりはどのような姿を見せるのでしょうか。
    これまでの先人の知恵や、私たちが培ってきた経験は使えないのでしょうか?

    そこまで悲観することはありません。
    このセッションでは、昨今のオンライン環境におけるふりかえりの新しい姿と、私たちが考えるべきこともお伝えできると思います。

    このセッションについて

    このセッションでは、あなたがふりかえりの中で行うファシリテーションを考えるときの気付きを提供します。

    COVID-19で変わったチームの姿。そして、この環境下でふりかえりにおいて変わるもの、変わらないもの。
    チームの形成、そしてチームの成長。チームのグラデーション。
    ふりかえりのファシリテーションと、マインドセット。

    「自分のチームでは今どんなことを意識しながらファシリテーションしているだろうか」
    「自分のチームのふりかえりの現状はどんなものか」をイメージしながら、セッションに参加していただければ幸いです。

  • Jun Yamamoto
    keyboard_arrow_down

    Jun Yamamoto - (自称)エバッキーの愛弟子!が札幌でエンタープライズシステム開発のスクラムマスターをしてみたお話

    20 Mins
    Talk
    Beginner

    基幹系システム開発は、ウォーターフォールで着実に品質を積み重ねて行うべきもの。

    そういった固定観念が社内外充満している中、
    SoEな領域だけでなくSoRにもスクラムが適用されたプロジェクトメンバー約200名のエンタープライズ・アジャイルSIプロジェクトに
    札幌からスクラムマスターとして参画してみた顛末をセッションで共有いたします。

    特段教訓めいた話に帰結するわけでもなく、発生したさまざまな出来事を通し、
    札幌のエンジニア達がLeSSに近しい姿をトライ&エラーしていく
    天竺への道程(現在進行形)を等身大で聞いていただければと思います。

    • アジャイルやスクラムも知らずに集められたメンバーの戸惑い。
    • 複数拠点横断スタッフとのリモートワークによるチーミング。
    • クライアントとのカルチャーギャップ。
    • 自分自身含めたメンバーのマインドセットの成長。
    • などなど・・・

  • Yasushi Hagai
    keyboard_arrow_down

    Yasushi Hagai / Stefan Nüsperling - 未経験者中心のチームとベテラン中心チーム、Management 3.0のプラクティスはどう作用したのか?

    75 Mins
    Workshop
    Beginner

    まだ”色”がついていない若手未経験者中心のチーム。『いままでやってきたやり方』そもそもが無いのでなんでも受け入れるが、主体的に「こうしよう」と動けるだけの経験・知識はまだ無い。

    一方、『今までやってきたやり方』の蓄積はたっぷりのベテラン勢中心チーム。打っても響かない感があったが、果たして本当にそうなのか?
     
    使ってみたManagement 3.0のプラクティス
    • Kudo Wall
    • Celebration Grid
    • Moving Motivators
    • Delegation Poker
    • Competency Matrix
    はそれぞれのチームにどう作用したのか。
    役に立ったのか?、役に立たなかったのか?、チームはどう変わってきたのか?
    現場での事例、仕掛けた側とチームそれぞれにどのような学びがあったかを話します。
     
    そして、Management3.0を日本で展開する、NüWORKS のStefan Nüsperlingさんといっしょに、簡単なManagement 3.0の紹介、Management 3.0のプラクティスである
    • ムービングモチベーター
    • デリゲーションポーカー
    のワークショップを行います。
    ムービングもチベーターは、「10の本質的なモチベーション」のカードを用いて、モチベーションの源泉、価値観を表明し合うツールです。デリゲーションポーカーとは、7枚のカードを用いて、意思決定領域ごとの認識をマネージャーとメンバーとですり合わせながら権限委譲レベルを決めるというツールです。羽飼がやってみたところ、『意外』も『納得』もあり、とても興味深い結果が得られました。是非体験していただきたいです。
     
     
    Management 3.0 は、オランダ出身のヨーガン・アペロ(Jurgen Appelo)が作ったアジャイルリーダーシップ概念です。
    「人ではなく、システムをマネージするべき」というアイディアに基づいています。
  • Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui - Happy Lucky XP ― ケント・ベックに教わったこと

    Tsutomu Yasui
    Tsutomu Yasui
    Consultant
    self-employed
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    “I do not love the bright sword for its sharpness, nor the arrow for its swiftness, nor the warrior for his glory. I love only that which they defend.”

    ― J.R.R. Tolkien, The Two Towers

    スクラムのイベントなので、エクストリームプログラミングの話をしたいなと思いました。

    私が最初にアジャイルに触れたのは、2000年頃、XPの記事や書籍、さらにXPを導入したプロジェクトにプログラマーとして参画したときでした。まだアジャイルという言葉はありませんでした。ペーペーのSIerプログラマーだった私はXPと遭遇して、プログラマーがさらに大好きになり、同時にただプログラミングが好きなプログラマーではいられなくなりました。プログラミングは趣味も含めて10年以上、フルタイムジョブとしては2年目くらいという、XPに触れたタイミングは幸運でした。

    XPはプログラマーの仕事を楽しくし、人生を幸せにします。プログラマーは指示通りに手を動かす歯車ではなく、創造性と専門知識を持った一個の人間です。同時に、プログラマーは安穏としてプログラムを書いてるだけでは済まず、顧客やその他すべての職種の人とコミュニケーションし、協力して、やるべきことをしなければなりません。プログラマーはプログラマーだから愛されるのではなく、生み出す価値が故に愛されます。XPは究極(エクストリーム)なので、プログラマーは究極的に最高の仕事をします。時間不足やスキル不足に追われる代わりに、ユーザーの期待と品質のバーを最高に設定して越えていく仕事が楽しくないわけがありません。プログラミング、ものづくりという仕事の意味をXPに塗り替えられた私は幸運でした。

    2000年に発行された『XP エクストリーム・プログラミング入門』(第1版)を見返すと、XPのユニークなプラクティスとして紹介されているものがいかに当たり前になっているかに驚かされます。テスト自動化、リファクタリング、コードの共同所有、継続的結合、シンプルな設計。当時の私にとっては、XP、Java、オブジェクト指向設計は不可分なものでした(時代背景的にも多くの人が似た状況だったのではないかと思います)。アジャイルなソフトウェア開発が発達するのと、並行して進歩する開発技術は表裏一体でした。将来当然となるプラクティスに早く触れられたのは幸運でした。

    XPは日本において(だいたい世界でも)現在に続くアジャイルのムーブメントを引き起こした先鋒であり第一の波でした。私はXPに心酔するのと同時にコミュニティに熱狂しました。アーリーアダプターの人たちがたくさん引き寄せられました(一過性ではなく、いまでもずっと活動されている方もたくさんいます)。そうした中で、コミュニティに参加したり、登壇の機会をもらったり、運営側を経験することにもなりました。人前で話をするなんてまっぴら御免と思っていた私にとって、幸運な機会がたくさんありました。

    XPはソフトウェアの作り手と使い手とを引き裂いた人工的な傷口を癒やし、全体性を取り戻す試みです。私は最初にXPに触れられて幸運でした。XPはプログラマーとして守るべき規律を示しながら、プログラマーの本来の役割は顧客やユーザーに歩み寄り、価値を生み出し続けるために一緒に働くことであるという、長く続く道にそうと知らずして進み始められたからです。オブジェクト指向設計やJavaといった技術だけを追求していたら、もしかしたら一生見つけられなかった道です。幸運だったとしか言えません。

    (上記はプロポーザル時点で考えている概要で、今後おおきく変化する可能性があります。4月になったら「XP: An East Asian smiley emoticon representing a happy face sticking out its tongue.」みたいな話になってる可能性もあります。悪しからずご了承ください)

  • Mizuki Kusakabe
    keyboard_arrow_down

    Mizuki Kusakabe - ゼロからつくったリモートスクラムチームはスクラムに挫折し解散しました

    20 Mins
    Talk
    Beginner

    「ゼロからつくる!リモートスクラムチーム」からタイトルを変更しました。

    プロポーザルを出した時点では以下のようなことをお話しするつもりでした。

    小さなベンチャー企業にて、新規自社プロダクトを作ることになりました。

    会社として作りたいものはあり、期日もありますが、メンバーがアサインされるわけでもなく、だれかが号令をかけるわけでもありませんでした。

    その状況から、

    • いちエンジニアがチームを立ち上げてプロジェクトを始動させた話
    • 他拠点・多国籍チームが立ち上がり、みんなでスクラムの勉強から始めてスプリントを回し始めた話
    • リモートでもチームとしてワークするために試行錯誤している話

    をお伝えしたいです。

    それから半年ほど経った今、このチームはすでに解散しています。目指していたマイルストンは達成できませんでした。

    でも、一部メンバーによってプロジェクトは推進されています。

    チームを立ち上げ、スクラムマスターとしてスクラムを実践してみたこと、スクラムに挫折したこと、チームの解散、その後のメンバーの頑張り、私たちにできたこととできなかったことを、ひとつの経験としてお話しします。

  • Yoh Nakamura
    keyboard_arrow_down

    Yoh Nakamura - これまでと違うやり方に取り組む時にうまくいくかもしれない方法とその落とし穴

    20 Mins
    Talk
    Beginner

    これまでのやり方に比べて、よりよさそうなやり方に変えてみるには知識と勇気、そして作戦が必要です。
    またそのようなことを進める中で様々な壁にぶつかります。

    このセッションでは自分がこれまでの様々な状況(※)で自分がどのように考え、やってみたこと、その時には越えることができなかった壁のこと、そこから得たことなどをお話します。

    ※様々な状況

    • SIerの客先常駐の現場
    • SIerのチームリーダー
    • 事業会社のマネージャー
    • アジャイルコーチ
  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - It dependsから脱却するスクラム

    50 Mins
    Talk
    Intermediate

    チーム、組織、会社、役割、契約、業種・・・
    私たちの仕事にはいろんな状況があるので、つい、
    「It depends(ケースバイケースだね)」
    と言いたくなってしまうときがあります。

    しかし、私たちがアジャイル開発やスクラムからヒントを得て成し遂げようとしているのは、そのいろんな状況の中で「It depends」ではない答えを出すことです。

    こんにちは!

    こんにちは、及部です。

    私は、2009年に楽天に新卒入社し、アプリケーションエンジニアとしてプロダクト開発の仕事に携わってきました。その中でもっとよいプロダクトをよいチームで作りたいと思い、スクラムやモブプログラミングを学んで、実践してきました。そして2019年には、チームFA宣言からのチーム転職をして現職であるデンソーでエンジニアとして働いています。

    組織上の役割やプロダクトのドメインや会社が変わっても、「よいプロダクトをよいチームで作りたい」という想いは変わりませんでした。コードを書くだけではなく、チームにもプロダクトにも言い訳をしない自分を、そしてチームを目指して試行錯誤してきました。

    伝えたいこと

    教科書にあるスクラムとは違うかもしれないけれど、プロダクト開発のいろんな状況において言い訳をしないために、どのように考えてどのようにチームを実装してきたのかお伝えしたいと思います。

    つい言い訳したくなってしまう人やスクラムをやっていても「これでいいんだっけ?」と悩んでいる人に、少しでも勇気と元気を与えて、行動のヒントを与えられるような時間にしたいです。

    それでは、スクラムフェス札幌大会でお会いしましょう。アディオス!

  • Tadahiro Yasuda
    keyboard_arrow_down

    Tadahiro Yasuda - 日本にJoy,Incを創る!どん底からスタートしたぼくらのジョイインクジャーニー7年間の軌跡 Scrum Fest Sapporo特別編

    Tadahiro Yasuda
    Tadahiro Yasuda
    CEO
    Creationline,Inc.
    schedule 1 year ago
    Sold Out!
    50 Mins
    Talk
    Beginner

    会社の文化(カルチャー)変革の7年間の軌跡。

    2013年ごろ、色々な問題が噴出し、会社としても個人(経営者)としてもどん底の状態でした。
    そこから、色々な取り組みを行い、少しづつ会社の状態がよくなり素晴らしいメンバーにも恵まれ、会社の良い文化(カルチャー)が形成されるようになりました。

    その過程のなかで2017年8月「Joy,Inc.」に出会いました。
    「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
    この本に共感しぼくらもこんな会社に成りたい!と決意。それまでの会社の文化を良くするための取り組みを更に推進していきました。

    会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

    今回はScrum Fest Sapporo特別編として
    1.コロナ禍によって全社リモートワークになり発生したメンバー間のコミュニケーションの減少という課題とそれを解決するために行っていること
    2.Menlo Innovations の現在の状況
    についてもお話したいと思います。

    https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11835/joyinc3

  • Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi / Ayumi HOSOZAWA / Toshiharu Akimoto - プロダクト生存戦略 : スクラムギャザリング東京の10年から学ぶ

    30 Mins
    Talk
    Advanced

    なかなか東京だと実現できない実行委員やスタッフや参加者の方のふりかえりを通じて、東京のRSGTで何が起こっていて、どう思って運営していて、これまでどんな事件があったか、みたいなのを話し合ってみたいです。

    実行委員やスタッフで参加される方、共同登壇者に名前を連ねませんか?2-3人でできればと思います。実行委員で東京のスタッフをされた方にも声掛けしたいです。

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori / Jean-Baptiste Vasseur / Kenta Sasa - スクラムの理解を深めるスクラムショーワークショップ

    75 Mins
    Workshop
    Beginner

    スクラムショーワークショップは、スクラムの説明をショー(寸劇)形式で行うワークショップです。
    このワークショップを通じて、参加者はスクラムの基本を体験・学習できます。

    スクラムショーワークショップは、yycr2019(アジャイルコーチとスクラムマスターの宴、通称:よなよなコーチングリトリート)
    生み出されたワークショップです。「短い時間でアジャイルを知るようにしてほしい」というニーズに応えるために、最大2時間でアジャイル・スクラムの理解を高められるワークショップをみんなで作りました。
    会社の中で展開するために、できるだけ準備が少なく済ませたいという要望にも応えています。

    最小100分間のワークショップで、スクラムの動きを身に着けられるほか、
    皆さん自身で、スクラムショーワークショップを実践できるようになります。

    紹介動画はこちらから!

    詳細はこちらの記事をご参照ください。

  • Ikuo Suyama
    keyboard_arrow_down

    Ikuo Suyama - 続・見積りしないスクラム / #NoEstimates Scrum Season2

    Ikuo Suyama
    Ikuo Suyama
    Engineer
    CyberAgent
    schedule 1 year ago
    Sold Out!
    50 Mins
    Talk
    Advanced

    はじめに

    本セッションはRSGT2020にてご好評いただきました「見積りしないスクラム」の続編となります。

    見積りをせず、どうやってスクラムを実践するのか。RSGT2020では、我々の方法論とその背景にある理論を紹介させていただきました。
    本セッションでは、それらHOWの部分に加え、時間の都合上ご紹介できなかった「見積りしない開発」にたどり着くまでの経緯や、
    見積りをやめてから起こった問題やその対処についてもご紹介します。

    また、現在我々のチームでは、書き入れ時である年度末に向けて、並列で走る納期駆動の小さなプロジェクトをこなしています。
    以前は「見積りしない開発」は向いていないと考えていた「納期優先」な状況でも、見積りをすることなく納期を守っています。
    この状況で考えたことや、納期駆動の状況でアップデートされた方法論についてもお伝えできればと思います。

    Introduction

    本セッションは「見積りは不要なのでやめよう」と一律に提案するものでは ありません。
    アジャイル開発における見積りについては「アジャイルな見積りと計画づくり(AEP)」という素晴らしい書籍でその有用性や有効な実践方法が示されており、私自身もその有用性について同意しています。

    しかしながら、見積りには負の側面があることもまた事実であるように思われます。
    RSGT 2019 Key Note において、 Chris Lucian(@christophlucian) 氏は見積りのコストについて言及し、 #NoEstimates のコンセプトを紹介しました。

    そもそも、なぜ見積りが必要なのでしょうか?

    そして、本当に必要なものは見積りなのでしょうか。

    この問を繰り返すうち、私達は「ほんとうに必要なものは見積りではなく、意思決定ではないか?」という仮説にたどり着きました。
    それから、見積りの負の側面と向き合い、「見積り」をせず「意思決定」をする方法を模索し始めます。
    以来、半年以上をかけて実験を繰り返し、時には失敗もし、今のプロセスをすこしづつ作り上げてきました。

    この私達のプロセスでは、モブプログラミングが鍵となっています。

    本セッションでは、私達がどのように見積りをせず開発をしているのか、その方法論を紹介するとともに、
    見積りをやめたチームの事例を紹介し、ソフトウェア開発、特にスクラムにおいての見積りのあり方の議論の一助となることを目的とします。

    見積りの負の側面と価値

    見積りの負の側面について、私達の考えをまとめます。
    私達が考える見積りの負の側面は、以下の「3M」に集約されます。

    • 数値化による「コミット圧力」… 納期の「ムリ」
    • 数値化による「仕事量の最大化」 … 仕事の「ムダ」
    • 数値化による「正確であるという錯覚」 … 精度の「ムラ」

    そしてこれらは、見積りを「数値化すること」により発生すると考えています。

    もちろん、見積りは負の側面ばかりではありません。
    見積りの価値について、見積りがなぜ必要なのか、という問いについて、AEPに完結に記されています。

    見積りと計画づくりは、期日やスケジュールを決定するためだけのものではない。
    計画づくりとは価値の探求なのだ。
    – アジャイルな見積りと計画づくり

    見積りだけでなく、価値の探求のための「計画づくり」をせよ、とあり、
    見積もり自体ではなく、この「計画づくり」に必要な判断材料として見積もりが必要であると考えられます。

    これらの考察から、私達は「#NoEstimates / 見積りしない」開発を

    見積りの負の側面の根源である「数値化」を行わず、
    見積りから取り出したい「価値」を抽出する手法

    と定義づけています。

    スクラムと見積り

    私達はスクラムを実践しています。

    見積りを行わなくても、スクラムは成立するのか。あるいはこれはスクラムと呼べるのか。
    見積りをやめて以来、ずっと問い続けてきました。

    スクラムガイドには「見積り」という言葉が9回登場します。
    それぞれを分類すると、スクラムにおける見積りは以下の意思決定を行うための情報であると考えられます。

    • リリース計画づくり … PBIの優先順位付け
    • スプリント計画づくり … スプリントのキャパシティを測り、コミットメントを高める
    • 進捗管理 … 残作業を確認し、計画を更新する

    見積り自体を行うことなく、これらの意思決定をするための情報を抽出することでスクラムを行う。
    これが私達のたどり着いた答えです。

    我々は、以下の方法でこの意思決定を行っています。

    • 優先順位付け / バックログリファインメント
      • PBIのサイジング … 直近のPBIを 1スプリント以下のサイズ に調整
      • C3D(Cost of Delay Divided by Duration)
    • キャパシティ / スプリントプランニング
      • PBIのスループット
      • スプリントゴール
    • 進捗管理 / デイリースクラム
      • SBIのスループット
      • モンテカルロ法 … 過去データからの ‘予測’
    • スプリント(開発作業)
      • モブプロ
        • WIP制限 … 安定性・予測可能性の向上

    「見積しない」 開発と現実

    このプロセスは教科書上の理論だけの話ではなく、現実のプロダクト開発で行われています。
    通常のソフトウェア開発と異なり、「見積りしない」ことが現実のソフトウェア開発にどのような影響を与えるのかについて、私達の事例をご紹介します。

    • 「見積りしない」の始め方
      • どのように上司を、ビジネスを巻き込むのか?
    • 「見積りしない」計画づくり
      • どのように先の見通しを立てるのか?
    • 「見積りしない」開発の課題
      • 見積りをやめてから、チームに降りかかる課題と対応
    • 「見積りしない」で納期を守る
      • 納期が設定された小さなプロジェクトが複数件並行で走る状況で、見積りせず納期を守るには?

    まとめ

    Joshua Kerievsky はAgile2016 の基調講演「Modern Agile」において、アジャイルプラクティスは「補助輪」であると表現しました。
    見積りは今、ソフトウェア開発の「補助輪」といえる段階に差し掛かっているのではないでしょうか。

    私達のプロセスは完成されたものではなく、日々実験と失敗を繰り返して進化しているものです。

    AEPから10年、「見積りはソフトウェア開発において必須」という考え方もまた固定概念なのかもしれません。
    我々の実践しているソフトウェア開発の形について紹介し、議論できればと思います。

  • Tsutomu Yasui
    Tsutomu Yasui
    Consultant
    self-employed
    schedule 1 year ago
    Sold Out!
    75 Mins
    Workshop
    Beginner

    昨年のRSGT2019などでも好評だった、心理的安全性ゲームを体験するワークショップです。

    • 心理的安全とは、気兼ねなく話せると全員が信じている状態である
    • 心理的安全がないと組織やチームとしての学びや成長が得られない
    • 心理的安全がある状態で困難な仕事に取り組んで初めて効果が上がる。ぬるま湯や仲良ししクラブが好ましいわけではない
    • 心理的安全を高めるコミュニケーションのやり方を自分たちで発見する

    こうしたことを、ゲームを遊び、ふりかえりをし、解説を聞きながら理解していきます。ゲームは簡単に遊べ、時間も短く、自分の現場でやってみることもできます。

  • kyon _mm
    keyboard_arrow_down

    kyon _mm / neno neno - 道産子が上京してからスクラムを2回はじめた話

    50 Mins
    Talk
    Beginner

    北海道でそだち上京、23歳で組織初のスクラム導入。転職してなんちゃってアジャイルだと数年たってから気付いてスクラムの再導入。どちらも期待と不安がいりまじった時間をすごしましたが、とても楽しい時間になりました。私が当時どのようにスクラムを導入したり、変化させていったのか。そしていまならどうやるのかという考察をお話します。

  • Stefan Nüsperling
    keyboard_arrow_down

    Stefan Nüsperling - DRAW! Graphic Recording/Facilitation for ANYONE グラフィックレコーディング&ファシリテーション

    45 Mins
    Workshop
    Beginner

    Drawing is FUN, ENERGIZING and easy to REMEMBER.

    And ... ANYONE can draw!!!

    In this workshop you will learn how to spice up your meetings, workshops or retrospective with engaging visuals.

    You will create something like the picture below.

    絵は楽しく、活気があり、覚えやすい。

    そして、誰でも描くことができます!!!

    このワークショップでは、グラフィックレコーディングを通して、その魅力と人を惹きつけるコツ、会議やワークショップ、ふりかえりを盛り上げる方法をお伝えします。

    このようなグラフィックレコーディングを描きます:

  • Stefan Nüsperling
    keyboard_arrow_down

    Stefan Nüsperling / Yasuyuki Kashima - リーン・チェンジマネジメント - チーム・組織に変化を起こす!オリジナルのチェンジ・フレームワークを構築する方法

    75 Mins
    Workshop
    Intermediate
    • 組織にアジャイルを導入するこに関わっていますか?
    • 変化(変革)をスタートするときに押さえておくべきポイントとは?
    • 変化(変革)に対する「人」と「要因」の適切な対応と考え方
    • 変化(変革)を「見える化」する
    • 全員で同じ方向に向かっていくために必要なこと

    あなたが組織の変化・変革に関わり、チェンジ・プログラムを開発、実行するためのより効果的な方法を探しているのであれば、リーン・チェンジエージェントになりましょう!リーン・チェンジエージェントとして、あなた自身のチェンジ・フレームワークを構築する方法や、変化の影響を受けるステークホルダーからどう支持してもらえるかを様々な視点から考え学びます。

    このセッションでは前半にManagement 3.0の「Change Management(チェンジマネジメント・ゲーム)」を行う予定です。後半はグループでチェンジ・キャンバスを作成します。ディスカッションを通して変化(変革)への戦略を考えていきます。キャンバスから見えてくる変化(変革)への課題とどう向き合い実践していくかを学び、リーン・チェンジマネジメントを体験してください。

  • Yukio Okajima
    keyboard_arrow_down

    Yukio Okajima - 【特別編】総売り上げ35,400円だったPOが挽回するためにやったこと

    20 Mins
    Talk
    Intermediate

    永和システムマネジメントはソフトウェアの受託開発を生業にしていて、私もその最前線で25年やってきました。 そんな私が企画し、プロダクトオーナーとして関わった自社Webサービスが、数か月前にひっそりと終了しました。

    その後、ビジネスのオーナーがすべきことは何なんだろう?個人と組織のより良い関係性は?といったことを徹底的に考えて行動を改善し、結果的に「Agile Studio Fukui」というアジャイル専門組織のオーナーへとピボットしました。

    その過程では、RSGT2020でお話させてもらったようなメンタルモデルの変革も行いましたが、もちろん、それだけではありません。今回の【特別編】では、挽回に向けて取った戦略と具体的な行動、またそれらに影響を与えてくれた考え方についてお話をさせてください。

  • Yoshihiko Kamata
    keyboard_arrow_down

    Yoshihiko Kamata - なんちゃってScrumからの立て直しをした話

    20 Mins
    Talk
    Beginner

    私たちのチームではかつてトップダウンでScrumが導入され、2つのチームで取り組みが始まりました。半信半疑だった私たちは熟練者にレクチャーをいただきながら試行錯誤していましたが、半年ほど経ち、1チームはScrumを止めてしまいました。残るチームも、Scrumを継続こそしていましたが、成果を出せませんでした。

    導入から約2年が経ち、チーム構成は再編され、開発プロセスの見直しも実施されました。
    今回のセッションでは、何がいけなかったのか?失敗例を交えながら、現場で何を感じ、何を考えながら改善活動に取り組んでいるのかを紹介したいと思います。

  • Cherie Marina Cheong
    keyboard_arrow_down

    Cherie Marina Cheong - 初めてのスクラムマスターが三つの国をわたるチームを一年間リードしてみた経験共有

    20 Mins
    Talk
    Beginner

    新卒で入社し、2.5年目にスクラムマスターをやらせていただきました。
    (もはや、やるしかなかったですw)

    元々リーダーシップやチームワークが好きとは言え、いきなり三つの国をわたるチームのスクラムマスターになり「えええ?!」と思いながら、あっという間に一年間のプロジェクトを過ごしてきました。

    国における違いの上、20人近くのチームに様々な国籍を持ち、
    人間って本当に面白いなーと思わせてくれた一年でした。
    「えええ?!」と思った瞬間が数えきれなくなったり
    これまで勉強してきたスクラムやアジャイルの原理を違反しまくったりしたけど
    「出来ないこと」ではなくて「出来ること」に集中して
    常に改善を求めることが完璧なプロセスを完璧に適応するより大事だと気が付きました。

    自分の経験はまだまだ浅いかもしれませんが、それに関わらず
    非常に濃くてユニークな一年を過ごしてきましたので
    苦労したこと、うまく行った・行かなかったこと、次回やりたいこと、
    全てオープンに話たいと思います!

help