以前に、要求分析と実装部分（外部設計部分）で、断層が起こるという話を書いた（ここ）
で、この問題、国家を挙げて行っているe-Japan構想でも起こっているようだ。。
ちょっと古いが、ここ
崖っぷち！電子政府～迷走する4500億円プロジェクトの行方・第3回：
問われるGPMOの調整機能 (1/2)
http://www.itmedia.co.jp/enterprise/articles/0608/15/news002.html
の真ん中くらいの図を見ていただきたい。
最適化というのは、国がＥＡをいうときの言い方（最適化計画という言い方をする。なぜこういうのかは、後述）。
この最適化計画から、基本設計（ウィリアムのいたずらが行っている外部設計の部分にあたる）にいたるところがあいまいであるというのを示している。
ちなみに、その詳しい話は、上記サイトに譲る。。。が、一点問題にしたいところがある。
それは（以下斜体は上記サイトより引用）
最適化計画は上流工程に当たるが、下流工程のプログラム実装やハードウェア販売で儲けたいベンダーは最適化計画を軽視しがち。事実、財政当局は上流工程に多くの予算を割かないため、それを安値受注したコンサルティング会社や監査法人も最適化計画を熱心につくらない。その結果、肝心の方式設計が曖昧になる悪循環が続くのだ。
これは、技術論敵に言うと、ちょっと違うのだ。
（もっとひどいのだ ＞＿＜！）正確に言うと、
最適化計画で使っている（多くはＤＯＡやそれ以前の）分析技法と、
現在のプログラムで使う（オブジェクト指向の）フレームワークの方式は、
合わないのだ（＝連携が取れないということ）。だから、かりに、きっちりしっかり分析したとしても、方式との連携ができないので、ここは、あいまいになってしまうのだ。
なので、肝心の方式設計があいまいになるというか、つながんないのだ。。（＞＿＜！）
具体的に話そう。
世の中のコンピューター設計の考えには、ＤＯＡとオブジェクト指向の２つの考えがある。
ＤＯＡは、全社的にデータを洗い出し、そこから最適なプロセスを考えていく。
一方、オブジェクト指向というのは、カプセル化を基本とする。ある部署なら部署、担当者なら担当者のオブジェクトを生成し、そこに送るメッセージと答えが満足できるものであればＯＫ。
（ちなみに、にているけど、ちょっと違うなんていう場合は、継承して、それにあったオブジェクトをつくる。これも、オブジェクト指向の基本的な考えだ）
このとき、そのオブジェクト内の処理は不問とする。だから、オブジェクト内が、最適になっているかどうかは、わからない。
このため、大きなプロジェクトでは、中身が不問になる、オブジェクト指向のほうが、向いているとされる。
ウィリアムのいたずらは、一概にそうとは言えないと思うが（前に、大きなシステムはむしろＤＯＡが向いていると書いている）、システムを手早く作るには、オブジェクト指向が向いている（ウィリアムのいたずらの考えは、そのため、いったん部分部分を、オブジェクト指向でつくり、全体を見切った上で、ＤＯＡでもう一度、きれいに作り直したほうがいいという考えを持っている。上記は、その意味で書いている）
さて話を、国のＥＡに戻して、ＥＡは部分最適でなく、全体最適になるような組織を目指している。ここから、最適化計画という言葉が来ている。
このため、現状の全体の組織、データ構造を明らかにし(AsIsモデル）、そこから全体最適の理想像(ToBeモデル）の組織、データ構造を作り上げていく。
そして、実際手法としては、
ＥＲ図、ＤＦＤ、情報システム関連図といった、
ＣＯＢＯＬ時代の構造化分析、その後のＤＯＡ時代に良く使った手法がでている。
一方、現在は、クラス内に、データとメソッドを隠蔽し、メッセージ中心のアプローチになっている。この形に落とし込めば（ＵＭＬでも、それは可能）JavaやＶＣ＋＋にも落とし込めるし、Ｗｅｂアプリにも落とし込める（ブラウザの画面とは、属性値が入力欄、プッシュボタンがメソッドにあたるクラスと考えられる）。
今のＪａｖａでの開発は、したがって、クラス図中心、場合によりシーケンス図であり、（あと分析にアクティビティ図、ユースケース図）このクラス図は、あくまでもカプセル化のために、データとメソッドをひとまとめにする。
ところが、ＥＡでも、クラス図は使われるが、それは、データ体系でデータの構造をまとめるための利用でしか過ぎない。ビジネス（ＢＡ）とデータが分離されてしまっているのだ。これじゃー、オブジェクトにならないので、使えない。
さらにもっとひどいのは、ＣＩＯ連絡会議では、クラス図が、政策業務体系（ＢＡ）で使うという。。おい、どっちなんだよ（＾＾；）
っていうか、この２つを分けちゃうことに問題があるんだけどさ（＾＾；）
てなかんじで、ＥＡでの分析体系は、ＤＯＡとかにむいていて、一昔前のＣＯＢＯＬ開発に向いている（ＤＯＡではＪＡＶＡ開発は無理という意味ではない。なぜなら、ＤＯＡのＥＲ図とＤＦＤから、クラス図に持ってくる手法はあるので。。しかし、その場合でも、Javaに落とし込むときは、クラス図を使う）。
情報システム関連図からは、ＣＯＢＯＬのような処理を持ってくることにはいいんだけど、Javaのように、カプセル化する言語だと、なにをカプセル化して、あるメソッドにおいて、他のクラスにどういうメッセージを送ればいいかはっきりしないので、処理があいまいになる。
っていうか、情報システム関連図作るんだったら、クラス図しっかり作ってくれってかんじ。
publicやprivateまできっちりしっかり、引数もきっちりしっかり決めて。。
っていうかんじで、ＣＯＢＯＬ時代の上司のプロマネが、部下のＳＥやＪａｖａのプログラマに指示出しているような感じで、話が合わないのだ。。この図の体系は。。
なんで、この場合は、ウィリアムのいたずらが言った、要求と方法論の断層というよりかは、もっとひどい、世代間（ＣＯＢＯＬ世代とＪＡＶＡ世代）の断絶、それが、大人が中途半端に、若者に擦り寄って、若ぶってクラス図なんか、もちだすから、なおさらわけわかんねーっていう感じに見えてしまう。
。。。なーんてかいて、大丈夫かなあ（＾＾；）
まあ、かいても、
批判がこなかったり、
削除命令がこなかったり、
ブログがある日突然潰れている（＞＿＜！）
とかいうことがなかったら、
もっと、根本的な問題、そもそも、全体最適化をすることは、可能なのか、
もっと根本的な、全体最適化をすることは、本当にいいことなのか？
っていう話題を、書いてみたいと思います。
アクセス
トータル
ランキング
