「マニュアル制作」記事の一覧
大手ECサイトでスマートフォン利用者によるアクセス数がPCユーザーのそれを超えたという話もあり、スマートフォンすなわち常時接続・携帯可能なデバイスの普及や実利用状況が閾値を超えたと言い切って良い状況になってきました。そうするとそろそろ各種取扱情報の電子媒体・配信への本格的移行...という話があちこちから出てきそうですが、その前にこの領域について自分が現段階で漠然と考えていることを、何のまとまりもなく、だらだらと書き出しておこうと思います（笑）
ということで、本年もよろしくお願い申し上げます。
スマートフォン本格普及を前提とした取扱情報の電子配信のありかた、コンテンツの見せかたについて一緒に研究したい！という方がいらっしゃいましたら、ぜひお声がけ頂ければ幸いです。
マニュアルの評価作業をしていて気付くのは、文章表現単体に問題を抱えるものは少なくなってきたものの、企画構成や視覚表現に問題を抱えているものが非常に多いということです。我が国のTC業界が狭義のライティングに重きを置きがちな以上、ある意味で当然の状況と言えるのかもしれません。
視覚表現については構造的な問題があるため、一朝一夕に解消することは確かに難しい面もありますが、問題は企画構成です。ユーザーの閲覧コンテクストを無視した情報構造や見出しタイトルの表現、記載内容の取捨選択といった問題が多く、ユーザーの閲覧コンテクストと情報の構成、記載内容に齟齬がないかどうかなど、基礎の基礎から再確認する必要がある有様です（参考：マニュアル評価フレームワーク）。論理一貫性だけに注力したわかりにくい構成ができあがるのは、制作者が閲覧コンテクストや製品の機能がユーザーに提供する価値を理解しようとせず、機能の表面的な実装形態や構造ばかりに着目していることに理由があります。わかりにくい見出しタイトルが一向に減らない原因も、ここにあると言えるでしょう。
機能が高度化・複雑化するにつれて、この悪循環は残念ながら強化される一方です。本来であれば、この種の問題は定期的なフォーマット見直しの際に手当てされるはずなのですが、ここ数年のコストダウン圧力に加えて人材への投資を怠ってきたことで、収拾が付かなくなっているように見えます。また、多国語展開における広義のコスト対策に目が行きすぎて、（多くの場合で）ベースとなっている日本語版の品質改善がおざなりになっているという側面も見逃せません。
でもそんな悪循環、そろそろ断ち切りませんか。景気回復の気運が高まりつつある現在こそ、必要なコストを掛けて品質を建て直す良い機会です。その際はぜひ、有限会社文書情報設計までお声がけください（案件大募集中！）というポジショントークは置いておくにしても、大規模会社への発注集約が進み、品質改善で力を発揮できる小規模制作会社が切り捨てられている現状は好ましくありません。品質評価を依頼したり改善プロジェクトに参画してもらうなどして、社内ノウハウの蓄積と品質改善を進め、マニュアルから製品全体のUX改善の一翼を担うべきでしょう。その際はぜひ（ｒｙ
マニュアル評価のためのガイドラインやチェックシートにもさまざまな種類がありますが、特に企画構成に関する部分が弱いものが多いようです。また、評価の前提が曖昧であるために、評価全体の信頼性について疑問符が付けられてしまうことも多々あります。
この現状に一石を投じるべく（？）有限会社文書情報設計がこれまで使用してきた評価のためのフレームワークを整理して、マニュアル評価にあたって押さえておくべき観点やチェックポイントのまとめとして、マニュアル評価フレームワーク（Ver.0.8 / 2013.4.8版）を公開します。ここではいわゆる取扱説明書・操作説明書の評価を対象としていますが、一般的な業務マニュアルに応用できる情報も多いかと思いますので、適宜ご活用ください。
現状では観点やチェックポイントを整理した状態ですので、各項目についての詳細解説などは追って（細々と）追加していく予定です。このフレームワークに対するコメントや追加すべきポイントの要望、そして評価業務のご依頼！などありましたら、お気軽にお寄せください。
例えばAという機能の説明を作成する必要があるとしましょう。そのためにまず必要なのは、形として表れてくるUIの外部仕様を知ることではなく、機能全体を理解すること、そして機能訴求ポイントや訴求方針を押さえることです。そういった面を全部想像してライティングするよりも、当該設計／実装に至った経緯を記した検討資料や各種仕様書（いわゆる「ドキュメント」）を入手して、エンドユーザー向けにコンテクスト変換した上でブラッシュアップ、必要に合わせて不足情報の追加というフローで作業した方が、正確で重要なポイントを押さえた成果物につながるわけです。それも効率良く。
なのですが、どうもこのドキュメントを要求する行為を甘えと取る人がそれなりにいるようで、なんだかなあという感じです。資料開示すればすぐに問題が解決するにも関わらず、どうして開示を嫌がって原稿作成工程に無用の負荷を掛けたがるのか、理由がまったく謎です。新規テキストをスクラッチでイチから起こすことと、エンドユーザーの利益（ひいては製品やサービスの提供側の利益）と、重要なのはどちらでしょうか。いろいろ見聞きしている範囲ではありますが、何を優先するべきか？の判断基準がズレてきてるなあ...と感じることが増えた今日この頃です。
この種の問題のありがちな原因として、開示できるレベルのドキュメントを残していない（から開示できない）というのであれば、それはそれで大問題ですよね。開発＆コアグループだけで検討や情報共有が完結するならば、整理されたドキュメントなしでも（当座は）良いのでしょうが、デザインにせよテキストにせよ、あとから外部発注作業を入れることが前提であるならば、絶対に何らかのドキュメントを残す必要があります。それに運用フェーズや人事異動でメンバー変動が発生することを考慮に入れれば、「開発＆コアグループだけだからドキュメントは不要」という弁解が通るはずがないのは自明だと思うのですがね。
ところで、エンドユーザー向け外部説明（各種ガイドやヘルプ、FAQ）の構成検討は、製品・サービス仕様検討と並行して進めるべきというのは、一体いつになったら一般化するんでしょう。仕様検討の段階で「これは仕様で対応、これはUI上のテキストラベル他で対応、これはヘルプなど外部説明で対応」のようにしっかり考えておかないと、最後になって「マニュアル（ヘルプ）に書いておけばいいや」のお約束が発動することになります。エンドユーザー向けのFAQを検討するなかで、仕様検討から漏れている観点も拾うことができるという効用も、いまいち理解されていないようです。ただコストダウン圧力の余波で最近はお疲れ気味とはいえ、メーカー系はなんだかんだでまだしっかりしてる印象です。Web屋さんはHCDとか言うのであればもっと頑（ｒｙ
ということで、「ドキュメント出して」「ドキュメント作って」「ドキュメント観点も大事」というまとまりがないようなあるような怪しい三本立て（何）でお送りしました。
リーマンショックは何とか耐えたものの、震災以降の不況（＆何ら対策がなされないままの円高）もあり、今年度は弊社もかなり大変な状況です。大型案件コンペ→2ヶ月放置→提案評価されつつ価格負けなど体験すると、営業的にもモチベーション的にも厳しいものがありますね...。放置されてる間は営業活動できないわけですし（受注できてコンペに勝つと、リソース不足で結局ご迷惑をお掛けすることに）。
ある程度の規模の企業が大幅安の費用で受注するというのは（弊社は相場平均〜やや安い）、事業継続性の面で問題があるだけでなく業界自体の衰退の原因となる（若手を雇用して育成する余裕がなくなる）上に、将来的な不況明けがあった場合でも当時の単価がベースとなってしまうので、本当に勘弁して欲しいです。ダンピングして荒らすくらいなら、さっさと退場して欲しいですね。もちろん当該企業がそれで適正な利益を上げていて、社員にも還元できているというのであればまったく問題はありませんが。
また別の側面として、メーカーの外注に対する甘えも気になります。以前はメーカー内の担当者の方が高スキルという前提があり、ローコストの外注を適切に指導することで品質を改善しつつ制作費の低減を...という建前も機能していましたが、すでに前提が成立していません。制作会社が新人を育成できない程度の費用しかメーカーが認めない状態が長く続けば、制作会社で制作を担当している中堅社員が高齢化して制作能力を失った場合、マニュアル外注体制自体が崩壊することになります（弊社と取引頂いているメーカー様は、その点に理解があるのが幸いです...）。
というわけで、現在お仕事大募集中です。新規案件は大・大・大歓迎ですが、ご時世的に厳しいと思いますので、社内勉強会の講師や改善プロジェクトのレビュアー、マニュアルの評価など、外部から制作品質を高めるためのお手伝いなどを中心にお役に立てればと思います。また、大きな案件の特定プロセス部分の制作のお手伝いや、Webサイト制作業界からのご依頼も大歓迎です。ご興味を持たれる方がいらっしゃいましたら、有限会社 文書情報設計のWebサイトからお問い合わせ頂ければ幸いです。
いろいろ改修したいなあと長らく思ってきましたが、業務が落ち着いたこともあってこのタイミングでWebサイト全体をリニューアルしました。なんと9年振りです（苦笑）
ITバブル崩壊以降、テクニカルコミュニケーション領域では人材育成、技能伝承の問題が長期化しつつあります。この苦境の最中に発生したメーカー各社の業績悪化により、このままではメーカーの制作部門・制作会社の基盤だけでなく、我が国のテクニカルコミュニケーションの技能伝承土台までも崩壊しかねない状況です。
この状況改善の一助とすべく、今回のリニューアルにおいては以下のポイントを主眼としました。
現状の危機脱却にどこまで貢献できるかはわかりませんが、皆様頑張っていきましょう！
4ヶ月空いてしまいました...。昨年の【禁則事項】が嘘のように、猛烈な業務多忙が続いておりました。で、気が付いたら8月とな。
ということで、8/24から開催されるTCシンポジウムに参加します。今回は「大学におけるTC教育事例と課題」ということで、2007年度から担当させていただいている専修大学の「マニュアルライティング」講義についての事例発表となります。講義資料は毎年公開していますが（2007年度、2008年度、2009年度、2010年度）、講義の狙いや進行方法、学生の反応、反省点といった講義資料だけでは把握できない裏事情とあわせて、企業の制作現場における教育上の課題との共通点などについて触れたいと考えています。
発表資料は公開するかもしれませんが、公開不可のネタ（何）も発表中に触れる可能性がありますので、お時間に空きのある方は是非。「TC専門教育カリキュラム・ガイドライン」とあわせてご覧頂けると、職場に持ち帰ることのできるネタが増えるのではないかと勝手に想像しております。
本来であれば2ヶ月半前に公開予定だった研究発表「コンテクスト変換という幻想（DITAを巡る話題）」、ようやく公開です。TCシンポジウム前（それも東京開催前）に公開する予定だったのに、テキストエディタが落ちて編集中のデータが飛んだり様々な不調に祟られたり、ようやく...です。
TCシンポジウムやDESIGN IT!でDITA（Darwin Information Type Architecture）が話題になっていたようですが、反応を見る限りでは、相変わらず変な誤解が（特にWeb制作業界やSI業界に）あるようです。何らかの形で「シングルソース化」に携わった経験のある、TC系の人達の冷たい（または生暖かい）視線とは対照的なのが何だかなあ、という感じで（笑）
気になったのはこの辺の記事ですかねー。
良い機会なので、シングルソース化の限界と絡めてこれまで考えていたことをまとめてみました。以前のエントリ「情報大工的CMS導入のポイント」と同様、なんか実体験の反省が入っているとかいないとか...。ああ、やっぱり胸の奥が痛い。
梅雨真っ盛りで微妙に過ごしにくい日々が続きますが、いかがお過ごしでしょうか。これまでの疲れが抜けず、テンションが上がらない今日この頃です...。
さて表題の通り、本年も縁あってTCシンポジウムに出し物をする側で参加させていただくことになりました。特別セッション「情報デザインの基礎 - コミュニケーションの全体像（テクニカルコミュニケーターが押さえるべき、情報設計の基本とプロセス）」です。昨年の内容をほぼ踏襲になりますが、（そういう依頼だったこともあり）対象領域を欲張ってフォーカスが甘くなっていた昨年の反省を活かし、よりテクニカルコミュニケーション領域にフォーカスを絞った形を予定しています。
この種の機会では「いつも同じ、当たり前の基本的なこと」しか言わないのですが、それなりによく整理されているという評価は頂いておりますので、入門用＆自己認識の整理用、または社内研修のネタ用としてご活用いただければ幸いです。なお、本年は東京だけでなく京都でも同一セッション開催の運びになりましたので、関西圏の方にお会いできるのも楽しみです。
ところでセッション案内でも書いている通り、
しかしテクニカルコミュニケーションの領域においては、特に情報設計の面で企画構成プロセスにおいて実行すべきことが明確化されていないのが現状である。情報設計という視点自体もテキストや画像などの最終的な表現技法よりも伝統的に軽視されており、教育・研修も充実しているとは言い難い。
という面に関しては、かなり憂慮しています。
TCシンポジウムでも人材教育系の話は毎年のように出ていますが、この辺についてはどうなのかな？と。マニュアル制作業界では（メーカー・制作会社問わず）OJTとして既存製品の小規模改訂やマイナーバージョンアップ製品から担当させることが常かと思いますが、実はここが「木を見て森を見ず」「仕様書が読めない」「構成案を作成できない」人材ばかりになりがちの諸悪の根源ではないか？と最近感じるようになりました。つまり「良いマニュアルとはどんなものか？」であるとか「企画構成で何をやるべきか？」というしっかりとした基本教育なしに、小手先の技巧の巧拙に走っているせいもあるのではないか？ということです。
人材教育の問題については最近の若者の特性ということに注目が集まりがちですが、この種の問題は十年ほど前から状況がまったく変わっていないことにも留意する必要があると考えます。シンポジウム後の懇親会（開催されれば、ですが）には東京・京都開催分両方に顔を出したいと思いますので、この辺についてご意見がありましたら、ぜひその際にでもお聞かせいただければと。もちろんメールいただいたり、このエントリにコメント付けていただく形でも結構ですよー。
「業務システムのためのユーザーマニュアル作成ガイド」なる書籍が発行されたとのことで、その辺について思うところを入手前（笑）に書いておこうと思います。
業務システムのマニュアルにおける一番重要なポイントは、画面単位ではなく、業務単位で説明することです（例：「顧客情報登録／修正」という画面があるとして、「顧客情報登録／修正」という画面単位ではなく、「顧客情報を登録する」「顧客情報を修正する」という業務単位で見出しを用意する）。業務システムでは単一画面で特定業務が完結するように設計されることが多いと思いますが、当該画面への遷移方法は利用組織・業務依存で異なることが常ですので（コンテクスト依存）、業務単位で説明した方がユーザーにとってわかりやすいのです。業務システムのマニュアルは、システム開発を担当したSIerが画面単位の外部仕様書を流用して作成することが多いと思いますが、この点に注意が必要です。
また、担当者が入れ替わりながら保守管理をしていくことを考慮すれば、特殊な制作ソフトウェアやデータ形式、極端に凝ったレイアウトを採用しない、ということもお約束に含まれます。（長期間にわたる保守管理を前提としない、ある意味使い捨ての）わかりにくい特定業務だけの簡易解説シートのようなものであれば凝りに凝ったPowerPointスライドでも良いでしょうが、ある程度ボリュームがあるマニュアルであるならば、素直にWordで作成した方が保守管理の面で得策といえます。
忘れられがちな観点として、業務マニュアルとの兼ね合いをどうするのか？という極めて重要なポイントもあります。業務システムのマニュアル（操作マニュアル）と業務マニュアルとの間の線を何処に引くのか、両者のバランスをどう取るのかの判断は非常に悩ましく、「これが正解」というものはありません。例えば先の顧客情報登録の際に、備考として自由記入フィールドが用意されているとしましょう。このフィールドに入力すべき情報の内容や入力に当たっての留意点は、業務システムのマニュアルと業務マニュアルのどちらに記載すべきでしょうか？まあ、この例の場合は第三の選択肢である「UI側でカバーしちゃえ」（フィールド初期値として文字列を表示するなど）というのが正解っぽいですけど（笑）
ちなみにユーザーが単一マニュアルを見るだけで情報入手を完結できることを最優先とするならば、業務システムのマニュアルと業務マニュアルを分割することはナンセンスです。ただこの場合、業務改善や業務システムの改修の影響がマニュアルに与える影響（保守管理コスト）が極めて大きくなります。先のTCシンポジウムでも指摘された通り、業務マニュアルは長く使われる性質を持ちますので、変更があることを前提に変更の影響を局限化できるような設計をはじめから意識する必要があります。その意味で、ユーザーの利益のために単一マニュアルの本文中にすべてを記載するという判断は、運用する側にかなりの負荷を要求することになります。極端な例を挙げてみましょう。
このように、業務システムのマニュアルと業務マニュアルを単純に統合しようとすると、情報量の増大によりマニュアルとしての機能が低下するだけでなく、業務の中核フローが変更されなくとも末端の運用基準が変更になっただけで大元の業務マニュアルの修正が必要になるなど、管理負荷が過大になるということに注意が必要です。業務マニュアルの設計に当たってメンテナンス性が重視されるというのはこういうことで、制作ソフトウェアやデータの作りかただけの問題ではないのです。全社対象の業務マニュアルや各種の規定書、部門単位の業務マニュアルとの間の兼ね合いといった頭痛のタネも、この種の問題に積み重なってきます。
で、メンテナンス性とユーザーニーズをどうバランスさせるかが問題なのですが...。この問題は本来、業務システムの設計段階で、十分検討される必要があるはずです（先の例のようにUI側でカバーできないか検討するなど）。ですが、どうしてもマニュアル系については「ヘルプ付ければいいや」「業務マニュアルに書くから」で片付けられがちで、なかなか上流側で意識すべき問題として取り上げられないのが実情でしょう。別に業務マニュアル制作をマニュアル制作会社に完全外注せずとも、業務改善検討や業務システム設計の段階で、ドキュメンテーションに長けた人材を参加させるようにすれば解決していく問題だとは思うのですが、問題周知も含めて先は長そうです...。
本格的な業務多忙で沈没しており、来月末まではちょっと身動き取れなさそうです。こちらも放置気味で申し訳ございません。さすがに3ヶ月放置はまずいので、前のエントリでネタを振ったTCシンポジウムの感想などを...（いくら何でも遅過ぎ）。
強烈な暑さの続く今日この頃ですが、いかがお過ごしでしょうか。暑さで体調など崩されませぬようご自愛ください。
このWebサイトは1996年の8月の開設ですので、実は11周年ということになります。昨年は10周年記念企画をやろうかと思っていたんですが、バタバタしていたり諸事情でなしのつぶてに...。開設した頃と比較して変わったこと、変わらなかったことなど、そのうちちゃんとまとめたいですね。12年目に突入しつつも、これまで通り細く長く（笑）続けていきたいと考えておりますので、思い出した頃にでも再訪して頂ければ幸いです。
テクニカルコミュニケーター協会の広報誌「TC協会ニュース」（第77号）（PDFファイル）で、「日本版SOX法の施行を睨み、業務マニュアル分野への対応拡大、支援を考えるべきでは」という趣旨の話が協会理事の方へのインタビュー記事にありました。このコーナーの以前の記事でも触れましたが、ようやくこういう話が出てきたか...という感じです。
でも正直なところ、現状のマニュアル制作者に要求されるスキルセットでは無理でしょう。というのは、業務マニュアル制作においてもっとも必要とされるであろうスキルが、現状のマニュアル制作では重視されていないからです（本当は必要不可欠のはずなんですが）。
業務マニュアルを制作する必要が出てくるケースとしては、以下の3つのケースが大部分ではないかと思います。
上記いずれの場合であっても、わかりやすいマニュアルとして情報をまとめる視点だけでなく、業務プロセスに問題（漏れや潜在リスクなど）がないかどうかをチェックするという視点が必要、ということに注意する必要があります。特に後者の視点が重要で、業務マニュアル作成という業務は、業務プロセスのコンサルティングの領域に一部踏み込む必要があるのです（ここでマニュアル制作者ならではの独自視点をどう活かすのか？が、コンサル屋さんとの差別化になるはずなのですが...）。
これは操作マニュアル制作において、仕様書を読解してユーザビリティの問題を指摘する（さらには改善案を提示する）ことと同義であり、現状のマニュアル制作者のスキルでは対応が難しいでしょう。主な活動領域である操作マニュアル制作においてさえできない（重要視されていない）ことを、業務マニュアル制作の領域でできるはずがありません。業務マニュアル制作に乗り出すためには、操作マニュアル制作に要求されるスキルセットから見直す必要が出てくるはずです。
当該記事中の会社は親会社がSIerということもあり、上流工程で業務が正規化された後で業務マニュアルの制作開始、というケースが多いのではないかと思われます。このようなケースでは、仕様書をベースに操作マニュアルを制作することとプロセスとしてはそれほど変わらないでしょうから、さほど大きな問題はなさそうです。ただ、それが本当に業務マニュアル制作という仕事なのか？というと、何かちょっと違うような気がするんですよね。
昨年「『メーカーの品格』は取扱説明書を見ればわかる！」なるニッチな記事を掲載した小学館のDIME ですが、またやってくれました。最新号（2007年11号（5/22発売号）では「いよいよ買い時の新『ビスタパソコン』 − 07年夏モデルはメーカーによってこんなに違う − 『親切コンシェルジェ機能』で選べ!!」というこれまた微妙な路線の記事が。最新のPCにプリインストールされている各種操作支援コンテンツの機能紹介という、何ともまあマニアックなことで（笑）
個人的にはこの種のコンテンツにおけるアニメーションやら動画やらといった演出は嫌いなので、正直「う〜ん」という感じなのですが、メーカー的にはどうなんでしょうね。とりあえず
という辺りについては、どう考えているのか非常に気になります。まあNECと富士通については、たとえ実効性に疑問を持っていたとしても、お互いに引くに引けない状態になっているんじゃないか...と意地の悪い見方をしていたりもするんですが（笑）
操作支援コンテンツというものは、ユーザーの問題を解決してはじめて意味があるものです。もちろんユーザーの問題というのはトラブルだけでなく、自分の目的を達成できないという状況も含まれます。そのためには市場における当該製品の位置づけや時代の変遷なども考慮に入れて、コンテキストをしっかり押さえる必要があります。動画マニュアルが変にもてはやされていることもそうなんですが、何か本質的な部分が置き去りにされているんじゃないかなあ、と心配になりがちな今日この頃です（動画マニュアルについては、以前書いたことがありますが、スタンスは変わっていません）。
まあ何にせよ、記事として取り上げられることで、こうした努力や問題に少しでも陽が当たるのは嬉しいものです。今後もDIMEに期待！というところでしょうか。HDDレコーダーのUI徹底比較とかやって欲しいなあ...。
早くも月刊化を回避するので精一杯の有様です（汗）
講義期間はそっちで使用するネタを考えるのに頭が回ってしまい、どうしてもblogの更新が途絶えがちになりますね...。突っ込みネタとかをやると簡単なんでしょうけど、どうしてもネガティブ方向に振れがちになりますからね。マニュアル制作に関する講義で何を教えるべきか？という講義関連の話題については、そのうち考察記事をしっかり起こして問題意識の共有などできればと考えています。
というわけで、今度はあまり更新頻度が空かないように努力いたします...。
細かいバタバタを乗り切って一段落したこともあり、携帯電話に関する新規エントリを投入しようと準備していたのですが、あまりの分量の多さに研究発表送りとなりそうです（久し振りの追加となりそうです...）。という訳で、以前からまとめておこうと思っていた「マニュアルの操作手順説明書からの脱却に必要な観点」について、少し書いてみようかと思います。業界的には以前から問題になっているのですが、解決に向けてのアプローチが少しズレていると感じることが多々ありますので。
マニュアルにおける操作手順説明には、以下の情報を含むのが基本です。
現在多くのマニュアルには「操作手順情報や注意情報、補足情報だけが手厚過ぎる」、要するに「導入情報が極端に薄い」という問題があります。確かに操作手順情報がマニュアルの本命であることは事実ですが、導入情報が薄いとユーザーによる機能認知を向上させられない、機能利用モチベーションを喚起できないという問題が発生します。また、大きなイラストを中心とした導入情報が存在しないため、マニュアルのどのページも同じような操作説明ばかりで紙面にメリハリがなく、マニュアル嫌いを増やす一因となっているように思えます（携帯電話のマニュアルが典型例です）。
したがって操作手順説明書からの脱却を考えるのであれば、まず「これは何？どんな良いことがある？」というユーザーメリットの訴求強化（＝導入情報の強化）を検討すべきです。ポジティブなユーザー体験の獲得を目指すのであれば、まずは製品を使ってもらう＆マニュアルを読んでもらうことが大前提となるため、ユーザーメリットの訴求もシンプルに行うことが必要となります。それと同時に、メーカーの自己満足になりがちな複数手段の説明（例：PC上でのアプリケーション起動方法を何通りも説明する）や重要度の低い補足情報などを、ばっさり削除するくらいの決断が必要でしょう。
また、マニュアル中でユーザーメリットの訴求強化に目を向けるということは、（長期的には）製品企画・設計の段階でより具体的な活用事例を考慮するようになるという、副次的な効果も期待できるのではないでしょうか。マニュアル制作の段階で具体的な使用シーンについて質問された時にしどろもどろになる場合、困るのはマニュアル制作者よりもむしろ実際に製品を購入するユーザーです。何故かって、その製品はしどろもどろになるようなレベルでの想定・作り込みしかされていないということですからね。
ただこの方向で脱却を目指すのであれば、決して忘れてはならない観点があります。それは操作体系のスリム化やデバイス側への操作情報の埋め込みなど、マニュアル内での操作手順情報の位置付けをできるだけ軽くするための対策が並行して行われる必要がある、ということです。そうでなければ単に分厚いマニュアルができるだけですからね。マニュアルの「操作手順説明書からの脱却」を目指すのであれば、製品開発初期段階からの密接な協業が必要な訳で、最終段階で「マニュアルに詰め込んどけばOKでしょ」というのはナシでお願いしたいものです（笑）
「某社のデジタルカメラに付属する取扱説明書が、基本情報しか記載されていない薄い紙冊子と、詳細な情報を記載したPDFファイルに分割された」という信じがたい話を耳にしたので、確かめてみました。...確かにその通りで、フォローのしようがありません（涙）
デジタルカメラがPCの周辺機器だった時代（いったい何年前の話やら...）ならともかく、今この時代に「デジタルカメラ購入者はPC所持者である」という判断をするのは、まったく市場が見えていないと言わざるを得ないでしょう。こんな方針にOKを出したマニュアル制作部門の判断は論外として、商品企画部門やエンジニアリング部門もこんな企画をしっかり却下できないようでは困ります。どうしても紙冊子を薄くしたいのであれば、ユーザーの利益を損なわない範囲で情報を徹底的に絞り込む、エンジニアリング部門と協働で操作情報をUIへ組み込むなどの手法を採るべきです。
百歩譲って紙冊子とPDFファイルに分割することを認めるにしても、現状では情報分割基準も完全にズレていると言わざるを得ません。
PictBridge対応プリンターなら、本機で撮影した画像をパソコンなしでプリントできます。
サイバーショットハンドブック（DSC-N2） 99ページ
という情報がPCなしでは見られない（PDF形式の電子マニュアルに掲載されている）のは、悪い冗談としか思えません。それに情報構成の手法にも問題があり、これでは仕様書のリライトに過ぎないような気も...。果たしてこれでお客様の方を向いてマニュアルを制作していると言えるのでしょうか？
そうそう、デジタルカメラのマニュアル話ついででアレですが、デジタルカメラのマニュアルについて各社にお願いがあります。梱包箱のサイズ制限もあって冊子の判型が小さくなる一方、コスト制限も厳しくなる一方なのは理解できるのですが、露出とかその辺の機能を使った作例を、具体的に大きめの（できればカラーの）写真で載せて欲しいんですよね。ごちゃごちゃした形で説明されても、具体的にどういうときにどういう写真が撮れるのか、自分に引きつけた形でイマイチ理解できないのが実状です。
（ここではデジタルカメラや写真そのものが対象になりますが）機能理解を通じて商品の面白さを体験してもらい、ユーザーと市場を育てていくというのも、マニュアルの役割の一つだと思うのです。コモディティ化しているから〜などと勝手に諦めずに、商品の魅力をうまく伝えるマニュアル作りを期待したいところです。
この1年での仕事の話です。メーカーのマニュアル担当の方と話をしていると、マニュアル制作者（制作会社）に対して不満を持たれている方が多いようです。そのなかでも「仕様書や支給資料の清書屋（DTP屋）以上の仕事をしていない」という不満が強いと感じます。さらに突っ込んで話を伺ったり、実際の完成マニュアルを拝見したりすると、以下の問題を抱えている傾向があるようです（以下、とりあえず自分のところを全部棚上げして話を進めます）。
要するに日本語表現としては正しくてもマニュアルとして全然ダメという訳で、これでは清書屋呼ばわれされても文句は言えないでしょう。何が良いマニュアルなのか？を理解していないためか、後継製品のマニュアルが元製品のものよりも劣化していることさえあります。制作会社（や担当者）によってレベルの差はあるにせよ、全体的にマニュアルの品質は低下傾向にあるように思われます（少なくとも明示的に向上しているようには思えません）。
確かに最近の製品やサービスは高機能化／複雑化が著しく、製品理解のハードルが上がっていることも事実です（これはまた別の機会に書きます）。しかし上記の問題はそれ以前の話で、「閲覧コンテクストを想定した上で、どのような情報をどのように提供すべきなのか？を正しく判断する」という、マニュアル制作のプロセスで一番重要なところができていないのですから、どうしようもありません。狭義のライティングテクニック（日本語表現）としては問題なくとも、マニュアルとして機能しないのであれば意味がないのです。
また、この品質低下問題については、既存の評価チェックリストによる品質評価が機能していないと捉えることも可能かと思います。多くの制作会社の社内チェックではこの種のチェックリストを使用しているようですが、それが品質向上につながらないのであれば、チェックリスト自体の妥当性が問題になってきます。マニュアルコンテストの審査基準に対する疑念は以前書いた通りですが、現実のマニュアル品質を評価する上での押さえておくべきポイントが、しっかり押さえられていないのではないでしょうか。
この種のチェックリストですが、文章やイラストといった最終表現のテクニック評価に偏りがちで、一番重要と思われるユーザーコンテクストとの適合性や情報構成方針などがケアされていないものが多い、という印象があります。要するに定量化やON/NGの判断がしにくい部分がスルーされている訳で、これが結局、所謂テクニカルコミュニケーションの付加価値を正当に主張できない（コストとして転嫁できない）という問題にも共通する、諸悪の根源ではないか？とも考えられます。
まあなんだかんだで、品質向上のためには教育体制を地道に何とかしていくしかないでしょう。優秀な人材を確保できないこともあるのかもしれませんが、マニュアル制作会社にもしっかりした教育をお願いしたいところです。この辺の教育のポイントについては、関係あるようなないような微妙な次回（予定）のエントリに続く、と思います。ちなみに弊社ではマニュアル評価や、社内勉強会のサポートなどといった品質向上支援も業務として行っておりますので、お困りの際はぜひ声をおかけください（笑）
そうそう最後にひとこと。笑って見てる（かもしれない）Web制作関係の方々、他人事ではありませんのでよろしくお願いしますね。
業務多忙は先月末で無事クリアできたのですが、その後いろいろありまして更新再開が遅れておりました。復帰へのリハビリも兼ねて、日経デザイン2006年8月号（20〜21ページ）の記事に見られる（発表者の）勘違いについて、少しコメントしておこうかと思います（以下、マニュアル制作業界以外の方にはわかりにくい内容が多くなりますが、あらかじめご了承ください）。
当該記事を要約すると、「これまでマニュアルの（ビジュアル）デザインは非常に貧弱だった。流し込みフォーマットばかりで、見開きも考慮されていない（これは制作ツールにも理由がある）。市場からはデザインリッチなレイアウトが要求されてきているので、InDesignを使用することで（以下略）」というものです。マニュアル制作に関わる人を馬鹿にした発表としか言いようがなく、これは文句をつけずにはいられません。この話は先のDIME誌の特集の話（座談会でも話題になったがカットされた）とも関連があります。
マニュアルのビジュアルデザインが貧弱と感じられがちで、雑誌のような印象的なレイアウトと縁遠いのは、（お金の話は別にしても）凝った先割りレイアウトデザインが事実上不可能という理由が大きいのです。マニュアルのビジュアルデザインを批判するデザイナーの方は多いのですが、この点まで思い至っている方は本当に少ない（皆無？）ようです（DIME誌の座談会でもデザイナーの方が驚かれていましたし、日経デザイン当該号18ページの記事でも、その片鱗が伺えます）。
この辺の状況に関しては、もう7年半も前に
現実問題として、ビジュアル面を強調した雑誌のようなデザインをマニュアルに採用するには無理があります。雑誌のレイアウトは、規定通りの文字数で内容を伝えるライティングあってこそ成立するものですが、必要な説明を省略してはならないマニュアルでは、その前提は成り立ちません。
と書いた状況からまったく変わっていません。
先割りレイアウトには文字量の制約（テキスト分量を決めて文字原稿を依頼するというワークフロー）が当然ですが、マニュアルではそのようなビジュアル優先の制約は機能しません。必要な情報をユーザーに伝えるという最優先の目的のためには、文字量の制約などそもそも無理な注文なのです（もちろん先割りレイアウトでなくてもレイアウトに配慮することは可能で、現状のマニュアルのデザインが貧弱だというのはもちろん制作者サイドの問題もありますが、後述します）。
その挙げ句に
今では、マニュアルにもよりわかりやすいビジュアル性の高いデザインが求められています。
日経デザイン2006年8月号20ページ
などと書いていますが、こんなことはそれこそ上記通り10年来の課題なわけで、いい加減にしろと言いたい（この発表を会場で聞いて、うっかり納得してしまった人も同様です）。
現実的な問題として、お金と時間、それを含めた開発体制が抜本的に変わらない限り、ビジュアル中心のマニュアル制作は困難といわざるを得ません。頻繁に発生する仕様変更（情報量の増減）に直面しているマニュアル制作の現場では、ビジュアル中心のマニュアルは修正発生時のリスクが大き過ぎるのです。しかしそのような状況の中でも、できるだけデザイン品質を向上させたり、紙媒体メディアとしての特性（見開き展開）を活かそうとしたりしたマニュアルは昔から存在しています（初代PlayStationのマニュアルなどもそうです）。制作ツールの問題ではないのです。
（私見ですが）マニュアルのビジュアルデザインが貧弱な理由としては、以下の3点が大きいのではないかと考えています。
熱意のある制作者にとっては前2つが問題で、熱意がない制作者はそれ以前の問題ということですね。結局のところ業界外に向けては「批判のポイントがズレてるんですけど」、業界内に向けては「もっと頑張ろうよ」という、ありきたりのつまらないオチで〆ということで。
小学館のDIME 2006年13号（6/22発売号）に、「『メーカーの品格』は取扱説明書を見ればわかる！」なる記事があります。内容的に特に目新しい視点がある訳ではありませんが、いわゆるガジェット系雑誌でこういう特集というのは結構斬新かなあと。ちなみに来週火曜には次号が出てしまうようですので、興味のある方はお早めに。
マニュアルの品質についての煽りはユーザーサポート系や消費者団体系という方向からがほとんどでしたので、こういう方面からの品質改善への煽りは歓迎すべきことといえるでしょう。煽りの質も方向も、既存のものとは微妙に違うと思いますしね。今後もこういう特集が競合他誌含めて定期的に出てくるようになると、現状改善への圧力の一助になるのではないかと期待しています。
ちなみになんでこんな紹介をしたかというと、弊社が取材協力としてクレジットされているという訳で...。なんか編集されまくりのアレな座談会などあったりしますが、気にしないでくださいませ。編集方針でカットされた話の方が面白かったような気がするので、その辺の話は機会がありましたら（あくまで）適当に公開しようかなと考えています。
ちなみに現在、極端な業務多忙です。今月前半に比較すれば事態は改善されつつありますが、危機的状況が持続しています。来月後半までは完全に身動きが取れませんので、ご了承くださいませ。
マニュアル制作で必要とされるスキル・視点をおおまかに分類してみると、次の3通りになりそうな気がします。
確かにマニュアル制作のスキル流用が直接的に可能であることを対外的に示すには、これが一番手っ取り早いように見えます。ただし、表現設計は適用領域による幅（業界基準や表現の流行など）が大きく、一般的なわかりやすい表現が通用するとは限りません（そもそも求められていなかったり...）。
さて、マニュアル制作のスキルを他領域で展開しようという話になると、たいていは表現設計の話になりがちです。「マニュアル制作で鍛えられた、わかりやすい表現技法を提供します」とかいって。
また、汎用ビジネス表現技法として見た場合でも、（広告に要求されるような）飛び道具的な表現が要求されても、対応できないのが実状でしょう。プレゼンテーション資料のように、実際のわかりやすさよりも見かけのわかりやすさやインパクトが求められる場面（最近の図表化・視覚化の流行とか...）も多いのが現実ですから、マニュアル制作のスキルが活かせるかどうかは、また違うような気がします。
というようなことを考えると、本当の意味でマニュアル制作やテクニカルコミュニケーションで得られた知見・経験を活用できるのは、ワークフロー設計や情報設計の領域だと思うのです。文書が絡む業務システムの分析とか、様々なメディアやツールで提供する情報の枠組みの再検討、業務文書のフォーマット規定などといった課題は、マニュアル制作で養った感覚を活かすにふさわしく、専門家としてのスキルを大いに発揮できるものでしょう。
一番の問題は、お客様が「なんで取説屋さんがここに？」と疑問に思ってしまうことでしょうか（苦笑）もちろん上記のようにご説明すると、納得して頂けるのですけど。その意味でも、マニュアル制作やテクニカルコミュニケーションで得られる適切なメリットについて、世間に対して呼びかけ続けることが大切になってくるのではないかと思います。
もう業務負荷が大変なことになっており、GW終了まではこのような状況が続きそうです（泣）
さて、ここ数年のマニュアル制作業界を見ていると、何が良くて何が悪いのかを的確に判断できる人が少なくなってきている印象を受けます。だから改善のつもりが改悪になったり、問題があることがわかっていても改善につなげられない、というような話があちこちで出ています。
このような状況の理由としては、もちろん企画構成手法や表現技法の変化についていけなくなっている組織・人が増えていることもあります。ですが、根本的には技能継承が適切に行われていないことに問題があるように思えるのです。つまり、（既存手法や技法に問題があるにせよ）表面的な手法や技法の問題ではなく、その根底に存在する考えかたや問題解決へのアプローチという部分がうまく継承されていないということです。この辺の問題については、各種ガイドラインやノウハウを集積して、ベースとなる技能を誰でも学べる環境を用意することが有効ですし、必要でもあります。品質を安定化させるための各種規定もそのために存在する訳ですし。ただ、それだけではやはり座学の域を出ません。「座学を実践できないのは理解が浅いから」と一蹴することは簡単ですが、座学では集約された知識を扱うことが中心となるため、どうしても現場の感覚から離れがちになってしまうのは仕方のない面があります。
したがって、座学とは別に、知識を実践していく場と、実践の中で適切な評価・修正が入る場が必要となります（そのためのOJTです）。でもそのような環境が存在しないからこそ、技能継承が行われないという現状問題が発生する訳で...と話がループしてしまうのが難しいところです（苦笑）
で、前者の実践していく場（自分で実際に手を動かすこと）はともかくとして、後者の実例ベースで議論しながら問題点を認識したり具体的な改善案を検討したりすることについては、ネットワークを利用することで実現できそうな気がするんですよね。もちろんメーカー独自ルールみたいな部分はカバーできませんけど、何もないよりはマシかなあと。担当者が孤独な立場に置かれている（誰もマニュアル制作のことを知らない）ことも多いでしょうし。
というような目的で、実際に市場に出ている実際の製品マニュアルをベースにして（メーカーのWebサイトで公開されているものを使用）、意見を交換するための専用の場を設けることを考えているのですが、どの程度の需要がありそうでしょう？（基本的には制作者や関連業務担当者など、実務担当レベル＋研究者＆学生？を対象として考えています）
これまでに研究発表として公開したコンテンツのうち、マニュアル制作に関連するものをまとめた「ぷちポータル」（笑）として「マニュアル制作入門」を公開しました。
いわゆる取扱説明書・操作説明書の制作を対象としていますが、一般的な業務マニュアルに応用できる情報も多いと思いますので、適宜ご活用ください。
すっかり間が開いてしまいましたが（反省）、ようやく復活です。
最近は製品開発期間の短縮（もちろんコストダウンも）が至上命題と化していて、マニュアル制作もそれに合わせて短期化することが求められています。また、現物重視の反復型の開発手法が多用されることが多くなってきている関係か、 マニュアル側も短期間にチェックを何度も重ねて内容を作り込むというケースが増えています。その結果として、数百ページのマニュアルを中二日ですべて修正して再提出という状況が頻発するなど、制作現場にかかる負荷は増大する一方です。まあこれは極端な例ですけど。
さて、負荷増大に対しては投入リソースを増やすことで対応するのが一般的かと思います。ですが、制作期間が短縮されるマニュアルの場合には、単純にリソースを増やしてもうまく対応できないことが多いのです。現状の開発体制では分散オーサリング→集中管理による一貫性チェックという段階を踏む時間など取れないことがほとんどですし、投入したリソースの分だけ余計にコストがかかることにも注意が必要です（どうせ認めてもらえないんですけど）。仕様書や機能単位を中心に解説するリファレンス系マニュアルであれば分散オーサリングでも問題ないのでしょうが、複数機能にまたがるユーザータスクを中心に解説する操作マニュアルは、定型化したもの以外は分散オーサリングに元々向いていないのです。で、既存ワークフローのまま現場に負荷をかけざるを得ない→現場崩壊／社員退職（笑）というお約束のルートを辿るわけです。
こういった問題を解決するには、マニュアル制作を反復型開発とは別のルートに乗せられないか検討するとか、（ユーザーに負担を転嫁しないことを前提に）マニュアルとして提供する情報の内容を見直す／削減するなど、純粋な制作方法以外の部分で何らかの対策をする必要が出てくるでしょう。制作側だけでなく、製品開発側やユーザーに対する情報提供に責任を持つ部門との調整も必要になります。とにかく現状のマニュアル制作を続ける限り、一定の品質を維持することがどんどん困難になってきていることを、多くの方に理解していただきたいものです。およ？ 品質なんてどうでもいい？ はあ、そうですか。
とまあこういう事情を理解していただいて、新しい情報提供の枠組み造りに取り組めるのは嬉しいものです。多忙で沈没することが増えそうですけど（笑）
最近の制作現場では、制作効率が優先されるあまりに、デザインに対する制約がかなり厳しくなってきています。
制作に使用するアプリケーションソフトはメーカーから指定されるのが常ですが、生産性向上という名目でソフトを変更することが最近多いのです。そのせいもあって、デザイン面での裁量の余地がかなり狭くなってきています。裁量余地が狭いということは、逆に工夫するための腕の見せ所という面もあることも確かなのですが、例外的でトリッキーな処理を多用すると、そもそも生産性向上を期して導入した制作プラットフォームの意味がなくなってしまうため、なかなかうまくいかないのが現実です。生産性重視のアプリケーション導入を強いる一方で、例外処理を多用したデザインを求める「？」なメーカーもありますが、そうした「わかってないなあ」という担当者を抱えているところも多いようです。
こうした縛りを別にしても、そもそもマニュアルのデザインを理解し、適切に評価できる人が少なくなってきていることも大きな問題です。「コスト制限による紙面の最大活用が要請される」といえば聞こえが良いものの、要するに単なる詰め込みレイアウトが主流になってきたあたりから、この傾向が強くなっているようです。全体のレイアウトバランスという大きな部分から、ディテールの見せかたといった細かい部分まで、デザインの話がわかる（できる）担当者がかなり少なくなってきています。以前にも取り上げたように、低レベルのデザインに慣れてしまったせいか、まともな評価がなされていない（というか、できない）状態です。
これではデザイナーの能力など正当に評価される訳もなく、デザイナーは実際のところDTPオペレーター扱いされていることが多いようです。当然業務へのモチベーションなど維持できるはずもなく、マニュアル制作の世界を離れていってしまうというわけです。お約束とは言え、優秀な人こそ、この傾向が強いのが頭の痛いところです。ある程度替えの効くライターと違って、しっかりしたデザイナーは替えが効かない人材なのですから、できるデザイナーはくれぐれも大切にしたいものです。
この辺の話は前から思っていたのですが、とあるメーカーの結構良いデザインをするデザイナーさんが別部署に異動してしまったという話を聞いて、あらためて実感した次第です。
「昨年からマニュアル制作の仕事量が減少傾向に転じている」という話を耳にすることが増えてきました。実際にメーカーがラインナップをかなり絞り込んでいる訳ですから、ある意味で当然といえるでしょう。また、リストラによる人余り対策として、メーカーによる内製化の話が出ているところもあるようです。内製化は以前の円高不況時にも流行って、あっという間にポシャった（簡単そうで実はそうじゃなかった）前歴があるのでそれほど心配していないのですが、メーカーは子会社への発注を増やすことで連結グループ外への資金の流れを絞るでしょうから、独立系の制作（印刷）会社に厳しい状況は続くでしょう。
ところで、マニュアル制作会社に求められているのは、
この辺りになる訳です。
不景気によって、量をこなすこと（2）が以前と比較して重要でなくなってきた以上、必然的にある程度コストをかけて良いものを作る（1）のか、あるいは徹底的にローコストオペレーションを狙うのか（3）というように、対象商品によって要求されるものが二極化してくるはずです。そして後者に関しては、DB連係やワンソース展開などの制作システムを刷新して対応するか、あるいは零細事業者を安く使い倒す（苦笑）しかなさそうです。先にあげた1〜3の中でひたすら2と3を重視していたような会社（特に印刷会社の制作部門に多く見られる）は、いまかなりきつい状況に陥っているのではないでしょうか。
多国語マニュアルは遅かれ早かれ海外制作に移行するでしょうから、問題は日本語と（翻訳元の）英語のマニュアルを、どれだけの品質で制作できるかが勝負になると思われます。単に品質というよりも、マニュアルを通したコミュニケーション戦略を提案していったり、マスターとなるフォーマットやひな形を提案制作する側にまわらないと、しばらくはコスト勝負の持久戦を強いられることになるでしょう。
現在のところは品質とコストによる淘汰段階かと思われますが、これがさらに進んで、ある程度の品質のマニュアルを制作できる所同士の叩き合いまで始まると、業界の活力的にはかなりヤバいところまで来てしまいそうです。というか、叩き合いが本格化すると、大規模な制作会社はかなり厳しい運営を迫られるような気がします。受注産業で供給過剰なのですから、まあいろいろと大変な建設業みたいなものでしょうか。取りあえずのところ、「お互い頑張りましょう」というしかないですよね。う〜ん、ネガティブ。
いや、低下するほど元は高かったのか？という話は置いておきますが。
お付き合いのある制作会社の方と話していたところ、「仕様書を解釈して、まともな構成をイチから起こせる制作者が最近少ないんですよ」というような話になりました。比較的大きい制作会社さんは大方の案件を内部で制作できるのですが、やはりオーバーフローしたり手持ちのリソースではカバーできない場合なども発生することがあるわけで、そういう場合には外注することになります。前者のように単純なオーバーフローのような場合は問題が少ないのですが、後者のようにある程度のレベルを求められる場合が問題のようです。
家電製品もデジタル化が進む一方ですから、AV（オーディオ・ビジュアル）だけでなくコンピュータやネットワーク絡みの内容まで押さえておかないと、まともなマニュアルを制作することが困難になってきています。メーカーのマニュアル担当者レベルでさえ脱落しかかっている方が多い状況ですから、実力のあるマニュアル制作者であれば、内容的な面に関してもイニシアチブを取ることが十分可能になってきています（実際にはそのレベルの人材はほとんどいないようですが）。また、内容理解という面だけでなく、製品の開発期間の短縮による制作工程の負荷増大にも耐えられる制作パワーも必要になってきますので、マニュアル制作者に求められる能力はますます厳しくなってきていると言えるでしょう。
それでは実際のマニュアル制作者はどうなのでしょう。これが実は、呆れるほど意識レベルが低いのです。不景気だから仕事が少なくなっているとか、ツールの使いこなしとか、言葉の意味がどうだとか、あいかわらずその程度のレベルの話でしか盛り上がれない。工程意識は皆無。ユーザー志向といいながら昔の方法論から脱却できず、相変わらずユーザータスクベースで情報を構成できない。最新技術動向に対する不感症。これではお話しになりません。以前ここでも苦言を呈したことがありますが、あれから状況はますます悪化しているように思えます。技術が高度化／複雑化する中でTCに関わる人材の重要性は高まるはずなのに、こんなレベルで一体どうしようというのでしょう？
紙媒体をはじめとする、従来形式のマニュアルの限界を見限ってWebサイト関連に転身しようとしているところも多いようですが、上記のような問題を抱えたままで転身できるほど甘くはありません。特に情報構造デザインにも注目が集まっている現在、説得力のあるポリシーでもって、コンテクストに応じて情報を構成する能力なしに、他業界から転身する意味がどれだけあるものやら。もちろん最終的に発生する文章のリライトレベルの仕事だけしていくということであればそれでも良いのですが、それって何か違うんじゃない？と思う今日この頃でございます（週明け早々、ネガティブな話題で失礼いたしました）。
当研究所が力を入れているのは、わかりやすさや使いやすさといった価値なのですが、皆様もご存じのように、これらの価値は直接目に見えるものではありません。EC系のWebサイトであれば、ユーザビリティ設計がそのまま購買実績に直結することも多いでしょうから、売り上げという目に見える価値として機能しているといえます。ですが、他の分野ではなかなかそうは行かないというのが実情でしょう。ユーザビリティ設計が劣悪なWebサイトであっても、扱っている商材の商品力でカバーしてしまうような力技が通用してしまう面もあるので、難しいところです。
そうすると、目に見えない価値をお客さまにどう理解していただくのかが大変になります。この場合のお客様は最終的なエンドユーザーではなく、マニュアルやWebサイトの制作を依頼してくるお客様ですね（最終的にはエンドユーザーにもその価値を訴求する訳ですから、結果的には同じことなのですが）。ありがちな路線として、サポートコストの低減やユーザー体験の品質強化によるリピート率の向上やブランドロイヤリティへの寄与ということを中心に訴求することになるのですが、問い合わせ数の減少によるサポートコストの低減はともかく、後者のような目的は数値目標的に測定すること自体が困難であったり、実際の数値において変数としてどれだけ寄与しているのかを独立して取り出すことが困難であったり、なかなか難しいところがあります。お客様としても、感覚的に理解できても、上層部から承認を得るためには数値目標的に達成基準が客観的に測定できる必要があるため、定性的な訴求だけではなかなか認められることはありません。
本来、デザインや機能といった目に見える部分の商品力にそれほど差がないのであれば、目に見えない部分の価値が商品力として重要な価値を持ち得るはずです。そういう意味で、同じ商品を扱うことが多いEC系のWebサイトで、ユーザビリティ設計やユーザー体験の強化に力が入れられていることは当然といえます。問題は、目に見える部分の商品力が多少劣っても、目に見えない部分の商品力が他を圧倒している場合です。こうした場合でも、たいていは目に見える価値の方が優先されてしまうことが多いのです。これではいつまで経っても、目に見えない価値は商品力に寄与しないことになってしまいます。
目に見えない価値を理解してもらうには、目に見えない価値を目に見えるような形で訴求するしかありません。それはわかってはいるのですが、どうやって目に見えない価値を目に見えるように実装していくのか、そして目に見えない価値を定量的に評価するスキームを作り上げるのか、なかなか難しいところです。ですが、ここを乗り越えないと、マニュアル制作やユーザビリティコンサルといった業界が「おたくの○○○はデキが悪い。デキを良くしないと祟りが〜」というような恐喝産業（苦笑）として認定されてしまうことでしょう。最近ユーザビリティ関連で派手な動きも散見されますが、目に見えない重要な価値を、それなりの対価が必要とされるものと理解してもらえるようになるためには、まだまだ地道な取り組みが必要とされているのではないでしょうか。
TCシンポジウムも無事終了しました。会場にお越し頂いた皆様、どうもありがとうございました。今年はパネリストによる個別発表形式ではないため、例年のような発表資料／内容公開はありませんが、近いうちに発表テーマのまとめを行いたいと考えています。
さてTCシンポジウムといえば、会場に展示されているマニュアルコンテストの受賞作品。別に受賞作品に対して文句を言うわけではないのですが、何故にこれとこれが同じ賞？というものがあったり、こんなもの入賞させて良いのかよというものがあったり。例年通りといえばそれまでなのですが、やはりコンテストという以上、評価する側にもそれなりの見識が求められると思うのです。
確かに適切に評価するために必要な方策はそれなりに取られていると思うのですが、評価者が根本的に見識を欠く場合には、現状では如何ともしがたいようです。そうかといって一般審査を参考程度に留めてエキスパートによる集中審査形式を採用すると、密室談義の誹りを免れるのが難しくなるということで、なかなか難しいものがあります。
現状で特に納得がいかない評価がされていると感じるのは、構成とデザインです。行間ほとんどなしでコラム幅いっぱいにテキストを組んでいるものが入賞していたり、デザイン自体の質はともかく製品のブランドイメージと乖離してないか？というものもあります。構成についても、ユーザー層や機器ごとの使われ方なども含めて、まともな評価がなされているのでしょうか。こうしてみると、これらを適切に評価できる人がマニュアル業界にほとんどいないと言わざるを得ません。それならそれで、見る目を持ったエキスパートによる審査監督を、もっと厳しく行う必要があります。パッと見で初心者受けする取っつきやすさも重要ですが、そうしたギミックだけに惑わされない大人のコンテストでなければ、業界団体で主催する意味はないのではないでしょうか。
良いマニュアルのスタンダードを確立／普及する目的でマニュアルコンテストを行うのであれば、入賞に値しないものは極力排除しなければなりません。例え入賞作がゼロになったり、特定メーカーのものだけが入賞になったとしてもです。審査を厳格化することで、評価者の見る目の向上も期待できますし、それは日々の業務にフィードバックされることでしょう。Webや電子マニュアルとの情報分担も含めてマニュアルが多様化する中で、マニュアルコンテストの意味や目的、方法を見直す時期に来ているのではないでしょうか。
マニュアルの比較評価やWebサイトのユーザビリティ評価などの結果を目にする機会がありますが、納得させられるものに出会うことは少ないようです。研究発表でも何回か取り上げた通り、基本的な評価の方法や評価軸といったものは存在するはずなのですが、なぜ納得させられるものが少ないのでしょうか。
その最大の原因は、それぞれの個別性、つまり市場におけるメーカーや製品のポジショニングであるとか、想定された目的であるとかを、きちんと織り込んで評価がなされていないことにあります。Webサイトの評価などはまだ良い方で、マニュアルの評価にあたっては評価者が実機に触れることがないどころか、評価対象となる製品カテゴリーに対する根本的な理解を欠いていることすら珍しくありません。「そのような立場の人間が評価した方が、初心者ユーザーにはフレンドリーなものになる」という意見はよく聞きますが、（言葉は悪いのですが）はじめからド初心者をある程度切り捨てる方針でマニュアルが制作されることは、決して珍しいことではありません。情報提供にかけるコストと対象ユーザーの割合を考慮して、現実的にそうした判断がなされることがほとんどなのです（もちろん大きな声では誰も言いませんよ）。
Webサイトの場合では、ターゲットユーザーの絞り込みを行っているサイトの評価に同じような問題がつきまといます。自サイトで取り扱う題材に興味があるユーザーを前提として、情報のカテゴリー分類基準やタイトル付けを決定しているようなところは、評価者を選ぶのです。評価やテスト担当者が運営側の想定ターゲットをはずれていると、思いっきりマイナスの方向にバイアスのかかったデータが出てきてしまいがちです。
マニュアルにしろWebサイトにしろ、それらがデザインされ、完成物として存在するまでのコンテクストを切り捨てた評価やランキングに、どれほどの意味があるでしょうか。もちろん、それ以前の一般レベルでの問題が多いマニュアルやWebサイトが多いことも確かです。ですが、結果を真剣に検討するに値するだけのアウトプットを出せないようでは、評価という業務にどれほど必然性があるのか疑問です。そろそろこうした面を真剣に考えないと、遅かれ早かれ評価する側が信頼を失うことになるのではないでしょうか。
情報大工のひとりごと