Whyから始めよう!スクラムチームが力強く前に進むための「なぜやるのか」を考える

皆様は、スクラムチームが走り始めるときにまずは何から始めますか?

 プロダクトバックログを作る?

 エレベーターピッチを作る?

 インセプションデッキを作る?

 とりあえず開発環境作ってみる?

 えーい!そんな暇はない!開発着手だ!!!

私が皆様におすすめしたいのは、スクラムチームのメンバーは今なぜここに集まっているのか?を問うことです。

 

ゴールデン・サークル理論という言葉を聞いたことはありますか?

TEDの人気プレゼンテーション「WHYから始めよ!」でサイモン・シネックが解説した理論です。

端的に言うと、人が真に突き動かされるのはWhat(何をやるのか)ではなくWhy(なぜやるのか)であるという内容です。

詳細はTEDの動画を見ていただきたいのですが、このWhy(なぜやるのか)こそ、スクラムチームが走り始めるときに最初にやるべきことなのではないかと思うのです。

 

実は、インセプションデッキの10の設問にも「我々はなぜここにいるのか?」という設問があるので、インセプションデッキを丁寧に作成したチームならWhy(なぜやるのか)を考える機会があるはずです。

しかし実際のところ、インセプションデッキをちゃんと作ったことがあるというチームはそれほど多くないのではないでしょうか?

インセプションデッキを作らない理由は様々ですが、そのようなことにかける時間が無いという理由が大きいのではないかと考えています。

 

そこで、Whyから始めることを私は提案します。

10の設問があるインセプションデッキに比べれば時間はかかりません。

しかし、チームの目的を設定しないまま走り始めるよりも間違いなく、チームは同じ目線・方向に向けて力強く走り始めることができるはずです。

 
 

Outline/Structure of the Talk

  • オープニング(自己紹介)
  • 問いかけ(スクラムチームを組んだらまずは何をするか)
  • Why(なぜやるのか)から始めてみることの提案
    • ゴールデン・サークルとは
    • なぜWhyが大切なのか
    • 人間の脳構造との関係
  • Whyをどうやって決めるか
    • まだ無いWhy
    • すでにあるWhy
    • Why/How/Whatで可視化
  • Whyを伝え続ける
  • Whyを追求し・改善し続ける
  • クロージング

Learning Outcome

スクラムチームを結成した際にまずは何から始めたら良いか、そのひとつの案(Whyからはじめてみる)を持ち帰っていただきます。

チームでWhy(なぜ私たちはそれをするのか)を深く理解し、そして各自が同意することで、より結束力が強い・目標に向けて力強く前進するチームになります。

Target Audience

スクラムチームの最初の一歩で、まずは何からするのがよいか悩んでいる開発者・リーダー・マネージャー

schedule Submitted 1 week ago

Public Feedback

comment Suggest improvements to the Author

  • eroccowaruico  
    keyboard_arrow_down

    eroccowaruico   - 四面楚歌からの反逆 (弱虫が生み出すイノベーションスタック)

    45 Mins
    Talk
    Beginner

    努力・忍耐。根性なんて大嫌い。
    そもそも人生の計画なんてとっくに消えた。
    周囲に溶け込めず学校や会社はもちろん、時には家族の中でも孤独を感じてしまう。
    やっとエンジニアになれたと思ったのに何に役に立っているのかわからない。
    キラキラにワクワクして出かけても、輝けない自分との違いに絶望し帰宅する。
    そんな弱虫はこの世にいる価値があるのか?
    ずっと辛いままじゃないのか?
    この世から消えていなくなりたい。
    苦しくてもがいているのに変化のない日々をただ過ごすだけ。

    でも、気がついたらこんなに長く生きている。
    完璧ではないけれど諦めていた未来の一部がここにある。
    なぜだろう。

    これを運というのだろうか?
    やっぱりただの偶然か?
    いや、それとも何か見落としていることがあるのか?
    もしそうだとしたらどこかに必然はあるのか?

    それがわかれば弱虫が弱虫のままでいいんじゃないか?
    弱虫が弱虫らしく生きることで小さなイノベーションを起こせるかもしれない。
    弱虫が弱虫らしく生きることで実は小さな成功を起こせるかもしれない。
    そんな事を考えて話してみようかと思っています。
    あと、多分今回は泣きません。

  • Ikuo Odanaka
    keyboard_arrow_down

    Ikuo Odanaka - OKRはツリーではない

    45 Mins
    Talk
    Advanced

    対話しながらチャレンジングな目標の達成に向けてドリブンしていくOKRと、検査と適応を繰り返していくスクラムチームは相性が良いものだ、と私は考えています。過去には「OKR-based Scrum Team」と題して話したこともあります。ここではOKRのツリー構造を使って組織と個人の意思をいかに伝搬させてゆくか、特に「納得」をいかに醸成していくかという点に重きを置いて話しています。

    ですが、実際に自分自身がOKRを運用している現場では、OKRを採用した2年目あたりから厳密なツリー構造というものからは脱却しています。ツリー構造にすることを重視すると、どうしても間に落ちてしまう部分が生まれてしまうというのがツリーからの逸脱のきっかけでした。同時期に「クリストファー・アレグザンダーの思考の軌跡」を読んでいたことも、ツリーを脱却しセミラティス構造に向かう直接の要因だったように思います。

    話は変わり、5月に開催された品川アジャイルのイベント「OKRってどういうのが正解なんだろう?」において、名著「Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR」を題材にOKRとはそもそも何なのか、ということを川口さんとたっぷり話す機会がありました。ここで衝撃を受けたのが、あらためてこの本を読み解いてみると「OKRはツリー構造だよ」なんてことは一言も書いていない、ということでした。それどころか、私が自ら切り開いたと思い込んでいた「ツリーではない構造のOKR」は、しっかりとここで提示されていたのです。なんということだ。

    気を取り直して。そう、OKRの分野の名著では「ツリーだ」なんていっていないわけです。けれども多くの現場はツリー構造に向かっているように思えます。
    そして「ツリー構造に落とし込むのが難しい」といった、本来悩まなくてもよい悩みを抱えてしまうことになったりする…あなたの現場はどうでしょうか。

    私自身、最初はツリー構造から出発しました。そこに窮屈さを感じセミラティス構造への転換を試み、メンバーからの意見をOKRに取り入れるよう工夫をし・・・今では、自己評価としてはうまくOKRと向き合うことができている、といえるくらいにはなりました。

    このセッションでは私自身がどのようにツリーから脱却していったのかという話と、そもそも人はなぜツリー構造に向かってしまうのかという謎を解明する試みについて話せればなと考えています。

  • Takefumi Iseki
    keyboard_arrow_down

    Takefumi Iseki - 開発にテストプロセスを融合させていく取り組み

    45 Mins
    Talk
    Beginner

    3年間開発の現場で、おもに QA として、テスト、パイプラインエンジニア、そして開発チームの PM からの雑用という立ち位置で開発チームのプロセス改善を行い、以下のような発表の機会をいただけました。

    品質はプロセス (システム) 、そしてそれを作り上げて実践していくメンバー (全員のマインド) という理念を基盤に、開発とテストが一蓮托生、同心協力でプロジェクトにあたるようなチームにしていることをお話しします。

     

  • Jumpei Ito
    keyboard_arrow_down

    Jumpei Ito - 現場の泥臭い話を「QAマネジメント」という言葉で定義してみかわ

    45 Mins
    Talk
    Beginner

    昨年のスクラムフェス三河2021では、「新米QA部門長がアジャイルな組織作りを実践してみかわ」というタイトルで、新米マネージャーのストーリーと意気込みを発表させていただきました。

    今年のスクラムフェス三河2022ではその後のマネージャーとしての取り組みについてお話ししたいと思います。

    まだまだ先は長いものの、QA部門長として色々見えてきたものや、様々なことにチャレンジして、失敗して、学んだことがあります。そして、もしかしてこれがQAマネジメント?と感じるものを、ここで一旦まとめます。

    (この一旦まとめてみるのがスクフェス三河の良さw)

     

    以下のような内容を話したいです。

    「ラインマネージャーとQAマネジメントは別物!?」

    「突然動かなくなる3rd Party。情報集めと定期的な配信」

    「自動テストにできない、定期的な手動リグレッションテストはアウトソースしよう」

    「ねぇねぇ。QAにスクラムマスターいる?もちろんいるよ!」

    「大変です!テストケース数が多すぎて自動テストが終わりません。。。」

    「来週リリースするので出荷承認お願いしますー え?」

    「POも開発エンジニアもテクニカルライターも。みんな集まれ。社内専用Janet研修」

    「QAもエンジニア。QMファンネルを使って自身のキャリアをイメージしよう」

    「もしかしてこれがQAマネジメント?QAメニュー表作れるかも!」

    「NINNOで社内ドヤリング大会」

    「社内チリング会でスクフェス視聴してYYしよう」

    「ハイヤリング×ハイヤリング」

help