2004年 2月 1日 作成 データ 設計法 (業務分析と概念設計) >> 目次 (テーマ ごと)
2008年 3月 1日 補遺  


 
 システム 作りは、以下の手順を踏む、と一般的に言われている。

  (1) 分析工程 (analysis)
  (2) 設計工程 (design)
  (3) 製造工程 (production)
  (4) 保守工程 (maintenance)

 以上の (一連の) 手順を総括して、SDLC (System Development Life Cycle) とよぶことがある。
 SDLC のそれぞれの工程を 「凍結」 して──前の工程が完了しなければ、次の工程に進むことができない、というふうにみなして [ ただし、純粋な シーケンス (sequential) を前提にしているのではなくて、前工程の終わりのほうと次のはじめのほうが concurrent に進むこともあるが、]──順次前進するので、「waterfall モデル」 ともいうことがある。

 ちなみに、システム を作るための プロセス・モデル は、waterfall モデル のみではない。
 ほかにも、以下の モデル がある(* 1)

  (1) 成長 モデル (evolutional model)
  (2) 螺旋 モデル (spiral model)
  (3) 花弁 モデル (flower model)
  (4) 契約 モデル (contract model)
  (5) パフォーマンス・モデル (performance model)

 成長 モデルは、ソフトウェア の性質を以下の 2つの類型として分類する。

  (1) P 型
  (2) E 型

 P 型とは、仕様が当初から固まっていて変更がない性質をいい、E 型とは、仕様が のちになって 変更される性質をいう。「仕様を凍結する」waterfall モデルは、P 型向きであるが、E 型向きではない。E 型 ソフトウェア の作成は、仕様を凍結しないで、変更を是認して「工程を繰り返す」 という点に特徴がある。つまり、フィードバック (feedback) を前提にした やりかた である。したがって、プロジェクト の スケジュール が組みにくい。
 現実の システム 作りでは、製造工程のなかで、仕様変更が多く起こっているにもかかわらず、waterfall モデル が使われている理由は、おそらく、プロジェクト の スケジュール を作成しやすいからであろう──とりわけ、システム 作りを請け負う ソフトウェアハウス にとって、スケジュール の作成および資源 (人員など) の割り当ては最大の配慮事項なので、waterfall モデル を使っている、というのが現状だと思う。

 螺旋 モデル は、waterfall モデル と成長 モデル を融合した やりかた である。
 [ 螺旋モデル = waterfall モデル + 成長 モデル ]。

 花弁 モデル は、ソフトウェア・データベース を構築する点に特徴がある。ソフトウェア・データベース のなかに 「情報 (SDLC の アウトプット)」 を集積して、その データベース を中核に置いて情報を参照・更新しながら、(SDLC の) それぞれの工程を任意に繰り返す。つまり、成長 モデル や螺旋 モデル を導入するための適用 モデル である。
 データベース を中核にして、それぞれの工程が、(データベース のまわりに) 1つずつの花びらのように輪状になって付着しているので、花弁 モデル とよばれている。

 契約 モデル は、発注者と受注者との間で合意される契約を基礎として、システム 作りの過程を管理する やりかた である。すなわち、発注者は、仕様・技術情報 (IT ミックス)・期限を示して、受注者は、成果物を納入する。

 パフォーマンス・モデル の 「パフォーマンス」 というのは、「上演」 という意味である。つまり、パフォーマンス・モデル は、演劇のやりかた を適用している。「練習・実演・反省」 という過程が繰り返される、という考えかたである。OJT (on the job training) とか 「仕事の引継ぎ」 などの技術移転を配慮した考えかたである。

 
 さて、現実の システム 作りでは、上述した モデル をいくつか混成している。たとえば、ソフトウェアハウス であれば、契約 モデル と waterfall モデル と パフォーマンス・モデル を混成している。なぜなら、契約 (請け負い)と プロジェクト 管理と技術移転は、ソフトウェアハウス にとって、仕事が成立するための最大の考慮点だから。
 ただ、悲しい現実として、契約 モデル では、アウトソーシング と称して 「丸投げ」 状態になっていて、プロジェクト 管理と称して、「多量の (too much)」 ドキュメント を作成して、パフォーマンス・モデル では、OJT と称して 「(先輩の) 経験談」 が罷り通っている。「モデル」 とは言うけれど、モデル 作成 (modeling) が技術になっていない。モデル を作るために、エンジニア の裁量が多すぎる。

 
 データベース 設計には、概念設計・論理設計・物理設計がある。
 物理設計が製造工程のなかで扱われることに対して、小生は異論がない。ただ、論点になるのは、概念設計と論理設計が、どの工程で扱われるのか、という点である。ER 手法や意味論 データベース が、「現実の事態」 を対象とした モデル (requirement model) 作成法なので、概念設計は analysis のなかで扱われ、論理設計は design のなかで扱われる、とするのが おおかたの 考えかたであろう。
 analysis 段階では、以下の やりかた が、提示されてきた。

  (1) トップダウン 手法(* 2)
      事業モデル (Enterprise Business Model)

  (2) ボトムアップ 手法(* 3)
      DFD (Yourdon 法、DeMarco 法、Gane/Sarson 法など)
      decomposition (Jackson 法、Warnier/Orr 法など)

 これらの手法が特徴とする点は、「構造化概念 (structured analysis)」 である。しかも、「function」 を──「関数」 という意味ではなくて、「プロセス の作用」 という意味で使っているが──記述する やりかた である。そして、プロセス の構造化が、事業のやりかた を記述するためには、やりやすい、と思い込まれた (oversimplification) のであろう。

 1つの構造として、1つの階のなかで (leveling) 扱われる モノ は、同じ範疇の モノ (整合的) でなければならない。
 1つの アプリケーション を対象にして、1つの構造の階を整合的に作成するということが、どれほど、むずかしいことか、という点を、DFD を信奉する人たちは知らないのではないか──実際、小生は、過去 20年間、「まともに作成された」 DFD を、一度も、目にしたことがない。
 上述した構造化手法は、いずれも、1960年代および 1970年代に提示された手法である。その時代では、コンピュータ を、事業のなかで、いかに使うか、ということが論点になっていた。それらの手法が、analysis を大切にして、エンジニア の頭のなかで考えられている構造を 「可視化」 した点──だれでもが、1つの計画資料を共有する、ということ──は、高く評価できる。しかし、それらの手法は、「設計の作法 (作図記法)」 であって、「設計の技術 (抽象化手順)」 ではない。抽象化の手順自体を──つまり、モノ [ プロセス、funciton ] を認知する判断規準と、(モノ と モノ との間に成立する) 関係 [ 構造化、階層化 ] を生成する判断規準を──それらの手法は提示していない。

 1970年代には、ER 手法 (チェン氏) と セット・アット・ア・タイム 法 (コッド 氏) が提示された。ER 手法は概念設計のなかで扱われ、セット・アット・ア・タイム 法は データベース 設計論として扱われている。いずれの手法も、「モノ」 と 「関係」 を前提にした考えかたであるが、ER 手法は、モノ を 「entity (主体集合)」 として考え、関係を 「relationship (関連)」 として考える点が特徴であり、セット・アット・ア・タイム 法は、モノ を (atomic な) 「属性集合」 として考え、関係を 「relation (関数)」 として考える点が特徴である。ER 手法では、主体集合を生成する判断規準として identifier が使われ、セット・アット・ア・タイム 法では、tuple を形成する判断規準として primary-key が使われる。いずれも、モノ を認知する判断規準を提示している。ただ、論点になるのは、identifier あるいは primary-key として、どのような データ を使うか、という点である。

 コッド 正規形では、tuple の整合性を検証する規準として、「関数的依存関係 (functional dependency)」 が使われる。チェン ER では、しかじかの性質 (attribute) が、かくかくの主体に帰属するかどうか、という点を判断する規準はない。数理 モデル (コッド 正規形) は、認知基準も検証規準も提示できたが、関数を使ったがゆえに、(現実の データ を対象にした際に生じる) 「半順序」 が問題点になった。いっぽう、意味論 モデル (チェン ER) は、現実の事態を記述する際に、認知の規準を導入したが、(関連を記述するためには、現実の事態を対象としているので、) 関連を認知する規準を提示できなかった。

 チェン ER が、「現実の事態を記述する」 意味論の技法として、概念設計のなかで使われるとすれば、上述した構造化手法に対して、アンチ・テーゼ となる。すなわち、(システム 作りのなかで、データベース 作りを主体にして考えるなら) チェン ER を作図してから (analysis 段階)、コッド 正規形 (design 段階) を作成する、という手順になる。ちなみに、逆の手順 (コッド 正規形 → チェン ER) は成立しない。

 コッド 氏は、意味論を毛嫌いしていたそうである (小生も、意味論を毛嫌いしている)。数理 モデル を信奉する コッド 氏が、意味論を毛嫌いした理由は、おそらく、「(意味論では) 構造を検証する規準がない」 という点を嫌がったのではないでしょうか。およそ、モデル というなら、以下の 2点を実現していなければならない。

  (1) 無矛盾性 (構造のなかで、A ∧ ¬A が起こらない、ということ)
  (2) 完全性 (構造は、いくつかの選ばれた前提から導出される、ということ)

 チェン ER 手法が 「作図の作法」 であって、「作図の技術」 ではない、と非難される理由も──少なくとも、小生は、そう非難する一人であるが──、モデル としての 「完全性」 がないからである。
 完全性を証明するには、無矛盾ならば モデル が存在することを証明すればよい。モデル とは、Σ を T の文の集合としたら、T が Σ のなかの任意の文 φ に関して、φ は、T のなかで、真・偽のいかなる可能性に対しても、恒真 (トートロジー) であるような解釈が成立すれば、T は Σ の モデル である、という。その意味で、セット・アット・ア・タイム 法は モデル である。

 以上をまとめれば、analysis とよばれている やりかた が、いずれも、「技術」 ではない、ということである。したがって、これらを ダイアグラム の記述作法とよぶことは良いが、モデル とよぶことには、小生は合点がいかない。
 もし、それらの手法が、ダイアグラム の記述作法だとすれば、事業をやっている当人が作成すれば、(事業を知らない SE が作図することに比べれば) マシ な アウトプット が出るでしょうね。もし、契約 モデル を前提にしているというなら、エンドユーザ が仕様を ダイアグラム 形式で提示するのは当然ではないか。でも、エンドユーザ はやらない。
 では、どうして、エンドユーザ が ダイアグラム を作成しないのか。おそらく、そんな 「お絵描き」 を作成するために、仕事を離れて、労力を 「浪費」 するのが嫌だから、でしょうね。なぜなら、エンドユーザ にとっては、仕事を効果的・効率的に進めるための 「情報」(* 4)があれば良いのであって、事業の構造など関心がないから。

 もし、現実の事態 (事業) を対象にしないで、「情報」 を対象にしたら、仕事自体の有用性を判断できない、というのであれば、「情報」 を使う目的を調べれば、(仕事のなかで使う情報と事業の目的とを対比すれば) 仕事の有用性を判断できる、と言っておきましょう。

 なお、小生は、job-analysis とか conceptual design に対して関心がない、という点を正直に述べておきます。

 
[ 注釈 ]

(* 1)
  これらの モデル の一覧は、以下の事典を参考にして、まとめた。
  「コンピュータ ソフトウエア 事典」、廣瀬 健・高橋延匡・土居範久 編、丸善、平成2年

  それぞれの モデル の詳細については、以下の文献を参照されたい。
  - Lehman, M.M. and L.A. Belady, "Program Evolution", Academic Press, 1985.
  - Boehm, B.W., "A Spiral Model of Software Development and Enhancement", IEEE Comuter, 1986.
  - Dawson, M., "ISTAR--An Integrated Project Support Environment", ACM, 1987.
  - Marks, P., "What is Leonard?", Technical Report 141-86, MCC, 1986.

(* 2)
 ここでいう トップダウン 手法というのは、構造を作成する際、トップダウン のやりかたで作成する、という意味ではない。というのは、DFD も decomposition も トップダウン 手法で作成することができるから。ここでいう トップダウン という意味は、意思決定の過程を、「戦略 (strategy)・戦術 (tactics)・業務 (operational)」 という 3 階層として考えれば、CSF (Critical Success Factor) を考慮して、戦略の観点から作成する、という意味である。いっぽう、DFD も decomposition も、operational な領域を対象にしている。
 ちなみに、ここでいう ビジネスモデル というのは、Enterprise Business Model であって、1990年代の半ば頃から注目されている ビジネス・メソッド (ビジネスモデル と一般にはよばれている) とは違う。

(* 3)
 以下の文献を参照されたい。
  - Yourdon, E., and L.L. Constantine, "Structured Design", Yourdon Press, 1975.
  - Jackson, M.A., "Principles of Program Design", Academic Press, 1975.
  - DeMarco, T., "Structured Analysis and System Specification", Yourdon Press, 1979.
  - Gane, C., and Sarson, T., "Structured System Analysis", Prentice-Hall, 1979.

 ちなみに、小生は、ビジネスモデル 手法として、Holland 式を学習して、DFD では、Gane/Sarson 法を、decomposition では、Warinier/Orr を徹底的に教育された。それぞれの手法の文献も、丁寧に読んだ。したがって、それらの手法について、理論も技術も習得している。
 しかし、それらの手法を、いまでは、信用していない。
 なお、オブジェクト 指向を前提にした UML の記法については、ウェッブ 上に、数多くの情報が提示されているので、参照されたい。

(* 4)
 ここでいう 「情報」 とは、フォーマル な コンピュータ・システム から生成される アウトプット のことではない。仕事のなかで使っている 「情報」 という意味であり、コンピュータ を使って自動化されている 「情報」 もあれば、インフォーマル な 「情報」 もある。原帳票や、コンピュータ から生成される レポート や、ファイル・レイアウト や、あるいは、手書きの報告書も対象としている。「情報」 を対象にすれば、対象となる数が多すぎて、作業をするのがむずかしい、という非難を聞いたことがあるが、なにをかいわんや。100万 ステップ くらいの システム を対象としても、画面数は、せいぜい、300 くらいだし、レポート 数も、100 から 200 くらいである。それ以上の数になることは、まず、ない。なぜなら、「情報過多」 になれば、情報を管理できなくなって、事業が混乱するから。少なくとも、現実の事態などという曖昧な対象を扱うことに比べたら、「情報」 を対象にするほうが、事業を理解しやすい。



[ 補遺 ] (2008年 3月 1日)

 前回述べたように、私 (佐藤正美) の立場は 「論理的意味論 (logical semantics)」 です。すなわち、私は、数学 (あるいは、ロジック) の観点に立って、「モデル」 を考えています。したがって、以下の 2点を提示しない やりかた を 私は 「モデル」 として認めない。

 (1) 構文論 (生成規則)
 (2) 意味論 (指示規則)

 ただし、私は、「概念設計」 の やりかた を知らない人たちが、私の考えかたに同調することを良しとしないので、「概念設計」 の やりかた には、どういう やりかた があるのかを一覧表示して、かつ、それぞれの やりかた を説明した原典を記載しました。ちなみに、私は、それらの原典の ほとんど を読んでいますし、本 エッセー のなかで記したように、それらの やりかた のいくつかを、かつて、実地に使ってきました。そして、それらの やりかた を捨てたという次第です。
 本 エッセー を読まれたひとは、本 エッセー のなかで記載した 原典を読んで、そして、それらの やりかた を、できれば、実地に使ってみて、ほかの やりかた (たとえば、コッド 関係 モデル──ただし、かならず、原典を読んで下さい──) も学ばれて、さらに、数学の 「モデル」 も学習して、そうしたあとでも、概念設計の やりかた のほうが良いと判断なさるのであれば、概念設計の やりかた を使えば良いでしょう。ただし、以下の点を かならず 示して下さい。

   「あなたが作成した 『構成』 は、『無矛盾で、完全である』」

 本 エッセー のなかで示した SDLC を前提にするならば──しかも、「分析 → 設計 → 製造」 という waterfall を前提にするならば──、「製造」 が 「真」 であるためには、「設計」 が 「真」 でなければならないし、「設計」 が 「真」 であるためには、その前提となる 「分析」 が 「真」 でなければならない、というふうに要請するのは当然のことでしょう。なぜなら、われわれは、「製造」 では、コンピュータ のなかに、「現実的事態を モデル として記述した 『構成』」 を実装するのだから、その 「構成」 のなかに、矛盾をふくんでいることは回避されなければならないから。

 「モデル」 の根底にある哲学まで遡って考えてみれば、「構成 (モノ と関係)」 の哲学として、関係主義 (関係が一次的、モノ は関係のなかの変数) と実体主義 (モノ が一次的、関係は 二次的) がありますが、私は、このふたつのあいだで 「揺れている」 ようです。さきほど、「真」 という ことば を使いましたが、「モデル」 では、規則 (生成規則、指示規則) に対応して、以下の 2つの 「真」 概念があります。

  (1) 「導出的な L-真」 (生成規則のなかで争点になる 「真」)
  (2) 「事実的な F-真」 (指示規則のなかで争点になる 「真」)

 (2) の 「真」 は、経験論的な言語では──すなわち、現実的事態を記述する モデル では──、モデル のなかの記号が、かならず、現実的事態 (モノ) を指示することを要請した 「真理条件」 です。そして、データ 設計上、争点になるのは、「モノ」 として認知される対象はなにか、という点です。少なくとも、事業過程・管理過程を モデル 化するのであれば、それらの 「モノ」 は、ひとりの システム・エンジニア の視点で判断されるはずがない。この意味において、私は、システム・エンジニア が オノマシオロジー の やりかた を 「いまでも」 採用していることに対して疑問を抱いています。オノマシオロジー の やりかた は、1970年代に、コンピュータ が、いまだ、事業過程・管理過程のなかで使われていなかったときには 「ききめ」 があったでしょう──というのは、事業過程・管理過程の どの領域に対して、コンピュータ を使えば役立つかを調べなければならなかったので (ただし、それでも、私は、そういう調査では、「作業日報」 があれば充分だと思っていますが)。

 本 エッセー のなかで述べましたが、私は、いわゆる 「概念設計」 の やりかた を認めていない。そういう言いかたが単なる独断とみなされる危険性があるのなら、以下のように言い換えても良いでしょう。すなわち、概念設計で示された 「構成」 が現実的事態を 「正しく」 記述しているという証明をしてくれないかぎり、私は概念設計を信用しない、と。





  << もどる ベーシックス すすむ >>
  データベースの基礎知識