タスク視点と成果物視点

業務システムや開発プロセスを設計し、管理し、改善するためには、プロセスを外在化、すなわち、モデル化する必要がある。以下は、プロセスをモデル化する際の視点の話し。

プロセスをモデル化する際に、人はなぜタスクの視点で描こうとするのであろうか。それは、プロセスを認識する場合、タスクの観点が人間にとっては自然である(慣れている人が多い)からである。

例えば、工場の生産ラインを記述する際、たいていの場合に目が行くのはラインを構成する機械である。生産ラインが「Aをする機械」、「Bをする機械」、「Cをする機械」… によって構成されていると認識した場合、生産ラインを”A→B→C…”の機械の並びとして描くことが自然であると感じる。しかし、生産ラインを設計する際のプロセスの本質はそれぞれの機械ではない。

このようなタスク視点に対して、製造ライン上でどのような中間成果物を作り、管理して最終製品に仕上げるかという、成果物視点による実体の構成こそが生産ライン設計の本質的な視点なのである。

作ろうとする成果物に対して、それを一度に作れない場合、段階を経て作ることになる。その際に、どのような段階に分けるかは、本質的には製造する機械によって決まるのではなく、作ろうとする製品の制約、品質管理上の確認ポイント、そして製造リスクの管理の視点から適切なプロセスが設計される。そして、ラインを構成する機械は、設計したプロセスを実現するために、プロセスからの要件と相互作用的に適用する技術が定義、もしくは開発されるのである。

このように、プロセスを設計するためにモデル化する場合には、成果物の視点からプロセスを描く必要がある。描いた業務プロセスモデルがシステム仕様の記述となってしまうのは、タスク志向でプロセスを描くことによって、システムで行われる(行われるであろう)処理、すなわち、システムの仕様が業務プロセスの中に入りこんでしまうためであるとも思われる。

ちなみに、ワークフローという言葉で用いられるときの「ワーク」の語源は、「作業」という意味ではなく、生産ラインの途中に現れる「仕掛品」、すなわち、中間成果物を意味している。つまり、ワークフローという言葉が指し示すプロセスモデル自体、本来的に成果物視点なのである。

 

消費者マインドの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万年前の旧石器時代にまで遡る。そこでは何が行われていたのか、「人間の歴史」でイーリンが描写したマンモスの狩猟場面を引用してみよう。

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

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


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


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