システムに何をしてほしい？通常と例外を一つの仕事で伝える方法

ユースケースは、使う人とシステムのやり取りを説明する

ユースケースは、一つの目的のために、誰がシステムへ何を伝え、システムがどう応じ、使う人にどんな結果が分かるかを説明するものです。この例では「社員が備品の貸出を一件申請し、受付状況や次の確認先を知る」という単位で考えます。「備品管理」という大きな名前だけで、購入、申請、貸出、返却、点検まで一度に混ぜません。

使う人の役割

ここでは「借りる社員」です。人の氏名や部署名の一覧ではなく、その場面で何をする立場かを示します。同じ人でも、借りるときと貸出担当として確認するときでは役割が変わります。

対象のシステム

ここでは「貸出申請システム」です。システムの外で行う実物の確認や、担当者同士の相談まで、すべて自動で行う機能として数えないために範囲を置きます。

使う人に分かる結果

申請を受け付けたことや、その日に貸せない条件と次の相談先など、操作した人が確認できる結果の案です。受付表示を見たことと、実物を確保して貸出を終えたことは区別します。

標準化団体OMGが公開するUML（システムの構造や動きを図などで表すための記法）の仕様は、対象システムの振る舞いと、外部の役割とのやり取り、そこから得られる結果を扱い、通常の動きに加えて変形や例外も記述できるとしています。本稿はこの考え方を、業務担当が読める普通の文章と架空例へ応用しています。UMLの原仕様の第16章で、役割とユースケースの説明を読む

業務フロー・画面一覧・ユーザーストーリーとの違い

業務フローは、複数の担当や仕事を含む全体の道順を説明するのに向きます。一方、このユースケースは、その道順の一部である「社員が貸出申請システムを使う場面」を詳しく見ます。全体の受け渡しから分からない場合は、業務フローで仕事の道順を整理する方法を先に確認すると、今回切り出す仕事を選びやすくなります。

画面一覧は、必要な画面の候補を並べるものです。「申請画面がある」だけでは、受付後に誰が何を確認するか、希望が重なると何を返すかまでは分かりません。ここでは画面名より先に、目的とやり取りを書きます。

ユーザーストーリーは、誰が何を何のためにしたいかを短く共有する表現です。例えば「社員が、会議で使う備品の貸出を申し込みたい」という目的を入口にできますが、短い文だけでは条件や例外の詳細が足りないことがあります。GOV.UKも、利用者・必要なこと・目的と、仕事を果たしたと確かめる条件を扱っています。これは英国政府サービスの指針であり、国内企業に同じ様式や手法を義務付けるものではありません。利用者の目的と確認条件をつなぐ考え方を原典で読む

貸出申請の一件に、始まりと終わりを置く

最初に選ぶのは、書類の種類ではなく、利用者が達成したい一つの仕事です。「備品を管理する」では広すぎるため、この例では「会議用の備品が必要になった社員が、希望する備品と利用日を伝える」ところから始めます。

終わりは、申請した社員が受付状況と次の確認先を知るところまでの案とします。実物の受け渡しや返却までを説明したいなら、その後の仕事として分けて担当へ聞きます。申請を受け付けた時点で、備品の確保、貸出承認、受け渡し完了まで成立したことにはしません。

きっかけと、始める前の条件を分ける

きっかけは「会議用の備品が必要になった」という、この一件を始める出来事です。始める前の条件は、貸出対象となる人や備品、使える申請方法などです。この架空例では、社内の貸出対象と申請方法をまだ確認していません。社員なら全員使える、すべての備品を借りられる、必ず特定の認証方法を使う、といった条件を作者の判断で決めません。

前提が分からないときは、「この備品を申し込める人は誰ですか」「今はどの経路で受け付けていますか」「開始前に担当者へ相談する条件はありますか」と尋ねます。条件が決まるまでは、一般的な会社の仕組みをそのまま自社のルールに写さないようにします。

社員・システム・貸出担当の仕事を分ける

説明の主語をそろえると、自動で行うつもりの仕事と、人が確かめる仕事の混同を減らせます。「確認する」「処理する」とだけ書かず、誰が何を見て、相手に何を返すかまで続けて書きます。

社員の仕事は、希望する備品と利用日を伝え、返ってきた案内を読むことです。システムの仕事としては、申請を受け付けたことや、貸出できない場合の理由と相談先を表示する案を置きます。貸出担当者の仕事としては、実物と日程、あるいは代替日や別備品を確認する案を置きます。いずれも、この架空例では担当者に確認済みの仕様ではありません。

ここで「システムが在庫を自動照合し、貸出を確定する」と付け足すと、元の案より仕事が増えます。実際の在庫の管理場所や更新方法、重複の判断方法が未確認のため、誰がどの資料を見て貸出可否を判断するかを先に尋ねます。表示の裏で必要な情報がそろっているとは限りません。

自動にしたい作業は、実現方法と一緒に相談する

自動で候補を示したいという希望が出たら、その希望と、現在分かっている業務条件を分けて残します。例えば、代替日や別備品をシステムが案内するには、候補を選べる規則や元の情報が必要です。元の案は人が確認する想定なので、自動提示できると決めず、業務担当と開発担当へ可否と必要条件を聞きます。

利用者から見える動きを説明する段階では、データベースの構造やプログラムの細かい処理順まで自社で作り込む必要はありません。ただし、別システムの情報が必要なら、何の情報を誰が持ち、誰へ接続条件を確認するかを残します。外部連携の実現性は別に確かめます。

通常時は、人の入力とシステムの返答を順に書く

まずは、目的に向かって進められる一つの条件を書きます。この例の「通常」は、実際に一番多いと測定した意味ではありません。希望日に貸出できる条件を仮に置き、やり取りを説明する入口としています。

1. 社員が何をしたいかを書く。会議用の備品が必要になり、貸出を一件申請したいという場面です。
2. 社員が渡す情報を書く。希望する備品と利用日を伝える想定です。日付の入力形式や、ほかに必要な項目は、これから確認することです。
3. システムの返答を書く。申請を受け付けたことを表示する案です。表示する正確な文言や、その時点で記録される情報は未確認です。
4. 人が続ける確認を書く。貸出担当者が実物と日程を確かめる案です。誰が担当し、何をもとに判断するかも確認します。
5. 利用者に分かる結果を書く。社員が受付状況と次の確認先を知る案です。貸出の確定や実物の受け取りと混ぜません。

これは、画面をそのまま再現した操作手順ではありません。「どのボタンを押すか」がまだ決まらなくても、社員が何を渡し、どういう案内を必要とするかは相談できます。画面が決まった後には、同じ場面を実際の操作へ結び付けます。

受付後の状態が曖昧なら、「申請を受け付けた後、社員は待つのか、担当者へ連絡するのか」「確認中に何を見れば状況が分かるのか」を尋ねます。担当者へ連絡する案を置いただけで、その連絡先や応答方法まで決まったことにはしません。

曖昧な依頼文を、やり取りが分かる説明へ直す

「貸出申請をできるようにしたい」だけでは、入力する内容も、操作後に何が分かればよいかも読み取れません。同じ一件を、例えば次のような説明の案へ書き直します。

書き直した文では、「社員が入力する」「システムが返す」「人が続けて確かめる」を別の主語にしています。これなら、開発担当はどの動きをシステムに求める案か、業務担当はどの確認が人の仕事として残る案かを読めます。受付したという案内を、貸出を確定したという案内へ読み替える余地も減らせます。

ただし、この文章は相談するための案です。実際の受付文言、担当者、在庫の判断方法が決まるまでは、表示画面や確定した仕様として使いません。「申請画面を作る」という依頼へ戻すのではなく、どの文の条件や担当が未回答かを示して話し合います。

貸せないときは、条件・案内・次の相談を足す

通常の説明ができたら、進め方が変わる条件を同じ場面へ戻して考えます。この例では、同じ備品の利用希望が重なり、貸出できない条件に当たる場合を置きます。重複判定の方法や、貸出不可を決める実際の規則は未確認です。

別条件を書くときは、「何が分かったら分かれるか」「どのやり取りが変わるか」「相手へ何を返すか」「その後は終えるのか、相談するのか」を示します。単に「エラー」と書いて終えると、借りられない理由や、次にできることが読者にも開発担当にも分かりません。

原寸の解説図を見る

貸出不可は、システム故障とは限らない

希望が重なって貸せない場合と、入力が足りない場合、システム自体が使えない場合では、必要な案内が変わります。この図が扱うのは、貸出できない条件に当たる場合の案です。ほかの条件まで、同じ理由や同じ戻り先だと決めません。

入力不足については、何が不足し、社員がどこを直せば申請を続けられるかを尋ねます。途中で通信が途切れた場合については、受け付け済みかをどう確かめ、同じ申請の重複をどう避けるかが質問になります。ここでは、保存や再送の仕様が確認済みだとはしていません。

分岐が多いときは、条件をまとめてから詳しくする

似た条件で同じ案内になる場合は、担当者へ同じ扱いでよいかを確かめてまとめます。理由や担当、利用者が次にすることが違うなら分けます。すべての細かい違いを最初から別の大きな図にせず、まず対象の一件で実際に確認すべき条件を選びましょう。

たとえば予約済みの申請を変更する仕事が必要なら、新規の申請と同じ流れへ黙って混ぜません。どの申請が既に存在し、何を変え、元の申請がどうなるかを別に確認します。この架空例でも、予約済み申請の扱いは未確認です。

二つの架空条件を、同じ項目で読み比べる

通常の希望では受付状況を案内し、貸せない条件では理由と相談先を案内する構想です。システムが返す言葉と、人が次に確かめる仕事を同じ項目で比べます。受付は貸出確定ではなく、実際の申請方法・判定規則・担当者は確認が必要です。

下の例は、本文と図に使った二条件の元の内容です。文章を短くするときにも、誰が何を入力し、システムと人が何を行う案か、どこが未確認かを落とさないよう、同じ項目で並べています。自社の確認済み仕様へそのまま写すための例ではありません。

両方とも、担当者への確認済みとはしていません。この状態は「その日に貸せない」「申請が失敗した」という貸出可否の値ではありません。また、未確認事項が残ることは、その規則や担当者が存在しない証明でもありません。回答を得た箇所だけを、根拠と一緒に更新します。

二条件で変わるのは、始まるきっかけや前提、条件に応じた案内、人が確認する内容、利用者に分かる結果です。入力はどちらも希望する備品と利用日です。二つ目を一つ目の改善後や、システム化によって成功した結果として読み替えないでください。

未確認をルールへ変えず、回答できる人へ確かめる

分からないことは、次に何を尋ねるかへ変えます。空欄を一般的な仕様で埋めるより、どの仕事の判断に影響し、誰の回答が必要かを示す方が、開発担当にも相談しやすくなります。確認相手がまだ分からないときは、その担当を社内の責任者へ尋ねます。

実際の在庫照合方法

「備品が使えることを、いまはどの資料や現物で確認していますか。誰が、どの時点で更新していますか」と貸出業務を知る人へ尋ねます。管理表があるという情報だけで、システムがいつでも正しい在庫を取得できるとはしません。

受付表示の文言

「申請を受け付けた表示を見た社員は、何が決まり、何が確認中だと理解すべきですか」と尋ねます。貸出確定だと誤解しない説明を、実際の運用に合わせて検討します。

担当者と決定権限

「受付を確認する人、貸出可否を判断する人、例外の扱いを決める人は誰ですか」と役割を分けて尋ねます。担当者を一人書いたことで、すべての判断を任せたことにはしません。

貸出不可を決める条件

「同じ備品の希望が重なった場合、何を見てどの申請をどう扱いますか」と尋ねます。先着、役職、利用目的など、元の例にない優先規則を決めつけません。

代替候補の提示可否

「代替日や別備品は、誰が何を確かめて案内できますか。システムから候補を示してよい条件はありますか」と尋ねます。人の提案と自動提示の可否を分けます。

予約済み申請の扱い

「既に受け付けた申請を変更・取消するとき、誰へ伝え、元の申請をどう残しますか」と尋ねます。新しい申請が来たという理由だけで、以前の申請を消す仕様にしません。

その場で回答が得られなければ、何を誰へ確認し、どの説明を保留するかを残します。判断者や回答予定も、実際に相談して決まったことだけを書きます。未回答のまま開発会社へ渡す必要がある場合は、確定した仕様と並べず、調査や提案を依頼したい範囲として明示します。

回答を受けたら、人の確認と自動化の希望をこう書き分ける

質問への回答は、単に「確認済み」に変えるためのものではありません。次のように、回答の中身によって本文の主語と範囲を直します。以下は回答を得た後の書き換え方の例であり、この架空の会社で回答が得られた事実を示すものではありません。

人が現物と管理表を確かめる運用だと分かったとき

例えば「貸出担当者が現物と管理表を照合する」と人の確認を具体化し、システムの役割は申請の受付や案内と区別します。受付後に社員が何を待つのか、どこへ確認するのかも、その運用に合わせて説明します。管理表があることだけを理由に、自動照合する機能を加えません。

別システムの情報から自動判定したいという希望が出たとき

「自動で判定する」は、まず新しく検討する希望として分けます。開発担当へ、どの情報を読み、いつ更新され、利用できないときにどう案内するかを相談します。連携できると分かる前に、人の確認を説明から消すと、受付後の仕事が抜けてしまいます。

誰が何を見て判断するか、まだ決まらないとき

申請を受け付ける案と、貸出可否の判断を分けたままにします。判断方法が決まるまで「受付＝貸出確定」と書かず、決める必要がある条件を残します。社内で決める規則と、開発会社へ実現方法を尋ねる部分を分ければ、相手に求める回答も明確になります。

回答によって役割や条件を変えたら、通常の説明だけでなく、貸せない場合の案内、図、利用者に分かる結果にも同じ変更を反映します。例えば自動判定を検討しただけの段階なら、図の「人が確認する」を完了済みの自動処理へ置き換えず、検討中の内容を文章で区別します。

担当者と一件をたどり、足りない分岐と結果を見つける

書いた説明は、業務を知る人と開発担当が同じ一件を追えるかで確かめます。本文を送っただけで確認済みにせず、何が合い、何が違い、どの質問が残ったかを残しましょう。実際の仕事が分からない段階では、利用者ヒアリングで具体的な仕事を聞く手順へ戻ることも必要です。

1. 社員の立場で、始まりを読む。なぜ申請するのか、何を用意して何を渡すかが分かるかを確かめます。
2. システムの返答を読む。入力の後に何が分かり、次に自分が何をするかを説明できるかを確かめます。
3. 貸出担当者の立場で、確認を読む。何をもとに、誰が判断するかが未確認のまま隠れていないかを見ます。
4. 貸せない条件へ進めてみる。分かれる条件、返す理由、相談先や続け方が足りているかを見ます。
5. 案と確認済みを区別する。誰のどの回答に基づいて直したか、まだ採用を決めていない内容は何かを残します。

この読み合わせは、実装されたシステムの動作試験ではありません。画面や保存結果が動くと確認した証拠にもなりません。いま確かめるのは、業務と要求の説明が、関係者にとって矛盾なく読めるかという点です。

意見が食い違うときは、条件の違いへ戻る

同じ備品の貸出でも、利用日や備品の種類、申請時点で扱いが変わる場合があります。どちらかの説明をすぐ誤りとせず、どの条件を話しているかをそろえます。実際のルールが決まっていないなら、決める権限を持つ人へ、選択肢と影響を相談します。

回答を受けたら、変わった一文だけでなく、その条件を使う通常・例外の説明、図、利用者に分かる結果を同じ内容へ直します。文だけを変えて図を古いまま残すと、開発担当が別の仕様を読むおそれがあります。変更理由と確認した人、確認日も同じ版へ結び付けます。

同じ場面を、提案依頼と受入条件へつなぐ

一件の説明がそろったら、開発会社へ何を求めるかにつなげます。目的、役割、通常と例外、残る質問を合わせて渡すと、画面名だけの依頼よりも、提案の前提を共有しやすくなります。ただし、説明を書いたことで、費用や日程、仕様や契約が確定するわけではありません。

提案依頼には、今回作りたい範囲と未決定を添える

貸出申請の例なら、申請と受付状況の案内をどこまでシステムで行う案か、人の確認として残す仕事は何か、在庫照合や代替候補の提示にどんな未確認があるかを示します。調査を手伝ってほしい部分と、決まった条件に対して実現方法を提案してほしい部分も分けます。

依頼書全体の目的、運用、費用、日程や各社の比較条件は、システム開発のRFP（提案依頼書）の作り方で確認できます。誰と資料を整え、質問へどう答え、社内でどう判断するかは、開発の発注準備の進め方へつなぎます。本稿の一件の説明だけで、発注準備の全体を済ませたことにはしません。

受入条件では、合意した入力と結果を試せる形にする

受入条件は、できたシステムが求める動きを満たしたかを確かめる条件です。ここで書いた場面を入口に、使う役割、入力する備品と利用日、条件ごとに表示される案内、残る人の確認を、後で試せる形へ詳しくします。実際のテストに使う値、表示文言や判定規則は、未確認のまま固定しません。

通常条件だけでなく、貸出できない条件でも、何が示され、利用者が何をできるかを確かめます。入力エラー、権限、変更・取消などの条件が必要と分かったら、今回作る範囲と一緒に合意します。操作と期待結果から受入条件を決める方法では、別の架空の注文例で考え方を詳しく説明しています。そちらの数量や業務規則を貸出の条件へ移すものではありません。

開発会社の提案で、システムと人の担当範囲や案内方法が変わる場合は、元の目的と二条件へ戻って確認します。便利そうな機能を足しただけで採用せず、必要な情報や運用、費用・日程への影響を確かめ、合意した版を更新しましょう。

まとめ：通常と例外の一件を、担当者に見せて確かめる

ユースケースを書く出発点は、誰のどの目的を、どこからどこまで扱うかを選ぶことです。人が渡す情報、システムが返す案内、人が続ける確認、利用者に分かる結果を順に説明し、条件が変わったときの別の進み方を足します。

この架空例では、申請受付と貸出完了を分け、通常の希望と貸出できない場合を並べました。在庫照合、表示の文言、担当と権限、貸出不可の条件、代替候補、予約済み申請の扱いは未確認です。分からない点を仕様に見せず、回答できる人へ質問し、得られた回答を文と図へそろえて反映します。