【授業レポート】システム開発入門 第29週｜改善実装の効果検証とA/Bテストの基礎

システム開発入門の第29週では、前週の運用テストとログ解析で見つけた課題に対して改善を実装し、その効果を再テストで確かめました。

今週の焦点は、機能を追加することではなく、変更によって何がどう変わったのかを数値で説明できるようにすることです。

A/Bテストとは、現行案のAと変更案のBを用意し、同じ目的に対する結果を比べる検証方法です。授業では簡易版を使い、「仮説、実装、計測、判断、次の仮説」という改善の流れを体験しました。

第29週の学習目標

1. ログから選んだ改善案を学習環境へ実装する。
2. 改善前後の応答時間、成功率、再生成要求率、フォールバック発生率を比較する。
3. 二つの案を公平に比べるためのA/Bテストの基本を理解する。

改善案を実装し、再テストの条件をそろえる

各班は、前回の解析で挙げた改善案から優先度の高いものを二、三個選び、テスト環境へ反映しました。

TTLは「Time To Live」の略で、キャッシュしたデータを有効として扱う時間です。TTLを延ばすと同じデータを再利用できる時間が長くなる一方、更新済みの情報がすぐに反映されない場合があります。仕組みを詳しく確認したい場合は、Laravelのキャッシュ戦略を扱った実務ガイドも参考になります。

実装後は、改善前と同じ負荷スクリプトを使ってログを収集しました。手順をそろえることで、テスト方法の違いではなく、実装変更による差を読み取りやすくなります。ただし、実行時刻やネットワーク状態まで同一になるわけではないため、後述する条件差も確認する必要があります。

KPIを使って改善前後を比較する

KPIは、改善の成否を判断するために継続して確認する指標です。授業では、処理性能だけでなく、利用者が再試行した割合や通常処理を続けられなかった割合も対象にしました。

次のスニペットは、全件数、成功率、平均応答時間だけを集計する最小例です。ログが0件の場合に0で割らないよう、先に件数を確認します。

# logs_control / logs_test は、それぞれ改善前と改善後のログリスト
def summarize(logs):
    total = len(logs)
    if total == 0:
        return {"total": 0, "ok_rate": 0.0, "avg_latency": None}

    ok = sum(1 for log in logs if log["status"] == "ok")
    latency_total = sum(log["latency_ms"] for log in logs)

    return {
        "total": total,
        "ok_rate": ok / total,
        "avg_latency": latency_total / total,
    }

再生成要求率とフォールバック発生率を比較するには、それぞれに対応するログ項目を別に数えます。一つの指標だけでは優劣を決められないため、検証前に「応答時間と成功率のどちらを優先するか」のように判断基準を決めておく必要があります。

学習環境で観察した変化

• キャッシュTTLを延長した班では、平均応答時間が約15％短くなりました。
• 長い入力を要約する前処理を加えた班では、タイムアウトが減り、成功率が上がりました。

これらは授業内の実測例であり、すべての環境で同じ結果になることを示す数値ではありません。実装内容と計測条件が班ごとに異なるため、各班は自分たちの改善前後を対応させて評価しました。

A/Bテストを設計する六つの手順

1. 仮説を決める：授業では「キャッシュTTLを延ばすと平均応答時間が短くなり、再生成要求率が下がる」と仮定しました。
2. AとBを定義する：Aを現行設定のTTL 300秒、Bを変更後のTTL 900秒としました。
3. 割り当て方法を決める：リクエストをランダムに振り分ける方法と、時間帯を分ける簡易な方法を確認しました。
4. 必要なログを集める：短時間の少ないデータだけで決めず、ばらつきを確認できる件数を集めます。
5. KPIを比べる：主に見る指標と副作用を確認する指標を分け、差の方向と大きさを読みます。
6. 次の判断を記録する：Bを採用するか、条件を変えて再検証するかを決め、その理由を残します。

時間帯で分けた簡易テストの読み方

授業では、AとBを一時間ずつ別の時間帯に実行しました。この方法は手順を学ぶには扱いやすい一方、時間帯ごとのアクセス量やネットワーク状態の差も結果に混ざります。そのため、今回の差は改善案だけの効果を厳密に証明するものではなく、次の検証につなげる観察結果として扱いました。

統計的有意差は、観察した差が偶然のばらつきだけでは説明しにくいかを検討する考え方です。授業では概要の紹介にとどめ、まずはサンプル数と割り当て条件が判断へ与える影響を確認しました。

結果を判断するときの確認項目

• 比較条件：AとBで、負荷のかけ方や計測方法がそろっているか。
• データ量：一部の極端な値に結果が左右されていないか。
• 目的との対応：改善前に決めたKPIが良くなったか。
• 副作用：応答時間を短くする代わりに、成功率や情報の鮮度が下がっていないか。
• 再現性：条件をそろえて測り直したときも、同じ傾向が見えるか。

「Aの方が速いけれど、Bの方が再生成要求率は低い。どちらを優先するかは目的次第だね」

この振り返りが示すように、A/Bテストは単純な勝敗を決める作業ではありません。利用者にとっての使いやすさとシステムの安定性を、目的に沿って選ぶための材料になります。

次週は改善を運用へ組み込む

次週は、今回の改善を継続して運用するためのチェックリストを作り、変更履歴と効果報告を文書にします。続きは第30週の改善運用とドキュメンテーションで扱います。

第29週のまとめ

改善は、実装した時点では完了しません。比較できる条件で数値を取り、結果と副作用を読み、次の判断を記録するところまでが一つのサイクルです。第29週では、この流れを簡易A/Bテストで確かめました。