1. はじめに
こんにちは、権限管理基盤チームで PdM をしている sentokun と申します。 私は基盤チームの立場でよくプロダクトチームから権限設計に関する相談を受けるのですが、実際にやっている内容に立ち返ると、それは業務フローとユーザーストーリーの整理に通じると感じています。
この記事では、権限設計という複雑そうなタスクの「よくあるパターン」を通して、業務フローとユーザーストーリーの重要性について共有します。
TL;DR
権限設計を考える際には、以下の2ステップが必要です。
- 業務フローとユーザーストーリーを整理する（2章）
- 「誰が、どんな立場で、何をするか」を具体化する
- 3つの深掘りポイントで解像度を上げる（3章）
- 立場・条件・データの境界を明確にする
とはいえ、何から手をつけたらいいかわからない！という方は、4つのきっかけから深掘りをしてみてください（4章）。
2. 目指すゴールは「業務フロー」と「ユーザーストーリー」
権限を設計するために、私たちが最初に目指すゴール。それは、きれいに書かれた権限の仕様書ではなく、具体的な「業務フロー」と「ユーザーストーリー」です。
なぜなら、権限というものは「その業務は誰が、どんな役割で行うことができるか」と切っても切り離せないからです。そのため、権限設計の相談をいただく際、まずは業務フローやユーザーストーリーの把握に努めています。
要は、「誰が、どんな立場でその業務を行うか？」 を徹底的に理解することが重要となります。
具体イメージ
例として、「freee会計ユーザーと税理士が契約を結び、freee 上で代行業務を行う」流れをまとめた概要図を貼ります。企業と税理士の関係や、代行業務が行われるまでにやることを簡単にまとめたものです。
この概要図からは、例えば以下のようなユーザーストーリーが見えてきます。
- 「事業所Aオーナーは、事業所Bに会計つよしを管理者として招待する」
- 「税理士事務所の会計つよしは、事業所Bの会計業務を行う」
ここでは、「権限とは」と難しく考える必要はありません。まずは議論したい内容に対して、このような「簡単な業務フローやユーザーストーリーを用意する」ことが、権限設計の第一歩になります。
ここからさらに、「会計つよしは何の立場で事業所Bの業務を行っているか？」、「どのようなフローによりその立場になれるのか？」や「会計つよしが行える会計業務は具体的には何か？」といった観点で、ユーザーストーリーを具体的にしていきます。
権限ならではの重要ポイント: 「どんな立場で業務を行うか？」「どのような条件により業務が行えるのか？」
ただし、通常の業務整理と「権限を意識した業務整理」で少しだけ違う、重要なポイントがあります。それは、業務のステップごとに「役割（例: 管理者かどうか）」や「条件（例: ユーザーがエンタープライズプランを契約しているか、ある部署に所属しているかなど）」を強く意識することです。
「ユーザーが画面のボタンを押す」という一つの動作に対して、そのボタンは誰が押してはいけないのか？どのプランに契約していないといけないのか？といった、権限に必要な観点までもう一歩だけ深掘りをしてみることが肝となります。具体的なプロセスは、3章で紹介します。
このゴールがあれば、後は「基盤の提供機能」を当てはめるだけ
「業務フローなんて言われても、やっぱり自分だけで合っているか不安……」と思う方もいるかもしれません。
でも、安心してください。ユーザー業務に詳しいみなさんが業務フローやストーリーを「要は、誰がどんな立場でやりたいんだっけ？」というレベルで整理してくれれば、権限設計における要件定義のフェーズとしては、8割完了です！
そこから先、どのようにロールやプランによる制御を反映するかといった方法は大抵プロダクトのアーキテクチャにより決まってくるでしょう。freee の場合は権限管理基盤の機能に適用する形となります。
3. ゴールへ向かうための「3つの深掘りポイント」
業務フローやユーザーストーリーに対して、権限設計に必要な観点を取り入れるための 3 つの深掘りポイントを紹介します。
【Point 1】 「誰が、どんな立場で」その業務を行うかを整理する
まずは「誰が使うか」を深掘りし、人に付随する変数を洗い出します。
権限の相談でよくあるのが、「ユーザー」という主語が大きすぎて、誰のどんな動きを指しているのか見えなくなるケースです。「一般ユーザー」や「アドバイザー管理者」など、業務上の役割を一歩具体化します。
- Bad: 「ユーザーが申請ボタンを押す」
- Good: 「経費精算を行いたい所員が、作成した経費申請を申請する」など
| 深掘りポイント | よくある「問い」 |
|---|---|
| 業務を行うユーザーを具体化し、その役割が何であるか？を問う | ・「その操作は誰でもできていいのですか？／できてはいけない人はいますか？（管理者だけ、など事業所内での立ち位置の制限はある？）」 |
【Point 2】 「その業務は、どんな条件で許可されるか」を突き詰める
「画面がこうなっているから」「コードがそうなっているから」という既存の How や今のオペレーションに引っ張られず、業務が成立する「前提条件（所属やアクセス対象の変数）」を紐解きます。この観点は権限設計の中でかなり重要なのですが、実は最も漏れがちです。
- Bad: 「一括経費申請を行う」
- Good: 「部署の所属社員として、自身の経費をまとめてその部署に申請する」、「経費の承認を行える権限を持った立場として、自身が承認依頼された経費申請をまとめて承認する」など
| 深掘りポイント | よくある「問い」 |
|---|---|
| 業務フローの各行動ひとつひとつに対する立場を意識する。業務上の役割が混ざっていないかを把握する | ・「その業務は、どのような条件が揃ったら行ってよい（許可される）ものですか？」 ・複数の事業所をまたぐユーザーの場合、「今『どの事業所の人間』としてその業務を行っていますか？」 |
【Point 3】 業務で満たすべき「利便性」と「安全性」のラインを見極める
ユーザー体験を考える際、ユーザー操作を減らしたいと考えるのは自然な流れです。ただ、一方で利便性を突き詰めすぎると「誰でもなんでもできる」が正義になってしまい、見せたくないデータの境界がなくなってしまいます。 逆に、安全性ばかりを追求すると「毎回アクセスしていいか確認する」といったユーザーの手間が増えてしまいます。
業務上押さえるべき「操作を減らしたい」という利便性のラインと、「見せたくない境界を守る」という安全性のラインを担保した状態で、業務フローを作る必要があります。そのため、既存の構造にとらわれずユーザーの行動特性とデータの制約（実態）を検証することが大事です。
- Bad: 「ユーザーはまとめて操作したいので、一画面に収める」
- Good: 「管理者は、自分が承認する経費申請を承認対象の申請一覧で確認できる。（自分自身が作成した経費申請は別で見られる）」
| 深掘りポイント | よくある「問い」 |
|---|---|
| 安全性のラインとして業務の境界を、利便性のラインとしてユーザーの立場に合わせた想定される行動を把握する | ・「その役割の人が、『見せたくない（アクセスさせたくない）』データの境界線はどこにありますか？」 ・「ユーザーは、どのような立場で作業中にクイックにその画面を参照したいですか？」 |
4. 4 つの「きっかけ」から見るゴールに近づくための深掘り方法
3章では、権限設計に必要な深掘り観点を紹介しました。しかし、相談に来るタイミングや持ち込まれる話のスタート地点は、プロダクトやフェーズによって様々です。
そこで、この章では、その観点を相談したい内容に合わせてどう使うかを整理します。よくある 4 つの「きっかけ（相談内容）」に応じた深掘りアプローチを解説します。
どのスタート地点から始まっても、最終的にはこれまで記載した目指すゴールである「業務フロー」と「ユーザーストーリー」を明らかにしておくことが、権限を整理する上では重要です。
特に、どのケースでも共通して意識したいのは、以下の2点です。
- 登場人物、役割、業務の境界をあいまいなままにしない
- 業務があいまいなまま、技術的な How（ソリューション）の話に終始しない
【きっかけ1】 解決したい業務がある
ユーザーの「業務フロー」や「やりたいこと」から会話がスタートするパターンです。
- よくあること
- 条件や制約（有料プランによる制限など）があいまいになる。
- 複数のユーザーのストーリーが1つに混ざってしまう。
- お客様の強い要望（will）がそのまま How の形で反映され、本来あるべき業務要件を超えた過剰な仕様になる。
- 深掘りアプローチ
- 3章の「3つの深掘りポイント」をそのまま適用し、一連のフローの中にどんな制限や立場が隠れているかを炙り出していきましょう。
【きっかけ2】提供したい機能がある
「一括申請ができる機能を作りたい！」といった、システム上の機能起点から会話がスタートするパターンです。
プロダクトに慣れている方々は、機能トリガーで考え始めることも多いのではないでしょうか？
- よくあること
- 登場人物や役割、業務のユーザーストーリーがあいまいになる。
- 「この画面のこのボタン」といった、技術的な How から話し始めてしまう。
- 深掘りアプローチ
- まずは、その機能を通じて「本当にやりたいユーザー業務」をユーザーの行動で分解します。そこから登場人物を引き出し、それぞれのユーザーストーリーに落とし込みます。登場人物が複数出てきた場合は、それぞれの業務目的が異なるはずなので、別々に整理していきます。
| よくある「問い」 | 深掘りイメージ |
|---|---|
| 「その機能って、具体的にユーザーが何をする（どんな動詞の）機能ですか？」 | 登場人物とその行動を具体化し、その業務がイメージできるようにしていく。 |
【きっかけ3】 解決したい課題がある
「〇〇という問題が発生している」「ユーザーから不満が出ている」といった、発生した課題から会話がスタートするパターンです。
- よくあること
- 「どうやって課題を解決するか（解決策）」の議論をいきなり始めてしまう
- 課題の裏側にある、ユーザーの本来のストーリーや業務フロー全体が明らかにならない
- 深掘りアプローチ
- 解決策を考える前に、まずは「その課題の要因となっている元の業務は何か？」を特定しにいきます。課題が起きているピンポイントの瞬間だけでなく、その前後に誰がどんな立場で関わっているかを把握します。
| よくある「問い」 | 深掘りイメージ |
|---|---|
| 「その課題は、具体的に誰が、何の業務をやろうとしている時に起きていますか？」 | 課題の発生源となっている「業務」を特定し、そこに対して3章のPoint 1（誰がどんな立場で）やPoint 3（安全性と利便性のバランス）を当てはめて、課題の本質的な原因を紐解いていきます。 |
【きっかけ4】 解決したい技術的構造がある
「今のコードやDB構造がこうなっているから、ここを直したい」「プロダクト事情に合わせた特殊な権限制御がしたい」といった、技術的構造やシステム都合から会話がスタートするパターンです。
- よくあること
- 実装の How（どう作るか、どう直すか）の話に終始する。
- その前段にある「結局、ユーザーのどんな課題を解決したいんだっけ？」という目的が見えなくなりがち。
- 深掘りアプローチ
- 技術的な How を一度横に置き、「その構造が変わることで、どのユーザーの、どの業務がどう変わるのか（あるいは変わらないのか）」を言語化します。
| よくある「問い」 | 深掘りイメージ |
|---|---|
| 「その技術的な変更は、どのような業務課題を解決しようとしていますか？」 「その技術的な変更は、どのようなユーザーの業務で利用されますか？」 |
技術の変更目的をユーザー業務の言葉に翻訳し、構造上の変更が「3章の3つのポイント（立場・条件・データの境界）」に正しくマッピングできているかを検証します。 |
5. まとめ：権限設計の肝=「どこまで業務を具体化するか」を取り込むこと
ここまで解説した通り、権限設計に必要なのは、「必要な観点で業務を具体化すること」。今回紹介した以下の観点を業務整理に組み込めば、権限設計はほぼ完了します。
- 「どんな立場で業務を行うか？」
- 「どのような条件により業務が行えるのか？」
- 「見せたくないデータの壁はどこか？」
必要なのはこの観点を知ることです。ぜひ普段の業務整理で試してみてください。
参考情報
私が考え方に影響を受けた書籍を紹介します。
- 解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の４視点と行動法 (スライド)
- ユーザーストーリーを考える際に事象を捉える視点が得られる
- 問いのデザイン (作者Note)
- 業務を深掘りする「問い」を学ぶ
私が PdM に成り立ての頃は、先輩からの「この主語は誰？」「なにができるようになるの？」「これができないとなにが困るの？」と言った問いの深掘りで鍛えられました。
