老舗大手製造業生まれの新規SaaSビジネスが1年目で直面した成長の壁、
モダンアプリ開発会社が加わり組成した新スクラムチームが、ビジネス貢献に取り組み続けて成果を上げ始めています。

「変化を目指す」老舗事業会社のPOと「変化を加速する」開発会社のScMが、体験や事実、その裏側にあった仲間の支援など、対談形式も交えてお伝えします。

「スピード優先で事業化にこぎつけスタートしたSaaSプロダクト。その結果プロダクトが、早晩スケーラビリティや持続性を担保できず足踏み状態になる」…そんなビジネスあるある。

今回題材となるSaaSプロダクトも、スピード優先でビジネスを始めた当初は数十社の顧客と密にやり取りを行い、フィードバックを製品に反映しながら良好な立ち上がりに見えました。
しかし顧客数が増えるにつれ、事業会社が進めていた日曜大工的開発では開発スピードや品質が市場要求に追いつけなくなっている状態に、事業会社POは悩みます。
（悩みの一例）
・PoCの延長で開発されたプロダクトのテスト、デプロイが人力依存で非効率な状態
・インフラやアーキテクチャが大規模顧客を考慮していない中でのエンタープライズシフト企画
など。
せっかくビジネスが拡大しそうなのに、さてどうしたものか。。。

組織的な改善を水面下で続けていた老舗大手企業とモダンエンジニア集団が出会い協力しスクラムに取り組んだ軌跡

登壇するPO、ScMが本プロジェクトで大切にしてるマインド

[ PO ]

対話を通してビジネスが目指していく姿、変化していく市場の生の声、背景を伝え続ける

[ ScM ]

POを含めたステークホルダへの状況の見える化と対話の機会を明示的に増やして活用してもらう工夫をしました

テスターを含むチーム全体（Whole-Team）で、プロセスやプロダクトに品質を作り込む（Build quality in）にはどうしたらよいでしょうか。
Janet Gregory とLisa Crispinによるこの動画では、W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」と、それをアジャイルな職場で実践する方法について詳しく学べます。

W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」で以下の2つの原則はJanetのお気に入りです。

• quality is everyone's responsibility（品質はすべての人の責任）
• improve quality you automatically improve productivity（品質を向上させれば、自動的に生産性も向上する）

また、Janetがオリジナルで提唱する原則が以下の2つです。

• if you focus on quality the speed will come（品質にフォーカスすればスピードが出る）
• if you focus on speed the quality gets lost（スピードにフォーカスすれば品質が失われる）

アジャイル環境において品質を考えると、「プロダクト品質」と「プロセス品質」の関係が重要となります。
JanetとLisaは以下のような内容で特にプロセス品質についてトークします。

１．Question Askerであるべき
２．例やテストを使って開発をガイドする
　・magic bubble（魔法の泡）　コード・テスト・自動化
　・Acceptance Testのループ（受け入れテスト作成→テストの拡大→自動化担当者とペア→テストメソッドの作成→何をテストするのかを明確化→TDDサイクル→ハッピーパスが通るまでリピート→探索的テスト）
３．エクササイズ（ユーザーストーリーからテストを考える）
４．アジャイルテスティングの4象限を使ってテストを把握する
５．探索的テスト、品質属性のテスト、スライディング・スケール
６．コアプラクティスを使う
　・継続的インテグレーション
　・テスト自動化
　・機能やストーリーの優先順位付け
　・ビジネス価値を頻繁にデリバリー（いつでも出荷可能なリリース候補を用意する）
　・品質をデリバリー（コアプラクティスを用いて、会社やチームのあらゆる部分で品質を構築）

（あとでちゃんとかくかもしれない）

2010年にフロリダで開催されたAgile conferenceに参加していらい、「よりアジャイルなチームを作るためには？」を考え続けてきたようにおもいます。僕の関心は常に「アジャイル開発」です。

当初は企業内のアジャイルチームとして活動し、のちにアジャイルコーチと名乗るようになり、開発現場に立ったり、チームや組織開発を考えたり、「どうやったらもっとアジャイルになるか」を考え続けてきましたが、今もアジャイルコーチとして新しい現場に立つたびに、10年前と変わらず悩み続けています。

10年の経験を得て、これまでにできてきたこと、まだできていないことをふりかえりながら、次の10年をスーパーアジャイルコーチとして現場を成功させ、その次の10年でウルトラアジャイルコーチとして過ごすために必要なことを考えるセッションです。

ベトナムでは COVID-19 が世界的に流行する以前より、日系企業のオフショア開発の縮小・撤退が散見されるようになってきました。ベトナム経済の継続的なえげつない高度成長により（コロナ禍でもGDPプラス成長）、コスト上昇が著しいのは事実です。コスト、品質、そのバランスなど悩みどころはたくさんあります。

ベトナムの開発では日系企業の場合、基本的には、通訳を通じての日本語もしくは直接英語でやり取りを行いますが、

言葉が通じることと、話しが通じることは違います。

要件を正しく伝える・相手の言いたいことを正しく理解する。ごく基本的で大切なことですが、特に国を超える場合、思考の背景にあるコンテキスト（カルチャー）を理解することが重要です。お互いが。

私は2014年12月からおよそ6年半、

• ハノイ、ホーチミン
• 案件を出す側・受ける側
• 保守運営案件、新規案件、自社開発案件
• ラボ型開発、受託開発
• エンジニアがいるクライアント、いないクライアント

など様々な組み合わせで、PM、エンジニア、人事、経営などの立場でベトナムに関わってきました。

Made in Vietnam のソフトウェア開発を世界品質にすべく活動するなか、試行錯誤してきたこれまでの取り組み、現在の取り組みをシェアしたいと思います。

スタートアップ企業のソフトウェア・サービス開発や、大手企業の新規事業開発を支援するSun Asteriskの開発拠点はベトナムにあり、約1500名の開発体制では常に110を超えるプロジェクトが同時に動いています。

私達は最近までプロダクトを高速でデリバリーすること強みとしてきましたが、最近では”品質”を次のテーマとして取り組んでいます。
品質が企業に与える影響は経営において非常に重要なものであり、その影響は長期的であると考え、
私達のビジネスモデルの特性をふまえてQA2AQやAgile Testingなどを参考に、以下の観点でSun*のアジャイル品質定義と品質改善活動に取り組んでいます。

    1. 私達が提供するべきプロダクト品質 (技術/製品品質)
    2. 顧客が私達に期待するプロダクト品質 (技術/製品品質)
    3. 顧客がEnd Customer / Userに提供するべきサービス品質 (製品品質)
    4. End Customer / Userがサービスに期待している品質 (特に製品品質)

今回はそんな私達の取り組みについてご紹介させていただきます。

#Agile mindset #QA2QA  #AgileTesting  #Scrum #GIST Planning

「ユニコーン企業のひみつ」。この本はとても読みやすいんだけど、でもそれって…自分と違う星の話を眺めてる気分だからじゃないのかな（仮説）。

私たちのチームと本で紹介されているチームの様子は、まるで地続きみたいによく似ていてます。本講演では「ユニコーン企業のひみつ」を使って私たちのチームについて説明を試みます。この本を自分のことのように受け止めた人たちの助けになれば良いな、と思います。

「どういう人がスクラムマスターをやればいいんだろうか？」

この質問はチームがScrumに取り組もうとした時によく出てくることの1つです
Scrumにあるプロダクトオーナー、スクラムマスター、開発者の3つの役割のうち、特にスクラムマスターはわかりにくいようで、この冒頭の質問が出てくるようです

しかし、一方で、ScrumGuideには以下にあるようにスクラムが機能するにはとても重要な役割を果たします

では、どのような人がスクラムマスターに向いているのでしょうか？
またプロダクト、チームや組織の状況によってどういうような人がスクラムマスターをするとより良いのでしょうか？

このセッションでは、「どういう人がスクラムマスターをやればいいんだろうか？」という質問に、ギルドワークスの現場コーチとして70チーム以上(すべてにスクラムマスターがいたわけではありませんが)を支援してきた事例から自分なりの経験や考えをお話できればと思います

よりよいスクラムマスターと出会える、見つける、なっていくヒントになれば幸いです

Smells like Agile Spirit: A fun way to learn some agile principles

This paper tries to present and tech some principles of agile, Scrum, TPS, less and so forth in a fun and entertained way doing a little match to Nirvana songs name or lyrics. This work came up when I had to work with 90s people and build agile ways of working. I like Nirvana music so I apologize nirvana fans if some of the songs do not mean what I present here, I tried to do the litle match forcing some times and using my imagination in others. Hope it can help you if you face similar challlenges.

In this talk I share Game Driven Development which is a game design framework to apply for wotking with development teams as part of team inception. The framework looks for gamify software development so learning, fun, improvements and building new ways of working can be optimized.

Agile Architectures makers: Enabling an agile and lean approach to the modeling, development, and evolution of an architecture at scale

This paper aims to share some practices and experiences to build an agile architecture at large enterprise working with development teams, software architects and technical leads and how this agile approach at architecture and system design ends helped us to scale agile and meet the real-world needs of modern organizations. WARNING: This papers summarized the experiences from agile coaching participation and we hope that hardcore developers appreciates it : )

みなさん、ふりかえりは楽しんでいますか？
うんうん、いいですね！私はすっっごく楽しんでいます！！

この2-3年、ふりかえりのことを発信する人たちが増えてきました。
日本で初開催された  ふりかえりカンファレンス では、22名もの人がふりかえりの想いや新しい手法を語っています。
また、ふりかえりamでも、Podcastの中でゲストが様々な手法を紹介してくれ、新しい手法も生み出されています。

日々、新しい手法が生み出されているふりかえり。

このセッションでは、近年生み出された手法を紹介していきます。
どれも楽しくわくわくする手法ばかりですので、気になる手法を真似してみてくださいね！

達人たちが見ている世界を覗いてみませんか

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

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

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

プロダクト開発は難しいですよね。コミュニケーションとスキルがとても必要です。よくストレスいっぱいあります。

でも、もしプロダクト開発がゲームだったら・・・

コーチとして、開発チームと仕事を面白くなるためにたくさん実験を作りました。

そのプレゼンには、アジャイルか開発を楽しくなるコツとゲームを紹介します。

アジャイルの浸透によってプロダクトがアウトカムに目を向けることの重要性が認識されるようになりました。では、従来型の開発プロセスで10年以上開発を続けてきたプロダクト開発チームは、どのように取り組めばアウトカムに目を向けたアジャイルな開発に転換できるのでしょうか？

今から2年前、10年以上の歴史を持つプロダクトが新たなビジネス領域に参入するためにチームを再結成して新機能を開発していくことになりました。正解がないレッドオーシャンのビジネス領域に飛び込んだ我々はまず開発プロセスをアジャイルに転換する必要性を感じてスクラム開発を取り入れようと試行錯誤していました。そんな中、関西でアジャイルコーチとして活動されている中村洋さんと秋元さんが開催していた相談会をたまたま見つけて相談しました。そこでホワイトボードの中央に書かれた言葉が「アウトカム」でした。

何のためにプロダクト開発をアジャイルにするのか？開発プロセスを変えてアウトプットを増やすだけではなく、ビジネスの成果＝アウトカムにつなげなければ我々の課題は解決しないと気付かされました。「アウトカムは何か？」を問いかけ続けてプロダクトを成長させていくことがアジャイルの本質だと気付きました。

アウトカムを得るためにはプロダクトとその顧客をよく知る人の存在が重要だと考えました。そこで、チームで一番のベテランエンジニアが経験ゼロからプロダクトマネジメントを担当することになりました。そこから1年間、まずは開発チームにスクラムを取り入れて、新体制のアウトプットを安定させる事に取り組みました。その間にプロダクトマネージャーはスクラムのプロダクトオーナーとしての振る舞いを学びました。そして2年目、プロダクトのアウトカム創造をチーム目標に設定して本格的にプロダクトマネジメントに取り組みました。

2年前の再結成からチームのマネジメントを担当しているエンジニアリングマネージャーと、自身も新たなステージへ飛び込んでチャレンジしているプロダクトマネージャーが、アジャイルを取り入れてプロダクトのアウトカム創造に試行錯誤してきたチームの取り組みについてそれぞれの視点でお話しします。

ふりかえりが少しずつ認知されてから、様々なところでふりかえりの重要性が叫ばれてきました。ただし、どう始めたらいいのか、どう定着までに至るのか、道のりはあまり述べられてきていません。

ふりかえりは、チーム全員で定期的に立ち止まり、チームがより良いやり方を見つけるために話し合いをして、チームの行動を少しずつ変えていく活動です。

COVID-19とリモートワークの加速によって、これまで顔を合わせて働いていたチームも、直接会って仕事をする機会は今後も減っていくでしょう。これから新しくチームを作ることも今まで以上に難しくなっていきます。

そんな世界の中でも、変化に柔軟対応でき、価値を生み出し続けられる「アジャイルなチーム」。そして、それを作るための一歩目である「ふりかえり」と、その導入をガイドします。

このセッションは「Developers Summit 2021（デブサミ）」でベストスピーカー賞8位を受賞したセッションの再演です。
ただし、アジャイル・スクラムの知識を前提として導入部分をバッサリカットし、デブサミではお話のできなかった＋αの内容をあわせてお届けしたいと思います。

このセッションでは，大学のPBL（Project Based Learning）でリーダーのいない組織を形成し，その活動の中でどのようにチームが成長してきたかをお伝えします．

いま，日本の大学ではPBLという学習方法が広く実施されています．PBLとは，実際にプロジェクトチームを形成してプロダクトを作る経験を得ることによって，チーム開発やチームマネジメントの手法について学ぶことができる学習手法です．私が所属する大学でもPBLのカリキュラムがあり，スクラムを用いてプロダクトを作るという経験を得ました．しかし，私たちのチームはほかのチームとことなりリーダーを決めずに活動してきました．そして，その結果として，とても良いチームを形成できたと感じています．

リーダーもいなく，開発初心者が集まるプロジェクトで，どのようなことに苦労したか紹介・分析し，どのようにいいチームに進化することができたのかお話ししていきます．

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.

Intro

　現代社会学の本を読むと、ある言葉をよく目にします。それは「機能主義」という言葉です。これは、各役割を担当する人の集合体として社会を理解するというもので、生き残るために細胞が進化を重ねるように、社会も僕たち人間が状況に合わせて絶え間なく仕組みを変えていくという概念です。

スクラムも同じ観点で理解することができます。人の集まりであるスクラムチームがどれだけアジャイルに時代のニーズに対応できるかで集団の運命が左右されます。僕はここでスクラムの成功の鍵として、スプリントの期間に注目したいと思います。

スプリントの期間は絶対的なものではありません。よくプロダクトを子どもに例えることがありますが、まさに年齢によって子どものしつけを変えるのと同様に、状況によって常に見直しされるべきものがスプリントの期間です。

このセッションでは、最適なスプリントの期間を探すために考慮すべき要素は何か、どういう時に期間の見直しをしないといけないかなどの考察を行います。

時間の経過により変化し続ける条件のコントロールに対し、スプリントの期間がどれだけ重要なものか。

この２０分間の考察で成功の鍵を見つけられるように、みんなで一緒に頑張りましょう。

アジャイルでは、なぜ支援者がトレーナーではなくコーチなのか？
どっかに引っかかりを感じながら、でも、なんとなく見ないふりをして、アジャイルコーチのマネごとをしてきました。
アジャイル支援サービスを構築して、販売して、徐々にお客さんからも評価いただくうちに、
自分がやっていることが本当にアジャイルコーチなのかに自信を持てなくなってきました。

ある日、流石に見ないふりが苦しくなって、
コーチを探し始めたら、わざわざ時間をとってたくさんのコミュニティの仲間が相談に乗ってくれて
スーパーコーチのAkiさんにたどり着きました。

現時点では導入となる6回のセッションが終わった段階、
旅の途中ですが、同じもやもやを持っている方に何かの助けになればと思って、自身の体験を共有します

※発表内容は個人の主張・主観であり、所属している組織とは関係ないものになります

スプリントプランニングってどうやってやったらいいか、モヤモヤしていませんか？

スクラムガイドを読んで、又は認定トレーニングを受けていざスクラムやっていこう！となったとき、実際にやってみると具体的にはどうやって進めたらいいかわからない、ということがスクラムには多いのではないかと思います。

「プロダクトバックログってどうやって作るの？」とか「自己組織化って何から始めたら？」とか「Doneの定義って具体的に何？」とかいろいろありますが、中でもワカラナイ代表の一つとしてあげられるのが「スプリントプランニングってどうやるの？」じゃないかなと思っています。

私自身もトレーニングを受けてから見様見真似でスプリントプランニングをやっていましたが、
「今までやってたWBSと何が違うんだ」
「タスクってどの単位で切るの？細かくするにも限界が・・・」
「なんかしっくり来ないな」
という感じでモヤモヤしていました。

それでもなんとか試行錯誤を繰り返していたら、チームの学びとして一つのやり方が確立できてきて、スプリントプランニングの役割もなんとなくしっくりきたな、と思えるようになったので、そのあたりを共有していきます。

これが全てではないけれど、きっと誰かの参考になるだろうと思います！