自分の題材で、もう一度作る

同じアプリを作れたら、次は題材だけを変えてみます。手順を覚えたかどうかは、別の入力や別の画面でも使えるかで確かめられます。

いきなり業務全体を自動化する必要はありません。一つの作業を小さく選び、完成条件を先に決めます。

この回では、新しい依頼書と確認計画を作ります。その依頼書を使って実装する時間は、この回の学習時間には含めません。

図を拡大 ↗

題材：小さくて、確かめやすいものを選ぶ

たとえば、読書メモの一覧、持ち物チェック、勉強会の予定表示です。入力と出力が見え、架空データで試せるものが向いています。

実データの共有、ログイン、決済、外部への自動送信が必要な場合は、権限やデータの扱いを別に設計します。最初の課題に全部含めると、できた部分と未確認の部分を分けにくくなります。

表の題材は例です。自分が本当に使いたい一つに置き換えてください。

依頼書：名前を変えるだけでは足りない

ナレッジデスクの検索テストを、そのままチェックリストに移しても合いません。利用者の操作と期待する結果を、題材に合わせて書き直します。

作りたい道具: [名前]
使う人と場面: [誰が、いつ、何をするか]
最初にできること: [一つの具体的な操作]
完成条件: [入力や操作と、観察できる結果]
作らないもの: [今回は範囲に含めない機能]
データと権限: [架空データ、編集できるフォルダ、外部接続の有無]
確認方法: [自動確認すること、画面で確認すること]
戻す方法: [失敗したときに保存済みのどの状態へ戻すか]

まず関連するファイルを読み、分からない条件を整理してください。
まだ編集せず、最小の計画を示してください。

計画を確認してから、小さく実装します。一度に完成を求めず、表示、操作、確認の順に進めます。

自己点検：五つの根拠を残す

この点検は、講座での練習用です。公式資格や、業務での使用を認証するものではありません。満たせない項目があれば、対応する回へ戻れます。

各観点で「自分で説明できる」「補助があればできる」「まだ試していない」を付けます。総合点だけにすると、次に何を練習するかが見えなくなります。

人に見てもらう：観察する操作を一つ渡す

たとえば、「検索で議事録を探してください」と頼みます。どこで止まり、何を押し、どの説明が足りなかったかを観察します。試した人の数や感想だけで、性能や効果を一般化しないでください。

相手の情報を記録する必要はありません。迷った操作と改善案だけを残します。アプリの機能と使い方の説明、どちらの問題だったかを分けます。

次の講座：今の課題に合わせて選ぶ

一人で使う品質を上げるなら、Claude Codeの実践習慣へ。レビューや長い作業の扱い方を習慣にします。

外部サービスやAPIが必要になったら、Claude Code実践へ。共有する担当が増えたら、チームで使う講座へ進みます。管理者として導入を考えるときは、組織導入で判断材料を整理します。

用語で止まったら、用語の辞典へ戻れます。機能を全部使うことより、目的に必要なものを選び、確かめられることを目指します。

今日のまとめ

• 学んだ進め方を、別の小さな題材で試すと定着を確かめられます。
• 目的・実装・検証・回復・説明の根拠を、それぞれ残します。
• 次に学ぶ機能は、自分の仕事で必要になったときに選びます。

Learnの講座一覧で、次のコースを選んでください。

参考・出典

• Anthropic：Best practices（目的、検証、文脈を絞る）
• Anthropic：Common workflows