このジャンルの新着記事
（最新５件）
記事のジャンル
過去記事
アンテナ・ブックマーク
「テクニカルコミュニケーション」記事の一覧
本格的な業務多忙で沈没しており、来月末まではちょっと身動き取れなさそうです。こちらも放置気味で申し訳ございません。さすがに3ヶ月放置はまずいので、前のエントリでネタを振ったTCシンポジウムの感想などを…（いくら何でも遅過ぎ）。
強烈な暑さの続く今日この頃ですが、いかがお過ごしでしょうか。暑さで体調など崩されませぬようご自愛ください。
このWebサイトは1996年の8月の開設ですので、実は11周年ということになります。昨年は10周年記念企画をやろうかと思っていたんですが、バタバタしていたり諸事情でなしのつぶてに…。開設した頃と比較して変わったこと、変わらなかったことなど、そのうちちゃんとまとめたいですね。12年目に突入しつつも、これまで通り細く長く（笑）続けていきたいと考えておりますので、思い出した頃にでも再訪して頂ければ幸いです。
テクニカルコミュニケーター協会の広報誌「TC協会ニュース」（第77号）（PDFファイル）で、「日本版SOX法の施行を睨み、業務マニュアル分野への対応拡大、支援を考えるべきでは」という趣旨の話が協会理事の方へのインタビュー記事にありました。このコーナーの以前の記事でも触れましたが、ようやくこういう話が出てきたか…という感じです。
でも正直なところ、現状のマニュアル制作者に要求されるスキルセットでは無理でしょう。というのは、業務マニュアル制作においてもっとも必要とされるであろうスキルが、現状のマニュアル制作では重視されていないからです（本当は必要不可欠のはずなんですが）。
業務マニュアルを制作する必要が出てくるケースとしては、以下の3つのケースが大部分ではないかと思います。
上記いずれの場合であっても、わかりやすいマニュアルとして情報をまとめる視点だけでなく、業務プロセスに問題（漏れや潜在リスクなど）がないかどうかをチェックするという視点が必要、ということに注意する必要があります。特に後者の視点が重要で、業務マニュアル作成という業務は、業務プロセスのコンサルティングの領域に一部踏み込む必要があるのです（ここでマニュアル制作者ならではの独自視点をどう活かすのか？が、コンサル屋さんとの差別化になるはずなのですが…）。
これは操作マニュアル制作において、仕様書を読解してユーザビリティの問題を指摘する（さらには改善案を提示する）ことと同義であり、現状のマニュアル制作者のスキルでは対応が難しいでしょう。主な活動領域である操作マニュアル制作においてさえできない（重要視されていない）ことを、業務マニュアル制作の領域でできるはずがありません。業務マニュアル制作に乗り出すためには、操作マニュアル制作に要求されるスキルセットから見直す必要が出てくるはずです。
当該記事中の会社は親会社がSIerということもあり、上流工程で業務が正規化された後で業務マニュアルの制作開始、というケースが多いのではないかと思われます。このようなケースでは、仕様書をベースに操作マニュアルを制作することとプロセスとしてはそれほど変わらないでしょうから、さほど大きな問題はなさそうです。ただ、それが本当に業務マニュアル制作という仕事なのか？というと、何かちょっと違うような気がするんですよね。
テクニカルコミュニケーター協会の広報誌「TC協会ニュース」（第74号）（PDFファイル）に、表題のコラムを執筆させていただきました。
既存の各コミュニケーションツールという枠組み間の調整よりも、ユーザーコンテクストとの合致を最優先として、既得権益の巣窟と化した枠組みそのものを解体していくことが必要なのではないか？という問題意識を、マニュアル制作領域で典型的に見られる問題にあてはめたものです。というか、エンドユーザーに日々向き合っているマニュアル制作者こそ、（本来は）こうした問題に向き合う視点を提供できるのではないか？という思いを込めたつもりなんですが。ただこれはあくまで筋論なので、現状の諸条件に適合しているかについては保証の限りではありませぬ（汗）
CGM（というかPGM）時代を前提とすると、企業は「ユーザーに正直に接する、嘘をつかない、虚勢を張らない」（参考記事1、参考記事2）ということを、これまで以上に意識していかなければならないはずです。このような態度こそ、自社のファン、サポーターになってもらうために必要なものですからね。そういうことを考えるにつけ、製品やサービスの都合の悪い面といつも向き合っているマニュアル制作に携わる人々を、もっと活用する方法はあると思うんですが。頭が固いというか、何というか。
ただマニュアル制作者の側も、現状ではまったく力不足と言わざるを得ません。いきなり全体の絵を描く話に参加するなどと意気込むよりも、目の前の仕事の品質を上げて行く不断の努力も必要でしょう。全体の話をするためには、自分の専門ならではの視点をしっかり提供できることが前提ですからね。「上流工程の話をしたい。マニュアルはやりたくない」などと実力も省みずに舞い上がって、地に足のついていないことを言い出す人もいるでしょうが、あらかじめ釘を刺しておくということで（もちろん自省も込めて、です）。
最後にいきなり話は変わりますが、当該コラムで触れた「UI組み込み型製品にどういう操作情報を組み込んでいくべきか」という課題は弊社としても非常に興味があります。位置付けや紙マニュアル他との連係について悩まれている方は、ぜひご一報を（笑）
この1年での仕事の話です。メーカーのマニュアル担当の方と話をしていると、マニュアル制作者（制作会社）に対して不満を持たれている方が多いようです。そのなかでも「仕様書や支給資料の清書屋（DTP屋）以上の仕事をしていない」という不満が強いと感じます。さらに突っ込んで話を伺ったり、実際の完成マニュアルを拝見したりすると、以下の問題を抱えている傾向があるようです（以下、とりあえず自分のところを全部棚上げして話を進めます）。
要するに日本語表現としては正しくてもマニュアルとして全然ダメという訳で、これでは清書屋呼ばわれされても文句は言えないでしょう。何が良いマニュアルなのか？を理解していないためか、後継製品のマニュアルが元製品のものよりも劣化していることさえあります。制作会社（や担当者）によってレベルの差はあるにせよ、全体的にマニュアルの品質は低下傾向にあるように思われます（少なくとも明示的に向上しているようには思えません）。
確かに最近の製品やサービスは高機能化／複雑化が著しく、製品理解のハードルが上がっていることも事実です（これはまた別の機会に書きます）。しかし上記の問題はそれ以前の話で、「閲覧コンテクストを想定した上で、どのような情報をどのように提供すべきなのか？を正しく判断する」という、マニュアル制作のプロセスで一番重要なところができていないのですから、どうしようもありません。狭義のライティングテクニック（日本語表現）としては問題なくとも、マニュアルとして機能しないのであれば意味がないのです。
また、この品質低下問題については、既存の評価チェックリストによる品質評価が機能していないと捉えることも可能かと思います。多くの制作会社の社内チェックではこの種のチェックリストを使用しているようですが、それが品質向上につながらないのであれば、チェックリスト自体の妥当性が問題になってきます。マニュアルコンテストの審査基準に対する疑念は以前書いた通りですが、現実のマニュアル品質を評価する上での押さえておくべきポイントが、しっかり押さえられていないのではないでしょうか。
この種のチェックリストですが、文章やイラストといった最終表現のテクニック評価に偏りがちで、一番重要と思われるユーザーコンテクストとの適合性や情報構成方針などがケアされていないものが多い、という印象があります。要するに定量化やON/NGの判断がしにくい部分がスルーされている訳で、これが結局、所謂テクニカルコミュニケーションの付加価値を正当に主張できない（コストとして転嫁できない）という問題にも共通する、諸悪の根源ではないか？とも考えられます。
まあなんだかんだで、品質向上のためには教育体制を地道に何とかしていくしかないでしょう。優秀な人材を確保できないこともあるのかもしれませんが、マニュアル制作会社にもしっかりした教育をお願いしたいところです。この辺の教育のポイントについては、関係あるようなないような微妙な次回（予定）のエントリに続く、と思います。ちなみに弊社ではマニュアル評価や、社内勉強会のサポートなどといった品質向上支援も業務として行っておりますので、お困りの際はぜひ声をおかけください（笑）
そうそう最後にひとこと。笑って見てる（かもしれない）Web制作関係の方々、他人事ではありませんのでよろしくお願いしますね。
2005年9月1日〜2日に開催されるテクニカルコミュニケーションシンポジウム2005ですが、パネルディスカッション「テクニカル・コミュニケーションで稼ごう！」にパネラーとして参加させて頂ことになりました。というか、そもそもそんなに稼いでないんですけど（汗）
確かにテクニカルコミュニケーション（というかマニュアル）で稼げる余地というのは減って来ているように思えます。ですが、それは単価ベースの下落による苦境というよりも、翻訳展開や派生機種の大量生産による売上という前提が成立しなくなっただけではないでしょうか。もちろん大量生産を前提としてリソースを手配しているような大きな制作会社にとって、死活問題であることは否定しませんが。
このような状況に対しては、テクニカルコミュニケーションの業界は上流（商品開発）／下流（サポート）の仕事を取り込むという「テクニカル」特化の方向と、仕事を周辺分野に拡げるという汎用化の方向のいずれかの道を選ぶ必要が出てきます。個人的には、「テクニカル」への必要以上のこだわりを辞め、専門化よりも汎用化、つまり総合コミュニケーションデザインの方向を目指すべきと考えています。
実際問題として、（無自覚的にではあっても）この種のスキルを求めているお客様は沢山いると思うのです（それをお金に替えることが難しいことも事実です）。適用領域を拡張していく中でお客様に喜ばれ、そしてまた本来の「テクニカル」な領域にも良いフィードバックがかかる、ポジティブな循環こそ必要なのではないかと。有能な人材がなかなか定着しないという、この業界の慢性的な悩みの解決策としても、一考の余地はあると思うのですが。
とまあ、こういった話などなど、いろいろな話が出るものと思われます。参加費用が高額なので会社費用で参加する人以外の参加はキツイ（笑）と思いますが、ご都合の良い方はぜひご参加ください。
先日のJAGATのセミナーの午後の部を聴講して、RIA（Rich Internet Application）の現状について勉強させて頂きました。情報の密度も高く、高額な費用も十分納得できる素晴らしいものだったと思います。
で、その際に各種デモを見て、何となく思ったことを。
一般的なRIAは通常のアプリケーションソフトウェア（以下、アプリケーションと略）と異なり、達成すべきタスクが明確で限定されている（例：航空券を予約する）ことが多いかと思います。そのため、アプリケーション全体の情報を提供する、独立した外部情報（既存のchm形式のヘルプや独立した操作解説ページなど）は不要となり、操作情報は操作に応じた状況依存で提供することが基本方針になります。
ただし、それでは操作前／操作中に操作全体の流れを把握できなくなり、ユーザーの不安感につながる可能性があります。従って、必要に応じてその種の情報を参照できるようにするか、または全体の流れの情報をUI側で提供する必要が出てきます。外部情報を参照させずに操作に集中してもらいたいというRIAの狙いからすると、操作情報をUIへ統合するという後者の方法が望ましいでしょう。操作情報のUIへの統合というネタは以前から主張してきたのですが、ようやく一般化するところまで来た、という感じです。
しかしこのような外部情報を軽視すると、操作にあたっての前提理解や制約条件といった情報をどのように提供するか、という視点が抜け落ちてしまう可能性があります。この種の情報は操作する前に提供されるべきものですが、実際にUI上でこの種の情報を提供しようとしても、文字情報だけを並べても読んでもらえることは期待薄でしょう。かといって、理解してもらわないことには、操作の終盤段階で「それではタスク実行できません」というユーザー体験としては最低のケースにつながりかねません。
そのような事態を防ぐためにも、ユーザーシナリオや操作手順、情報伝達システムを入念に設計することが必要で、先日のセミナーでもこれらの設計プロセスの重要性が強調されていました。ですが、通常のアプリケーションでもこの辺の設計はヘロヘロなのに、RIAになった瞬間に問題が解消される、というのは幻想に過ぎないでしょう。結局のところ、WebサイトやアプリケーションのUI設計や情報設計に携わる方でも、操作情報のデザイン経験が乏しいということにも原因があるのではないでしょうか。その意味で、テクニカルコミュニケーション分野の人達の関与が、もっと必要ではないかと思います。
まあそんなこんなで、RIA上での操作情報の提供手法については、今後も見守っていきたいと考えています。
マニュアル制作で必要とされるスキル・視点をおおまかに分類してみると、次の3通りになりそうな気がします。
確かにマニュアル制作のスキル流用が直接的に可能であることを対外的に示すには、これが一番手っ取り早いように見えます。ただし、表現設計は適用領域による幅（業界基準や表現の流行など）が大きく、一般的なわかりやすい表現が通用するとは限りません（そもそも求められていなかったり…）。
さて、マニュアル制作のスキルを他領域で展開しようという話になると、たいていは表現設計の話になりがちです。「マニュアル制作で鍛えられた、わかりやすい表現技法を提供します」とかいって。
また、汎用ビジネス表現技法として見た場合でも、（広告に要求されるような）飛び道具的な表現が要求されても、対応できないのが実状でしょう。プレゼンテーション資料のように、実際のわかりやすさよりも見かけのわかりやすさやインパクトが求められる場面（最近の図表化・視覚化の流行とか…）も多いのが現実ですから、マニュアル制作のスキルが活かせるかどうかは、また違うような気がします。
というようなことを考えると、本当の意味でマニュアル制作やテクニカルコミュニケーションで得られた知見・経験を活用できるのは、ワークフロー設計や情報設計の領域だと思うのです。文書が絡む業務システムの分析とか、様々なメディアやツールで提供する情報の枠組みの再検討、業務文書のフォーマット規定などといった課題は、マニュアル制作で養った感覚を活かすにふさわしく、専門家としてのスキルを大いに発揮できるものでしょう。
一番の問題は、お客様が「なんで取説屋さんがここに？」と疑問に思ってしまうことでしょうか（苦笑）もちろん上記のようにご説明すると、納得して頂けるのですけど。その意味でも、マニュアル制作やテクニカルコミュニケーションで得られる適切なメリットについて、世間に対して呼びかけ続けることが大切になってくるのではないかと思います。
「エディトリアル・デザインはウェブ・デザインの夢をみるか」（wellinton's blog）に基本的に同感（行長＆字数制御の必要性は特に！）で、読みにくいWebページはまだかなり多いと思います。人文系の長文だけでなく、技術系の翻訳モノにも読みにくいWebページが多い印象がありますね。InDesignの師匠（笑）に組んで頂いたフォーマットで紙媒体データを制作する仕事が最近続いているのですが、しっかりした版面設計を見慣れたあとにWebサイトを見ると、正直いろいろと辛いものがあります。
ユニバーサルデザイン志向という理念だけでなく、閲覧環境（Webブラウザ＆表示デバイス）の多様性に対応しきれないという現実からも、この問題に対する決定的な解決策は見つかっていません。ですが、それを言い訳にして、読みやすさの実現を最初から放棄しているような印象も受けます。ある程度の決め打ちを含めて、一般的（これが困難…）な環境での読みやすさは、もっと追求されてしかるべきだと思います（アクセシビリティに関しては、プレゼンテーションとデータの分離によって保持すべきというのが持論です）。
読みやすさを改善するためには、「CSSにおける国際的レイアウト」のように、読みやすいデザインを実現するための仕様／技術を拡張することがまだまだ必要だと思います。またそれだけでなく、いわゆるエディトリアルデザインを専門にするデザイナーが、Webの世界にもっと出てくるべきでしょう。もちろん紙媒体からの転身であるか、電子媒体育ちであるかは問わず、です。
その一方で、デザインだけで読みやすさを改善するのはやはり限界があります。その意味で、読みやすいWebページを実現するためには、テキスト側にも電子媒体にあわせた工夫が必要となります。紙媒体でのライティング習慣を電子媒体にそのまま持ち込んでも、読みやすさにはつながらないのです。「簡潔に！（ウェブの文章作法）」（Alertbox）のようなWebページ用ライティングの必要性は以前から訴えられていますが、具体例を元にしたWebページ用のライティングガイドラインがそろそろ必要なのかもしれません。
ちなみにこのサイトでは、以下のポイントを意識するようにしています。このくらいがテンポ的にも良さそうという判断なんですが、いかがでしょう？
つまり、「段落の持つ意味合いを紙媒体と電子媒体で分ける」ことこそ、Webページ上で読みやすいテキストを実現するための最重要ポイントではないか？ということです。段落の役割として（厳密な）意味のまとまりを伝えるよりも、読むためのまとまりやテンポを与える機能を重視することで、Webページの読みやすさは大きく改善されるのではないでしょうか。
「不合格翻訳に対し賠償請求？」（最近のJanさん。）経由で、「中国最新情報」（2003年12月16日発行分）という面白い記事を発見しました。どうも中国国内で、翻訳の国家規格を制定するとのことです。制作側からすると、翻訳精度の保証については、助かるような助からないような微妙なところ（謎）かもしれません。
ちなみに誤翻訳に伴う修正作業だけでなく、その後の回収／再配布などの費用負担まで請求対象になるんでしょうかね。あと適用対象についてですが、中国「で」翻訳する場合だけが問題となるのであれば、翻訳を中国の国外に逃がせば良いだけのようにも思えます。問題背景も含めて、気になる部分と謎の部分が錯綜しているので、詳しい情報が出てくるまで要観察ですね。
ところでこの「中国最新情報」中に
各種のエコマークが11月30日から統一され、国際標準化機構の制定、指導により、一般エコロジー商品の「ISO14020シリーズ」の実施が始まった。同時に、「非汚染」、「エコロジー」などの8種の流行語を製品や広告の中で使うことが禁止された。
（中略）
ISO14020国際標準規格では、8種の絶対使用禁止用語があり、製品の包装、説明書での使用を禁止している。具体的には環境に安全、環境にいい、地球に無害、汚染しない、エコロジー、自然にやさしい、オゾン層を破壊しないなどのいわゆる「持続可能」な表現を絶対使用禁止用語としている。
という、表記制限の話が出ていることが気になりました。
ISO14020シリーズについては完全にノーマークで、お恥ずかしい限りです。さくっと調べた感じでは、具体的なラベルは記載されていないものの、環境省の「ISOの環境ラベルに関する規格 」が参考になりそうです。
あと、この辺の表記制限ついでの話ですが、実は家電公正競争規約というものも存在します。要するに過剰表現をはじめとした、不適切な表現に対する制限の取り決めです。この辺の話はWeb制作をされている方でもご存知ない方が多いと思いますので、ぜひ一度チェックしておきましょう。
当研究所にも制作ツールの売り込みメールがときどき届くことがあるのですが、その多くは動的コンテンツ作成ツールだったりします。「操作過程を記録して動的コンテンツとして再現できる！」みたいな、オンラインチュートリアル用のオーサリングツール路線といえばわかりやすいでしょうか。
「電子マニュアル作成に最適！」とか銘打ってるんですが、こんな動的コンテンツ、マニュアルやヘルプとしては使い物になりませんよ。商品デモや一発目の花火だけで良いのなら話は別でしょうが、ユーザーの時間を拘束してしまう方法で情報を提供するなど、ありえません。ただでさえ必要な情報を得られずにイライラしているのに、そこで時間拘束などされた日には、もう。売り込む側もわかっててやってるんだと思いますけど、もしわかってないんだったら、すごく嫌な気分。ぷんすか。
ただ、動的コンテンツを積極的に使うべき場所もあります。
製品の使い方にしてもサービスの仕組みにしても、最近は説明対象が複雑になる一方で大変です。説明すべき対象そのものだけでなく、説明に必要な前提情報も複雑になっています。その結果として、入り組んでいる相互関係や、前提条件や時間の変化に依存する状態遷移などの、複雑な説明を要求されることが増えています。
で、このような場合にこそ動的コンテンツを用いるべきだと思うのです。時間軸上の状態遷移を伴った関係図を文章＆静止画だけで説明することは困難ですし、様々な軸から情報の関係を示したい場合でも、静止画を切り替えるよりも動的な視点変換の仕組みを用意した方がわかりやすいですからね。Webサイト上で提供される簡易シミュレーションも、この部類に含まれる有効な活用法だと思います。
まあ本当はマニュアルやヘルプなどの外部説明手段に頼るよりも、説明情報をUIに統合すること考えたら？とか思うんですけど。いずれにしても、動的コンテンツのご利用は計画的に（笑）
よくわからない機能や動作がある場合に、「わからないから説明を追加しましょう」ということはよくある話で、特にマニュアル制作では頻繁に目にする光景です。ですが、わかりやすさや使いやすさを実現する上で、「説明を追加することで問題を回避する」ことはあくまで暫定回避策に過ぎず、本質的な解決にはつながっていないことが忘れられがちです。
ユーザビリティに注目が集まるのは嬉しいのですが、どうもこの部分は勘違いされがちで、「説明すればわかりやすくなる、難しい機能も使ってもらえる」と安易に思い込んでいる人が多いようです。しかし実際のところ、紙媒体のマニュアルにせよ画面上に表示される各種情報にせよ、説明なんてちゃんと読んでくれる人の方が少ないんですよ（苦笑） これは説明することが仕事のマニュアル制作をしていると、嫌でも実感する大前提なんですけど。
したがって、説明を追加しなければならないことが判明した場合は、以下の順序で対策を考慮すべきです。
つまり、わかりやすさや使いやすさを実現するために基本とすべき考えかたとは、「説明がなくても理解できる・操作できる」仕組みを準備することなのです。さらに付け加えるならば、「ユーザーは説明を読まない」ことを前提とした、製品やシステム、周辺情報の提供枠組みの設計が必要とされるのです。
説明なしで済ませるように物事を設計することは困難な作業ですが、なぜ説明を必要とするのか？を把握できれば、あとは対策の取りようも出てくるものです。たとえ根本的な解決策に至らない場合でも、問題の検討を進めるうちに、説明量を大幅に削減できる回避策を思い付く可能性も十分にありえます。
そうは言っても、まったく新しい概念を伴うようなものについては何らかの概要説明は不可欠であることも事実です。土壇場で根本的な対策を取ることができない場合など、最終回避策として説明を追加することでお茶を濁さざるを得ない場面も存在するでしょう。そのようなこともあって無下に説明不要論を唱えるわけではありませんが、そこに説明が存在しなければならない必然性については、日頃からもっと考えるようにしたいものです。
アクセシビリティに注目が集まっている関係か、音声による情報提供が研究されるケースが増えているようです。もちろん本体よりも大きく重いマニュアルをなんとかしたい携帯電話や、安全上の問題からユーザーが紙面や画面をじっくり読む訳に行かない車載情報システムなど、音声による情報提供に注目せざるを得ない製品が増えつつあることも理由の1つでしょう。
さて音声で情報提供を行う場合ですが、ワンソースマルチユースで対応する場合と、専用コンテンツを用意する場合の2つのアプローチが考えられます。つまり、紙や電子媒体用の通常の文字表現テキストをそのまま利用するのか、それとも音声による情報伝達に最適化したコンテンツを別途用意するのか、ということです。また、すべての情報を音声で提供するのか、それとも音声による情報提供はポイントを絞って必要最小限にとどめ、製品やサービス全体の情報を（紙の冊子やWebサイトなどで）別途提供するのかによっても、音声コンテンツに求められる性質が変わってきます。
ただはっきりしているのは、特に高機能製品の取扱情報を提供するケースにおいて、ワンソース運用では音声情報としてまともに機能させるのは難しいということです。これは何故かというと、（紙にしろ電子にしろ）視覚表現を前提として設計した情報をそのまま流用しても、音声ではうまく機能しないからです。「alt属性の記述など各種アクセシビリティ対策をすることで、音声環境でも同等の使い勝手を提供できる」というような極論を目にしますが、とんでもない話です（もちろん何もしないよりは全然良いのですけれども）。
例えば、操作情報の枠組みは、見出しと導入文、操作文＋結果文のセット、サブ情報（ご注意＋ヒント）といった要素で構成されます。紙媒体では導入文内の概念説明が過剰だと感じた時点ですぐに飛ばし読みができますが、音声を聞いている場合はどうでしょう？ 音声では聞き飛ばし（斜め読み）がしにくいので、情報を必要最小限に絞り込む必要が出てきます。操作説明文であれば、実際の操作説明の前には、見出し（タスクのゴール）と見出しだけで説明しきれないタスクの補足情報、操作前に把握する必要のある重要な制約情報程度に限定する必要があるでしょう。概念説明や補足説明などの既存のマニュアルで重宝される情報に関しては、操作説明が終了したあとに必要に応じて参照できれば十分です。完全な情報を提供する機会を別途用意するのであれば、なおさらですね。
音声による情報提供で一番重要なのは、現在再生されているコンテンツは自分が必要としている情報なのか？を極めて初期の段階で把握できるようにすることです。これは視覚による情報提供では斜め読みで見当がつく場合が多いのに対して、音声ではある程度の量を聞いてみないと見当がつかないためです。ある程度の量を聞く＝それだけ時間がかかる訳ですから、この部分をしっかり意識する必要があります。お客様窓口電話番号に採用されることが多くなった自動応答システムで、自分が必要な情報がどれなのかわからなくなって途方に暮れた経験はありませんか？（この話、たぶん何かの機会に続きます）
世の中は論理思考ブームのようで、MECE（mutually exclusive, collectively exhaustive）つまり「互いに重ならず、すべてを網羅する」というキーワードを聞く機会が増えました。
そもそも論理思考がブームで良いのか？という話は置いておくとして、実はこれまでの紙媒体のマニュアル制作の基本精神とは、まさにこのMECEだったんですよね。つまりページ増を防ぐために情報は重複させずに、すべての機能説明や注意を網羅しなければならない、という訳です。経験を積んだマニュアル制作者が論理思考や情報の構造化に強いと言われる所以は、ここにあったのです（最近はこの能力の低下が目立ってきているようですが）。
なんですが、メーカーなどの情報の提供側からするとMECEで良くても、ユーザー側にはとんでもない話となります。これは当たり前の話で、情報が他の見出しと重複しているかどうかなんてユーザには関係ない訳で、とにかく直接必要な場所を見るだけですべて完結していて欲しいというのは当然の欲求ですよね。マニュアルではなく攻略本が評価されるのは、このような側面もあります。ここまではMECE的マニュアルのME部分の問題と言えるでしょう。
また、マニュアルが些末な情報まですべてカバーすることで、情報の伝達効率が低下するという問題もあります。以前取り上げたこともありましたが、操作の柔軟性という名目で複数の操作方法を提供しているような機器の場合、すべての場面ですべての方法を説明させようとするメーカーのなんと多いことか。結果として重要な情報が埋もれてしまうだけでなく、ユーザーの読む気を損なったり、さらには情報量増によるコスト増につながったりとロクなことがありません。これがMECE的マニュアルのCE部分の問題です。
さすがにこの辺の問題にはマニュアル制作者も気付き始めていますので、情報量の制約が少ない電子マニュアルでは、MEなんか無視してトピック内で情報完結するのが基本となっています（重複を避けてリンク参照なんて、誤操作を招くので愚の骨頂です）。紙マニュアルでも、導入編などの最優先で伝達効率が要求される領域に関しては、重複を厭わずに情報完結を狙うことが増えています（当研究所もこの方法で構成を組んだことがありますが、好評でした）。
しかし、CEの壁はまだまだ厚いのが現実です。追加した機能はすべて説明を入れたがる表面的なスペック重視も相変わらずですし、些末なユーザークレーム回避のための逃げ道という発想もなかなか減りません。最終的なユーザーの利益と伝達効率を考慮した上で、メーカーがユーザーに提供しなければならない「すべての機能の情報」とは一体なんだろう？ということをゼロベースで検討することなしに、この問題はおそらく解決しないでしょう。
論理思考の考えかたとしてのMECEはともかくとして、マニュアル制作の考えかたとしてはMECEはもう限界！というお話でした。
さてここのところ、文書コンサル関連の業務に携わることが多いのです。文書コンサルといってもそれほど大げさなものではなく、業務上必要とされる内容は十分網羅されているのかを実際の文書ベースで評価したり、記載情報の標準化や構造化を含めた業務文書開発のための枠組みづくりを支援したりというようなものです（ぼかした言い回しですが、業務直結系の話なんでご容赦ください）。SI系の会社からご依頼いただくこともある関係上、制作環境だけでなく文書システムに対する知識が要求されることも多いです。
この辺の業務に関してはマニュアル制作系のスキルを持った人材であれば十分対応可能だという感触はこれまでも持っていたのですが、まあ何とか対応できているようです（大汗）。ただ気になるのが、こうした業務を依頼してくださるお客様が口を揃えて「こういう仕事をできるところが少なくて . . . 」とお話になることです。どうも現場と開発／制作プロセスの両者をつなぐ役割を担当できる会社／人材が、少ないようなのです。マニュアル制作に携わっている人材にはこのような仕事はうってつけのはずなんですが、これは一体どうしたことでしょう？
上流／下流という言葉はあまり好きではありませんが、開発プロセスやメーカーのマニュアル制作部門などの上流で決定された事項を前提として無条件に受け入れ、その枠の中でマニュアル制作（文書開発）をすれば十分であると考えている人が多いようです。日々の業務から前提自体のあり方を問い直したり、前提の構築のされ方自体を改善したりしようという問題意識の持ち方は十分可能なはずですし、そのような問題意識なくして（品質の高い成果物の制作という）問題解決は得られないはずなんですが、う〜ん。いっとき「仕様書の読めないライター」が問題になったことがあるんですけど（今もですかね）、なんか問題の根底は共通のような気がします。まあこれも漠然とした、勘みたいなものなんですけど。
マニュアル制作の立場にいるとよく見えるのですが、一般消費者がインターネット接続に必要な設定をする際の意外な難関、それはプロバイダや通信機器メーカーによって用語がバラバラ、という奴なのです。例えばA社では「ダイヤルアップパスワード」、B社では「PPPパスワード」、C社では「接続パスワード」と同じ用語に異なった名称をつけています。同じものが様々な呼称を持っているのですから、サービスを利用するユーザーは混乱するばかりです。以前TC系のMLでこの問題が話題になったこともありましたが、解決策に向けての妙案がなかなか存在しないというのが頭の痛いところです。
簡単な解決策が存在しない理由としては、包括的な業界団体の不在がまずあげられます。事業領域の特性か、ネットワーク絡みのサービスや製品を巡っては、ベンチャー系や海外事業者の日本法人など様々な背景を持つ種々雑多なプレーヤーが市場に参加しています。そのため、事業者を包括して用語の統一を図ることのできる機能を持つ団体が存在しないように見受けられます。ある程度の統一がとれている用語でも、そういった用語選定が存在することを知らない（積み重ねがない）プレーヤーが、用語を混乱させている面もあるでしょう。市場の状況を踏まえないローカライズによる問題も大きいのではないかと思われます。
これだけでは後発参入組だけが悪く思えるかもしれませんが、先発の大手どころも責任はかなり大きいのです。大手どころの一番の問題は、他社模倣を良しとしない文化にあります。ほとんど同じなのに小手先だけ字面を変えるなど、変な部分で自社プライドを大事にする習慣です（知的財産権絡みで安易に模倣できないということもあります）。さらに、最近は機能名に対する商標申請など、悪い意味で用語を自社内へ囲い込む傾向が目立つように思えます。
サービスなり製品なりがスタンドアロンで使用されるものであれば、それでも良いでしょう。ですが、ネットワークなど様々な事業者が入り乱れて様々な製品やサービスを提供する領域であれば、わかりやすく適切な用語を積極的に共有するという文化が必要なのではないでしょうか。自社のプライドにこだわって難解であるという印象を消費者に与えるよりも、現状はまだまだ市場全体のわかりやすさを向上させるべき時期だと思うのです。特にこれからはホームネットワークだ、ユビキタスコンピューティングだとネットワークを利用したサービスが全盛を迎える訳ですから、一昔のAV製品レベルとまではいかなくとも、それなりのわかりやすさを市場全体で実現してほしいと切に願います。
そういう意味で、先日の「ルータベンダー4社『日本ホームゲートウェイ連絡会』発足へ」（BroadBand Watch）というニュースは、業界団体による用語統一の第一歩として期待したいところです。
交通エコロジー・モビリティ財団から、主に交通／観光／商業施設用にデザインされたピクトグラム（図記号）の標準案と、アウトラインデータ（Adobe Illustrator形式）が配布されています（詳しくは利用規程をご覧ください）。直接マニュアルに関係するものがあるわけではありませんが、禁止指示のための表現や人物の表現など、いろいろと参考になるものが多いのではないかと思います。また、このピクトグラムが想定するような施設では、Webサイトや各種パブリケーション、そして現実（リアル）の施設に使用するピクトグラムを統一することで、相乗効果を期待することもできるでしょう。
ピクトグラムにしろアイコンにしろ、最近は凝りすぎたものが多く、視認性という面で問題があるのでは？というものが増えているような気がします。視認性だけならともかく、これ何を意味してるのさ？というようなもののも増えています。要するにビジュアルとしての存在だけで、本来想定した機能を果たしていないわけです。
ビジュアル的なワンポイントであれば多少凝ったくらいでちょうど良いのかもしれませんが、最低限必要なコミュニケーションやナビゲーションのために用いるものであれば、今回配布されているようなシンプルで、かつわかりやすいデザインを参考にしてみるのも良いのではないでしょうか。そういう意味で、Webデザインに携わる方にも必見と言えるでしょう。
ところで、TCシンポジウム2001（主催：テクニカルコミュニケーター協会）のプログラムの暫定版が公開されているようです。関心のある方はぜひどうぞ。