現代のソフトウェア開発は、ソフトウェアやサービスが密接に一体化してプロダクトを構成しています。

質の高いプロダクトを生み出し続ける一つの方法は、プロダクトと開発チームの間や開発チーム内部、複数の開発チームの間、ユーザと開発チームの間にある組織結合度について、実質的な密結合と疎結合のバランスを上手にデザインしカイゼンすることだと私たちは考えています。

プロダクトバグの原因になる組織バグは、
工数が足りないから密結合になるべき組織結合度を疎結合にしようとして必要なコミュニケーションを無理に減らしたり、
やらされ感やこなし感にコミュニケーションがまみれ実質的に疎結合化してしまっていたり、
不必要な自称ステークホルダーを排除できず疎結合化できなかったためにノイズが増えて優先度などの意志決定がブレるなど、
密結合と疎結合のバランスの崩れの現象が起きていると捉えられるからです。

我々SEA-SIGSQAでは、疎結合と密結合を上手にバランスさせるための大事なマインドセットの一つとして「納得感の共感」を挙げています。

本講演では、ユーザ・プロダクト・開発に関わる組織において網の目のように“納得感の共感のチェーン”をたくさん構築するというアイデアをお話ししたいと思います。

伝統的なテストや品質保証では、カバレッジ達成やプロセス準拠といった品質基準が一人歩きしてしまい、プロダクトや組織の質の低下につながった現場もありました。

一方アジャイル開発では、アジャイルテスティングやHolistic testing、Whole-team approachという技術やアプローチが提示されていますが、まだそれらは局所的だったり部分的なプラクティスとしてしか理解されていないような気がしています。

私たちは、網の目のように張り巡らされた“納得感の共感のチェーン”がアジャイルテスティングやHolistic testing、Whole-team approachを動かす組織の大動脈や静脈、毛細血管から構成される血管網になり、優れた品質文化を醸成していくと考えています。

すなわち、プロダクトに対する開発チームの納得感の共感が品質保証の基礎となり、開発チームの内部（現場）での納得感の共感がよいチームとなり、
複数の開発チームの間での納得感の共感が上手な大規模化を導き、経営層と開発チームの間での納得感の共感が持続的な進化につながっていくわけです。

この講演によって理解が進み、納得感の共感によって組織バグを低減させることで、アジャイル開発における品質保証を上手に進めていただければと願っています。

私が経験した中でもっともハードな「人の気持ちになるワーク」をRSGTの参加者の皆さんだからこそ届けたい。
説明や本だけでは得られない実感を味わい、見えていたのに見ていなかった視界を手に入れて下さい。

スクラムやアジャイルに限らずさまざまな場面で「共感する」「相手の気持ちになる」「相手の立場になる」という言葉を聞きます。いったいどうなれば「共感する」「相手の気持ちになれた」「相手の立場になれた」と言えるのでしょうか？この問いに対して、私が持つ一つの答えであるワークショップを行います。

RSGTを終えたあと
1on1や家族との対話で今まで以上に相手の考えが理解できるようになったら嬉しくありませんか？
同僚の内面から自分を見て、同僚に伝わる言葉を使えたら嬉しくありませんか？
「お前は人の気持ちがわからない」と言われていたのに、人の気持ちがわからないのは「お前は人の気持ちがわからない」と言っている人だったと気づけたら、対策が取れるようになりませんか？

このワークショップでは実際に相手の立場と自分の立場のそれぞれに自分で立って対話をしてもらいます。有意識下では「気づいていなかった」「気づきたくなかった」相手や自分の考えや主張が見えてきます。あくまで貴方が持っている相手の情報から相手を推測するに過ぎません。しかし、無意識ではわかっていた、気づいていなかったことはたくさんあります。今、時点でわかり得る情報を元に全力で「相手の気持ち」を考えてみましょう。

• ある人は上司と向かい合い、上司が常々言っている良い評価を受け止められるようになった。
• ある人は配偶者と向かい合い、目を瞑って避けていた配偶者の思いを少しずつ受け止められるようになった。
• ある人は義母と向かい合い、夫婦と義母の軋轢を解消する糸口を見つけ出した。

このワークショップでは、参加者ペアで行い、参加者にとって実在する相手を題材に行います。大っぴらに言いづらい事を言わざるを得ない場合があるのでご注意下さい。お互いの加えて守秘義務を守ってご参加下さい。

体感してもらう場であり、やり方を教授する場ではありません。やり方を身につけたい方は専門家の支援を受けてください。

QA（品質保証）の組織や体制をつくろうと考えるCTOやVPoE、EMが増えてきました。とはいえ、QAの組織や体制のあり方はQAメンバのスキルや開発チームの状況、プロダクトの特性、ドメインに求められる規制、自社の文化などによって千差万別です。また、つくった後もどんどん変化していく必要があります。そこで私たちSIGSQA-jpでは、QAの組織や体制をつくる時に見通しよく捉えるために、QMファンネルとQAスタイルファインダーを使ってみてはいかがかな、と考えています。QAの組織や体制に悩むCTO・VPoE・EM、開発マネジャー、一人QA、経営者の皆さんの助けになれば幸いです。

Scrum/Agileといった短いSprintで開発をしていくと、テストも少ない工数の中で行なっていく必要があります。

少ない工数でテストを行うにはどのような工夫があるでしょうか？

もしかしたら「自動テスト」と考えた人もいるかもしれません。確かに自動テストも工数削減の可能性がある方法の1つです。

ただし自動テストだけでなく、テスト設計技法の適用も工数削減の工夫の1つです。

本セッションではテスト設計技法に注目し、お題を解いてもらいながらテスト設計技法について理解してもらおうと考えています。

「今までなんとなくテストをやっていたんだけど、うまくいかないな…」「なんか結局膨大なテストケース数になって、毎回大変なんだよな…」という人はぜひ本セッションでテスト設計技法を体験してみませんか？

皆さんは、どんな目的でScrum Fest Niigataに参加することにしましたか？

• Agile/Scrumのことをもっと学びたい！
• テストのことをもっと学びたい！
• 新潟のお酒を楽しみたい！

色々な目的があると思います。

そこにさらに、初開催であるScrum Fest Niigataに参加した仲間のことをもっと知りたいという目的を加えてみませんか？

本セッションでは、ポジションペーパー（立場表明書）を用いた自己紹介を行うワークショップを用意しました。

本セッションに参加することで、お互いのことをもっと良く知ることができるはずです！

スクラムやアジャイルに限らずさまざまな場面で「相手の気持ちになる」「相手の立場になる」という言葉を聞きます。いったいどうなれば「相手の気持ちになれた」「相手の立場になれた」と言えるのでしょうか？この問いに対して、私が持つ一つの答えであるワークショップを行います。

このワークショップでは実際に相手の立場と自分の立場のそれぞれに自分で立って対話をしてもらいます。有意識下では「気づいていなかった」「気づきたくなかった」相手や自分の考えや主張が見えてきます。あくまで貴方が持っている相手の情報から相手を推測するに過ぎません。しかし、無意識ではわかっていた、気づいていなかったことはたくさんあります。今、時点でわかり得る情報を元に全力で「相手の気持ち」を考えてみましょう。

このワークショップでは、参加者ペアで行い、参加者にとって実在する相手を題材に行います。大っぴらに言いづらい事を言わざるを得ない場合があるのでご注意下さい。お互いの加えて守秘義務を守ってご参加下さい。

体感してもらう場であり、やり方を教授する場ではありません。やり方を身につけたい方は専門家の支援を受けてください。

スクラムチームが「うちのQAなんなん？」と思っている状況は意外に多いと思います。その原因の一つは、QAのスタイルがチームや組織に合っていないことにあります。今回は、チームや組織にアジャストできるようQAのスタイルを診断する「QAスタイルファインダー」というツールを紹介します。またSIGSQA-jpのメンバによる、アジャストできている組織やそうでない組織のリアルエピソードを交えながらのトークタイムを楽しんで聞いて頂ければと思います。

スクラムで品質に悩んでいるチームや組織へのアプローチを整理する話をします。

品質を向上するためにテスターやQAエンジニア、SETやSREを増やそうとする組織は多いですが、スキルセットやキャリアパスをどのように決めていけばよいのかについて困っているところも多いと思います。また、当面はテストを外部発注してしのぐとしても、どう内製化するか、どうスケールするか、どう組織全体に根付かせていくか、について悩んでいる組織も多いと思います。

そうした悩みを解決するために、本プレゼンテーションではQMファンネル（3D版）を使って整理するお話を紹介します。

頂点が下向きになっている三角錐を想像してください。まず三角錐の側面はエンジニアのスペシャリティ（得意技）です。スペシャリティをTE（Test Engineer、いわゆるテスター）、QA（Quality Assurance、いわゆる品質保証）、DA（Delivery Accelerator、いわゆるSETやSRE）の3つに分けて整理します。もちろん、それぞれのスペシャリティがサイロ化しないように、側面の境界をスムーズにするような境界的なスペシャリティも考えないといけません。

次に、三角錐の深さはレンジ（範囲）になります。レンジを、外部発注したり専門組織によるサービスという役割分担から、スクラムチームの内部だけで頑張るインプロセス、チームと一緒に開発しながら高度なスペシャリティを浸透させるコーチ、それぞれのチームの外部からスペシャリティを移転するコンサルタント、組織全体にスペシャリティを浸透させていくプロモーターといった5つのレンジに分けて整理します。

品質を向上するには、TE、QA、DAの3つのスペシャリティが全て必要です。これらをまとめてQM（品質マネジメント）として捉えることで、バランスのよい品質向上が実現できます。同時にオールレンジの活動を意識することで、組織全体でバランスよく品質向上を浸透させることができます。

またQMファンネルは、伝統的なプロジェクトのようにPMとエンジニアを区別する考え方ではないという点にも注意する必要があります。スクラムチームでは、テスト計画・テスト設計・テスト実行を分割してサイロ化させるのは得策ではありませんし、コンサルタントやプロモーターが偉いわけでもありませんので。

私たちのQMファンネル（3D版）について聞いて頂いて、皆さんの組織の品質がスムーズに加速できればとても嬉しく思います。たくさん議論させてくださいね！

あなたのチームは「こんなテストでいいのかな？」と不安を持ったことがありませんか？
あなたの組織は「これが我々の品質保証だ！」と自信を持って進められていますか？

• スクラムチームのテストが上手くいっていない感じがするが、打つ手が見つからなくなってきた
• 所属している組織の品質を上げたいが頭打ち感がある
• テストや品質保証で外の力を借りようとしたが、イマイチだった（上手くいかなかった）

この発表では、ソフトウェアテストや品質保証に漠然とした悩みや不安を抱えている方に向けて、自信を持ってテスト活動を進めていくスタートラインをいくつかの例を使ってお伝えします。

この発表で扱う予定の例：

• テストケースを行き当たりばったりで作り続けてきたが、増やしても増やしても不安が消えないチーム
• あるチームで行ったテスト自動化を組織に横展開してみたが、メンテナンスコストが増える一方で品質が上がっている気がしない
• プロダクトの開発規模拡大のために外部のテスト専門会社にテストを依頼したが、期待したようなテストをやってもらえなかった

この発表で特にお伝えしたい点：

• テスト・品質保証のスキルは大きく4つに分類できる
  • Domain Knowledge：ドメイン知識…プロダクトに関わる固有知識・技術
  • IT Skills：ITスキル…開発そのものの技術（テスト自動化の環境構築なども含む）
  • Test Skills：テストスキル…モデリングやロジカルシンキング、パターン化能力、質問力などの技術（※ひたすら入力・打鍵・実行する作業スキルではない）
  • Soft Skills：ソフトスキル…コミュニケーションやファシリテーションなど他のスキルの下支えとなる技術
• どのスキルを使っているか？重視するか？を分析することで漠然とした不安から抜け出せる
• 足りないスキルを埋めるために何ができるか
• ソフトウェアテストは広大だ！

あなたが抱えるソフトウェアテスト・品質保証の漠然とした不安や頭打ち感を、この発表を通して一緒に紐解いてみませんか？
自信を持ってテスト活動を進めるためのスタートラインに一緒に立ちましょう！

• 「社内にアジャイルを広めたいが、中間管理職が障壁になって広がらない」
• 「マネージャーを説得するのに多大なコストを払い、開発に集中できない」

大企業や従来型企業でアジャイル開発を推進する方々から多く聞く悩みです。

今回は、普段からこの悩みに日々向き合うGraat(グロース・アーキテクチャ＆チームス)のコンサル/コーチ陣が、解決の方向性や事例について、豊富な経験を交えながらディスカッションします。

もちろん、皆様からのご意見やコメントも大歓迎です!!

(このセッションはスポンサーセッションです。)

「なんで？」「どうして？」というという問いは時に凶器になります。

「なんで（私が言った通りにやらないんだ）？」
「どうして（そんな風にしてしまったんだ）？」

そして時に問いという形で指示や命令をすることにもなります。

「こないだ説明しませんでしたっけ？（説明した通りにちゃんとやってくださいよ）」
「これでどうですか？（もう何回も直してるんで、そろそろOK出してくださいよ）」

問いと上手にお付き合いするためには、問いを立てる対象の観察が必要不可欠です。
同時に自分自身を観察する（ふりかえる）という必要もあるかもしれません。

ある一場面を観察したとき、いままで経験してきた物語が違う人たちの間で、その場面をどう捉えるか？
さまざまなコンテキストの違いによる物語の幅にフォーカスすることで、よりよいコミュニケーションや問題解決ができるかもしれません。

「観察」を体験し、「物語を捉える問い」を考えることで、よりよい未来を創るファシリテーションの入り口に立ってみましょう。

※テストエンジニア向け（WACATE2019冬）に実施したワークショップをベースに、XP祭り向けに改変して実施します。

【問題 vs 私たち】で考えることが大事！というのは、DevOpsを進めているようなチームであれば当り前のことでしょう。
日々、立ち向かう【問題】を「どう解決するか？」ということに頭を悩ませ、チームでよりよい解決策を考えて改善活動を継続的に行っているかもしれません。

ところで、

立ち向かっている【問題】が、本当に今あなたのチームが立ち向かうべき【問題】か？
その【問題】が解決できた時にチームが辿り着けるゴールはなにか？

と考えたことはありますか？

• 【問題】に対して効果的なTry/Actionが出せない
• 【問題】に立ち向かい続ける改善のサイクルは回しているが終わりがみえない
• 立ち向かう【問題】が見当たらなくなってしまった

と悩んだことはありませんか？

様々なチームの支援を行っていると、次のような光景に出会うことがあります。

• 目についた【問題】と次々に戦い続けていて、チームがレベルアップした実感が持てずに改善疲れをしている
• まだチームで【問題】に立ち向かうプロセスが出来上がっていない段階でラスボスのような巨大な【問題】と戦って疲弊している
• 次に立ち向かうべき【問題】が見つけられず、改善活動やチームの成長が停滞している

こんな時は【問題】を「どう解決するか？」を考える前に、チームが立ち向かうべき【問題】が「なにか？」を見極めることが大切です。

DevOpsを進めるチームによくある【問題】を例に、【問題】を捉えなおすことによっておきる嬉しい変化についてお話します。

また、チームで【問題】に立ち向かうプロセスをどのように構築していくか？についても言及します。

あなたのチームが【問題】に立ち向かいながらレベルアップし、楽しく改善を進めていくヒントを持ち帰っていただければ嬉しいです。

改善疲れから抜け出し、チームが自信をもってレベルアップした！と実感できる活動にシフトしていきませんか？