- - PR -
「特集 InfoPathの衝撃」を読んで
1
| 投稿者 | 投稿内容 |
|---|---|
|
投稿日時: 2003-03-26 16:14
特集
InfoPathの衝撃 -マイクロソフトの新しい戦略Officeスイート「InfoPath」によって、XML技術は新時代を迎える - の記事に関してですが、大変興味深く読ませて頂きました。 確かに、このツールが登場する事により、XMLスキーマ（XSD文書）に関するスキルを持つ人が増え（裾野が広がり）利用が進むものと思います。 ただ、単純にこのソフトをビジネス・ツールとして捉えると以下のような疑問が浮かびました。 １．XMLスキーマ（XSD文書）やRDBMS、Webサービスからフォームを作成する事ができるが、 逆に、まずフォームを作成して、そのフォームを元にXMLスキーマ（XSD文書）を作成する事は できないのか？ （XMLネイティブではないですが、Lotus Notesはこのイメージを実現しているように思います。） ２．上記ができないのであれば、このツールを使用する際に求められるスキルは MS-Accessを使用するのと同程度のものが求められないだろうか？ つまり、まずスキーマを設計する能力が求められるので、エンドユーザにとって 「衝撃的なほど簡単に」フォームを作成できるというのには少し無理がないだろうか？ （システム管理者／開発者がスキーマを用意するのであれば、フォームまで用意させられて しまう事の方が多い気がします。） ３．InfoPathで作成したフォームはInfoPathでしか使用できないのか？ 作成したフォームを Webベースで使用（Deploy）できないのであれば、とても プロプライエタリなソリューションであると言えないか？ まだ製品として世に出ていないのに期待だけが膨らみすぎているのかもしれませんが これらが実現できていないとなると、とても残念な気がします。 [ メッセージ編集済み 編集者: じょび 編集日時 2003-03-26 16:16 ] |
|
投稿日時: 2003-03-27 07:51
お読みいただきありがとうございます。 製品がベータ版なので、変更される可能性はありますが、私の知る限りの現状をお知らせします。
>逆に、まずフォームを作成して、そのフォームを元にXMLスキーマ（XSD文書）を作成する事はできないのか？ できます。VBやAccessでフォームを作成するのと同じような感覚です。 >このツールを使用する際に求められるスキルはMS-Accessを使用するのと同程度のものが求められないだろうか？ Office2003は、スキーマの設計者と利用者とを分けて考えていると思います。スキーマは定形フォームを表現するものなので、そのデータを利用する人々で、共通のものを作成し、それを入力するときにいろいろな方式を選べるということです。 フォームごとにスキーマを作るという発想は、おそらくOffice2003とは相容れません。1つのスキーマに対して、さまざまな入力と表示方法を提供し、しかもどこからでも共通のデータが利用できるというのが、Office2003の想定される使い方でしょう。たぶん。 >InfoPathで作成したフォームはInfoPathでしか使用できないのか？ >作成したフォームを Webベースで使用（Deploy）できないのであれば、とてもプロプライエタリなソリューションであると言えないか？ Webにデプロイというメニュー項目があるのですが、想像されるようなものではありません。SharePointサービスで利用するためのものなので。私の知る限り、InfoPathのフォームの機能はInfoPathでしか使用できません。確かにxsnファイルからxslファイルを取り出して、これを利用してブラウザにフォームを表示することはできるのですが、カレンダーのような機能は使えませんし。 InfoPathはOfficeの一員です。OfficeはMicrosoftのリッチクライアントソリューションの中心に位置するスイート製品です。従って、Officeから作られたものを、Webのようなシンクライアントソリューションで利用できるようにすることはちょっと考えられません。Officeチームの存在意義に逆行するからです。 InfoPathがXFormsベースのテンプレートを生成しないことを疑問に思う向きもあるようですが、Office製品であることを考えれば、フォーム自体を他のツールからも利用できるようにすることは戦略的に無意味です。InfoPathはフォームから出てきたデータの再利用を重視しているわけで、フォームの再利用は考えていないし、そのようなことは戦略的に正しくないと考えます。 もっとも私はMicrosoftの人間ではありませんので、彼らの戦略の変更しだいではいくらでも変更はありうるでしょうけど。 |
|
投稿日時: 2003-03-27 10:32
ご返答ありがとうございます。
>>逆に、まずフォームを作成して、そのフォームを元にXMLスキーマ（XSD文書）を作成する事はできないのか？ > >できます。VBやAccessでフォームを作成するのと同じような感覚です。 そうすると、InfoPathはスキーマ設計ツールとしても（ある程度）使用できるという事ですね。 >Office2003は、スキーマの設計者と利用者とを分けて考えていると思います。スキーマは定形フォームを表現するものなので、そのデータを利用する人々で、共通のものを作成し、それを入力するときにいろいろな方式を選べるということです。 そもそも１つのスキーマに対して、それほど多くの種類のフォームが必要なのか？という疑問があります。（単に私の理解不足のような気がしますが．．） 例えば、携帯電話からアクセスする為のフォーム（が可能であるかは別にして）のように数種類が必要になるケースは想像できますが、同じスキーマのデータを入力するために各人が必要とするフォームがそれぞれそんなに異なるものなのかな？という気がします。 もっとも、InfoPathにおける「フォーム」が、Lotus Notesで言うところの複数文書を一覧形式で表示するための「ビュー」の役割も内包しているのであれば、項目の並び順等もありますしわからなくもないのですが、記事からはちょっとそこまでは読み取れませんでした。 >Webにデプロイというメニュー項目があるのですが、想像されるようなものではありません。SharePointサービスで利用するためのものなので。私の知る限り、InfoPathのフォームの機能はInfoPathでしか使用できません。確かにxsnファイルからxslファイルを取り出して、これを利用してブラウザにフォームを表示することはできるのですが、カレンダーのような機能は使えませんし。 作成したフォームを共有して使用するための仕組みは必要だと思うのですが、SharePointサービスでどこまでサポートされているのか気になります。 InfoPath Web Access（？）とまでは行かなくても、何かをしたい時にどのフォームを使用すれば良いかがエンド・ユーザにわかるような仕組みはないのかなと思ったのですが、ほとんどファイル共有に近いレベルのサポートなのであれば、もう少し頑張ってほしいかなという印象です。 |
|
投稿日時: 2003-03-27 12:22
>そもそも１つのスキーマに対して、それほど多くの種類のフォームが必要なのか？という疑問があります。
1つのスキーマに複数のフォームという考え方ではなく、1つのスキーマが表すデータを部分的に出力する定形フォームがたくさんあるという考え方でしょう。経理のシステムが扱うのが全社的なお金の情報だとすると、その情報を集めるフォームは社内に無数に存在するはずです。それぞれには（経理システムから見れば）断片的な情報を入力するわけですが。 >何かをしたい時にどのフォームを使用すれば良いかがエンド・ユーザにわかるような仕組みはないのかなと思ったのですが、 ですね。Sharepointサービスがどこまで使えるかは私も興味のあるところです。言ってみれば、フォームを探すためのUDDIのようなものが必要になるのは間違いないでしょう。 |
|
投稿日時: 2003-03-28 12:57
>1つのスキーマに複数のフォームという考え方ではなく、1つのスキーマが表すデータを部分的に出力する定形フォームがたくさんあるという考え方でしょう。経理のシステムが扱うのが全社的なお金の情報だとすると、その情報を集めるフォームは社内に無数に存在するはずです。それぞれには（経理システムから見れば）断片的な情報を入力するわけですが。
う〜ん。難しいですね．． 経理のシステムを例にとって考えると、１つの伝票に対応するスキーマを作成するのではなくて、複数の伝票が入る（もっと大きな）スキーマを作成して、伝票入力フォームや伝票一覧（集計）フォームを作成していくというイメージなのでしょうか？ それとも、スキーマは１つの伝票に対応するものを作成して、ほとんどの情報は入力用フォームから入力するけれど、決済承認用の（小さな）フォームなども作成する、作成された個々のXML文書をバックエンド・システムで集めてマージ（Transform）し、大きなXML文書にして一覧（集計）フォームはそちらを参照するというイメージなのか．．． また、上記のような例の場合、起票者が入力／参照できる（してよい）項目と経理部しかアクセスしてはいけない項目なども出てくると思うのですが、この辺りのアクセス制御をどのようにして行うのかも気になります。 ＃この辺りの設計スキルを勉強しておかないと、エンド・ユーザに「はい。使って下さい。」と言えないですね（滝汗） >言ってみれば、フォームを探すためのUDDIのようなものが必要になるのは間違いないでしょう。 どちらかと言うと、関連する複数のフォームへのリンクを集めたポータルのようなものを作りたくなると思うのですが、InfoPathはInfoPathの世界で閉じているという事になると、このようなものを作る必要があってもInfoPath（またはSharepoint）で出来ない事は出来ませんという事になってしまいそうな気がします。 |
|
投稿日時: 2003-03-28 14:01
Office2003は、1つ1つの製品を独立して考えないほうがよさそうです。
>１つの伝票に対応するスキーマを作成するのではなくて、複数の伝票が入る（もっと大きな）スキーマを作成して、 ということになるでしょう。ある特定のシステム領域がカバーする範囲全体で、統一されたデータを扱うのが目標なので、仮に領域が全社だとすると、ERPやらCRMやらを含む、全社で扱う情報というものを整理して、「顧客」「在庫」ごとに対するスキーマを作成する必要があることになります＜＜ちょっと話が壮大すぎますよね。。 >伝票入力フォームや伝票一覧（集計）フォームを作成していくというイメージなのでしょうか？ で、ここがポイントなんですが、入力フォームはInfoPathで作りますが、集計はExcelで行うでしょう。従来はExcelのデータはExcelを使わないと取り出せないし、WordはWordで、AccessはAccessで、でした（オートメーションとかありましたけど、あれは人間がやるかVBがやるかという違いだけですので）。 Office2003のXML対応というのは、データはXMLとして1箇所に置き、各Office製品が得意分野を活かしてそのデータを利用するという形になると思われます。各製品は、データを「所有」しないで「利用」するだけ。 >起票者が入力／参照できる（してよい）項目と経理部しかアクセスしてはいけない項目なども出てくると思うのですが、この辺りのアクセス制御をどのようにして行うのかも気になります。 確かにそれって重要ですね。XSDはincludeを使ってファイル自体を物理的に小分けできますが、それだけでは足りない気もします。ただ、自分が入力するデータは当然自分が見られるわけなので、見られないデータはXMLデータにも入れない、またはXIncludeのような仕組みをうまく使って、インクルードの可否をアクセス制御で切り分けるような部分は作る必要があるのかもしれません。 いずれにしてもポイントは、製品とデータとを切り離して考えることにあると思います。ExcelはXMLの集計ツール、WordはXMLの整形ツール、InfoPathはXMLの入力ツール、ということで、いずれの製品も単一のXMLデータに対する異なるビューを与えるだけ、と考えると、データがXMLになっているメリットも「なるほど」だと思われますが、いかがでしょうか。 ＃私はマイクロソフトのマーケティング担当ではありませんので、もしかするとまったくずれたことを言っているかもしれません。念のため。 
|
|
投稿日時: 2003-03-29 13:47
>で、ここがポイントなんですが、入力フォームはInfoPathで作りますが、集計はExcelで行うでしょう。
この辺りのサジ加減も難しいですね。 入力をInfoPathから行う以上、過去に自分が入力したデータを呼び出してきて変更（修正）する部分もInfoPathで同様のフォームを使用して行いたい、そうすると、過去に入力したデータを条件検索したり、一覧表示する部分が必要、一覧表示をするのであれば簡易的な集計は一覧表示の下に XPath式を入れれば可能という流れが自然のような気がします。 もちろん、多角的分析を行うといった目的には ExcelやAccessが適しているというのは想像できますが、何々を行う場合は Excelを立ち上げる、何々の時には InfoPathを起動といった使い分けをあまりエンド・ユーザに要求したくはないです。 （ユーザが意識して使い分けなければならない状態の意） Excelで作成した一覧表示の中から特定の一行を選んでクリックするとInfoPathのフォームが起動する、またはInfoPathで作成したフォームをExcel等他のOffice製品から使用といった事が可能であればシームレスに連携できるかもしれません。 |
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。