|
|
居心地が悪いシステム開発
|
目次 第１回 開発側の問題点 第２回 下請け企業の連鎖 第３回 ユーザートップの姿勢 第４回 ユーザーシステム部門の悲哀 第５回 官公庁とITジェネコンの癒着？ 第６回 もう一つの本質？ 第７回 これは極論か？ 第８回 逆転する状況 第９回 家畜化するユーザー 第１０回 迷想する？ITベンダートップ 第１１回 モラルハザードか？ 第１２回 ユーザーはトロか？ 第１３回 東証株誤発注の責任 第１４回 そして誰も居なくなる？ 第１５回 お受験もシステムのせいか？ 第１６回 悪質住宅リフォーム業者か？ 第１７回 システム的短絡思考の果て？ 第１８回 特攻と原爆？ 第１９回 Web2.0は世界を救う？ 第２０回 Web2.0は蜘蛛の巣か？ 第２１回 Web2.0のロングテールを齧る？ 第２２回 C#で東浩紀を語る？ 第２３回 C#とJavaのInner Class? 第２４回 動かなかったシステム？ 第２５回 ツール概念が人間を規定する？
システムを開発するため客先や関係者と打ち合わせを しているときに、最近ふと居心地の悪さを覚えること がある。 これにはいくつかの原因が想定されると思う。 だが、そもそも居心地が悪いのは、自らの業務能力と意識の 低さを示すものであり、わざわざ分析する必要もなかろうと、 いう意見があるかも知れない。 それは自明のこととしてひとまず置いておき、自分の経験から （自らの業務能力と意識の低さを暴露する結果ではあるが･･･） その理由と原因を思いつくままに列挙してみよう。 読者の皆さんが感じるものと一致するものがあるかも 知れないし、ないかも知れない。 本稿の目的は、率直な状況判断と心理分析が、システム開発を 進めて行く過程において、なんらかのプラス（あるいはマイナス？） に働く可能性を探ってみたい、ということである。 まずは問題の取っ掛かりとして、一般によく問題視されている 下記二つの命題を選んで見た。 １）我々が望むのはシステム開発から得られる収益性なのか それとも顧客満足度か？ ２）お客はそもそもシステム開発を本当に望んでいるのか？ 本来は２）が先で１）が後に来るべきであるが、システム開発側から みて最も身近な話題である１）をまず検討してみよう。 前提として、ここはBlogという私的媒体（半ば公的？）であるため、 A) 会社におけるシステム開発のマニュアルや規定、B)巷間に溢れる 開発要領本に書いてあるような教科書的な内容は割愛する。 分析にあたって、とりわけ開発側の社会心理学的？本音ベースを 主体に検証してみよう。 勿論、これはあくまで筆者が個人的に考察する本音であって、 本音は百人百色なので、読者のなかに、A)やB)を自らの本音と して体感・体得しておられる強者（曲者？）や、希望に満ち溢れた 開発新人君がおられても、それは全然問題ではない。 Blogにおける議論は常に開かれたものであるべきであり、多様な 論点こそ、真の意味で建設的なものを生み出す基盤であるから。 では １）我々が望むのはシステム開発から得られる収益性なのか それとも顧客満足度か？ 通常、この問題は二者択一的な設定で問われることはない。 顧客満足度を最大限にすると、同時に収益性を確保する。 又は 顧客満足度を最大限にすることが、収益性を確保することに繋がる。 と、並列的または因果関係的に思考するよう「教えられている。」 さらに妥協？しても、収益性の「範囲内で」顧客満足度をいかに 高めるかに知恵を絞れとか･･･包含的に述べられることが多い。 さて、現場の実態はどうであろうか？ では、営業、開発、メンテそれぞれのフェーズにおける顧客満足度の あり方を収益志向性と絡めて眺めてみよう。 １） 営業部隊は「極めて一般的に」自分では良く知りもしない、 技術的な新動向や理想論をお客にぶち上げて、「これに乗り遅れると ビジネスチャンスを逃しますよ。」「負け組み企業になりますよ。」 と、お客に「教唆」する、…プレゼンというソフィスティケイト された行為に紛れ込ませているが、実態は強迫観念を伴った唆しで あり、目的はお客の当該システム開発予算を最大化し、受注に結び つけることである。 受注実績で営業は評価されるため、それが技術的に実現するか どうか？システムがまともに動くかどうか？なんてことは、あまり 頭にはない。 まして、お客のビジネスなんて知ったことではない。 「建前として」プレゼン中「最も強調される」お客のビジネス・ メリットではあるが、営業部隊の意識の中は受注額と利益幅、 同種プロジェクトのリピートの可能性しかない。 ２）開発部隊は営業がぶち上げた構想の火消し役に徹する。 これ以外には、開発プロジェクトを無事終了させる可能性は皆無 だからである。 コストと納期をキープするために、いかに当初の理想論的仕様を 削るか？削って、削って、削りまくっても、開発作業は遅れる、 コストは肥大化する。 これらの遅れやコスト増加は、結局テスト工程の日程や体制に しわ寄せされ、バグだらけの本番稼動の日を迎えることになる。 従って顧客満足度などは端っから期待するほうが無理な話である。 では、「良心的に」顧客満足度のために当初の仕様を一切削らず、 追加仕様を次から次に受け入れたプロジェクトはどうなるのか？ そのような真っ当な開発部隊は存在しないのか？ 実は存在していた。 日経の「動かないコンピュータ」にリストアップされたプロジェクトが 累々と･･･ 「良心的な元請け」の下請けに組み込まれたベンダーの プログラマーが、「喜劇的な悲劇！」に見舞われることになる ことは、この業界において周知の事実となっている。 ３） メンテ（保守運用）部隊は稼動直後の「当然起こるべくして 起こる」トラブル対応に開発部隊と一緒に追われながら、「OJTで」 本システムの脆弱性を身体に叩き込まれる。 同時にシステム固有のだましのテクニックやノウハウを学習する 機会を得るのである。 メンテと開発部隊が共に仕事するのは、この時期しかない。 この時期さえ過ぎれば、開発部隊は「後は野となれ山となれ」 である。この希望？が無ければ、開発部隊の精神力は開発中 とっくに切れてしまっているのである。 不整合な設計、つぎはぎだらけの実装、これらがトラブルを頻発させ システム改修を困難にさせる。 ところが、これが即ち、メンテ部隊の仕事が「末永く確保される」 ことになる理由である。このメンテ費用こそ、開発中の赤字を 埋めるための収益源となるのである。 が、しかし顧客満足度とは全然レベルの違う、 客先の「文句」「怒号」「嫌味」の中で、営々とメンテは続く･･･ とまぁ、今回は開発側の顧客満足度不在の現実を強調し過ぎた 傾向はあるが、上記の１）〜３）と全く関係のないプロジェクトが 現在のシステム業界に存在したとすれば、それは、 奇跡的なことではないだろうか？ 以上 目次へ
「居心地の悪いシステム開発」シリーズの第１回では 営業、開発、保守の各段階において、いかに顧客満足度が 収益性のために犠牲になっているか、単なるお題目に 過ぎないものになってしまっているかを述べてみた。 これは問題の導入部として、あくまで全体の布置を 分かりやすくする目的で書いたものである。 内容的にシステム開発業界に限った話でもないことは、 読者の皆さんも良くお分かりと思う。 建設業界やプラント業界など受注生産形態の企業において、 営業の調子の良い話に泣かされる設計や現場、プロジェクト の混乱やメンバーの視野狭窄的な心理や行動、保守運用 による赤字費用の回収などは、日常茶飯事であり謂わば、 受注生産企業におけるデファクト・スタンダードになって いる、といっても過言ではない。 システム業界ではお客に対して「WINWINの関係で」 と言われることがある。またそれを目指すべきが真の 営業と教えられている。だがそれは畢竟、「知的に優位に ある方が劣位を食う」というビジネスの実態にオブラートを かけたものに過ぎないのではなかろうか。 官公庁がお客の場合は、「双方合意の上で」ベンダーが 食う決まりになっているが、マーケットにおいては、 お客が優位か、ベンダーが優位か、それはケースバイケース である。ただベンダーにとって、いつも食えるお客、脇の 甘いお客が良いばかりとはいえない。 そんなお客は早晩マーケットから消えざるを得ないだろうし、 楽に食えれば食えるほど、自らの技術や組織の進歩や向上も ないからである。官公庁商売に慣れたベンダーが競争力を 失う原因は、この辺りにあろう。 さて、次回は第１回で述べた開発側の問題点を掘り 下げる前に ２）お客はそもそもシステム開発を本当に望んでいるのか？ に関して、現在業界で問題視されている概要を眺める ことにする。 その後、お客と開発側双方の視点から筆者なりの問題点の 所在と原因を分析することにしたい。 なお、前回掲載した >「良心的な元請け」の下請けに組み込まれたベンダーの >プログラマーが、「喜劇的な悲劇！」に見舞われること >になることは、この業界において周知の事実となっている。 における「喜劇的な悲劇！」とは何ぞや？ という、この業界に不案内な？読者よりの質問がメールで あったのでここでお応えする。 例えば５人のメンバーが「この土地に穴を掘れ」という 指示を受ける。メンバーはせっせ、せっせと穴を掘った。 途端に「今掘った穴を埋めろ」という指示を受ける。 ぶつぶつ言いながらもメンバーは穴を埋める。 この掘ったり埋め戻したりの作業を３回繰り返した ところで、このプロジェクトは終了した… つまりプロジェクトの指揮命令系統が大小の仕様変更で 混乱を極め、末端で（中心でも…？）何が行われているのか、 その意味は何か、がサッパリ誰も分からない状況を指して 「喜劇的な悲劇！」と定義した次第である。 実際の作業はコーディングだからして、物質的な損失は 発生しない。自然破壊も？ ただ被害は、人的損失「だけ」であるが… 以上 目次へ
前回まで開発側の問題点に関して全体を俯瞰的に眺めてみた。 今回からユーザー側から見た問題点を 「お客はそもそもシステム開発を本当に望んでいるのか？」 の視点から、経営トップ、システム部門、ユーザー部門の 三つの階層に分けて検討してみよう。 なお、システムのユーザーも多種多様であり、一概に 共通する問題点を洗い出すのは困難ではあるが、以下では 東証一部上場企業（従業員5,000人超、資本金100億円超） のような比較的大きな企業を想定して述べることにしたい。 １）経営トップ 一般的にシステム開発に当たっては、いかにユーザーの 経営層を「その気にさせるか？」が当該プロジェクトの 成否を握ると開発側からは言われている。 また、ユーザー企業もCIOの設置などシステム開発に 熱心な経営層が、最近では増えているように 見うけられる これまでの経験から経営トップのシステム開発にのぞむ 姿勢を以下の３タイプに分け、タイプ別にそれぞれの 関心の有りどころを探って見よう。 a)フンフンお任せ型 このタイプは深くシステム開発に関わる気持ちも余裕も ない。基本的に開発は全て部下まかせで社内儀式的に 計画案や進行状況の話を聞くだけ。システムが大きな トラブルを発生させ、自らが頭を下げるような羽目に さえならなければ、開発がどうなろうとかまわない。 このところトップの責任や指導力を問われる場面が 増えたため、経営者として本業や資本融資以外の事に 首をつっこむ暇などないのが本音であろう。 さらに言えば、一応巷間騒がれているIT分野にもトップ として「関心の一端を」示しておきたいところだが、 「成功して当たり前、失敗すれば泥沼」に自ら引きずり こまれることだけは、なんとしても避けたいところであろう。 トップにとってリスクとリターンがこれ程アンバランスな 経営課題も珍しい。このフンフンタイプが大企業のトップに 最も多いことは極めて納得のゆくところである。 b)コストと納期専念タイプ 比較的中規模の会社に多いトップで、システムの中味が 分からないものだからコスト（開発費用）と納期だけに 興味を示すタイプ。 システム効果についても、何人分の合理化や減員が 可能なのか、が関心の中心を占める。 c)システム親和（神話？）型 極めてまれではあるが、システムの開発にかって携わった 経験を持ち、自ら細かい部分まで関心を持つタイプ。 ただし、その経験もかってのホストを中心とした旧いもの に過ぎず、現状の技術進歩にキャッチアップしているとは 言い難い。 このタイプはシステム開発側のトップにもよく見られる。 開発側から言わせれば、上記ユーザートップの姿勢の中で 有りがたい順番を言えば、c)->b)->a)では「ない。」 a)->c)->b)といったところか。 b)の開発費用を削られること、納期にうるさいこと、実質的に 何人減るのか？など開発側としては話題として最も避けたい ところである。 c)のシステムを「生半可に」知っている、分かっている ユーザートップもシステム開発を進めて行く上での混乱 要素にしかならない。 ユーザートップの鶴の一声でプロジェクトが山に上ったこと はあれ、収束に向かったケースは聞いたことがない。 （開発側トップの鶴の一声も…） a)あくまで消去法であるが、フンフン型のトップが最も 無難であることは良くお分かりであろう。 実はユーザトップの姿勢がシステムに対する顧客満足度に 与える影響度も実は同じ順序a)->c)-b)である。 b),c)からはトップ自らの不満が飛び出す可能性が高いが フンフン型であればトップ自ら責任を問われることが ない限り文句は出ない。 たとえ責任を問われるような場面においても、かって 某銀行の頭取が行内のシステムトラブル発生時 国会で「実害はありません。」と明言し、当時の 開発ベンダーが「感涙にむせんだ」という有名な話がある。 まさにフンフン型の「鏡」ともいうべき「見事な責任の 取り方？」ではなかろうか。 （一般的には顰蹙を買ったそうだが…） ユーザートップはシステムに期待している素振りは良いが 本当に期待してはいけない。トップのシステム期待度の レベルも低ければ低いほうが、開発側も有りがたいし、 真にユーザーのためになるのである。 トップの期待度が低ければ予算も少なくて済む、さらに これは最も重要なことであるが、動くシステムが完成する 可能性が高い。 トップのシステムに対する期待度とシステムの完成可能性は 「反比例する。」 では冒頭述べた >一般的にシステム開発に当たっては、いかにユーザーの >経営層を「その気にさせるか？」が当該プロジェクトの >成否を握ると開発側からは言われている。 の理由は何か？ ずばり開発側の幻想である。開発側が期待するような ユーザートップは存在しない。 ア)まずは、ユーザートップの期待に応じて高い予算を付けて 欲しい。 イ)プロジェクトを開発側の「思惑通り」推進するために ユーザートップ自ら旗を振ってもらいたい。 ウ)また開発が失敗した場合にユーザーに責任転嫁するため、 失敗の一端をユーザートップにも担ってもらいたい。 （その後ろに開発ベンダーは隠れたい…） エ)幸いにして、上手くいった場合はユーザートップに 認められ、プロジェクトのリピートを期待したい… 等々、 開発側ベンダーが生み出す身勝手な欲望による幻想に 過ぎないのではなかろうか。 次回はユーザーのシステム部門について分析を進める ことにする。 以上 目次へ
本シリーズ第三回では、ユーザー経営トップがシステム開発 のリーダーシップを取ることは事実上難しいこと、また かりに取ったとしても逆効果になる可能性が高いことを 説明した。では、前回述べたユーザー経営トップのタイプ の中で最大多数を占める「フンフンお任せ型」は、一体誰に 丸投げしようとするのか？ 中小企業であればSIベンダーやシステムコンサルタントに 直接丸投げすることもあり得るが、通常大企業の場合 自らの組織の中にシステム部門を抱えている。 ITや通信など情報分野に関しては、社内では一手にこの システム部門が調整することになっているところが多い。 さて、今回は経営トップからの被丸投げ部署である、 ユーザー社内システム部門の問題点を眺めてみることに しよう。 かってホスト全盛時代にはかなりのプログラマーを自ら抱え 開発や保守等に社内システム部門は忙しく活躍していた。 大企業であればその関連会社まで含みシステム要員を 各部署に配置して人員的にも予算的にも隆盛を誇っていた 頃もあった。 現在はホストからサーバーへのダウンサイジング、WEB系の 技術の普及により、ほとんどの社内システム部門は人員の 削減、予算の圧縮、アウトソーシングの波に洗われ、 かっての面影を止めるところは少ない。 実働部隊は子会社化され、システムや通信に関する企画調整 部門としての機能だけが、ユーザー社内にかろうじて残って いるのが現状である。 ユーザーシステム部門の最大の問題点は、ユーザーを代表 しながら、実は自らの子会社における実働部隊をいかに 食わせるか？に関心の殆どが集中していることである。 開発予算を最大化したいという部分では、一見SIベンダーと 利害が共通しているように見える。システム子会社は 収益を上げなければならないので、そこを通じて発注すれば、 全体開発額が大きい方が有り難いのは自明のことである。 ユーザー全体としては開発費用は極小化したいところで あるが、システム部門は「逆の動き」をせざるを得ない。 またさらに、システム子会社の設立目的の一つとして 企業グループ内の仕事だけではなく、グループ外の仕事 （自主営業部分）を増やせとトップから厳命されているのが 普通である。目的は自主営業で儲けた部分をグループ内の 仕事に振り向けてグループ全体の開発予算を低く保とうと することである。だがしかし、グループ内で「なぁなぁ」 の開発や仕事のやり方に慣れたシステム子会社の人々が 厳しいフリーのマーケットで儲けられるほど世の中は 甘くない。 そこでグループ内の仕事の予算を最大化しシステム子会社の 収益を上げ、それでもって自主営業分の赤字を埋めようと するのは必然の帰結である。 ユーザーシステム部門はユーザーグループ内にありながら、 ある意味それを裏切る行為に走らざるを得ない状況に 陥っているのである。 さらにSIベンダーからみても、システム子会社における かってのユーザー子飼いプログラマーの技術レベルに 合わせるような、彼等の人工稼働率を上げられるような開発 プラン以外はシステム部門の承認を得ることが難しいのは、 彼等の置かれている立場を考慮すれば無理もないところ であろう。出来るだけ新規技術を避け、旧来システムを 活かす方向が望ましい。つぎはぎだらけになろうが、運用が 困難になろうが、子会社の連中が遊んでしまうよりはるかに マシだとの判断が下される。 どうしても、この手法がとれない場合にのみ「丸投げ」 が敢行される。 するとどうなるか？ 下記の長大な丸投げの連鎖と伝言ゲームが形成されることに なる。 ユーザートップや現場ー＞社内システム部門ー＞システム 子会社ー＞SIベンダー元請けー＞下請けー＞孫受けー＞･･･ これはまだ単線だからまだましだが、企業合併等で複数の ユーザーの現場、社内システム部門、システム子会社の 下にぞろぞろとコンサル、システム設計会社、SIベンダー、 下請けなどが繋がる複線、多階層の開発案件になると、 それぞれのグループ間における縄張り争いの要素がこれに 加味され、その混乱の度が頂点に達するのは火を見るより 明らかである。 まったくもって非効率極まりないが、たとえ付加価値を 一切付与することがなくても、この「伝言ゲームに参加する」 ことで、（だけで？）ユーザーシステム部門の威信が保たれ、 子会社に金が落ちる仕組みが出来上がる次第である。 だがさらに問題は、ユーザーシステム部門や子会社の実態 や技術レベルがこの程度のものであることを、経営トップも 現場のユーザー部門も、表面には出さないがとっくに察知 しているところにある。それが彼らのユーザー企業内での 求心力を急速に失わせ、統合的な調整力を欠き、システム 開発の混乱に輪をかける原因となっている。 翻って、経営トップも「この状況を充分熟知しながら、何ら 手段を講じない」ところに経営トップとしての経営資源の 重点配分法則に合致した「独自の経営方針」があるのでは なかろうか？「期待できないところは、丸投げする。」 この思い切った割り切りこそ、経営における要諦の一つで あろう…か？ なお、SIベンダーとして注意を要するのは、新規お客の ユーザーシステム部門を相手にする場合は、通常裏には そのお客と繋がっている別のSIベンダーが隠れていること である。即ち、アイデアと企画を説明するだけ説明させ られ、それを「丸取り」されたあげく、仕事は別の ところに「泣き別れ」…の事態にならないよう、充分に 留意する必要があろう。 但し、SIベンダーにとって、こんなユーザーシステム部門 「だけが？」、ユーザーの中で「自らの利害から」ではあれ システム開発を「真から」望んでおり、私企業においては 珍しいお役所的な発想（予算最大化・形式主義）を持った 数少ない部門なのである。 さらに俯瞰的に言えば、この部門ほど現在のシステム開発に おける引き裂かれた状況を体現している部署は他にないと 断言出来る。 「その苦衷を察することはあれ、決して軽侮することが あってはならない。」 一般にシステム業界での技術能力的プライオリティとして １位 OS ２位 言語・コンパイラ ３位 組み込み機器 ４位 フレームワークやコンポーネント ５位 業務システム となっている。 業務系の知識は大切であるが、システム技術者としては あくまで副次的なものであり、その業務に詳しくなれば なるほど当該及び関連システムに「塩漬け」される恐怖が あるため、人気薄な面は否めない。 そういった技術者的な心理面からしても、ユーザーにおける システム部門の行く末は、決して楽観を許さないもので あることは、読者の皆さんも容易に予測し得るところで あろう。 以上 目次へ
これまで本シリーズでは大手私企業におけるシステム開発 について分析してみた。ここで少し焦点を変更し、官公庁に おけるシステム運用の実例に関して検討してみたい。 若干旧聞に属するが、平成17年1月18日のNHKクローズ アップ現代はまさにIT業界の暗部を取材していた。 大手のITジェネコンが、地方自治体行政上の区分変更に ともなう、住所の一部名称変更と年齢基準の変更など、 メインフレームシステムのプログラムを一部修正する ために、それぞれ500万円にも上る費用を請求し、自治体も それをそのまま承認、地方税が支出されていたのである。 通常のプログラム構造からして、いくらなんでもそれぞれの プログラムサブルーチンにコンスト（定数）として住所や 基準年齢が埋め込まれているはずはあるまい。 テストや作動確認を含めてもせいぜい３人が三日でやれる 作業である。それが500万円なのか。 ついに佐賀市は韓国のベンダーにサーバー型のオープン システムを発注して、この日本のITジェネコンのメイン フレームの使用中止に踏み切った。 また長崎県はITジェネコンからシステム構築の見積もりを とったところ、16億円!との回答があった。そこで自ら システム仕様書を書いて地元業者を含めて分割発注した ところ、1億円でシステムは完成し現在稼動している とのことである。 驚いたことに、その過程でITジェネコンから「長崎県 殿」 という通知書が県に届いており、「高度な技術を持った 専門家にまかせないとろくなことは起こりませんよ」、 との親切極まりない?ご忠告まで届いている始末である。 だが、官公庁が上記のようにITベンダーに叛旗を翻し、自ら リスクを負ってシステム的な取り組みをするのは極めて 異例であり、一般的にはITジェネコンの言いなりになって いると見てよかろう。（地方自治体の予算編成段階から 後述のように、ITジェネコンが関与しているはずだ からである。） さて、これまでは納税者の立場から問題を分析してきたが、 こんなに単純な勧善懲悪式の議論で良いのであろうか。 つまり官民癒着構造による税金の無駄使いというパターン化 した見方で我々は判断して良いのか、作業したプログラマー は全ての実情を知っていながら「見て見ぬ振りをする プログラマー達」という図式を当て嵌めるだけでことは 済むのか。 まず上記システム改修費（500万円）の妥当性を検証して みよう。３名が三日作業したとすると、80万円/人月の 平均的プログラマーが従事した場合5千円/Hrとして 5千円＊3人＊8Hr＊3日＝24万円が製造コストである。 これに販管費15％、利益10％を載せても30万円となり、 クローズアップ現代に登場した匿名システム関係者の コスト予想とほぼ一致する。 では残りの470万円とは何か？ 以下はあくまで可能性として考慮すべきポイントを 指摘するものであって、当該自治体のケースを実地監査した ものではないことを予め申し上げておく。またITジェネコン の懐に470万円丸々入ったとする可能性を否定するものでも ない。 １．自治体の前年度システム改修や開発において予算担当者 のITベンダー側に対する「泣いてくれ！」は無かったか？ ご承知の通り年度当初に一定の予算は計上するものの、 システム改修やハード保証切れの故障部品の交換などは 必ずしも予算通りには発生しない。 このような場合、本来なら追加予算を申請すべきところで あるが、これはこれで結構大変な事務申請作業になると 同時に予算計上不足の責任を問われかねない。そこで 「来期なんとかするから、今期はこの予算内で泣いてくれ！」 ということになる。これも官民癒着構造と言えばそうなるが、 ある程度の融通は効かさないと、とても世の中渡って 行けないのも事実である。 ２．この仕事に携わった３名を含む地方自治体メイン フレームシステム担当のプログラマーとは？ 一般的にメインフレーム関係システムは古いものが多く、 改修、変更などのパッチ当てでプログラム自体が当初の 設計と大きくかけ離れ、かつ仕様変更書などのドキュメント が整備されてないケースがほとんどである。 従ってユーザー（地方自治体）がシステムを継続使用して いる以上ベンダー側は事情を知ったメンテナンス プログラマー要員を確保しておく必要がある。 一方、新たな技術を採用しがちな新規システム開発には 優秀なプログラマーを当てざるを得ない。従ってこのような メンテにはそれなりのプログラマーが担当するようになる。 古いシステムのメンテにプログラマーが埋没する状況を 以前も述べたが業界では「塩漬け」にされたという。 メンテって本当は結構大変なんだけれども、ベンダー内での 評価は高くないのである。おまけにメンテの収益性が 低ければ一体誰がやるのか、やらせるのか。 さらにITジェネコンと称されるほどベンダーの世界に おいては階層化した下請け構造が形成されている。 その下請け層の隅々までメインフレームで食っている プログラマーは存在するのである。 WEBやサーバー型の開発方法に乗り遅れた人々が多数食い つないでいる。 いわば地方自治体や中央官庁システムは彼等の貴重な飯の種 となっているのである。 もし、佐賀市や長崎県の開発したシステムを他の地方自治体や 中央官庁にオープンに開放したりしたら一体どうなるのか？ そら恐ろしい限りである。 現状、各地方自治体や官庁はそれぞれ独自にシステムを 開発・発注しているが、多様な職種がある企業と違って 役所内業務の内容がそれほど違うわけがない。 国家・地方公務員法が共通である以上、せいぜい決裁経路が 少し違う程度に過ぎない。ちょっとした手直しで十分汎用化 可能である。 一億やそこらのサーバーシステムが全国の役所を制覇して しまえば日本経済に与える影響も「有効需要の喪失！」と 言った意味で被害甚大ではなかろうか？ （財政の再建には寄与するだろうが…） メインフレームプログラマーにとっては、まさに失職に 即繋がる悪夢が現実のものになろう。 以上 目次へ
さて、前回述べた問題の可能性をさらに煮詰めながら 焦点を一層明かにすることにしよう。 お分かりの通り、前回項目１．の市担当者のベンダーに対する 今期は「泣いてくれ。」しかし来期は必ず返す。は、 逆もあり得る。 来期の予算削減が厳しいのが見えている、とか今期の予算に 余裕がある場合に、今期は「多めに支払う」が来期は 「その分返せよ」と両者が合意することである。 これも官民癒着の一形態であるが、市側職員が業者側の通常 レベルの接待を受ける程度で金品の授受さえなければ、 大目にみられるケースではなかろうか。 真の問題は官庁における予算制度の硬直性にある。 つまり予算査定側も内容が良く分からないため、一律 前年度比ベースで決めることになり、本来は変動費で あるはずの予算が固定費化しているのである。 また縦割り組織のため不意の出費に他部門の予算を分捕って 来るような力技は、まずあり得ない。全てそのような事態 では臨時増額にならざるを得ないのである。なぜなら 他部門も自らの予算を年度中に自ら使用しない限り、 来年の予算査定で削減されるため、他部門のゴリ押し？に 断じて屈する訳にはいかないから…。 従って「有能な」市担当職員ほど業者に顔が効き、融通を 図りながら予算配分額を上まわらないよう、かつ「決して」 下まわらないように調整するのである。予算と人員こそ、 役所におけるその部門の力の源泉である。 この種担当者の有能さ？は極めて人間的なものである。 また所属する部門の上司や同僚、部下を含めてその能力を 高く評価する。このような文化制度的環境で育った人々が 透明性の高い発注・検収形態を望むであろうか。 長い付き合いで顔が効くという能力を生かせるのか。 もっと言えば透明性と効率性の高い発注形態は官公庁に おける個人の「人格的代替不能性」をある意味失わせるもの であるかもしれない。 前回２．項のITジェネコンをその仕事振りから分析して みよう。 前述の通り土木建築ジェネコンと同様システム業界も、 深い階層的下請け構造をもっている。上部組織ほど付加 価値の高い仕事を行い、下層にゆくほど労働集約的な 仕事をやることになっている。（丸投げが付加価値の 高い仕事かどうかは別にして…） さて、これまでのところ本来は数十万円の仕事が数百万円の 仕事に仮装されているという前提で話を進めてきた。 が、本当に数百万円の仕事になっている可能性はないのか？ これまで市側との折衝などを含め表面ではITジェネコンが 表に立っている。ところが実は内部では下請けが様々に 組み合わされて仕事がやられるケースがほとんど であろう。 つまりITジェネコン直下の一時下請けまでは、ITジェネコン の名刺をもって官庁側に接触することもあるだろうが、 さらにその下となると闇の中である。 これまでの度重なる改修コーディング作業がどのように 行われてきたかはユーザーの全く分からぬ世界となる。 業界では常識的な手法となっているが、本体のプログラムを 改修せずにパッチ当てと称してアウトプット（ユーザーに 見える部分）の直前のコードだけをいじくることで、 いかにも全体ロジックを改修したように見せ掛ける テクニックがある。 しかしながら、これを続けてゆくとあちこち矛盾が噴出する 可能性がある。つまり基礎とは矛盾したものを表面に貼り 付けるだけだからして、それが多層的になると全体動作の 安定が保てないのである。 いわば若いうちに美容整形をやり過ぎた女性が老けたら どうなるか？ 改修作業を同じ下請けではなく違う下請けが次々と勝手に やるとどうなるのか。（美容整形の医者がコロコロ変わる イメージである。） どこかの時点で基礎から立て直さないとシステム自体が 成り立たないのは自明であろう。 （美容整形の再構築があるのかどうか？筆者は知らない･･･） これはあくまで仮定であるが、大幅再構築を今回の住所や 基準年齢の一部変更にかこつけてやった可能性はないのか。 大幅改修であるから当然、システム本体のテストや関連 システムとのインターフェース調整も必要となる。 ５百万円の改修作業２回分でトントンの収支となる 次第である。 このように自治体担当部署に所属する人々と協力（結託？） しつつ、あらゆるシステム改修の過程で辻褄あわせを やりながら、ITジェネコンと下請けが構成する「共同体」に 所属する人々の安定した雇用と賃金が保証されるのである。 前回から提起している問題の本質を俯瞰的に眺めると どうも不思議な現象が浮かび上がってくる。 お分かりの通り、役所とITジェネコンの関係は別に 役所と土木ジェネコンの関係と入れ替えてもそのまま 成立する。まさにありふれた役所と業者の関係と同じである。 持ちつ持たれつ一朝事あればお互いに団結して事に当たる だけの人間的繋がりが形成されているとも言えるが、要は 互いの非効率の上に雇用と賃金が保証されている 仕組みである。。 つまりは徴収した税金の再配分である。累進課税の 勾配分だけ、高所得層から低所得層に「仕事」を達成した という満足感とともに所得が再配分される。 このような日本における社会福祉的な政策の一環と なっていることは周知の事実であろう。 結局そのつけは国債となって未来世代に先送りされて いるが、事の本質は実にシンプルではある。 だが、IT推進という効率化、省力化を旨とする分野に おいても同じ状況を生み出しているというパラドックス自体 実に不思議なことではなかろうか。 日本全体のITによる競争力の強化を雇用と生活の安定が 足を引っ張っている。 俯瞰的に見ればそういう構図である。 話をNHKのクローズアップ現代に戻そう。 国谷アナウンサーは一方的に役所と業者の癒着を非難して、 韓国のITベンダーにソフトを発注した佐賀市を高く評価 している。また、長崎県の自力仕様書作成と発注方式を 推奨しているように感じた。 その視点から漏れているのは何か？ 業務全体の非効率性に安住し、これまでその仕組みの中で 「彼らなりに努力して」きた人々の雇用と賃金の問題では なかろうか。 社会保険庁での問題も根は同じである。 システムの再構築、効率化に抵抗する勢力の想いは 共通している。 我々の仕事はどうなるのか？ これまでの仕事のノウハウは無駄になるのか？ 人間的な接触による人脈はどうなるのか？ 何よりもこのような非効率性に安住せざるを得ない 人間としての「能力格差」を「知的格差」を一体 どうしようというのか？ 筆者は、「だから現状のままで良い」と主張している訳では 決してない。 まして、官民癒着や税金の無駄遣い構造を温存すべきだと 言っている訳ではない。 そうではなくて、問題を解決するには、もっと問題を煮詰めた 形で明るみに出し、その構造の中で人脈や経験に有能感を もって働く人々、生計を立てている人々が存在することを 忘れてはならないということである。 もっと端的に言えば「システム化、合理化によって必然的に 生み出される余剰人員をどうするつもりか？」 これに対する具体的な処方箋のないシステムについての 議論は、現代において既に意味を喪失しているのでは ないかと。 以上 目次へ
さて、このシステム開発シリーズも７回目を迎えた。 これまではシステムを作る側なり、予算を計上して システムを導入する側の実情について検討してきた。 その中ではいかに、実際に出来上がったシステムを 利用する側からの、即ち「現場の視点が不在」である ことが良くお分かりになったことであろう。 ユーザーとひとくくりに言っても経営トップやシステム 部門などは、自らの立場や利害に汲々として、現場で それを利用する人々の実情に対する関心は極めて薄い。 トップによっては、開発されたシステムで 「何人？人が減るのか？」 しか関心がないと豪語する人も…。 開発ベンダー側も意識するにしろ、しないにしろ、現場の ユーザーをシステム開発サイクルを構成するための人的な 材料と捉えているのではなかろうか。システムにどのように ユーザーを組み込み、動かし、効率化するのか、生産性を 上げるのか。 現場から少々不満があっても、システムを不承不承でも 使ってくれさえすれば、関心はユーザーの経営トップや システムの検収部門であるシステム部門における評価の 方が、収益を確保するためには、はるかに重要な意味を 持つ。 つまりシステム自体の利用状況よりも、開発・改修 プロセスをいかに効率的に回すかが、開発ベンダー側の 最大の関心事となっている。 これは極論になるかも知れないが、本シリーズ第２回で 述べた： >例えば５人のメンバーが「この土地に穴を掘れ」という >指示を受ける。メンバーはせっせ、せっせと穴を掘った。 >途端に「今掘った穴を埋めろ」という指示を受ける。 >ぶつぶつ言いながらもメンバーは穴を埋める。 >この掘ったり埋め戻したりの作業を３回繰り返した >ところで、このプロジェクトは終了した… このような状況が下請け企業の末端で発生しようが しまいが、開発・改修プロセスさえ、収益性を 持って回転していれば、「実害」は全くないのである。 さらに極論を進めてみよう。 稼働中のシステムのトラブルやシステム開発が途中で頓挫 する話は枚挙のいとまもない。 「日経コンピュータ」の特集では、開発案件中の16〜19％ 程度しか品質も納期も満足するプロジェクトはないと、 同誌のアンケート調査で報告されている。これだけ低い 結果でもアンケート先はユーザーのシステム部門だった。 現場のユーザーに直接アンケートをとっていたとしたら、 どのような結果が出ていたか想像するだに冷や汗が出る。 なお開発されたシステム案件のほぼ2割が一年以内に お蔵入りで稼動していない、との報告もある。 開発費用は５年償却だから、会計上残額は特別損失に計上 されることになる。がしかし、ほとんどのシステムは 実際に使用されてなくても、システム部門の面子にかけて 当該システムは稼働中とカウントされ、損失計上だけは 是が非でも避けたいところであろうが… 何故？システムトラブルが多発し、システム開発がうまく いかないか、原因を究明したり、対策を提案する書籍、 専門誌には事欠かない。 さてここで、現場のユーザーや一般の人々は蚊帳の外から、 迷惑を受けながらも「大変だなぁ。」との印象を絶え間なく 「与えられ続けている」ことは事実である。 システムの開発やシステムの復旧に直接携わっている 当事者は「実際に」大変な思いをしていることは 間違いない。 がしかし、より大切なことは社会の多くの人々が 「システムはトラブリ易く、開発は困難なものである」と いう、社会的信念体系を共有するところにある。 システムはトラブリ易いというイメージは、トラブルが発生 しないようにシステムをさらに複雑化する駆動力となる。 つまり際限なくトラブル防止用のプログラムが付加される ことにより、ますますエラーが発生する確率を高める。 東証で誤発注が生じた際に、ポップアップでその取引に 問題があることをシステムが入力した担当者に知らせていた。 それにも関わらず、担当者はその警告を無視して誤発注して いたことをご記憶の読者もあろう。 このような「人為」ミスが発生しないようにシステムを 改修すべきだ、との意見がメディア上で散見された… では、そもそも人為とは何か？ 人為に従わないシステムとは何か？ そんな疑問とは一切関係なく、開発ベンダーはただひたすら システム修正を繰り返し、システムをますます複雑化して いるのである。 はっきり言ってしまえば、自分のところじゃ困るが、 どこか他のベンダーがシステムトラブルを起こして 問題になってくれた方が、ベンダーにとっては 「有り難い」のである。他所で動かないシステムを 作ってくれればくれるほど、お客が高額な開発見積りを 丸呑みしてくれる可能性は大きくなる。稼働中のシステム トラブルが増えれば増えるほど（人為的なミスかどうかは 別にして）システム改修用の下請けプログラマーの 人工単価を高く維持出来るのである。 オフショアなんかでトラブル無しにシステムが安く出来て しまったら、最も困るのはITベンダーである。 システム開発の特効薬を「銀の弾丸」という。 業界では当然、「銀の弾丸なんて存在しない。」という 信念体系が「確固として」存在している。 変な話だが、システム業界において、システム・トラブルや 開発におけるデスマーチは「有効需要」を高く維持するため の「必要悪」となっている「側面も」あるのではなかろうか？ 以上 目次へ
前回の分析で、稼働中のシステム・トラブルやシステム開発 作業中における問題の多発及び開発自体の頓挫という表面的 にはシステム開発ビジネスに対するマイナスイメージに なるようなものが、逆に開発サイクルという収益構造を 回転させるためのイナーシャーとなっていることについて 検証した。 日経コンピュータ誌の「動かないコンピュータ」特集 がコンピュータビジネスを下支えしているという逆説的な 結果を生み出している。（業界専門誌としては当然か…） 東証におけるシステムトラブルしかり、銀行合併時の ATMトラブルも同じである。勿論これらの記事の内容や 事象は誇張でもフェイクでもなく、厳然たる事実である。 その具体的な事実性こそが、確固とした社会的信念体系を 形成する。 このような状況を改善すること、システムを複雑化させる ことが、新たな障害の可能性を高めつつ、ビジネスの チャンスを広げ、開発サイクルを回転させる。 今やシステムの耐久性や信頼性（お客に対するプレゼンに おいてのみ辛うじて余命を維持はしている…）が開発側に とって、もはや重要ではなく、どうすれば、早く技術的に 陳腐化させ、再構築需要を起こさせるかが主要な関心事と ならざるを得ない。 いかに、システムを「消費財化」するか、「一過性の危脆な もの」にするか、「最新の企業ファッション化」するか？ さて、筆者はこれまで色々とシステム開発に対して批判 めいたことを書いているようだが、それは決して本意では ない。 そうではなくて、システム開発によって雇用を維持 している人々の側からは見えにくい部分を、見えても 意識したく無い部分をエスノメソドロジー的（地誌学） な手法を使い具体的に、かつ俯瞰的に浮かび上がらせる ことによって、つまりポジ側ではなく、ネガ側から光を 当てることによって、より立体的にシステム開発という ものを捉えたいと考えているのである。 ITベンダーの収益性やビジネスに貢献するか、どうかは 別にして、これまで様々な立場から開発に携わってきた ものの一人として、部外者の方々にも納得のゆく形で、 今日的な意味でのシステム開発に対する視座を構築したい と思っているのである。 ここまでの検討結果から、開発ベンダーやユーザーの経営 トップ、ユーザーのシステム部門、官公庁のシステム担当 部門においては、既にシステムそのものの利用価値は 見失われつつあり、オートポイエーシス的（自動組織的）な 開発サイクルが自己目的的に、その「貨幣的交換価値」を 生み出し続けていること、またそのサイクルの中でそれに 携わる膨大な人々が様々な形で利害相反を含みながらも、 それぞれの生計を維持していることが、お分かりになった ことと思う。 次回はいよいよ、システムを現場で利用するユーザー （受益者…被害者？）の立場より、システムそのものの 本質に迫りたいと考えている。 少しだけ、ご期待下さい。 以上 目次へ
空き巣が増えれば、錠前屋が儲かり、コンピュータ ウイルスが増えれば、ウイルス防止ソフトが売れ、台風や 地震災害があれば土建屋が儲かる、戦争の危険性が 高まれば防衛予算が潤沢になりー＞軍需関連産業が儲かる。 etc.etc･･･ 不幸な事態や人々が不安に感じることが有効需要の 原因になることは、よく知られたケインズ流近代経済学の 原理である。 だが、良く見ればお分かりの通り、上記の不幸な事態や 不安要因はそれによって潤う産業の外部からやってくる。 （もっとも、ウィルス防止ソフト会社の全企業努力を 集中した、専門家のノウハウが、次々と全く無関係な 素人ハッカーに易々と破られるってのは…ノウハウが 漏洩しているのではと疑われても無理のないところでは あると、「素人的」には思う。） しかしながら、前回解説したシステム・トラブルの多発や システム開発の困難さは、まさにシステム開発産業自体の 問題である。 筆者は決して、意図的に発生させていると主張している 訳では決してない。ただ、産業内部で発生する問題が 人々の社会的信念体系まで形成し、それが開発サイクル を回転する駆動力になっている点を指摘しているだけで ある。 ここで、システム開発によって生計を立てている人々、 （開発ベンダーだけではなく、ユーザーシステム部門や 予算担当部門の人々）は、上記開発サイクルの回転自体に 依存している。 では、実際に現場のユーザーから見たシステムとは？ ここでは、原子力発電所の制御システムや航空管制 システム、JRの信号スピード制御システムなど人命に 直結するクリティカルなシステムは除外する。 これまで主に検討してきた所謂「業務システム」に焦点を 当てたい。 東証の取引が止まろうが、銀行のATMが誤作動しようが a)人命にかかわることはない。 b)状況の回復は、時間の長短はあれ、可能である。 c)即ち某銀行頭取がいみじくも国会で発言されたように トラブルが発生しても「不便だが実害」はない。 このような「業務システム」を対象とする。 ところで、以前良く見かけた光景ではあるが、深夜ビール などの自動販売機の前で、酔っ払いが意味不明なことを 喚きながら、販売機を蹴っていたことがあった。 （あくまでも一人の酔っ払いであり、性別は…） 「ガンガン、ガンガン、ガンガン」 「この野郎ぉ！」「ビール出せぇ！」 「ガンガン、ガンガン、ガンガン…本人が疲れ果てて その場で眠ってしまうか、はっと正気に戻るまで ガンガンガンは続く…だれもあえてそれを止める人は いなかったが… かってのビールの自動販売機が本来ここで対象とすべき 「業務システム」かどうかは置いておく。（人命に影響は 与えないか…？） むしろ、ガンガンガンガンガン･･･の絶え間なくいつまでも 続いたヒールの響きが、現代のシステムユーザー全体の 心情を、その孤独感とやるせない絶望感を、象徴していた ように思えたので取り上げた次第である。 業務システムのユーザーで操作中にそのシステムを ぶっ壊したい！という強い衝動が湧き上がった経験のない人 って、はたして存在するのだろうか？ 開発側のプログラマーでさえ、その衝動を抑えるのに苦労 している人もいるぐらいだから、ましてシステムに制御 されていると感じる度合いの強いユーザーにおいてをや？ システムとは最もシンプルに定義すれば、情報をデジタル化 して取り込み、蓄積して、ユーザーが利用し易い形に内部加工 し、アウトプットするものである。 けれども、システム自体は無形である。自動販売機はハード に組み込まれているため有形であるが、ビールを出すかどうか の「判断」は無形のソフトウェア、もっと言えばソースコード をコンパイルしたデジタル信号が行っている。 さらに、このデジタル信号自体は不滅である。不変である。 シンボル自体だからである。 いったん決定したビールを出さない判断は決して覆らない。 泣こうが喚こうが蹴ろうがぶっ飛ばそうが（箱物が壊れて ビールが出てくることはあるかも知れないが･･･） システム的には決してその判断を変更することはない。 すなわち、ここで筆者が述べたいことはシステムは確かに データの貯蔵、検索、加工、など現代では不可欠な利便性と 作業速度を提供してくれる。 一方、組織内で業務システムを使用するユーザーにとって それは下記のような印象を与えているのである。 a)システムは組織内でユーザーが従うべき法的主体として 現前する。社内マニュアルやBRなどは言うに及ばず、 実定法上の手続きやその実施要綱などが、システムには 全て組み込まれて開発されている。ユーザーは組織に所属 する限り、眼前のシステムからの逸脱や逃亡は許されない。 b)システムが開発されるサイクルにおいても貫徹している リズム、それに参加する人間全てが同期をとって収益 サイクルを回転させるリズム、これは当然開発される業務 システムにも継承されている。より拡大され、より強固に。 つまり当該業務を効率的に合理的に回転させるメカニカルな リズムを強化する働きを持たないシステムは、業務システム としての存在意義を失うのである。 このリズムこそ、ユーザーがシステムを使用しているという 支配感よりも、逆にユーザーがそのリズムのなかに必然的に 巻き込まれているような被支配感を覚える原因になっている。 c)業務システムはもはや職場における環境の一部となって おり、それがない限り業務は進まないほど、ユーザーは システムに依存しているのである。a)項で述べた実定法上の 条文を知らなくても、商法や会社法を知らなくても業務は システムに従って進行するのである。要するにユーザーが システムに依存すればするほど、「頭脳負荷は軽減」できるが 同時それは「知的空洞化」を招く。家畜化した行動しかとり 得ないように「飼育されている」と言っても、過言ではない。 これらの意見は確かに厳しすぎるように思う読者がおられる かも知れない。 けれども、たとえば現在あちらこちらの企業で進められて いる日本版SOX法のシステム開発状況を眺めてみよう。 ご承知の通り企業内統制（SOX)システムは企業内や企業間で 従業員や社外関係者が不正を行うのを防ぐために構築するもの である。しかし、ここまで人間不信を徹底したチェックと 監視が必要なのか？と疑問を感じ、絶望的な気分に陥った方は おられないのだろうか？ 以前にも述べたが「人為」というもの、その結果に対する 「責任」までシステムに奪われた人間は、果たして 人間なのか？ 以上 目次へ
これまで本シリーズの検討においては、 １)システム開発ベンダー 営業部隊 ２)同上 開発部隊 ３)同上 保守運用部隊 ４)ユーザー 経営トップ ５)同上 システム部門 ６)同上 予算担当部門（官庁） ７)同上 現場のユーザー とシステム開発に携わる関係者を分類し、それぞれの 社会心理学的な本音部分について分析してみた。 さて、これまで話題にならなかったシステム開発 ベンダー側の経営トップはどう現在の事態を把握し、 何を考えているのか？ 最近の業界紙や専門誌上で、ベンダートップはお客との コミュニケーションを重視する姿勢を特に強く打ち 出している。例えばSOA（サービス・オリエンティッド 手法）と称して客先の業務形態をモデリングツールなどを 使用して分析することなどがその一つの方法である。注１） お客とのコミュニケーション重視は、システムの目的が 客先の人々の働き方や組織を合理化、効率化することに あるため、以前から開発側で言われて続けてきた。 「いかにお客を開発に巻き込むか？」は今も昔もシステム 開発の成否を握る鍵である。 ちなみに「無責任、無理解、無茶な、お客のお陰で、酷い 目に合いました。」というなんとも、真実味？溢れる、 無責任な？エクスキューズがシステム開発失敗時には、 開発側で頻繁に囁かれたものではあるが…今も昔も。 ただ、ここに来て業界では言い古された方針「お客との コミュニケーション重視」が、あらためて開発ベンダーの トップから打ち出される理由はなんであろうか？ a)これまでの「私共に全ておまかせ下さい。」方式の 効力が失われてきた。ITベンダーの提案するビジネス・ ソリューションの限界が露呈してきたのである。 アメリカ式経営手法の焼き直しに過ぎないソリューションは 必然的に画一化したものにならざるを得ず、顧客企業の マネジメント能力の競争力強化に繋がらなくなった。 高いシステム開発費を支払っても同業他社との差異化が 図れなくなったのである。ITベンダーが喧伝する 世界の「ベスト」プラクティスも各々の企業が採用すれば それは凡庸なものに堕してしまう。 マネジメント能力がそこまで成熟していていない企業には それなりの価値があるかもしれない。けれども、中小企業 などでは、経営者がシステムなどなくても日々全体状況を 把握し適宜、経営判断を実行する方が、大掛かりな システムを導入するよりはるかに経営効率は高い。 またその能力のない経営者は、中小企業では生き残れない。 b)各々の企業における実態を調査し、市場の状況を加味した 当該企業内部からの提案を盛り込んだシステムでないと、 同業他社と比較してのマネジメント競争力差異を生み 出せない。すなわち、各々の企業状況に応じたビジネス 形態の変革をシステム化するという基本に戻ったという ことであろう。 こういったベンダー側経営トップの方針に問題はないのか？ 以下で検証してみる。 A)ユーザーとのコミュニケーションといっても上記で 分類したように、経営トップ、システム部門、予算担当、 現場のユーザーと立場がそれぞれ違い、これまでの 本シリーズ分析でもお分かりの通り利害も相反している。 各々の立場からの意見を一本に取り纏めることは、率直に 申し上げて、ユーザー経営トップでも至難の技なので ある。（逆に言えばユーザー経営トップもこれまで変革に 伴う憎まれ役をシステム部門や開発ベンダーに丸投げして いたとも解釈できる。） B)もし、A)のプロセスが上手くいって、ユーザーの斬新な ビジネス形態の変革案が纏まったとする。だがこれまで パターン化したフレームワークやテンプレートの使い回し ばかりしていたベンダーの開発部隊がそれをシステム化 出来るのか？という問題が残る。 具体的には、プロジェクトマネージャーは（予算枠と納期の 圧力を、全身で受け止めながら）、お客から要望される 斬新なアイデアを、これまで自分が開発経験のある陳腐な パターンに、なんとか押し込みたいという、PMとしての 「本能」とも言うべき欲望を統御できるのか？ あるいは、PMの立場を維持するために必要不可欠な？その本能 まで抑制した場合に、現状の開発部隊が抱えるメンバーの能力を もってして、そのような斬新なシステムを無事完成させる 「自信が」彼の心中に生まれる余地があるのか？ C)かって、開発ベンダーがお客を集めて開催したビジネス・ ソリューションセミナーのプレゼンテーション終了後、 質疑応答時のことである。 「御社において、今説明のあった、そのビジネス・ ソリューション・システムは、どれだけ効果を発揮して いるのでしょうか？」 と、セミナーの出席者の一人から質問があった。 このような質問を開発ベンダーは受け付けられない。 応えられないのである。 なぜなら、開発ベンダー内部のマネジメント状況は 「一般的には」ユーザー内部よりはるかに低レベルなので ある。（関係会社や下請け業者管理を含めて、社内の コミュニケーションはガタガタ…）マネジメント面において、 ユーザーより能力的に高いと思われるのはプレゼンテーション 能力（パワポの作成・操作）「だけ」ではなかろうか？ ビジネス・ソリューション・システムなど客先には 勧められても、社内では「夢のまた夢」であるような 開発ベンダーが、お客と斬新なビジネス上のアイデアに関して 実のあるコミュニケーションが出来るとは、 とても思えないが… 以上A)、B)、C)の問題点を考慮すれば、開発ベンダートップの 「お客とのコミュニケーション重視」のスローガンも絵に描いた 餅に終わりそうな予感がしませんか？ （SOAモデリングツールでRFPを可視化すれば、確かに 絵にはなる…） 以上 注１）SOA(Service-Oriented Architecture)： ビジネスプロセスの構成単位に合わせて構築・整理された ソフトウェア部品や機能を、ネットワーク上に公開し、 これらを相互に連携させることにより、柔軟なエンター プライズ・システム、企業間ビジネスプロセス実行 システムを構築しようというシステムアーキテクチャのこと。 注２）RFP(Request For Proposal): 情報システムを導入するに当たって、ユーザが納入を 希望するベンダに提供する、導入システムの概要や調達 条件を記述した文書。 [IT用語辞典よりーご参考] 目次へ
先生、警官、宗教関係者の忘年会は、最も乱れが激しい。 これは飲み屋や料亭、旅館の仲居さん達の常識である。 普段の行動を規制されている人々程、心中密かに鬱屈した ものを溜め込むものだ。 日本版SOX法や社内統制システムなどは、特に組織内外で 働く人々の行動を監視し、不正を「未然に」防止する目的 で開発される。「未然に」とは不正を働く前にシステムは 対策を実施するという意味である。不正が実際に発生すれば システム的には失敗であり、システム的な不具合であると 判断される。 「特定の業者に発注が集中していないか？」 「出張精算は正しく行われているか？」 などなど、想定できるあらゆる不正の温床をシステム的に 「未然に」チェックすることになる。 システム・ユーザーの被監視感、被統制感はいやがおうにも 高まる。さらに、一般ユーザーにはシステムがチェックして いる内容は知らされない。（「泥棒」に監視カメラの配置を 教えるようなものだ、…との思想のもとに） 従ってユーザーは「未然に仮想不正行為者」と見做されて いるのである。 仮想不正行為者であるユーザーは、真性不正行為者と認定 されないために、システムが実際にはチェックして いない項目にも配慮する必要がある。痛くもない腹を 探られないようにしなければならない。 システムのチェック項目が７個であれば、少なくとも １０個には注意を払う必要があろう。（その１０個には、 チェック項目である７個が必ず含まれているとは 限らないが…） 一般的に企業で不正を働く真性不正行為者の人数は 仮想不正行為者（一般従業員）よりは圧倒的に少ない。 （社会保険庁は…?） その圧倒的に多い人間が業務以外の「不要な注意力」を 常に強いられる構造になってしまう。 例えば、 「貴女は、昨日もこの業者を使用しましたねぇ？ 特にリベートなど、もらってないでしょうねぇ？ まさか、オトコがその業者に居たりなどしてないよねぇ？」 とか。 いや、これは極めてプリミティブな防止策ではあるが、 こんなポップアップメニューが注文書入力時、ヌーッと 画面上に立ち上がったりしたら、どう？ おまけに、禿げて脂ぎった上司の顔写真付きで… これ程、極端な例は無いとは思うが、社内統制システム 稼働中におけるユーザーのストレスは、常時相当なもの であることは間違いない。 この鬱屈したものが、先生、警官、坊主のように忘年会 「程度で単純に」解消されれば良いが… 費用対効果の意味でも企業にとってメリットはあるのか？ さらに本質的にモラルの問題を掘り下げて見よう。 常に監視されている状態に慣れてくると、以前紹介した 東証における株の誤発注のようにポップアップメニュー警告を 無視するようになる。制度そのものの権威と信頼性を損なう 結果となる。 また、監視状態が解除されていたり、監視されてない項目を ユーザーが見つけてしまったりすると、規制が強ければ強いほど 不正への誘惑を抑制することが困難になる。サーカスで電気鞭 によって他律的に規制され続けてきた動物が、それがはずれた とたん暴れだすことと、同じ現象を生じるのではないかと 筆者は危惧している。 システムによって真性不正行為者を「密かに、育成している」 という逆説的なことになるのではないか。 ばれなければ、何をしても良いという風潮を助長する結果に なりはしないか。 本来、昔から人間の言動はその場限りであり、物質的に 記録されないのが普通であった。 人間は自らの記憶に対して、その記憶を他者と共有する ことで世界のなかで自らと人に対して誓約し、それを履行 してきた訳である。 常に監視され記録されることによって、システムの向こうに 他者がいることは想定できても、世界の中で「自らとの誓約」 を失いつつあるのではないだろうか。 昨今、生じているモラルハザードの原因の一つとして システムに依存し過ぎて、人間としての尊厳の根拠である 「自らとの誓約」を忘れ、「自らに対する責任」を 放棄するようなことが起こりつつあるような気がして ならない。 モラルは確かに歴史・文化・制度・社会的な産物であり 個々人によって様々であることは当然である。 しかしながら、人為とは決断であり、一回性の不可逆なもの であるならば、その指針であるモラルをシステムに依存 することは、人為の崩壊に繋がるものであると筆者は 信ずる。 この世界に共に生きる人々が、先人の知恵に学び、将来の 世代を想いつつ、自らの人為によりモラルを維持し、 構築し続ける以外に他に方法があるとは、 とても思えないのである。 以上 目次へ
「自分達が使うシステムだろうがぁ、やる気あんのか？」 システム開発プロジェクトにユーザーの業務代表として、 選任されたメンバーに対して、このように感じなかった 開発側のメンバーが、未だかって存在するのだろうか？ 「物事が決まらない、ユーザーの意見を纏められない、 無責任に前言を翻す、なんでも開発側に押し付ける。」 「なんでユーザーの部門間の仕事の調整まで開発側が やらなければ、ならないのか！」 「鮪で言えばトロだ。あるのは高級魚？のプライドだけ。 お客気取りでドテェ〜として動きがトロい！」 このようなユーザー代表に対する様々な憤懣が、開発側の メンバーのなかで渦巻いているのが実情であろう。 筆者も若い頃は、（今でも結構、幼稚だが…）よく、こんな 不満を抱いたものであった。 最近、これが「組織心理学的な構造要因」によるものだと ようやく気が付いた。 まず、開発側のメンバーが何故？「若い頃」に、このような 不満を感じることが多いのか、を検証してみよう。 １．よく言われるように若い頃は希望に燃え、使命感や 感受性が高いゆえに不満を感じることが多い、のではない。 そうではなくて、若いから経験も少ないため「それなりの 予算のプロジェクトを担当させられること」が多い からである。開発側の会社から、若い連中は「トロい」 ばかりの単なる見習いとしか、評価されていないだけ なのである。根も葉もない言い方をすれば、開発側のトロと ユーザー側のトロとが「互いに不満を」抱きあいながら やりあっている構図か？ ２．開発側でも優秀なメンバーは極めて少ない。 経験を積んでもトロいのはトロのままが多いからである。 この原因については、胸に手を当ててよ〜くっ反省すれば 分かる話なので、また本人がどうこう出来ることでもない ので、…ここでは、取り上げない。 （筆者も自分自身、反省する「振り」だけは時々…） 従って自分は既に若くなくて、未だに上記のような不満を 感じる開発側のメンバーは早めに転職を考えたほうが良い、 かも知れない。それとも、ひたすら大トロ同士の責任の押し 付け合いに耐え続けるか… では、高額で受注したシステム開発プロジェクトを 担当する、ユーザー業務代表は優秀なのか？ 実は、トロいまま… 今回は「このトロ」の拠って来る原因を究明してみる。 そこで具体例として、営業日報をシステムに取り込み、 ナレッジマネジメントやデータマイニング手法を利用して 効率的な営業を展開しようという、「よくある、又は、 あったシステム」の開発における実情を想定してみる。 このケースでは、システム開発における業務担当に なるのは、ユーザーの営業部の人間となる。 A. 開発ベンダーの強引かつ巧みな売り込みに乗って …（受注額の何パーセントがキックバックになって ユーザーに還流しているかどうか、顧客の誰が、海外 セミナーに招待するという名目でのベンダーが費用丸抱え の海外旅行に「釣られるか」、なんてことについては、 一切筆者の関知しない部分である。）… システム部門からの極めて功利的なアドヴァイスを基に、 経営トップから無責任に言われてやむを得ず、システムを 開発する主体は営業本部が名目的になることが多い。 そこで実際に人を出すのは営業の実務部隊となる。 読者の皆さんが営業部長だとしたら、どのような人材を システム開発プロジェクトにメンバーとして出すだろうか？ 売り上げ目標に追われ続け、ただでさえ人手の足りない 営業部長が、たとえ一時期プロジェクト専従にならなくても 優秀な人材の手を本業以外に「煩わせる」ことを敢えてする だろうか？ 居ても居なくても分からないような「無難」な人材を それでも「シブシブ」出すことになるのではないか。 「優秀な」営業部長は常に「無難」な人材を「シブシブ」 選んで送り出す。その心は： a) シブシブ出すことで、その人材をあたかも優秀に 見せかけるのである。 b) 出された本人も惜しまれながら送り出される方が、 居なくなってせいせいすると喜んで送り出される よりは士気が高まる。トロい人間ほど自分は優秀である と「錯覚している」人間が多い。開発側としては この錯覚が一番迷惑なのではあるが･･･ c) これが最も大事なところだが、営業部長の上司 (営業本部長？）に対して、シブシブ、プロジェクトに 人を割くことで自分の職場は多忙だと印象づけることが できる。本部長にあそこは暇だと思われたら即、次の 人事異動で人を減らされるからである。さらにはこの システム開発プロジェクトに人を取られなくて済む、 他の営業部長に「貸し」を作ることが出来る。 なぜなら営業部長レベルともなれば、ほとんど全ての 部長が、こんなシステムを作っても何の役にも立たない ことを、これまでの経験で知り抜いている。謂わば、 人身御供を出すことを、逃れられたこと。つまり当該 営業部長がそれを負ってくれたことに「暗黙の借り」を 負うことになるのである。（基本的に会社の組織は この「暗黙の貸し借り」で動いており、無視すればたちまち 組織から放り出されるのである…） d) 最後に、いくら「無難」な人材であっても、忙しい 時には「猫の手」より、まだましだからシブシブ… トップへのゴマすりに目がくらんで、喜んでプロジェクトに 優秀な人材を送り出すようでは、その営業部長の先は 見えている。 その一方で、優秀な営業部長にその部下が、 「これからはシステムの時代だ。一つここは君の将来の ための勉強と思ってプロジェクトに参加してくれ。」 と言われたら、その職場での彼の先も見えているが… それが証拠にシステム開発プロジェクトに送り込まれた 営業の人材でその後、華々しい活躍をした人間をどなたか ご存知であろうか？ かようにして、先の見えた無難な人材（大トロ）がユーザー 業務代表として送り込まれてくることになるのである。 B. もし、営業の実務部隊が「猫の手」も出せない状況 であればどうなるか？ 勇気凛々、やる気満々、システムコンサルやプログラマー が使用するような業界用語を使いまくりながら 「うちの営業の連中はコンピュータリテラシーなんて からっきしでしてね。勘と度胸と根性しか取り得のないの が多いですから。このあたりで一つ最新のナレッジ・ マネジメント・システムを導入してうちの経営陣がリアルに 営業情報を入手し、経営判断のスピードを上げるように しないと、同業他社に遅れるばかりですよぉ。」 なんてシステム企画書を丸写ししたかのようなご託宣を 滔々と述べる、コンピュータオタクっぽい人が紛れ込んで きたりする。 若いうちはこんな「やる気のありそうな」ユーザーと 意気投合しやすい。が、実はこれが危ない。 大体この手の人は営業企画部とか業務部とか、本流の営業 部隊から外れて、人より一寸だけ詳しいエクセルやアクセス を操作しながら営業統計資料などを社内で細々と作って いることが多い。このタイプは営業の本流から外れている 僻み意識が極めて強い。だからこそ？ワイドショウに 出てくる無責任な評論家のように大所高所からの意見が 大好きで、大言壮語を繰り返すが実際の仕事には、まったく 役に立たないのである。 こんなユーザーを信用して出来上がるシステムは、大量の 営業マンが日々大量のデータを極めて細かく分類して 入力したあげく、成果はこれまでと同じような統計資料の アウトプットでしかない、なんてことになりかねない。 いや、なりかねないではなく、まずそうなる。なぜなら、 この手の人は統計資料の作り方しか知らないからである。 システムがせっかく完成しても営業部隊はだれもそれを 使うことなく、即刻お蔵入りの可能性が最も高いのが、 このB系ユーザーが主導したシステム開発である。 （これで開発費を払ってもらえるなら、データを集積して 統計資料を作るのは一番簡単なシステム「エクセルや アクセスでもって、これまでB系ユーザーが一人でやって 来たこと」だからして、開発側としては確かにボロい 商売ではあるが･･･） C. A系無難派もB系オタク派も大トロなら、最後の望みは ユーザーシステム部門しかない。かってはたしかに システム開発で主導的な役割を果たし、結構ユーザーの 業務にも詳しい担当者もユーザーシステム部門には存在した。 しかしながら、以前にも本シリーズで述べたこともあるが アウトソーシング化と子会社化で、そんな連中も チリヂリ、バラバラとなってしまっている。残っているのは 年寄りだらけの管理職が集まった名前だけの企画部隊のみ。 目的は、いかに自分ところのシステム子会社の売上げを 伸ばすか？ 開発ベンダーからいかにピンハネ（アイデアも含めて） するか？ それぐらいしかこの連中の頭にはない。 刺身のツマ程度か… 開発側としては、A系の「無難」派でとりあえず我慢すべき であり、B系の変に「やる気」のあるユーザーは警戒し、 C系のシステム部門には、システムの完成検収時以外には 出来るだけ近寄らないのが「無難」ではなかろうか？ 本稿の結論としては、かなり高い確度で上記A,B,Cで 分析したユーザーの状況は、今後も変わらないと 筆者は思う。 いや、その無責任傾向はますます顕著になってこよう。 何故か？ 筆者は以前、1970年代から80年代のホスト全盛時代に 顧客が作成したシステム仕様書を、偶々書庫にあった 古いダンボールの中から見つけ出したことがある。 全体構想から、個々の業務分析、システム要件、ユーザー 教育マニュアル（業務用とシステム用）と一点の非の 打ち所もないものが、「ボールペンで1000ページ余り」。 その綿密で周到な調査と検討内容には、圧倒される 思いであった。 最近の企画仕様書で見かける横文字の美辞麗句は一切ない。 全て構造的に、大きな項目から詳細へ、具体的に、システム を作り上げる目的に集中して書かれてあった。ボールペンで 書かれた文字は決して美しくはないが、誤字はなく、 理路整然、何回も推敲され清書されたものであることは、 明々白々である。 その文字の向こうにあるシステム構築に対する熱意が脈々と 伝わってきて、鳥肌の立つ思いであったことを記憶している。 我々は既に、こんな時代を過ぎてしまったのである。 システムに対してこんな熱意と情熱があるユーザーはもう 存在しない時代に生きている。 コンピュータがあらゆる職場に入り込めば込むほど、 システムは簡便化し、ユーザーをコントロールするように なり、逆にユーザーのシステム開発への熱意と集中力を 奪う結果となっているのである。 ユーザーの頭脳負荷は確実に軽減の方向に進む。 それは同時にユーザー自身の知的空洞化をも意味する。 この流れは止められない、不可逆なものではなかろうか？ 以上 目次へ
本日(06/08/23)の朝刊に、以前から本シリーズで話題と して取り上げていた、みずほ証券の東証システムを 使用した大量株誤発注に関する記事が掲載されていた。 ご承知の方も多いと思うが、昨年１２月「６１万円で 一株」売る注文を「６１万株を一円」で売るという 誤発注をしたものである。 担当者は即これに気付き、注文取り消し処理を行ったが 東証システムの不具合により受付けられず、取り消し 処理をしてからの損失４０４億円を東証に請求した ものである。取り消し処理が効いていれば被害は ３億円で済んだとのことである。 本来は、注文申し込み入力時にその担当者がシステムから の取引異常を知らせる警告ポップアップが出た段階で 気付けば、事なきを得たのだが、それは無視して発注 操作を継続してしまったらしい。 東証の規定には「故意又は重大な過失がなければ 東証に賠償の責任はない」となっており、これを 盾に「システムの不具合は重過失にはあたらない」 として東証は損害賠償を拒否している。 みずほ証券の担当者に責任があることは、確実である。 特に警告を無視してまで注文継続したことに関しては 論外としか言いようがない。 しかしながら、システムの注文取消しが作動しないことが、 重過失に該当しないだろうか？ ブレーキが作動しないような車に重大な不具合はないのか。 これがシステムではなく、東証の担当者の怠慢により 被害が拡大したならば、これは明らかに重大な過失として 認定されるであろう。 「システムの不具合は重過失にはあたらない」という 認識の根底には、システムは非人格であり、エラーは 付き物である、という安易な考えが潜んではいないか？ これはシステム障害を発生させた某銀行頭取の国会での 発言のように、単なる一時的なシステムエラーだから 「実害はない。」と同じ発想である。 非人格であるシステムの影に隠れて、自らの管理監督 責任を放棄したものではあるまいか？ 利用者に対してシステムによる注文取消し操作が可能である ことを、周知徹底させていた以上、東証に過失があることは 明白である。 ちなみに、これがエレベータのプログラムミスや飛行管制 システムの不具合により重大事故が発生しても、それは 「システムの不具合は重過失にはあたらない」と 言えるのか。あるいは４００億円程度の損失は東証にとって 重大なミスとは考えないということか。 ここで東証とみずほ証券の確執から離れ、問題をシステムの 開発運用側から掘り下げてみよう。 「システムの不具合は重過失にはあたらない」という 東証トップの判断を東証システムの開発運用部門や ベンダーはどのような気持ちで聞いているのであろうか？ 「この程度のミスはいつでも発生する可能性があり、 その都度損害賠償を請求されたら、たまったもん じゃない。」 と感じているとしたら、（たとえ本音だとしても…） それは自らの職場における行為と責任をないがしろに するものではなかろうか？ 「ここで責任を回避すれば、システム全体の信用を損なう。 ひいては業界全体に対する信頼をも失う。」との危機感を 持たないシステム開発ベンダーは、自ら社内におけるモラル ハザード状態を世に喧伝しているものではないか。 従って、404億円の補償金額の配分方法については、 １．みずほ証券 ２．東証 ３．システム開発運用ベンダー が、裁判という司法制度に頼ることなく、各社の責任に おいて合議・決定するのが最も適切であると考える 次第である。 （だだでさえ、高給を享受する弁護士や法曹関係者を 本訴訟によって潤したとしても、それこそ、何の 付加価値も生まない…） いづれにしても今後、システムが企業の外部の人々との インターフェースになってゆく状況が避けられない以上、 当該システムの作動が従業員による業務上の言動と何ら 異なるものではない、という認識が企業にとって不可欠 であることを銘記すべきであろう。 以上 目次へ
アメリカのタワーレコード（米最大の音楽CD販売チェーン） が昨日倒産した。日本の音楽CDも販売数が激減している。 原因はインターネットからのミュージックダウンロード の普及である。（Winnyによる違法コピーも寄与して いるか…） 音楽CD販売チェーン店で働く人々の数とミュージック ダウンロードのシステムを運営している人々の数は 正確な比率は分からないが10,000 vs 1 程度では なかろうか。 システムの本質って多分このあたりにあるのだろうと 最近筆者は考えている。 すなわち1人の雇用が残り9,999人の働く場が喪失する。 そういったビジネスを起こすさらに極々少数の人々、 10,000 vs 1の比率における１側の少数の人々を雇用する 人々しか儲からない、成功しない仕組みを生み出す わけである。 企業統計においては、どちらも1 vs 1 であり、ビジネス 形態は異なるが「収益的には向上する」から好況という 結果となる。政府から見れば法人税は増えて、所得税を 多数の人々からとるのではなく、少数から取ることに なるから、収支はトントンまたは若干のマイナスか。 勿論これはこんな単純な話ではなく、ミュージック ダウンロードを可能にするiPodや通信ソフトなどを 製作する人々や、その反対には音楽CD再生機を製作して いた人々やCDを焼いていた人々とか…無数の関係者が 絡んでいるので一概に結論を出すことは出来ない。 しかし最小限、全体として働く人々がシステムに 置き換わっていることだけは間違いなかろう。 さて、これを巨視的に産業の推移から俯瞰してみよう。 歴史的に、狩猟採集ー＞農業ー＞工業ー＞サービス業に 人々が大量に移っていった事実は否定できない。 （少なくとも先進国においては…途上国の発展方向も） 工業化段階が機械によって人々（牛や馬も）の労働力を 代替してきたことが、現在サービス産業においてシステムが それを果たしている構図であると言えなくもない。 それでは、これまでと何が決定的に違ってきているのか？ もう大量の人々を吸収できる受け皿がないということである。 もっと言えばその受け皿をシステムが侵食することによって のみ収益を確保できる時代に我々は既に生きているのである。 工業化時代まで人類は自然を加工して食って生きてきた。 今や人類はシステムによって人類を加工し、食う以外に 生きる術がないのではないか。 当今システム開発に携わって、その職場で働くユーザーから 不信と不安の眼差しを浴びなかった、感じなかった経験の ない人間は存在しない。 その根本的な原因は、システムが人間を食っていることに あり、食われた人間の外側、出来たシステムの外側の人間が その利便性を享受し、また収益を確保する構造になって いるからではないか？ システム開発過程におけるそれに携わった人々の受難の例は （デスマーチやシステムトラブル）枚挙の暇もない。 あちらのサーバーの下には何人、こちらのサーバーの下には 何人、の犠牲者…と業界で囁かれているのを聞くのは、 受け皿を破壊され、追い出された人々の暗黙の呪詛からか… 我々が慣れ親しんだシステム開発におけるITジェネコンと 下請け構造による大量プログラマーの雇用という非効率な 仕組みは、システムによって他の人々がこれまで雇用されて いた受け皿を破壊する代わりの、せめてもの「人類全体に 対するお詫びの印？」ではなかろうか… この流れは現在システム開発に携わっている当の人々でさえ システムによる代替圧力を避け得ないものにする。 俺は常に新たな技術を学び続けるから「システムを開発する 人間を代替するそのシステム」を作る側（IDEやフレーム ワーク）に回れる…と考えている人は甘い。 人間の記憶容量には限度があり、プロとして技術を身体に 滲みこませた人間ほど、それを捨てがたいという性質が 人間にはあるからだ。 そのうえ「システムを開発する人間を代替するその システムを開発するその人間を代替するそのシステム…」 とシステム側は執拗に、さらにスピードを高めて 追いかけて来る。 勿論人間がこのプロセス自体に全く関与しないことは 有り得ない。しかしながら、この段階が進むたびに 確実に関与する人間は減少し、淘汰されてゆく。 量子コンピュータ時代になったら、人間のシステムに 関与するやり方自体も変わってくるだろう。 従って客観的にその確率を考慮すれば「俺だけは大丈夫」 は極めて怪しくはないかな？ 以上 目次へ
前回はシステム開発が進むということは、その分野での 人間による仕事がシステムによって代替され、人々の 雇用機会を奪う結果になっていることを指摘した。 音楽CD販売・レンタル店の倒産、かってはいたるところに あった町の小さな本屋の倒産、（Amazonやセブンアンドワイ のせいであるとは必ずしも言えないが…） 銀行や証券会社などの支店の統廃合など急速な勢いで WEB系のシステムに置き換えられている。 かっては大人数の雇用が必要であったものが、少数の 人間によって大量のサービスを提供できるようになったと いうことである。これを裏返して言えば、サービスを 提供する側と消費する側の人数が極端にアンバランスに なってきていることを表している。 A.提供する側ー収入を得る。 B.消費する側ー支出する。 この経済バランスが人数的に均衡しなくなってきている。 さらに問題は、人間の知的なばらつきは正規分布して いることである。その生理的な頭脳構造はこの何万年、 大きな変化はない。 その分布を 優秀層20％、並層60％、残り層20％（筆者もここか…） とすれば巷間喧伝されているように、（「下流社会」 「Web進化論」）このなかの優秀層20％しか正規雇用の機会 を得ることができない時代になるよう、システムがますます 流れを加速していることになる。 たとえ落ちこぼれてもチャレンジが何回も出来る、流行の 「美しい国」とは何だろうか？ 潰れていった銀行や証券会社の支店で働いていた人々などは 決して残り層ではなく、並層が大部分であったことを 考慮すると、残り層ー＞並層へのステップアップでは もう安定して食えない時代に入りつつあると見てよかろう。 すなわち残り層と並層ともー＞優秀層にアップしなければ ならないのである。これが今日ますます激化する低年齢 「お受験ブーム」の根底にある考え方である。 さらに、その安定して食える優秀層もますます薄くなり つつある。 はるか空のかなたの薄くなりつつあるオゾン層に向かって 「何回もチャレンジが出来る」世の中こそ「美しい国」と いうことになる。 これから先は宇宙飛行士クラスじゃないとチャレンジしても 難しいのではないかな？ マスメディアも常に（政治家も？）ヒーローやヒロインを 礼賛し、その成功物語、影の苦労話を紹介している。 （宇宙飛行士もある意味当然か…） 勇気をもって諦めずに挑戦すれば、望みは必ず叶う… ここにチャレンジ幻想のパラドックスが存在する。 ヒーローやヒロインがウジャウジャいれば、それは ヒーローやヒロインでもなんでもない。全体のなかの 絶対的少数であるというのが彼や彼女達の必須条件である。 絶対多数は絶対になれないからヒーローでありヒロイン なのである。 ＞勇気をもって諦めずに挑戦すれば、望みは必ず叶う… という大多数の人々へのメッセージは、成立しない 命題である。一般の人々にはフィクションに過ぎない。 ひと時ヒロインやヒーローに自らを重ね合わせることに よって、その忘我的一体感によって、「大多数の人々の 身の丈にあった並の目標である部分が破壊されつつある」 ことを、忘れさせる効果を持つのではあるまいか。 （イ）世の中で有用な存在である。役に立っている。 同時に安定した収入を得る。生活と性殖を確保する。 （ロ）この人類にとって基本的な部分がシステムによって 破壊されつつあることを、世の中全員が暗黙のうちに 感じている。 現在のナショナリズムの高まり、日本、韓国、中国を含め 全世界に広がる動きは、自分自身の（イ）の部分に対する 不安、危機感や苛立ちがナショナリズムという形で、その エネルギーを国家の外部に放出しているのではないかと 筆者は考えている。 歴史的に人々の失業と貧困への不安が、常にナショナリズム の温床であったことはご承知の通り。 アメリカやヨーロッパのような豊かな世界においても失業と 貧困への不安が、貧しい世界と同じように発生し、それが 世界中でナショナリズムや宗教闘争として衝突している構図 ではなかろうか。 では、何故（ロ）のシステムによる雇用基盤の破壊に 直接不満が向かわないのだろうか？ その原因は二つある。 １．システムによって雇用機会を奪われる人々自身が、 一方ではシステムの恩恵を享受する消費者であり、 システムに依存しているからである。 今やiPod無しで、パソコン無しでは生活が出来ないほど、 どっぷりシステムに依存している。また消費者と しては、システムによる生産性の向上（省力化、省人化） でコストが下がり、プライスが下がり、利便性が向上する ことは、歓迎すべきことであり、なんの痛みも伴わないの である。 ２．システムが認識・評価出来ることは、「極々」 限られている。 a) 収入であり、収益性であり、損得勘定のような 量計算である。 b) 地位、学歴、美人コンテストやブランドのような 分類とランキングである。 c) a)やb)を達成するためのif〜then〜else〜のような 条件因果式である。またそれを繰り返すwhile文のような 反復式である。その過程での問題発生時における、 try〜catch〜文のような自己保身対策である。 現代人の思考や判断基準と、どこが違うのか？ 勿論、システムは人間の思考を模倣しモデル化したもの だから、似ているのは当然との反論はあろう。 しかし、問題はそこにはない。 そうではなくて、システムを開発するということは 確かに人間の仕事をモデル化することではあるが、 上記の ＞システムが認識・評価出来ることは、「極々」 ＞限られている。 この限定された人工環境を自らの周囲に構築することで ある。古来、人間は常に環境に適応して生きてきた。 つまりみずから作り出したシステムに適応、同期しなければ 生きられない状況を生み出しているのである。それは即ち、 自らの思考回路を限定的なものに、日々変容させられ続けて ているという再帰的な悲劇性（喜劇性？）をここで筆者は 言いたいのである。 上記で述べた通り、自らの生活習慣や思考にまで システムは深く浸透し、イデオロギー、社会体制、宗教の 如何を問わず、現代はシステムに丸ごと依存し、変貌を 遂げつつある。 （お陰様で、システム開発の商売が成り立つ訳だが…） 以上 目次へ
人の話を聞かないのが増えた。顧客とのシステム開発の 打ち合わせでも、自分に関係する部分しか聞かない。 ひどいのは、自分がこれから発言、発表することに気を 取られて、自分に関係する部分も聞かないのがいる。だから お客が既に発言していることと矛盾していても分からない。 もっとひどいのは、オリンピックのように参加することに 意味があるとでも思っているのか、始めから終いまで 黙って聞いている「振り」だけしているのがいる。 なかには、発表式の会議室におけるプレゼンの一聴衆と してならいざ知らず、顧客との対面式の会議室において 質疑応答中に寝る奴まで… 聞かない、聞いても理解しない（出来ない）、理解できなく ても質問しない。おまけに議事録は忘れた頃に内容不明で やって来る。 聞けないほど、理解出来ないほど、発言内容が豊富で中味が 濃いのか？ そうではない。出席メンバーの２割が９割の発言時間を 占め、同じ内容を繰り返しているに過ぎない。 勿論これは顧客側も状況は同じだ。 それゆえに会議を何度やっても同じところをグリグリ 回っていることが多い。永久ループのようなものだ。 この状況をさらに悪化させているのが、参加メンバーが 変更になっても前のメンバーから引継ぎを一切受けずに 会議に参加することだ。前のメンバーも聞いてない、 理解してない、ので引き継ぐ内容もないのである。 そもそも、引き継ごうという意志もなく、引き継ぐ意志 もない。従って会議が進めば進むほど訳の分からない メンバーが増殖する。 そして、参加者全員が訳の分からなくなった頃を 「見計らって」会議は突如、開発スケジュールの関係？ で終了する。 まさにシステム開発会議は会議のために会議が行われ ている。 何故こんなことが起こるのか？ １．会議をやろうがやるまいが出来上がるシステムに 変わりはないからである。受注段階でベンダーとしては その予算と動員された開発メンバーの経験と能力により、 ほぼ自動的にシステムの仕様は決定されているのである。 顧客の要望を受け入れる開発側の余地などコスト的にも、 スケジュール的にも、精神的！にも、殆どないのが 実情である。 ２．会議に「参加」することで顧客もシステム開発に関与 した「気分」を味わい、ベンダー側にとっては参加人員が 実質的に開発人工時間に「カウント」されるのである。 まるで、メータが入ったままお客と無駄話をしている タクシーの運転手と同じ気分を味わえるのである。 ３．上記２．で述べた通り顧客が会議に参加し、システム 開発に参画している「錯覚」は与えられるが、実は１．項で 述べたようにベンダー側の都合によりシステム開発構想から 実質的に顧客の希望は排除されている。 しかしそれにも関わらず、顧客との会議はベンダー側に とって極めて重要なのである。 それは決して、ベンダートップが吹聴するように顧客との コミュニケーションが何よりも大切だからではない、 そうではなくて、顧客が会議に出席したことで顧客自身が 開発作業に携わったことの証になるからである。 つまり出来上がったシステムの完成度に関して顧客に 責任を分担させることが目的なのである。 a)システムの仕様作成から実質的に顧客を排除すること、 b)ベンダー側が一方的に作成したシステムに対して顧客を 共同開発者に祭り上げて責任を押し付けることは、 ベンダーにとって表裏一体のビジネステクニックなのである。 出来上がったシステムに顧客が不満を漏らしても、それは 開発会議の席上で言うべき問題であり「今さら言われても」 と軽くベンダーにいなされる。 結局、これじゃ現場の業務が進まないという致命的な 不具合を修正するために、高額な追加費用を支払わされる はめになるのである。 ベンダーにとって常に追加仕様は「高額」であることに 意味があり、実際の修正工数とは無関係である。 ４．議事録は通常ベンダーが作成する。 上記の >おまけに議事録は忘れた頃に内容不明でやって来る。 これがベンダーの戦略的陥穽の一環である。ベンダーの やるべきこと、やるべき時期などは巧妙に抹消され、顧客の やるべきこと、やるべき時期はがっちり書かれた内容の ものが、顧客がほとんど何を話したか忘れた頃に、さも さり気なくメールなどで送られてくる。 ベンダーのやるべきことが抹消されているから、 どんなシステムが何時出来上がるのか読んでも さっぱり分からない。だから誰もそんな酔ったような 打ち合わせ覚えを注意して読むようなお客はまず居ない。 これが顧客とベンダーが揉めた時に威力を発揮するとは 神ならぬ身の顧客は知る由もない。 「お客さん、この打ち合わせ覚えには何もそんなこと記載 されてませんよねぇ」とベンダーに言われれば、会議中に 「要望したような気がするだけ」の顧客にとって法的な対抗 要件は何もない。 受注時にベンダーの甘い一言： 「全て私共におまかせ下さい。」に乗ったことを、お客が その時点で悔いても遅いのである。 （システム開発において、悪質住宅リフォーム屋とのやり取り と紙一重の事態が常に発生する原因は、この辺りにあるの ではなかろうか…） 本稿はシステム開発ベンダーの狡猾さを暴いたり、お客の 迂闊さを指摘することを主旨としたものでは決してない。 そうではなくて、システム開発におけるドロドロした利害 に絡んだ現実に迫りながら、むしろ、コミュニケーション 重視の掛け声で祭り上げられる参加者が、実は常に企画側 からは排除の対象として意識され、オープンで開かれた場が 同時に排除の場としても機能しているという、普遍的位相を 読者に伝えたかった次第である。 本来コミュニケーションという社会的な行為には、この 二面性が既に刻印されており、参加者側の意志が排除され ないと、かつ企画側の意志が優先されないと、その コミュニケーション自体が成立しないのである。 もっと言えば、排除されながら参加する、いや排除されて いると意識することなく参加する多数者こそが、社会的な コミュニケーションにおける不可欠な「儀式的」構成要素 ではないかと。 以上 目次へ
会議中に人の話を聞かない。寝るのが増えた。これはどうも システム開発会議であるという理由だけでは説明がつかない 普遍的なオフィスにおける会議の状況のようである。 年寄りが午後の会議で寝るのは昔からよくあった。 加齢による生理的現象である。しかし最近は特に 若い世代が朝から晩まで会議中に集中力を失う。 会議におけるプレゼン技術は以前に比較すれば飛躍的に 進歩している。パワーポイントによる図示、写真、アニメ まで、なんとか参加者の興味を繋ぐため様々な工夫が こらされている。にも、関わらず寝るのが増えた。 確かにパワポ映写時に室内の照明を落とすことも原因の 一つか… それだけでは説明のつかない「寝る」現象を今回は システムの職場への普及という視点から考察してみよう。 これまでオフィスで働く人は「人間」であった。従って 会議とは人格と人格が接触する対話の場として成立して いた。そこで「人の話を聞かない。」あるいは「寝る」 などは、話し手である人格を社会的に侮辱した行為で あった訳である。即ち自らの社会的人格を危うくする ことを意味していた。 ところが業務システムがオフィスに侵入してきたことで、 表面的にはオフィスで働く人がそれを利用する、または 使いこなすという様相を見せてはいるが、実体的には システムにより人が同期化される部品へと変容させられて きているのではないか。 以前本シリーズ第１２回で取り上げた営業日報をDB化した ナレッジマネジメントシステムを例にこれを検証してみよう。 その日の営業活動をシステムに投入し、それが個人の活動 記録として残る、と同時に他部署への連絡事項として利用 される。会社によっては上司はそれを見ながら人事評価 まで行う。評価は客観的にということで、上司と一緒に 飲みに行ったりゴルフしたりした回数ではなく、厳密に 受注件数と金額およびその利益率によってシステム的に 判断される。 この流れから消去されているものは何か？ 個人としての唯一性を保つ人格的関心ではあるまいか。 卑近な例だが、商談を失敗したときや、（個人で飲んだ 飲み屋の付けを回すときも？）上司の機嫌の良いときを 窺うとか、他部署の誰にどのような順番で根回しをすれば、 （例えば、「相当以前に自腹ではないが」奢ってやった奴 から予め話を通しておいてもらうような…）最も話が進み 易いのかとか、人格的な関心を払う機会を奪われている。 個人がシステムによって投入した情報量に応じて計算可能な 実体に変換されているのである。ある地区なり機種の営業 担当者としてシステム的に部品化され、自らの従業員コード と一体化された「もの」としてしかオフィスに存在しない。 これは工場で見られるベルトコンベアーの前でのブルー カラーと同じ現象である。 オフィスで情報という不確定なものを扱っていたホワイト カラーがブルーカラー化しているのである。 情報を扱うために不可欠である多様な人格的な関心を システムによって奪われ、視野狭窄的な部品化した 思考様式に押し込められているのである。 ここで本論に戻るが、上記で述べたように極めて限定した 範囲のものにしか反応しない部品は、会議中においては 自らの関心範囲外と認識されたものに対して、自らの 頭脳負荷を軽減するため、「自動的に」スイッチがオフに なるのである。 システムによって人格的関心が磨耗し尽しているため、 そこに何の社会的な罪悪感を覚えることもない。 言わば部品が部品と話している感覚であり、システム的に オブジェクト指向からこれを表現すれば、インターフェース がないオブジェクト同士は完全に関心が分離されるので ある。複雑性による情報の縮減というか、シャットダウン 現象というか、これが「どうどう！と」会議中に寝る 真の原因ではないだろうか。 （「はてな」というBlog運営会社では、これを防ぐ意味？ からかブルーカラーの朝礼、作業指示と同じスタイルで 全員が立ったまま会議をしているようである。 是非このスタイルを国会でも取り入れてはどうか…） システムによる思考経路の縮減は、困ったことに縮減されて しまった人々にはその事実が分からない。システムに 取り込まれた形となっているために、そのシステムの外部 から自分自身を見ることが出来ない。本人は反省している つもりでも、どこまでも合わせ鏡のようにシステム的な 回路が続いているように見えてしまう。 視点をここで一般社会に移してみよう。 最近、高校生が３０万円で友人に母親を殺させた事件が 発生した。その高校生や友人に関してここでどうのこうの 論評するつもりはない。そうではなくて、テレビでこの 事件を題材にして論評する人々について考えてみよう。 A.「たったの３０万円でそんなことを請け負うとは…」 B.「そんな小細工をしてもすぐにバレるとは考えないの だろうか…」 C.「働き手である母親を殺してどうして食って行く つもりだったのか…」 論評から評論家の思考経路がシステム的に縮減されている 事実にお気づきでしょうか？ システムは本来的な意味を理解しない。 全てを手段と成果として考える。 人を殺す。母親を殺す。という本源的な意味が A. では３０万円という金額に B. ではバレるバレないの真偽値に C. では生活手段に それぞれすり替わって議論されている。大真面目で話を している評論家連中と事件を起こした高校生と思考回路に おいて、そのシステム的な縮減率において殆ど差がない ではないか。 これをさらに詳細に立ち入って検証してみる。 システム開発の目的はユーザーを限定した思考回路に 向けて追い込み行動規制することにある。でないと システム自体が成立しない。 例えばパソコンで画面を消したいときには自動的に右上の X印をクリックする。これは即ち、関係のない場所でクリック したり、ドラッグする、あるいは、画面に話しかける！と いったユーザーの行動を規制している訳である。 何回も自動的に画面消去作業が繰り返されて思考経路が 固定化されると、「ウザイ」画面と「ウザイ」母親とが 形容詞的衝動である「ウザイ」によって短絡し、消去の 対象となるのは必然的な成り行きではなかろうか。 さらに人を殺す、母親を殺す、が画面オブジェクトの操作と 同一視され、上記 ＞A. では３０万円という金額に ＞B. ではバレるバレないの真偽値に ＞C. では生活手段に に、評価が変換されてしまう「人を道具的に捉える論評」 を生み出す元になってはいないか。 技術文明史的にこれを眺めれば、合理的な利便性が 頭脳負荷を軽減すると同時に空洞化を招いている といった構図を表していると言えよう。 さらに、世の中の大きな流れを見てみよう。 共有する大きな物語がない。 タコツボ化する人々の増加。 その対策としての「愛国心」や「美しい国」日本の再建 という話題が喧しい。 筆者は決して「愛国心」や「美しい国」自体を 否定するものではない。そうではなくて、「愛国心」や 「美しい国」という概念が、システム的に縮減された 思考回路にとって心地よいものとして、短絡的に持て 囃される危険性はないのか、むしろそれを危惧している。 我々が現在享受している平和は多くの人々の犠牲の上に 成り立っている。 イ）特攻隊や回天など戦時中若者が自ら進んで国に命を 捧げたことは事実である。 ロ）しかしその何百倍の人々が広島や長崎の原爆で「自ら の意志に反して」亡くなったこともまた事実である。 ここで言いたいことは、イ）の人数 ＜ ロ）の人数 などというシステム的な計量ではない、まして特攻が 右翼で原爆はアカだ、という単純な政治的ラベリング でもない。 そうではなくて、現在の平和の礎という意味で両者を 考えた場合、当時の為政者に戦争の継続や本土決戦を 実質的に「思い止まらせた」のはどちらなのか？ システム的に短絡した思考回路で「愛国心」や「美しい 国を守る」という言葉に踊らされ、イ）の特攻や回天に 乗り込んでいった、（乗り込まざるを得なかった）若者達 「のみ」がヒロイックに賛美されるとしたら、またそれと 同時にロ）の原爆という殺戮手段によって一般人が大量に 一瞬にして虐殺されたという記憶が人々の間で消去されて ゆくとしたら、真の意味での「愛国心」に反することに なりはしないかと。 将来、戦争はますますシステム化される。米軍であれ、 中国軍であれ装備の近代化、システム化が進み、大量の 兵士が失業の危機に直面している。これはシステムによって 働く人々が代替されつつある現在のオフィスの状況と 軌を一にしている。この大量失業への焦りが地域紛争の 勃発と武力解決への政治的圧力となっていることも否定 できない。 ただここでは、将来においてヒロイックで自己犠牲的な 精神や行動が実際に有効性を保つ余地は、もはや自爆テロ ぐらいにしかなくなり、真の国家間の戦争においては パトリオットや大陸間ミサイル、局地戦では自動戦車や 自動飛行物体など遠隔操作によるシステム的で効率の 良い戦闘行為しか残らなくなる可能性が極めて高いことを 指摘しておきたい。 まるでシステムエンジニア同士のゲーム化した戦争の 様相を呈するであろう。 但し、そのゲーム的戦争においてさえ虐殺の標的と なるのは無辜の人々の命であることを忘れてはならない。 以上 目次へ
前回は主としてシステムが人間の思考にどのように影響を 及ぼしているかを検討してみた。 ＞１.会議中に人の話を聞かない。寝るのが増えた。 ＞２.テレビのワイドショウにおいて 人を殺す。母親を殺す。という本源的な意味が A. では３０万円という金額に B. ではバレるバレないの真偽値に C. では生活手段に それぞれすり替わって議論されている。 ＞３．特攻や回天に乗り込んでいった、若者達 「のみ」がヒロイックに賛美され、それと 同時に原爆によって一般人が大量に虐殺された という記憶が人々の間で消去されてゆく 上記３点をシステムによる思考回路の縮減という切り口で 分析し、頭脳負荷の軽減をはかる「思考の短絡的判断と 不要なものの消去」が、これらの現象の底に流れる 普遍的位相であると結論付けた。 上記１、２項については前回の説明で充分と思われるので あらためてここでは論評はしない。 上記３項、同じ戦争体験であるはずの特攻「自らの命を 賭けて国を守る」と原爆「無辜の人々の大量虐殺」に おいて、なぜ前者によって後者が縮減されるのか？ 安倍さんの近著「美しい国へ」でも小泉さんと同質の 特攻に対する強い思い入れは書かれているが原爆の 記述はない。 今回はこの点に関して想定される原因を挙げることで 若干の補足を試みる。 １．特攻には「国家を守るための自己犠牲」がある。 原爆には「国家が始めた戦争の犠牲」しかない。 ２．特攻や回天には悲壮感がある。原爆には悲惨しかない。 a)特攻や回天の悲壮感は、自らの命は犠牲となるが 敵艦を撃沈するという目的に基づいている。敵を攻撃 するというヒロイックな部分がある。人間の闘争本能を 満足させるものがある。 b)原爆には悲惨しかない。敵機B29から投下された 爆弾の焦熱によって無辜の民間人が無抵抗に焼き殺さ れるだけである。 ５．システム的な思考回路からこれを分析すれば A. 戦争をやるかどうか。 B. やるなら勝たねばならぬ。 C. 勝つにはどうすれば良いか。 この単線思考において物量的に劣勢な状況で勝つ ための方策として、実質的な有効性を度外視すれば、 特攻作戦は辛うじてその位置を占めることが出来る。 しかし原爆はこの単線思考に受け入れられる余地など 全くない。 これらが特攻による原爆の縮減論理を形成する要因では ないか。（原爆投下国であるアメリカへの政治的配慮 などは、システム的縮減論理とは相容れないので 割愛した。） さて、自己犠牲的な国家への忠誠行為は、イデオロギーに 関わらず為政者やその国民から常に支持・賛美される傾向に ある。例えば共産主義である中国においても抗日戦線に おける自己犠牲的な戦闘行為者は救国の英雄として賞賛 されている。但し特攻においても、抗日戦線の英雄行為に おいても、その自己犠牲的な戦闘行為で殺傷された相手 （米国軍人、日本軍人）については、単なる敵兵、 もしくは戦果、として認識されるに過ぎない。 その一方で、米国においてはアーリントンの戦没者墓地に、 日本においては靖国神社において、相手国の英雄的行為の 犠牲者も、それぞれ英霊として祀られている。 即ち、自己犠牲的な英雄も彼等が標的とした相手も、 それぞれが双方の国で英霊として祀り上げられること になる。 これほど戦争行為自体の究極的な愚かしさと虚しさを 如実に表すものはあるまい。 「内（国家）を守るために、自らと外（他国）の人々を 殺す。」 宣戦布告で始まる国家間戦闘員同士の戦争（日中戦争 では最後まで正式な宣戦布告はなかったそうだが）かどうか を別にすれば、イスラム原理主義における自爆テロ行為者と 当事者心理においてなんら変わりはない。 国家なり組織の目的遂行システムにおいて人間が部品化され ている実体が、至純の大義や殉教という言葉によって覆い 隠されてはいないか。 ここで筆者が強調したいことは、内（国家）の結束を図る ことを目的として、戦争において自己犠牲的な戦闘行為を 実行した人々をヒロイックに回想し賛美することは、 真の愛国心に繋がるものではないということである。 何故ならそれは不可避的に外（敵）を生み出さずには 成立しない思考だからである。 集団的自衛権も畢竟その内と外を断絶する思考に 他ならない。 現在日本において最も大切なことは、特攻で若くして 散った命も、原爆で無残に亡くなった命も、さらには 敵味方の隔てなく、先の戦争で亡くなった全ての人々の 「命を等しく」哀悼の念でもって崇敬し、不戦の誓いを 新たにし、それを改めて世界に向けてはっきりと示す ことである。 残念ながら世界は今そういった理念とは逆の方向に 流れようとしている。だからこそ日本が世界に貢献する 道は経済援助や海外への自衛隊の派遣などではなく、 時代の不穏な動向に対して断固としてNOを発信し続ける ことではないか。 それが世界で唯一の被爆国としての日本の国際的な 義務である。 今こそ「核不拡散」から「全面核廃絶」に向けた道筋と スケジュールを具体的に提示し、その実現に向けた努力を 関係国とともに日々積み重ねる決意を示すことが喫緊の 外交課題ではなかろうか。 なぜなら、そのような世界平和に向けた決意と努力こそ 世界中で眠る英霊達が「何よりも」望んでいることで あるから。 以上 目次へ
話は少し脱線するが、システム業界は「古い酒」を 「新しい皮袋」に入れるのが実にうまい。名前を 新たに考案するのである。いわばキャッチコピーのような ものである。SOAと以前の客先業務分析の違いは、実も蓋も ない言い方をすればモデリング手法とツールを使用するか どうかだけである。 最近話題のAjaxとは何か？ 以前からあるJavaScriptによるWEB画面動作機能にHTTP 通信機能を付加したものではないか。 Ruby on RailsとはMSのASPの焼き直しetc.etc. Web 進化論などで次々と新たな技術が社会を進歩させてゆく 「イメージ」を「希望」をもって人々に語られている。 業界内部の人間から見れば、確かに有りがたい面はある。 反面、技術屋にとってみればいくらなんでも、そりゃぁ ないぜとシラける人はおられないのだろうか？ 特に最近Web2.0とか3.0とかという新情報技術潮流なる ものが持て囃されている。 膨大なWeb利用者、消費者自身がWebの世界に自ら参加して これまでPull型（受容型）であった情報の流れがPush型 （発信型）に逆転されるというものである。 BlogにしてもSNSにしても技術的には従来からあったものの 焼き直しではあるが、一部の熱心な利用者とそのビジネスを 演出するもの達がこのムードを盛り上げているのである。 （Web2.0の解説本の著者達やその出版社なども…） この流れをさらに後押ししているのはソフトウェアや コンテンツの無償化である。Winnyは別にしても、これまでの 商用レベルのソフトウェアが無償で提供される環境が 整いつつある。 かのマイクロソフトでさえIE以外の無償開発ツールの配布を せざる得ない状況に追い込まれている。 一つにはGoogleのように企業が得られる広告収入を開発費用に 充てるもの、二つにはLinux、GNUやウィキペディアのように ボランティアが開発したり編集に参加しているものに大きく 分かれる。Web2.0とはこのような無償ツールを使用して 貢献するボランティアがWeb上に大量に発生することを 期待する「ある種の文化」的な現象と言えよう。 さて、この文化的現象はこれまでシステム開発が不可避的に 抱えていた、 a)サービス提供者数の減少ー収入の減少 b)消費者数の増加ー支出の増加 といった、システムによる労働力代替型の収益レバレージ効果 がもたらす「経済的なアンバランス」をどのように変化 させるのか。果たして雇用や収入の減少を食い止めることが 出来るのか。 結論から先に申し上げよう。 雇用状況はますます悪化する。労働格差は増大の一途を 辿ることになろう。 新しいビジネスチャンスは増えるかもしれない。 しかしその雇用力は零細企業並みである。 かの有名なBlog運営会社「はてな」で正社員は２１名。 大田区界隈の鉄工所並ではないか。 世界に冠たるGoogleで5000名、三菱重工の事業本部並。 いかに少人数で大量の消費者を相手に出来るかがこれで お分かりであろう。 さらにはこれまでシステム開発やソフト開発で生計を 立てていた人々も無償化の流れから無縁ではいられない。 収入は細る一方である。 何よりも大きなポイントは、もし膨大な利用者が「最初 だけの物珍しさ」を通りこして、ボランティアとして 無償サービスを提供し続けるとしたら、恐るべき事態を 招くことになりはしないか。 まず、無償サービスによってこれまで生計を立てていた人々 百科事典の執筆者や編集者など（大した数ではないが…） は不要になってしまう。ウィキペディア程度で治まって くれればよいが、次から次へとこれまでの事業を侵食する ような事態になれば、「日本のGDP、賃金水準や失業率」 にも影響を与えかねない。大量の善意が失業者を生むと いうこのパラドックス。 その一方で、団塊の世代以降の年金世代ばかりでなく （むしろ彼等は少ない）大部分は若年層である膨大な 利用者やボランティアがBlogに書き込む労力やソフトを 作成する時間はどう考えればよいのか。 個人収入や生産性には一切寄与しない。どうやって彼等は 生計を立てて行くのか。 こうした膨大な利用者によるWebへの没頭による収入減は 決して、ソフトや百科事典の無償化程度の支出の減では 補いきれないのは明白な事実である。 かくして膨大な人々の収入減が生じ、ひいてはそれが 消費の落ちこみに繋がる。Webで宣伝しても買う金のない 人々を大量に生み出すことになりはしないか。 結局新しいビジネスチャンスも「物珍しさ」に飽きた 消費者（ある面極めて賢明な…）からも見放されて しまう結果が予期されないだろうか。 NHKのクローズアップ現代でパジャマを消費者からの Web上のアンケートに基づいて作った下着メーカーが コスト削減のうえ、売上げが増加した話をWeb2.0活用の 一例として放映していた。 例え半分はヤラセの消費者？であったとしても、確かに 斬新なアイデアではある。（NHKの放映効果をも含め…） 但し、あまりに底の浅いアイデア故に模倣する業者が簡単に 輩出するであろう。所詮は一過性の成功に過ぎないのでは なかろうか。 Web2.0に乗ることは、大量の人間が自らの首を絞めながら 少数の人間の生計を維持する手段である。 さらにその少数の人間もその「一過性」から脱却するのは 極めて難しい。従ってビジネスも烏合衆参を繰り返す、 状況に左右され易い、不安定な業容・雇用形態となる。 ３年後に「はてな」や、「Google」でさえ企業として 存続している可能性は途轍(とてつ)もなく少ないことを 銘記すべきであろう。 以上 目次へ
システム開発側でコードを組んだことのない人には、 分からない部分は確かに存在する。 徹夜作業になってオフィスの床で寝袋に潜り込んで、 煌々とした照明の下、冴えてしまう頭で仕事の 空いたほんの短時間なんとか眠ろうとしている。 やれトロッと来たまさにその瞬間、まだ働いてる連中の 「疲労困憊のために」（と一応は納得するはめには なるが…）よろけた靴で頭を「思いっきり」蹴っ飛ば された、経験など…実は、たいしたことではない。 それは身体的（人間心理的？）な問題で、形骸化した 労働法環境のもとで徹夜作業が続く仕事であれば、 どこでもそんなものであり、別にシステム開発の仕事に 限った話ではない。 そうではなくて、システム開発にどっぷり浸かって しまっている人々には、自明過ぎて逆に意識することも ないことではあるが、 １．コードという極めて厳密に同一性論理が貫徹した （ポストモダン的に言えば郵便的誤配が不可能な）言語を 使用して、多義性と不確定性に満ちたユーザーの行動を コントロールする困難さである。 ２．コード自体は日常言語よりはるかに単純な構造と語彙 しかない。しかしながら、それらがシステムとして集積 することにより、人間の多義性と不確定性に対抗しようと するとき、その名状し難い複雑性との格闘である。 ３．システム開発者はこの頭脳負荷に耐えらない。そこで 細部を無視したモデル化とイデオロギー的とも言える抽象性 のなかに人間（開発者とユーザー）の思考と行動を追い込む といった、ある意味「全体主義的」な衝動を抑えきれない のである。 ４．目的や結果の是非よりも手段と効率を重視し、人を 人格的な存在であるというより道具・部品的な「モノ」と して機能的に取り扱わざるを得ないのである。 何故なら、システム自体の本源的な存在事由が そうであるから。 ５．同時に３、４項に書かれた内容が、いかにもそうでは ないかのようにシステムを表象（フェイク）しなければ ならないというダブルバインド圧力がシステム開発には 存在する。 Web2.0になってもシステムの本質に変化はない。 いや、ますます人々の間で増殖して行く過程こそ Web2.0の世界である。 システムの世界に人々が取り込まれれば取り込まれるほど 自然との接触の機会が減少する。それは人と人との全人格的 交流をも疎外する。即ち思考回路が限定的なものにならざる を得ない。 デジタルデバイドとは何か？ いかにもIT機器の操作ノウハウやその関連知識の有無如何 であるかのように喧伝されているが、実体は道具的理性の 普及度ではなかろうか。この普及度差異が収入差異に 繋がるとしたら、人間本来の自然な感情や情緒は一体 どうなるのか。 人間関係の煩わしさこそ、社会を構成するための不可避・ 不可欠な要素ではないか。（徹夜で寝ている最中に頭を 蹴飛ばされようとも…）その頭脳負荷まで軽減することは すなわち、先人がこれまで円滑な社会を形成するために 営々と築いてきた人格的交流を虚しくするものではないか。 Web2.0におけるデジタルデバイドとは人々をWeb（蜘蛛の巣） に追い込むための掛け声に過ぎない。 このデジタルデバイドは蜃気楼である。 だれであっても常に最先端に追いつくことは、もはや 不可能である。（たとえビル・ゲイツでも…って、彼は 引退して賢明だったかも） これまでこのBlogで論述した批判的な意見は、本来 システム開発側から発せられるべきものではないはずだ。 （利害的立場からして…） システム環境に取り込まれてしまったユーザーからでも、 難しいものがある。（思考フレームが変容してしまって いるから…） 本来は大学における研究者のような学問的な立場から、 中立的に論及、批判されるべきものじゃないだろうかと 筆者は最近考えている。寡聞にして大学の研究内容を よく知っているとは言えないが、ゲームソフトが 子供の精神的発達に及ぼす影響程度がせいぜいであろうか。 最近、大学において社会的メインストリームを批判・研究 することに対する風当たりは強い。大学の格付けがその 収益性で決まる時代だからか。 企業の基礎研究所、人材養成所となることだけが大学の 存立理由になることは、返って社会全体の調和と健全な 発展を阻害することになりはしないか。 世の中のシステムを駆動する歯車になることだけが 大学に課せられた社会的な役割ではなく、システムを 批判的に検証し、オルタナティブな提案を生み出し続ける こともまた、殊の外枢要な任務であろう。 それともあるいは、大学においてさえ、人や組織や社会を 全体的な有機体として認識する知覚が、既に衰退しつつ あるのだろうか。 もし、どなたか大学の研究機関においてシステムやWebが 人間の思考や社会生活に及ぼす影響を「批判的」に研究 している例を、ご存知であればメールででも是非教えて 頂きたい。 「肯定的な」例としては、下記があるが… http://ised.glocom.jp/ised/ 以上 目次へ
システム開発は、具体的に企業や官公庁などのために システムを製作する行為である以上、狭義のシステム工学の 範囲を越えて他のどんな学問分野とかかわるにせよ、それ 自体はつねにビジネスの現場から離れることはできない。 その結果、それはビジネスにおける双務契約に起因する 制約を、たとえば私企業や官公庁が組織として要請する 密室性や非公開性という制約などを受けることになる。 ビジネスのパートナーとして守秘義務を負うのは当然 のことである。従ってシステム開発の現場は製作に直接 関与する要員以外の人間には、原則として公開されない。 これまでこのBlogでもシステム開発の現場の実情を、 個別著名性を極力排した、ある意味誇張した形で戯画的な 説明をせざる得なかったのは、この間の経緯によるもの である。まして、具体的なモデリングプランやコードなどを 個人的なBlogで公開することは、職業倫理に反する行為で あると筆者は考えている。 しかしながらその一方で、システム開発という密室的な 製作状況のなかで得られる知見には、システム工学の範囲 などにはとても収まりきれない、普遍的な位相を示すものが 得られることもまた事実である。 A.システム開発という一連の行為から、 B.システムというその無機質でありながら人間を誘導、 規制する「擬似主体」から、 人間と社会を観察することから見えてくるものを 論述することが本シリーズの目的である。 さらに詳細にこれを述べれば、上記A項は社会、人間の モデル化、システム化という方向であり、翻ってB項は完成 した、というより状況によって変容する動的なシステムと いう環境要因が社会や人間に与える影響を考察すると いった方向である。 勿論AとBは密接不可分にシステムという「擬似主体」に よって統合されてはいるが、本稿においてはB的な視点から その問題を探る試みであると言えよう。 この問題に接近する方法として、数量的な測定とその統計的 な処理によって科学的形式を保つのも一つであろう。これが システム本来の形式に則った方法であることは認めざるを 得ない。だが、客観的あるいは科学的形式と称するものに おいて、いかに発表者の恣意が巧妙に紛れ込み、聴衆が 発表者の意図する方向に導かれる結果になることを、 「知り過ぎてしまった」筆者としては、どうしても 抵抗感を覚えてしまうのである。 （統計における検体と母集団の確定の仕方、及びその 処理方法とプレゼンによって結果はどうにでもなる。と、 そこまで断言するつもりはないが…） そこで、たとえ読者と認識を共有できない可能性があったと しても、筆者個人の主観的な直感を通じて問題に接近する 方法を選択している。 こういった極めて個人的な意見に対する多数の？反発も、 限りなくゼロに近い？賛同も、そして「圧倒的多数の」 無視さえも、それなりに意味があると考えている。 Web2.0で形容されるロングテールの端を「ひっそりと ほんの少し」齧ってみるか… さて、話を本論に戻そう。前回の ＞それともあるいは、大学においてさえ、人や組織や社会を ＞全体的な有機体として認識する知覚が、既に衰退しつつ ＞あるのだろうか。 に関して具体的に説明してみよう。 システム開発の過程で接触する人々（特に若年層）のなかで、 システムをトータルで動体的に認識すること、またその システムがユーザー企業のなかで人々にどのような環境を 提供しようとしているかについてのイメージが湧かない人が 増えてきている。 システムは無機質なコードの集積に過ぎないが、ある意味 生きているような有機体的な全体性を有している。 そのシステムが稼動する組織も、それに属する個々の人々が 全人的に生きていると同時にある有機体的な全体性を 持っている。さらには、そういった個々人、組織と システムが融合して、システムが入る以前又はシステムが 変更になる以前とは異なる有機体的全体性を形成する ことになる。 それがどうもバラバラにしか、それも自分の関係する 機能しか認識対象とならないような具合なのである。 もとより経験や知識の多寡によって全体像や稼動イメージ が異なるのは順当なことであろう。しかし自分なりの全体像 自体が形成出来ないことは、どこか不自然なのではない だろうか。 そういった若い人達の知能や記憶レベルが低い訳では 決してない。（少なくとも学校偏差値においては…） ただ共通して感じられることは、生き生きとした躍動感に 乏しい。生命エネルギーのポテンシャル自体が若干他の 連中に比べて低いような印象を持っている。 心理学や哲学の専門家には僭越ではあるが、 その原因に関して自分なりに考えてみた。 まず基本的な人間の世界に対する思考形態から… １．本来世界（宇宙的）は物質を含めて全て流動変化 生成を繰り返すエネルギーによって出来ており、人間が 認識する以前の状態が存在する。時空間発生以前のカオス である。厳密に言えば認識以前であるから「絶対的他と して存在すると、仮定する」であるが… ２．生命体とは宇宙的エネルギーが一定の空間に 閉包されたものである。本来は水が流れるのと同じ エネルギー法則に基づいており、閉包された空間に より個別性が判別され、そのエネルギーが世代間に 渡って継承される。 ３．人間の思考は、世界エネルギーと閉包エネルギーが 絶対現在において一緒になり物質（身体あるいは脳細胞） に刻印されるところから始まる。つまりエネルギーと 身体の界面は常に現在のこの一瞬にしかない。 ４．そのような閃き的な刻印が時空間意識に展開され 記憶となり、認識が開始され、予期や反省が自意識と ともに付随して発生する。従って認識や思考は常に 過去完了形である。通常我々が思考と捉えているのは この段階になってからである。 ５．ただ過去も未来も思考のなかにしか存在しないため ３と４の過程は常に同時に現在の瞬間にしか発生して いない。 これ以上、人間の認識論や存在論を本稿で述べるつもりは ないし、またその立場にもない。ご興味のある方は ハイデッガーやフッサール、ベルグソンなどの著書を 参考にされたい。 ここで筆者が指摘したいのは、本来人間は上記の１から ５までのエネルギー過程全てを包含する統一体として 存在するべきところが、上記３項の過程がシステム的に 縮減されている可能性はないのか？ といった点にある。 この縮減が人間存在としての統一性を損ない、ひいては 他の人や組織などの有機体的全体性を感じとれなく なってはいないのか。共感する基盤そのものを失って しまっているのではないか。 システムは常に記録し、複製し、再現可能、修正可能、 予期可能な環境を人間に提供し続ける。 そんな環境の中で、生き生きとした現在性を瞬間性を 一回性の不可逆性を失いつつあるのではないかと 危惧しているのである。 ご承知のとおり人間は、 A．生への欲動として種個別の閉包エネルギーに適した ように世界を分割認識し、エネルギー維持・拡大のために 手段化する本能がある。上記３−＞４の過程方向に発生。 B．一方個別の閉包エネルギー状態から解放され 世界エネルギーに回帰したいという欲動がある。 上記３−＞２−＞１の過程方向に発生。 生命の実感や移ろいゆくものの情感などは、AとBが 絡み合いながら拮抗しつつ、上記３項の絶対現在の 過程において、生が営まれるところから生ずるのでは なかったか。 ところが今日、システムはあまりにA欲動に偏向し 過ぎてはいないか？これが筆者の第二の危惧である。 自然の生成流転から遠くはなれ、世界を道具的理性で 分割し手段化することに集中し過ぎていないか。 抑圧されたB欲動は、自然の叛乱は、必ずどこかに 吐け口を求めて動きだす。 それが静的な方向では、若者の引き籠りであり、最悪は 自殺につながる事態を招き、動的な方向としては ヒステリックなナショナリズム（特攻や回天などの ヒロイックな死）への傾斜に繋がってはいないか。 学究の緻密な検証を待ちたい。 以上 目次へ
これまで本シリーズではシステム開発における関係者の 社会心理的要素やシステム自体がユーザーに及ぼす 影響等を「批判的」な視点からに絞って述べてきた。 （「肯定的」な視点からの議論は、掃いて捨てるほど あるので…） 但し、ここに来てあまりに抽象的な話題が多すぎるとの 批判が一部に存在する。システム開発と何の関係がある のか？との疑問も筆者に集中する始末である。 （そんなに文句があるなら自分で書けよと言いたい ところを、グッと飲み込んで…） このようなシラケタ状況を鑑み、これまでの方針を 急遽変更しプログラム・コードといった具体的な問題に 今回は焦点を当てることにしたい。 システム開発において「プログラム・コード」という問題を 考えようとする場合、当然、開発者の体験がその出発点と なる。開発者の体験といっても、それはなにもいわゆる プログラミング体験であるとはかぎらない。営業があり、 企画書があり、要求定義があり、設計があり、テストが あり、ユーザー教育があり、開発後のフォローもある。 しかしシステム開発であれば必ずプログラム・コード が何らかの形でからんでくる。 プログラム・コードを問題にする場合に、われわれは どうしても、昔からコードそのものを主題に研究対象と してきた、言語設計者や一部の数学者などの意見を参考に しようとする。ところが困ったことに、そういった 「理論的」な研究のほとんどは、実際のシステム開発に 役に立たない。一つにはそれらの理論を使いこなせる程 開発者のレベルが高くないことがあり（システム開発は 護送船団方式で一番能力の低い開発者のレベルに 合わせるといった、暗黙の、かつ極めて実際的な掟が存在 する…）、もう一つには携わる開発者の能力と関係は ないが、それぞれの現場の様々な状況と関係者の要請に あったプログラミングをしないと現実に開発は進まないと いった点がある。（顧客の突飛な？要望も一概に無視は 出来ない…） そこで読者の皆さんにここでプログラミングの雰囲気を 把握してもらうために、現実の業務プログラムは著作権上の 問題もあり、かつグチャグチャのコードをいきなり 見せられても、（JUnitのソースコードのように美しい プログラムなど現実には極めて稀少である…） 意味が分からないと思われるので、ここは一つ、特別に 自作してみることにする。 さらにこれまでのシリーズの流れからあまり内容的に 遊離しても、返って読者の混乱を招く恐れがあるのでは と考え、前回説明した人間本来の思考回路における構造を プログラム化することを試みる。UML図や設計などは 一切省き、アドホックなアジャイル手法により、いきなり コードを書いてしまおう。それにはかなり高度な熟練…を、 当然「要しない」…思いつくままにコードを書くだけで 済むから… さて、システム製作の目的は、以前にも紹介した http://ised.glocom.jp/ised/ において司会を務めておられる、東浩紀教授（国際大学） の「自我」を誠に僭越の極みではあるが、「プログラム」化 することにする。 東さんはご承知の通り若いときに「存在論的、郵便的」 という著書でデリダ哲学の解説をされたことにより一躍 有名になられた。 しかしながら、以降中高年にさしかかろうとしている 今なお、本格的な哲学的な著作はない。 東さんの師匠筋にあたる浅田彰氏が「構造と力」以降 本格的な哲学作品がないことを、東さんは以前批判して おられたことがあったが…自らもないのである。 東さんのその後の著書である「動物化するポストモダン」 などは、単なる社会評論に過ぎない。 筆者は東浩紀さんのファンである。（遠い外野席からの…） その哲学的才能を高く評価するものである。（自ら哲学的 才能なくして無責任な評価＝野次？だけはする…） それだけに、氏の大学教授としての現状だけでは、いかにも 物足りない。（ついでに、ISEDの司会者としても…） そこで東さんに「自分は哲学者か」現状「哲学者に 値するか」という「重い課題」を与えることで彼自身に 考えてもらいたいと思った次第である。 プログラミングにあたっては、マイクロソフトが今ネット 環境で最も注力している新言語、C#で書いてみた。 敢えてC#を使用した理由は三つある。 一つには、C,C++,Javaと続く最もメジャーな手続き型言語の 流れにあるので読者の皆さんが理解し易い。（Haskellなどの 関数型言語やPrologのような論理型言語ではいかにも読者の 皆さんには敷居が高すぎると考えた。VBでも良かったんだが これは逆に敷居が低すぎて…） 二つには、業界でもJavaから移行してC#を使用するところが 増えてきた。従って筆者自身のトレーニングのためでもある。 三つには、これが一番肝心な理由であるが、普段みんなが 使用しているようなC,C++,Javaといった言語で書くと 筆者のプログラミングセンスの無さが一目で分かって しまう、のではないかと…。そこで敢えて、筆者も読者も 「不慣れ」なC#で書くことにした訳である。 （この辺り、いかにも言い訳がましく太宰風に…） さて、前置きはこれぐらいにして早速プログラムを 見てもらおう。 using System;//コンソールプログラムなので使用するのは //System傘下のクラスライブラリーだけ。 namespace Azuma_Tetsugaku{ class AzumaJiga { int kaisuu = 3;//無限ループを避けるため //三回に限定。 string meidai; string hitei = "と、は言えない。"; public AzumaJiga(string kadai) { Console.WriteLine("今日は東浩紀です。\n"); this.meidai = kadai;//与えられる課題を //自我内部で命題に設定する。 } public void AzumaNayamu() { Console.WriteLine(meidai + "と考える自分はいるけど、"); meidai = meidai + hitei; Console.WriteLine(meidai + "と思うんです。\n"); kaisuu--; if (kaisuu < 1) return;//三回悩んだら終了 AzumaNayamu();//自分自身（関数）を //再帰的に呼ぶ。 } } //東浩紀先生の思考回路構造はこれだけ。 //後は課題「自分は哲学者だ。」を与えて //悩ませるのみ。 class Program { static void Main(string[] args) { AzumaJiga azuma = new AzumaJiga ("自分は哲学者だ。"); azuma.AzumaNayamu(); Console.ReadLine();//コンソール表示用 } } } 以上のあまりにも簡単な？C#コード（東先生の自我構造が 単純だからとは決して思わないで欲しい…）をコンパイル 実行するとコンソールに下記アウトプットが表示される: 「今日は東浩紀です。 自分は哲学者だ。と考える自分はいるけど、 自分は哲学者だ。と、は言えない。と思うんです。 自分は哲学者だ。と、は言えない。と考える自分は いるけど、 自分は哲学者だ。と、は言えない。と、は言えない。 と思うんです。 自分は哲学者だ。と、は言えない。と、は言えない。 と考える自分はいるけど、 自分は哲学者だ。と、は言えない。と、は言えない。 と、は言えない。と思うんです。」 ご承知とは思うが、プログラム中の「//」以降は全て コメント行であり、実際の動作とは一切無関係である。 上記の、 >簡単な？C#コード（東先生の自我構造が >単純だからとは決して思わないで欲しい…）をコンパイル >実行するとコンソールに 筆者の文章はこのように「（）書き」が文のあちこちに 脈絡もなく現れて、読み辛いという感想をお持ちの 読者の方も多いと思われる。これはプログラマー時代の 名残である。コメント行と考えて頂ければ結構。 初心者時代に（今も…）コードを書いたところ、それを 読んだ人間が、誰もその意味を理解できなかった、 （自分も含めて…）という苦いトラウマがあるため、 必要以上にコメントを書く癖が付いてしまったことに よるもので、他意はない。 では、コードの解析と解釈に話を進めよう。 このプログラムのポイントは自己言及性にある。 「自分は哲学者だ。」とは自己と世界を結ぶ社会的な 関係を課題としている。「自分」が主体（主語）であり、 「哲学者だ」が社会的自己の鏡像（述語）である。 自らは「哲学者」でありたい、しかし自分の現状を 社会的、客観的な視点からみて「哲学者」足りえるのか。 鏡像的自己が成立し得るのか。その是非を東先生の 自我内で「と、は言えない。」という否定を伴った 再帰的吟味によって検証されている。哲学とは命題の 否定的な、批判的な、吟味なしには成立しない。 その否定が、否定されることにより、肯定になり、また それが否定されゆく過程こそが哲学的な思考の営みである。 前回説明したごとく、 「自分は哲学者だ。と考える自分はいるけど、 自分は哲学者だ。と、は言えない。と思うんです。」 までが現在において事実として脳細胞構造的に刻印される。 すると、次の「現在」における想起は、 「自分は哲学者だ。と、は言えない。と考える自分は いるけど、」で記憶（当初の内容）が否定型に変容して いることが分かる。 さらにそれを、 「自分は哲学者だ。と、は言えない。と、は言えない。 と思うんです。」と肯定に変わる。 次の想起と反省では、 「自分は哲学者だ。と、は言えない。と、は言えない。 と考える自分はいるけど、自分は哲学者だ。と、は 言えない。と、は言えない。と、は言えない。 と思うんです。」とまた前回の肯定が最終的に否定される。 （極めてくどいようだが、これほど偏執質でないと哲学者と いう商売は勤まらないのかも…） 現実の思考では、このように否定と肯定が単に入れ替わる だけではなく、さらに多様に、煩雑に、ずるずると、 これまでの思考過程全体が、その時点での現在において 「一瞬にして」再帰的に想起・反省されることに留意 願いたい。 デリダ的に言えば、差延が振動しながら自らに回帰して くる、あるいは自らに対する誤配を含みつつ思考は展開 される、といった解釈になろうか。 思考の現在性とは、このような再帰的な繰り返しに よって都度、形作られているものであることが、この プログラムからご理解頂けたであろうか？ 以上 目次へ
今回はプログラミングに関する技術的なことについて、 説明します。JavaとC#におけるインナークラスの取り扱いの 違いについてです。（技術的な説明になると急に「である」 から「ですます」調になりますが、他意はありません…） インナークラスはJavaにおいてイベントハンドラーとして 利用されておりますが、C#は独自にデリゲートやイベント 構文を持ち、さらにはC#2.0で匿名メソッドなどが付加 されたことで実務上インナークラスを使用するケースは、 殆どないと言ってもいいでしょう。 但し本シリーズのようにコードによる人間思考のモデル化に おいては、インナークラスを利用する価値は充分あるのでは ないかと筆者は考えております。 今回は、JavaとC#のインナークラスを利用するにあたっての 違いについて、それぞれのサンプルプログラムを比較して もらいます。 親クラスの中に子クラスがありその中に孫クラスがある といった入れ子式のクラス構造になっています。 （親亀の上に小亀、孫亀…のようなイメージでしょうか） 孫は外側の親や子のメソッド、フィールドを利用出来ます。 さらに、親クラスの外クラスも作りそのメソッドを 孫クラスから利用する方法も示します。 両者（JavaとC#)に共通する点は、内部クラスのすぐ外側の クラスしか内部クラスのインスタンスを作れない制約が あることです。完全に外からインナークラスの内部を 隠蔽することが、その理由となっているようです。 さなきだにオブジェクト指向におけるクラスの取り扱いは、 それに慣れないものにとって煩雑を極めるところ、就中 クラス・カプセル化の極致のような制限をプログラマーに 要請する次第です。 両者の違いは、Javaにおいては内部クラス（孫）から その外側のクラス（親、子）にあるメソッドやフィールドを まるで同じ孫クラスにあるのと変わりなく、透過的に利用 出来ることです。 一方C#の場合は、親であろうが子であろうが孫からその メソッドやフィールドを利用するときには、一旦それぞれの インスタンスを作りそれを経由しないと利用することが 出来ません。この取り扱い方はC#において外部のクラスの メソッドやフィールドを利用するときと全く同じです。 それではまずJavaのプログラムからご覧頂きましょう。 package inner1; //Inner1.javaです。 /*クラスOyaの中にクラスKoがあり、クラスKoの中に クラスMagoがある三重にクラスがネストした形に なっています。 */ class Oya { String oya_name = "OyaHanako "; public void m_oya() { System.out.println ("OyaのメソッドをMagoが呼んだ？"); } public void ko_yobu(){ Ko ko = new Ko(); ko.mago_yobu(); } class Ko { String ko_name = "KoTaro "; public void m_ko() { System.out.println ("KoのメソッドをMagoが呼んだ？"); } public void mago_yobu(){ Mago mago = new Mago(); mago.m_mago(); mago.name_all(); } class Mago { String mago_name = "MagoYumi"; public void m_mago(){ System.out.println ("Magoのメソッドを自分で呼んだ？"); m_oya();// 一番外のOyaクラスのメソッドを呼ぶ m_ko();// 次のKoクラスのメソッドを呼ぶ name_all(); Soto soto = new Soto(); soto.m_soto(); // 外部のSotoクラスのメソッドを呼ぶ } public void name_all() { System.out.println(oya_name + ko_name + mago_name +"\n" + "親、子、孫フィールドをMagoから呼んだ？"); //フィールドも同じクラスの中のように //内部クラスから操作可能となる。 } } } class Soto { public void m_soto() { System.out.println ("SotoのメソッドをMagoが呼んだ？"); } } public class Inner1 { public static void main(String args[]) { System.out.println("内部クラス動作開始！"); Oya oya = new Oya(); oya.ko_yobu(); //Koのmago_yobu()経由してm_mago()を呼ぶ。 } } では引き続き、C#のプログラムです。 using System; namespace Inner2 { /*クラスOyaの中にクラスKoがあり、クラスKoの中に クラスMagoがある三重にクラスがネストした形に なっています。 */ class Oya { String oya_name = "OyaHanako "; public void m_oya() { Console.WriteLine ("OyaのメソッドをMagoが呼んだ？"); } public void ko_yobu() { Ko ko = new Ko(); ko.mago_yobu(); } class Ko { String ko_name = "KoTaro "; public void m_ko() { Console.WriteLine ("KoのメソッドをMagoが呼んだ？"); } public void mago_yobu() { Mago mago = new Mago(); mago.m_mago(); mago.name_all(); } class Mago { Oya oyaI; Ko koI; //OyaとKoのインスタンスをMago内に保持する。 String mago_name = "MagoYumi"; public Mago() { this.oyaI = new Oya(); this.koI = new Ko(); //外のクラスと同様にインスタンス生成が必要。 } public void m_mago() { Console.WriteLine ("Magoのメソッドを自分で呼んだ？"); oyaI.m_oya(); // 一番外のOyaクラスのメソッドを呼ぶ koI.m_ko();// 次のKoクラスのメソッドを呼ぶ Soto soto = new Soto(); soto.m_soto(); // 外部のSotoクラスのメソッドを呼ぶ } public void name_all() { Console.WriteLine (oyaI.oya_name + koI.ko_name + mago_name+ "\n"+ "親、子、孫のフィールドをMagoから呼んだ？"); } } } } class Soto { public void m_soto() { Console.WriteLine ("SotoのメソッドをMagoが呼んだ？"); } } class Program { static void Main(string[] args) { Console.WriteLine("内部クラス動作開始！"); Oya oya = new Oya(); oya.ko_yobu(); //Koのmago_yobu()経由m_mago()に繋がる。 Console.ReadLine();//コンソール出力用 } } } 上で提示したプログラムのアウトプットはJava、C# 双方、下記の通りです。 「 内部クラス動作開始！ Magoのメソッドを自分で呼んだ？ OyaのメソッドをMagoが呼んだ？ KoのメソッドをMagoが呼んだ？ SotoのメソッドをMagoが呼んだ？ OyaHanako KoTaro MagoYumi 親、子、孫のフィールドをMagoから直接呼んだ？ 」 上記で述べたJavaとC#のコードで、インナークラスにおける 文法上の違いを除けば、異なる部分は、 「System.out.println」と「Console.WriteLine」だけ！ いかにJavaとC#が似た言語同士であるか、よくお分かり ですよね。まさにこれは、後発であるC#にとっての 諸刃の剣です。 Javaからの移行が極めて易しい面と、移行してもJavaと ほとんど変わらない（メリットが…）面です。 ドット・ネット環境を利用するのであれば、J++という 手段もあり、C#が今後Java以上に伸びるかどうか…。 余談はさておき、上記のとおりC#がインナークラスの 制約をJavaよりも厳しくしている理由は、よりコードの 安全性といった面を重視しているためでしょう。 総じてC#は「virtual」と「override」修飾子を必ず ペアーで書くように義務付けたり、大規模システム 開発用に言語仕様が特化している傾向にあります。 従って、孫とは言え親や子のメソッドやフィールドを 無制限に使用できることは安全性の観点から問題がある、 とマイクロソフトは考えたんじゃないでしょうか。 開発効率の向上のため、出来るだけシステム・エラーを コンパイル時に検出しようとするものは、まさにそれ故に 少々コードが煩雑になろうが安全性を優先し、しすぎる ということはないのであろう。 コンピュータ言語の仕様を作成する立場から言えば、 制約が少ない方がシンプルに実装出来ます。 プログラマーに詳細を書かせれば書かせるほど、実装は 楽になるように、つまりマシーン側の負荷が少なく済む ように一見感じる方も多いと思いますが、実は逆の 場合が多いのです。クラスのカプセル化などを厳しく するほうが実装としては、手間がかかります。 だから、最近できるスクリプト言語はその辺りがゆるい 訳です。それを「言語としての自由度が高い」と宣伝する ところに、言語開発者としてのある意味「腕の見せ所」が あるのです。これも余談ですが… では、人間の思考をインナークラスによってモデル化する 場合に、Java方式が良いのか、C#方式が良いのか。 人間の思考時における脳細胞群の部分的な活性度に ついては、ある程度計測出来るようになりましたが、 具体的に思考がどの脳細胞モジュールでどのように 加工されているかまでは、今のところ分かっておりません。 現実に脳細胞モジュール間で制約があるのか、それとも 透過的なのか、分からないのであれば、どうでもよいような 気がしますが、それをプログラムコードでモデル化し 説明する場合において、透過的な構造よりも制約的な 法則性があったほうが、読者の皆さんがそれを理解する 上では、より明示的になるのではないかと考えました。 従い次回より、C#による簡単な思考構造の解析を試みたいと 思いますので、ご期待下さい。 お分かりの通り、筆者はプログラミング手法において再帰や 入れ子構造に親近感を抱いております。 族的には（暴走族ではなく…）関数言語族出身だからと いったことが一つ考えられます。AIにおいては論理型の PrologとともにLispやSchemeなどが、かっては繁栄を 謳歌しておりましたが、今やオブジェクト指向手続き型 言語に押され、関数言語族は見る影も無く落魄して おります。それに付随してAIも…。 ようやく最近Haskellなどが本屋の店頭で見られるように なりました。以前「CraftManShip of Haskell」などを 読みながら、Monadに関する概念や機能などを群論の 視点から友人達と議論していたことが、つい昨日の ように想い出されます。 「少年老い易く、青春忘れ難し」 以上 目次へ
前回９月末に以下のように書いて、 >従い次回より、C#による簡単な思考構造の解析を試みたいと >思いますので、ご期待下さい。 すっかりご無沙汰してしまいました。上記思考構造の解析は 簡単なものから、どんどん複雑化してしまい…これは システム開発でも良くあるケースでアイデアや状況の変化 から本来予定していた仕様が、思いもかけず変容、膨大化し 収拾がつかなくなることがあります。当然費用負担の面でも 客先とハードなネゴが展開される訳ですが、これも泥沼状態 のまま期限に追われて開発作業だけは突っ走る（進捗して いるのか、それとも無数のバグ取りが別のバグを生んで いるのか…）ことになる。 上記の「C#による簡単な思考構造の解析」も結局C#の スタティックなRTTI機能じゃ駄目だぁ。という意見に押され 急遽言語をダイナミックなスクリプト言語に変更するという 「最悪」の選択を行ってしまいました。開発の途中で ツールを変更するのは、一からやり直しと同じですから 避けた方が無難です。しかしこれは仕事じゃないから 思いつきのままやってしまった。スクリプト言語仕様と ライブラリー群の学習をやりながら、脳科学の神経細胞 構造を勉強しながら…フッサールやベルグソンも読み返し ながら？？？ で、お決まりの「動かないシステム」が出来上がった 次第です。 辛うじて人間が音楽（メロディーと歌詞）を理解する、 記憶と予測構造をパターン化する程度しか出来なかった。 曲目も「春の小川」だけ… この程度なら別にC#でも十分実装可能なプログラムで スクリプト言語でやる必要もなかったと後でみんなで 反省したところです。 そうは言ってもBlogやHPで公開するような規模には 収まりきらないので、これはこれで機会があれば、 遺伝的アルゴリズム、ニューロンシステム、それを 脳内細胞構造的に重層構造化して、海馬機能を付加する ことにより知覚と記憶と判断機能を現象学的に意味づけ したようなものを「簡単にシステム化」しては いけませんよ！ というサンプルとして学会の論文にでも発表しようかと… 何よりも興味深かったのは、「素人が」脳科学を勉強すれば するほど「簡単に」システム化「出来そうな気」がして来る ところです。冷静に考えればシステムのアルゴリズム自体が 人間の思考を模倣したものですから、オリジナルー＞模倣 （コピー）で「かのようにRepresent」する行為を逆流させて 模倣ー＞オリジナルに迫ろうという試みですから出来そうな 気がするのは当たり前ですよね。 ポイントは「簡単なもの」を作ろうとして始めることです。 （結局、簡単なものしか出来なかったんですが…） やり始めるとそのブラックホールのような思考吸引力は すさまじいものがある。出来そうな気がどんどんしてくる。 中世の錬金術みたいなものですね。それが証拠にネット上 どのコンピュータ言語でもAIアルゴリズムの実装が 溢れ返っています。 しかしところがどっこい、嵌り過ぎると危険です。 どう表現したら良いか分かりませんが、合わせ鏡の中間に 自分が居てその思考を果てしなく追うような感覚とでも 言いましょうか。 日常感覚を突き抜けてしまう部分がかい間見えるような… ある意味若い方が危ない、「コテコテ」に常識と日常感覚が 固まった年寄りの方が安全なんでしょう。 （でも年寄りは、そもそもこんなことには興味がない…） いずれにしても「AI」は恐ろしい。 今回の実験で気付いたこと： １．人間の生命欲動と同一性論理は密接不可分に連結して いるが、それぞれは別のものである。但し同一性論理が なければ人間は認識さえ出来ない。勿論言葉も使えない。 ２．自分という概念、思考は同一性論理に基ずく社会的 仮想他者視線からのそのまた仮想である。従ってデカルトの 「我思う故に我有り」の「我」は仮想的な仮想概念である。 ３．システムはまさに同一性論理から生まれた構築物・ 人工環境であり、人間はそのシステム的な自己運動の中に 必然的に埋没し同質化されざるを得ない。 ４．一方人間本来の生命欲動におけるカオス的な圧力は、 システム化され同一性論理が貫徹されればされるほど、 吐け口を求めて噴出の機会を求める。 最後にネックになったのは、システム化による人間として の自由と意味が喪失する事態をどう回避するのか。 といったところです。 勿論、絶対的な自由や意味は存在しません。 一定の歴史・宗教・文化・制度・社会的な思考フレームに おける自由や意味ではあるが、「人間」にとっては 生命欲動と同一性論理をリンクしている不可欠な 要素なんです。即ち上記の3項と4項をなんとか仮想的に 結びつけている。 まだ現在においては… というのは、歴史・宗教・文化・制度・社会的な 思考フレームがシステムによる同一性論理で 貫徹されてしまったら、その中における人間は 「人間」と称するに値する「動物」なのか？ かってのナチズムや共産主義のような全体主義的な 世界でさえ、いやそれだからこそ余計に民族や主義的 ロマンの残滓が色濃く残っている。 システム全体主義には科学信仰しかない。科学信仰は 同一性論理に基づく道具的理性の発現でしかない。 今はまだ収益という資本主義的な要素と結びつくことで なんとかロマン＝豊かさの名残りがあるが、それを 超えた先は荒涼たる道具的世界しか残らない。 このシステムエンジニアの根幹を震撼する問題に ぶち当たり、本プロジェクトは儚く霧消すること になりました。 以上 目次へ
今回の思考回路プログラムの実装は完全な失敗には終わり ましたが、随分システム開発に関する意見の違いを認識 することができました。 前回説明した通りプログラミング言語をC#から動的な スクリプト言語に変更したのですが、メンバーの中に はかなり抵抗感があったようです。スクリプト言語の 選択ですが、オブジェクト指向も高階関数のような関数型 言語のようなことも出来るということで、日本ではあまり 馴染みがない言語ですがPythonを使ってみようということ になりました。 ご承知の通りスクリプト系の言語は型宣言が不要です。 従って、Pythonでは x = 'Hello' x = 1 としても何ら不都合はありません。 print x =>1 最後に代入された値が戻ります。 この辺りは、変数名をstrXとかintYとかにして、その ルールを守るようにすればそれほど抵抗感はない。 （ルールを無視してstrX = 1も可能なので、何が 出てくるのか使ってみないと分からない不安はあるが…） なおPythonの場合、C++のリファレンスと同じで値を 代入しないと使えない。つまり、代入を伴わない変数宣言は 出来ないところが慣れないと戸惑う部分の一つです。 さらに、これが一番抵抗感が強かった言語仕様ですが、 例えばJava,C++やC#などのスタティックな言語では クラス定義されたものが、そのインスタンスを生成する 訳で、その振る舞いや属性を変えようとすればクラス定義を 変更する必要があります。 換言すればインスタンスの振る舞いは、クラス定義部分さえ 読めば分かるということです。 勿論スーパークラスから継承されたクラスであれば、 それも確認する必要がありますが、少なくともクラス 定義内の中の話です。 ところがPythonなどの動的な言語の場合、インスタンスが 勝手に振る舞いや属性を追加・変更出来るのです。 Rubyなども特異メソッドと称して同じ機能があります。 これまでクラス定義が設計図でインスタンスがその実体だと 説明されていたオブジェクト指向の概念が、設計図通り ではない実物が勝手に作成出来てしまう。 言葉で説明しても分かりずらい面もあると思うので 簡単なプログラムを書いてみましょう。 まずはC#から、 using System; namespace PyComp { class CompLang { public string nameLang; public void work() { Console.WriteLine(nameLang + "でコードを書く"); } } class Python : CompLang { public Python(){ this.nameLang = "Python"; } } class Program { static void Main(string[] args) { Python py = new Python(); py.work(); Console.ReadLine(); } } } 特に説明の必要もないような簡単なクラス継承に よるコードです。py.work()の中味はスーパークラスで 定義されています。 O/Pは ＝＞Pythonでコードを書く です。 まず、これと全く同じ仕様のPythonのコードを書いて みます。（#以下はコメント行です。） class CompLang: nameLang = "" #スペースを代入しておく def work(self): print (self.nameLang + 'でコードを書く') class Python(CompLang): def __init__(self): #コンストラクターです。 self.nameLang = 'Python' if __name__=='__main__': #上記のif以下は通常のmain()関数ではなく #このファイルのクラスが別のファイルから #流用された時に以下のコードを無効にするための #おまじない？のようなものです。 py = Python() py.work() O/Pは、当たり前ですが… ＝＞Pythonでコードを書く です。 次にスクリプト言語におけるインスタンスの自由（奔放？） な動作を検証してみます。 上記PythonのコードにRubyクラスをクラス定義に追加して、 さらにnandemo関数を実行文の中で付加します。 class CompLang: nameLang = "" #スペースを代入しておく def work(self): print (self.nameLang + 'でコードを書く') class Python(CompLang): def __init__(self): #コンストラクターです。 self.nameLang = 'Python' class Ruby(CompLang): def __init__(self): #コンストラクターです。 self.nameLang = 'Ruby' if __name__=='__main__': py = Python() rb = Ruby() py.work = rb.work #インスタンス同士でメソッド交換。 py.work() def nandemo(): print 'Pythonはなんでも有りか？' py.work = nandemo py.work() #まったく別のメソッドに変化する。 py.work()のO/Pは、驚いたことに…、って当たり前ですが、 それぞれ、 ＝＞Rubyでコードを書く ＝＞Pythonはなんでも有りか？ になります。 総じて大規模システム開発経験者はこのような言語仕様を 嫌う傾向にあります。一万行やそこらのシステムを数人で 開発するなら問題ないでしょうが、百万行単位のシステムを 数千人の下請け会社のプログラマー達を統制しながら開発 するような時に、こんな言語仕様をてんでばらばらに 使われたらとてもシステム挙動をコントロールすることは 不可能です。一方、スクリプト言語派は「出来ることは 出来ないより良いことだ。」という信念の基に、どう 使用するかは使う側の問題であると主張する。そもそも 動的とは最大限の実行時自由を保証することであり、 制限することはその原則に反すると。 実務的なコードを利用する上での問題は、上記の通りです。 これを人間の思考認識パターンに還元して考えてみましょう。 オブジェクト指向の場合のクラスはインスタンス生成の ひな型です。つまりインスタンスのアイデンティティー 同一性の原型になっている訳です。上記の例で py = Python()で作成されたインスタンスがクラス定義外で ＝＞Rubyでコードを書く といったOPをすることは、アイデンティティーから逸脱 するような感覚を抱かされるといったところでしょうか。 ある意味これまでのオブジェクト指向の既成概念を破壊 している。勿論プログラムですからC#でもgoto文で スパゲッティープログラムを作ることは可能です。 しかし、インスタンスを勝手にクラス定義外では変更 出来ない。これはプログラミングが発達し、人間の認識 限界をカバーするための関心分離とその秩序を維持する 不変のルールだった訳です。 それが破れたことにより、新たな「無秩序への頽落」の 予感に襲われるといった現象でしょうか。 前半で述べた、 >変数名をstrXとかintYとかにして、その >ルールを守るようにすればそれほど抵抗感はない。 といった極めて単純なルール、文字列変数にstr、 整数変数にintのそれぞれプレフィックスを付けて 識別するルール自体、も一種の環境です。つまり そのルールを大多数の開発者が守る限り。 後半のインスタンスがクラス定義以外でその振る舞い や属性を変更することも、開発者にとっての環境です。 スクリプト系支持者にとって見れば、「問題だと思えば その機能を使わないルールにすれば良いだけじゃないか？」 と主張するでしょう。 ではその違いはどこにあるのか？ 前者は参加する開発者の自由意志に完全に依存した 環境であるが、後者はJava,C++,C#などの言語を使用した 場合はシステムによって強制的に禁止されています。 大規模開発者の抵抗感は、自由意志に基づくルール （コーディングスタンダード等）に関しては比較的 緩やかであり、後者の「システム強制環境が無い。」こと に対してより強く反応しています。 この現象を分析すれば、自由意志による環境より 強制力のある環境のほうが、それに対する適応性と 規制効果およびその安心感は強いということになる。 これに更に生活手段としてコンピュータ言語を使用して いると一層、拒否反応は強くなる。日々身体的に言語操作 が刻みこまれ、反射神経的にコーディングするレベルに なると「ツールが思考を規定する。」それが変わることは、 プログラマーとしてのアイデンティティーをも揺るがす 事態になってしまう。 寧ろ、そういった拘りに鈍感な人で優秀なプログラマーで ある事例は極めて少ない。 ヴァイオリニストが弦の張り具合に敏感であることや バッターがバットの握りの太さに神経質なことなどと まったく同様に、身体感覚化したものが、生活の糧と 結びついているのです。プログラミングを知らない人から 見れば、何が問題なのか分からないような些細な部分で あっても専門的にその分野に集中して「生活」する 人間にとっては死活問題であることが、ご理解頂ける でしょうか。私はここでスクリプト系言語の好い加減さを 非難している訳でも、大規模開発が何より重要だと 主張しているのでもありません。そうではなくて、人工的 な言語が人間の思考や行動に及ぼす影響を論議している のです。たかが、一万行のシステムを数名で開発する際に C#の言語仕様で要求される、override修飾子が不可欠とは 思えません。言語にはそれぞれに適した使い方があって 当然です。しかしながら、それを使用する人間の思考や 行動には確実に反映され、依存性を生み出すことを云いたい のです。 プログラミング言語は20世紀半ばから発生し、オブジェクト 指向言語が生まれたのは1970年代です。それがJavaなどの 言語の発展とともに日本でメジャーな開発言語となったのは 21世紀に入ってからです。これだけ浅い歴史の中で、それも ドッグイヤーと云われるほど進歩の早い情報通信分野に おいて、オブジェクト指向言語を使用し、これまでの大規模 開発の経験から、醸成された既成概念の堅固さとそれから 逸脱することの激しい抵抗感は、今回の開発のテーマである 人間の思考回路設計にとって実に興味深いものでした。 以上 目次へ
|