情報活用行う上で重要なことがありますそれは３つの度ということです
１、３つの度とは、鮮度・感度・加工度
２、感度というのは情報の送り手と受けての意識がどれだけマッチングしているか、受け手の期待と送り手の洞察力が合うかどうか
３．加工度というのが結構大事なことで、どういうことかというと、あるとき経営トップと話をしていたとき、事業部などとのヒアリングで分厚い資料を見せられて、どうかといわれるが、そのデータというのはたいていの場合自分たちの都合のいいように加工したもので恣意的なデータであるわけで、そんなものをみせられても困る。いっそ生のデータのほうがましだと言われたことがありまして、しかしだからといって生のデータを渡してどうですかというわけには行かない。どこまでに加工するかが重要なポイントではないか。
では経営に役立たせるためにはどんな情報を提供すべきなのだろうか
１、いまのような話となると、経営としては単なる数値データだけの情報ではもちろんダメ
２、数値データではない情報、内部情報だけではない外部情報も必要
３．死体解剖的な情報から生体ドック的な情報をどう提供できるかにかかっている
過去のデータみてどうだったかではなく、これからどういう手を打つんだというための情報が重要
４．究極的な言い方をすると社長になれるＣＩＯがどんどん出てこないと真に経営に役立つITを提供できない
ところが役に立つ領域もあって
１、情報活用を考えるとむしろ事業部長とか各部長のところが有効
２、なぜかというとちょうど情報がクロスするところで、経営からの情報、オペレーショナルレベルからの情報がクロスするところ
３、ここの裁き方で企業としての情報活用度が上がる
４．したがって、ここへ向けた仕組みを構築するのが効果的
プロセスは全部で７つのステップから成っている。
ステップ１ 哲学とビジョンを構築する
ステップ２ 技術の棚卸とフィールドワーク
ステップ３ コンセプト／モデルの構築
ステップ４ デザイン－ デモンストレーション用プロトタイプをデザインする
ステップ５ 実証
ステップ６ ビジネスモデル構築
ステップ７ ビジネスオペレーション
BPM 1.0 BPM 2.0
Marketed to Business Analysts Used by Process
Analysts
Starting with a Process Modeling Tool Starting with
a CompleteBPMS
Multiple Tools from Multiple Vendors One Single Tool
in Eclipse
BPEL, BPML, WSFL, XLANG, XPDL BPEL
ARIS, HIM, UML, Proprietary Notations BPMN
BPEL Editor BPMN Designer
Writing Code Behind the Boxes Zero Code
Writing Deployment Descriptor Files One Click Deploy
Application Connectors Generating Web
Services on-the-fly
Bring your own Rule Engine Rule Engine
Included
Bring your own BAM Real-Time BAM
ncluded
Ad hoc Process Simulation Native Process
Simulation
BPM 2.0 is not for non-technical business analysts. We’ll just let more technical process analysts understand business requirements and implement them directly into the process, while leveraging existing IT systems.
Neither top-down nor bottoms-up, it’s a middle-out approach, and it’s the only one that makes the gap any narrower.
・情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。
・情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。
・情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。
・ビジネス価値を満たす要求は、直接・間接にその価値に関わるステークホルダー間の合意形成を通じてのみ創り出される。
・要求の開発は、命令統制によらず参加協調による継続的改善プロセスを指向すべきである。
・「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。
システムの上流工程にモデルアプローチを適用するのが正解とされつつありますが、ＤＯＡなのか、それともＵＭＬによるＯＯなのかについては、迷っておられる方が多いように見受けられます。さらにＯＯについては「人の数ほどいろいろなやり方がある」、また「ＤＯＡについてもいくつかのアプローチがある」ということで余計な混乱を招いているようです。 われわれは、「情報システムの製品は画面・帳票であり、これと直結したデータがシステムの基盤を作る」として、「まずはＷＨＡＴとしてのデータを固め、次にＨＯＷとしての処理を考えるＤＯＡアプローチが正解なのではないか」と考えます。そして９０年代、メインフレームからＣ／Ｓ、あるいはＥＲＰへのシフト に追われているうちに、「ＤＯＡ技術の継承が中断され、危機的状況にあるのではないか」と心配しております。そこで「これを解消したい」との思いから、かつてのＩＲＭ研究会を思い出しながら、「ＤＯＡ＋コンソーシアム」を立ち上げることにいたしました。
クライアント側の要素 ： 「人」と「IO」
サーバー側の要素 ： データベース、エンティティ、データ項目
われわれの夢は、今は価値がないとされる業務モデルのコンテンツが流通し、市場価値を持つようになることです。ある単位の業務モデルリポジトリのコンテンツをライブラリとして貯え、これを適宜選択・組合わせて、自社に合ったデータモデルを構築することができれば、「パッケージに身体を合わせろ」と言った妥協を大幅になくせるものと考えます。これをアメリカより、１年でも２年でも早く実現するのです。そうすれば９０年代に付けられた差を一気に逆転する可能性すらあるように思うのです。
Ａ．建設：見積－受注－建設計画－建設－検収
Ｂ．生産財製造業：受注－生産計画－生産－出荷
Ｃ．消費財製造業：販売計画－生産計画－生産－受注－引当－出荷
Ｄ．卸業：販売計画－仕入－受注－出荷
Ｅ．小売業：販売計画－手配－販売
Ｆ．サービス：契約－設定（工事／担保）－サービス－検収
１．人材調達・育成（人事）
２．市場開発・保守（ＣＲＭ）
３．設備建設・保守
４．商品開発・改良（ＰＤＭ・ＰＬＭ）
５．資金調達・利殖（財務）
６．情報システム開発・保守
複数のアプリケーションを集めたコンポーネントの最小構成単位は，ビジネスで扱う人や物など「もの」として定義された対象物（エンティティ）の生 成から消滅までにしている。例えば債権についてのコンポーネントは，債権の発生から消滅に関する更新要求や参照要求への対応，ビジネスロジック（債権充 当，充当修正，滞納判定，滞納情報作成，滞納解消情報作成，回収代行債権返戻情報作成など），コンポーネント外部とのインタフェースを制御するデータ変換 部分を対象とする。コンポーネントは，情報として管理するものの最小単位ともいえる。
ここまででは、コンポーネントとして、業務サービスという言い方をした小さな単位の業務プロセス、例えば「受注」というようなものもコンポーネントとみなすと、こうした大きな括りの業務サービスコンポーネントがあって、その下に「受注受付」のようなアクティビティあるいはタスク主体の業務コンポーネントがあり、それを動かす共通基盤的な仕組みとしてのシステム機能コンポーネントがあると言ってきた。それでは、それぞれのコンポーネントの粒度をどう考えていったらよいのでしょう。
システム機能コンポーネントについては比較的考えやすいと思うので、ここでは、業務コンポーネントについて考えてみる。
まず、抽象的な言い方だと、ビジネスの環境や組織が変わっても、それ自体変わらない部分をコンポーネントの単位とすることなのだが、例えば、会計処理なんかはそのプロセスはそう大きくは変わらない（法改正、制度変更はあるが）から、業務パッケージそのものがコンポーネントと言えないこともない。こんな場合は、それをひとつのサービスとして括ってもかまわない。
最近Webサービスという形でネット上にもこうしたサービスが登場してきている。有名なSalesforce.comのオンデマンドサービスはまさにまるごと外部のサービスとして利用できる。だから、他社と差別化する必要のない機能は、できるだけ個別企業ごとに作るのではなく、外部のサービス利用という形態が望ましい。
こういうことができるようになったとというのがSOAのもたらした効果なのだ。企業は、システムを“作る”、“買う”（パッケージを買うという意味）、“借りる”のバランスをうまくとりながら構造化を図ることが大事である。
さて、もう少し具体的に見ていくと、一番問題となるのは業務コンポーネントの粒度をどうするかだ。この中には、単なるワンアクションのようなものから、ワークフローを含んだ処理までが想定されると考えられる。「生産量登録」みたいなものから「見積依頼」というようなワークフロー的なコンポーネントのことである。
例えばこの「見積依頼」という業務処理を考えてみよう。工事の見積を行なうと仮定するとこの処理は、「仕様書作成」→「仕様書承認」→「見積依頼書作成」→「見積依頼受付」→「見積依頼」のように流れる。このとき、「仕様書作成」のレベルを一つの業務コンポーネントとして、それらをBPMでつないでプロセスを作っていくというのもありですが、少し細かすぎるような感じがする。
そこで、BPMとWorkFlowについてだが、厳密な定義があるのかないのか知らないが、似ているように思うし、一緒のように言う人もいる。よくわからないというのが正直なところで別にそんなことを考えなくてもいいと思う。むしろ、WorkFlowって一体なんなのだろうかと見るほうが大切で、仕事というのは、ひとからひとへシークェンシャルに流れていくものであるという前提でWorkFlowという概念が成り立っている。
確かに、稟議決済なんて仕事が流れていく典型であるけど、大部分はその前提を崩して考えてもいいような気がする。すなわち仕事が流れるのではなく、“状態が遷移する”と考えるべきだということです。だから、ワークフローというのは、フロー制御とステータス制御の2通りあると捉える。
以前、.NETのフレームワーク上で動くコンポーネントを開発し、それを使ったアプリケーションを構築することを試行したことがあったが、そのとき業務というのは、書類をイメージした「データコンポーネント」が転記されて受け渡されることだと規定したことがあるが、これと似ている。
また最近、こうしたことを気づかせてくれたのは、あるCMSツールです。それは、Ploneといって、オープンソースのアプリケーションサーバーであるZopeとそのフレームワーク上に構築されたコンテンツ管理システムなのですが、そのなかにワークフローの機能があるというのです。で、よく見てみると、“オブジェクトの状態とユーザロール”を中心に構築されているのです。簡単に言えば、共通の場で情報を共有してそのステータスをコントロールすることで仕事ができると言っているのです。
このあたりはまた後述しますが、粒度の話に戻ると、ここにヒントがあって、ここで言うオブジェクト単位で粒度を設定すればいいのではないかということです。では、そのオブジェクトとは何だろう。筆者は上述したように、それは「書類」ではないかと考えている。すなわち、仕事の単位は、書類（必ずしも紙でなくてもいい）を作成してそれに追記・転記して完結するということではないかと考え、それをコンポーネントと捉えたらどうだろうか。このように考えてもいい業務処理はわりと多いと思われる。
従って、従来WorkFlowといっていた部分は、StatusControlとし、対象となるオブジェクトを書類（広義）とし、その単位でコンポーネント化する。コンポーネントは例えば、PloneのようなCMS（もちろん他のWebアプリケーションでかまいません）みたいなものでできて、それらのコンポーネントをBPMを使ってプロセスにしていくというのがざっとしたイメージになります。
ミクロなサブワークフローは軽量Webアプリで、マクロのメインワークフローはBPMという構成です。言ってみれば幹線道路はBPMで作るが支線や私道は軽量フレームワークでさくっと作ってしまい、ジャンクションは標準の取り決めに従ってつなぐという感じになりますがいかがでしょうか。全部がこれでできるとは思っていませんが、挑戦してみる価値はあるように思えます。
前回、オープンソースのCMSの話がでたが、いま話題のWeb2.0とBPMはどういうことになるのだろうか。ここは、前に言ったBPM2.0という意味ではなく、Web2.0の思想やサービスモデル、技術についてのことだ。
Web2.0というとつい、Google、Amazon、Yahooといった企業あるいはWikipedia、SNS、ブログ、Youtubeといったサービスに注目するが、実は重要なことは、そこにある思想と支える技術の両面をきちんと理解することではないでしょうか。
有名なO’Reillyが作成した下記「Web2.0ミームマップ」を見るとWeb2.0の概念がだいたいわかる。
このなかから、BPMあるいは企業情報システムと関連する記述を見てみよう。
まずは、情報のハンドリングについては、「情報の自己コントロール」「集合知の利用」「参加のアーキテクチャ」がある。すなわち、Wikipediaに代表されるようにみんなが知恵を出し合ってできたものが一番いいものができるということ、さらにSNS、ブログ、Amazonレビューのような皆が情報の発信者になれるということで、こうしたユーザを信頼する楽天的民主主義の色合いが強くでているのがわかる。
システムのつくりみたいな領域では、「プラットフォームとしてのウェブ」、「パッケージソフトウエアではなくサービス」「永久にベータ版」、「利用者が増えるほど改善されるソフトウエア」、「モジュール化とゆるやかな統合（コンポーネントとしてのウェブ）」といったところになるが、これまで議論してきたことに大いに関連していると思いませんか。Webの世界と企業情報システムサイドとがだんだん近づいてくるように思えます。
ただし、ここで重要なことはWeb2.0の世界というのは、既成の概念を打ち破るパラダイムシフトのことですから、企業にとっても情報システムだけの話ではなく、企業体質、組織、仕事のやり方などが変革されなければ受け入れられない思想なのです。次世代の企業をめざすのなら、Web2.0的体質にならなくてはいけないし、脱皮できた企業が生き残っていくような気がする。
Web2.0によってもたらされた変化はいったいなんなのだろうか。
企業にインパクトを与えるものとしては、まず参加型のアーキテクチャがあげられる。ブログやソーシャルネットワークに代表されるように誰でも情報発信できるようになったことが大きい。これまで情報交換はせいぜいメール（メーリングリスト）ぐらいでしたが、これからは社内ブログのようなものも出てくるでしょうし、社外に対しても積極的に情報発信していかないといけなくなるわけで、これは、結果的に情報共有、情報公開ということが非常に重要な要素となり、平気で「不都合な真実」を隠蔽するような企業は生き残れなくなる。
この参加型のアーキテクチャというのは、従来の階層型の組織では受け入れられない考え方で、組織をフラット化してこそ生きてくる。実は、前回ステータス管理という仕事のやり方について書いたが、これがまさに参加型のワークフローなのだ。
従来のように階層化された組織を順番に仕事を流していくやり方では、そのフローのなかで業務処理の状況がどうなっているのかわからないまま、自分のところに“さあ、承認お願いします”と来ても困ってしまう。最初から利害関係者が参加し、そこで意見交換しながら仕事を進めていけば、自ずと意思決定も早くなるのではないでしょうか。
また、オープンソースプログラムのようにネット上にソースを公開し、そこに誰でもアクセスでき、知恵を出し合いながら作り上げる。こうした、知的生産活動はいままでのように個人で仕事を抱え込み、また抱え込むことで自分の存在価値を確認しているようなやりかたと違い、「永久にベータ版」として早めに衆知にさらせば、知的生産活動で生み出される情報の質はかなり向上する。要するに、社内の情報を握っているだけで部長になるようなことがなくなっていくということだ。
いまや、こうした情報リテラシーをもった若者がどんどん会社に入ってきている時代だ。会社自体も会社2.0に変貌していかないと、入社したはいいが3年で辞めていかれてしまうのではないでしょうか。
さらに、これまで自分のデスクトップ上にあったデータをネットワーク側に蓄積するようになり、それを基にネットワーク側から様々なサービスが提供されるようになった。それとソフトウエアが無料で使え、インターフェースも標準化され、簡単にHack、Mashupできてしまうチープ革命といわれることがあります。
しかしながら、この恩恵を受けるには自己責任ということを覚悟しなくてはいけない。それができる企業は自らの手で自らの責任でシステムを構築していくことを選択すべきであろう。それがいやなら、相変わらずベンダーの言うとおりに、２０％の機能しか使えないソフトウエアを買い続けることだ。
ただし、無条件に無償のオープンソースを使うことを薦めているわけではありません。そこには、今言った自己責任ということとともに、技術に対する目利きと使いこなす技術力がいるため、やみくもにとびつくことはしないほうがいいと思います。自社のリソースを頭に入れて、そのメリット、デメリットをきちんと見極めることが大事です。
今回は、Web2.0の思想と企業の体質、組織などについて述べたが、次回はもう少し技術的な側面について考えてみる。
Web2.0の技術に関するキーワードを「WEB2.0 キーワードブック」（翔泳社）から拾ってみると、REST、XML、RSS/ATOM、URI、Ajax、Mashup、microformats、WebAPI、PageRank、Skype、があげられています。今後それぞれが多かれ少なかれ企業情報システムに影響を与えていくものと思われます。上記の本の執筆者は錚々たるメンバーでその分野の第一人者ですので、筆者が解説するのも無理があるので、サイボウズ・ラボの奥一穂さんが総括してくれているのでそこのポイントを抜粋する。
まずは、各要素技術をみるとき、サーバー間の連携、クライアントサイドへの処理の委譲、クライアント・サーバーモデルからの脱却という3つの流れを意識する必要がある。
従来型のウェブアプリケーションは、サーバー内に溜め込まれたデータを、サーバーサイドで処理して、ブラウザにHTMLとして配信するという手法でした。これだと、魅力的なアプリケーションを構築するためには、大量の商品情報やコンテンツを保有しなくてはいけなくなり、1社では限界がありました。
それをデータ公開という形で打ち破ったのがアマゾンです。そこでの技術でいえば、セマンティック・ウェブであり、Webサービスです。セマンティック・ウェブの基盤はRDF（ResourceDefinitionFramework）という文書モデルで、これに準拠したものではRSS1.0やFOAFが有名です。Webサービスはネットワーク上の複数のコンピュータで協調処理を行なうための取り組みで、基盤となっているのはSOAP、WSDL、UDDIといった規格です。
この両方ともに属さない技術としては、RSS2.0、XML-RPC、RESTがあります。この中では、RESTがHTTPの機能を多く使うため、ウェブサービスごとに異なる仕様が少なくなったり、ブラウザから動作の確認ができるなどのメリットから、RESTを活用したウェブサービスが増えている。
ウェブサービスに対応したとしても、ユーザが使ってくれなければ意味がありません。そこで出てきたのが、AutodiscoveryとMicroformatです。Autodiscoveryとは、HTMLページ内にXMLデータやXMLAPIへのリンクを埋め込む仕組みで、これに対応したWebサイトであれば、RSSリーダにHTMLページのURLをそのまま入力すれば、RSSリーダがそのページ内からHTMLタグを検出し、RSSの正しいURLを取得してくれる。一方microformatは、HTML内にXML等のちょっとしたデータを埋め込むことを言います。
クライアントの技術としては、Ajaxがあげられます。HTMLの表現力は決して高くありませんので、高度な目的のためにはブラウザでは力不足という認識でした。そこに、JavaScripとHTML、XmlHttpRequestオブジェクトを活用する優れたユーザインターフェースをもつ「Ajax」が登場したのです。入力インターフェースが格段に向上してきている。
その他、GoogleAdSenceで使われるClient-side IncludeやSkypeに代表されるP2Pなどがあります。
最後に、Web2.0的技術に共通する特徴は「目的を実現するためのチープなソフトウエア技術」であると言える。
こうしてみるとWeb2.0の技術というのは、ユーザ指向、サービス指向でその目的にあったものを簡単にさくさくできるための技術のようだ。ということは、いままで論じてきた「ユーザ目線のBPM」にとっては外せない技術であると言えそうだ。前々回提案したワークフローアプリケーションをWeb2.0の技術との組合せで実現しようということの意味をわかっていただけたでしょうか。
企業でいう顧客接点のところでは、Web2.0技術を使ったアプリケーションがすごく有効であり、単体のサービスとともにMashUpされたサービスがどんどん供給されてくる。ほんとうにびっくりするぐらい素早くMashUpサイトはできてしまう。
また、BPMとは多少ずれるが、それ以外の領域でも大いにWeb2.0技術が活用できる。例えば内外の同業他社情報、業界動向を持ってきて事業計画作成の参考にするだとか、全社に散らばっている技術情報を集めて技術マップを作るだとかといった様々な情報処理作業を伴う知的生産活動があるが、こういうところでも有効だ。ネット上の情報のハンドリングは企業内のそれとは比べものにならないくらい大量で複雑であるので、そこでできている技術をうまく利用できれば生産性が大幅に向上する可能性を秘めている。
たとえば、「YahooPipes」をご存知でしょうか。最近、米Yahooが発表した、RSSフィードによって得られるデータを組み合わせ、操作することによって新しいフィードを生み出すことができるマッシュアップホスティングサービスなのですが、簡単に情報の収集・加工ができてしまう。これなどは、情報ハンドリングの強力なツールになるでしょう。
今後、その他多くのWeb2.0技術が企業に浸透していくことだろう。
今まで、Why、What、Howについてみてきましたが、最後に残りのWho、Where、Whenを考えておかないと紙の上の議論となってしまいます。最初の頃にも言いましたが、動いてなんぼ、役に立ってなんぼの世界であるので、具体的にどういう体制で、どういう組織で、どこに適用し、いつやるのだということを提示することも重要であると思う。
体制のことで言えば、業務プロセスのデザインをビジネスプロセスデザイナー、業務プロセスの実装をITアーキテクト（従来のSEの進化形）、プログラミングをスーパープログラマーというのが理想的である。このチームで「セル生産方式」のように一気に作り上げることが望ましい。たとえが悪いが、「必殺仕事人」「黄金の7人」みたいなものだ。ここで作られたコアシステムをベースにカスタマイズしたり、運用したりするのは、一般のひとがやっていくという役割分担になる。
ここで、軽量プログラミング言語を操る技術者をどう巻き込んでいくがポイントだ。たとえば、IPAの未踏ソフトウエアの卒業生を引き込むとか工夫する必要がある。
また、このビジネスプロセスデザイナーという役割をどうするか。前に、企業IS部門や情報子会社について、彼らはどちらかというとベンダー寄りであると書いた。ここでは、期待を込めて、この役回りを企業IS部門あるいは情報子会社が負うことを提案する。
従って、従来に比べ、さらに業務側にシフトしたスタンスとする。これは前にも言ったように、別にユーザと同じレベルで業務を知る必要はなくて、BPMという道具を使い、手持ちのコンポーネントを見せて、必要とする業務プロセスを引き出す能力をもつことでかまわないのだ。
情報子会社が本質的に抱える課題である自立化を実現するヒントになると考える。これは本題ではないのでこれ以上は言及しない。
ただし、こうした開発部隊をどう組織化するかは難しい課題である。次に述べる地方の中小企業に導入する場合など、必ずしも情報子会社でやれるとは限らないケースもあると思われる。全国規模のITベンダーの力を借りることも必要になるかもしれない。
さて、実際にここで論じた方法論や仕組みをどこにどうやって適用するのがいいのだろうか。その答えとして、中小企業への適用を行い、地域ごとのビジネスサポートセンター設置を構想する。なぜそう考えるに至った理由について、昨年「日経ソリューションビジネス」に掲載された記事が参考になるで引用する。この記事は「中堅・中小企業の市場に対する「これまでの常識」と７つの「新常識」」と題したものでベンダーに向けて発信されているが、状況を的確に捉えているのであえてそのまま載せる。
これまでの常識
これからの常識
これを見たらおわかりのように、「ユーザ目線のBPM」は、中堅・中小企業をターゲットにするのが適していると思いませんか。
また、社内にＩＴ部門をもたない中堅・中小企業が多く、運用を自社で行なうのが困難であり、コア業務に集中するために運用は外部にまかせたいと考えている。従って、センター化してASPサービスとして機能させることが望ましい。
筆者は、全国の信用金庫単位でこのセンター（ビジネスサポートセンターと呼ぶ）を構築したらどうかと提案している。それぞれの信用金庫には多くの中堅・中小企業がぶらさがっています。その企業群が共同で利用できるビジネスシステムを提供することをめざします。全国に２９２の信用金庫がありますが、どこかひとつを選んでそこで実装し、モデル化して全国水平展開するというイメージでいかがでしょうか。
いつやるかは、全体スキームの確立状況をみて決めていくことになります。
日本の強さは中堅・中小企業の力によるところが大きいと考えられます。さらにそこを強化して行こうではありませんか。
ここまでの議論を整理してまとめると次のようになる。
・役に立つものができるなら、従来の作り方を変えようじゃないか
・それにはBPMを使ってコンポーネントを組み立てる作り方が有効なようだ
・BPMは開発と監視の道具であるとし、使い勝手を重視しよう
・BPMはSOAの基盤の上に構築するのが構造的によさそうだ
・コンポーネントは、Web2.0的技術あるいはサービスでさくさく作ってしまいたい
・早く安く作る事が重要でしかも変更や手戻りは当たり前と考えよう
・コア開発は、ビジネスプロセスデザイナーとITアーキテクトとスーパープログラマーのチームで迅速に、カスタマイズ適用と運用は“一般”チームで確実に
・小さく生んで大きく育てる思想で、非基幹系、中小企業向けから始めよう
この議論の表題を「ユーザ目線のBPM」としたが、これは筆者がエンドユーザであった時代、そしてIS部門、情報子会社でシステム構築を行なってきたときの経験から、どうもこれまでのシステム作りがメーカ、ベンダー、SIerの目線で行なわれてきたように感じられたので、あえてそのようなタイトルにした。
目線ということで言えば、最近「下流志向」という本を書いた内田樹氏がこんなことを言っている。
「目線」というのは「そこから何が見えるか」ではなく、むしろ「そこからは何が見えないか」によって特徴づけられる。例えば、本邦のテレビのニュース番組のほとんどは「おばさん目線」である。だから、私たちがワイドショーやニュースから知れることができるのは「日本のおばさんは何を知っているか」ではなく主に「日本のおばさんは何を知らないか」である。これはそれなりに有益な情報である。
この傳でいけば、「ユーザ目線」というのは、「システムについてユーザからは何が見えないか」、「日本のエンドユーザの人たちは何を知らないか」ということになる。この議論で“それなりに有益な情報”を提供できたのであろうか。おわり。
「ユーザ目線のBPM」で実際に動くものをつくらないといけないと言い、その形としてオープンCMS（oss-CMS）によるコンポーネントをBPMでプロセス化することを提案した。そこでこの「ビジネスコンポーネント指向開発」についてもう少し具体的に考えていこうと思います。
その前に、おさらいの意味でもう一度「ユーザ目線のBPM」のなかでなぜ「ビジネスコンポーネント指向開発」を提唱したかを整理してみる。
BPMはまだきちんと定義されているわけではなく、共通認識がないように思われる。従って、ひとによって様々なアプローチがある。
大きくは次のようなアプローチがあるように思える。
さて、BPMを考えるうえで重要な視点はいったいなんなのだろうか。それは、BPMの最終ゴールはどこにあるだろうかということに他ならない。そして最も適した答えは、「事業の役に立つ業務プロセスをつくること」ではないだろうか。
経営ではなく、事務ではなく事業のためであり、その事業の足を引っ張ることはもってのほかで、事業が円滑に運営するための本当に役に立つ仕組みでなくてはいけない。
そう考えると、上記のアプローチでは物足りない。事業の役に立つためにさらにどこまでやらなくてはならないかを掘り下げる必要がある。従って、つぎのようなところまでやってこそ初めてBPMらしくなる。
で、今回提唱している「ビジネスコンポーネント指向開発」というのは、③のアプローチのことである。④は事業視点が薄いので除外すると、①②であるが、③のアプローチがプロセス制御の考え方でいうところのフィードバック制御的であるのに対し、①はフィードフォワード的、②はシーケンス制御的であるといえないことはない。
フィードフォワードでは外乱に対する制御量の把握の難しさやそれだけでは完全な制御ができないこと、またシーケンスの論理回路の設定が難しいことなど、言い換えれば、よその会社のテンプレートが自社の本当のベストプラクティスになりえるのかという問題や、標準化・最適化が本当にできるかなどの問題があり難しいアプローチであると考えている。
従って、業務プロセスに対する応答性のよいフィードバック制御が一番現実的で有効であると言っているのです。ただし、こうして開発されると業務コンポーネントが蓄積され、またブラッシュアップされていくため、こうした業務コンポーネントをモデル化あるいはテンプレートすることによって、次第にフィードフォワードやシーケンス制御の利点も取り入れることも可能になっていくものと思われる。
制御工学の話を持ち出してわかりずらかったかもしれませんが、まずは、業務プロセスをきちんと制御してから、その後より最適な方向に持っていくというアプローチを推奨しているわけです。
コンポーネントという場合、どうしても部品とか、クラスライブラリーとかいったイメージで語られることが多い。これは、システムを作るうえでのシステム機能を指している。そういうものであると、しょっちゅう使う機能や、共通的な機能をまとめて外だしにする、いわゆるフレームワーク化することで、それらの再利用性を高め開発効率をあげることを目的としている。従来のコンポーネント開発といわれるものは、こうしたシステム機能寄りの発想が主なものになっているような気がする。
そうした業務非依存のアプリケーションフレームワークのレベルのものは、いまやStrutsや.NETFramworkあるいはWebの各種フレームワークなどがあり、こうしたフレームワークにあるシステム機能コンポーネントを活用すればいいことになる。問題は、業務に密着したその上層のドメインフレームワークがなかなか難しいのである。再利用性が高いドメインフレームワークはあまり見たことがない。
さて、フレームワークといってもよく分からないが、要はビジネスコンポーネントをどういう粒度で分類するかが肝になるところである。「ユーザ目線のBPM」にも書いてあるので重複するが、もう一度整理する。
言葉の使いかたはともかくとして、このくらいの階層構造になるのではないかと思う。
これらを分類・定義していくわけだが、業務分類から入るビジネスモデリングからのアプローチだとレベルが高いうちはいいが、詳細に落とし込んでいくとその固有性や例外、特殊性などの罠にはまり、モデル化が困難になるのではないだろうか。
そこで、いい業務プロセスを作るには、業務コンポーネント主体の開発でないといけないと考えた。より普遍的な粒度で業務コンポーネントを規定し、細かい機能的なぶれはそこで吸収し、業務サービス・業務プロセスでは、差別化のための差異を表現するというアプローチだ。
いい業務プロセスを引き出す方法論、道具の提供を目指すビジネスコンポーネント指向開発こそがBPMの正しい活かし方であると考えている。
次回はこの業務コンポーネントの粒度についてさらに具体的にみていく。
粒度の話に行く前に前回話した業務アプリケーションの階層構造について図示したものを見ていただきたい。
例えばとして販売管理という業務アプリケーションについてのそれぞれのプロセスやサービス名を書いてある。このなかで一番小さい業務コンポーネントは細かすぎるので書いていないが、本回ではここを中心に議論する。
この業務コンポーネントの粒度を決めるのは、その理論的な基準もないため非常に難しい。そこで考えついたのが、「書類」という単位です。
業務というのは、結局人間を中心に仕事の依頼（指示）が来て、それを受付し、何らかの処理や判断を行い、またつぎの人に新たな仕事を依頼するという繰り返しではないかと思う。その一部をITが人間の替わりに振舞ったりすることはあっても基本的な流れは人間を経由してまわっていくのではないでしょうか。
そのとき、受付－処理－依頼というアクションというかタスクというか、そういった単位業務処理は、書類で受け渡すことになるのではないのかということです。
「○○依頼書」で依頼して、その依頼書を受け付けて、処理というのは依頼書の作成・編集に相当して、例えば承認にしてもその書類に承認のサインをすることであるし、その時点でその書類が最終化され、次のステップのきっかけになっていく。
これは、何も書類になっていなくてもよくて、例えば「在庫引当」というような場合、あたかも「在庫引当依頼書」を発行したかのように振舞えばいいわけで、ほとんどのケースでそうした単位に分けることができる。そうです、この書類のライフとでも言ったらいいと思うが、一つの書類に対する「作成－編集－確定－承認」の単位を業務コンポーネントとすれば、すごく分かりやすいし、そのコンポーネントは業種・業態や環境の変化に左右されない。
そして、この業務コンポーネントを「受付」、「依頼」を介して、BPMがプロセスにしていくことになる。
業務コンポーネントのつくりをどうするのかになるが、書類のライフと定義したということは、書類の作成から編集・確定・承認という、いわばワークフローという形態でもあると言える。しかし、ワークフローといっても、この場合は単純なもので、むしろ「状態遷移」と捉えたほうが分かりやすい。要するに、書類が作成された初期状態から、追記されたり、変更を加えられたりして、編集された状態に遷移する。それをメンバーが確定し、承認者に承認をうけて完成させるということである。
しかも、これらを逐次的な流れではなく、メンバー間での情報共有的さばきかたでやるのがこれからの仕事の進め方になるし、効率的であると思われる。Web2.0的な考え方の、参加型のアーキテクチャ、あるいは集合知の活用というところでしょうか。従って、これこそoss-CMSが本来的に持っている機能の重要な部分である。だから、それを利用するのだ。
誰かが、該当メンバーに書類の作成を宣言し、できたものをβ版でいいからすぐにアップする。それをみんなが寄ってたかって意見を言い合い改編していく、場合によっては承認者も参加しているため、承認伺いが立ったらすぐに承認・公開されるというわけだ。
それでは、具体的にoss-CMSをみていきましょう。CMSはコンテンツマネジメントシステムのことであるが、IT用語辞典「e－Words」によれば、「Webコンテンツを構成するテキストや画像、レイアウト情報などを一元的に保存・管理し、サイトを構築したり編集したりするソフトウェアのこと。広義には、デジタルコンテンツの管理を行なうシステムの総称。」ということになる。
もうちょっと技術的にいうと、「Webサイトを構築するには、テキストや画像を作成するだけでなく、HTMLやCSSなどの言語でレイアウトや装飾を行ない、ページ間にハイパーリンクを設定するなどの作業も行なう必要がある。これらの要素を分離してデータベースに保存し、サイト構築をソフトウェアで自動的に行なうようにしたものがCMSである。」であるが、CMSには拡張機能がいろいろあって、プラグインよいう形で付加できるため、広い範囲のアプリケーションに対応できる。
代表的なものをいくつかあげると、Plone、Xoops、WordPress、MovableType、osCommerce、ZenCartなどがあり、WikiやSNSも入れると数多く存在する。
今回さしあたって、「書類の状態遷移」を業務コンポーネントと定義した場合に適したものとして、Ploneを選択した。理由は、“オブジェクトの状態とユーザロール”を中心に構築されたワークフローの機能をもっていたからです。
Ploneはどのユーザが見たり実行したりできるのかを定義するのにロール（役割）を用い、そのオペレーションのすべての面においてセキュリティを組み込む。ロールにはanonymous(無名)、member(メンバー)、owner(所有者)、reviewer(レビューワ)、それにmanager(マネージャ)がある。
そして、Ploneのワークフローにはvisible(可視)、pending(保留)、published(公開)、private(私的)の４つの状態があり、それぞれのロールを与えられたユーザがオブジェクトを利用できるかどうか、また、オブジェクトが次に他のどんな状態に遷移できるのかはオブジェクトの状態によって決まってくる。
このように、ロール（役割・権限）とオブジェクト（書類）の状態を管理することでひとつの業務を処理していくわけです。こうした単位業務を組み合わせることで業務プロセスが形成されるのです。
業務コンポーネントにPloneを指名しましたが、場合によってはその他のCMSでもかまわないのです。例えば、ZenCartのような販売サイトをコンポーネントとして捉えてもよいし、Xoopsでコミュニティの議論結果をもってくるとか、応用動作は多くあるような気がします。
次回はBPMについて議論します。
業務コンポーネントは、oss-CMSを有効に活用し、できない部分も軽量言語とフレームワークでさくさくと開発してしまいましょうということを提案した。
さて次に、そうした業務コンポーネントをフローにしていかなくてはいけない。しかも、単なるワークフローではなく、業務フローが適正なつながりになっているか検証できるシミュレーション機能やできあがったフローの稼動を監視するモニタリング機能などが要求されてきている。そういった意味では、最近注目のBPMを使って業務プロセスを組み上げ、フロー制御していくのが有効な手段であると考えている。
BPM製品もEAIやWASから拡張されたようなものも含め、数が増えてきているが、ここでは「SAVVION」という製品でBPMを行なってみる。この製品は4年前に筆者が実際に使ったことがあることや機能的にもすぐれているので採用することにする。
ただし、この製品でなくいてはいけないということではなく、他の製品でもかまわないし、場合によってはオープンソースのものでもいいのだが、この分野はまだコミュニティが成熟していないのでまだリスクが大きいと思われる。
BPMで必要な機能とはいったい何なのだろうか。最低必要なものとしては、
であると考える。
その他、BAMだとかBIあるいはビジネスルールなどあるが、そこまで活用できる企業は少ないのではないでしょうか。ですから、まずは、適正な業務プロセスが作れて、すぐに動かすことができ、その動いている状況を把握できる仕組みがあればいいのです。
ここで、ビジネスプロセスデザイン機能についてもう少し詳しくみていく。単純に今やっている業務フローを書き出すだけでは、ビジネスプロセスデザインとは呼べない。そのAsIsのフローをシンプルで一貫化されたものにする、適正化という作業が大事である。そのためには、BPMSの中に適正化のためのチェックが自動的に行なわれることと、いろいろなケーススタディができる機能が望まれる。ここはまだ研究中でどうするかは時間が要りそうだ。
参考までに、SAVVIONのモデラーでサンプル業務フローを書いた例を載せる。
この四角の箱がアクティビティであるが、その中味はPloneで作られているといったイメージになる。そして、それぞれの線の取り合いが依頼と受付になる。それで理想的には、アクティビティの機能や線のつなぎ方に業務プロセス上で重複や迂回などのルール違反があるとワーニングしてくれるというのがうれしいのですが。
次回は、開発方法について考えてみる。
おおまかな開発手順は次のようになる。
こうした手順はウォーターフォール的に書いてあるが、実際にはスパイラル的に行なっていく。開発には、ビジネスプロセスをデザインする「ビジネスプロセスデザイナー」、業務コンポーネントの開発部分を担当する「スーパープログラマー」、実装を請け負う「ITアーキテクト」からなる開発部隊とそれを「プロジェクトマネジャー」が統括する形で行なっていく。
人数も少数精鋭で短期に仕上げて行く。また、非基幹系の業務プロセスで高い正確性を要求されないものなどはβ版で公開し、少しずつブラッシュアップするやり方も行なう。
ここで特徴的なのは、エンドユーザのひとたちと対面して開発することである。そのためには、要求が出たらすぐに実装して見せてあげることが必要となる。こうした開発方法をここでは、「対面開発（Face2FaceDevelopment)]と呼ぶことにする。ユーザの要求の”ぶれ”を早期に吸収し、手戻りの発生を防止する効果を期待する。
さて、これまでの述べてきた「ビジネスコンポーネント指向開発」の特徴と優位点についてまとめてみる。
結局、役に立つBPMというのは、こうした考え方、技術、方法論により実現できると考える。これらを図示すると次のようになる。
この開発手法でどこまでの業務アプリケーションができるのだろうか。いままでの議論では、どちらかというと非基幹系業務ならだいじょうぶそうだが、基幹系だと無理じゃないのかと思われる方もいると思う。基幹系の仕組みが既にあってその周辺の業務に適用するものではないかと。しかしながら、例示したなかに販売管理システムがあったように、基幹系にも十分適用できるものと考えている。
そのとき、何をもって基幹系なのか非基幹系なのかの定義をしておく必要がありそうだ。ERPにあるから基幹系だとか生産・販売・物流は基幹系だとか、なんとなくぼやっとしていないだろうか。広義の意味では企業のPDCAサイクルを回す業務のことであるが、これだとまたよく分からないところがあるので、もっと狭めて考える必要があるような気がする。
ここで、基幹系とは、「ヒト・モノ・カネに関する確定した数量・金額を処理する」業務のことと定義する。
簡単にいえば、確定した見積金額、確定した受注数量、確定した売上等々を処理することであり、どれだけ売り上げてどれだけコストがかかったのかをはっきりさせることであり、BS/PLに反映されるアクションである。
なぜこうした境界にしたかというと、安定なシステムであるかそうでないかを峻別したいがためである。もともとコンピュータが導入された当初はこの部分しかシステムに載せていなかったわけで、その後PCが端末に登場することで、確定前の処理もPCに載せだしたために“不安定な”システムが作り出されたように思える。
例えば、受注にしても受注するまでに顧客やあるいは社内関係部署との間で在庫状況のチェックや与信などいろいろなやり取りがあって確定していくが、そのやりとりというのは必ずしも決まった手順があるわけではなくケースバイケースでの対応が多い。
こうした処理を基幹システムに放り込むことにより、例外処理や戻し処理、過剰なエラーチェックなどシステムを複雑かつ不安定にしてやしないかということである。
ですから確定前の業務はむしろ非基幹系業務ということにして分けて考えたほうがいいような気がする。また。基幹系業務で生成されたデータを使って処理する業務も非基幹系業務のひとつとして定義できる。従って、別の言い方をすると、確定前処理というのは情報共有的な進め方であるのが一般的であるため、「情報共有」と「情報活用」業務のことを非基幹系業務ということにする。
「情報共有」によりデータを確定し、それを基幹系システムに渡し、基幹系ではそのデータを使って業務処理を行い、決算データを作成し、そこで生成されたデータを「情報活用」し、次のアクションに生かしていくというシステム構造である。
さて、「ビジネスコンポーネント指向開発」は基幹系業務にも適用できるといったが、情報共有を主体とした確定前処理業務に適用するほうが向いていることから、まずはこの領域で実践し、もし有効であれば基幹系にも拡げていくことをねらう。
上述の定義からいうと非基幹系業務がけっこういっぱいあるのではないかと思う。極論すれば、今の業務パッケージをスリムにして（確定後の処理だけにして）、その周りを「ビジネスコンポーネント指向開発」で作り上げ、できたコンポーネントと業務プロセスをできるだけ再利用していくという方向性が見えてくる。
ただし、すぐには難しいのでやりやすいところから実現していくのがよいが、そのターゲットとしては見積依頼管理、顧客サービスのようなものが考えられる。また、ITILのシステム化やISO文書管理などへの適用も有効かもしれない。
これまで業務コンポーネントを書類のライフとみたてて議論を進めてきた。ほとんどの業務プロセスはこの書類のライフで組み立てられるが、それ以外の業務コンポーネントも定義しておかなくてはいけない。
業務コンポーネントの性格には大きく二つあると考えている。双務的なものと片務的なものである。すなわち、双務的というのは、BPMから依頼が来てそれを受け付けて、処理を行い、その結果をBPMに渡し、次の処理を依頼するというコンポーネントのことである。一方、片務的というのは、業務プロセスの端に位置するもので、その業務処理から、プロセスが始まるもの、例えばコールセンターみたいなところからクレームがくるとかいったものや業務プロセスが終わらせるアクション、例えば結果をレガシーシステムに登録するとか、掲示するとかいったものである。
さて、書類のライフ以外の双務的なものをみていくことにする。計算型というのは、代表的なものにEXCELで集計したり、縦横計算をさせた結果を戻したい場合などにこのコンポーネントを使う。EXCELを計算エンジンに使うというのは筆者の経験ではけっこうあり得る話であると思っている。ちょっと脇にそれるかもしれないが、縦横計算を駆使する原価計算のエンジンにはＥＸＣＥＬがパフォーマンスがいちばん出るし、最適ではないかと思うのである。
次に外部ルールをコンポーネントとしてみているが、簡単なルールについては、ＢＰＭに内臓するか、適正化機能で実現するのがよいが、「作業割付」、「例外処理」「差し戻し」などについては、外部化せざるを得ないだろう。本来はもっと上位概念的なビジネスルールを取り込まなくてはいけないのだろうが、これまでの議論の文脈から泥臭いところでいいのではないでしょうか。
でこのビジネスルールのことなのだが、最初はよく理解できなかった。ところが、それってデシジョンテーブルですよと言われたので少し調べたら、昔、もう２０年くらい前になるが、筆者が工場のプラント制御に関わっていたころにやっていたことと基本的には一緒のような気がした。例えば、発電所の選択遮断の仕組みって、ケースに応じて、系統を遮断するルールがデシジョンテーブルにセットしてあって、それに従って作動させるわけである。
さらに、例えば「ILOGJRules」というエンジンは人工知能ブームのときのAIエンジンから派生したというじゃありませんか。もう、人工知能だとかAIなんて言葉は聞きませんが、そのころははやったのです。かくいう筆者もエキスパートシステムと称して、プラントの異常検知のシステムをAIすなわちIf Then Elseの技術を使って開発したことがある。いくつかの事象をモニタリングしておいて、そこで異常が起きそうな予兆がでたらアラームを出すという仕掛けでした。何かこれはルールエンジンというよりBAMみたいな機能ですね。
少々脱線したのでもとに戻すと、書類ライフ以外の業務コンポーネントをあげてみましたが、今度はそれをどう作っていったらいいかということになると、書類ライフではオープンCMSの適用がフィットするとしたが、これだけがベストの選択肢ではない。
例えばさっき出てきた計算コンポーネントではEXCELがいいわけだし、コールセンターはそのための専用ソフトがしいし、単純なアクションだったら、それこそ「Tuigwaa（今はEscafeWebというそうだ）」でいけるだろう。ちょっとしたアプリケーションはＲｕｂｙ on Railsかもしれないし、コミュニティサイトはXoopsがいいとか、要は目的や要求機能にあったソフトウエア、フレームワークを選ぶことが大切になってくる。
なぜなら、できるだけ開発要素はなくし、最低限のカスタマイズで使うことが、開発生産性と保守性を向上させるからである。
どの企業もBPMを導入すればいいというものではない。また、BPMSにも適用する機能の順番がある。IT化のレベルが低い企業にいきなり高度な機能を適用しても使いきれない。従って、企業の成熟度に応じて適切なBPMの導入が重要となってくる。
BPMは、その企業に合った最適な業務プロセスを構築することをめざし、プロセスの整理から始まってそれらを高度化するステップ、またできたプロセスを可視化していくステップをマネージすることが大きな目的のひとつとなる。実際には、この最適化までいくのは難しいが、業務プロセスのシンプル化、可視化のレベルをできるだけあげることが求められている。
そのために、BPMSのなかの機能をそのレベルに応じて使い分けることが必要で、BPMSはレベルアップの手段となる。一方、業務プロセスの開発にあたっては、コンポーネントの再利用あるいは共同利用化により、業務プロセスのシステム化範囲の拡大、高度化が可能になってくる。
こうしたそれぞれの要素が、各レベルでどのようになっているのかをざっとみていくことにする。
まず、成熟度の尺度をどうするかは、いちばん分かりやすい「COBIT（Control Objective for Information and Related Technology）」の成熟度モデルをもってくるのがいいだろう。
レベル１ではプロセスらしきものはあまり意識されていない状況なのでBPMは登場しない。
レベル２では一応現状の業務プロセスが描き出されてくるが、当然あるがままの状態で網羅性もないし、属人化されて隠れている場合もあるようなレベルである。こんな場合、BPMは何をすればいいのだろうか。まずは、AsIsベースの業務プロセスをプロセスデザインツールを用いてシンプルで一貫化された適正モデルに整理することだろう。
そして、その業務プロセスをワークフローでシステム化することになる。このとき、整理された業務機能から書類イメージのコンポーネントを抽出する。
レベル３では、適正化されたきれいなプロセスができあがり、ドキュメント化もなされ、かなり可視化された状態となる。ただ、まだ攻めのプロセスにはなっていないし、コントロールされているとは言いがたい。そこで、ビジネスルールやBAMにより、プロセスをより戦略的なものにしたり、また監視をすることによりガバナンスを効かすことを行なっていく。
また、このレベルでは、他システムや外部サービスとの連携が求められるためEAIのような機能が必要になる。このレベルの業務プロセスを構成するコンポーネントは標準化されて出てくるので再利用性のあるコンポーネントができあがる。
レベル４になると、経営方針や事業戦略を反映した業務プロセスが作られ、競合他社と差別化を図る武器になってくる。そのためにも、いつもプロセスの見直しが行なわれ、ビジネス環境の変化に柔軟に対応するための不断のブラッシュアップが行なわれていく。
そこでは、更に密なるシステム間連携やプロセスから生成される情報の分析などが行なわれていく。業務コンポーネントはライブラリー化され、新しいプロセスの構築、あるいはプロセス改良のために活用される。
レベル５は、そこまで達することができる企業はほんのひとにぎりで、いわゆるグローバルな超優良企業でみんなのお手本となる企業なので、ここでは言及しない。
ということで、COBITの成熟度モデルに応じたBPMを考えてみたが、要はBPMというと範囲も広いし、機能も多いし、何と言ってもひとによって様々な定義がなされているのでいくぶん混乱しているように思えるので、こんな整理の仕方をしてみたということである。
ビジネスプロセスライフサイクルとは
企業の経営あるいは事業は、会社が保有するリソース（ヒト・モノ・カネ・情報）とビジネスプロセスから成り立っている。ここではビジネスプロセスはリソースデータを使って構成されるので、データを包含したプロセスというふうに括って、ビジネスプロセスをもって企業システムと呼ぶことにする。従って、自社のビジネスプロセスをどんな構造にし、どんな機能をもたせるかは、効率的な経営や競争優位戦略などにとって非常に重要なことになる。
このビジネスプロセスを開発することについては、「ビジネスコンポーネント指向開発」で詳しく論じたが、このビジネスプロセスは作ったらそれでおしまいというわけではなく、開発したビジネスプロセスをどうコントロールするのか、継続的に保守・運用をしていくのか、そして、不断の改善をやっていけるのかというビジネスプロセスのライフサイクル全体を運用してこそ、経営に貢献できるビジネスプロセスとなる。
従って、それぞれのフェーズにおける体系や方法論を整備し、それに従って開発（Development）・制御（Control）・維持（Maintenance）・改善（Improvement）を行なっていくDCMIオペレーションシステムのことをBPライフサイクル（BPLO）と呼ぶことにする。ここで、マネージメントシステムとは言わず、オペレーションシステムとしたのは、こうしたものは、管理的というより実際に実行してこそ意味があるわけで、そうした思いをこめているからである。
そして、このDCMIについて、それぞれに基本コンセプトがあって、その考え方に従って方法論なりシステムができあがっている。
Dの開発については、今までさんざん述べているように、Business Component Oriented Development（BCOD）ということになる。Cの制御は、Information Driven Control（IDC 情報駆動制御）、Mの維持は、Sustainable System Maintenance（SSM 持続可能保守管理）、Iの改善が、Continuous Process Improvement（CPI 継続的改善運動）である。
これから、このライフサイクルに従って、どのような考え方や方法でやっていったらいいのかについて議論を進めていきたいと思います。
制御については、Information Driven Control（IDC 情報駆動制御）という概念を提示したが、この話にいく前にプロセスということについて考えてみる。
プロセスというと業務プロセスだけではなく、製造工程をさすこともあったり、それこそシステム開発の過程もプロセスである。筆者は若い頃石油化学プラントのプロセスエンジニアをやっていたので、プロセスというと化学製品の生産プロセスを思い浮かべる。この生産プロセスのライフサイクルを考えてみて、業務プロセスと対比してみる。
まず、開発だが生産プロセスの場合は最初はそれこそ試験管からは始まって、パイロットプラントを経てスケールアップされて、完成プロセスとなる。ここでは、もちろん反応方式が違うとかいったことも大きいが、このスケールアップというのが重要なファクターになる。業務プロセスの場合はいきなりどんと全社システムの導入のようなやり方になる。
システム開発ではこのスケールアップというステップがとれないし、これは生産プロセスも同じだが、一部を動かして順次全体に拡げていくというのも、無理すればできないこともないが難しい。ここが、システム開発のやっかいなところで、そのため導入時にはいくつかの弊害がでてくる。
例えば、業務間あるいはシステム間の全体整合をとるためにすごい苦労をしたり、プロジェクトの最後にはやみくもにコーディングして後で泣くとか、長いテスト期間をとるとか、そういった一発勝負的な開発が多いような気がする。ただし、これは今までの話であって、これからはこの問題についても解決手段として、BPM on SOA
が有効になる可能性があると思っている。
ここで忘れてはいけないのが、全社リソースデータが一元管理できていることが重要な前提となることである。スケールアップや順次稼動の場合、個別にデータベースを作っていたのでは、整合性のとれない“サイロ”システムを生み出すだけになるおそれがあるからである。
さて、生産工場などにおけるプロセスはどのように可視化されているかというと、実物の機器や配管などが目で見えるというのも大きな違いであるが、関係者がコミュニケーションできる共通の図面の存在も違いのひとつではないだろうか。
プラントでは、オペレーター、スタッフ、保全担当、安全担当などの人々は、何かあると必ずP&ID（Piping & Instrument Diagram）というものを見ながら話をする。文字どおり、プロセス流体の流れ、遷移状態、プロセス変数などがすぐに分かるようになっている。それと、配管図や機器図などを参照していけば、プロセスは可視化できるのである。
翻って、業務プロセスはどうか。このP&IDに当たるものがない。配管図や機器図に当たるものは、ネットワーク図やハードウエア構成図などがあるが、プロセスの動的な部分も含めて、流れの状態がわかるような図面がないように思える。業務フロー図、業務マニュアルがあるじゃないかといわれるかもしれませんが、それで制御できるのだろうか。
ここで強く言いたいのは、同じプロセスという概念で扱うのであれば、ただ開発したらあとはエンドユーザのひとにおまかせと言うのではなく、その後の制御、維持、改善を考えたライフサイクルを意識することが大事だということである。
特に、生産プロセスの場合は、制御というところにすごく重きを置いているわけで、そのためには、プロセスの設計には現場のオペレーションする人たちのかかわり方が強くある。自分たちがオペレーションしなくてはいけないプロセスは自分たちで考えようじゃないかという当たり前の話なのだ。
従って、業務プロセスの設計・開発にもあとで実際にそのプロセスを使ってオペレーションする人の参画を濃いものにしていかなくてはならない。これは、開発側の問題でもあり、ユーザ側の問題でもある。もちろん、ユーザ参画はいまでもやられているプロジェクトもあるが、もう少しその気になった参画と、あとの“制御”という考え方を取り入れた設計を行なう必要があると思う。
制御だけではなく、維持、改善というプロセスについても、生産プロセスの場合はかなりシビアに管理している。従って、業務プロセスの場合もこうしたことを含めたライフサイクルが非常に重要なことになる。
化学プラントのようなプロセスやその他の生産プロセスでは、プロセスを制御して生産性をあげるだとか、安全・安定な製品を作るということが重要だという話をした。ところが、ホワイトカラーの事務処理のような業務プロセスでは、プロセスを制御するという考え方が薄いような気がする。これまで、この領域ではコンピュータシステムを作ることに汲々としていて、しかもできたらそれで終わりみたいなところがあって、画面のレスポンスやバッチの処理時間のようなことには敏感だが、これはシステムの制御であって業務プロセスの制御ではない。
BPMはプロセス制御という考え方を取り入れてきているが、制御とはなにかという定義の問題も含めてまだバラバラのような気がする。プロセスのある部分での停滞を監視して、停滞箇所での処理を促すのか、系のパフォーマンスを算出するだけなのかというように、何をモニタリングして、その結果をどのように生かすのかが定まっていない。
それはBAM（Business Activity Monitoring）でしょという声が聞こえてきそうだが、BAMというのは、リアルタイムでモニタリングして何か異常事象が発生したらワーニングしたり、対応アクションにつなげたりすることなのだが、ただこれだと制御というイメージではなく、プラントで言えば安全装置を働かせたり、バイパスしたりといったことに相当する。だから、制御というのはプロセスが安定して動くようにどうするかということとその異常時対応の両方で成り立つ。
さて、制御には2段階あって、まず系を安定させる制御と異常時の対応ということなのだが、BAMの機能で言われていることを本当に有効に活用できる企業ってどれだけあるのだろうか。BAMの目的は、重要なビジネス目標をモニターし、オペレーション上のリスクを予知し、事後事象からアクション開始までのタイムラグを低減することなのだが、オペレーショナルレベルとビジネス目標が必ずしも密接につながっていることは少ないことや、異常事象とプロセス変数の相関も難しいし、そこから因果関係を見つけて操作変数を動かすのはもっと難しいことから、うまく（自動的に）使われるとは考えにくいのは筆者だけだろうか。少なくとも、相当成熟度レベルの高い企業にしか適用は難しいと思う。
なお、BAMは、またBIと組み合わせて改善につながるための監視機能にもなる。そこについては改善の項で言及する。
一般の会社においては、情報だけはもらうが、それを使ってどうするかは、結局人間の判断というのが現実的であろう。だから、プロセスをスムーズに回すにはどうしたらいいのか、システムはそれにどう寄与するのかという制御を考えたほうがよさそうだ。
それは、この方法論では「情報がアクションを誘導する」仕掛けである。具体的には、まずはCMSによるコラボレーションサイトである。これまでの、仕事のやりかたやシステムの構成は、どちらかというと逐次的な処理形態をベースにしている。すなわち、何かの処理が終わると次に回してという風に順番に仕事をこなしていく。しかも、その処理の受渡しは、次の処理を行なう人が情報を取りにいくプル型の流れになっていたのが多い。こうだと受け手が情報を見ないとそこで停滞がおき、相互の連携が切れてしまうので、全体の系の動きがコントロールできなくなる。
従って、これをプッシュ型に変えて、さらにその情報が関係者全員に分かるように公開することで、誰の手にボールがあって、次はどこに投げられ、どこで止まっているかが見通せるようにすることが大事だ。そうすれば、人間の目ではあるが、プロセスを円滑に機能させるためのドライビングフォースになる。一種のピアプレッシャーである。こうした、情報共有型業務処理では、人間の目による制御機構が働くことになる。
一方、マクロワークフローを回す部分では、システム的なパフォーマンス監視での制御となる。それぞれのプロセス変数に対して、閾値を決め、それを越えるようならワーニングを出す。ここは、定型的、安定的な処理になるため、こうしたシステム的な制御が有効になってくる。
何回も繰り返してきていることだが、業務処理のタイプ、すなわち、定型的かそうでないか、安定なのか不安定なのかといったことにより、その開発方法、稼動プラットフォームが違うのと同じように、その制御の仕方も違ってくるのだ。その制御方法こそ、情報駆動制御（Information Driven Control（IDC））ということになる。
さて、業務プロセスを開発して、制御したら、それを維持していかなくてはならない。日常的な運用や保守である。それは、ビジネスプロセスそのものの維持とそれを動かしているシステムの維持という二つの側面を持っている。
システム屋さんは、この前者のビジネスプロセスの維持という観点が薄いというか、ないのではないでしょうか。しかし、重要なのは、たえず事業に貢献できるプロセスであり続けるかというチェックである。単にユーザから変更要求があったら、それに対応すればいいという態度では、プロセスの劣化も起こるだろうし、つぎの改善というアクションにつながっていかない。ですから、ビジネスプロセスの維持管理は、BPライフサイクルでも軽視できない大事なサイクルである。
それでは、ビジネスプロセスが劣化するとはどういうことなのだろうか。劣化することがあるのだろうか。ビジネスプロセスそのものの劣化はないのではないでしょうか。腐るわけではないし、壊れるわけではないので。たとえば、プロセスに慣れてきたため、注意を怠って、誤って出荷先を間違えたなんてことが、プロセスの劣化とは言いがたく、それはオペレーションの問題でどちらかというと制御の領域と考えられる。
となると、ビジネスプロセスの劣化というのはどうも、法や制度の変更も含めたビジネス環境が変わったのでそれに対処するためにプロセスを変えていかないとビジネスが維持できないというケースがこれに当たるのではないでしょうか。改善とは違って、受身的な対応である。人事システムのように、毎年法改正や組織改正があってそれに対応するための変更が必ずあるというものもある。ですから、どこの会社でもあると思うが、年末調整の前や組織が変わるある時期だけ忙しくて、そのほかはメンテはほとんどないということがある。
他のシステムでも、人事ほどではないにしても、法や組織改正による変更が発生する。それ以外にも、競合他社に離されないためにプロセスを変えざるを得ないだとか、画期的なサービスや技術が登場して、それに対応しないと取り残されてしまうとかといった、ビジネスのレースから脱落しないための維持管理ということも非常に重要なことである。
こうした素早い変更ができるためには、プロセス自体が変更に強い構造になっていなくてはならない。機能とプロセスを、そしてデータを分離して、疎結合にしておくことで対応することになる。こうしたSOAのシステム基盤こそが、保守性の向上に大きく寄与するのだ。
さて、次はシステムの保守という問題である。ただ、これは従来からやられていたことだから、ここであえて採りあげるつもりはないが、ひとつ注意しなくていけないのに、オープンソースのソフトウエアの保守をどう考えるかがある。オープンソースは、使うのは無償ということもあり、開発時はコストもかからないからと飛びつくが、そのあとの保守をどうするかは考えていないことが多い。
バージョンを上げたら今のアプリケーションが動くかどうか誰がみてくれるのかとか、そもそもそのオープンソースのコミュニティがなくなってしまうというリスクもあるわけで、導入コストだけで判断すると危険である。ですから、まずはオープンソースといえどもメジャーでコミュニティも活発で、特に日本の活動がちゃんとされているものを選ぶのが大事だ。
そして、ソースコードをある程度読める要員を確保することが望ましい。本を書くのは難しいが読むのはそう難しくないように、プロダクトをクリエイトするのは難しいが、ソースを読んでどんなコードで成り立っているくらいは分かると思う。そういう人であれば、コミュニティへ参加して教えてもらうことも可能だ。もし、そうした人材も確保できなかったら、お金を払ってその橋渡しをしてくれる人か、会社を確保すればよい。
だから、オープンソースだとお金がかからないということはなく、維持管理にはコストがかかるのだ。これは商用のソフトウエアと同じで、自己責任の範囲を広げてコストダウンをするのか、コストをかけて責任を回避するのかということである。そこは、自社の人的リソースの状況あるいは対象アプリケーションの性格などによって、どちらを選択するか決めればいい。
「ビジネスコンポーネント指向開発」において、オープンCMSを採用した理由は、フロントの確定データを作るまでのコラボレーション業務に適用しているので、言ってみれば、重要度が落ちる領域であるからである。極端な話、そこで不具合があって動かなくなっても、電話とメールで会話して、手で入力すればすむのであって、そんなクリティカルなことではないのである。
逆に、その確定データが投入されたあとのシステムの不具合は、影響が多くなるため、商用ソフトウエアを利用する考え方をとっている。
ですから、こういうところにも適材適所のシステム構造を設計していかなくてはいけないのだ。
何と言ってもビジネスプロセスは持続可能でなくてはならない。そのためにもこうしたSustainable System Maintenance（SSM 持続可能保守管理）という考えかたが重要になってくる。
さていよいよ最後のプロセスの改善徒言うことになる。これは、昔BPR(Business Process Reengineering）というやつに近い。当時のBPRはいきなり業務改善のような話だったり、会社全体の大きなプロセスを対象にしたりしていて、何となくついていけなくて消えていった。今またBPMという形でつながってきている。BPMの場合は、プロセスのモデル化をして、そこからかいぜんというアプローチだから以前に比べると地に足がついたことができるような気がする。
ビジネスプロセスは、環境の変化や新しい技術の出現、経営からの要求度など、経営も変化していくのに合わせて、プロセスも進化していかなくてはいけない。そのために重要なことは、現状をよく監視し分析することである。今何が起きていて、どういう問題があるのか、そういったプロセス全体の状況をよくモニタリングすることから始めていく。それを可能にしてくれる機能がBAM（Business Activity Monitoring）である。
また、広くBI（Business Intelligence）もBAMの一種と考えてもいいような気がする。ただ、両者の違いは、リアルタイム的か定期的かということと、対象が事象なのかデータなのかの違いがあるが、そう大きな差はない。両方とも必要なソリューションである。だから、BAMでどこかのプロセスに停滞はないのか、納期に遅れないか、このままだと問題が起きそうだとか、そういった現時点での対処につながる監視を行なうのである。
これは制御に似かよった話である。在庫が切れそうだからアラートを出すなんていうのは制御のレベルである。BAMはもう少し改善につながるための監視であると考える。ただし、どんなプロセスでもBAMの効果が出るとは限らない。そんなにリアルタイムにプロセスを監視していて、瞬時に対応するなんてことをやる業種ってなんなのだろうか。ジャストインタイムのようなことをしているところなのか、よくわからない。
一方、プロセスから生み出されて様々なアクションの結果がデータとなって蓄積されるので、それをBIにより解析し、相関関係あるいは因果関係を探っていくことになる。BIについては、BPMというところからの入り方というより、どんな企業でも大なり小なり、データ解析は必要であり、そこから改善の芽が生まれてくる。だから、データ・情報活用という観点でみていけばいい。
このBAMというのはどうもある程度成熟した企業がやっと取り組めるようになるソリューションであると思う。最初にBPMに取り組んだ会社は、いきなりBAMまでいかずにせいぜい何とか自分たちのプロセスをコントロールすることが大切である。そこで系を安定させておいて、次に問題箇所を見つけ出し改善していくというステップだ。
いずれにしろ、こうした取り組みは不断の努力によって成しとげられるので、Continuous Process Improvement（CPI 継続的改善運動）として地道でいいから自然に続けられる仕掛けが大事になってくる。
この「ビジネスコンポーネント指向開発」の技法は世間的には何という名前なのだろうか。いわゆるソフトウエア工学では、従来の構造化分析、構造化プログラミングといった構造化手法からいまはオブジェクト指向というふうに変わってきていると書いてある。
構造化技法というのはDFDを書いて、プログラムを関数という「部品」に分割して、それを組み合わせてソフトウエアをつくると言われてもだいたいわかるが、オブジェクト指向はよくわからない。オブジェクト指向で、「データ」と、それを操作するための「メソッド」の組み合わせて、それをカプセル化したものが「オブジェクト」ですと言われても、これって構造化手法のこととどこが違うのと思ってしまう。
一方、オブジェクト指向はプログラミングから来ているから、分析とか業務設計には向いていないとも言われている。DOAをやっている人がよく言う。確かにUMLでビジネスを書かれても、特にユーザは理解できない。ユーザに理解してもらえない手法は、システム屋のマスターベーションでしかない。だからといって、DOAのER図がユーザから理解されるかというとこれもなかなかむずかしい。
DOA（Data Oriented Approach）というのは、和製英語で堀内一さんが最初に言い出したものでが、それまでのPOA（Process Oriented Approach）というものは今はどうなっているのだろうか。
こうしてみると開発手法は、構造化手法、オブジェクト指向、DOA、POAとあるが、これだという決定打はないように思える。いまは、オブジェクト指向ばかりのように見えるが、それだけで満足できるものができるかどうかあやしい。筆者は、それぞれの手法を適材適所的に使うことを提案したい。言い換えれば、それを実行しているのが、「ビジネスコンポーネント指向開発」なのである。
システムは（ビジネスといってもいい）、再三言ってきたように機能とプロセスとデータから成り立っている。これらを設計するのに、基本的に機能はOOA（Object Oriented Approach）、プロセスはＰＯＡ、データはＤＯＡ、全体を「構造化」するという考え方である。ここでいう「構造化」というのは、構造化手法ということではなく（いわゆる構造化手法というのは、ＰＯＡやＯＯＡに引き継がれている）、ＳＯＡの概念で柔軟な構造にするという意味です。
ここで注意しなくてはいけないのは、全く別々にやるわけではなく、主としてその手法を用いるといった程度のものである。逆に共通するもの、あるいは交差するものもある。
例えば、機能といった場合、いまオブジェクト指向で言う「オブジェクト」という概念をあてはめているが、ＰＯＡでは「アクティビティ」であり、ＤＯＡでは「エンティｒティ」に相当する。だからそこでお互いが結ばれていくというイメージです。もう少し説明を加えると、ＯＯＡで実ビジネスおける概念をしっかり定義することであり、そこから生まれたアクティビティ（コンポーネント）をＰＯＡでシンプルなプロセスにし、ＤＯＡでリソースデータを中心にしたデータインフラを構築するというのが正しい方向である気がします。
この考え方を「ビジネスコンポーネント指向開発」において具体的に説明すると、まず「オブジェクト」を書類というふうに定義しています。ビジネスではほとんどの場合、書類の受渡し（紙ではなくても）により仕事をしています。だれかに依頼され、それを処理して、つぎに渡すという流れですが、それは書類という「オブジェクト」を作成し、できたものが「クラス」と言ってもいいかもしれませんが、その書類が転記されていくことが処理に当たると考えています。
この「クラス」が、「アクティビティ」となってＢＰＭに飛んでくるわけです。ＢＰＭではＰＯＡに考え方によりプロセス中心に構築していきます。「ビジネスコンポーネント指向開発」では単なる「アクティビティ」ではないもう少し、広いサービスのようなものも対象にしますから、それらもひっくるめて「ビジネスコンポーネント」と呼んでいるのです。
次に、データとの関係を見て行きましょう。ＤＯＡでは、ＥＲ図を書くことでデータとプロセスが表現できることになっています。ＤＯＡでは、まずリソースデータとイベントデータに分けて設計します。リソースデータは､人・物・顧客などの、いわゆるマスタデータで、イベントデータは、「○○する」という言い方ができる、例えば、受注、出荷、購買といったものがこれにあたります。そのイベントデータは時系列的においていきますから、プロセスを表現していることになります。
とういうことは、それでプロセス設計ができるじゃないかと言われますが、なかなか分かりにくく、ユーザには難しいのです。従って、ＤＯＡでリソースデータベースの設計を行ない、ＢＰＭ側はそのリソースデータを使ってプロセスを回し、そこで発生したイベントデータはＢＰＭ側で作るというのがいいのではないだろうか。
このデータベースの設計と蓄積されたデータの活用も含めたデータベースマネージメントについては次回に提示する。
大きく二つに分かれる。インフラ系のデータベースとイベント系のデータベースである。イベントデータは、前回にも書いたようにプロセスに結びついたトランザクションデータとなります。ですから、このデータベースはプロセスの設計時にそのアクティビティに付属するデータとして捕捉されます。Savvionではデータスロットに格納されるデータということになります。
ここでの議論は主にインフラ系のデータベースについてとなります。インフラ系のデータベースはリソース系と参照用データベースにわかれます。リソース系というのはマスタデータ、参照用というのはデータウエアハウス（DWH）と言い換えてもかまいません。
DWHは、さらにセントラルDWH（エンタープライズDWH）と用途に応じて絞り込んだデータマートに分解されていきます。
さて、「ビジネスコンポーネント指向開発」では、業務プロセスが可視化され、そのプロセスから生じたデータがイベントデータベースに格納されて、そのデータをモニターしてプロセスの制御を行なったり、パフォーマンスの解析に使ったりする。
また、エンタープライズレベルでは、BIツールを使ってデータ分析を行ない、BSCなどの業績評価や管理会計につながっていく。筆者は管理会計というのはデータウエアハウスだと思っていて、静的データはリソースDBから、動的データはBPMのイベントDBからもってきてマッピングするのではないでしょうか。
このように、データベースもその使い方や性格に応じて構造化しておき、相互の連携を行なうことが大事である。場合によっては、EAIのようなツールを使うことになるかもしれません。
特に、リソースデータ（マスタ）は、One Fact in One Placeの原則をきちんと守り、システム開発の最初に構築しておくことが望ましい。
最近、マスタデータマネジメントシステム（MDM）という言葉を見かけるになってきた。意外とこのマスタデータを運用・管理するのは手間がかかるものである。多くは人手を介して泥臭くやっているのではないでしょうか。エンドユーザ自身にやってもうというのもあるかもしれないが、いずれにしろここはシステマチックにいきたいものです。
ここでもBPM－CMSを使ったシステム化を推奨します。すなわち、マスタの追加･変更をCMS上に流し、そこで承認を得たものがBPMを通してマスタに飛んでいくというイメージだ。システム部門ですぐにできるのでそこからはじめたらどうだろうか。
BPMというと、どうしてもプロセスに目が行ってデータベースがおろそかになるが、データベースありきが前提というわけには行かない場合もあるので、プロセス設計と同じようにデータベース設計も重要であることを忘れないようにしたいものだ。
ビジネスプロセスにはマクロワークフローとミクロワークフローがあるということを言ってきて、ミクロワークフローは、人間主体のグループとしての情報共有型業務であることも言ってきた。
ところでさらにもう少し踏み込んで考えると、個人の業務管理はどうなのということがある。この個人の業務管理というのは、フローではなくタスク管理ということになる。すなわち、個人のタスクが、いまどういうものを抱えて、それがどんなステータスなのか、期限がいつなのかというようなことを管理することが重要になる。まあ、TO DO管理ということかしれない。
一方、以前業務コンポーネントの種類ということで、書類という定義だけでは収まらないこともあって、プロセスの開始点、例えばコールセンターのクレーム受付といったものは、書類化以前のアクションで、こうしたものをどうするかという課題があった。
また、プロセスの途中でも、「計算処理」だとか「作業割付」みたいな割り込み処理のようなものが入る。それは、別のサービスとして処理を依頼して、その処理結果を戻してもらうということがある。それをどういうやり方、あるいはどういうサービスツールで実現するのかという課題もあった。
計算処理は大体がEXCELでいけると思うが、ほかのところをどうするのかが課題であったが、個人のタスク管理という視点のツールが多分これを満たしてくれるような気がする。すなわち、ここでもガチガチスタイルの管理ツールではなくもうちょっとゆるやかなものです。
そうなんですね、人間関係に入ったら、人間の脳コンピュータに任せて、機械コンピュータはおとなしくしているというのが望ましい態度なのではないでしょうか。そういう意味では、ゆるいシステムがいいのだが、ただそれだと野放図になっても困るので、ある種のルールあるいは作法がそれを規制する姿でいいんじゃないかと思う。
それで、最近「グルット」というツールを注目している。イッシュートラキングシステムと名乗っているけど、まあタスク管理システムでいいんだけど、要はEXCELライクの表で自分のタスクを管理するソフトなんだけどゆるいからいい。
システムの歴史は、システムが人間を支配する、あるいは人間の振る舞いを表現できるというように動いた気がする。しかし、現実は、システムは人間を超えられないという当たり前の事実に向き合っている。システムの生物化がいまだにできていないということである。
じゃあどうするかというと、もっと人間と融和した関係を“システマチック”に作ることが大切なのではないだろうか。プロセスのつなぎに人間が介在するという言い方もできる。
だから、これからの「BPM＋web2.0」がその傲慢さを反省し、人間との共生を目指したシステムになりうることを期待するのである。
ブログ「mark-wada blog」のカテゴリ「ユーザ目線のＢＰＭ」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。
次のカテゴリは企業情報システムのかたちです。