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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そこで！

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

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

セッション中は

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

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

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

【お話の背景】

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

それは、

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

ということ。

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

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

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

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

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

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

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

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

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

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

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

----

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

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

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

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

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

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

『教育心理学概論』という書籍があるのはご存じかなと思います。この書籍を書いた三宅なほみ先生は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

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

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

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

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

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

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

それは社内からです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スクラムマスターの役割はなんとなく理解しているけど、実際何しているの？実際の現場では様々なスクラムマスターがいます。チーム作りが得意なスクラムマスター、スクラムにおける技術プラクティスの導入が得意なスクラムマスター、プロダクトオーナーの戦略づくりの支援が得意なスクラムマスターなどなど。

専任のスクラムマスターを1年半以上やってきたぼくが実際に普段やっていることを説明することで、One ofスクラムマスターの具体的な動きについて理解していただくとともに、スクラムマスターの組織における動きの違いについて探求できればと思います。

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

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

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

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

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

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

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

昨年、部署内でコミュニティ「もぐもぐ会」の立ち上げにチャレンジしました。

このコミュニティは、部署でのトップダウンの施策ではなく、2人の社員が自主的にボトムアップで開催を始めたものです。

このコミュニティはチーム間の交流や知識の共有を目指したものであり、現在9ヶ月隔週で継続しています。

コミュニティを立ち上げてみて、LTや勉強会などさまざまな事を行なってきました。

本セッションでは実際に社内でコミュニティを運営してよかったこと、課題と今後の展望についてお話しできればと思います。

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

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

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

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

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

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

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

でした。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

概要

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

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

本セッションでは

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

について共有します。

処方箋

服用推奨者

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

用法

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

成分

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

効能

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

注意事項

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

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

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