ちょっと前に、
「データモデルなきアジャイル」の危うさ
http://watanabek.cocolog-nifty.com/blog/2012/08/post-def9.html
という話題が出て、その後、平鍋さんが
データモデリングなきアジャイル開発は危ういか？
http://blogs.itmedia.co.jp/hiranabe/2012/09/agile-and-data-modeling.html
というエントリを書いて、有名になった？話について、今日は書いてみる。
はじめの”「データモデルなきアジャイル」の危うさ”には、２つの暗黙の前提がないと、この話は成立しない（いや、もっとあるかもしれないが、とりあえず２つを挙げる）
（１）ＰＯＡとＤＯＡは、同時には成立しないか、同時に行うと
悪い結果になる。
（２）ＤＢ構造が複雑なシステムは、ＤＯＡで行えば、必ず成功する
ちょっと解説する。
（１）について、ＰＯＡとＤＯＡが同時に成立して、それをやるのが良いことであれば、排除する必要はなく、両方ともやればいい。たとえば、アジャイルには、
アジャイルの「ライトウィング」と「レフトウィング」
http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html
ということで、ライトウィングとレフトウィングがあるそうだが、ライトとレフトが「われこそがアジャイルなり」といって対立したら、不毛な争いになるが、普通そうは考えない。ライトとレフト、同時に１プロジェクトの中に存在し、両方やったほうが良いと考える（むしろ、有機的につながり、補完する考えであり）。その中で、あなたは、どっちのほうが、比重が大きいですか？という意味である。
つまり、抽象的に言うと、Ａ・Ｂという２つの考えがあり、この考えは。
・ＡかＢかというデジタルや、
・Ａは２０％、Ｂは８０％といった、線上の考えではなく、
あるプロジェクトは、Ａは２０時間、Ｂは８０時間、
別のプロジェクトでは、Ａは１０時間、Ｂは４０時間というふう
（おなじ１：４でも時間は違ってる）に、
面、あるいは３次元？的な考えができて、混ぜたほうがよりよい効果がでる概念がある（こっちの方がたぶん多い）
Ａにアジャイルのライトウィング
Ｂにアジャイルのレフトウィング
をいれればよい。
で、ここで話題にしているのは、
ＡにＤＯＡ
ＢにＰＯＡ
を入れることはできないか、ＰＯＡとＤＯＡは対立する概念ではなく、補完することができるとしたら、ＰＯＡを一方的に非難している”「データモデルなきアジャイル」の危うさ”のロジックは崩れてしまう。
（２）について、ＤＢ構造が複雑なシステムを、ＤＯＡで行って、もし失敗する事例があるとしたら、その事例でＤＯＡを使えない。この事象が起こる場合、ＤＯＡをよしとしている、”「データモデルなきアジャイル」の危うさ”のロジックは崩れてしまう。
■（１）について：ＤＯＡとＰＯＡは同時に成立する
そりゃ、目が細いお客さんの中には、
横浜、たそがれ、ホテルの小部屋、口付け、残り香、タバコの煙
と、事物だけしか説明しないお客さんもいるかもしれない
（いや、いないだろ・・・五木ひろしか山口洋子以外・・・）
だけど、ふつうのお客さんは、
たそがれ時に、横浜のホテルに泊まりました。
そのホテルの小部屋に入って・・・
と、動詞と名詞を同時に話す。
この動詞に着目するとＰＯＡ、事物に着目するとＤＯＡになる。
だから、お客さんレベルでは、ＰＯＡとＤＯＡは混在していて、開発者がヒアリングやドキュメントを意図的にどちらかに誘導することになる。
ということは、開発者がＤＯＡ、ＰＯＡと選んでいるわけで、ＰＯＡ、ＤＯＡにできる人はいるかもしれないし、１つの組織でＰＯＡの見方をする人と、ＤＯＡの見方をする人がいて、２人で開発を進めていけば（アジャイルのペアプロのように）高品質なシステムが作れるかもしれない。
で、そのように２つの見方、プロセスとデータの見方を同時にしてチェックするのが、たぶん鈴木 三紀夫氏のＷモデルの「２つのキャップ」であり、開発者がＰＯＡ、テスタがＤＯＡの立場を取ってチェックすると、バグが減るっていう話になるんだと思う。
（プログラマは、プログラムを考えるから、プロセス的に考えやすい。テスターは、テストデータを作る関係からデータ的に考えていきやすい）。
ＰＯＡとＤＯＡが対立する概念とは、必ずしもいえない。という気がしてこないだろうか？
長くなりすぎた。続きは後で・・・
「データモデルなきアジャイル」の危うさ
http://watanabek.cocolog-nifty.com/blog/2012/08/post-def9.html
という話題が出て、その後、平鍋さんが
データモデリングなきアジャイル開発は危ういか？
http://blogs.itmedia.co.jp/hiranabe/2012/09/agile-and-data-modeling.html
というエントリを書いて、有名になった？話について、今日は書いてみる。
はじめの”「データモデルなきアジャイル」の危うさ”には、２つの暗黙の前提がないと、この話は成立しない（いや、もっとあるかもしれないが、とりあえず２つを挙げる）
（１）ＰＯＡとＤＯＡは、同時には成立しないか、同時に行うと
悪い結果になる。
（２）ＤＢ構造が複雑なシステムは、ＤＯＡで行えば、必ず成功する
ちょっと解説する。
（１）について、ＰＯＡとＤＯＡが同時に成立して、それをやるのが良いことであれば、排除する必要はなく、両方ともやればいい。たとえば、アジャイルには、
アジャイルの「ライトウィング」と「レフトウィング」
http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html
ということで、ライトウィングとレフトウィングがあるそうだが、ライトとレフトが「われこそがアジャイルなり」といって対立したら、不毛な争いになるが、普通そうは考えない。ライトとレフト、同時に１プロジェクトの中に存在し、両方やったほうが良いと考える（むしろ、有機的につながり、補完する考えであり）。その中で、あなたは、どっちのほうが、比重が大きいですか？という意味である。
つまり、抽象的に言うと、Ａ・Ｂという２つの考えがあり、この考えは。
・ＡかＢかというデジタルや、
・Ａは２０％、Ｂは８０％といった、線上の考えではなく、
あるプロジェクトは、Ａは２０時間、Ｂは８０時間、
別のプロジェクトでは、Ａは１０時間、Ｂは４０時間というふう
（おなじ１：４でも時間は違ってる）に、
面、あるいは３次元？的な考えができて、混ぜたほうがよりよい効果がでる概念がある（こっちの方がたぶん多い）
Ａにアジャイルのライトウィング
Ｂにアジャイルのレフトウィング
をいれればよい。
で、ここで話題にしているのは、
ＡにＤＯＡ
ＢにＰＯＡ
を入れることはできないか、ＰＯＡとＤＯＡは対立する概念ではなく、補完することができるとしたら、ＰＯＡを一方的に非難している”「データモデルなきアジャイル」の危うさ”のロジックは崩れてしまう。
（２）について、ＤＢ構造が複雑なシステムを、ＤＯＡで行って、もし失敗する事例があるとしたら、その事例でＤＯＡを使えない。この事象が起こる場合、ＤＯＡをよしとしている、”「データモデルなきアジャイル」の危うさ”のロジックは崩れてしまう。
■（１）について：ＤＯＡとＰＯＡは同時に成立する
そりゃ、目が細いお客さんの中には、
横浜、たそがれ、ホテルの小部屋、口付け、残り香、タバコの煙
と、事物だけしか説明しないお客さんもいるかもしれない
（いや、いないだろ・・・五木ひろしか山口洋子以外・・・）
だけど、ふつうのお客さんは、
たそがれ時に、横浜のホテルに泊まりました。
そのホテルの小部屋に入って・・・
と、動詞と名詞を同時に話す。
この動詞に着目するとＰＯＡ、事物に着目するとＤＯＡになる。
だから、お客さんレベルでは、ＰＯＡとＤＯＡは混在していて、開発者がヒアリングやドキュメントを意図的にどちらかに誘導することになる。
ということは、開発者がＤＯＡ、ＰＯＡと選んでいるわけで、ＰＯＡ、ＤＯＡにできる人はいるかもしれないし、１つの組織でＰＯＡの見方をする人と、ＤＯＡの見方をする人がいて、２人で開発を進めていけば（アジャイルのペアプロのように）高品質なシステムが作れるかもしれない。
で、そのように２つの見方、プロセスとデータの見方を同時にしてチェックするのが、たぶん鈴木 三紀夫氏のＷモデルの「２つのキャップ」であり、開発者がＰＯＡ、テスタがＤＯＡの立場を取ってチェックすると、バグが減るっていう話になるんだと思う。
（プログラマは、プログラムを考えるから、プロセス的に考えやすい。テスターは、テストデータを作る関係からデータ的に考えていきやすい）。
ＰＯＡとＤＯＡが対立する概念とは、必ずしもいえない。という気がしてこないだろうか？
長くなりすぎた。続きは後で・・・
アクセス
トータル
ランキング
