• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
要求開発×アジャイル開発×ドメイン駆動開発
 

要求開発×アジャイル開発×ドメイン駆動開発

on

  • 1,475 views

オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2013年6月定例会発表資料です。 Open Community "Requirement Development Alliance" 2013/6 ...

オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2013年6月定例会発表資料です。 Open Community "Requirement Development Alliance" 2013/6 regular meeting of the presentation materials.

Statistics

Views

Total Views
1,475
Views on SlideShare
1,465
Embed Views
10

Actions

Likes
7
Downloads
33
Comments
0

1 Embed 10

https://twitter.com 10

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    要求開発×アジャイル開発×ドメイン駆動開発 要求開発×アジャイル開発×ドメイン駆動開発 Presentation Transcript

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