XDDPプラクティス路線図とパターン・ランゲージ ～時を超えた派生開発の道～
5 likes1,783 views
Agile Tour Osaka 2018 の発表資料です。
![自己紹介
1
あなたの好きな電⾞は？
阪急電⾞♡
S Ie rのエンジニア
製造業の業務システム開発（〜2016年）
XDDP導入支援、社内研修の企画・実施（2016年〜）
[ 資 格 ]
中級ソフトウェア品質技術者(JCSQE中級)
JSTQB Advanced Level テストマネージャー
川口 典子
[ 所 属 ]
コベルコシステム株式会社
派生開発推進協議会(AFFORDD) 運営委員、
関⻄部会 副部会⻑
※本日の発表は所属組織を代表するものではありません。
あなたの好きな電⾞の部位は？
パンタグラフ◇
（c）Noriko KAWAGUCHI, 2018.](https://image.slidesharecdn.com/agiletourosaka2018xddppatterns-191021034745/85/XDDP-2-320.jpg)
![参考⽂献
56（c）Noriko KAWAGUCHI, 2018.
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)『クリストファー・アレグザンダーの思考の軌跡―デザイン⾏為の意味を問う』、彰国社](https://image.slidesharecdn.com/agiletourosaka2018xddppatterns-191021034745/85/XDDP-57-320.jpg)
XDDPプラクティス路線図とパターン・ランゲージ ～時を超えた派生開発の道～
- 1. XDDPプラクティス路線図と パターン・ランゲージ ～時を超えた派生開発の道～ Agile Tour Osaka 2018 2018年12月1日(土) 川口 典子 （c）Noriko KAWAGUCHI, 2018.
- 2. 自己紹介 1 あなたの好きな電⾞は？ 阪急電⾞♡ S Ie rのエンジニア 製造業の業務システム開発（〜2016年） XDDP導入支援、社内研修の企画・実施（2016年〜） [ 資 格 ] 中級ソフトウェア品質技術者(JCSQE中級) JSTQB Advanced Level テストマネージャー 川口 典子 [ 所 属 ] コベルコシステム株式会社 派生開発推進協議会(AFFORDD) 運営委員、 関⻄部会 副部会⻑ ※本日の発表は所属組織を代表するものではありません。 あなたの好きな電⾞の部位は？ パンタグラフ◇ （c）Noriko KAWAGUCHI, 2018.
- 3. 年 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.
- 4. 本日の内容 1. XDDPプラクティス路線図が生まれるまで 2. XDDPプラクティス路線図とパターン・ランゲージ 3. XDDPプラクティス路線図の活⽤の仕方 4. XDDPプラクティス路線図のこれから 3（c）Noriko KAWAGUCHI, 2018.
- 6. XDDPプラクティス路線図 機能追加プロセス 変更 要求仕様書 変更 設計書 追加機能 要求仕様書 サイズ⾒積り アーキテクチャ 再構築法 変更プロセス リファクタリング リスク管理 USDM PFD プロジェクト管理 ユースケース 要件管理 スペックアウトTM⼀⻫に コード変更 設計 要求 モデリング ※点線はXDDPの取扱範囲外(隣接技術) 状態 遷移 業務フロー DFD 三段⾒積り トレーニング 品質保証 新規性管理 レスキュープロセス (火消し) 品質要求の 仕様化 仮説⾒積り Evolutionary Scheduling プロジェクト計画ピアレビュー DevJTestT型マトリクス テストプロセス 変更のアジャイル開発 モジュールの 尺度と分割 構成管理 コア・プラクティス プラクティス 乗 ⾞ 券 肯定眼→能動 乗 ⾞ 券 肯定眼→能動 結合 テスト システム テスト リリース 実装 進⾏⽅向 スケジュール管理 単体 テスト 機能追加のアジャイル開発 XDDP列⾞ 5（c）Noriko KAWAGUCHI, 2018.
- 11. ツリー構造ではうまく整理できない 10 当初はツリー構造でプラクティスを 整理しようとしたけど、できなかった。 特に、USDM(※)の配置で困る。 ※Universal Specification Describing Manner 要求の仕様化技術、及び、要求仕様の記述方法 （c）Noriko KAWAGUCHI, 2018.
- 15. 出典 : 国土地理院 https://maps.gsi.go.jp/ 尼崎 ⻄宮芦屋 JR 大阪環状線・東⻄線 JR 神⼾線阪急 神⼾線・今津線・宝塚線・伊丹線 阪神本線 大阪 神⼾ 阪神 武庫川線 14 宝 塚 伊丹 宝塚 大阪梅田 神⼾三宮 空から関⻄を⾒てみよう - 大阪〜神⼾ 大阪城 甲子園球場 （c）Noriko KAWAGUCHI, 2018.
- 16. 出典 : 国土地理院 https://maps.gsi.go.jp/ 空から関⻄を⾒てみよう - 神⼾〜姫路 神⼾三宮 姫路 明石 加古川 高砂 姫路 神⼾ JR 神⼾線阪急 神⼾線 阪神本線 15 明石海峡大橋 （c）Noriko KAWAGUCHI, 2018.
- 19. 清水さんに⾒せてみた 18 自分のXDDPの理解が合っているか確かめたくて、 清水さんに送ってみた。速攻で返信が届く。めっちゃ喜んでくれた♡ （c）Noriko KAWAGUCHI, 2018.
- 21. XDDPプラクティス路線図の生成プロセス 20 AFFORDD 関⻄部会 AFFORDD 現場 出典：ロベルト・ベルガンティ『突破するデザイン』 （c）Noriko KAWAGUCHI, 2018.
- 22. XDDPプラクティス路線図の生成プロセス（詳細） 21 AFFORDD 関⻄部会 AFFORDD 現場 出典：ロベルト・ベルガンティ『突破するデザイン』（c）Noriko KAWAGUCHI, 2018.
- 24. ラディカルサークルAFFORDD関⻄部会 - 衝突と融合（1/2） 23（c）Noriko KAWAGUCHI, 2018.
- 25. ラディカルサークルAFFORDD関⻄部会 - 衝突と融合（2/2） 24（c）Noriko KAWAGUCHI, 2018.
- 26. ラディカルサークルAFFORDD関⻄部会 – 新たな方向を⾒つける 25 清水さんがAFFORDD関⻄部会でお披露目してくれた。 パターン・ランゲージについて調べてみる。 特に、ツリー構造ではなく、セミラティス構造だったところ。 川口さんの路線図、 パターン・ランゲージですよ！ ほんまや！ 関⻄部会メンバー （c）Noriko KAWAGUCHI, 2018.
- 27. 論⽂にまとめることを決意 26 X D D P とパターン・ランゲージと鉄道路線図の組み合わせを 提言型論⽂としてまとめることを決意。 その頃、偶然、会社から何か論⽂を書いてみないかと声がかかる。 （c）Noriko KAWAGUCHI, 2018.
- 28. 論⽂「XDDP普及のためのXDDPプラクティス路線図の提案」 多様なステークホルダーが 理解可能なガイドマップ 選択的・段階的導入の 手順を表したロードマップ 27※1 The architect Christopher Alexander in 2012 / Michaelmehaffy / CC BY-SA 4.0 XDDPプラクティス路線図を提案 普及 課題 ① 普及 課題 ② 関⻄鉄道路線図パターン・ランゲージXDDP ※1 （c）Noriko KAWAGUCHI, 2018.
- 29. 論⽂で現在の形にまでブラッシュアップ 機能追加プロセス 変更 要求仕様書 変更 設計書 追加機能 要求仕様書 サイズ⾒積り アーキテクチャ 再構築法 変更プロセス リファクタリング リスク管理 USDM PFD プロジェクト管理 ユースケース 要件管理 スペックアウトTM⼀⻫に コード変更 設計 要求 モデリング ※点線はXDDPの取扱範囲外(隣接技術) 状態 遷移 業務フロー DFD 三段⾒積り トレーニング 品質保証 新規性管理 レスキュープロセス (火消し) 品質要求の 仕様化 仮説⾒積り Evolutionary Scheduling プロジェクト計画ピアレビュー DevJTestT型マトリクス テストプロセス 変更のアジャイル開発 モジュールの 尺度と分割 構成管理 コア・プラクティス プラクティス 乗 ⾞ 券 肯定眼→能動 乗 ⾞ 券 肯定眼→能動 結合 テスト システム テスト リリース 実装 進⾏⽅向 スケジュール管理 単体 テスト 機能追加のアジャイル開発 XDDP列⾞ 28（c）Noriko KAWAGUCHI, 2018.
- 30. 優秀論⽂として認められた！ 29 大事なことは、自分は何のためにこの人たちを説得するのに 苦労しているのかと言う問いに答えられることかもしれませんね。 まるで「宣教師」ですね。 今回のIBMに出した論文も、私にはこの線上の行為に見えます。 焦らず、諦めず、工夫しながら信じる道を開きなさい。 （c）Noriko KAWAGUCHI, 2018. ※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
- 31. 派生開発カンファレンス2017でお披露目 30 細谷さんをはじめ数人の方が パターン・ランゲージだと ⾒ただけで気づいてくれたのが と て も う れ し か っ た 清水さんが パネル・ディスカッションで 「路線図の彼女はXDDPの 本質を理解している」 と言ってくれたのは一生の宝 出典：http://affordd.jp/conference2017_program.shtml （c）Noriko KAWAGUCHI, 2018.
- 33. 派生開発に特化した開発方法論 清水 吉男 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 （c）Noriko KAWAGUCHI, 2018.
- 34. 派生開発とは 33 メカ エレキ ソフト 組み込みシステム 製品A Ver.1 製品A Ver.2 製品A Ver.3 製品D 製品B 製品C 新規開発に対峙させた概念 既存のベース・システムに対して機能追加や変更を⾏い、 新たなシステムを開発する 主に製品価値を高めるために⾏われる 例）クルマに自動運転機能を追加 機能追加・変更 機能追加・変更 機能追加・変更機能追加・変更 機能追加・変更 XDDPはシステムの 機能追加・変更を扱う （c）Noriko KAWAGUCHI, 2018.
- 36. 変更3点セット トレーサビリティ マトリクス トレーサビリティ マトリクス 変更 要求仕様書 変更 要求仕様書 変更 設計書 変更 設計書 追加機能 要求仕様書 追加機能 要求仕様書 ①XDDPの開発プロセス 35 追加機能 要求仕様書 の作成 結合 テスト ベース・ ドキュメントの 更新 追加機能分 の設計書の 作成 追加機能分 の実装 追加機能分 の単体テスト 参照 ※機能追加プロセスは、新規開発と同様のプロセスで実施する 変 更 プ ロ セ ス 機 能 追 加 プ ロ セ ス 機能仕様書 など 変更 要求仕様書 の作成 変更設計書 の作成 コードの変更 変更分の 単体テスト システム テスト 既存のソースコードを抜け漏れ・誤りなく変更することが求められる 既存のアーキテクチャ構造を踏まえた新しい機能の要求仕様書や設計書の作成が求められる （c）Noriko KAWAGUCHI, 2018.
- 37. ①XDDPの開発プロセス - 変更3点セット 36 作成順 ドキュメント名 視点 記述内容 1 変更要求仕様書 What : 何を変更するか？ Why : なぜ変更するか？ 変更要求・理由(要求の背景)と 変更仕様 2 ト レ ー サ ビ リ テ ィ ・ マ ト リ ク ス ( T M ) Where : どこを変更するか？ 変更仕様と コード変更箇所の関係 3 変更設計書 How : どのように変更するか？ コードの変更方法 コード変更に着手する前に 担当者の思い込みや勘違いによる不具合を取り除く 変更プロセスでは、システムの変更内容を異なる視点で 表現したドキュメントを、段階的に作成・レビューしていく （c）Noriko KAWAGUCHI, 2018.
- 39. 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 プラクティス （c）Noriko KAWAGUCHI, 2018.
- 41. ※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 ここ重要 クリストファー・アレグザンダー （c）Noriko KAWAGUCHI, 2018.
- 42. パターン・ランゲージ例 - 組織パターン アジャイル開発における組織のあり方をパターン・ランゲージの形式でまとめたもの Organizational Patterns of Agile Software Development パターン パターン・マップ 状況 問題 解決策 出典 : ジム・コプリエン他(2013) pp.275-276 出典 : ジム・コプリエン他(2013) p.243 41 出典 : ジム・コプリエン他(2013) 表紙 （c）Noriko KAWAGUCHI, 2018.
- 43. パターン・ランゲージで表現することのメリット 42 現場の状況に合わせて パターンを選択・再利⽤できる • 秘訣をパターンという ⼩さい単位で整理（部品化） • 現場の状況に合わせて 特定のパターンを選択して 再利⽤することができる ステークホルダー間の コミュニケーションを促進できる • パターンやパターン・マップを 共通言語として、 ステークホルダー全員が共有 • ステークホルダー間の コミュニケーションが促進され、 全体像を共有することができる パターンの順序・組み合わせを 知ることができる • パターンどうしの関連をパターン・ マップのネットワーク構造で表現 • 複数のパターンを一定の順序 で組み合わせるためのルールを 知ることができる （c）Noriko KAWAGUCHI, 2018.
- 44. 43 XDDPパターン（XDDP Patterns）の定義 構成要素 説明 パターン (Pattern) 個々のXDDPプラクティスを、パターンの形式で表現したもの パターン・マップ (Pattern Map) XDDPプラクティスの関連や適⽤順を、パターン・マップの形式で表現したもの 「XDDPをパターン・ランゲージの形式で体系化したもの」と定義 XDDPパターンがXDDP普及課題を解決すると考えた理由 導入ロードマップとして 活⽤可能 • プラクティスの関連や適⽤順を 表現できる • 現場の状況に合わせて必要な プラクティスを選択するための ロードマップとして活⽤できる 選択的・段階的導入が 可能 • XDDPプラクティスを パターンに凝集・疎結合化 • XDDPプラクティスを 部品化することにより 選択的・段階的導入が可能 共通言語としての ガイドマップを提供 • 多様な経験を持つ ステークホルダー同士が対話を するためのガイドマップを提供 • ステークホルダー全員にとって 目指すべき将来像を共有できる （c）Noriko KAWAGUCHI, 2018.
- 46. XDDPプラクティス路線図 機能追加プロセス 変更 要求仕様書 変更 設計書 追加機能 要求仕様書 サイズ⾒積り アーキテクチャ 再構築法 変更プロセス リファクタリング リスク管理 USDM PFD プロジェクト管理 ユースケース 要件管理 スペックアウトTM⼀⻫に コード変更 設計 要求 モデリング ※点線はXDDPの取扱範囲外(隣接技術) 状態 遷移 業務フロー DFD 三段⾒積り トレーニング 品質保証 新規性管理 レスキュープロセス (火消し) 品質要求の 仕様化 仮説⾒積り Evolutionary Scheduling プロジェクト計画ピアレビュー DevJTestT型マトリクス テストプロセス 変更のアジャイル開発 モジュールの 尺度と分割 構成管理 コア・プラクティス プラクティス 乗 ⾞ 券 肯定眼→能動 乗 ⾞ 券 肯定眼→能動 結合 テスト システム テスト リリース 実装 進⾏⽅向 スケジュール管理 単体 テスト 機能追加のアジャイル開発 XDDP列⾞ 45（c）Noriko KAWAGUCHI, 2018.
- 47. JR神⼾線 阪神武庫川線 阪急今津線 関⻄鉄道路線図とのマッピング 機能追加プロセス 変更 要求仕様書 変更 設計書 追加機能 要求仕様書 サイズ⾒積り アーキテクチャ 再構築法 変更プロセス リファクタリング リスク管理 USDM PFD プロジェクト管理 ユースケース 要件管理 スペックアウトTM⼀⻫に コード変更 設計 要求 モデリング ※点線はXDDPの取扱範囲外(隣接技術) 状態 遷移 業務フロー DFD 三段⾒積り トレーニング 品質保証 新規性管理 レスキュープロセス (火消し) 品質要求の 仕様化 仮説⾒積り Evolutionary Scheduling プロジェクト計画ピアレビュー DevJTestT型マトリクス テストプロセス 変更のアジャイル開発 モジュールの 尺度と分割 構成管理 コア・プラクティス プラクティス 乗 ⾞ 券 肯定眼→能動 乗 ⾞ 券 肯定眼→能動 結合 テスト システム テスト リリース 実装 進⾏⽅向 スケジュール管理 単体 テスト 機能追加のアジャイル開発 XDDP列⾞ 46 阪 急 神 ⼾ 線 JR大阪環状線 阪急宝塚線 JR東⻄線 阪神本線 姫路 神⼾三宮 大阪梅田 （c）Noriko KAWAGUCHI, 2018.
- 48. XDDPプラクティス路線図の作成の狙い 機能追加プロセス 変更 要求仕様書 変更 設計書 追加機能 要求仕様書 サイズ⾒積り アーキテクチャ 再構築法 変更プロセス リファクタリング リスク管理 USDM PFD プロジェクト管理 ユースケース 要件管理 スペックアウトTM⼀⻫に コード変更 設計 要求 モデリング ※点線はXDDPの取扱範囲外(隣接技術) 状態 遷移 業務フロー DFD 三段⾒積り トレーニング 品質保証 新規性管理 レスキュープロセス (火消し) 品質要求の 仕様化 仮説⾒積り Evolutionary Scheduling プロジェクト計画ピアレビュー DevJTestT型マトリクス テストプロセス 変更のアジャイル開発 モジュールの 尺度と分割 構成管理 コア・プラクティス プラクティス 乗 ⾞ 券 肯定眼→能動 乗 ⾞ 券 肯定眼→能動 結合 テスト システム テスト リリース 実装 進⾏⽅向 スケジュール管理 単体 テスト 機能追加のアジャイル開発 XDDP列⾞ 47 ①プラクティスの関連 ②プラクティスの分類 ③プラクティスの中心 ④プラクティスの順序 ⑤フィロソフィー(肯定眼と能動) ⑥導入の主体としての開発メンバー （c）Noriko KAWAGUCHI, 2018.
- 49. 48 XDDPプラクティス路線図の作成の狙い 多様なステークホルダーが①〜⑥を直感的・同時に理解できることを狙って作成 ①プラクティスの関連 • プラクティスを駅で表現 • プラクティスの関連は 駅と駅を結ぶ線路で表現 • 隣接するプラクティスは 現場に同時に導入することで より効果をあげることができる ②プラクティスの分類 • プラクティスと開発プロセスの 対応付けを、路線で表現 • 同じ路線上のプラクティスは 強い関連を持っている • どの開発プロセスの改善に⼒を 注ぐべきかに議論を集中できる ③プラクティスの中心 • 「USDM」 は XDDPの中心プラクティス • 各路線の始発駅が集結する ターミナル駅として表現 ④プラクティスの順序 • プラクティスの導入順を 始発駅からの駅の並び順で 表現 • プロジェクト管理は 循環的な構造を持つため JR大阪環状線をイメージ ⑤フィロソフィー （肯定眼と能動） • 肯定眼と能動を 乗⾞券として象徴化 • XDDPを実践する人・組織は この乗⾞券を持っていなければ ならない ⑥導入の主体としての 開発メンバー • 開発メンバーを XDDP列⾞として表現 • 開発メンバーが 主体的にXDDPを 導入していくことを象徴化 （c）Noriko KAWAGUCHI, 2018.
- 50. XDDP導入ロードマップの作成 49 XDDP列⾞の停⾞駅 （導入プラクティス） XDDP列⾞の始発駅 （開始プラクティス） 現⾏の 派生開発 プロセス 相当する現⾏プロセス ①現状分析 ③導入プラクティスの決定 ④開始プラクティスの決定②XDDPとのマッピング （c）Noriko KAWAGUCHI, 2018.
- 51. 現場で路線図を使った効果・課題 50 効果① ガイドマップ ロードマップ として 課題 効果② コミュニケーション ツールとして • リラックスした雰囲気が醸成され、活発に意⾒を引き出せた • 列⾞に例えて話すことで、問題について話しやすくなった 例）「この辺りの区間で列⾞がよくバックする」といった表現で、 手戻りが多いプロセスについて話してくれたメンバーがいた • XDDPの全体像を容易に伝えることができた • 選択的・段階的導入の道筋を描くことができた 全員XDDP未経験であったが・・・ 現場でのディスカッションでは・・・ 新駅開業により現場活性化へ • それぞれの開発現場では、 独自の⼯夫を⾏っている人がいることがわかった • 独自の⼯夫を、新しいプラクティス（新駅）として追加し 現場独自のパターン・ランゲージとして拡張していく （c）Noriko KAWAGUCHI, 2018.
- 53. XDDP Patterns を作りたい 52 AFFORDD関⻄部会メンバーに 協⼒してもらいながら、 パターン記述を作成中。 清水さんを通して顕れた 派生開発の良い実践の秘訣を XDDP Patternsとしてまとめたい。 （c）Noriko KAWAGUCHI, 2018.
- 54. あなたは、依頼者から要求仕様を聞き出そうとしている。 --- 派⽣開発の場合、依頼者はシステムの具体的な変更 内容を伝えてくることが多く、その背景にある依頼者が実 現したいことを伝えてくることは少ない。 実現したいことが不明確であると、本来必要な仕様が 漏れていたり、不適切な仕様で開発してしまうことがある。 --- それゆえ： USDMテンプレートを使おう。 • 要求仕様を「要求」と「仕様」とに分け、 階層構造で表現しよう。 • 「要求」には依頼者がシステムで実現したい“こと”を 表現し、仕様化の範囲を示そう。 • 「仕様」にはソースコードに変換可能な“もの”を表現 し、要求を満たすシステムの振る舞いや処理などを示 そう。 • 「要求」には「理由」を付け、「要求」の導出や洗練、 妥当性確認の拠り所にしよう。 XDDPのプラクティス - USDM 要求の仕様化技術、及び、要求仕様の記述方法 Universal Specification Describing Manner 状況 --- 問題 --- 解決策 プラクティス名 概要 イメージ写真 53（c）Noriko KAWAGUCHI, 2018.
- 55. XDDPのプラクティス - スペックアウト ソースコードを解析して設計資料を作り出す⾏為 ス ペ ッ ク ア ウ ト 状況 --- 問題 --- 解決策 プラクティス名 概要 イメージ写真 新規開発時に後の派⽣開発のときに有効な設計資料 は作られていないため、ソースコード以外に仕様を理解す る手がかりがない。 そのため、あなたは、ソースコードを読んで既存システムの 仕様を理解しようとしている。 --- ⼀般に、他人の書いたソースコードから仕様を読み取る ことは難しいため、あなたはソースコードの理解を誤ることが ある。 --- それゆえ： • あなたの理解状況を可視化して、 第三者に理解状況を確認してもらおう。 • 理解したことを図や表などを使って表現できるよう、 構造図、PADフローなどの表現技術を習得しよう。 • 可視化した設計資料は、今後の派⽣開発で活用 できるよう、ベース・ドキュメントの更新に取り込もう。 54（c）Noriko KAWAGUCHI, 2018.
- 57. 参考⽂献 56（c）Noriko KAWAGUCHI, 2018. 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)『クリストファー・アレグザンダーの思考の軌跡―デザイン⾏為の意味を問う』、彰国社