2021/12/9・15・21に開催した「現状分析→価値開発→仕様化&テスト設計の展開事例解説(3回シリーズ)」の1回目で解説した概説資料です。 当事例の問題意識、RFPによる新システム化の問題点など。 https://sapidcasestudy.connpass.com/event/229458/
現状分析→価値開発→仕様化&テスト設計の展開事例解説(3回シリーズ) 概説Copyright © Kenji Adachi / Software Quasol, All Rights Reserved1
View Slide
価値につながる要件・仕様からテストを考える当会では、ソフトウェアテストシンポジウム(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/3Copyright © Kenji Adachi / Software Quasol, All Rights Reserved
新図書館システム既存図書館システムIT SystemAs-isシステム可視化RDRA【神崎】VisionMissionConceptITSpecificationITRequirementValueOutcomeResultOperationTo-beシステム可視化RDRA【神崎】価値要件仕様To-beシステム仕様化with Test【水野】4As-is業務・事業可視化SaPID【安達】To-be業務・事業開発SaPID【安達】当アプローチの全体像As-is To-beCopyright © Kenji Adachi / Software Quasol, All Rights Reserved①回目②回目③回目
この発表に至った問題意識5Copyright © Kenji Adachi / Software Quasol, All Rights Reserved
問題提起システム開発の全体像を示す「Vモデル」の左上は「要求分析」または「要求定義」となっています。このモデルが示す通り、システムの開発は要求分析や要求定義からスタートする、テスト要求分析やテスト設計も、主に要求仕様の情報から検討を開始し、組み立てていくのが当然のように感じています。ところが、システムの要求定義には主に分析の”結果”が書かれ、要求定義としてのまとめ方、示し方、構成される情報も組織やチームによってまちまちです。その結果、システム要求が導出された経緯や意図、受け取り方に違いが生じ、開発過程やテスト要求分析、設計時に別途その確認や調整が必要になったり、利用者が直接システムに触れる段階で思わぬ手戻りに発展するケースもあります。要求定義方式設計詳細設計実装単体Test結合・システムTest受入Test??6Copyright © Kenji Adachi / Software Quasol, All Rights Reserved
発表概要当発表では、架空の「図書館システム開発案件」を題材としてわれわれが試行した、既存図書館システムの現状分析、新しい図書館運営の狙いや提供する価値の明確化、それを実現する新図書館システムの要求定義を出発点に、要件、仕様をベースとしたテスト要求分析~テスト設計の事例により要求定義とその背後に存在する情報は、設計開発、テスト要求分析・設計過程のどこに、どのようにつながるのか?テストを効果的に組み立てるために、要求定義とその背後に存在する活動で明らかにしておくべき事項とは何か?これまでのテストや開発過程で発生しがちな問題のうち解決できることは何か?等を共有したいと思います。要求定義??? ??要求の理由や根拠? 要求定義はどう表現すればよい?仕様化とテスト設計7Copyright © Kenji Adachi / Software Quasol, All Rights Reserved
よくありがちなRFP(発行: Z市図書館)1.本書の目的この提案依頼書(Request For Proposal:以下、RFPとする)は、Z市図書館システムによる図書館運営の効果・効率改善の提案を依頼するためのものである。2.背景現在のZ市図書館システムは、1998年に初度リリースされた。当時としては画期的なバーコードリーダを活用した受付機能や会員カード発行機能などを備えているが、これら基本機能・使用機器は変えずにこれまで多くの改修を重ねてきた。20数年が経過して、老齢者の増加等の人口動態やIT技術動向と市民浸透度、および地域における図書館の位置づけが変化している。8Copyright © 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や依頼者の指示の背景に何があるのか?そして本当に求められることは何か?を読み解き、関係者で共有して開発をすすめる必要がある。11Copyright © 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 Reserved13END