ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

「品質」と「価値」と「顧客満足」の関係が難しい

JaSST'24 Tokyoに参加して感じたことの一つに、「顧客に素早く価値を届けるために・・」という表現の発生頻度の高さがあります。特定の発表を批判したり、揶揄したりする意図はありません。この表現が決まり文句的に使われているために、その言葉の意味を考えずにいることを自覚したのでした。

「品質」と「価値」は何が違うのか。
みなさんからいただいたコメントも踏まえて、少し考えてみました。

先にイイワケしておくと、

  1. 過去の偉人の議論とか、論文とか、規格における定義とかはほぼ参照していません
  2. 特に明確な結論もありません、頭の体操にすぎません

ので、ご承知おきください。もちろん、「価値という言葉を使うな」という主張でもありません

1. 価値・品質 同一説

過去幾度となく引用されたであろうG. M. Weinbergの定義、

品質は誰かにとっての価値である。

を単純に受け取ると、「品質=価値」とも読めます。

身も蓋もない言い方をすると、2つの言葉に明確な意味の差はない。ないけれど、何となく目新しい響きもあり、好んで使われるようになったという説です。

面白いなと思ったのが山崎先生のこのご意見。

確かに、テスト・品質保証という言葉に、「守り」とか「最後の門番」の印象を持つ人も多いでしょう*1。極端にいうと、「マイナスをゼロに持ってくる」イメージ。
一方で「価値」というと、より積極的に「ゼロをプラスに変えていく」というイメージを、わたし自身は感じます。その結果、よりポジティブな印象を与える「価値」が、好んで使われるようになったというのはあるかもしれません。

2. 価値・品質 包含説

品質は価値の一部分ではあるけれど、そのすべてではない、という捉え方です。

秋山さんは例として

牛丼屋の、早い・安い・うまいの「早い」は価値だと思うけど、品質(商品やサービスの特性)ではないと思います。

とおっしゃっています。わたしは「早い」はサービス品質の一つだと解釈するので、ここは意見の分かれるところです。

ではわたしは、品質以外で何を、牛丼屋の価値と考えるのか。たとえばですが、

  • いつ行っても、期待した通りの品質のモノが供されるだろうという信頼感
  • どんな時刻でも、行けばご飯が食べられるだろうという安心感

があるでしょうか。うーん、これもサービス品質ですかね?

またJaSST後の懇親会で、とあるサービスのベンダとそのユーザ、お二人の会話を聞いていて感じたのが、
「このベンダは、自分たちユーザの要望をバックログリストに載せている」 という「実感」
もまた、価値の一つであるということです。これはサービス自体の品質でも、サポート自体の品質でもないのですが、ユーザを惹きつける要因だと思います。

別の例としては、一部のクレジットカードの、「持っていること自体がステータスになる」という特性は、クレジットカード自体の品質とは無関係の「価値」であると感じます。持ちたいとは思いませんが。

3. 価値・品質 因果説

品質が価値につながる、という解釈です。

身近な例だと、果物の「糖度の高さ」は品質で、「甘くてうまい!」が価値、ですかね。
「品質が価値につながり、その価値が顧客満足につながる」というのは、わかりやすい流れに思えます。

ただし、以下の3点に注意する必要があります。

同じ品質でも、ユーザが感じる価値は異なる

果物に「甘い」を求めていない消費者にとっては、糖度が高くても「うまい!」とはならないですよね。
品質が同じでも、価値が同じとは限らない。「開発側がユーザ目線でテスト」するにも限界があり、最終的にはユーザに聞くしかない、となります。

すべての品質が価値につながるわけではない

牛丼屋の例でいうと、食器をメチャクチャ高級なものにしたところで、顧客価値は上がらないでしょう。

ソフトウェアでいうと、たとえばソースコードの複雑度を下げれば、いわゆる内部品質が上がったことになりますが、顧客の価値が直接上がるわけではないでしょう。
もちろん、コードの複雑度が下がる→保守性が上がる→コードの変更の難易度が下がる→新規機能やバグフィックスがより容易に行える→ユーザに新機能やバグフィックス版を迅速に提供できる→ユーザは嬉しい という間接的な因果関係はあるかもしれません。

価値につながるのは品質だけではない

これは包含説と同じ話ですね。
ただ、「品質以外で価値につながるもの」が、わたしには今のところ「プロダクトやその提供者への信頼感」「ブランド」みたいなものしか思いついておらず、もう少し考えたいところです。

みなさんはこれらの3つのうちどれが、品質と価値の関係に近いと思いますか?

アジャイル・スクラムの原点では?

『アジャイルソフトウェア開発宣言』にも「価値」という言葉が出てきますが、これは顧客にとっての価値というより、ソフトウェア開発における価値、と読みとれます。
『スクラムガイド』(2020年11月版、PDF)には「価値」という言葉が何度も出てきますが、その一部は顧客にとっての価値を表し、他のものはスクラムチームにとって価値を表しているようにわたしには読めます。

違うかな?
この辺はあまり書くとボロが出るので(もう出てるか)、この辺にしておきます。

Weinbergに戻る

Weinbergに戻りましょう。
上述のWeinbergの言葉は、以下のように続くそうです。

品質は誰かにとっての価値である。
「価値」という言葉は、「人びとはその要求がみたされるなら、喜んで対価を支払う(または何かをする)か?」ということを意味している。

こうしてみると、「価値」とはシンプルに、「要求が満たされること」なんですよね。

でもその「要求」は、「人びと」が明確に言語化できるとは限りませんし、仮にできたとしてもそれは不変ではありません。なのでアジャイル開発では、高い頻度で「動くソフトウェア」をリリースして、「要求が満たされること」を確認するんですよね。

なので、「顧客に素早く価値を届ける」というのは、本当は、「顧客に素早く価値(があると自分たちが仮説として考えたもの)を届ける」なのかなーと思ったりもします。揚げ足取りかもしれませんが。

おわりに

もともと「品質っていったい何なんだ・・?」とQAエンジニアみんなが悩んでいたところに、「価値」という言葉も加わり、ますますワカンネー感が広がりました!

Generated By Dalle

追記

その後まとめたワンページサマリーです。

品質と価値の関係 ワンページサマリー

*1:その割には「QAエンジニア」というロールの認知度と印象が急に上がった現象もあり、不思議ではあります・・・。

【参加メモ】「QA業界のパイオニアが語る!アジャイル・AI時代の品質保証の今」

2024年3月7日(木)の午後、「QA業界のパイオニアが語る!アジャイル・AI時代の品質保証の今」というイベントに参加してきました。
スピーカーは早稲田大学の鷲崎弘宣先生、永和システムマネジメントの平鍋健児さん、AGESTの髙橋寿一さんです。

この記事は当イベントのメモですが、AGESTのオウンドメディアであるSqripts会員限定&抽選式のイベントであり、SNSでの発信についてのご案内もなかったことから、あまり詳細には触れずに概要を紹介したいと思います。

sqripts.com

アジャイルメトリクスの全体像と利用者・顧客満足に向けて

鷲崎先生のご講演です。

初めに、従来型開発とアジャイル開発における品質メトリクスの違いを説明したうえで、アジャイル開発においてよく利用されている品質メトリクスは圧倒的に製品品質に関するものが多く、一方で肝心の顧客満足を測定する取り組みが目立たないことを課題として提起されました。ユーザ価値を目指しているはずが、それを調べられていない状態ということです。

この課題を解決するために、バグ票やソースコードのコミット履歴が公開され、かつアプリストアでユーザレビューも見られるソフトウェアを対象にした研究を実施。間接的ながら、コミット履歴からは開発プロセスの特性を定量化でき、ユーザレビューからは顧客満足に相当する情報を定量化できる、というわけです。

結論として、レビュー依頼からマージまでの時間は、レビュースコアと明らかな負の相関があるということがわかったそうです。
擬似的な代替メトリクスであり、両者に因果関係があるとまでは断定できないとのことでしたが、顧客満足に影響する要素を特定するための活動としてとても面白いと感じました。

デジタルビジネスの潮流とアジャイル開発 〜ビジネスとエンジニアの協働チームづくり〜

平鍋さんのご講演です。

まずウォーターフォールの課題として、「要求からリリースまでのターンアラウンドタイムが長い」「終盤になってモメて、発注側と受注側のゼロサムゲームで消耗する」ことを挙げられました。これとは対照的なモノ作りとして、現場でユーザの実施のふるまいを観察しその場でプロトタイプを作り上げていくNordstromのアジャイル開発を紹介。

www.youtube.com

その中で品質保証の人間は意思決定できるチームの中にいるべきで、プロダクト横断的な観点、たとえばセキュリティの作り込みやテストのような開発項目を、「品質シナリオ」*1としてプロダクトバックログの中に組み込む役割を果たせるだろうとお話しいただきました。

また、「アジャイル開発の全社標準」といったものには注意すべきで、やるとしても、実践してうまくいったチームの経験を使うこと、またそれぞれの開発チーム自身が工夫できる余地を残すことを強調されていました。
個人的にも、「うまく行ったことのあるやり方」や、「工夫して作り込んだテンプレ」みたいなものを共有・紹介するのはとてもいいと思う一方で、それらの謎ANDを取って「全員このプラクティスに従うべき!」というのはチームを縛るだけで、アジャイル開発の良さを殺すんだろうなと感じます。

AI時代のソフトウェアテスト入門(シフトレフトするの?シフトライトするの?)

高橋 寿一さんの講演です。

高橋さんは、「生成AIによって開発生産性は上がるが、テストの生産性は上がっていない」と問題提起したうえで、AIのテストの難しさについて解説されました。
出力の非決定性、学習データのバイアス問題、テストオラクル問題*2とそれに伴うテスト自動化の困難さ、未成熟なテスト技法、といった具合です。また技術面とは別に、法規制などの側面でも新たな問題が生まれそうだとしています。
良くも悪くも、テストエンジニアの仕事はむしろ範囲が増える形になっており、それをどうやって減らしていくかが課題になりそうだとお話されていました。

なお、AIのテストについての翻訳本が春に出るというアナウンスがありました。
現著者は、Adam Smith氏とRex Black氏。Black氏はソフトウェアQA/テスト業界ではあまりに著名なコンサルタントですし、Smith氏はISO/IEC JTC 1/SC 42(人工知能)のメンバーでもあります。つまり、テストのプロとAIのプロが組んで書いた本。これは楽しみですね。

↑ これは原著ですのでご注意!

おわりに

どれも印象に残る講演で、自分の仕事にも取り込んでいきたいと感じました。
わたしはAGESTさんの回し者ではありませんが、SqriptsはQAについての記事を幅広く、またかなりの頻度で出しているメディアであり、購読をお勧めします。まあ読み切れないのですが。。

余談ですが、懇親会で供されたビュッフェ、めちゃくちゃ美味しかったです・・・帝国ホテルのローストビーフ・・・。

Generated By Dalle

*1:『アジャイル品質パターン』で定義された、アジャイル開発における品質プラクティスの一つ。

*2:テストにおいて、あるべき期待値を決める根拠が得られないという問題。たとえばChatGPTに「美しい詩を書いて」と指示した場合、どんな詩が出力されれば「正解」で言えるかを決めることは難しい。「テストオラクル」については、こちらの記事も参照。 www.kzsuzuki.com

【参加メモ】AI時代のソフトウェアテストの現在と未来 #genai_autify_launchable

本日2024年3月5日(火)の昼間に開催された、『AI時代のソフトウェアテストの現在と未来』というイベントがとてもよかったので、特に印象深かったポイントについて共有したいと思います。

イベントの詳細はこちらで。 autifyjapan.connpass.com

登壇者はタワーズ・クエストの和田卓人 @t_wada さん、Launchableの川口耕介 @kohsukekawa さん、Autifyの近澤良 @chikathreesix さんのお三方。ファシリテーターは、近澤さんと同じくAutifyの、末村拓也 @tsueeemura さんです。

宣伝タイム

  • Launchableは、「テストの失敗をよりインテリジェントに扱う」ことを目指している。
    たとえば、テストのFlakinessの判定や対処にできるだけ人を介在させないとか、過去の実行結果を見て再実行要否の判断をするといったもの。
  • Autifyは、E2Eテストの2つのペインポイントである実装と保守を、ノーコードで行う。画面変更にも自動的に追随できる。

質問1. AIを活用した開発プロセスのあるべき姿

「ソフトウェア開発における生成AIの活用といえばまずコード生成が挙がるが、生成AIは要件定義でも強みがありそう」という川口さんのご指摘に対して、近澤さんも「要件定義など上段をしっかり作ると、良いアウトプットができる」とおっしゃっていました。
基本設計→詳細設計→プログラミング と、設計ドキュメントを十全に作り上げてから実装の始まる従来の開発から、「包括的なドキュメントよりも動くソフトウェアを」を旨とするアジャイル開発へのシフトが起こりましたが、今後は「動くソフトウェアを素早く作るためのドキュメントを」というパラダイムも来るのかなーと感じます。

生成AIによって生成されたモノの質の担保について、「何をもって正しいかは人間が判断する」とした和田さんのご意見が印象的でした*1。AIはあくまでも「自分が書くとこうなる」とわかっているものを作ることは楽にしてくれるけれど、「どう書けばいいかわからない」ものは、質を評価できないと。これはプロダクトコードもテストコードも同じ。
「プロダクトコードとテストコード両方を書く場合、プログラマーは頭のモードを切り替えて自分との会話をするが、LLMにこの対話をさせるパイプラインをデザインできないか」という川口さんのアイデアに対し、「両方をAIに生成させると、両方が等しく誤るリスクがある」とおっしゃっていました。ただ、「要件・仕様ドキュメント」「プロダクトコード」「テストコード」のトリオのうち2つを人間が作り、残りの1つを生成させると、高い精度が得られる傾向があるというお話をされていました。
何となくRAID5の分散パリティを思わせるようでもあり、またある意味「たがいに冗長」である2つをしっかり作ることで、残りの1つが間違える確率を減らしているようにも思え、ワクワクする知見でした。

質問2. テストにおけるLLMの活用

近澤さん、川口さんともに、今後はテキストベースのログだけでなく、マルチモーダルAIでスクリーンショットをチェックし、従来はベテランの直感頼りだった異常検知もできるようになるだろうとおっしゃっていました。
「才能のあるテストエンジニアの力を民主化し、スケールさせる」という表現も面白かった。

質問3. 人間に残されるタスク

たとえば運転は、自動運転に代替され始めている。そうなると、「運転する」こと自体は重要ではなく、「どこに行くか」を考えられることが重要というのが、San FranciscoでWeimoの自動車を目の当たりにしている近澤さんのご意見でした。「何を作るか」は人間が考えるということですね。
一方川口さんは、いわゆる「上流」の仕事も、ユーザやマーケットの観察などある意味で機械的・言語処理的なものであり、生き残るかどうかには懐疑的とのご意見。

ファシリテーターの末村さんは、ベテランのエンジニアが行っていることの例として、「どのタイミングでどういうテストを行うべきか」といったテスト戦略の立案や、新しいテスト技術の開発*2といったものがあり、こういった作業は代替されないのでは?と問いかけを行っていました。

前者について和田さんは、従来のテスト戦略の暗黙の前提になっている点を見直す必要が出てくるというお話をされていました。
これまでのテスト戦略は、テストを行う主体が人間であることを前提とし、そのうえで最適な方法を模索しています。単純な例だと、「パラメータの全組み合わせを手動で実行している時間はないから、リスクに応じてカバレッジ基準を落とそう」といったものです。
テスト自動化によりそれも変わってきてはいますが、生成AIがそれに拍車をかける。よって、今まで前提としてきたもののうち、依然として有効なものがどれで、すでに無効になっているものがどれかを見極める必要がある、ということです。

4. レガシーコードの技術的負債に対するAIの活用

巨大なコードベースで、テスト容易性・理解容易性・変更容易性がすべて低いような状況において、「リファクタリング前後のサンプル」を少数与えることで、残りのレガシーコードも「以下同文」としてすべてリファクタリングすることができるのではないか」という和田さんのお話が面白かったです。
また、数万行オーダーのコードを生成AIが一気に理解できるようになれば、コードから仕様ドキュメントの生成も容易になり、「誰も全体を把握していない」「超ベテランしか把握していない」という状態から抜け出せるというお話もありました。夢が広がる話です。

感想

今後のテスト・QAに対する自分の取り組みに新たな発想を与えてくれる、非常に有意義なトークセッションでした。生成AIを含めたAI全般についての知識を深めつつ、業界内の動向や事例をよく吸収して、良いモノづくりにつなげていきたいと感じさせられました。

登壇者のみなさん、運営のみなさん、ありがとうございました。

Generated By Dalle

*1:なお、人間が指示→AIが作業→人間が確認する形を「サンドイッチワークフロー」と言うそうです。

*2:たとえば、最近書籍が出版された話題になっているプロパティベーステスト(Property-based Testing)を挙げられていました。

JaSST'24 Tokyoでパネルディスカッションに参加します!

JaSST'24 Tokyoは3/14(木)、3/15(金)に開催。再来週に迫ってきました。

jasst.jp

わたしも同僚とともに2日間、現地で参加予定。とても楽しみにしています。

IT系イベント・カンファレンスといえば最近はオンライン開催も多く、自宅から気軽に参加できる大きなメリットを享受しています。運営に関わるみなさまには感謝ばかりです。
一方で現地イベント。移動の手間はかかるし、聴講する環境も必ずしも良くはなかったりする。それでも。
それでも、現地ならではの熱気と、何より自分自身の集中力がまったく違うんです。現地イベントにおけるわたしの集中力を53万とすると、映像コンテンツの苦手なわたしのオンラインイベントにおける集中力は5くらいなんですよね。

また、わたしはコミュニケーション能力が高い方ではないのですが、それでも現地に行けば、多少なりともネットワーキングができる!
有力な転職情報は特に求めていないのですが、「ソフトウェアの品質やテストについて、ダラダラしゃべったりできる同志」がとても大切なんです。 現地にいらっしゃるみなさん、当日はどうぞよろしくお願いします。

なお2日目は、『テスト管理ツールの向かう先』というセッションで「しゃべる側」になります。

jasst.jp

テスト管理ツールベンダ三社とユーザ(これがわたし)の立場から、「テスト管理ツールってどうなの?」に加えて、「テスト管理ツールって、これからどうなっていくの?」という話ができればと思っています。
Quality Forwardを担ぐベリサーブの朱峰さん、CATを担ぐSHIFTの石井さん、TestRailを担ぐテクマトリックスの会田さん。みなさんそれぞれベンダーの立場としてのご登壇ですが、「ぶっちゃけで行きましょう」という方ばかり。

「テスト管理ツールにはこんなメリットがあるのでみんな使おう!」に終始する提灯セッションではなく、「テスト管理ツールでテストを・品質を・開発をどう変えていきたいか」という未来の話を、プロのみなさんから引き出せるよう、わたしも頑張ります! よろしければぜひ、ご聴講ください。

なわとびから考える情報の仕分けとソフトウェアテスト

 レビューの難しさの一つに、「レビューする側とされる側で、感じる重みにギャップのある指摘」問題があります。
 特に、「レビューする側は大事な問題だと思っているのだけれど、される側はそう思っていない」ものが厄介です。このような場合、される側は「そんな重箱をつつくようなことを言わなくても・・」と感じているので、小手先の修正に終わってしまい、次回もまた同じことをやってしまいがち。

 その種の指摘の例として、「列のタイトルとデータが整合していない表」があります。

 「いやそんなことある?」って思われるかもしれませんが、「最初に列タイトルをつけてからデータを入れていったところ、タイトルとあまり関係ない情報も出てきた、でも列を分けなかった」みたいなものはちょいちょい見かけます。この手の表は、書き手が思っている以上に、読み解きの難易度が上がると感じます。

 ちょっと例がアレですが、イメージはこんな感じ。

メトリクス 計算式
テストケース密度 テストケース数 / 開発規模
欠陥密度 欠陥数 / 開発規模
※n件/ks以上を目標値とする

 「計算式」の列に、計算式以外の情報を入れんでくれ~
 目標値を書きたいなら、「目標値」って列を作ってくれ~

 でふと思ったのですが、「たくさんの情報があるときに、それを仕分けして、適切な列名を定めて表に落とし込む」って、実はそこまで簡単なことではないんだよなと。

突然のなわとび

ということで今日は、「情報の仕分け」を考えてみましょう。お題はこれです!

ジャーン

 これはわたしの次男が学校からもらってきた、「なわとびけんてい」の表。各「種目」で何回飛べたかに応じて色塗りをしていくことで、自身の成果と成長を見える化する、素敵なプリントです。

 この表自体に特に問題があるわけではない(ただし通番と種目の列は分けてほしい、通番の数字は半角にしてほしい、数字は右揃えにしてほしい)のですが、種目を眺めていると、「なわとびの種目は、いろんな概念が組み合わせられている」と感じませんか? これを紐解いていきましょう。なわとびだけに。

1. 要素に分解する

 名前からしてすでに組み合わせが発生している種目を、要素に分解していきます。

  • 前とび → 前
  • かけ足とび → かけ足
  • 後ろとび → 後ろ
  • あやとび(前) → あや × 前
  • 交差とび(前) → 交差 × 前
  • かけ足あやとび → かけ足 × あや
  • あやとび(後ろ) → あや × 後ろ
  • かけ足交差とび → かけ足 × 交差
  • 前ふりとび → 前ふり
  • 交差とび(後ろ) → 交差 × 後ろ
  • 二重とび → 二重
  • 二重とび(後ろ) → 二重 × 後ろ
  • あや二重とび → あや × 二重
  • 交差二重とび → 交差 × 二重
  • 三重とび → 三重

 以下のような要素がそろいました。意外に少ないですね。

前、かけ足、後ろ、あや、交差、前ふり、二重、三重

2. 要素を仕分けする

 集まった要素を仕分けて、カテゴリーにしていきます。
 仕分けの一つの手がかりとして、「似ているもの」があります。たとえば「前」と「後ろ」は真逆ですが、「回転の方向」を語っているという意味で似ています。

 結果として、以下の4つのカテゴリーとなります。

  • 回転の方向: 前、後ろ
  • 足の動き: かけ足、前ふり
  • 腕の動き: あや、交差
  • 回転の回数: 二重、三重

 表の話に戻ると、「回転の方向」などのカテゴリーが列名となり、「前」「後ろ」といった要素がデータの種類になります。

3. 要素の過不足をチェックする

 さて、要素はこれで十分でしょうか?
 いいえ、足りていないものがありますね。最初の「仕分け」は名前を元に行ったので、名前に明示的に現れない要素が抜けているのです。たとえば「足の動き」は「ノーマル」、つまり単純にジャンプ→着地するものがありますよね。

 これらを加えると、以下のようになります。

  • 回転の方向: 前、後ろ
  • 足の動き: ノーマル、かけ足、前ふり
  • 腕の動き: ノーマル、あや、交差
  • 回転の回数: 一重、二重、三重

 以上の要素を組み合わせることで、最初の種目すべてを表現できるようになりました。

# 種目 回転の方向 足の動き 腕の動き 回転の回数
10 交差とび(後ろ) 後ろ ノーマル 交差 一重
01 前とび ノーマル ノーマル 一重
16 さいきょう 後ろ 前ふり 交差 三重

 いや~ このように整理できると気持ちがいいですね! ぼくの考えたさいきょうのなわとび種目もすぐ作れるわけです。

4. 新しい要素を考えてみる

 さて、この整理をすると、もう少しできることがあります。

 確かに、最初に提示した種目はこれですべてカバーできるのですが、各列に足せる要素はないでしょうか?
 そうですねー、たとえば「腕の動き」。
 あやとびではジャンプのたびに腕の交差と解放を繰り返しますが、「1回のジャンプで交差と開放をする”ダブルあや”ができないか?」みたいな感じです。
 これは、「腕の動き」というカテゴリーで列名が付いていることにより、考えやすくなっています。

 「回転の回数」なら、単純には「四重」が考えられますし、「1回ごとに回転の回数が変わる飛び方」というのも発想できるかもしれません。

5. 新しいカテゴリーを考えてみる

 さらに、カテゴリーに何か追加できないか考えてみます。
 「足の動きと腕の動きがあるから・・・腰の動きってどうだ? ジャンプごとに、腰を左右に捻る!これは腹筋に効くぜ・・・!」みたいに。

 これも、カテゴリーの名前が適切に付けられていることが、発想の源となります。

おわりに

 最初の話からだいぶズレてきました。

最初に言いたかったこと

 表を作るなら、列名とデータの内容を整合させよう。

今言いたいこと

 適切なカテゴリー名を付けて分類することは、要素だけでなく、そもそもの分類の軸であるカテゴリーの過不足を検討するためにも、とっても大事なプロセスである。

 QAエンジニアの方なら、「何か、デシジョンテーブルテストとか組み合わせテストやるときに似てるな」と感じたかもしれません。
 その通りです! これらの表を作る時も、軸と選択肢の洗い出しと仕分けが重要なんですよね。実は最初は「なわとび直交表」を作ろうと思ったのですが、いつの間にか全然違う話になってしまいました。

 無理やりテストの話に持ち込んだところで、今日の雑談は以上です。今年の目標「三重とびをマスターする」を掲げて、今日も練習してきます。

Generated By Dalle