1.
How to let them in house of quality
開発関係者に品質の基礎をどう教えるの
@JaSST nano
CopyRight 徳 隆宏

2.
問題提起
前提（一般論）
品質は、QA担当者だけでなく全員で取り組んだ方が良い
問題
QA以外の人に対しバランスよく手短に品質を教える方法が世の中にない（気がする）
（特にアジャイルに慣れ親しんだ若い人たちに、品質知識を教える方法は見当たらない）
よくある事象
・精神論、PDCAしっかりしよう ： （具体性なし）
・設計方法論の教育 ： （プラクティスの教育に偏り全体感なし）
・テストエンジニア教育 ： （テストの話に寄りすぎ。某標準テキスト）
・テスト規定教育 ： （手順や特定の観点の話に偏る）
・QA担当者向け教育 ： （アジャイルの話放置になりがち）
・SQuBOK/JSTQBを読め教育 ： （読めるなら苦労しない）

3.
全員参加型コンテンツです
「どう教えるの？」は、私の個人著作物（秘伝のたれ状態）を特急で紹介します。
適当にtwitterで@tokutakaへメンションつけて述べてください
① あなたの組織で使えそうか
② 一緒にメンテしたいか
③ 批判・批評・改善・質問・誤り訂正など
・返答は保証しません。
・空気を読んで、githubでCreative Commons zero（ただし引用箇所除く）という
扱いにするかも。

4.
解決策
解決策
若手エンジニアをターゲットとした
品質の基礎研修 2時間編を作ってみた。
ところで、発表者って
何者？

5.
TOKU Takahiro @tokutaka
空気をなんとかする中間管理職
@滋賀県
登山、スキー、ジョギング、カラオケ、ビール
Career : AI IoT QA Engineer
・2005年-2011年 外資系SI, 技術コンサル
製造業・金融・流通の基幹システムや組み込み開発。SE、
プロマネ支援、設計品質改善、など
・2011年-2021年 制御機器開発者・研究者
組込機器開発のプロマネ、仕様、アーキ、設計、テスト、
マニュアル作成。AI技術調査や事業化など
・2021年- AI IoT QA Engineering Manager
プロジェクト計画、クラウド構築、AI技術選定、テスト観
点、セキュリティ、データ品質など。教育・実施・支援
JaSST 関西実行委員、テスコン審査委員、QA4AI
弊社では、
腕に自信のあるQAエンジニア募集中！

6.
内容：初心者でも入るようストーリー仕立てで最終的には参考文献に誘導する
1. 導入部（引き込む）
1. 経営からの品質に関するメッセージ、KPI
2. 組織の重大不具合事例
3. 品質の定義とは？（グループワーク）
4. 品質の定義例
5. 品質管理と普段のお仕事
2. ソフトウェア工学の歴史（知ってもらう）
1. 品質の話がよく出る時代になった
2. トレンドに対して求められる能力
3. 開発アプローチのカバレッジ
4. アジャイルは「基礎」が必要
3. 開発アプローチの話（ムズイこと知ってもらう）
1. W字
2. 品質モデル
3. 様々なアジャイル・W字アプローチ
4. Agile Testing
5. 受け入れテストの条件だし（グループワーク）
4. テストの基礎（明日からできる気になってもらう）
1. テスト原則、プロセス
2. 代表的なテスト技法
3. マイヤーの3角形（演習）
4. 境界値分析
5. Aster オンラインセミナーの紹介
ここから、超駆け足で話をしていきます！！！(40p)

7.
今回の研修の目的：
品質に関する理解を深める。個々人の未然防止・検証活動のイメージをつかみ学べるようにする
目的でない：
各部門や製品の品質に関する決まり事を丸暗記し、実務ですぐに使えるようにする
経営からの品質に関するメッセージ、KPIなど

8.
組織で見つかった重大不具合
非機能不具合で、
金銭的被害がわかる事例が良い

9.
9
はじめに：品質の定義：品質ってなんですか？
2000年代までに登場した品質関連ワード
「うまい、はやい、やすい」
「バグがない」
「過剰品質」
「やすかろう、わるかろう」
「お、ねだん以上」
「さかいー、やすいー、しごときっちり！」
ワークショップ
5分作業、1分発表
お題： グループで、品質について意見を交換し、発表してください。

10.
10
品質とは：どれが自分たちに一番当てはまりますか？
ISO 9000
製品またはサービスが所与の品質要求を満たしていることの
妥当な信頼感を与えるために必要なすべての計画的および体系的活動
P. Crosby “Quality is still free”
顧客や製品の“要求”に対し、どれだけ満たしているか。
G.Weinberg “ワインバーグのシステム思考法”
品質は誰かにとっての価値である
James Martin
システムが稼働するときの本当のユーザーニーズに合致しているか
ワインバーグの定義が引用されることが多い。

11.
11
品質管理用語
品質マネジメント (Quality Management)
・品質に関する経営活動すべてを指す概念
品質保証
Quality Assurance
品質管理 Quality Control
・品質の要求事項を満たすためのあらゆる活動
狭義のQC
・職場全体をよりよくする
・顧客理解を深める
・商売・会計として成立させる
・統計的に測定・判断・改善
7つ道具を活用する
・小集団活動
・ニーズを十分満たすものを作り確認する
・関係者の巻き込み・検証などの手段で
問題が起きないよう作る・確認・予防
・顧客への問いかけや観察により
ニーズに充足しているか確かめる
生産現場のQC
・統制し外乱をなくす（５S）
・工程能力を上げる
・付加価値のない仕事を減らす
もっと学びたい人は、現代品質管理総論を参照。

12.
12
品質管理用語 （実は身近な仕事）
品質マネジメント (Quality Management)
・品質に関する経営活動すべてを指す概念
品質保証
Quality Assurance
品質管理 Quality Control
・品質の要求事項を満たすためのあらゆる活動
狭義のQC
・職場全体をよりよくする
・顧客理解を深める
・商売・会計として成立させる
・統計的に測定・判断・改善
7つ道具を活用する
・小集団活動
・ニーズを十分満たすものを作り確認する
・関係者の巻き込み・検証などの手段で
問題が起きないよう作る・確認・予防
・顧客への問いかけや観察により
ニーズに充足しているか確かめる
生産現場のQC
・統制し外乱をなくす（５S）
・工程能力を上げる
・付加価値のない仕事を減らす
もっと学びたい人は、現代品質管理総論を参照。
良いバックログから、
良いコードを書くことで、
良いフィードバックをもらう
顧客に迷惑をかけな
いよう、顧客の気持
ちで作る・確かめる
手続きを増やすより、
価値を増やし提供する
ログや不具合を分
析し、改善する
ふりかえる
障害をなくす

13.
13
ソフトウェア工学の歴史と概要（2010年代後半以降のモダンな変化は省略）
1960年代 1970年代
マネジ
メント
1980年代 1990年代 2000年代 2010年代
ニーズにあう
機能を発明
計画までの開発
完了
大規模ソフトを
安く
機能の時代 納期の時代 規模の時代 品質の時代
ソフトウェアに社会・企業・事業・生活が依存
工学の
焦点
アート
工芸品
形式化
ウォーター
フォール
生産性・拡張性
反復的な構築
並行 vs 順次
Agility と 価値
テスト
の焦点
デバッグ
仕様を満たす
エラーの撲滅
ソフトウェア
ライフサイクル
（SDLC)の一部
予防 SDLCの進化と自動化
辰巳氏発表のソフトウェアテストの歴史 を参考に作成。 https://www.slideshare.net/Bugler/ss-139696080
メインフレーム オフィスコンピュータ
ダム端末、ミニコン
Microsoft Corporation
Windows 3.1発売
Microsoft Corporation
Windows 95 発売
Microsoft Corporation
Windows 10 発売
スマートフォン

14.
14
求められるソフトウェアエンジニア能力は増大(1/2)
1960年代 1970年代 1980年代 1990年代 2000年代 2010年代
品質の時代
ニーズをくみ取って、動くものを作って、その範囲で確かめる
手戻りや無駄が起きないよう、手順や仕様を決めて作り、満たすか確かめる
疎結合にしたりデータの流れを整理して、
不整合が起きないか確かめる
反復的に作って品質（＝価値）を確かめる
SDLCを最適化
（CI CD、自動化）
ニーズに対し最適化
（クラウド、AI、
DevOps、自動テスト)
機能の時代 納期の時代 規模の時代
メインフレーム オフィスコンピュータ
ダム端末、ミニコン
Microsoft Corporation
Windows 3.1発売
Microsoft Corporation
Windows 95 発売

15.
15
開発アプローチの得意分野
1960年代 1970年代 1980年代 1990年代 2000年代 2010年代
ニーズをくみ取って、動くものを作って、その範囲で確かめる
手戻りや無駄が起きないよう、手順や仕様を決めて作り、満たすか確かめる
疎結合にしたりデータの流れを整理して、
不整合が起きないか確かめる
反復的に作って品質（＝価値）を確かめる
SDLCを最適化
（CI CD、自動化）
ニーズに対し最適化
（クラウド、AI、
DevOps)
W字モデル
アジャイル
メインフレーム オフィスコンピュータ
ダム端末、ミニコン
Microsoft Corporation
Windows 3.1発売
Microsoft Corporation
Windows 95 発売

16.
16
アジャイル一辺倒ではカバーできない。基礎を補う何かがチームに必要
1960年代 1970年代 1980年代 1990年代 2000年代 2010年代
ニーズをくみ取って、動くものを作って、その範囲で確かめる
手戻りや無駄が起きないよう、手順や仕様を決めて作り、満たすか確かめる
疎結合にしたりデータの流れを整理して、
不整合が起きないか確かめる
反復的に作って品質（＝価値）を確かめる
SDLCを最適化
（CI CD、自動化）
ニーズに対し最適化
（クラウド、AI、
DevOps)
基礎が必要
アジャイル
メインフレーム オフィスコンピュータ
ダム端末、ミニコン
Microsoft Corporation
Windows 3.1発売
Microsoft Corporation
Windows 95 発売

17.
17
他社事例：W字、アジャイル
全員が想像がつく、
それなりに規模の大きいシステムを例に、
Agile、W字の併用とその例を説明。
Google Map, ゲーム、アパレルアプリなど、
講師が説明しやすく受講生が理解しやすいもの。

18.
18
W字モデル
要求・仕様などの各種開発行為の進展にあわせて、
レビューやテストといった活動を実施し、品質をレベルで分けて検証する

19.
19
W字モデルのポイント：受け入れテスト
なぜテストアクティビティの開始になっているのでしょうか？

20.
20
W字モデルのポイント：受け入れテストは早く始める
「誰が何をどうやって受け入れたと判断しますか？」
誰
・意思決定者
・使用者
・運用者
・保守担当者
・平常
・異常
・自動
どうやって
・会議
・説明
・操作
・訓練
・政治
何を
・品質

21.
21
品質特性、品質モデル (ISO/IEC 25012 : SQuARE)
・品質はプロセスで作りこむ。意識できることで差が大きくなる
製品品質モデル 利用時の品質モデル
機能適合性 機能完全性、機能正確性、機能適正性
性能効率性 時間効率性、資源効率性、容量満足性
互換性 共存性、相互運用性
使用性
適切度認識性、習得性、運用操作性、
ユーザエラー操作性、UI快美性、アク
セシビリティ
セキュリ
ティ
信頼性 成熟性、可用性、障害許容性、回復性
機密性、インテグリティ、否認防止性、
責任追跡性、真正性
保守性
モジュール性、再利用性、解析性、修
正性、試験性
移植性 適応性、設置性、置換性
有効性 有効性
効率性 効率性
満足性 実用性、信用性、快感性、快適性
リスク
回避性
経済リスク緩和性、
健康・安全リスク緩和性、
環境リスク緩和性
利用状況
網羅性
利用状況完全性、柔軟性

22.
22
品質特性と、普段の開発業務
・コード品質、文書品質、バックログの質を高めることで、高品質を実現する。
製品品質モデル
機能適合性 機能完全性、機能正確性、機能適正性
性能効率性 時間効率性、資源効率性、容量満足性
互換性 共存性、相互運用性
使用性
適切度認識性、習得性、運用操作性、
ユーザエラー操作性、UI快美性、アク
セシビリティ
セキュリ
ティ
信頼性 成熟性、可用性、障害許容性、回復性
機密性、インテグリティ、否認防止性、
責任追跡性、真正性
保守性
モジュール性、再利用性、解析性、修
正性、試験性
移植性 適応性、設置性、置換性
有効性 有効性
効率性 効率性
満足性
実用性、信用性、快感性、
快適性
リスク
回避性
経済リスク緩和性、
健康・安全リスク緩和性、
環境リスク緩和性
利用状況
網羅性
利用状況完全性、柔軟性
バックログ
バックログ
バックログ
コード
コード
バックログ
*ここでは、説明の簡単化のために、設計実
装構築をすべて「コード」と呼んでいる
コード
コード
コード
コード
コード
コード・
文書
コード
利用時の品質モデル

23.
23
品質特性と、テスト
テストは品質を上げるものではないが、
どうテストされるか？を想像できると有効。
特に、非機能要件での先人の知恵として。
高信頼化のための開発手法ガイドブックより
https://www.ipa.go.jp/sec/softwareengineering/reports/20100915.html

24.
重大不具合が、
もし品質特性を意識してたら予防できたかも？

25.
25
チームのプロセスは様々
皆さんはどう開発してますか？なぜそうしていますか？ (正解は無いです）
段階的・反復的開発モデル
（20年前に開発されたW字開発プロセス）
Disciplined Agile Delivery (PMIより）
Scrum
(ryuzee氏よ
り引用）
IBM Rational Unified Process Reference and Certification Guideより引用

26.
26
Agile Testing Condensedより引用
アジャイルでもテストをする、すこし重点が違う

27.
27
Agile Testing Condensedより引用
アジャイルテストを理解することによるメリット （計画編）
① テストタイプの象限
どのテストをどの順序で行うか・自動化するか。
チームは議論の指針を得ることができる。
②システムの詳細レベルごとのテストを理解することで、
より機動的にテストを計画できる。
（単体、結合、システムという区分けから卒業）

28.
28
Agile Testing Condensedより引用
アジャイルテストを理解することによるメリット（実践編）
③ 継続的デリバリのパイプラインでの考慮点が
理解しやすい
④ 受け入れテスト駆動開発（Acceptance Test Driven
Development）での検討フローが示され、
具体的な活動イメージが沸く。

29.
あなたの開発での「受け入れ」とは？
ビジネスモデル
データ・モデル
受け入れ物 受け入れ人 受け入れ条件
開発・運用
ワークショップ
20分作業、5分発表
リリース時
に確認したい品質
利用時の
価値の有無
アーキテクチャ
考慮の十分さ
実際に運用・維
持できるか
開発対象を設定し、
受け入れ対象・人・条件をディスカッション。
安易な計画よりも、具体的な整理が有効そうだ
という手ごたえを持って帰ってもらう。

30.
30
http://aster.or.jp/business/seminar_text.html ASTER標準テキストの目次より引用。
テストについてこれだけ覚えて帰ってほしい（言い過ぎ）
1. テストの基礎
1.1 テストとは何か？ [K1/K2]
1.2 テストの必要性 [K2]
1.3 テストの7原則 [K2]
1.4 テストプロセス [K2]
1.5 テストの心理学 [K1/K2]
1.6 行動規範 （※）
2. ソフトウェア開発ライフサイクル全体
を通してのテスト
2.1 ソフトウェア開発ライフサイクルモデル [K1/K2]
2.2 テストレベル [K2]
2.3 テストタイプ [K1/K2]
2.4 メンテナンス（保守）テスト [K2]
3. 静的テスト
3.1 静的テストの基本 [K1/K2]
3.2 レビュープロセス [K1/K2/K3]
4. テスト技法
4.1 テスト技法のカテゴリ [K2]
4.2 ブラックボックステスト技法 [K2/K3]
4.3 ホワイトボックステスト技法 [K2]
4.4 経験ベースのテスト技法 [K2]
5. テストマネジメント
5.1 テスト組織 [K1/K2]
5.2 テストの計画と見積り [K1K2/K3]
5.3 テストのモニタリングとコントロール [K1/K2]
5.4 構成管理 [K2]
5.5 リスクとテスト [K1/K2]
5.6 欠陥マネジメント [K3]
6. テスト支援ツール
6.1 テストツールの考慮事項 [K1/K2]
6.2 ツールの効果的な使い方 [K1]

31.
31
これだけ覚えて帰ってもらいます。
1. テストの基礎
1.1 テストとは何か？ [K1/K2]
1.2 テストの必要性 [K2]
1.3 テストの7原則 [K2]
1.4 テストプロセス [K2]
1.5 テストの心理学 [K1/K2]
1.6 行動規範 （※）
2. ソフトウェア開発ライフサイクル全体
を通してのテスト
2.1 ソフトウェア開発ライフサイクルモデル [K1/K2]
2.2 テストレベル [K2]
2.3 テストタイプ [K1/K2]
2.4 メンテナンス（保守）テスト [K2]
3. 静的テスト
3.1 静的テストの基本 [K1/K2]
3.2 レビュープロセス [K1/K2/K3]
4. テスト技法
4.1 テスト技法のカテゴリ [K2]
4.2 ブラックボックステスト技法 [K2/K3]
4.3 ホワイトボックステスト技法 [K2]
4.4 経験ベースのテスト技法 [K2]
5. テストマネジメント
5.1 テスト組織 [K1/K2]
5.2 テストの計画と見積り [K1K2/K3]
5.3 テストのモニタリングとコントロール [K1/K2]
5.4 構成管理 [K2]
5.5 リスクとテスト [K1/K2]
5.6 欠陥マネジメント [K3]
6. テスト支援ツール
6.1 テストツールの考慮事項 [K1/K2]
6.2 ツールの効果的な使い方 [K1]
http://aster.or.jp/business/seminar_text.html ASTER標準テキストの目次より引用。

32.
テストの7原則
原則1：テストは欠陥があることは示せるが、欠陥がないことは示せない
原則2：全数テストは不可能
原則3：早期テストで時間とコストを節約
原則4：欠陥の偏在
原則5：殺虫剤のパラドックスにご用心
原則6：テストはコンテキスト次第
原則7：「バグゼロ」の落とし穴

33.
テストプロセス
・専門性が上がると、プロセスの粒度が細かく
・グレーで塗っている箇所が、テスト設計と呼ばれるテストケースを抽出する活動。
テスト計画
テスト手順作
成 テスト実施
20世紀までの
イメージ
テスト計画と
コントロール
分析・設計 実装・実行 終了基準評価
とレポート
終了作業
テスト計画
モニタリング
コントロール
分析
実
装
終了基準評価
とレポート
終了作業
設計
実
行
JSTQB
Foundation Level
JSTQB
Advanced Level
評価・レビュー

34.
34
テスト技法＝ テストケースを抜けもれなく検討する技
・テストケースとは、
ある要件を確かめるテストでの、「入力」「実行条件」「テスト手順」「期待結果」を示すもの
ワークショップ
15分作業、3分発表
三角形判定アプリ
A B
C
問題： このアプリは3つの入力を受け付け、三角形の各辺の長さと解釈する。
三角形が「正三角形」「二等辺三角形」「不等辺三角形」であれば、そのメッセージを出力する。
必要なテストケースを全て挙げよ
A
B
C
メッセージ

35.
35
代表的なテスト技法
① 同値分割法
• 同等に処理されると想定したデータすべてを同じパーティションに振り分け、各パーティションから少な
くとも1個の値を選んでテストする。
② 境界値分析
• 同値分割法の拡張で、パーティションが数値または順序付け可能な値で構成される場合に、パーティショ
ンの最小値と最大値（または最初の値と最後の値）を選んでテストする。
③ デシジョンテーブルテスト
• 条件と結果的に起きる動作を表の行、条件の一意な組合せとその結果として実行するアクションにより表
される判定の規則を表の列とし、規則ごとにテストする。
④ 状態遷移テスト
• ソフトウェアが有効または無効な遷移を介して、定義された状態の開始および終了を実行できるかどうか
をテストする。
⑤ ユースケーステスト
• 1個のサブジェクト（コンポーネントまたはシステム）と1個以上のアクターとの相互作用による振る舞
いを表すユースケースのシナリオをテストする。
⑥ 組み合わせテスト
• 複数の値を持つ複数のパラメータを含むソフトウェアに対して、組合せに含めるアイテムの数を選択して、
作成した組合せをテストする。
引用：ASTER セミナー標準テキスト http://aster.or.jp/business/seminar_text.html

36.
36
ソフトウェアテストの歴史と近年の動向 （辰巳 敬三氏）資料より図表を引用。
テスト技法を使いこなすには、数学などの技術が必要
テストとは「サンプリング」（全数・全網羅できない）で、数学的・物理的な思考を発揮するところ。
ベース技術を体得できていないと、テストを考えるところでボロが出る。
自分の得意分野を理解し、テストを考えきれない（=品質リスク）を、チームに共有すると良い。

37.
37
引用：ASTER セミナー標準テキスト http://aster.or.jp/business/seminar_text.html
同値分割法(1/4)
計算
クリア
（例）１けたの正の整数2個を足し算するプログラム。
？
それぞれ「1」から「9」までの整数
が入力できるのであれば、「1+1」
から「9+9」までの81通りのテスト
が必要か？
「１けたの正の整数」以外
の値も入力できてしまうの
では？
Copyright Association of Software Test Engineering All rights reserved. V3.1.1
出典： ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J03
同等に処理されると想定したデータすべてを同じパーティションに振
り分け、各パーティションから少なくとも1個の値を選んでテストする。

38.
38
同値分割法(2/4)
同等に処理されると想定したデータすべてを
同じパーティションに振り分ける。
同値パーティション
9
有効同値パーティション
（システムに受け入れられる値）
無効同値パーティション
（システムに拒否される値）
無効同値パーティション
（システムに拒否される値）
1 10
0
Copyright Association of Software Test Engineering All rights reserved. V3.1.1
出典： ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J03

39.
39
同値分割法(3/4)
同等に処理されると想定したデータすべてを
同じパーティションに振り分ける。
各パーティションから、少なくとも1個の値を選んでテストする。
同値パーティション
9
有効同値パーティション
（システムに受け入れられる値）
無効同値パーティション
（システムに拒否される値）
無効同値パーティション
（システムに拒否される値）
1 10
0
Copyright Association of Software Test Engineering All rights reserved. V3.1.1
出典： ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J03
無駄なテストをなくし、テスト回数を大幅に削減
できる。
代表値：5 代表値：15
代表値：-5

40.
40
同値分割法(4/4)
パーティションは、必要に応じて細かく分割（ズームイン）する場合もあれ
ば、粗く分割（ズームアウト）する場合もある。
文字種の分割例①
半角
数字
全角
数字 ひらがな
半角英字
（大文
字）
全角英字
（大文
字）
半角
カタカ
ナ
全角
カタカ
ナ
半角英字
（小文
字）
全角英字
（小文
字）
漢字
半角
記号
全角
記号
数字 ひらがな
英字
カタカナ
記号
漢字
数字
数字以外の文字
文字種の分割例② 文字種の分割例③
Copyright Association of Software Test Engineering All rights reserved. V3.1.1
出典： ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J03

41.
41
より知りたい人は、Youtubeを見てください。
https://www.youtube.com/playlist?list=PLN8WCH8BmTXy5DbYwCsEG_DDoMgm-Meiz

42.
42
終わり：Wrap-up
研修の目的
ソフトウェアの品質管理について理解し、日々の業務で品質を意識した行動ができるようになる。
・品質は誰かにとっての価値である
・品質モデルを意識し、品質をプロセスで作る
・W字モデルやアジャイルテスト
・受け入れテストは大仕事
・テスト技法を学ぼう

43.
参考文献（自己啓発にどうぞ）
・現代品質管理総論 (シリーズ 現代の品質管理) 飯塚 悦功 (著)
・ASTER セミナ標準テキスト
http://aster.or.jp/business/seminar_text.html
・Agile Testing Condensed
https://leanpub.com/agiletesting-condensed-japanese-edition
・ASTER オンラインセミナー
https://www.youtube.com/playlist?list=PLN8WCH8BmTXy5DbYwCsEG_DDoMg
m-Meiz
・ソフトウェア品質知識体系ガイド (第3版) ―SQuBOK Guide V3
・JSTQBシラバス
http://jstqb.jp/syllabus.html
・ソフトウェアテストの歴史と近年の動向 （辰巳 敬三氏）
https://www.slideshare.net/Bugler/ss-139696080
・IBM Rational Unified Process Reference and Certification Guide
・Disciplined Agile Delivery 公式サイトhttps://disciplinedagiledelivery.jp/
・Scrum用語集（ryuzee氏）https://www.ryuzee.com/contents/blog/7137
本資料で取り上げた参考文献 自己啓発でのおすすめ文献
・つながる世界のソフトウェア品質ガイド IPA
https://www.ipa.go.jp/files/000044964.pdf
・DtoDに基づくアジャイル要求入門
https://www.ogis-
ri.co.jp/column/agile/docs/IntroARWithDtoD.pdf
・テスト設計コンテストちびこん編チュートリアル
http://www.aster.or.jp/business/contest/tutorial_chibic
on.html
・実践ATDD～TDDからさらに歩みを進めたソフトウェア開
発
https://speakerdeck.com/hgsgtk/atdd-by-genba-
example?slide=34
書籍
・RDRA2.0 ハンドブック：軽く柔軟で精度の高い要件
定義モデリング手法 神崎善司
・Domain-Driven Design Distilled Vaughn Vernon
・ソフトウェアテストの教科書 布施 昌弘 (著), 江添
智之 （著）他

44.
その他商標・知的財産権に関して。
• Windows、Microsoft、Windows3.1、Windows10は、Microsoft Corporationの米国及びその他の国における商標または
登録商標です。
• 本資料での引用はMicrosoft社のガイドラインを参照し適正利用に努めております。https://www.microsoft.com/en-
us/legal/intellectualproperty/trademarks/publications
• Rational Unified Processは、IBM社の商標です。説明に利用したRUPのプロセス図は、IBM Rational Unified Process
Reference and Certification Guide: Solution Designer (RUP)より、プロセスの解説のため引用しました。
• スクラムを示す画像は、ryuzee氏の著作物であり、ryuzee氏のblogより引用しました。利用条件は引用元の明記です。
https://www.ryuzee.com/contents/blog/7124
• Disciplined Agile Deliveryは、PMIの商標です。説明に利用したプロセス図は、PMIのサイトより説明のため引用しました。
https://www.pmi.org/disciplined-agile/lifecycle

45.
おわり
現状、私の個人著作物（秘伝のたれ状態）ですが、
適当にtwitterで@tokutakaへメンションつけて述べてください
① あなたの組織で使えそうか
② 一緒にメンテしたいか
③ 批判・批評・改善・質問など
（確実にレスするかはわかりません・・・）