Googleスライドで紙芝居的に強調する場所を示すコツ

はじめに

先日、Developers Summitで講演してきました*1

event.shoeisha.jp

発表スライドはこちら

speakerdeck.com

このスライドを作成する際に使った、紙芝居的に強調する方法をご紹介します。完成形はこんな感じです。発表スライドのp9とp10が該当します。

なお、今回の元画像はryuzeeさんのプロダクトマネジメントの”罠”を回避しよう のスライドから拝借しています。

作り方

1.強調する前の画像を作成する。

2.画像をクリップボードにコピーする

3.半透明のオブジェクトを作成する

Googleスライドでは、透明度も含めてカラーコードが指定できます。私の場合、黒背景の半透明の場合(今回の場合)は「#000000bf」を、白背景の半透明の場合は「#ffffffbf」を指定しています。

黒背景の半透明のオブジェクトを画像の上に貼った状態

4.手順2でコピーした画像を貼り付ける

5.手順4で貼り付けた画像と手順1の画像の位置を揃える(ガイドが表示されるので、簡単に揃えられるはずです)

6.【今回のポイント!】画像を選択し、メニューバーにある「画像を切り抜く」のアイコンをクリックする

「画像を切り抜く」のアイコン

7.【今回のポイント!】強調したい場所のみに範囲を狭める

8.範囲を狭めたオブジェクトの外枠に色を付ける

完成!

おわりに

今回は紙芝居的に強調する方法をご紹介しました。

今回の場合以外にも、「画像を切り抜く」は様々な装飾に活用できますので、ぜひお試しあれ!

*1:ちなみに、今回のDevelopers Summitではもう一つセッションを持っていました。そちらについては別記事をあげていますので、気になる方はそちらもどうぞ!

nihonbuson.hatenadiary.jp

Developers Summitの新人研修セッションの中で「新人研修マニフェスト」を発表しました #devsumi

はじめに

先日、Developers Summitで、及部さんやっとむさんと一緒に新人研修に関するパネルセッションを行いました*1

event.shoeisha.jp

その冒頭で、新人研修マニフェストを発表したので、ここでも紹介します。

新人研修マニフェスト

新人研修マニフェスト

テキストにもしておきます。

  • 新人研修の充実よりもエンジニア人生の充実を
  • 包括的なカリキュラムよりも学び方を学ぶことを
  • 教えるよりも一緒に学ぶ関係性を
  • 計画に従うことよりもリアルな現場体験を

価値とする。
左記のことがらに価値があることを認めつつ、わたしたちは右記のことがらにより価値をおいています。

マニフェスト誕生の経緯

このマニフェストは、今回の新人研修セッションを行うにあたり、事前の打ち合わせの内容をもとに及部さんが作成したものです*2

当日にパネルディスカッションをやっていても、各登壇者がこのマニフェストに書いた内容を大切にして新人研修を行っているなと改めて感じられて*3、「及部さんの言語力すげー」となってました。

おわりに

今回は登壇者3人が共通して大事に思っていることをもとに新人研修マニフェストを作成してみました。

もしも、「こんなことも大事なんじゃね?」とか意見がありましたら、フィードバックくださいませ!

追記

既に頂いてたコメントに対しての私の考えを書いておきます。

調べ方を教えるのも重要なんじゃない?

それも含めて「リアルな現場体験」の中に包含するかもしれないです。

いくら特定分野の調べ方を教えたところで、別分野では調べ方が分からなければあまり意味がないかもしれません。「○○は社内用語だよ」と伝えてもキリがないです。

それよりかは、リアルな現場を提供した上で、それを調べるという体験がやはり重要かなと考えています。そこで、うまく調べられなかったという経験も大事かなと思っています。「こうやって調べれば良いんだよ」という、予めの「計画に従うこと」を目指していない気がします。

テストとか品質に対してこのマニフェストは難しいんじゃない?

はい、難しいと思います。kawagutiさんが似たようなことを仰ってた。

なので、「教える」となることが多い中でも、どのようにすればマニフェストの内容に近づけるのかを考えるのが腕の見せ所ですね。

*1:今回のDevelopers Summitでは、私個人の公募セッションもありましたが、そちらについては後日記事を書く予定です。

event.shoeisha.jp

*2:なんか、私がブログ記事でこの新人研修マニフェストを公開しちゃってますが、©︎TAKAKING22として良いと思うぐらいです

*3:実際、聴講者もそのように感じていたようです。

『Software Design 2024年2月号』に寄稿したテストの考え方を用いた、具体的なテストの改善例

はじめに

先日、私が第1特集「新しいソフトウェアテスト講座」の第1章「ソフトウェアテストとは何か?」を寄稿した、『Software Design 2024年2月号』が発売されました。

gihyo.jp

この雑誌を読んだ黒柴さんが、雑誌の第1特集をキッカケとして*1ブログ記事を書いてくださりました。ありがとうございます!

note.com

そこで、本記事では、上記の記事に載っている題材について、第1特集の第1章でお伝えした内容を活用して、改善案を書いてみたいと思います。

目次

黒柴さんのブログ記事の概要

参考元にしている黒柴さんのブログ記事では、以下のような題材を扱っていました。

仕様:
ある工場では、3直で24時間勤務を行っており、アプリの画面には現在の直で実施予定の作業情報を表示する
そのため、テスト対象の処理ルーチンでは、現在時刻を元に現在の直の開始時刻を算出する仕様としている
各直の勤務時間は以下のとおりとする

直ごとの勤務時間
テストケース:
担当者(実装、およびユニットテストを担当)が考えたテストケースは、以下のようなものだった
誤ったテストケース
このテストケースは、直の仕様を以下のようなパーティション分割であると整理して作成したものと予想される
テストケースの元にした直のパーティション
不具合の詳細:
上記のテストケースでは、日付が考慮されていない
そのため、項番4の7:29では前日の23:00を直の開始時刻とするべきところを、時刻のみを計算して直の開始日時としているため、当日の23:00を開始時刻として出力していた
この点では、対象の処理ルーチンが「直の開始日時」ではなく、「直の開始時刻」を算出していることに問題がある

提示された仕様では、直の情報に日付が定義されていないが、時刻のみならず日付も考慮したうえで、以下のように整理されるべきであると考える

日付を考慮した直のパーティション

テストプロセスを踏まえて考え直す

Software Design 2024年2月号』の私の寄稿の中で示している通り、個人的にはテストプロセスを踏まえた方が良いと思っています*2

ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J01(以下、JSTQB)で示しているテストプロセス

なので、まずはテスト分析から考えてみます。

テスト分析

今回の場合、「何をテストしたいのか」という考え(これを「テスト条件」と言います)でいくと、以下のような部分が気になります。

  • a)現在の勤務に応じて表示が変わるのか
    • 例えば、現在時刻が二勤の時間帯の場合は、"15:30"という表示になるのか
  • b)勤務が被っている部分についてはどのように表示されるのか
    • 例えば、現在時刻が15:31の場合は、一勤の時間帯なのか、それとも二勤の時間帯なのか
  • c)日付を跨いだ場合、適切に表示されるのか
    • 例えば、現在時刻が02:00の場合は、"00:00"とはならずに、"23:30"という表示になるのか
  • d)休憩時間中の場合、適切に表示されるのか
    • 例えば、現在時刻が12:00の場合は、"07:30"という表示になるのか

このうち、a)は元々行われていたテスト条件、c)は発生した不具合で漏れていたテスト条件となります。また、b)とd)は私が必要だと感じたテスト条件です。個人的には特にb)に不具合が潜んでいそうだなと感じています。

続いて、これらのテスト条件に対してのテスト設計技法の適用を考えます。

今回は時刻について、a)とb)についての同値分割および境界値分析と、c)についての同値分割および境界値分析と、d)についての同値分割および境界値分析を行うのが適切だと考えました。なぜ、a)b)とc)とd)で分けたかというと、一緒くたに表現すると、何をテストしようとしているのか見通しが悪くなると感じたからです。

現在の勤務に応じた表示に関するテスト設計およびテスト実装

テスト設計(同値分割)

以下のように同値分割します。

現在の勤務についての同値分割をした結果

同値分割で大事なのは、複数のパーテーションに属することがないようにすることです。

JSTQBシラバスでも以下のように書かれています。

パーティションは、重複してはならず、空でない集合でなければならない。

そのため以下のような表現は、同値分割法で表現できていないことになります*3

同値分割の考え方にそぐわない表現方法

テスト設計(境界値分析)

同値分割を行った結果を用いて、境界値分析を考えると、以下のようになります。

現在の勤務についての境界値分析をした結果(同値分割の※1周辺のみを抜粋)

今回の図では※1周辺のみを示しましたが、※2、※3周辺も同様に表現できるはずです。

テスト実装

テスト設計で明らかになった境界値を考慮して作成したテストケースは以下のようになります。

境界値を考慮して作ったテストケース

このうち、「???」とした部分は、元々の記載内容だけでは判断できなかった部分です。この部分こそ、チームで議論し、明らかにすべき箇所です。

このように、プログラムを1文字も書かなくてもテストを考えることができますし、場合によってはテスト実行をせずとも、テスト実装以前の段階で不具合を発見することができます

2024/02/06追記

元々の記載内容だけでは判断できなかった部分について、黒柴さんに補足していただきました。ありがとうございます!

日付を跨いだ場合の表示に関するテスト設計およびテスト実装

テスト設計

前述までと同様、同値分割を行います。なお、勤務が被っている部分については、前述のテスト設計を元に議論した結果、後続の勤務グループの時間として判断したとします。

日付を考慮して同値分割をした結果

境界値分析の図示は、前述と同様の表現となるため割愛します。

テスト実装

テスト設計で明らかになった境界値を考慮して作成したテストケースは以下のようになります。

境界値を考慮して作ったテストケース

ここまでと同様に、休憩時間中の表示に関するテスト設計およびテスト実装も行うことができるはずです。今回は説明を割愛します。

テストコードの表現への活用

さて、ここまで整理してきたテスト設計やテスト実装の情報は、テストコードに活かすことができないのでしょうか。

私は活かすことができると考えます。テストメソッド名やテストコードの構造化に役立てることができます。

元記事に書いてあったテストケースの表は以下のようになります。

テストケースの表

これをそのままテストコードで表現してしまうと、見通しが少し悪い(保守性が悪い)テストコードができてしまう可能性があります。少なくとも、数年後にこのテストケースを見た時に、どんな目的で書かれたテストなのかが分からなくなっているでしょう。

一方、今回のテスト分析で示したように、a)、b)、c)、d)で分けて表現するといかがでしょう。例えば、以下のようになります*4

public class DisplayDateTimeTest {

    @Nested
    @DisplayName("現在の勤務グループに応じた表示のテスト")
    class JudgeGroupTest {

        @Test
        @DisplayName("一勤と判断される時間帯のテスト")
        void judge_first_group(){
            assertEquals(displayDateTime("2024/02/05 13:00"), "2024/02/05 07:30");
        }

        @Test
        @DisplayName("二勤と判断される時間帯のテスト")
        void judge_second_group(){
            assertEquals(displayDateTime("2024/02/05 17:00"), "2024/02/05 15:30");
        }

        @Test
        @DisplayName("三勤と判断される時間帯のテスト")
        void judge_third_group(){
            assertEquals(displayDateTime("2024/02/05 23:45"), "2024/02/05 23:30");
        }
    }

    @Nested
    @DisplayName("勤務が複数被っている付近の時間帯のテスト")
    class DuplicateGroupTest {

        @Test
        @DisplayName("一勤の勤務時間と判断される最後の時刻のテスト")
        void judge_first_group_end_boundary_time(){
            assertEquals(displayDateTime("2024/02/05 15:29"), "2024/02/05 07:30");
        }

        @Test
        @DisplayName("二勤の勤務時間と判断される最初の時刻のテスト")
        void judge_second_group_start_boundary_time(){
            assertEquals(displayDateTime("2024/02/05 15:30"), "2024/02/05 15:30");
        }

        @Test
        @DisplayName("二勤の勤務時間と判断される最後の時刻のテスト")
        void judge_second_group_end_boundary_time(){
            assertEquals(displayDateTime("2024/02/05 23:29"), "2024/02/05 15:30");
        }

        @Test
        @DisplayName("三勤の勤務時間と判断される最初の時刻のテスト")
        void judge_third_group_start_boundary_time(){
            assertEquals(displayDateTime("2024/02/05 23:30"), "2024/02/05 23:30");
        }

        @Test
        @DisplayName("三勤の勤務時間と判断される最後の時刻のテスト")
        void judge_third_group_end_boundary_time(){
            assertEquals(displayDateTime("2024/02/06 07:29"), "2024/02/05 23:30");
        }

        @Test
        @DisplayName("一勤の勤務時間と判断される最初の時刻のテスト")
        void judge_first_group_start_boundary_time(){
            assertEquals(displayDateTime("2024/02/06 07:30"), "2024/02/05 23:30");
        }
    }

    @Nested
    @DisplayName("日付を跨いだ場合のテスト")
    class AcrossDaysTest {

        @Test
        @DisplayName("当日の三勤の勤務時間と判断される最後の時刻のテスト")
        void judge_today_third_group_end_boundary_time(){
            assertEquals(displayDateTime("2024/02/05 23:59"), "2024/02/05 23:30");
        }

        @Test
        @DisplayName("前日の三勤の勤務時間と判断される最初の時刻のテスト")
        void judge_yestarday_third_group_start_boundary_time(){
            assertEquals(displayDateTime("2024/02/06 00:00"), "2024/02/05 23:30");
        }
    }
}

テストコードのさらなる改善

上記のコードだと「どの勤務グループなのか」と「勤務グループの開始時刻はいつなのか」の2つの確認を合わせて行っています。そこで、さらにテストコードを改善してみます。

public class DisplayDateTimeTest {

    @Nested
    @DisplayName("現在の勤務グループの判定テスト")
    class JudgeGroupTest {

        @Test
        @DisplayName("一勤と判断される時間帯のテスト")
        void judge_first_group(){
            assertEquals(judgeGroup("2024/02/05 13:00"), "一勤");
        }

        @Test
        @DisplayName("二勤と判断される時間帯のテスト")
        void judge_second_group(){
            assertEquals(judgeGroup("2024/02/05 17:00"), "二勤");
        }

        @Test
        @DisplayName("三勤と判断される時間帯のテスト")
        void judge_third_group(){
            assertEquals(judgeGroup("2024/02/05 23:45"), "三勤");
        }
    }

    @Nested
    @DisplayName("勤務が複数被っている付近の時間帯の勤務グループの判定テスト")
    class DuplicateGroupTest {

        @Test
        @DisplayName("一勤の勤務時間と判断される最後の時刻のテスト")
        void judge_first_group_end_boundary_time(){
            assertEquals(judgeGroup("2024/02/05 15:29"), "一勤");
        }

        @Test
        @DisplayName("二勤の勤務時間と判断される最初の時刻のテスト")
        void judge_second_group_start_boundary_time(){
            assertEquals(judgeGroup("2024/02/05 15:30"), "二勤");
        }

        @Test
        @DisplayName("二勤の勤務時間と判断される最後の時刻のテスト")
        void judge_second_group_end_boundary_time(){
            assertEquals(judgeGroup("2024/02/05 23:29"), "二勤");
        }

        @Test
        @DisplayName("三勤の勤務時間と判断される最初の時刻のテスト")
        void judge_third_group_start_boundary_time(){
            assertEquals(judgeGroup("2024/02/05 23:30"), "三勤");
        }

        @Test
        @DisplayName("三勤の勤務時間と判断される最後の時刻のテスト")
        void judge_third_group_end_boundary_time(){
            assertEquals(judgeGroup("2024/02/06 07:29"), "三勤");
        }

        @Test
        @DisplayName("一勤の勤務時間と判断される最初の時刻のテスト")
        void judge_first_group_start_boundary_time(){
            assertEquals(judgeGroup("2024/02/06 07:30"), "一勤");
        }
    }

    @Nested
    @DisplayName("日付を跨いだ場合のテスト")
    class AcrossDaysTest {

        @Test
        @DisplayName("当日の三勤の勤務時間と判断される最後の時刻のテスト")
        void judge_today_third_group_end_boundary_time(){
            assertEquals(displayDateTime("2024/02/05 23:59"), "2024/02/05 23:30");
        }

        @Test
        @DisplayName("前日の三勤の勤務時間と判断される最初の時刻のテスト")
        void judge_yestarday_third_group_start_boundary_time(){
            assertEquals(displayDateTime("2024/02/06 00:00"), "2024/02/05 23:30");
        }
    }
}

このようにすることで、もしもテストがNGになった場合にも、どんなテスト条件に関わる部分(何についてのテスト)なのかわかりやすい形になり、保守性が上がります。

また、例えば「二勤の開始時刻が1530→15:00」と変更された(仕様が変わった)としても、変えるべきテストは「一勤の勤務時間と判断される最後の時刻のテスト」と「二勤の勤務時間と判断される最初の時刻のテスト」だと、テストメソッド名だけを見て予想を立てることができます

このように、テストコードの作成前に(特にテスト分析とテスト設計で)行うべきテストを整理することで、保守性の高いテストコードを書くことができます

おわりに

今回は、黒柴さんの記事を元に、テストプロセスのテスト分析〜テスト設計〜テスト実装、そしてテストコードの改善について考えてみました。

本記事では1つのケースを取り上げてみましたが、考え方については『Software Design 2024年2月号』に寄稿という形で書きましたので、よければそちらもご覧ください。

gihyo.jp

*1:

*2:JSTQBの中では「テスト計画」「テストのモニタリングとコントロール」「テスト完了」もありますが、今回は単一のテストについてなので割愛します

*3:同値分割法で表現できていないだけであって、仕様を理解する図としてはあっても良いと思っています

*4:テストコードに残すにあたって、同値分割のみにしたり、重複している境界値のテストケースは削ったりといった小さな工夫をしていますが、今回は説明を割愛します

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

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:「時間の都合で途中まで見て終了」とかかな…?