テクニカルコミュニケーションの第四期

テクニカルコミュニケーションという言葉は、これまで主にマニュアルや取り扱い説明書の作成に関して使われてきた。パソコンやワープロが市場に登場した時期に、その使い方のわかりにくさが問題となり、その問題を改善するためには、マニュアルや取り扱い説明書を改善する必要があると考えられたわけである。この時期には、こうした紙ベースの情報媒体において、機器やシステムの使い方や機能を分かりやすく説明するのがテクニカルコミュニケーション技術だと考えられてきた。これをテクニカルコミュニケーションの第一期と呼ぶことにする。ちなみに、この問題がマニュアルや取説だけの問題ではなく、機器やシステムそのものの問題でもあるのだと認識されるようになったのが、現在のユーザビリティ活動の出発点だったといえる。

こうしてテクニカルコミュニケーションの重要性は認識されるようになったが、ユーザがマニュアルや取説をあまり読まないという現実、分厚いマニュアルや取説を無くしたいというメーカ側の要望などから、次第に紙ベースのマニュアルや取説がオンライン化されるようになってきた。こうした動きの中で、テクニカルコミュニケータの仕事は徐々にソフトウェアとの関係が深いものになってきた。いわゆるオンラインマニュアルやオンラインガイダンス、オンラインヘルプといわれるようなものをテクニカルコミュニケーションの観点から改善することがその業務となった。この時期がテクニカルコミュニケーションの第二期に相当する。

こうした経過をたどってきたテクニカルコミュニケーションは、現在第三期に入りかけている。つまり、機器の利用に関する情報がWebに掲載されるようになってきたのである。Webであれば、更新や訂正が容易に行えるというのがその大きな理由である。ただし、Webのデザインにおいては、テクニカルコミュニケーションの担当者に、第二期におけるより以上のソフトウェア技術が要求されることとなった。その意味で、従来のテクニカルコミュニケーション担当者がこうした新技術から置き去りにされる可能性が懸念されている。HTMLのコーディングくらいできなければテクニカルコミュニケーションの実践などできないではないか、という見方があるからだ。現実に、Webデザインという業務は、そのユーザビリティも含めて、Webデザイナとよばれる新たな「人種」によって遂行されているケースが多い。そこではテクニカルコミュニケーションはWebのユーザビリティを向上させるノウハウの一部として見なされている。

こうした状況の中、テクニカルコミュニケーションの第四期が到来しつつある。いや、到来したというよりは、そうした問題意識が必要とされるようになったというべきかもしれない。この第四期を特徴づけるのは、パソコンのソフトウェアが画面に出力する情報そのもののデザインである。エラーメッセージに代表されるシステムメッセージの分かりにくさは以前から認識されていた。しかし、それに対する取り組みは、テキストデータの作成とそのコーディング作業を同一のソフトウェア担当者が行うという業務形態の関係から、テクニカルコミュニケータとは別の場所で行われてきた。そうした状況とソフトウェア開発作業量の増大の結果、OSにおいても、アプリケーションソフトにおいても、単にエラーメッセージが理解しにくいだけでなく、まともにそれを利用しようとする際に表示情報が理解できないといった事態が発生したのである。

たとえばWindowsのネットワーク接続において「新しい接続ウィザード」の表示情報はバージョンごとに変化してきたが、最新のXPにおいても依然としてわかりにくさが残っている。例をあげるときりがないが、たとえば「詳細接続をセットアップする」という表示のわかりにくさは、単に「セットアップ」という日本語になじみがないというだけでもなく、「詳細」な「接続」って何だということだけでもない。さらに「詳細接続」を「セットアップする」という関係が分かりにくいだけもない。つまりここにおける問題は日本語の話だけではないのだ。

たとえば自宅に別のパソコンがあり、新しいパソコンとそれを接続してLANを組んで、それら全体をインターネットに接続したい、という要求をユーザが持っていたとすると、「インターネットに接続する」を選べばいいのか「ホームネットワークや小規模オフィスのネットワークをセットアップする」を選べばいいのか、「詳細接続をセットアップする」を選べばいいのかが分かりにくい。こうした論理的な関係のデザイン、たとえば選択肢における相互排他性の確立といった論理的かつ認知的な視点と力量が必要なのだ。

この問題に見られるように、第四期のテクニカルコミュニケーションに要求されているものは、単なる文章表現の問題ではなく、機能の整理や体系化に関する論理構築の問題なのだ。こうした問題は従来、ソフトウェア担当者にまかせておくべきものと考えられてきた。しかし、自分では分かっていても他人にそれをうまく説明できないソフトウェア担当者が多いことが次第に明らかになってきた。その一方で、それを従来のテクニカルコミュニケーション担当者がこなせるのかというと、残念ながら現状では疑問の余地がある。問題のカテゴリーとしては、明らかにテクニカルコミュニケーションなのだが、それを適切に担当できる「人種」は時代と共に変化しているように思う。