【小学生でもわかる】dots不具合調査ガイド！原因と修正案を確かめる3STEP

どんな話？

架空の短いPythonコードを dots へ渡し、再現条件、最小の変更案、確認結果をまとめた調査メモを作った回です。数量2と3の2行で期待は5、実際は2。原因は len で注文の行数を数えていたことで、変更案は数値の qty を sum で合計すること。追加で実行を頼むと、空・1行・2行の3例が 0・2・5 になったログ（quantity_check.txt）を受け取れました。実リポジトリの修正、プルリクエスト、本番反映は実施していません。

この記事でわかること

• 入力・期待結果・実際の結果を1組にする。今回は入力が数量2と3、期待結果が合計5、実際の結果が2。期待する値を書かなければ、2件の注文を数える処理としては正しい可能性がある
• 「原因は分かった」「変更案を受け取った」「実行して確認した」「アプリへ反映した」は別々の段階。報告にも、どの段階まで済んだかを残す
• len(items) は「何行あるか」を数える命令なので、2行なら2を返す。変更案は、各行の qty を取り出して sum で合計すること。ただし、各行に数値の qty がある前提
• 確認例は、空のデータなら0、数量2だけなら2、数量2と3なら5。ダウンロードしたログには Python 3.12.14、確認用コード、3例の実測0・2・5が記録されていた
• 最初は原因・修正案・期待結果の返答だけだったため、追加で実行を依頼した。コード案を読む依頼と、実行して結果を確かめる依頼を分けると、何が済んだかを追いやすくなる
• 実際のプロジェクトで Codex へ作業を渡すには、使う場所と権限の準備が必要。クラウドの Codex 環境は、対象リポジトリとセットアップをあらかじめ用意する条件がある

こんな人に

• アプリの数字がおかしいのに、何を伝えれば直せるのかわからない人
• コードを書かないが、担当者へ渡す調査メモを作りたい人
• 返ってきた修正案を、実行した結果と分けて確かめたい人

この話のTIPS

• コツdotsは、調査を進めたり、必要に応じてWorkやCodexのタスクへ仕事を渡したりできる相棒です。不具合調査では、まず再現条件をまとめるところから始めると、返ってきた結果を人が確かめやすくなります。
• 注意確認結果が返らない場合は、未実行なのか、環境が足りないのか、失敗したのかを分けて聞きます。別の担当へ渡した仕事は、その担当の会話と状態も確認が必要です。dotsの一言だけで全工程の完了を判断しないようにしましょう。