派生開発カンファレンス2024
ワークショップ
派生開発とアジャイルの「いいとこどり」～派生開発とアジャイルのアプローチを徹底比較し学ぼう～
サイボウズ株式会社 永田 敦
派生開発推進協議会 T4/T6研究会メンバー

2024年5月24日 13:25~15:25

©

2024

主催者紹介T04研究「XDDP」とテストプロセスとの接続
堀川透陽

©

2024

T06研究
Agileとの連携
永田 敦
斎藤賢一
葛西孝弘
工藤寛
中村勝志
星野充史
本田英稔

2

ワークショップ概要• アジャイルもも、既存の資産に変更や機能追加を行い、価値あるソフトウェアを提供することを目指しています• XDDPの勉強 資料では、アジャイルもである、と述べています• しかし、それらのアプローチは違います• 本ワークショップでは、の解決したい問題と課題に立ち返り、XDDPとアジャイルがそれをどのように課題を解決しているのか、そのアプローチを対比していきます• そこから、アジャイルがXDDPから学ぶこと、XDDPがアジャイルに学ぶことの気づきを、参加される方と一緒に探索していきます• これらの気づきは、アジャイルとのさらなる工夫や 化をもたらすことを期待しています©

2024

3

アジャイル開発とXDDP• 一見すると正反対のアプローチに見える、アジャイル開発とXDDPですが、互いに学ぶべきところがあると思います。
• T6研究会は、アジャイル開発とXDDPは融合できないか、考え方、価値観を互いに取り入れることはできないか、研究してきました。
• 今回のワークショップは、XDDPの勉強会の資料を基に、XDDPから学ぶこと、アジャイルから学ぶことをあげて、いいとこどりの考えを議論しようと思います。

©

2024

4

ワークショップのスコープ• XDDPのお話のスコープは広く、とても2時間では議論しきれません。そこで、今回は特に コードの実装のあたりをフォーカスします。
• XDDPでは、3点セット（変更要求仕様書、TM,変更設計書）を書き、レビューが終わるまで、コードに手を付けません。
• 一方でアジャイル開発は、要求ごとに設計、実装、テスト、結合をイテレーティブにおこなう開発スタイルです。
• この最も違いのあるところを中心に議論をしていきます

©

20245

開発の対象• 違いを直接議論する前に、開発の対象になるものを確認していきましょう

©

20246

©

20247

そういう定義でしたら、アジャイル開発は、ほぼすべて派生開発といえます。
アジャイル開発は、コードの変更は必然的なものととらえています

要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。 アジャイル宣言：アジャイルソフトウェアの12の原則
から変更の理由
1. 要求の追加
2. バグの修正
3. 設計の改善
4. リソース利用の最適化
レガシーコード改善ガイド

©

20248

©

20249

©

202410完全理解はできるのか？

• アジャイル開発も部分理解になる• すべてのコードを理解しようとすると、かなりの認知負荷がかかる
そもそも、全体を詳細に理解することは難しい• スコープを小さくする• 問題空間 ： 要求を小さく分解する• 解決空間 ： 仮説検証を小さく回す• チームで対応する• 多様性の利用©

202411

©

2024

12

一人プロジェクトの課題
一人プロジェクト

＝ほかの人とコミュニケーションをあまりとらない

暗黙知になりやすい
一応、フォームにのっとりドキュメントは書くけれど暗黙知化しているので、あまり書かない
派生開発の要求はスコープが小さく見えるので、問題空間の理解もそこそこに、すぐに解決空間に走りコードをいじる©

202413アジャイルでも一人プロジェクトになってしまうことがある
仕様の誤り、漏れが起こる
見積もりが悪い（なかなか終わらない）

品質が悪い

©

202414

©

2024

15

問題を引き起こさないように、設計、実装している

©

2024

16

アジャイルでもあるあるパターン
アジャイルのプラクティス（活動）の意味を理解せず、形だけをまねたもののばあい、これと同じようになることがある。
要求（バックログ）のレビューもなく品質が悪いと、仕様も生煮えのままコードをすぐにいじってしまうことになる。
振る舞いの漏れ （エラー処理やコーナーケース）
コードレビューやテストも的確でないと、内部品質が悪化し、デグレードやバグを生む。ネガティブスパイラル

アジャイル開発での失敗の原因

©

2024

17

巨大な泥団子

©

2024

18

シャンティタウン

©

2024

19

取り巻く環境、制約条件はアジャイル開発も変わりません

©

2024

20

©

2024

21

派生開発におけるバグの原因
問題空間

変更の要求仕様の品質

変更箇所（影響箇所を含む）の特定
解決空間

既存コードの理解
変更箇所の変更方法
既存コードの質

©

2024

22

©

2024

23

©

2024

24

解決空間

問題空間

変更を明確にする

変更箇所を探す

変更方法を考える

変更要求
仕様書

TM

変更
設計書

コードを変更するテストをする

一気に実装を行う

全ての要求に対し３点セットを作りレビューする

XDDP
©

2024

25

©

2024

26

コード変更を遅らし、一気に行う• 最適な変更の設計をしていきたい• 別な要求が同じ個所を変更することになったときに、それぞれの要求に合う最適な設計をしたい• 変更の影響による混乱を緩和したい• 全ての変更箇所を明らかにすることで、影響し合う状況が把握しやすい• よりコーディング自身の効率を上げたい• 変更設計書に以上に挙げた情報を盛り込み設計することにより、迷いがなく一気にコーディングすることができる• コードの劣化を最小限にしたい• 一気に行うことで、コードの変更の回数を最小限にできる©

202427

ディスカッション1
コーディングを遅らすメリットはなんでしょう？

©

202428

解決空間

問題空間

アジャイル
バックログ

要求（バックログ）ごとに繰り返す

変更を明確にする

変更箇所を探す

変更方法を考える

変更要求
仕様書

TM

変更設計書

イテレーション内

コードを変更するテストをする

一気に実装を行う

全ての要求に対し３点セットを作りレビューする

XDDP©

202429アジャイルの特徴• アジャイルでも、問題空間と解決空間は分けようとしている• 問題空間• スクラムではバックログ、Leanでもチケットで要求は表している• その要求における表現の質は、課題を持っているところもある。
• USDMの考え方は勉強になる• 要求のプラクティスがそろっている• リファインメント：バックログの内容を洗練する• ユーザーストーリマッピング• 実例マッピング（BDD)• 解決空間• バックログごとに、設計、実装、ビルドを行い、メインブランチに結合し、テストを行う。
• そこで要求どうりに実装されているかを確認できる• “Doneの定義”という、バックログの完了の定義がある

©

2024

30

アジャイル開発の違い• バックログ単位でコーディングを行う• PRO• すぐにテストをすることができる• 実装による問題や、仕様、設計の想定外の問題をいち早くフィードバックし学ぶことができる。

• CON• コードの変更が頻繁に起こるので、コード劣化のリスクがある。
• 同じところを何回も変更する

©

2024

31

変更によるコードの劣化
XDDPでは、ソースコードの変更は「１回」で済ませることで、ソースコードの劣化を防ぐ
ソースコードの変更は、数が少ないほど、ソースコードの劣化が少ない
ソースコードを変更すると、ソースコードは劣化する

©

2024

32

ディスカッション2
Q: なぜ、コードを変更すると、劣化してしまうのでしょうか？

©

2024

33Q: なぜ、コードは変更をかけると劣化してしまうのでしょうか？
変更するたびに、コードを2，3か所壊してしまう
コードを追加したり変更するには現在のコードにある“もつれ”、“ねじれ”“結び目”をいくつも理解しなければならない。
そして、コードを追加変更した後には、新しいもつれ、ねじれ、結び目がいくつもコードに加えられる。そして、以下のように 産性は時間とともに0に近づいていく©

2024

34

Clean Code：Robert Matin

可読性
コードを追加する際にも、常に既存のコードを読まなければならない。
コードを読みやすくすることは、書きやすくすることを意味する
コードは何度でも洗練しなければならない

洗練：リファクタリング
テストが必要イテレーティブなプロセス
少しずつ、コードを変えていく
TDD
リファクタリングが入っている©

2024

35

コードの変更を1回で済ませる
コードの変更は一度でよいものができるのだろうか？
”一遍のプログラムロジックであっても、それがエレガントで、プロの手による仕事とみなされるためには、3度も4度も書き直されなければならないことが多い
ヨードン”

変更設計書に“十分な“情報を書ききれることができるか？
変更設計書はコーディングの直前のところまで書くといわれるその組織でわかるところまで書く：目的とスキル
その“直前のところまで書いたもの”は、最適なものなのだろうか？
なので、レビューする
それでも不確実なもの、（コーディングをし、テストをして失敗すること）はないだろうか？
その失敗は学びになる
実験（仮説検証）と、熟考やレビューとのバランスをとること
©

2024

36

アジャイルから見たXDDP• 要求フェーズでの、要求の表し方は参考になる• アジャイルにおける要求と仕様• 要求はバックログのユーザーストリーとして対応している。
• 仕様はあまりドキュメントとしては書かれていないことがあり、本当にあるべき振る舞いが分からなくなることもある• 負担のない仕様の扱いが課題になる• XDDPからの学びの例：理由を書く、Before/Afterを書く• コーディングを最後まで遅らせる：違いを感じる点• 本当に動くかどうかの確認が遅れる。
• 仕様の理解、設計の質などへの学びのフィードバックが遅れる。
• 変更設計書も仮説であり、想定どうりになるかどうかはわからない• 顧客へのリリースとそのフィードバックも遅れることで、作っているものの価値の評価も遅れる

©

2024

37

まとめてみると• アジャイル開発は、派生開発といえる• 扱っている問題は同じ• シチュエーションも同じ• プロセスの面から• 問題領域は両者抑えている• 要求を抑えようとしている• 解決領域は違う• XDDP• ドキュメントとプロセスの工夫• アジャイル• 小さく、コードをテストしながら、積み上げることを繰り返す

©

2024

38

ディスカッション3
さて、どうしましょうか
あなたは、コードを遅らすことと、コードを要求ごとに動くかどうか評価することどちらがよいとおもいますか？

©

2024

39

システム更新の二つの方法準備をして変更する
業界標準
実行しようとする変更作業を注意深く計画し、更新対象のコードを理解し得散ることを確かめたうえで変更に着手します。
注意深く作業し、とてもプロらしい方法保護して変更する Cover and Modify
保護＝テスト
変更に問題があった場合でも、ソフトウェアのほかに害が及ばないようにする

©

2024

40

テスト
レグレッションテスト
既存コードを作るときに作ったテストを行い、影響が起きてないことを確かめるテスト
シフトレフト
バックログ（要求）を実装したら、すぐにテストをする
TDD

設計時にテストの網を張りながら開発をする
©

2024

41

リファクタリング
マーチン・ファウラー
コードを改善するプロセス
改善する前のコードのテストを作り、パスさせる
改善（リファクタ）の方針を立てる
コードを変更するテストをする

完了
©

2024

42

TDD テスト駆動開発 おすすめの工夫
ケント・ベック：ソフトウェアを構築する方法
機能させる：Make it work
正しくする：Make it right
速くする：Make it fast

テストで失敗する

©

2024

リファクタ

動くようにリング変更する
43

アジャイル開発の進化
多種多様のアイデア

多くの手法、工夫、プロセス、考え方
組織の在り方、チームのつくり方
そして、アジャイルを進化させてきたコミュニティが支えた

©

2024

44

派生開発を進化させよう
Afforddは進化の場©

202445

ディスカッション4
では、どんな進化が考えられるでしょうか
皆さんの派生開発の進化した姿を妄想してください©

2024

46

おしまい
ありがとうございました
T6一同T4（テスト）T6(アジャイル）の研究会に参加してみませんか？

©

2024

47