Regional Scrum Gathering Tokyo 2024で今一番伝えたいことを発表してきました #RSGT2024

RSGT 勉強会 発表

1月10日〜12日に開催されたRegional Scrum Gathering Tokyo 2024で登壇をしました。

Regional Scrum Gathering Tokyo 2024 - できるだけ大きなアウトカムが得られるように、シフトレフトとシフトライトの両面から製品開発に取り組んだお話 | ConfEngine - Conference Platform

RSGTで登壇したのは2021年以来だったので、3年ぶりの登壇になります。

軽くふりかえりをしてみます。（が、後半はポエムになってしまった…）

発表資料

speakerdeck.com

前回よりも嬉しかったこと「フィードバックの多さ」

前回と大きく違ったのは、発表後、多くの方に質問や感想を伝えてもらったことでした。

これは前回とコンテンツの内容が違っていたのが要因なのか、参加者がよりギャザリングを意識しているからなのかは分かりません。

しかし、個人的にはフィードバックが多い方が嬉しいので、今回のような反応の方が嬉しいです。

次回に向けての改善点「セッションの惹きつけ方」

今回は、よりAgileやDevOpsを意識したセッションタイトルにしてみました。また、私としてはQAやテスターに限った話をしているつもりは無かったので、セッションタイトルに「テスト」という単語を敢えて入れませんでした。

しかし、結果としてリアル聴講のうちQAやテスターと呼ばれる人の割合が多めのようでした。これは誤算でした。

（良い意味でも悪い意味でも）私には「テストをしている人」というラベルがあった方が、聴講者にとっては「聞いてみよう」と思ってくれるのかもしれません。また、「シフトレフト」や「シフトライト」といった単語がQA界隈以外には想定よりも浸透しておらず、そもそもセッションタイトルを見ただけでは聞く気になれなかったのかもしれません。

そういう意味では、来月のDevelopers Summitの公募で出したセッションタイトルの方が、より惹きつけられるタイトルなのかもしれません。

event.shoeisha.jp

待って！本当に改善点なの？

今回は確かにQAの聴講者が多めでした。ですが、それは改善すべきことなのでしょうか？

私の発表はきょんさんの発表やいくおさんの発表やふりかえりの森さんの発表のように、聴衆を巻き込むタイプの発表ではありません。

RSGTやScrum系のイベントにおいて数少ないQAに光を当てたいという気持ちが強いです。万人に聞いてもらおうと努力した結果、QAらしさが失われてしまう発表になってしまったら元も子もないです。

自分が目指しているのは、「ライブでの聴講者数」ではなく「よりQAらしい発表」だと思ってます。本当は気にすべきではないアウトカムを目指して、測定しやすいが目標とは関係ないメトリクスを取って一喜一憂したくありません。

今回の発表のモチベーションは「まだ世になかなか出ていない『シフトライト』でのテスト活動の事例を話したい！」でした。ここの軸は見失いたくない。

しかもありがたいことに、RSGTは講演動画がYouTubeに上がります。つまり後から見返せる訳です。なので、発表時点で気付かれなくても良いのです。「あれ？以前に誰かがシフトライトについて話してたな？」と思った時に見返してもらえれば良いのです。

何はともあれお疲れ様でした

とここまで色々と書きましたが、これはイベントが終わっても悶々と考えていたので、記事にしてみた結果です。

RSGT2024は終わりました。ということは、RSGT2025の準備が始まります。

今度プロポーザルを出すのはRSGT2025かもしれませんし、また3年置いてRSGT2027ぐらいに出すかもしれません。ただ、その時にも「よりQAらしい発表」を目指すプロポーザルを書けるように日々精進したいと思います。

あ、そもそも今回の発表資料を公開しなきゃですね…。

2023年の活動をふりかえる

発表 勉強会

年の瀬です。

今年5月に転職したので、これからの動きを改めて整理してみる（宣伝多め）という記事を出しました。

その記事を書いた時に「自分自身で言語化しておくのは大切だなー」と感じたので、年内の全ての社外イベントが終わった*1このタイミングで改めてふりかえろうかと思います。

目次

転職

今年1番大きなイベントでした。

5月に株式会社ビズリーチから株式会社10Xへ転職しました。

10x.co.jp

「まだ8ヶ月しか経ってないのかー」と思ってしまうぐらいには、充実した日々を過ごせています。

開業

2月あたりに「B-Testing」を開業して、個人事業主としてのページも作成しました。

www.b-testing.net

副業

いくつか副業をさせてもらってます。そのうち公開できるものを記載しておきます。

iCARE様の技術顧問業

昨年に引き続き、iCARE様のところでお手伝いをしています。肩書きは「フェロー（QAE技術顧問）」となってます。

www.icare-carely.co.jp

普段はリモートでお手伝いをしていますが、先日は会社で行われたDJイベントに実際にお邪魔させていただきました。

note.com

上の記事を見ても分かる通り本当に良い感じの会社ですので、興味のある方はぜひご応募を！

herp.careers

CodeZine Academy講師

翔泳社様主催の「CodeZine Academy」というセミナーで講師をしています。

event.shoeisha.jp

ありがたいことに、毎回多くの方にご参加いただいております。次回の開催も計画中です。

ASTER標準テキストを用いた自治体主体のセミナーの講師

自治体主体のセミナーでも講師を務めています。千葉で開催しているセミナーの担当です。

www.aster.or.jp

年2回開催しており、来月に第4回が開催される予定ですが、こちらも毎回満席近くのご応募があります。

Holistic Testing研修講師

『実践アジャイルテスト』『More Agile Testing』『Agile Testing Condensed』の著者であるJanetとLisaが監修しているHolistic Testing研修の認定講師になりました。

サイトにも名前が載ってます。

運営

コミュニティ活動の運営をしています。

WACATE

ソフトウェアテストの合宿型ワークショップ形式勉強会であるWACATEに実行委員長として携わっています。

毎年6月と12月に開催しています。

wacate.jp

JaSST Review

日本で（おそらく）唯一のソフトウェアレビューのシンポジウムであるJaSST Reviewに実行委員長として携わっています。

www.jasst.jp

執筆

いくつか執筆をしました。

Sqripts連載

7月から、Sqriptsで全7回の連載記事を書きました。主にBDDについての記事です。

sqripts.com

Software Design寄稿

2024年2月号の『Software Design』に寄稿しました。テスト設計についての記事です。2024年1月18日発売予定です。

Software Design2024年2月号表紙

gihyo.jp

登壇

いくつか登壇をしました。

依頼を受けて登壇したもの

運営側として登壇したもの

公募して登壇したもの

これからの登壇

来年の予定ですが、既に登壇が決まっているものがあります。

Podcast

今年は音声メディアの露出を始めた年でもありました。

PIVOT Growth Drivers

ビジネス映像メディア「PIVOT」さんがエンジニア向けにお送りしているPodcast「PIVOT Growth Drivers」でゲストとしてお呼ばれし、全3回に渡って喋ってきました。

open.spotify.com open.spotify.com open.spotify.com

10X.fm

私が現在所属している株式会社10XのPodcast「10X.fm」の企画「QA部屋」でモデレーターを務めてます。毎回ゲストを招いて、今までの経歴やテストに関する話をしています。

既に出ているエピソードは以下の通りです。

open.spotify.com open.spotify.com open.spotify.com

おわりに 〜来年の抱負〜

今回は1年間の活動をふりかえってみました。ただ、実はほとんどの活動が転職後（5月以降）の8ヶ月間での活動となります*2。なので、より密度があるなーと感じてます。

来年も引き続き、依頼いただいたものは極力受けたいと考えてます。ご依頼は以下でお受けしております。

www.b-testing.net

一方、公募などによる、自分から働きかける活動はセーブしたいなと考えてます*3。

また、今の業務は本当にワクワクすることが多いので、それに関する話は積極的に社外へお伝えできればと考えてます。

それでは2023年、お疲れ様でしたー！

*1:最後のイベントは12/23,24にあったWACATE 2023 冬でした

*2:時系列で書くとこんな感じ。

  • 1月
    • （前年から引き続き継続的に）iCARE様の技術顧問業
    • ASTER標準テキストを用いた自治体主体のセミナーの講師
  • 2月
    • 「B-Testing」開業
  • 3月
    • （特になし）
  • 4月
    • とある副業が新たにスタート
  • 5月
    • 転職
    • JaSST nano vol.24
    • 第20回Ques
    • CodeZine Academy講師
  • 6月
    • WACATE 2023 夏
  • 7月
    • Sqripts連載開始
    • QA Test Talk Vol.3
  • 8月
    • JaSST nano vol.27
    • CEDEC 2023
  • 9月
    • ASTER標準テキストを用いた自治体主体のセミナーの講師
    • CodeZine Academy講師
    • Holistic Testing研修講師になる
  • 10月
    • （特になし）
  • 11月
    • JaSST nano vol.30
  • 12月
    • JaSST Review'23
    • ATN#19 【ハイブリッド開催】Agile Testing Days 2023 をふりかえる夜
    • 『LEADING QUALITY』品質文化の醸成 お悩み解消会
    • WACATE 2023 冬

*3:といっても、今年公募して登壇したのはJaSST nanoだけなんですけどね…

政府が発表した「こども未来戦略」案を題材にレビューとテスト設計を考えてみる

技術

はじめに

本記事はソフトウェアテスト Advent Calendar 2023やソフトウェアテストの小ネタ Advent Calendar 2023にエントリーできなかった、アドベントカレンダーとは関係ない通常投稿です*1。

ということで、実際に考えてみることにしました。

なお、本記事は政策の批評を目的としておらず、あくまでもレビューやテスト設計の題材として利用しているだけです*2。

目次

政府方針

以下の記事より、必要そうな要素のみ抜粋

news.yahoo.co.jp

「異次元の少子化対策」をめぐり、政府は3人以上の子どもがいる多子世帯について、2025年度から子どもの大学授業料などを無償化する方針を固めた。所得制限は設けない。教育費の負担軽減で、子どもをもうけやすくする。

対象は子どもが3人以上の世帯。大学生のほか、短期大学や高等専門学校などの学生も含める方針。入学金なども含む方向で調整している。子どもとしての数え方も今後詰める。

今回は多子世帯は原則、所得制限なく無償化すると踏み込んだ。

授業に出席していない場合は対象外とすることなどを想定している。

要求の抽出

政府方針は要求定義というよりも要件定義の意味合いが強かったのですが、その中から要求っぽいもの*3を抜き出すと…

  • 「異次元の少子化対策」
  • 教育費の負担軽減
  • 子どもをもうけやすくする

あたりでしょうか。

また、隠れた要求としては、

  • 過度な財政負担にならないようにする

あたりがあるようにも思えます。

要件定義

続いて、要件定義っぽいものを少し構造化しつつ表現してみました。

  • 子どもの大学授業料などを無償化する
    • 大学生のほか、短期大学や高等専門学校などの学生も含める方針
    • 入学金なども含む方向で調整
    • 授業に出席していない場合は対象外とすることなどを想定
  • 3人以上の子どもがいる多子世帯が対象
    • 子どもとしての数え方も今後詰める
  • 所得制限は設けない
  • 2025年度から適用

要件定義レビュー

今回の要件定義のレビュー観点は、以下2つにしました。

  • 要件が曖昧になっていないか
  • 要求の内容に踏まえたものになっているか

1つずつ見てみましょう。

要件が曖昧になっていないか

私が要件の曖昧さで気になったのは主に2点。

  • 「子どもの大学授業料などを無償化する」の「など」には何が含まれているのか
  • 「子どもとしての数え方も今後詰める」とは何か？
「子どもの大学授業料などを無償化する」の「など」には何が含まれているのか

これは本文中にも書いた以下の内容かなと推測しています。

  • 大学生のほか、短期大学や高等専門学校などの学生も含める
  • 入学金なども含む
  • 授業に出席していない場合は対象外とすることなどを想定

ただ、これらもそれぞれ「など」とついているので、そこはツッコミたいところではあります。

「子どもとしての数え方も今後詰める」とは何か？

子どもとしての数え方は定まっていないのでしょうか。本文中には「3人以上の子どもがいる多子世帯」と明確に書いているように見えるのですが…*4。

要求の内容に踏まえたものになっているか

続いて、要求の内容との合致について気になったのは以下の点。

  • 「教育費の負担軽減」は実現できるのか
  • 「子どもをもうけやすくする」は実現しているのか
  • どのように財源確保をするのか

このうち、財源確保については割愛します*5。

「教育費の負担軽減」は実現できるのか

過去に「出産育児一時金の増額に合わせて、出産費用を値上げした」という事例がありました。

news.yahoo.co.jp

同様に、大学授業料の無償化（つまり、国が負担）を謳った時点で、そもそもの大学授業料の値上げをするのではないのでしょうか。

すると、「やはり無償化はムリ！」と負担軽減を途中で諦めたり、子どもが2人までの世帯はむしろ負担が増えてしまうのではないでしょうか。

もちろん、一部の大学だけが値上げを行う場合は、その大学に入学しようとしなくなるだけなので良いですが、全国にその機運が高まってしまうと、なし崩し的に値上げをしてしまうかもしれません。

「子どもをもうけやすくする」は実現しているのか

子どもがいない世帯については、仮に三つ子を産んだとしても、恩恵を受けるのは通常18年後。それまでこの制度が続いているのでしょうか。

今回の制度でより効果を生むのは、高校生ともう一人の子どもがいる家庭のみなのではないでしょうか。

恩恵を受ける人が全くいないというわけではないですが、より効果的な方法がないか、大学授業料の無償化以外の方法を検討しても良いかもしれません。

なお大学授業料の無償化以外の方法の検討について、後日発表された「こども未来戦略」案の中では、児童手当の所得制限撤廃や支給期間の延長、出産育児一時金の引上げなどが書かれていました*6。

「こども未来戦略」案

政府方針の発表から4日後、「こども未来戦略」案が公表されました。

これも以下の記事より、必要そうな要素のみ抜粋します。

news.yahoo.co.jp

対象となるのは、扶養する子どもが3人以上いる世帯の子で、所得制限はない。

例えば3人きょうだいで、第1子と第2子が大学に在籍していれば、2人とも対象となる。ただ、第1子が卒業後に扶養を外れると、扶養する子どもが2人となるため、第2子と第3子は対象外となる。

「無償化」となるのは授業料と入学金で、どちらも上限がある。

大学の場合、授業料免除の上限は、国公立が標準額となる約54万円、私立は約70万円。

医学部や薬学部などの6年制の学部については、最大6年間支援を受けられる。大学だけでなく、短大や高専や専門学校に進学しても支援は受けられる。ただし、留年や出席率が低い場合などは対象から外れる可能性がある。

進学する大学や短大、高等専門学校が、直近3年度全ての収容定員が8割未満の場合は対象外となる可能性がある。専門学校は5割未満の学校。

基本設計

設計の元となる情報を整理してみます。

  • 対象となるのは、扶養する子どもが3人以上いる世帯の子
    • 例えば3人きょうだいで、第1子と第2子が大学に在籍していれば、2人とも対象となる。
    • 第1子が卒業後に扶養を外れると、扶養する子どもが2人となるため、第2子と第3子は対象外となる。
  • 所得制限はない
  • 「無償化」となるのは授業料と入学金
  • 授業料免除の上限あり
    • 国公立が標準額となる約54万円
    • 私立は約70万円。
  • 医学部や薬学部などの6年制の学部については、最大6年間支援を受けられる。
  • 大学だけでなく、短大や高専や専門学校に進学しても支援は受けられる。
    • 進学する大学や短大、高等専門学校が、直近3年度全ての収容定員が8割未満の場合は対象外となる可能性がある。
    • 専門学校は5割未満の学校。
  • 留年や出席率が低い場合などは対象から外れる可能性がある。

テスト分析

さて、ここからはテストを考えてみます。まずはテスト分析です。基本設計をインプットとして、どのような視点でテストを行うべきか考えてみます。なお今回は、仮に無償化の判定プログラムができた場合を仮定してテストを考えてみます。

  • 無償化の対象となる家族構成
    • 扶養する子どもが3人以上いる世帯の子
    • 子供の扶養状況によって無償化するかが変わってくる
      • →扶養状況の変化は状態遷移テストを行う価値がありそう
      • →子どもの構成の組み合わせについてはデシジョンテーブルで整理してテストを行う価値がありそう
  • 所得制限
    • 今回は所得制限なし
    • 2024年度では年収600万円程度までの世帯が対象となっていたため、600万円以上の人でも無償化になっているか確認したほうが良さそう
      • →境界値分析を使う？
  • 授業料免除の上限
    • 国公立と私立で異なる
    • 上限に達している場合とそうでない場合で個人負担の額が異なる
  • 授業料免除の期間
    • 6年制の学部は最大6年間支援
      • ということは、4年制の学部では最大4年間の支援？（留年は配慮されない？）
    • 短大や高専や専門学校も対象
    • 直近3年度全ての収容定員が8割未満（専門学校は5割未満）の場合は対象外
      • 入学後に収容定員が8割未満なった場合は？
        • →特定のケースでテストする価値がありそう
  • 無償化の対象外
    • 留年や出席率が低い場合などは対象から外れる
      • 留年になった瞬間から、以降は無償化の対象外になる？
        • →特定のケースでテストする価値がありそう

テスト設計

テスト分析で見えてきた方針を元に、テスト設計を行います。今回は、特に複雑そうな「無償化の対象となる扶養状況の変化」に注目し、状態遷移テストを作成します。

今回の場合、家族構成は様々なパターンが考えられるので*7、「第1子は大学2年生、第2子は大学1年生、第3子は出産していない」という状況をスタート地点として考えます。

今回考え始めて10分ぐらいで作った状態遷移図は以下のとおりです。あまり網羅することを考えておらず、「こういうケースだったら扶養対象が変化するよなぁ…」と思いついたものをざっくり挙げてみました。

状態遷移図案

この状態遷移図は全くもって完璧ではありませんが、ちょっと描いただけでも気になる点がいくつか出てきました。

  • 第1子が扶養から外れたら、第2子は無償化対象外？
    • 報道によると対象外とのことだが、それは本来の要求である「子どもをもうけやすくする」の実現ができている？
  • 第1子が再入学した際には再び無償化対象になる？
  • 死別してしまった場合、子どものカウントは減る？
    • 死別して大変な時に、さらに無償化対象から外れるのは辛そう

上記は状態遷移図しか作っていませんが、他にも様々なところに注目し、色々なテスト設計技法を用いることで、制度の改善すべき箇所が見つかるかもしれません。

おわりに

今回は、政策を題材にレビューやテスト設計について考えてみました。

案外こういう内容でもテスト設計の練習にはなりました。

また、政府立案に対し審議することが仕事である国会は、レビューやテスト設計のような考え方を持つことで「こういう場合はどのように想定しているのですか？」といった有意義な議論ができるかもしれませんね。

*1:ソフトウェアテスト Advent Calendar 2023およびソフトウェアテストの小ネタ Advent Calendar 2023はソフトウェアテストに関する面白い記事が多数ありますので、ソフトウェアテストに興味のある方はぜひアドベントカレンダーにも足を運んでくださいませ。

*2:本記事を書くにあたって色々と調べましたが、記事になっていること以外も政策を立案していることが分かり安心しました。

*3:「誰からの要求？」と考えるとちょっと疑問が出てきますが、「国家の要求」もしくは「国民からの要求」でしょうか…。

*4:私の知識不足でもあったのですが、まさかこの記載にトラップがあるとは、政府方針が出た時点では思いもよりませんでした…

*5:私なんかよりも、もっと有識者な方が指摘したり、国会で議論しやすいところなので

*6:詳しくは「こども未来戦略」案をご覧ください。

*7:今回は扶養状況の変化に注目しています。家族構成のパターンを考える際は、別途デシジョンテーブルなどを作成すると良いでしょう

ソフトウェアレビューに対する考え方「ソフトウェアレビューマニフェスト」を考案しました

技術

本記事はソフトウェアテストの小ネタ Advent Calendar 2023の9日目の記事です。

ソフトウェア開発やソフトウェアテストに比べて、ソフトウェアレビューは未発展の分野だと感じています。レビュー体系化を目指す会では、その名の通りレビューの体系化を模索しているのですが、その道中に「この考え方は重要だよね」と感じた部分をマニフェストという形で表現してみました*1。

ソフトウェアレビューマニフェスト（工事中）

画像だけでなく文章も残しておきます*2。

ソフトウェアレビューマニフェスト（工事中）

私たちは左記のことがらに価値があることを認めながらも、右記のことがらにより価値を置きます。

  1. 承認を得る よりも 全員の納得を

  2. 欠陥指摘 よりも メンバーが「またレビューをやりたい」と思う結果を

  3. ファシリテーターの進行 よりも 参加者同士の連動による会話の広がりを

  4. 1回の完璧なレビューを目指す よりも 複数回のレビューの積み重ねを

  5. 誰がレビューしたか よりも 何をレビューしたかを

  6. 時間切れで終了 よりも 期待レベルまで出し切っての終了を

これはアジャイルソフトウェア開発宣言（アジャイルマニフェスト）を参考に作成をしました。

また、「（工事中）」と記載している通り、まだまだブラッシュアップの余地はあると感じています。ただし、現時点で思いつく、よくありがちなソフトウェアレビューの考え方について、思考を変えるために作成してみました。

皆様の現場に役立てることができるものになっているか分かりませんが、コメントや疑問がありましたら #jasstreview でどうぞ！

需要があれば、後日、それぞれのマニフェストの解説を書きたいと思います。

また、皆様からのフィードバックをお待ちしております。

12/9 追記

良いフィードバックをいただいたので補足です。

時間切れで終了 よりも 期待レベルまで出し切っての終了を

ここでいう「時間切れで終了」とは、「上から見ていって、時間切れになったから最後の方は見ずに終了」のパターンを想定してます。

ちょっとここの表現は伝わりづらいと思っているので、「時間切れで終了」よりも良い＆短い表現があれば教えてくださいませ*3！

*1:なお、このマニフェストは、先日、JaSST Review'23というカンファレンスの中で初めてお披露目しました。

*2:文字の配置の都合上、画像では「上記」「下記」と表記していますが、文章では「左記」「右記」と表記しています。

*3:「時間の都合で途中まで見て終了」とかかな…？

電気通信大学 西康晴先生 / にしさんとの思い出

今年10月18日に、にしさん（西康晴先生）がお亡くなりになられました。

www.aster.or.jp

私は電気通信大学の西康晴先生に対しての面と、にしさんとしての面の両方に対峙していたので、その思い出話をつらつらと書き連ねたいと思います*1。

電気通信大学の西康晴先生

私は電気通信大学（以下、電通大）電気通信学部システム工学科（当時）の学生として入学しました。

入学当時にシステム工学科の講師として在籍していたのが西康晴先生です。ちなみに、最期まで教授にはならず、意思を持って講師のままで居続けていました。

特に目立った学生ではなかったですし、西先生の研究室の所属でも無かった*2ので、おそらく西先生は学生時代の私のことを特別に認識をしていたわけではないと思います。しかし、私にとっては印象的な講義が多かった先生でした。

西先生の印象的な講義1. コンピュータリテラシー

大学1年前期の科目としてあったのが、コンピュータリテラシーでした。この講義は大学のコンピュータ室*3で行われ、コンピュータの歴史的な側面を学びつつ、リテラシーについて学んでいきました。

その中で、「ネット上でコミュニケーションを取ってみよう」というものがありました。そこで西先生は匿名掲示板を用意して、「他の誰かと必ず1回は会話のやり取りをしてください。」という課題を出しました。

最初は穏やかだった掲示板が、数分後には荒れていきます。誰かをいじるような投稿も増えていきました。そうしてある程度荒れている状況を笑って見過ごした後、おもむろに西先生は「まあ、表示上は匿名だけど、誰が書いたかは特定できますよ」と言いました。その瞬間、ピタッと投稿が止みます。続けて西先生は「誰が書いたのかわざわざ調べようとは思いませんけどね。いつでも調べることはできますからね。」と言っていました。

身をもって体験できた出来事だったなぁと今でも思ってます。

ちなみに、その時の感想を卒業後ににしさんにお伝えしたところ、「え？そんなことやったっけ？」と一言。決して誇ることなく、覚えてない素振りをするのが実ににしさんらしいなと思いました。

西先生の印象的な講義2. システム工学科実験

大学3年の科目としてあったのが、システム工学科実験でした。この講義は、3週間（3回分）ごとに講師が代わり、それぞれの担当講師が用意した実験を行うものでした。その中で西先生が用意したのがレゴのマインドストームによる自動運転車両を用いたレースでした。

education.lego.com

この実験では、3週間でレゴの車両と内部プログラミングを作成し、用意されたオーバルコースを1分以内で完走できれば単位を与えるというものでした。

ただしこの実験のミソは、「2人1組で行うこと」ということです。すると自然と、1人は車両作り、もう1人は内部プログラミング作りと分担することになります。

実はこの課題では、同じプログラミングでも、車両のデザインによってはうまくいかなくなります。うまく噛み合わないと、その場で車が回転して一向に前に進まなくなってしまうのです。

この実験を通じて、ハードウェアとソフトウェアの両方の面から考えることの大切さと難しさ、チーム開発の難しさを学びました。

ちなみに、その時の感想を先ほどと同じように卒業後ににしさんにお伝えしたところ、「へー、そういう学びもあるんだね」と一言。今でも「きっと狙いとして持っていたんだろうな」と思っているのですが、それを表に出さないのがやっぱりにしさんらしいなと思いました。

他にも、西先生の講義はどれもアクティブラーニングなものが多かったと記憶しています。

その他の西先生としてのお話は、西研出身の方の記事でたくさん語られているので、そちらもご覧ください*4。

hansuoi.hatenablog.com

にしさん

西先生とは、卒業後も「にしさん」として色々と関わることになりました。

にしさんは「西先生」と呼ばれるのを極度に嫌がります。それは、「西先生と呼ばれると、そこで上下関係ができてしまい、対等な議論ができない」「電通大の学生ならばともかく、そうでもない人から西先生と呼ばれたくない」というものでした。また、親しみを持って接してほしいという意味からも「にしさん」とひらがな表記を徹底していました。

ASTER理事長としてのにしさん

にしさんはNPO法人ASTERを設立し、理事長として動いていました。ASTERはテストシンポジウムのJaSSTやJSTQBを運営している団体です*5。テストエンジニアリングを生業としている人ならば、何かしらの形でASTERに関わっていたと思います。その貢献は多大なものだと思っています。

また、JSTQBステアリング委員会の委員長も務めていました。そのため、JSTQBの合格証書には全員、にしさんのサインが書かれています。そんな中、にしさんは「JSTQBの合格なんてものにそんなに価値はない。結果でしかないので、そこまでに勉強していることの方が大切」と言い切っていたのを覚えています。にしさんらしいなと思います。

もう少しマイルドに表現した投稿がこちら。

ちなみに、私が学生の頃はそのような活動をしているのを全く知りませんでした。にしさんの講義ではそんな話を一切言わなかったのです。そこらへんもにしさんらしいなと思ってます。

レビュー研究会/JaSST Review実行委員のにしさん

数年前ににしさんに誘われて、レビュー研究会の一員となりました。そこでは、ISTQB/JSTQBの活動によって体系化されていったテスト分野に対して、まだまだ体系化できていないレビュー分野について語っていこうというものでした。

またそこから派生して、JaSST Reviewというレビューシンポジウムを立ち上げることとなりました*6。2018年から続いており、先週第6回目の開催を無事に終わらせることができました。

にしさんが最後に参加したのは昨年のJaSST Reivew'22でした。にしさんが研究会の活動に参加すること自体はなかなかありませんでしたが、JaSST Reviewについてはほぼ毎回参加していました。そんな中での以下のツイートが今でも自分の心に残ってます。ここまで言ってくれて本当に嬉しかったです。

その他、さまざまな活動で関わったにしさん

他にもさまざまな活動でにしさんにお世話になりました。

2022年には、WACATE（ワークショップ型のテストの勉強会）にて招待講演を引き受けてくださりました*7。その時の概要文はユーモア溢れてて好きです。

WACATE 2022 冬のプログラムのページより引用

あと、プロフィール文の最後に書かれている「ずっとずっと叱られ支えられ教えられながら、いつまでも楽しく成長したいともがいている毎日です。」という一文に今もまたうるっと来てしまいました*8。

最近はとある付き合いで、比較的頻繁に一緒に関わっていました。その関係で、今年は電通大にも数年ぶりにお邪魔させていただきました。その中で頻繁に「どうやったらブロッコリーのような若い世代がもっと動きやすくできるのか」という話をしてくださっていました。

大学の先生、ASTERの理事長という肩書きがありながら、驕ることなく本当にテストに関する組織やテスト業界に対して真剣に考えてくださっていた方だと思います。

組織について考えると言う意味では、組織に変化をもたらすことについてのツイートはとても印象的でしたので、ここでも紹介しておきます*9。

テスト以外でも関わったにしさん

テスト以外の面でもにしさんにはお世話になりました。詳しくは書きませんが、にしさんが実質的な仲人となって、妻と結婚できたと思っています。

結婚後、

私「自分の子供が大学生になったら、電通大に入って、にしさんの研究室に入れたいです！」

にしさん「その頃は、もう俺は定年退職して、大学にいないから！」

私「そこは、にしさんに名誉教授なりになってもらって、何とか電通大に居続けていただいて…」

という掛け合いを何度かしていたのですが、まさかこういう形で実現不可能になるとは思いもよりませんでした…。

私のことを気にかけてくれていたにしさん

ここまでで、学生時代、社会人時代の両方でにしさんにお世話になりっぱなしであることを書きましたが、それと同時に、にしさんが私のことを気にかけてくれていました。

私は電通大を卒業した後、一度も所属の研究室に顔を出さなかった不届きものです。そんな中、にしさんは私が所属していた研究室の先生に、頻繁に私のことを伝えていたそうです。そのおかげもあって、今年、電通大にお邪魔したときに、にしさんがプッシュしてくれたおかげで、所属していた研究室へ無事に挨拶できました。

私と面と向かって言うことはほとんどありませんでしたが、他にも色々な方に対して私のことを話題に挙げてくれていたようです。

にしさんには感謝しかありません。本当にありがとうございました。

*1:もう四十九日も経ったので語っても良いかなと。個人的には気にならないのですが、「なんで四十九日も経ってないのに軽率に書いてるんだ」と怒っている人を見たので…。

*2:社会人になってから「なんでブロッコリーは俺の研究室に入らなかったんだよ」的なイジリを複数回やられました

*3:ちなみに、コンピュータ室はUnix環境だったのですが、にしさんは「Unixというのはドジっ娘なメイドさんなんだよ」と、コンピュータリテラシーの初回の講義で話していましたのも印象に残ってます

*4:西研出身の方の記事で「にし研の学生は大体豆腐さんって呼んでる。会ったこともねぇのに。」と書いてあったけど、きっとブロッコリーも呼んでたのかな？知らんけど。

*5:あきやまさんの記事によると、設立順としてはJaSST→ASTER→JSTQB（ASTERの傘下としてジョイン）のようです

*6:JaSST Reviewの実行委員長を決めるときに、にしさんから「○○さんは△△の理事というポジションだし、××さんは◇◇のリーダーというポジションだし、俺はASTERの理事長だから、ブロッコリーが実行委員長で良いんじゃね？」という雑な振られ方をされて、流れで実行委員長になったのも、今となっては良い思い出です

*7:オンライン開催だったということもあり、その当時の講演映像のデータが残っていました。一般公開はできず、実行委員限定の映像となっているのですが、私はこの映像を見返して泣いてしまいました。

*8:余談ですが、にしさんはプロフィール文を2パターン用意してくれました。お堅めのプロフィール文と、WACATEで掲載することになったプロフィール文です。最終的にはWACATE実行委員の方で選んだのですが、公開されたプロフィール文の方がにしさんらしくて好きです

*9:このツイートは、私と同世代の伊藤さん宛に、にしさんがリプライしたものです。若い世代の人が悩んでいる姿を見て思わず伝えたくなったのでしょう

DevOpsのループ図およびシフトレフトテスト/シフトライトテストについての考察

Testing in DevOps 技術

はじめに

本記事は ソフトウェアテスト Advent Calendar 2023 および10X プロダクトアドベントカレンダー2023の5日目の記事です*1。

皆さんは「DevOpsに関する図を思い浮かべてください」と言われたら、どのような図を想像しますか？一番思い浮かべる人が多いのが、DevOpsのループ図ではないでしょうか？

DevOpsのループ図（vecteezyより拝借）

本記事では、DevOpsのループ図の発端を探しつつ、このループ図に対しての私なりの考えを述べた上で、シフトレフトテスト/シフトライトテストについて詳しく言及していきます。

目次

Danの考えるDevOpsのループ図

まず、DevOpsのループ図にはどのようなものがあるのでしょうか？

※12/5追記：Danの描いたDevOpsのループ図は発端では無かったため、本文中の表現を修正しました*2。

DevOpsのループを用いた図の1つとして、Dan Ashbyの「Continuous Testing in DevOps…」という記事*3があります*4*5。

Danの記事内に描かれているDevOpsのループ図を日本語訳したものがこちらになります。

記事「Continuous Testing in DevOps…」内記載の図に日本語訳を付けて作成

ループ図の解釈

DanのDevOpsのループ図からは、いくつか主張したい部分があると感じています。

テストの扱いについて

Danが描いたDevOpsのループ図をよく見てください。♾️の中に「TEST」という文字が存在しておらず、全てのフェーズに「テスト」の文字が刺されています。

Danは先述したブログ記事の中で以下のように述べています。

私にとって、テストはこのモデルのあらゆる点に適合します。

つまり、Danにとって♾️のループ図は、テストという活動が特定のフェーズに留まらないことを示すために描いたとも言えます。

一方で、冒頭に載せたような図のように、♾️のループの中に「Test」が描かれていることも多く、これはDanの示している意図とは異なることも理解できるでしょう*6。

ループの形について

この図はループになっています。これは、「リリース後にモニタリング(MONITOR)をテストして終わり」ではなく、次のプラン(PLAN)に繋げることの重要性を示していると言えるでしょう。

また、Danの記事内では以下のようにgif画像も用いながら記述しています*7。

しかし、図に欠けているものは何でしょうか…? 何かが足りない気がしてなりません…..
そうそう！それはもう明らかです！アイデアがないと計画を立てられませんよね？？

このモデルでは、計画を立てる前に行われるすべての作業については言及されていません。これについての私の考えを説明するために、爆発的なふわふわ雲の gif を示します。

アイデアを元に、計画を立てる前に行う作業のイメージ図

このgif画像では、アイデアが元にあり、そこからスリーアミーゴスやBDDといった活動を行って、ユーザーストーリーやマインドマップを作り、さらにコードやAPIなどに落とし込んでいくということを示していると理解しています。

つまり、モニタリングまで行ったことを元に、新たなアイデアが生まれ、そのアイデアがgif画像で示しているような活動を元に次のプランに繋がっていく形です。そうして、DevOpsがループしていくのです。

DevOpsのループ図とシフトレフトテスト/シフトライトテストの関係性

書籍『Agile Testing（邦訳：実践アジャイルテスト）』『More Agile Testing』『Agile Testing Condensed』の執筆者の1人であるJanet Gregoryは、Danの描いたDevOpsのループ図を元に、自身のブログ記事の中で「Continuous testing（継続的テスト）」として表現し直しました。

継続的テスト

この図を見ると分かりやすいのですが、デプロイをする前までのテスト活動（♾️の左側）をシフトレフトテスト、デプロイをした以降のテスト活動（♾️の右側）をシフトライトテストと表現することが多いです*8*9。

シフトレフトテストの具体的な活動は何か

上述では、デプロイをする前までの活動をシフトレフトテストと表現しました。それでは、いったいどのような活動なのでしょうか。

テスト駆動開発の適用

シフトレフトテストな活動で一番イメージがつきやすいのは、テスト駆動開発（以下、TDD）の適用でしょう。実装が終わった後だったテスト活動のタイミングを、実装をする前に行うように変えました。これもまさしくシフトレフトテストな活動といえます。

TDDのやり方について詳しくは、以下の動画をご覧ください。

www.youtube.com

実例マッピングの適用

ユーザーストーリーを書き終え、実装を始める前に行う活動である「実例マッピング」は、TDDよりもさらに前倒ししたシフトレフトテストな活動と言えるでしょう。

実例マッピングのやり方について詳しくは、以下の発表資料をご覧ください。

speakerdeck.com

レビューでの適用

テストで確認していた内容を、要求・要件レビューや設計レビューで確認することによってシフトレフトテストを実現することもできます。

これについて詳しくは、先日開催しましたJaSST Review'23の発表資料をご確認ください。セッション1の資料にて、以下の画像のような話を載せています。

レビューにおけるシフトレフトな活動の例

シフトライトテストの利点は何か

上述では、デプロイをした以降のテスト活動をシフトライトテストと表現しました。シフトレフトテストな活動に比べて、シフトライトテストな活動はあまり知られていません。そこで、なぜシフトライトテストを行うのかについて考えてみましょう。

シフトライトテストな活動を行う理由は主に2点あると私は考えています*10。

  1. 一般的なテスト活動（BUILDやINTEGRATE時点でのテスト）で解決するにはコストが高すぎるため
  2. 次の開発（PLAN）の参考にするため

シフトライトテストな活動を行う理由①：一般的なテスト活動で解決するにはコストが高すぎるため

一般的なテスト活動（BUILDやINTEGRATE時点でのテスト）で全てを明らかにしようとするとコストがかかりすぎるものが存在します。

例えばユーザビリティ観点です。ユーザビリティが良いかどうかについては、実際のユーザーの利用率を元に判断したい場合があります。理論的に良さを導き出すコストよりも実際にユーザーに使ってもらう方がコストが低い場合には、シフトライトテストとして任せるかもしれません*11。

なお、このようなものをシフトライトテストな活動にする際には、「この指標を用いて良さを判断する」とデプロイ前に計測内容を確定しておくことが大事です。とりあえずデプロイしてみて、その結果を後付けで考えるというのは得策ではありません。テスト結果はシフトライトテストな（デプロイ後に判明する）活動ですが、テストすべき指標の決定までシフトライトテストな活動にしないようにしましょう。

用いる指標の決定はシフトレフトの段階で行う

シフトライトテストな活動を行う理由②：次の開発の参考にするため

モニタリング結果などから次の開発に繋げる活動もシフトライトテストな活動と言えるでしょう。

この場合は、何か狙いを持っていなかったとしても、ユーザーがどのように使っているかを観察することで次に繋げられる場合があります。それは、「ループ図の解釈」の「ループの形について」で載せたgif画像のように、シフトライトテストな活動が次のアイデアに繋がり、それが次のシフトレフトな活動へと続いていくのです。

シフトライトテストな活動で見つけた気付きをアイデアとして次の開発に活かす

シフトライトテストの具体的な活動は何か（宣伝）

ここまででシフトライトテストな活動を行う理由について述べてきました。それでは、具体的にはどのような活動をすれば良いのでしょうか。 A/BテストやFeature flag(toggle)といったプラクティスは知られていますが、上述した「シフトライトテストな活動を行う理由」と紐づけて語られている事例はまだまだ多くありません。

まだ模索段階ではありますが、私が現在所属している10Xの開発チームではシフトライトテストな活動を行っています。そして、そこで実際に行った事例をRegional Scrum Gathering Tokyo (RSGT) 2024にて発表することになりました。

Regional Scrum Gathering Tokyo 2024 - できるだけ大きなアウトカムが得られるように、シフトレフトとシフトライトの両面から製品開発に取り組んだお話 | ConfEngine - Conference Platform

発表会場での聴講チケットは既に売り切れてしまいましたが、オンライン上からの聴講チケットはまだ販売しておりますので、ご興味のある方はお買い求めくださいませ！

2024.scrumgatheringtokyo.org

また、10X プロダクトアドベントカレンダー2023の6日目の記事で、こういちさんが具体的な活動の1つを紹介しています。こちらもご参照くださいませ！

note.com

おわりに（さらに宣伝）

今回はDevOpsのループ図とシフトレフトテスト/シフトライトテストについて述べてきました。

本記事の最後に書いた通り、10Xではシフトライトテストな活動も取り入れて、開発チーム一丸となって開発を進めています。私の所属している品質管理部では以下の職種で募集をしています。少しでも興味を持ってくれた方からのご応募をお待ちしております！

とりあえず話だけでも聞いてみたいという方がいればカジュアル面談もオープンにしていますので、こちらからどうぞ。

私とテストについて話したい場合はこちらからご応募くださいませ！

youtrust.jp

*1:アドベントカレンダーの前日の記事は、それぞれ以下の記事となります。

*2:もしかしたら、もっと昔に発端があるのかもしれませんが、私が調査した限りでは見つけることができませんでした。

12/5追記

辰巳さんより、発端の候補として2013年の記事があるそうです。辰巳さんありがとうございました！

www.appdynamics.com

*3:日本語訳の記事はこちら

*4:ここでいう、「DevOpsのループ図」とは、

  • ♾️の形をしている
  • 開発ライフサイクルの最初が左上に位置している
  • 起点（左上）から反時計回りで描かれ、右半分は時計回りで描かれている

を全て満たしているものとします

*5:細かいことを言うと、WEB上に公開されているものの中では「Continuous Testing in DevOps…」が発端でありますが、この記事を書く前からカンファレンスで同様のモデルを言及していたようです。

*6:ここではあくまでもDanの描いたループ図とは意図が異なることを示しただけであり、別の意図でループ図を使っていた場合には成り立つとも思っています。

*7:ちなみに、翻訳記事ではなぜかこのgif画像がカットされています。Danが主張したかった根幹の1つだと思うので、個人的には記載してほしいなぁ…と感じています。

*8:元々の単語の意味を考えると、「シフトレフト」とは、とある活動をタイムライン上の早い段階に前倒しすることを示します。しかし、一般的にテスト活動はビルド(BUILD)や統合(INTEGRATE)の際に行う活動と認知されているため、それを前倒ししている♾️の左側部分は総じてシフトレフトしていると言えるでしょう。シフトレフトテストに関して詳しくは、にしさんの発表資料を参考にすると良いです。

*9:今回は「継続的テスト」の図を本文で紹介しましたが、シフトレフト/シフトライトに対する誤解が生まれていることを感じてか、最近ではJanetは別の図を用いて紹介しているようです。詳しくは「Testing From A Holistic Point Of View」の記事（邦訳記事：「【翻訳】ホリスティック・テスト：プロセス全体からテストを捉えなおす（Testing From A Holistic Point Of View）」）をご覧ください。

*10:ちなみに、よくある誤解としてこんな話を耳にしました。

これに対する反論として本記事を書いている面もあります。

*11:「ユーザビリティ観点全てをシフトライトテストな活動で判断しろ」と言いたいわけではありません

【翻訳記事】新しいチームに移って8か月で起きたこと Part5 「今後の展望とチームの変遷の記録」

翻訳 Lisi Hocke

はじめに

本記事は A Tester's Journey: A Time of Transition - Eight Months on a New Team を日本語訳したものです。

この記事は、著者のLisi Hockeが、新しいチームにJoinして8ヶ月間で起きたことを赤裸々に語っています。その中で、どのようにチームにフィードバックを促し、どのようにチームを変化させていったのかが詳細に語られており、大変良い記事だと感じたため、今回翻訳することにしました。

なお、元記事が長文なため、翻訳記事は計5回に分けてお届けします。

  1. Joinする前のチーム状況
  2. チームに入ってから8ヶ月間で起きたこと
  3. 現在のチームの状況
  4. チームが変化できた要因
  5. 今後の展望とチームの変遷の記録（本記事）

本記事は第5回です。

このチームに関する詳しい内容や、記事執筆後に起こった変化はJaSST Review'23にて講演予定です！（同時通訳付き）

興味を持たれた方は以下のページから参加申し込みをお願いします！

www.jasst.jp

目次

次は何をしますか？

この 8 か月の間にたくさんのことが起こりました。このチームは、私が昨年 12 月に入社したときに出会った人々のグループとはもはや比較できません。私たちは実際に自分たちの物語を作り始めましたが、これで終わりではありません。私たちの将来に何が待ち受けているのか、そしてチームと組織のニーズに合わせてそれを形作るために何ができるのかを楽しみにしています。

私たちは今、より持続可能なペースに戻り、過去数か月間で落とさなければならなかったものを取り戻しました。チームとしてさらに成長しつつあり、新たなエキサイティングな時期が始まります。深く掘り下げるトピックや、チームの観点から推進すべきさらなる取り組みがたくさんあります。解決すべき問題はさらに増え、摩擦は軽減されなければなりません。より価値のある製品を構築するために学ぶべき多くの知識、スキル、ツールがあります。私たちは今、技術的な基礎に取り組み、生きたチーム文化として実験に成長し、他のチームとのさらなるつながりを築くことができます。やるべきことはたくさんあります。チャンスはたくさんあるので、すぐに退屈することはありません。

さらに、組織に関するトピックがいくつかありますので、詳しく説明していきたいと思います。今は通常の作業ペースに戻りつつあるので、じっくり考え、次の取り組みや実験について真剣に立ち止まって考える時間がもっと取れるようになります。さまざまな組織の中で、チーム間でより多くの知識を共有したいと考えています。チーム間での実践的なコラボレーション、特にペアリングやアンサンブルのセッションを増やすことを考えています。また、より大規模な変化を達成するために、これまでに組織的に観察したことに基づいて行動したいと考えています。早く学ぶには何を最初に試すべきか、どこに最も影響を与えるか、そして何が自分の成長につながるのかを見極める必要があります。同じ組織内で起こるということ以外に、次に何が起こるかはわかりません。私自身も将来に興味があります。

改めてチームのことを考えてみると、人間にとって変化には本当に時間がかかります。 私たちは短期間で長い道のりを歩んできました、そして感謝しています。

おまけ: コラボレーションのお祝い

私たちのチームの変遷が私のツイートに時間の経過とともに反映されているのがわかります。それらのいくつかは、すでに上でコンテキストに埋め込んでいます。しかし、特にコラボレーションを強化し、チームとしての親密さを高めることに関しては、それだけではありません。ここ数か月のコラボレーションのハイライトを紹介するツイートをまとめました。私はあらゆる小さなことを祝いますが、間にはたくさんの空白があることを覚えておいてください。それでも、私が一緒に働くことを光栄に思っている善良で素晴らしい人々を称えることには、とても価値があります。

今週、同僚からフィードバックという形でかなりの数の贈り物を受け取り、感謝しています。🙏🏻 今日のハイライトは、私のチームの開発者からのものでした。「あなたには才能があります。あなたと話しているだけで、たとえ聞いているだけでも、私の頭の中でアイデアが生まれます。」🌟

私のチームの 4 人は問題を調査するために毎日残っていました。 私たちは一緒に欠けていた手がかりを見つけ、それを修正し、うまくいきました。そして私たち全員がお互いから新しいコマンド、ショートカット、洞察を学びました。 暗黙知が明示的になり、それによって倍増するこのような状況が大好きです。🤩

なんて楽しい仕事の一日でしょう！専門知識を結集してセキュリティ要件を一緒に理解します。アプリのセキュリティテスト。レジリエンスの構築について意見を交換します。コンプライアンス、特にトレーサビリティについてさらに学びます。ウィキをクリーンアップしています。ああ、猫についてのおしゃべりも！ 🐈

今日は仲間の開発者との素晴らしいペアテストセッションでした。彼は手伝いに来て、これをテストする方法を私から学び、一緒に調査しました。彼は何が問題なのかすぐに気づき、私たちはそれを修正し、さらに調査し、新しいテスト可能性の問題を解決して、完了しました。 💪🏻 私たち二人とも勉強になりました！ 🙌🏻🎉

今日のハイライト: 開発者のチームメイトが、常に物事を把握しており、ストーリーのテスト結果について私を褒めてくれました。私のアプローチは彼らにとって新しいもので、本当に価値があり、探索的テストとは何かを理解させました😊 (これらすべてがどの程度のものであるかは関係ありません。本当です、受け取ります 😉)

今日のハイライト: フロントエンド開発者がペアテストを申し出て、私たちはバックエンドサービスに欠けている機能を発見し、それを実装したところです。💪🏻 まだまだやるべきことはありましたが、何を変更する必要があるのかを理解しました。それがうまく機能し、テストが可能になりました。ピースが所定の位置に収まったときは最高です! 🎉

これ、これがエンジニアリングであるべきものです。 人間は他の人間をサポートし、分かち合い、思いやり、そして変化をもたらします。 私は、チームを知ってから短期間でチームがどれほど遠くまで到達したか、そして私たちの先にはさらに多くのことがあることを非常に誇りに思っています。 👏🏻👏🏻👏🏻

今日、親愛なる開発メンバーが知識共有とペアリングのセッション中に私に教えてくれた内容がとても気に入りました。私たちは皆、物事がまだスムーズではないことに痛みを感じ始める必要があるため、全員がそれらを改善することに熱心です。🙌🏻とても熱心です。問題を可視化して経験できるようにする必要があります。

今日は開発者とペアになりました。
私: このツールでアプリの状態を確認する方法と、パスを指定した場合に変更をサブスクライブする方法を知りました。
彼：すごいですね！ パスを提供しない場合はどうなるでしょうか？🤯
完全な状態をサブスクライブできると考えました。💪🏻
勝利のためのペアリングでした。 🙌🏻

今日もペアリングが機能しました。💪🏻
1) システムの知識と戦略を効果的に交換することで、テストの時間と労力を節約しました。これは、私たちが取り組んでいる複雑な大きなテーマにとって非常に貴重です。
2) 2人で問題を確認し、一緒に迅速に解決できるようになりました。 🙌🏻

今日、開発者が、変更を一緒にテストするために2つ目のペアリングを求めてきました。 別の開発者が参加し、ペアになりました。それから私も参加しました。この自発的なアンサンブルの中で、私たちはテストし、ギャップを特定し、問題を軽減することを決定し、実装してリファクタリングし、理解を調整しました。効果的でした！💪🏻

先週は高揚感のあるうちに終わりました。
1) 今週は私が休みなので、私のチームがすべてのテスト活動を引き継ぎ、たくさんの素晴らしい質問をしてくれました。 この時期に彼らが何を学ぶのかとても興味があります！💡
2) 自発的なアンサンブルによってテストされ、バグ修正をリリースします。💪🏻
3) 素晴らしいフィードバックをいただきました😊

今日で新しい会社で半年が終わりました！🎉素晴らしい旅でした。これからもたくさんのことが待っています! 💪🏻 また、今日（偶然ですが）、私はチームにとってこれまでで最長となる、2週間の休暇に入ります。 彼らがこれを手に入れたのはわかっています！ 🙌🏻 ある開発者はこう言いました。「心配しないでください、私たちは練習しました」。 😊

ベストな一日ではなかったけど、私にとって今日は何だったと思う？私が仕事に戻ったにもかかわらず、開発メンバーがまだお互いに変更をテストし、またお互いに（勝利に向けてペアを組んで）テストしている様子を見ました。私はその姿を見るのが大好きです。そして、私自身のテストとペアリングも楽しんでください。😊

先週の仕事のハイライト：開発メンバーとよくペアを組みました。現在のシステムの振る舞いなどについて学び、予期せぬサプライズを発見し、その原因を解明し、作業を進めていくうちに問題をすぐに修正および改善しました。迅速なフィードバックと迅速な改善になったのです！💪🏻

自分たちの知識、経験、アイデアを組み合わせて持ち合わせなければ、どれほど危険だったかを身を持って認識しました。声を出して考えることで、私たちの会話が新しいアイデアや試行を引き起こし、それをもとに構築していきました。それがなければ、重大な問題を見つけることはできなかったでしょう。

ふー、今日はなんて日だろう！問題調査、リリース文書、テストセットアップ、チーム全体のシステムテストに関する 4 つの異なるアンサンブルを行いました。そして、開発メンバーとのボーナスペアリングセッションでは、JavaScript の奇妙な挙動を発見し、修正を見つけ、テストを追加しました！とても効果的でした。🚀