方法論を用いたソフトウェアを提供できるよう日々鍛錬しております。ハードウェア、ソフトウェアの次の概念がアトムズウェアである。コードで、8桁または11桁のアルファベットと数字で構成される。Technology」の略。「情報技術」を意味する概念。戦略情報システムを構築する手段。近年、この言葉の意味は広く、情報通信分野の基礎技術から応用技術、敷いては、技術を利用することにまで及び、コンピューターやインターネットを中心とするネットワークを活用する会社の総称をIT業界と呼んだりしていて、曖昧なものを表す。アルゴリズムアルゴリズムとはアルゴリズム(algorithm)とは、数学、コンピューティング、言語学、あるいは関連する分野において、問題を解くための手順を定式化したもの。エンティティエンティティとは実態ともいう。一単位として扱われるデータのまとまり。DOA(データ指向)では、エンティティと2種類のリレーションシップを使い、データモデル図(ER図)を作成する。コンピュータのシステムでは、要件定義で具体的に人間が認識する登場人物(登場物)のことをオブジェクトという。オブジェクトには下記の4つの特性がある。1.リレーション(関係):オブジェクトは単独で存在することはない。ほかのオブジェクトと関係を持つ。2.属性:オブジェクトは、固有の姿・形・性質などを持つ。これらのうち、文字列とか数値で表されるものは、新たなオブジェクトを立てるのではなく、属性として扱う。3.操作:各オブジェクトは固有の(仕事)振る舞いを持つ。これを操作と呼び、動詞で表現する。4.アイデンティティ(識別):各オブジェクトは、ほかのオブジェクトから自らを識別できるアイデンティティを持つ。オブジェクトを抽象化(共通化/分類化)したものをクラスという。オブジェクト指向は、対象であるみんなに仕事をやってもらう指向である。反対にサブジェクト指向は、主体が仕事を自分でやる指向である。サブジェクトがオブジェクトに仕事の依頼を行って初めて、システムが成り立つ。オブジェクト指向のシステムは確かに魅力的であるが、大規模開発には適さない。「オブジェクト指向ってなに?」と思われている方は、たくさんいます。Approach)といった、3つの考え方について理解し、比較した差分で考えるのがよいでしょう。この3つはどの方法で行っても、最後は同じプログラムにたどり着きます。「システム開発は、どう行えばよいか?」を気にしている人です。方法論は、あくまでも方法論で学校の勉強のレベルです。方法論は、アプローチの方法が違うだけで、良いシステムの結果は同じです。大切なことは、最終的にどれだけ何と何が同じで、何と何が違うのかを洗い出してシステムを作り上げるかということである。その手段として、プロセス指向、データ指向、オブジェクト指向しいては、アスペクト指向、サービス指向、ビジネスプロセス指向があります。結局、どれでやっても、システム開発/メンテナンスが良いものを作りたいのです。これを踏まえた上で、ここでは、他の方法論と比較しながらオブジェクト指向について記述していきます。そんなことは、みんなわかっているし、調べればわかる。システムを設計する際、まずはじめに要件定義を行います。この要件定義で登場する具体的に人間が認識する登場人物のことをオブジェクト指向でのオブジェクトといいます。組織を管理するシステムを作るとします。組織内には、社長の鈴木さん、部長の佐藤さん、田中さんなどがいます。この人たちの管理職や各部門、各課の関係を登録して管理するシステムを作成するとします。上記の文章で、オブジェクトにあたるのはどれでしょうか?オブジェクトは具体的に人間が認識する登場人物、つまり鈴木さん、佐藤さん、田中さんです。勘がいい人ならこれで、オブジェクトがなにかニュアンスをつかめたでしょう。わからないと思うので、別の例を次に上げます。オブジェクトとは(2)業務システム開発をしていると、知らないですまないデータベース。プロセス指向(POA)でシステムを開発しようとしても、昔のようにSAMファイルにデータを書き込むのではなく、リレーショナルデータベース(RDB)にデータを書くようになった。よって、POAで開発を進めようとしても、データベース設計が必要となり、データ中心指向(DOA)でも、設計する必要が出てきました。ここで、スケジュール通りにすすまない状態が発生する。POAでシステム設計する人とDOAでシステム設計する人が別々に設計するので、意思疎通が難しくなるのである。こんなトラブルにならないように、優秀なシステムアーキテクチャは、先にER(エンティティリレーション)設計(DOA設計の一部)をしてしまう。そのあとで、業務手順に沿ってPOA指向で機能設計する。「なんやぁ、オブジェクト指向してるやん。」で、本題なんですが、このようなシステム開発されている方々なら、オブジェクトというのは、データベース内の1レコードと思っていただけば良いのです。テーブル(エンティティ)設計した際の、実際にテーブルに入るレコードのことです。社員テーブル内の1レコード(鈴木さんとか佐藤さん)のことです。いう風に理解していただければ、一番わかりやすいと思います。ニュアンスつかめました?ただ、テーブル内の1レコードはオブジェクトなんですが、テーブルに書き込まないオブジェクトってのが他にあるだけです。次は、そのようなオブジェクトについて上げてみます。オブジェクトとは(3)システム設計でデータベース設計を行う場合は、静的情報のみを洗い出します。いったように属性を持ちます。このように、属性をもつものしかER設計では注目しません。該当システムの開発においては、このような属性は持つ必要がないオブジェクトが存在します。仕事しかしない、つまり動的情報しかもたないオブジェクトです。このオブジェクトも一緒に考えることがオブジェクト指向ですね。組織を管理するシステムでは、鈴木さん、佐藤さんという実際に組織に属しているオブジェクトは、データベースに登録されます。この組織に対する操作は、データベースに保存されません。人事部の人が行っている仕事に、組織図を作るという仕事があります。組織を管理するシステムでは、この仕事も(を)システム化します。「2005年第三クオータ時点の組織図」もオブジェクトです。データベースには、もととなる情報のみ保存されればよく、データベースに保存されたデータをもとにつくられた図などは別途考えます。オブジェクトとして考えれば、データベースに保存されようがされなかろうが、関係ありません。なんでもかんでも、まず同じという観点で考えることが大切だと私は思います。同じであるということは、1度設計すれば、その他では「あれと同じです」で説明が済むということです。プログラムも同じです。1つ書けばあとは、それを呼ぶだけでよいということになります。次は、いよいよ何と何が同じで、何と何が違うのかの考え方第一弾について書いてみます。共通の性質を有する部類,種類のこと。そんなことは、みんなわかっているし、調べればわかる。ソフトウェアを設計するということは、どれだけ何と何が同じで、何と何が違うのかを洗い出すことである。洗い出したオブジェクトの共通点をクラスといいます。前述のオブジェクトとは(1)で鈴木さん、佐藤さん、田中さんは、具体的に存在するものであり、それがオブジェクトだということを学びました。いった情報を保有するものであると気づきます。これらの共通事項に名前をつけて、従業員と呼ぶとします。この従業員という型(共通の性質を有する部類,種類)が、クラスです。クラスの特徴は、抽象的な名詞であることです。実際には存在しないが、共通点に人間が名前をつけたものであることに気づきます。オブジェクト指向では、このクラスのネーミングがとても大切です。システム全体では、たくさんのオブジェクトが登場します。それらの共通点であるクラスもたくさん登場します。このとき、自分以外の人が誤解をしないように、共通点を的確に表現する一般的な名前をつけることが大切です。だれがどうみても、組織を管理するシステムで、鈴木さん、佐藤さん、田中さんは従業員だと思うなら、それは正しくクラスを見つけられたことになります。次は、データベースの場合で考えてみます。クラスとは(2)前回で大体理解していただけたと思うのですが、ER(エンティティリレーション)設計の場合だとテーブル(エンティティ)は、クラスだと思って頂くとわかりやすいです。オブジェクトとは(2)で登場した社員テーブルがクラスで、社員テーブルにデータとして入るレコード(鈴木さんとか佐藤さん)がオブジェクトです。具体的な値をセットするとレコードになります。従業員というクラスに社員番号1番で、社員名鈴木一郎で性別男性で・・・・という具体的な情報が付加されることでオブジェクトになるともいえます。?何と何が同じで、何と何が違うのかの考え方第一弾を理解していただけたのではないでしょうか?DOAとOOAの違いとして共通点であるクラス探しから行うか、具体的なオブジェクト探しから行うかの思考の違いが一番大きな違いだと私は思っています。話は変わるのですが、リレーション(関係)が大切です。クラスをただ単に見つけ出すだけで満足してはいけません。オブジェクトとオブジェクトの関係の共通点を見出し、クラスとクラスの関係を洗い出す。この点も常に考えておく必要があります。組織と部門と従業員の関係。佐藤さんはシステム部に所属しており、A社という組織は、システム部を含む他の部門から構成されているという関係です。この関係を折角考えているのだから、設計書に記述しておきたいですね。この関係を記述する方法として現在主流なUML法のクラス図で表してみましょう。好きだけど高くて個人では買えない・・・)リレーションとは(1)オブジェクトとオブジェクトには関係があります。その関係を大きく三つに分けることができます。継承の関係(抽象と抽象の関係)保有の関係の三つです。1つ目の具象と抽象の関係は、クラスとオブジェクトの関係です。佐藤さんは従業員です。(AというオブジェクトはBというクラスです。)佐藤さんと従業員は、具象と抽象の関係です。これまでで、ニュアンスをつかめているでしょう。2つ目の継承の関係は、is-a関係とも呼ばれます。佐藤部長は、従業員です(管理職は従業員です。)といえるので、管理職と従業員は継承の関係です。3つ目の保有の関係は、has-a関係とも呼ばれます。A社はシステム部を保有します。(組織は部門を保有します。)システム部は、佐藤さんを保有します。(部門は、社員を保有します。組織と部門、部門と社員は保有の関係です。これらも保有の関係です。保有の関係で保有されるクラスを、クラスとして設計せずに属性という言い方をしていきます。ここで、何と何が同じで、何と何が違うのかの考え方第二弾です。いったものの場合は、クラスにするか属性にするか検討します。今から作るシステムの環境で決まります。「社員名は文字列です」といえるので、継承の関係です。言語に標準で用意されている文字列クラスにマッピングできます。属性としてしまうことで、クラスを共通化してしまうのです。このようにして、共通化していきシステムを簡単にしていくのです。プロセス指向、データ指向、オブジェクト指向、アスペクト指向、サービス指向、ビジネスプロセス指向といったどのようなアプローチを取ったとしても、システムの差分を設計するのです。何を作らなければならないかを整理(設計)していきます。継承の関係(抽象と抽象の関係)の切り分けです。この切り分けを間違えてシステムを複雑化しかねないのです。オブジェクト指向を学者がするのなら、どんどん複雑になってもかまわないでしょう。時間を使って解決すればよいのです。ソフトウェア開発の場では違います。ポリモフィズム(次回触れます)を利用し、シンプルにしなければなりません。多態性または多相性と訳されている。オブジェクトは、関係をもち、関係を整理すると属性をもつと学びました。オブジェクトは、さらに仕事をもちます。オブジェクトをすべて擬人化して考えることで、オブジェクトがもつ仕事を見出すことができます。この仕事をオブジェクト指向では、操作といいます。組織を管理するシステムの範囲で従業員が保有する操作を考えてみます。*異動する(所属、昇任、降任)*変更届けを出す(引越、婚姻)*働く*給料をもらうがあります。オブジェクトは(1)で登場した課長の田中さんとヒラの山本さんがそれぞれ、給料をもらうとします。管理職である田中さんは、会社から管理職手当てがでており、ヒラの山本さんよりも給料は高くなります。これは、同じ給料をもらうという操作なのに、結果が違うということです。同じ操作なのに、オブジェクトごとに振る舞いが変わることをポリモフィズムといいます。平社員が給料をもらうのと管理職が給料をもらうのは違うと考えるか同じと考えるかで、ソフトウェアの作りが変わってきます。同じと考えて、ここだけ違うと考えられることが大切です。これをするために、視点をいつも高いところにもっていくよう心がけます。同じ計算方法ですみます。設計やプログラムでもし何々だったらというIF文を考えるのではなく、こう考えればすべて同じというふうに解決していくことで、シンプルなソフトウェアを構築していきます。何と何が同じで、何と何が違うのかをしっかり見極めてこそポリモフィズムです。複雑なソフトウェアは、心配性なひとが「この業務ではこういう場合にこれが違うあれが違う」と違いばかり気になって同じことに気が付かないことで失敗してしまいます。「入力データを加工して出力データを作成するだけ」のもの、または、そうなるようにもっていくものだと考えます。すべて一緒の視点を持っていきたいと思います。システムは芸術!?今日は、システムが芸術かどうか考えてみたいと思います。絵とか彫刻とかプラモデルって、実物にまねて作ったものです。コンピュータで作られるシステムも実物にまねて作ったものです。芸術を辞書で調べると「芸術...鑑賞の対象となるものを人為的に創造する技術」とあります。私は、システムとは現実のビジネスの対象となるものを人為的に想像するものと思います。「芸術とは、自然が人間に映ったものです。大事なことは、鏡をみがくことだ」と言っています。私は、システムとは自然にまたは、ルールにしたがって人間が行うことだと考えています。大事なことは、鏡をみがくことではないでしょうか。絵や彫刻は、見た目だけでなく動きや感情をその創造物に込め、モデル化しようとしています。システムは、絵や彫刻とは違うけれども、ビジネスをモデル化しようとしています。上記から考えてある意味、システムも芸術といえるのではないでしょうか。高い視点(システムの全体像)から物事をみてモデル化する必要があると思います。「それはセンスを必要とされる。簡明で誰にも分かりやすいものでなければならないと思います。良いシステムではないでしょう。この感覚を身につけたいものです。芸術的センスがないと、良いシステム設計はできないと思います。リレーションとは(2)あなたが街を歩いていてとても好みの女性(男性)を見かけたとします。するとあなたの頭の中では「あ、あれは初恋の彼女(彼)に似ている」もしくは「あ、あれは3番目の彼女(彼)に目元が似ている」と記憶をたぐり寄せます。この時のあなたの脳内を見てみましょう。*好みのタイプの人を見かける(五感が刺激される)*びびびっとくる(脳内細胞シナプスに電気信号が伝わる)*以前の彼女(彼)を思い出す(シナプスによってニューロンが刺激される)過去に見たり聞いたり触ったりしたことというのは必ずニューロンという神経細胞に記憶されます。あなたが以前好意を持った異性もしっかり記憶されています。思い出せなくてもニューロンには必ず記憶されているのです。ニューロン間を伝達するシナプスがないニューロンはどこからも呼ばれないため、死んだ記憶となってしまいます。困ったことに、変にニューロン同士を結ぶシナプスが出来てしまっても思考できなくなってしまいます。恋多き人は何番目の異性と似ているのか思い出せないのです!!・・・いや、そんな話ではなく思考とはつまり、過去の記憶をどれだけ思い出せるかという単純なことです。脳のシワ(シナプス)が多い人ほど頭がいいと言われます。ニューロンをオブジェクト、シナプスをリレーションと考えてみます。オブジェクト指向のブログなので。オブジェクトとオブジェクトの関係は、さまざまあります。関係しているものはそんなに多くはないです。関係がないオブジェクトもありません。オブジェクトは(1)で登場した鈴木さんと佐藤さんには直接の関係はありませんが「鈴木さんはシステム部を統括しており、システム部の責任者として部長の佐藤さんがいる」というつながりで関係が発生しています。どのオブジェクトとオブジェクトが関係もっているのかを正しくみきわめる必要があります。リレーションを間違うととんでもないシステムが出来上がってしまいます。複雑になって難しいシステムになってしまったりします。システム設計において、リレーションが正しいか正しくないかでプロジェクトの成否は決まります。まとめ:歴代の彼女(彼)を間違えて声をかけると大変なことになる。いうこと・・・なのか?オブジェクトとは(4)これまででオブジェクトには、3つの特性があることを学びました。リレーション(関係)オブジェクトは単独で存在することはありません。ほかのオブジェクトと関係を持っています。保有の関係のいずれかです。属性オブジェクトは、固有の姿・形・性質などを持っています。これらのうち、文字列とか数値で表されるものは、新たなオブジェクトを立てるのではなく、属性とします。各オブジェクトは固有の(仕事)振る舞いを持ちます。これを操作(operation)と呼び、動詞で表現します。本当は、もうひとつ特性があります。アイデンティティ(識別)各オブジェクトは、ほかのオブジェクトから自らを識別できるアイデンティティを持っています。鈴木さん、佐藤さんというのは、必ず、個別に識別できます。(注)オブジェクトから、識別性を取り払うとクラスになります。オブジェクトは(1)で登場した鈴木さん、佐藤さんというのは、従業員というクラスです。これらの4つの特性があるものをオブジェクトといいます。書いている本で「軽快なJava」という本があります。「黄金のハンマーは危険である」と・・・。この本でかかれていることはシステム開発者(特にプログラマー)にとっては、とても勉強になる内容でした。(著者のJ2EE嫌いの偏見を飛ばして読めばですが・・・)私も黄金のハンマーは危険だと思います。黄金のハンマーとは、過去にやってきた自分の技術にこだわり、どのプロジェクトでも適用しようとすることです。過去の成功にこだわると歪が生じます。過去成功したそのとき以上に成功できるようにしたいと思っていれば、問題ないのでしょうけど、そこにあぐらをかくと百害あって一利なしです。同じ仕事を2個のプログラムにさせる設計をしてしまったと後悔することが多々あります。言語や環境によって、同じプログラムが2個できてしまったりすることは、しょうがないとあきらめています。人間が同じ作業を2回しないことが大切だと・・・。人間は、単純作業だとどうしても、ミスしがちです。(気を抜いたり、手抜きをしちゃうんですよねぇ。)結果そういう個所にバグが潜みます。同じ仕事を2度人間がしなくてよいそんな仕組み作りを私は、いままでもしてきたしこれからもしていきたいとおもっている。そのための考え方の1つにオブジェクト指向も勉強してきた。皆さんは、何のためにオブジェクト指向を勉強されていますか?カプセル化とは(1)capsuleとは、要約、概要のこと。そんなことは、みんなわかっているし、調べればわかる。自分がわからないことは、人に頼むでしょう。自分がわからなければ、知っている人に依頼する。自分のプロジェクトでメンバー不足が発生し部長に要員手配を依頼します。数日後、自分のプロジェクトにメンバーが増員された。カプセル化とは、知ってる人を最小限にすることで、ルールが変わったときに一人だけが知っていれば良いようにするための考え方です。上記の場合、要員手配のルールが変わったときに部長だけがルールが変わったことを覚えればよいですね。透明感をもたせメンバーにも知らせると思います。仕事が進む形に設計します。そもそも、薬をカプセル化したことからこのようにいわれています。「こんな症状の時はこのカプセルを飲んでね」っていうだけでよいのです。「全国民に配合を伝えないといけないんです」っていってるみたいなカプセル化とは、どんな要望にも柔軟なシステムを作るための考え方です。あいつに聞くオブジェクトの洗い出しに没頭し、無我夢中になってクラスはどれかと考えることがあります。物理的に、様々な具体例を洗い出し、オブジェクトというオブジェクトを洗い出したのはいいが、いざクラスをどれにすべきかというときになって、悩むのです。クラス設計こそが、プログラミング工数、メンテナンス工数にもっとも左右するからです。悩んでも悩んでもいい方法が思いつかない場合に、ふと一服したときに、そうだこうすべきだとひらめく。タバコを吸いにいったときが、一番問題解決します。一服しているとき、自分の頭の中にいる別の人が教えてくれるような感覚になります。その自分の頭の中にいる別の人のことをあいつと私は、呼んでいました。それで、今日改めて、あいつが何者か知ったので、ここに記しておきたいのです。「メタ認知」というそうです。メタ認知とは、自分を改めて客観的にみることだそうです。(こういう風に、記号化(言語化)されていることだったんだ。)あいつという認識だと他人にうまく表現できないノウハウでした。メタ認知というクラスを知ったことで、WEB検索することもできるし、他人に伝えやすくもなったので、今日、このブログに書いてみました。色って何?みんなが赤と言っている色は、本当にみんな赤く見えているのだろうか?信号機の一番右にあるのが赤と習ったので私もあなたも赤と言っていいます。見えている内容が人それぞれ個人差があるのは、確実です。色盲のひともいるのだから・・・。あなたが見てる青が私にとって赤かもしれない。あなたが見ている赤が私にとって青かもしれない。人それぞれ、その色が、この色と教えられることによってその色を、何色って覚えます。要は、人が共通に認識できるように、ものごとを記号化しています。(ことばや文字も記号の一種である。)クラスだってそうだ。オブジェクトを人間が共通に認識できるように記号化されたものですね。DOAとOOAとPOADOA(データ指向)とOOA(オブジェクト指向)ってデジタルとアナログと似てるっておもうんですよね。デジタルな人とアナログな人という言い方をたまに聞きます。いうときに使われるかというとデジタルな人っていうのは、決断をてきぱきできる人しかし、許容範囲が狭く周りを取捨するような人ってかんじかな。効率のいい人ってかんじやね。アナログな人は、決断をあいまいにしてしまう人しかし、許容範囲が広く周りを受け入れる人ってかんじやな。効率は悪い人ってかんじやね。アナログとは、大小の程度で,データを表現することです.デジタルデータは,数値の列で表現されたデータです.ということから考えると本来、デジタルな人は、世の中を記号化、言語化して理解する人。何でもオブジェクトをクラスで表現して理解する人かな。アナログな人は、世の中をそのまま理解する人。オブジェクトはオブジェクトのまま覚えちゃう人ちゃうかな。っシステム設計するときに、DOA設計するかOOA設計するかの違いをかんがえるとDOA設計は、まず、対象業務のエンティティ(クラス)を洗い出して、そのクラスとクラスの関係を考えていく。考えるときに具体例として、オブジェクトを上げる。こんな設計方法ですね。OOA設計は、まず、対象業務のオブジェクトを洗い出して、そのオブジェクトの共通点を言語化し、クラスを見つけ出す。オブジェクトとオブジェクトの関係がそのまま、クラスとクラスの関係となる。処理だけに注目して、業務の手順(業務フロー)どおりにプログラムしていきます。このとき、同一の処理が見つかると共通処理として洗い出していきます。結果オブジェクト指向システムと同じ結果になっています。求めるシステムになるわけですが、アナログな人は、OOA設計がデジタルな人は、DOA設計が天才は、POA設計が向いているんじゃないかなぁと私は思います。以前経験したシステムと同じであれば、以前のクラスを再利用します。経験範囲に応じて、OOAからDOAへまたは、DOAからPOAへ指向をかえて設計していけばよいと思っており、そのように行っています。皆さんは、システム設計するときどのように設計されていますか?JAVAでポリモフィズムポリモフィズムを実現するには、リフレクションを使うことが必須になる。いうことで、リフレクションサンプル。オブジェクトの反対の意味。初版のオックスフォード辞典では、オブジェとは「その神を邪魔するもの」という意味。サブジェクトとは、そのしもべになること。本来は主語がサブジェクトにあるわけでも、目的がオブジェクトにあるわけでもない。隷属しているサブジェクトがあって、邪魔をする関係として「オブジェクト」があった。現在は、オブジェクトとサブジェクトの位置と意味をひっくり返してしまっている。現在の考え方でいうとサブジェクト指向は、主体が仕事を自分でやる指向である。反対にオブジェクト指向は、対象であるみんなに仕事をやってもらう指向となる。プログラムとは(1)コンピュータにさせる仕事の手順書のこと。コンピュータでプログラムを作る作業をプログラミング(programming)と呼ぶ。プログラミングでは、最初にコンピュータで行いたい仕事のために、プログラマがコンピュータになったつもりで、アルゴリズムを作る。作ったアルゴリズムに従い、それを特定のプログラミング言語で記述する。その記述された手順書がプログラムである。カプセル化カプセル化とはソフトウェアを構成する要素をコード(命令)とデータ(情報)に分類し、機能修正に対する耐久性で比較した場合、データの方が一般的に弱い構造を持つ。データは、利用者に対して、自分の構造自体を公開してしまうからである。これに対し、コードは自身の実行形式であるインターフェイス(返却値・引数)によって、実際の内部処理(関数の内部)を覆っているため、内部ロジックを変更したとしても、インターフェイスさえ変更しなければ、結果的に機能修正が利用者に及ぼす影響を押さえることができる。この性質を利用し、直接データを公開するのではなく、コードを通じて公開するような構造化を行えば、弱い構造をもつデータでも耐久性をあげることができる。この考え方をカプセル化、もしくはラッピング(参考:ラッパー)という。カプセル化を進めることによりオブジェクト内部の仕様変更が外部に影響しなくなり、ソフトウェアの保守性や開発効率が高まる。コーダコーダとは設計書を元にソースコードを記述する人。ソースコードをコンパイラなどのツールを用いて実際に動作する形式に変換し、試しに実行して不具合を探したり、見つかった不具合を取り除くためにソースコードを修正したりする作業をする人。オブジェクトの反対の意味。初版のオックスフォード辞典では、オブジェとは「その神を邪魔するもの」という意味。サブジェクトとは、そのしもべになること。本来は主語がサブジェクトにあるわけでも、目的がオブジェクトにあるわけでもない。隷属しているサブジェクトがあって、邪魔をする関係として「オブジェクト」があった。現在は、オブジェクトとサブジェクトの位置と意味をひっくり返してしまっている。現在の考え方でいうとサブジェクト指向は、主体が仕事を自分でやる指向である。反対にオブジェクト指向は、対象であるみんなに仕事をやってもらう指向となる。三要素から構成される単位」を意味する概念。「特定の仕事を行う単位」を意味する概念。個々の要素が意味のあるひとまとまりになった単位。サブジェクトがある決まったビジネスルールに基づきオブジェクトに対し仕事の依頼を行う。このことにより仕事を成り立たせる仕組みを見出すことを「システム化」という。システムを導入する企業は、コスト対効果を考えシステムを要求しなければない。することで、何が優先でなにが後回しでよいか明確に判断できる基準を持たなければならない。システムを導入することで何かを自動化し、人間がする仕事を減らさなければ意味がない。システムを構築する人は、物事を汎用的に捉え、シンプルなシステムを提案し構築しなければならない。例外を例外でなくするように物事を考える必要がある。我社の使命は、「システムを構築する人のためのシステム」を提案し構築していくことである。