現状分析→価値開発→仕様化 ＆テスト設計の展開事例解説 (3回シリーズ) 概説 Copyright © Kenji Adachi / Software Quasol, All Rights Reserved 1

価値につながる要件・ 仕様からテストを考える 当会では、 ソフトウェアテストシンポジウム(JaSST)2021東京 チュートリアル1 で実施した内容（下記の表題）を一部見直しをしたうえで詳細解説します。 http://www.jasst.jp/symposium/jasst21tokyo/details.html#F3 水野 昇幸 （TOC/TOCfE北海道） 2 安達 賢二 （Software Quasol） 神崎 善司 （バリューソース） Copyright © Kenji Adachi / Software Quasol, All Rights Reserved

情報量が多いため3回に分けて解説 ①回目：12/9（木） 課題の把握とAs-Isの可視化＜SaPID×RDRA＞ https://sapidcasestudy.connpass.com/event/229458/ ②回目：12/15（水） To-Beに向けた要求の整理と要件化＜SaPID×RDRA＞ https://sapidcasestudy.connpass.com/event/229689/ ③回目：12/21（火）＜仕様化×テスト設計＞ 要件から仕様への落とし込みとテスト設計 https://sapidcasestudy.connpass.com/event/229694/ 3 Copyright © Kenji Adachi / Software Quasol, All Rights Reserved

新図書館システム 既存図書館システム IT System As-isシステム可視化 RDRA 【神崎】 Vision Mission Concept IT Specification IT Requirement Value Outcome Result Operation To-beシステム可視化 RDRA 【神崎】 価値 要件 仕様 To-beシステム 仕様化with Test 【水野】 4 As-is業務･事業可視化 SaPID 【安達】 To-be業務･事業開発 SaPID 【安達】 当アプローチの全体像 As-is To-be Copyright © Kenji Adachi / Software Quasol, All Rights Reserved ① 回 目 ② 回 目 ③ 回 目

この発表に至った問題意識 5 Copyright © Kenji Adachi / Software Quasol, All Rights Reserved

問題提起 システム開発の全体像を示す「Vモデル」の左上は「要求分析」また は「要求定義」となっています。このモデルが示す通り、システムの 開発は要求分析や要求定義からスタートする、テスト要求分析やテス ト設計も、主に要求仕様の情報から検討を開始し、組み立てていくの が当然のように感じています。 ところが、システムの要求定義には主に分析の”結果”が書かれ、要求 定義としてのまとめ方、示し方、構成される情報も組織やチームに よってまちまちです。 その結果、システム要求が導出された経緯や意図、受け取り方に違い が生じ、開発過程やテスト要求分析、設計時に別途その確認や調整が 必要になったり、利用者が直接システムに触れる段階で思わぬ手戻り に発展するケースもあります。 要求定義 方式設計 詳細設計 実装 単体Test 結合･ｼｽﾃ ﾑTest 受入Test ？？ 6 Copyright © Kenji Adachi / Software Quasol, All Rights Reserved

発表概要 当発表では、架空の「図書館システム開発案件」を題材としてわれわ れが試行した、既存図書館システムの現状分析、新しい図書館運営の 狙いや提供する価値の明確化、それを実現する新図書館システムの要 求定義を出発点に、要件、仕様をベースとしたテスト要求分析～テス ト設計の事例により 要求定義とその背後に存在する情報は、設計開発、テスト要求分析・設計過 程のどこに、どのようにつながるのか？ テストを効果的に組み立てるために、要求定義とその背後に存在する活動で 明らかにしておくべき事項とは何か？ これまでのテストや開発過程で発生しがちな問題のうち解決できることは何 か？ 等を共有したいと思います。 要求定義 ？？？ ？？ 要求の理由や根拠？ 要求定義はどう表現 すればよい？ 仕様化とテスト設計 7 Copyright © Kenji Adachi / Software Quasol, All Rights Reserved

よくありがちなRFP （発行： Z市図書館） 1.本書の目的 この提案依頼書（Request For Proposal：以下、RFPとする）は、Z市図書館シス テムによる図書館運営の効果・効率改善の提案を依頼するためのものである。 2.背景 現在のZ市図書館システムは、1998年に初度リリースされた。 当時としては画期的なバーコードリーダを活用した受付機能や会員カード発行機 能などを備えているが、これら基本機能・使用機器は変えずにこれまで多くの改 修を重ねてきた。 20数年が経過して、老齢者の増加等の人口動態やIT技術動向と市民浸透度、およ び地域における図書館の位置づけが変化している。 8 Copyright © Kenji Adachi / Software Quasol, All Rights Reserved

3.現状の課題・問題 現在のZ市図書館システムには、現在下記のような問題点が存在する。 □使用機器や機能の陳腐化が目立つ。 →近年のIT技術動向（最新の読み取り装置・AI・IoT・ビックデータ分析など）に マッチした機能や設備を搭載する必要がある。 □近年電子書籍も市場に展開されているが現状は当図書館では扱えていない。 □個人情報流出などのセキュリティ事故の発生を防止する必要がある。 □受付機能を中心に図書館職員作業中割込みが多い等、システムの利便性向上が 望まれる。 □図書館運営費、システム維持費を含めた経費を減少させる必要がある。 9 前頁のつづき Copyright © Kenji Adachi / Software Quasol, All Rights Reserved

4.募集（提案）の目的 以上の背景、現状の課題・問題点を踏まえ、運営効果と効率を向上させる新Z 市図書館システムに刷新する提案を募集する。 5.提案書提出期限 2022年3月末日 2023年4月第一営業日～稼働開始を前提とする。それまでに新システムを開発 し、必要な機器類の調達～設置を終え、稼働を開始することを求める。 6.提案依頼内容 提案書に盛り込むことを期待する情報は以下である。 なお、提案に際して他に必要な事項や情報があればそれを追加することを制限 しない。 ・会社組織情報：貴社情報 ・提案システム概要 ・システム構成 ・プロジェクトスケジュール ・プロジェクト体制図 ・・・・・・ 10 前頁のつづき Copyright © Kenji Adachi / Software Quasol, All Rights Reserved

RFPをそのまま鵜呑みにして開発する？ • 依頼者は「わかっているようでわかっていない」ことも • 要件がなかなか決まらない、開発過程で要件や仕様がコロコロ変わる。 • 依頼者はRFPに何を書いてよいかわからないことも多い。 • 既存システムを保守･運用しているベンダーがRFPを代筆している場合 もある。 • 流行言葉の列挙、一般論で固めた「それっぽい＆よくあるRFP」やベ ンダーが有利になる歪んだRFPを書くことも多い。 • 図書館システムのRFPでは、「図書館システムの課題」は書かれるが 「図書館の課題」は書かれないことも多い。 • RFPや依頼者の指示の背景に何があるのか？そして本当に求め られることは何か？を読み解き、関係者で共有して開発をすす める必要がある。 11 Copyright © Kenji Adachi / Software Quasol, All Rights Reserved

ありがちな機能提案 ～本当の問題･課題にヒットするのか？ 例えば、流行の手段を列挙して魅力的（？）に見せるだけ？ □AI連動-嗜好性分析によるおススメ図書提案 □外部図書情報との連携による各種図書人気ランキングや 話題図書情報提供 例：各種受賞情報（芥川賞･直木賞･本屋大賞･マンガ大賞等） □ICタグによる書籍管理 □コンビニ受取／返却サービス 12 ぼんやりしたRFPにありがちな機能提案で返すのは？？ Copyright © Kenji Adachi / Software Quasol, All Rights Reserved

現状分析→価値開発→仕様化 ＆テスト設計の展開事例解説 (3回シリーズ) 概説 Copyright © Kenji Adachi / Software Quasol, All Rights Reserved 13 END