What is G.O.O.D. Testing? And why is it Important for Everyone?

G.O.O.D.テストとは何か？そして、なぜそれが誰にとっても大切なのか？

Whether your testing involves automation or manual testing, agile or traditional methods, dev ops or waterfall or whatever the context, the importance of not only the craft of testing but also the impact of testing and its purpose is worth considering. For years, we have been looking to make testing more efficient and more automated which of course has its obvious advantages, but what aspects of testing have not yet been developed? What good is it to remove defects out of systems that are at their core designed poorly or designed for questionable purposes? Is testing helping or hindering humanity if it enables systems that are designed dangerously or have hidden elements that hinder basic rights of their end users or have impact on important issues such as privacy, security or confidentiality.

テストが自動か手動か、アジャイルか伝統的な手法か、DevOpsかウォーターフォールか、どんな文脈であれテストの技術だけでなく、テストの影響とその目的の重要性は考える価値があります。何年もの間、私たちはテストをより効率的に、より自動化することに目を向けてきました。もちろん、明らかな利点はありますが、テストのどの側面がまだ開発されていないのでしょうか？コアの設計が貧弱だったり、疑わしい目的のために設計されたシステムから欠陥を取り除くことに、どんな意味があるのでしょうか？もし、危険な設計があったり、エンドユーザーの基本的な権利を妨げたる隠された要素を持っていたり、プライバシー、セキュリティ、機密保持などの重要な問題に影響を与えたりするようなシステムが有効になる場合、テストは人類の役に立つでしょうか、それとも妨げになるのでしょうか？

If you are also a Tester who is comfortable in the technical and business aspects of your testing but still feels there is something more to consider when we speak of “Quality” of systems, perhaps a look at my proposed G.O.O.D. Testing points could help.

もしあなたが、テスターとして技術面やビジネス面では満足しているが、システムの「品質」についてもっと考えるべきことがあると感じているなら、私が提案するG.O.O.D.テストのポイントをご覧になれば、きっとお役に立てるでしょう。

G.O.O.D. Testing involves 4 basic principles, it: 

G.O.O.D.テストには、4つの基本原則があります。

• G: Gives transparent insights into the quality and risks of the system to ALL stakeholders
• O: Observes the quality of the system not only in terms of verification or validation and defects but also in terms of the impact of the system in society at large 
• O: Opens the doors to ask questions about the intended use of the system in relation to the broad set of end users
• D: Determines testing scenarios which measure the Quality of systems in terms of ethical characteristics such as safety for the end users in terms of privacy, security and confidentiality among others. 

• G: すべてのステークホルダーに対して、システムの品質とリスクに関する透明性のある洞察を提供する。（Give）
• O: システムの品質を、検証や妥当性確認だけでなく、システムが社会全体に与える影響も含めて観察する 。（Observe）
• O: 幅広いエンドユーザーに関連して、システムの使用目的について質問するための扉を開く（Open）
• D：エンドユーザーに対する安全性（例えば、プライバシー、セキュリティ、機密性）など、倫理的特性の観点からシステムの品質を測定するテストシナリオを決定する。（Determine）

Especially in these times, where a larger amount of the population is forced to use digital platforms, the responsibility of testers to test G.O.O.D. becomes more apparent. The standards for releasing other physical, mechanical or pharmaceutical systems requires consideration for the safety of end users. Should not some standards also be applied to software when the software is of a nature that impacts the well-being of the end users or society at large?

特に、より多くの人がデジタルプラットフォームを使わざるを得ないこの時代、G.O.O.D.をテストするテスターの責任はより明白になっています。物理的または機械的なシステムや、製薬システムをリリースをするための基準では、エンドユーザーの安全性に配慮する必要があります。ソフトウェアがエンドユーザーや社会全体の幸福に影響を与える性質のものであるならば、ソフトウェアにも何らかの基準が適用されるべきではないでしょうか？

Imagine a time when systems are tested G.O.O.D. and if they do not pass the test, perhaps they not released or used “at your own risk” because they don’t meet the criteria of not only Quality but also of what is “Good” for the end user.  

Are you testing G.O.O.D.? Or are you just Testing?

システムがG.O.O.D.でテストされていることを想像してください。 またテストに合格しなければ、おそらくリリースされないか、品質だけでなくエンドユーザーにとって「良い」という基準も満たしていないため「自己責任」で使われるでしょう。

G.O.O.D.のテストをしていますか？それともただのテストですか？

AgileおよびAgile Testingは21世紀に様々な考えが考案されました。

• 2001年…アジャイルソフトウェア開発宣言
• 2008年…書籍『Agile Testing（邦訳：実践アジャイルテスト）』刊行
• 2015年…テストマニフェスト考案
• 2016年…継続的テストモデル考案

上記の1つ、テストマニフェストでは下記のように書かれています。

私たちは下記を大切にします。

• 最後にテストする よりも ずっとテストし続ける
• バグの発見 よりも バグの防止
• 機能性をチェックする よりも チームが理解している価値をテストする
• システムを破壊する よりも 最高のシステムを構築する
• テスターの責任 よりも 品質に対するチームの責任

他にも「今までのQA/テストではなく、Agileの時代で重要なのは◯◯だ」という主張をよく見かけます。

これらの考えは、Agile以前に存在しなかったのでしょうか？

実はAgile誕生よりもずっと昔から日本では存在していた考えです。

そこで本セッションでは、Agile Testingの考えに深く関わりのある、品質保証（QA）の歴史を遡ることで、先人がどのようにテストや品質保証に向き合っていたのか、先人の考えが現在でも通用するものなのか考察していきたいと思います。

皆さんの身近には「メンタルヘルス当事者」の方はいらっしゃるでしょうか？

私の場合は、1人開発者でプライベートの問題を抱えつつ仕事をしていたがために身動き取れなくなり、体調を崩し、病院に行ったら一発アウト（うつ病の判定）でした。

2018年の厚生労働省「最近の精神保険福祉政策の動向について」という資料では、日本の精神病患者は約392万人、30人に1人という統計になっています。

つまり1学年に1人は精神疾患にかかる方がいるということです。

一方で、精神疾患についてはあまり良い情報が多くありません。

過去の精神病院等の扱いやメディアで犯罪者が精神疾患だったという報道によるイメージが悪いこと、精神疾患にかかったことを公表するとデメリットがある（職につきにくい等）があるためです。

しかし、このままでは精神疾患を抱える人にとって良くなる社会にはなりようがありません。

そのため、私一個人のケースですが、どのように精神疾患に掛かったのか、そしてどのように回復しつつあるのか、社会復帰できるようになってきたのかについてお話したいと思います。

一番大切だと思っていることは「一度メンタルヘルスを崩した（病気）になったことの評価をネガティブなままにしないのが重要だ」ということです。

F1のFはFeedbackのFです。
アジャイルに関わる皆さんならきっと大好きなフィードバック、これを上手にできる腕を競う選手権です。

この45分間のパネルセッションは、大喜利形式で行われる楽しいセッションです。

アジャイル開発で悩んだり困ったりしたシチュエーションをお題として募集します。お題に対して回答者はフィードバックコメントをし、もっともナイスフィードバックと思われる回答がポイントを獲得します。
ポイントの投票は回答者自身と、聴講者によっておこなわれます。
高評価の観点が参加者によって醸成されていく、ダイナミックでインタラクティブなセッションです。
最多ポイントを獲得した人はF1新潟グランプリの勝者となり、1年間、その栄誉が讃えられます。

お題と回答の例その1
お題「僕はスクラムマスターです。上司がチームのパフォーマンスを気にしているので、ベロシティのグラフを見える化してみたんですが、どうでしょうか？」
回答1「上司にベロシティについての理解を問うてみてはどうでしょうか？」
回答2「ベロシティは顧客価値につながる指標なんでしょうか？」
回答3「デプロイメント頻度は計測できていますか？」

お題と回答の例その2
お題「私はデベロッパーです。いつもテストをきちんとしようと思うのですが、プロダクトオーナーの期待するスピードで作ることができません。正直毎スプリントこんなにきっちりテストをするなんて足枷に感じてしまうのですが、どうしたらいいでしょうか」
回答1「テストをサボるとその足枷がどんどん重くなるのでは？」
回答2「一度テストをまったくしないで進めてみてはどうでしょうか？」
回答3「プロダクトオーナーを説得する役割の人はいないのですか？」

出演者の情報です。
実況：ながせ（miholovesq）
解説：もりや（yudmo）
ドライバー（回答者）：よた（yota）、てやまぐ（teyamagu）、やっとむ（yattom）、かっちゃん（katzchang）
その他のドライバーにはこれから声をかけます。
出走希望のドライバーも募集しています。ローカルレーサーは特に歓迎します！

お題は下記のフォームで募集し、当日はこの中から厳正なる抽選で採用されます。
Google Form: F1新潟GP'22お題募集フォーム

2019年の夏、マネージャーを引き継いだRettyのtoC Webサービス開発は度々障害を出し、QAプロセスの早急な整備が必要に思われました。当初はQA組織の立ち上げを考えていましたが、アドバイザーとの壁打ちの結果「皆でQAが担保できるのであれば、門番的なQA組織はいらない」ことに気がつき、リリース前テストとは遠いところから整備を始めました。QA観点の整備、検証項目の早期準備と相互レビュー、不要な機能の削除、早い段階での結合とテストなど。それらが成果を結び、2021年夏には大きな障害が起きにくくなったと組織で実感できるぐらいに状態が改善されました。

しかし事業の注力領域がtoCからtoBに移るにつれ、これまで発生率で気にしていたエラー・障害を「発生件数」で気にするようになり、あらためてQA体制のあり方を再考しています。

当初目指していた「門番にならないQA組織」に結実できるよう、考えたこと・悩んでいること・実践していることを皆様に共有します。

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

QA2AQ(品質保証からアジャイル品質への移行に関するパターン)は、アジャイルの品質保証を学ぶための有用な情報を与えてくれます｡現在23あるパターンのうち、2020年8月から、2１年10月までに12のパターンを社内で勉強会、ワークショップを開いてきました。もう使っているパターンもあれば、やられていないものもありました。その一部を、2020年8月に、スマートエスイー主催のセミナーで発表したこともありました。（Linksを参照）。

今回の発表は、その中の一つを事例として発表します。

パターン名は　”システム品質：ラジエータ: System Quality Radiator”です。

メトリクスは、CFD（Cumulative Flow Diagram)を用いました。フローの質を測り、それをラジエターで毎日見せることで、チームがどのような行動変容したかというお話になります。

"メトリクスは、メッセージを持つべき"、つまり"Talking Metrics"というのが戦略です。チームをオブザーブし、その兆候から予想されるリスクを、メトリクスを使っていかにチームに気づかせるかがカギになります。なので、メトリクスの形をアダプティブに変化させていきます。

名付けて　”アジャイル・トーキング・メトリクス：Agile Talking Metrics”

メトリクスにはメッセージを込めます。つまりメトリクスが話しかけ、気づかせるようなメトリクスを作りたい、というのが思いです。

それにより、インペディメントを抑え、品質を落とす行動を防いで、チーム全体のレジリエンスを引き出すといった連続した効果を、メトリクスを使ってご紹介します。

38日間の、アジャイル・トーキング・メトリクスを使った品質のラジエータの旅をお話しします

2018年10月、IT業界を離れる決意をした自分は退職願いを会社に出しました。その大きな理由の一つが毎日仕事でやっていたテストでした。
すんでのところで会社に留まる決断をした自分ですが、テストとは距離を置き続けました。

月日が経ち、自分はアジャイルを通してテストにもう一度向き合う覚悟を決めました。Agile testing condensedを読み進める所からスタートした自分は、テストに対する意識が少しずつ変わると共に、テスト関連書籍やコミュニティなど、素敵な繋がりが生まれました。
こうした繋がりは新たな繋がりを生み、現場での成果も少しずつ出るようになっていきました。

本プレゼンでは、テストが大嫌いだった自分がどのような過程を踏んでテストに対する距離を縮めて品質に興味を持ち、現場にどう適用をしていったのかをお話したいと思います。

アジャイル開発において避けては通れないであろうトピックのひとつが、E2Eテストの自動化です。近年ではSaaSモデルのE2Eテストツールもメジャーとなり、それに伴い導入事例の紹介も多く見受けられるようになりました。

しかし発表される事例の多くは運用フェーズに入ったプロダクトのテスト自動化であり、結局のところいつからE2E自動テストを導入すれば良いのかという疑問が残ることでしょう。

「マネーフォワード クラウド確定申告」は2020年にフルリニューアル版をローンチしました。

スクラムチームでインクリメンタルに実装するにあたり、当時のQAリーダーである西條は開発の初期からE2Eテストツール Gauge を導入しました。本セッションの前半では、ツール選定や実装時の困難など導入時のエピソードを紹介します。

後半は、2代目QAリーダーの小林による運用篇です。

400件近くのシナリオが実装された状態で引き継いだ小林は、開発経験者が自分ひとりのみのQAチームでローコードなE2E自動テストを運用するという課題に直面しました。それを乗り越えるための取り組みと、今後の展望についてお話しします。

開発チーム外に所属しているQAエンジニアが、開発チームに潜入することに成功しました！そこでは、開発エンジニアに「テスト」という武器を授ける活動を行っています。

ところで、開発エンジニアはどう思っているのでしょうか？一緒に活動した開発エンジニアをお呼びし、本音を聞いてみましょう。

自分達にもできそうだな！と、一歩踏み出す勇気を与える、栄養ドリンクのような発表を目指します！

•  人間関係ですれ違ったり、たまにツラい思いしませんか？
  • そこまでツラいわけでもないけど、あの人とお話するのはちょっと気が重い
  • QA vs 開発、営業 vs 開発、マネジメント vs 現場 みたいに部署対部署や上下関係でいがみ合ってしまう。
  • "あいつら" と言われたり、言ってしまったりする
• 人と人との関係性は認知するのは難しい
  • そもそもそんな方法習ってないですよね
  • それでうまくやれって言われても...
• 関係性の取り扱い
  • 自分達の関係性を認知する
    
    • 自分の大事にしている価値感や世界観を知る
    • 自分自身の心理的な抵抗感を知る
    • 相手の価値感、想い、心理的な抵抗感を知る
  • 関係性が明らかになる
    •  
  • 心理的な抵抗感の様々な超え方
    
    •  
• アジャイルな文化にはそういう態度と親和性があるように思える
• 人が認知する他者との境界はどこにあるんだろう？

こんな事を話したいと思ってるんですが、正直まだまとまってません。
ぜひご意見ください。直前までUpdateする可能性があります

「品質より納期優先で!」
「テストは QA チームがやるから、とにかくコードを書け!」
「後でリファクタリングすればいい。」

こんなセリフがいまだに言われてたりします。顧客が家だと思っているところに、ドリフの舞台セットを提供するようなものだと、私には思えるのですが、多くの開発現場ではこんなやりとりが普通に行われています。

アジャイル文化では、品質を後から作り込むことはできないことは常識ですし、品質とスピードはトレードオフの関係ではありません。 "開発とともに品質を作り込んでゆく" ことが、速く開発することと同義であることと、本当の問題は "開発が下手クソ" であることを (おもしろおかしく) 紐解いてみたいと思います。

アジャイルでモダンな組織を作っていくうえで、テストに関する考え方は極めて重要になると思います。もし、要件定義、開発、テスト(品質保証)をそれぞれ別のチームで行っている場合は、根本的な体制の組み直しが必要になると思います。

その際に、突きつけられ、迷子になりがちなのが「我々はなぜテストをするのか？」という問いです。独立していたQA担当をチーム内に入れるべきなのか？開発者自身がテストをするべきなのか？POやPdMがテスト項目を記述すべきなのか？組織的にはさまざまな問いがあるだろうと思いますが、おそらく自分たちの文脈において「我々はなぜテストをするのか？」を考えられないと、ただ組織を組み替えて、足りない部分を誰かに押し付けて終わってしまうのではないかと思います。

最近、３つの講演に出会いました。KANOメソッドで有名な狩野紀昭先生による、日科技連の歴史を振り返る講演、Jonathan Rasmusson氏による Spotify などのユニコーン企業でのテストについての講演、それから BDDの提唱者である Dan North 氏による BDD is not Testing です。このセッションでは、この三つの講演から、「我々はなぜテストするのか？」について、考え直してみたいと思います。

なにぶんテスト専門家でもありませんので、みなさんに十分な知見をお届けできるかわからないのですが、議論のきっかけになれば幸いですし、間違っているところがあればご指摘いただければ幸いです。

一応、私の実務者としてのバックグラウンドはこんな感じです。もうだいぶ時間たってしまったので、あんま意味ないかもしれませんが。

• 社会人になって、私が最初に配属された部門は「情報部門」というところでした。データを作る部門、という感じですが、主な仕事は、アナログな情報のデータ化でした。ファックスや印刷物、メールなどで飛び交う情報の特定部分を抽出して、ちゃんと整理してデータベースに入れる仕事です。ここで行われるテストは、入力した情報が間違っていないかどうかの、２～３重の確認でした。これを間違えると、重要な経済指標の算出が間違ってしまい、しかもそれ以降の計算も間違っていくので、とても重要な仕事でした。間違いが許されない。
• その次に携わったのは、そうしたデータを入力するシステムの開発です。人々が間違った情報を入力してしまわないように、見比ベることを容易にしたり、振り返って直せるようにするための仕組みです。ユーザビリティを高める必要がありました。
• そして、数年後には、もっと複雑な仕組みに携わるようになりました。リアルタイムデータ。取引情報をリアルタイムに表示する仕組みで、これをどうやって間違わないように行うのか？パターン無限にあるやん。また、さまざまなクライアントでそれをきちんと再現するにはどうしたらいいのか？さらに問題が起きたときに情報を収集する仕組みを作る必要がありました。
• 最後にやったのが、サーバインフラに、間違わずに環境を届ける仕事です。システムそのものの正規の状態を作り上げ、それを間違わずにデプロイによって複製する仕組みです。しかも、そのあとは動いているシステム同士が間違っていないことを確認し続ける必要があり、問題がある場合は、問題が起こる前のサーバー状態と入れ替えて再生する必要があります。

"割り切る"。

どこか投げやりで無責任な印象を持つ方もいらっしゃるかもしれませんが、私は公私においてしばしば出くわす課題や試練を「割り切ること」で乗り切ってきたように思えます。

このセッションではそんな私の以下のような「割り切り話」を展開し、正しく割り切りながら課題と向き合う方法についてお伝えしたいと考えています。

■ソフトウェアテストの割り切り

• はじめての割り切り
• 自動テストだって割り切るところからですねという話

■プロセス改善の割り切り

• 割り切らなきゃ何も始められないぞという話

■私の周りの割り切り話

• 息子の場合、妻の場合、私の場合 etc.

■正しい割り切りについて2,3の考察

• その割り切り、あなたは納得してますか？
• 根拠と主体性が大切

「リリースの度にテストケースが増えていくよ…」
「自動テストを導入したいけどどこから手をつけていけばいいの…」
「やることたくさんあってもう忙しいよ…」

といったお悩み解消の一助となれば幸いです。

探索的テストではテストを実行しながら自分の中の期待値と動作の結果を確認していきます。
ただしテスト仕様書はありません。
その場合は、どうやって期待値を考えるのでしょうか？

このセッションでは探索的テストのExploreIt!からの情報も絡めながら、探索的テストにおける期待値（標準）を作る方法を紹介します。

期待値を作るためにはテスト実行前にもやることがあります。探索的テスト実施前や常に気を付けていることについて以下のように分類しました。順番は自分達のプロダクトに近い順番に並べています。

- 以前のソフトウェア（機能追加前）がどう動くか？＜実行前＞
- 同じソフトウェア内の別の機能はどう動くか？＜実行中＞
- 社内の別のソフトウェアはどう動くか？＜実行前＞
- 社外のソフトウェア（競合他社やデファクトスタンダード）はどう動くか？＜実行前＞
- 現在のトレンドはどうか？＜実行前＞
- 法令やスタンダードに沿っているか？＜実行前＞

これらを意識することで自分達の中に標準ができてきます。
探索的テストの実行では、この標準と照らしあわせながら違和感やバグそのものを探していくことになります。

セッションではそれぞれについて実例をあげながら説明していきます。

スクラムマスターの重要なスキルとして、「観察」がよく挙げられます。

観察が重要だという話は、一見すると特に疑問の余地がありません。しかし、下記のような観察の実態について語られる機会は少ないように思います。

• なぜ観察が重要なのか
• 効果的な観察とはどのようなものか
• どうやって観察するのか
• 観察のスキルを伸ばす方法

私自身も、スクラムマスターとして、観察が重要だという考えを持っています。本セッションでは、上記のような疑問について改めて考え、スクラムマスターの「観察」スキルを掘り下げてみたいと思います。そして、観察のスキルを伸ばし、タフな現場でも心身を健全に保つために役立つ心構え・テクニックをご紹介します。

『品質文化試論』というQiitaの記事を2021年12月に公開しました。JaSST東海'21に合わせて公開したわけですが、ありがたいことに、様々なコメントを界隈で貰うことができました。

コメントを眺めていると、一人ひとりの問題意識とか立ち位置（ポジション）によって『品質文化試論』の受け取られ方は異なっているのではないかと思うようになってきました。そこで今回は、改めてMark（ぼく）が何を考えてあの文章を書くに至ったのかをプレゼンしようと思います。

『品質文化試論』で語ったことは、端的に表現すれば「品質文化は組織戦略に逆らったものにはならない」でした。その結論に至るまで、大きく2つの議論をしています。

ひとつめは、縦の階層構造です。「品質文化は組織文化に従う（逆は難しい）」のではないかと提示しています。

もうひとつは、横並びの構造と捉えて「戦略と文化は組織の両輪」と考えました。

「品質文化」というものを真正面から考えるのはシンドイのでこういう手法を取ったわけですが、結果的には「品質戦略」という言葉を引き出すに至りました。魅惑的な言葉が増えてしまって、正直なところ頭を抱えています。ただ、こうした構造を表現したことで、特に「1人目のQAエンジニア」へのメッセージを発することになったかなと思っています。

さてさて、こういうちょっと変わった角度から「品質文化」を考えるに至った源泉はなんでしょうか。これも大きく2つあると思っています。

まずはMBA（経営学修士）で学んだ知識があります。特にヒト系科目と呼ばれる「人材マネジメント」や戦略系科目「経営戦略」あたりで学んだことがベースになっています。エンジニアでMBAに通う人はまだまだごく少なく、特にQAエンジニアでいえば、国内では会ったことがありません。その意味では、少々レアな経験を積んでいると思います。

もうひとつ、5年前から海外カンファレンスや洋書を通じた学びを続けており、現在は『LEADING QUALITY』という本を翻訳しています。この本はCレベルのエグゼクティブ（たとえばCEO）が品質を重要な経営課題と認識して取り組むことの価値と、いかに推進するか、その事例が書かれています。どちらかというと技術書っぽくない、経営陣向けの「ビジネス書」に近い感覚の独特な本ですが、品質エンジニア目線で経営陣をどう説得するかを学びたい方にもおすすめできる著作です（翻訳されたら買ってください、ぜひ）。

ところで、品質関係の書籍というとどんなものを想像するでしょうか。「品質とは何か」「品質をいかに測るか」を説明した書籍や規格類が、やはり多いかなとぼくは思います。その一方で「品質の大切さをいかに組織に広め、品質文化を醸成するか」を解説した信頼できる情報源は、ほぼ皆無だとも。「品質文化」という言葉はいかようにも解釈できる危険な言葉で、避ける人もいますが、それが危険なまま放置され続けてきたこともまた、注目に値するのではないでしょうか。人類の進化に火が多大な貢献をもたらしたことを考え合わせてもいいかもしれません（プロジェクトを炎上させたくないぼくたちに火の話題はタブーかもしれませんけど）。

国内では比較的レアな品質 x MBAというコラボレーション、そして『LEADING QUALITY』をはじめ、海外から学んだ知見があって『品質文化試論』につながっているのです。

そして『品質文化試論』は「試論」にすぎません。ぼくはこれを『品質文化論』に進化させたいと考えています。たぶん、数年かけて。

今回の登壇はその長い道のりの第2歩になるかもしれません。

参加者の皆さんとの対話の中で（決して保証はできませんが）広く共有できる「なにか」があればいいなと思っています。楽しいセッションにいたしましょう。長い旅路の第2歩目を、ぜひご一緒しませんか。

こんにちは、世界！
※このプロポーザルは、テストの街「葛飾」コミュティが「オンライン参加を存分に楽しむぞ！」という宣言になります。
https://www.tmkatsushika.tokyo/

突然ですが、みなさんは、
スクラムフェス新潟は、オンサイト参加ですか？オンライン参加ですか？

オンサイト参加は、NINNOのかっこいい会場、実行時委員長おすすめの名酒を酌み交わしながらの交流など魅力的な体験ができそうですね。

今回、家庭や諸事情によりオンライン参加になった人は、少しオンサイト参加の人が羨ましく思いますか？

そんなことありませんね。
みなさんはオンラインはオンラインならではの楽しみ方があるとことを知っています。

オンラインの良さの一つに、時、場所を選ばずにコミュニケーションがとれることがあります。

オンライ参加者は、スクラムフェス新潟の開催中（もしくは開催前後でも）にDiscordを利用して無限にコミュニケーションをとることができます。（オンサイト参加者と違い、移動もお店の閉店時間も気にする必要がないのです。）

私たち、テストの街「葛飾」も、積極的にDiscordのボイチャに参加して、雑談というなのコミュニケーションを存分に楽しみます。

開催中は、Discordのボイチャになるべく在中にますので、もし誰かと発表内容の感想など雑談したいなと思ったら、気軽にお声がけください。

オンラインの楽しみ方がアタリマエの人には、余計なお世話かもしませんが、
今回もオンライ参加でギャザリングを楽しみましょう！

宣言終わり。

エンジニア、プロジェクトマネージャー、スクラムマスター、アジャイルコーチとしてITシステム及びソフトウェア開発チームたくさん関わってきました。テストにおける考え方、戦略、実践も色々挑戦したり、見てきました。

自慢じゃないが、ほとんど派手に失敗してきた！

成功パターンがまだわからないのなら失敗パターンを追求していきます！

そこにヒントがあるはずだ！

このセッションでは過去のテスト失敗経験を語りながら失敗パターンを見つけてみます。

最近よく耳にするようになったコーチング。

興味はあるけどなぜか一歩目が踏み出せない・・・
なんかうさんくさい・・・
なにから始めればいいかわからない・・・
こうやって、悩み続けてもなにもすすまない・・・
いや、だからこそ飛び込んでみてから考えよう！！

そんな想いでコーチングの世界に足を踏み入れた5人の勇者たち。

はじめた動機、バックグラウンド、学んでいるもの、進度は違えど、
実際に行動しはじめた5人だからこそ話したいことがここにある。

コーチングを学んでいるもの同士が、お互いに問うことでお互いの思考を探ります。