消費者マインドのcommon sense化と視野狭窄

バブル崩壊後の失われた10年から今日まで、日本で何が起こってきたかを振り返ると、新自由主義のトリクルダウン理論と、それがねじれた形で表出した消費者マインドの定着がある。

「消費者マインド」とは、要するに「最小限のコストで高い価値のものを手に入れることが社会的な成功である」ということである。一方で、トリクルダウン理論(先富論)は、富める者が富めば、貧しい者にも自然に富が浸透するということである。しかし、この理論の落とし穴は、(端から見たら)富んでいる人が「自分は、まだ富んでいない。自分は、もっと多くを手に入れるに足る者である」と思ったとたんに、富が配分されなくなることである。この、「もっと多くを手に入れるに足る者」という考えかたと、「最小限のコストで高い価値のものを手に入れる」という考えかたが、一方は経済的上位の人たちから、そしてももう一方は下から浸透し、それらが反発せずに親和した状態が今日の日本のcommon senseとして深く定着しているように思える。

小泉政権の2001年~2006年は、まさしく、このトリクルダウン(そしてその落とし穴の考えかた:私はもっともらえる人だ)が日本中に浸透していった年である。この期間に何が起こったかというと、ユニクロの低迷からの回復(2005)、ライブドア事件(2005)、そして中田英寿が現役引退をし、”自分探し”をはじめたのが2006年である。

中田英寿の”自分探し”というのは、要するに「私はもっともらえる人だ」という考えかたの典型である。自分の成長に視点があるのではなく、”もっともらえる自分”というものがすでにあって、それは変わらない存在であり、その上で価値のあるものや社会的な状態(ステータス)を手に入れることが、自分という存在にとって最も興味のあることであるという考えかたである。

今日のビジネス界に目を向けると、”もっともらえる自分”なので、経営責任を取らないことに罪悪感を感じない経営者が増え、新しい市場を創造するはずのベンチャー魂が、うまくコストをかけずに(つまり、できるだけ努力をしないで)儲けるという思想の人たちの集まりなってしまっているように思える。

小泉内閣後の自民党のドタバタのあと、民主党政権に変わって社会的な価値観も変わるのかと期待していたが、消費者マインドの慣性は思いのほか強く、逆に、より深まり、おそらく悪化してきている。そしてさらに、震災による原子力発電所事故のあとの「けじめって、つけなくてもいいのね」感が、それに拍車をかけているように思える。
驚くことは、大学での多くの学生の質問が「その授業は就職に役に立ちますか?」であり、いかに少ない努力で就職に役に立つ授業をとるかに関して、まさしく、ディスカウントショップでの買い物と同じ心理で”学ぶこと”を選んでいることである。

日本社会全体(もしかすると、グローバリゼーションを標榜する国全体が)が消費者心理に陥り、”努力しないで値打ちのあるものを手に入れることが社会的に成功すること”という考え方に染まっているように思えてならない。つまり、短期視点、部分最適という狭い視点に陥ってしまい、市民としての成熟度が極端に低下しているように思える。

どうしてそのような心理に陥ってしまうのか。チンパンジーの研究の第一人者であるジェーン・グドールの逸話(エサを与えられたサル)を思い出した(近日中にアップ予定です)。

 

逆Vモデル

企業が顧客にもたらすべき価値の定義から、それを支援し実現するためのITシステム構築までの橋渡しの方法はどのようなものになるだろうか。Vモデルは、システム開発のための要件定義から受け入れテストまでのライフサイクルを表している。

従来のシステム開発は、構築するITシステムに対する要求を受け入れ、解釈し、ITシステムの要件として定義するところからがスタートであった。そして、システム要件定義よりも前、すなわち、システムに対する要件を導出するまでのプロセスはエンジニアリング領域の対象外であった。しかし、顧客価値を生み出す業務プロセスこそが企業の根幹の技術であり、ITシステムはそれを支援し実現するためのツールであることを考えれば、システム要件を導出する前の工程こそが技術化すべき領域であると言える。IPA(情報処理推進機構)では、 システム要件定義よりも前の工程を「超上流工程」と呼び、またCMMIでは、「要件開発プロセス」として、エンジニアリングプロセス領域の中に取り込んでいる。この超上流の工程モデルとして「逆Vモデル」を考案した。逆Vモデルは、Vモデルのさらに上流、Vモデルが上下反転したプロセスとして示すライフサイクルモデルである。

逆Vモデルは、3階層の抽象度を持つ超上流工程のライフサイクルモデルとして定義している。我々がシステム開発で必要とするものはシステムに対する要件である。ところで、対象とするシステムを構成するものは、組織や人、そしてシステムといった”モノ”のレベル、すなわち、目に見える存在である。一方で、企業が顧客に対して価値を創出するのは、人やシステムといった”モノ”のレベルを横断して機能するプロセスである。逆Vモデルでは、モノのレベルの上位として業務プロセスを定義する。モノのレベルである人やシステムの上を”コト”としての業務プロセスが流れることによって、顧客に対する価値(カチ)を生み出す。要するに、そこで何が行われているかがコトのレベルである。しかし、コトのレベルである業務プロセスはほとんどの場合は目に見えない。可視化、すなわちモデル化が必要となる。

逆Vモデルでは、システムの仕様であるモノのレベル、業務プロセスをモデルによって外在化したコトのレベル、そして企業が提供する価値を発見し定義するカチのレベルの3段階の抽象度を定義する。業務プロセスのモデル化は、システム要件と顧客価値とをつなぐものとなる。つまり、まず提供すべき顧客価値が定義され、それを実現するたの業務プロセスが考案される。そして、考案したと業務プロセスの実行を支援するためにシステムに対する要件が定義される。

重要なポイントは、これらの各抽象度レイヤーはお互いに独立しているということである。上位のレイヤーは下位レイヤーへの要件となる。多くのBPRやBPMで見られる問題は、業務プロセスとシステムの仕様とが混合し、描いた業務プロセスのモデルがシステムの仕様となってしまっていることである。

エンジニア視点が引き起こすよく見られる誤りは、顧客価値、業務プロセスを明確に定義せずに、現行のシステム仕様から、いきなり更改システムの仕様を考えてしまうことである。その結果、なぜそのような仕様になっているか、すなわち、おおもとの要件としての顧客価値や業務プロセスとの対応が保守可能な状態に置けなくなってしまうことである。その結果、業務プロセスの改善や、そもそもの顧客価値の戦略見直しに対して、対応するシステム要求へのトレーサビリティーが取れない状態になってしまう。さらに、システム利用者からのシステム改善要求に対して、問題を引き起こしている根本原因の業務プロセスや顧客価値に立ち戻らないまま、要求に対するシステム改善を行うことになってしまう。このように、いわばパッチ当てのような機能改善が積み重なり、システムの利用性が逆に低下してしまう原因となってしまう場合も非常に多い。

逆Vモデルでは、 逆Vの右側(ライフサイクルの後半)は、上述したように、顧客価値から業務プロセスの設計を経てシステム要件定義へとつながるDesign(設計)のプロセスである。一方、 逆Vの左側は、現行システムの分析からはじまるReverse Engineeringのプロセスとなる。なぜReverse Engineeringが必要かというと、現在のシステムがどのような業務プロセスを想定して作られているか、また、顧客に対してどのような価値を提供するために設計されているかが外在化されていない場合がほとんどであるからである。現在の業務プロセスは、顧客に対してどのような価値を提供すべく考案されたものなのか、そして、システムは何故そのような仕様になっているかを推察しなければならない。つまり、現行システムの”設計思想(意図)”をリバースする必要がある。

Reverse Engineeringのプロセスの最初、「現行システム分析」では、現行システムのリソースとその外部仕様を洗い出す。リソースとは要するに「ヒト、モノ、カネ」である。コンピュータなどの情報機器(例えば、FAXや電話なども含まれる)とその外部仕様、そして業務遂行に関わる人の洗い出しをおこなう。さらに精度を上げるのであれば、要求されるコストの分析を行う。コスト分析を行うことによって、改善した業務プロセスとシステムのROIの評価を行うことが可能となる。
また、「As-isプロセス分析」では、現在の業務プロセスのモデル化を行う。システムが見えるのに対して、プロセスはそのままでは見えない。業務プロセスを見えるものとして描き出すモデル化の方法がポイントとなる。

上記、逆Vモデルに関して、現在、主にエンタープライズ系のシステム開発において実際に適用し、モデルの妥当性の検証を行っている。

Back to the Future

『科学と技術がもたらした変革のはざまで、おそらくすべての国のなかで日本だけが、これまである種の均衡を見出すのに成功してきました。このことはたぶん何よりも、日本が近代に入ったのは「復古」によってであり、例えばフランスのように「革命」によってではなかったという事実に、負っているのでしょう。』レビィ=ストロース

「悲しき熱帯」(中公クラシックス2001年版)によせられたレビィ=ストロースのてばなしともいえるメッセージは、現在、岐路に立つ日本人が、立ち止まり、そして歩むべき路を示唆しているように思える。もちろん、レビィ=ストロースの語る「復古」とは、浅薄な日本的国粋主義への共鳴などというものとは、およそ無縁なものである。

西洋においては、自然(一番の自然は、人体である)は管理可能な対象であり、革命は、あらたなディシプリンを浸透させ、過去を断ち切る。一方、日本においては、過去を否定し新規のレールを敷設するのではなく、ターニングポイントに行きあたったときに常に「われわれとは何であるのか」を問いなおすことによって、過去と変革との均衡ポイントを見つけてきた。

「われわれとは何であるのか」ということは、ひとつには(そして、重要なこととして)労働観として認識される。日本人にとっての労働は、人も含めた自然とどのように折り合いをつけるかということであった(一方で、西洋のそれは、自然を征服し、管理するというものである)。

戦後、我々は、都市と農村との折り合いを模索してきた。しかし、3.11のあとの原子炉事故は、都市と農村とが年月をかけて折り合いをつけてきたカーテンを一気に引き払い、両者の間に横たわっていた深淵を我々に見せつけているように思える。今の我々は、ベールが剥ぎ取られて露わになった深い淵に立ち尽くし、そして、その淵の前に立って、「われわれとは何であるのか」を、ふたたび考えているのかもしれない。そして、(強制的に、もしくは自ら進んで受け入れてきた)都市に代表される西洋の労働観に対して、日本人本来の労働観の再認識が、いま、まさに求められているのではないだろうか。

日本人の労働観の再認識と、科学技術が自然とどのように折り合いをつけるべきかを、実践を通しながら考えてゆくことをテーマにした、プロジェクト型のシステム開発演習授業を構想している。

プロセスのモデル化が難しい理由

「活動の本質は”変化すること”であり、すべての活動をそのまま(タスクの視点で)描くことは非常に困難なのである。」Keen, 1997

企業のITシステムを中心とした業務改善を目的に、ビジネス・プロセス・リエンジニアリング(BPR)や、ビジネス・プロセス・モデリング(BPM)といった取り組みが、90年代からの流行語として今もなお続いている。ネット上で検索をするまでもなく、様々な研究者がこの問題に取り組み、また多くの書籍が刊行されている。彼らは、企業が顧客にもたらすべき価値と、それを実現するための企業内プロセス、そして企業内プロセスを支援し、実現するためのITシステムとをつなぐために、各人が各人なりの解釈をし取り組んでいる。ところが、実際のところ、長年の取り組みにも関わらず、明らかに成功したという事例を耳にすることが難しいのが現状である。

業務プロセス設計は、顧客視点から要求された品質目標に対して、どのように業務を進めたら経営ゴールを満足し、さらに経営リスクを低減できるかを設計することである。そして、業務プロセスを設計するためには、目に見えないプロセスを外在化、すなわちモデル化する必要がある。一方で、「ワークフローとしては定義することが難しいがビジネスにおいては無視できないプロセスが存在する」と言われるように、業務プロセスはモデル化すること自体に難しさがある。

Davenportが「組織の階層構造が、もっぱらある時刻の断面から責任の所在と報告関係をとらえようとするのに対して、プロセスの構造は、いかにして組織が価値を提供するかという動的な視点に立つ」と述べているように、プロセスのモデル化とは、価値の提供という目的に対して、組織を構成するリソースがどのように動的に変化するかを描くことである。ところが、システムの動的変化を記述しようとして、多くのモデル化手法が「ビジネスを”ある価値を持つものを生み出すことを目的としたアクティビティ(活動)の列”として見るという立場(ワークフロー的視座)」を持ってプロセスを記述しようとする誤った視点に陥ってしまっている。

Keenが「人間社会の営みの根幹は活動の調整である」と述べているように、活動は常に変化する。モダン・タイムスで描かれた固定化された活動は、人間性を阻害し生産性を引き下げる。変化、すなわち活動の調整こそが、人間の柔軟性の現れなのである。現在みられる、もしくは用いられているプロセスのモデル化方法のほとんどはタスク視点でのモデル化である。タスク視点では、プロセスを描くために、活動をいかに固定化してとらえて描くかという視点をとっている。そこでは、Keenの言うような、活動の調整的視座が欠けてしまい、人の活動を正確に描こうとすると、すべての場合が描けているのかという問題にあたってしまう。その結果、多くの業務プロセスモデルでは、人の活動ではなく、システムの仕様(もちろん、固定化されたものである)を描いてしまっている。活動の本質は”変化すること”であり、すべての活動をそのまま(タスクの視点で)描くことは非常に困難なのである。

さらにKeenは続けて「調整は言語に依り、言語は要求と約束に依る」と述べている。技術は「客観的法則性の意識的適用」であると定義
されるように、言語化することによって、技術であるプロセスを目的的に意識することができるようになる。また、プロセスの中でのコミュニケーションは、「その人が果たすべき役割に対する期待によって変わってくる」ものである。つまり、プロセスを描くというもうひとつの側面は、プロセスを言語化するということである。多くのモデル化手法がそのノーテーションの説明にほとんどのページを割いているが、重要なことは、プロセスを言語化する際の明確な指針、視点の置きかたであり、ノーテーションは、極論を言えば”実はどうでもよいこと”なのである。

 

プロセスは技術として立ち現れる

蒸気機関の発明が産業革命を起こしたと言われるように、産業活動における最も劇的な変化は新しい技術の発明と生産ツールとによってもたらされると言われている。ところで、この理解は正しいのであろうか。
プロセスという考えかたは、今日のIT社会ではじめて議論の遡上にのぼったわけではなく、古くは、といってもかなり古く、時は200万年前の旧石器時代にまで遡る。そこでは何が行われていたのか、「人間の歴史」でイーリンが描写したマンモスの狩猟場面を引用してみよう。

『人間たちは、一群となってマンモスの後を追った。一本の槍ではなく、何十本という槍がその毛むくじゃらの脇腹を突き刺した。足も手も、何十本もあるもののような人間の群れは、マンモスを追った。そこで働いたものは、単に何十本という手だけではなく、何十本という頭だったのである。(中略)マンモスの重量をもってしたら人間をふみつぶすことなどは何でもなかった。が、人間たちはこの巨大な獣に打ち勝つために、大地もやっとそれに堪えているようなその重量を逆に利用したのであった。人間たちはマンモスを四方からとりかこんで草原に火をつけた。マンモスは輝く火のために目は狂い、毛は焼けこげて、ただもう火が追いつめる方向へかけ逃げた。が、その火は、人間たちの狡猾な考えによって、マンモスをまっ直ぐに沼地の方へ追って行った。沼地へ落ち込むと、マンモスは沼の上に立てられた石の像のように沈んでいった。マンモスは雷鳴のような吼え声で、大気を震わせながら、足を沼地から抜き出そうとして力んだ。が、そうやって体を動かす毎に沼地はますますマンモスを引き入れた。そうなれば人間たちは、もうマンモスを打ちのめすばかりであった。』

産業革命の起源に習えば、旧石器時代の技術は、槍や石斧ということになる。しかし、イリンの描写が活き活きと描き出しているのは何であろうか。マンモスを捕えるための一連のプロセスである。旧石器人たちは、マンモスを捕らえるためのプロセスを開発したのである。そして、開発したプロセスを実行に移すための手法として、すでに手にしていた火や石器の利用方法を考え、そしてその利用目的に従って、(すでに持っていたであろう)槍や石斧、そして松明などのツールの最適化を図ったのである。


産業革命に時を進めてみると、産業革命を起こした技術は蒸気機関ではなく、チャップリンが「モダン・タイムス」を通して描き出したように”分業による流れ作業”というプロセスなのである。そこでは生産プロセスが個々の労働者が遂行できる単純な作業単位に分割された。それによって、労働者は自分に与えられた単純作業だけを理解すればよくなった。その結果、人を入れ替え可能な部品として扱うことができるようになり、人件費を極限まで下げることができるようになったのである。つまり、新たな生産プロセスと資本主義の目的とが結びついたことが産業革命の本質であると考えられる。


ソフトウェア工学のレイヤーモデルが示すように、品質目標を達成するためには、まず、プロセスの設計が必要である。そして、プロセスを実行するために手法が考案され、手法の実行を支援するためのツールが開発される。ともすると、最上位にあるツールにのみ目がいってしまい、ツールがすなわち技術であると捕えられがちである。しかし、技術とはプロセス・手法・ツールの総体である。そして、技術の本質はプロセスにあり。プロセスは、意識的な適用を通して技術として実体化するのである。

 

Googleのシステム管理と再稼働問題

Googleを支えている大規模なサーバシステム。その管理方法は従来のシステム管理の方法とは大きく異なっているらしい。つまり、1台1台のサーバの状態を監視するのではなく、ある一定時間が過ぎたものから順次廃棄し、新しいものに入れ替えるそうである。

機械システムを信頼性の高いものにするためのこれまでの方法は、堅牢に作る、ということである。負荷やリスクを見積もり、投資対効果を判断して(経営リテラシーの高い経営者であれば)最大限の丈夫なシステムを作る。しかし、エントロピーが増大しないシステムはない。すべてのシステムは、摩耗し、酸化し、劣化し、運用ミスが蓄積され、さらに(経営視点からすると)”想定外”のトラブルに見舞われる。

一方で、生物は、エントロピー増大によってシステムが修復できない状態になるよりも先回りして自らを能動的に壊し、再構築を繰り返すことによって、38億年もの間、環境に順応し進化を遂げてきた。生物が採用しているこの戦略を、Googleのシステム管理は採用しているのである。

壊れるまで使い、壊れたら修復する。そして、再稼働するという対処方法は、短期的な視野からすると低コストであるように思える(そもそも、「コスト」という考えかた自体が、短期的ライフサイクル視点であるが)。しかし、システムが次の世代へもわたる継続性を得るためには、生物が採用しているような、長期的視野に立ったシステムのエントロピーをコントロールする戦略を考えるべきである。そのような視点を持っていたのであれば、「千年に一度の」未曾有のアクシデントによって取り返しのつかない事態に陥いる、という事態にはならかったのではないだろうか。

 

手段が構えに及ぼす影響

「Smalltakはテスティングの習慣がある。ちょっとプログラムを変更したら、ちょっと動かしてみる。というインクリメンタルなサイクルを回す。」Kent Beck

「肩凝り」に相当する英語は無いらしい。英語でそれに近い表現は、”pain on the back”であり、単純に、肉体的に痛む部位を示しているにすぎない。一方、日本語の「肩凝り」は、肩を中心とした筋肉が痛いというだけではなく、社会的、精神的なストレスの訴えをも表明している。

私たちは、言葉を使うことによって、私たちの周りの価値観や価値体系を、自立的に表現していると思っている。しかし、事実はその逆であることをソシュールは教えている。私たちが、満天の冬の星空からオリオン座を切り出すことができるように、言葉を使うことそれ自体によって、ものの見かたや考えかたが、私たちの中に強く存在するようになる。私たちは、言葉を使うことによって、すでにある価値体系や概念、そして思考体系の中に無意識的にも取り込まれているのである。

アジャイルは、しばしばプロセスのテーマとして議論されている。しかし、開発に使用する言語が、アジャイルという作法を強く誘導している(していた)ことについては、多くが語られていない。

現在、主流であるC、 C++や Javaなどの言語は(モデリング方法の如何を問わず)、その動作を検証する(つまり、人から見て意味のある動きをしているかどうかを確認する)ために、早い段階での結合が求められる。すなわち、遅延結合ができない言語である。そのために何が起こっているかというと、学習曲線の低い段階で、実装の対象である現実世界をできるだけ正確にモデル化することが求められる。さらに、固定化した現実世界のモデルからシステムモデルへ正確につなぐ技術が必要となる。というのは、現実世界をモデル化し、それを入力としてシステムモデルを作成するという変換モデルに従っているためである。

学習曲線の低い段階での結合が求められる早期結合言語では、What -Howのギャップが大きくなる。C、 C++や Javaなどの言語でテンプレートが利用されているのは、そのギャップを埋めるためである。

このような、遅延結合ができない言語の場合、工学的には、ソフトウェアというよりも、むしろ、建築やハードウェアの構築モデルに近いといえる。学習曲線の低い段階で決めなければならないという状況が、ソフトウェア開発がかかえる本質的問題として語られ、その解決方法としてアジャイルなどのメソッドが議論されているが、本質的には、使用する言語の特性が現象しているのかもしれない。

マクルーハンは、メディアそのものがメッセージであると語った。メディアの本質はコンテンツではなく、メディアそのものである。

ある社会(つまり、システム)に見られる振る舞いが、文化に誘導されるものなのか、文化が社会システムへの適用の結果なのかは、社会学での長年のテーマである。

言語に関しては、ソフトウェアサイエンスの領域であり、ソフトウェア工学では、言語の差異による振る舞いの違いに関しては、長らく議論の遡上に上ってこなかったように思える(もしくは、ハードウェア的な言語をいかに使いこなすかが価値のある行為のような思い込みもあるのかもしれない)。

 

よくわからない段階で決めなければならない

「ソフトウェアに関係する仕事をしています」と自己紹介すると、「ゲームですか?」と聞かれる場合がある。ソフトウェアは、「私の仕事はコレです」と手のひらに乗せられるモノを示すことが難しい。おのずと、モノとしてイメージしやすい“ゲーム”が想起されるのであろう。

マウリツィオ・ラッツァラートは、「出来事のポリティクス」の中で、“Immaterial Labor(無形労働:伊藤訳)”という言葉を用いて、ポスト構造主義の現代を生きる我々の生きかた(新しい労働のしかた)を示そうとした。

ソフトウェアは実体を有しない無形物である。ソフトウェアを作るという行為は、ラッツァラートが定義した無形労働の典型であり、ラッツァラートの言葉を借りれば、商品に内包される社会や文化を作り出す労働であるといえる。

一方で、ソフトウェア開発は学習の行為であるとも言われる。対象を理解し、設計し、構築する行為の中で、対象の理解がより深まる(もしくは変わる)。そして多くの場合(というよりも、すべての場合)、我々は、よくわからない段階で決めなければならいという状況のなかでモノゴトを作り出している。つまり、商品に内包される社会や文化に対する仮説を、仮説という荷姿のまま社会へ送り出しているともいえる。

人間は生産・労働を通じて作り出したものを媒介にして自分が何ものであるかを知る(ヘーゲル=マルクス主義)のであるとすれば、ソフトウェア開発とはどのような活動なのかという命題は、ソフトウェア開発に関わる人間として、意識的にも無意識的にも共通して持ち続けるテーマである。

たとえば、「ソフトウェアは本当にソフトな、つまり、柔軟な構築物なのか」、「共通の理解はどのように形成されるのか(もしくはされないのか)」、「知識の所有権はどこに帰属するのか」といったようなソフトウェア開発にまつわる課題は、視野を少し広げてみると、現代の社会が抱えている問題につながる部分が多いと考えられる。ソフトウェア開発のなかで意識される問題を、社会的な視点から眺めていきたい。

 

語ることによって語ること

「僕らにできるのは、執拗な反復によって自分を変更させ(あるいは歪ませ)、そのプロセスを自らの人格の一部として取り込んでいくことだけだ。」村上春樹(走ることについて)

ブログ形式でホームページを更新することにした。
と言っても、これが最初の投稿なので、「しようと思う」が、意思としては正しいのではあるが、ブログ形式にするということは、つまり、定期的に更新するということである。

語るということは、星空から星座を切り出すようなもので、日々のなかから何に対して問いを立てているのかを、自分自身が認識することでもある。
語ることを反復することによって、自分の星座が見えてくればと思う。