QA がスクラムマスターっぽい役割をしてみた話

開発モデルが、いまどきV字型をとっているというと驚かれるかもしれませんがスクラムどころかアジャイル開発型にもなっていない開発現場です。

このような組織では、上流から要求が出てきたものを実装しテストをしてリリースをするだけとなり、「どうしてこのような機能にしたの?」と聞かれても
「仕様書に○○と書いてあったから」というだけの説明がほとんどででした。


また、言われたこと以外は実装せず (実装してミスをするとさらに問題になるので冒険はしない) 「仕様書に書かれていないから」という保身的な状態も多くありました。

さらに、ふりかえりも (ほぼ) なく (あっても名ばかり) で案も出ずに、結局根性論に落ち着いて、全く改善につながらない状態でした。

よって、仕様の限定範囲での意見や改善はありましたが、おおよそは、指示待ち設計、指示待ち開発、指示待ちテストという状態でした。


これでは、価値を創造し顧客へ提供するという概念がなく、結局、価値が低い (品質が低い) 製品となり、技術者も新しい知識や情報を取得せず、製品も技術者も「緩やかに死ぬ」危機感を覚えていました。

そこで、価値を創造できるような開発チームになるように、この V 字型の開発手法において、QA がスクラムマスターっぽい役割となり開発チームのマインドセットを変え、要求分析/要件定義をはじめ、設計、コーディング、テストのプロセスの変更、そしてふりかえりからの継続的なプロセス改善に取り組んでみました。

要件定義においては、ステークホルダー分析から始まり、品質特性などから、それぞれの人が本当に欲しい機能はなんだろうということを考えることから始めました。
さらにユーザーストリーマッピングの考え方も取り入れて、どういう使われ方をするのかを考えるプロセスも取り入れました。

設計やコーディングにおいては、開発者、テスターの全員でモブ設計を行い、多様な意見を交流できるようにして、様々な機能の必要性を検討するようにしました。

テストにおいては、開発者がテストをする大切さを説き、テストファーストの概念でテストコードを書く習慣に変えようとしています。

また、プロセス全体としてふりかえりを行い、新しい手法や考えを取り入れていき改善していくことを考えていけるようにしていきました。


そんな QA が思考錯誤しながらスクラムマスターっぽいことをやってみた奮闘記をお話しをしたいと思います。

 
 
 
 

Outline/Structure of the Talk

  • 旧開発体制のメリットとデメリット
  • 意識改革 (その時歴史が動いた)
  • プロセス改善奮闘記
    • 要求分析・要件定義
    • 設計、コーディング
    • テスト
    • ふりかえり
  • まとめ (改善は続く)

Learning Outcome

  • 旧開発体制からの脱却
  • 組織 (チーム)の意識とプロセスを何とかして改革していく事例

Target Audience

QA やテスターの人、スクラムマスター見習い

schedule Submitted 9 months ago

  • Yuya Kazama
    keyboard_arrow_down

    Yuya Kazama - Scrumチームに「テストは単純作業ではなく創造的な活動だ」という意識を浸透させて良品質&低コストの製品を作るようになるまでの物語

    Yuya Kazama
    Yuya Kazama
    QA Engineer
    BizReach Inc.
    schedule 11 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    皆さんはテストを「作業」としてやっていますか?それとも「活動」としてやっていますか?

    • 沢山の羅列をしたチェック項目を確認することがテストである
    • とりあえずプログラムの実装をして、実装が終わった後に、確認すべきことを考えてテストする
    • 実装したプログラムに対してバグを検出することが、唯一にして最大のテストをする目的である

    上記のような考え方をしている方々は、おそらくテストを「作業」として行なっています。

    もしくはテスト駆動開発(TDD)がテストの全てだと考えている人もいるかもしれません。

    そして残念ながら、テストを作業として行なっているorTDDがテストの全てだと考えているScrumチームが多くあると感じています。

    一方私は、テストは創造的な活動であり、プログラムの実装前の時点でもテストの活動を行うことが可能だと考えています。これは、TDDを行うよりももっと前の話です。

    例えば、テストの活動を利用することで、リファインメント時点で今まで以上に仕様を明確にすることができます。(しかもそんなに時間をかけずに!)

    また、テスト技法を用いることで、Planning時点(開発実装前の段階)で行うべきテストを考えることができます。

    これらの活動により、品質の良い&コストのかからない製品を作り出すことができます。

    本講演では、「テストは作業である」「テストについては実装後にQAに任せれば良い」と考えていたScrumチームに対して、どのようにして「テストは活動である」という考え方を染み込ませていったかの物語をお伝えします。

  • Ikuo Odanaka
    keyboard_arrow_down

    Ikuo Odanaka - R&Dチームが歩むスクラム守破離ジャーニー

    20 Mins
    Talk
    Beginner

    R&D(研究開発)チームは常に不確実性と向き合っているため、アジャイル/スクラムを取り入れることは必然のように思えます。
    私が所属するR&Dチームや隣のR&Dチームもスクラムに取り組み、自分たちで働き方を問い直しながら変化し続けるようになっています。
    今ではスクラム導入前にどう働いていたのか思い出せないほどにチームに浸透しています。
    新しく配属された新人は、このやり方こそがスタンダードだと感じています。

    しかし、最初から難なくスクラム開発に取り組むことができたかというと、そうではありませんでした。
    スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ…
    スクラムイベントの名を冠する予定は定期的に開催されていたものの、そこに透明性はなく、よって検査と適応もない状態でした。

    形だけのスクラムがもたらした閉塞感から脱却し、透明性・検査・適応によって変化していくために実施したこと。
    取り組む中でどのような壁にぶつかり、どう適応し変化していったのか。いつ自分たちの開発スタイルに自信を持つことができたのか。
    そして、今はどこに向かっているのか。

    現在進行形の現場から、チームの学びと成長をお届けします。

  • Makoto Iguchi
    keyboard_arrow_down

    Makoto Iguchi - セキュリティとアジャイル開発のいい関係について考える / Security and Agile Development

    20 Mins
    Talk
    Intermediate

    The presentation will be given in Japanese. I've uploaded the (partially) translated version of my slides at https://www2.slideshare.net/makotoiguchi/how-to-balance-between-security-and-agile-development for your reference.


    2018年12月頃に掲載された「アジャイル手法でのセキュリティは困難」というタイトルの記事において、某セキュリティ会社のCTOは「高速のCI/CD(継続的なインテグレーション/デリバリー)においてセキュリティ上の問題が浮上しても、その解決に当たる余裕や時間がないままに事態が進行してしまうようなことが往々にしてあり、現場が混乱する」とした上で、結果として「DevSecOps、NetSecOpsが、現実にはうまく機能しない」という見解を示しました。

    これは本当なのでしょうか?
    もし本当だとしたら、それは悲しいことなのではないでしょうか?

    一方、2019年8月に掲載された "Your security team is probably an infuriating obstacle - but it doesn't have to be this way" という記事においても触れられているように、開発者側より「セキュリティは、DevOpsやアジャイルな開発スタイルにブレーキをかける存在である」といった声を聞くことがよくあります。

    これは正しい姿なのでしょか?
    セキュリティとアジャイル開発は、水と油の関係なのでしょうか?

    このセッションでは、ISMS内部監査責任者とスクラムマスターを兼任している立場の人間から見た、セキュリティとアジャイル開発の「あるべき姿」についてお話します。また、現在行っているセキュアなアジャイル開発の実現へ向けた実験(The Elevation of Privilege: Threat Modeling Card Deck を活用したセキュリティ問題の洗い出しとプラニング)をご紹介します。

    参考)The Elevation of Privilege: Threat Modeling Card Deck を日本語化&いらすとや化したもの。こちらの Github レポジトリで公開中です。

    EfOaaY7VAAE6AW7?format=jpg&name=medium

  • Arata Fujimura
    keyboard_arrow_down

    Arata Fujimura - モダンオフショア開発のすすめ

    Arata Fujimura
    Arata Fujimura
    Manager
    Classmethod, Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    オフショア開発と聞いて皆さんは何をイメージしますか?

    • 安かろう悪かろう
    • 技術力不足
    • 低品質

    未だにこのようなイメージを抱いている方も少なくないかもしれません。

    クラスメソッド社で2019年7月に立ち上げたグローバルチームでは、上記イメージのようなオフショア開発をレガシーオフショア、我々が目指すオフショア開発をモダンオフショアと明確に分けて定義し、ベトナム開発パートナーとともにモダンオフショア開発を実践してきています。

    -56-1024.jpg?cb=1581658760

    レガシーオフショアとモダンオフショアの違いを上記のように定義していますが、モダンオフショアを一言で言うと"アジャイル×オフショア開発"となります。

    当セッションでは、実際にモダンオフショア開発を進める上で得た学びを、事例を交えて熱くお話しさせて頂きます!

  • Woohyeok Aaron Kim
    keyboard_arrow_down

    Woohyeok Aaron Kim - Integrate your cycle with OODA (Extended Edition of Scrum X Army at ‘RSGT2020’)

    45 Mins
    Talk
    Intermediate

    世界中で著名な人物である野中先生やScrumのCo-CreatorであるJeff氏の歩みからも分かるように、Agile・Scrumの哲学は長い間の研究で発達してきた軍隊の組織論に基づいています。軍隊はただ一度のミスが作戦の失敗をもたらすという厳しい状況で、どうすれば戦闘力を最大化し勝ち続けていけるのかの未来図を示しています。軍隊がいつも力を入れているこの点は、Velocityを最大化し、どのようにビジネスの成功を導くか工夫している点でAgile組織と同じだと言えます。

    その軍隊が、成功のために必須不可欠だと強調しているものがOODAループです。

    PDCAというサイクルはすでに、ビジネス世界で基本中の基本となっています。ただ計画性が重要視されるだけに、予期できなかったことが起きた場合またPlanningから始めなければなりません。Agileが主流になっている今、PDCAが持つ限界は明確ですが、この弱点を補うのがOODAです。最初から全てを計画するのではなく、現在の出来事を観察(Observe)し、その分析結果により(Orient)次のアクションを取る(Decide, Action)ことで、変化に対する素早い対応ができるようになります。

    OODAループはどこからきたのか、どういうものなのか。そしてPDCAとのハイブリッド的な運用で、組織に対して何を示すことができるか。4年間士官として軍隊に勤めていた私からご提示させていただきます。

    (このセッションは、RSGT2020で好評をいただけた「SCRUM X ARMY」の再演ではなく、拡張版となります。)

  • Kazuyoshi Takahashi
    keyboard_arrow_down

    Kazuyoshi Takahashi - アジャイルコーチとVPoE、あるいはEMの間にあるもの

    20 Mins
    Talk
    Executive

    10年前から5年前まで、アジャイルコーチとして2,000人以上の開発組織を抱える企業のアジャイルトランスフォーメーションに挑戦していました。
    現在はその立場を離れ、事業会社のVPoEとして開発組織の運営をしています。

    アジャイルコーチとVPoE、両方の経験からチームを見る視点にどのような違いがあるのか、アジャイルコーチの先にどのようなキャリアがあるのか、個人的な経験を交えながらお話します。

    RSGT2020 Closing Keynote「NEXT→ACTION」の後日談でもあります。

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori / Takahiro Kaneyama - ふりかえり手法のおもちゃばこ

    45 Mins
    Panel
    Intermediate

    ふりかえり/スプリントレトロスペクティブで、みなさんはどんな手法を使っていますか?

    「KPT・YWT・Fun/Done/Learn あたりは試してみたものの、他の手法は知らない」という人も多いはず。

    色々な手法を試してみると、「あぁ、ふりかえりってこういうものなのね」とあらためて見えてくるものがあるんです。

    だから、色んな手法を試してみてほしい!楽しんでほしい!

    そんな想いで、このセッションを実施します。

     

    このセッションでは、トコトンHowを追求します。

    目的の話は一切しません(目的の話は関連リンクをご参照ください)

    とにかく色んな手法を、手法の進め方、実施イメージ、ポイントなどに絞ってお話します。

    1手法1分~2分くらいで、とにかくたくさん、面白い手法を話します。

    メジャーなものからマイナーなものまで、色々話したいと思います。

    きっと、「あ!これ楽しそう!私もやってみよう!」という手法が見つかるはずです。

     

    話せるとよいなと考えている手法

    • DPA
    • 3Dots
    • 連想ゲーム
    • Timeline
    • Story of a Story
    • 象、死んだ魚、嘔吐
    • 斜に構える/構えないを切り替える
    • Starfish / Small Starfish
    • Following up on Action Items
    • Celebration Grid
    • 質問の輪
    • Sailboat / 熱気球 / スピードカー / ロケット
    • ORID
    • 4Ls
    • Repeat / Avoid
    • Effort & Pain
    • SMART Goals
    • 360度感謝
    • Hapiness Door

    このセッションは、参加者との双方向で作り上げていきます。

    KANEが参加者からのコメントを拾い、森が解説する。

    気になる手法を、この場で明らかにし、楽しいふりかえりを作り上げていきましょう!

  • kyon _mm
    keyboard_arrow_down

    kyon _mm / neno neno - アジャイルを忘れるチーム Unlearn Agile

    45 Mins
    Talk
    Advanced

    「チームが生き生きしつづける予感はどこからきますか?」

    予告編動画 => https://www.youtube.com/watch?v=5Ro5_c5kFaY

    20200904164048_original.jpg

     

    アジャイルをUnlearnし、生き生きとした開発を見つけたチームがいました。そこにはアジャイルマニフェストもスクラムガイドもなく、自分達のパタンランゲージがありました。開発するシステム、立ち居振る舞い、プロセス、価値観、イベント、成果物などありとあらゆるものが記述されていました。パタンランゲージの語彙は200を超え日々編纂されていました。

    私達チームが新しい形に変化していくこと自体が漸進的で、自然で、納得しやすい必要がありました。Unlearnしていくこと、アレグザンダー理論を導入していくこと、実践していくことは一見難しくおもえました。ですが、私達は徐々にできてきました。この漸進的な変化こそが私達が見つけたかったものです。これこそがチームにおける決定の遅延であり、漸進的変化でした。これらの具体例そして考察をおとどけします。

    時を超えた開発の道とは何かを考えるきっかけにどうぞ。

  • SATORU KAWABUCHI
    keyboard_arrow_down

    SATORU KAWABUCHI - NTTみたいな企業で新アプリをスクラム開発してみんなが笑顔になった

    20 Mins
    Talk
    Beginner

    NTTグループでサービスをアジャイル/DevOps的に運営をしてきた。しかしながら、現在提供中のスマホアプリがNow Up To Dateなものではなくなってきたため、新しいアプリに作り変える必要性があることがわかってきた

    そして決めたのは

    ・一般的にトラディショナルな会社ではアプリの刷新は、既存機能を全て要件定義し、マイグレーションを行うが、この方法をとらずアジャイルスクラムで新アプリをつくることとした

    ・すなわちユーザーの価値が高いものからプロダクトバックログを作り、動くモックを作ってレビューするを繰り返してきた。そのときに既存機能でも価値が低いものは作らないこととし、リリース可能担ったタイミングでリリースすることとした

    ・トラディショナルな会社の中でこのやり方を承認してもらい、メンバーが取り組んでいく中で、ステイクホルダーまで含めて盛り上がってきた

    ・結果的に良いものができた。できることは限られているが、とても高速で動きユーザーにとって一番あってほしい価値を実現できた。

    大企業の中でアジャイルを生き延びさせるには?起きてくる現場と社内との課題、その時マネージャーにできることは?この取り組みのようなことをトラディショナルな企業でも考えていくべきと思うので学びにしていってもらいたい!

  • Harada Kiro
    keyboard_arrow_down

    Harada Kiro - スクラムをスケールするとはどういうことか?

    Harada Kiro
    Harada Kiro
    CEO and Agile Coach
    Attractor Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    DXという言葉がいろいろなところで見かけるようになり、それに伴ってスクラムをスケールする手法も色々と出てくるようになっています。

    たくさん見かけるからといっても、うまく行っている例は多くありません。むしろ、例ばかりが増えすぎて混乱しているようにも見えます。過去にも用語だけ先行する例はたくさんありましたね。

    このセッションでは、特定のスケーリング手法を説明するのではなく、スクラムがスケールできた状態とはどういうものか、スケーリングを妨げる障害について議論したいと思っています。

     

  • Yoh Nakamura
    keyboard_arrow_down

    Yoh Nakamura - 組織がアジャイルになっていく道を歩んだ時、「少しだけうまくやれたこと」と「うまくやれなかったこと」

    20 Mins
    Talk
    Intermediate

    ScrumやXPなどを用いて、みなさんのチームがアジャイルになっていっているとします。

    そのチームの活動がプロダクトを構築することが主なら、次はプロダクトをより使い続けてもらえるプロダクトづくりができるチームを目指してもいいかもしれません。

    その時には開発をする役割以外にも、ユーザーのことを知る活動、ユーザーに買ってもらう活動、ユーザーのサポートをする活動など様々な活動が必要になります。そしてその活動を担う人達やチームと連携して動く(少し大きな)チームになる必要があります。

    このようなチームがうまく機能する要素の1つに「組織がアジャイルな価値観や考え方、それに根ざした活動ができているか?」というのがあります。
    もし1つ、2つのチームしかアジャイルな価値観や考え方を持っていなければ、このようなチームはうまく機能しないかもしれません。

    このセッションでは、組織がアジャイルな価値観や考え方、それに根ざした活動をうまくできるようになるために取り組んできた事例をお話します。
    組織の中の一員としてやっていた(昔の)事例、ギルドワークスの現場コーチとして様々な現場を外から支援していた事例をお話できればと思います。

    みなさんの組織がアジャイルになっていくヒントになればと考えています。

  • Masanori Kawarada (Mark Ward)
    keyboard_arrow_down

    Masanori Kawarada (Mark Ward) - [Online Interpretation] 独立QAチーム1年戦記:スクラムの外からチームと組織の品質を創る道 / An Independent QA Team's 1 Year's War: Way to Create Quality of the Teams and the Organization from the Outside of Scrum

    45 Mins
    Talk
    Intermediate

    English follows:

    「Scrum@Scale(S@S)を取り入れた100名ほどの開発組織で、スクラムに入らない独立したQAチームが活躍している」と聞いたら、もしかしたら奇異な感じを受けるかもしれない。スクラムではチームであらゆることが完結することを理想とするため、当然テスター(QAエンジニア・テストエンジニア ・などなど)もスクラムチームに入るべき、と考える方がスクラム実践者にとっては自然だからである。あえて、その自然に逆らって、私たちQAチームは独自のビジョンを掲げた「ビジョナリー・QA(Visionary QA)」として、独立した立場から品質向上という成果を上げようと奮闘している。このトークではそんな私たちQAチームの1年戦記をありのままに扱いたい。

    開発プロセスの高速化が進み、多くの企業でアジャイル開発が取り入れられ、過去の当たり前が当たり前でなくなっている中で、QA界隈ではどうやって価値を提供するか頭を悩ませている。あくまでもテストにこだわる者もいれば、スクラムマスター・プロダクトオーナーの視野を得るべく資格を目指す者もいる。2009年に翻訳出版されたリサとジャネットによる『実践アジャイルテスト(Agile Testing)』(翔泳社)は国内のテスターに広く読まれているが、最近版元品切になっていることもあり、手に入りにくくなっている。

    さて、テスターは異質な存在のひとつとして見なされている。ご存知の通り、スクラムガイドにはテストやQA活動をどのように行うべきか、言及されていない。3つのロールに「テスター」の文字は無い。よって、テスターのあり方はそれぞれの組織で模索するしかなく、特にテスターをスクラムチームに含めるべきか否かという議論は継続的に行われている。先にもあげたように、スクラム実践者にとってはテスターがスクラムチームに入ることは自然であると感じられ、実際そのようにしている組織が多いが、それぞれにメリット・デメリットがあることから、あらゆる組織で通じる答えは今のところ無さそうだ(テスターとして仕事をしてきたメンバーがスクラムチームの開発者の一員としてどれだけクロスファンクショナルに動けるか、という点が特にネックなように思える)。

    このトークは、独立した立場で動くことを選んだQAチームの話だ。スクラムチームにテスターを迎え入れねばならないと思っている方にはそうでない可能性を示す一方で、やはりスクラムチームに開発者としてテスターを加えるべきだと結論づけるオーディエンスもいらっしゃるかもしれない。スクラムチームとテスターの一筋縄ではいかない関係を、1年間の実例をもとに、一緒に考えようではないか。

    "In a 100-strong software development organization which runs Scrum@Scale, an independent QA team works well." ––it may sound strange to you. Ideally, in Scrum, everything should be done in one scrum team, so it is natural for Scrum practitioners that testers (QA engineers, test engineers, etc.) should join a scrum team. Daring to go an unnatural way, our QA team struggles to achieve quality improvement results from an independent standpoint as "Visionary QA" with its vision. I want to treat our QA team's year-long battle story as it is in this talk.

    Development processes are getting faster and faster. Many companies are incorporating agile development. The commonplace of the past is no longer the norm. In this fast-changing age, the QA industry is struggling to figure out how to deliver value.  Some testers are more concerned with testing, while others aim for the certification to learn a Scrum Master/Product Owner's perspective. The excellent book, "Agile Testing" by Lisa Crispin and Janet Gregory (Addison-Wesley), which was translated in Japan in 2009 by the domestic publisher Shoeisha, has been widely read by testers in our country. Recently, however, it isn't easy to get due to out of print.

    Testers tend to be seen as one of the heterogeneous entities. As you know, there is no mention in the Scrum Guide on how testing and QA activities should be done. There is no "Tester" in the three roles of Scrum. Therefore, each organization has no choice but to explore the nature of testers. In particular, there is an ongoing debate on whether or not testers should be included in Scrum. As mentioned earlier, it seems natural for Scrum practitioners to have testers join Scrum, and indeed many organizations are doing so. Still, since each has its advantages and disadvantages, it seems that we don't have an answer that works for all organizations at the moment. One of the problematic points appears to be how well testers can work cross-functionally as a "Developer" in Scrum.

    With this session, which is about a QA team that chose to work independently, some attendees who feel testers should join a Scrum team may get a chance to notice the other possibility, and others may conclude that Scrum teams should still include testers. Let's take a look at the tricky relationship between Scrum and testers with the help of a year's worth of examples.

  • 平鍋健児
    keyboard_arrow_down

    平鍋健児 - 野中郁次郎のスクラム再訪問(Nonaka's Scrum Revisited)

    平鍋健児
    平鍋健児
    CEO
    ESM, Inc.
    schedule 11 months ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    これまで、Scrumの1つの源流ととらえられてた "The New New Development Game" ですが、今回は、一連の野中先生の著作や論文の中に発見される、組織論コンセプトと、現在の Scrumとの関係について、整理してお話したいと思います。

    1. 2つの知の形態:暗黙知と形式知
    2. 自己相似系(マトリョーシカ)組織と「海兵隊」
    3. 消耗戦と機動戦。OODA モデル。
    4. 第3の知=実践知(Phronesis)
    5. 「共感」の本質、You-I-It(二人称・一人称・三人称) 

    などのコンセプトを中心にお話します。

     

     

     

  • Noriyuki Nemoto
    keyboard_arrow_down

    Noriyuki Nemoto - プロダクトを強化する探索的テスト戦略

    Noriyuki Nemoto
    Noriyuki Nemoto
    senior engineer
    Agile Sapporo
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    スクラム/アジャイル開発でプロダクトの品質はうまく担保できていますか?

    要求をシンプルにしたり、テストの自動化に取り組んだり、テスト設計をしたり。もちろん品質を担保するには色々なアプローチがありますが、今回は探索的テストの使い方に焦点を当ててお話をしたいと思います。

    具体的にはST:スクリプトテスト(テスト仕様書に沿ったテスト)とET:探索的テストの使い分けのパターンを紹介します。探索的テストはコストが少ない割にバグの発見率がいいんです!!

    • ST->ETシリアル
    • ST/ET パラレル①
    • ST/ET パラレル②
    • ET-> STシリアル
    • ET->ST->STシリアル
    • ST&ET STチャーター

    品質が悪くて手戻りが多いチームにお勧めします。
    自動テストに探索的テストを加えて、安心してスプリントを進めていきましょう。

    最後に…探索的テストってテストのアジャイルなアプローチなんですよ!!

  • Ryutaro YOSHIBA (Ryuzee)
    keyboard_arrow_down

    Ryutaro YOSHIBA (Ryuzee) - スクラムにおける「完成」とはなにか?

    20 Mins
    Talk
    Intermediate

    スクラムガイドには「完成」という単語が36回、「完成の定義」が12回登場します(弊社調べ)。ほかの代表的な単語を調べてみると、スプリントバックログは16回、スプリントレトロスペクティブは12回です。
    つまり、スクラムにおいて「完成」は非常に重要な意味を持つことは明らかです。

    しかし、「完成」に対する認識がスクラムチームのなかで違ったり、組織での品質の基準をまったく考慮せずに開発を進めていった結果、リリース直前に品質上の大きな問題が起こったといった話もよく聞きます。

    sgt01.jpeg

    ネット上の記事を調べても、「完成」が重要な意味を持つ割に「完成」とは何なのか、どのように「完成」を定義し、どうやって「それを守っていくのか」というノウハウはあまり出回っていません(と認識しています。プロダクトバックログの話なんかは山のように見かけるんですが)。

    そこで、本セッションでは、「完成の定義」をできる限り深堀りし、今後みなさまが「完成」を守っていく上でのヒントを共有します。

  • Yoshimasa Iwase
    keyboard_arrow_down

    Yoshimasa Iwase / Junki Ueda - Remote Work Native な働き方を志向した結果、Agileな状態に爆進しているとあるHRチームの話 - 組織全体への波及を添えて

    20 Mins
    Talk
    Beginner

    2020年初頭よりコロナウィルスの流行により、私達の働き方は激変しました。もともと、オフィス出社が当たり前だった状態から、フルリモート中心に変化しています。

    自身の人事系チームにおいても、コロナ前はオフィス出社があたりまえのチームでした。そのため、リモートに適したチーム運営・コミュニケーション・ITフル活用を進めていかねば、リモート時にパフォーマンスが悪化してしまいます。

    そこで、在宅でも高いパフォーマンスを出すために、Remote Work Native な働き方を考え続け、継続的にふりかえり、試行錯誤を繰り返していきました。その結果、自然とBeing Agileな状態に進んでいることがわかりました。

    本Talkでは、どのようにAgileな状態へ進んでいったのか、またその取組みを組織全体・会社全体へ波及させるために何をしているのか、といった実例についてお話いたします。

  • Minoru Yokomichi
    keyboard_arrow_down

    Minoru Yokomichi - アジャイルつまみ食いしたい人向けの「アジャイルから学べること(私が学んだこと)」〜アジャイルに興味をもってもらう方法を添えて

    20 Mins
    Talk
    Beginner

    私が最初に本格的にアジャイルと出会ったのは 2012年の Developer Summit でした。その後、書籍や記事、アジャイルコミュニティにいる実践者、研修トレーナー、同僚などから様々なことを学びました。

    その本質が理解できていた(る)かはさておいても、その中には、次の日から意識や行動が変容するような、私の中でそれまでの考え方が大きくかわった考え方もたくさんありました。

    ここ数年、「アジャイル」という言葉にはこだわることなく、これらのアジャイルから学んだことを、部分的であったとしても、様々なロールの人と働く中で実践しその考え方をおすそ分けしてきました。それがアジャイルから学んだことであることを明かすことで、結果としてアジャイルに興味を持って頂くシーンもとても増えてきました

    このセッションでは、私自身が初学者だった頃にさかのぼって、今でも印象深いことを広く浅くごった煮駆け足でお伝えできればとおもいます。(なるべくその後その知識を深められるように、参照元を紹介する予定です)

    さまざまなロールの方が、その中から一つでもひっかかり、つまみ食いでも良いのでアジャイルに興味を持つきっかけになればと思います。
    または、アジャイル実践者の方は、まわりでアジャイルのファンを増やす活動のヒントや材料にしていただければと思います。

  • Rochelle Kopp
    keyboard_arrow_down

    Rochelle Kopp / Tatsuya Kinugawa - Bilingual cross-cultural discussion 日本人と外国人のディスカッション: How to accelerate the adoption of agile and scrum in Japan? 日本でのアジャイルとスクラムの導入をどう加速すれば良いか?

    100 Mins
    Workshop
    Beginner

    This session is an opportunity for Japanese and non-Japanese to exchange ideas about the challenges of implementing agile and scrum in Japan, and brainstorm about how to work together to overcome them.

    RSGらしい国際交流の場をTokyoでも。こちらのセッションでは、日本におけるアジャイルとスクラムの導入をどうすれば加速できるかについて日本の方々と外国の方々にご参加いただき議論できればと思っています。RSGTにご参加の皆様は耳を疑うかもしれませんが、我々2人は今もなお外国の方々から「日本ではなぜアジャイル開発がスタンダートではないのか」「アジャイル開発を導入したいが様々な課題に直面している」という相談を受けることがあります。この課題には実は二つの異なる要素が包含されているように感じています。一つは、日本、ひいてはアジア諸国における文化的なハードルによる難しさ(いわゆる異文化交流の難しさ)、もう一つは、日本の企業体制におけるアジャイル導入のハードルによる難しさだと思います。

     

  • Tadahiro Yasuda
    keyboard_arrow_down

    Tadahiro Yasuda - 僕らのジョイインクジャーニー コロナ禍編 リモートワークへ移行した会社(チーム)がカルチャーを維持/向上させるために取り組んでいること

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

    あなたは喜びに満ちた人生を送りたいですか?
    あなたは喜びに満ちた職場で働きたいですか?

    この言葉を自分自身に問いかけて、僕自身がまず変わりそれを会社全体へ少しずつ少しづつ波及させていき、その取り組みによって会社のカルチャーが変わり、会社が少しだけ「喜びに満ちた職場」になったと思った。しかしそう思ったのも束の間、突然発生した新型コロナウィルス。


    それにより、僕らの働き方が大きく変わりました。
    ただこれまで培ってきた僕らの大切な会社のカルチャーを維持していきたい、またこれまでよりも良くしていきたい。と強く願いそれに対して取り組んできました。
    その取り組みなどについて、是非みなさんと情報共有できればと思っています。

    ーーー
    昨年のRSGT2020で発表した「日本にJoy,Incを創る!どん底からスタートしたぼくらのジョイインクジャーニー7年間の軌跡」の続編としてこの1年間の取り組みについて情報共有いたします。

    僕らが一番大切にしている会社のカルチャー、それを維持/向上させるためにどのようなことを取り組んでいるのか、またその取り組みによりどのような効果を得ることができたのか、また失敗した取り組みについてもそれはなぜ失敗したのか、などについて、具体的な事例を含めて情報共有したいと思います。

  • Ryo Tanaka
    keyboard_arrow_down

    Ryo Tanaka - フィールドワーカーから学ぶアジャイルコーチとしての生き方のすゝめ

    20 Mins
    Talk
    Advanced

    民族誌学/エスノグラフィーのフィールドーワーカーから学ぶアジャイルコーチとしての生き方。

    フィールドワーカーとは他の文化圏、他の民族の中に入り、中からそのシステムを観察し、何らかの研究結果を出していく仕事です。
    外部アジャイルコーチは、NOT SCRUM 文化圏や伝統的IT文化圏の中に入り、中からそのシステムを観察し、何らかの変化をシステムに与えていく仕事です。

    観察し、解析し、なんらかの仕事をする。このサイクルはかなり共通点が多いと考えています。
    アジャイルコーチもフィールドワーカーも「カルチャーショック」を潜り込んだ先で受けますし、相手側は「フィールドワーカーショック」をフィールドワーカーから受けます。コーチの場合は「アジャイルコーチショック」とでもいうのか。その場合の影響の最小化の仕方、最大化の仕方。記録のとどめ方。

    また、アジャイルコーチもフィールドワーカーも人間ですから、段々と精神が不安定になってくることもあります。その場合の乗り切り方(例えば「正直な日記」の書き方)。うまくいってる時はいってる時で、どのような観察をフィールドワーカーとしてすべきなのか?(厚い記述と薄い記述の話)。

    等々、フィールドーワーカーから学べる事は非常に多いと考えています。 

help