■ プログラマは、単なる「コーダ （coder）」なのか。

　日々、実際のシステム作りに専従していると、（１日は、２４時間しかないので、） どうしても、作業を離れて、「理論」を落ち着いて学習することが、むずかしい。

　プロジェクトが、当初の計画どおりに進んでいれば良いのだが、思わぬトラブルが--それが、コンピュータ・システム上の技術的なトラブルであっても、プロジェクト・チームのなかの人間関係的なトラブルであっても--起こったりすれば、対応に追われて、担当している仕事のほかに、精神を集中することなどは、むずかしい。

　しかも、２０歳代・３０歳代は、技術を習得しながら、それを直ぐに使わなければならないので、習得した技術を、じっくりと検討する余裕などないのが現実である。「言われたことを、そのとおりに、実行する （習得した技術を、取り急ぎ、使用する）」状態にならざるを得ないというのが、きびしい・悲しい現実である。

　まして、プログラムの仕様を、システム・エンジニア （ＳＥ） が作成して、プログラマは、それをコンピュータ言語に翻訳するのみという体制では、プログラマは、いよいよ、単なるコーダ （coder、情報を記号化する人） になってしまう。
　そういう体制が導入された理由は、おそらく、事業のなかからシステム化の対象を調べる作業では、事業知識を習得していることのほうがコンピュータ技術を駆使できること比べて、大切である、という判断をしていて、事業知識を習得していると思われているＳＥのほうが--実際は、そうではないＳＥが多いのだが（苦笑）--、プログラマに比べて、事業を情報化する力がある、と思われているのであろう。
　しかし、プログラマには、事業知識が、ほんとうにないのであろうか （--小生は、そうは思わない）。

　
■ ＲＡＤでは、プログラマは、事業知識を習得していなければならない。

　ＲＡＤ （あるいは、ＲＵＰや agile） をやるなら、プログラマは、当然ながら、事業知識を習得していなければならない。プロトタイプ技法をフロントエンドにして、システム作りの納期を短縮するのなら、当然ながら、プロトタイプ作成の直後には、プロトタイプを読み切って、事業の中身を理解していなければならないし、「整合的な」データベース構造が用意されていなければならない。もし、そういうことができないのであれば、ＲＡＤは、仕様変更の無限後退に陥ってしまう。
　ＲＡＤを実現できるプログラマは、（事業知識とコンピュータ技術のいずれをも習得した） 第一級の プログラマであり、人数が少ないのは事実である。

　ＲＡＤでは、プロトタイプを作成しながら、設計図 （事業の記述とデータ構造） も作成しなければならない。したがって、プログラマ （ＳＷＡＴチーム） は、事業過程 （とくに、財務管理、生産管理と販売管理） に関する「通論」の知識を習得していなければならない。なぜなら、プログラマは、用意された設計図を観て、事業を読み切って、情報 （プロトタイプ） の用途を理解して、「直ちに」、プログラムを作成しなければならないから。

　
■ ＲＡＤでは、プロトタイプ技法と「整合的なモデル」が両輪となる。

　設計図 （事業の記述およびデータ構造） を作成する勝負点は、（ＲＡＤは短納期を旨とするので、） 短期間のうちに作成されなければならないという点と、作成するエンジニアの価値観が記述を左右してはいけないという点である。とすれば、設計図を作成する技法は、単なる作図技法では役に立たない--ダイアグラムの記述方法が整っているのみでは役に立たない。事象を抽象化するための「ルール」および構造を作るための「ルール」が提示されていなければならない。

　1970年代から今に至るまで、モデルが、数々、提示されてきたが、実地のシステム作りでは、ほとんど、役に立っていない。その理由は、それらのモデルは、モデルといいながら、生成規則を提示しないで、単なる作図作法に終わってしまっているから。
　データ設計に関して、小生がモデルとして認める唯一の技法が、コッド関係モデルである。コッド関係モデルは、整合的な理論と単純な技術を提示している。しかし、コッド関係モデルは、データ設計用のモデルであって、意味論が弱い--ただし、この非難は的はずれであって、コッド関係モデルは、データの独自性 （data-independence） を着目した論理設計・物理設計のモデルであって、意味データモデルではない。

　さて、ＳＤＬＣのすべての工程のなかで、２年を費やして実現してきたことを、ＲＡＤとして、わずか、６ヶ月以内のうちに実現しなければならないのであれば、しかも、システム作りのなかで用意しなければならないドキュメントの品質を落とさないのであれば--「意味」を記述する「形式」を、確実に整えていなければならないのであれば--、論理設計が概念設計を吸収するしかない。

　
■ モデルはルール・ベースでなければならない（生成規則を提示しなければならない）。

　すなわち、ＲＡＤでは、プロトタイプを作成した直後に、論理設計をやって、論理設計では、「形式 （データ構造）」が「意味 （事業の現状）」を記述する「ルール・ベース」を前提にしたモデルを使い、モデルの「ルール （生成規則）」に従えば、だれが作成しても、ほぼ、同じデータ構造になって、データ構造が、一人のＳＥの価値観のために揺らがないようにしなければならない。

　経営環境の変化がはげしいので、システムを、昔のように、２年も費やして作る時代ではないし、環境変化に対応して、つねに、システムを、こまめに、メンテナンスしなければならないので、ＲＡＤ （ＲＵＰ、agile） をやるのなら、上述したような「整合的な、ルール・ベースの」モデルを使わなければ、「速く作って、ゆっくりと後悔する」憂き目にあう。

　そして、「ルール・ベース」のモデルを使えば、プログラマは、「通論」の知識さえ習得しておれば、「通論」を標準形にして、（プロトタイプおよび） データ構造のなかに記述された「（事業の） 意味」を理解することができる。とすれば、「通論」の知識を習得することは、そうそう、年数を費やす学習ではないし、仕事のなかで、「通論」の知識が、直接に役立つのであれば、プログラマが、事業知識を習得することは苦痛ではないはずである。
　事業の知識が、プログラマには、直接には関係がない、という先入観は、（短い納期を実現しなければならない現代では、） 打破されなければならない。

　
　（2004年8月8日）