@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
ユーザ目線のシステム作り:SOA(BPM+Web2.0)
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2008-01-06 10:47
Markです。
前回に“従来型のシステム構造や方法論”では限界ということ言いました。それでは、従来型というのは何を言うのかについて考えたいと思います。 まずはシステム構造ということですが、いまSOAという言葉が注目されていますが、この言葉がなぜ登場してきたかにも大いに関係してきます。ただちょっと横道にそれてしまいますが、私はいまいろいろなところでSOAと言っていることに少し違和感があります。 そのひとつにSOAを目的化していることです。例えば、“うちの会社はSOAを構築しました”なんて言うのを聞くことがありますが、全くおかしい話でSOAはあくまで概念、考え方であって、この仕組みがSOAですということはないのです。 しかも、システムサイドもさることながら、ビジネスサイドからの要求でもあるのです。現代のビジネススピードや多様化についていけるためには、柔軟でアダプティブなシステム構造が必要なのである。それに答えられれば、どんな仕組みでもSOAだと私は思います。 さて、従来型のシステム構造というのは、概してアプリケーションごとに閉じられた孤島システムでした。しかも昔はスクラッチで開発した固有のシステムであったわけです。それがERPの登場により、統合化という方向に向かいました。データの統合、アプリケーション間の統合です。 しかしながら、ERPパッケージは統合化と同時に標準化をねらっていましたから、自社業務をパッケージに合わせるというアプローチをとりました。その結果、企業は2つの方向を選択することになりました。ひとつは、パッケージに合わせて非常に窮屈な思いをするか、もうひとつは自らの業務に合わせるために思いっきりアドオンすることでした。こうしてできたシステムは、硬直的で変化対応力に乏しいものになっていました。 そのため最近では、ERP自体も変貌してきて、SOAの概念に基づいた新たなバージョンがひろまってきています。ただ、私から見るとまだシステムの構造がアダプティブでないため、機能追加などは相変わらずアドオンプログラムで対処せざるを得ないのではないかと思っています。また、ERPへ入力するための周辺システムは別に開発してデータ連携するなどインターフェース開発も相変わらず必要になっています。それよりも何よりも非常に高価であることは変化対応力がないと言えます。 またERPを導入できないところは、つぎはぎだらけの開発により、アプリケーション連携もできない、部分最適のシステム構造のままです。 次に開発方法論ですが、オブジェクト指向開発とかDOAとか多くの方法論が提示されていますが、決め手になるものはないような気がします。前回言いました開発技術の2つのジレンマを解消できていないのです。 従来型の開発手法は、ユーザからヒアリングして要件定義をし、機能を定義し、そしてプログラム仕様書を作成し、コーディングというようなプロセスになるかと思いますが、これだとどうしても手戻りが発生したり、追加が増えてしまうのではないでしょうか。 私の経験からいうとユーザって要件定義フェーズで仕様を確定してくれることはまずありえない。これにはいろいろな理由があって、決定権のない担当者だったり、キーパソンは忙しくて対応してくれないとかあると思いますが、何といっても“その気になってくれない”ことではないかと私は考えています。 ではユーザをその気にさせるにはどうしたらよいのでしょう。私は要求を聞いたらユーザの目の前ですぐに動くものを見せることだと思っています。いままでのやり方だとずっと先になってやっとどんなものができているかがわかるわけで、その間にユーザの要件は変化してしまうし、忘れてしまうことだってあるのです。ですから、難しいことかもしれませんが、ユーザに要件を出してもらうのと同時にその実現される姿をその場で見せてあげるというのが望ましいと考えています。 ざっと、現状の問題点を考えてみたが、その他にも企業の情報システム部門や情報子会社の問題、IT業界の構造、人材育成方法等々ありますが、ここでは主にシステム構造と開発方法論について議論しています。 もちろん既存手法もどんどん進化していると思いますが、ユーザ視点を持って(ユーザの要求は、いいものを早く、安く作ってくれですからこれに答えるには)一旦ゼロベースで見直すようなことが必要である気がするのです。 | ||||
|
投稿日時: 2008-01-06 21:10
非常に面白そうな話題ですので拝見させてもらっています。
今後の話題の発展方向にもよるのでしょうが、個人的に思うところを少し。 今回言われているシステム規模というのが、どうも「全社」などの範囲が大きめな話に読みとれるのですが、今回議論したいのはそのようなレベルで構築するシステムの話なのでしょうか? 構築するシステムの規模や種類によっては向き、不向きがあると思うのですよ。
この点については非常に同意です。ユーザー側にとってはもっとも望ましいことだと思いますね。今のところSI側にかかる負担(技術、人員の教育など)を解決できる手法がないのが問題なだけで。 | ||||
|
投稿日時: 2008-01-06 21:53
言語的な問題はありますが、そういったことは10年前ぐらいから言われています。 最近は話題にはあがりませんが、RAD(Rapid Application Development) と呼ばれる手法で、この概念が発表されたころはVBとかDelphiとかが RADツールとか言われてました。 プロトタイピングもこの概念に含まれます。 参考 http://journal.mycom.co.jp/series/stratesys/011/index.html それにしてもスレ主はなにを語ろうとしているのかさっぱりわからない 風呂敷を広げるのはいいけど 話に新規性がない。 | ||||
|
投稿日時: 2008-01-07 10:29
markです。
ご質問いただいていてちゃんと答えていなくて申し訳ありませんが、申し訳ないついでにもう少し書かせてもらいます。Ahfさんや七味唐辛子さんのご指摘のように話が広がりすぎたり、概論的であるのはそのとおりですが、だんだんと絞って行きますのでしばらくお付き合いください。 ではどこを見直したらよいかということになりますが、そのときに「企業にとってのITとは」を考えておいたほうがよさそうですね。これは、加納さんのご指摘の前半部分にあった「業務」とはということに関連してきます。 ユーザから見た情報システムは、当たり前かもしれませんが、まずはそれぞれの会社の経営であったり、事業であったり、そうしたビジネス活動を円滑に行なうためのサポートツールととらえられます。ですから、情報システムを作ることが目的ではなく、その結果として効率化が図れたり、意思決定が早くなったりして、会社の利益に貢献するというのがあるべき姿になります。 ではビジネス活動とはどういうことでしょうか。 その経営の仕組みを考えてみます。メインのプロセスは、経営計画、事業計画、開発計画などの計画作成を行い、それを実行し、実行というのは生産・販売・物流・調達などの行為をさします、その後そうして実行した結果をBS/PLという形で作成し、管理会計でチェックします。そして、またその結果を生かして次のアクションへとつなげていくわけです。いわゆる、PDCAサイクルです。これが、会社の基幹業務システムになります。 そして、その周辺に各種のサポート業務があります。大きく二つあって、プロフェショナルサポートとバリューチェーンサポートです。プロフェッショナルサポートというのは、法務とか税務です。バリューチェーンサポートは、物流管理、品質管理、設備管理などをいいます。そのほかにヒト・モノ・カネ・情報といったリソース管理の業務があります。 そして、それらが有機的につながっていて、そこに携わっている人たちは会社の最終目的である利益を最大化することに向かって、効率とか能率とかは別にしてむだのない「業務」をおこなっているわけです。 さてここで「業務」ということについて考えてみましょう。極端な言い方かもしれませんが 私は上に書きましたように会社という組織の中で行なっている行為はみな「業務」であると思っています。全部が会社の最終目的につながることですから、それは「業務」ということでいいということです。 いやつながらないこともやっていると言われるかもしれないが、会社の経営とかシステムを考える時には、会社にとって不必要であり、知らないわけだから、スコープに入れるものではないのです。 次に、加納さんがご指摘する「試行」ということ考えてみましょう。ここは割りと重要な論点になってきます。言葉の定義の問題もあるかと思いますが、私は「試行」という行為は立派な「業務」であると思ってしまいます。“「業務」とはデータが「がちがち」になってから行なう”ものと言われていますが、その定義は「システム化すべき業務」というようなとらえ方になってはいないでしょうか。従来のシステム化の範囲というのは、データを確定した後のプロセスを想定している場合が多かったように感じます。確定前の作業についてもシステム化の光をあてるべきだと思っています。 例えば、受注―出荷というような業務プロセスをみると、受注が確定してから、生産指示を出したり、在庫を引き当てたりというアクションに進みます。ところが現実にはこの受注を確定するまでに様々なアクションやコミュニケーションがあります。お客さんから問合せがあったり、営業が訪問して案件を持ち帰るとかして、それを在庫があるか確認したり、お客さんの実績を調べたり、評価見積をしたりとか、そういうことをやりながら決定して行きます。 もしこうした部分を「試行」ということであるとなると、決められたとおりの「業務」を行なうマクドナルド型のシステムしか「試行」のない業務プロセスは合わないように思うのと、あるいはデータの登録だけで済んでしまう経営や事業ってあるのだろうかと思うのですが。いかがでしょうか。現実には「試行」しながらものごとを決めていくわけで、そのためのコラボレーション的な業務が多いことに気が付くと思います。「だべり」が大事な意思決定プロセスのような気がします。 さきほど重要な議論といったのは、「BPWeb2.0」は、このデータを確定するまでの「業務」のシステム化がひとつのキーポイントであるからです。 従来型のシステム化の考え方は、メインフレーム時代に遡りますが、ホスト−端末の思想です。どういうことかというと、机の上の電卓をたたいたり、隣のひとと相談したり、電話をしたりしてデータを収集・確定し、その結果を端末にデータを登録していました。そこからがシステムの受け持ちと考えたわけです。 ところが、PCが登場して、自分の机の上に端末が来て、電卓やメールが備わってきたのですが、残念ながら、それがバックヤードのシステムとは必ずしもスムーズにつながったわけではなく、システム化は遅れているのではないでしょうか。 ところがこの領域のシステムのことでいうとネットの世界ではどんどん行なわれていて、Web2.0で語られる「集合知」や「参加型アーキテクチャ」といった考えから生成されたソフトウエアが企業のコラボレーション業務に適用できるところまで来たのです。 | ||||
|
投稿日時: 2008-01-07 15:06
おもしろそうなので斜め読みさせていただきました。
どのようなシステム構築になるのかよくわかりませんでしたが、 真っ先にhttp://www.atmarkit.co.jp/im/carc/serial/reqdef/01/01.htmlの記事が頭をよぎりました。
このユーザーがどのレベルの人を指しているのかはわかりませんが、 その要求というのは、他システム連携、運用が可能な上でユーザの真の目的を満たすものなのでしょうか。 この真の要求を正しく定義せずに、ユーザの要求を可能な(体力のつづく!?)限り受け入れているのが現在のシステム業界の問題ではないかと思います。 | ||||
|
投稿日時: 2008-01-08 10:32
markです。
もう少しお付き合いを。また、マシュマロさんの言われるIT業界の問題も重要なテーマであり後々議論していきたいと思います。 前回は業務の話をしましたが、今回は経営システムに対応した情報システムの話です。前回有機的に構成された経営システムということを言いましたが、情報システムというのはこの経営システムに鏡のように写されたものでなくてはなりません。もちろん全部がIT化されなくてもいいのであって、一部人間が介在しながら全体システムが形成されます。 そういう観点から企業情報システムをみていきましょう。まずERPですが、本来前回示したリソース管理のところに適用されてきましたが、さらにメインプロセスのところにも入ってきています。ただサポート系のところは個別システムになっているところが多いような気がします。 ですから、私はERPで全部のシステムを構築することはできないと思っています。ここで注意しなくてはいけないのは、ERPの定義です。ほとんどの場合、ERPとは「ERPパッケージ」を指しています。ですから、パッケージ化されたもので全てやることの限界があることと、一社のベンダーにまかせてしまうリスクがあることを認識しなくてはいけません。 だとすると、ERPというのをパッケージではなく基幹業務システムという定義の方がわかりやすいですね。ただ、基幹業務のスコープをどこに置くか、別の言い方をするとERPにどこまでの役割をもたせるかは検討する必要があります。これは後々に議論していきます。 ここで会社の業務というのはどういう要素で成り立っているのかを考えていきます。抽象化した表現でいうと、「機能」と「プロセス」と「データ」から成り立っていると私は考えています。「機能」というのは、「業務処理」「情報処理」あるいは最近では「業務サービス」という言い方もあるかもしれません。 こうした処理の結果を業務プロセスという形で順次つぎのステップに送られていきます。「業務フロー」ということもあります。 「データ」というのは、こうした業務処理に際しては参照されたり、加工されたりするとともに、「プロセス」で登録データの最終確定を行い、データベースの更新を行なうわけです。 この3つの要素を独立分離して配置し、それぞれの要素間の連携を行なうというのが最も機能的な構造であると考えています。これを私はシステムの構造化と呼んでいますが、SOAの考え方でもあると思っています。 この連携というのをもう少し噛み砕いてみると、構造的にはハブ&スポーク型疎結合になります。このハブに何を持ってくるかですが、機能のハブがBPMSで、データのハブがEAIとなり、アプリケーションのハブがデータベースということがいえます。最近はESBとか言われますがそこまではいらないのではないかというのが私の意見です。 この構造が、特にプロセスのところがERPだとよく見えないと思っています。ですからここを一旦解体して再構成したほうがいいと思うのですが、なかなかそうはいかないですね。可視化したいが可視化できていないのでそれができないというジレンマですね。 ただ、SOAの考え方では、段階的かつ部分的導入が可能であることが特徴のひとつなのだから徐々に構造改革をしたらよいと思っています。 | ||||
|
投稿日時: 2008-01-08 11:10
私も新規性が見えないなぁ。
単に「大量生産の既製品で事足りる相手に既製品を提供しよう」という ずいぶん昔から試みられてきたことをやろうとしているだけに思える。
などと言っているけども、BPWeb2.0とやらがERPに代わるだけで BPWeb2.0とやらでは全部のシステムを構築できないだろうし BPWeb2.0を提供するベンダーに任せてしまうリスクもあるのでは? | ||||
|
投稿日時: 2008-01-08 18:47
markです。
少し前置きが長くなったようなので、ここで一旦これまで述べてきたことを整理してみます。 まず冒頭で「BPWeb2.0」というのはどんなものかをざっと説明しました。 3層構造のアプリケーションプラットフォームとその上で書類のライフというコンポーネントをBPMでプロセスにして業務アプリケーションを構築するという開発技法を提示しました。 次にこうしたフレームワークを考えた背景として現状の企業情報システムが抱える問題点を挙げてみました。それらの問題点をカテゴリー別に分類してみるとつぎのようになります。 1.構造的な問題 1)システムの構造に関するもの 密結合の硬直的なシステムの変化対応力の弱さや可視化できていないこと 2)ユーザとベンダーの関係 ユーザの要求が反映されにくい、あるいは使わないシステムを作ってしまう 3)IT業界の問題 人月ビジネスの限界 2.開発技術の問題 1)仕様が決まらない、手戻りの発生などユーザに振りまわされる 2)例外やあいまいな部分のシステム化の難しさ こうした問題点をどう解決していくのかがこれからの企業情報システムの課題になると思います。そして、この課題を解決する方向性として概略次のようなことを提案しました。 1.システム作りをSIer視点、開発者目線からビジネス視点、ユーザ目線に変えましょう 2.そのためには、開発はユーザ自身ができる、あるいはユーザ主導で行うようにしたい。それを可能にするには原則としてコーディングしないシステム構築技法が望まれること。そして、ユーザ要件が出たらすぐに動くものが示せることではないか 3.そうしたことができるシステム構造は、「機能」、「プロセス」、「データ」を独立・分離して配置し、それぞれを疎結合で結び、変更が容易な構造にすることではないだろうか 簡単に言うとこんなことになります。これを踏まえて皆さんのご質問にお答えしようと思います。 Kumaさんについてはkonibiさんが答えてくれていますので、そのほかの方々にお答えいたします。 |