atom.nocode-builder.organize-change-request-process
改修依頼の流れを整備する
改修依頼の流れを整備する レストランで料理を注文するときのことを想像してみてください。メニューがあって、注文用紙があって、厨房に伝票が回ります。この流れが整っているからこそ、料理がスムーズに届きますよね。 Webサ...
成果物成果物このレッスンが終わったとき、あなたの手元に残る具体的な成果物です(例: 公開済みの Web ページ、動作するフォームなど)。
証跡証跡成果物が正しく作れたことを確認するためのチェックリストです(例: ブラウザで動作する、フォーム送信で値が保存される)。
メディアメディアレッスン内に出てくる図や動画のスロットです。実際の画面やイメージで理解を補助します。
レッスン本文
改修依頼の流れを整備する
レストランで料理を注文するときのことを想像してみてください。メニューがあって、注文用紙があって、厨房に伝票が回ります。この流れが整っているからこそ、料理がスムーズに届きますよね。
Webサービスやツールの「改修依頼」も同じです。依頼の受け付けから完了までの道筋があらかじめ決まっていると、作る側も依頼する側も安心できます。逆にルールがないと、依頼がチャットに埋もれたり、「言った・言わない」でトラブルになりがちです。
このレッスンでは、あなたが改修依頼の流れを1枚の文書にまとめることを目指します。AIツール(=ChatGPTやClaudeなどの対話型AI)を使って下書きを作り、あなた自身の言葉で仕上げましょう。15分で終わるように、手順を絞って進めます。

前提を確認する
- あなたが日頃、社内ツールやWebサービスの改修を誰かに依頼している、または依頼される立場であること
- AIツール(ChatGPT、Claude など)を開いて文章のやりとりができること
特別なプログラミング知識は必要ありません。
ステップ1: 依頼の「入口」を決める
まず、依頼がどこから入ってくるかを1つ決めます。チャット、メール、フォームなどが考えられますが、1つに絞るのがコツです。
良い例:
- 「Googleフォームで依頼を受け付ける。項目は5つ以内に絞る」
- 「Notionのデータベースに依頼テンプレートを用意する」
悪い例:
- 「Slackでもメールでも口頭でも受け付ける」(バラバラだと漏れる)
- 「フォーマットは特にない」(毎回ヒアリングが必要になる)
入口がはっきりしていると、依頼が埋もれにくくなります。
ステップ2: 依頼に必要な情報を洗い出す
依頼内容を正しく伝えるために、最低限必要な項目を決めましょう。多すぎると依頼する側が面倒になるので、3〜5個に絞るのがポイントです。
おすすめの項目:
| # | 項目 | 書く内容の例 |
|---|---|---|
| 1 | 現状の問題 | 「○○画面の検索が遅い」 |
| 2 | 期待する状態 | 「3秒以内に結果が出る」 |
| 3 | 希望期限 | 「来月末まで」 |
| 4 | 優先度 | 「高・中・低」の3段階 |
| 5 | 依頼者の連絡先 | 「Slackの@名前」 |
良い例: 「現状の問題・期待する状態・希望期限の3項目を必須にする」 悪い例: 「一言でざっくりお願いします」(何をどう直すか伝わらない)
ステップ3: 依頼の「出口」を決める
依頼が完了したことをどう伝えるかも決めておきます。「できました」だけでは、依頼者が確認できません。
良い例:
- 「Slackの専用チャンネルで完了通知を送り、テスト環境のURLを添える」
- 「依頼フォームのステータスを『完了』に変え、確認依頼のメンションを送る」
悪い例:
- 「完了したら口頭で伝える」(記録に残らない)
- 「次の定例で報告する」(タイムラグが大きい)
ステップ4: AIツールで下書きを作る
ここまで決めた内容をAIツールに伝えて、文書の下書きを作ってもらいましょう。以下のプロンプト(=AIへの指示文)をコピーして、ChatGPTやClaudeの入力欄に貼り付けてください。
<山括弧> の部分はあなたの状況に合わせて書き換えます。
社内ツールの改修依頼フローをまとめた文書を作ってください。
次の条件を反映してください。
- 依頼の入口: <Googleフォーム / Slack / メール など>
- 必須項目: <現状の問題 / 期待する状態 / 希望期限 など>
- 完了の通知方法: <Slack / メール など>
- 対象サービス名: <サービス名>
- 想定される依頼者: <営業チーム / 全社員 など>
フローを「依頼 → 受付確認 → 着手 → 完了報告 → 依頼者確認」の
5ステップで表形式にまとめてください。
各ステップに「誰がやるか」「何をするか」「使うツール」を書いてください。
AIの出力をチェックするポイント
AIが出してきた文書をそのまま使うのではなく、次の3つを必ず確認してください。
- あなたの職場に合っているか ― 存在しないツール名や部署名が入っていないか
- ステップが多すぎないか ― 5ステップ前後に収まっているか。多すぎたら「ステップを5つに絞ってください」と追加で指示する
- 専門用語が紛れ込んでいないか ― 依頼者(非エンジニア)が読んでわかる言葉になっているか

AIへの追加指示の例
出力に不満があれば、次のように追加で指示してみましょう。
- 「表にもう1列『所要時間の目安』を追加してください」
- 「依頼者が非エンジニアなので、専門用語を使わず書き直してください」
- 「完了条件が曖昧なので、具体例を入れてください」
ステップ5: 文書を仕上げる
AIの下書きをベースに、以下の最終チェックをしながら手を加えましょう。
| チェック項目 | 確認すること |
|---|---|
| 時系列で並んでいるか | 依頼→受付確認→着手→完了→依頼者確認の順か |
| 担当者が明確か | 各ステップに「誰がやるか」が書いてあるか |
| 戻り先が書いてあるか | 不明点があったら誰に聞けばよいか |
| 完了条件が具体的か | 「テスト環境で動作確認済み」のように判定できるか |
| 依頼者が読んでわかるか | 専門用語なしで書けているか |

成果物を確認する
完成した文書が次の条件をすべて満たしているか、最終チェックしましょう。
- 依頼の入口(どこに連絡するか)が1つ決まっている
- 必須項目(何を伝えるか)が3〜5個列挙されている
- 依頼から完了までのステップが5つ前後で時系列に並んでいる
- 各ステップに担当者(誰がやるか)が書いてある
- 完了の定義が「テスト環境で確認済み」のように具体的である
- 不明点の問い合わせ先が書いてある
- 依頼者(非エンジニア)が読んでわかる言葉で書かれている
すべてチェックがつけば完成です。文書を社内で共有しやすい場所(Googleドライブ、Notion、社内Wikiなど)に保存しましょう。
つまずきやすいポイントに対処する
| つまずき | 原因 | 対策 |
|---|---|---|
| 項目を詰め込みすぎて依頼者が書くのが大変になる | 「念のため」で項目を増やしがち | 必須項目は3〜5個に絞る。追加情報は任意欄にする |
| AIの出力をそのまま使って職場の実情に合わない | AIはあなたの職場を知らない | 必ず自分の言葉で読み直し、ツール名・部署名を書き換える |
| 完了の定義が曖昧で「できた」の認識がずれる | 完了=リリースなのか、テスト済みなのか不明 | 「テスト環境で動作確認済み」など具体的な完了条件を書く |
| フローが複雑になりすぎて誰も見なくなる | 例外ケースまで全部書こうとする | まず基本の5ステップだけ。例外は運用しながら追記する |
| AIへの指示が漠然として的外れな出力が返ってくる | 条件を具体的に伝えていない | ステップ4のプロンプト例のように、入口・項目・出口を明示する |
種類: markdown_doc
検証: basic_manual_check_v1
証跡証跡成果物が正しく作れたことを確認するためのチェックリストです(例: ブラウザで動作する、フォーム送信で値が保存される)。
メディア
必須
なし
あると楽
なし