CR06・M14
性能目標2秒に対して32秒
ここまでの学習
Stage 1 症状
CASE FACTFROZEN正本に記載されたアステリア案件の事実
M14
- 性能目標: 2秒（危機演習のタイトル「性能目標2秒に対して32秒」）
- 通常2秒
- 月末想定負荷32秒
- 一部タイムアウト
「性能目標2秒」はタイトルの記述、「通常2秒」は本文の記述で、別々の記述です。「通常2秒」が具体的に何を意味するかは、正本からは確定できません。正本から確定できない
何の処理・画面の値か、月末想定負荷がどんな条件か、何がどれだけタイムアウトしたかは、正本に記録がありません。記録なし
TRAINING UI演習の問い
性能目標は2秒です。月末想定負荷では32秒、一部でタイムアウトと書かれています。
このまま進めてよいと思いますか。
そう考えた理由を書いてください。
「通常2秒」と書かれていることから、何が言えて、何が言えないと思いますか。
この段階では AI に聞かない
正本の記述は短く、「通常2秒」の意味も確定できません。この段階で AI に聞くと、足りない部分を AI がもっともらしく補ってしまうおそれがあります。
まず、あなた自身の最初の印象を書きます。
Stage 2 最初の資料
正本の記述を、出典ごとに並べます。この段階で新しい事実は加えません。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
| 出典 | 正本の記述 |
|---|---|
| 危機演習のタイトル | 性能目標2秒に対して32秒 |
| 時点 | M14 |
| 本文 | 通常2秒 |
| 本文 | 月末想定負荷32秒 |
| 本文 | 一部タイムアウト |
「通常2秒」が具体的に何を意味するかは、正本からは確定できません。正本から確定できない
TRAINING UI資料の読み方
正本から言えること
- 性能の目標は2秒と書かれている
- 月末想定負荷では32秒と書かれている
- 一部でタイムアウトが起きている
まだ言えないこと
- 「通常2秒」が、具体的に何を意味するか
- 「通常2秒だから、普段は問題なかった」と言えるか（言えません。「通常2秒」の意味が確定できないためです）
- 目標の2秒と、本文の「通常2秒」が、同じ処理・同じ条件についての記述か
- 月末想定負荷とは、どんな条件か
- 32秒は、何の処理の値か
- 何がタイムアウトしたのか、どれくらいか
- なぜ遅いのか
次に確認したいこと
- 目標の2秒は、どんな条件で満たすべき目標だったのか
- 月末想定負荷の条件は、どう決められていたのか
- 時間がかかっているのは、どの処理か
TRAINING UI演習の問い
THINK
「通常2秒」と書かれていれば、「普段は問題がなかった」と言えるでしょうか。
「次に確認したいこと」に、あなたが確認したいことを1つ以上足してください。
AI WORKFLOW
AI に使ってよいのは、「判断する前に確かめること」の一覧づくりです。
AI へ渡す情報: 上の表の5項目だけ
AI へ渡さない情報: 推測した処理の名前、推測した負荷の条件
AI への問いの例（演習用の例です。ケースの中で実際に使われた指示文ではありません）
「性能目標2秒、通常2秒、月末想定負荷32秒、一部タイムアウトという記述があります。判断する前に確かめるべきことを挙げてください。処理の中身や負荷の条件は推測しないでください。」
検証のしかた: AI が「通常2秒」を「通常時は目標を満たしている」と読んでいたら、正本からは確定できないとして退けます。AI が処理の名前・データの量・利用者の数を書いていたら、正本に記録がないため削除します。
Stage 3 仮説整理
「サーバーが遅いのでは」の一言で済ませず、処理の作り・基盤・運用・負荷の見込み・目標の決め方まで、月末想定負荷で32秒になる理由の候補を広げます。
LEARNER HYPOTHESISあなたが立てる仮説。事実ではありません
A. 処理の作り
処理の作りに、時間のかかる部分がある。
- 確かめ方: 処理ごとにかかっている時間の記録（正本に記録がありません）
B. 基盤
基盤の能力が、負荷に見合っていない。
- 確かめ方: 基盤の能力と使用状況の記録（正本に記録がありません）
C. 運用
同じ時期に、ほかの処理が重なっている。
- 確かめ方: 月末に動く処理の記録（正本に記録がありません）
D. 負荷の見込み
月末の負荷を、最初から見込んでいなかった。
- 確かめ方: 負荷の条件がどう決められていたかの記録
E. 目標の決め方
2秒という目標を、どんな条件で満たすのかが決まっていなかった。
- 確かめ方: 目標を決めたときの条件の記録
A〜E のどれか1つに絞る必要はありません。特定の会社・人・システムを原因とする仮説は、正本に記録がないため挙げません。
AI WORKFLOW
AI に仮説を広げさせることはできます。ただし、AI の仮説は一般的な傾向であり、このケースの事実ではありません。
AI へ渡す情報: 時点 M14、性能目標2秒、通常2秒、月末想定負荷32秒、一部タイムアウト
AI へ渡さない情報: 推測したデータの量・利用者の数・基盤の能力
AI への問いの例（演習用の例です。ケースの中で実際に使われた指示文ではありません）
「次の状況で、月末想定負荷で性能目標を満たせない原因の仮説を観点ごとに挙げ、それぞれを確かめるために必要な記録を書いてください。データの量や利用者の数は推測しないでください。」
検証のしかた: AI の仮説ごとに、「このケースの記録で確かめられるか」を人間が確かめます。確かめる記録がない仮説は、仮説のまま残します。
REVIEW
AI が「通常時は2秒で目標を満たしているので、月末の負荷に耐えられるようサーバーを増強すれば解決します」とまとめることがあります（演習用に想定した回答の例です）。
- この回答は、「通常2秒」を「通常時は目標を満たしている」と読んでいます。正本からは、そう確定できません。
- 「サーバーを増強すれば解決する」は、何に時間がかかっているかを確かめる前に、対策を先に出しています。
- 仮説 D・E のように、目標や負荷の条件がどう決められていたかを確かめる観点が抜けています。
足りない証拠: 時間がかかっている処理の記録、目標と負荷の条件がどう決められていたかの記録。
人間が判断すること
- どの仮説から確かめるか
- 時間のかかる処理が見つかったら、それで問題は解決したと言えるか
Stage 4 追加証拠
この段階では、処理の技術面に関わる事実を開示します。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
大量データ検索SQLがボトルネックでした。
SQL の中身、実行にかかった時間、検索の対象、どの画面・機能の処理かは、正本に記録がありません。記録なし
TRAINING UI開示の順番について
この演習の段階の順番は、学習のために情報を示す順番です。ケースの中で、この順番で分かったという記録はありません。
TRAINING UI仮説の見直し
- 仮説 A（処理の作り）は、この事実とつながります。
- 仮説 B（基盤）・C（運用）は、この事実だけでは肯定も否定もできません。
- 仮説 D（負荷の見込み）・E（目標の決め方）は、この段階ではまだ確かめられていません。
TRAINING UI演習の問い
THINK
この SQL を速くすれば、この問題は終わりと言えるでしょうか。
大量のデータを検索する処理が、なぜ月末想定負荷で問題になったのかを考えるには、ほかに何を確かめる必要がありますか。
AI WORKFLOW
AI へ渡す情報: 5つの仮説と、大量データ検索SQLがボトルネックだったという事実
AI への問いの例（演習用の例です）
「大量のデータを検索する処理の性能を確かめるときの観点を、一般論として挙げてください。このケースの SQL・テーブル・数値の例は書かないでください。」
検証のしかた: AI の観点は一般論として扱います。AI がこのケースの SQL の書き換え案や、かかる時間の見積もりを出していたら、SQL の中身が正本に記録がないため削除します。
Stage 5 決定的証拠
この段階では、要件と設計に関わる事実を開示します。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
性能要件・性能設計不足がありました。
どの性能要件・どの性能設計が足りなかったのか、月末想定負荷がどんな条件かは、正本に記録がありません。記録なし
TRAINING UI開示の順番について
この演習の段階の順番は、学習のために情報を示す順番です。ケースの中で、この順番で分かったという記録はありません。
Stage 4 と Stage 5 に事実を分けたのも、学習のための分け方です。この段階の事実の方が根本的な原因だったという記録はありません。
TRAINING UI演習の問い
THINK
性能の要件と設計が足りていなかったとしたら、「2秒」という目標は、どんな条件で満たすものとして決めておく必要があったと思いますか。
Stage 4 で開示した事実と合わせて、月末想定負荷で32秒になったことを、自分の言葉で説明してください。
AI WORKFLOW
AI へ渡す情報: 正本の記述、Stage 4・5 で開示した2つの事実、あなたが書いた考え
AI への問いの例（演習用の例です）
「次の私の考えのうち、示された事実から言えることと、私の推測を分けてください。推測を事実のように書き換えないでください。」
検証のしかた: AI の仕分けが正本の事実の範囲に収まっているかを人間が確かめます。AI が足りなかった要件の項目をこのケースの事実として挙げていたら、正本に記録がないため削除します。
Stage 6 真因
この段階では新しい事実は加えません。Stage 4・5 で開示した2つの事実を、正本の真因として並べて示します。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
真因
性能要件・性能設計不足、大量データ検索SQLがボトルネック
Stage 4・5 で分けて示した2つは、正本では、この真因の1行に並べて書かれています。
TRAINING UI2つの観点で整理する
症状
性能目標2秒。月末想定負荷32秒、一部タイムアウト。
要件・設計の観点
性能要件・性能設計不足（Stage 5）。
技術の観点
大量データ検索SQLがボトルネック（Stage 4）。
読み方
遅い SQL を速くすることと、どの負荷条件で何秒を満たすべきかを要件・設計で定めることは、別の観点の問題です。片方だけを見ていると、もう片方が残ります。
重要
正本は、2つを並べて真因としています。どちらが元で、どちらがその結果か、どちらがより重いかという上下の関係は、正本に記録がありません。記録なし
「通常2秒」が具体的に何を意味するかは、ここでも正本からは確定できません。正本から確定できない
仮説 B（基盤）・C（運用）は、正本の真因には含まれていません。ただし、関係がなかったとも書かれていないため、否定もしません。
TRAINING UI演習の問い
THINK
Stage 3 であなたが有力と考えた仮説は、この真因とどう重なり、どう違いましたか。
SQL だけを速くした場合、要件・設計の観点の問題は残るでしょうか。
Stage 7 対応・成果物更新
何を確認し、立て直すか
M14 の時点で実際に何をしたのか、その結果どうなったのかは、正本に記録がありません。記録なし
ここでは、正本の真因をもとに、目の前の性能問題と、要件・設計の観点の両方について、何を確認し、立て直すかを考えます。この段階に、新しい正本の事実はありません。
TRAINING UI考えること
目の前の性能問題
- 時間がかかっている処理を、どう確かめ、どう直すか
- 一部でタイムアウトが起きている状態を、どう扱うか
要件・設計の観点
- 2秒という目標を、どの負荷条件で満たすべきものとして定め直すか
- 月末想定負荷の条件を、誰が、何をもとに決めるか
- 直した後に、どの条件で性能を確かめ直すか
人間が判断すること
- どちらから手を付けるか、両方をどう並行させるか
- 性能の目標と負荷の条件を、誰が決め、誰が承認するか
- 確かめ直した結果を、誰が受け入れるか
このケースで誰が判断したかは、正本に記録がありません。記録なし この演習では、正解となる人物・会議体・期限を示しません。役割で考えてください。
AI に任せてよいこと・任せてはいけないこと
任せてよいこと（下書きとして。最終確認は人間）
- 性能を確かめる観点の一覧の下書き
- 性能の要件を書くための書式の下書き（中身は人間が決める）
任せてはいけないこと
- 性能の目標値や負荷の条件を決めること
- 確かめ直した結果を受け入れるかどうかの判断
AI への問いの例（演習用の例です）
「性能の要件を書くための書式案を作ってください。項目名だけを挙げ、目標値や条件の数値は空欄にしてください。このケースの処理の例は書かないでください。」
検証のしかた: AI が書式に数値や処理の名前を埋めていたら削除します。書式に何を書くかは人間が決めます。
演習
最初に確認し、立て直すことは何ですか。目の前の性能問題と、要件・設計の観点のそれぞれについて書いてください。
成果物で見直す観点
- 性能の目標と負荷の条件
- 性能を確かめ直すときの記録
- 性能に関わる設計判断の記録
- 性能問題の管理
学習上の接続（正式な対応関係ではありません）:
CR06 の数値が性能試験で得られたという記録はありません。接続先の成果物にある記載例は学習用のサンプルで、CR06 のケースの事実ではありません。
Stage 8 / 8
Stage 8 再発防止
このケースの正本には、再発防止の記録がありません。記録なし ここで考える策は、あなたの設計です。
TRAINING UI再発防止を設計する
真因の2つそれぞれについて、あなたの策を書いてください。
性能要件・性能設計不足
性能の目標を、どの負荷条件で満たすものとして、いつ、誰が決めますか。
大量データ検索SQLがボトルネック
大量のデータを扱う処理の性能を、いつ、どの条件で確かめますか。
AI WORKFLOW
AI へ渡す情報: 正本の真因と、あなたが書いた策
AI への問いの例（演習用の例です）
「この再発防止策は、性能要件・性能設計不足と、大量データ検索SQLがボトルネックの2つを、それぞれ扱っていますか。扱っていないものを指摘してください。」
検証のしかた: AI の指摘は、策の抜け漏れを確かめる補助です。AI が足した策を、このケースで行われた再発防止として扱いません。どの策を、誰の承認で、いつから運用するかは人間が決めます。
最後の問い
月末想定負荷で性能目標を満たせないことに、もっと早く気づくには、何を、いつ確かめる必要があったでしょうか。
あなたの再発防止策は、真因の2つのそれぞれに対応していますか。
CR06で覚えてほしいこと
性能の問題は、遅い処理を直すだけでは終わりません。
このケースの正本は、大量データ検索SQLのボトルネックと、性能要件・性能設計の不足の2つを真因としています。
性能の目標は、どの負荷条件で満たすものかまで決め、その条件で確かめます。
学習上の接続（正式な対応関係ではありません）:
LEARNER HYPOTHESISあなたの考え。事実ではありません
Stage 8 の記録
学習状況
状態：未着手