| ▲ このウインドウを閉じる |
| All meats pleases not all mouths. |
かって、オブジェクト指向的な若いＳＥが、「認知番号（コード体系）と日付」しか論点にしていないＴ字形ＥＲ手法に対して、以下のように、「きつい」コメントをしてくれました。 「こんなのが『方法論』？」 ははは、僕は、なんとも、返事できなかった。 Ｔ字形ＥＲ手法は、ちょっと、「あぶない」技術です。「技術として」、できうるかぎり、単純にしましたから、実地に使う際、逆に、Ｔ字形ＥＲ手法の「考えかた」を理解していなければ、踏み外してしまいます。 概念設計の技法として、Ｔ字形ＥＲ手法を使うなら、使いにくい技術です。概念設計技法として、もっと、ほかに良い技法が、いくつも、あります。そして、論理設計の技法として、Ｔ字形ＥＲ手法を使うなら、使いにくい技術です。論理設計技法として、もっと、ほかに良い技法が、いくつも、あります。 Ｔ字形ＥＲ手法を、「モデル」と云うことに対して、正直に言えば、僕は、かなりの抵抗感を覚えます。というのは、ほかの概念設計技法や、ほかの論理設計技法と比べて、それぞれ、概念設計の段階とか、論理設計の段階のなかで、比較すれば、Ｔ字形ＥＲ手法には、なんのメリットもない--損な比較になりますから。 Ｔ字形ＥＲ手法は、「システムを作り直したい」と思っているユーザが、「目標に向かって燃えているあいだに」、概念設計と論理設計を、一気に（同時に）やって、「ユーザが、ものごとを、どのように考えているか」という点を、「情報（画面など）」を基礎資料にして、「形式（形式知）」として、まず、整えてしまえ、というやりかたです。 そして、当初、作成したＴ字形ＥＲ図を、原案にして、添削しながら、ユーザの「のぼせ」を、「じっくりと」、冷ます技術です。そして、ユーザに対して、（システムの作り直しを考えているなら、）システムを、「もっと、ちゃんと考えなさい」と迫る技術です。だから、Ｔ字形ＥＲ図は、いったん、作成して、それから、添削することが、勝負点なのです。 というのは、技術が、いかなる思想を根底にしていようが、技術として使うことができなければならないから。僕から、Ｔ字形ＥＲ手法を、直接に指導されなければ使うことができない、というのでは技術ではないから。
ただ、実地のプロジェクトというのは、さまざまな人たちが参画して、生々しい人間関係も出てきますし、ユーザが理解している以上のことを、システムとして、実現することは、まず、むずかしい。
或る人 曰く、
そういう やりかた が良いことなのかどうか、という点を僕は判断できないのですが、モデルとしての理論的な整合性を崩さないようにしながら、ユーザが、最高に満足する点を探ります（こういう仕事をしていると、そういうことを感知するのが、こまやかになって、人間嫌い [ 自己嫌悪 ] になります--苦笑）。
ただし、こういう点（ユーザとの対応）は、ほかの人たちに伝授できない。でも、「技術」は伝授できる。だから、僕は、公にする書物のなかでは、「技術しか対象にしない」ということを指針にしています。
もし、モデルが「絶対的な」モノであるなら、モデルを使うユーザは--モデルを使う「すべて」のユーザは、モデルを、そのまま使えば、--、成功してきたはずですから。でも、それは「夢」物語でしょう。なぜなら、（モデルに対する）ユーザの理解度や、対象となっている事業の戦略的配慮や、プロジェクトの管理や、プログラムを作るソフトウェアハウスの人たちの協力度など、多くのパラメータがあるから。
ただし、モデルは、モデルとして、整合的でなければ、現実に対応するための「技術」にはなりえないでしょう。でも、モデルは、現実を、或る観点から記述することしかできない。
|
| ▼ このウインドウを閉じる |