JavaScriptファイルを変更した後に、毎回手動でlintを頼む代わりに、変更後のHookで同じ検証を実行します。失敗したら完了扱いにしません。
このLessonの結論
忘れやすい確認をHooksへ組み込み、作業後に同じ検証を繰り返せるようにします。
大切なのは、知識として覚えることではありません。自分の仕事を一つ選び、判断基準を当てはめ、変更前と変更後を比べられる状態まで進めることです。
- 自動化する確認を一つ選ぶ
- 失敗時は処理を止める
- 結果を人が読める形で残す
なぜ、うまく進まないのか
人が覚えて実行する確認は、急いでいる時に抜けます。頻度が高く、結果が明確な検証から自動化します。
3つの基準を、実務でどう使い分けるか
ここまでの要点は、三つを同時に満たすための標語ではありません。作業の段階ごとに使う判断基準です。順番を飛ばすと、手段だけが増え、何を改善したのか分からなくなります。
1. 自動化する確認を一つ選ぶ
AIへ任せる範囲を決める観点です。入力できる情報、期待する出力、人が確認する箇所を分けます。便利かどうかではなく、誤りが出たときの影響まで見てください。
「自動化する確認を一つ選ぶ」を確認するときは、判断を一文で書きます。根拠にした事実も隣へ置くと、別の選択肢と比べるときに迷いません。
2. 失敗時は処理を止める
出力の品質を安定させる観点です。指示文だけで解決しようとせず、材料の不足、完成条件、確認方法を分けます。同じ入力で再試行すると、偶然の成功も見抜けます。
「失敗時は処理を止める」を確認するときは、判断を一文で書きます。根拠にした事実も隣へ置くと、別の選択肢と比べるときに迷いません。
3. 結果を人が読める形で残す
人が判断を残すための観点です。数字、固有名詞、権利、公開可否はAIへ委ねません。誤りを見つけた後に戻れるよう、入力と出力の履歴を残します。
「結果を人が読める形で残す」を確認するときは、判断を一文で書きます。根拠にした事実も隣へ置くと、別の選択肢と比べるときに迷いません。
変更前と変更後の間にある判断
変更前作業者が思い出した時だけlintを実行する
変更後対象ファイル変更後にlintを動かし、失敗時は修正または停止する
重要なのは、変更後の表現をそのまままねることではありません。何が曖昧だったために判断できず、どの情報を加えたことで次の行動を選べるようになったかを読み取ります。
自分の仕事へ置き換えるときは、固有名詞や数字だけを差し替えません。相手の状況、止まっている理由、決める必要があることを先に書き換えてください。
変更後の案が長くなった場合は、目的に直接関係しない説明を削ります。短さを優先するのではなく、判断に必要な情報だけが残っている状態を目指します。
手順ごとの確認点
「Hooksで検証を自動実行する」を実務で使うときは、次の手順を一度に終わらせません。各段階で短い記録を残すと、途中で迷っても一つ前の判断へ戻れます。
繰り返し忘れる確認を一つ選ぶ
最初の作業では、対象と出力を一文で書きます。固有の業務名、相手、利用場面のどれかが入っていると、次の手順で迷いません。
成功と失敗を終了状態で判定できるようにする
二つ目の作業では、選んだ内容と理由を並べます。別の案を採用しなかった理由も一言残すと、判断基準が明確になります。
失敗結果を短い報告へ残す
三つ目の作業では、今回扱う範囲を固定します。追加したくなった内容は別のメモへ移し、最初に決めた目的から外れないように進めてください。
結果が出ないときは、どこへ戻るか
回答が毎回変わる
指示文を長くする前に、入力材料と完成形式を固定します。同じ入力を二回試し、変わった箇所と業務への影響を分けて確認してください。
もっともらしい誤りが混ざる
正しそうな文章と正しい事実は別です。数字、日付、固有名詞を原資料と照合し、確認できない内容は採用しません。
確認作業が増える
AIへ任せる範囲が広すぎます。分類、要約、下書きなど一工程へ戻し、人が確認する項目を三つ以内に固定します。
失敗は、最初からすべてやり直す合図ではありません。対象、根拠、変更、確認のうち、記録が途切れた場所だけへ戻ると改善を続けられます。
実践課題の完成条件
課題は「ファイル変更後に実行するlintまたは形式確認を一つ自動化します。」です。資料を作っただけでは完了にしません。次の四項目を第三者が読み取れる状態まで整えます。
- 誰の、どの業務や場面を扱ったかが一文で分かる
- 変更前の事実と、困っていた理由が分かれている
- 今回変えた箇所と、その判断理由が対応している
- 結果を確認する数字、行動、完成状態のどれかがある
説明を加えないと伝わらない場合は、情報量を増やす前に順番を見直します。第三者が「何を見て、何を変え、どう確かめるか」を説明できれば合格です。
つまずきやすい3つの点
最初から対象を広げすぎる
一度に多くを変えると、どの変更が効いたか分かりません。最初は一つの対象、一つの場面へ絞ります。
曖昧な目標で終える
「改善する」「注意する」だけでは、完了を判断できません。何がどう変われば成功かを、観察できる言葉で決めます。
変更前を残さない
元の状態がないと、改善したかを振り返れません。変更前、変更内容、確認結果の三つを同じ場所へ保存します。
そのまま使える作業メモ
対象今回扱う人、業務、場面を一つ書く
現状作業者が思い出した時だけlintを実行する
変更対象ファイル変更後にlintを動かし、失敗時は修正または停止する
確認何を見れば改善したと判断できるかを書く
実践課題
ファイル変更後に実行するlintまたは形式確認を一つ自動化します。
上の作業メモを使い、変更前と変更後を並べて保存します。所要時間は20〜30分が目安です。完成度を上げるより、一度試して差を確認することを優先してください。
理解度チェック
- 自分の業務では「自動化する確認を一つ選ぶ」を、どの事実で確認しますか。
- 自分の業務では「失敗時は処理を止める」を、どの事実で確認しますか。
- 自分の業務では「結果を人が読める形で残す」を、どの事実で確認しますか。
答え方の目安対象の業務名、確認する事実、合格とする状態の三つが入っていれば十分です。「意識する」「気をつける」だけで終わっていないかを見直します。
まとめ
忘れやすい確認をHooksへ組み込み、作業後に同じ検証を繰り返せるようにします。
まずは小さな一例で試し、結果を見てから対象を広げます。次のLessonへ進む前に作業メモを一つ残すと、学んだ内容を次の仕事でも再利用できます。