＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
ユーザ目線のシステム作り：SOA（BPM＋Web2.0）
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-01-12 11:14
るぱんです。
ノンコーディングはいいんだけど、 SEだけが使いそうな言葉を全部排除していただきたい。 そうでなければ、エンドユーザーよりの開発手法なんて 何の価値も無いと思うのは僕だけか？ | ||||||||||||||||
|
投稿日時: 2008-01-12 12:18
ユーザ目線のわりには、読者？のターゲットが不明なのでわかりにくい
話が抽象的だとはすでに語っているが、ＢＰＭ、ＣＭＳとか並べられてもなぁ ＲＤＢにデータを登録してシステムが動くといっているのとあまり変わらない | ||||||||||||||||
|
投稿日時: 2008-01-13 10:07
ｍarkです。
いろいろご意見をいただいていますが、これから述べるところはそれらの答えも含んだものですので論を進めていきます。 業務コンポーネントと粒度ということを考えます。 業務を階層的にみていくと呼び方はともかくとして次のようになるのではと考えています。 業務プロセス−業務サービス−アクティビティ−アクションです。 わかりにくいので具体例でいうと、受注から出荷までの業務を想定してみてください。この場合、受注から出荷までが業務プロセスになり、受注が業務サービスです。アクティビティは受注受付でアクションは受注受付メモ作成といったことになります。段階が多いとか少ないとかあるかもしれませんが、このように階層化して業務は考えられます。業務のモデリングでよくやられていることです。 本技法では、業務プロセス−業務サービスの階層とアクティビティ−アクションの階層を分けて考えます。そして後者を業務機能と呼ぶことにして、この粒度でコンポーネント化しようとしているわけです。 後述しますが、前者の業務プロセス、業務サービスは広く業務プロセスという風に規定しています。そして、業務プロセス−業務サービスのところをマクロワークフロー、アクティビティ−アクションのほとんどのところをミクロワークフローと呼んでいます。 | ||||||||||||||||
|
投稿日時: 2008-01-13 18:53
私も、興味を持って読まさせて頂いておりました。
基本的には、markさん及びkonibiさんのご意見には諸手を挙げて賛成です。 ただ、他の方もおっしゃっているように、新規性がないように思います。 まるで、雑誌をそのまま書き写しているのか、または@ITの記事をコピペして いるかのような感覚です。
私は、BPWeb2.0を「Web2.0+CMS+BPMSにERPのエッセンスを加味したもの」と理解して おります。調べてみましたら、CMSとBPMSを合わせたような製品というのは見当たりませんでした。 なぜないかと言うと、BPM製品でもCMSのような要素がありますので、あえてわざわざCMSを 組み合わせるようなことはしていないように思います。 議論の進み方を見ておりますと、ユーザ目線ということばかりが強調されてしまって おり、もうひとつの軸である「Web2.0」がおざなりになってしまっているようです。 本当にWeb2.0を入れて考えるのならば、いいものができあがると思います。 ではWeb2.0とはどんなものかという定義が必要と思いますが、ここは 良いものがありましたので、これを参照にしたいと思います。 (前向きストラテジー: http://maemuki-strategy.com/2007/02/build_a_web_20_startup_in_japanese.html ) BPMに「プロジェクト管理」+「集合知」+「ウィキ」を加えたとします。これなら なんとかできそうですね。(Trac+BPM?) BPMと「地図」+「Ajax」+「SNS」ではどうでしょうか?営業のエリアマーケティング となんかで使えそうです。 BPMと「動画、ビデオ」+「RFID」+「エンターテインメント」+「シェアリング、共有」 はどうでしょうか？ちょっと業務では思いつきませんが、承認を必要とする高度なテレビ会議と いったところでしょうか。 BPMと「出会い系」+「ワイヤレス」+「レコメンド、おすすめ」+「オークション」 では、むしろ業務に支障になるんじゃないかと思うくらいです。 本気でWeb2.0を考えれば、良いものが出来上がるはずです。 がんばってください。応援しています。 | ||||||||||||||||
|
投稿日時: 2008-01-13 19:17
もうひとつの論点である「ユーザ目線」ということで考えてみたいと思います。 10年以上前から、プログラマー不要論というのはあります。将来は、ボタンひとつで システムが自動で構築できるから、プログラマーは不要になるということです。 しかし、現実には不要どころか不足していました。 そこで、10年くらい前に出てきたのがRADでした。ある程度操作の自動化をはかって いるので、簡単にシステムの構築ができるということではやりました。 それこそ、面倒な要件定義や設計すらいらないので、特別なスキルを持った人間で なくても操作できるという触れ込みでした。そして、実際に『簡単に』構築できました。 しかし、むしろ開発の現場やユーザ側では混乱が生じてしまいました。 『簡単』という意味を取り違えていたのです。要件定義や設計を排除してしまった ため、不要なシステムや役にたたないシステムが無計画に多く作られました。 また、自動化してあるシステムというのは、決まったことをするのは簡単に作れますが、 ちょっとでも標準から外れてしまうと凄く難しくなってしまうという特徴がありますので 緻密な要求に応える、本当に業務に必要なシステムにはかえってなかなか作られないという矛盾が生じました。 そして、2〜3年くらい前から、要件定義の重要性が改めて見直されるようになりました。 今の[上流]ブーム(ここでいう上流は上流工程です)はこのような反省から流行りだした ものではないでしょうか？ 今、10年前から言われていることが解決されようとしています。しかもそれは、 皮肉にも「ユーザの人でもシステム構築ができる」ことへの反省からはじまっています。 | ||||||||||||||||
|
投稿日時: 2008-01-13 21:54
私はどちらかというと懐疑派なのかもしれません。
そうでしょうか。それは疑問があります。 Web2.0って要するにプログラマ(or「アクティブ」なユーザ。業務を行う意味の「ユーザ」とは正反対の存在) の作りたいまま作ってみてよかったら使おうかというのが基本的なコンセプトです。 で使っていけばさらによくできると。 どう考えてもWeb2.0系統を使う人々と「業務」の人々と交わるところが全くありません。 性質が正反対です。 システムの本質的なところが「人」に行き着くとすれば、グループの性質が全く 違うなら、ぜんぜん違うシステムになるような気がします。 となれば、開発手法も同じように出来る保証は何もないと思います。 まぁ、私の懐疑的見方の中心の一つです。 | ||||||||||||||||
|
投稿日時: 2008-01-13 22:26
加納、です。
先に言っておきますが、私程度に、いちいち反応する必要はありません。 どうぞ勝手におやりください。
その意味の、ユーザ主導、というのがすでに無理があります。「ビジネス視点、ユーザ目線」(1)という話がありましたが、本質的に(1)は「ユーザ(本来は経営者)」ごとに複数たくさんあります。システムごとにあるのではありません。でもシステムは一つしかありません。たくさんあったりはしないのです。 そもそもユーザは構築したいとは思っていません。自分の業務にあった「分かりやすい」システムが教育つきで、会社に来た日に備わっていればそれでいいのです。構築したいと思う人は存在しえません。だって「業務」をしたいからシステムを作るのですから。
少ないのは当たり前です。誰だって自分のビジネスを単なる1プログラムにしたいと思う「ユーザ」など居るわけもない。(そんなことをしたら自分が不要になる)だから本質的には「コンポーネント」にはならない。本来コンポーネントとは (wikipedia(ソフトウェアコンポーネント)より引用) * 完全に文書化すること * テストをしっかり行うこと * 特に各種入力値を入力したときの動作をしっかり確認すること * 分かり易い（あるいは利用し易い）エラーメッセージを返すこと * 想定していない状況で使われる可能性があることを念頭において開発すること などがあってしかるべきです。(上記は再利用の話ですが) ユーザが上記を考えてコンポーネント化する?なぜ? んなもん考えないなら、それはコンポーネントではなく単なる「一塊」です。箱。四角。 そういうふうに、存在する「業務」を「一塊」と定義するなら、ごくふつーに
「業務箱」の連なりを業務プロセスとして、要件定義の一環ぐらい考えて聞き流す 、、のは問題ですが、ふつーに要件定義した方がましです。 そうすると普通の要件定義より、低レベルな要件定義ですが。 高レベルの要件定義は、基本的に「全部」聞くのが普通です。 コンポーネント化なんて考えない。なるべく広く考える。
しかも「フレームワーク」と「コンポーネント」がごちゃごちゃのようですが。 まぁ素人を煙に巻くのはいいのかもしれませんが、COMコンポーネントとJavaのSpringフレームワークを一緒にするのはお勧めしませんがね。 もちろんそういう要求は良くあるのですが。 #でどっちか妥協すると。 | ||||||||||||||||
|
投稿日時: 2008-01-14 00:09
勉強させてもらっています。
読ませていただいていると、Web2.0 という新しい言葉を使って、 業務系システムも包括されているグループウェアを作りたいという事でしょうか？ 最終的に出来上がるものが、イメージできません。 抽象的な概念が多過ぎます。 | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.