「テクニカルコミュニケーション」記事の一覧
大手ECサイトでスマートフォン利用者によるアクセス数がPCユーザーのそれを超えたという話もあり、スマートフォンすなわち常時接続・携帯可能なデバイスの普及や実利用状況が閾値を超えたと言い切って良い状況になってきました。そうするとそろそろ各種取扱情報の電子媒体・配信への本格的移行...という話があちこちから出てきそうですが、その前にこの領域について自分が現段階で漠然と考えていることを、何のまとまりもなく、だらだらと書き出しておこうと思います（笑）
ということで、本年もよろしくお願い申し上げます。
スマートフォン本格普及を前提とした取扱情報の電子配信のありかた、コンテンツの見せかたについて一緒に研究したい！という方がいらっしゃいましたら、ぜひお声がけ頂ければ幸いです。
業界を問わず、志を同じくする方々と議論などしていると必ず出るネタの1つに、「TCを主戦場とする人間がWebサイトの「コンテンツ」に進出するべき」という話があります。似たような話はここでも何度も出しているので、長年のお客様にはお馴染みの話でしょうか。
「わかりやすく正確に」「ユーザーの立場で」情報を処理することが第一とされるTCを専門領域とする人間からすると、現状のWebコンテンツには以下のような問題があるように思えます。
で、この辺の問題をそろそろ何とかしたいのです。そして何とかできるのは、TC系の素養のある人間なればこそ、と思うのです。
なんとなく問題意識を持ってはいるものの「うまく問題点を言語化できない」「改善のための端緒としてどこから手を着ければよいのか悩んでいる」といった事業者さんやWeb屋さんがいらっしゃれば積極的に話を聞かせていただきたいですし、少しでも力になれるのであれば協働してお役に立ちたい。また、アプリの一般化に対して、ネットワーク上に展開する機能説明や操作説明、サポートコンテンツ（例：FAQやヘルプ）の整備が質的にも量的にも追いついていないのが実状と思われますが、この部分の悩みについても十分お役に立てるはずです。
ということで、決意表明とともに有限会社文書情報設計のサービスメニューに「Webコンテンツ作成支援」を追加いたしました。興味をお持ちになる方がいらっしゃいましたら、まずはお気軽にご連絡いただければ幸いです。「仕事としてはともかくとして、とりあえずこの辺の問題を肴に飲みたい」お誘いももちろん大歓迎です（笑）
気が付いたら今年一度も更新していないじゃないですか！ ということで、仕事が一段落したこともあり、最近考えていることをつらつらと書いてみます。
この数年「なんだかなあ...」と、いろいろと行き詰まりを感じることが正直なところ増えました。
そんなこんなで、正直なところ様々な点で目算が誤っていた、というか楽観的に過ぎた（笑）と認めざるを得ない感じですね。さーて、これからどうしましょうか。
まずは、お仕事絶賛大募集中です！大型小型、特定プロセスのスポット支援含め、ちょっとやらせてみようかな？という機会がありましたら、ぜひ声をお掛けください。制作案件だけでなく、既存の制作体制のままフォーマット改善（改善の前提となる現状品質評価）への外部支援や、まるでユーザーの方を向いていない商品／サービス説明が氾濫するWebコンテンツの改善など、ご協力できる・ご協力したい分野は無限にあるのです！（大事なことなので2度）
ちなみに「パッケージとして完結している」のである限り、（電子媒体であってもパッケージとして頭から終わりまでリニアに読むこともできる）EPUBやPDF形式でもOKで、別に紙媒体に拘っているわけではないのです。「全部読んだけどどこにも書いていない！」などのように、ユーザーが全体を確認できないような形で提供されるのはNG、という判断です。まあそれでも電子媒体閲覧の一手間を掛けさせるのを何とかしないと、ですね。
テクニカルコミュニケーション領域の教育ネタは時々火が付いたりするものの、公開ドキュメントが少なく議論が拡がらないという問題を抱えています。そこで今回は、2010年のTCシンポジウムで発表した「大学におけるTC教育事例と課題 〜制作現場における教育の観点から〜」の発表論文を、研究発表として公開しました。
「うちのところはこうやってるよ！」「この部分について詳しく聞きたい！」「ああ、その辺どこも苦労してるよねー」などご意見ご感想などありましたら、お気軽にお寄せください！というか、こういう議論を公開の場でやっていきたいんですよ。そうしないと、いつまで経っても知見が共有されないでジリ貧になる一方ですがな。
GW前後から抱えてきた大物案件が先月末でめでたく完了したこと、専修大学ネットワーク情報学部のマニュアルライティング講義も本年度分をめでたく完了したことで、少々脱力気味のこの頃です。厳しい暑さがようやく和らいできましたが、皆様いかがお過ごしでしょうか。
マニュアルの評価作業をしていて気付くのは、文章表現単体に問題を抱えるものは少なくなってきたものの、企画構成や視覚表現に問題を抱えているものが非常に多いということです。我が国のTC業界が狭義のライティングに重きを置きがちな以上、ある意味で当然の状況と言えるのかもしれません。
視覚表現については構造的な問題があるため、一朝一夕に解消することは確かに難しい面もありますが、問題は企画構成です。ユーザーの閲覧コンテクストを無視した情報構造や見出しタイトルの表現、記載内容の取捨選択といった問題が多く、ユーザーの閲覧コンテクストと情報の構成、記載内容に齟齬がないかどうかなど、基礎の基礎から再確認する必要がある有様です（参考：マニュアル評価フレームワーク）。論理一貫性だけに注力したわかりにくい構成ができあがるのは、制作者が閲覧コンテクストや製品の機能がユーザーに提供する価値を理解しようとせず、機能の表面的な実装形態や構造ばかりに着目していることに理由があります。わかりにくい見出しタイトルが一向に減らない原因も、ここにあると言えるでしょう。
機能が高度化・複雑化するにつれて、この悪循環は残念ながら強化される一方です。本来であれば、この種の問題は定期的なフォーマット見直しの際に手当てされるはずなのですが、ここ数年のコストダウン圧力に加えて人材への投資を怠ってきたことで、収拾が付かなくなっているように見えます。また、多国語展開における広義のコスト対策に目が行きすぎて、（多くの場合で）ベースとなっている日本語版の品質改善がおざなりになっているという側面も見逃せません。
でもそんな悪循環、そろそろ断ち切りませんか。景気回復の気運が高まりつつある現在こそ、必要なコストを掛けて品質を建て直す良い機会です。その際はぜひ、有限会社文書情報設計までお声がけください（案件大募集中！）というポジショントークは置いておくにしても、大規模会社への発注集約が進み、品質改善で力を発揮できる小規模制作会社が切り捨てられている現状は好ましくありません。品質評価を依頼したり改善プロジェクトに参画してもらうなどして、社内ノウハウの蓄積と品質改善を進め、マニュアルから製品全体のUX改善の一翼を担うべきでしょう。その際はぜひ（ｒｙ
マニュアル評価のためのガイドラインやチェックシートにもさまざまな種類がありますが、特に企画構成に関する部分が弱いものが多いようです。また、評価の前提が曖昧であるために、評価全体の信頼性について疑問符が付けられてしまうことも多々あります。
この現状に一石を投じるべく（？）有限会社文書情報設計がこれまで使用してきた評価のためのフレームワークを整理して、マニュアル評価にあたって押さえておくべき観点やチェックポイントのまとめとして、マニュアル評価フレームワーク（Ver.0.8 / 2013.4.8版）を公開します。ここではいわゆる取扱説明書・操作説明書の評価を対象としていますが、一般的な業務マニュアルに応用できる情報も多いかと思いますので、適宜ご活用ください。
現状では観点やチェックポイントを整理した状態ですので、各項目についての詳細解説などは追って（細々と）追加していく予定です。このフレームワークに対するコメントや追加すべきポイントの要望、そして評価業務のご依頼！などありましたら、お気軽にお寄せください。
いろいろ改修したいなあと長らく思ってきましたが、業務が落ち着いたこともあってこのタイミングでWebサイト全体をリニューアルしました。なんと9年振りです（苦笑）
ITバブル崩壊以降、テクニカルコミュニケーション領域では人材育成、技能伝承の問題が長期化しつつあります。この苦境の最中に発生したメーカー各社の業績悪化により、このままではメーカーの制作部門・制作会社の基盤だけでなく、我が国のテクニカルコミュニケーションの技能伝承土台までも崩壊しかねない状況です。
この状況改善の一助とすべく、今回のリニューアルにおいては以下のポイントを主眼としました。
現状の危機脱却にどこまで貢献できるかはわかりませんが、皆様頑張っていきましょう！
4ヶ月空いてしまいました...。昨年の【禁則事項】が嘘のように、猛烈な業務多忙が続いておりました。で、気が付いたら8月とな。
ということで、8/24から開催されるTCシンポジウムに参加します。今回は「大学におけるTC教育事例と課題」ということで、2007年度から担当させていただいている専修大学の「マニュアルライティング」講義についての事例発表となります。講義資料は毎年公開していますが（2007年度、2008年度、2009年度、2010年度）、講義の狙いや進行方法、学生の反応、反省点といった講義資料だけでは把握できない裏事情とあわせて、企業の制作現場における教育上の課題との共通点などについて触れたいと考えています。
発表資料は公開するかもしれませんが、公開不可のネタ（何）も発表中に触れる可能性がありますので、お時間に空きのある方は是非。「TC専門教育カリキュラム・ガイドライン」とあわせてご覧頂けると、職場に持ち帰ることのできるネタが増えるのではないかと勝手に想像しております。
2月頃まで忙しく、その後仕事環境の整理や事務所内のレイアウト変更、新規案件の準備その他いろいろ...としているうちに気が付いたら4月に（汗）twitterで遊びすぎました。
さて気を取り直して、何点か。
というわけで、新年度を迎えて気分一新、頑張っていきましょう！（...と自分に言い聞かせる）
本来であれば2ヶ月半前に公開予定だった研究発表「コンテクスト変換という幻想（DITAを巡る話題）」、ようやく公開です。TCシンポジウム前（それも東京開催前）に公開する予定だったのに、テキストエディタが落ちて編集中のデータが飛んだり様々な不調に祟られたり、ようやく...です。
TCシンポジウムやDESIGN IT!でDITA（Darwin Information Type Architecture）が話題になっていたようですが、反応を見る限りでは、相変わらず変な誤解が（特にWeb制作業界やSI業界に）あるようです。何らかの形で「シングルソース化」に携わった経験のある、TC系の人達の冷たい（または生暖かい）視線とは対照的なのが何だかなあ、という感じで（笑）
気になったのはこの辺の記事ですかねー。
良い機会なので、シングルソース化の限界と絡めてこれまで考えていたことをまとめてみました。以前のエントリ「情報大工的CMS導入のポイント」と同様、なんか実体験の反省が入っているとかいないとか...。ああ、やっぱり胸の奥が痛い。
ぼーっとしていたら、あっという間に10月が終わりそうに（汗）
TCシンポジウムの東京開催と京都開催、特別セッション「情報デザインの基礎 - コミュニケーションの全体像（テクニカルコミュニケーターが押さえるべき、情報設計の基本とプロセス）」にお越し頂き、ありがとうございました。アンケート集計結果を確認させていただいたところ、かなり好意的に評価していただけたようで何よりです。頑張って準備した甲斐がありました...。
セッション後の会話や懇親会でも少し話題になった（した）のですが、やはり教育の問題（特に上流プロセス）については課題感を持っている方が多いようです。Web情報アーキテクチャや情報デザインの世界では、標準教科書となり得る書籍が刊行（刊行準備）されている訳ですが、TC業界としてもその種の標準化および外部公開化をより強力に進めていくべきではないかと思います（現状の技術検定テキストにおける上流プロセスの扱いは、お話にならない位に弱いので）。
また、「既存フレームを超えた発想が出てこない」というOJTの限界も、話題にのぼったと記憶しています。この辺りは微修正→小規模改訂→大規模改訂→新案件、という順序を踏んでOJTを進めていく以上、仕方のない面があるかもしれません。そのためOJTと並行して、そもそもの筋論から考える訓練や、（自社が扱わない）別領域の事例を扱うことで客観視点を確保する訓練などを、意識して教育プログラムに入れ込んでいく必要があります。
この点については大学の講義設計で実感済なのですが、この種のトレーニング用事例を考えるのはかなり大変です。教育コストが切り詰められがちな時勢を踏まえても、TC協会が軸になり、この種の事例集積を進めていくことも今後必要になってくるのではないかと思います。会員が事例を持ち寄って、相互に使用可能な形でオープンに公開するといった形もその一例です。TC協会では大学教員の方を中心に標準の教育プログラムを策定していく意向があるようですので、協力できる部分では積極的に協力していきたいと考えています。
最後に少し宣伝タイムを。
昨今の不況の煽りを受け、弊社もいろいろ大変な状況になってきました。昨年が超多忙だった反動と不況のダブルパンチで、晩秋の寒さが身にしみます（汗） というわけで、現在お仕事大募集中です。新規案件は大大大歓迎ですが、ご時世的に厳しいと思いますので、社内勉強会の講師や改善プロジェクトのレビュアーなど、外部から制作品質を高めるためのお手伝いを中心にお役に立てればと思います。
ご興味を持たれる方がいらっしゃいましたら、有限会社 文書情報設計のWebサイトからお問い合わせ頂ければ幸いです。
また、新規の研究発表（DITAとか...）を現在準備中です。来月上旬には公開できるかと思いますので、お楽しみに。
前から書こうと思ってストックしていたネタだったのですが、多忙にかまけて失念していたことをDITA騒ぎの最中に思い出したという（汗）
えーと、CMSの導入が当然のような流れに世の中ではなっているようなのですが、遅まきながら気になることを書き連ねておきたいと思います。なんか実体験の反省が入っているとかいないとか...。ああ、胸の奥が痛い。
まあ、CMS屋さん的には当然のこととして行われている、当たり前の話ばかりですよね。ですよね？？？というのは、「"DITA"と"CMS"- DESIGN IT! Forum 2009 参加レポート」を読んで、何とも言えない不安感に襲われたからなんですけど（汗）
やはり上記のポイントのうち、最後の項目については忘れられていることが多いようですね。そもそも部品粒度を下げること（＝情報の枠組を詳細に作り込むこと）の効果は、部品（情報）単位での抜け・漏れおよび部品内の記載内容のブレの防止、による品質向上にあると思うんですよね。で、その辺をサポートできる存在という意味で、CMS屋さんはドキュメント屋さんと組むといろいろと良いことがありそうなものなんですが、いかがでしょう（笑）
梅雨真っ盛りで微妙に過ごしにくい日々が続きますが、いかがお過ごしでしょうか。これまでの疲れが抜けず、テンションが上がらない今日この頃です...。
さて表題の通り、本年も縁あってTCシンポジウムに出し物をする側で参加させていただくことになりました。特別セッション「情報デザインの基礎 - コミュニケーションの全体像（テクニカルコミュニケーターが押さえるべき、情報設計の基本とプロセス）」です。昨年の内容をほぼ踏襲になりますが、（そういう依頼だったこともあり）対象領域を欲張ってフォーカスが甘くなっていた昨年の反省を活かし、よりテクニカルコミュニケーション領域にフォーカスを絞った形を予定しています。
この種の機会では「いつも同じ、当たり前の基本的なこと」しか言わないのですが、それなりによく整理されているという評価は頂いておりますので、入門用＆自己認識の整理用、または社内研修のネタ用としてご活用いただければ幸いです。なお、本年は東京だけでなく京都でも同一セッション開催の運びになりましたので、関西圏の方にお会いできるのも楽しみです。
ところでセッション案内でも書いている通り、
しかしテクニカルコミュニケーションの領域においては、特に情報設計の面で企画構成プロセスにおいて実行すべきことが明確化されていないのが現状である。情報設計という視点自体もテキストや画像などの最終的な表現技法よりも伝統的に軽視されており、教育・研修も充実しているとは言い難い。
という面に関しては、かなり憂慮しています。
TCシンポジウムでも人材教育系の話は毎年のように出ていますが、この辺についてはどうなのかな？と。マニュアル制作業界では（メーカー・制作会社問わず）OJTとして既存製品の小規模改訂やマイナーバージョンアップ製品から担当させることが常かと思いますが、実はここが「木を見て森を見ず」「仕様書が読めない」「構成案を作成できない」人材ばかりになりがちの諸悪の根源ではないか？と最近感じるようになりました。つまり「良いマニュアルとはどんなものか？」であるとか「企画構成で何をやるべきか？」というしっかりとした基本教育なしに、小手先の技巧の巧拙に走っているせいもあるのではないか？ということです。
人材教育の問題については最近の若者の特性ということに注目が集まりがちですが、この種の問題は十年ほど前から状況がまったく変わっていないことにも留意する必要があると考えます。シンポジウム後の懇親会（開催されれば、ですが）には東京・京都開催分両方に顔を出したいと思いますので、この辺についてご意見がありましたら、ぜひその際にでもお聞かせいただければと。もちろんメールいただいたり、このエントリにコメント付けていただく形でも結構ですよー。
「業務システムのためのユーザーマニュアル作成ガイド」なる書籍が発行されたとのことで、その辺について思うところを入手前（笑）に書いておこうと思います。
業務システムのマニュアルにおける一番重要なポイントは、画面単位ではなく、業務単位で説明することです（例：「顧客情報登録／修正」という画面があるとして、「顧客情報登録／修正」という画面単位ではなく、「顧客情報を登録する」「顧客情報を修正する」という業務単位で見出しを用意する）。業務システムでは単一画面で特定業務が完結するように設計されることが多いと思いますが、当該画面への遷移方法は利用組織・業務依存で異なることが常ですので（コンテクスト依存）、業務単位で説明した方がユーザーにとってわかりやすいのです。業務システムのマニュアルは、システム開発を担当したSIerが画面単位の外部仕様書を流用して作成することが多いと思いますが、この点に注意が必要です。
また、担当者が入れ替わりながら保守管理をしていくことを考慮すれば、特殊な制作ソフトウェアやデータ形式、極端に凝ったレイアウトを採用しない、ということもお約束に含まれます。（長期間にわたる保守管理を前提としない、ある意味使い捨ての）わかりにくい特定業務だけの簡易解説シートのようなものであれば凝りに凝ったPowerPointスライドでも良いでしょうが、ある程度ボリュームがあるマニュアルであるならば、素直にWordで作成した方が保守管理の面で得策といえます。
忘れられがちな観点として、業務マニュアルとの兼ね合いをどうするのか？という極めて重要なポイントもあります。業務システムのマニュアル（操作マニュアル）と業務マニュアルとの間の線を何処に引くのか、両者のバランスをどう取るのかの判断は非常に悩ましく、「これが正解」というものはありません。例えば先の顧客情報登録の際に、備考として自由記入フィールドが用意されているとしましょう。このフィールドに入力すべき情報の内容や入力に当たっての留意点は、業務システムのマニュアルと業務マニュアルのどちらに記載すべきでしょうか？まあ、この例の場合は第三の選択肢である「UI側でカバーしちゃえ」（フィールド初期値として文字列を表示するなど）というのが正解っぽいですけど（笑）
ちなみにユーザーが単一マニュアルを見るだけで情報入手を完結できることを最優先とするならば、業務システムのマニュアルと業務マニュアルを分割することはナンセンスです。ただこの場合、業務改善や業務システムの改修の影響がマニュアルに与える影響（保守管理コスト）が極めて大きくなります。先のTCシンポジウムでも指摘された通り、業務マニュアルは長く使われる性質を持ちますので、変更があることを前提に変更の影響を局限化できるような設計をはじめから意識する必要があります。その意味で、ユーザーの利益のために単一マニュアルの本文中にすべてを記載するという判断は、運用する側にかなりの負荷を要求することになります。極端な例を挙げてみましょう。
このように、業務システムのマニュアルと業務マニュアルを単純に統合しようとすると、情報量の増大によりマニュアルとしての機能が低下するだけでなく、業務の中核フローが変更されなくとも末端の運用基準が変更になっただけで大元の業務マニュアルの修正が必要になるなど、管理負荷が過大になるということに注意が必要です。業務マニュアルの設計に当たってメンテナンス性が重視されるというのはこういうことで、制作ソフトウェアやデータの作りかただけの問題ではないのです。全社対象の業務マニュアルや各種の規定書、部門単位の業務マニュアルとの間の兼ね合いといった頭痛のタネも、この種の問題に積み重なってきます。
で、メンテナンス性とユーザーニーズをどうバランスさせるかが問題なのですが...。この問題は本来、業務システムの設計段階で、十分検討される必要があるはずです（先の例のようにUI側でカバーできないか検討するなど）。ですが、どうしてもマニュアル系については「ヘルプ付ければいいや」「業務マニュアルに書くから」で片付けられがちで、なかなか上流側で意識すべき問題として取り上げられないのが実情でしょう。別に業務マニュアル制作をマニュアル制作会社に完全外注せずとも、業務改善検討や業務システム設計の段階で、ドキュメンテーションに長けた人材を参加させるようにすれば解決していく問題だとは思うのですが、問題周知も含めて先は長そうです...。
あまりの業務多忙に更新が滞りまくっている最近です...。昨年夏頃から連休すら取れないのはいかがなものかと思わなくもないのですが、想定が何もかも裏目に出てしまう異常事態が続いたので、仕方がないと泣きながら頑張っている今日この頃でございます。あ、話半分で聞いておいてくださいね（笑）
というわけで直前告知で申し訳ありませんが、今週開催されるTCシンポジウムに出し物をする側で参加させていただくことになりました。
という訳で、当日はよろしくお願いいたします。あ、ちなみにパネルディスカッションの方は京都開催（10/10）でもやることになっています。TCシンポジウムは出し物側として何度か参加させていただいていますが、関西遠征は初めてなので新鮮です。
地デジ対応に合わせてJCOMのSTBを変更したらUIが最悪でTVを見る以前に電源を入れることすら減って放送・家電業界は自分で自分の首を絞めているのではないだろうかとか通常のネタもいろいろあるのですが、いつも各種提出物を待っていただいている状況でそんなネタを展開できるはずもなく。とにかく来月下旬まで頑張りきれば一段落するはずですので、更新再開はその辺りまでお待ちくださるようお願いいたします...。
本格的な業務多忙で沈没しており、来月末まではちょっと身動き取れなさそうです。こちらも放置気味で申し訳ございません。さすがに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（主催：テクニカルコミュニケーター協会）のプログラムの暫定版が公開されているようです。関心のある方はぜひどうぞ。
情報大工のひとりごと