Web Technology ＞ XML for Designers
机の引出しに眠っていた原稿を掲載します。書籍用に執筆し、ページ数があふれたためにカットしたものです。
実務でWebアプリケーションを開発することになれば、クライアント（開発依頼主）の要求に沿って、企画設計を行う必要があります。画面設計も、項目名も、データも、書籍収録のサンプルと同一になることはありえません。サンプルプログラムをそのまま使うのではなく、処理を理解したうえで、設計書に基づき、プログラムを記述していくことが求められます。
既にXML Webアプリケーション開発の経験がある人にとっては、プラットフォームが何であれ、従来の開発工程を大きく変える必要はありません。しかし、
（１）これまでRDBを扱っていてXMLを使ったことがない
（２）Windowsアプリケーション開発の経験はあるがWebアプリケーション開発の経験はない
（３）静的なWebサイト制作経験はあるが、動的な処理を実装したことはない
という人にとっては、これまで考える必要のなかった作業が派生してくるので注意が必要です。
XMLアプリケーションの開発では、RDBを使ったアプリケーションと異なり、データベース設計に際して、階層構造を考えなければなりません。親子関係と、要素にするか属性にするかといった問題も考えなければなりません。
検索や表引き処理、データ登録を実装する場合は、主キーに該当する要素（あるいは属性）も見当を付けておきます。
項目名やデータ型（必ずしも型は必要ではないこともある）を決めるのは、RDBも同じです。
また、Webアプリケーションの場合は、Windowsアプリケーションと異なり、クライアントだけでなく、一般インターネットユーザの環境や操作性も考慮しなければなりません。企画・設計段階で、クライアントのイメージを忠実に再現し、且つユーザインタフェースも考慮した、画面遷移図の作成が重要になってきます。
さらに、Webアプリケーションでは、静的なWebサイトと異なり、ユーザのアクションに応じて結果を返す処理が必要になるため、サーバへのポストバックやキャッシュのクリア、処理速度も考慮しなければなりません。
XML Webアプリケーションでは、幅広く、いろいろな要素を考慮して、バランスをとりながら開発を進める必要があります。
ここでは、書籍に掲載されているサンプルプログラムを参考にしながら、小・中規模案件の開発を実際に行っていく場合の注意事項をピックアップしてみました。
ASP.NETで素早くシステムを組んで従来業務を効率化したい」といった小・中規模案件では、クライアントは、Webアプリケーションというよりもむしろ、検索や集計などのプラスアルファの機能が付いたWebサイト制作をイメージしていることがあります。中には「Webサイト＝ホームページ作成ソフトで簡単に作成できる」というイメージを持っているケースもあります。このため、納期や予算の面からも、即座の開発が要求されがちになり、企画や設計をおろそかにして、コーディングを進めがちになります。また、資料整理や議事録作成、仕様変更の記録といった、いわゆる「雑用」をおろそかにしがちです。しかし、段取り８分で、企画や設計の工程を曖昧なまま進めてしまうと、逆に、後々度重なる仕様変更が生じかねません。そこで、企画段階では、最低限、次の事項を詰めておいた方がよいと思います。
もちろん、これら以外にも、ヒアリングしておくべきこと、コンセンサスを得ておくべきことは山ほどあるでしょうが、次の事項は最低限忘れないようにしたいものです。
※ WindowsアプリケーションからWebアプリケーションに移行したシステムハウスと、Webサイトの制作からWebアプリケーションまで業務を拡張した制作会社では、同じ開発テーマであっても、アプローチも進め方も、使われる用語も異なります。以下は、前者と後者、どちらにもある程度共通すると思われる工程や、打合せ時の注意事項です。
1. Webアプリケーションの期待効果の確認
- 新規開発か、旧来システムからの移行や見直しか、現状のシステムの技術的バージョンアップか
- アプリケーションの目的。業務処理か、物品販売か、広告宣伝か、コンテンツ発信か、情報収集か、データ共有やデータ交換か、など。
- 現状はどのような作業が行われているか
- アプリケーションによって、現状をどのように変えていきたいか（できるだけ単なる話ではなく数字で示す）
- 社会的背景、使用対象、使用範囲、使用場所、使用人数、期待効果、経営・業務課題
- 期待効果を得るために、どのような機能を実装したいと考えているか
2. WindowsアプリケーションではなくWebアプリケーションであることの確認
- 両者の仕組みの違いを説明する。
- サーバサイド処理と、クライアント処理のメリット、デメリットを説明する。
- サーバの費用、メンテナンス、セキュリティ面も説明する。
3. 利用ユーザ側の閲覧環境の確認
- パソコンか携帯端末か、ブラウザ、そのバージョン、回線、画面解像度を確認する。
- アクセシビリティについて、確認する。
※サーバサイド処理であってもブラウザによって表示は異なることを説明する。
4. 実データの確認
- データの内容（言語、文字コード、外字や異体字の有無、数式、地図、図面など）
- 定型か不定形か、階層構造にするメリットがあるか
- 既存データが存在する場合：そのデータの形式（まだ紙ベース、あるいはAccessで管理しているなど）、現在の管理方法、項目数（ノード数に反映）、ファイルサイズなど
- 既存データが存在しない場合：フォーマットに合わせたデータ作成がクライアント側で可能かどうか（不可能であれば入力フォームをWindowsアプリケーションとして開発したり、あるいはInfoPathを使って作成したり、データ入力まで請け負う必要あり）
- 随時更新の可能性があるかどうか、その頻度、最終的に使用するデータの量
- データの再利用の可能性、利用頻度、利用目的（参加団体で共用、取引先や支社などで利用、他部署で利用、他目的で利用、など）
5. データ形式の確認
- RDBか、XMLか、併用か
- XML化の目的を明確に（XML化の理由が曖昧なまま、XML化を進めない方がよい）
6. その他のチェック事項
- データの機密性（ユーザ情報を扱うかどうかなど）、Webアプリケーションの利用頻度、プログラムファイル以外のファイルのサイズ（商品写真などを掲載する場合）、Webサービスを実施する可能性があるかどうかなど。
7. クライアント側スタッフの確認
- クライアント側との作業分担。開発を協力体制で行うか、運用、保守にどこまで関わるか。
- クライアント側にIT技術者がいるかどうか、その専門は何か、アプリケーションのメンテナンスやサーバ管理をどちらが行うか、開発言語あるいは開発ツールに指定があるかどうか
- データベースの更新をクライアント側で行うか、開発側で行うか
8. データベース製品を導入するかどうか
- 規模、データの保守性、予算
- フラットな階層でよいか、ツリーを活かす必要があるか
- 既に取引のあるベンダがいるかどうか
9. プラットフォームの確認
10. サーバの検討
- 自社で構築するか、専用サーバ、レンタルサーバか
- サーバのOSとそのバージョン、Frameworkのバージョン、開発ツールを導入するかどうか
- XMLだけでなく、SQL Serverデータなどを併用するかどうか
- 既存のblogを利用するかどうか
11. 予算の確認
- 初回打合せ時に既に予算ありきの話である場合。予算に対して実装する機能の希望があきらかに多すぎる場合は、一括構築か段階的導入か、企画見直しか予算計上か、コストダウンする方法はないか（人件費の安価な地方SOHOに外注するなど）、機能を絞り込めないか
12. 技術の確認
- 技術的に可能かどうか、不可能であるとすれば社外に専門家がいないか、将来可能にならないか（バージョンアップ時に実装できないか）
13. タグ設計の確認
- XMLの場合、データ先行か設計先行か、将来的に項目変更などが生じるかどうか、整形式XML文書とするか検証済みXML文書とするか、整形式の場合タグ設計時点での覚書の作成フォーマットはどうするか、検証を要する場合スキーマかRelaxかDTDか、公開されているDTDを利用できないか、など。
以上の点を重点的に確認してから、企画書や見積書を作成します。
