要求开発×アジャイル开発×ドメイン駆动开発
8 likes3,984 views
オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2013年6月定例会発表資料です。 Open Community "Requirement Development Alliance" 2013/6 regular meeting of the presentation materials.
Ad
More Related Content
What's hot (20)
Similar to 要求开発×アジャイル开発×ドメイン駆动开発 (20)
Ad
More from Kent Ishizawa (20)
Ad
要求开発×アジャイル开発×ドメイン駆动开発
- 2. www.openthology.org 本日話したいこと(1) ? 要求开発×アジャイル开発×ドメイン駆动开発（DDD) の三位一体の適用が最強だと思う根拠。 – 少なくともスクラッチ開発においては、現時点で最強のアプロ ーチだと感じる(SE27年の経験から) – どれか一つが欠けても駄目。適切なバランスで適用する。 要求開発 ドメイン駆動 開発(DDD) アジャイル開発 三位一体
- 3. www.openthology.org 本日話したいこと(2) ? 実際のプロジェクトで実践するために理解しておくべき 要求開発、アジャイル開発、DDDのエッセンス（本質的 な価値）と最小限のプラクティス。 – 実践するのは難しい？そんなことないでしょう。 – 最初から完璧な環境?手順を整備してからやろうとするから できない。 – できることからコツコツと始める。結果が出せれば物事はうま く動き始める。 「いつやるか？」「今すぐでしょう」 – 最初のチャレンジで完璧になる訳がない。謙虚に猛省し継続 的に改善する。フィードバック、PDCA、守破離のサイクルを 回せ。 – お手本を求め過ぎるな。エッセンスを理解すれば、やり方は 無限に工夫できる。守は少しで良い。破?離を重視しよう。
- 4. www.openthology.org 要求開発：質問1 ? 設計?実装に先駆けて実施する要求開発フェーズで、 どこまで要求を正しく理解すると想定しますか？ A) 要求開発をきちんと実施して、設計?実装前に100%完璧 に正しく理解するという前提で進めるべき。 B) 要求開発をいくら頑張っても、設計?実装前に100%完璧に 正しく理解するのは無理だという前提で進めるべき。
- 5. www.openthology.org 要求開発：質問1に対する私の見解 ? Bが私の前提。 B) 要求開発をいくら頑張っても、設計?実装前に100%完璧に 正しく理解するのは無理だという前提で進めるべき。 ? 100%完璧に正しく理解できるのが理想だし、設計?実 装前の要求開発では最大限そう努力すべきだと思う。 ? でも、現実には難しい。少なくとも私自身は今まで完璧 にできた経験は無い。おそらくこれからも無いだろう。
- 6. www.openthology.org 要求開発：質問2 ? 要求開発でどこまで詳細にシステムでの実現手段 (How)を考えるべきだと思いますか？ A) 要求開発ではWhy, Whatを明らかにするだけにとどまらず 、詳細にシステム上のHowを検討しておかなければ優れた 要求は導けない。 B) 要求開発ではWhy, Whatを明らかにすることにとどめてお くべき。詳細なシステム上のHowを考え過ぎると優れた要 求は導けない。
- 7. www.openthology.org 要求開発：質問2に対する私の見解 ? Aが私の前提。 A) 要求開発ではWhy, Whatを明らかにするだけにとどまらず、詳 細にHowを検討しておかなければ優れた要求は導けない。 ? Howにひきずられて、Why, Whatが吟味されないのは最 悪。しかし、Howを詳細に考えずして優れた要求を導き出 すのは難しい。Why, Whatを吟味した上でHowをどう考え るのか。我々ITプロフェッショナルの存在価値はそこにある 。 ? 設計?実装レベルでの実現可能性?必要コストが要求の選 別に大きな影響を及ぼす。そこまで考えずして、投資対効 果を最大化するために何をすべきか（作るべきか）は決ま らない。
- 8. www.openthology.org 要求開発：実践上の課題と解決の方向性(1) ? ウォーターフォールモデルって、要求開発で100%正し く要求を理解できるという前提に立っている。それって 現実的？ – 動くものを評価してみて初めて気づく要求を取り入れやすい アプローチ(要求開発×アジャイル開発)が必要だと思う。 ? 設計?実装まで進めてみて初めて「もっとこうすれば良 い」と思い付くことが多いのに、契約に縛られて変更で きないなんてナンセンスじゃない？ – 途中で要求を変更することを許容する進め方にもとづいた契 約(要求開発×アジャイル開発)が必要だと思う。
- 9. www.openthology.org 要求開発：実践上の課題と解決の方向性(2) ? 将来の要求の変化を事前の要求開発ですべて予測し て備えておくことって無理だよね？ – ライフサイクル全般（主に保守フェーズ）で要求の変化に迅 速に低コストで対応するためには変更容易なシステム構造( 要求開発×DDD)が必要だと思う。 ? そもそもシステム化対象の問題が巨大?複雑?難し過ぎ て、最初から全体を見据えて要求を考えられないことも あるよね? – ライフサイクル全般（開発&保守フェーズ）で要求を継続的に 改善するプロセスならびに変更容易なシステム構造(要求開 発×アジャイル開発×DDD)が必要だと思う。
- 10. www.openthology.org 要求開発：実践上の課題と解決の方向性(3) ? トップダウンに目的から手段に落とし込む単方向な思 考プロセスって本当に快適に実施できていますか？ – トップダウンで無理やり進めようとしても挫折する。 – 他人にはすぐに論理的に説明できない無自覚な思考過程( おそらく)を経て、直感的にぽっと出てきた手段（解決策）が最 適解ということも多い。 – ロジカルシンキングは、うまく説明できない直感的な解決策 の根拠を他人に共有したり、ヌケ?モレも含めて妥当性を評 価する際に有効だと思う。 – 最初に直感的なHowが脈絡なく出てきて、それらを足がかり に目的と手段を関連付けながら全体像を明らかにする方が 現実の思考回路に沿ってないか。ジグソーパズル。
- 11. www.openthology.org 要求開発：実践上の課題と解決の方向性(4) ? 後工程で苦労しないように要求開発のゴールを必要以 上に低く抑えようとしていませんか？ – 設定したゴール以上の成果を達成する可能性は皆無。だか ら、なるべく高くゴールを設定しておかないと、ユーザが満足 できる成果は得られない。 – ウォーターフォールは早い段階で要求を決定することを強い る。そうなると後から変更できないので安全側に倒したくなる 。アジャイルは「ぎりぎりまで決定を遅らせて」最適なオプショ ンを決定する。後者のやり方だと、ゴールを高く設定しておく ことへの心理的抵抗が緩和される(要求開発×アジャイル開 発) – ゴールはなるべく高く設定して引き算で調整する。プラクティ スはなるべくシンプルに設定して足し算で改善する。
- 12. www.openthology.org アジャイル開発：質問3 ? アジャイル開発について何を最も重視しますか？ A) 変化に適応しやすい B) ユーザの要求に応えやすい C) 問題やリスクを早く明らかにしやすい D) 人が成長しやすい
- 13. www.openthology.org アジャイル開発：質問3に対する私の見解 ? Cを私は重視する。 C) 問題やリスクを早く明らかにしやすい ? C以外のメリットももちろん大きいが、もっとも重視した いのは「問題やリスクを早く明らかにできること」。 ? アジャイルの良いところはウォーターフォールに比べて フィードバック、PDCAサイクルを短く回して継続的に改 善をしやすいこと。これがエンジンとなってAからDのメ リットを生み出している。
- 15. www.openthology.org アジャイル開発：質問4 ? この変更コスト曲線のグラフをどう解釈しますか？ A) ウォーターフォール(シーケンシャル)とアジャイル(インクリメンタル&イタ ラティブ)のライフサイクルモデルの違いによる差を表現している。 B) リファクタリングやテスト駆動などのプラクティスを実施している/いない の差を表現している。
- 16. www.openthology.org アジャイル開発：質問4に対する私の見解 ? 私はBだと思う。 B) リファクタリングやテスト駆動などのプラクティスを実施している/ いないの差を表現している。 ? ウォーターフォール vs. アジャイルのライフサイクルモデル の違いでここまでコストに差が出るとは正直思えない。ミス リードされていないか？ – 理屈が通らないと思う。少なくとも私はライフサイクルモデルの差 がこれだけのコスト差を生むことをうまく説明できない。 – 普通に考えると、変更容易なアーキテクチャを構築し、リファクタ リングで維持し、自動テストで再帰テストを効率良く行うことが、 変更コストを抑えるために必要なことでは？ – この点に関する規律が厳しい分、アジャイルが有利なだけ。
- 17. www.openthology.org アジャイル開発：実践上の課題と解決の方向性(1) ? なぜ、自分たちはアジャイル開発を採用したいのか？ – その根拠を明確に説明できなければならない。 – それが明確ではない場合、頓珍漢な結果に終わるリスクが ある。
- 18. www.openthology.org アジャイル開発：実践上の課題と解決の方向性(2) ? 私が重視するアジャイルのメリットの根拠の例 – 重視するメリット ? 問題やリスクを早期に発見し、手を打つことがやりやすい ので、開発コストを下げることができる。 – 問題/リスク ? 要求リスク ? 技術リスク ? 要員リスク ? 品質リスク ? 生産性リスク ? プロジェクトマネジメントリスク 等
- 19. www.openthology.org アジャイル開発：実践上の課題と解決の方向性(3) ? 私の根拠の例(続き) – アジャイルでは開発の初期段階から全工程を実行し、ユーザにも動くシ ステムを提供するので、問題/リスクがあればすぐに発覚する。 – 一方のウォーターフォールは後半の工程の問題/リスクを初期段階で発 見することが難しい。 – 問題/リスクに対処するためのコストは、プロジェクトが進行すればするほ ど高くなる。だから早く発見してリカバリしておく必要がある。 ベームが言いたいことは、プ ロジェクトが進行すればする ほど、それまでに作成した成 果物の量が増えていくので、 同じ目的の修正でも、やり直 し作業の量が増えてしまうの で、なるべく早い段階に誤りを 正しなさいということだと思う。
- 20. www.openthology.org アジャイル開発：実践上の課題と解決の方向性(4) ? 私の根拠の例(続き) – つまり、計画が非常に重要。 ? リスクが高いもの、重要なものをなるべく早い段階のスプ リント（イテレーション）で実施するように計画することが重 要。 – よくある失敗例 ? 簡単な機能を早い段階のスプリントで実施し、難しい機能を遅 い段階のスプリントで実施するように計画する。 ? 簡単なものから作って勝ち癖を付けたい、やり方が確立して生 産性も向上したところで難しいものを作った方が効率が良いと 考えてしまうのも理解できるが、これが失敗を招く。 ? 難しいものほどリスクが高い、重要度が高い場合が多いが、こ れらを後半に実施して問題が発覚してしまうと、問題を早く発 見して修正コストを抑えるというアジャイルのメリットがほとんど 享受できない。
- 21. www.openthology.org アジャイル開発：実践上の課題と解決の方向性(5) ? 私の根拠の例(続き) – つまり、計画が非常に重要。 ? リスクが高いもの、重要なものをなるべく早い段階のスプ リント（イテレーション）で実施するように計画することが重 要。 – よくある失敗例 ? 簡単な機能を早い段階のスプリントで実施し、難しい機能を遅 い段階のスプリントで実施するように計画する。 ? 簡単なものから作って勝ち癖を付けたい、やり方が確立して生 産性も向上したところで難しいものを作った方が効率が良いと 考えてしまうのも理解できるが、これが失敗を招く。 ? 難しいものほどリスクが高い、重要度が高い場合が多いが、こ れらを後半に実施して問題が発覚してしまうと、問題を早く発 見して修正コストを抑えるというアジャイルのメリットがほとんど 享受できない。
- 22. www.openthology.org アジャイル開発：実践上の課題と解決の方向性(6) ? 残念ながら、システムのライフサイクル全般で考えるとメリットを 得られるのはごく短い期間のみ。 – 基本的には開発フェーズの初期から中期の期間限定だと思う。 – 保守フェーズになるとウォーターフォールもアジャイルも差はなくなる。 – ライフサイクルを通じて変更コストを低く抑え続けるためには変更容易な アーキテクチャを整備するしかない(アジャイル開発×DDD) ここで10件問題発見して 解決できた 20万円×10件=200万円 ここまで10件問題を見過ごしてし まい、ようやくここで解決した 70万円×10件=700万円 ?同じ品質だったのにウォー ターフォールプロジェクトはア ジャイルプロジェクトに比べて 500万円損している。 ?曲線の高さだけを見ている とトータルでの損得が見えづ らくないか？ ?曲線の高さを抑えるよりも、 発見?解決の時期を早める方 が重要では？
- 23. www.openthology.org アジャイル開発：実践上の課題と解決の方向性(7) ? アジャイルは本当に変化に適応しやすいのか？ – 心構えとして変化を受け入れるというマインドが無いと、ライ フサイクルモデルだけ真似ても変化には適応できない。 – ウォーターフォールだから変化に適応できないのではなく、そ れ以外の要因が大きいように思う。 ? 変化への影響範囲の特定が難しかったり、修正量が大きくなり 過ぎたりすることが原因では？ ? さわって動かなくなるのが怖い。コピーして別機能で実現したり 、ユーザにあきらめてもらう。 – 結局変化への適応も開発プロセスよりもアーキテクチャによ るところが大きいように思う(要求開発×DDD)
- 24. www.openthology.org ドメイン駆動開発：質問5 ? ドメイン駆動開発(もしくはDCIでもOOでも良い）につい て何を最も重視しますか？ A) ビジネスロジックをプレゼンテーション操作から切り離す B) ビジネスロジックの共通化を図る C) データ構造変更の影響範囲を小さくする
- 25. www.openthology.org ドメイン駆動開発：質問5に対する私の見解 ? Cを私は重視する。 C) データ構造変更の影響範囲を小さくする ? もちろんC以外も非常に重要なこと。しかし、Cが実現しや すいことに大きな魅力を感じる。 ? プレゼンテーションは変化しやすいが、データ構造は変化 しづらい。そう信じてきたが、信じられなくなってきた。 – 要求が変化したらデータ構造の変更が必要な場合も多い。 – 初めから完璧なデータ構造を設計することは無理だと思い始め ている。 – データ構造の変更コストが高すぎるために変化に適応できない 。データ構造変更の敷居を下げないと変化への適応が進まない 。
- 26. www.openthology.org ドメイン駆動開発：実践上の課題と解決の方向性(1) ? 初心に返って、原理?原則にのっとってシステム作るの が一番必要じゃないでしょうか？ – DRY(Don’t Repeat Yourself) – 関心の分離 – 分割統治 – カプセル化 – 高凝集、低結合 ? これらって全て可能な限り機能を重複しないで作成 するための原則だよね。そうすることで変更に対応しや すくなる。 ? DDDもDCIもOOもすべて根っこにはこの原理?原則が あると思う。
- 27. www.openthology.org ドメイン駆動開発：実践上の課題と解決の方向性(2) ? 私、スーパー右翼とよく同僚に言われます – 具体的なビジネスロジックはなるべく右側のクラスのメソッド にする。 – 左側のクラスは右側を呼び出す手続きのみを簡潔に記述す るイメージ プレゼンテーション層 アプリケーション層 ドメイン層 インフラ層 Controller Facade Domain Service Entity Value Object Repository Persistence Factory
- 28. www.openthology.org ドメイン駆動開発：実践上の課題と解決の方向性(3) ? Entityをただのデータの入れ物としてしまうと個人的には DDDのメリットがあまり得られないと考えている – Domain ServiceやFa?adeに記述するビジネスロジックが増える。 重複のリスクが増す。 – Domain ServiceやFa?adeがデータ構造のルールを知らなければ ならなくなりやすい。データ構造の変更に弱くなる。 プレゼンテーション層 アプリケーション層 ドメイン層 インフラ層 Controller Facade Domain Service Entity Value Object Repository Persistence Factory