課題発見・企画学習記事全11節Concept
聞き取りメモから、依頼者・承認者・運用管理者を整理する
この記事で身につくこと利用者・担当者・承認者・管理者の違いを説明し、「使う人」と「決める人」と「運用する人」が別であり得ることを例で言える。
記事内目次（18項目）
この記事の会社・人物・聞き取り内容はすべて架空の設定です。実在する会社や案件とは関係ありません。
この記事は何の話か。みらい業務サービスの総務課長・総務担当への架空の聞き取りメモから、依頼者・承認者・運用管理者という3つの役割を整理する話です。
なぜ必要か。「利用者」とひとまとめに考えてしまうと、実際にアプリを使う人と、業務のルールを決める人、日々の運用を担う人が別であることを見落とし、必要な機能や権限を取りこぼします。
この記事を読むとできるようになること。
- 利用者・担当者・承認者・管理者の違いを、「使う人」「決める人」「運用する人」という観点で説明できる
- 聞き取りメモから、依頼者・承認者・運用管理者の役割ごとに実際の作業と困り事を整理できる
- 聞き取りで得た情報と、聞き手の推測を区別し、追加で確認すべき事項を一覧にできる
読む順路。この記事は3つの深さで読めます。全部を順に読む必要はありません。
- 基本だけ理解する：第1節→第3節（使う人・決める人・運用する人の違い）→第4節（判断すること）→第5.2節（整理表）→第9節。ここまでで、自分の業務の関係者を「役割」で分け、聞き取れたことと推測を分けて書き始められます。
- 作って確かめる：上に加えて第5.1節（聞き取りメモ）→第5.3節（未確認事項）→第6節（完了条件との照合）→第7節。
- 設計判断を深める：上に加えて第8節（推測のまま進める危険、適用限界）。
1. 今回の業務課題と完成するもの
この記事でやることは、みらい業務サービスの総務課長・総務担当への架空の聞き取りメモをもとに、依頼者・承認者・運用管理者という3つの役割について、実際の作業と困り事を整理表に書き分けることです。
00-04では「人とAIの役割」を扱いましたが、この記事から先は「業務に関わる人たちの役割」を扱います。ここでの役割の区別が、この先の要件定義（記事Aの役割表）・設計（05-03の権限表）の土台になります。
この記事を読み終えると、次のものが手元にできます。
- 利用者・関係者の整理表（役割、人数の目安、作業、困り事、確認済み／推測）
- 未確認事項の一覧
2. 前提知識と読む順路
この記事で使う言葉を先に説明します。
利用者・関係者
一言でいうと、利用者はアプリを直接操作する人、関係者はアプリの結果に影響を受けたり、運用に関わったりする人を含む、より広い呼び方です。
聞き取り
一言でいうと、実際に業務をしている人に、困り事や作業の内容を尋ねることです。たとえば、「依頼の進捗が見えない」という総務課長の発言は、聞き取りで得られた情報です。
これがないと、開発する側の思い込みだけで機能を決めてしまい、実際の困り事とずれた仕組みを作ってしまいます。
読む順路：人とAIの役割は00-04が該当します。この記事の整理表は、01-02（現状の流れと困り事を整理する）で使う登場人物になり、整理表の「困り事」欄の発言が01-02の課題一覧の「現象」になります。
3. 理解する：「使う人」「決める人」「運用する人」は別
3.1 4つの立場の違い
| 立場 | 一言でいうと | この題材での例 |
|---|---|---|
| 利用者 | アプリを直接操作する人 | 依頼者、承認者 |
| 担当者 | 日常の業務を回す人 | 総務担当（依頼の取りまとめなど） |
| 承認者 | 内容を確認し、進めてよいか判断する人 | 総務課長、または割り当てられた承認者 |
| 管理者 | 利用者・権限・運用を管理する人 | 運用管理者 |
同じ人が複数の立場を兼ねることもあります。たとえば、総務課長は「承認者」であると同時に、自分の依頼を出すときは「利用者（依頼者）」にもなります。
3.2 よくある誤解
「利用者はみんな同じことをする」。依頼者と承認者では、できること・見るべき情報がまったく異なります（記事Aの役割表、05-03の権限表で扱います）。
「聞き取りで言われたことがすべて正しい要件になる」。聞き取りは実際の困り事を知る手がかりですが、そのまま要件にするのではなく、01-02で現象と仮説に分け、記事Aで確認可能な条件に整理し直します。
「運用管理者は聞かなくても分かる」。この記事の聞き取りでは、依頼者・承認者の困り事は具体的に聞けていますが、運用管理者の実際の作業・人数はまだ聞き取れていません（第5.3節）。
4. 判断すること
整理表を作るときに人が判断することは、次の4つです。
| 判断すること | なぜ判断が必要か | 仮置きしてよいか | 間違えた場合の影響 |
|---|---|---|---|
| 聞いた相手を、どの役割（依頼者・承認者・運用管理者）に置くか | 役割ごとに「できること」が違う（第3.1節）。同じ人が複数の役割を兼ねることもある | 可（迷ったら、その人が「その場面で何をしているか」で置き、兼ねる場合は両方に書く） | 総務課長を承認者だけに置くと、課長自身が依頼を出す場面（依頼者としての困り事）を取りこぼす |
| 各行が「聞き取り済み」か「推測」か | 推測を事実として次工程へ渡すと、01-02の現象、記事Aの要件の根拠が、誰も言っていないことになる | 不可。聞き取れていない行は必ず「推測」または「未確認」と書く | 運用管理者の作業量・人数を推測のまま計画（03-04）に使い、現実と合わない計画になる（第8.1節） |
| 人数の目安をどう書くか | 人数は後の費用・運用体制の判断に効くが、この段階で正確な数は取れないことが多い | 可（「架空の仮定」「未確認」と明記して仮置きする） | 仮の人数が確定値として一人歩きし、01-04の費用比較の根拠にされる |
| 追加で誰に何を聞くか | 聞き取れなかった役割・人数・兼務は、放置すると要件定義まで空欄のまま進む | 可（確認先の候補を書いておけば、実施は02-01の前でよい） | 運用管理者の困り事が要件に入らず、運用が始まってから機能不足が分かる |
勝手に決めてはいけないこと：聞き取りメモにない困り事を、この記事で新しく作りません。聞き手の推測を、聞き取り済みの事実であるかのように書きません。
AIに任せる範囲：聞き取りメモを役割ごとの表に整理する下書き、聞き漏らしやすい観点（兼務、人数、運用担当）の候補出しはAIに任せられます。しかし、誰をどの役割に置くか、どの行が聞き取り済みでどの行が推測かの判断は、実際に聞き取った人が行います。AIは聞き取りの場にいません。
5. 作って確かめる：利用者・関係者の整理表を作る
5.1 準備
みらい業務サービスの架空の聞き取りメモを用意します（記事Aの聞取りメモと同じ設定です）。
総務課長：依頼の進捗が見えない。承認したつもりが記録に残っていなくて、あとで「承認されてないですよ」と言われた。承認を簡単にしたい。
総務担当：依頼がメールとチャットにばらばらに来る。誰が今の担当か分からず、同じ依頼に2人で対応したことがある。急ぎかどうかも本文を読まないと分からない。
5.2 利用者・関係者の整理表
| 役割 | 人数の目安 | 実際の作業 | 困り事 | 確認済み／推測 |
|---|---|---|---|---|
| 依頼者 | 架空の仮定：数名〜十数名程度 | 会議室の予約や備品の発注など、依頼をメールやチャットで送る | 依頼がメールとチャットに分かれ、誰が今の担当か分からない（総務担当の発言） | 聞き取り済み（総務担当より） |
| 承認者 | 架空の仮定：総務課長を含む数名 | 依頼の内容を確認し、承認する | 承認したつもりが記録に残っておらず、後で「承認されていない」と言われる（総務課長の発言） | 聞き取り済み（総務課長より） |
| 運用管理者 | 未確認（03-01では教材上の仮定として1名としている） | 利用者・役割・担当割当の管理、運用記録の確認（記事Aの役割定義） | 未確認 | 推測（記事Aの役割定義から、実際の困り事は未聞取り） |
5.3 未確認事項の一覧
| 未確認事項 | 確認先の候補 |
|---|---|
| 運用管理者の実際の人数・作業内容・困り事 | 運用管理者本人への追加の聞き取り |
| 依頼者・承認者の正確な人数 | 総務部門の名簿等（この記事では架空の仮定のまま） |
| 依頼者の中に、複数の役割を兼ねる人がどれだけいるか | 追加の聞き取り |
| 「急ぎかどうかも本文を読まないと分からない」（総務担当の発言）が、依頼の項目として必要かどうか | 総務担当・総務課長への追加の聞き取り（この記事では困り事として記録するにとどめ、項目の要否は記事AのQ表で扱う） |
6. 確認結果
第5.2〜5.3節の内容を、完了条件と照合します。
残る制限：この整理表は架空の聞き取りメモに基づく一例です。運用管理者については実際の聞き取りができておらず、記事Aの役割定義からの推測にとどまっています。この記事の本文と記入例はClaude Codeが作成したもので、業務担当者による内容確認は行っていません。
7. よくある勘違いと直し方
- 聞き取れなかった役割を、聞き取れた役割と同じ確からしさで書いてしまう：運用管理者の行を「聞き取り済み」にしてしまうと、実際には確認していない情報を確認済みと誤解させます。「推測」と明記します（第5.2節）。
- 困り事をそのまま機能要件だと思ってしまう：「承認を簡単にしたい」という困り事は、そのままでは要件になりません。記事AでM-2として分解し、REQ-001〜005のような確認可能な条件にします。
8. 設計を判断する
8.1 推測のまま進める場合の危険
この記事の時点では、運用管理者への聞き取りができていないため、後工程（03-01・03-04）では「教材上の仮定」として扱われています。実際の業務でこの記事を使う場合は、推測のまま次工程へ進めず、追加の聞き取りを行うことが望まれます。
8.2 適用限界
この整理表は、架空企業「みらい業務サービス」の一部（総務課長・総務担当の2人）への聞き取りに基づく一例です。実際の業務では、より多くの利用者・関係者への聞き取りが必要になることがあります。
9. 持ち帰る成果物
| 成果物 | 空欄版 | 記入例 |
|---|---|---|
| 利用者・関係者の整理表ひな形（役割、人数の目安、作業、困り事、確認済み／推測） | templates/01-01-stakeholders_template.md | templates/01-01-stakeholders_example.md |
自分の業務に使うときの手順は次のとおりです。
- 業務に関わる人たちに、実際に聞き取りを行う
- 聞き取った内容を、役割ごとに実際の作業・困り事に整理する
- 聞き取れた情報と推測を区別する
- 追加で確認すべき事項を一覧にする
10. 次工程への受渡し
次へ渡すもの：利用者・関係者の整理表、未確認事項の一覧。
次工程での使われ方：01-02（現状の流れと困り事を整理する）では、この整理表の役割を業務フローの登場人物として使い、「困り事」欄の発言を課題一覧の「現象」にします。
前工程へ戻る条件：この整理表が00-04の役割表（人が判断する項目）と食い違う場合は、00-04に戻って確認します。
11. 根拠と更新情報
- この記事の会社・人物・聞き取り内容はすべて架空の設定です。
- 聞き取りメモ（総務課長・総務担当の発言）は、記事Aの記入例で使われている設定と同一のものを使用しています。
- 依頼者・承認者・運用管理者という3役割、および運用管理者の役割定義（利用者・役割・担当割当の管理、運用記録の確認）は、記事Aおよび教材設計書
AI_SYSTEM_DEV_BLUEPRINT_v0.1.md第5.2節に基づきます。 - 制作の来歴：本文・ひな形・記入例はClaude Codeが作成しました。人（ユーザー）による実読・内容確認は未実施です。
- 2026-09-20（Phase 5B-2A）：読む順路（3つの深さ）、第4節の判断項目（判断すること・仮置き可否・間違えた場合の影響・AIに任せる範囲）、記事間の参照を追加した。聞き取りメモにあった「急ぎかどうか」の発言を第5.3節の未確認事項に加えた。整理表・完了条件は変えていない。
- 未確認事項：運用管理者への聞き取りは行っておらず、実際の作業・人数・困り事は未確認のままです（第5.3節）。