チームがLeSSにJoinして1年半経ったので振り返ってみた

location_city Mikawa schedule Oct 2nd 02:25 - 02:45 PM JST place りん people 5 Interested

Rettyでは2年前から大規模スクラムのひとつの手法であるLeSSで開発をはじめました。
私達のチームは約1年半まえから社内の4番目のチームとしてLeSSチームに合流しました。

私達のチームではtoB向け商品開発をすることから開発期限が厳しいものが多かったり、少しでも開発を早くするために(当時としては)できるだけ対象機能について詳しいメンバーにタスクをアサインし、可能な限り着手タスク数を増やすために一人一タスクで開発を進めるといったことを行っていました。

その結果、属人化が進んでしまったり、開発期限から改善系タスクが後回しになりがちになったり(運用やバグ対応はもちろんする)といろいろな課題が発生していました。

このセッションではそうした私達のチームがLeSSに加わってからの1年半の軌跡と、その中であった変化についてのポイントとそれがどういった背景で起きたのかについてをお話していきます。

 
 

Outline/Structure of the Talk

  • LeSSにJoinする前のチームの状態について
    • 事前にスクラムイベントの説明はざっとうけたくらい、見様見真似でスクラムを始めた
  • 48日後
    • 特に変化はない
  • 3ヶ月後
    • それっぽくスクラムが回り始める
  • 6ヶ月後
    • 属人化の状態について変化が始まる
  • 9ヶ月後
    • CI・CD改善、自動テスト、振り返り手法の改善
  • 1年後
    • 新メンバーが加わる!スクラム詳しい!スクラムガイド輪読会
  • 1年半後
    • 新メンバー加わる!雑談、率直に相談する意識感が加速

Learning Outcome

  • LeSSを導入している組織において、全社のLeSS体制にジョインする上での学び
  • スクラムに取り組むうえでチームがよくなるキッカケとそのポイント

Target Audience

全社のLeSS体制にジョインしていこうとしているチーム

schedule Submitted 10 months ago

  • Masanori Kawarada (Mark Ward)
    keyboard_arrow_down

    Masanori Kawarada (Mark Ward) - 独立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:

    [email protected][email protected])を取り入れた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 [email protected], 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.

  • Imai Takaaki
    keyboard_arrow_down

    Imai Takaaki - 「守破離の守!」スクラムガイドをみんなで読んでみた。

    Imai Takaaki
    Imai Takaaki
    Webエンジニア
    Retty株式会社
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    「チームが次のステップに行くためには何が必要だろう?」

    ある日のふりかえりでそんな声が上がりました。

    スプリントを回して、スクラムイベントを開催して、プロダクトバックログから取ったアイテムもそれなりにDoneできている。
    ふりかえりをやれば意見は出るし、次のスプリントで改善にも取り組んでいる。
    チームの雰囲気だって悪くない。

    でも、本当にこれでいいんだっけ?
    知らないだけで、本当はもっと良いやり方があるんじゃないか?
    何か大きな課題に気づけていないんじゃないか?

    確かにスクラムを実践しているつもりだけど、チームメンバー全員がスクラムについて勉強しているわけじゃない
    スクラムイベントを行う意味やスクラムのロールの意義について、お互いの解釈を確認したり深く議論してはいない。
    初心にかえって、自分たちのやっているスクラムというものがなんなのか学んで見るのはどうだろう

    というわけで、まずはスクラムガイドをみんなで読んでみて、現状とのギャップを知ることで、ステップアップのヒントを探ることにしました!

    読み合わせで出てきた様々な解釈やその中で生まれた議論と共に、会の旗振り役として観察した結果得られた気づきをお話しします!

  • Toshiharu Akimoto
    keyboard_arrow_down

    Toshiharu Akimoto / kyon _mm - みんなでともに考えるコーチング。みんなで一緒にコーチングと仲良くなろう

    20 Mins
    Talk
    Beginner

     

    ただただコーチングについて語り、問いかけ合い、コーチングを理論だけではなく、体験や感覚として、聞いた人が今までより手に馴染むものに近くなるように対話してみる実験回です。

    想定されそうな話題としては

    • コーチングってなに?(入り口的な深さで)
      • 世の中で語られているコーチングのさまざま
      • 実際にどんなことをしているのか、プロセス、スタイルなど
    • どういう場面で、なんの役に立つのか
    • 日常にコーチングはどう使えるのか。溶け込むのか。
    • どのようにコーチングスキルをトレーニングしていくものなのか

    というあたりでしょうか。
    これらの観点をふたりから見たコーチやコーチングという話題も踏まえて対話してみたいと思います。

    もっとこういう話聞いてみたいというのがあれば Feedback 欄からお気軽に投稿してみてください(このセッション内で答えられるかどうかわかりませんが、善処します)

     

    タイトルや中身は直前まで推敲するので、変更する場合があります。


    「あの人はこの問題に対してなんて答えるんだろう?」
    「あの人はこの答えに辿り着くまでにどういう思考プロセスを経たのだろう?」
    「あの人の頭の中身が見てみたい!!」
    と思ったことはありませんか?

    同じようなプラクティスや手法を用いていても、人/チームによってまったく違う結果になります。
    つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。

    このセッションでは達人たちが見ている世界を覗いてみる実験をします。
    ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
    ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。

  • Masahiko Watanabe
    keyboard_arrow_down

    Masahiko Watanabe / Shuichi Matsubara / Akihisa Furuhashi / Shigeo Konno / Kenta Sasa / Saito Norihiko - いろんなアイデアが聞けて、とにかく前向きになる相談会

    45 Mins
    Talk
    Beginner

    あなたの現場では、こんなことがおきていませんか?

    「ペアプロを導入したいけど、上司が…」
    「Daily Scrumで何も話題が出てこない…」
    「本やブログで書いてあったやり方をやってみたけど…」

    同じような問題でも、現場によって有効な解決策やアプローチは違ってきます。
    簡単にいうと銀の弾丸はありません。

    そこで!

    実際に皆さんの現場で起きている問題や悩みを出してもらい、とにかく前向きな6名が通用するかどうか分からない鉛玉を大量に提供したいと思います!

    色んな現場で実際に試して
    失敗したアイデア、成功したアイデア、
    社内のチェンジエージェントの観点、社外のアジャイルコーチの観点、
    あの現場での話、この現場での話…
    数ある鉛玉から自分の現場に合いそうな輝く弾丸を持ち帰ってください。

    セッション中は

    みなさんも無責任に「自分だったらこうするかなぁ」「こんなことしたら上手くいったよ!」という鉛玉をじゃんじゃん放流してくださいね!

    みんなでわいわいしましょー。

  • Hiroki Hachisuka
    keyboard_arrow_down

    Hiroki Hachisuka - 「これがティール色?」~会社も歳もスキルも違う仲間で、プライベート開発を始めたら見えてきた世界~

    Hiroki Hachisuka
    Hiroki Hachisuka
    parallel PdM
    -
    schedule 11 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    「また大袈裟なこと言いやがって、テーマがでかいんだよ」と思った方、そうは言わず、騙されたと思って、詳細を見ていってくださいw

     

    【お話の背景】

     2021年4月から組織を飛び出し複業家になった私は新たなチームの形の実験をしていました。

    それは、

    「社会人の部活動としてプロダクト開発をチームで行う」

    ということ。

     

    本業がありながらも、副業ほど報酬を求めるでもなく、個人開発の延長としてのチーム開発の実験をしています。

     

    この実験の中で、生まれたチームを本業での開発チームと見比べると組織として面白いことがたくさん見えてきました。

    具体的には、ティール組織の原則である、

     

    ① 進化する目的(組織の存在目的)

    ② セルフマネジメント(自主経営)

    ③ 全体性(ありのままの自分でいられる)

     

    を意図せずあっさりと、満たすチームが生まれていました。

    これは、はじめから狙ったわけでなく、このプロポーザルを出すにあたり、ふりかえると見えてきたことです。

     

    では、その秘訣はなんなのか?何故こうなったのか?本業のチームに生かせる部分はあるのか?

    などをお話しさせていただけたらと思います。

     

  • Mori Yuya
    keyboard_arrow_down

    Mori Yuya - めちゃめちゃ使いこなす観察、理解、知識、解像度! そしてコンテキスト!!

    45 Mins
    Talk
    Advanced

    観察、知識、理解といった心の働きは仕事の質を左右する重要な活動です。
    このセッションはよりよい仕事を果たそうとする人のために心の働きと、その質を高め方を紹介します。

    ----

    私たちは観察、理解、知識を用いて仕事をこなしています。「心の働き」といえるものです。
    心の働きは仕事の成果の質を左右する重要な活動で、また何十年も続けてきた慣れ親しんだ活動でもあります。

    しかし、心を働かせるとはいったいどのような活動なのでしょうか。
    私はほとんど答えることができませんでした。
    慣れていただけで、自分の心の使い方についてはほとんどなにも知らなかったのです。

    日常から取りあげてみましょう。
    「今日の仕事のタスクを洗い出す」とします。
    どのようにして洗い出しを行っているのでしょう。

    ・机に向かって5秒、10秒…。心が働きはじめます。
    ・ひとつひとつ判断を重ねるにつれて、計画が徐々に形作られます。
    ・10分後にはタスクを洗い出せました。

    タスクは洗い出せました。ではいったいどのように洗い出していたのでしょう。
    少し考えても10分の間に何が起きていたのか答えるのは容易ではないと思います。
    しかし、そこで起きていたことは私たちの仕事の質を左右する最も重要なことです。

    このセッションではこれまで何気なくしてきた観察、知識、理解を明らかにし、その質を高め方を紹介します。

  • Yotaro Takahashi
    keyboard_arrow_down

    Yotaro Takahashi - 狙いはボトルネックだ。小さい課題には目もくれるな!〜タウンワークアプリチームが戦ってきた改善の軌跡〜

    45 Mins
    Talk
    Intermediate

    改善したいこと、たくさんありますよね?

    でもいっぺんには解決できませんよね? どこから手をつけますか?

    このセッションでは、我々がタウンワークのネイティブアプリ開発チームが数年間戦ってきた技術的・プロセス的な課題とその対応についてご紹介します。

    我々の対峙した課題と、その解決策の一例は下記の通りです。

    • テストにめちゃめちゃ時間がかかる
      • ならば自動化!は本当に正しい、のか!?
        • 取り組んだ「手動テストの効率化」
        • デグレを防ぐ意味での自動テストの導入
    • プロセス上のムダがどこにあるのか見えない?
      • Scrumを頑張る? Kanbanやってみる?
      • 開発案件が「生まれてから役目を終えるまで」の一気通貫のモニタリング
    • クラッシュレートが上がってきた?
      • アプリのクラッシュレート改善とそのモニタリング
    • 人が、人がたらねぇ
      • アプリのSwift化
      • ハイブリッドオフショアチーム構想
    • バグを出さないために速度を犠牲にせざるを得ない
      • 我々が出すべきアウトカムってなんだっけ?
      • 質とスピード
      • 今のプロセスは足りない?適正?やりすぎ?

    これだけ読むと、課題と解決策がマッチしていないように感じるかもしれません。我々がなぜこれらの課題にフォーカスし、どうそれを捉え解決策を練っていったのかのコンテキストは当日のセッションで補完しながらお伝えできればと思っています。

  • 20 Mins
    Talk
    Beginner

    QA部門の部門長に任命され、3か月目の新米ほやほや部門長です。

    部門長になり、今まで見えていなかったものが見えるようになり、聞きたくないことが聞こえてきたり。。。
     
    QA部門をアジャイルな組織にするためにはどうするか?
    まだまだ模索中ですが、今までのマネージメント方法を踏襲しつつ、目の前の課題や未来のビジョンをメンバーと共有したり、新しいことにチャレンジしていることを話したいと思います。
     
    部門長として一番最初にしたことは、ステークホルダーと1on1をしたこと。最初は初の部門長なので、あいさつがてら「今後もよろしくお願いします」と言うノリでしたが、組織の意外な弱点やステークホルダーの強い「思い」を聞きだしました。
     
    そして会社の事業や、ステークホルダーの「思い」を総括して、QA部門として今後どうあるべきか、会社に対してどう貢献できるか、ビジョン駆動型のOKRを作ってみました。
     
    部門内においてはマネージャーと話し合い、未来のあるべき姿、今後どう活動し、何に投資するかを決定し、部門の予算を見える化して、共通の理解を得ました。
     
    また、ストレングスファインダーの知識を深め、部門の全メンバーと1on1をして、現状に満足感はあるか、一人一人が何を考えどんな特質があるか話し合いました。
     
    その中で出て来た一例として、キャリアパスがわからないメンバーが思ったより多いことが分かったため、QMファンネルを活用したQAキャリアパスを作成して、共有しました。
     
    今後もQA人材のハイヤリングや、組織変更は継続して行うため、ストーリーは続きます。もし、あなたがQAエンジニアやテストエンジニアで、スクラムチームに入って品質について悩んでいたり、品質文化をどう組織にアプローチするかを考えていれば、是非紹介したいセッションになります。
  • Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi / Furuta Kazuyoshi / Shinya Ogasawara - 建設的相互作用の論文 (通称「ボビンの論文」) とスクラムの源流 “The new new product development game” を読んでペア作業からスクラムについて考えてみりん

    45 Mins
    Talk
    Beginner

    『教育心理学概論』という書籍があるのはご存じかなと思います。この書籍を書いた三宅なほみ先生は1986年に発表した博士論文"Constructive interaction and the Iterative Process of Understanding" (通称「ボビンの論文」) で、ペア作業の観察を通じて、理解というものはなにか?複雑な問題をペア作業によってどのように進めていくのか?に迫りました。「建設的相互作用」を提案した論文として多くの影響を与えているそうです。

    スクラムの源流が80年代の製造業のプロダクト開発を観察した1986年の論文 "The New New Product Development Game" にあることはもちろんご存じですよね。この論文については、スクフェス大阪で読みました。https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15403/the-new-new-product-development-game

    2つの日本人による論文が同年に出ていることは全くの偶然ですが、異なるアプローチで人間の協調作業に迫っていることが興味深いです。

    本セッションでは、「ボビンの論文」と「The new new product development」を機械翻訳をかけながら読んだ経験を振り返り、理解とは何か、組織にとって必要な小グループ活動、ペア作業の効果に関して議論していきたいと思います。また、普段モブプロをやられている方や、ファシリテーションに取り組まれている方にとって、人間の意識がどうなっているかがわからないのは悩みのタネであろうと思います。そうした方にも気づきがあるのではないかと思います。

     

  • Naoki Kitagawa
    keyboard_arrow_down

    Naoki Kitagawa - スクフェス大阪2021で発表というアウトプットを出したら会社的インパクトが起きた話

    20 Mins
    Talk
    Beginner

    スクラムフェス大阪2021で「ゼロからのスクラムチャレンジ」というテーマで発表しました。

    とにかくIIJ名古屋支社のスクラムへの取り組みを知ってほしいとの想いで始まった取り組みでした。

    何かのきっかけになればぐらいの気持ちでしたが、思わぬところで反響がありました。

    それは社内からです。

    この発表の他にも社内のコラボレーションツールによる広報活動もあって一気に動き始めます。

    • 社内広報のインタビュー
    • 社内勉強会での発表
    • IIJの社外イベントである「IIJ Technical NIGHT」での発表

    スクフェス大阪の発表から2ヵ月で起きた出来事です。

    これらは私たちの取り組みを社内外へ発信することを目的として結成されたスクラムチームで取り組んだ結果です。

     

    これは開発ではなく発信を目的としたスクラムチームのお話です。

    • チーム結成秘話
    • 取り組んだ内容
    • 複業チームとしの苦悩
    • 突然動き出す歯車
    • これから

    などをお話できればと思います。

     

    こんなモヤモヤしてる方に是非聞いてほしい内容です。

    • 開発はないけどスクラムを取り入れたい
    • スクラムは業務時間の何%しか使えない
    • 行動したことでどんな出来事が起きえるのか知りたい
    • 行動に移す勇気をもらいたい
  • Yuichi Tsunematsu
    keyboard_arrow_down

    Yuichi Tsunematsu - スクラムマスターの育て方

    Yuichi Tsunematsu
    Yuichi Tsunematsu
    Manager
    Retty Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    Rettyでは大規模スクラム(LeSS: Large Scale Scrum)を導入しており、複数のスクラムチームが自律的にプロダクト開発に取り組んでいます。スクラムに悩む他社様と情報交換させていただくことがありますが、その中で一番よくいただく質問は「どうやってスクラムマスターを育てているのですか?」というものです。

    Rettyは基本に忠実にスクラムに取り組んでおり、スクラムマスターもプロジェクトリーダーや管理職ではなく、チームのサーバントリーダーとして、スクラムのプラクティスを遵守する役割をお願いしています。チーム構成の変更に合わせて複数のメンバーにスクラムマスターを担ってもらいましたが、各々が悩みながら、チームをよくしようとして、きちんとその役割を果たしてくれています。

    本講演ではスクラムマスターをどう選ぶか、どう引き受けてもらうか、どう成長してもらうかを、Rettyでの経験をもとに紹介させていただきます。

  • aki matsuno
    keyboard_arrow_down

    aki matsuno - 些細な変化に対する感応度を上げるために

    aki matsuno
    aki matsuno
    engineer
    -
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    突然ユーザーから仕様変更が通達された、突然メンバーから退職の知らせを受けた…

    システム開発をしていく上で突然起こる大きな変化に戸惑っていた自分でしたが、スクラムを実践していく中で、大きな変化は突然起こるものではなく、些細な変化が積み重なって起こることが多いことを学びました。

    では、大きな変化の兆候となる些細な変化に気がつきやすくするためにはどのような仕組みが考えられるのでしょうか?

    自分自身が些細な変化に敏感になるためにはどのようなトレーニングを積むと良いのでしょうか?

    本セッションでは、こうした疑問に対して自分がどのように考えて試行錯誤を繰り返したのか、その学びの過程を紹介します。

    また、セッション後半では、実際に自分が実践している

    • 変化に気が付きやすくするための工夫
    • 自分自身が変化に敏感になるために実践しているトレーニング(10,000回以上続けているもの、ここ数ヶ月で始めて効果を実感したもの…)

    も幾つか紹介してみようと思います。

  • Kazuki Higashiguchi
    keyboard_arrow_down

    Kazuki Higashiguchi - 振り返りを積み上げて自分たちのプラクティスとして昇華•体得していくための仕組みと考え方

    20 Mins
    Talk
    Intermediate

    スクラムのマインドの中では、自分たちの伸びしろやチームとしてもっとうまくプロダクトを作るためにはどうすればよいか?ということを模索するために継続してレトロスペクティブ(ふりかえり)をしているチームが多いでしょう。

    私個人がチームを育てていくなかでこの振り返りについて課題に感じていたのが振り返りがフロー情報で流れていってしまう点でした。当該チーム内の暗黙知として共通認識となればよいのですが、新入社員を受入れていったりチームが大きくなる段階では流れてしまった振り返りで得られた「自分たちのプラクティス」がストックされないのは、チームの学び・成長に対しての確かな実感としては少々弱いのではないでしょうか?

    そこで私がチームビルディングの考え方でインスパイアされたのが、建築家クリストファー・アレグザンダーの「パタン・ランゲージ」という概念の文脈で語られる、自分達に合わせてチューニングした「プロジェクト・ランゲージ」というものです。

    われわれはスクラムのフレームワークを土台として日々のプロダクトづくりをするわけですが、あくまでそれは汎用的フレームワークであるがゆえ自分達に合わせて最適にチューニングする必要があります。フレームワークにないプラクティスを採用したり新規に自分達のプラクティスを生み出すこともあるでしょう。

    弊チームではそのような組織ローカルなプラクティスの連なり・一連を次のブログで紹介していて一定の反響を頂いておりました。

    https://devblog.thebase.in/entry/bank-practices-2020

    本トークでは、自分達のプラクティス集や日々の語彙をいかに振り返りから育てていくか、チームで実践している実例を紹介いたします。

  • izumi ito
    keyboard_arrow_down

    izumi ito - 目の前のことをひたすらやり続けて起きた変化を見てみかわ

    20 Mins
    Talk
    Beginner

    2021年1月に開催されたRSGT2021のCanDoneLearnという歓談タイムで、私は2021年の抱負としてこう宣言しました。

    「アジャイルコーチになりたいです。そのため一歩として何か行動します!」

    "何か行動"。なんと抽象的な宣言でしょうか。

    早いものでもう半年以上が立ちましたが、まだアジャイルコーチになれていません。

    え、進捗ゼロですか?いえいえ、そうではありません。

    何からやったら良いかわからない、けど何かは行動したいという気持ちはありつつも、コレといって得意なものもない私がやってきたこと。それは

    「ちょっとでもできそうだと思ったらやる」を、ひたすらやる、とにかくやる

    でした。

    1つ1つは小石を積むような簡単なことですが、"何か行動"し続けた結果、私に起きた変化(または変化しなかったこと)をお話します。

     

    本セッションは北海道からオンラインでお話します

  • Noriyuki Nemoto
    keyboard_arrow_down

    Noriyuki Nemoto - 自分達のテストを再考してみかわ

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

    システムテスト、負荷テスト、パフォーマンステスト、あっ探索的テストも…

    みなさんのチームの周りには色々なテストが溢れていませんか?
    スクラムガイドにはあまりテストのコトは書かれていないですが、xxテストの使い方が乱雑になっていると抜け・モレが発生しやすくなります。
    xxテストと書かれていても、人によっては別の概念のことが沢山あります。
    ここではベーシックなテストの整理の仕方をお伝えし、チームメンバー全員がどんなテストが必要か意識できるようになる方法をお伝えします。

    テストを整理するポイント
    ・自分達の言葉を大切にする
    ・テストレベルかテストタイプかテストフェーズかを区別する
    ・それぞれのテストに目的を考える
    ・それぞれのテストに具体的な項目を書いて認識を合わせる
    ・理想は追求しすぎない
    ・いきなり品質特性を使わない

  • Arisa Ishimura
    keyboard_arrow_down

    Arisa Ishimura - 採用を真剣に考えたらチームにマヂで取り組めた話

    Arisa Ishimura
    Arisa Ishimura
    マネージャー
    株式会社GxP
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    私のチームはこれまで、ウォーターフォールからアジャイルに寄せていったり、チームでふりかえりのやり方を改善したりと少しずつステップアップしてきました。
    チームの中で私は全体の遂行に責任を持っており、プロジェクトマネージャー、組織のマネージャー、スクラムマスター、設計者などの帽子をかぶっています。

    そんな中、この1年間は社員のメンバーを増やすため、中途採用に力を入れてきました。
    これまでBP(協力会社)さんに入ってもらうことはあっても、採用はしたことがありませんでした。

    採用をするとなると、転職活動をしている人たちに、私たちのチームの魅力を伝えて、仲間になりたいと思ってもらわなければいけません。
    事実と異なることを伝えたり誇張してしても、入ったらすぐにバレてしまうので意味がありません。
    また、「こう書いたら人が来ないのでは?」と思うようなことは、今チームに居る人たちにとっても、「居続けたいチームではない」と思われてしまう要因になりうるのだとも気づきました。

    採用活動を通じて、チームの状況を捉えなおし、自身の課題を見つめなおすとても良いきっかけになりました。
    まだまだ採用活動継続中ですが、ここまでの学びを共有したいと思います。

    タイトルは「分散アジャイルチームについて考える会」できょんさんが考えてくださいました!
    この話をしてみようというきっかけをくれた、めちゃくちゃ素敵なコミュニティです。

  • Yusuke Uchida
    keyboard_arrow_down

    Yusuke Uchida / Emi Kobayashi - 情熱が消えそうなあなたへ - コミュニティでもらった処方箋たち

    20 Mins
    Talk
    Beginner

    概要

    組織を変えようともがいているけれど、周りとの温度差で情熱が消えそう…そんな悩みを感じたことはありませんか?

    全く異なる組織で組織を変えようと活動する二人が、周りとの温度差で情熱が消えかけてしまうという共通の経験をしました。
    そんな悩みをTwitterでつぶやいたことがきっかけで二人で意気投合し、コミュニティでの相談に繋がり自分を客観視でき世界が変わりました!

    本セッションでは

    • コミュニティでもらった様々な意見
    • 様々な意見を通して得られた気付き
      • 選択肢が増えて自分の今の状態も選択した結果の1つなのだと客観視できる
      • これからの状況も自分の意思で選択できる

    について共有します。

    処方箋

    服用推奨者

    組織を変えようともがいているけれど、周りとの温度差で情熱が消えそうな方

    用法

    ご自身が服用推奨者に該当すると思った時に、ご視聴ください
    複数人でわいわい感想を言いながら見ると、さらに効果が期待できます

    成分

    • 芯の強さ
    • 知識
    • 優しさ
    • ポジティブ
    • メタ認知力
    • うなぎ

    効能

    • 自分の今の状態を1つなのだと客観視できる
    • 他の選択肢を知り、視野が広がり不安を和らげる作用

    注意事項

    症状を改善する一例なので盲信にはご注意ください

  • Yui Nakanishi
    keyboard_arrow_down

    Yui Nakanishi - 非ソフトエンジニアばかりの研究部署でスクラムを使ってアプリ開発に挑戦してみたら組織もアプリもハッピーになった話

    Yui Nakanishi
    Yui Nakanishi
    Developer
    株式会社デンソー
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    本セッションでは、株式会社デンソーの研究部署で材料研究者がスクラムチームを立ち上げ、Webアプリの開発をしてみたら組織もアプリもハッピーになった話をします。

    スクラムに全く馴染みのない部署・メンバーで初めてソフトウェア開発をすることになったとき、日頃からスクラムを取り入れているチームでは起こらないようなギャップが起こります。例えば研究部署では個人の取り組みを重視する考え方が色濃く、チームの成果よりも個人の能力が尊重されていたり、プロジェクトは基本個人持ちであったりと、システムや考え方がスクラムとは合致しないということがあります。わたしたちのチームで実際に起こったギャップと乗り越え方、スクラムを取り入れたことによってどうハッピーになったか、スクラムチーム発足からのタイムラインに沿って話していきます。

  • Kei Ogane
    keyboard_arrow_down

    Kei Ogane - 一年半同じチームで色んなふりかえりをやったので手法と学び紹介していく

    Kei Ogane
    Kei Ogane
    engineer
    for Startups, inc.
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    一年半程同じチームで色んな手法でふりかえりをやっています。
    最初はKPTだけをずっとやり続け、ふりかえりの雰囲気もお通夜みたいでしたが、
    途中から毎回のように手法を変え、その結果どんどんふりかえりとチームの雰囲気が良くなっていきました。

    このセッションではそんなチームが変わっていった様子を伝えるとともに

    • ふりかえりを色んな手法でやることのメリット
    •  色んな手法をやる中で見えてきたふりかえりの色んな側面
    •  チームで経験した15のふりかえりのやり方とチームメンバの感想、どんな感じだったか

    を紹介していきます。

  • Tomonari Nakamura ( ikikko )
    keyboard_arrow_down

    Tomonari Nakamura ( ikikko ) / Shinnosuke Yata - えっ、まだユニットテスト書いてない現場があるんですか?~ ボトムアップでもっといけてるチームになるために、たった一つの大事なこと ~

    45 Mins
    Talk
    Intermediate

    アジャイルなソフトウェア開発を効果的に進めるためには、「ライトウィング」と「レフトウィング」の両輪が必要になります。

    • レフトウィング:協働でゴールに向かう「チーム環境」
    • ライトウィング:高速に石橋を叩いて渡る「開発環境」

    私達の現場では、レフトウィングについては、アジャイル向きなマインドセットを持ったチームメンバーが多いことと、アジャイルコーチ・スクラムマスターの支援によって、チーム環境の継続的な改善を進めることができています。ですが、ライトウィングについては、バージョン管理や継続的インテグレーションなどは実践していたものの、特に自動ユニットテストが十分に用意されておらず、そのことによってコードの保守性への大きな懸念が存在していました。

    本発表では、ユニットテストを根付かせるために、チームメンバーとスクラムマスターがタッグとなって行ってきた以下の2つの取り組みについて紹介します。これらの取り組みを推し進める際にどういうことを考えていたかや、取り組み後の周りからの反応や効果についても触れたいと思います。

    • 社内TDD Boot Campの開催
    • ユニット環境の整備
help