XDDPプラクティス路線図とパターン・ランゲージ～時を超えた派生開発の道～

XDDPプラクティス路線図と
パターン・ランゲージ
～時を超えた派生開発の道～
Agile Tour Osaka 2018
2018年12月1日(土)
川口典子
（c）Noriko KAWAGUCHI, 2018.

自己紹介
1
あなたの好きな電⾞は？
阪急電⾞♡
S Ie rのエンジニア
製造業の業務システム開発（〜2016年）
XDDP導入支援、社内研修の企画・実施（2016年〜）
[ 資格 ]
中級ソフトウェア品質技術者(JCSQE中級)
JSTQB Advanced Level テストマネージャー
川口典子
[ 所属 ]
コベルコシステム株式会社
派生開発推進協議会(AFFORDD) 運営委員、
関⻄部会副部会⻑
※本日の発表は所属組織を代表するものではありません。
あなたの好きな電⾞の部位は？
パンタグラフ◇

年 2007 2008 2009 2010 2011 ・・・ 2015 2016〜
イベント
開発部門
本社部門
XDDPと私
XDDP
導入
XDDP
導入
▲2007/11 清水さんのXDDP本が出版される
▲2008/12 XDDP本を読んで感銘を受ける
▲2009/04 担当案件にXDDPを導入し始める
派生開発における
不具合や手戻りが
多発
派生開発における
不具合や手戻りが
低減
Before After XDDPプラクティス
路線図をひらめく
XDDP
普及
2（c）Noriko KAWAGUCHI, 2018.

本日の内容
1. XDDPプラクティス路線図が生まれるまで
2. XDDPプラクティス路線図とパターン・ランゲージ
3. XDDPプラクティス路線図の活⽤の仕方
4. XDDPプラクティス路線図のこれから

1. XDDPプラクティス路線図が生まれるまで

XDDPプラクティス路線図
機能追加プロセス
変更
要求仕様書
変更
設計書
追加機能
要求仕様書
サイズ⾒積り
アーキテクチャ
再構築法
変更プロセス
リファクタリング
リスク管理
USDM PFD
プロジェクト管理
ユースケース
要件管理
スペックアウトTM⼀⻫に
コード変更
設計
要求
モデリング
※点線はXDDPの取扱範囲外(隣接技術)
状態
遷移
業務フロー
DFD
三段⾒積り
トレーニング
品質保証
新規性管理
レスキュープロセス
(火消し)
品質要求の
仕様化仮説⾒積り
Evolutionary
Scheduling
プロジェクト計画ピアレビュー DevJTestT型マトリクス
テストプロセス
変更のアジャイル開発
モジュールの
尺度と分割
構成管理
コア・プラクティス
プラクティス
乗⾞券
肯定眼→能動
乗⾞券
肯定眼→能動
結合
テスト
システム
テスト
リリース
実装
進⾏⽅向
スケジュール管理
単体
テスト
機能追加のアジャイル開発
XDDP列⾞

はじめに
6
大好きな♡XDDPの世界、
大好きな♡清水さんの広い世界観を
伝えたくて作ったものが、
XDDPのパターン・マップだと後で気づいた。
XDDPのパターン・マップを
作ろうと思って作ったのではなかった。

XDDP紹介時、清水本を渡すと・・・
7
XDDP本 USDM本

だいたいこんな反応・・・

一目でわかる「全体像」が必要
9
XDDPの普及活動で、
XDDPの全体像を伝えるのに苦労していた。
（最初にプラクティス満載の清水本は難しい。）
図や表で表現した、
一目でわかるものがほしかった。
でも、調べた限り⾒つからなかったので
自分で作ろうと思った。

ツリー構造ではうまく整理できない
10
当初はツリー構造でプラクティスを
整理しようとしたけど、できなかった。
特に、USDM(※)の配置で困る。
※Universal Specification Describing Manner
要求の仕様化技術、及び、要求仕様の記述方法

ネットワーク構造だと気づく
11
XDDPのプラクティスの関係が
ネットワーク構造だということに気づく。
コア・プラクティスはUSDM。

いろいろ試作してみたけれど・・・
12
試作①
コア→ハブ空港のイメージ→⾶⾏機の路線図。
全然しっくりこない・・・。
シーケンスが感じられなかった。
試作②
アジャイルメトロマップをまねて地下鉄の路線図。
全然しっくりこない・・・。
コアが感じられず、USDMが配置できなかった。

ひらめきは突然に
13
諦めかけていたある日、、、
阪急電⾞と阪神電⾞が
阪神間を並走するイメージと
XDDPの機能追加と変更のプロセスが
脳内で重なる。

出典 : 国土地理院 https://maps.gsi.go.jp/
尼崎
⻄宮芦屋
JR 大阪環状線・東⻄線
JR 神⼾線阪急神⼾線・今津線・宝塚線・伊丹線阪神本線
大阪
神⼾
阪神武庫川線
14
宝塚
伊丹
宝塚
大阪梅田
神⼾三宮
空から関⻄を⾒てみよう - 大阪〜神⼾
大阪城
甲子園球場

出典 : 国土地理院 https://maps.gsi.go.jp/
空から関⻄を⾒てみよう - 神⼾〜姫路
神⼾三宮
姫路
明石
加古川
高砂
姫路
神⼾
JR 神⼾線阪急神⼾線阪神本線
15
明石海峡大橋

梅田がUSDMや！
16
梅田がUSDMだと気づいて、そこからは悩まずどんどん生成できた。
XDDPプラクティス路線図の卵ができあがる。

XDDPプラクティス路線図の卵

清水さんに⾒せてみた
18
自分のXDDPの理解が合っているか確かめたくて、
清水さんに送ってみた。速攻で返信が届く。めっちゃ喜んでくれた♡

２. XDDPプラクティス路線図とパターン・ランゲージ

XDDPプラクティス路線図の生成プロセス
20
AFFORDD
関⻄部会
AFFORDD 現場
出典：ロベルト・ベルガンティ『突破するデザイン』

XDDPプラクティス路線図の生成プロセス（詳細）
21
AFFORDD
関⻄部会
AFFORDD 現場
出典：ロベルト・ベルガンティ『突破するデザイン』（c）Noriko KAWAGUCHI, 2018.

XDDP
スパーリングパートナー清水さん
22
XDDP
USDM
PFD
USDM
PFD
XDDPトライアングル
XDDP

ラディカルサークルAFFORDD関⻄部会 - 衝突と融合（1/2）

ラディカルサークルAFFORDD関⻄部会 - 衝突と融合（2/2）

ラディカルサークルAFFORDD関⻄部会 – 新たな方向を⾒つける
25
清水さんがAFFORDD関⻄部会でお披露目してくれた。
パターン・ランゲージについて調べてみる。
特に、ツリー構造ではなく、セミラティス構造だったところ。
川口さんの路線図、
パターン・ランゲージですよ！
ほんまや！
関⻄部会メンバー

論⽂にまとめることを決意
26
X D D P とパターン・ランゲージと鉄道路線図の組み合わせを
提言型論⽂としてまとめることを決意。
その頃、偶然、会社から何か論⽂を書いてみないかと声がかかる。

論⽂「XDDP普及のためのXDDPプラクティス路線図の提案」
多様なステークホルダーが
理解可能なガイドマップ
選択的・段階的導入の
手順を表したロードマップ
27※1 The architect Christopher Alexander in 2012 / Michaelmehaffy / CC BY-SA 4.0
XDDPプラクティス路線図を提案
普及
課題
①
普及
課題
②
関⻄鉄道路線図パターン・ランゲージXDDP
※1

論⽂で現在の形にまでブラッシュアップ
変更
要求仕様書
変更
設計書
追加機能
要求仕様書
サイズ⾒積り
再構築法
変更プロセス
リスク管理
USDM PFD
ユースケース
要件管理
コード変更
設計
要求
モデリング
状態
遷移
業務フロー
DFD
三段⾒積り
トレーニング
品質保証
新規性管理
(火消し)
品質要求の
Evolutionary
Scheduling
モジュールの
尺度と分割
構成管理
プラクティス
乗⾞券
肯定眼→能動
乗⾞券
肯定眼→能動
結合
テスト
システム
テスト
リリース
実装
進⾏⽅向
単体
テスト
XDDP列⾞

優秀論⽂として認められた！
29
大事なことは、自分は何のためにこの人たちを説得するのに
苦労しているのかと言う問いに答えられることかもしれませんね。
まるで「宣教師」ですね。
今回のIBMに出した論文も、私にはこの線上の行為に見えます。
焦らず、諦めず、工夫しながら信じる道を開きなさい。
※1 出典 : https://www.uken.or.jp/cgi/membership/users.cgi?file=USERS201704VOL6.pdf ※2 出典 : https://www.uken.or.jp/cgi/membership/users.cgi?file=USERS_H29VOL4.pdf
※2※1
※2

派生開発カンファレンス2017でお披露目
30
細谷さんをはじめ数人の方が
パターン・ランゲージだと
⾒ただけで気づいてくれたのが
とてもうれしかった
清水さんが
パネル・ディスカッションで
「路線図の彼女はXDDPの
本質を理解している」
と言ってくれたのは一生の宝
出典：http://affordd.jp/conference2017_program.shtml

３. XDDPプラクティス路線図の活⽤の仕方

派生開発に特化した開発方法論
清水吉男
Yoshio Shimizu
（1949-2017）
※1
※2
32
eXtreme Derivative Development Process
清水吉男によって提唱された派⽣開発に特化した開発⽅法論
清水氏の組み込みシステム開発やプロセス改善
コンサルティングにおける実践的ノウハウの集大成
組み込みシステムの世界で広く普及
派生開発における特有の制約に対応するために
① 合理的な開発プロセス
② 開発プロセスを効果的に⾏うためのプラクティス
③ XDDPを実践する人・組織が持つべきフィロソフィー
を提唱
※1 画像引用元 : http://image.gihyo.co.jp/assets/images/cover/2007/9784774132495.jpg ※2 画像引用元 : http://image.gihyo.co.jp/assets/images/cover/2010/9784774142579.jpg

派生開発とは
33
メカ
エレキ
ソフト
組み込みシステム
製品A Ver.1 製品A Ver.2 製品A Ver.3
製品D
製品B
製品C
新規開発に対峙させた概念
既存のベース・システムに対して機能追加や変更を⾏い、
新たなシステムを開発する
主に製品価値を高めるために⾏われる
例）クルマに自動運転機能を追加
機能追加・変更
機能追加・変更機能追加・変更
XDDPはシステムの
機能追加・変更を扱う

開発期間が短く設定されやすい
・開発期間が開発の規模感から決められることが多い
・開発規模はベースのソースコードの規模に⽐例しない
34
派生開発における特有の制約
派生開発の担当者は上記制約のもとでコード変更を強いられる
担当者の思い込みや勘違いによる不具合の混入が避けられない
短納期
部分理解
ベースのソースコードをすべて理解していない状況
・新規開発の終了時、通常、開発要員の大多数は離任
・新規開発時に作成された設計書がソースコードと不⼀致

変更3点セット
トレーサビリティ
マトリクス
トレーサビリティ
マトリクス
変更
要求仕様書
変更
要求仕様書
変更
設計書
変更
設計書
追加機能
要求仕様書
追加機能
要求仕様書
①XDDPの開発プロセス
35
追加機能
要求仕様書
の作成
結合
テスト
ベース・
ドキュメントの
更新
追加機能分
の設計書の
作成
追加機能分
の実装
追加機能分
の単体テスト
参照
※機能追加プロセスは、新規開発と同様のプロセスで実施する
変更プロセス
機能仕様書
など
変更
要求仕様書
の作成
変更設計書
の作成
コードの変更
変更分の
単体テスト
システム
テスト
既存のソースコードを抜け漏れ・誤りなく変更することが求められる
既存のアーキテクチャ構造を踏まえた新しい機能の要求仕様書や設計書の作成が求められる

①XDDPの開発プロセス - 変更3点セット
36
作成順ドキュメント名視点記述内容
1 変更要求仕様書
What : 何を変更するか？
Why : なぜ変更するか？
変更要求・理由(要求の背景)と
変更仕様
2
トレーサビリティ・
マトリクス ( T M )
Where : どこを変更するか？
変更仕様と
コード変更箇所の関係
3 変更設計書 How : どのように変更するか？コードの変更方法
コード変更に着手する前に
担当者の思い込みや勘違いによる不具合を取り除く
変更プロセスでは、システムの変更内容を異なる視点で
表現したドキュメントを、段階的に作成・レビューしていく

②XDDPのプラクティス - 解消する不具合（問題）
変更要求を
つかんでいない
影響調査の範囲
をつかんでいない
影響箇所を
漏らす・誤る
変更仕様を
漏らす・誤る
コード
変更方法を
誤る
コード
変更箇所を
漏らす・誤る
ベースのコードの
理解を誤る
変更
要求仕様書
変更設計書TM
スペック
アウト
USDM
XDDPプラクティス
派生開発で発生しやすい不具合（問題）
適⽤順
影響する
解消する
変更3点セット

U S D M
変更
要求仕様書
トレーサビリティ・
マトリクス ( T M )
変更設計書
⼀⻫に
コード変更
追加機能
要求仕様書
品質要求の
仕様化
D e v J Te s t
(Dev Join to Test)
ピアレビュー T 型マトリクス
単体テスト結合テストシステムテストリリーススペックアウト
仮説⾒積りサイズ⾒積り P F D
モジュールの
尺度と分割
再構築法
プロジェクト計画スケジュール管理
三段⾒積り
トレーニング
Evolutionary
Scheduling
品質保証
要件管理構成管理新規性管理リスク管理
(火消し)
38
②XDDPのプラクティス
開発プロセスを支える多様なプラクティスを提供
プロジェクト管理プロセスエンジニアリング・プロセス
XDDP
プラクティス

③XDDPのフィロソフィー
39
他人のプロセスや成果物の中で
良いところを積極的に肯定する姿勢
能動的にプロセス改善を⾏う人・組織へと成⻑
佐藤⼀斎
(1772-1859)
江⼾時代の陽明学者
「人の短所を視ることなかれ。
短所を視れば、則ち我れ彼れに勝り、
我れに於て益なし。
長処を視れば彼れ我れに勝り。
我れに於て益あり。」
肯定眼
例）ピアレビュー
レビュー対象の成果物について、欠陥の指摘を⾏うだけでなく
肯定意⾒も出すことを重視する。欠陥の指摘だけだと「肯定
眼」が育たず、折角の優れた⽅法も組織全体に広がらない。
出典 : 言志四録
⼀般に、開発現場は未知の手法に対して抵抗感を抱きがち
しかし、プロセス改善は何か⼀つでも良いものを取り入れようという能動的な姿勢がなければ進まない
能動で⾏動したとき、遭遇する障壁は工夫によって破られる

※1 The architect Christopher Alexander in 2012 / Michaelmehaffy / CC BY-SA 4.0
建築家のクリストファー・アレグザンダーによって提唱された
知識記述の方法
良いデザインや良い実践の秘訣を共有するための手法
建築の世界だけでなく、ソフトウェア開発の世界でも活⽤
パターン・ランゲージとは
※2
構成要素説明
パターン
(Pattern)
特定の状況（Context）において
繰り返し発生する問題（Problem）と
解決策（Solution）の関係を表したもの
パターン・マップ
(Pattern Map)
パターンの関連や順序を表したもの
網目のように絡み合ったネットワーク構造を持つ
※2 画像引用元 : http://www.kajima-publishing.co.jp/test/database/imgs/isbn9784306041714.jpg ※3 画像引用元 : http://www.kajima-publishing.co.jp/test/database/imgs/isbn9784306043060.jpg
※3
※1
40
ここ重要
クリストファー・アレグザンダー

パターン・ランゲージ例 - 組織パターン
アジャイル開発における組織のあり方をパターン・ランゲージの形式でまとめたもの
Organizational Patterns of
Agile Software Development
パターン
状況
問題
解決策
出典 : ジム・コプリエン他(2013) pp.275-276
出典 : ジム・コプリエン他(2013) p.243 41
出典 : ジム・コプリエン他(2013) 表紙

パターン・ランゲージで表現することのメリット
42
現場の状況に合わせて
パターンを選択・再利⽤できる
• 秘訣をパターンという
⼩さい単位で整理（部品化）
• 現場の状況に合わせて
特定のパターンを選択して
再利⽤することができる
ステークホルダー間の
コミュニケーションを促進できる
• パターンやパターン・マップを
共通言語として、
ステークホルダー全員が共有
• ステークホルダー間の
コミュニケーションが促進され、
全体像を共有することができる
パターンの順序・組み合わせを
知ることができる
• パターンどうしの関連をパターン・
マップのネットワーク構造で表現
• 複数のパターンを一定の順序
で組み合わせるためのルールを
知ることができる

43
XDDPパターン（XDDP Patterns）の定義
構成要素説明
パターン
(Pattern)
個々のXDDPプラクティスを、パターンの形式で表現したもの
(Pattern Map)
XDDPプラクティスの関連や適⽤順を、パターン・マップの形式で表現したもの
「XDDPをパターン・ランゲージの形式で体系化したもの」と定義
XDDPパターンがXDDP普及課題を解決すると考えた理由
導入ロードマップとして
活⽤可能
• プラクティスの関連や適⽤順を
表現できる
• 現場の状況に合わせて必要な
プラクティスを選択するための
ロードマップとして活⽤できる
選択的・段階的導入が
可能
• XDDPプラクティスを
パターンに凝集・疎結合化
• XDDPプラクティスを
部品化することにより
選択的・段階的導入が可能
共通言語としての
ガイドマップを提供
• 多様な経験を持つ
ステークホルダー同士が対話を
するためのガイドマップを提供
• ステークホルダー全員にとって
目指すべき将来像を共有できる

44
XDDPパターンの作成方法
清水氏の著書や
AFFORDDの研究成果
①
パターンの
抽出
②
パターンの
記述
③
パターン・
マップの
作成
XDDPプラクティスの
状況・問題・解決策
(XDDPプラクティス路線図)
パターンの関連や適⽤順を表すため
XDDP導入のガイドマップ、ロードマップ
としての役割を果たす
パターン
XDDPプラクティス一覧
パターン
一覧

変更
要求仕様書
変更
設計書
追加機能
要求仕様書
サイズ⾒積り
再構築法
変更プロセス
リスク管理
USDM PFD
ユースケース
要件管理
コード変更
設計
要求
モデリング
状態
遷移
業務フロー
DFD
三段⾒積り
トレーニング
品質保証
新規性管理
(火消し)
品質要求の
Evolutionary
Scheduling
モジュールの
尺度と分割
構成管理
プラクティス
乗⾞券
肯定眼→能動
乗⾞券
肯定眼→能動
結合
テスト
システム
テスト
リリース
実装
進⾏⽅向
単体
テスト
XDDP列⾞

JR神⼾線
阪神武庫川線
阪急今津線
関⻄鉄道路線図とのマッピング
変更
要求仕様書
変更
設計書
追加機能
要求仕様書
サイズ⾒積り
再構築法
変更プロセス
リスク管理
USDM PFD
ユースケース
要件管理
コード変更
設計
要求
モデリング
状態
遷移
業務フロー
DFD
三段⾒積り
トレーニング
品質保証
新規性管理
(火消し)
品質要求の
Evolutionary
Scheduling
モジュールの
尺度と分割
構成管理
プラクティス
乗⾞券
肯定眼→能動
乗⾞券
肯定眼→能動
結合
テスト
システム
テスト
リリース
実装
進⾏⽅向
単体
テスト
XDDP列⾞
46
阪急
神⼾線
JR大阪環状線
阪急宝塚線
JR東⻄線
阪神本線
姫路神⼾三宮
大阪梅田

XDDPプラクティス路線図の作成の狙い
変更
要求仕様書
変更
設計書
追加機能
要求仕様書
サイズ⾒積り
再構築法
変更プロセス
リスク管理
USDM PFD
ユースケース
要件管理
コード変更
設計
要求
モデリング
状態
遷移
業務フロー
DFD
三段⾒積り
トレーニング
品質保証
新規性管理
(火消し)
品質要求の
Evolutionary
Scheduling
モジュールの
尺度と分割
構成管理
プラクティス
乗⾞券
肯定眼→能動
乗⾞券
肯定眼→能動
結合
テスト
システム
テスト
リリース
実装
進⾏⽅向
単体
テスト
XDDP列⾞
47
①プラクティスの関連
②プラクティスの分類
③プラクティスの中心
④プラクティスの順序
⑤フィロソフィー(肯定眼と能動)
⑥導入の主体としての開発メンバー

48
XDDPプラクティス路線図の作成の狙い
多様なステークホルダーが①〜⑥を直感的・同時に理解できることを狙って作成
①プラクティスの関連
• プラクティスを駅で表現
• プラクティスの関連は
駅と駅を結ぶ線路で表現
• 隣接するプラクティスは
現場に同時に導入することで
より効果をあげることができる
②プラクティスの分類
• プラクティスと開発プロセスの
対応付けを、路線で表現
• 同じ路線上のプラクティスは
強い関連を持っている
• どの開発プロセスの改善に⼒を
注ぐべきかに議論を集中できる
③プラクティスの中心
• 「USDM」は
XDDPの中心プラクティス
• 各路線の始発駅が集結する
ターミナル駅として表現
④プラクティスの順序
• プラクティスの導入順を
始発駅からの駅の並び順で
表現
• プロジェクト管理は
循環的な構造を持つため
JR大阪環状線をイメージ
⑤フィロソフィー
（肯定眼と能動）
• 肯定眼と能動を
乗⾞券として象徴化
• XDDPを実践する人・組織は
この乗⾞券を持っていなければ
ならない
⑥導入の主体としての
開発メンバー
• 開発メンバーを
XDDP列⾞として表現
• 開発メンバーが
主体的にXDDPを
導入していくことを象徴化

XDDP導入ロードマップの作成
49
XDDP列⾞の停⾞駅
（導入プラクティス）
XDDP列⾞の始発駅
（開始プラクティス）
現⾏の
派生開発
プロセス
相当する現⾏プロセス
①現状分析 ③導入プラクティスの決定 ④開始プラクティスの決定②XDDPとのマッピング

現場で路線図を使った効果・課題
50
効果①
ガイドマップ
ロードマップ
として
課題
効果②
コミュニケーション
ツールとして
• リラックスした雰囲気が醸成され、活発に意⾒を引き出せた
• 列⾞に例えて話すことで、問題について話しやすくなった
例）「この辺りの区間で列⾞がよくバックする」といった表現で、
手戻りが多いプロセスについて話してくれたメンバーがいた
• XDDPの全体像を容易に伝えることができた
• 選択的・段階的導入の道筋を描くことができた
全員XDDP未経験であったが・・・
現場でのディスカッションでは・・・
新駅開業により現場活性化へ
• それぞれの開発現場では、
独自の⼯夫を⾏っている人がいることがわかった
• 独自の⼯夫を、新しいプラクティス（新駅）として追加し
現場独自のパターン・ランゲージとして拡張していく

４. XDDPプラクティス路線図のこれから

XDDP Patterns を作りたい
52
AFFORDD関⻄部会メンバーに
協⼒してもらいながら、
パターン記述を作成中。
清水さんを通して顕れた
派生開発の良い実践の秘訣を
XDDP Patternsとしてまとめたい。

あなたは、依頼者から要求仕様を聞き出そうとしている。
---
派⽣開発の場合、依頼者はシステムの具体的な変更
内容を伝えてくることが多く、その背景にある依頼者が実
現したいことを伝えてくることは少ない。
実現したいことが不明確であると、本来必要な仕様が
漏れていたり、不適切な仕様で開発してしまうことがある。
---
それゆえ：
USDMテンプレートを使おう。
• 要求仕様を「要求」と「仕様」とに分け、
階層構造で表現しよう。
• 「要求」には依頼者がシステムで実現したい“こと”を
表現し、仕様化の範囲を示そう。
• 「仕様」にはソースコードに変換可能な“もの”を表現
し、要求を満たすシステムの振る舞いや処理などを示
そう。
• 「要求」には「理由」を付け、「要求」の導出や洗練、
妥当性確認の拠り所にしよう。
XDDPのプラクティス - USDM
要求の仕様化技術、及び、要求仕様の記述方法
Universal Specification
Describing Manner
状況
---
問題
---
解決策
プラクティス名
概要
イメージ写真

XDDPのプラクティス - スペックアウト
ソースコードを解析して設計資料を作り出す⾏為
スペックアウト
状況
---
問題
---
解決策
プラクティス名
概要
イメージ写真
新規開発時に後の派⽣開発のときに有効な設計資料
は作られていないため、ソースコード以外に仕様を理解す
る手がかりがない。
そのため、あなたは、ソースコードを読んで既存システムの
仕様を理解しようとしている。
---
⼀般に、他人の書いたソースコードから仕様を読み取る
ことは難しいため、あなたはソースコードの理解を誤ることが
ある。
---
それゆえ：
• あなたの理解状況を可視化して、
第三者に理解状況を確認してもらおう。
• 理解したことを図や表などを使って表現できるよう、
構造図、PADフローなどの表現技術を習得しよう。
• 可視化した設計資料は、今後の派⽣開発で活用
できるよう、ベース・ドキュメントの更新に取り込もう。

ご清聴
ありがとうございました
おおきに！

参考⽂献
1. 清水吉男(2007a)『「派⽣開発」を成功させるプロセス改善の技術と極意』、技術評論社
2. 清水吉男(2007b)「２１世紀の品質保証体制の構想」<http://soft-koha-hp.la.coocan.jp/Else/Head0701Cntents.html>(2016/12/15アクセス)
3. 清水吉男(2010)『【改訂第2版】[入門＋実践]要求を仕様化する技術・表現する技術―仕様が書けていますか？』、技術評論社
4. クリストファー・アレグザンダー(平田翰那訳)(1984)『パタン・ランゲージ―環境設計の手引』、⿅島出版会
5. クリストファー・アレグザンダー(平田翰那訳)(1993)『時を超えた建設の道』、⿅島出版会
6. 井庭崇他(2013)『パターン・ランゲージ―創造的な未来をつくるための言語』、慶應義塾大学出版会
7. 井庭崇他(2016)『プロジェクト・デザイン・パターン―企画・プロデュース・新規事業に携わる人のための企画のコツ32』、翔泳社
8. ジム・コプリエン他(和智右桂訳)(2013)『組織パターン―チームの成⻑によりアジャイルソフトウェア開発の変⾰を促す』、翔泳社
9. ⻑坂⼀郎(2015)『クリストファー・アレグザンダーの思考の軌跡―デザイン⾏為の意味を問う』、彰国社

XDDPプラクティス路線図とパターン・ランゲージ～時を超えた派生開発の道～

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie XDDPプラクティス路線図とパターン・ランゲージ～時を超えた派生開発の道～

Ähnlich wie XDDPプラクティス路線図とパターン・ランゲージ～時を超えた派生開発の道～ (20)