2024/3/15(金)10:00-12:00（120分）
Track05 セッション E6「価値あるソフトウェア」の”価値”ってなぁに？

セッション概要

１ • バグが多い、少ない／システム化する目的／ユーザーストーリーなど、さまざまな価値が存在する中で、われわれが向き合うべき「価値あるソフトウェア」の”価値”とはいったい何なのか？
2 • 現状、プロジェクト関係者はソフトウェアの”価値”をどのように認識して開発やテストを行っていて、その結果何が起きているのでしょうか？
• さらに、理想的にはプロジェクト関係者はソフトウェアの”価値”を
3 どのように認識して実務を行うのがよいのでしょうか？
• それを一緒に考える場にしたいと思います。

想定する参加者•アジャイル開発を含むITシステム開発、保守、運用などに携わるみなさん。～開発技術者、テスト担当者、管理者、営業担当者など

登壇者紹介
永田さん

安達

吉澤さん

永田 敦
サイボウズ株式会社
開発本部
アジャイル・クオリティ
JSTQB Advanced Level Test Manager
Agile Inspection Maestro
2008年 JaSST Tokyo ベストスピーカ賞受賞（マインドマップとHAYST法）
2011年 JaSST Tokyo ベストスピーカ賞受賞（リスクベーステスト）
2011年 5WCSQ (5th World Congress of Software Quality: 上海)
2016年 6WCSQ(6th World Congress of Software Quality: London)
2021年 JaSST Niigata 2021 基調講演 アジャイル・クオリティの探求
その他発表、ワークショップ多数
SQiP研究会 研究コース４ 「アジャイルと品質」 主査

自己紹介
アジャイルの流儀：EVO

現場モード：Stealth
SQiP 研究会主査
派生開発推進協議会運営委員

Agile RCA

copyright © A.Nagata
2015 /1/30

6

今回のセッションのきっかけ～JaSST’23東京ワークショップでやったこと

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

7

JaSST’23東京ワークショップ資料より

問題意識

価値

• テスト対象である“システム”で実現しようとしている価値は何か？
を把握してテストを実施していますか？
• 自ら分析、設計、実装、実施しているテストのうち、 システム化で実現しようとしている価値にミートするのはどこの部分でしょうか？
• これらがわからずにテストを行う境遇である場合、以下のようになる可能性があります。
間違いや不備、無駄などに対してフィードバックができなくなる。
強弱なしに言われたことだけをただこなすテストになってしまう。
テストを通じて何に貢献できているのか？が希薄になる。
テストへのモチベーションが得にくくなる／前向きに取り組めない。
Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

それはPOの仕事でしょ？

価値8

JaSST’23東京ワークショップ資料より

対象システムの画面遷移図～テストはどのように組み立てる？

ところで・・・このシステムはどのような価値を獲得するために構築しているのでしょうか？
普段のテストでそれを認識していますか？
対応例：状態遷移図と同等とみなして「状態遷移テスト」
でアプローチする！
Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

9

JaSST’23東京ワークショップ資料より

当ワークが目指すゴール• ゴール1：テストの視野を広げ、テストと「システム化により実現したい価
値（Value from Systemization：ここではVFSとします）」までの物
理的・心理的な距離を縮める。
• ゴール2：テストが持つ意味や意義への認識を“より高い方”に改め、テス
トに対するモチベーションを高めるきっかけになる。
• そのために、受講者のみなさんが以下の状態になることを目指す。
VFSを解き明かす（一つの）方法を把握する。
→現状分析＆価値設計をテストの立場で一緒に実施するのが理想
VFSを認識してテストを実施できるようになるきっかけを与える。
Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

10

JaSST’23東京ワークショップ資料よりDX実践の全体像とテスト／ワークのSCOPE

ビジネス
ミッション 利害関係
分析
者ニーズ・
要求定義
システム
要求定義

参考： ISO/IEEE 15288:2015（JISX0170）

ユーザとプロジェクト間の合意が重要となる
過程

保守
運用

アーキテク
チャ定義

妥当性
確認

T

移行

設計定義

T

結合

実装

ソフトウェア
要求定義

検証

ソフトウェア
方式設計

ソフトウェア
詳細設計

ソフトウェア実装

T

T

T

ソフトウェア
単体テスト

ソフトウェア
結合テスト

ソフトウェア
総合テスト

HW開発

T テスト活動

インフラ開発・運用開発など
Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

11

JaSST’23東京ワークショップ資料よりDX実践の全体像とテスト／ワークのSCOPE
現状分析

価値設計

システム開発ユーザとプロジェクト間の合意が重要となる過程

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved12

１

われわれが向き合うべき「価値あるソフトウェア」の”価値”とは？

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

13システム／ソフトウェアと価値

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

14吉澤さん調べ

価値ってなに？

15

価値ってなに？

吉澤の悩み• アジャイルとかで「価値の実現」とか、「価値の提供」とかよく聞くようになったなあ• 「品質とはだれかにとっての価値である」って、レジェンドの人が言ってたなあ• 「価値がある」って言葉はよく聞くけど、お金？だけではなさそうな• 同じものに対しても、感じる「価値」って人それぞれだよなあ「価値」って何だろう？
。。。ということで調べてみました価値について調べてみた＜日本国語大辞典＞① 物事のもっている値うち② 人間の基本的な欲求、意志、関心の対象となる性質。真、善、美、聖など。
③ ある目的に有用な事物の性質。使用の目的に有用なものを使用価値、交換の目的に有用なものを交換価値という＜デジタル大辞泉＞
経済的価値／生命価値／論理的価値（真）、道徳的価値（善）、美的価値（美）、宗教的価値（聖）＜日本大百科全書(ニッポニカ) ＞

経済学における価値／客観価値説／主観価値説／マルクス経済学における価値＜最新心理学事典＞
自分が，重要だと考えたり感じたりする対象（もの・人・こと）が価値であると考える立場（価値の客体説）では，重要だとされる物（古い写真）・人（亡くなった母親）・こと（良い思い出）にいずれも重要と判断される特質（懐かしさを引き起こす）があると考えて，それを価値とよぶ。
＜goo辞書＞
その事物がどのくらい役に立つかの度合い。値打ち。「読む—のある本」「—のある一勝」
経済学で、商品が持つ交換価値の本質とされるもの。→価値学説
哲学で、あらゆる個人・社会を通じて常に承認されるべき絶対性をもった性質。真・善・美など。
＜モットチャント＞
価値とは、一言で言えば、どれぐらい役に立つのかの度合いです。

価値について調べてみた＜日本国語大辞典＞

値打ち① 物事のもっている値うち

関心の対象となる性質② 人間の基本的な欲求、意志、関心の対象となる性質。真、善、美、聖など。

物事の性質
使用価値

交換価値

③ ある目的に有用な事物の性質。使用の目的に有用なものを使用価値、交換の目的に有用なものを交換価値というどれくらい役に立つかの度＜日本大百科全書(ニッポニカ) ＞
合い＜デジタル大辞泉＞

生命価値

経済的価値／生命価値／論理的価値（真）、道徳的価値（善）、美的価値（美）、宗教的価値（聖）

宗教的価値

経済学における価値／客観価値説／主観価値説／マルクス経済学における価値

美的価値＜最新心理学事典＞

自分が，重要だと考えたり感じたりする対象（もの・人・こと）が価値であると考える立場（価値の客体説）では，重要だとされる物（古い写真）・人（亡くなった母親）・こと（良い思い出）にいずれも重要と判断される特質（懐かしさを引き起こす）があると考えて，それを価値とよぶ。

経済的価値＜goo辞書＞

論理的価値

その事物がどのくらい役に立つかの度合い。値打ち。「読む—のある本」「—のある一勝」
経済学で、商品が持つ交換価値の本質とされるもの。→価値学説
哲学で、あらゆる個人・社会を通じて常に承認されるべき絶対性をもった性質。真・善・美など。
＜モットチャント＞
価値とは、一言で言えば、どれぐらい役に立つのかの度合いです。

道徳的価値

価値の考え方客観価値説／主観価値説• 客観価値説：自分が，重要だと考えたり感じたりする対象（もの・人・こと）が価値である• 主観価値説：価値づけをする人の心理にある• 価値の交渉説：対象とのかかわりの中から価値が生まれ，またそれが変化していく生成系AIに聞いてみた
価値とは、一般的には物事が持つ重要性や優れている度合いを表す概念です。これは、経済的な価値、道徳的価値、芸術
的価値、学術的価値、個人的な価値観など、さまざまな文脈で使用されます。
1. 経済的価値: 商品やサービスが市場で取引される価格。供給と需要のバランスによって決定されます。
2. 道徳的価値: 人間の行動や選択が社会的な倫理や道徳に基づいてどれほど良いか悪いかを示します。これは個々の社会や文化により異なる場合があります。
3. 芸術的価値: 作品が持つ美的な価値。これは主観的な評価が大きく影響します。
4. 学術的価値: 研究や理論が持つ知識的な価値。その分野の専門家による評価が一般的です。
5. 個人的な価値観: 個々の人が何を大切にするか、何が自分にとって価値があるかという個人的な信念や価値観。
これらの価値は相互に矛盾する場合があり、それぞれの視点から見ると重要性の度合いが変わることがあります。価値は主観的な評価に大きく影響を受けるため、全ての人が同じ価値を共有するわけではなく、それぞれが独自の価値観を持つことも大切です。
価値感とは、一人ひとりが大切だと考える理念や規範で、それが何であるかによって自己の行動や選択、意志決定などが左右されます。これは文化、教育、経験、宗教などの影響を受けて形成され、社会生活を営む上での個々の尺度や判断基
準となります。
たとえば、「努力は報われる」と信じる人は努力を尽くすことにエネルギーを投じる傾向にあります。また、「公平性」を大事にする人は他人との関係性において公平であることを重視します。これらはすべて、個々の判断基準や行動の原動力となる内在する信念や理念を反映しています。

別の生成系AIにも聞いてみた
価値とは何ですか
価値とは、商品やサービスに対してユーザーが感じる価値のことです。これは、ユーザーが感じる魅力や有益性、利便性などによって異なります。また、価値には
経済的な価値だけでなく、社会的な価値、芸術的な価値、個人的な価値観なども含まれます。経済的価値: ユーザーが商品を購入したりサービスを利用したりする際に感じる、商品の価格に対する価値です。価格が高ければ高いほど価値が高く、価格が低ければ低いほど価値が低いと感じます。社会的な価値: ユーザーが商品を購入したりサービスを利用したりする際に感じる、社会的な受容性や信頼感に対する価値です。安心して利用できることが価値となります。芸術的な価値: ユーザーが商品を購入したりサービスを利用したりする際に感じる、芸術的な技術やデザインに対する価値です。感動や驚きなどの感情が価値となります。個人的な価値観:
ユーザーが商品を購入したりサービスを利用したりする際に感じる、個人的な信念や価値観に対する価値です。自分にとっての価値が高いことが価値となります。
1．自己実現価値: 自分が何者であるか、何になりたいのかといった自己実現に対する価値です。自分自身の価値を認めることで、自己肯定感を高めます。
２．関係性価値: 家族や友人、恋人、仕事仲間など、自分の周囲の人たちとの良好な関係を築くために必要な価値です。信頼関係を構築し、維持するために必要な価値となります。
３．実用的価値: ユーザーが商品やサービスを利用して、具体的な利益やメリットを感じるために必要な価値です。価値を感じることで、商品やサービスに対する興味や関心を高めます。
４．自己成長価値: 自分自身の成長やスキルアップに必要な価値です。自分自身の価値を認めることで、自己啓発や自己成長を促します。
５．感情的価値: ユーザーが商品やサービスから感じる、喜びや悲しみ、驚きなどの感情的な価値です。感情的な価値を感じることで、商品やサービスに対する満足感と愛着心を高めます。
さらに聞くと。。
１．環境価値: 社会や文化が、環境に与える影響や、環境に優しい素材を使用することの価値です。環境負荷を減らし、持続可能な社会を実現するために重要な価値となります。
２．安全・安心価値: ユーザーが商品やサービスを利用して、安心・安全に必要な価値です。安全性が高まり、リスクを回避することができます。
３．快適価値: ユーザーが商品やサービスを利用して、快適な生活を送ることができるために必要な価値です。ストレスや疲労を感じにくく、快適に利用することができます。
４．知識価値: ユーザーが商品やサービスを利用して、新しい知識や情報を得るために必要な価値です。新しい知識や情報を得ることで、自分自身の成長につながります。
５．経験価値: ユーザーが商品やサービスを利用して、楽しい経験や思い出を得ることができるために必要な価値です。ワクワク感やドキドキ感を感じることができます。
これらの価値は、商品やサービスの価値を高めるために重要となります。また、それぞれの価値を満たすことで、ユーザーにとっての価値を高めることができます。

こんな価値の種類がありそう
経済的価値
道徳的価値
芸術的価値
学術的価値
個人的な価値観

自己実現価値
関係性価値
実用的価値
自己成長価値
感情的価値

環境価値
安全・安心価値
快適価値
知識価値
経験価値

ソフトでの関心ごと
はこの辺かな？
でも、経済的価値や道徳的価値はありそう、実用的価値もこんな価値の種類がありそう
経済的価値
道徳的価値
芸術的価値
学術的価値
個人的な価値観

自己実現価値
関係性価値
実用的価値
自己成長価値
感情的価値

環境価値
安全・安心価値
快適価値
知識価値
経験価値

得られる？感じる？価値。。。かもしれない

作りこむ価値？

参照したサイト一覧●コトバンクhttps://kotobank.jp/word/%E4%BE%A1%E5%80%A4-45051●goo辞書https://dictionary.goo.ne.jp/word/%E4%BE%A1%E5%80%A4/●モットチャント
https://mottochanto.net/what-is-valu/●最新心理学事典https://www.heibonsha.co.jp/book/b157304.html

品質とは誰かにとっての価値である。
Quality is value to some person.

Gerald.M.Weinberg

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved26アジャイル宣言の背後にある原則(抜粋)https://agilemanifesto.org/iso/ja/principles.html

The following 12 Principles are based on
the Agile Manifesto.

私たちは以下の原則に従う:

Our highest priority is to satisfy the customer
through the early and continuous delivery of

顧客満足を最優先し、価値のあるソフト

valuable software.

ウェアを早く継続的に提供します。

Welcome changing requirements, even late in
要求の変更はたとえ開発の後期であっても歓迎します。
development. Agile processes harness change for 変化を味方につけることによって、お客様の競争力を引
the customer’s competitive advantage.
き上げます。
Deliver working software frequently, from a
動くソフトウェアを、2-3週間から2-3ヶ月というできるだ
couple of weeks to a couple of months, with a
け短い時間間隔でリリースします。
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

27

JaSST’23東京ワークショップ資料より

デビット・アーカーによる価値の3分類とITシステムの位置づけ ※Benefit＝価値ITシステムとのインターフェース

または便益

自己実現価値

情緒的価値

機能的価値
ITシステム商品・サービスを所有したり体験することで獲得できる自
己表現・自己実現

商品・サービスを所有したり体験することで獲得できるポジティブな感情
商品・サービスに対して抱く
感覚的・精神的な価値

商品・サービスの機能やスペックによってもたらされる利
便性や利益

自分らしくいられる
理想に近づく自信が持てる

幸福感や優越感
ワクワクする感覚
ブランドイメージ

機能、操作性
処理能力
効率性 などCopyright © Kenji Adachi@Software Quasol , All Rights Reserved

28

JaSST’23東京ワークショップ資料より差別化できる価値はシステムの外側にある

機能的価値（機能・性能の充実）と利用者が持つ情緒的価値（イメージ・印象・愛着など）は必ずしも一致しない

ブランドなんでもランキング 第35回：機能的価値と情緒的価値（ノートパソコン）
http://japanbrand.jp/ranking/nandemo/35.html
Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

29

2
現状

アンケート結果よりプロジェクト関係者はソフトウェアの”価値”をどのように認識して開発やテストを行ってるの?

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved30事前アンケート結果• あなたの職種(プログラマ、QAなど)を教えてください• あなたの職位(担当、リーダ、マネージャなど)を教えてください• あなたが携わっているプロダクトやサービスではどのような価値を提供していますか？
• その価値を実現するためにあなたはどのようなことをしていますか？

□プロダクト・サービスを提供する過程での困り事や問題点があれば教えてください。→OUTPUT先に直接書いてもらう31

あなたの職種(プログラマ、QAなど)を教えてください“QA”
全体の66%“テスト”を含めると全体の77%QA

QAエンジニア

コンサルタント

テスター

PMO

QA/SET

SEPG

アーキテクトエンジニアリングマネージャ

テスト

テストエンジニア

テストエンジニア兼テストマネージャー兼テストアナリスト

プログラマ

プログラマ、評価担当

開発エンジニア

業務ソフトウエア開発のPM組み込み製品開発32

あなたの職位(担当、リーダ、マネージャなど)を教えてください

リーダー

マネージャ／管理者

メンバー／担当

その他
33

あなたが携わっているプロダクトやサービスではどのような価値を提供していますか？
QAE：業務効率化・ビジネス損失の低減
QAE：選択体験
QA：第三者検証サービスとしての妥当性をもった提案
QA：セキュリティー
QA：ファクトリーオートメーションにおける生産性の向上
QA：気軽に撮影でき、シェアできる
QA：安全性と使いやすさ
QA：安さ、安心感、継続的開発、カスタマイズ性
QA：記憶を日常にする
QA：利用者に対してサービスの安全性を提供
QA：部品検査の効率化、検査精度の安定化
QA：品質管理
QA：顧客が安心して、しかも効率的に使用できるハイ
クオリティ製品を継続的に提供
QA：社員のライセンス管理、業務アセット管理
QA：ソフトウェアテスト、プロセス改善

QAE：会計プロダクトと連携する決済プロダクトとして、ユーザーは新たに入力することなく、1プロダクトのような統合体験を得ることができ、ユーザーの業務効率を10倍以上にする世界実現に寄与するプロダクト価値の提供
QA：ECサイトを運営しているので、欲しい商品をお客様に届けて使っていただくという価値を提供しています。改めて質問されると答えるの難しいQA：空き時間に働きたいユーザーと、人手が欲しい事業者のマッチングを行っています
QA/SET：ウェルネス増進
QAE：導入企業が、採用時や社内間のコミュニケーションが円滑行える状態を価値として提供している
QA：利用者の負担軽減に重きを置いた価値を提供しています。
QAE：顧客企業が実現したいエンド顧客向け体験を実現する
QA：履歴の把握
QAE：アナログ業務からの脱却、IT化による利便性の向上
34

あなたが携わっているプロダクトやサービスではどのような価値を提供していますか？
QA：人事採用管理システムの品質管理に携わっています。組織の効果的な人材獲得プロセスを実行するためのツールで、候補者の管理や選考プロセスの管理、評価と意思決定の支援など、これらの機能を統合し、組織が効率的かつ効果的に人材を獲得し、優れた採用結果を実現するためのプロセスをサポートしています。
QA：安全を大前提として快適であること
QAE：建物管理の業務オペレーションの効率化
QA：サイトの会員からデータを集めてクライアントの意思決定の情報として提供する
QA：調査・ガイド作成・教育実施
QA：最低限誰でも思いつくようなバグは出さないよう、基本的なアプリのテストは実施している
SM/QA：スクラムマスターによるチームやプロセス改善／QAによる品質向上施策
TE：開発者テストサポート／テストプロジェクト管理
TE：安全かつ通信データ保証、利用品質検証。セキュリティ妥当性確認。
TE：テスト、テスト自動化
TE：商店街などで使えるオトクな電子商品券を提供しています35

あなたが携わっているプロダクトやサービスではどのような価値を提供していますか？
PMO：受発注・製造品質管理・出荷等をITシステムで支援し、顧客にプロダクトを届ける
ARC：大きくは空気（質）そのものの価値、その実現のためのサービス品質
ENG：患者と医療機関の物理的な距離を縮める、病院の待ち時間を短縮する、治験の生産性等
DEV：データ保存
DEV：変わり種ですが私自身がシステムを開発するよりも「お客様が開発やテストを内製化で開発できるようになる」という喜びを提供しています
DEV：業務システムなので利用者に使ってもらって価値を提供する
PRG：業務効率化、生産性向上
PRG：QCDを意識した製品品質
SEPG：継続的に故障なくツールを使える
CON：資源活用のムダ排除
CON：組織のテストマネジメント力を上げる、組織のテスト技術を底上げする、組織の開発アジリティを高める（ための対話のツールと場を提供する）
36

その価値を実現するために
あなたはどのようなことをしていますか？
QA：サービスへテスト効率化の導入とスケール化
QA：要件定義のレビュー
QAE：ドメイン理解プロダクト理解ユーザ利用目線でのSpecレ
ビュー、テスト
QAE：適正な品質のよいプロダクトをできる限りはやくお届けすること（テスト作業、リファインメント参加、自動化作業ほか）
QA：スキル教育の設計や運用
QA：最新技術の情報収集
QA：プロダクトの価値を低下させる可能性のあるプロダクトリス
クを特定し、リスク軽減に向けたモニタリングとコントロールを行う。
QA：アウトカムを意識した品質保証
QA：上位要求からのレビュー参画、ユーザビリティテストの検討
QA：・スコープを小さくする・リスクベースアプローチ・背景理解のための問いかけ・ドキュメント更新・自動化・業務改善活動
QA：「価値」が何か分からなくなってきたので改めて考えようとしてます

QA：ユーザに使い続けてもらえるプロダクトにするためにはどういうことをするべきかを考える、議論する、実験する
QA：サービスローンチの短縮に向けた効率的・効果的なQA
体制の構築
QA：重要な品質が劣化しないように注力している
QA：テストマネージ
QA：最新の品質関係の知識や技術、ならびにマネジメント
手法等を纏めて教育を実施
QA：テスト、テストコーチ
QAE：・ミニマムな状態からリリースして、爆速で機能拡充し価値の質の向上やより広い範囲への価値提供できるように、
品質とスピードを両立した品質保証を行う・ユーザーにとっての体験をあらかじめ意識できるよう、スクラムマスタリングを通じて
ユーザー価値に対し意識を合わせるためのファシリテーションを行う
37

その価値を実現するために
あなたはどのようなことをしていますか？
QA：欲しいものを当たり前に購入できるという最低限のところは担保できるようにテストをしています
QA：機能がユーザーに正しく届くように検証を予定期間内に完了できるようテストやFB、レビューを行なっています
QA：品質メトリクス収集、品質分析
QA/SET：ユーザビリティテストシフトライトによる検証
QAE：利用者の立場にたって、利用性が少しでも上がるように提案を行っている。また、それを早く届けられるようにスピード感を持って提供出来るようにしている
QA：複数の顧客の声をヒアリングし、要望からユーザーストー
リー推測し、求められるものよより確実に要件・仕様に落とし込むようにしています。
QA：QAとしてプロダクトに対するテスト計画の策定やテスト実
施、バグの発見と報告、プロセスの改善を行い製品やサービスの品質を確保し、顧客満足度や信頼性を向上させる役割を担っています。

QAE：顧客体験に焦点を当てた、分析、マーケティング、コ
マースなどの仕組みを提供する
QA：テスト
QAE：現行運用の課題の把握、利用者のニーズの確認、それらがシステムに落とし込めているかの要件の確認など
QA：テストや品質を考えるときに価値を中心にして工数や範囲について強弱をつける
QAE：テスト観点から要件や仕様をレビュー、テスト実施
QA：情報を集めるアンケートデータが正確に集まるサポート
TE：開発チームへテスト分析およびテスト設計の中間成果物によるプロダクトリスク及びプロジェクトリスクのフィードバック。
TE：効果的なテスト手法の情報収集ほか
TE：テスト自動化の構築、支援、相談など
TE：システムのテストをしています。
TE：ソフトウェアテストに関する知見の収集
38

その価値を実現するために
あなたはどのようなことをしていますか？
PMO：ITシステムの開発維持で、陥りやすい課題や解決方法を例示する
ARC：クラウドを含め、リードタイムを短くするためのプラットフォーム構築
ENG：体制やプロセスなどエンジニア組織全体の仕組みづくりをしている
DEV：製品のテスト
DEV：AWS、設計支援、テスト設計、自分での構築など必要なことはなんでもします
DEV：適切な要件定義。開発コストを上げないために、無駄な機能を作らない。
PRG：現状の業務フローを整理し、やりたいことをお客様と認識を合わせている
PRG：欠陥の前倒し。評価前にできるだけ問題点を解決する。
SEPG：ハードなどの環境の故障自動検知、毎日の巡回診断など
CON：スクラムマスター
CON：ワークショップをデザインする、ワークショップを実施する、気づきを得てもらう問いを投げかける、テストや品質保証にまつわる技術を学び広げる39

システムの利害関係者と関心事(例)
顧客に評価
される？

売上は？

儲かるかな？

納期遵守？
採算は？
機能は
動く？
どんな機能
が必要？

システムオーナー組織
(発注者)
利用者
評価は？
発売タイミン
グは？

非機能
要件は？

開発プロジェクト

セキュリティ
は？

〇〇システム開発プロジェクトチーム
協力会社

雇い主の
評価は？

実利用者

テストに
パスする？
リリース

協力会社

使いやすいのかな？

外部ベンダー

提供部品の
評価は？

役に立つ
のかな？

この機器で
使える？

保守・運用メンバー

保守しやすいのかな？

運用しやすいのかな？

Copyright © Kenji Adachi＠Software Quasol, All Rights Reserved

流行の機能
はある？

40

3
アンケート結果を頭に入れておき、事例を見ながら、事例の意味・意義と現状について議論する

ソフトウェアの価値への取り組み事例

41

永田さん

永田さんの事例

42

JaSST’23 Hokkaido 発表

品質観点でみたインセプションデッキとその改善
サイボウズ株式会社
アジャイルクオリティ

永田 敦

インセプションデッキとは
１０の質問
1. チームの意義は？
2. 製品を一言で説明すると？
3. 製品の売り文句は何ですか
4. ターゲットのスコープは何ですか？
5. 周りのお世話になる人たちはだれ？
6. 解決の目論見はある？
7. リスクはなんですか？
8. ざっくりしたスケール感は？
9. 優先するもの、トレードオフする項目は？
10.ざっくりした見積もりは？
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

44インセプションデッキとは中期的な計画です”計画に従うことよりも変化への対応により多くの価値を置く“
アジャイルソフトウェア開発宣言

変化に対応するために、計画を立てる
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

45インセプションデッキとはチーム自身によりプロジェクトの全体像を整理する

目的、方向性を表現する
Jonathan Rasmusson、西村直人 他、アジャイルサムライ、オーム社、2011

プロジェクトを成功することに対する納得感を得る
提供価値、スコープ、リスクなどの品質要素が多く含まれる
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

46

目線を揃える
QAメンバーも開発メンバーも、同じチームとなって、同じゴールに向かって、走っていくことができる

Whole Teamで上流での品質を組み込みを行う

7/16/2021

COPYRIGHT © ATSUSHI NAGATA

47

計画とは
“品質とは、誰かにとっての価値である“
顧客が対価を払う“価値”＝製品の”品質”
顧客に提供する製品の“品質”をいかにして、製品に作りこむかを表現したもの
•
•
•
•

何を作るか
それはどんな段取りで作るか
自分たちに作れるか
他より優れたものが作れるか• 作る意思、情熱を持っているか

2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

48

ビジネスにおける価値のことば
提供価値
バリュープロポジション
製品価値

Product Value

アウトプット2023/9/8

Value Proposition

Output

顧客価値

Customer Value

アウトカム

OutcomeJaSST Hokkaido 2023 copyright © Atsushi Nagata

49

提供価値

Value Proposition「提供価値」または "Value Proposition" は、製品やサービスが顧客に提供する利点や価値を指します。
これは企業や組織が、その製品やサービスを通じて顧客の問
題をどのように解決するか、または顧客のニーズをどのように満たすかを示すものです。

1.ユニークさ - 製品やサービスが競合他社と異なる独自の特徴や機能。
2.顧客の利益 - 顧客が製品やサービスを使うことで得られる具体的なメリット。
3.解決策 - 製品やサービスが提供する解決策や、顧客の抱える問題をどのように解決するか。
4.顧客との関係 - 顧客との関係構築や、顧客体験に与える影響。

2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

50提供価値→ 製品価値
• 提供価値：バリュープロポジションは、企業が顧客に提供することを約束するもので、製品やサービスが提供するユニークな利益と価値を包含しています。これは、企業が提供するものの重要性と独自性に関する声明です。
• 製品価値はバリュープロポジションに密接に結びついており、製品がバリュープロポジションを満たすために提供する有形および無形の利益を代表しています。これには、バリュープロポジションで特定されたニーズを満たすために設計された製品の特徴、品質、および能力が含まれます。
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

51製品価値 → 顧客価値
• 製品価値は、バリュープロポジションで約束された特徴、利益、品質を提供することにより、顧客価値の基盤を提供します。
• 顧客価値は、製品の価値が顧客の観点からどのように知覚されるかについてです。
• これは、製品が彼らのニーズを満たし、問題を解決し、バリュープロポジションで行われた約束を果たすかど
うかを顧客が評価することを含みます。顧客価値は主観的であり、顧客によって独自の好み、ニーズ、期待に基づいて異なります。
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

52顧客価値 → アウトカム• 顧客価値は、顧客と企業の両方にとってのアウトカムに直接影響を与えます。顧客にとっては、高い知覚価値が満足度、忠誠心、リピート購入につながる可能性があります。これは、製品の価値が顧客にとっての現実の利益にどのように変換されるかについてのものです。

• アウトカムは、売上の増加、市場シェアの拡大、顧客維持、ブランドロイヤリティなど、ビジネスに影響を与える具体的な結果を含みます。製品価値が顧客の期待とよく一致し、企業のバ
リュープロポジションに基づいて高い顧客価値を実現した場合、ポジティブなアウトカムが達成されます。

2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

53相互接続されたサイクル• 提供価値：バリュープロポジションは、製品のユニークな価値と利益を強調することで期待を設定します。
• 製品価値は、その特徴と品質を通じてこれらの期待に応えます。
• 顧客価値は、製品が顧客の期待を満たすかそれを超えた場合に実現され、知覚された価値と満足度につながります。

• アウトカムはこのプロセスの具体的な結果であり、顧客（満足度と忠誠心を通じて）とビジネス（財務パフォーマンスと成長を通じて）の両方に影響を与えます。

2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

54

価値の創造と流れ：バリューストリーム
提供価値
バリュープロポジション
計画
計画

アウトプットインテグレーション

分析
学ぶ

設計
設計
実装
実装
テスト
テスト

製品価値
7/16/2021

利用
活用 顧客価値振り返り
レビュー

モニタリング

アウトカム
COPYRIGHT © ATSUSHI NAGATA

55

多様な側面からプロジェクトを描く
開発対象要求
ステークホルダ

ミッション
目的

インセプション
デッキ

スコープ
プロジェクト
リスク

ビジョン
リスク

予算
リソース

プロダクト
リスク

提供価値、スコープ、リスクなどの品質要素が多く含まれる
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

56インセプションデッキがうまくできないと▌チームは目標やベクトルがそろわない状態になりがち▌自律的に動きにくい→

プロジェクトがうまくいかない要因▌品質面では次のような懸念が出てくる

 スコープが不明確（特にやらないこと）
 リスクが洗い出されていない（当たり前品質） 価値（魅力的品質）が不明確になりがち57
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

インセプションデッキのよくある課題
１．実行に時間がかかる

定着できない２．表現がステレオタイプになる

納得感がない３．ステークホルダの多様な価値に気づかない

価値が偏る

納得感が得られない。現実と合わない。自分事にならない

時間をかけた割に、効果がないということで、途中でやめてしまったり、やらなくなってしまったりしてしまう
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

58課題1 実行に時間がかかる

2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

59原因：時間がかかる
インセプションデッキの10の質問の抽象度
質問や解答の抽象度◎ 非常に高い○ 高い△ やや高い抽象度◎ 1. なぜあなたはここにいるのか?
◎ 2. エレベーターピッチ○ 3. プロダクトボックス
4. やらないことリスト
5. あなたのプロジェクトコミュニティ△ 6. テクニカルソリューション
△ 7. 夜も眠れないようなこと
8. どのくらい大きいのか？
△ 9. トレードオフ スライダー
10.最初のリリース

角谷信太郎、インセプションデッキ の テンプレート、https://github.com/agile-samurai-ja/support/blob/master/blank-inception-deck/README.md, Aug,20192023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

60原因：時間がかかる
最初、まだ、プロジェクトとの共通の整理と理解ができていないところで抽象的な話をしようしてしまう

メンバー皆が納得する表現を生むのが難しい
まとめようとすると、非常に時間がかかる
抽象的な問いが最初続くので、前半で1日費やしてしまうことも2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

61対策：時間がかかる
１．問いの目的を、言い換えて説明する
抽象度◎ 1. チームの意義と目的は？
◎ 2. 開発対象を一言でいうと？
○ 3. 製品の売り文句は何ですか
4. ターゲットのスコープは何ですか？
5. 周りのお世話になる人たちはだれ？
△ 6. 解決の目論見はある？
△ 7. リスクはなんですか？
8. ざっくりしたスケジュールは？
△ 9. 優先するもの、トレードオフする項目は？
10.ざっくりした見積もりは？

２．抽象的な問いを後回しにし、事実をベースにした問いから手を付ける
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

62

対策の効果：時間がかかる
時間が短縮

数日

3，4時間

振り返りの声“われわれはなぜここにいるのかを最後に決めたのはよかった。
順番的には最初だが、最初に出せるものではないと気付いた。”“3時間でもなんとかできた”
繰り返すモチベーション

半年おき程度表現がより洗練された
振り返りの声“抽象的で難しい問いも多かったけど、みんなで議論したことで進めていけた感じがする！”“これから何か問題が起きたらインセプションデッキを見直すぞ！”
自分たちで行うようになった

自分たちで独自のモデルをつくる

もっと自分たちの考えを別の形で整理したい
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

63課題２ 表現がステレオタイプになってしまう

2023/9/8
JaSST Hokkaido 2023 copyright © Atsushi Nagata

64課題：表現がステレオタイプ
ここでは、当たり前な、ありきたりな表現のこと• 売り上げをあげる• 効率を上げる• 品質を上げる
当然の表現を使うため、抽象的で、腹落ちしない、自分事にならない、
納得が得られない言葉になってしまう

原因

特に抽象的な問いに対して答えるとき• 抽象的問いを理解できていない• 答えも抽象的になるが、表現を扱い慣れていない

2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

65原因：表現がステレオタイプ
特に抽象的な問いに対して答えるとき• 抽象的問いを理解できていない• 答えも抽象的になるが、表現を扱い慣れていない
例：”なぜあなたはここにいるのか?”
答え：“ｘｘ機能を開発すため”

問いの意味
チームメンバーがどんな意思を持って開発をしようとしているか、
あるいは、開発で生まれる価値で、ステークホルダをどのように変えようと考えているのか
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

66対策：表現がステレオタイプ
一番ステレオタイプが起こりやすい、最初の問い、“なぜ我々はここにいるのか”に焦点を当てた。

オリジナルテンプレート；“このプロジェクトを行う最大の理由“を求めているチームが持つ、プロジェクトに対する意図、意思
それを表現するモデルとして、価値駆動開発の手法1である匠メソッド2の”価値デザインモデル”を使ってみた

1.価値駆動開発の基本、SE4BS, https://se4bs.com/sites/foundation/, 2022
2. 価値駆動開発実践トライアル編、4.7 価値デザインモデルの作成、SE4BS, https://se4bs.com/sites/practice/、2022
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

67対策：価値設計モデル
チームが持つ、プロジェクトに対する意図、意思
プチでもいいので、ビジョンを考えてみる

チームの価値観を決める

このプロジェクトで作られる成果物の価値

ビジョン

ステークホルダにおいてどのようなアウトカムを生むのか

コンセプト

コンセプト

コンセプト

ビジョンを実現するためのアプローチ、概念
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

プロジェクトの意思

創造的で自律的な行動になる

68

対策の効果：表現がステレオタイプ
事例 : “なぜ我々はここにいるのか”に対してのあるチームの取り組み
Before: 最初のインセプションデッキ：まだ、価値デザインモデルは入っていない
・現在手掛けている事業を成功させたいから
・世界中の販売の量と効率を最大化するため・システムの顧客体験を盛り上げていきたいため問いに直接答えようとしてステレオタイプの表現になっていた

After : 次のインセプションデッキ：価値デザインモデルを入れてみた・ビジョン：販売システムにより、世界中に売れている・コンセプト：4つの基本戦略を立てた。実現のための具体的な議論ができるようになった
振り返りの声”思考が構造的になり、前回よりも表現が明確になった。”

2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

69

（参考）価値デザインモデル

価値設計モデルの例 価値駆動開発実践トライアル編、4.7 価値デザインモデルの作成、SE4BS, https://se4bs.com/sites/practice/、2022

2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

70課題３ ステークホルダの多様な価値に気づかない

2023/9/8
JaSST Hokkaido 2023 copyright © Atsushi Nagata

71

（参考）エレベータピッチ• [必要性や機会を記述]を望んでいる• [対象顧客]にとって• [プロジェクト名]は• [製品カテゴリ]に属しており• [キーベネフィット, 購入への説得力ある理由]がある.
• [他の主要な競合製品]と違って• 我々のプロジェクトは[主要な違いの記述]がある.

https://github.com/agile-samurai-ja/support/blob/master/blank-inception-deck/blank-inception-deck1-ja.pdf
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

72課題：ステークホルダの多様な価値

ステーク
ホルダA

ステーク
ホルダB

ステーク
ホルダC

ステーク
ホルダD

ステーク
ホルダE
システム
サービス

オリジナルのインセプションデッキでは“顧客”としか表されていない

アウトカムを最大化するためには
どんな価値をだれにどのくらい重点に置けばよいか
そのバランスや戦略を考える必要
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

73対策：ステークホルダの多様な価値を表す
テンプレートに二つのモデルを加えることでステークホルダの多様な価値を表現する

ステークホルダ分析
関係するステークホルダの洗い出し

価値分析モデル3
洗い出されたステークホルダが得る価値を表現する
価値駆動開発の手法である匠メソッドの価値分析モデルを用いる
3. 価値駆動開発実践トライアル編、4.6 価値分析モデルの作成、SE4BS, https://se4bs.com/sites/practice/、2022
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

74

（参考）ステークホルダ分析

ステークホルダ分析の例 （SB4BS, 実践トライアル編, https://se4bs.com/sites/practice/）

2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

75

（参考）価値分析モデル

価値分析モデルの例 （SB4BS, 実践トライアル編,. https://se4bs.com/sites/practice/、2022）
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

76対策：価値記述“チームが提供している価値で、
ステークホルダがどのような影響をうけて、うれしく感じたか”をチームが想像し、表現していく。

ステークホルダ
機能開発チーム

UIを開発する時
価値を感じる場面
価値を提供する機能や手段
どのようにうれしいか

シチュエーション

手段
価値の言葉

最新のUIライブラリが使えるようになって価値

フロントエンド
コンポーネント
開発チーム

使用する顧客によりよいユーザー体験を提供できて嬉しい
価値記述の例

2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

77

対策の効果：ステークホルダの多様な価値を表す
どのチームも、開発には多くのステークホルダがいることを認識した。
振り返りの声“ステークホルダが多い！（来年はもっと増える）“
受け取られた価値がステークホルダごとに違うことに気づいた
振り返りの声“色々な物の見方があると言うのが改めてわかりました。““関係者間でも、求める内容が少しずつ違っていることが知れた“

2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

78

対策の効果：事例
ステークホルダ

価値分析モデル
価値記述システムを使う
顧客

オペレータ

試用したいとき、素早くその手続きや環境が整い早く試用が始められてうれしい

サブシステムが落ちた
ときでもアクセスできて不安にならない

利便性が高い入力が間違えにくい問い合わせのとき適切な履歴が残る（迅速な対処ができる）

二つのステークホルダグループが感じる価値に大きな違い

要求の漏れを防ぐ

要求のバランスや優先度を考える

スコープやリスクに対する視野を広げる効果
2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

79

QAやテストエンジニアの参加
QAが得られる情報・機能の重要な品質ポイント
・製品リスクはなにか

品質・テストの戦略
Error Prone
テスト観点

・品質の観点から、価値を表現し、チームに気づきを提供する

チームへの
貢献

・どの品質や品質特性に注目していくか
パフォーマンス、負荷、セキュリティ、UX、アクセシビリティ・テストの方針をより明確に立てられる

振り返りの声

2023/9/8“求められる品質/セキュリティへのイメージをつかむことができた”

JaSST Hokkaido 2023 copyright © Atsushi Nagata

80

他部門への応用▌向き直りの手段
 ギャザリング
 QAチーム： 自分たちが目指すQAのビジョン、QAの方針、ポリシーを策定▌中期計画
 営業やサポート組織、そして、スタートアップにおける中期計画

振り返りの声“インセプションデッキ、営業でも使えたな”“インセプションデッキ有効な手法だと思います。来年もまたやりましょう！！”

2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

81

課題と展開▌ [課題]価値記述は難しい

 しかし、回を重ねるごとによくなっていく 効果、メリットを実感してもらう▌ [展開]インセプションデッキの後どうしていくか ユーザーストーリマッピング

 ロードマップ→

2023/9/8

バックログ作成

JaSST Hokkaido 2023 copyright © Atsushi Nagata

82

まとめ
▌ インセプションデッキを、より軽量化する工夫により、実行時間を改善
し、定期的に行うモチベーションを生んだ →継続による向上▌ 価値駆動開発の手法を取り入れることにより
 チームが持つ、プロジェクトに対する意図、意思をモデル化すること
で、このプロジェクトを行う最大の理由を表した ステークホルダの価値を表現することで、その多様性に気づき、要求の漏れを防ぎ、スコープやリスクに対する視野を広げる効果をもたらした▌ この活動を継続するモチベーションが生まれ、表現内容が向上したことを確かめたｋ。

2023/9/8

JaSST Hokkaido 2023 copyright © Atsushi Nagata

83

あだち

システム化により実現したい価値はどこから？
[事例]

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

84

JaSST’23東京ワークショップ資料より

ワークのお題”ツアーパック株式会社”

Copyright © Levii Inc, All Rights Reserved

85

JaSST’23東京ワークショップ資料より

Copyright © Levii Inc, All Rights Reserved

86

JaSST’23東京ワークショップ資料より

Copyright © Levii Inc, All Rights Reserved

87

JaSST’23東京ワークショップ資料より

ツアーパック株式会社DXの背景• 現状は主に鳥取県内のコアな有名観光地をベースにしたツアー企画パンフ等を公開し、観光客に申し込んでもらう形式で運営。
• 今までのメインターゲット：インバウンド観光客→コロナで激減→補填のためには単価高宿泊客を増やす必要有• これからのメインターゲット：国内観光客
コロナによる影響が海外観光客よりは少ない
しかし、現状は日帰りが多い・リピートする旅客が少ない
砂丘などスポット観光で日帰りという認識が強い
鳥取でしか味わえない体験をアピールできていない
どの県も国内旅行誘致に力を入れていて競争が激しい
Copyright © Levii Inc, All Rights Reserved

88

JaSST’23東京ワークショップ資料より

現状の価値
（課題）
ビジネス
ミッション 利害関係分析
実現したい価値
者ニーズ・
要求定義
（目的）
システム
要求定義
アーキテク
チャ定義

DX実践の全体像

参考： ISO/IEEE 15288:2015（JISX0170）
保守

ユーザとプロジェクト間の合意が重要

運用
妥当性
確認

T

移行

設計定義

ITシステム（手段）
T

実装

ソフトウェア
要求定義

ソフトウェア
方式設計

ソフトウェア
詳細設計

ソフトウェア実装

ソフトウェア
単体テスト

T

検証

結合

T

T

ソフトウェア
結合テスト

ソフトウェア
総合テスト

HW開発

T テスト活動

インフラ開発・運用開発など
Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

89

JaSST’23東京ワークショップ資料よりDX実践の全体像
現状分析

現状の価値
（課題）

価値設計

実現したい価値（目的）

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

システム開発

システム
（手段）

90

JaSST’23東京ワークショップ資料よりDX実践の全体像（例）
大分類／フェーズ
現状分析

価値設計

システム開発中分類／タスク

Outputビジョン・ミッション・コンセプト共有

ビジョン・ミッション・コンセプト

コンテキスト分析

As-isコンテキストモデル

業務フロー分析

As-is業務フロー

課題構造化～課題特定

As-is価値連鎖モデル

要求分析～価値連鎖モデル構築

To-be価値連鎖モデル

新コンテキストモデル構築

To-beコンテキストモデル

新業務フロー構築

To-be業務フローモデル

情報構造設計To-be情報構造モデル

ユースケース・画面一覧構築

To-beユースケース・画面一覧

実現価値ユーザーストーリー化＋UXモデル構築

To-beUXモデル

価値にミートするテスト設計

価値にミートするテスト設計結果

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

91

JaSST’23東京ワークショップ資料よりDX実践成果物の全体像
To-be
要求分析ツリーTo-beユーザー
ストーリーマッピング

ビジョン・ミッション
(要約)

左記の別解

ビジョン・ミッション
As-is
コンテキストTo-be
コンテキスト

As-is
価値連鎖モデルTo-beユースケース

As-is
課題構造
As-is
業務フロー

To-be業務フロー（全体+個別）To-be画面一覧

To-be
価値連鎖モデル

To-be
UXモデル

To-be情報構造
Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

92

JaSST’23東京ワークショップ資料より組織のありたい姿・使命の把握

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

93

JaSST’23東京ワークショップ資料より

ビジョン・ミッション・コンセプト共有
世界中の人々の出会いと感動を創造し、魅力的で心豊かな地域社会の実現に貢献する
ツアー提案を通じて鳥取の魅力を発信し、地元の発展に寄与し続けられる
旅行会社

凡例

鳥取まるごと好きになる
人を増やすために、様々な価値観や時代のニーズに応えられる魅力あるツアー提案・実施を実現する

Copyright © Levii Inc, All Rights Reserved

94

JaSST’23東京ワークショップ資料より

現状をありのまま把握する

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

95

JaSST’23東京ワークショップ資料より

As-isコンテキストモデル作成＆課題明確化事例

Copyright © Levii Inc, All Rights Reserved

96

JaSST’23東京ワークショップ資料より

As-is業務フロー作成＆課題明確化事例

Copyright © Levii Inc, All Rights Reserved

97

JaSST’23東京ワークショップ資料より

As-is課題構造作成例

実現したい姿
現実の姿

Copyright © Levii Inc, All Rights Reserved

現実を作る要因

98

JaSST’23東京ワークショップ資料より

As-is課題構造作成例（別解）Copyright © Levii Inc, All Rights Reserved

99

JaSST’23東京ワークショップ資料より

課題構造中のコア要素特定
利用する立場

利用者の負の体験体験する（目的）差し出す（手段）価値
未提供
製品・サービスを提供する立場（ITシステム）

識別付与の例
Copyright © Levii Inc, All Rights Reserved

100

JaSST’23東京ワークショップ資料より新しい価値を設計する～システムにつなぐ

Copyright © Levii Inc, All Rights Reserved

101

JaSST’23東京ワークショップ資料より

To-beコンテキストモデル作成

Copyright © Levii Inc, All Rights Reserved

102

JaSST’23東京ワークショップ資料より

To-be業務フロー作成

Copyright © Levii Inc, All Rights Reserved

103

JaSST’23東京ワークショップ資料より

To-beユースケース作成

Copyright © Levii Inc, All Rights Reserved

104

JaSST’23東京ワークショップ資料より

To-be価値連鎖モデル作成

問題・課題

戦略要求

業務要求

Copyright © Levii Inc, All Rights Reserved

IT要求

105

JaSST’23東京ワークショップ資料より

To-be価値連鎖モデル作成（別解）経営・ビジネス業務

Copyright © Levii Inc, All Rights Reserved

ITシステム

106

JaSST’23東京ワークショップ資料より

To-be価値連鎖モデル中のコア要素例
経営・ビジネス業務

ITシステム

利用する立場

カギとなる正の利用者体験体験する（目的）カギとなる正の
利用者体験

コアな価値
提供元

差し出す（手段）

コアな価値
提供
製品・サービスを提供する立場（ITシステム）
Copyright © Levii Inc, All Rights Reserved

107

JaSST’23東京ワークショップ資料より

UXモデル作成(ユーザーストーリー単位)

Copyright © Levii Inc, All Rights Reserved

108

JaSST’23東京ワークショップ資料より

To-be画面一覧・画面イメージ作成

Copyright © Levii Inc, All Rights Reserved

109

JaSST’23東京ワークショップ資料より

ITシステムに近づく～構成要素が増えていく

今日はこちらからアプローチしたこちらから見るとわかりにくい

コアな価値の例
Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

110JaSST’23東京ワークショップ資料より“コアな価値”と“付帯する価値”を見分ける

“コアな価値”が提供できないと“付帯する価値”は意味をなさなくなる一方で“付帯する価値”は“コアな価値”のレベルを一層高める（付加価値）

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

111

JaSST’23東京ワークショップ資料より観点群とコアな価値の関係性（仮説）
システム/ソフトウェア特性

利用時品質特性

互換性
移植性

利用状況網羅性

使用性
機能
機能適合性

有効性

性能効率性

システム運用･保守

信頼性

可用性

保守性

保守･運用性セキュリティ

コアな価値とはこれでは？

効率性

満足性

リスク回避性セキュリティ
性能･拡張性

移行性

システム環境･エコロジー
Copyright © Kenji Adachi@Software Quasol , All Rights Reserved112フィードバック

フィードバック仮説

Agileの4つの価値
・個人との対話・動くソフトウェア
・顧客との協調・変化への対応

検証

実装

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved113Web上の公開資料より

ITシステム価値関連の事例

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved114アイムデジタルラボさんの事例
三越伊勢丹デジタルサービス実現

三越伊勢丹におけるデジタルサービスのつくりかた
https://www.jasst.jp/symposium/jasstreview21/pdf/S1.pdf
115

エピック：案件の目的および価値を定義する

三越伊勢丹におけるデジタルサービスのつくりかた
https://www.jasst.jp/symposium/jasstreview21/pdf/S1.pdf
116エピックの書き方
1.現状の課題•現状、[お客様/従業員]にとって[問題点]という課題がある

2.実現したいこと•[お客様/従業員]として[達成したいゴール]をしたい

3.期待できる効果•[お客様/従業員]にとって[具体的価値]という効果が期
待できる
三越伊勢丹におけるデジタルサービスのつくりかた
https://www.jasst.jp/symposium/jasstreview21/pdf/S1.pdf
117

サービスブループリント＝エピックの具体化
お客様の行動、従業員の業務、システムの挙動をセットで表す

三越伊勢丹におけるデジタルサービスのつくりかた
https://www.jasst.jp/symposium/jasstreview21/pdf/S1.pdf
118

ユーザーストーリー「例とテンプレートで作るユーザー ストーリー」より
https://www.atlassian.com/ja/agile/project-management/user-stories「私が [ペルソナ] なら、[希望] を実行することで[目標] を達成したい」＜ユーザーストーリーの例＞• 私が[Max]なら、[友達を招待]して[このサービスを一緒に受けられる]ようにしたい。
• 私が[Sascha]なら、[仕事を整理]して、[上手に管理できていると思える]ようになりたい。
• 私が[管理者]なら、[部下たちの作業の進捗を把握できる]ようにして、[成功や失敗についてより適切に報告できる]ようになりたい。
119

エピックとユーザーストーリーの関係性の例
エピック

案件の目的や価値を定義

ユーザーストーリーn
案件のサブ目的や価値を定義
ユーザーストーリー3
TicketTicket
案件のサブ目的や価値を定義
ユーザーストーリー2 Ticket Ticket
案件のサブ目的や価値を定義
ユーザーストーリー1Ticket Ticket

案件のサブ目的や個別価値を定義
TicketTicketTicketTicket120

ソニックガーデン遠藤大介さんの事例

ビジネスの成長に合わせてソフトウェアを進化させ続ける秘訣• たえず変わる市場環境やユーザーからの反応を元に、柔軟に対応しないといけない• プロダクトの仕様についてPOとプログラマ両方の視点から適切さと複雑さのギリギリのポイントを“絶えず”探す～それをPOとプログラマで徹底的に対話を繰り返すことが とても大切• PO：適切さ
ユーザ価値的に必要なことが実現できているのかどうか• プログラマ：複雑さ

ソフトウェア的に負債を抱えてしまわないかどうか
ソフトウェアを進化させ続ける秘訣
https://www.jasst.jp/symposium/jasstreview21/pdf/S5.pdf

121

10X風間裕也さんの事例

シフトレフトとシフトライトの両面から製品開発に取り組んだお話
https://speakerdeck.com/10xinc /shift-left-and-shift-right122

3

取り組み事例から言えることは何か？

123フィードバック

永田さんの事例
安達の事例

10X風間裕也さんの事例

フィードバック

検証

仮説

実装
ソニックガーデン遠藤大介さんの事例

Copyright © Kenji Adachi@Software Quasol , All Rights Reserved

124みなさんのロール（例：QA）では価値をどう認識しているでしょうか？
• 現状でみなさんの役割はどこを／何を対象とした活動をしている？
• 他のロールが実施しているから自らのロールの対象外になっていないか？
• 各種判断をする際にベースに置くのが”価値“のはず• システムテスト設計時に利用者ならどうするかを考えるはず／顧客観点（顧客はこういう境遇でこう使う）のフィードバックが開発（ハッピーパスベース）に効く
125

役割分担
悪しき役割分担イメージ

Whole Teamイメージ

PMer
PdM

PMer

PdM

顧客

Developer

顧客
QA

QA
Developer126

3

今日のふりかえり

プロジェクト関係者はソフトウェアの”価値”をどのように認識して実務を行うのがよい?

127きょうのふりかえりをオンラインOUTPUT会場に書き込んでみてください128ご参加いただきありがとうございました！
今後もソフトウェアの価値について議論していきましょう！

129