@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

ユーザ目線のシステム作り:SOA(BPM+Web2.0)

投稿者投稿内容
ひら
ぬし
会議室デビュー日: 2005/03/04
投稿数: 260
投稿日時: 2008-01-14 00:54
引用:

加納正和さんの書き込み (2008-01-13 21:54) より:
どう考えてもWeb2.0系統を使う人々と「業務」の人々と交わるところが全くありません。
性質が正反対です。



もしかしたら失礼な言い方になってしまうのかもしれませんが、私にとって、ある程度
予想通りの反応でした。(以下、一般論です。)
アイデア出しというのは、反対する人が多ければ多いほど成功に近いといわれています。
逆に賛成する人が多いものは、たいしたモノではないと
思いますので、逆説的な言い方をすると加納さんのような意見があって、
まぁ良かったのかな?とも思います。(お気を悪くされたのであればごめんなさい)


業務の鏡像に近いものをシステムにするのが、システム構築の理想の姿でした。
しかし今は、むしろシステムが業務を凌駕していますので、Web2.0が
システムを通じて業務を支配するのもそう遠くはないと思います。


引用:

cordwainerさんの書き込み (2008-01-14 00:09) より:
最終的に出来上がるものが、イメージできません。
抽象的な概念が多過ぎます。



正直、私にもイメージできません。
しかし、Web2.0+業務というのは、既にIT系サイトで記事になっているという
ことを考えると、大して斬新でもないのかな?と思います。
http://itpro.nikkeibp.co.jp/article/NEWS/20060305/231740/



[ メッセージ編集済み 編集者: ひら 編集日時 2008-01-14 00:57 ]

[ メッセージ編集済み 編集者: ひら 編集日時 2008-01-14 00:59 ]
mark
常連さん
会議室デビュー日: 2007/12/31
投稿数: 35
投稿日時: 2008-01-14 10:42
markです。
ちょっとことわっておきますが、本来ならこの技法の全部をお見せしてからご批判やご意見をもらったほうがいいのですが、こういう場なので順番に小出しで書いているため、抽象的だとか新規性がないといったコメントがあるのは仕方ないと思っています。まあ、あせらずやりましょう。(笑)

ところで、この技法で作った、原初的ですが、実際に動くサンプルシステムがすでにできていますので、ただ紙に書いただけのものではないことはご理解してください。ですから、あとで具体的な姿を示すことになります。

さて、しつこいようですが、もう少し業務機能について見ていきます。要件定義において現場で作業をしている人にヒアリングをしてアクションレベルの項目をあげていくと、どのプロセスにも共通的に登場してくるものがピックアップできます。

作業受付/作業依頼/書類作成/書類完成/承認/参照/確認/連絡/転記/報告/メール送信/DB登録/帳票出力/実作業/外部サービス利用などです。まあ、他にもあると思いますがざっとこんなところではないでしょうか。

ここでこれらの業務処理形態をじっとながめてみてください。ある単位で括れそうと思いませんか。ここからが本技法の特徴的なものになります。最初にあげた、作業受付/作業依頼/書類作成/書類完成/承認というのは、どうも何か依頼があってそれを書類という形で起こし、それを完成して承認をもらい、つぎの作業の依頼をするというミクロ的なワークフローあるいは書類というオブジェクトを状態遷移させるというイメージになります。

なお、業務プロセスの始点になる依頼・受付のところは、単純に書類を起こすことができない場合があります。コールセンター的な業務処理ですね。それは書類の状態遷移とは違うので別のコンポーネントとしたほうがよさそうです。

また次の参照/確認/連絡は関係者とのコミュニケーションをとりながらのコラボレーション作業ということがいえます。そして、これらは書類を作成している途中の行為として行われます。

その他は実作業、外部サービスを除くと、データの処理といったワンショットの一方通行的な行為になります。

ということで、どうもメインの業務処理は書類の作成から発行とコミュニケーションになりそうです。この形態が詳しくは後述しますが、Web2.0的な動作であるような気がします。すなわち、「集合知」「参加型のアーキテクチャ」「永遠にβ版」といった考え方で、そうしたことを具現化するものとして、Web2.0のサービス(CMSなど)や技術(Ajaxなど)を使おうとしています。

また、コミュニケーション作業のなかで、オフラインで情報処理をしてもらいそれを参考にするということがよくあります。そうしたデシジョンサポートもコンポーネントに入れておきます。そこで業務コンポーネントの種類とどこに適用するのかを整理してみます。

(1)書類ライフ型(ミクロワークフロー)
   社内プロセスのほとんどはこのコンポーネントが使える。
(2)依頼・受付型(コールセンター)
   顧客接点における依頼、相談、苦情などを受付ける場合に使用する。
(3)SNS型(コミュニティ)
   ある目的を持ったコミュニティで議論をしながら意思決定を行なう場合だが、大方 は書類ライフ型でやれる。製品開発や研究などで使われる。
(4)デシジョンサポート型(計算、作業割付、スケジューリング、評価見積等)
   何か判断したいときに計算した結果などを参考にする場合に使用。ほとんどが、書類の記載内容に反映されるので、書類ライフ型の下位コンポーネントとして扱う。
(5)シングルアクション型(DB登録・更新、メール送信、帳票出力等)
   一方通行的な処理で、そこでプロセスが終わるもの。
(6)外部サービス型
   与信や銀行残高照会などのように外部のサービスを利用する場合に使用する。

こうしたコンポーネントが、BPMSのフロンエンドになるわけです。
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2008-01-14 23:47
引用:

markさんの書き込み (2008-01-14 10:42) より:
markです。
ちょっとことわっておきますが、本来ならこの技法の全部をお見せしてからご批判やご意見をもらったほうがいいのですが、こういう場なので順番に小出しで書いているため、抽象的だとか新規性がないといったコメントがあるのは仕方ないと思っています。まあ、あせらずやりましょう。(笑)



意思疎通というのは難しいものですから。
議論は訓練しないとできるようになりませんし。
焦る必要はないでしょう。

個人的には、同じことを繰り返し説明されているように思えます。
説明に新たな要素が出てこないので、「新規性」という隠し玉が
どこに眠っているのか気になるところですね。

プログラム言語を用いないことを「ノンコーディング」と言っているのかな?
扱うものがプログラミング言語だろうと、自然言語だろうと、
やりたいことを整理し、仕組みを捉えアルゴリズムを考え固定化するのには
プログラミング技術が必要なので、プログラム言語さえ避ければ
ユーザが自分でシステムを組み立てられるということにはなりません。

コレをどうやってクリアしようと考えているのか非常に気になります。
七味唐辛子
ぬし
会議室デビュー日: 2001/12/25
投稿数: 660
投稿日時: 2008-01-15 00:20
引用:

nagiseさんの書き込み (2008-01-14 23:47) より:
意思疎通というのは難しいものですから。
議論は訓練しないとできるようになりませんし。
焦る必要はないでしょう。

個人的には、同じことを繰り返し説明されているように思えます。
説明に新たな要素が出てこないので、「新規性」という隠し玉が
どこに眠っているのか気になるところですね。




それは 自分も感じてました 話が振り出しに戻っている。
フラクタルな構造になっていていつまでたっても底が見えない
想像で書くとデータ処理は外部のサービスをWEBを通じて使うまたは
コンポーネントと呼ばれる物で処理をするからノンコーディングでOkといいたのでは?

そしてコンポーネントと呼ばれる物はおそらくCOM+とかCORBAのことをさしているのでは? ちなみにCORBAを使ったシステムをあるのか?思う人はいると思うけど、ちゃんと使われています。 

[ メッセージ編集済み 編集者: 七味唐辛子 編集日時 2008-01-15 00:30 ]
ひら
ぬし
会議室デビュー日: 2005/03/04
投稿数: 260
投稿日時: 2008-01-15 01:02
markさんのご意見にはほぼ異論ありません。ただ、

引用:

markさんの書き込み (2008-01-14 10:42) より:
この形態が詳しくは後述しますが、Web2.0的な動作であるような気がします。すなわち、「集合知」「参加型のアーキテクチャ」「永遠にβ版」といった考え方で、そうしたことを具現化するものとして、Web2.0のサービス(CMSなど)や技術(Ajaxなど)を使おうとしています。


おそらく、Web2.0に無理やりこじつけている?もしくは、Web2.0を勘違いしている?
ように思いました。

世の中には、Web2.0を謳っておきながら、実際にはAjaxにしか対応していない
ようなツールというのは割と多いです。それと似た感覚です。
mark
常連さん
会議室デビュー日: 2007/12/31
投稿数: 35
投稿日時: 2008-01-15 10:11
markです。
新規性について少し。個別の要素に新規性がなくともその組み合わせに新規性があればそれは立派な創造であると思っています。外山滋比古が「思考の整理学」で言っている、第二次的創造であり、ちゃんぽんではないカクテルのことです。

それよりも、私は「新規性」自体に価値を見出しているわけでもなんでもありません。自分のやりたいことを実現させるために新たな仕組みや技術、考え方を使っているだけです。私の場合、ここで言っている自分のやりたいことは5年前からやりだしたのですが技術がついてこないだとか、サービスがなかっただとか難しかったのです。それが、ここにきてやっと実現できるようになったということです。

今回は、ミクロワークフローとしての書類のライフを考えていきます。前回、書類ライフ型の業務コンポーネントということを提示しました。書類のライフというのは、まず書類を生成して、それに対して関係者からアドバイスやコメントをもらいながら、書類を編集し、完成させます。そして、承認をもらい発行するということをさします。

これはあたかも、作業依頼がきて、それに対して何らかの処理を行ない、次の作業を依頼するということと同じだと考えたわけです。

ですから、必ずしも、現実に紙の書類がなくてもかまわないのです。例えば在庫引当なんていうのは、仮に「在庫引当依頼書」があるようにして処理することになります。

なぜ、書類というものを持ち出したのかというと、ユーザの人がイメージしやすいからです。ふだんでも作業依頼する場合もメモを渡したりしてやりますよね。

これを、CMS(Contents Management System)で実現していきます。CMSとは、「Webコンテンツを構成するテキストや画像、レイアウト情報などを一元的に保存・管理し、サイトを構築したり編集したりするソフトウェアのこと。広義には、デジタルコンテンツの管理を行なうシステムの総称。」ですが、このコンテンツのひとつを書類と規定していきます。

今動いているサンプルの実例で言いますと、CMSにオープンソースの「Plone」を使っています。PloneはオープンソースのアプリケーションサーバーであるZopeとその関連プロダクトであるコンテンツ管理フレームワークの上に構築されたコンテンツ管理システムです。

このCMSには、ワークフロー機能がついています。コンテンツの状態遷移の管理と権限の付与などができます。主な使い方は、Webサイトの構築をして、それを承認してから公開するといった業務に使われます。

そのCMSをBPMSのフロントエンドとしてもってきます。なぜかというと、この議論の最初のほうでも言いましたが、データを確定するまでの振る舞いって、関係者同士のコラボレーションで決めていきますよね。そのプラットフォームにはCMSが適しているように思うのです。

ではそれをCMSでどうやるかですが、まず担当者が書類を作成し、CMS上にアップします。例えば、工事の仕様を決めたいといった場合には、「仕様書」という書類を作りそれをあげます。それに対してアドバイスやコメントを書ける人をメンバーとして、そして承認権限を持った人を承認者として登録しておきます。その人たちが、「仕様書」原案に対して何か言いながら、追加、削除、変更などの編集を行います。それでOKであることが確認されたら承認され、発行されるわけです。なお、ここで発行すると言うのはBPMSへ渡すということを意味しています。

これは、情報共有型のコラボレーション業務です。従来こういった作業は、電話、FAX、メールなどで行なわれていたのではないでしょうか。そして、一本道的ワークフローでやっていたように思います。

それを「参加型」にし、「集合知」を導出しようということです。少しおおげさかもしれませんが、こうした形態にすることで、私は3つの利点があると思っています。

ひとつは、承認者が最初から参加していますから、書類の確定までの経緯が見られる、あるいは自らも参加できることによって決定が早くなるということです。

2番目は技術継承の問題です。いま、ベテランのひとたちの退職により技術やノウハウが散逸してしまうといわれていますが、いまのうちにこういう人たちをメンバーに加えておいて、若手が作った書類に対してアドバイスをしてもらうということです。これはずっとアーカイブされますし、貴重な実践的教育資料となるのではないでしょうか。

3つ目は、コンプライアンスの問題です。情報共有ということは情報開示のことでもあるわけで、衆人監視のなかで業務が進みますから、不透明な決定は排除されていきますし、ここでも決定のいきさつがアーカイブされます。

ということで、不定形、不安定なフロント業務を書類というオブジェクトの状態遷移(ミクロワークフロー)と捉え、Web2.0的サービスであるCMSで行うことの有効性を私は評価しているのです。
 
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2008-01-15 10:35
引用:

markさんの書き込み (2008-01-15 10:11) より:
markです。
新規性について少し。個別の要素に新規性がなくともその組み合わせに新規性があればそれは立派な創造であると思っています。外山滋比古が「思考の整理学」で言っている、第二次的創造であり、ちゃんぽんではないカクテルのことです。



それはそれで創造的だと思うんですが、問題は、
その組み合わせってすでにされているよ?という部分なわけで。
組み合わせに新規性があると思えないので、
パーツに新規性が眠っているのかと思っていました。


引用:

それよりも、私は「新規性」自体に価値を見出しているわけでもなんでもありません。自分のやりたいことを実現させるために新たな仕組みや技術、考え方を使っているだけです。


新規制がなくとも、車輪の再発明だろうとも、トータルでまとまった
ソリューションであればその利便性から価値はあると思いますよ。
そういう方向性なんでしょうか?


引用:

今回は、ミクロワークフローとしての書類のライフを考えていきます。


この部分に関しては、業務の基礎的な話ですから
世の中にたくさんの前例があるわけで、その方法論は過去に幾度も
アプローチされてきているわけですよ。
そして、決定版がないというのが現状なわけです。

それらの過去のフレームワークの失敗をどのように分析して
どのように工夫をなさったのでしょう?
そして、そこに工夫があるのであればそれこそが新規性ですよ。
そこを見極めたくてこのスレッドを注視している人がいるのではないでしょうか。


引用:

これは、情報共有型のコラボレーション業務です。従来こういった作業は、電話、FAX、メールなどで行なわれていたのではないでしょうか。そして、一本道的ワークフローでやっていたように思います。


システムを作った会社はシステムで行っています。
システムを作っていない会社は古典的な手法でやっています。
「従来」というとちょっと語弊がある気がしますね。


結局のところ、
「大量生産の既製品で事足りる相手に既製品を提供しよう」
という方向性なんですよね?

書類のライフ云々の部分ってのはあなたがたが作り上げた既製品なんでしょう?
必要に応じてERPとかとの連携もできるみたいですけども。

[ メッセージ編集済み 編集者: nagise 編集日時 2008-01-15 10:35 ]
ちゅき
常連さん
会議室デビュー日: 2005/02/18
投稿数: 41
お住まい・勤務地: 関西
投稿日時: 2008-01-15 22:57
引用:

markさんの書き込み (2007-12-31 11:38) より:

大晦日のあわただしい中の会議室開設ですが、とりあえずこんなところで年明けから本格的な議論に入っていきましょう。




とりあえず、どの部分がBPWeb2.0の紹介で、なにを議論したいのかまとめていただけると非常に助かるのですが...。

むしろ、どこかのページで全容を記述してから議論に移ったほうが良いようにも感じます。

せっかくの面白そうなアイデアなのに、なんかもったいない気がします。
「ユーザー目線」で見た場合、なんちゃら2.0といわれると、それだけでバズワードかいな、と思ってしまいます^^;

スキルアップ/キャリアアップ(JOB@IT)