現状分析→価値開発→仕様化＆テスト設計の展開事例解説：仕様＆テスト編

現状分析→価値開発→仕様化＆テスト設計の展開事例解説仕様＆テスト編 1 みずのり（みずののりゆき）＠TOC/TOCfE北海道 RDRA MeetUp、TEF道など（ペーパー）プロトタイピングな仕様化とテストの具体例紹介

自己紹介 2 好きなもの：汎用的スキル（テストや論理思考、TOC）、趣味：テスト中心のモデリング研究発表や公開している内容は以下。※過去6年程度のみ RDRA関連（神崎さんとの勉強会から実践で学んだもの）・RDRA+プロトタイピングおよび仕様化時に役立つ技術、事例紹介・伝統的食品工場エンジニアリング会社が挑むDXへのビジネスアイデアを RDRAによる要件定義でプロダクト開発へつなぐ～Side：要件定義（DevSumi関西2020）・今回の発表ネタ、長いタイトルなので省略（JaSST’21東京チュートリアル）
TOC（制約理論：Theory of Constraints）関連（安達さんとワークショップ作成）・SaPIDTOC～未来予想型チーム運営ワークショップ（JaSST’18東京チュートリアル実施）・プロジェクトマネジメントの概要とCCPMによる工期短縮の仕組み・提案を検証する技術（TOC マフィアオファー（URO）活用技術）・SQiP2014：CCPMの考え方を活用したテストフェーズにおける課題解決～課題発見、解決までのケーススタディ～ソフトウェアテスト/テスト自動化関連・（共著）InSTA2019＠西安：Coexistence of test execution efficiency and test ・ET⁻WEST2018：なぜ組込みシステムにおけるテストは難しいのか～ 2つのテストアーキテクチャによってテストを組立てる～・（共著） InSTA2018＠Sweden：Proposal for Enhancing UTP2 with Test Aspects ・（共著） InSTA2017＠東京：Test Conglomeration - Proposal for Test Design Notation like Class Diagram ・JaSST’17関西：納得できるテストをつくるアプローチ・STAC2015：自動家は見た～自動化の現場の真実～・テストカタマリーの紹介/活用したテスト設計プロセス案

全体の流れを再確認 3 そして新図書館システムへ既存図書館システム ASISシステム可視化 ①RDRA 【神崎】 TOBEシステム可視化 ③RDRA 【神崎】
TOBEシステム ④仕様化with Test 【水野】 ② SaPID 【安達】 TOBE 図書館システムによる運営の効果と価値の可視化 ASIS 図書館システムによる運営の効果と価値の可視化イマココ

全体の流れ：RDRAから仕様化へ 4 今回の仕様化については、図書館システムにおける「会員登録」に絞って具体例を交えて紹介を行います。 ※RDRAがあることで対象を絞り込んで計画がやりやすくなります窓口会員期限管理会員登録 [会員管理：業務] 窓口
会員返却窓口貸出書架図書館員蔵書 [貸出・返却：業務] [蔵書管理：業務] 会員棚卸書籍補充書籍店蔵書司書 [窓口貸出：BUC] 蔵書を貸出す書架から本を探す蔵書の貸出を登録する会員貸出登録蔵書貸出図書図書館員貸出制限会員登録会員カードを作成する図書館員会員IDを発行する会員 [会員登録：BUC] 貸出図書を返却する返却図書を書架に返す貸出図書の返却を登録する会員返却登録貸出図書図書館員貸出予約蔵書 [返却：BUC] [期限管理：BUC] 貸出期限を確認する日次貸出図書貸出期限切れ通知会員窓口図書館会員貸出・返却書籍店司書蔵書管理書架蔵書会員管理図書館員司書補充リストを作成する書籍の発注を行う司書 [書籍補充：BUC] 書籍発注書籍発注登録蔵書を登録しラベルを張る蔵書を登録する蔵書登録蔵書書籍ラベルココやる

全体の流れ：RDRAから仕様化へ 5 選択理由：次のようなターゲットとなる。・全体に影響のありそうなところ・最初に小さくMVP構築できそうなところ・業務のメイン部分でキッチリ作ったほうがよいところ・多くの方の関心の強いところ窓口会員期限管理
会員登録 [会員管理：業務] 窓口会員返却窓口貸出書架図書館員蔵書 [貸出・返却：業務] [蔵書管理：業務] 会員棚卸書籍補充書籍店蔵書司書 [窓口貸出：BUC] 蔵書を貸出す書架から本を探す蔵書の貸出を登録する会員貸出登録蔵書貸出図書図書館員貸出制限会員登録会員カードを作成する図書館員会員IDを発行する会員 [会員登録：BUC] 貸出図書を返却する返却図書を書架に返す貸出図書の返却を登録する会員返却登録貸出図書図書館員貸出予約蔵書 [返却：BUC] [期限管理：BUC] 貸出期限を確認する日次貸出図書貸出期限切れ通知会員窓口図書館会員貸出・返却書籍店司書蔵書管理書架蔵書会員管理図書館員司書補充リストを作成する書籍の発注を行う司書 [書籍補充：BUC] 書籍発注書籍発注登録蔵書を登録しラベルを張る蔵書を登録する蔵書登録蔵書書籍ラベル上位の分析があると判断しやすい SaPID検討より

全体の流れ：RDRAから仕様化へ 6 窓口会員期限管理会員登録 [会員管理：業務] 窓口会員返却
窓口貸出書架図書館員蔵書 [貸出・返却：業務] [蔵書管理：業務] 会員棚卸書籍補充書籍店蔵書司書 [窓口貸出：BUC] 蔵書を貸出す書架から本を探す蔵書の貸出を登録する会員貸出登録蔵書貸出図書図書館員貸出制限会員登録会員カードを作成する図書館員会員IDを発行する会員 [会員登録：BUC] 貸出図書を返却する返却図書を書架に返す貸出図書の返却を登録する会員返却登録貸出図書図書館員貸出予約蔵書 [返却：BUC] [期限管理：BUC] 貸出期限を確認する日次貸出図書貸出期限切れ通知会員窓口図書館会員貸出・返却書籍店司書蔵書管理書架蔵書会員管理図書館員司書補充リストを作成する書籍の発注を行う司書 [書籍補充：BUC] 書籍発注書籍発注登録蔵書を登録しラベルを張る蔵書を登録する蔵書登録蔵書書籍ラベルこれだけだと作るまでは厳しい今回の仕様化については、図書館システムにおける「会員登録」に絞って具体例を交えて紹介を行います。 ※RDRAがあることで対象を絞り込んで計画がやりやすくなります

仕様づくり（ペーパープロトタイピング仕様化withテスト） 7 紹介するもの：「会員登録」業務に対する仕様化withテスト実際にRDRAを作った後に依頼されてやることの多い実際の仕事相当の内容をリアルに紹介紹介する流れ：・仕様検討における問題～Vol0 ケーススタディより～・今回紹介するもの（仕様化のテンプレートと流れ）
・仕様化検討のケーススタディ（一例） Vol1．ヒアリングのための仮説を作る Vol2．ヒアリング結果から、仕様を完成させる Vol3．仕様に対するテスト設計からフィードバックする・まとめ

仕様検討における問題：Vol0 ケーススタディ 8 仕様Vol0にてありそうな問題を紹介します。 ※SaPIDもRDRAもない状況を考慮したものです。具体例紹介

仕様の例：Vol0 残念なケース 9 メモ：具体例部分には↑にバーを入れてます

仕様テーマ：会員登録の実施 10 Vol0 よくあるインプット（会話の内容込み）：（会話で残される情報）元々会員カードで運用していましたが、カードを忘れる人が多いのでスマホでも貸し出しができるとよいです
あ、AIとかもやりたいですが簡単に行けますかね ※要件定義も大中小で書かれた簡単な表のみ

仕様テーマ：会員登録の実施 11 仕様Vol0（残念な仕様）：＜会員の登録/会員カード発行＞・図書館を使用する（書籍の貸し出しをする）ためには、事前に会員登録をする・会員登録ができること、会員登録の条件は既存の会員条件と同じ・会員カードは新規システムでも発行する、カード発行されると市内の全図書館で使用できる・会員は会員カードを使用することでセルフレジで貸し出しができ、予約情報が記録される・会員カード発行だけではWeb/スマホでは使えないが、貸し出しには使用できる＜Web向け会員ID（Web会員ID）の登録＞
・Web向け会員IDを持つことによってWebでの書籍検索と予約ができる・会員は自分でWeb会員IDを申請して獲得ができること、図書館でもWeb会員IDを申請ができること・会員カードを忘れる人が多いので、スマホでもカード情報を呼び出して貸し出しをすることができることいろいろ突っ込みアリ

仕様テーマ：会員登録の実施 12 残念な仕様の結果… ＜既存の会員対応が後手にまわり不備が発生＞・既存のカード体系を考慮せずに新規カード/システムを作ってしまい、図書館統合に対応できない新旧のカード体系が大きく変わり、既存カード対応を最後に無理に追加するなどで複雑化＆不具合発生へ・既存カードを持った人は再登録して新規カードに切り替えないとWebを使用できない＜（SaPIDで検討したような）ToBe対応方針が達成できない＞・図書館員に依頼してWeb登録する手順が入り、図書館員の負担が増えてしまう・カードのみで図書館を使う会員に対してWebでのなりすまし登録が発生する
・Webシステム側に安易に個人情報が保存された状況となりセキュリティ上の問題が発生え、先月カード作ったばかりなのにまた再発行が必要？利用者図書館員システム変わっても結局忙しい… 旧カードも使うのかよ… 開発者

仕様テーマ：会員登録の実施 13 残念な仕様の結果… ＜既存の会員対応が後手にまわり不備が発生＞・既存のカード体系を考慮せずに新規カード/システムを作ってしまい、図書館統合に対応できない新旧のカード体系が大きく変わり、既存カード対応を最後に無理に追加するなどで複雑化＆不具合発生へ・既存カードを持った人は再登録して新規カードに切り替えないとWebを使用できない＜（SaPIDで検討したような）ToBe対応方針が達成できない＞・図書館員に依頼してWeb登録する手順が入り、図書館員の負担が増えてしまう・カードのみで図書館を使う会員に対してWebでのなりすまし登録が発生する
・Webシステム側に安易に個人情報が保存された状況となりセキュリティ上の問題が発生え、先月カード作ったばかりなのにまた再発行が必要？利用者図書館員システム変わっても結局忙しい… 旧カードも使うのかよ… 開発者色々達成できず…もう少しうまいやり方ができるとよいのかも

仕様検討における問題：Vol0 ケーススタディ 14 仕様Vol0にてありそうな問題を紹介しました。・表形式の要件、会話内で出てくる一部に特化した意見がインプット・仕様としても箇条書きで8行程度（これに意味があるか不明）・結果として残念なことが多くなり… SaPIDで紹介された方針は達成できない

今回紹介するもの 15 ・ユーザー、開発者とヒアリングしながら仕様化を進めます・「プロトタイピング仕様化（withテスト）」とでも呼んでおきます ※プロトタイピングと言っておりますが、実際にはペーパープロトタイプを使います・上位の情報（SaPID/RDRA）もあればより有効的な活動ができます・仕様に対してテスト設計を行うことで、仕様や業務手順へフィードバックもします・仕様ドキュメントの書き方自体は以下のテンプレートを段階的に埋めていく形式を使っています ※みなさんの環境にあわせてカスタマイズしてください・今回は段階的な打合せとドキュメントの更新を経て仕様化する例を紹介します
プロトタイピングな仕様開発者ユーザー運用実現テンプレートタイトル内容背景仕様（新規作成、変更）が必要とされる背景や AsIs状況を書きます。課題・やりたいこと解決したい課題ややりたいことを書きます。検討・検証シナリオ業務のパターンとヒアリング時にケーススタディを行うためのシナリオを特定します。実現方針人の運用でカバーを含めての実現方法を書きます。（調整事項）中間ヒアリングでの質問事項。最後には消えます。仕様実装に必要な情報を箇条書きなどでまとめます。テスト向け情報仕様やシナリオに対するテスト設計を書きます。

今回紹介するもの 16 ▪（参考）開発者、ユーザー双方の傾向開発者：システムの知識はあるが、業務の知識はない。実現方法に興味が強い。運用への興味が薄いことが多い。・手持ちの or 思いついた実現手段が運用にも適していて何とかなると思いこみやすい・実装するもの≒既に合意されているものと思いこみやすい・説明が雑なことが多い、開発者のみ伝わる表現（UMLや概念モデルとか）で伝わると考えている
・（極端なケース）ユーザーとの話をするのが無駄だと思っている人もいるユーザー：業務の知識はあるが、システムや開発の知識はない場合が多い。運用と業務効率化に興味が強い。・開発者の言っていることが何かわからない、理解できないことが多い・知っている範囲で実現する手段を提示し、知らない手段には耳を貸さないこともある・ものが出てくるまで/運用を開始するまで実感がないことが多い逆に運用を開始して使い始めた後に意見が大量に出ることが多い・「自分の範囲の仕事」で語ることが多く、課題を分けたり業務フロー的に分割・整理して話すことができる人は少ないプロトタイピングな仕様開発者ユーザー運用実現

今回紹介するもの（参考資料） 17 とある書籍より、今回の進め方の参考となる概念イメージ →仕様編の紹介範囲目的を特定する主要なシナリオを特定するアプリケーションの全体像を描く主要な課題を
特定する解決策の候補を出す上位の要件や情報が存在しない場合は安達さん神崎さんのお話を聞きましょう全体の整理は RDRAで実施してもらっているので個々の検討に専念します

仕様化検討のケーススタディ 18 今回は、図書館システム会員登録とWebで使用するための会員ID登録について仕様化のケーススタディをします・仕様化検討のケーススタディ（一例） Vol1．ヒアリングのための仮説仕様を作る Vol2．ヒアリング結果から、仕様を完成させる Vol3．仕様に対するテスト設計からフィードバックする・今回のケーススタディにおける進め方は以下になります。 ※必ずしもこの流れにはなりませんので注意してください… SaPID情報
仕様 Vol1 RDRA情報ヒアリングのための仮説仕様を作る・背景・課題・やりたいこと・検討・検証シナリオ・調整事項ヒアリング結果から仕様を完成させる・全体更新・実現方針・仕様仕様 Vol2 ユーザー/顧客ヒアリングヒアリング結果仕様に対するテスト設計からフィードバックする・テスト向け情報・全体更新仕様 Vol3 必要に応じてユーザー/顧客との共有テスト設計テスト設計結果

仕様化検討のケーススタディ： Vol1．ヒアリングのための仮説仕様を作る 19 ・上位の情報（RDRA、SaPID）があれば便利・背景となる情報があれば記載して、課題・やりたいことを仮でまとめる・対象の業務で検討が必要なバリエーションを出し、議論する代表の業務シナリオを決める・（RDRAの業務フローがある場合）業務フローを1段階詳細化し、具体的にシステムを使う箇所を特定する・業務フローに沿った流れを確認するために、特定の情報だけ記載したペーパープロトタイプを用意する・上記を作成する際に、調整事項（実現に対する課題）を特定してまとめる・全体として、論点が異なるものは別検討や拡張仕様でまとめる方針として分ける
・上記がまとまり次第、「調整事項（実現に対する課題）」を確認するためヒアリングを行う SaPID情報仕様 Vol1 RDRA情報ヒアリングのための仮説仕様を作る・背景・課題・やりたいこと・検討・検証シナリオ・調整事項ヒアリング結果から仕様を完成させる・全体更新・実現方針・仕様仕様 Vol2 ユーザー/顧客ヒアリングヒアリング結果仕様に対するテスト設計からフィードバックする・テスト向け情報・全体更新仕様 Vol3 必要に応じてユーザー/顧客との共有テスト設計テスト設計結果

仕様化検討のケーススタディ： Vol1．ヒアリングのための仮説仕様を作る 20 テンプレートに従って進める例を紹介します。具体例紹介

仕様の例：Vol1 ヒアリングのための仮説仕様 21

仕様テーマ：会員登録の実施 22 Vol1 インプット： RDRA情報 SaPID情報窓口会員期限管理会員登録
[会員管理：業務] 会員カードを作成する図書館員 Web会員ID を発行する会員 [会員登録：BUC] 会員会員登録会員登録条件会員登録会員登録

仕様テーマ：会員登録の実施 23 Vol1 インプット：ざっくり状況の特定（だいたいの目安） →厄介そうな部分はある程度把握しておくシステム設計要図書館の統合 CMSは別スコープとする業務調整
販売チェーン連携図書館員の業務負荷の大改善トレードオフ要 RFIDシステムの前提

仕様テーマ：会員登録の実施 24 Vol1 ・テンプレートに対して、前半部分を中心に仮説的な仕様をまとめていきます。テンプレートタイトル内容背景（必要時）仕様（新規作成、変更）が必要とされる背景や AsIs状況を書きます。課題・やりたいこと
解決したい課題ややりたいことを書きます。検討・検証シナリオ業務のパターンとヒアリング時にケーススタディを行うためのシナリオを特定します。実現方針人の運用でカバーを含めての実現方法を書きます。（調整事項）中間ヒアリングでの質問事項。最後には消えます。仕様実装に必要な情報を箇条書きなどでまとめます。テスト向け情報仕様やシナリオに対するテスト設計を書きます。ここまでをまとめるのが目標となるこの2つは前半が決まらないと無駄になるので考えない説明補足

仕様テーマ：会員登録の実施 25 背景：・図書館システムの導入に対して事前に会員登録を行っている→今後も行う・前提：すでに会員カードの登録している会員がいる状況、新システムが不要な人もいる・システム導入前から使用している現会員カードについて…？（たぶん使えたほうがよいが確認）・図書館を統合するシステムとなるが、現状の会員の仕組みは…？（仕組みが異なると利用者の影響が大きい）課題・やりたいこと：・新規登録者にはWeb会員ID、仮パスワード、（新規のカードが必要なら？）会員カードを発行したい ※調整：Webで会員カード発行まですべての登録はできない想定で仮検討してます
・すでに会員で会員カードを持っていて、Webを使わない方は元の会員カードのみで運用継続（しますか？）・すでに会員で会員カードを持っている人は、利用者本人がWeb画面でWeb会員ID登録ができるようにしたい ※調整：この場合、会員カードを発行して手に入れる必要があるか確認・Web会員IDを登録することで、スマホ（ブラウザ/アプリ）で表示してカードの代わりに使用できる＜用語整理＞・会員（カードを持つ人）、Web会員IＤ（Webで使用するための）：それぞれ個別に登録が必要という想定＜別論点の課題とする＞・会員カードを忘れる人が多いので、スマホでも貸出ができる仕組みを作る（貸出処理は別仕様で整理）・既会員で会員カードを持っている人が継続的に運用ができるかどうか確認・会員情報を変更するような場合にWebから可能にする方法は別途整理するテンプレートタイトル内容背景（必要時）仕様（新規作成、変更）が必要とされる背景や AsIs状況を書きます。※assumptionやconstraintも対象課題・やりたいこと解決したい課題ややりたいことを書きます。

仕様テーマ：会員登録の実施 26 背景：・図書館システムの導入に対して事前に会員登録を行っている→今後も行う・前提：すでに会員カードの登録している会員がいる状況、新システムが不要な人もいる・システム導入前から使用している現会員カードについて…？（たぶん使えたほうがよいが確認）・図書館を統合するシステムとなるが、現状の会員の仕組みは…？（仕組みが異なると利用者の影響が大きい）課題・やりたいこと：・新規登録者にはWeb会員ID、仮パスワード、（新規のカードが必要なら？）会員カードを発行したい ※調整：Webで会員カード発行まですべての登録はできない想定で仮検討してます
・すでに会員で会員カードを持っていて、Webを使わない方は元の会員カードのみで運用継続（しますか？）・すでに会員で会員カードを持っている人は、利用者本人がWeb画面でWeb会員ID登録ができるようにしたい ※調整：この場合、会員カードを発行して手に入れる必要があるか確認・Web会員IDを登録することで、スマホ（ブラウザ/アプリ）で表示してカードの代わりに使用できる＜用語整理＞・会員（カードを持つ人）、Web会員IＤ（Webで使用するための）：それぞれ個別に登録が必要という想定＜別論点の課題とする＞・会員カードを忘れる人が多いので、スマホでも貸出ができる仕組みを作る（貸出処理は別仕様で整理）・既会員で会員カードを持っている人が継続的に運用ができるかどうか確認・会員情報を変更するような場合にWebから可能にする方法は別途整理するどちらでもできるけど、どちらがよいか？を議論できるように、テンプレ内容をまとめながら質問箇所を出す説明補足

仕様テーマ：会員登録の実施 27 検討・検証シナリオ：・RDRA成果物を踏まえたうえでユーザーと議論します説明補足窓口会員期限管理会員登録 [会員管理：業務]
会員カードを作成する図書館員 Web会員ID を発行する会員 [会員登録：BUC] 会員会員登録会員登録条件会員登録会員登録ルールや手続きの変わるバリエーションを（すべてではないが）洗い出したい例：本の貸し出しバリエーションと条件条件＠RDRA ・バリエーションの組み合わせ・バリエーションと状態の組み合わせ ※バリエーションはツリー分析など条件はデシジョンテーブルでも表現可狙いどころ：議論が発散しすぎないようにする目的を見失わないようにするやること：業務のバリエーションを考え、特定のシナリオへ整理するテンプレートタイトル内容検討・検証シナリオ業務のパターンとヒアリング時にケーススタディを行うためのシナリオを特定します。

仕様テーマ：会員登録の実施 28 検討・検証シナリオ：・RDRA成果物を踏まえたうえでユーザーと議論します説明補足窓口会員期限管理会員登録 [会員管理：業務]
会員カードを作成する図書館員会員 [会員登録：BUC] 会員会員登録会員登録条件会員登録会員登録会員可能な住所 Z市＋近隣町上記以外バリエーションを仮検討会員状況既に会員、Web会員ID登録済既に会員、Web会員ID登録なしまだ会員ではない Web会員IDの登録場所（仮説込み）図書館員が会員登録/カード作成時に仮登録？会員が自分でWeb上で登録狙いどころ：議論が発散しすぎないようにする目的を見失わないようにするやること：業務のバリエーションを考え、特定のシナリオへ整理する ※参考（他の懸念事項もここで出てくる）・Webで会員カードの申請までする？ →開発側としてやりたくないので仮で除外・図書館統合の場合、登録図書館カードを切り替える際にどうするか？既存カードの扱いはどうか？ Web会員ID を発行する会員登録（カード）申請場所図書館（窓口） Web

仕様テーマ：会員登録の実施 29 検討・検証シナリオ：・ステークホルダと議論をやりやすいシナリオを導出します会員可能な住所 Z市＋近隣町上記以外バリエーション会員状況既に会員、Web会員ID登録済
既に会員、Web会員ID登録なしまだ会員ではない Web会員ID場所（仮説込み）図書館員が会員登録/カード作成時に仮登録？会員が自分でWeb上で登録目先で議論しやすいシナリオ（条件）を選定表示条件整理 #1 #2 #3 会員状況既に会員、Web会員ID登録済対象外 - - - 既に会員、Web会員ID登録なし対象〇〇 - まだ会員ではない対象 - - 〇会員可能な住所 Z市＋近隣町（会員対象）対象〇〇〇上記以外（会員非対象）画面案だけ確認 - - - Web会員ID登録場所図書館員が仮登録？対象〇 - - 会員が自分でWeb上で登録対象 - 〇〇シナリオひとまず採用〇〇〇非採用 - - - 議論時に使用する代表シナリオ #1 すでに会員の人が図書館受付で図書館員にWeb会員ID依頼？ #2 すでに会員の人が自分でWeb上でWeb会員IDを登録 #3 まだ会員で無く、図書館で会員登録＆Web会員ID同時登録？（該当住民のみ、該当住民でない場合は会員非対象とする）

仕様テーマ：会員登録の実施議論時に使用する代表シナリオ #1 すでに会員の人が図書館受付で図書館員にWeb会員ID依頼？ #2 すでに会員の人が自分でWeb上でWeb会員IDを登録 #3 まだ会員で無く、図書館で会員登録＆会員ID同時登録？（該当住民のみ、該当住民でない場合は会員非対象とする）検討・検証シナリオ：
・RDRA業務フロー（1段階詳細化） RDRAの情報を1段階詳細化します紹介するフロー：新規会員登録時をして図書館員が会員ID登録まで実施するまで会員可能な住所 Z市＋近隣町上記以外バリエーション会員状況既に会員、Web会員ID登録済既に会員、Web会員ID登録なしまだ会員ではない Web会員ID場所（仮説込み）図書館員が会員登録/カード作成時に仮登録？会員が自分でWeb上で登録

仕様テーマ：会員登録の実施 31 検討・検証シナリオ：仮画面案（ペーパープロト）：新規会員登録 Web会員ID仮登録名前：住所：電話番号：性別：
生年月日：メールアドレス：希望ID名：（OK/登録済）会員名：会員カードNo：XXX Web会員ID：XXXで登録仮パスワード：XX 登録登録（会員IDを登録しないで終わらせるケースはない？）印刷図書館システムWeb Web会員ID登録 Web会員IDを希望で設定可能とするかシンプルにカードNoにするか ※カードNoをIDにすることで制約にならないかも検討なりすまし登録の可能性やセキュリティ問題があるのでどうするか調整パスワード変更登録できない住所の判別は行う →登録はZ市、近隣のAA町、BB村の3つ ※そもそも選択式で登録できないって方針もあり＜Web会員ID登録画面＞＜会員登録画面＞＜Web会員ID情報画面＞図書館員用の端末旧カードの場合どうしよう？

仕様テーマ：会員登録の実施 32 実現方針（案）：・会員登録（会員カードの発行）とWeb会員ID（Webで使用可能とする）登録を分ける・Webの画面で既会員のWeb会員ID登録を可能とする・図書館の端末操作でも既会員のWeb会員ID登録を可能とする（会員操作と同一画面）・図書館システムの新規会員登録に引き続きWeb会員ID登録を可能とする（双方合わせて登録でも可）調整事項（実現に対する課題）：・Webで新規会員登録もできる？会員登録は図書館で行ったほうがよさそう。（構築側はやりたくない）・新システム会員に新規カード発行は必要？新規カード発行する場合、Webで登録した場合にどう渡す？
・既存のカードを使うことができる会員は継続でよいか？（カードNoなどの継続性、Web会員IDルールも確認）・完全新規登録の会員でWebを使わない人は放置でよい？希望なければWebアクセスできない仕組みにする？＜SaPIDのリスク分析より出てくるもの＞・Web登録のなりすまし・情報漏洩の可能性について検討、Webを使わない人への考慮も必要 →多少利便性を下げてもセキュリティを高くした方がよいのではないか？仕様：・後のページより ※ここまでの情報を渡して議論して、決めた内容を仕様としてまとめる。テンプレートタイトル内容実現方針人の運用でカバーを含めての実現方法を書きます。（調整事項）中間ヒアリングでの質問事項。最後には消えます。

仕様テーマ：会員登録の実施 33 参考：・ひとまず一式を検討し終えたタイミングでSaPIDの資料を再確認すると、疑問に対するステークホルダ側の回答がある程度予想がつきます・今回の場合は… - 図書館員の負担となるケースは減らす手続きを選択するだろう - セキュリティはすでにリスクでも出されているので、安全に倒したほうがよいだろう
説明補足

仕様テーマ：会員登録の実施 34 仕様：・TBDなう

仕様テーマ：会員登録の実施＜テスト向け情報＞あとで書くので現状は枠のみテスト向け

仕様テーマ：会員登録の実施 36 ヒアリングで得た情報： ※本内容は半分程度、墨田区図書館のシステムを参考としてます。＜会員ルール＞・既存会員も2年に1度会員更新が必要というルール→2年後には全員更新される・既存のカードは5桁の数字、バーコード管理。会員追加のたびにインクリメントしている（図書館毎にNoを採番している）・既存の通り図書館で新規会員登録はできるが、Webだけでも会員カード申請を行いたい（カードは図書館受取り）・会員全員にカードおよび会員No（会員カードNo）を発行する・既存のカードはそのまま使用可能としたい（カード廃止はしない）
セルフレジもバーコード読み取りさせる <図書館横断ルール> ・現図書館（市内で4館）で個別にNo設定されている。ただし、バーコードシステム/会員Noルールは全図書館同じものを使用・Z市の人口が増えている＋図書館横断となるため、会員カードNoも増やす→5桁から6桁に増やす・既存の図書館の会員Noは上位桁を0扱いとする。Web登録時には5桁の番号の場合に登録図書館名をセットで情報として使う・新規カードNoは1XXXXX以降で採番し、市内の図書館4館共通で使えるカードにする＜参考：スマホ向け情報＞・スマホでは会員カードのバーコードと同じものを表示できれば良い＜Web会員ID登録＞・できれば既存のカードのままでもWeb会員ID登録をしてWebを使えるようにする・図書館員は負担が大きいため、作業を増やさないこと→会員が自分でWeb/図書館端末で会員IDを登録する＜セキュリティ＞・多少使い勝手を下げても情報漏洩が無いようにしたい・Webでは予約・貸与中の書籍情報確認のみでもよい・Webの会員ID登録しないでカードのみで図書館を使用する人も許容する→Webのなりすまし対策も検討赤字は厄介そうな部分

仕様テーマ：会員登録の実施 37 ヒアリング前に予想されること SaPID側の情報があると、ある程度の回答が予想できる。

仕様化検討のケーススタディ： Vol2．ヒアリング結果から、仕様を完成させる 38 ・ヒアリング結果を活用して各種情報を更新する・ヒアリング結果をふまえた実現方針（運用で対処を含む内容）を記載する・具体的な仕様を描く（必要に応じて分割する）・上記検討で、追加で確認する事項が発生した場合には再度ヒアリングを行う SaPID情報仕様 Vol1
RDRA情報ヒアリングのための仮説仕様を作る・背景・課題・やりたいこと・検討・検証シナリオ・調整事項ヒアリング結果から仕様を完成させる・全体更新・実現方針・仕様仕様 Vol2 ユーザー/顧客ヒアリングヒアリング結果仕様に対するテスト設計からフィードバックする・テスト向け情報・全体更新仕様 Vol3 必要に応じてユーザー/顧客との共有テスト設計テスト設計結果

仕様化検討のケーススタディ： Vol2．ヒアリング結果から、仕様を完成させる 39 Vo1でのヒアリング結果とそれを踏まえたVol2への更新を紹介します。具体例紹介

仕様の例：Vol2 ヒアリング結果から、仕様を完成へ 40

仕様テーマ：会員登録の実施 41 背景：・図書館システムの導入に対して事前に会員登録を行う方針とする・システム導入前から使用している会員および会員カードについてはそのまま使えるようにする・Webシステムを使えるようにするために、会員にWeb会員ID（パスワードつき）を付与したい・前提として、すでに会員カードの登録している会員がいる状況、新システムが不要な人もいる・前提として、2年前から会員は2年に1度更新する仕組みとしている課題・やりたいこと：・新規登録者には番号（6桁）付きの会員カードを発行したい。既存は5桁のIDで新規システムでは一桁増やす
完全新規の場合、図書館もしくはWebで会員申請、図書館で新規会員カードの発行する・現在の図書館IDもWebで登録可能とする。登録時に5桁のIDの場合には登録図書館名とセットで扱う。・すでに会員で会員カードを持っていて、Webを使わない方は元の会員カードで書籍貸与ができる・すでに会員で会員カードを持っている人は、利用者本人がWeb画面でWeb会員ID登録ができる（新システム間相互は過去のカードを持つ人もWeb会員ID登録ができる）・Web会員IDを登録することで、スマホ（ブラウザ/アプリ）で表示してカードの代わりに使用できるスマホで会員ID6桁およびバーコードの表示ができるようにする。最初はブラウザのみで運用・Web会員IDの登録をすることで、図書館横断でカードが利用できるようになる＜別論点の課題＞・会員カードを忘れる人が多いので、スマホでも貸出ができる仕組みを作る（貸出処理は別仕様で整理）・既会員で会員カードを持っている人が継続的に運用ができるようにテストで確認・会員情報を変更するような場合にWebから可能にする方法は別途整理する

既に会員、Web会員ID登録なしまだ会員ではない Web会員IDの登録場所（仮説込み）図書館員が会員登録/カード作成時に仮登録？会員が自分でWeb上で登録目先で議論しやすいシナリオ（条件）を選定表示条件整理 #1 #2 #3 会員状況既に会員、Web会員ID登録済対象外 - - - 既に会員、Web会員ID登録なし対象〇〇 - まだ会員ではない対象 - - 〇会員可能な住所 Z市＋近隣町（会員対象）対象〇〇〇上記以外（会員非対象）画面案だけ確認 - - - Web会員ID登録場所図書館員が仮登録？対象〇 - - 会員が自分でWeb上で登録対象 - 〇〇シナリオひとまず採用〇〇〇非採用 - - - 議論時に使用する代表シナリオ #1 すでに会員の人が図書館受付で図書館員に会員IDを登録？ #2 すでに会員の人が自分でWeb上で会員IDを登録 #3 まだ会員で無く、図書館で会員登録＆会員ID同時登録？（該当住民のみ、該当住民でない場合は会員非対象とする） Vol1情報

既に会員、Web会員ID登録なしまだ会員ではない目先で議論しやすいシナリオ（条件）を選定議論時に使用する代表シナリオ＜会員登録を図書館で実施するとき＞ #1 すでに会員の人が図書館受付で図書館員に会員IDを登録？ #1 すでに会員の人が図書館端末にて自分で会員IDを登録 #2 すでに会員の人が自分でWeb上で会員IDを登録 #3 まだ会員で無く、図書館で会員登録＆会員ID同時登録？ #3 まだ会員で無く、図書館で会員登録＋Webで会員ID登録 Vol2情報会員登録申請場所図書館 Web Web会員IDの登録場所（仮説込み）図書館員が会員登録/カード作成時に仮登録？図書館端末にて会員が自分で登録会員が自分でWeb上で登録条件整理 #1 #2 #3 #4 会員状況既に会員、Web会員ID登録済対象外 - - - - 既に会員、Web会員ID登録なし対象〇〇 - - まだ会員ではない対象 - - 〇 - 会員登録/カード作成場所図書館対象〇〇〇 - Web（カードは図書館で受け取る）対象 - - - 〇会員可能な住所 Z市＋近隣町（会員対象）対象〇〇〇 - 上記以外（会員非対象）画面案だけ確認 - - - - Web会員ID登録場所図書館端末にて会員が登録対象〇 - - - 会員が自分でWeb上で登録対象 - 〇〇 - シナリオひとまず採用〇〇〇〇非採用 - - - -

仕様テーマ：会員登録の実施議論時に使用する代表シナリオ #1 すでに会員の人が図書館受付で図書館員に会員IDを登録？ #2 すでに会員の人が自分でWeb上で会員IDを登録 #3 まだ会員で無く、図書館で会員登録＆会員ID同時登録？（該当住民のみ、該当住民でない場合は会員非対象とする）検討・検証シナリオ：
・RDRA業務フロー（1段階詳細化）会員可能な住所 Z市＋近隣町上記以外バリエーション会員状況既に会員、Web会員ID登録済既に会員、Web会員ID登録なしまだ会員ではない Web会員IDの登録場所（仮説込み）図書館員が会員登録/カード作成時に仮登録？会員が自分でWeb上で登録 Vol1情報希望IDには対応しないカードNo＝アカウントカード発行は必須必ず会員が実施 Webか図書館端末（カードNoが必要）

仕様テーマ：会員登録の実施検討・検証シナリオ：・RDRA業務フロー（1段階詳細化）会員可能な住所 Z市＋近隣町上記以外バリエーション会員状況既に会員、Web会員ID登録済既に会員、Web会員ID登録なし
まだ会員ではない Vol2情報会員登録申請場所図書館 Web Web会員IDの登録場所（仮説込み）図書館員が会員登録/カード作成時に仮登録？図書館端末にて会員が自分で登録会員が自分でWeb上で登録議論時に使用する代表シナリオ＜会員登録を図書館で実施するとき＞ #1 すでに会員の人が図書館受付で図書館員に会員IDを登録？ #1 すでに会員の人が図書館端末にて自分で会員IDを登録 #2 すでに会員の人が自分でWeb上で会員IDを登録 #3 まだ会員で無く、図書館で会員登録＆会員ID同時登録？ #3 まだ会員で無く、図書館で会員登録＋Webで会員ID登録

まだ会員ではない Vol2情報会員登録申請場所図書館 Web Web会員IDの登録場所（仮説込み）図書館員が会員登録/カード作成時に仮登録？図書館端末にて会員が自分で登録会員が自分でWeb上で登録議論時に使用する代表シナリオ＜会員登録をWebで実施するとき＞ →スコープが大きくなりすぎるので、図書館で会員登録のケースを検討後に議論することを合意して後回しにします。（サンプルからは除外）段階的な検討を合意するただ、後回しにしても業務フローレベルは軽く合意しておく

仕様テーマ：会員登録の実施 47 （参考）：・実際の進め方でも、検討サイズ大と判断した場合には範囲を絞り、段階的に議論することを合意します。後回しにする場合でも、業務レベルの流れと課題だけ出して置くことを推奨します。 ※今回の例では、まず「図書館で会員登録」を検討後に「Webで会員申請」を検討することを合意します。図書館で会員登録できるプロトタイプ Webでも会員申請できるシステム
仕様検討その① （および実装）仕様検討その② （および実装）最初にこちらを専念することを合意して進める今回はやらず、業務の流れだけ確認。あとで実施することを合意する説明補足

図書館員用の端末仕様テーマ：会員登録の実施 48 検討・検証シナリオ：仮画面案（ペーパープロト）：新規会員登録 Web会員ID仮登録名前：住所：電話番号：
性別：生年月日：メールアドレス：希望ID名：（OK/登録済）会員名：会員カードNo：XXX 会員ID：XXXで登録仮パスワード：XX 登録登録（会員IDを登録しないで終わらせるケースもある？）印刷図書館システムWeb 会員IDを希望の設定可能とするかシンプルにカードNoにするか ※カードNoをIDにすることで制約にならないかも検討なりすまし登録の可能性やセキュリティ問題があるのでどうするか調整パスワード変更登録できない住所の判別は行う →登録はZ市、AA町、BB村の3つ ※そもそも選択式で登録できないって方針もあり＜Web会員ID登録画面＞＜会員登録画面＞＜Web会員ID情報画面＞新システムは図書館統合なので旧カードでのWeb会員ID登録は図書館指定が必要カードのみ発行して渡す会員カードNoは必須図書館員による Web会員ID仮登録は不要 Web会員ID＝カードNo （旧カードは元図書館情報込み）個人設定は確認不可能会員ID登録時に生年月日と電話番号のみを入力して照会する ※照会のみ、参照不可能 Vol1情報 Web会員ID登録

仕様テーマ：会員登録の実施 49 検討・検証シナリオ：めんどくさい会員IDルールの統合・現カードは対象図書館の判断が可能、ID5桁というのは統一、バーコードリーダーも同じものを使用。各図書館でIDを付与しているのでIDだけを見ると重複あり、該当図書館しか使わない想定。・新カードは図書館統合で使用する。ID6桁とする。現カードX Vol2情報 X町図書館
ID:12345 （みずの）現カードY Y町図書館 ID:12345 （あだち） IDと図書館名の2つの情報でユーザを特定上位1桁は「0」扱い新カード図書館統一 ID:123456 （みずの） 6桁のID、1桁目が1以上で判断 Web会員ID のルール

仕様テーマ：会員登録の実施 50 検討・検証シナリオ：仮画面案（ペーパープロト）：新規会員登録名前：住所：電話番号：性別：生年月日：
登録パスワード：パスワード確認：会員カードNo：電話番号：生年月日：登録登録（確認画面を用意）カード発行への導線も用意する（運用）カードNoの使い方、会員IDの登録方法を伝える確定図書館システムWeb （図書館端末でも同じ） Web会員ID登録登録できない住所は選択式なので入力できない →登録は登録はZ市、AA町、BB村の3つ＜Web会員ID登録画面＞＜会員登録画面＞＜Web会員ID登録確認画面＞ Web会員ID＝カードNo （旧カードは登録図書館情報も持つ）個人設定は確認不可能 Z市▼ 登録図書館：XXX 会員カードNo：XXX 登録しますか？＜Web会員ID登録完了＞登録を完了しました会員ID登録時に生年月日と電話番号のみを入力して照会する ※照会のみ、保存しないキャンセル図書館員用の端末 Vol2情報（5桁Noのカード時）登録図書館：旧カードとのNo体系の違いを吸収

仕様テーマ：会員登録の実施 51 検討・検証シナリオ：仮構成案（ペーパープロト）：会員登録図書館員ユーザー情報＜Webシステム＞バーコード会員No
XXXXXX 会員 Web会員ID登録ユーザ情報を確認する画面はない ID登録時照会のみ（別で検討）各種Web操作書籍検索、予約、貸与中書籍確認、書籍のリクエスト等ができる申請用紙（手書き）電話番号と生年月日は照会のみでデータは置かない＜図書館会員管理システム＞個人情報はこちらで管理市内図書館の統合データとなる IDの追加スマホでカード代替（仮）メモ：Web登録なしというオプションもあったほうがよい？ Vol2情報カード発行

仕様テーマ：会員登録の実施 52 検討・検証シナリオ：仮構成案（ペーパープロト）：Web会員申請のあたりをつけると… 会員登録図書館員ユーザー情報＜Webシステム＞バーコード会員No
XXXXXX 会員 Web会員ID登録 ID登録時照会のみ（別で検討）各種Web操作書籍検索、予約、貸与中書籍確認、書籍のリクエスト等ができる申請用紙（手書き）＜図書館会員管理システム＞個人情報はこちらで管理市内図書館の統合データとなる IDの追加スマホでカード代替（仮）メモ：Web登録なしというオプションもあったほうがよい？ Vol2情報カード発行会員登録（カード）申請会員申請承認

仕様テーマ：会員登録の実施 53 検討・検証シナリオ（システム全体範囲）：仮構成案（ペーパープロト）：説明補足重要な業務をあと2-3個議論して決めるとして、システムの「あたり」はつけて制約を確認特に初期はこの程度のざっくり感

仕様テーマ：会員登録の実施トレードオフテーマ：カードの更新有無・図書カードを全員新カードへ更新する・旧カードを使えるようにする Vol2情報案懸念コスト課題：従業員負荷
課題：利便性図書カードを全員新カードへ更新する懸念・図書館毎のID重複へ対応・Web会員IDへの複雑さとユーザへのわかりにくさ・カード更新時の作業量・新RFIDシステムとの整合性比較的安くなる移行もシンプル初期運用時が大変図書館に来る人全員が更新になる全員移行すればわかりやすい旧カードを使えるようにする厄介既存カードで凌ぐので最初の負担が大幅に減る Web会員の動線が新旧カードになってわかりづらい（参考）：上位の検討ベースでの「あたり」のつけかた。トレードオフ、方針決定（Architecture Decision）例その他の各テーマを挙げて同等の検討をする→各種決定の中間議論を残すと、見直しの際にも役立つ・図書館員にてWeb仮登録を行うかどうか・Webでの会員（カード）申請をするかどうか SaPIDの検討があれば判断基準はだいたい見える

仕様テーマ：会員登録の実施 55 実現方針（案）：・会員登録（会員カードの発行）と会員ID（Webで使用可能とする）登録を分ける・Webの画面で既会員の会員ID登録を可能とする・図書館の端末操作でも既会員の会員ID登録を可能とする（会員操作と同一画面）・図書館システムの新規会員登録に引き続き会員ID登録を可能とする（双方合わせて登録でも可）調整事項（実現に対する課題）：・Webで完全新規登録できる？会員登録は図書館で行ったほうがよさそう。・新システム会員に新規カード発行は必要？新規カード発行する場合、Web登録した場合の導線はどうする？
・既存のカードを使うことができる会員は継続放置でよいか？（カードNoなどの継続性、会員IDのルール）・完全新規登録の会員でWebは使わない人は放置でよい？希望なければWebアクセスできない仕組みにする？・Web登録での、なりすまし・情報漏洩の可能性について検討、Webを使わない人への考慮も必要・（上記検討後）使用する画面構成について仕様：・後のページより ※ここまでの情報を渡して議論して、決めた内容を仕様としてまとめる。 Vol1情報

仕様テーマ：会員登録の実施 56 ※ひとまず、図書館での新規会員登録/カード発行を開発する。分割テーマ： 1．新規会員登録 2．Web会員ID登録実現方針（1．新規会員登録）：・会員ではない人は必ず図書館で新規会員登録を行う・（運用）会員希望者が申請用紙に記入して提出し、図書館員が登録を行う・（運用）証明書を提出して、登録者を確認の上会員登録を行う
・会員登録情報を入力後、会員カードNo（新規は6桁）付きの会員カードを発行する・（運用）会員IDの登録方法は、個別に新規会員に説明（説明用紙などを作成してもらう）実現方針（2．Web会員ID登録）：・会員カードNoを用いてWeb会員ID登録を可能とする・既会員も既存の会員カードNoでWeb会員ID登録ができる、・Webの画面と図書館端末で既会員のWeb会員ID登録を可能とする（図書館端末でもWebと同一画面）・（参考）Webシステムでは、氏名や住所などの個人情報は直接取り扱わないようにする →多少使い勝手を下げても情報漏洩が無い仕組みにする・（参考）Webでは予約・貸与中の書籍情報確認のみでもよい・（参考）スマホではカードの代替となる会員Noとバーコード表示ができればよい Vol2情報

仕様： 1．新規会員登録・会員登録画面を用意する必要な情報は、下記の画面構成を参考のこと・全体メニューから会員登録画面へ移動できる・住所はZ市とAA町、BB村の3つのみ選択できる形式とする・（その他入力形式のルールは省略）・登録ボタンを押すことで会員登録確認・カード発行画面へ移行する・確認画面移行時に会員Noを仮採番、確認後にカード発行を可能とする・カード発行時に会員情報を図書館会員管理システムへ追加する
・カード発行時にWebシステムへWeb会員ID（≒会員No）を追加、会員のWeb会員IDを登録可能とする ※既存会員の移行作業が必要仕様テーマ：会員登録の実施 57 名前：住所：電話番号：性別：生年月日：登録＜会員登録画面＞ Z市▼ 名前：XX XXX 住所：Z市XXX 電話番号：XXX-XXXX-XXXX 性別：男女生年月日：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行＜会員登録確認・カード発行画面＞新規会員登録＜全体メニュー＞・・・・カード発行機でカード発行・図書館会員管理システムへ会員情報を追加・Webシステムへ会員ID追加キャンセル会員No 仮採番 Vol2情報

登録パスワード：パスワード確認：会員カードNo：電話番号：生年月日：登録＜Web会員ID登録画面＞（5桁Noのカード時）
登録図書館：仕様： 2．Web向け会員ID登録・Web会員ID登録画面を用意する ※必要な情報は、下記の画面構成を参考・図書館の端末画面からもWeb会員ID登録画面へ移動できる・Web会員ID登録画面では以下を確認して、Web会員ID登録確認画面へ移行する - 旧カードNo（5桁の場合）には、カードの対象とする図書館の選択があること - 会員カードNoに対応する電話番号、生年月日が正しいこと（図書館会員管理システムへ照会して確認） - 登録パスワードとパスワード確認が一致していること・Web会員IDの情報が正しい内容の場合、 Web会員ID登録確認画面でWeb会員ID登録を確定できる・ Web会員ID登録を確定すると、 Web会員ID情報がWebシステムに登録される・（参考）ログインすることでスマホでの会員情報表示、Web予約、貸与中書籍確認等ができる ※別途検討仕様テーマ：会員登録の実施 58 確定＜Web会員ID登録確認画面＞登録図書館：XXX 会員カードNo：XXX 登録しますか？＜Web会員ID登録完了＞登録を完了しましたキャンセル図書館システムWeb （図書館端末でも同じ） Web会員ID登録 Vol2情報

仕様テーマ：会員登録の実施＜テスト向け情報＞あとで書くテスト向け

仕様化検討のケーススタディ： Vol3．仕様に対するテスト設計からフィードバックする 60 ・仕様からテストを検討し、具体的にテストを設計する・テストが必要以上に複雑になるような箇所や考慮したほうがよい異常ケースなどの対応がある場合、再度ヒアリング等で確認しつつ仕様に取り込む・業務バリエーション、業務シナリオからテストを設計し、必要に応じてフィードバックを行う SaPID情報仕様 Vol1
RDRA情報ヒアリングのための仮説仕様を作る・背景・課題・やりたいこと・検討・検証シナリオ・調整事項ヒアリング結果から仕様を完成させる・全体更新・実現方針・仕様仕様 Vol2 ユーザー/顧客ヒアリングヒアリング結果仕様に対するテスト設計からフィードバックする・テスト向け情報・全体更新仕様 Vol3 必要に応じてユーザー/顧客との共有テスト設計テスト設計結果

仕様化検討のケーススタディ： Vol3．仕様に対するテスト設計からフィードバックする 61 Vo2の結果にテスト設計を行った結果をフィードバックさせる例を紹介します。具体例紹介

仕様の例：Vol3 テスト設計によりフィードバックする 62

仕様： 1．新規会員登録・会員登録画面を用意する必要な情報は、下記の画面構成を参考のこと・全体メニューから会員登録画面へ移動できる・住所はZ市とAA町、BB村の3つのみ選択できる形式とする・（その他入力形式のルールは省略）・登録ボタンを押すことで会員登録確認・カード発行画面へ移行する・確認画面移行時に会員Noを仮採番、確認後にカード発行を可能とする・カード発行時に会員情報を図書館会員管理システムへ追加する
・カード発行時にWebシステムへ会員ID（≒会員No）を追加し、 Webからの会員ID登録可能とする仕様テーマ：会員登録の実施 63 名前：住所：電話番号：性別：生年月日：登録＜会員登録画面＞ Z市▼ 名前：XX XXX 住所：Z市XXX 電話番号：XXX-XXXX-XXXX 性別：男女生年月日：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行＜会員登録確認・カード発行画面＞新規会員登録＜全体メニュー＞・・・・カード発行機でカード発行・図書館会員管理システムへ会員情報を追加・Webシステムへ会員ID追加キャンセル会員No 仮採番 Vol2情報まず、こちらの仕様に対してテストを考えてみる

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト 1．新規会員登録：仕様に対するテストの全体案テスト向け名前：住所：電話番号：性別：
生年月日：確認＜会員登録画面＞ Z市▼ 名前：XX XXX 住所：Z市XXX 電話番号：XXX-XXXX-XXXX 性別：男女生年月日：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行＜会員登録確認・カード発行画面＞新規会員登録＜全体メニュー＞・・・キャンセル・カード発行機でカード発行・図書館会員管理システムへ会員情報を追加・Webシステムへ会員ID追加会員登録チェック会員No仮採番カード期限設定カード発行会員情報の図書館会員管理システムへの追加 Webシステムへの会員ID追加会員No 仮採番検討の例・ふるまいのあたりをつける・関連するデータを考える・それぞれ詳細テスト設計する

生年月日：確認＜会員登録画面＞ Z市▼ 名前：XX XXX 住所：Z市XXX 電話番号：XXX-XXXX-XXXX 性別：男女生年月日：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行＜会員登録確認・カード発行画面＞新規会員登録＜全体メニュー＞・・・キャンセル・カード発行機でカード発行・図書館会員管理システムへ会員情報を追加・Webシステムへ会員ID追加会員登録チェック会員No仮採番カード期限設定登録日カード発行会員情報の図書館会員管理システムへの追加 Webシステムへの会員ID追加会員DB 会員DB WebDB カード発行機会員No 仮採番入力：会員情報検討の例・ふるまいのあたりをつける・関連するデータを考える・それぞれ詳細テスト設計する

生年月日：確認＜会員登録画面＞ Z市▼ 名前：XX XXX 住所：Z市XXX 電話番号：XXX-XXXX-XXXX 性別：男女生年月日：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行＜会員登録確認・カード発行画面＞新規会員登録＜全体メニュー＞・・・キャンセル・カード発行機でカード発行・図書館会員管理システムへ会員情報を追加・Webシステムへ会員ID追加会員登録チェック会員No仮採番カード期限設定登録日カード発行会員情報の図書館会員管理システムへの追加 Webシステムへの会員ID追加会員DB 会員DB WebDB カード発行機会員No 仮採番入力：会員情報検討の例・ふるまいのあたりをつける・関連するデータを考える・それぞれ詳細テスト設計するなんかあやしい

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト 1．新規会員登録：会員No仮採番のテスト検討テスト向け会員登録チェック会員No仮採番カード期限設定
登録日会員情報の図書館会員管理システムへの追加 Webシステムへの会員ID追加会員DB 会員DB WebDB Aさん（1人目） Bさん（2人目） Cさん（3人目）仮採番（000001）キャンセル Time 仮採番（000002）登録仮採番（?）仮採番（000003） No 状態 000001 仮採番 000002 仮採番 000003 仮採番 No 状態 000001 仮採番 000002 登録 000003 仮採番 No 状態 000001 なし 000002 登録 000003 仮採番 No 状態 000001 ？？ 000002 登録 000003 仮採番 000004 ？？入力：会員情報検討の例・ふるまいのあたりをつける・関連するデータを考える・それぞれ詳細テスト設計する仮採番、キツくない？

生年月日：確認＜会員登録画面＞ Z市▼ 名前：XX XXX 住所：Z市XXX 電話番号：XXX-XXXX-XXXX 性別：男女生年月日：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行＜会員登録確認・カード発行画面＞新規会員登録＜全体メニュー＞・・・キャンセル・カード発行機でカード発行・図書館会員管理システムへ会員情報を追加・Webシステムへ会員ID追加入力：会員情報会員登録チェック会員No仮採番カード期限設定登録日カード発行会員情報の図書館会員管理システムへの追加 Webシステムへの会員ID追加会員DB 会員DB WebDB カード発行機会員No 仮採番仮採番は仕様としてキツイカード発行は失敗ケースを最初から考慮

仕様（Vol2）： 1．新規会員登録・会員登録画面を用意する必要な情報は、下記の画面構成を参考のこと・全体メニューから会員登録画面へ移動できる・住所はZ市とAA町、BB村の3つのみ選択できる形式とする・（その他入力形式のルールは省略）・登録ボタンを押すことで会員登録確認・カード発行画面へ移行する・確認画面移行時に会員Noを仮採番し、確認後にカード発行を可能とする・カード発行時に会員情報を図書館会員管理システムへ追加する
・カード発行時にWebシステムへ会員ID（≒会員No）を追加し、 Webからの会員ID登録可能とする仕様テーマ：会員登録の実施 69 名前：住所：電話番号：性別：生年月日：確認＜会員登録画面＞ Z市▼ 名前：XX XXX 住所：Z市XXX 電話番号：XXX-XXXX-XXXX 性別：男女生年月日：XXXX年XX 会員No ：123456 カード期限：2023/03/15 カード発行＜会員登録確認・カード発行画面＞新規会員登録＜全体メニュー＞・・・キャンセル・カード発行機でカード発行・図書館会員管理システムへ会員情報を追加・Webシステムへ会員ID追加会員No 仮採番

仕様（Vol3）：テスト設計での見直し結果 1．新規会員登録・会員登録画面を用意する必要な情報は、下記の画面構成を参考のこと・全体メニューから会員登録画面へ移動できる・住所はZ市とAA町、BB村の3つのみ選択できる形式とする・電話番号は半角数字のみでハイフンなし入力とする、生年月日は選択形式・（その他入力形式のルールは省略）・登録ボタンを押すことで会員登録確認・カード発行画面へ移行する・確認画面で、確認後に会員No採番とカード発行を可能とする
・カード発行時に会員情報を図書館会員管理システムへ追加する・カード発行時にWebシステムへ会員ID（≒会員No）を追加し、 Webからの会員ID登録可能とする・カード発行失敗時のために再発行操作を可能とする仕様テーマ：会員登録の実施 70 名前：住所：電話番号：半角数字性別：生年月日：選択確認＜会員登録画面＞ Z市▼ 名前：XX XXX 住所：Z市XXX 電話番号：0123456789 性別：男女生年月日：XXXX/XX/XX 会員No ：123456 カード期限：2023/03/15 カード発行＜会員登録確認・カード発行画面＞新規会員登録＜全体メニュー＞・・・キャンセル会員No 採番・カード発行機でカード発行・図書館会員管理システムへ会員情報を追加・Webシステムへ会員ID追加会員カードを発行しました Webシステムへ登録しました会員No123456 カード再発行終了

登録図書館：仕様： 2．Web向け会員ID登録・Web会員ID登録画面を用意する ※必要な情報は、下記の画面構成を参考・図書館の端末画面からもWeb会員ID登録画面へ移動できる・Web会員ID登録画面では以下を確認して、Web会員ID登録確認画面へ移行する - 旧カードNo（5桁の場合）には、カードの対象とする登録図書館が選択されていること - 会員カードNoに対応する電話番号、生年月日が正しいこと（図書館会員管理システムへ照会して確認） - 登録パスワードとパスワード確認が一致していること・Web会員IDの情報が正しい内容の場合、 Web会員ID登録確認画面でWeb会員ID登録を確定できる・ Web会員ID登録を確定すると、 Web会員ID情報がWebシステムに登録される・（参考）ログインすることでスマホでの会員情報表示、Web予約、貸与中書籍確認等ができる ※別途検討仕様テーマ：会員登録の実施（Vol2） 71 確定＜Web会員ID登録確認画面＞登録図書館：XXX 会員カードNo：XXX 登録しますか？＜Web会員ID登録完了＞登録を完了しましたキャンセル図書館システムWeb （図書館端末でも同じ） Web会員ID登録 Vol2情報こちらも仕様に対してテストを考えてみる

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：仕様に対するテストの全体案テスト向け図書館システムWeb （図書館端末でも同じ）
会員ID登録会員ID登録チェック新旧カード会員No確認会員照会期限確認会員DB パスワード確認 WebDB 入力：会員 ID情報 Webシステムへの会員・パスワード登録 WebDB ※その他初期データ作成時は確認登録パスワード：パスワード確認：会員カードNo：電話番号：生年月日：登録＜Web会員ID登録画面＞（5桁Noのカード時）登録図書館：確定登録図書館：XXX 会員カードNo：XXX 登録しますか？＜Web会員ID登録完了＞登録を完了しましたキャンセル＜Web会員ID登録確認画面＞

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：仕様に対するテストの全体案テスト向け図書館システムWeb （図書館端末でも同じ）
会員ID登録会員ID登録チェック会員照会期限確認会員DB パスワード確認 WebDB 入力：会員 ID情報 Webシステムへの会員・パスワード登録 WebDB ※その他初期データ作成時は確認 UIだけからは発想しづらいが、会員期限もチェックが必要登録パスワード：パスワード確認：会員カードNo：電話番号：生年月日：登録＜Web会員ID登録画面＞（5桁Noのカード時）登録図書館：確定登録図書館：XXX 会員カードNo：XXX 登録しますか？＜Web会員ID登録完了＞登録を完了しましたキャンセル＜Web会員ID登録確認画面＞新旧カード会員No確認

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：仕様に対するテストの全体案テスト向け確定キャンセル
図書館システムWeb （図書館端末でも同じ）会員ID登録会員ID登録チェック会員ID確認会員照会期限確認会員DB パスワード確認 WebDB 入力：会員 ID情報 Webシステムへの会員・パスワード登録 WebDB ※その他初期データ作成時は確認会員ID登録時には期限の確認も必要会員DB側への照会を考慮するとフロントでの入力制約もあるとよい（半角しばり、ハイフン無しなど）登録パスワード：パスワード確認：会員カードNo：電話番号：生年月日：登録＜Web会員ID登録画面＞（5桁Noのカード時）登録図書館：登録図書館：XXX 会員カードNo：XXX 登録しますか？＜Web会員ID登録完了＞登録を完了しました＜Web会員ID登録確認画面＞

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：Web会員ID登録チェックのCFD（Cause Flow Diagram）テスト設計テスト向け会員No確認（WebDB）
会員カードNo登録済入力NG 通知新旧カード会員No確認会員照会期限確認会員DB パスワード確認 WebDB 入力：会員 ID情報 Webシステムへの会員・パスワード登録 WebDB ※その他初期データ作成時は確認会員カードNoがない会員照合（会員DB）入力の不正値カードNo、電話番号、生年月日不整合カード期限確認カード期限内カード期限切れ会員期限 NG通知カードNo、電話番号、生年月日が整合入力パスワード確認登録OK 確認画面へ入力の不正値登録内容と確認内容が異なる登録内容と確認内容が整合 Password NG通知 NG通知の適切さも議論することが可能照合対象データの形式をここで検討できる新旧カード確認入力の不正値カード情報 NG通知新旧カード併用のわかりづらい点を通知でフォロー新カードの6桁No 旧カードの5桁No ＆登録図書館の入力

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト新旧カードのわかりづらさを改善調整テスト向け新旧カード確認新カードの6桁No 入力の不正値旧カードの5桁No
＆登録図書館の入力カード情報 NG通知新旧カード併用のわかりづらい点を通知でフォロー？登録パスワード：パスワード確認：会員カードNo：電話番号：生年月日：登録＜Web会員ID登録画面＞（5桁Noのカード時）登録図書館：登録パスワード：パスワード確認：（6桁Noのカード時）会員カードNo：登録＜Web会員ID登録画面＞（5桁Noのカード時）登録図書館：会員カードNo： OR 電話番号：生年月日：？そもそもの仕組み上の複雑さをカバーするデザインも必要 ※雑ですが？画面上の説明、ヘルプ入力チェックやエラーメッセージの工夫が必要な箇所を特定 Noの入力フィールド 1つで5桁6桁判断？＋登録図書入力判断？

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：会員ID登録チェックのCFD （Cause Flow Diagram）テスト設計テスト向け

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：会員ID登録チェックのCFDテスト設計 ※CFDから生成したデシジョンテーブルテスト向け Enterprise Architect＋CFDアドインを使用
ツールの活用でDTまで作成も可能

登録図書館：仕様（Vol2）： 2．Web向け会員ID登録・Web会員ID登録画面を用意する ※必要な情報は、下記の画面構成を参考・図書館の端末画面からもWeb会員ID登録画面へ移動できる・Web会員ID登録画面では以下を確認して、Web会員ID登録確認画面へ移行する - 旧カードNo（5桁の場合）には、カードの対象とする登録図書館が選択されていること - 会員カードNoに対応する電話番号、生年月日が正しいこと（図書館会員管理システムへ照会して確認） - 登録パスワードとパスワード確認が一致していること・Web会員IDの情報が正しい内容の場合、 Web会員ID登録確認画面でWeb会員ID登録を確定できる・ Web会員ID登録を確定すると、 Web会員ID情報がWebシステムに登録される・（参考）ログインすることでスマホでの会員情報表示、Web予約、貸与中書籍確認等ができる ※別論点仕様テーマ：会員登録の実施 79 確定＜Web会員ID登録確認画面＞登録図書館：XXX 会員カードNo：XXX 登録しますか？＜Web会員ID登録完了＞登録を完了しましたキャンセル図書館システムWeb （図書館端末でも同じ） Web会員ID登録

仕様（Vol3）：テスト設計での見直し結果 2．Web向け会員ID登録・Web会員ID登録画面を用意する ※必要な情報は、下記の画面構成を参考・図書館の端末画面からもWeb会員ID登録画面へ移動できる。Web会員登録画面ではヘルプを用意する・Web会員ID登録画面では以下を確認して、Web会員ID登録確認画面へ移行する - 旧カードNo（5桁の場合）には、カードの対象とする登録図書館が選択されていること - 会員カードNo（5桁の場合、登録図書館との組合せ）が登録していること、カード期限が有効であること
- 会員カードNoに対応する電話番号、生年月日が正しいこと（図書館会員管理システムへ照会して確認）会員カードNo、電話番号は半角数字のみでハイフンなし入力とする、生年月日は選択形式 - 登録パスワードとパスワード確認が一致していること・Web会員IDの情報が正しい内容の場合、 Web会員ID登録確認画面でWeb会員ID登録を確定できる・Web会員ID登録を確定すると、 Web会員ID情報がWebシステムに登録される・（参考）ログインすることでスマホでの会員情報表示、Web予約、貸与中書籍確認等ができる ※別論点仕様テーマ：会員登録の実施 80 確定＜Web会員ID登録確認画面＞登録図書館：XXX 会員カードNo：XXX 登録しますか？＜Web会員ID登録完了＞登録を完了しましたキャンセル図書館システムWeb （図書館端末でも同じ） Web会員ID登録登録パスワード：パスワード確認：（6桁Noのカード時）会員カードNo：登録＜Web会員ID登録画面＞（5桁Noのカード時）登録図書館：会員カードNo：電話番号：生年月日：？？半角半角選択半角選択

仕様テーマ：会員登録の実施＜テスト向け情報（全体検討）＞テスト全体の検討例（少し俯瞰して考える） A) 仕様に対するテスト 1．新規会員登録 2． Web向け会員ID登録 B) 業務フロー、シナリオに対するテスト
以下業務バリエーションを考慮したテストテスト向け会員可能な住所 Z市＋近隣町上記以外会員状況既に会員、Web会員ID登録済既に会員、Web会員ID登録なしまだ会員ではない会員登録/カード作成場所図書館 Web（将来検討） Web会員IDの登録場所図書館端末にて会員が自分で登録会員が自分でWeb上で登録

仕様テーマ：会員登録の実施＜テスト向け情報＞ B) 業務フロー、シナリオに対するテスト業務バリエーションを考慮したテスト：以下シナリオをベースにテストをする・会員対象ではない人が会員登録せず/できずに帰っていただくケース（システム対象外）・既に会員の人がWeb会員IDを登録する（PC）・既に会員の人がWeb会員IDを登録する（スマホ）・新規会員登録後、図書館で登録する（図書館端末）・新規会員登録後、Web登録なしでカードのみで運用
テスト向けフィードバック・職員の手間削減で手順1つ渡して済ませたい・PCと図書館端末のUIを一致させるのを推奨・PCとスマホ双方のWeb会員ID登録手順が欲しい会員可能な住所 Z市＋近隣町上記以外会員状況既に会員、Web会員ID登録済既に会員、Web会員ID登録なしまだ会員ではない会員登録/カード作成場所図書館 Web（将来検討） Web会員IDの登録場所図書館端末にて会員が自分で登録会員が自分でWeb上で登録 →PCとスマホからの登録を想定シナリオをテストで再検討して活用する

仕様テーマ：会員登録の実施＜テスト向け情報＞ B) 業務フロー、シナリオに対するテスト業務バリエーションを考慮したテスト：以下シナリオをベースにテストをする・会員対象ではない人が会員登録せず/できずに帰っていただくケース（システム対象外）・既に会員の人がWeb会員IDを登録する（PC）・既に会員の人がWeb会員IDを登録する（スマホ）・新規会員登録後、図書館で登録する（図書館端末）・新規会員登録後、Web登録なしでカードのみで運用
テスト向けフィードバック・職員の手間削減で手順1つ渡して済ませたい・PCと図書館端末のUIを一致させるのを推奨・PCとスマホ双方のWeb会員ID登録手順が欲しい会員可能な住所 Z市＋近隣町上記以外会員状況既に会員、Web会員ID登録済既に会員、Web会員ID登録なしまだ会員ではない会員登録/カード作成場所図書館 Web（将来検討） Web会員IDの登録場所図書館端末にて会員が自分で登録会員が自分でWeb上で登録 →PCとスマホからの登録を想定運用を考慮したフィードバック例会員ID登録の手順はA4用紙1枚程度にまとめる＋Webとスマホ双方の手順があるとよい

仕様テーマ：会員登録の実施参考：・テストを検討する際には一度SaPID/RDRAを含めて全体の情報を見直してテストを考えることで、検討で抜けている仕様や必要なサービスや運用補足用にやる必要があるタスクなりが見えてきます。説明補足 84 84 窓口会員期限管理
会員登録 [会員管理：業務] 会員カードを作成する図書館員 Web会員ID を発行する会員 [会員登録：BUC] 会員会員登録会員登録条件会員登録会員登録

まとめ：今回の流れ今回の進め方の参考目的を特定する主要なシナリオを特定するアプリケーションの全体像を描く主要な課題を特定する解決策の候補
を出す Vol1/2で具体的なイメージを描きながら特定していくペーパープロトタイプで課題につながる部分を描いて呼び水とする段階的に具体的な内容を描く課題の共有、トレードオフのためにいくつか方法を用意して議論をすると意見が出やすい上位の要件や情報が存在しない場合は安達さん神崎さんのお話を聞きましょう 85 RDRAで範囲を絞り込んだうえで業務に対するバリエーションを考慮しつつシナリオを詳細化する

まとめ：今回の流れ今回の進め方の参考→とある書籍とは「実践ソフトウェアエンジニアリング（第9版）」でした。第4 章推奨のプロセスモデルの内容です。 86

まとめ：今回の流れ第4 章推奨のプロセスモデルは結構面白いので興味があれば立ち読みでもしてください。 87 プロジェクト構想要求エンジニアリング
初期アーキテクチャ設計プロジェクトリソース見積り 1stプロトタイプ構築プロトタイプ評価継続可否判断 Go/No Go決定プロジェクト終了システムの洗練プロトタイプリリースソフトウェアメンテナンススコープ再定義次のプロトタイプ構築 1stプロトタイプの構築プロトタイプ評価と Go/No Go決定システムのリリース、次のプロトタイプ構築注：こちらは、実践ソフトウェアエンジニアリング（第9版）第4章推奨のプロセスの説明に独自解釈を加えたものです

まとめ：今回行った段階（イテレーション）と進み方ユーザー側、開発側ともに「確信度」を高める進め方を行ってます。 ※今回は一例につき、繰り返し検討を続けるケースもあります。開発者確信度ユーザー確信度 Vol1 Vol2 Vol3
88 プロトタイピングな仕様開発者ユーザー運用実現

まとめ：今回行った段階（イテレーション）と進み方ユーザー側、開発側ともに「確信度」を高める進め方を行ってます。 ※今回は一例につき、繰り返し検討を続けるケースもあります。オレンジのように進む場合もあります… 開発者確信度ユーザー確信度 Vol1 Vol2
Vol3 89 プロトタイピングな仕様開発者ユーザー運用実現

まとめ：最終的な仕様最終的な仕様はいわゆる「INVEST」を達成しやすい内容となっております。 ※半分くらいはSaPIDやRDRAがあることによって達成しやすくなります。 Ⅰ：Independent 独立している RDRAにより業務としての分割がされ、仕様を検討する際にシステムを考慮することで独立性が確保しやすくなります。（RDRAにおける影響分析の技術を使うこともあります）Ｎ：Negotiable 交渉可能である
ユーザー側にヒアリングした結果がすべて入ってます。「実現方針」に運用対処の範囲を含め調整結果をまとめます。Ｖ：Valuable 価値がある SaPIDやRDRAの検討＋「背景」や「課題・やりたいこと」を明記して確認することで、無意味な開発は減ります。Ｅ：Estimable 見積可能である仕様としてまとめつつ、テーマを分割することで個々の仕様単位でユーザーストーリー化し見積りできます。Ｓ：Small 小さい仕様としてまとめつつ、テーマを分割および仕様の検討段階を分割することで、適度なサイズにすることが可能です。Ｔ：Testable テスト可能である「テスト向け情報」を作るプロセスが入ってます。また、「検討・検証シナリオ」も最後にテスト向け情報になります。 90

まとめ：いわゆるプロダクトバックログとの関連性アジャイル風の開発としてのプロダクトバックログとの関連性としては、だいたい「エピック→（仕様化検討）→プロダクトバックログ」という感じの運用になります。今回の仕様に対する各概念およびプロダクトバックログの構成の例を以下に紹介します。 ※（当然ですが）必要に応じてスプリントバックログはさらに分割して作業します。 91 プロトタイピングな仕様 1．新規会員登録 2．Web向け会員ID登録【エピック】
会員登録を可能とする【PBI】新規会員登録（仕様参照）【PBI】 Web向け会員ID登録（仕様参照）仕様化検討仕様内容と分割可能かを考慮してプロダクトバックログアイテム（PBI）単位に分けておきます

まとめ：（参考）仕様に対するレビュー観点、チェックリスト開発者側は「仕様」「テスト向け情報」だけ見れば開発ができるようになる方が理想です。仕様を記述する際には、以下のような項目でチェックすることが可能です。前提：仕様ドキュメントのテンプレートにて事前検討をしたうえで仕様をまとめている。 ――――――――――――――――――――――――――――――――――――――――――――――――― チェックリスト/レビュー観点： □ 箇条書き単位で、1つずつふるまいを表現できているふるまいを考慮した設計もしくはテスト検討があると分割整理とレビューがやりやすくなります □
ロジック（ビジネスルール）がある場合には、デシジョンテーブルやCFD、CEGなどを用いて表現している □（できれば）各箇条書きがテストケースと対応できる単位になっている □ 必要に応じてデータ構造がクラス図や開発者が分かる絵、リストなどで表現できている ――――――――――――――――――――――――――――――――――――――――――――――――― ※処理分割や細かいデータ構造は開発側で決めたほうがよいケースも多く、詳細さはチームにより変わります。ロジックまでデシジョンテーブルやCFDで明確にしたうえで詳細は開発者に任せることも多数あります。 92

まとめ：実際の進め方パイプライン的に仕様→実装につないで開発を進めていきます。場合によっては開発結果をプロトタイプと捉えて、実データを登録して業務の妥当性を確認します。要件定義開発フィードバック業務①：会員登録業務②：貸し出し業務③：Web会員申請
プロトタイプに会員登録のデータを登録し業務の流れを評価 ※アジャイルを考慮した開発の流れの例仕様化 RDRA要件定義の整理必要に応じて更新業務①：会員登録実装・テスト業務②：貸し出し実装・テスト必要に応じてフィードバックフィードバックフィードバック 93 フレームワーク選定や全体の課題検討 SaPIDによる価値分析価値分析状況によりフィードバック

注意事項：ペーパープロトタイピングにおける限界点と注意点限界点・「現状からの変化」および「目先の変化」までがペーパープロトタイプでやりやすい範囲です。・逆に「今までなかったもの」はペーパープロトタイプより、動くプロトタイプを推奨します。・一度動くプロトタイプを作ったうえで、目先の改善検討はペーパープロトタイプで議論はやりやすいです。・ペーパープロトタイプは、1つの論点に対する「目先の変化」までの議論までは向いてますが、例えば「修正後を見据えた追加改善案」までは議論がやりづらいです。 →今回の例では、「会員登録の検討結果を考慮して会員検索の仕組みを考える」というような範囲。・1つ先の修正が決まり次第システムを構築・修正し、評価しながら次を考えるという進め方を推奨します。注意点
・ペーパープロトタイプは、論点単位で議論しやすいイテレーティブなプロセスを作って活用ください。・説明する人によってはノイズとなりそうな意見が多くなりすぎて、逆に進まなくなるケースがあります。 →適切に論点を分けて仕分けをするファシリテーション、論理思考の技術も必要になります。開発仕様化会員登録：仕様会員登録：開発会員検索照会：仕様会員Web登録：仕様貸し出し：開発評価評価貸し出し：仕様・・・ 94

まとめ：上位のテスト参考：SaPID/RDRAからのテスト今回のようなSaPIDやRDRAの情報がある際には以下のように役立てることができます・（中間で紹介しているように）テスト検討のタイミングで内容を見直すことで俯瞰的なテスト計画/テスト（スイートアーキテクチャ？）設計において検討が抜けていないかに気づく。＜SaPID成果物の活用＞・SaPIDの成果物を用いて、テスト観点を導出する →例えば、パフォーマンスが必要な点、セキュリティの重要性などが導出できる・ SaPIDの成果物を用いて、テスト結果の十分性を判断する
→シナリオとして「図書館員の負担が減りそうか？」という判断で妥当性の判断ができるようになる＜RDRA成果物の活用＞・RDRAの成果物の業務構成をテスト全体の設計構造と同一にする →RDRAの成果物は業務単位での適切な分割がやりやすく、テスト構造と一致させても使うことができる・RDRAの成果物から業務の典型的シナリオを導出してリグレッションテストなどに活用する →紹介した仕様化方法だけでは「業務単位」のテストが導出されるので、全体を考慮したテスト検討が役立つ・RDRAの成果物モデルとテストのトレーサビリティが取れるようにモデル化・ツール連携する →例えばEnterprise Architectを用いてモデル化し、TestRailといったテストツール構造とリンクします 95

まとめ：テスト担当者の出番テスト担当者は以下のような箇所でスキルが役立つはずです。・業務バリエーションと業務シナリオを整理及び提案する・仕様に対するテスト設計をして仕様へのフィードバックをする（仕様がいったん完了後にテスト設計の時間を作る、もしくは並列で進める）・SaPIDやRDRA成果物から開発側が忘れてそうな観点（セキュリティやパフォーマンス等）を提案する 96

参考：使用している技術の参考文献 ▪関連資料・RDRA+プロトタイピングおよび仕様化時に役立つ技術、事例紹介 https://www.slideshare.net/NoriyukiMizuno/rdra-236183496 ・伝統的食品工場エンジニアリング会社が挑むDXへのビジネスアイデアを RDRAによる要件定義でプロダクト開発へつなぐ～Side：要件定義 https://www.slideshare.net/NoriyukiMizuno/dxrdraside ▪プロトタイピング関連・書籍：デザイナーのためのプロトタイピング入門 ▪PSFit関連技術（仕様テンプレートの前半に対応）
・書籍：正しいものを正しく作る ▪流れとプロセス/ソフトウェアエンジニアリング・書籍：実践ソフトウェアエンジニアリング（第9版） ▪CFD（Cause Flow Diagram）およびデシジョンテーブル・書籍：ソフトウェアテスト技法ドリル・CFDツール（EAアドイン）：https://www.sparxsystems.jp/products/EA/tech/CFD.htm ・CFD紹介： https://softest.jp/?p=100 ▪図書館情報の参考・墨田区立図書館： https://www.library.sumida.tokyo.jp/ 97

おまけ：最終的な仕様 ※テスト込みで14P程度 98 最終的にはこの程度でまとめますが、中間での議論が大量に前段階で存在します

仕様テーマ：会員登録の実施 99 背景：・図書館システムの導入に対して事前に会員登録を行う方針とする・システム導入前から使用している会員および会員カードについてはそのまま使えるようにする・Webシステムを使えるようにするために、会員にWeb会員ID（パスワードつき）を付与したい・前提として、すでに会員カードの登録している会員がいる状況、新システムが不要な人もいる・前提として、2年前から会員は2年に1度更新する仕組みとしている課題・やりたいこと：・新規登録者には番号（6桁）付きの会員カードを発行したい。既存は5桁のIDで新規システムでは一桁増やす
完全新規の場合、図書館もしくはWebで会員申請、図書館で新規会員カードの発行する・現在の図書館IDもWebで登録可能とする。登録時に5桁のIDの場合には登録図書館名とセットで扱う。・すでに会員で会員カードを持っていて、Webを使わない方は元の会員カードで書籍貸与ができる・すでに会員で会員カードを持っている人は、利用者本人がWeb画面でWeb会員ID登録ができる（新システム間相互は過去のカードを持つ人もWeb会員ID登録ができる）・Web会員IDを登録することで、スマホ（ブラウザ/アプリ）で表示してカードの代わりに使用できるスマホで会員ID6桁およびバーコードの表示ができるようにする。最初はブラウザのみで運用・Web会員IDの登録をすることで、図書館横断でカードが利用できるようになる＜別論点の課題＞・会員カードを忘れる人が多いので、スマホでも貸出ができる仕組みを作る（貸出処理は別仕様で整理）・既会員で会員カードを持っている人が継続的に運用ができるようにテストで確認・会員情報を変更するような場合にWebから可能にする方法は別途整理する

まだ会員ではない会員登録申請場所図書館 Web（将来検討） Web会員ID場所図書館端末にて会員が自分で登録会員が自分でWeb上で登録テストに使用する代表シナリオ＜会員登録を図書館で実施するとき＞ #1 すでに会員の人が図書館端末にて自分で会員IDを登録 #2 すでに会員の人が自分でWeb上で会員IDを登録 #3 まだ会員で無く、図書館で会員登録＋Webで会員ID登録 Web登録は将来のイテレーションで検討シナリオはテストで再活用

仕様テーマ：会員登録の実施 101 検討・検証シナリオ：仮画面案（ペーパープロト）：新規会員登録名前：住所：電話番号：性別：生年月日：
登録（確認画面を用意）カード発行への導線も用意する（運用）カードNoの使い方、会員IDの登録方法を伝える確定図書館システムWeb （図書館端末でも同じ）会員ID登録登録できない住所は選択式なので入力できない →登録は登録はZ市、AA町、BB村の3つ＜会員登録画面＞＜Web会員ID登録確認画面＞ Web会員IDはカードNo ログイン時に5桁IDの場合に登録図書館も入力すること個人設定は確認不可能 Z市▼ ＜Web会員ID登録完了＞登録を完了しました Web会員ID登録時に生年月日と電話番号のみを使用してして照会する ※照会のみ、保存しないキャンセル図書館員用の端末登録パスワード：パスワード確認：（6桁Noのカード時）会員カードNo：登録＜Web会員ID登録画面＞（5桁Noのカード時）登録図書館：会員カードNo：電話番号：生年月日：？？登録図書館：XXX 会員カードNo：XXX 登録しますか？

仕様テーマ：会員登録の実施 102 検討・検証シナリオ：仮構成案（ペーパープロト）：会員登録図書館員ユーザー情報＜Webシステム＞バーコード会員No
XXXXXX 会員期限 2023/03/15 会員会員ID登録ユーザ情報を確認する画面はない ID登録時照会のみ（別で検討）Web予約、貸与中書籍の確認ができる申請用紙（手書き）電話番号と生年月日も照会のみでデータは置かない＜図書館会員管理システム＞個人情報はこちらで管理 IDの追加スマホでカード代替（仮）メモ：Web登録なしというオプションもあったほうがよい？ →開発中追加も可能

仕様テーマ：会員登録の実施 103 ※ひとまず、図書館での新規会員登録/カード発行を開発する。分割テーマ： 1．新規会員登録 2．Web向け会員ID登録実現方針（1．新規会員登録）：・会員ではない人は必ず図書館で新規会員登録を行う・（運用）会員希望者が申請用紙に記入して提出し、図書館員が登録を行う・（運用）証明書を提出して、登録者を確認の上会員登録を行う
・会員登録情報を入力後、会員カードNo（新規は6桁）付きの会員カードを発行する・（運用）会員IDの登録方法は、個別に新規会員に説明（説明用紙などを作成してもらう）実現方針（2．Web向け会員ID登録）：・会員カードNoを用いてWeb会員ID登録を可能とする・既会員も既存の会員カードNoでWeb会員ID登録ができる。この場合、登録図書館情報を使用する・Webの画面と図書館端末でも既会員のWeb会員ID登録を可能とする（図書館端末もWebと同一画面）・（参考）Webシステムでは、氏名や住所などの個人情報は取り扱わないようにする →多少使い勝手を下げても情報漏洩が無い仕組みにする・（参考）Webでは予約・貸与中の書籍情報確認のみでもよい・（参考）スマホではカードの代替となる会員Noとバーコード表示ができればよい

仕様： 1．新規会員登録・会員登録画面を用意する必要な情報は、下記の画面構成を参考のこと・全体メニューから会員登録画面へ移動できる・住所はZ市とAA町、BB村の3つのみ選択できる形式とする・電話番号は半角数字のみでハイフンなし入力とする、生年月日は選択形式・（その他入力形式のルールは省略）・登録ボタンを押すことで会員登録確認・カード発行画面へ移行する・確認画面で、確認後に会員No採番とカード発行を可能とする
・カード発行時に会員情報を図書館会員管理システムへ追加する・カード発行時にWebシステムへ会員ID（≒会員No）を追加し、 Webからの会員ID登録可能とする・カード発行失敗時のために再発行操作を可能とする仕様テーマ：会員登録の実施 104 名前：住所：電話番号：半角数字性別：生年月日：選択確認＜会員登録画面＞ Z市▼ 名前：XX XXX 住所：Z市XXX 電話番号：0123456789 性別：男女生年月日：XXXX/XX/XX カード期限：2023/03/15 カード発行＜会員登録確認・カード発行画面＞新規会員登録＜全体メニュー＞・・・キャンセル会員No 採番・カード発行機でカード発行・図書館会員管理システムへ会員情報を追加・Webシステムへ会員ID追加会員カードを発行しました Webシステムへ登録しました会員No123456 カード再発行終了

仕様： 2．Web向け会員ID登録・Web会員ID登録画面を用意する ※必要な情報は、下記の画面構成を参考・図書館の端末画面からもWeb会員ID登録画面へ移動できる。Web会員登録画面ではヘルプを用意する・Web会員ID登録画面では以下を確認して、Web会員ID登録確認画面へ移行する - 旧カードNo（5桁の場合）には、カードの対象とする登録図書館が選択されていること - 会員カードNo（5桁の場合、登録図書館との組合せ）が登録していること、カード期限が有効であること
- 会員カードNoに対応する電話番号、生年月日が正しいこと（図書館会員管理システムへ照会して確認）会員カードNo、電話番号は半角数字のみでハイフンなし入力とする、生年月日は選択形式 - 登録パスワードとパスワード確認が一致していること・Web会員IDの情報が正しい内容の場合、 Web会員ID登録確認画面でWeb会員ID登録を確定できる・Web会員ID登録を確定すると、 Web会員ID情報がWebシステムに登録される・（参考）ログインすることでスマホでの会員情報表示、Web予約、貸与中書籍確認等ができる ※別論点仕様テーマ：会員登録の実施 105 確定＜Web会員ID登録確認画面＞登録図書館：XXX 会員カードNo：XXX 登録しますか？＜Web会員ID登録完了＞登録を完了しましたキャンセル図書館システムWeb （図書館端末でも同じ） Web会員ID登録登録パスワード：パスワード確認：（6桁Noのカード時）会員カードNo：登録＜Web会員ID登録画面＞（5桁Noのカード時）登録図書館：会員カードNo：電話番号：生年月日：？？半角半角選択半角選択

仕様テーマ：会員登録の実施＜テスト向け情報（全体検討）＞テスト全体 A) 仕様に対するテスト 1．新規会員登録 2．Web向け会員ID登録 B) 業務フロー、シナリオに対するテスト以下業務バリエーションを考慮したテスト
テスト向け会員可能な住所 Z市＋近隣町上記以外会員状況既に会員、Web会員ID登録済既に会員、Web会員ID登録なしまだ会員ではない会員登録申請場所図書館 Web（将来検討） Web会員ID場所図書館端末にて会員が自分で登録会員が自分でWeb上で登録

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト 1．新規会員登録：仕様に対するテストの全体案テスト向け名前：XX XXX 住所
：Z市XXX 電話番号：0123456789 性別：男女生年月日：XXXX/XX/XX カード期限：2023/03/15 カード発行＜会員登録確認・カード発行画面＞新規会員登録＜全体メニュー＞・・・キャンセル・会員No採番・図書館会員管理システムへ会員情報を追加・Webシステムへ会員ID追加・カード発行機でカード発行会員登録チェックカード期限設定登録日カード発行会員No採番会員情報の図書館会員管理システムへの追加 Webシステムへの会員ID追加会員DB WebDB カード発行機入力：会員情報名前：住所：電話番号：半角数字性別：生年月日：選択確認＜会員登録画面＞ Z市▼

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：仕様に対するテスト全体案テスト向け図書館システムWeb （図書館端末でも同じ）
会員ID登録 Web会員ID登録画面チェック新旧カード会員No確認会員照会期限確認会員DB パスワード確認 WebDB 入力：会員 ID情報 Webシステムへの会員・パスワード登録 WebDB ※その他初期データ作成時は確認確定登録図書館：XXX 会員カードNo：XXX 登録しますか？＜Web会員ID登録完了＞登録を完了しましたキャンセル＜Web会員ID登録確認画面＞登録パスワード：パスワード確認：（6桁Noのカード時）会員カードNo：登録＜Web会員ID登録画面＞（5桁Noのカード時）登録図書館：会員カードNo：電話番号：生年月日：？？

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：Web会員ID登録チェックのCFD（Cause Flow Diagram）テスト設計テスト向け会員No確認（WebDB）
会員カードNo登録済入力NG 通知新旧カード会員No確認会員照会期限確認会員DB パスワード確認 WebDB 入力：会員 ID情報 Webシステムへの会員・パスワード登録 WebDB ※その他初期データ作成時は確認会員カードNoがない会員照合（会員DB）入力の不正値カードNo、電話番号、生年月日不整合カード期限確認カード期限内カード期限切れ会員期限 NG通知カードNo、電話番号、生年月日が整合入力パスワード確認登録OK 確認画面へ入力の不正値登録内容と確認内容が異なる登録内容と確認内容が整合 Password NG通知 NG通知の適切さも議論することが可能照合対象データの形式をここで検討できる新旧カード確認入力の不正値カード情報 NG通知新旧カード併用のわかりづらい点を通知でフォロー新カードの6桁No 旧カードの5桁No ＆登録図書館の入力

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：会員ID登録チェックのCFD （Cause Flow Diagram）テスト設計テスト向け

仕様テーマ：会員登録の実施＜テスト向け情報＞ A) 仕様に対するテスト 2． Web向け会員ID登録：会員ID登録チェックのCFDテスト設計 ※CFDから生成したデシジョンテーブルテスト向け Enterprise Architect＋CFDアドインを使用
ツールの活用でDTまで作成も可能

仕様テーマ：会員登録の実施＜テスト向け情報＞ B) 業務フロー、シナリオに対するテスト業務バリエーションを考慮したテスト：以下シナリオをベースにテストをする・会員対象ではない人が会員登録せずに帰っていただくケース（システム対象外）・既に会員の人が会員IDを登録する（PC）・既に会員の人が会員IDを登録する（スマホ）・新規会員登録後、会員IDをすぐに登録する（図書館端末）・新規会員登録後、Web登録なしでカードのみで運用
テスト向けフィードバック・職員の手間削減で手順1つ渡して済ませたい・PCと図書館端末のUIを一致させるのを推奨・PCとスマホ双方の会員ID登録手順が欲しい会員可能な住所 Z市＋近隣町上記以外会員状況既に会員、Web会員ID登録済既に会員、Web会員ID登録なしまだ会員ではない会員登録/カード作成場所図書館 Web（将来検討） Web会員ID場所図書館端末にて会員が自分で登録会員が自分でWeb上で登録 →PCとスマホからの登録を想定

おしまい！

現状分析→価値開発→仕様化＆テスト設計の展開事例解説：仕様＆テスト編

現状分析→価値開発→仕様化＆テスト設計の展開事例解説：仕様＆テスト編

More Decks by みずのり

Other Decks in Design

Featured

Transcript