ちょっと前に、
みんなが幸せに、儲かるんなら、どんな理論を使っても、いいんじゃないか？その１
http://blog.goo.ne.jp/xmldtp/e/d7848b56fdd3d83963b7611596e25261
というのを書いて、そのあと続きを書いていなかった。
今日はそのつづき
もともとの話は、
「データモデルなきアジャイル」の危うさ
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://blog.goo.ne.jp/xmldtp/e/d7848b56fdd3d83963b7611596e25261
というのを書いて、そのあと続きを書いていなかった。
今日はそのつづき
もともとの話は、
「データモデルなきアジャイル」の危うさ
http://watanabek.cocolog-nifty.com/blog/2012/08/post-def9.html
という話題が出て、その後、平鍋さんが
データモデリングなきアジャイル開発は危ういか？
http://blogs.itmedia.co.jp/hiranabe/2012/09/agile-and-data-modeling.html
というエントリを書いて、有名になった？話について、
（１）について：ＤＯＡとＰＯＡは同時に成立する
は書いた。今日は、
「（２）ＤＢ構造が複雑なシステムは、ＤＯＡで行えば、必ず成功する」とは言い切れない
から
■「（２）ＤＢ構造が複雑なシステムは、ＤＯＡで行えば、必ず成功する」とは言い切れない
この例としては、要求工学―プロセスと環境トラックのＰ５２、抽象モデルの構築に失敗した場合の例として、２つ上がっている
ひとつは、ビジネスプロセスのオブジェクトモデルを構築したが、管理が複雑になり、顧客が構築したモデルを理解できず、検証できなかった例、もう一つは、ペトリネットを使って失敗した例が載っている。
前者の例は、オブジェクトモデルなので、データ中心のモデルと似たようなものができるはず（エンティティ＝クラスといえるので）。したがって、ここでの失敗は、同じ失敗がＤＯＡでも起こりえるといえる。
つまり、管理が複雑になり、検証できなくなるのだ・・・
あまりにも、データが複雑になりすぎると、管理、つまり、データが適切にＣＲＵＤしているか、（生成されていないのに読み込むなどということはありえないか）、検証できるか（ユーザーが業務的に問題ないと追っていけるか）という問題に突き当たる。これは、ある一定の限度がある。
と書いても、ＤＯＡ中心の人には、「オブジェクトモデルとＤＯＡはまったく違う、真逆の概念である」といいはってしまうだろうから、もっとＤＯＡチックな例を挙げよう。
昔、ＥＡというのが盛んだった。これはＤＯＡ的なアプローチを取る。
そして、ＥＡによる政府の代表的な例として、人事院のシステムがある。このシステムは、はじめ、ＩＢＭと富士通が請けて、結局うまくいかず、その後、菊島氏がＣＩＯ補佐官となり、稼動にまでこぎつけた話がある。たしか、ＩＢＭ＋富士通のときは、ＥＡ（ＤＯＡ）的なアプローチで、ＤＦＤを作って行ったんじゃなかったっけ？それでうまく行かず、ユースケースにしたんじゃなかったかな？菊島さんのときに・・・
だとすると、「要求工学―プロセスと環境トラック」の定石、抽象モデルの構築に失敗した場合、ユースケースシナリオを使うという典型的な例になりますよね。
■大きいシステムは小さく分割して確認する－アジャイルもそのひとつ
結局、大きいシステムは、ＰＯＡにしろ、ＤＯＡにしろ、ある程度になると、人間の限界が来てしまう。
そこで、限界が来る前に、小さく分割して、それを組み合わせるというアプローチを取るしかない（完全自動化による検証というアプローチもあるが・・これがモデル検査に繋がっていく）。
その場合、小さく区切って、それをすばやく組み立てて確認することになるが、そのアプローチのひとつが、アジャイルなのであろう。
また、小さく区切った中の部分は、好きなように開発してよい。ＰＯＡでも、ＤＯＡでも、ウォーターフォールでもアジャイルでも・・ただ、ＰＯＡで混乱する開発量と、ＤＯＡで混乱する開発量では、差があるかもしれない。なので、その際、どちらにしたほうがいいかという議論はある。
■宗旨替えの必要はない
じゃあ、アジャイルがよくって、この人がアジャイルをやったほうがいいのかというと、そんなことはない。この人はＤＯＡで成功してきたんだから、そのままＤＯＡでよいのではないか。
人によって、開発規模とか、開発期間とかは、まちまちだと思う。この人は、ＤＯＡで成功するが、ＰＯＡでやると失敗する開発規模・開発期間なのであると思う。
世の中、一般的に考えると、開発期間がとても短く、全体がはっきりしない中で開発しないといけない場合、修正されることを前提にＰＯＡということもありえるだろうし（ＰＯＡかＤＯＡかは別として、この場合アジャイルの可能性が高い）、適当な規模の場合には、ＤＯＡ＋ウォーターフォールが一番開発しやすい場合もあるだろう。
そして、たいてい営業がとってくる仕事、自分が取れる仕事というのは、似たような規模、似たようなケースが多い。だから、ＰＯＡでやったほうがいい、ＤＯＡのほうがいい、アジャイルのほうがいい、ウォーターフォールのほうがいいなどは、決まってくる。ただ、これは絶対じゃないし、請けてくる仕事が変われば、おのずとベストな方法論は違う。
だから、みんなが幸せに、儲かるんなら、どんな理論を使っても、いいんじゃないか？
でも、状況が変われば、自分の方法論では対応できなくなることがありえる。だから、ひとつの方法論に固執すべきでないし、自分以外の方法論を批判して、反撃すべきではない。その方法論を使わないと解けない問題が出てくるかもしれない。こっぴどく反撃したら、その理論は使えない（使ったら周りから蔑視されるだろう。「なんだあいつ、あんだけ言っておいて、結局その手法使うんジャン」と・・）
そういう意味で、アジャイルも、ＤＯＡもＰＯＡも、ＪａｖａもＪａｖａｓｃｒｉｐｔもＰｙｔｈｏｎもＣＯＢＯＬもＲＤＢもＮｏＳＱＬも、何でもいいんじゃないかと思う。
それを適切に使いこなせる人だけが、次の時代に生き延びれるんじゃないかなと思う。
長々と、駄文を書きすぎた・・
この話は、このへんでおしまい。
アクセス
トータル
ランキング
