前回、実録！ふりかえりを60日間続けると人はどう変わるのか？ふりかえりをふりかえり！をやった4人のエンジニアがセッションで「これなら来年まで出来るよねー」って言った後の記録です。

前回はたったの60日だけでした。今回は400日以上続けてみた記録をふりかえります。

1年間続けると色々な学びがありました。60日間ではわからなかった学び、工夫、苦労したこと、ふりかえり続けて変わったことなど、1年間やってわかったこと、気づきを一緒にふりかえってみませんか?

これを書いているときがちょうど365日、つまり始めてから1年がたちました。ふりかえりカンファレンスの時には400日を超えると思います。絶賛ふりかえり記録更新中!

セッションではこんなことをふりかえります

• 前に決めたルールで変えたことは?
  • 続けるのが難しかったルールは？
  • それをどう工夫したの?
  • 新しいルールはどうやったの?
• 400日続けてどうだった?
  • 続けるための工夫は？
  • どんなときに続けるのが難しかったの？
  • 出来なかった日はどんな日?
• 400日続けることで得られたことは?

いろんな会社の人が集まってわいわいやった結果をわいわいふりかえります。

どうぞお楽しみに

ちなみに前回のルールはこんな感じ

ふりかえりのやり方はこんな感じ

• 何をふりかえるか？
  • おのおのがその日のふりかえる
  • ふりかえりたいことは各個人で決める
  • 60日間のログ（記録）を取って変化を楽しむ
• ふりかえりの手法は？
  • 手法はみんな共通
  • 毎日変える
    • ふりかえりカタログを参考に
  • 前の日に決める
    • みんなが集まらなかったとき 左の図の番号とN日目と合わせる 2/1が1日目
• やり方はやりながら変えていく

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

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

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

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

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

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

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

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

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

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

こんな経験ありますか？

• 普段会話しない上司から突然の評価面談でダメ出しされた
• 明らかにパフォーマンスの低い同僚と比べてサラリーが低い
• 自分がどんな軸で評価されているかわからない

どれも昔、自分が経験したことです。

ずっとモヤモヤしていましたが、「これが社会人として普通のことだ」と自分に言い聞かせていました。

しかし、自分が部門のマネージャーになり、メンバーの人事評価をする立場になりました。

メンバーとは1on1をし始めて、今までそこまで会話してこなかった人に聞くと同じようなモヤモヤを持っていることがわかりました。

「評価方針が良くわからない」

「評価プロセスに対する透明性がない」

「他グループのメンバーと評価軸が同じかわからない」

「評価に対する上司からのフィードバックがあいまいでぶっちゃけ納得感はない」

うん。うん。同意です。

では他の会社の組織ではどんな人事評価をしているのか？

気になり、悩んだ結果、RSGT2022のOSTで悩みをテーマにしました。

OSTでは10～20人くらいの人に参加していただき、意見をたくさんいただきました。

「評価者から被評価者にどのように評価するかのイメージを共有していますか？」うっ

「評価面談でどうなってほしいか？またはなりたいか？等の会話はありますか？」うっ

「お互いに納得のできるフィードバックになってますか？」うっ

いろんな組織のやり方やアドバイス、また同じような悩みを聞いて、本当に勉強になりました。（参加していただいた方には感謝しております。）

OSTから学んだことをまとめると以下の2つでした。

• 評価者と被評価者の間で評価に対する納得感の確保
• そのためには評価プロセスと評価軸の言語化と透明性が大事

学びを受け、自分が試した実践は以下でした。

• QAという職種のキャリアを明確にする
• 評価方針や評価プロセスの透明性を明らかにし、公平性を確保する
• マネージャー間でメンバーに対する評価のすり合わせや、マネージャーからメンバーへのフィードバックをし、お互いの納得感を確保する
• そのための評価軸をしっかりと定義する（結果的に以下の4つの軸ができた）
  • マネジメント評価軸
  • エンジニアリング評価軸
  • 部門内の課題解決評価軸
  • コンピテンシー評価軸
• 次の評価に向けたキャリアプランの形成や目標管理

本セッションではOSTから学んだことを実際の現場で実践し、どのような結果だったのか。

成功したことや、失敗談を、伝えられる範囲で発表したいと思います。

はじめた動機、バックグラウンド、受けた変容、進度は違えど、
実際にコーチングを受け続けたものだからこそ話せる体験を時間いっぱい語り尽くします！！
（順次テーマは受け付けていきたいと思います！）

テーマ例：

• コーチングで受けた一番のタフクエスチョンは？
• 自分が壁を超えたと思った瞬間は？
• 今でも心に残っている言葉は？
• 最高のコーチ像は？
• 毎回、そんなに悩むほどのテーマってあるの？
• コーチすごい！って思った瞬間

昨年のスクラムフェス三河2021では、「新米QA部門長がアジャイルな組織作りを実践してみかわ」というタイトルで、新米マネージャーのストーリーと意気込みを発表させていただきました。

今年のスクラムフェス三河2022ではその後のマネージャーとしての取り組みについてお話ししたいと思います。

まだまだ先は長いものの、QA部門長として色々見えてきたものや、様々なことにチャレンジして、失敗して、学んだことがあります。そして、もしかしてこれがQAマネジメント？と感じるものを、ここで一旦まとめます。

（この一旦まとめてみるのがスクフェス三河の良さw）

以下のような内容を話したいです。

「ラインマネージャーとQAマネジメントは別物！？」

「突然動かなくなる3rd Party。情報集めと定期的な配信」

「自動テストにできない、定期的な手動リグレッションテストはアウトソースしよう」

「ねぇねぇ。QAにスクラムマスターいる？もちろんいるよ！」

「大変です！テストケース数が多すぎて自動テストが終わりません。。。」

「来週リリースするので出荷承認お願いしますー　え？」

「POも開発エンジニアもテクニカルライターも。みんな集まれ。社内専用Janet研修」

「QAもエンジニア。QMファンネルを使って自身のキャリアをイメージしよう」

「社内チリング会でスクフェス視聴してYYしよう」

「ハイヤリング×ハイヤリング」

こんにちは！仙台。

私はQA組織のラインマネージャーをしていますが、なかなかエンジニアが集まらないことに悩みを持っています（どこもそうかもしれませんが）

そこで、QAエンジニアやテストエンジニアについて少し語らせてください。

QA（品質保証）という職種はピンとこないものですよね。

特にこれからエンジニアとして新しく社会人になる方は未知の世界だと思います。

実際に弊社の新人研修に参加して、新人エンジニアに聞いてみると、QAエンジニアやテストエンジニアの印象は以下のようなものでした。

「よくわからないけどテストする人」

「製品の品質を保証する人」

「プロジェクトを改善する人」

実際に採用情報を調べてみても、よくわからないのが現状のようでした。

では、ウイングアーク１ｓｔ（弊社）ではどのような定義をしているか？

実はQMファンネルというツールを使ってわかりやすく説明できる状態にしています。

このセッションではQMファンネルを使ってエンジニアを再定義し、実際にどのような活動を行っているのかを紹介しつつ、これから新社会人になるエンジニアにQAについての理解度を深めてほしいと思います。

そして「QAの魅力や、やりがいを感じ取ってほしい！」そんな想いをのせたいと思います。

QMファンネルとは？

新しい品質保証のかたちを目指して、SigSQAというコミュニティで作ったツールで、スペシャリティやロールを可視化することによって、組織デザインやキャリア開発の手助けをします。

詳しくはこちらのブログを参考にしてください。

3つのスペシャリティと5つのロールを軸に説明します。

QMファンネルはエンジニアを３つの得意技に分けています。これをスペシャリティと表現しています。

• テスト・エンジニア（TE）
• パイプライン・エンジニア（PE）
• QA・エンジニア（QA）

また、３つのスペシャリティに対して深さ（実業務への近さ）を表します。これをロールと表現しています。

• スプリット
• インプロセス
• コーチ
• コンサルタント/サービス
• プロモーター

Morning Lean Coffee

カンファレンスの素晴らしい朝に、リアルにコーヒーでも飲みながら、リーンコーヒーしてみんなでギャザりましょう！

カンファレンスのこと、アジャイルのこと、テストのこと、普段思ってる些細なことでも、何でも良いので、みんなで共有しあって、気持ちの良い朝を迎えましょう。

Morning Yoga

毎日忙しく運動不足になりがちなデスクワークの人向けに、自宅やオフィスで簡単にできるヨガのアーサナ（ポーズ）、呼吸法、瞑想を紹介します。

肩こり改善やストレス解消に役立ててください。

DevOpsの世界において、テストはどのような位置づけにあるのか？

テスターはどのように適応すればよいか？

DevOpsでは、開発チームと運用チームが一緒に仕事をすることが奨励されています。これにより、製品を提供するために協力する人々のネットワークが広がり、テストの境界が拡大し、テストの性質が進化する機会が生まれます。

開発チームが運用で利用可能なスキル、プラクティス、ツールを理解すると、テストは生産に向けて右肩上がりになる。例えば、本番同様の環境でテストを行うことができるオンデマンドインフラ、顧客指標から得られるA/Bテスト実験からのフィードバック、顧客からのフィードバックを迅速に提供するベータテストグループなどがあります。

DevOpsによって納品ペースが上がると、新機能のテスト戦略にも課題が生じます。開発チームは、リリースを過度に妨げることなく、どのように新機能を調査すればよいのでしょうか。テストの自動化、モニタリングとアラート、迅速な自動デプロイとロールバックなどのツールの賢い利用を含めて、テストアプローチを適応させることができます。

このセッションでは、Katrinaが彼女の著書「A Practical Guide to Testing in DevOps」からいくつかの考えを紹介します。また、DevOpsを紹介し、開発中、本番稼働中、インフラに対するテストのための一般的なDevOpsプラクティスをいくつか紹介し、DevOpsがどのように、そしてなぜテスト戦略を変えるかも説明します。

「ふりかえりを60日間続けると人はどう変わるのか？ 」と疑問が湧いたの4人のエンジニアの記録です。

業種も職種も全く異なる4人のエンジニアが夜に集まって、お互いの1日のふりかえりを始めました。

60日間毎日ふりかえりをします。

ふりかえり手法は毎日違うものを試しているので、ふりかえり手法について毎日学びがありますし、

集まってふりかえりすることでその場に集まった仲間からもフィードバックを得られます。

また60日間継続するために、みんなでAgreementも決めてやっています。

 2/1から始めていて、現在絶賛ふりかえりキャンペーン実施中！

ふりかえりのやり方はこんな感じ

• 何をふりかえるか？
  • おのおのがその日のふりかえる
  • ふりかえりたいことは各個人で決める
  • 60日間のログ（記録）を取って変化を楽しむ
• ふりかえりの手法は？
  • 手法はみんな共通
  • 毎日変える
    • ふりかえりカタログを参考に
  • 前の日に決める
    • みんなが集まらなかったとき 左の図の番号とN日目と合わせる 2/1が1日目
• やり方はやりながら変えていく

ふりかえりを60日間続けると4人のエンジニアは果たしてどう変わるのだろうか！？

お楽しみに！

なんでみんなそんなに優しいの？

なぜスクラムフェスを新潟でやりたい？

Agile Testing Daysのフェス感がすごい！

それからはAgile Testing Days 2019に一緒に参加した、

川口さんの「先ずはスクラムフェスと言う形で新潟でやったら？」や、

ブロッコリーさんの「地域の祭りと言う意味では新潟がぴったり」や、

永田さんの「ポツダムはビール、新潟は日本酒」や、

山口さんの「新潟いいなー」が、

かなり後押ししてくれていますw

https://twitter.com/jp_110/status/1191810337013669888

 

また、スクラムフェス大阪で知り合った様々な人や、コミュニティからの後押しから刺激を受けて、

ついにスクラムフェス新潟開催を決意したわけであります。

 

コミュニティの応援がうれしい！

かつては「コストセンター」と言われたQA部門。

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

テスターを含むチーム全体（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象限を使ってテストを把握する
５．探索的テスト、品質属性のテスト、スライディング・スケール
６．コアプラクティスを使う
　・継続的インテグレーション
　・テスト自動化
　・機能やストーリーの優先順位付け
　・ビジネス価値を頻繁にデリバリー（いつでも出荷可能なリリース候補を用意する）
　・品質をデリバリー（コアプラクティスを用いて、会社やチームのあらゆる部分で品質を構築）

QAに携わる人は一度は品質問題でお客様から怒られた経験はありませんか？
私は最近経験しました。

突然、マネージャーや経営陣に呼ばれて、
「お客さん怒ってるから、品質が語れるQAとしてお客さん先に行ってきて」
と言われました。
もちろん今まで自分が担当したことのない製品でした。

お客様と会話し、開発現場のプロジェクトにどっぷりとハマり、見えたものは、
お客様とチームとのギャップ、またチーム内のメンバー同士が主張するギャップでした。

書籍『Agile Testing Condensed』では「Whole-Team」の定義を「whoever you need to deliver the product」と提唱しています。
また、「Whole-Team Approach」は「all team members are responsible for the quality of thier product」と提唱しています。
つまりプロダクトをデリバリーする際に関連するメンバー全員が「Whole-Team」であり、Whole-Teamのメンバーは全員がプロダクトに対する品質の責任があります。

このトークでは、QAが品質問題を抱えている開発現場に入って、プロダクトマネージャーやチームメンバーとの信頼関係を構築して、徐々にWhole-Team（チーム全体）としてプロダクトをデリバリーできるようなチームになった話をします。

また、品質にフォーカスした開発を行うAgile Testingマインドセットを実践し、顧客との会話で得たビッグピクチャー（全体像）とユースケースの重要性を理解して、徐々に品質を改善したストーリーを話します。

テスト設計コンテストに初参加し、アジャイルにテスト設計をしてみた結果を共有します。

http://aster.or.jp/business/contest.html

アジャイルは何も開発プロセスだけでなく、色々なプロジェクトで適応でもるものです。今回、テスト設計コンテストに初参加し、スクラムでテスト設計を実施した時の気付きと学びを共有します。

書籍『Agile Testing』の著者であるJanet Gregory と Lisa Crispinが明かす、本の出版後に何が起こり何を学んだかが、Agile Testing Days 2011のKeynoteで知ることができます。

XPチームに入り、テスターとしてどう関わったか
ジャネットとリサの出会い
チャレンジングな課題感のある5つのトピック
ジャネットのジグソーパズルからのユーザーストーリー話
現在の状況に見合ったリサのリモートワーク人間話
「失敗のお辞儀」「専門の一般化」
等々

面白い話が色々聞けます！

当日は日本語の字幕を付けて動画を放映しますのでお楽しみに！

ドイツのポツダムで毎年開催されるAgile Tesing Days 2019に参加してきましたので、フィードバック会として参加者たちのパネルディスカッションを行いたいです。

海外カンファレンスの「フェス感」が伝えられることを最大のゴールにしてます！

今までウォーターフォール開発にQAとしてどっぷり浸かっていた私が、開発チームがアジャイル開発を始めた時の失敗談と、そこから得た学びを語りたいと思います。

ドイツのポツダムで毎年開催されるAgile Tesing Days 2019に参加してきましたので、フィードバック会として参加者たちのパネルディスカッションを行いたいです。

海外カンファレンスの「フェス感」が伝えられることを最大のゴールにしてます！