伝えたいこと

プロダクトやチーム、そしてスクラムの継続性を維持するうえで、「ふりかえり」は最も重要なイベントです。

スクラムに取り組み始めると、多くのチームが失敗と学習を繰り返して自分たちなりのスクラムを定着させていくことになると思いますが、その中でポイントとなる重要なイベントがふりかえりではないでしょうか。様々な事情からいきなりスクラムに変えることができないチームも、まずはふりかえりから導入している事例をよく耳にします。

私自身もスクラム開発に取り組み始めてから、スクラムマスターとしてふりかえりをファシリテートしていく中で、「あの時のふりかえりでチームが前進した」「あの時のふりかえりでチームが新たな学びを得た」と感じたことが多々あり、ふりかえりはスクラムチームの継続性にとって重要なイベントであると実感しています。

この経験から、私が最初にスクラムに取り組んだ現場での1年間をふりかえりの切り口で改めて整理し、その後の別のチームではふりかえりを軸にチームをアジャイルにしていくことに取り組んでいます。それらの実例をご紹介するとともに、この経験を踏まえて私が考える継続性を意識したふりかえりについてお伝えします。

継続的なふりかえりとは、チームの過去・現在・未来をつなぐ支援をすることです。

  • 過去
    • チームは以前と比べて何がどのくらい変わったか
    • 以前のふりかえりでの課題がどう解決したか
  • 現在
    • チームが今一番困っていることは何か
    • このスプリントでどんなことが起きたか
  • 未来
    • プロダクトはどうなるのか
    • チームはどうしたいのか

そして、継続的なふりかえりで特に私が意識しているのは以下の3つです。

  • タイムボックス
    • 時間オーバーしたり忙しいからと言って中止したりしない
    • 継続的な状態をつくる基礎として定期的に同じリズムで実施することが大切です
  • ふりかえり以外でのふるまい
    • ふりかえりを意識してチームを観察し、支援する
    • スプリント中のいつでも、ふりかえりの価値を高める機会があります
  • 楽しむ
    • ふりかえりを楽しむ
    • 楽しくないふりかえりは継続が困難です
スクラムと私

株式会社ラクス は中小企業向けのクラウドサービスを提供し、19期連続増収で事業拡大中の会社です。私は2011年に入社し、BtoCサービスや北米向けサービスなどの新規事業の開発を経験した後、主力サービスである楽楽精算の大阪開発チームをリーダーとして立ち上げ、2018年からスクラム開発に取り組みました。スクラム開発に取り組んだことで、過去の開発経験も含めてチームが不確実性と向き合い敏捷性を高めていくことの重要性を改めて実感しました。2019年4月からは10年以上続くメール配信サービスの開発チームに異動し、マネージャとして従来型の開発プロセスを少しずつ改善してチームのアジリティを高めていくことにチャレンジしています。

 
 

Outline/Structure of the Talk

以下の3本立てでお話しする予定です。

  1. ふりかえり1年戦争
  2. ふりかえり駆動の再チャレンジ
  3. 継続的なふりかえりとは

Learning Outcome

  • ふりかえりを軸としてチームやプロダクトを継続的に前進させていくためのノウハウを得られる
  • ふりかえりを1つのステップとして少しずつチームをアジャイルにしていくためのヒントが得られる

Target Audience

スクラムを始める/続けるためにふりかえりをファシリテートしているスクラムマスター、スクラムを浸透させたいマネージャー/リーダー/スクラムマスター

Prerequisites for Attendees

  • スクラムの実践経験がある
  • ふりかえりを実践したことがある/してみたい
schedule Submitted 3 months ago

Public Feedback

comment Suggest improvements to the Speaker

  • Liked Tadahiro Yasuda
    keyboard_arrow_down

    Tadahiro Yasuda - 日本にJoy,Incを創る!ぼくらのジョイインクジャーニー3年間の軌跡

    Tadahiro Yasuda
    Tadahiro Yasuda
    CEO
    Creationline,Inc.
    schedule 4 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    2012年ごろからDevOpsを取り組んでいくなかで、会社(組織:チーム)にとって文化的なものが非常に大事だとは認識するようになっていたのですが、自社内において具体的なアクションは(忙しさにかまけて)正直出来ていませんでした。チームメンバー(社員、契約社員を含む社内で活動する方々)にある意味で依存していました。そのような状態では、当然相互のコミュニケーションに問題があり、結果として当然チームメンバー相互の充分な協力は得られていませんでした。そんな会社が、どんな取り組みをしてどんな会社(チーム)になってきたのか。
    2017年にJoy,Incに出会い、衝撃を受けぼくらもこんな会社に成りたい!と決意。それを実行してきました。会社のカルチャーを変えることはとても難しいし、時間もかかる、反発もあるかもしれない。それを覚悟したうえでのスタートでした。
    そんなぼくらのジョイインクジャーニーの3年間の軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

  • Liked Woohyeok Aaron Kim
    keyboard_arrow_down

    Woohyeok Aaron Kim - 【元士官が語る】軍隊組織からみる、これからのアジャイルのあり方

    45 Mins
    Talk
    Intermediate

     アジャイルでの大物でありScrumを考案して世界に広げた人物。ジェフ・サザーランド氏は実は、米国陸軍士官学校を卒業した元パイロットです。

    軍隊は一番入れ替わりが激しい組織です。今日入隊する人がいて、その反面退役する人もいます。退役の方が入隊より多く、総員の数がマイナスになることもあります。入れ替わる時の階級もバラバラで、一般兵士が入隊してきても、例えばベテラン士官が退役する場合もあります。

     しかし、こういう状況の中でも、全てのメンバーを即戦力に作る極限のアジリティーを発揮し、最高のパフォーマンスを保つのが軍隊の最大課題であり、存在理由でもあります。私はそこで元陸軍将校として4年間勤め、300名の部下を纏めながら、毎日戦闘力の向上のために資源管理・訓練の計画・実施などに力を入れていました。

     チーム(ないしは会社)そしてアジャイルプロセスは、軍隊と特に違いはありません。入れ替わりは激しく、生産性のために中途はもちろん新卒に対しても即戦力になれる人材を求めています。チームなど組織に対しても、一定のパフォーマンスを出すことが求められています。

    制限された状況の中でも、どうしたら常に最大のパフォーマンスが発揮できるか。

    軍隊ではどういう風にしていて、それをどうやって今のチーム・組織に活かせるか。私の経験を持ってご提案させていただきます。

  • Liked 中村 薫(Kaoru Nakamura)
    keyboard_arrow_down

    中村 薫(Kaoru Nakamura) - 10年たってやっとアジャイルがわかりかけてきた話

    中村 薫(Kaoru Nakamura)
    中村 薫(Kaoru Nakamura)
    CEO
    HoloLab Inc.
    schedule 4 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    アジャイル、XP、Scrumは10年くらい前からイベントに出たり、本を読んだり勉強しても、どうにも身につかず。

    2017年に会社を作って、2019年に自社サービスをリリースして、やっとアジャイルが腹落ちしてきた気がします。

    このセッションでは、なぜ今までアジャイルが実践できなくて、なぜ今になってアジャイルがわかりかけてきたのか、ということをお伝えできればと思います。

  • Liked Arata Fujimura
    keyboard_arrow_down

    Arata Fujimura - 最高のScrumキメた後にスケールさせようとして混乱した(してる)話

    Arata Fujimura
    Arata Fujimura
    Manager
    Classmethod, Inc.
    schedule 4 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    2018年の11月頃から始まり、開発手法としてScrumを採用したとあるプロジェクトは、2019年の6月に予定通りサービスのローンチを行うことができました。

    このプロジェクトはお客さんとのユーザーストーリーマッピングでのMVP検討から始まり、まずはサービスの背骨にあたるMVPの実装を1ヶ月で完了。その後4ヶ月間はリリースできる状態をずっと維持し続けながら、毎スプリント着実に機能を追加していき、ローンチの1ヶ月以上前にはお客さんが希望する機能の追加を完了。ローンチ前にはいくつかのメディアに取り上げられたこともあり、多少注目されながらローンチ当日を迎えましたが、そこでも拍子抜けするほどなんのトラブルも起きず、お客さんからも開発チームからも、これほど安定したプロジェクトは今まで経験したことがないといったようなポジティブなフィードバックをもらうことができました。

    その結果、お客さんからの期待値が想定以上に高まってしまい、同じやり方を他の複数プロジェクトにも早急に導入することが決定。開発者を含む関係者が一気に倍増したことで、チームは混乱状態に陥ってしまいました。

    今現在も混乱中ですが、RSGT2020が開催される頃までには何とかなってると思うので、私達がこれからどのようにして再び練度の高いチームを作り上げていったかについてお話しできればと考えています。

  • Liked Ikuo Suyama
    keyboard_arrow_down

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

    Ikuo Suyama
    Ikuo Suyama
    Engineer
    CyberAgent
    schedule 3 months ago
    Sold Out!
    20 Mins
    Talk
    Advanced

    はじめに

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

    ここで、あえて問わせていただきます。

    「あなたのチームの見積りは、どれくらい正確ですか?」

    前回の RSGT 2019 Key Note において、 Chris Lucian@christophlucian 氏は #NoEstimates のコンセプトと、見積りのコストについて言及しました。
    彼が述べたように、見積りには負の側面があることもまた認める必要があるのではないでしょうか。

    私達のチームでは、これら見積りの負の側面と見積りから得られるものを比較し、見積りすることをやめる判断をしました。
    以来、半年以上をかけて実験を繰り返し、時には失敗もし、今のプロセスをすこしづつ作り上げてきました。

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

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

    見積りの負の側面と価値 - なぜ見積りをやめたのか

    少し見積りの負の側面について触れておきます。
    私達が考える見積りの負の側面は、以下に集約されます。

    • 見積りのコスト
      • 見積りを行うためにかかる時間
      • 数値化したことによる、納期コミットの圧力
      • 数値化したことによる、仕事量の最大化(パーキンソンの法則)
    • 見積りの難しさ
      • ソフトウェア開発はそれ自体が複雑で不確実性を含む
      • 殆どの場合で経験したことがないことへの対応が必要になる
      • このため、正確な見積りを行うことが困難

    もちろん、見積りは負の側面ばかりではありません。
    しかしながら、見積りの「価値」については、見積り自体に価値があるのではなく、見積りから得られる副次的な情報に価値があると考えられます。

    • 見積りの価値
      • 見積りから得られる計画
      • 共通理解の促進
        • e.g. プランニングポーカー

    見積りから副次的に得られる価値が見積りの労力とバーターしない場合、その価値を別の方法で得られるのであれば、見積り自体をやる必要はないと考えます。

    スクラムと見積り

    タイトルの通り、私達はスクラムを実践しています。

    見積りを行わないプロセスでもスクラムは成立するのか、あるいはこれはスクラムと呼べるのか、という疑問が当然湧いてきます。

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

    • 計画づくり
      • PBIの優先順位付け
        • ROIの ‘I’ の算出に必要
      • スプリントのキャパシティを測る
    • 追跡
      • スプリントの進捗状況を把握する

    見積り自体を行うことなくこれらの意思決定をするための情報が得られるのであれば、見積りをしなくてもスクラムとして成立するのではないか、というのが今回のアイディアです。

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

    • PBIの優先順位付け(ROIの ‘I’)
      • PBIのサイジング
        • 直近2Sprint分のPBIはすべて1スプリント以下のサイズに調整
      • CD3(Cost of Delay Divided by Duration) による優先順位付け
    • スプリントキャパシティ&追跡
      • モブプロによるWIP制限
        • 安定性・予測可能性の向上
      • 過去データからの ‘予測’
        • タスクのサイクルタイムをヒストグラム化
        • タスクカウントとスループット

    まとめ

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

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

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

  • Liked Tatsuya Sato
    keyboard_arrow_down

    Tatsuya Sato - RSGT 100分ハッキング - 出張短縮版OSS Gate ワークショップ -

    Tatsuya Sato
    Tatsuya Sato
    Software Developer
    DENSO
    schedule 4 months ago
    Sold Out!
    100 Mins
    Workshop
    Beginner

    開発チームのスキルによって、開発の時に重要な要素である実行可能性(Feasibility)は大きく左右されます。価値のあるバックログアイテムが用意されても、それを実現でき、お客さんに届けることができなければ意味がありません。実現することこそが開発チームの本懐であると思います。

    現在のソフトウェア開発において、オープンソースソフトウェア(OSS)を活用することは当たり前となってきています。もちろんOSSも人が作ったソフトウェアですのでバグはありますし、期待した機能を持っていなかったりもします。では、そういった不具合や期待した機能を持っていないことに気づいた時に、どうしたらいいでしょうか?居酒屋で見つけたバグをネタにビールを飲むことでしょうか?「こんなバグがあるなんて、酷い!」「このOSSは、○○が無いのでダメだ!」などとSNSなどで投稿することでしょうか?

    残念に感じたり、時には怒りを覚えるかもしれません。ですが、それはとても素晴らしいチャンスです。そう、OSSに貢献するチャンスです。しかし、残念なことにOSSへの貢献がとても高いハードルと感じている方もいらっしゃるようです。

    ようこそ、OSS Gate ワークショップへ!
    このワークショップでは、OSSに貢献したいけど最初の一歩を踏み出せずにいる方の背中を後押しするワークを行っていただきます。終わった時には、小さいかもしれませんが、OSSへの貢献に確実な一歩を踏み出せたと思えっていただけるでしょう。そして、普段の開発で、それまでよりもOSSに対して身近に感じていただけると思います。

  • Liked 藤原大
    keyboard_arrow_down

    藤原大 / Takao Oyobe - 輝く未来を抱きしめて。アジャイルコーチ、スクラムマスター10年戦記

    45 Mins
    Talk
    Intermediate

    このセッションのプレゼンテーターの二人は、過去に同じ開発プロジェクトにおいて、アジャイル開発を経験しました。ひとりはアジャイルコーチ、スクラムマスターとして参加し、ひとりはエンジニアとして参加しました。

    そのプロジェクトは1000人を超える開発組織の中で初の「アジャイル開発を導入する」とうたったプロジェクトでした。もちろん途中、困難はありましたが、無事にプロダクトはリリースされました。

    プロジェクトが終わり、ふたりは異なる環境でスクラムマスターやアジャイルコーチの経験を積んでいきます。

    共に歩んだアジャイルプロジェクトから10年。それぞれの経験をふりかえりながら学びを確認し、今後の10年を考えるセッションです。

  • Liked 常松 祐一
    keyboard_arrow_down

    常松 祐一 - 「1プロダクトをみんなで作る」会社での大規模スクラム(LeSS)導入

    常松 祐一
    常松 祐一
    Engineering Manager
    Retty Inc.
    schedule 3 months ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    Retty株式会社は「信頼出来る友人や好みの合う人から自分にぴったりなお店を探す」グルメサービスRettyの開発・運営を行なっております。内部システムはレストランを見つけるtoC向けのWeb、スマートフォンアプリ、レストラン側が利用するtoB向け管理システムに大別できますが、会社としてたった1つの多くのユーザに利用されるサービスを手がけています。

    サービスと会社が大きくなった結果、全社でスピード感とアジリティを追求していくには開発プロセスの見直し、そして組織構造の見直しが必要だと考えるようになりました。

    本講演では1チームから始まったスクラム開発をどう広げ、LeSS(Large Scale Scrum)を採用した大規模スクラム体制に移行できたのか、具体的な課題とその対処を交えて紹介します。

  • Liked Junki Kosaka
    keyboard_arrow_down

    Junki Kosaka / Ikuo Suyama - 立ち上がれ、デベロッパー!私たちにとって大切な3つの勇気

    20 Mins
    Talk
    Intermediate
    • 「ビジネスになったアジャイルをエンジニアに取り戻せ!」

    師匠:David氏からDevOpsDays Tokyo 2019で強いメッセージを受け取った直後に臨んだ認定スクラムデベロッパー研修。エンジニアがオーナーシップを持ってプロダクトと向き合うこと、スクラムをやるためにはXPが必要であるなど、私たちは師匠から熱い想いやメッセージを受け取りました。

    これを経て、改めて『エクストリームプログラミング』(2015/6/26 Kent Beck (原著), Cynthia Andres (原著), 角 征典 (翻訳))に目を通すと、

    “XPが価値、原則、プラクティスを用意しているのは、ガイダンス、チャレンジ、説明責任を提供するためだ”

    とあり、XPは単なるプラクティス集ではなく、エンジニアは自分たちが取り組んでいることに対してちゃんと価値を理解すべきであり、それを周りの人たちに責任を持って説明していく必要性があることを強く訴えている、非常に刺激的なものであることに気づきました。

    「お客様に継続して最も高い価値を届けられるのは自分たちだ!」と自負をしながら、より高いスキルやデザインを追求出来る。

    クラムとXPを最高のチームで体現していく勇気を、今こそ分かち合いましょう!

    • 「社内なのに請負開発みたいだ・・・」

    ”ビジネス側” から言われたものを言われた納期でつくる。私達は内製のプロダクトのはずなのに、まるで請負契約のような開発をしていました。

    そこから、開発チームが少しずつ変化し、プラクティスを実践し、”ビジネス側” を巻き込み、プロダクトの価値をともに考えるチームに成長してきました。

    その変化の中で、プロダクトが価値を届けることにフォーカスし、チームの中心に据えることができたのは、師匠から学んだ価値、原則、プラクティスと、その実践の影響が多分にありました。


    もっとより良いチームになりたい。もっとより良いプロダクトを開発出来るようになりたい。そんな想いで立ち上がり、一歩ずつビジネスと向き合えるようになったチームの今をお話します。

  • Liked Arnab Gupta
    keyboard_arrow_down

    Arnab Gupta / 羽渕 彰博 - 人間には感情があることを知っていますか?アジャイル改革の盲点

    20 Mins
    Talk
    Beginner

    クライアントからアジャイルな開発体制を作って欲しいと要望される。
    アジャイルな開発体制を求めている理由を聞いていくと、「ビジネスインパクト」だという。
    今までにない新しいプロダクトが素早く創れることを期待している。

    本当にそれだけで「ビジネスインパクト」が得られるのか?
    開発部門だけでなく、新たなビジネスモデルやオペレーティングモデルを実現するためにも他部門を横断して価値を生み出さないといけないのではないか。

    そのような本質的な問いを抱いていたアジャイルコーチのGupta。
    アジャイル開発の外側で、組織変革に携わっているreborn founderのハブチン。
    呑みながら二人が対話したとき、仕組みや体制だけでなく、社員のモチベーションも重要で、ある仮説を立てた。

    仕組み×モチベーション=組織変革

    仕組みだけだと形骸化するし、
    モチベーションだけに頼ると不安定な状態になる。

    両方の要素をバランスよく組み合わせることによって、
    組織が変革し、「ビジネスインパクト」が得られるのではないか。

    それではモチベーションの正体は何なのか。
    鍵は個人のミッションの見える化にあった。
    個人のミッションとチームのミッションが重なり合ったとき、
    真のアジャイルが生まれていく。

    ハブちんとGuptaの会話で生まれた様々な気付きをこの場でシェアしたいと思っています。

  • Liked Kazuhiro Niwaya
    keyboard_arrow_down

    Kazuhiro Niwaya / Yusuke Amano - 残業まみれで属人的だったサイボウズ人事部をスクラムで改善した話  ~抜けたエースの穴をチームで乗り越えるまで~

    20 Mins
    Talk
    Beginner

    サイボウズの人事部採用チームは、
    採用計画の立案から面接の実施、合否連絡、内定者のフォロー、イベントの出展、説明会の実施といった業務を日々行っています。
    採用チームに異動してきて2年目の始めに、リーダーを引き継ぐことになりました。
    これまで経験豊富なリーダー中心に業務を進めてきた状態だったので、経験の浅い自分がリーダーになることに不安を感じていました。
    自分個人がエースの抜けた穴を埋めるのではなく、チームの皆でカバーできるような進め方をしたいと悩んでいたところ、
    開発チームで導入が進んでいたスクラムが目に止まりました。
    スクラムが人事の業務改善にも役立つと感じ、導入を決意し、2年ほどスクラムをベースにした業務改善を進めてきました。
    プランニングやふりかえりで地道な改善を重ねた結果、モブ作業やカンバンを活用が進み、メンバーの残業が減り、チームのベロシティも向上しました。
    現在はチームでタスクがコントロールでき、理想のチームに向かう良い状態が作れています。

    改善の過程で起きた問題やそこから学んだこと、チームに起きた変化を紹介したいと思います。

  • Liked Akihiro Wada
    keyboard_arrow_down

    Akihiro Wada - チーム・組織の健全性に対する嗅覚

    Akihiro Wada
    Akihiro Wada
    PM
    CyberAgent
    schedule 2 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    日々スプリントを回している中で

    「明確に課題があるわけじゃないんだけど、何か違和感を感じる」

    「仲が悪いわけじゃないんだけど、本音で話し合えているのだろうか?」

    上記のような健全ではないことを何となく感じ、そこから振り返って次の取り組みを考えたことはないでしょうか?

    私はこのように感じることを"嗅覚"に例えています。

    ではその嗅覚はどうやって身に付いたものなのでしょうか?

    アジャイルソフトウェア開発宣言の「プロセスやツールよりも個人との対話を」の背景にその答えが隠れているのではないかと考えています。

    ノンバーバルコミュニケーションにある多大な情報を紐解くことができるかどうかで"嗅覚"を感じることができるのではないでしょうか。

    理屈はいい加減身につけてきたという方々に向けて、「考えるのではなく感じる」という力とは何なのか、それをこのセッションでお話できればと思います。

  • Liked Satoshi Shibata
    keyboard_arrow_down

    Satoshi Shibata - 開発実務未経験者が気づいた、若手が成長できるスクラムの3つの視点

    20 Mins
    Talk
    Beginner

    新卒 3 年目の春、スクラムを実践している開発チームへの配属となり業務に携わっています。

    2 年目までは運用・保守の業務に携わっており、定期的に発生する運用作業・非定型な運用業務・他部署からのシステムに関する仕様回答などを担当していました。そのため、実務レベルのシステム開発経験はなく漠然としたイメージをもっているのみでした。

    ジョブローテーションにより、スクラムを実践している開発チームへ配属されるにあたり、改めて実務レベルのシステム開発とはどんなものであるかを想像してみました。真っ先に浮かぶものはやはりウォーターフォール(WF)です。
    私はWFなシステム開発に以下のようなイメージをもっています。

    • 開発前にリリースまでに決められた計画を作る(超上の人たちが決めている)
      • 担当が決まったときには工数が決まっている(焦りポイント)
    • 設計はある程度システムの知見ある人が担当する(上の人たちが決めている)
      • 将来は設計もしたいけどどうやって学べばよい? システムの知見はどうやって増やす? 実務で経験するしかないの?
    • 経験の浅い若手はテストや実装がメイン(私はココ)
      • 決められた工数で作ることを求められるし、工数に学習の時間は加味されていない・・・(焦りポイントその2)

    まとめると、WFは工程を重視した開発手法であるため、まずは実装を習得しないことには設計は出来ず、見積もり・設計・実装を横断的には経験できません。
    そのため年次を重ねないと成長出来ず、開発現場は「若手が成長しにくい環境なのでは?」と思っていました。

    本セッションでは開発実務未経験者が開発現場に対して「若手が成長しにくい環境なのでは?」と思っていた私が、スクラムを経験し「若手が成長できる環境である」と気づけた下記の3つの視点を共有します。

    1. 「計画」プランニングで見積もり、スプリント計画を自分で立てることができる。
    2. 「知識」プランニング、レトロスペクティブで機能横断的に知識が得られる。
    3. 「経験」タスク分割のおかげで小さく、色々な機能の開発に参加できる。
  • Liked Yuichiro Yamamoto
    keyboard_arrow_down

    Yuichiro Yamamoto - 共感がインクリメントの価値を高める

    Yuichiro Yamamoto
    Yuichiro Yamamoto
    ICT部 部長
    株式会社AmidA
    schedule 3 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    こんにちは。2年前に転職してEC通販/製造企業のIT部門長をしています。元アジャイルコーチだった私は早速スクラムを導入し、持ち前の鈍いマサカリと役職権限をふりかざして覇道系プロダクトオーナーとして切磋琢磨しています。

    “システムの価値は、その機能ではなく、どう使われるかで決まる”
    どこで読んだか聞いたかことか忘れましたが、私はずっと意識してきました。

    私が就いたIT部は、つぎはぎシステムの補修とそれが吐き出す壊れたデータを直すことで日々を追われていました。
    やらなければならないことが多すぎるので、できるだけ手間をかけずに要望を満たす必要があります。しかし機能を削るだけでは利用部署の不満は増します。
    私は、十分に機能するものを小さく作るために「どう使うか」に注目することにしました。そして、そのために利用部署との間に「これはいいものだ」と言える共通の認識を作りあげるよう努めてきました。

    インクリメントは何かできたかよりも、いつ・どういう形でデリバリーするのかを評価します。業務で使ってもらうのに「ちょうどよい」タイミングがあり、業務部署にそう認識してもらうための過程があります。事業部との間に共に解決するという関係性を築いて、プロダクトバックログがインクリメントに変わったときにもっとも効果的に使ってもらえるよう図るのです。

    また、成果に結びつけるにはチームメンバーの深いコミットメントも必要になります。指示をうけるだけでは「いいもの」にはなりません。
    メンバーのそれぞれの動機やスタイルを尊重したうえで、やみくもに個人の欲求を優先するのではなく、チームの目的とどう一致するかを見いだしてもらうよう工夫しています。場合によってはテストや設計の知識の甘さを問いただすこともありますが、できるだけ共同で解決して実体験から理解してもらえることを原則にしています。

    昨年のRSGT2019では、IT部が批難の的から信頼を獲得するストーリーを発表させてもらいました。いま私たちはとある次の大きなステップを目指しています。その過程として、共感をベースとした価値構築に奮闘しています。
    いま、共感に基づいたマネジメントが見直されていますが、人のためだけでなく価値を高めるために重要なファクターでもあるということ皆さんと共有できたらと思います

  • Liked Yoko Tsuruoka
    keyboard_arrow_down

    Yoko Tsuruoka / Atsushi Nagata / Iwao Harada - リスクを見える化!みんなが安心するためのアジャイルQA実践

    45 Mins
    Panel
    Beginner

    アジャイルQAで仕様をつくりこみ、開発の手戻りを減らすことができた!
    でも、もっと良い開発方法がないかを検討して実践してみています。
    その方法をみなさんと共有・議論したいと思います。

    テストコード/テストケースのメンテで苦労していませんか?
    いまこそ “もっと” QAエンジニアと共により良い開発をしましょう。
    全てをテストすることはできません。チームが一丸となりバグの重大度=リスクを把握し、狙いどころを押さえて効果のあるアジャイルを生かすテストを実現しようとしています。
    そのための方法を検討し、現場で実践してみた内容をお伝えしたいと思います。

  • Liked Yuki Nakagami
    keyboard_arrow_down

    Yuki Nakagami - インターンシップの企画から運営までスクラムで回してみた!

    20 Mins
    Talk
    Beginner

    「急にインターン来るとか言われたけど、何すりゃいいんだ?」
    「今忙しいから作業手伝ってもらおうかな。。。」
    「部門紹介とか、座談会、あとワークとかやればいいかな」
    、、、こんなインターンシップしてませんか?

    「どんな学生?」「どんな目的?」「何が成功?」分からないことが多いインターンシップは、漸進的に進めるスクラムと非常に相性が良さそうです。
    ならばインターンシップもスクラム的にやったらうまくいきそうじゃないですか?

    このセッションでは、開発以外の全てがスクラムに見えてしまう「スクラムの奴隷」がインターンシップをスクラムで成功に導いた体験談と、開発以外にスクラムを適用するためにどのように取り組めば良いかをお話しいたします。