最近のマニュアル制作の1コマ

音声による情報提供は難しい

アクセシビリティに注目が集まっている関係か、音声による情報提供が研究されるケースが増えているようです。もちろん本体よりも大きく重いマニュアルをなんとかしたい携帯電話や、安全上の問題からユーザーが紙面や画面をじっくり読む訳に行かない車載情報システムなど、音声による情報提供に注目せざるを得ない製品が増えつつあることも理由の1つでしょう。

さて音声で情報提供を行う場合ですが、ワンソースマルチユースで対応する場合と、専用コンテンツを用意する場合の2つのアプローチが考えられます。つまり、紙や電子媒体用の通常の文字表現テキストをそのまま利用するのか、それとも音声による情報伝達に最適化したコンテンツを別途用意するのか、ということです。また、すべての情報を音声で提供するのか、それとも音声による情報提供はポイントを絞って必要最小限にとどめ、製品やサービス全体の情報を（紙の冊子やWebサイトなどで）別途提供するのかによっても、音声コンテンツに求められる性質が変わってきます。

ただはっきりしているのは、特に高機能製品の取扱情報を提供するケースにおいて、ワンソース運用では音声情報としてまともに機能させるのは難しいということです。これは何故かというと、（紙にしろ電子にしろ）視覚表現を前提として設計した情報をそのまま流用しても、音声ではうまく機能しないからです。「alt属性の記述など各種アクセシビリティ対策をすることで、音声環境でも同等の使い勝手を提供できる」というような極論を目にしますが、とんでもない話です（もちろん何もしないよりは全然良いのですけれども）。

例えば、操作情報の枠組みは、見出しと導入文、操作文＋結果文のセット、サブ情報（ご注意＋ヒント）といった要素で構成されます。紙媒体では導入文内の概念説明が過剰だと感じた時点ですぐに飛ばし読みができますが、音声を聞いている場合はどうでしょう？ 音声では聞き飛ばし（斜め読み）がしにくいので、情報を必要最小限に絞り込む必要が出てきます。操作説明文であれば、実際の操作説明の前には、見出し（タスクのゴール）と見出しだけで説明しきれないタスクの補足情報、操作前に把握する必要のある重要な制約情報程度に限定する必要があるでしょう。概念説明や補足説明などの既存のマニュアルで重宝される情報に関しては、操作説明が終了したあとに必要に応じて参照できれば十分です。完全な情報を提供する機会を別途用意するのであれば、なおさらですね。

音声による情報提供で一番重要なのは、現在再生されているコンテンツは自分が必要としている情報なのか？を極めて初期の段階で把握できるようにすることです。これは視覚による情報提供では斜め読みで見当がつく場合が多いのに対して、音声ではある程度の量を聞いてみないと見当がつかないためです。ある程度の量を聞く＝それだけ時間がかかる訳ですから、この部分をしっかり意識する必要があります。お客様窓口電話番号に採用されることが多くなった自動応答システムで、自分が必要な情報がどれなのかわからなくなって途方に暮れた経験はありませんか？（この話、たぶん何かの機会に続きます）　（2003.01.27）

制作期間を短縮するにはどうする？

すっかり間が開いてしまいましたが（反省）、ようやく復活です。

最近は製品開発期間の短縮（もちろんコストダウンも）が至上命題と化していて、マニュアル制作もそれに合わせて短期化することが求められています。また、現物重視の反復型の開発手法が多用されることが多くなってきている関係か、 マニュアル側も短期間にチェックを何度も重ねて内容を作り込むというケースが増えています。その結果として、数百ページのマニュアルを中二日ですべて修正して再提出という状況が頻発するなど、制作現場にかかる負荷は増大する一方です。まあこれは極端な例ですけど。

さて、負荷増大に対しては投入リソースを増やすことで対応するのが一般的かと思います。ですが、制作期間が短縮されるマニュアルの場合には、単純にリソースを増やしてもうまく対応できないことが多いのです。現状の開発体制では分散オーサリング→集中管理による一貫性チェックという段階を踏む時間など取れないことがほとんどですし、投入したリソースの分だけ余計にコストがかかることにも注意が必要です（どうせ認めてもらえないんですけど）。仕様書や機能単位を中心に解説するリファレンス系マニュアルであれば分散オーサリングでも問題ないのでしょうが、複数機能にまたがるユーザータスクを中心に解説する操作マニュアルは、定型化したもの以外は分散オーサリングに元々向いていないのです。で、既存ワークフローのまま現場に負荷をかけざるを得ない→現場崩壊／社員退職（笑）というお約束のルートを辿るわけです。

こういった問題を解決するには、マニュアル制作を反復型開発とは別のルートに乗せられないか検討するとか、（ユーザーに負担を転嫁しないことを前提に）マニュアルとして提供する情報の内容を見直す／削減するなど、純粋な制作方法以外の部分で何らかの対策をする必要が出てくるでしょう。制作側だけでなく、製品開発側やユーザーに対する情報提供に責任を持つ部門との調整も必要になります。とにかく現状のマニュアル制作を続ける限り、一定の品質を維持することがどんどん困難になってきていることを、多くの方に理解していただきたいものです。およ？ 品質なんてどうでもいい？ はあ、そうですか。

とまあこういう事情を理解していただいて、新しい情報提供の枠組み造りに取り組めるのは嬉しいものです。多忙で沈没することが増えそうですけど（笑）　（2003.03.10）