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

品質を向上するためにテスターや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を進めるチームによくある【問題】を例に、【問題】を捉えなおすことによっておきる嬉しい変化についてお話します。

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

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

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