取扱説明書の構造を図解する

この記事は 図解アドベントカレンダー 7日目の記事です。

図や絵をもちいて表現することをテーマに、12月1日から25日まで1日に1つ、みんなで記事を投稿していくというイベントです。

adventar.org

1998年から取扱説明書制作に携わり、業界特化せず多種多様な製品やサービスのテクニカルドキュメント・・・取扱説明書（取説、トリセツ）、サービスマニュアルなどや、プレゼンテーション資料を制作してきました。
家電などを買って箱を開けると入ってたり、ウェブにアップロードされている（そして最終的にどこにいったかわからなくなる）「コンテンツ」を作ってます。

取扱説明書制作においても、図や絵の表現はかかせないものです。
むしろ、文字中心よりも図や絵中心の説明が求められています。

取扱説明書で使う図や絵の表現としては
・線画におこしたテクニカルイラストレーション
・写真を目的にあわせたレタッチしたもの
・フロー図など、作業の流れを模式化したもの
等、表現する目的やトンマナにあわせてさまざまな手法が使われています。

取扱説明書は、使い方だけのコンテンツじゃない

「取扱説明書」と聞くと「使い方が載っている」コンテンツだと連想するのですが、取扱説明書の目的・存在意義は使い方だけではありません。

上記は、ソフトウェア/アプリ/サービスなどを含む製品の取扱説明書を想定した構成例です。

取扱説明書を構成する要素としては大きく分けて
①メーカーの管理項目
②ユーザーが使うことを想定した使い方を解説する項目
③ユーザーが使いこなして製品やサービスの価値を高める項目
があります。

①製品やサービスの取扱説明書は、メーカーにとっては「部品」です。商品の一部なので品番や製品安全記載、保証規定、お手入れ項目等が記載されています。
②ユーザーの「使いたい」と思う気持ちを華麗に完遂させる必要があり、時系列に沿って項目が記載されます。
③「使い続ける」ための工夫のため、活用法などを掲載することがあります。

ソフトウェア/アプリ/サービスを経由する製品やサービスの取扱説明書では、インストール手順やログイン/ログアウト、パスワードの解説、より活用するためのAPI情報なども掲載されます。

これらを整理し、構造化や可視化を経て1つのまとまった取扱説明書コンテンツが生まれていきます。

取扱説明書としては下記の3タイプの方向性をもって構造化されることが多いです。
・製品やサービスの利用初期段階のコンテンツ：時系列
・ヘルプやテクニカルな記載中心のコンテンツ：機能別
・辞書のように体系化されたコンテンツ：項目別

高機能な商品の取扱説明書はなぜわかりにくいか

ひとつの製品やサービスにつき、取扱説明書コンテンツが複数存在することもあり、すでにできあがった製品やサービスをひとつにまとめる場合にもあらためて構成を組み替えることがあります。
ユーザーとしては「なんでひとつになってないの？」と思ってしまいますが、ここは製品やサービスの提供側の都合（予算、納期、ニーズ、人的リソース等）に影響受けることがあります。

取扱説明書の制作現場では、製品やサービスが生まれるごとに新たに書き起こして取扱説明書を作るわけではなく、すでに制作したベースモデルの取扱説明書をもとに組み合わせて作ることがあります。

ベースモデルの取扱説明書を元に変化点を追いかけて作成していくと、全体の構造がおかしくなることもあります。（単純に、取扱説明書の設計ミスですが。）

ベースモデルがあっても取扱説明書をコンセプトにあわせて設計しなおすことで最適化された状態で構造化していくことができます。

取扱説明書の構成には、ユーザー体験を反映する

弊社では昨年、サイボウズ株式会社の 「kintone導入ガイドブック」を制作させていただきました。

PaaS（Platform as a Service）の取扱説明書制作で、これからkintoneを導入しようとしている方向けに、スムーズにPaaSを導入そして活用いただき、導入担当者も離脱せずやりたいことをうまく見える化してもらえるようにする冊子の形で提供しました。

kintone導入ガイドブックの「やること見える化シート」は、冊子を開いたページにあります。取扱説明書でいう、もくじにあたります。
活用を含めた導入工程の全体を見ながら、自分が何をやりたいのか、だれを巻き込むのかを、書き込みながら見える化＆自分ごと化していただくツールになっています。

上半分にカスタマージャーニーマップの要素を、下半分にユーザー体験の要素を設計しています。

書き込むというユーザー体験を取扱説明書の設計に組み込むことで、離脱しやすいサービスの導入を食い止めることもできます。