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

技術

はじめに

本記事はソフトウェアテスト 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 の奇妙な挙動を発見し、修正を見つけ、テストを追加しました！とても効果的でした。🚀

【翻訳記事】新しいチームに移って8か月で起きたこと Part4 「チームが変化できた要因」

翻訳 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. 今後の展望とチームの変遷の記録

本記事は第4回です。

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

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

www.jasst.jp

目次

この移行の促進となった要因は何ですか?

社内外の人々から、私がチームの変革にどのように貢献したかを尋ねられました。はい、私も上記の取り組みに参加しましたが、これを達成するために多くの人々が協力してきました。この旅で何が私を助けてくれたかを考えてみると、これについてはさらに考える必要があることに気づきました。これを次回のプロポーザルのテーマにしようと考えています。そこには、試してさらに発展させていくためのインスピレーションがあるかもしれないと思うからです。物事がうまくいく方法はたくさんあると思います。現時点では方法が見つからないときでも、このような経験を共有することで、新たな火種が生まれ、何か違うことに挑戦できる可能性があります。とりあえず、ここ数か月間で私にとって役立ったことをいくつか共有したいと思います。

私の「親愛なる未来の私へ:私は一人ではない」という投稿を思い出してください。ピーク時にはこのことを自分に言い聞かせる必要がありました。 二度と同じような状況に陥るつもりはなかったのに、ここに来てしまったのです。昨年の私自身のアドバイスは、今年も私にとって貴重なものでした。

他に何が役に立ったでしょうか？忍耐、忍耐、そして忍耐です。そして多くの楽観主義と希望を持つことです。新しい考え方を採用し、行動を変え、システムを形成するには長い時間がかかります。結局のところ、私たちは人間と一緒に働いており、私たち自身も人間です。私たちも常に最高の日々を過ごせるとは限りません。長期戦に臨みましょう！そして、何か賞賛に値するものを見つけたら、必ず祝いましょう。本当に、旅の一歩一歩、どんな小さなことでも祝いましょう。うまくいかない時期を乗り越えるために、私はそこから多くのエネルギーを得るのです。私が公の場でこれをやっているのをよく見かけるかもしれません。外から見ると、すべてが美しく輝いていると思うかもしれません。しかし、そうではありません。同様の努力が必要です。同様の忍耐が必要です。私は勝利するたびに祝いますが、それ以上に失敗することもたくさんあります。ただしそれは問題ありません。私の知っている近道はありません。やるべきことはまだたくさんありますが、私たちはそれを自分たちの手で成し遂げることができます。

それは本当です！楽観主義は、私が共により良い方向に進み続けるために多くのエネルギーを引き出すところです。物事の良いところを見ようとして、それを増幅させてみましょう。あまり理想的ではない状況を、私たち全員にとっての学習の機会として組み立てます。ああ、私はいつも楽観的ではなく、ただ練習を続けているだけです。

過去に良い経験をしたことから多くのことを引き出しました。例えば、どんな状況にも好奇心を持って取り組み、学びたいという気持ちを示します。うまくいっていることに感謝し、ポジティブな面を追求し、良い面を改善します。助けてくれたことに感謝の気持ちを示し、それが私にとって大きな影響を与える理由を説明するようにします。人々が特定の方法で行動するのには、通常、正当な理由があることを知っています。多くの人は良い経験をしたことがなかったり、物事を試す機会や許可がなかったりします。ですから、物事を試す機会を彼らに与えて、彼ら自身に経験をさせましょう。自分自身の行動を変えます。私には他の人を変えることはできません。観察し、透明性を獲得し、意識を高め、人々を実験に誘いましょう。たくさんの「私たち」の考え、「私たち」のメッセージ、「私たち」のアクションがあります。本物でありつつも脆弱な存在であり、成功も失敗もすべて共有します。理論にこだわらず、具体的なアクションに取り組みます。それが実現不可能なら、誰も拾わないでしょう。人々の仕事を妨害したり門番したりするのではなく、サポートする形でアクションします。基礎を整える際には、現実主義を多用し、高い理想に固執しすぎないようにします。人々とそのニーズに非常に近くで動きます。彼らの言語で話します。現在いるところからスタートし、そこから徐々に改善していきます。現状よりも良いものを目指して努力しますが、完璧を目指すことは決してありません。現在よりも良いもので十分です。行動や決断の背後にある理由、その理由を説明しましょう。

誰もが同じではない、それは素晴らしいことです。私のチームには早期採用者と後期採用者がいます。場合によっては、1 人が両方とも異なるテーマに取り組んでいることもあります。どちらのタイプも、以前のポジションに比べて大幅な移行を行いました。遠慮していた人がすぐに私へ通話をするようになりました。これまで一度も一緒に仕事をしたことがなかった人が、同じ重要なアクションにもっと目を向けてもらうよう、参加する人たちに求めるでしょう。これは私自身の未来に対する理想ではない（常に変化する）かもしれませんが、同時にこれは彼らにとって大きな一歩であり、私は個人的に非常に前向きに判断しています。つまり、全員が同時に同じジャンプをすることを期待しないでください。人は自分のペースで進む必要があり、人によって課題が異なります。

変化を誘いたい人に仕事の内容が見える場所（チケットのコメントなど）で仕事をしましょう。特定のこと（最初に単独でテストする、API のみをテストする、コードを読む、テストをテストするなど）を実行する価値があると彼らに納得させようと試みないでください。代わりに、実行して、結果とアウトカムに納得してもらいましょう。すぐにうまくいかない場合でも、それを個人の責任だと受け止めないでください。これには多くの時間がかかることを覚えておいてください。自信は助けになりますが、多くの場合、すでにチームを引っ張る必要がある一方で、自分自身の自信を築かなければなりません。これはチャレンジです。それについてはっきりと伝えるようにしてください。しかし、先延ばしにしないでください。 そう、私にもまだまだ勇気が必要なのです。

つい先週、私はMary Lynn MannsとLinda Risingによる素晴らしい本『More Fearless Change』をついに読み終えました。そして、この本の中で言及されている変化を助けるために自分がさまざまなパターンをたくさん使っていることに気づきました。とても心に響きました。信じられないほどです。変化を望んでいるなら読むことを本当にお勧めします。

ほかに何かありますか？お互いを知り、関係を築きましょう。私たちは一緒にこの問題に取り組んでいます。安全な空間を作りましょう。そうすれば、学習に集中し、物事を試し、何が起こるかを確認できるので、全員が向上し、毎日少しずつ改善できるようになります。ですから、まずは、思い切って何かを試してみてください。何もしないことは何も役に立ちません。他の人は行わないか、あなたが望んでいる方法では行いません。自分で行動を起こしましょう。完璧である必要はありません。昨日より少し良くなるだけで十分です。大きな一歩である必要はありません。ほんの小さな一歩です。正式なリーダーシップの立場にある必要はありません。キャリアのスタート時点から物事を変える力があります。観察し、何かを試し、何が起こったのかを振り返ります。この学習に基づいて、別のことを試してください。続けてください。

Part5「今後の展望とチームの変遷の記録」に続く…

【翻訳記事】新しいチームに移って8か月で起きたこと Part3 「現在のチーム状況」

翻訳 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. 今後の展望とチームの変遷の記録

本記事は第3回です。

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

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

www.jasst.jp

目次

私たちは今どこにいますか？

私たちはこの旅において大きな進歩を遂げました。 私たちがどこから始めたか覚えていますか？私たちが今見ているものと比較してみましょう。

あらゆる種類のコラボレーションが起こっています

同じ仮想空間で並行して作業する同期ペアリングとアンサンブル、および非同期なソロ作業。 人々が今どこにいても、彼らが今最善だと考えるものは何でも起こっています。そして今も進化中です。

コミュニケーションが大幅に増加し、物事が明確になりました

これは主に同期作業で発生しますが、チームチャンネルや通話でも観察されることがあります。チーム間でも同様です！

デフォルトで一体感がありアクセスしやすい

このトピックについては今後も引き続き学習していきますが、人々がチームのことを考えて振る舞いを変え、それが自分自身にも利益をもたらしたことがすでに分かっています。これは私たちにとって大きな変革でした。

我々のプロダクトに対する信頼性が高く、問題が少なくなりました

迅速かつ早期のフィードバックが功を奏しました！同様に、テスト容易性が向上し、誰もが基礎的なテストを実行できるようになりました。 役割を越えて知識を共有しましょう。多様な視点も含めましょう。それが全てです。

システム思考が高まり、物事を成し遂げることへの集中力が高まりました

開発メンバーは、アクションがシステム全体にどのような影響を与えるかを認識し始めました。フローとキュー、スループットと待機時間などが表示され始めました。役割や主な専門分野を越えてどのようにお互いに助け合うことができるか、どのように負荷を共有できるかが分かるようになりました。 時々フィードバックが再び遅くなることがありますが、開始時に比べてフローは大幅に改善されました。

何かを試すことがより安全でより普通になりました

私たちは実験駆動の文化をまだ持っていませんが、自分たちで決定を下し、何かを試してみるという自由を感じるだけで、チームメンバーは解放された気分になりました。 私たちはすでに多くのイニシアチブを目にしており、良いものを維持できています。

1つのチームになった

私たちは皆、ずっと仲良くなりました。今では私たちは本当にチームだと言えるようになりました！このチームで働き、スピリットを体験し、素晴らしいものを共同で創造することがすごく楽しいです。そしてこれは決して終わりではなく、これからも続く旅です。

以前とは別のチームとして見られるようになった

私たちの評判と外部の認識はすでに肯定的なものに変わりました。 私たちはこれを意図的に改善するために継続的に取り組んでいます。

@lisihocke 自分のチームを本当に誇りに思うと言えます！ #言ってみただけさ

私たちも、ようやく穏やかな海域に入りつつあります。私たちは皆、当面は、この巨大なEpicのような私たちが直面する課題を達成するために、厳しい決断を下す必要があることを認めます。はい、いくつかの問題はありましたが、全体としては、物事が非常にスムーズに進んだことを非常にうれしく思います！非常に素晴らしいパトリック・プリルを含む、近くのチームにも多大な感謝と称賛を送ります。親密でとても協力的なコラボレーションが大好きでした。彼らはこの成功に大きく貢献し、チームの歩みにも非常に良い影響を与えました。

また、私は今、これまでのキャリアの中で最も多様なチームで働いていることもお伝えします。メンバー10人は、出身国が9か国、人種が4種類、女性が3人、学歴や子育てなども意識した構成になっています。はい、確かに私たちは特定の視点を見逃しています。同時に、私たちはこれまでに 1 つのチームにまとめたことのないほど多くのメンバーを擁しています。とても貴重です、とても勉強になっています。

これはすべて簡単なことではなく、本当に困難なことでした。それは挑戦であり続けるでしょう、私は確信しています。しかし今、私たちは本当にこの問題に取り組んでおり、全員でより良い方向に進むことができます。私たちは成長し、変化しています。未来が私たちを待っています。

ついに起こりました。私のキャリアを通じて初めて、0人や1人ではなく、2人の女性と同じチームに所属することになりました。🎉 まあ、私たちが12人という巨大なチームであることが影響していると思いますが。また、性別を除けば、私がこれまで参加した中で最も多様なチームです。❤

Part4「チームが変化できた要因」に続く…