IBMにおけるDITAの取り組み

移行するに当たって苦労なさった点がありますか。

今まで扱っていた大量のSGML文書をDITAに移行しなければならなかったので、そのワークロードやコストは、とても大きかったと思いますし、移行の手順を確立する点も苦労しました。
さらに、SGMLの時には一つ一つのファイルがとても大きいものでしたが、それを小さなコンポーネントに分割するというのも大変でした。たとえば、どこで分割するのか、どの程度の大きさに分割するのかということも問題になります。
他にもツールの面で、今まで利用していたID Workbenchをそのまま使うにしても、DITAをSGMLに変換する部分のトランスレータを作る必要がありました。翻訳を考えた場合には、新しいマークアップの教育、既存の翻訳メモリーの再利用率の向上、ファイル数の増大による管理手法の変更など、多くの苦労がありました。

IBMにおいてNLSはどのような役割をお持ちでしょうか。

NLS（ナショナル・ランゲージ・サポート）は、IBM Translation Services Center（TSC）の一員としてIBMで作られているすべての製品の翻訳業務に携わっております。
IBMでは製品によって10から40程度の言語に翻訳されていますが、その中で日本語への翻訳は一番量が多くなっています。具体的な数字を申し上げることはできませんが、IBMの製品の量から類推していただけるかと思います。それらの製品のマニュアルやオンラインヘルプの翻訳は相当な量になります。

DITAに移行することによって翻訳も含めたドキュメントの製作期間や翻訳量に変化はありましたか。

DITAの主な目的はレイアウトと論理を分離するということでした。ドキュメントの制作期間を短縮するという目的だけを考えるとDITA以外にもソリューションはあったかもしれませんが、DITAに移行しコンポーネントの単位が小さくなっていることで、結果として期間が短縮するという効果もありました。

情報を再利用することで、翻訳する量も減少していると思います。ただ、ファイル自体が小さくなっていますので、以前に比べるとファイルの数は増え、翻訳者にとっては大変かもしれないと思っています。

翻訳プロセスにおけるDITAの運用方法や、注意されていることを教えてください。

DITA自体は通常のXMLですのでXMLの翻訳のプロセスと同じです。翻訳されたDITAをSGMLに変換して最終的な成果物を作るという点で独自のプロセスを使っていますが、実際にSGMLに変換しているところはID Workbenchが行うので、成果物を作成するオペレーターにとってはそれほど大きい変更があったわけではありません。

ただし注意している点として、ditamapやオプションの設定によっては、意図したものと全く違うものができる可能性があります。同じditamapを使っていてもフォーマットするときのオプションが違うとまた違うものができてしまうので、英語版とまったく同じ形のものを作成するためには、今までよりも注意を払う必要があります。
以前に比べると開発元から届くReadme文書（指示書）の量が非常に増えましたし、とりわけ組版するための説明が増えています。それだけ、運用していく際には注意が必要だということです。

さらに管理の面で大きく変わった点はありますか。

ファイル管理に、より注意を払うようになりました。例えば、一つのパッケージの中にリファレンスガイドとユーザーズガイドが含まれており、大量にあるDITAファイルをditamapで指定して複数の成果物を作ります。１つの翻訳パッケージのユニットから2冊、3冊のマニュアルができるという形式が主流になっています。複数のマニュアルで共通で使うファイルもあれば、単独で使うものもあります。一つ一つのファイルは小さいのですが、１つのパッケージに含まれるファイルの数は増えましたので、慎重に管理する必要があります。

さらに変わった点としては、以前に比べるとソースを作成する際の変更が簡単に行えるようになりました。そのため小さい変更がたびたび行われますので、それに対して翻訳も追いついていかなければなりません。これからもっとオンデマンドという形の翻訳が必要になってくるでしょう。

大きな修正ですと、時間をかけて変更がなされるというケースが少なくありません。以前のSGMLやGMLに比べると早く最終成果物を作ることは可能になっていますが、それでも、よりタイムリーに出すということに関しては、これからも課題となっていくと思います。

ほかに今後の課題と思われる点や、さらに期待する点はあるでしょうか。

DITAを使用することが適しているのは、リファレンス性のあるものだと思います。一つ一つの機能をコンポーネント化してお互いを参照し合うものに関してはとても有効ですね。

ただ、一つ将来に対する課題として、コンポーネントベースの考え方で記述したものが、お客様にとって良いものかどうかというのは、まだ分からないところもあります。じっくりと読むタイプのものに関してはどのくらいの効果があるのか考えていかないといけないでしょう。もともとDITA自体が、読者の使い勝手を考えて作られたものではなくてメンテナンスのしやすさや、再利用性を重視して作られたものなのです。それがお客様にとってどのような影響を与えるかというのは一つの課題となります。またそれは情報の作成側の責務であると考えます。

今後期待することは、コンテンツマネジメントシステムなどで管理して、もっとスムーズに、早くお客様に提供できるようにしていきたいということです。

DITAを使うことによって、例えばウィキ（Wiki）のようなもの、Webブラウザを利用して、簡単に発行や編集が行えるようにできないかということも期待されています。例えばマニュアルであれば何か指摘があった時に動的に修正できるようになればいいですね。それができればユーザーはいつも最新の情報を手に入れることができることになるのです。現状では、動的に修正するにしても、どのように修正されたかというヒストリーなどの情報も必要になってくるでしょうし、その効率的な運用も含め今後の課題だと思います。

日本の中でDITAの関心は高まっていると思いますが、これからDITAの導入を考えている読者へ一言お願いします。

DITAに移行する際には、コンポーネントをなるべく小さくすることが一番大事です。例えばパラグラフが４つか５つあるセクション単位が一つのコンポーネントになるというような書き方が必要だと思います。いわゆる構造化された文章を書くスキルが重要でしょう。要するに最初から最後までずっと単調に書いていくのではなくて、いかにそのインフォメーションをユニットに分けていくかということが重要です。

現在、比較的長く書かれているものを論理構造主体の小さなコンポーネントにしていくところでは苦労する部分があるかもしれません。しかし、それができると様々な効果があるでしょう。
例えば一つのヘルプメッセージを一つのコンポーネントとするならば、DITAを管理しているコンテンツマネジメントシステムから、マニュアルを作る際にライターがそのヘルプメッセージを引き出すこともできますし、プログラムを作る時にもそのDITAファイル自体を、メッセージ情報などとすることができます。パネル名やフィールド名などの画面用語もそこから利用できますね。
そのインフォメーションのユニットをどのように分割するかによって、使いやすいものになるか、そうならないかというのは決まっていくと思います。

あえてDITAにしなくてもよいインフォメーションもあるでしょう。ただ、ファイルフォーマットをある程度共通化することで、ポータビリティが高まることになります。
最初の導入には時間と労力がかかりますが、使い方次第で、様々な効果が得られるでしょう。

本日はありがとうございました。
（聞き手：成宮 紗弥子）

【脚注】
1.PII（Program Integrated Information）：製品の一部をなすオンライン情報で、パネル、メッセージ、ヘルプ、チュートリアルなどがあります。

日本アイ・ビー・エム株式会社 ナショナル・ランゲージ・サポート 部長  吉野  徹夫 氏 日本 IBM 入社後、1983-1988 テクニカルライターして勤務。 その後 1989-1992 翻訳関連ツール、機械翻訳関連ツールなど、翻訳、出版を支援するツール類の開発、テストに参加する。1993-2000 には IBM 製品のローカライゼーション、テスト関連業務を行う。その後 2001-2003 社内の翻訳支援ツール作成、サポートグループの責任者として業務し、現在、翻訳部門の責任者として活動。