＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
ユーザ目線のシステム作り：SOA（BPM＋Web2.0）
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-01-21 23:59
七味唐辛子さん返答ありがとうございます。
こんなツールがあったんですね。 無知ですいませんでした。 教えて頂いた資料を読ましてして頂きました。 このようなツールをユーザーに提供して作製してもらうという解釈という事なんでしょうか？ 私の担当している会社では１００％やってくれませんね。 やはり、ユーザーにシステム開発を行ってもらうのは夢の話のようですね。 | ||||||||
|
投稿日時: 2008-01-22 01:00
ユーザに直接システム作成させるという考えは、昔よりありました。ただしその方法が
吉と出るか凶と出るかは不透明です。少なくとも、過去の事例ですと大成功というのは 見たことがありません。経験により業務を覚えたとしても、その業務の本質を分析できる ようにならなければ
Web2.0と言われるサービスや技術は、多岐にわたって広がっており、すぐに出てくるような ものではありません。私自身も、業務システムやBPMにWeb2.0を採用するとどうなるか というのは(良い意味で)不明瞭です。(それとも、Web2.0そのものについて尋ねられて いらっしゃいますでしょうか？) 拙い知能で思いついたものを挙げますと、まずBPMそのものの構築としまして ・ビジネスプロセスのモデリング自体を、デザインツールを使わずWebだけで作成する コンパイルやデプロイなどの作業を要せず、リアルタイムでエンジンに反映される 実行時におきましては ・文書入力フォームもWeb上で自動生成され、編集も可能 ・作成された文書に対して自由なタグ付け 役職や地位を問わない ・材料にはRFIDが付けられ、入出庫や組み立ての具合がリアルタイムにフロー図に表示される ・顧客管理、仕入先管理、生産地など住所を項目にもつシステムとGoogleEarthのマッシュアップ ・製造ラインにWebライブカメラの設置と録画。問題が発生したときはこの動画を再生し対策に役立てる ・商品データベースを他サイトから検索できるようWebAPIの提供 単なる思い付きですので、外していたり実現不能なものもあるかと思います。 上記においては、もっと洗練される必要があると思います。 (それでも、CMSよりは自由度が高いと思います) | ||||||||
|
投稿日時: 2008-01-22 12:53
ｍarkです。
皆さんにご意見をいただいていますので、それについてお答えしておきます。確かに「会議室」という場で半ば一方的に持論を展開しているところがあり、おかしいと思われている方が多いかと思います。 ですから、こういう場ではないところのほうがよかったかもしれませんが、議論の進め方としては、こんな考え方や技法を作ったのだがそれに対して皆さんがどう思うかご意見を聞いてみたいということでした。そうであれば、最初に全体像をみせておかないといけないわけなので非常にわかりづらくなって申し訳ありませんでした。やっとだいたいの姿がみえたのではないかと思っているのですがいかがでしょうか。 ただ、ご指摘のように文字だけなのでいっそう理解しにくかったのではないかと思い反省しています。それでもやはりこういう場だと限界があるような気がします。本当は実際に動くものを見ていただくのがよいのですが。 さて、議論という意味では私はこんなことを議論したらどうかと思っています。 ここで提示したものは、現状の問題意識から出発しています。それは、日本の業務システムの作り方が今のままではいけないという危機感です。おそらく、皆さんも現状をなんとかしたい、変えていきたいと思っている方が大半だと思っています。今のままで十分だと思っている人は少ないのでなないでしょう。 ソフトウエアは欧米から買ってきて、製造はインド、中国にシフトしていき、相変わらずの人月ビジネス、３Ｋとか４Ｋとか言われる職場、学生に人気のない業界等々、こうした状況を打破するため、日本発のモノつくりの方法、技術を生みだし、あるいは魅力ある業界、働きがいのある職業にすることを自らで考え出すことが必要ではないのでしょうか。それをどうやってやっていくかをみんなで知恵を出し合って大いに議論すべきだと思います。 自虐的にならずに、お互いに足の引っ張り合いをせずに、スーツだギークだといわずに、世界に目を向け、みんなで力を合わせてユニークなものを創造することが大事なのです。 私がこの会議室で提示したものは、そのためのひとつの問題提起であり、それを面白いと思うか、くだらないと思うか、できっこないと思うかなど人それぞれだと思いますが、皆さんが自分だったらこうするといった方向に考えてもらえるきっかけになることを期待しているのです。 ここで、本技法だとどんな開発体制、開発のやりかたになるのかということを少し話しておきます。 今、ソフトウエア自体はオープンソースの出現によりどんどん無償化の方向に向かっています。従って、ここは欧米のものでも持ってきてかまわないと思うのですが、設計・製造のところは、内製すべきであると思っていて、そこの生産性を上げられるかが重要なポイントとなります。そのためにはアプリケーション開発の段階ではコードを書かないでユーザでさえ作れてしまうものを用意することだと考えたのです。 こうした考えでのプロジェクトはこんな体制になります。必要な人材としてはつぎのようになります。 ・ プロジェクトマネージャ（ＰＭ） ・ ビジネスプロセスデザイナー（ＢＰＤ） ・ ＩＴアーキテクト（ＩＴＡ） ・ スーパークリエーター（ＳＰＧ） ・ データアドミニストレーター（ＤＡ） 簡単にいうと、ＤＡにより整備されたデータベースのもと、ＳＰＧが作った部品やインターフェース等とフレームワークを使い、ＢＰＤが作った業務プロセス・機能をＩＴＡが実装し、ＰＭがプロジェクト全体を管理するというイメージになります。これだと多くの人数は要りません、少数精鋭でやるわけです。しかも、ユーザの前でプロトタイプを見ながら一緒になって作っていきます。 要するに難しいことは優秀なプログラマーにさくっと書いてもらって、部品とかフレームワークに隠蔽し、ビジネスの構築に注力するということです。 もしこういうことができたら、今のSIとかはどうなるのでしょうか。業界構造も変わっていくような気がします。 お前はまた大風呂敷かと突っ込まれるかもしれませんが、私は挑戦しようと思っています。 こんな年寄りが一生懸命考えているのですから、若いひとたちも柔軟な頭で想像力を豊かにして斬新なアイディアをどんどん出してくれることを期待しています。 | ||||||||
|
投稿日時: 2008-01-22 12:57
markです。
ひらさんのWeb2.0に関するご意見ありがとうございます。参考になります。 ただ若干CMSについて私と認識が違うように思います。CMSはフレームワークですからCMSで何でもやろうというわけではなく、基本的にはコンテンツ管理をします。コンテンツというのは、フォルダー、ページ（ドキュメント）、画像、イベント、ファイル、リンクといったものです。 ご提示のようなものは、CMSの中でやれるものもありますし（まさにページ上で「文書入力フォームもWeb上で自動生成され、編集も可能」をやろうとしているのです）、そのほかは、CMSのコンテンツとの連携技術あるいは機能になっています。従って、CMSだとできないからWeb2.0ではないということではなく、今の技法に取り入れられるし、早晩組み入れられるものと考えていますので、必ずしもCMSと並べて比較するものではないように思います。 その前のBPMの構築のところはどうもBPMSの機能のことであって、Web2.0とは異質のよう気がしますがいかがでしょうか。 | ||||||||
|
投稿日時: 2008-01-22 13:39
こんにちは。三度凝縮を試みます。
議論の進め方としては、こんな考え方や技法を作ったのだがそれに対して皆さんがどう思うかご意見を聞いてみたいということでした。 最初に全体像をみせておかないといけないわけなのですが、 「会議室」という場で半ば一方的に持論を展開しているところがあり、 非常にわかりづらくなって申し訳ありませんでした。 やはりこういう場だと限界があるような気がします。本当は実際に動くものを見ていただくのがよいのですが。 やっとだいたいの姿がみえたのではないかと思っているのですがいかがでしょうか。 私はこんなことを議論したらどうかと思っています。 現状の問題意識から出発しています。 日本の業務システムの作り方が今のままではいけないという危機感です。 日本発のモノつくりの方法、技術を生みだし、働きがいのある職業にすることを自らで考え出すこと。 それをどう実現するかを大いに議論すべきだと思います。 私がこの会議室で提示したものは、そのためのひとつの問題提起であり、 それを面白いと思うか、くだらないと思うか、できっこないと思うかなど人それぞれだと思いますが、 皆さんが自分だったらこうするといった方向に考えてもらえるきっかけになることを期待しているのです。 ここで、本技法だとどんな開発体制、開発のやりかたになるのかということを少し話しておきます。 内製すべきと考える部分は、設計・製造であり、この部分の生産性を上げること重要なポイントとなります。 生産性を上げるための方針として、次のことを考えました。 ・アプリケーション開発の段階ではコードを書かないでユーザでさえ作れてしまうものを用意すること こうした考えでのプロジェクトはこんな体制になります。必要な人材としてはつぎのようになります。 ・ プロジェクトマネージャ（ＰＭ） ・ ビジネスプロセスデザイナー（ＢＰＤ） ・ ＩＴアーキテクト（ＩＴＡ） ・ スーパークリエーター（ＳＰＧ） ・ データアドミニストレーター（ＤＡ） 簡単にいうと、 ＤＡにより整備されたデータベース ＳＰＧが作った部品やインターフェース等とフレームワークを利用する ＢＰＤが作った業務プロセス・機能をＩＴＡが実装する ＰＭがプロジェクト全体を管理する というイメージになります。 これだと多くの人数は要りません、少数精鋭でやるわけです。 しかも、ユーザの前でプロトタイプを見ながら一緒になって作っていきます。 要するに難しいことは優秀なプログラマーにさくっと書いてもらって、部品とかフレームワークに隠蔽し、ビジネスの構築に注力するということです。 --- 最後に。
いつまで経っても話の要点がよくわかりません。 私なりに消化しようと思い、身勝手な要約を試みましたが理解には至りませんでした。撤退します。 #なぜ勝手に要約されたりするのか。それを考えるに至ることを切に願います。せっかくの説明が…もったいない。 [ メッセージ編集済み 編集者: 未記入X 編集日時 2008-01-22 13:42 ] | ||||||||
|
投稿日時: 2008-01-22 14:40
つまり、今の大手SIerの思想と大差ないと思います。 とくに『要するに難しいことは優秀なプログラマーにさくっと書いてもらって、部品とかフレームワークに隠蔽し』の部分がどうにも。 部品・フレームワークがあるからすぐ出来上がるという言葉で製造を軽視して要員・コストを乗せず短期間で線をひいた結果、現場が火を噴き、ユーザに跳ね返っているというプロジェクトをいくつもみてきました。 ここで質問なのですが、 ・この手法が効果を発揮するユーザ・システム規模 ・請求金額の算出方法 ・ユーザとシステム屋の責任範囲 ・ユーザのシステムを構築するプロジェクトを推進するする上で考えられるリスク はどのようにお考えでしょうか。 | ||||||||
|
投稿日時: 2008-01-23 00:06
勉強させてもらっています。
最終的に、「今」と変わらないと思うのですが。 さらに、「ある程度出来上がっている」というのであれば、以前にお聞きした、Notes 等のグループウェアとどう違ってくるのでしょうか？ 当初書かれていた、「ユーザが作る」だと、運用フェーズ以降の不具合等はどうするのでしょうか？ また、「必要な人材」はそれだけで足りるのでしょうか？ | ||||||||
|
投稿日時: 2008-01-23 00:33
意味がまるで存在しない持論は終わったのでしょうか。 「機能とプロセス」とやら(なにせ定義されていないので「やら」としかいい得ない) に分ける理由は無意味な理由だけでした。 また、上記には「ユーザ目線」が何もないようですが。ユーザが動作を見て分かる? でも上記の手順?目標?はユーザが「メリット」を理解できませんけど。 なぜ理解できないって「コンポーネント」だの「ミクロワークフロー」「マクロワークフロー」。ユーザ目線では無駄な単語です。 カタカナだからではありません。これらは「システムドメイン」の考え方だからです。 「ミクロ」とは「何と比べて」ミクロなのか考慮せずに使用しています。 簡単に言えば「機能とプロセス」をあっさり分けられるかのように書いてありますが 現実のシステムドメインでは、「機能とプロセス」を分けることは困難です。 なにが「ミクロ」かも、なにが「マクロ」となるかも、現実のシステムでは基準がばらばらです。 それは当然で「経営ドメイン」では、最大予算のものが「マクロ」になります。 例えばERPを買えるようなところは「マクロ」はERP。でも、んなことは出来ないところは 「マクロ」がまさにexcelのマクロ(苦笑)だったりするわけです。 ということで普通は。「機能とプロセス」は、分けないで「機能とプロセス」 全部入ってる「パッケージ」(ERPのような)を買ってくるのが一般的です。 普通は出来ないけど、あえてやるのなら、それなりの理由が必要でしょう。 が、元記事の人は何の理由も提示しない。 だから、考えるだけ無駄です。 ま、考慮の失敗事例としては参考になります。Web2.0を業務に適用しようとして このように考えると、中身がなくなるなぁ、という意味の。 (1)「業務」を外して開発手順を考えても単なる無駄。話が抽象的になりすぎ、そもそも開発手順にならない。 (2)BPMSを使う理由が何もない。システムの粒度が決まって、ある程度の「業務」が分かってからなら別だが。 (3)ユーザ主導で作るシステムは、どう考えても「ユーザ目線」だと無理すぎる。 やはりこう考えると、分割して、ここだけCMSとか、ここだけBPMSとかは無理なのかな。。。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.