QA学園： 「出席アプリのバグ」から考える品質の範囲 〜QA学園5人の議論〜

この記事は、創作世界観「QA学園」に登場する架空の出席アプリの不具合を題材に、

• 不具合（バグ）を直すだけで終わらせるのか
• 「品質」の範囲をどこまで含めるか

を整理してみたメモです。

「QA学園」は、ソフトウェアテスト／品質保証（QA）の考え方を
学園ものの物語として可視化していく試みで、登場人物や世界観はフィクションですが、
出てくる要素（ログ、バッチ、UX、Fth など）は実務QAと対応するように作っています。

---

1. どんな不具合だったか

題材にしたのは、学校の「出席アプリ」の不具合です。

• 授業の開始時に、学生は教室のQRコードを読み取る
• アプリ上ではその瞬間、「出席しました（緑）」と表示される
• しかし授業終了後、先生の管理画面では「欠席」扱いになっている学生がポツポツ出る

ざっくりいうと、

「ちゃんとQR読んだのに、最終結果が欠席になる」バグ

です。

1.1 ログを追いかけてみる

ログを追うと、だいたいこんな感じの流れでした。

1. クライアント側（スマホアプリ）

   • QR読み取り → 出席APIに status = present を送信
   • その瞬間の画面表示は「出席しました（緑）」

2. サーバ側

   • リクエストは受理され、
     出席ログテーブルに present = 1 で記録

3. 授業終了後の「集計バッチ」

   • 「授業時間外」「時間割と違う授業コード」「登録クラスと違う教室」など、
     いくつかの条件にマッチした打刻を「不正打刻」とみなし、
     “掃除”の名目でログから削除していた

4. 結果

   • 不正打刻と判定された学生の出席ログは 物理削除
   • 集計結果テーブルには出席レコードが残らず、「欠席」とカウントされる

1.2 何が設計ミスだったのか

技術的に見ると、原因は 集計バッチの「掃除ロジック」の設計ミスです。

• 学校側の「時間割テーブル」を絶対正しい前提として扱いすぎていた
  • 補講、教室変更、クラス変更など、現場でよくある例外運用が考慮されていなかった
• 「不正打刻」と判定したログを 物理削除 してしまっていた
  • 誰が・どの条件で・なぜ削除したのかが後から追えない

つまり、

QRを読んだ瞬間はシステムも「出席」と認めていたのに、
後工程で「なかったこと」にされていた

という構造になっていました。

---

2. 学生5人で「どこまでを品質に含める？」を議論してみた

QA学園には、こんな感じの5人が出てきます（役割だけ簡単に）。

• ユウタ：現場寄りのQA／テスト設計担当
• アヤ：違和感センサー（感情の波形＝Ew に敏感な人）
• テラ：モデル厨（状態遷移や因子・水準で整理する人）
• 美桜：ビジネス・運営目線（説明責任や運用を気にする人）
• キョウスケ：アーキテクト兼、「ログ思想」担当

この5人で、「この不具合を直そうとするとき、どこまでを『品質』に含めたいか？」を話した、という形で整理してみます。

2.1 技術的バグだけ見るなら

「技術的なバグ修正」に限定すると、話はシンプルです。

• 集計バッチの条件を直す
  • 正しい授業コード／教室／時間割への対応を増やす
  • 補講やクラス振替用の例外ルールを追加する

ここまで直せば、最終的な「出席／欠席」の数は合うはずです。

ただ、この時点でユウタとアヤがモヤモヤします。

• ユウタ:

  「ちゃんとやったのに欠席にされると、現場感覚としては信用なくすよね」

• アヤ:

  「一回“出席しました”って緑で言われたのに、
  あとから“やっぱなし”ってされるの、感情的にはかなりきつい」

ここで出てくるのが「Ew（Emotion waveform）」という概念です。

2.2 Ew（Emotion waveform）という視点

Ew は、ある出来事に対して生じる感情の「波形・混ざり具合」を表す変数です。

• 「ちゃんとやったのに、あとからなかったことにされた」
• 「アプリはいったんOKって言ったのに、後から否定された」

こういう体験をすると、ユーザーの Ew はかなりネガティブ側に振れます。

技術的には「バッチの条件を直せばOK」でも、
ユーザー Ew 的には、

「このアプリ、がんばっても信用してくれない」

というラベルがついてしまう。

ここまで含めて「品質」とするかどうかが、議論のポイントになりました。

---

3. 5人それぞれの「品質」の定義

ユウタ（現場QA）

「ちゃんとやった人が損しない」ことを保証したい。

• QRを読んだ瞬間のログを ILK（Isolated Log Key 的なもの）経由で残したい
• たとえバッチや時間割テーブルが間違っていても、
  後から「ちゃんと出席していました」と復元できる仕組みを入れたい

アヤ（Ewセンサー）

「一度OKと言われたものが、後から“なかったこと”にされないこと。

• もし後でNGに変えるなら、
  • なぜダメだったのか
  • どの条件に引っかかったのか
• その理由をユーザーが理解できる形で見せてほしい

テラ（モデル厨）

「システムの状態遷移が、人間の頭の中の認知モデルと一致していること」。

• ユーザーは
  • QRを読む → 「出席になった」
  • 授業が終わる → 「そのまま出席が残る」
• というストーリーで頭の中に状態遷移を書いている
• 実装側の状態遷移（クライアント→サーバ→バッチ）が、
  その認知モデルとズレているのは品質的に危ない

美桜（ビジネス・運営）

「トラブル時に、説明責任を学生側にだけ押し付けない設計」。

• 今の仕様だと、
  • 学生「ちゃんと出席しました」
  • 学校「ログ上は欠席ですね。証拠あります？」
• という形になりがち
• 「ちゃんと出席してくれていたかどうか」は、
  システム側が証明できるようにしておきたい

キョウスケ（アーキ＋ログ思想）

「ログのどこにも嘘をつかせないこと」。

• 一度「出席しました」と記録したログは残す
• 後からNGが分かったなら、
  「○○という理由でNGに変更した」というログを追記する
• 「不正打刻」と判定しても、
  ログごと物理削除するのは最終手段にすべき

---

4. 実際にはどう直したか

物語上の世界では、最終的に次のような修正を入れています。

4.1 ログの扱いを変更

• 「不正打刻」と判定されたログも 物理削除しない
  • 別テーブル（退避テーブル）に移動
  • 判定理由コード＋判定者ID＋判定日時を一緒に保存

4.2 先生画面の表示を変更

• 単に「欠席」ではなく、
  • 「出席打刻あり」
  • 「◯◯という条件により、欠席扱いに変更」
• という情報が見えるようにする

4.3 例外運用の設計

• 補講や教室変更があった場合、
  • 先生が出席ログを「正」としてマークできる画面を用意
  • その操作も ILK （不可逆AI保存デバイス）的な仕組みでログを残す（誰がいつ補正したか）

結果として、

• 「最終的な出席／欠席の数が合う」
  だけでなく、
• 「学生の“ちゃんとやった”という努力や Ew を、ログとして残す」
• 「トラブル時に、システム側からも『この学生は本当に来ていた』と言える」

ところまで含めて「品質」とみなす方針になりました。

---

5. このエピソードから持って帰れる問い

この出席アプリの例を通じて、
自分の案件／プロダクトに置き換えて考えたいポイントはこんなところだと思っています。

• 不具合を直すとき、
  • 技術的な整合性だけを揃えていないか？
  • ユーザーの Ew（感情の波形）はどう変化するかを見ているか？
• 「ログを消して帳尻を合わせる」設計になっていないか？
• 「弱い側（エンドユーザーや学生側）にだけ説明責任が乗る」構造になっていないか？
• 自分／チームは、「どこまでを品質に含めたい」と思っているか？

---

6. おわりに

QA学園の中では、
こうした不具合1件1件をネタにして、

• 技術的なバグ
• UXやEwの問題
• ログや責任の構造
• 「どこまでを品質と言い張るか」というFth（閾値因子）

を、学生たちが何度も議論する、という形で世界観を作っています。

実務でも、

「このバグ、直せば終わりでしょ？」

で済ませるのか、

「このバグから見える“品質の線引き”まで含めて話をしよう」

とするのかで、
プロダクトの育ち方や、チームの文化はかなり変わってくると思います。

みなさんの現場では、
「出席アプリ」的な不具合から、どんな“品質の線”が見えていますか？