« 「スクラッチ開発」という名のゴムボート | トップページ | 会計システムにオトシマエをつける »

2005.05.08

「As-is先行」か「To-be先行」か

前回、DOAとOOAとの対立の話を書いたが、DOAとて一枚岩ではなく、いろいろな考え方をする人たちがいる。だから、筆者も参加している「DOA+コンソーシアム」の集まりは、椿正明博士や佐藤正美氏といった歴々の方法論者や、商売上競合しそうな営業担当者同士が呉越同舟で語り合うという、奇跡のような企画である。参加者の考え方の違いは想像以上で、「どうも偶然にも、我々は全員『DOA+コンソーシアム』という集まりに名を連ねているらしい。一致点が見つかってよかったなあ」なんて冗談が出るほどだ。それほどに違いを楽しめるというのも、本質的な部分が共通している余裕ゆえなのだろう。

DOAの中でも議論になりやすいのが、「現状分析と基本設計のどっちを先にやるべきか」という問題だ。その前後関係が分析・設計手法の前提をまったく変えてしまうからだ。まあ、けっきょくは「個別の案件毎に特性が違うから、どっちが正しいとはいえない」なんて面白みのない結論にたどり着いてしまうのだが、論者のシステム観がよくわかって面白いネタだ。

じつは最近まで、現状分析は基本設計に先行してなされるのが当たり前と思われていた。企業システムに限らず何かを改善するためには、とりあえずその現状を理解しなければ何も始まらない。そのように考えれば、現状分析を先行させるのがごくまっとうなやり方で、議論の余地なんてなさそうにも思える。

ところがどうもそうとは限らないのが、システム開発の一筋縄でいかないところだ。筆者自身は「現状分析は基本設計の『後』で実施すべし」の側に立つ(少数派である)が、これを敢然と主張するようになったのは、あるプロジェクトの顛末を身近で見たことがきっかけだった。それは「構造化分析設計手法(SA/SD, Structured Analysis/ Structured Design)」の方法論にもとづいて実施されていた大規模プロジェクトだった。

◆構造化分析設計手法の問題

SA/SDは、「熊とワルツを」等の著作で有名なトム・デマルコらによって提唱され、80年代から90年代初頭にかけて流行した開発手法である。大きな特徴は「現状(As-is)を詳細に調べて抽象化すれば、あるべき姿(To-be)が導き出される」という信念にもとづいている点だ。まず、(1)現在の物理構造を調べ上げ、そこから(2)現在の論理構造を抽出する。次に(3)現在の論理構造から「あるべき論理構造」を洞察する。さらに(4)「あるべき論理構造」から「あるべき物理構造」を導く、というやり方をとる。

具体的には、(1)~(4)のそれぞれの段階でDFD(Data Flow Diagram)を作成する。それらの成果物は順に「現物理フロー」、「現論理フロー」、「新論理フロー」、「新物理フロー」と呼ばれる。これらの成果物は厳密に層別化(レベリング)されていて、最上位の図面は「コンテキストダイアグラム」と呼ばれ、最下位の図面(プログラムに相当するプロセスの内部を表す)は「ミニスペック」と呼ばれる。これらのドキュメントが完成したなら、「新物理フロー」の「ミニスペック」にもとづいて詳細設計がなされ、実装され、システムは完成する。

(2)現論理フロー → (3)新論理フロー
  ↑           ↓
(1)現物理フロー   (4)新物理フロー

このやり方をとるのであれば当然なのだが、実際に作成した図面を見せてもらったとき、なによりもその「量」に圧倒された。各レベルのフローにプロセスが平均4つ並んでいるとして、レベル0から4まで階層化するとしたら合計341(=1+4+16+64+256)枚の図面が描かれることになる。しかも、これらを「現物理フロー」、「現論理フロー」、「新論理フロー」、「新物理フロー」の4セットぶん作らねばならない。「DFDはもう見たくない」とうんざりしていた友人の顔を思い出す。

図面の枚数が多くても、それが良い結果を生み出すのであればかまわない。機械的な作業の積み重ねで困難な課題を解決できるとしたら、それこそ方法論の真骨頂だ。しかし、SA/SDはそうではなかった。決定的な問題は、上述した「現状(As-is)を詳細に調べて抽象化すれば、あるべき姿(To-be)が導き出される」の信念に合理的な根拠がなかった点だ。要するに「現論理」から「新論理」を導き出すなど、どう考えても無理なのである。もしそれが可能だとしたら、現行システムは改修の必要のないほどに洗練されているはずだ。なんという矛盾だろう。

SA/SDは一時代を画したといっていいほど流行したが、ものすごく手間がかかるわりに成功事例が少ないことから急速に廃れた。(余談だが、SA/SDは日本ではなぜか「DOA」の呼び名で実施されたため、DOAと聞くと「ああ、あのDFDを山ほど書くやり方ね」と応える人が今でもいて困る。SA/SDはDOAとは関係ない。それどころかデータ中心とは正反対のプロセス中心型のアプローチだ)

◆現行システムは「企業の強み」と「市場の制約」の鉱脈

筆者はそれまでも、不毛と思えるくらいに現状分析に時間をかけるやり方に疑問を感じていたので、SA/SDのやり方を身近で見た経験は強烈だった。それで、あっという間に「現状分析不要」の過激派に走ってしまったのだが、ほどなくそれも間違いであることに気づいた。

現行システム(コンピュータを使っているとは限らない)には、その企業を存続させている「強み」や、企業努力では変更できない業界や市場での「制約」といったものが克明に記録されている。たとえば、営業担当者が納品時に顧客の意見をきめ細かく聞き取って上司に報告する過程があって、これが顧客の信頼を生んでいるのかもしれない。また、無意味なほどに複雑なキックバックの計算手順が組み込まれているが、これを前時代的と切り捨てることもできない業界の慣行があるのかもしれない。そして、これらはユーザにとってことさら「強み」とか「制約」とは意識されていない可能性も高い。

意識されていないことが多いとはいえ、それらの要素を基本設計に盛り込み損なうとひどいことになる。強みを発揮できなくなって業績が悪化したり、制約を反映していないためにシステムとして使い物にならなかったりするからだ。

◆現状分析はきっちりやるべし(ただし基本設計の「後」で)

では、現行システムのあり方からそれらの宝石を採掘するにはどうしたらいいのだろう。「企業の強みはどこだー、市場の制約はどこだー」となまはげのように探し回ればいいのだろうか。それは無理だ。ユーザ自身がそれをそれとして意識していないだけでなく、「比較対象(コントロール)」がないからだ。

たとえば、「あなたの個性は何ですか」と訊かれて、「他人との比較」なしで答えるのは不可能だ。「個性」が字義上「他人との比較」を含意しているからだ。そして、比較されるべき「他人」はマイケル・ジャクソンのような個性派であってはいけない。「一般的に人はこのような傾向を持つものだ」みたいな平均的な人物像を想定して、それとの違いがようやく「個性」とみなされる。

「企業の強み」や「市場の制約」はその企業システムの「個性」のようなものだから、これをあぶりだすためにも、「この業種の企業システムは一般的にこのような傾向を持つものだ」といった理想化されたシステム像が必要だ。以前にも書いたように、業種別のシステム設計の型紙集みたいなものが流通しているわけではないので、理想化されたシステム像なんてものは用意できないように思える。しかし、「現状分析に先行して実施された基本設計の成果物」を、上質の比較対象として利用できるのである。

家の改築に喩えれば、設計士が描いた新しい家の図面と、現在の家の見取り図とを比較して、はじめて「神棚」を置くスペースがないことに気づくようなものだ。その施主にとって、神棚に毎朝お参りすることが、家の個性とさえ意識されていないほどに当たり前の慣行ならば、設計士との打ち合わせの際に「神棚のスペースをよろしく」とはことさら言わないかもしれない。設計士としても、神棚にこだわる家族がいることが想像を絶しているなら、施主との打ち合わせの際に「神棚はどうしましょう」とはことさら言わないかもしれない。そのようなお互いの常識の差にもとづくすれ違いを是正するには、新しい家の図面と現在の家の見取り図を比較するのが効果的だ。

基本設計、現状分析、の順序の意義をじゅうぶん理解してほしい。基本設計においては、現行システムに変に引きずられずに伸び伸びと「To-be」を組み立てる。続く現状分析においては、「To-be」を「強みや制約が考慮されたTo-be」に洗練させる。この順序でやれば、もっとも少ない工数で効果的な新システムの仕様を生み出せる。つまり、現行システムは新システムをデザインするための「発想の源」ではなく、新システムの「フィージビリティ(実現可能性)」を確保するためのダシとして「いいように利用される」ということだ。

反対に、現状分析の後で基本設計を実施すると、現行システムの仕様が新システムをデザインするための「発想の源」となり、代わり映えのしないシステムが生み出されやすい。問題はこれにとどまらない。新システムの仕様を発想できないのは、現行システムの仕様がじゅうぶんに理解できないゆえに違いない――スキルの足りない技術者はそのように判断して現状分析に耽溺する。住宅を全面改修するために現状の畳の目の数を虫眼鏡を使って数えるような、丹念かつ不毛な作業を延々と続ける。結果的に、完成が遅れる。

付言すれば、基本設計の後で現状分析を実施するやり方にも問題がないわけではない。ユーザのカジュアルな発言だけにもとづいて「それならこんな感じでどうでしょう」とその場でTo-be案を描き広げるためには、さすがに適性や経験が求められる点だ。とはいえ、これも致命的な問題ではない。企業システムの設計者も「建築家」や「ミュージシャン」と同様、適性も地道な訓練も必要なフツーの専門職のひとつであるというだけの話だ。誰もが手軽になれる職業があるとしたらそれは「専門職」ではない。「この弾き方で、10日後にはあなたもプロミュージシャン」なんて広告を信じるマヌケはいない。

|

« 「スクラッチ開発」という名のゴムボート | トップページ | 会計システムにオトシマエをつける »

コメント

こんにちは、再びお邪魔いたします!

自分も学部の卒研では、分析設計方法論について研究してました。

渡辺さんが考案された方法論では、「基本設計」から入るという
ことですが、この場合、顧客の要求と僅かな調査結果から理想と
するシステム像(モデル)を構築するということですよね。

そこで、疑問なのですが、そのシステム像はどのような因果関係を
背景として考案されているのでしょうか。


仕様を確定することが「行為」であるからには、必ず「理由」が求め
られ、設計者にはその行為に及んだ「説明責任」が伴うはずです。

「私自身の経験からは、このようなケース(問題)にはこのような
機能を作ることが対策として効果的であり、実証済みだからです」

・・と明確な理由があるのなら、もちろんそれも有効だと思います。

但し、そのような設計者の考案した機能が「プロジェクトの開発目的
に貢献(あるいは合致)していること」が大前提条件です。

「何をどのような目的で作るのか?」が解らなければ「作れない!」

もし、考案した機能が「開発目的に貢献するものでない」とすれば、
単なる「顧客無視の押し付け」になってしまうはずです。

例えば、開発目的が「在庫回転率の向上」であるのに、その根本的
な原因を探らずに、すべての取引結果をデータベースに落とし込み、
ひたすら自動化するのは、明らかに「顧客無視」な行為です。


このような開発目的とは、通常、顧客の要望と、その背景となって
いる「現状における背景と問題」から導き出されて、一義に収束し
定義されるものです。(市場の要請や制約はこの背景となりうる)

つまり、「背景」→「問題」→「要望」→「目的」→「手段」です。

はたして、殆ど現状調査もされていない段階で、理想のシステム像、
つまりは「目的を達するための手段」が定まるのでしょうか。

もちろん、仮説を立てておいて、徐々に修正を加えていくという
アプローチも有効なのでしょうが、どうしてそこに「DFD」や
「ER図」が登場する必要があるのでしょうか・・??

このとき必要なのは、「現状の業務像(背景)」と「理想の業務像
(目標)」であって、「実現方式」が求められているわけではない。


もう一つ、渡辺さんの主張する「業務知識ライブラリー」の構想は、
大変素晴らしいのですが、「業種別・分野別に整理された簿記の
教科書や参考書」と、何がどのように違うのでしょうか??

「成功事例」「失敗事例」として上げて、なぜそのような結果に
なったのか?、どこに原因があったのかを、プロジェクトの背景
(問題、要望、目的、手段)と照らし合わせて知識化するのなら、
教材としては非常に優れたものになると思われますが・・。

それと、「平均的」あるいは「理想的」であるかどうかの基準は、
一体どのようにして定めるのでしょうか。(統計?合意?)

現在、分析設計パターンに関する研究は盛んで、多くの論文が執筆
され国際会議まで開かれていますが、まともな成果として産業界で
活用されている話など殆ど耳にしません。(まず無理がある)

以上のような質問(突っ込み)なのですが、宜しくお願します。

投稿: 後町(gocho) | 2005.05.08 13:08

>後町さん

1つ目の質問への答:現状分析が先行しない場合、基本設計は個々の要求に対して「分析的」に提示されるものではないんですよね。それは本でも書いたとおり、「相手の発言にもとづく、相手の恋人の似顔絵描き」のような作業です。「ゴルゴ13のような目でお願いね」と言われて、設計者は彼なりにゴルゴ風の目を描く。それを見た相手は「んー、ちょっと違います。もっと氷のように冷たい目なんです。それと、輪郭はもっとサモハン風です」なんて反応して、いやというほど描き直させられる。最終的に相手に気に入ってもらった「描かれた目」と相手の「目に関する発言」の間にある「因果関係」は相手にしかわかりません。気に入ってもらうまで、山ほど失敗を繰り返さねばなりませんが、そのときに必要なのが「似てないならアカラサマに似てないとわかるような図法」で、DFDやERDやパネルイメージはそのために適しています。高速に、サルのように失敗を繰り返す。これがカギです。

2つ目の質問への答:私が考えている業務知識ライブラリーと簿記の本なんかとの違いは、コンピュータ利用にともなう諸問題が含まれているかどうかです。データベース構造や入出力パネルイメージや、それらを使う仕事の手順に関する記述がともなっているかどうかの違い。教材にそのような要素が含まれていないと、コンピュータが普及している時代に、業務知識は実践的なものとして学びにくい。最初にリリースされるものはけっこう偏向した内容にならざるを得ないと思いますが、フィードバックされているうちに「平均的」なものになっていくと思います。

#長めになるようであれば、コメントではなくトラックバックにしてもらったらうれしいです。

投稿: わたなべ | 2005.05.08 15:17

御回答ありがとうございます。

>描かれた目」と相手の「目に関する発言」の間にある「因果関係」は
>相手にしかわかりません。気に入ってもらうまで、山ほど失敗を繰り
>返さねばなりませんが、

>DFDやERDやパネルイメージはそのために適しています。
>高速に、サルのように失敗を繰り返す。これがカギです。


えーと・・。

その事実は、渡辺さんが経験された範囲での事実ですよね。

自分は要件定義に対するそのような認識に対しては、疑問視
しており、そのアプローチには懐疑的な立場であります。

確かに、仕様とは、完全に凍結できるものではありません。

市場の要請や環境の変化、技術の進歩に伴って、段階的に進化
発展させていくことが、最も理想的であると思われます。

しかし、だからと言って、開き直り、すべてを試行錯誤により
解決していくといった方法では、非常に効率が悪く、さらに、
何時までたっても「プロジェクトを達成できない」という事態
に陥り、当初の計画を大幅に外してしまいかねません。

「できるだけ普遍的な部分を確定する努力」は行うべきです。


仕様変更は、設計者自らが招いているケースが殆どだと思われます。
要求の背景にある因果関係であれば、確定することは可能です。

例えば、ユーザーへのヒアリング(要求分析)にしても、顧客から
要求されたことを実施(モデル化)して、正しいか否かを確認する
だけではなく、自ら要求の「真意」を引き出す努力が必要です。

 ・「なぜそのような要求をするのですか?」
 ・「どこに問題があると思われますか?」
 ・「それは何が原因だと思われますか?」
 ・「実態調査を行うために現物の業務資料を頂けますか?」

要求の背景にある因果関係が把握できていなければ、「目先の現象」
を解決するための手段しか講ずることができないのは当然です。

しかしながら、そのような手前味噌的な対応では、根本的な原因を
解決したわけではないので、次から次へと新しい要求が発せられる
こととなり、何度も仕様変更を余儀なくされることになります。


開発要件を「因果レベル」にて分離・独立させておくことにより、
誤った解決手段の選択に対して、柔軟に対応することができます。

例えば、経営戦略では通常、「長期目標」「中期目標」「短期目標」
を定めて、長期的な展望の下で、臨機応変に対応していきますよね。

開発計画にしても、「概要スケジュール」と「詳細スケジュール」を
設けて、進捗を常時監視することにより、「長期的な遅れ」の兆候を
詳細レベルの早い段階から察知し、対処することが可能となります。

つまりは、何事であっても「ブレークスルー」により実施することが、
手戻りと作業効率のバランスからは、最も効果的であるわけです。

これに対して、顧客の要求(要件ではない)を纏めただけの情報から
理想のシステム像を構築するという行為は、「ブレークスルー」とは
全く逆のアプローチとなり、非常に効率が悪いと推測されます。

「行き先の不明な船」「羅針盤のない船」は、目的地に到達する
ことが困難です。従って、「船の進行方向」(=開発目的・目標)
を初めに定めてやらねば、適切なルートを辿ることができません。


えっと、いろいろ屁理屈を捏ねてしまいましたが・・。

とはいえ、「設計思想」や「システム論」は人それぞれであり、
それゆえ方法論にも様々な個性が表れるのだと思います。

思考特性は人によって異なるので、そうであって良いと思います。
(ただ、オブジェクト指向で設計するアプローチには反対です)


>私が考えている業務知識ライブラリーと簿記の本なんかとの違いは、
>コンピュータ利用にともなう諸問題が含まれているかどうかです。

つまり、これをマトリクス(多次元)として体系付けると・・。

「分野」×「業種」×「問題」×「対処」×「結果」

・・となるわけですね?

「実現方式」まで含めて体系付けるには、時間軸も必要になりますから、

 ×「設計手法」×「利用可能技術」×「技術の進化動向」

という次元も必要になり、膨大な調査と時間が必要になりますよ??
自分としては、それはあまり現実的でないように思います・・。


>#長めになるようであれば、コメントではなくトラックバック

ブログへ書き込みは始めてなもので、失礼いたしました(汗)
次回からは、トラックバックとして投稿させて頂きます。

投稿: 後町(gocho) | 2005.05.09 00:35

それゆけ西表島さん(?)、はじめまして。


おそらく試してもいないであろうことを「理想論」の一言で
片付けられ、「効率優先指向」と曲解されるのは心外です。

「要件定義に必要十分な時間を費やせ」と主張しているのです。

顧客の要求している背景を探り、開発要件を十分に検討したうえで、
プロジェクトの目的・目標を定め、緻密な計画を立てて進めていく
という行為は、そんなに「不自然」なことですか?

ごく「当たり前のこと」ですよね?

ところが、この「当たり前のこと」の重要性が意外と認識されて
おらず、「目先の効率ばかりが優先され」真意の追求を無視して、
いきなり実現方式の設計に入ろうとします。

多くの場合、「抑えるべきポイントを抑えずに作業に挑んでいる」
ことがプロジェクトの失敗の原因ではないかと推測しますが?


>顧客は見たこともないものを「ちゃんと」決めるのは無理

あなたの論は、矛盾しています。

「顧客には明確な要求仕様を確定できるだけの技量がない」
にもかかわらず、「仕様が正しいかどうかの判断はできる」

現時点では「仕様が正しいかどうか」など解るはずもなく、
その「客観的評価基準」として目標を定めるわけです。

それ以前に、「ちゃんと決める」の定義を示して下さい。


>仕様確定のやり取りの中で失敗を繰り返すことにより、
>両者が今回のプロジェクトについて精通し

一般に、顧客から与えられた仕様ほど曖昧なものはありません。

顧客自身が「本当は何をしたいのか解らない」という状況で、
設計者は、顧客が実現したい真の要求を、現状の背景と要望
から導き出し、「代替案(仮説)」として提示するわけです。

あなたの主張するあるべき論は、「真の要求かどうかも定か
ではない」状態でシステム設計を開始し、「仕様が正しいか
否かの判断すら付かない」顧客に確認をとるわけですね?

あなたの言う「失敗」とは、本来必要なはずのプロセスを
省いた故の結果(単なる手戻り)ではないのですか?


それから「作ってみないと解らない」箇所があるのなら、
「その部分だけに限定して」作ってみればよいわけです。

トライアル(プロトタイピング)が必要な場合は、十分にその
目的を検討した上で実施する必要がありますが、多くの場合は
「紙芝居」で十分であり、また、どの機能について検証が必要
であるかは、「何を作るのか」が解らなければ実施できません。


>XPを始めアジャイル開発も、無駄と失敗を積み上げながら
>進める開発モデル

海外の偉い方の提唱する、最近流行の「バカ理論」を鵜呑み
にするのではなく、御自身の経験と自ら導き出した結論を
大切にすることをお勧めします。

投稿: 後町(gocho) | 2005.05.10 06:47

ふー・・。

渡辺さんとは、もっとCASE論について語り合いた
かったのですが、ここでは、あまり歓迎されていない
みたいなので、出直して来ようとおもいます・・。

議論にお付き合い下さり、ありがとう御座いました。
またいつか宜しくお願い致します。

投稿: 後町(gocho) | 2005.05.10 12:34

渡辺さん、はじめまして。

非常に興味深く読ませていただきました。

自分はパッケージ物を中心に仕事していますが、パッケージ・インプリの仕事では、パッケージの世界を中心にしてTo-BeをAs-Isの前に構築することが、スクラッチと比べると自然にできると思っています。というか、実際的にはパッケージのデータ処理を捻じ曲げることは不可能なので、不可避的にそのような手順になってしまいます。Oracleの提唱するAIMでも、同様の手順を推奨していると理解しています。

今度時間のあるときに、他のページも見せていただきます。どうもありがとうございました。
今後も訪問させていただきますので、よろしくお願いいたします。

投稿: botts | 2005.05.26 01:47

大変興味深い議論だと思いました。システム開発/ソフトウェア開発は顧客の問題解決の手段であるという前提に立てば、結果を出すためには取りうる手段の内から最善のモノを選択できればよいのかなと考えます。ただし、顧客の問題意識や責任感の度合いによって、良いシステム/ソフトウェアが提供できたかどうかが別れると思います。
ここでは、As-is かTo-beのどちらが先行するかという話しですが、基本はTo-beでしょうね。なんと言っても、顧客がどうしたいのか?どうなったら良いのかということについて合意できなければ、単に予算を消化しただけでPJは終わってしまうでしょう。
To-beの内容がヒューリスティックであっても、少しリスキーですが、現状にとらわれて縛られるより良いと思います。
最後に、いまさら、DOA,SA/SD,他にAgileなど、、、これらの手法がPJの成功を約束すると勘違いなさらない方が良いと思います。非現実的な手段は適用できないのは当たり前ですが、PJを成功させているのは方法論のおかげでも何でもないです。最新の開発手法の方が無難でありますが、適用して手法の落とし穴にはまらないように工夫するのは結局自分たちなのですからね。
おまけ、、、DOAの佐藤正美さんの本を眺めてみましたが、データに着目することで開発を上手く進められるのは業務系の安定したデータを扱う部分に限られます。動的にデータ構造が変化するような問題については、まず難しいでしょう。RDBMSの限界です。ここで、気が付くことは、この方法は上手く行くという話しには、何らかの強い前提条件が隠れていると言うことです。そこを見極めないで自分たちの開発に適用すると、ヤケドをしてしまうと言うことなんですね。

投稿: takojyujyu | 2005.06.08 22:11

ご無沙汰してます。

自分は将来、ツールを売って商売していこう!と張り切っていたの
ですが、どうも上手く行かず、大人しく就職することにしました。

自分には、ビジネスの才能がないということが解り、へこみ気味です。

(根っからの技術屋なんだろうなきっと・・)


本題に入ります。

>結果を出すためには取りうる手段の内から最善のモノを選択
>できればよいのかなと考えます。

takojyujyuさんの御意見に同意です。

むしろ、単純な二元論に当てはめて論じること自体が不毛だと思います。


>As-is かTo-beのどちらが先行するかという話しですが、基本はTo-be
>でしょうね。なんと言っても、顧客がどうしたいのか?どうなったら
>良いのかということについて合意できなければ、

「As-is かTo-be」論に対する自分なりの見解を示します。

当たり前のことですが、まずは顧客の「要望」が先に来ます。
設計者は、その要望を一つの情報として仕様を策定します。

現状分析が必要な理由としては、1つは上記に述べたような、
顧客の要求している背景(真意)を探るためのプロセスが
必要であることと、それから、システム化への移行を支障
なく行えるように「BPR」を伴うことがあるからです。

もともとの業務プロセス自体が不明確であれば、たとえそれを
コンピュータシステムに置き換えたとしても、後の業務が正常に
運用できるという保証はありません。従って、まずは業務レベル
での整合性及び妥当性・効率性を検討する必要があります。

また、システム化後の業務プロセスと現行の業務プロセスが
異なるような場合、現行の企業情報がそのままデータベース
に落とせるとは限らなくなります。例えば、在庫業務の廃止、
インターネットによる新たな販売経路拡大といった場合です。

よって、まずは業務プロセスの改善、及び標準化を実施して、
改善後の業務活動で必要な情報を記録する「仮想帳票」を
設けて業務全体の整合性を検討する過程が必要になります。


結論を言えば、単純な「As-is/To-be論」でシステム設計を
語ることは不可能であり、現実に則した結論には至らない。

よって、議論の対象枠を広げるか、限定論に妥協するかです。

(無愛想&つまらない結論で申し訳ありません・・汗)


>データに着目することで開発を上手く進められるのは業務系の
>安定したデータを扱う部分に限られます。動的にデータ構造が変化
>るような問題については、まず難しいでしょう。RDBMSの限界です。

業務系のデータ設計に、リレーショナル理論が用いられるのは、
複雑な情報間の関連を持つ企業活動情報との親和性に優れていて、
「情報システムが管理すべきデータ」を表現し易いからです。

科学技術計算の分野などで、大量の蓄積データを一括してバッチ
処理する場合などでは、相変わらず階層型DBMSが適切です。

えっと、ちょっと気になったのですが・・。

不勉強で申し訳ないのですが、「データ構造を動的に変化させる」
ことが必要なケースとは、どのようなシステムの場合でしょうか?

この場合の実現方式としては、「メタデータを先行させ、それを
ランタイムに解析し、定義情報に基づいて本データを処理する」
といった仕組みが作りこまれている必要がありますよね・・。

自分が研究開発中のツール「ProtoCASE」ではこれをやってますが、
実社会におけるシステムでは、かなり珍しいケースかと思います。

単純に「場合分け」が必要なだけであれば、場合別のデータ構造
を設計しておけば良いだけです。つまり、第四正規化定理に従い、
同時刻に発生するデータであっても、場合によって異なるデータ
が発生するのであれば、それを「継承関係」として、別の実体に
格納しておくことで対処することができます。

つまり「場合すら把握できない」ケースでのみ、このような方式が
必要になると思われますが・・。


>何らかの強い前提条件が隠れていると言うことです。そこを見極めないで
>自分たちの開発に適用すると、ヤケドをしてしまう

大切なのは「テクノロジーに対する正当なる理解と評価」ですよね。

技術や手法の長所・短所を理解して、相応しいケースに、相応しい形
で適用するという、割り切った考え方が設計者には求められます。

ましてや、派閥を作って争う必要などはないと思います。

投稿: 後町(gocho) | 2005.06.13 17:18

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/87674/4033469

この記事へのトラックバック一覧です: 「As-is先行」か「To-be先行」か:

» 建築家 [『建築家』 建築辞典]
建築家建築家(けんちくか)とは自らの美学的見地で形あるものを設計する人のことである。(参照: 建築)欧米では、建築家は医師・弁護士と共にプロフェッションとして扱われる。建築家が生前に受賞できる最も著名な賞はプリツカー賞 (The Pritzker Architecture Prize)... [続きを読む]

受信: 2005.05.09 17:51

» いい無駄わるい無駄、いい失敗わるい失敗 [それゆけ西表島]
ソフトウェア開発、特に受託して開発するような場合は、無駄の連続である。無駄を排除して効率よくしようとすると、なぜか無駄が多くなるという矛盾がある。なぜだろうか。 机上でソフトウェア開発を考える人(要するにあまり実経験のない人)は、顧客のニーズを最初に「ちゃんと」引き出して、「ちゃんと」確定できれば、作る際に無駄はないし、非常に効率的だと考えるのである。まさに理想論なのだが、根本的な問題として、顧客は見た... [続きを読む]

受信: 2005.05.10 01:07

« 「スクラッチ開発」という名のゴムボート | トップページ | 会計システムにオトシマエをつける »