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

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

投稿者投稿内容
mark
常連さん
会議室デビュー日: 2007/12/31
投稿数: 35
投稿日時: 2008-01-08 19:12
引用:

七味唐辛子さんの書き込み (2008-01-06 21:53) より:

それにしてもスレ主はなにを語ろうとしているのかさっぱりわからない
風呂敷を広げるのはいいけど 話に新規性がない。 



話に新規性がないのそうかもしれませんね。それは現状の問題点を中心にお話していますから、そういうご指摘をされるということは以前からずっと言われ続けているのでまたかと思われているでしょう。ということで問題点の所在はわかっているがその答えがないということなのではないでしょうか。
ただ、Web2.0を業務アプリケーション(情報系ではないですよ)に適用するというのは新規性があると思うのですが。さてまださっぱりわかりませんでしょうか?
mark
常連さん
会議室デビュー日: 2007/12/31
投稿数: 35
投稿日時: 2008-01-08 19:14
引用:


どのようなシステム構築になるのかよくわかりませんでしたが、
真っ先にhttp://www.atmarkit.co.jp/im/carc/serial/reqdef/01/01.htmlの記事が頭をよぎりました。



この記事は見ています。問題意識や考え方は共有できますが、違う点が2つあります。ひとつは、ここで述べられている要件定義の方法論は、いろいろな人たちが提案している、ある意味オーソドックスなものであるようにみえます。すなわち、課題分析、ゴール分析をして、ToBeモデルを作ってといういわゆるトップダウンアプローチです。これに対して私の提案しているものはボトムアップアプローチです。私は、トップダウンアプローチは、特に日本では、実践的でないと考えています。ただ、現実にはどちらか一方だけではなく両方加味したハイブリッド型アプローチになると思います。
もうひとつは、開発技法がどうなっているのか、あったらその技法にどうもっていくのかがよくわからないのです。実装のイメージがつかめないということです。
これについてもまた議論していきましょう。
mark
常連さん
会議室デビュー日: 2007/12/31
投稿数: 35
投稿日時: 2008-01-08 19:17
引用:

マシュマロさんの書き込み (2008-01-07 15:06) より:

このユーザーがどのレベルの人を指しているのかはわかりませんが、
その要求というのは、他システム連携、運用が可能な上でユーザの真の目的を満たすものなのでしょうか。

この真の要求を正しく定義せずに、ユーザの要求を可能な(体力のつづく!?)限り受け入れているのが現在のシステム業界の問題ではないかと思います。



真の要求というのは難しいですね。真の要求とはいったい何なのでしょうか。

SIerからみるとユーザは勝手なことばかり言ってきて困ると言うし、ユーザ側からは自分たちがITのことをよくわからないと思って、余計な機能を入れたり、高価なソフトを入れるし困ったものだとなる。両方正しくて、両方間違っているのです。

で私はこう思っています。データは別として、プロセスはユーザの要求がどちらかというと正しいと思います。日常の業務を行なっているのはユーザ自身ですから、ユーザはそのプロセスをSIerからとやかく言ってほしくないのです。というか、業務をユーザ以上に知っているSEはいないのです。

話はそれますが業務を知っているSEは必要ありません。ユーザが要求をしたプロセスを素早く作ってあげる作り方の技術があればいいのです。

一方、機能はIT側が入りこんでいくことができます。技術ドリブン的な関わり方は必要だと思います。特に最近は新しい技術がどんどんできてきていますから、IT側からビジネスに寄与する機能を提案してみるのもいいかと思います。

適材適所的な開発体制への転換でシステム業界の課題を解決できるかもしれないという可能性を私は持っています。


mark
常連さん
会議室デビュー日: 2007/12/31
投稿数: 35
投稿日時: 2008-01-08 19:20
引用:

nagiseさんの書き込み (2008-01-08 11:10) より:
私も新規性が見えないなぁ。
単に「大量生産の既製品で事足りる相手に既製品を提供しよう」という
ずいぶん昔から試みられてきたことをやろうとしているだけに思える。




ちょっと「大量生産の既製品で事足りる相手に既製品を提供しよう」というところが理解できないのですが、大量生産の既製品と既製品の違いが? それと既製品というのはパッケージのことでしょうか?

この「BPWeb2.0」は既製品のパッケージではありません。コンテンツマネージメントの仕組みとプロセスエンジンを使って業務アプリケーションを構築していこうというものです。少なくともこの2つは昔からあるものではありませんのでご指摘のところはちょっと違うと思っています。
mark
常連さん
会議室デビュー日: 2007/12/31
投稿数: 35
投稿日時: 2008-01-08 19:21
引用:

nagiseさんの書き込み (2008-01-08 11:10) より:

などと言っているけども、BPWeb2.0とやらがERPに代わるだけで
BPWeb2.0とやらでは全部のシステムを構築できないだろうし
BPWeb2.0を提供するベンダーに任せてしまうリスクもあるのでは?



これは前述したようにどちらか一方で全部やろうと言うわけではありませんし、3層プラットフォームは、ERPの役割、BPWeb2.0の役割を表わしているわけです。

BPWeb2.0を提供するベンダーは存在しません。部分のツールを提供するベンダーはありますが、それを組み合わせて使うことをBPWeb2.0と言います。ですから、私はやっと文字通りのSIerの登場だと言っています。プログラム開発会社ではないシステムインテグレータです。

ですからおっしゃられるベンダーに任せてしまうリスクはないのです。場合によっては、両方ともオープンソースを使うこともできます。
加納正和
ぬし
会議室デビュー日: 2004/01/28
投稿数: 332
お住まい・勤務地: 首都圏
投稿日時: 2008-01-09 00:30
引用:

markさんの書き込み (2008-01-08 18:56) より:
引用:

加納正和さんの書き込み (2008-01-03 23:30) より:

残念ながら、ここでデータが確定したなら、ERPに流れるしかないと思います。




そのデータを確定していくには多くの場合あるプロセスを経て確定していきます。




ERPに「まず」流れることは肯定するのですか。そうなるとBPMSとやらを作る理由が希薄のような気がしますが。

引用:


従って、BPMSが全く不要ということではなく、ERPの中のフロー機能を使うか、BPMSを使うかの差になるように思います。私は、プロセスの可視化という意味でBPMSの使用を薦めているわけです。




そのBPMSで行う、「業務でない」多くのプロセスなどシステム化する必要さえないと思います。

なぜかって?ERPのフロー機能かBPMSを使うかを「真に」決定するためには、まずERPに落としてみないと分からないわけです。もともとの主張が「仕様がころころ変わる」というところから来ているのでは?ERPに落とすまでBPMSを使う必要があるかないか分からないのなら、BPMSをそもそも作る必要はないでしょう。

でもって「ERPで行う業務」がちゃんと「業務」足りえると、とたんに、ERPの拡充に走ることになるでしょう。BPMSを新たに定義する必要性は永遠に発生しません。

「業務の」プロセス可視化ならERPに作ればいい。BPMSにする必要なんかあるわけもない。そのときにはもう「仕様が変わる」とか言う話は無意味なわけです。仕様は決まりきってるわけですから。

ERPに「まず」流れることを肯定するのなら、もはやBPMSを作る理由はかなり薄くなります。確かに業務的にはBPMSを「後で」立ち上げた方がいい場合はありますが、その場合はその時点で金を払えばいい。

わざわざ先に金を払っていつ使うか分かりもしないBPMSを定義する理由が、本当に顧客にあるのですか?

BPMSを定義しないのなら、CMSなんてさらに不要にしか見えませんけど。。。。

ということで、BPMSを「先に」定義する必要があるシステムは、あまりに仕様が決まりえないシステムしかないような気がします。

そ、それは、、つまり業務システムを作る難易度が高いことを示していて、そんなシステム開発はもともと失敗しやすいのでは。。。

加納正和
ぬし
会議室デビュー日: 2004/01/28
投稿数: 332
お住まい・勤務地: 首都圏
投稿日時: 2008-01-09 00:48
引用:

markさんの書き込み (2008-01-08 18:59) より:

また、SIer視点、開発者目線からビジネス視点、ユーザ目線に変えることは本質的な変化だと思っています。




いままでの内容を斜め読みしたところ、私は以下のように解釈しました。

CMS -> 見栄え
BPMS -> ワークフロー
ERP -> 基幹業務

でそれぞれを「わざわざ」分離して実装していこうという開発手法。
に見えます。

でCMSはノーコーディングでいけるから、それで見栄えだけ見せて顧客のOKをいただく。
「試行」はBPMSで行う
ERPはまんま(製品を買う。買ったまま修正しない。もちろんなるべく)

広く言えば構造化手法の構造化割合をCMS領域とBPMS領域とERP領域でなるべく多く
構造化していこうという手法に見えます。

それを分けても、どこまで行っても「構造化手法」の一手法にしか見えません。
「ビジネス視点、ユーザ視点」とは無関係に見えます。

なぜなら「システムドメイン」の分割の仕方を議論しているという意味では
「構造化手法」の域を出ていないからです。結局は「システムドメイン」を見ているに過ぎません。

「ビジネス視点、ユーザ視点」というなら「ビジネス、ユーザドメイン」を見る必要があると、私は思います。

CMSも、BPMSも、(ERPは当然)「システムドメイン」の住人です。
よって「ビジネス、ユーザドメイン」には居ません。

だから、この開発手法で「ビジネス視点、ユーザ視点」といえる理由が不明です。
加納正和
ぬし
会議室デビュー日: 2004/01/28
投稿数: 332
お住まい・勤務地: 首都圏
投稿日時: 2008-01-09 01:14
引用:

markさんの書き込み (2008-01-07 10:29) より:
markです。

データを確定した後のプロセスを想定している場合が多かったように感じます。確定前の作業についてもシステム化の光をあてるべきだと思っています。




えっと、「データを確定した後のプロセス」を決めることを、人は「要求定義」と呼びます。ふつーに「要求定義」をすれば、その「確定前の作業についてもシステム化の光をあてるべき」な行動は「光が当て終わった後」であるはずです。

そうでない場合は、単に「要求定義」が不足だっただけです。
で、それは当然のこととして。

引用:

ところがこの領域のシステムのことでいうとネットの世界ではどんどん行なわれていて、Web2.0で語られる「集合知」や「参加型アーキテクチャ」といった考えから生成されたソフトウエアが企業のコラボレーション業務に適用できるところまで来たのです。



要するに要求定義している瞬間にも、すでに「ビジネスが変化する」時代になってきたので、その対応をする必要がある、という話だと解釈しました。

それは、恐るべきことを顧客に要求していると思います。
いわく。究極的には、「従業員の行動すべてを金に換算しろ」ということです。

ふつー従業員は「業務命令」にて行う業務によって給料を得ていると思います。
で私の言ってた「業務」はシステム化した業務のつもりですが、業務命令にて行う
「業務」も範囲に含みます。

自分の浮かんだ考えにて給料を得るのは、あまり従業員とはいえません。
それはクリエイターと呼ばれます。

「ふつー」は定型な「業務」を行って給料を得るのが当然です。
「従業員の行動すべてを金に換算しよう」と思っている企業は、現状は存在しないと
思います。

でも、Web 2.0系の考えだと、それを目標にする「べき」と言っているように見えます。
それは、、、従業員の無言の抵抗を受けるでしょう。

「いやだ」とは言われませんが、なぜかシステム化が進まない、というどっかであるような状況が加速するだけだと思われます。

しかもいくら金になったか計って、金にならなかったら、システムとして0円だったりして。マイナスだったら、システム屋が払うのかな。これは余談ですが。

引用:


のためのコラボレーション的な業務が多いことに気が付くと思います。「だべり」が大事な意思決定プロセスのような気がします。




んなことをいったら「業務」として「だべり」をする必要があります。
しかも大勢の従業員がですか?

駐車場の誘導員が「だべり」をしていて仕事になるとでも思うのでしょうか。

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