導入・受入の準備学習記事全11節Operate
3つの役割の操作と、困ったときの連絡先を利用手順書にまとめる
この記事で身につくこと操作説明、困った時の連絡先、権限の申請、管理担当を決める理由と、運用管理者が承認を代行しない方針を説明でき、初めて使う人が「準備・始め方・入力・確認・失敗時・止める・相談先」を利用手順書から読み取れる。
記事内目次（21項目）
この記事の会社・人物・データはすべて架空の設定です。実在する会社や案件とは関係ありません。連絡先・管理担当の人数は、03-01と同じく教材上の仮定です。この記事の時点で実際に動く画面は無く（10-01・10-04のとおり）、手順書の画面名・項目名・表示文は04-02・04-04の設計文書に基づくもので、実画面では未確認です。手順書の中では「実画面未確認」と明記しています。
この記事は何の話か。依頼者・承認者・運用管理者という3つの役割それぞれの操作をまとめた利用手順書と、困ったときの連絡先・権限申請の流れをまとめた問い合わせ手順を作る話です。
なぜ必要か。アプリができても、使い方や困ったときの連絡先が分からなければ、利用者は操作に迷ったり、誤った使い方をしてしまいます。役割ごとに何をすればよいかと、困ったときにどこに連絡すればよいかを、あらかじめ整理しておく必要があります。
この記事を読むとできるようになること。
- 操作説明、困った時の連絡先、権限の申請、管理担当を決める理由を説明できる
- 依頼者・承認者・運用管理者向けの利用手順書と、問い合わせ手順を作れる
- 問い合わせ対応を誰が担うかを、運用担当の負担と業務への影響から判断できる
- 手順書に書けること（設計文書に基づく操作）と、実画面ができてから確かめること（実画面未確認）を分けて書ける
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（3つの役割と運用管理者の立場）→第4節（判断すること）→第5.1節（全員に共通する準備と始め方）→第5.5節（問い合わせ手順）→第9節。ここまでで、手順書に何を書き、困ったとき誰へ相談するかが分かります。
- 作って確かめる：上に加えて第5.2〜5.4節（役割別の手順書：依頼者・承認者・運用管理者）→第6節（手順書としての完成条件との照合）→第7節（確かめたこと・確かめていないこと）。
- 設計判断を深める：上に加えて第8節（問い合わせ対応の分担、実画面未確認の扱い、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、依頼者・承認者・運用管理者の3役割それぞれの操作（作成・提出・承認・差戻し・再提出など）をまとめた利用手順書と、困ったときの連絡先・権限申請の流れ・管理担当をまとめた問い合わせ手順を作ることです。
04-03では画面遷移の正常系を確認しましたが、それを利用者向けの説明としてまとめる作業はまだ行っていませんでした。この記事では、それを行います。
この記事を読み終えると、次のものが手元にできます。
- 利用手順書・問い合わせ手順（役割別の操作、困った時の対応、連絡先、権限申請、管理担当）
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
利用手順書
一言でいうと、利用者が迷わず操作できるように、役割ごとの操作をまとめた説明資料です。
権限申請
一言でいうと、承認者を追加してほしい、担当を変更してほしいといった、権限に関わる依頼を運用管理者に申し出る手続きです。
これがないと、利用者は操作に迷ったときに何をすればよいか分からず、運用管理者への問い合わせが整理されないまま集中し、対応が混乱します。
読む順路：役割別の操作は04-01、画面の項目は04-02、画面遷移は04-03、例外時の表示は04-04、受入確認は10-01、権限は05-03が該当します。この記事の手順書は、10-04（利用開始の可否を判断する）、11-03（初期利用）、12-02（異常を検知し影響を判断する）、13-04（引継ぎ・移行・廃止を行う）で使います。
3. 理解する：3つの役割と運用管理者の立場
3.1 依頼者・承認者・運用管理者の操作の違い
依頼者は自分の依頼の作成・提出・再提出を行い、承認者は割り当てられた依頼の承認・差戻しを行います。運用管理者は利用者・役割・割当の管理を行いますが、05-03で確認したとおり、承認そのものを代行することはできません。
3.2 よくある誤解
「運用管理者は管理者だから、困ったときは代わりに承認してくれる」。05-03の権限表のとおり、運用管理者は承認を無条件に代行できません（設計書5.2）。運用管理者ができるのは、利用者・役割・割当の管理までです。承認者が対応できない場合は、別の承認者への割当変更で対応します（第5.4節・第5.5節）。
「利用手順書があれば、問い合わせは来なくなる」。手順書で解決できるのは、操作方法などの一般的な内容です。個別の依頼の内容についての判断（承認してよいかなど）は、手順書では解決できず、業務上の判断が必要です（第8.1節）。
「他の記事へのリンクを並べれば手順書になる」。「04-02参照」と書かれた表は、設計者には辿れても、初めて使う人には操作の手がかりになりません。手順書は、その人が今いる画面で何を入力し、何が表示されれば成功で、失敗したら何をするかまで書きます（第5節）。
「設計文書に書いてあれば、画面もそのとおりに動く」。この記事の時点で画面はまだ無く（10-01・10-04）、手順書の画面名・表示文は設計文書上のものです。実画面ができたら、手順書の各手順を実際に操作して確かめ、違いがあれば手順書を直します（第8.2節）。
4. 判断すること
利用手順書と問い合わせ手順を作るときに人が判断することは、次の5つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| 誰向けに、どこまで書くか | 依頼者・承認者・運用管理者で必要な操作が違う。全員に全部を渡すと、自分に関係ない手順に迷う | 可（役割が増えたら章を足す） | 承認者が依頼者の手順を読んで操作を間違える |
| 手順書に書けること／実画面ができてから確かめること | 画面はまだ無い。設計文書に基づいて書ける手順と、実画面で確かめる手順を分けないと、「書いてあるのに動かない」手順書になる | 不可。区別を落とすと、手順書が事実として読まれる | 存在しない画面の操作が「確認済み」として引き渡される |
| 失敗したとき、どこで止めて誰へ相談するか | 利用者が自己判断で繰り返すと、二重提出や状態の不整合が起きる（04-04の通信失敗） | 不可。止める条件と相談先は手順書に書く | 同じ操作の繰り返しで異常が広がる。申告が届かない |
| 運用管理者に何を頼めるか | 利用者・役割・割当の管理まで。承認の代行は05-03で禁止 | 不可。権限表と食い違う手順を書かない | 「管理者に承認してもらう」運用が生まれ、権限表が空文になる |
| 問い合わせを誰が受けるか | 運用担当（総務の担当者1名、架空）の負担と、業務への影響から決める（第8.1節） | 可（架空の体制で仮置き） | 問い合わせが集中して対応できない、または誰にも届かない |
勝手に決めてはいけないこと：05-03の権限表にない操作（運用管理者による承認代行など）を、この記事で許可しません。連絡先・管理担当の人数を、確認済みの事実として書きません（教材上の仮定です）。画面が存在しないのに、画面を操作して確認したかのように書きません。
AIに任せる範囲：設計文書（04-01・04-02・04-04）から手順の下書きを作ること、役割別に並べ替えること、表示文の一覧化はAIに任せられます。任せてはいけないのは、止める条件と相談先の決定、権限表との整合の確認、実画面ができたときに手順を実際に操作して確かめることです。
5. 作って確かめる：利用手順書・問い合わせ手順を作る
以下が利用手順書の本文です。画面名・項目名・表示文は04-02（画面の原型）と04-04（例外時の表示）の設計文書に基づき、この記事の時点では実画面で未確認です（表の「実画面」列）。
5.1 全員に共通：準備と始め方
| 項目 | 内容 | 実画面 |
|---|---|---|
| 準備するもの | ①自分の役割（依頼者／承認者／運用管理者）が登録されていること（登録されていなければ第5.5節の権限申請へ）。②この手順書。③困ったときの連絡先（第5.5節）。④依頼者は、件名・内容・承認者（誰に承認してもらうか）を手元に用意 | — |
| どこから始めるか | アプリを開くと一覧画面が表示される。一覧には自分に関係する依頼（依頼者：自分が作成した依頼、承認者：自分に割り当てられた依頼、運用管理者：すべて）が、件名・状態・提出日で並ぶ。依頼が0件のときは「表示できる依頼がありません」と表示される | 未確認 |
| 状態の見方 | 依頼は「下書き→提出済み→承認済み」または「提出済み→差戻し→（再提出で）提出済み」と進む。今の状態は一覧と詳細画面に表示される | 未確認 |
| 全員に共通する止める条件 | 「通信に失敗しました。時間をおいて再度お試しください」が2回続けて表示されたら、それ以上繰り返さず運用担当へ連絡する（同じ依頼が2件提出されるのを防ぐ）。自分の役割でできないはずの操作ボタンが見えたら、押さずに運用担当へ連絡する | 未確認 |
5.2 依頼者の手順
| 段階 | 何をするか | 何を確認するか（成功のしるし） | 失敗したとき | 実画面 |
|---|---|---|---|---|
| 1 作成 | 一覧画面から依頼作成画面を開き、件名・内容を入力し、承認者を一覧から選ぶ（3つとも必須） | 3項目が入力され、承認者が選ばれている | — | 未確認 |
| 2 提出 | 「提出」ボタンを押す | 一覧に戻り、その依頼の状態が「提出済み」、提出日が今日になっている | 「件名を入力してください」など項目名が表示される→ その項目を入力して再度提出。「通信に失敗しました…」→ 時間をおいて1回だけ再試行。2回続いたら止めて運用担当へ | 未確認 |
| 3 待つ | 承認者の対応を待つ。提出後は自分で編集できない | 一覧の状態が「承認済み」または「差戻し」に変わる | 3営業日（架空の目安）を過ぎても「提出済み」のまま→ 承認者本人に連絡。承認者が不在なら運用担当へ割当変更を依頼（第5.5節） | 未確認 |
| 4 差戻しへの対応 | 状態が「差戻し」の依頼を詳細画面で開き、差戻し理由を読む。内容を直して「再提出」ボタンを押す | 状態が「提出済み」に戻る | 差戻し理由が表示されない→ 運用担当へ連絡（理由なしの差戻しは設計上できないはず。04-04） | 未確認 |
| 止める条件 | 提出したはずの依頼が一覧に無い、状態が「提出済み」にならない、同じ依頼が2件見える | — | 自分で作り直さず、運用担当へ連絡（12-02の申告の入口） | — |
5.3 承認者の手順
| 段階 | 何をするか | 何を確認するか（成功のしるし） | 失敗したとき | 実画面 |
|---|---|---|---|---|
| 1 確認 | 一覧画面で状態「提出済み」に絞り込み、自分に割り当てられた依頼を開く（詳細画面） | 件名・内容・承認者（自分）が表示され、「承認」「差戻し」ボタンが見える | ボタンが見えない→ 自分に割り当てられていない依頼か、状態が「提出済み」でない。割当を確認したいときは運用担当へ | 未確認 |
| 2 判断 | 内容を読み、承認するか差し戻すかを業務上の判断で決める（この判断は手順書では決められない。第8.1節） | — | 判断に迷う→ 上位の業務判断者へ相談（この記事の範囲外） | — |
| 3a 承認 | 「承認」ボタンを押す | 状態が「承認済み」になり、「承認」「差戻し」ボタンが消える | 「通信に失敗しました…」→ 時間をおいて1回だけ再試行。2回続いたら止めて運用担当へ。承認したのに状態が変わらない／記録がない→ 繰り返さず運用担当へ（12-02） | 未確認 |
| 3b 差戻し | 差戻し理由を入力してから「差戻し」ボタンを押す | 状態が「差戻し」になり、理由が依頼者に見える | 「差戻し理由を入力してください」→ 理由を入力してから押す | 未確認 |
| 止める条件 | 自分の依頼に「承認」ボタンが見える（自己承認は禁止。05-03）、割り当てられていない依頼が承認できそうに見える | — | 押さずに運用担当へ連絡 | — |
5.4 運用管理者の手順
| 段階 | 何をするか | 何を確認するか（成功のしるし） | 失敗したとき | 実画面 |
|---|---|---|---|---|
| 1 利用者・役割の管理 | 利用者の登録、役割（依頼者／承認者）の設定を行う。この記事の時点では管理画面が無く、11-02で配置した利用者データを運用担当が直接更新する運用（教材上の仮定） | 変更後、該当の利用者の一覧に役割どおりの依頼が見える | 変更が反映されない→ 配置したデータの版を確認（11-04） | 未確認（管理画面なし） |
| 2 割当変更 | 承認者が対応できない依頼について、別の承認者へ割当を変更する。承認そのものは代行しない | 新しい承認者の一覧にその依頼が「提出済み」で見える | 変更後も元の承認者の一覧に残る→ 状態と割当の不整合。12-02の初動へ | 未確認 |
| 3 一覧の閲覧 | すべての依頼の状態を確認する。状態を変更する操作は行わない（04-01） | — | — | 未確認 |
| 止める条件 | 承認・差戻し・再提出を求められた（権限表で禁止）。同じ症状の申告が2件以上、または失敗ログが増え続ける | — | 代行せず、割当変更で対応。異常は12-02の初動手順、切戻しは11-04 | — |
5.5 問い合わせ手順（全員）
| 困りごと | まず自分で確認すること | それでも解決しないとき | 連絡先 |
|---|---|---|---|
| 操作の仕方が分からない | この手順書の自分の役割の節 | 運用担当へ連絡 | 運用担当（総務の担当者1名、架空の仮定） |
| 依頼が見えない、権限がない旨が表示される | 自分の役割と、依頼の状態（05-03の権限表どおりなら正常） | 想定外なら運用担当へ連絡 | 同上 |
| 承認者を追加・変更してほしい（権限申請） | — | 依頼者または承認者が運用担当へ申請し、運用担当が利用者データの役割・割当を変更する | 同上 |
| 承認者が長期不在で対応できない | 承認者本人に連絡 | 運用担当へ連絡し、別の承認者へ割当変更してもらう（運用管理者は承認を代行しない） | 同上 |
| 操作したのに状態が変わらない、記録がない、同じ依頼が2件ある | 同じ操作を繰り返さない | 運用担当へ申告（12-02の初動の入口） | 同上（緊急時は総務課長、架空） |
権限申請の流れ：申請者（依頼者または承認者）→ 運用担当（総務の担当者1名、架空の仮定）へ連絡 → 運用担当が利用者・役割・割当を変更 → 申請者へ変更完了を連絡（架空の想定）。
6. 実行結果（利用手順書・問い合わせ手順）
本節は文書としての成果物であり、コードの実行は伴いません。第5.1〜5.5節がそのまま利用手順書・問い合わせ手順です。初めて使う人の視点で、手順書が次の7つに答えているかを照合します。
| 初めて使う人の問い | 手順書のどこが答えるか | 答えているか |
|---|---|---|
| 何を準備する | 第5.1節「準備するもの」 | 役割の登録、手順書、連絡先、入力内容 |
| どこから始める | 第5.1節「どこから始めるか」 | 一覧画面から。0件時の表示も記載 |
| 何を入力する | 第5.2節の段階1、第5.3節の段階3b | 件名・内容・承認者（必須）、差戻し理由 |
| 何を確認する | 各役割の「何を確認するか（成功のしるし）」列 | 状態と提出日の変化、ボタンの表示・非表示 |
| 失敗したらどうする | 各役割の「失敗したとき」列 | 表示文ごとの対処（04-04の4場面に対応） |
| どこで止める | 第5.1節の共通の止める条件と、各役割の「止める条件」行 | 通信失敗2回、権限外のボタン、状態が変わらない、二重表示 |
| 誰へ相談する | 第5.5節 | 運用担当（架空）、緊急時は総務課長（架空） |
ただし、画面はこの記事の時点で存在しないため、各手順の「実画面」列はすべて「未確認」です（第7節）。
7. 確認結果
実行環境：本節は文書によるまとめであり、コードの実行は伴いません。作成日：2026-09-20、手順書の作り直し：2026-09-21。
完了条件との照合：
| 完了条件 | 確認結果 |
|---|---|
| 3役割それぞれの操作が書かれている | 第5.2〜5.4節に、段階・確認・失敗時・止める条件を役割ごとに記載 |
| 初めて使う人の7つの問い（準備・始め方・入力・確認・失敗時・止める・相談先）に答えている | 第6節の表のとおり |
| 連絡先と管理担当が空でない（架空でよい） | 第5.5節に記載（総務の担当者1名、教材上の仮定） |
| 権限申請の流れがある | 第5.5節末尾に記載 |
| 権限表（05-03）と食い違う手順が無い | 運用管理者の承認代行なし、自己承認は止める条件に記載 |
| 画面が存在しない部分を「実画面未確認」と明記している | 第5.1〜5.4節の「実画面」列 |
この記事で確かめたこと：手順書が、設計文書（04-01・04-02・04-04・05-03）と矛盾せず、初めて使う人の7つの問いに答える形になっていること。
この記事で確かめていないこと：
| 範囲 | 理由 | どこで確かめるか |
|---|---|---|
| 手順書どおりに実画面が動くこと（画面名・項目名・表示文・ボタンの表示条件） | 画面が未実装（10-01・10-04） | 画面完成後、各役割の手順を実際に操作して確かめ、手順書を直す（第8.2節） |
| 実際の利用者が手順書を読んで操作できること | 実際の利用者への説明は未実施 | 10-04の限定試行へ進む条件が満たされてから |
| 運用管理者の管理操作の実際の方法 | 管理画面が無く、データの直接更新は教材上の仮定 | 管理の方法を決めてから |
| 問い合わせの実際の量と対応時間 | 運用未実施 | 12-01の運用項目で把握する |
残る制限：この手順書は、実際の利用者に説明したり、実際に運用してみたりしたものではありません。連絡先・管理担当の人数は、03-01と同じく教材上の仮定です。この記事の本文はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
8. 設計を判断する
8.1 問い合わせ対応を誰が担うかを判断する
| 問い合わせの種類 | 手順書で解決できるか | 対応の担い手 |
|---|---|---|
| 操作方法（作成・提出・承認の仕方） | 解決できる | 手順書（人を介さない） |
| 権限申請（承認者の追加・変更） | 手順は書けるが、実際の変更作業は人が行う | 運用担当（総務の担当者1名、架空の仮定） |
| 個別の依頼の内容についての判断（承認してよいか） | 解決できない（業務上の判断が必要） | 承認者本人、または上位の業務判断者（この記事の範囲外） |
運用担当の負担を考えると、操作方法のような繰り返し発生する問い合わせは手順書で解決し、権限申請のように利用者データの変更を伴うものだけを人（運用担当）が対応する、という分担にしています。
8.2 「実画面未確認」の扱い
| 選択肢 | 内容 | 適する場合 |
|---|---|---|
| 画面ができるまで手順書を書かない | 実画面で確かめてから書く。書き直しが無い | 画面の完成が近く、利用開始まで時間がある場合 |
| 設計文書に基づいて書き、未確認と明記する（この記事で採用） | 手順書の形と、止める条件・相談先を先に決められる。画面ができたら操作して直す | 手順書が10-04の判定材料や13-04の引継ぎ資料として先に必要な場合 |
この記事では後者を採用し、「実画面」列で未確認を明示しています。画面が完成したら、各役割の手順を実際に操作し、画面名・表示文・ボタンの表示条件の違いを手順書に反映してから、「未確認」を消します。消すのは操作して確かめた手順だけです。
8.3 適用限界
この手順書は、依頼者・承認者・運用管理者という3役割を前提にしています。将来、役割が増えたり、複数の部署にまたがる運用になったりする場合は、この手順書だけでは対応しきれない可能性があり、その時点で見直しが必要です。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 利用手順書・問い合わせ手順ひな形（役割別の操作、困った時の対応、連絡先、権限申請、管理担当） | templates/10-03-user-guide-support_template.md | templates/10-03-user-guide-support_example.md |
自分の業務に使うときの手順は次のとおりです。
- 役割ごとに、準備・始め方・入力・確認（成功のしるし）・失敗したとき・止める条件を書く
- 画面が無い、または操作して確かめていない手順は「実画面未確認」と明記する
- よくある困りごとと、その対応・連絡先を整理する
- 権限申請の流れ（誰が、誰に、何を申請するか）を決める
- 問い合わせ対応を誰が担うかを、負担と業務への影響から判断する
- 画面ができたら手順を操作して確かめ、手順書を直してから「未確認」を消す
10. 次工程への受渡し
次へ渡すもの：利用手順書・問い合わせ手順。
次工程での使われ方：10-04（利用開始の可否を判断する）では、この手順書が整っていること（ただし実画面未確認）を判定材料の1つとして使います。11-03（初期利用）では、承認者役の操作と止めて戻す条件の土台にします。12-02（異常を検知し影響を判断する）では、この問い合わせ手順を申告経路として使います。13-04（引継ぎ・移行・廃止を行う）では、この手順書を引継ぎ資料の一部として使います。
前工程へ戻る条件：役割そのものや権限の範囲に見直しが必要な場合は、05-03に戻って確認します。画面の項目・表示文が設計文書と違うと分かった場合は、04-02・04-04に戻って設計文書を直してから手順書を直します。
11. 根拠と更新情報
- この記事の会社・人物・データはすべて架空の設定です。
- 役割別の操作は04-01、画面名・項目・ボタンの表示条件は04-02、例外時の表示文と次の操作は04-04、権限（運用管理者の承認代行禁止を含む）は05-03・記事Aに基づきます。画面は未実装のため、いずれも設計文書上の内容です。
- 2026-09-21（Phase 5B-2C2）：初版の利用手順書は役割別の操作を「04-02参照」などの短い表にしただけで、初めて使う人が読んで操作できる内容ではなかった。本更新で、役割別に準備・始め方・入力・確認（成功のしるし）・失敗したとき・止める条件・相談先を書いた手順書に作り直し、画面が存在しない部分を「実画面未確認」と明記した。連絡先・権限申請の流れ・運用管理者の承認代行禁止は変えていない。
- 連絡先・管理担当の人数（総務の担当者1名）は、03-01と同じ教材上の仮定を引き継いでいます。
- 制作の来歴：本文はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
- 未確認事項：手順書どおりに実画面が動くこと、実際の利用者への説明、実際の問い合わせ対応の運用は、この記事の時点では行っていません。