０６　ユーザーズマニュアル（取扱説明書）　

ユーザーズ・マニュアル（User’s Manual）とは，パソコンやコンピューター周辺機器などのハードウエアと，アプリケーション・プログラムなどのソフトウエアの使用方法や操作手順に関する取り扱い説明書を指します。ユーザーズ・マニュアルは，ハードウエアやソフトウエアを利用者（ユーザー）に使いこなしてもらうための道案内，あるいはシステムや機械とそれを使う人間との橋渡し役を担います。

　なお，ユーザズ・マニュアル作成の前提として，ユーザーの要望をとりまとめたシステム要件書，システムやソフトウエアの機能をまとめたシステム仕様書，プログラムの動作を記述したプログラム仕様書，プログラムテストとそのデータを詳述したテスト仕様書といったシステム開発関連のドキュメント類の整備も必要です。

　2006（平成18）年，東京都港区のマンションで起きた高校生のエレベーター圧死事故で，国土交通省昇降機等事故対策委員会は，「事故調査報告書」でブレーキ異常が直接の原因としています。また，報告書では，製品の欠陥とともに，設計図や機器のマニュアルをメーカーから引き継がないという業界の“悪しき慣習”も糾弾しています。

　当初は事故機の保守も自ら行っていたメーカーのシンドラー社は，入札制度導入によって落札業者が代わった際，業界の慣例通り，点検マニュアルを後継の保守会社に渡さなかったことから，保守会社は，東京都が発行する一般的なエレベーターの仕様書や，シ社の類似機のマニュアルを元に管理しており，対策委は「（仕様書とは）全く違う構造で，適切な管理ではなかった」と指摘しています。

　この事件を契機として，シンドラーエレベータ社や他の外資系メーカーは独立系を対象に技術指導講習会を開いいたり，マニュアルの引き継ぎを求めた際，応じるケースもみられるようになってきたほか，点検内容を厳しくチェックする顧客も増えたということです。　

　

７−１　ソフトウェアに関するマニュアル

　パソコンのアプリケーション・プログラム，情報機器の操作方法など，情報システムに関連するドキュメントは多岐に及びます。一般的に業務処理に関わる情報システムで使用するドキュメント類には，ユーザー向けドキュメント，保守用ドキュメント，開発用ドキュメントの３つがあげられます。
　そのうち，ユーザー向けドキュメントをユーザーズ・マニュアルとして，使用目的別に分類すると，�@導入手引書・導入ガイド（入門マニュアル），�A操作マニュアル，�Bリファレンス（辞書），�C事例集，�Dセットアップ・ガイドなどに分けられます。

１）　導入解説書・導入ガイド（入門マニュアル）

　　導入解説書・導入ガイドとは，システム開発の経緯や，システム（アプリケーション）の概要および利用法を解説するマニュアルをさします。
　物事を理解するとき，はじめから詳細を知ることよりも，まず全体の概要を知る方が理解が早まります。情報システムでも基本的な機能を理解すれば，システムの全体像を感覚的にイメージをすることができ，操作マニュアルへの理解も深まります。
　一般にシステムの持つ全機能のうちの20〜30パーセントで，対象業務の80パーセントは処理できるともいわれています。このことから，初心者向けの導入ガイド（入門マニュアル）では，ユーザーの業務を分析して，そこから課業（タスク）あるいは機能を抽出し，タスク・機能中心に解説するのが有効です。

２）　操作マニュアル（操作説明書・操作マニュアル）

�@情報システムの操作マニュアル

　情報システムの操作マニュアル（取扱説明書）では，システム運用に関する規則や条件，全機能の概要，その機能を使うための操作手順，インプットデータ，アウトプット情報などを記載します。なお，使いやすい操作マニュアルの条件としては，�@必要な箇所をすみかに見つけられるよう，目次や検索機能の工夫，�Aわかりきったことでも繰り返し記述する，�B障害発生時の対応の仕方の明快さ，といった点があげられます。
　その出来が悪いと、利用者が不満を抱くだけでなく、操作ミスの発生を招き，システムの信頼性を失うとともに，膨大なメンテナンスコストの発生ともなりかねません。

・わかりきったことでも繰り返し記述す
　これを読むﾕｰｻﾞｰは，システムやコンピュータに関する深い知識や経験を持っていないことを前提とし，「必要あるいは重要と思われる内容については，「わかりきったこと」でも重複を承知で繰り返して記述します。


・障害予防・制約事項の告示，障害処理の説明
　障害が起きた時こそ，マニュアルの真価が問われます。システム運用上のハード・ソフトの両面からの制約事項や，障害が起きた場合の対処法どを明示したマニュアルが有用です。

７−２　ハードウェアの操作説明書・取扱説明書

　家電製品，パソコンといったハードウェアの「取扱い説明書」は，分厚いものが多く，「ほとんど読まない」という声も聞かれます。そこで，一ページにコンパクトにまとめた要約版，インターネットを活用してのオンラインマニュアルなど，使いやすくわかりやすさの工夫が求められています。

◆「分厚い」「難しい」に対応

　マニュアル（取扱説明書）が分厚くなった理由の一つに，製品の高機能化，多機能化があげられます。加えて，説明書の冒頭に，「安全上のご注意」がずらりと並ぶことに見られるように，1995年施行の製造物責任法（ＰＬ法）による警告表示の徹底も，マニュアルのボリュームを増やしています。

　「分厚い」「わかりづらい」などの声が増えたことから，企業側は企業側は，マニュアルのコンパクト化を目ざし，工夫を凝らしての取扱い説明書作りに乗り出しています

　Ａ社は，洗濯機や冷蔵庫などで，説明書を見やすいカラー刷りにし，ページ数は従来の7割ほどに絞り込むよう見直しを進めています。Ｂ社のテレビでも，下敷きほどの大きさ1枚に設置の仕方をまとめたガイドが添えられています。

　インターネットを通じて，操作説明や取扱い説明書を提供するメーカーは増加しています。ここでは，「電子トリセツ」などと呼ばれ，動画で使い方を解説したり，検索機能で調べたいページにたどり着けるようにしたりするなど，インターネット機能を生かすなど工夫を凝らしています。
　
　さらに，文章だけではなかなか伝わりにくい使い方のコツを実感としてつかんでもらうために，売り場でのアドバイスに力を入れる企業もあります。

・なぜ，そうするのか−理由・根拠を示して納得させる

　　「××メニューの××をクリックしてください」とか「××ボタンをクリックしてください」というように，手順を指示しでいるだけで，「どうしてそうしなければならないのか」なぜ，そうすべきなのか」」といった，理由や根拠を示さないと，読者は操作の目的や理由を理解できません。目的や理由がわからないと，手順そのものの理解度も低くなります。「言われた通りにやったらできたけど，なんだかよくわからない」というモヤモヤした気持ちを，読者はずっと持つことになり，不満が残ります。

　操作を説明する場合は，いきなり手順を説明するのではなく，
　　・これから何を行なうのか？
　　・なぜ，その操作を行なうのか？
　を述べます。説明することにより，お客様は操作の目的や見通しを持つことができ，心の準備ができます。明確な目的や見通しを持ち，納得して操作できるので，内容の理解も深まります。

・わかりにくいときは，図で示す

　説明や理由，あるいは根拠を示す場合，専門用語はできるだけ使わず，平易な表現とします。図を付記するのも効果的です。

3）　リファレンス（辞書）・百科事典・逆引き辞典

　アプリケーションプログラムを使用するための仕様や規則，条件など全機能の詳細などについて辞書形式で厳密に詳述した文書がリファレンスです。随時，必要な項目や機能，コマンドを検索できるよう目次の工夫や検索のしやすさを重視した編成とします。

　マニュアルの文体は読みやすさの観点から，通常は「ですます調」が適します。ただし，リファレンス（辞書）は，簡潔表現という観点からは，「である調」が適しています。

4）　事例集────啓蒙書

　業務処理と対応させてシステムの具体的な使い方の事例を紹介するものです。

5）　セットアップ・ガイド

　実際にシステムを使う前に行わなくてはならない準備作業を記述したマニュアルです。

○操作をわかりやすく説明するためのポイント

　　　　　　　　　　　　　　　　　　　　　　┌─知っておくべきこと
　　　１．情報の階層化をはかる─┤
　　　　　　　　　　　　　　　　　　　　　　└─知っていると便利なこと
　　　２．目標（またはあるべき姿）を明らかにする
　　　３．全体の流れを示す
　　　４．目標・操作の全体像と部分の関連を明らかにする
　　　５．状態→操作→状態の流れを示す
　　　６．類似の操作は，相違点を明示する
　　　７．操作の結果を明示する
　　　８． 操作の取消の仕方，障害対策を逐次伝える

○　システム開発に関連したドキュメント類−−『書き込み中』

　通常システム開発は，基本設計，詳細設計，プログラミング，テストという流れで進められます。この流れに対応してのドキュメントは,�@ユーザーの要求をまとめた「要求仕様書」，�Aシステムやソフトウエアの構成をまとめた「システム設計書」，�Bプログラムの動作を明確に記述した「プログラム設計書」，�Cテストシステムのしくみととそのデータを記述した「テスト仕様書」，などがあげられます。
　システム開発での仕様書は，ユーザー要求仕様書（プログラム依頼書）に始まり，システム設計，運用設計，プログラム設計，テスト運用，導入（移行）設計そして運用ルールといったように，開発から導入にいたる一連の段階とその作業工程に合わせて，それぞれの工程別に仕様書を用意します。　なお，ドキュメントの書き方は，採用したシステム開発技法によるところが多です。例えば，“データ処理や操作を手続きの流れとしてではなく，もの（オブジェクト）同士の関係としてとらえるオブジェクト指向プログラミングによるならば，オブジェクト指向モデルを表現するためのグラフィカル言語であるUML（Unified Modeling Language）対応”といったように，開発技法に対応した記述方法をとるようにします。　

�@ユーザー要求仕様書（要件定義書・プログラム依頼書-requirements specification）

　ソフトウエア開発で見舞われるトラブルの原因の多くは，要求仕様に起因します。

　ユーザー（依頼者・発注者・顧客）は，「何をするために，何が必要なのか」といったシステムの目的とシステム概要，それを実現するための機能，依頼事項，保証要件などの顧客要求事項を確認し，これに対応したシステム全体に関する仕様を，文書にまとめます。
　本来，ユーザー仕様書は顧客が作成すべきものですが，システム開発の専門家ではない顧客に，必要十分な要求仕様書の作成は期待できません。そこで，「要求仕様書は，システムサイド（ＳＥ）が作成するもの」とし，顧客の要望を網羅した要求仕様書の作成が望まれます。
　ユーザー要求仕様書の主要な内容構成を一覧します。

• システムの目的

• システム概要，性能，運用・動作環境

• 開発環境（使用するハードウエアとソフトウエア）

• 入力データと出力データ

• 操作，取扱方法

• 開発スケジュール

• 開発体制

• 開発言語

• リスク対策（耐障害性）

• テストラン

• データバックアップ

�A開発段階での仕様書

　開発や設計に関する決定事項や指示事項を文書にすることで，それらの内容をプロジェクトに関連する人たちに確実に伝達するのが，開発段階における仕様書の目的です。 　
　　『書き込み中』　画面デザイン　画面デザインや操作性-----<

�Bプログラム設計書−−−書き込み中

　小規模システムでは，人的余裕がなければ，プログラムの仕様書は不要。プログラム仕様書より，・・・（書き込み中）

�Cテスト仕様書

　ひと口にテストといっても，個々のプログラムをチェックする「単体テスト」，プログラム間のデータのやりとりをチェックする「統合テスト」，そして機能面，性能面，運用面でユーザーの発注仕様を満たしているかどうかをチェックする「システムテスト」，システムが「要求仕様書」通りに仕上がっているかをチェックする「受け入れテスト」とさまざまです。さらに，システムテストは「機能テスト」「回帰テスト」「負荷テスト」「障害テスト」「運用テスト」とに分けられます。

　　『書き込み中』

７−３　システムの運用に関連したマニュアル　

　運用中のソフトウエアが所定の機能を保持し，正常に実行できるよう維持管理していくべく，システムの運用に携わる部門向けのマニュアルとして，運用・管理マニュアルと障害対応マニュアルの二つを取り上げます。

�@運用・管理マニュアル

　「運用・管理マニュアル」は，システムやコンピューターを管理している部門が用いるマニュアルです。入退出管理，データおよびプログラムの保管管理，電源施設，防犯施設，………といった事柄を記述します。主な構成項目を以下に列挙します。
　・コンピュター運用規定
　・システム関係
　・操作関係
　・安全対策
　・運用関係
　・運用基準

�A障害対応マニュアル　

　いくら完璧を期したシステムでも，障害の発生を防ぐことは至難です。そこで障害が発生したときに素早く対処できるようマニュアルを作成しておきます。障害対応マニュアルの主な内容構成項目を示します。
　・障害対策チームの緊急招集
　・ハードウｪア障害対応
　・システム障害対応
　・最悪事態への対応−
　・障害対応終了後の後始末−再発防止策，報告・ユーザとの折衝など