XMLによるデータ標準化の進め方ハウツー

本日、汐留シオサイトに海風が堰き止められて、気温が上昇してしまったという噂の酷暑の銀座で、IT系研修サービス業界の方々の集まりに混ぜていただいた。

取り扱い商材のマスター同期に使えるXMLデータ標準を作ろうということで、積極的に標準化活動を始められているところである。

本来、異なる企業間では、お互いの所有しているシステムがどのようなデータの持ち方をしているかを事前に詳しく知る手段はなく、こうした話し合いの場で徐々に情報を公開し合い、足並みを揃えていくしかない。

私もこういった標準化活動に携わるようになって4年ほどになるので、いわゆる勘どころというか、どの業界でも一度は経験する壁みたいなものの存在は、だいたい予見できるようになってきたつもりだ。こういう新しく標準化活動を立ち上げようとされているところでは、お役に立てる部分も少しはあるだろう。

しかし、これは一足飛びにゴールへ近道できることを意味するわけではない。なぜなら重要なのは、当事者たち自身が標準化とはどういうことなのかを肌で感じ、そのプロセスの中に身を置いて体得していくこと、即ち時間をかけてコミュニケーションを重ねていくことそれ自体が重要だからである。私にできるのは、確実に成功する処方箋を提示することなどではなく、確実に失敗する方向に向いてしまっているときに、そっと軌道修正を促すことだけだ。

2時間ほどのディスカッションに混じってお話をさせていただいたポイントは、下記のようなことである。データ設計＆標準化の基本的な考え方と思うので、ご参考まで。

• 何よりも、ゴール設定が重要。何を達成したいのか。Excelなどでデータの受け渡しをしていた部分を自動化したいということであれば、システム化が投資効果に見合う部分は更新頻度の高い部分に限られる（マスター系なら、価格表など）。受け取ったExcelの情報を自社システムに再入力する作業が月一回で数時間程度の作業なら、恐らくそれほどシステム化を急ぐ必要はない。
• 普及を狙うならとにかく「単純明快」な仕様にすることが重要。ゴールを達成するために必要十分なデータ項目に絞り込む。ここでも20:80の法則（パレートの法則）は大体うまく機能する。あれも必要これも必要と棚卸しして出てきたデータ項目の総和の、重要な20％だけを採用すれば、だいたい80％の要件（特に正常系）は満足される。とにかく必須の項目に注目し、「あれば便利（かも知れない）だからオプションとして入れておこう」という論調を避ける。特に、フラグによる分岐は実装の複雑度に直接ヒットするため、極力避ける。
• データとプロセスは、常に表裏一体、システムの陰と陽。「プロセスなんかない」と思い込んでいるときこそ、実は何がしかの習慣的な手続きを暗黙に仮定しているに過ぎない。例えばマスター同期のような単純な要件でも、更新頻度や祝祭日はどうするかなどの取り決めは運用上必要なので、ポンチ絵一枚程度でも必ず約束事を明文化しておく。初期検討時の考慮から漏れた例外的な事柄は必ず後でボロボロ発生するので、そのときにはその文書をメンテしていく。
• 変わらない、変わりにくい情報（企業名、住所、電話番号など）は「TPA（Trading Partner Agreement：取引運用規約）」という、契約書で言えば基本契約書のようなものに持たせる。何でもかんでもトランザクション電文に取り込もうとしない。
• データ型は基本的なもの（String, decimal, dateTime程度）だけから始め、前提知識を最小化する。durationは理解と実装の負担が大きいので避けるか、ユースケースをきっちり制限する。維持管理が問題にならない場合、候補値（enumeration）をうまく使うのはよいこと。

参考：よく利用されるXML Schemaのデータ型（＠IT）

• バックエンドから単純にセットするデータ項目に関しては、データの桁数についてあまりケチケチしてナーバスに定義しない。桁数の制約が効いてくるのはvarcharなどの可変長を扱えないレガシーなバックエンド側の問題（あるいはダム端末への画面表示制約など）なので、中間フォーマットのXMLレベルで制約したところで実はほとんどメリットはない（A社のシステムが10桁で管理していて、B社のシステムが12桁で管理していたら、結局A社のシステムを何らか更改するしかない）。バックエンドのDBも同時に新規に設計する機会に恵まれたなら、物理設計レベルでは将来の拡張に備えてvarchar(256)のように緩く、緩く。
• 多数の繰り返しがある明細項目は、一電文につき一カ所まで。互いに独立な繰り返し項目を二つ以上含むと、確実に実装の難易度が上がるため避ける。明細以外の繰り返し（例えば二人分の担当者情報など）は、繰り返し回数の上限を少なく規定し、ループを用いないベタ実装の余地を残しておく。つまり、不定数の明細は一カ所だけループ処理すれば済むようにする。（これは不特定の相手に対する、実装の自由度とスキルのばらつきについての配慮である）

以上、ハウツーということでこのような信条を一覧してみたが、これらは様々な標準化の流派のほんの一つの選択肢に過ぎない。方法論の好みや相性は人それぞれ。上記の内容も妄信せず、皆さん自信で咀嚼し、使えそうな部分は使ってみていただけるとありがたい。

こんな走り書き程度の情報でも、誰かしらのお役に立てることを祈りつつ。

♪ Vince Neil / Living Is A Luxury