＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
ユーザ目線のシステム作り：SOA（BPM＋Web2.0）
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-01-09 19:05
markです。
説明が十分でないところもあってか、議論がかみ合わないところが少しあるので、もう一度ここで提案している「BPWeb2.0」について補足したいと思います。 まず、重要な論点としてビジネス視点、ユーザ目線に変えていくんだというところで、じゃあ一体ビジネス視点、ユーザ目線ってどういうことなのかということがあります。 根本的な理解として、システムはビジネスすなわち経営や事業のためにあるわけです。ですから、ビジネスありきでそれを写像する形でシステムが存在します。 従って、理想的にはユーザが自分でシステムを作ることです。それが一番ユーザ自身の要求を実現できる手段になります。しかし、それは全部ユーザだけでやるのは難しいのでシステム部門やSIerが支援するというのが現実の姿でしょう。 ですから私が提示している手法は、できるだけこの理想形に近づけるためのものです。現に世の中の動きもそうなってきています。昨日のITProの記事（ここは＠ITなのにすいません）にもそうした傾向が書かれています。 http://itpro.nikkeibp.co.jp/article/OPINION/20071219/289800/ また、最初はERPだとかBPMSといったソフトウエアプロダクトは意識しないというアプローチです。「業務機能」と「業務プロセス」と「企業活動のためのデータ」から考えるということです。これを独立で考えることが肝です。独立という意味は、「実装独立」ということと「疎結合」としてみるということです。 業務モデルだとかビジネスモデリングでは、だいたいだれでもプロセスと機能の階層化とマトリックス化をすると思いますが、そういう構造ですよね。 そのあと、機能部分をどうやって実現するのか、プロセスをどう描いていくのかになるわけです。 そしてそのためのツールを選択していきます。このとき、注意しなくていけないのは、私の手法は道具を選択しているということであって業務アプリケーションパッケージを選択しているのではないのです。だから、BPMといわずBPMSという言い方にしているわけです。 ということで、BPMSとERPを並べて比較するのはおかしくて、正確には先に言ったとおりBPMSとERPの中のワークフロー機能との比較をしなくていけません。なぜなら、BPMSはあくまで道具ですがERPは業務を表現しています。「BPWeb2.0」は、BPMSとCMSという道具を使って業務アプリケーションを構築する手法です。 ですから、BPMSは要るか要らないかの議論ではなく、業務プロセスを表現するひとつの道具であるから、単にそれを選択しているだけなのです。従って議論の焦点はどういうケースでERPのワークフローを使うのがいいのか、それともBPMSを使った方がいいのか、はたまたプログラムで書いたほうがいいのかといったことになるのではないでしょうか。 それが、元々めざしているユーザ自身でできるものなのかといったことや開発生産性や品質、コストなどの評価軸で選べばいいのです。 繰り返しますが、「BPWeb2.0」というのは、ユーザが本当に必要とするシステムを、CMSという道具を使って業務機能コンポーネントを作り、それをBPMSという道具を使って業務プロセスにする手法でユーザ自身が構築できるものです。 ですから、かなり抽象度の高いレベルの話なので、構造化手法やOOやOAなんかとは次元が違っています。 また大風呂敷といわれるかもしれませんが、このように変えていかないと、日本のIT業界は、今のような欧米からソフトウエアを買ってきて、インド、中国で製造するという空洞化から脱却できないのではないでしょうか。 そのためにどうしたらよいかを日夜頭をひねった結果がこの手法です。それを皆さんに評価してもらいたいのです。あるいは、代替案を示していただくとありがたいと思っています。 次回からもう少し具体的な手法の内容について議論していきます。そうするとまた違った理解になるかもしれませんのでよろしくお願いします。 | ||||||||
|
投稿日時: 2008-01-10 02:05
簡潔であり読みやすい文章希望。
| ||||||||
|
投稿日時: 2008-01-10 02:43
http://kamawada.com/~masanori/blog/2007/12/it_13.html
結局ここに書いてる目的は、セミナーの集客のためなんでしょ。 [ メッセージ編集済み 編集者: dodo 編集日時 2008-01-10 02:50 ] | ||||||||
|
投稿日時: 2008-01-10 12:11
ここらへんが一番言いたいことなのかな、と思うわけですが、 まっとうな開発者ならユーザの要件を「言われたままに」開発などしません。 ビジネスありきでその写像としてのシステムを提案するわけです。 そういう意味で、「ビジネス視点、ユーザ目線」ってのはなんら新規制はなく 開発者としての心得として当たり前の事項となります。 「理想的にはユーザが自分でシステムを作ること」でしょうが、 システムを作るというのは高度で専門的な仕事です。 ビジネスだけへの理解ではシステムは作れない。 だから、ビジネスの写像としてのシステムを作るために大量の専門家が 従事する必要があるわけです。 ですから、「システム」ではなくITをよく知らない人間に対して 便利なパーツを与えて「システム」よりは数段下ではあるけども OA(オフィスオートメーション)させましょう、というアプローチにしか ならないのではないかと思うわけです。 「大量生産の既製品で事足りる相手に既製品を提供しよう」という 表現はまさにこのことを意味しています。 オーダーメードのシステムは非常に高価です。 安い大量生産の既製品で事足りるならそれでいいのではないでしょうか。 # なお、既製品とはパッケージ販売の有無ではなく、複数の相手に提供して # 開発費を回収するスタイルを指して言っています。汎用品を売る方式。 「ユーザが自分でシステムを作ること」が可能なケースというのは 複雑ではない、新規制のないビジネスに限られると思っています。 そして、そういうユーザというのは既製品で十分だと思っています。 だからこそユーザで作れるとも言えるでしょう。 そして、「ユーザが自分でシステムを作ること」を目指したプロダクトも 過去に多数あったように思います。 いまなおシステム開発がなくならないのは、「ユーザが自分でシステムを作」れる ほどにはシステムってのは簡単じゃないからこそではないでしょうか。 | ||||||||
|
投稿日時: 2008-01-11 10:04
そうですね、nagiseさんのご意見は重要なイシューです。すなわち、業務システムを作る場合の使い手側と作り手側の役割をどうするか、システム側がどこまで作るのか、使い手側は何をするのかあるいはしないのかということだろうと思います。
それでこれから、こうした論点も含めてテーマを絞りながら具体的な内容を提示して議論を展開したいと思います。できるだけ簡潔にわかりやすいように努力していきます。 その議論を進めるにあたって、テーマというか目次を示しておきますので、こういうことも議論したらとかありましたらご指摘ください。 「BPWeb2.0」のフレームワークは次の４つのエリアからなっています。 １）開発技法 ２）アプリケーションプラットフォーム ３）コンテンツ＆業務プロセステンプレートライブラリー ４）開発体制 そのなかで、今から議論するのは１）の開発技法についてです。 １．開発コンセプト ２．業務機能のコンポーネント化と粒度 ３．業務コンポーネントの種類と適用法 ４．ミクロワークフローとしての書類のライフ ５．プロセスコントロールということ ６．開発手順 １）業務プロセス設計 ２）BPMS設定 ３）CMS設定 ４）BPMS-CMS連携 ７．まとめ とりあえずこんなところですが、いかがでしょうか。 | ||||||||
|
投稿日時: 2008-01-11 10:34
るぱんです。
結論的に申し上げるのであれば、結果を急ぎすぎている感じに受け取っています。 論点の絞込みができていない＆汎用的であるべきとのスタンスを論拠に、 ERP,BPMS,CMSは概念がぶれる所なので、 排除すべきと思います。 また、ミクロワークフローはいいのですが、 マクロを語れないミクロは論外なので考慮いただきたいです。 （業務プロセステンプレートライブラリがそれにあたると思いますが。） マクロを語ろうとして、ミクロの積み上げアプローチを採用しているように思います。 正確性重視であれば、重要ですが、 期間が短い中で採用するのであれば、 ミドルアップミドルダウンしかないと思います。 （トップダウンでは総論賛成各論反対で議論が空回りすると思います。） システムに依存させないと言う意味で 下記ではいかがでしょうか？
誰が定義したのかが不明ですが・・・。
って、こう書いちゃうと、開発関係なく、 自社の業務を誰がどのように取りまとめるか・・・になるので、 開発向きじゃないなぁ・・・と思います。 業務コンサルの内容なんじゃないかな？ | ||||||||
|
投稿日時: 2008-01-11 19:50
仕事がはやく終わったので覗いてみました。 とりあえず ・開発手法とは何を指しているのか？ を明確にするべきではないでしょうか 以前にも書きましたが、私の認識では ２）アプリケーションプラットフォーム ３）コンテンツ＆業務プロセステンプレートライブラリー ４）開発体制 のようなものは開発手法には含まれません。 かろうじて以下の内容です。 １．開発コンセプト ２．業務機能のコンポーネント化と粒度 ３．業務コンポーネントの種類と適用法 ５．プロセスコントロールということ 議論を望むのであれば同じ土俵にあがらなくては成り立ちません。 そうでなければ単なる自己主張やアナウンスでしかありません。 (もっとも私以外の方の認識はあっているかも・・その際はスルーしておいてください) | ||||||||
|
投稿日時: 2008-01-12 10:53
さて、開発技法について論を進めていきます。Kumaさんご指摘の開発手法の定義は曖昧なところがありますが、私はあまりこだわりません。言葉として、「開発方法論」といったり「開発手法」であったり。今ここでは「開発技法」とか言ったりしているわけですが、要は、業務アプリケーションを構築するにはどんなやり方でやるのかということで、そこにはコンセプト、ツール、手順といったものから構成され、実装までいくものであるというぐらいでいいんじゃないかと思っています。そんな感じでやっていきます。
まずは、開発技法の最初は本技法のコンセプトです。 技法のようなものを考える場合、これだけは“ゆずれないこと”というのがあると思います。その技法の特徴あるいはアピール点といってもいいかもしれません。それはつぎの３つになります。 １）ユーザ主導（できればユーザ自身で“構築”できること） ２）とにかくシンプルでわかりやすいこと ３）ノンコーディングであること この“ゆずれないこと”を保持するために具体的にどうするかというと １）業務機能をコンポーネント化する ２）業務コンポーネントの連なりとして業務プロセスを表現する ３）フレームワークを活用し、難しいコーディングはその中に隠蔽する 若干の補足説明をしますと、これまでもコンポーネントという概念を開発に持ち込むことはやられていて、コンポーネントベース開発といった方法も提示されています。しかしながら、コンポーネントというとそれらは概して、システム機能コンポーネント（認証、カレンダー管理、メール送信、検索、ログ管理などのことをいっています）を指しているように感じています。しかも、それは開発生産性をあげる、あるいはプログラムの再利用性という観点のものであるように思います。 業務コンポーネント、ビジネスコンポーネントというのはまだ少ないように思います。本法はこの業務機能をコンポーネント化することに重きを置いています。 システム機能コンポーネントのほうは、BPMSやCMSのフレームワークにある、もしなければそこに埋め込むという風に考えています。ただ最近のフレームワークは非常にいいものが多く、あらかたのことは備わっているようです。 また、誤解されてしまうといけないのでここで言っておきますが。ノンコーディングというと全くコードを書かないでやるのかと思われるかもしれませんが、コードを書く場合もあります。コードを書かないというのは、特定の業務アプリケーションを開発するときに要求に応じてその時々にコードで書くことはしないという意味です。予めフレームワークとか部品のようなものとして用意しておくということです。そのなかでコードを書く場合は、スーパープログラマーにさくっとコードを書いてもらいます。 ですから、ユーザは道具と部品が与えられ、それらを組み立てるというイメージになります。そうすれば、ユーザ主導での開発が可能になるのではないでしょうか。というか、ユーザ自身でできるようにという目標を掲げるなら、このアプローチしかないと思うのですがいかがでしょうか。できるかできないかは後の議論として、攻め方としてどうなのかということです。 [ メッセージ編集済み 編集者: mark 編集日時 2008-01-12 10:57 ] | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.