X 0153：2015 (ISO/IEC 26514：2008)
（1）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
目 次
ページ
序文 ··································································································································· 1
1 適用範囲 ························································································································· 2
2 適合性···························································································································· 4
2.1 適合性の適用 ················································································································ 4
2.2 適合性の状況 ················································································································ 4
3 引用規格 ························································································································· 5
4 用語及び定義 ··················································································································· 5
5 システム及び／又はソフトウェアのライフサイクルにおける利用者用の文書化プロセス ··············· 11
6 プロジェクトの要求事項，目標，及び制約条件 ····································································· 14
6.1 プロジェクトの目標 ······································································································ 14
6.2 利用者用文書類の要求事項及び制約条件 ············································································ 15
6.3 プロジェクトの目的及び制約条件····················································································· 16
6.4 利用者及び使用性の目標 ································································································ 17
6.5 技術連絡担当者及び他の専門家へのインタビュー ································································ 19
6.6 プロジェクト計画 ········································································································· 20
6.7 文書類の提案 ··············································································································· 24
7 分析及び設計 ·················································································································· 25
7.1 読者層分析及び作業分析 ································································································ 25
7.2 利用者用文書類の設計 ··································································································· 31
8 作成及びレビュー ············································································································ 32
8.1 プロトタイプ及び草稿 ··································································································· 33
8.2 文書類の評価 ··············································································································· 35
8.3 文書類のテスト ············································································································ 40
9 制作······························································································································ 41
9.1 最終的な組立て及びレビュー··························································································· 41
9.2 承認 ··························································································································· 42
9.3 構成管理 ····················································································································· 42
9.4 更新及び保守 ··············································································································· 42
10 文書類の構造 ················································································································ 43
10.1 文書類の全体的な構造 ·································································································· 43
10.2 読者層のニーズに従った文書類の構造 ············································································· 44
10.3 画面上の文書類のトピック項の大きさ ············································································· 46
10.4 利用者用文書類の構成要素 ···························································································· 47
10.5 利用者用文書類の構成要素の配置 ··················································································· 47
11 利用者用文書類の情報の内容 ··························································································· 48
X 0153：2015 (ISO/IEC 26514：2008) 目次
（2）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ページ
11.1 情報の完全性 ·············································································································· 48
11.2 情報の正確性 ·············································································································· 49
11.3 識別データの内容 ········································································································ 49
11.4 文書類の利用のための情報 ···························································································· 50
11.5 運用の概念 ················································································································· 50
11.6 ソフトウェアの一般的な利用のための情報 ······································································· 52
11.7 手順及び学習書のための情報 ························································································· 52
11.8 ソフトウェアの命令についての情報 ················································································ 54
11.9 データ入力欄の説明 ····································································································· 55
11.10 エラーメッセージ及び問題解決の内容 ············································································ 55
11.11 警告及び注意の内容 ···································································································· 56
11.12 専門用語の情報 ·········································································································· 57
11.13 関連情報に関する情報 ································································································· 57
11.14 利用者が提供した内容 ································································································· 58
12 文書類の提示体裁 ·········································································································· 59
12.1 一般 ·························································································································· 59
12.2 印刷用の体裁又は画面上の体裁の使用 ············································································· 59
12.3 適切な媒体及び体裁の選択 ···························································································· 60
12.4 状況依存の情報 ··········································································································· 63
12.5 アクセスしやすい文書類 ······························································································· 64
12.6 体裁の一貫性 ·············································································································· 65
12.7 専門用語の一貫性 ········································································································ 66
12.8 画面及びページのレイアウト ························································································· 67
12.9 視認性 ······················································································································· 70
12.10 リストの形式 ············································································································ 72
12.11 ユーザインタフェース要素を表すための体裁 ··································································· 73
12.12 色の使用 ·················································································································· 74
12.13 ナビゲーションの機構 ································································································ 75
12.14 情報を発見するための文書類の体裁 ··············································································· 78
12.15 警告，注意，及び注のための体裁 ·················································································· 81
12.16 指示のための体裁 ······································································································ 81
12.17 利用者が付けた注釈のための体裁 ·················································································· 81
12.18 図表のための体裁 ······································································································ 82
12.19 アイコン及び目印 ······································································································ 86
12.20 文書類の包装 ············································································································ 88
附属書A（参考）利用者用文書類のスタイルガイドの内容 ··························································· 89
附属書B（参考）利用者用文書類のための文体及び手法 ······························································ 90
附属書C（参考）翻訳及び地域化のための利用者用文書類のスタイル ············································ 95
附属書D（参考）印刷した情報の設計，作成，及び制作······························································ 96
X 0153：2015 (ISO/IEC 26514：2008) 目次
（3）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ページ
附属書E（参考）利用者用文書類のためのチェックリスト ·························································· 107
附属書F（参考）文書化プロセスのための要求事項の箇条及びチェックリスト ······························· 113
附属書G（参考）文書類製品のための要求事項の箇条及びチェックリスト ····································· 118
参考文献 ··························································································································· 133
X 0153：2015 (ISO/IEC 26514：2008) 目次
（4）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
まえがき
この規格は，工業標準化法第12条第1項の規定に基づき，一般社団法人情報処理学会（IPSJ）及び一般
財団法人日本規格協会（JSA）から，工業標準原案を具して日本工業規格を制定すべきとの申出があり，
日本工業標準調査会の審議を経て，経済産業大臣が制定した日本工業規格である。
この規格は，著作権法で保護対象となっている著作物である。
この規格の一部が，特許権，出願公開後の特許出願又は実用新案権に抵触する可能性があることに注意
を喚起する。経済産業大臣及び日本工業標準調査会は，このような特許権，出願公開後の特許出願及び実
用新案権に関わる確認について，責任はもたない。
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
日本工業規格 JIS
X 0153：2015
(ISO/IEC 26514：2008)
システム及びソフトウェア技術−利用者用文書類の
設計者及び作成者のための要求事項
Systems and software engineering-
Requirements for designers and developers of user documentation
序文
この規格は，2008年に第1版として発行されたISO/IEC 26514を基に，技術的内容及び構成を変更する
ことなく作成した日本工業規格である。
なお，この規格で点線の下線を施してある参考事項は，対応国際規格にはない事項である。
アプリケーションソフトウェアの利用者は，自分の作業を完了するためにそのソフトウェアがどのよう
に支援してくれるのかについての正確な情報を必要としている。文書類は利用者が目にする最初に手に取
ることができる品目かもしれず，したがって，ソフトウェア製品に対する利用者の第一印象に影響する。
情報が便利な形式で供給され，見つけやすくて，理解しやすいならば，利用者は製品の利用にすぐに慣れ
ることができる。したがって，よく設計された文書類は，利用者を補助して，訓練及び支援のコストを削
減するのを助けるばかりでなく，製品，製造業者，及び供給者の評判を高める。
ソフトウェア開発者は，文書類を最小限するために，直感的に動作するユーザインタフェースを設計す
ることに注力しているが，容易ではない。今日のソフトウェアは，アプリケーションの内部にとどまらず
アプリケーション相互に知的に情報をやり取りする，強固な機能を提供してきている。さらに，ほとんど
のソフトウェア設計には，利用者がそのソフトウェアを使って得ることができる結果に影響を与える，基
本的な規則及び計算，又はアルゴリズムを含んでいる。そのような基本的なプログラミング機構は，利用
者によって認識できるが，面倒な（多くの時間及び労力を要する）テストが必要である。これらの理由及
びその他から，依然として利用者用文書類は，使用できるソフトウェア製品の主要な構成要素である。
文書化はしばしば，ソフトウェアの実装後に行われる付加的なものとみなされる。しかしながら，高品
質なソフトウェア文書類については，その作成はソフトウェアライフサイクルプロセスの不可欠な部分と
みなすべきである。適切に行うならば，文書化又は情報管理は，それ自体でプロセス計画を必要とする十
分大きな仕事である。
この規格は，JIS X 0160:2012及びJIS X 0170:2013の利用者が，ソフトウェアライフサイクルの一部と
して文書類を設計及び作成するのを助けるために開発された。この規格は，文書類の作成者の立場から文
書化プロセスを定義している。
注記 管理者，アセッサ及び試験者，並びに取得者及び供給者の観点から文書類及び情報管理プロセ
スを扱うために，ISO/IEC 265NNファミリーの他の国際規格が，準備又は計画されている。
標準のプロセスを定義することに加えて，この規格は文書類の製品も扱っている。この規格は，文書類
の構造，内容，及び体裁を規定しており，また，利用者用文書類のスタイルの有益な指針も提供する。
以前の規格は，文書化プロセスの結果を1冊の本（又は数冊の本の集合），すなわち，一度限りの納入物
2
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
とみなしていた。これに対し，“ほとんどの利用者用文書類は，以前に作成された情報（単一源の文書類）
を，ソフトウェアの新しい版に適応するように，又は様々な画面上及び印刷媒体での提示に適応できるよ
うに，管理・再利用することによって作られている。”と文書類の設計者が考えるようになってきている。
この規格は，コンテンツ管理システム（CMS）をどのように設定するかは記述していないが，単一源から
の文書化を実践している文書化組織に適用できる。
この規格は，文書類の作成に使用してもよいソフトウェアツールから独立していて，かつ，印刷した文
書類及び画面上の文書類の両方に適用される。ソフトウェアの利用者用文書類と同様に，ハードウェアを
含むシステムのための利用者用文書類に，この規格のほとんどの指針を適用できる。
この規格は，ソフトウェア利用者用文書類のためのJIS X 0160:2012の7.2.1に適合する。この規格は，
文書化の製品，プロジェクト，及びJIS X 0170:2013又はJIS X 0160:2012への適合を主張する組織のため
の適合性又は指針の文書として用いてもよい。
この対応国際規格のための一次資料は，以前の規格であるIEEE Std 1063-2001，及びISO/IEC 18019:2004
である。
1
適用範囲
この箇条は，この規格の適用範囲，目的，組織，及び対象となる用途を示す。
この規格は，一貫性があり，完全で，正確で，かつ，使用可能な文書類について規定することによって，
ソフトウェア利用者の利便を図る。この規格は，標準化における次の二つの取組の両方を含む。
a) 文書類の製品を作成する方法を規定する，プロセスの標準化。
b) 文書類の特性及び機能の要求事項を規定する，文書類製品の標準化。
この規格の最初の部分（箇条5〜箇条9）は，文書類の設計者及び作成者のための利用者用文書化プロセ
スを扱っている。この規格は，情報の利用者が必要とするものを確立する方法，その情報を利用者にどの
ように提示することが望ましいかを決定する方法，並びに情報の準備及び情報を利用可能にする方法を示
す。この規格は，ライフサイクルの設計フェーズ及び開発フェーズに限らず，情報管理プロセス及び文書
化プロセス中のアクティビティを含んでいる。
この規格の第二の部分（箇条10〜箇条12）は，ソフトウェアを含むシステムの利用者が作業環境で使用
する，印刷した文書類及び画面上の文書類の両方について，利用者用文書類の構造，情報の内容，及び体
裁のための最小限の要求事項を与える。この規格は，印刷された利用者マニュアル，オンラインヘルプ，
学習書，及び利用者参照文書類に適用される。
この規格は，印刷媒体若しくは電子的な（画面上の）媒体を文書化のために使うこと，又は文書類の作
成・管理を行う特定のツール若しくは方法論を使うことを，奨励するものではないし，また，それらを使
わないことを奨励するものでもない。
この規格は，次の種類の文書類について，全ての側面を網羅するものではないが，作成するときに役立
ててもよい。
− ソフトウェア以外の製品の文書類
− アニメーション，ビデオ，及び音を使用するマルチメディアシステム
− 主として正式な訓練プログラムでの使用を意図した，コンピュータ利用の教育訓練（CBT）パッケー
ジ及び専門課程教材
− 実装者，コンピュータ運用者，又は最終利用者ではないシステム管理者のために制作された文書類
− システムソフトウェアの内部の運用について記述する保守文書類
3
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− ユーザインタフェース自体に組み込まれた文書類
この規格は，次に示す様々な専門家を含む文書類の設計者及び作成者が利用できる。
− 文書類の集合における，文書類製品の構造及び体裁を計画する情報の設計者及びアーキテクト（構成
方法設計者）
− 意図している利用者がそのソフトウェアで実行する作業を識別する，使用性に関する専門家及び業務
分析者
− 利用者用文書類のための内容を作成及び編集する人
− 電子媒体の専門技術をもつグラフィックデザイナ
− 画面に表示される文書類の体裁を設計するために一緒に働いている，ユーザインタフェース設計者及
び人間工学の専門家
また，この規格は次に示す文書化プロセスへのその他の役割及び関心をもつ人々が参照してもよい。
− ソフトウェア開発プロセス又は文書化プロセスの管理者
− 供給者によって準備された文書類の取得者
− 使用性の試験者，文書類のレビュア，対象領域専門家
− 画面上の文書類を作成するためのツールの開発者
− 文書類をよりアクセスしやすく，かつ，利用しやすくするための原則を識別する人間工学の専門家
この規格は，文書化のための専門部署が存在するかどうかにかかわらず，あらゆる種類の組織での利用
を意図しているが，ある組織内だけで使う標準及び手順の基礎として利用してもよい。読者には，ソフト
ウェア開発プロセス又は文書類作成プロセスに関する経験又は知識があることを仮定している。
この規格の利用者は，自分の組織の中で利用するスタイルマニュアルを，この規格の附属書で提供する
指針を補完するために採用するか，又は業界で受け入れられているスタイルガイドを採用することが望ま
しい。附属書Aはスタイルガイドの内容についての指針を提供し，かつ，附属書B及び附属書Cはスタ
イルの指針を提供している。
この規格における箇条の順番は，文書類がこの順番で作成される，又はこの順番で利用者に提示される
ことが望ましいことを意味してはいない。
各箇条では，要求事項はできる限り媒体と独立している。印刷又は電子媒体のいずれかに特定の要求事
項は，それが分かるように，特に箇条12で識別している。附属書Dは印刷した文書類の設計のための指
針を提供する。
附属書Eのチェックリストは，適切なステップが実行され，かつ，完成した文書類が品質基準を満たし
ていることを確認するために，文書化プロセスの各フェーズで利用してもよい。
附属書F及び附属書Gのチェックリストは，文書化プロセス及び製品のためのこの規格の要求事項への
適合性の追跡に利用してもよい。
参考文献には，利用者用文書類の管理，準備，及びテストのプロセスの指針を提供する著作物を列挙し
ている。
注記 この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。
ISO/IEC 26514:2008，Systems and software engineering−Requirements for designers and developers
of user documentation（IDT）
4
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
なお，対応の程度を表す記号“IDT”は，ISO/IEC Guide 21-1に基づき，“一致している”こ
とを示す。
2
適合性
この規格は，JIS X 0170:2013又はJIS X 0160:2012への適合を主張するプロジェクト及び組織に対して
適合性の文書又は指針の文書として利用してもよい。
2.1
適合性の適用
組織又はプロジェクトが，選択されたソフトウェアライフサイクルプロセスを修整したか，又はそれら
を全て採用したかにかかわらず，組織又はプロジェクトは，その文書化プロセス，文書類，又はそれら両
方についてこの規格への適合性を主張してもよい。
この規格は，必要かつ費用対効果に優れた要求事項だけを文書化に適用するように，修整されることを
意図している。修整は，特定のソフトウェア製品及び文書類製品によって明らかに反映するために，この
規格の必須の要求事項に適合する取組を指定するか，又は必須ではない推奨事項及び取組を変更する形を
とってもよい。取得者が行う修整は，契約のときに明記することが望ましい。
この規格を通して，“…しなければならない”は従わなければならない規範を表し，“…することが望ま
しい”は幾つかの可能性の中での推奨を表し，“…してもよい”はこの規格の限界の中で許される行動を示
す。この規格を，指針として利用するときには，用語“…しなければならない”を“…してもよい”に置
き換える。この規格への適合性を主張するために，利用者用文書類の部品（すなわち，章，トピック項，
ページ，画面，ウィンドウ）に対して，この規格の用語体系を用いる必要はない。
注記 “…しなければならない”を含む全ての規定は，附属書F及び附属書Gに列挙されている。
2.2
適合性の状況
利用者用文書類の適合性は，様々な状況に応じてそれぞれに解釈される。適合性の主張の前提となる状
況は，適合性の主張の中で，次のように明示しなければならない。
1) 組織が適合性を主張するとき，組織は，ライフサイクルプロセスの修整を宣言する文書を公表しなけ
ればならない。
注記1 ある組織が，“文書化計画”を引用する箇条を扱う方法の一つは，それらが組織内のいずれ
の特定の文書化プロジェクトのためのプロジェクト計画の中でも解釈されなければならな
いことを指定することである。
2) プロジェクトが適合性を主張するとき，プロジェクト計画又は契約は，文書類の要求事項の修整を文
書化しなければならない。
注記2 プロジェクトの適合性の主張は，通常は組織の適合性の主張に沿って指定される。
3) 多供給者（プロジェクトの上位概念としての）プログラムが適合性を主張するとき，必要なアクティ
ビティを全て要求する契約が一つもないために，個々のプロジェクトのどれもが適合性を主張できな
いことがあってもよい。それにもかかわらず，必要なアクティビティのそれぞれが識別された当事者
によって実施される場合，プログラム全体として適合性を主張してもよい。プログラム計画は，“契約”
を参照するこの規格の箇条の解釈と同様に，要求されたタスクの修整，及び様々な当事者への割当て
を文書化しなければならない。
4) 文書類の製品に対して適合性を主張するとき，組織又はプロジェクトは，組織のコンテンツ管理プロ
セスを通して制作されたただ一つの文書，文書類の集合，又は全ての利用者用文書類のいずれに対し
て適合性が適用されるのかを指定することが望ましい。
5
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
二つの当事者（取得者，及び制作者又は供給者と呼ばれる。）が，この規格に従って供給者が文書類を提
供することに合意するとき，この規格は契約又は同様の合意に含めるか又は参照されてもよい。また，こ
の規格に従って文書類を制作すると決めたプロジェクト又は組織によって，社内の標準として採用されて
もよい。
3
引用規格
次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。これらの
引用規格は，記載の年の版を適用し，その後の改正版（追補を含む。）は適用しない。
JIS X 0160:2012 ソフトウェアライフサイクルプロセス
注記 対応国際規格：ISO/IEC 12207:2008，Systems and software engineering−Software life cycle
processes（IDT）
JIS X 0170:2013 システムライフサイクルプロセス
注記 対応国際規格：ISO/IEC 15288:2008，Systems and software engineering−System life cycle
processes（IDT）
4
用語及び定義
この規格で用いる主な用語及び定義は，次による。
注記1 この規格を通して，用語“文書類”はソフトウェア利用者用文書類を示す。この規格におけ
る専門用語の使用は，参照を容易にするためであって，この規格への適合のためには強制的
ではない。
注記2 対応国際規格では，用語の参照先として，IEEE Std 100を引用しているが，この規格では不
要であり削除した。
4.1
アクセシビリティ（accessibility）
様々な能力をもった幅広い層の人々が使うときの，ソフトウェア製品若しくは文書類製品，サービス，
環境，又は施設の使用性。
注記1 JIS X 8341-6を基に変更を加えた。
注記2 “アクセシビリティ”は，通常，障害のある利用者を扱うが，概念は，障害に関わる事柄だ
けには制限されない。
4.2
動作（action）
利用者が一つの手順の中で実行するステップの要素。
4.3
アクティブ領域（active area）
利用者入力に反応する（画面上の文書類の）領域。
注記 グラフィック上のホットスポット及び文字列中のリンクは，アクティブ領域の例である。
4.4
分析（analysis）
利用者の種類と情報のニーズとを特定することを目指す開発の調査及び収集のフェーズ。
6
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
4.5
アプリケーションソフトウェア（application software）
コンピュータ自体を制御するソフトウェアとは異なるものとして，利用者が特定の作業を実行したり，
又は特定の種類の問題に対処するのを助けるように設計されたソフトウェア。
比較参照 ソフトウェア
注記 アプリケーションソフトウェアをアプリケーションと略記する。
4.6
読者層（audience）
同じ又は同様の特性及びニーズ（例えば，その文書類を利用する理由，作業，教育水準，能力，教育訓
練，経験）を共有する利用者のカテゴリ。
注記 意図した文書類の内容，構造，及び使用法を定める様々な読者層（例えば，管理担当，データ
入力担当，保守担当）があってもよい。
4.7
注意（caution）
何らかの動作の実行が，データの喪失又は設備での問題発生のように，望まない又は未定義の結果をも
たらすかもしれないことを述べる，文書類中の助言的な情報。
比較参照 警告
4.8
変更管理手順（change control procedure）
開発中のソフトウェアの製品又は文書類の製品への変更を識別し，文書として記録し，見直し，かつ，
承認するためにとられる動作。
注記 その手順は，変更の妥当性が確認され，他の項目への影響が調べられ，かつ，開発に関係する
人々がその変更について通知されることを確実にする。
4.9
構成管理，CM（configuration management，CM）
構成の識別，制御，状態の記録，及び監査を包括する技術的及び組織的なアクティビティ。
注記 ISO 10007:2003，品質マネジメントシステム−構成管理の指針を参照。
4.10
状況依存ヘルプ（context-sensitive help）
表示される情報が，ソフトウェアの利用者の視点に依存している画面上の文書類の種類。
比較参照 組込文書類，印刷した文書類
4.11
重大情報（critical information）
ソフトウェアの安全な使用，ソフトウェアによって作成された情報のセキュリティ，又はソフトウェア
によって作成されたか若しくは格納されたかした機密の個人情報の保護，を記述している情報。
4.12
カスタマイズ（customization）
特定の読者層のニーズへのソフトウェア又は文書類製品の適応。
4.13
設計（design）
7
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
製品としてどんな文書類を提供するのか，また，その文書類はどんな性質なのかを決定することに関す
る文書類の作成段階の一つ。
4.14
作成（development）
設計が済んだ後に文書類を準備するアクティビティ。
4.15
文書（document）
文書類の一つの集合の一部であってもよい別々に識別される一つの文書。
4.16
文書類（documentation）
ソフトウェア製品を使用する方法を説明する情報。
注記1 文書類は，分離形文書類若しくは組込文書類又は両方として提供できる。
注記2 この規格では，用語“文書類”は用語“利用者用文書類”及び“ソフトウェア利用者用文書
類”と同義である。他の形式の文書類（例えば，“システム文書”）はそのように明確に識別
する。
注記3 印刷したマニュアル，画面上の情報，及び単独で動作するオンラインヘルプは文書類の例で
ある。
4.17
文書集合（document set）
配布又は利用の容易さのために別々に識別される分冊又はファイルに区分された文書類の集合。
4.18
組込文書類（embedded documentation）
ソフトウェアの一部としてアクセスされる文書類。
比較参照 分離形文書類
注記 画面上のポップアップヘルプ及びヘルプ文は組込文書類の例である。
4.19
入力欄（entry field）
画面上又はウィンドウ内で利用者がデータを入力する領域。
4.20
第三者預託（escrow）
指定された契約上の条件が満たされるまで第三者の保護監督の下に保持されるソースコード及び文書類。
4.21
機能（function）
利用者がその作業を実行するための手立てを与えるアプリケーションの一部。
4.22
アイコン（icon）
コンピュータシステムの機能を表す，画面に表示されたグラフィック。
注記 JIS X 9303-1:2006の4.7を基に変更を加えた。
4.23
図表（illustration）
8
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
本文の文字列とは別に設定され，かつ，普通は本文中で引用されるグラフィック。
注記1 この規格では，用語“図表”を表，図，展示，スクリーンキャプチャ，流れ図，線図，絵画，
アイコン，及びその他のグラフィックの種類の総称用語として用いている。
注記2 “スクリーンキャプチャ”は，画面又はその他の視覚出力装置に表示されたものを画像とし
て保存したもののことをいう。
4.24
実装（implementation）
設計，テスト，及び改訂に従って利用者用文書類が作成される開発のフェーズ。
4.25
教習モード（instructional mode）
作業を実行するときにソフトウェアの使用法を教えることを意図する利用モード。
4.26
国際化（internationalization）
国際的な読者層に適するように情報を作成するプロセス。
比較参照 地域化
4.27
リンク（link）（画面上の文書類の場合）
新しいトピック項又は現在のトピック項の異なる部分を表示するアクティブ領域。
4.28
地域化（localization）
製品の各国版又は特定の地方版の作成。
比較参照 国際化
注記 地域化は各国版への翻訳プロセスとは別に実行してもよい。
4.29
メニュー（menu）（画面上の文書類の場合）
利用者がそこから選ぶトピックのリスト。
4.30
ナビゲーション（navigation）
文書類へのアクセス及び異なるトピック項を見る行為。
4.31
画面上の文書類（on-screen documentation）
ソフトウェアを利用している間，利用者が画面上で読むことを意図した文書類。
比較参照 印刷した文書類，組込文書類
注記 画面上のポップアップヘルプ及び説明文は画面上の文書類の例である。
4.32
画像（picture）
対象物の実際の外観を示している図表。
注記 写真及び絵画は画像の例である。
4.33
印刷した文書類（printed documentation）
9
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
印刷した形式で提供するか，又は自分で印刷する顧客若しくは利用者のために電子的な形式で提供する
文書類。
4.34
手順（procedure）
作業を実行する方法を指定する，順番を付けた一連のステップ。
4.35
プロセス（process）
インプットをアウトプットに変換する，相互に関連する又は相互に作用する一連の活動。
（JIS Q 9000:2006）
4.36
製品（product）
ソフトウェア及び文書類の完全な集合。
4.37
製品権限者（product authority）
製品の能力及び品質に対して全体的な責任をもっている人又は人々。
4.38
プロジェクト（project）
新製品の開発又は既存の製品の強化のための一連の活動。
4.39
プロジェクトマネージャ（project manager）
プロジェクトの管理及び稼働に対して全体的な責任をもつ人。
4.40
品質管理（quality management）
品質に関して組織を指揮し，管理するための調整された活動。
（JIS Q 9000:2006）
4.41
現実世界のオブジェクト（real-world object）
三次元の形状で存在し，かつ，連想によって，ソフトウェアの機能と同様の特性又は振る舞いを暗示す
る実体。
注記 プリンタ，ファイルキャビネット，ファイルフォルダ及び1枚の紙は，現実世界のオブジェク
トの例である。
4.42
参照モード（reference mode）
一般にソフトウェアの機能に慣れているソフトウェア利用者のために，特定の情報への迅速なアクセス
を提供することを意図する利用モード。
4.43
副ウィンドウ（secondary window）
別のウィンドウ（主ウィンドウ）の情報に依存した情報を含むウィンドウ。
注記 副ウィンドウの情報は，主ウィンドウの情報を補足する。
10
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
4.44
分離形文書類（separate documentation）
ソフトウェアとは無関係に使用されてもよい文書類。
比較参照 組込文書類
注記 印刷したマニュアル及び独立しているハイパーテキストシステムは，分離形文書類の例である。
注記0A “ハイパーテキスト”とは，“文章の一部をキーワードとして，文章間に様々な関係付けを行
って関連情報を参照できるようにした文章”のことをいう。
4.45
目印（signpost）
情報の特定の種類がある場所又は現在表示している情報が全体の文書のどこに当てはまるのかを利用者
が識別することを助ける文，記号又は小さいグラフィック。
注記 異なる種類の情報は，異なる種類の記号又はグラフィックによって示してもよい。
4.46
ソフトウェア（software）
コンピュータを機能させるために使用するプログラム又はプログラムの集合。
比較参照 アプリケーションソフトウェア
注記 この規格では，用語“ソフトウェア”には画面上の文書類を含まない。
4.47
ステップ（step）
利用者が一つ（又は複数）の動作を実行することを指令する（番号付き項目のリストである）手順の中
の一つの要素。
注記 ソフトウェアによる応答は，ステップとは考えない。
4.48
スタイル（style）
文書類の文法，専門用語，句読点，大文字化，及び単語選択を含む言語特有の編集上の取決めの集合。
4.49
技術連絡担当者（technical contact）
ソフトウェア製品に関する技術資料を文書類作成者に提供する，又は文書類の草稿の技術的な正確性を
確認することに責任がある人。対象領域専門家とも呼ぶ。
4.50
トピック項（topic）
文書の小さい部分であって，一つの主題を扱うもの。
注記1 印刷した文書類では，トピック項は節（見出し，小見出し）及びその内容と同等である。画
面上の文書類では，トピック項は，主題（典型的には，作業，概念又は参考情報）に関する
題名（見出し）及び情報から成る。
注記2 画面上の文書類に対して，システムは，利用者の介在なしでトピック項を提示してもよい。
注記3 現在の文書を印刷する方法の指示は，トピック項の例である。
4.51
学習書（tutorial）
ソフトウェア又は文書類とともに供給され，利用者が見本のデータを利用してソフトウェアの機能を練
11
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
習する教習モードの文書類。
4.52
使用性（usability）
ソフトウェア又は文書類の製品が，指定された利用者によって，指定された利用の状況下で，指定され
た目的を達成するために用いられるときの，有効さ，効率及び利用者の満足度の度合い。
注記 JIS Z 8521:1999の3.1を基に変更を加えた。
4.53
利用モード（usage mode）
文書類の作成者が，文書が使用されると期待する主なやり方。
注記 この規格は，教習モード及び参照モードの二つの利用モードを考えている。
4.54
利用者（user）
ソフトウェアで一つ以上の作業を実行する人。特定の読者層の一員。
4.55
利用者用文書類（user documentation）
ソフトウェアの使い方を記述，説明，又は指示する情報。
比較参照 文書類
注記 印刷した利用者マニュアル，組込みの画面上の情報，及びヘルプは利用者用文書類の例である。
4.56
ユーザインタフェース（user interface）
利用者とコンピュータシステムとの対話を許すソフトウェア及びハードウェアの集合体。
4.57
警告（warning）
ある動作の実行によって，重大又は危険な結果を導くかもしれないことを提示する文書類における助言
的な情報。
比較参照 注意
4.58
ウィンドウ（window）
目に見える境界をもつ領域であって，ソフトウェアオブジェクトを表示するもの又は利用者とコンピュ
ータシステムとの対話の場を提供するもの。
4.59
ウィザード（wizard）
利用者との対話によって作業の各ステップを通して利用者を案内する手続的なヘルプの形式。
5
システム及び／又はソフトウェアのライフサイクルにおける利用者用の文書化プロセス
この規格は，利用者用文書類を設計，指定，及び制作するのに含まれるフェーズを扱う。
利用者用文書類の設計者及び作成者は，JIS X 0160:2012で定義されるソフトウェア製品のライフサイク
ルプロセスの中で働く。JIS X 0160:2012では，ソフトウェア支援プロセスにソフトウェア文書化の管理
（7.2.1）を含めている。
したがって，利用者用文書類の作成は，ソフトウェア製品のライフサイクルと同じプロセスの一部であ
12
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
り，かつ，ソフトウェア及び利用者用文書類が一緒にテスト，配布，及び保守が行われてもよいように，
理想的にはソフトウェアの開発と同時に実行されることが望ましい。画面上の文書類及び印刷した文書類
を含め，全ての文書類の仕様は，別個の課題ではなく，全体としてソフトウェア製品の開発の一部である
ことが望ましい。ソフトウェア製品を完全に開発し終わるまで，正確な利用者用文書類は完成できなくて
もよいが，利用者用文書類及びソフトウェア製品はいずれも並行に開発することで利益がある。
伝統的な文書類作成プロセスは，利用者マニュアルを一つだけ伴うソフトウェア新製品のライフサイク
ルに適用されるが，ソフトウェア及び利用者用文書類は，次のようなより複雑な状況の下で設計及び開発
されることも多くなってきている。
1) 以前に文書化したソフトウェア製品が更新されるか，前とは異なる（版の違いも含まれる。）オペレー
ティングシステムのプラットフォーム用に提供されるか，又はシステム統合の一部としてカスタマイ
ズされるかしたため，以前の文書類を改訂する必要がある。
2) 以前の文書類を，別の体裁（学習書，オンラインヘルプ，高度な利用のための参照指針など）若しく
は別の媒体，又は別の言語若しくは別の版に変換する必要がある。
3) 以前の文書類に手を加えて，組織が取得する又は供給する別のソフトウェア製品群に対するモデルと
する必要がある。
利用者用文書類の設計及び作成は，文書化計画，システム設計文書，システムテスト計画，リリース記
録，及び問題報告のように，ソフトウェアライフサイクルの間に制作された他の文書類の存在によって大
いに助けられる。コンテンツ管理及び文書類レビューのためのスタイルガイド及び組織の手順のような，
文書化プロセスに特有な他の文書類を制作してもよい。
注記 JIS X 0171:2014［システム及びソフトウェア技術−ライフサイクルにおいて生成する情報の内
容（ドキュメンテーション）］は，システム及び／又はソフトウェアのライフサイクルを通じて
要求される文書のための推奨する内容を提供する。
したがって，一つの本又はヘルプシステムの制作に焦点を当てるのではなく，利用者用文書類の設計者
は自らのタスクを，そのアクティビティが次に示すJIS X 0170:2013の6.3.6.3で定義されている情報管理
プロセスの一部とみなすことが望ましい。
情報管理プロセス
a) 情報管理の計画 このアクティビティは，次のタスクから成る。
1) 組織の方針，合意又は法令に従って，システムライフサイクルの間に管理され，それ以降の定義
された期間で，維持される情報の項目を定義する。
2) 情報の項目の発生，世代，把握，保管及び廃棄に関連しての権限及び責任を明示する。
3) 情報項目の保有，伝達及びアクセスに関連する権利，義務及びコミットメントを定義する。
注記 情報及びデータに関する法令，セキュリティ及びプライバシー（例えば，所有権，合意条
件，アクセス権，知的財産及び特許）に対し，当然の配慮を払う。条件又は制約が当ては
まれば，情報は，それに応じて識別される。情報のこのような項目の知識をもっている要
員は，義務及び責任を通知される。
4) 情報の表現，保有，伝達及び検索のための内容，意味論，形式及び媒体を定義する。
13
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記 情報は，どのような形式（例えば，口頭，テキスト，図表，数字）で発生及び終了しても
よい。そして，どのような媒体（例えば，電子媒体，印刷物，磁気媒体，光媒体）にも蓄
えられ，加工され，複製され，伝達されてもよい。組織の制約（例えば，基盤構造，組織
間のコミュニケーション，分散プロジェクト作業）に対して当然の配慮を払う。関連情報
の保管，変換，伝達及び提示の標準及び提示の慣例は，方針，合意及び法令の制約に従っ
て使われる。
5) 情報維持活動を定義する。
注記 これは，リスク抑制のための完整性（integrity），妥当性及び利用可能性に対して蓄えられ
た情報並びに代替媒体への複製又は変換に対するニーズに対しての状態レビューを含む。
技術の変更があっても，保管された媒体を読むことができるように，基盤を保持するニー
ズ又は新しい技術を利用して保管した媒体を再度記録するニーズのいずれかを考慮する。
b) 情報管理の実施 このアクティビティは，次のタスクから成る。
1) 情報の識別された項目を得る。
注記 これは，情報の生成又は適切な発生源からの収集を含んでもよい。
2) リスク抑制のための完整性（integrity），セキュリティ及びプライバシーの要求事項に従って，情報
項目及びこれらの保管記録を維持する。
注記 情報項目の状態，例えば，改訂の記述，配布記録，セキュリティ区分を記録する。情報は，
容易に読めるもので，ふさわしい環境を提供し，損害，劣化及び損失を防止する設備に，
すぐに取り出せる方法で，蓄えられ，保持されることが望ましい。
3) 合意されたスケジュール又は定義された状況によって要求されたときに，指定された当事者に対
して，情報を検索し配布する。
注記 指定された当事者に対して適切な形式で情報が提供される。
4) 要求されたときに公式の文書を提供する。
注記 公式の文書の例は，認定，認可，ライセンス及びアセスメント評定である。
5) 監査，知識保有及びプロジェクト終結の目的に従って，指定された情報を保管する。
注記 指定された保管及び検索期間並びに組織の方針，合意及び法令に従って，情報の媒体，場
所及び保護を選定する。プロジェクト終結後必要な文書を保管する取決めが存在すること
を確実にする。
6) 組織の方針並びにセキュリティ及びプライバシーの要求事項に従って，不必要な，妥当でない又
は検証不可の情報を処分する。
以降の箇条は，次に示すプロセスフェーズのための要求事項及び指針を含んでいる。
− プロセスの実現
− 目標の設定：文書設計に影響するエンタープライズ，プロジェクト，及びソフトウェア製品（内部）
の規格のような目的，方針，及び制約条件の識別
− プロジェクトの計画，管理，及び制御
注記 文書類がソフトウェアとは異なる組織によって設計及び作成されるとき，プロセス実現には，
取得及び供給プロセスの使用を含めてもよい。
− 作成及びレビュー
− 分析及び設計：プロジェクトのための文書類設計の立案，ソフトウェア製品，利用者，利用者の作
14
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
業，及び利用者の情報のニーズに関する情報集め，並びにそれらの必要性に基づいた文書類の設計。
− 作成及びレビュー：使用性のために内容の構造化，文章及びグラフィックの内容を作成することに
よる文書類設計の明確な表現，選択した媒体による情報の実装，並びに製品の残りについての利用
者用文書類の評価。
− 制作：印刷媒体又は画面に表示する媒体を通して利用者が使える文書類の制作及び包装，原本ファイ
ル及びリリースした版の構成管理の維持。
− 保守：使用性の改良に対する適応を含めて，ソフトウェア製品のライフサイクルを通した文書類の正
確性の維持。
この規格は分かりやすくするために，文書類の作成のための明確な出発時点及び明確な終了時点がある
かのように，ライフサイクルについて記述する。しかし，全ての製品及び全ての種類の情報に対して全て
の場合に通用する，アクティビティ群の一つの順序があるわけではない。例えば，画面上の文書類のため
の設計及び実装のアクティビティは，分析及び設計のアクティビティのようにしばしば密接に相互に結合
し，かつ，それらの結びつき方はプロジェクトごとに異なる。
6
プロジェクトの要求事項，目標，及び制約条件
利用者用文書類の作成者は，文書類の構成要素の設計に影響する要求事項を理解するために，プロジェ
クト全体のより広い範囲の情報を集めたり，又は受け取ったりしなければならない。プロセスの実装（開
始）フェーズの目的は，プロジェクトの目標，要求事項，及び制約条件を理解することであり，特に次の
ものが大切である。
− ソフトウェア製品のための要求事項及び目標
− ソフトウェア製品の作成者によって設定された，文書化方針並びに標準の体裁及びスタイルのような
利用者用文書類のための要求事項及び制約条件
− プロジェクトの費用，スケジュール，要員配置，及び機器に適用してもよい制約条件
− 契約によるか又は一般に販売するかに関係なく，ソフトウェア製品及び文書類の意図している取得者
及び最終利用者
− 使用性の要求事項
提示された要求事項によって設計の選択肢が制限され，文書類の適切な集合が利用者に与えられないと
き，文書類設計者は，次を行うことが望ましい。
− 食い違いの理由を説明するように，要求事項を疑う。
− 代替案を提案する。
組織は，要求事項の源まで遡り，かつ，その妥当性を再確認できるように，それぞれの要求事項の発生
源の記録を残すことが望ましい。
6.1
プロジェクトの目標
理想的にはプロジェクトの目標として，利用者の期待を満たし，かつ，利用者のニーズに合ったソフト
ウェア製品を開発することが望ましい。文書類作成者は，次の情報を必要とする。
− 利用者は誰であるか及びどんな状況で製品を使用するのか。
− 特別なニーズをもつ利用者がいるか。
15
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− そのソフトウェア製品の目的は何か。それは何をするか。
− 旧版があるか。そうだとすれば，どの特徴を変更しなければならないか及びどれをそのままで残さな
ければならないか。
− 製品は単独のものであるか，又は一そろ（揃）いの製品の一部であるか。
− 製品はいつ文書化するために利用可能になるだろうか（製品のスケジュールは，文書類の種類及び量
を決定するのを助けるかもしれない。）。
− 将来の版のための計画があるか。
− このリリースで製品はどんなプラットフォームで稼働するか。今後，他のプラットフォームのための
計画があるか。
− その製品は，特定の組織又は複数の組織のために開発されているか。そうだとすれば，それらの組織
は排他的な利用者になるか。
− 製品の地域化版又はカスタマイズ版が要求されているか。
プロジェクトは，次に示すソフトウェア製品に要求される標準の情報を保守しなければならない。
− （ISOのような）国際規格刊行物
− 製品が使用される国の国内規格
− 製品が実行されるシステムのための業界標準
− 画面上の文書類を見るシステムのための業界標準
− アクセシビリティ規格及び要求事項
− 企業，製品，又はオペレーティングシステムの標準及び取決め
− ソフトウェア及びその文書類の，複製又は修正の制限
− 機密情報の保護
6.2
利用者用文書類の要求事項及び制約条件
次の情報は，文書化計画で考えることが望ましい。
− 組織には，正式な文書類又は情報の正式な管理方針及び手順があるか，並びに，もしあるならばそれ
らはこのプロジェクトにどのように適用されるか。
− 文書管理，索引付け，及び検索可能性を支援するために文書類のそれぞれに対してどんなメタデータ
が必要か。
− 組織の標準体裁，テンプレート，スタイル，又はシステムがあるか。それらはこの規格の要求事項及
び推奨事項と整合しているか。もしないならば，この規格と整合したものを作ることが望ましい。
− 要求されている内容に制約条件があるか。
− ソフトウェア製品自体についての利用者の組織の作業手順又は情報のような，背景又は概念的な情報
を提供する必要があるか。必要ならば，その情報はすぐに使えるか。
− 技術連絡担当者，仕様書，及び（開発版又はプロトタイプ版でもよい）製品そのもののような，製品
に関する技術情報を文書類作成者に供給するための資源があるか。
文書類は，法律的及び規制的な要求事項を満たさなければならないことがある。文書類の設計者及び作
成者は，次の事柄を考慮し，かつ，必要ならば法律的助言を得ることが望ましい。
− 国の法令によって決められた要求事項
− 文書自体の著作権の状態
16
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− ほかの場所から文書類に流用した文章の著作権の問題
− 機密データの保護
− 承認
− 商標
− 第三者預託の状態
− 使用許諾
− 適用する提示に関する要求事項（例えば，独占的なプラットフォーム互換である文書類製品を識別す
るために，包装の表面と文書類の中とに特別なロゴマークを使用すること）
− 知的所有権
− 製品保証及び権利保証
セキュリティに関して，文書類作成者は，画面上の文書類の完整性を制御する必要があるかどうか，又
は利用者が行った意図的若しくは偶然な内容の変更を許すかどうかを決定することが望ましい。
供給者及び依頼者はまた，文書類を保守及び更新する方法を決定することが望ましい。
6.3
プロジェクトの目的及び制約条件
プロジェクトの事業目的は，ソフトウェア製品が契約の下に又は一般的な市販のために生産されるかど
うかによる。ソフトウェア製品及び文書類の販売目標の重要な特徴は次のとおりである。
− 見積もった製品寿命の間に配布するソフトウェア製品の達成目標の数量
− 時間軸に沿った販売の傾向の予想（需要は安定しているか又は一定期間の絶頂期があるか。）
ソフトウェア製品の修正は文書類の設計に影響を及ぼすことがあるので，文書類の設計者及び作成者は
製品の修正版を利用者が使えるようにするために計画を見直すことが望ましい。アプリケーションの将来
の修正のための計画は，次の質問を使って識別してもよい。
− ソフトウェア製品及び文書類は，どのくらいの間隔で修正するのか。
− 異なるレベルの修正のどれを行うのか。例えば，次のものを発行する。
− 一時的修正
− 中間版
− 大幅な更新又は実質的に新しい版
− 修正を行うために費やす時間はどれほどか。
− 保守の費用の制約条件は何か。
− 文書類の更新はどのように行うか。
− 旧版のサポートを維持するか又は止めるか。
− 既存の利用者はどのように修正を入手するか。
6.3.1
プロジェクトのインフラストラクチャ及びツール
プロジェクトの制約条件には，インフラストラクチャシステム並びにツール，スケジュール，費用，及
び要員配置を含んでもよい。
新しいソフトウェア製品が一式のソフトウェア製品の一部であるならば，その製品一式のために文書類
を作成，保守，納入，及び視聴するために，既に指定したツールを考慮することが望ましい。ソフトウェ
ア製品をそのために開発している顧客又は組織が，新しいソフトウェア製品も一貫して使いたいと思う既
存のシステムをもっているならば，文書類の設計者及び作成者は，これらの既存システムが特定の文書類
17
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
の納入及び視聴の仕組みの使い方を決定するかどうかを考慮することが望ましい。
文書類に対する制約条件は，ソフトウェア製品が解決することが望ましい実際の問題の取扱いを制限す
ること，並びにその製品を開発するためのハードウェア及びオペレーティングシステムの範囲を制限する
ことを許さないほうがよい。文書類設計者は，次のような計画又は要求されたツールの能力及び制限につ
いての情報を得ることが望ましい。
− ソフトウェアを使用することによって，文書類作成者は，それがどのように動作するか及び利用者が
それをどのように使わなければならないかを見つけてもよい。
− 文章の執筆，割付け，及び編集
− 画面上の情報の執筆及びヘルプファイルの編集
− 図表の作画
− 文書類のレビュー
− 文書類のテスト
− アクセシビリティのテストを含め，利用者テストの実施
6.3.2
スケジュールの制約条件
設計者及び開発者は，ソフトウェア製品の開発スケジュールに関して次を知る必要がある。
− アルファテスト，ベータテスト，及び受入試験の開始及び終了の時期
注記1 アルファテストとは，開発初期版のソフトウェア，ハードウェアなどを実際に様々な環境
で動作させ，テストすることをいう。
注記2 ベータテストとは，開発中のソフトウェア又は正式公開直前の版を利用者に提供し，実際
に使ってもらい，性能，機能，使い勝手などを評価してもらうテストのことをいう。
− 複数のリリースがあるならば，段階的又は包括的なリリースへの取組があるか。どんな特徴及び／又
は機能がどのフェーズで納入されるのか。
− 現在行われている事業のやり方を変更するために定義する必要がある作業プロセスがあるか。
− 政府の認証及び認定のためにソフトウェア製品を提出するか。
− 完成したソフトウェア製品の納品日はいつか，及び世界同時リリースか又は地域ごとに異なるリリー
ス日か。
− 文書類は，納品日の何日前に準備する必要があるか。
− 早期リリースの日付のような，その他のどんな節目（マイルストーン）をプロジェクトに適用するか。
− プロジェクト全体の中で異なるアクティビティの間の主な依存関係は何か。
− 製品を地域化又はカスタマイズする場合，様々な地域化版又はカスタマイズ版のために必要な納品日
はいつか及びそれらの納品日の何日前に文書類を準備しておく必要があるか。
− 文書類を翻訳する場合，リードタイム，翻訳への引渡し日，及び翻訳からの納品日を含む翻訳スケジ
ュールはどうなっているか。
− 文書類は，納入の前にセキュリティ又は法律的なレビューを通過する必要があるか。
− 文書類は，国内で印刷し国際的に出荷するのか，もしそうならば，物理的な納入のために文書化スケ
ジュールに組み込む出荷時間の見積りはどれほどか。
− 文書類製品をプリンタで印刷する場合又は着脱可能媒体で発行する場合，必要なリードタイムはどれ
ほどか。
6.4
利用者及び使用性の目標
設計者は，プロジェクトの始めから，使用性の要求事項に気を付けることが望ましい。使用性は，最初
18
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
から文書類及び支援ソフトウェアの構造，内容，及び体裁に組み込むことが望ましく，文書類作成の終わ
りに使用性を加えることはできない。したがって，使用性の要求事項及びそのテストの方法は，利用者の
その他のニーズが決まる分析フェーズで指定しなければならない。
文書類の使用性は，ソフトウェア製品の使用性に不可欠な部分である。ソフトウェア製品のために使用
性の達成目標を設定し及び測定するとき，文書類はソフトウェア製品に不可欠な部分として扱わなければ
ならない。文書類作成者及びソフトウェア開発者は，使用性を確実にするために一緒に作業することが望
ましい。ソフトウェアの使用性から独立している文書類の使用性の測定には，次を含まなければならない。
− 文書類の中の指示を使って指定された作業を行う方法を学ぶための時間
− 文書類を用いて眼前の作業を達成する利用者の能力
文書類が使いものになることを確実にするには，次の二つの側面がある。
− 設計への人間中心原則及びソフトウェア人間工学原則の適用。ISO 13407:1999，及びJIS Z 85xxシリ
ーズ（JIS Z 8511〜JIS Z 8527“人間工学−視覚表示装置を用いるオフィス作業”，JIS Z 8520 人間工
学−人とシステムとのインタラクション−対話の原則，及びJIS X 8341-6:2013 高齢者・障害者等配
慮設計指針−情報通信における機器，ソフトウェア及びサービス−第6部：対話ソフトウェア）がそ
のような設計の助言を扱っている。
− ソフトウェア製品が実際にどの程度使えるかを総合評価するために，設計及びソフトウェア製品を評
価する。ISO 13407は，そのような設計の助言を扱っている。
注記 ISO 13407:1999は廃止され，ISO/TS 18152:2010，Ergonomics of human-system interaction−
Specification for the process assessment of human-system issuesに置き換わった。
定量的なテストは，作業完了時間及び正確性のような品質を測定するが，定性的なテストは，利用者の
態度及び好みを測定する。
個別の使用性テストのために選択した定量的な測定と定性的な測定との組合せは，特定のテストの目的
及びテストを実行するライフサイクルの時点に依存する。
ひとたび使用性の要求事項の分析を行い，かつ，適切なテスト方法を選択すると，文書類の設計者及び
作成者は，その要求事項を文書類の使用性の目的に翻訳することが望ましい。目的は，使用性のテストで
測定する定量的又は定性的な達成目標である。図1に電子メールシステムにおける過程を例示する。
19
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ステップ1．利用者の目標を定義する。
利用者の目標は次のとおりである。
− メッセージを送るための指示をヘルプメニューで見つける。
− 利用者が自分の言葉で作業をまとめる。
− メッセージを送る。
ステップ2．それらの目標のために使用性の測定量を定義する。
測定量は次のとおりである。
− 有効性（正しい情報が見つかったか。）
− 効率性（情報を見つけるのにどれだけかかったか。最も短い検索ルート又は方法を使ったか。
ヘルプの文章は，理解又は記憶するためには読み直さなければならないか。）
− 満足性（ヘルプに対する利用者の態度はどうか。）
ステップ3．受入れの基準を定義する。
基準は次のとおりである。
− 利用者が20秒以内に情報を見つける場合，構造及びナビゲーションは，受け入れることができる。
− 利用者の作業の概要が正しい場合，情報は正確，かつ，適切に明確である。
− 指示に従って一度で正しく作業を実行できた場合，ヘルプは，受入れ可能，作業指向，及び完全である。
図1−電子メールシステムの使用性の目的を定義する過程の例
アクセシビリティの要求事項は，ソフトウェア製品を使用するかもしれない全ての人に対して，文書類
が適切な体裁で提供されることを確実にするために，使用性の要求事項を拡張している。ソフトウェアを
使用することができ，かつ，そのソフトウェアが支援する作業を実行できるならば，視覚，聴覚，又はそ
の他の物理的な制限をもつ利用者にも使えるような媒体及び体裁で文書類を提供することが望ましい。
例 米国政府は，リハビリテーション法508条として知られている，ソフトウェアアクセシビリティ
のための特定の要求事項を発行している。508条の詳細は，参考文献に記載したURLで見ること
ができる。
国際化及び国家の文化的な要求事項は，スケジュール，費用，提示体裁，文体，及び使用性のテストを
含む文書類の設計に重要な影響を与える。設計者は，アプリケーションが国際的な読者層によって使用さ
れるか及びどの国で使用されるかを決定することが望ましい。これらの質問への答えが翻訳の要求事項を
決定する。
元の国と同じ言語を使っている他の国でソフトウェア製品を使えるようにするためには，文書類の設計
者及び作成者は，適切な現地語，方言，又は取決めを用いて，文書類を特別に地域化した版をそれらの国
のために準備するべきかどうかを考慮することが望ましい。文化的な事柄は，ソフトウェア製品及び文書
類の両方で，特に例の中で，考慮することが望ましい。利用者用文書類がその国での使用に適しているこ
とを確実にするために対象の国の国民が確認することが望ましい。
6.5
技術連絡担当者及び他の専門家へのインタビュー
文書の設計者及び作成者は，情報の収集及び設計の意思決定での合意への到達過程の一部として正式な
インタビューを実施することが望ましい。インタビューは，直接会合，電話，インスタントメッセージン
グ，電子メール，音声又はビデオ会議，インターネットを利用するリアルタイムのチャットツール，及び
プロジェクトチームが使う他の情報伝達媒体を通して行ってもよい。文書類の設計者及び作成者は，最初
に，利用可能なソフトウェアライフサイクル設計文書を読み，次に，疑問を解決するために技術連絡担当
者及び他の専門家への正式なインタビューを計画及び実施することが望ましい。個別又はグループで実施
するかどうかに関係なく，インタビューはできるだけ早く予定を決めることが望ましい。頻繁で，不統一
で，予定外の会合又は質問は，他のチームメンバからは妨害と受け取られるかもしれない。文書類の設計
20
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
者及び作成者は，自分たちが必要とする情報を提供する可能性が最も高い個人又はグループの名前又は役
割とともに，その情報を識別することによってインタビューの計画を始めることが望ましく，次に，必要
な答えを引き出す質問を慎重に作成することが望ましい。
グループインタビューは，同じ人々との一連の個人インタビューよりも，しばしばより多くの情報を生
み出し，かつ，プロジェクトチームのメンバ間の前提及び取組における食い違いを解消する。文書類の設
計者及び作成者は，特定のプロジェクトに対してどのインタビュー手法が最もよいかを決定するときに，
参加者のスケジュール及び時間要求の調和をとることが望ましい。インタビューの間，その実施のときに
たとえどんな媒体が使われたとしても，参加者は，参照するために文書，プロトタイプ，又はソフトウェ
アにアクセスできること，さもなければ情報を引き出すことが望ましい。インタビュー及び会合から得た
意思決定及び情報は，意思疎通の誤りを即座に訂正し，かつ，以前から続いている情報のかい（乖）離を
識別するように，参加者及びプロジェクトマネージャに議事録で公表することが望ましい。
6.6
プロジェクト計画
文書化プロジェクト計画の目標は，納品する文書の識別，それらが満たす品質及び使用性の標準の指定，
並びにプロジェクトのタスク，アクティビティ，スケジュール，資源，及び費用の定義を行うことである。
この箇条は，設計者，執筆者，編集者，アーティスト（イラストレータ，グラフィックデザイナなど），ソ
フトウェア開発者，及び利用者用文書類の作成に関わるその他の人々の観点から，文書化プロジェクトの
計画及び制御における要因を示す。文書類の設計者及び作成者は，現実的な構成管理，スケジュール，及
び費用見積りのためにプロジェクトマネージャに入力を提供する。
文書類の設計者及び作成者は，プロジェクトの要求事項，目標，及び制約条件を識別し，かつ，議論す
る会合に参加することが望ましい。
注記1 文書化プロセスの計画及び管理は，国際規格（ISO/IEC/IEEE 26511，システム及びソフトウ
ェア技術−管理者のための利用者用文書類の要求事項）で扱う。この規格は利用者用文書類
の管理のためのもので，文書化計画の作成，文書類の作成の制御，又は利用者用文書類がよ
り容易に再利用できるようにその内容の管理に責任をもつ人々が参考にすることが望ましい。
文書化計画プロセスの結果は，制作すべき文書類を網羅し，かつ，それぞれの文書品目のための個別の
計画（概要又は仕様）を含む，文書化計画に記録しなければならない。詳細な文書化計画は，プロジェク
ト計画とともに徹底的にレビューすることが望ましい。文書化計画は，次に示すそれぞれの主なアクティ
ビティのために責任及び権限を割り当てなければならない。
− 文書類の技術的な正確性
− ソフトウェア製品を使うときの文書類の使用性，及びその逆のときの使用性
− 市場に対する文書類の適切性
− 文章及び図表の両方を含む文書類の編集の品質
− 法的要求事項への適合性
− ツールの支援を含む文書類の制作
− 翻訳，地域化，又はカスタマイズ
− ソフトウェア及び文書類の包装及び納入
− 文書類の最終承認
文書計画の読者層は，次のとおりである。
− 著述チーム
21
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− レビュア
− 分析及び計画をする人々
− 製品権限者
− 文書作成を監督するプロジェクトマネージャ
− 文書類が完成した時どのように見えるかを知る必要があるかもしれない顧客
− 翻訳，制作，及び使用性のテストをしている人々
− マーケティング，教育訓練，及び顧客支援に責任をもつ組織内のその他の人々
文書化計画は，文書以外の残りの製品とともに承認されることが望ましく，かつ，文書化計画以外の残
りのプロジェクト計画とともに変更管理手順の下になければならない。
注記2 作成が一旦始まった後で文書構造又はスタイルを大きく変更することは，計画段階で設計を
変更するよりも更に難しく，かつ，高価である。
6.6.1
品質管理
この規格で推奨する文書類の作成アクティビティは，そのソフトウェア製品の開発に使用している品質
管理システム（QMS）の制御の下で実行されることが望ましい。この規格の利用者は，JIS Q 9000への適
合を独立に総合評価されていてもよい品質管理システムを運用することが推奨される。
6.6.2
版管理及び変更管理
利用者用文書類を管理するためには構成管理（CM）プロセスを使わなければならない。文書設計者は，
構成管理が，文書類の設計に影響を与え，かつ，その保守性に影響を与えるかもしれないCM方針を考慮
することが望ましい。これらの方針には，次を含んでもよい。
− 版管理を適用する水準。例えば，情報の単一のファイル，又は特定のモジュール，トピック項，オブ
ジェクト，若しくはタスク，のための情報に適用するかどうか。
− その時点で新しい版を作成すべきプロジェクト内の目印。例えば，一群のテストの後ごと。
− 各版への変更を管理するための方法
− 地域化版及びカスタマイズ版に版管理を適用するための方法
− バックアップ及び保管する手順
− 必要になったときに旧版を再生できるようにするために，それぞれの版の履歴に関して記録をつける
ための方法
− もしあれば，どの段階で，版管理の目的のために文書類がソフトウェアの一部となるか。
プロジェクトのための変更管理手順は，文書化アクティビティの要求事項を考慮しなければならない。
文書類作成者は，変更の承認に責任をもつ何らかの組織のメンバであることが望ましい。文書類は，ソフ
トウェアの設計又は教育訓練若しくは支援の計画の変更によって大きく影響を受けてもよい。したがって，
承認を与える前に，そのような変更によって予想される結果を総合評価することが望ましい。ソフトウェ
ア製品の変更を行うとき，最新の情報だけに基づいて作業できるように，文書類作成者は即座に知らされ
ることが望ましい。
注記1 システムの大きな変更がいつも文書類の大きな変更を必要とするというわけではないが，シ
ステムの小さな変更が文書類の大きな変更を引き起こすかもしれない。例えば，システムメ
ニューの変更は，ソフトウェア自体にとっては小さな変更であるかもしれないが，利用者マ
ニュアルの全体の構造を大きく変更するかもしれない。対照的に，何らかの複雑な操作のた
22
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
めにソフトウェアの中で使われた方法を完全に改訂することは，ソフトウェアの開発にとっ
ては主要な作業かもしれないが，ソフトウェアの利用者の視点には全く影響しないかもしれ
ず，したがって，文書類の変更を全く必要としないかもしれない。
ソフトウェア開発に使っているのと同じ構成管理システムが，文書化を支援してもよい。この構成管理
システムには，通常，特に画面上の要素を含めて，文書化に適切な幾つかの特徴がある。
注記2 ISO/IEC TR 15846:1998情報技術−ソフトウェアライフサイクルプロセス−構成管理 が構成
管理システムについての指針を提供する（このTRは，TR X 0018:1999として発行されたが，
2005年9月10日廃止された。）。
6.6.3
資源の利用可能性
プロジェクト計画の間，設計者及びプロジェクトマネージャは，文書類を作成するために必要な資源の
利用可能性を決定することが望ましい。計画は，組織内で現時点では利用できない資源又はサービスの取
得を含む時間及び労力を含んでいることが望ましい。資源は，次に示すような設備，サービス，ツール，
及び人的資源を含む。
− ソフトウェアのプロトタイプ又は他の版を使用するためのハードウェア及びソフトウェア
− 文書化しているソフトウェアの情報を得るために文書類の作成者が使うソフトウェアのプロトタイプ
又は他の版
− 文書類自体の作成，コンテンツ管理及び原本の保存，並びに翻訳，のためのハードウェア及びソフト
ウェア
− 使用性のテストのための実験室，並びに単体テスト及び機能テストのような他のテストのための適切
な場所
− 情報の提供，文書類作成者との技術的詳細の議論，技術的な質問への回答，及び文書類の草稿の確認
を行う技術連絡担当者
− 文書類の草稿の編集上の見直しをする文書類作成者又は他の要員
− グラフィックデザイナ及びイラストレータ
− プリンタ及び包装機器の製造供給元
− 使用性の要員
− 法律的なレビュア又は契約
− 翻訳者
6.6.4
スケジュール
プロジェクト実装フェーズの間，組織は，文書化アクティビティのために準備段階のスケジュールを準
備しなければならない。プロジェクトの他の部分のための基本計画の一部として，それぞれ独立した文書
を作成するためのより詳細なスケジュールを，設計及び作成フェーズの間に作らなければならない。文書
類の設計者及び作成者，ソフトウェア開発者，並びにプロジェクトマネージャは，プロジェクトの全体の
スケジュールに合意することが望ましい。スケジュールが一度合意されると，そのチームは，要求された
時間及び費用の中で準備できるように文書類の設計に責任をもつ。
プロジェクトの予定表を定義しているとき，文書類の設計者及び作成者は次を行う。
− ソフトウェアの設計が確定し終わるまで，文書類の作成を完了できないことを念頭に置く。
− 次のアクティビティに必要な時間が，重要かもしれず，かつ，それらのためにプロジェクトのスケジ
ュールで十分な許容期間を作ってもよいことを念頭に置く。
− 作成段階の間，ソフトウェア又はそのソフトウェアのプロトタイプの観察及び使用
23
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 新しいツールの使用法の学習
− 技術連絡担当者からの情報の獲得及び彼らによる草稿の正確性の確認
− グラフィック及びスクリーンキャプチャの作成
− ソフトウェア製品の妥当性確認，実地試験，及び使用性の試行のために使える文書類の草稿の作成
（このような草稿を準備するために，文書類作成スケジュールは，これらの練習及び試行のタイミ
ングに影響する。）
− 各アクティビティ，特にシステムテスト，レビュー，編集，及び利用者テストのために，修正した
文書類へのこれらのアクティビティの結果の組込み。ソフトウェア及び文書類のそれに続く再テス
ト及び更なる改訂を伴う。
− ソフトウェア製品に組込文書類を含めるために必要となる技術的な作業の識別
− 法律的なレビューの入手
− 必要ならば，文書類の翻訳
− 必要ならば，文書類の印刷及びこん（梱）包
アプリケーションを納入する期日が一度合意されると，計画の全てのフェーズにそれを適用することが
望ましい。ソフトウェア製品及び計画された納品日の変更は，関係者に即座に伝えなければならず，かつ，
文書類に対するこれらの変更の影響を評価しプロジェクトマネージャに伝達しなければならない。プロジ
ェクトの間にスケジュールの調整が必要になったとき，品質を犠牲にして時間を節約するために，システ
ムテスト，レビュー，及び使用性のテストのようなアクティビティをスケジュールから取り除かないほう
がよい。
6.6.5
費用の見積り
文書類作成者は，次に示す関連するものを含めて，提案した文書類を作成する費用の見積りのための入
力を提供することが望ましい。
− 作成及び草稿のレビューのための文書類作成者の費用
− 文書類作成者への状況説明及び草稿のレビューのための技術要員の費用
− 図表の費用
− プロジェクト管理費用
− 編集の費用
− ツールの支援費用
− 教育訓練費用
− 支援要員のための支出
− 設備費用
− 資材費用
− 大量の複写及び制作の費用（例えば，媒体の複写及び包装）
− システム妥当性確認テスト，レビュー，及び利用者テストの費用
− 評価費用
− 保守費用
− 制作，印刷，又は顧客若しくは利用者への納入若しくは配布の費用
− 各言語のための翻訳費用。これには，料金，旅費，及び通信費を含んでもよい。
注記1 文書類の設計がソフトウェア製品の設計で考慮されてないならば，文書類は十分に簡潔で
24
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ないかもしれなく，したがって，文書類の作成費用は必要以上に高くなるかもしれない。
注記2 同様に，製品を翻訳又は地域化すべきで，かつ，それらの費用がソフトウェア及び文書類
の設計で考慮されていないならば，それらの費用は必要以上に著しく高くなるかもしれな
い。全ての翻訳版又は地域化版の費用がより高くなることになる。
注記3 製品の将来の版が計画されているが，文書類の設計では考えられていないならば，費用が
かなり高くなるかもしれない。例えば，製品の基本版及び企業版がリリースされるかもし
れないことを文書設計者が最初から知っていれば，ソフトウェアの製品名に対して変数の
ような出版のための特徴を用いてもよいし，また，原本の作成の間に文書の中でそれらを
用いてもよい。その後，一つの変数の値の変更は，複数の文書から長かったり短かったり
するソフトウェア製品名を検索し置換するよりもはるかに速くなる。
文書類作成者は，文書化の費用の制約条件の交渉で役に立つように，様々な文書類の種類に対して，文
書類の作成及び制作のアクティビティを実行する費用の見積りを得ることを支援してもよい。
6.6.6
地域化及びカスタマイズの計画
全体として，文書化プロジェクトのための計画で考慮したのと同じ要因は，地域化版又はカスタマイズ
版の計画にも適用することが望ましい。
− 誰がそのプロセスに責任をもつのか。
− 誰が地域化又はカスタマイズのための指示を準備するのか，及びいつ準備するのか。
− どこで地域化又はカスタマイズを実行するのか，及び誰がそれを実行するのか。
− いつ及びどのように製品は，要員に納入されるのか，及び誰がその仕事を実行するのか。
− どのように地域化版及びカスタマイズ版は，テストされるのか。
− いつ及びどのように地域化版及びカスタマイズ版は，納入されるのか。
− 誰が地域化版及びカスタマイズ版の品質に責任をもつのか。
− 誰が地域化版及びカスタマイズ版の使用性に責任をもつのか。
6.7
文書類の提案
文書類が（内部又は外部の）別々の組織によって制作されるとき，目標及び計画アクティビティの成果
は，供給者から取得者への文書類の提案であってもよい。図2に，文書類の提案のための内容リストの例
を示す。
25
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
文書類の提案内容
1. 要旨
2. 目標及び要求事項の概要（この節では，プロジェクトに指定されている要求事項を提示し，かつ，それらが目
標をどのように満足するのかを簡潔に説明する。）
− 文書化すべき製品，将来の修正，カスタマイズ，セキュリティ及び安全に対する懸案事項
− 対象読者層，国際化及び地域化，アクセシビリティへの懸案事項
− 文書化すべき重大な作業
− 法律的な要求事項（知的財産の問題を含む。）
− プロジェクトに影響する組織の方針，手順，及び開発ツール
3. 提供する文書類の概要
− 納入文書類の準備段階の高水準設計
− 国際規格及び従うべき取決め
− 文書類の納入及び視聴の制約条件
4. 文書類の開発及びレビュープロセス（この節には，地域化，翻訳，又はカスタマイズのプロジェクトのための
別々の節を含んでもよい。）
− プロセスの概説
− 取得者の資源及び責任
− 供給者の資源及び責任
− 準備段階のスケジュール
− 使用すべきツール及びシステム
− プロジェクトのリスク
5. 業務の提案
− 見積りの基礎（以前のスケジュール，費用，及び資源とプロジェクトとの比較）
− 知的財産及び納入された文書類の所有権
− 費用及び支払条件
図2−文書類の提案のための内容リストの例
7
分析及び設計
分析及び設計は，文書類の設計及び作成のプロセスで最初のタスクである。分析は，文書類のための詳
細な要求事項及び受入基準を作成するプロセスである。文書類は，読者層分析及び作業分析に基づかなけ
ればならない。設計は，これらの分析を考慮に入れて，文書類で使うべき，構造，内容，体裁，及びスタ
イルを指定するプロセスである。
7.1
読者層分析及び作業分析
7.1.1
読者層分析
設計者は，ソフトウェア製品の意図している利用者の種類を列挙し，かつ，利用者を読者層へと分類し
なければならない。各読者層は，仕事の作業及びアプリケーションの使い方が同様である利用者群から成
る。分類は，次を考慮することが望ましい。
− 利用者の背景，経験，及び教育訓練
− 利用者に身近な言語
− アプリケーションを使う方法
− 利用者の学習段階（例えば，このアプリケーションをどのくらい経験しているか。）
− 使用頻度（アプリケーション又は機能を頻繁に使う利用者もいるが，まれにしか使わない利用者もい
る。）
− 利用者の作業環境（利用者は，仕事の大部分を机上で行うのか，又は電柱の上で行うのか。）
注記 それぞれの読者層のメンバによって実行された作業の分析は，読者層ごとの情報の要求事項
26
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
（7.1.3参照）の識別を助ける。しかしながら，上述の要因は，情報の表現及び組織化のため
の最もよい方法と同様に，要求された詳細さの水準，表現した情報における概念的なものと
手続的なものとの比率に影響を及ぼす。
図3は，受注処理システムの一部のための読者層のリストの例を示している。
コールセンタ運用者
コールセンタ監督
ウェブマスタ
倉庫の選別要員
倉庫管理者
財務管理者
経理管理者
買掛金事務員
売掛金事務員
図3−受注処理システムの一部のための読者層のリストの例
文書類設計者は，全ての利用者の種類を考慮したことを確認するために“ボトムアップ”及び“トップ
ダウン”の両方の取組をすることが望ましい。
− ボトムアップ−文書類設計者は，誰がソフトウェア製品を使用するかを考え，かつ，利用者の全ての
種類を決定することが望ましい。幾つかのアプリケーションにおいて，会計士のようにその職名によ
って読者層を識別してもよい。他のアプリケーションにおいては，手紙を書く人のように人が行って
いる役割によって読者層を識別しなければならないかもしれない。
− トップダウン−文書類設計者は，組織全体又はアプリケーションの総合的機能を考慮し，かつ，これ
が一群の読者層又は役割に達するまで分割することが望ましい。この一群の読者層は，ボトムアップ
分析の結果を確認するために使ってもよい。
利用者の役割は，人間と一対一に対応していなくてもよい。同じ人が複数の役割，例えば，販売員及び
商品購買者を果たすこともある。
読者層は，個々の文書が幾つかの読者層を対象としてもよいように，階層構造に分類されてもよい。文
書類設計者は，ソフトウェアとの間で同じ種類の相互作用をもつ読者層を一緒にするために階層構造を使
うことが望ましい。文書類設計者は，利用者組織の組織図を（必ずしも）再利用しないほうがよい。図4
は，そのような階層構造の例である。
27
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図4−読者層の階層構造の例
読者層がどのくらい長くアプリケーションを使っているのか又はどれくらいの頻度で使うのかによって，
その他の点では似ている読者層が異なる種類の文書類を必要とする。例えば，次のとおり。
− 使うための学習をする読者層（概念の説明及び手順に関する学習書）
− 時々又はまれに使う読者層（手続的な指示）
− 常用する読者層（早引きカード）
− 高度な又は複雑な作業を実行する読者層（参照用資料及び付加的手順）
開発しているソフトウェア製品が，消費者向けソフトウェアパッケージのとき，典型的な利用者の仕事
及び背景について，例えば，利用者の仕事及びスキルが様々であるので，役に立つ情報を集められないか
もしれない。この場合，設計者は，利用者が実行する作業及び利用者が通る学習段階に集中することが望
ましい。広い範囲の経験，スキル，及び知識をもつ，様々な種類の潜在的利用者がいるかもしれないとこ
ろでは，文書類は，予想した中で最も経験のない利用者が使うのに適切であることが望ましい。
文書類設計者は，利用者の作業環境の詳細を集めることが望ましい。これらの詳細は，情報を表現する
ために最も便利な媒体を決める一つの要因である。例えば，貯蔵室又は倉庫で使うアプリケーションソフ
トウェアのとき，次を考慮する。
− 印刷した文書を持ち歩かなければならないか。
− それらを保管するのに便利な場所があるか。
− 利用者が画面上の情報を見る設備があるか。
経験及び利用頻度が様々な水準にある広い範囲の利用者によって文書類が使われると予想するならば，
情報を慎重に“階層”化することが重要である。階層化は，必要とする詳細さの水準で，必要とする情報
を，全ての利用者が見つけられるような方法で，資料が提示されることを確実にする。印刷した文書類で
は，階層は，利用者が正しい情報を選べるように分かりやすい見出しを使って，だんだんと詳細になるよ
うに情報を提供している。オンラインの文書類では，概要レベルの項目から詳細な情報を含む項目へのハ
利用者
外部
顧客
供給者
倉庫
選別員
倉庫管理者
コールセンタ
運用者
監督
内部
28
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
イパーテキストリンクの使用を含む，様々な方法によって階層化を達成してもよい。
7.1.2
読者層プロファイル
文書類設計者は，利用者の種類のそれぞれについて，関連する情報を記録する読者層プロファイルを作
成することが望ましい。このプロファイルは，計画の作成において役に立つとともに，執筆者及びイラス
トレータの指針としても役に立つ。読者層プロファイルは絶対的表現（例えば，一つの読者層に固有な条
件の記述）で記録してもよいし，相対的表現（例えば，利用者の経験内容をある基準と比較したもの）で
記録してもよい。図5は，読者層プロファイルに含まれるかもしれない情報の種類を例示する。
読者層：旅行業者（米国の場合）
背景
旅行業者には，観光業，顧客のニーズ及び関心，並びに他のコンピュータ予約システム
に関する知識がある。
言語
旅行業者は，英語を自由に使える能力をもっているが，最もうまく使える言語が英語で
ある必要はない。
アプリケーションの使用 旅行業者は，顧客と電話している間又は顧客が来ているときアプリケーションを使い，
かつ，すぐに切符を予約する。
学習段階
全ての旅行業者が1日の教育訓練コースに出席する。その結果，どの利用者も初心者で
はない。
少なくとも一人の専門家の利用者が絶えず，各オフィスにいる。
使用頻度
旅行業者は，8時間の（休憩を含む）勤務時間の間中，頻繁にアプリケーションを使う。
作業環境
オフィスは，騒がしく，かつ，非常に忙しいかもしれない。
旅行業者は，机に座って働く。業者は，勤務中ずっとコンピュータを使っているが，プ
リンタは共有しているかもしれない。
事務所には，通常，複写機，ファックス，及びスキャナがある。
旅行業者は，電話にはヘッドセットを使用する。
次のものは，全ての事務所にあるわけではない，
− ちょっとした蔵書を陳列する棚の空間
− 机の引き出しの空間
− 図表を貼ることができる壁の空間
図5−読者層プロファイルの例
7.1.3
作業分析
文書類設計者は，できれば利用者に質問をすることによって，又は利用者を観測し彼らが何をするかを
記録することによって，利用者が何をするかについての情報を集めることが望ましい。これができない場
合（例えば，ソフトウェアがまだ開発中である場合），文書類の設計者及び作成者は，作業を考慮するか，
又はユースケースの設計文書のようなその他の情報源を使うことが望ましい。
図6は，電子メールシステムの作業リストの例を示している。
29
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
受信メールの確認
メッセージの発信又は転送
メッセージの印刷
ファイルの添付
添付の閲覧
メールフォルダの作成
メールをフォルダに移動
図6−電子メールシステムの作業リストの例
文書類設計者は，各作業について次の情報を考えることが望ましい。
− なぜ作業を実行するのか。
− 作業は，どの程度頻繁に実行されるのか（利用者がそのやり方を覚えているかどうかを判断するのを
助ける。）。
− 利用者の活動形態はどのようなものか。活動形態の例としては，数時間休みなく活動し続けなければ
ならないものとか，顧客がその場にいる間にトランザクションを処理しなければならない実時間の状
況での活動とかがある。
− 作業をどのように又はいつ実行するかについて，利用者は，どんな裁量をもつのか。
− どんな順番で利用者は作業の集合を実行するのか。
− 作業のための前提条件は何か。
− その作業ではどれだけ過失が許されるか。すなわち，利用者が正しく作業を実行することがどれだけ
重要か。
− 作業が完了したとき又は完了しないときに，どんな結果がもたらされるのか。
設計者は，図7に図示したような階層構造で，関連した若しくは類似の作業，又は類似のステップを含
む作業をまとめることが望ましい。設計者は，作業の詳細を作業プロファイルに記録することが望ましい。
30
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図7−作業階層の例
文書類設計者は，どの読者層がどの作業を実行するかを文書で記録することが望ましい。設計者は，表
1に示すように，行列を使って考えることが望ましい。この例は，どの種類の利用者が一群のセキュリテ
ィ関連の作業を実行するか，及び彼らの学習段階が何になるかを示している。読者層分析及び作業分析の
結果を使えば，機能分析者のための指針，セキュリティ担当者のための指針，及びパスワードを変更する
ときの利用者のための早引き（ヘルプトピック）に，文書類を構造化できる。そして，両方の指針に含め
るべきセキュリティログを見る作業のための共通手順を書くこともできる。
作業
メンバ
アカウント
報告
調査
債務者
メンバの詳細についての調査
アカウントについての調査
債務者の追跡
新メンバの追加
メンバの詳細の変更
アカウントの作成
アカウントの詳細の変更
臨時の報告の生成
週報の生成
要約月報の生成
31
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表1−読者層と作業とを対応付ける行列
読者層
作業
DIC
SUP
MAN
AUD
ACC
FC
SO
FA
SA
新しい利用者の追加
N
利用者の削除
N
利用者が機能にアクセスする許可の
付与
N
利用者が機能にアクセスする許可の
削除
N
利用者が機能にアクセスする許可の
閲覧
N
自分のパスワードの変更
O
O
O
O
O
O
O
O
O
別の利用者のパスワードの変更
NE
セキュリティログの閲覧
N
N
機密保護違反の調査
NE
NE
セキュリティレポートの印刷
NE
NE
表1の凡例
読者層の記号
学習段階の記号
DIC
データの入力事務員
O
臨時使用
SUP
監督
N
通常使用
MAN
管理者
E
高度な特徴の有効利用
AUD
監査役
ACC
会計士
FC
会計監査役
SO
セキュリティ担当者
FA
機能分析者
SA
システム管理者
7.2
利用者用文書類の設計
利用者用文書類の設計者は，次の二つの主要なアクティビティを実行しなければならない。
− どんな情報（文書類の内容）を提供する必要があるか，かつ，何を提供しないかを決定するための，
読者層分析及び作業分析の使用
− 文書類の集合における必要な項目への内容の構造化，及びそれぞれの文書類製品のための構造の決定
問題になっているソフトウェアに応じて，この箇条における多くの項目を特定の文書よりも文書類の集
合に適用してもよい。例えば，あるソフトウェア1本に，最終利用者のための学習書，運用操作管理者の
ためのマニュアル，アプリケーションプログラムインタフェースのための参照，オンラインヘルプ，早引
きの指針などがあってもよい。
この規格の以後の箇条は，利用者用文書類に要求される構造及び内容を扱う。情報を画面上又は紙面で
供給することが望ましいかどうかを決める指針は，12.2を参照。
7.2.1
内容の利用のための設計
文書類設計者は，関連するアクセス及び構造的な情報に加えてトピック項のリストを準備することが望
ましい。どこでどのように利用者に情報を提供するかに関しての意思決定に影響を及ぼす主要な要因は，
次のとおりである。
32
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 読者層プロファイル及び作業プロファイル
− 情報の特性
− 情報が利用される環境
− 利用者の利便性
− 文書類の作成，納入，及び視聴に利用可能な，資源及びソフトウェア製品を含む，技術的な機能の範
囲
− 納入費用及び保守費用
文書類設計者は，どれだけの情報量となるかを表す尺度を選択し，かつ，納入方法及び納入媒体を目的
にかなうように選択するために，その尺度を使うことが望ましい。情報の種類によって，量の見積りが異
なる。情報の量を正確に求めることができないかもしれないが，設計者は，文書類の規模尺度の概念をも
っていることが望ましい。文書類設計者は，目次の草稿，トピック項のリスト，又はウェブページのリス
トを使って，それぞれの文書の準備段階の構造を定義することが望ましい。それぞれの文書の規模を指定
するために，文書類設計者は，ページ又はトピック項の予定数を数えることが望ましい。文書類設計者は，
内容リスト自体，索引，用語集，及び参考文献のようなナビゲーションページ又はトピック項をリストに
含めることが望ましい。次の手法が役立つ。
− 設計者は，識別できる項目，例えば，アイコン，作業，ダイアログボックス，トランザクション，を
数え上げてもよい。
− 設計者は，各項目にどれだけの情報，例えば，ある作業の平均及び最大のステップの個数，又はある
概念に必要な単語のおよその個数，が必要かを評価してもよい。
− 設計者は，一つの項目を標本として準備し，かつ，そのサイズを計算の基礎として使ってもよい。
− 設計者は，同程度の利用者，作業，及びアプリケーションに対して既存の文書類を参照してもよいし，
かつ，それから現在のアプリケーションにどれだけの情報が必要なのかを評価してもよい。
7.2.2
体裁の設計
利用者が体裁よりも内容に集中できるので，一貫した文書類は，より容易に使える。組織は，全ての文
書及び文書集合，トピック項，章，前付，後付，序文，技術的専門用語，アイコン及び記号，ナビゲーシ
ョンコントロール，並びにシステムメッセージに対して，全ての製品，プロジェクト，又は組織のための
取決めを設定しなければならない。
文書類の体裁設定の詳細については，箇条12を参照。
8
作成及びレビュー
文書類のプロトタイプ又は見本を文書類の設計プロセスの一部として作成してもよいが，全体の開発及
びレビューのプロセスは文書類の設計が完了した後に始めることが望ましい。完結した文書化計画によっ
て，文書類作成者は，指定されたツール及び方法を使用し，並びに詳細な文書化計画に指定された情報だ
けを含めて，詳細な文書化計画で指定された文体及び図表スタイルに従うことが望ましい。
文書類の作成は，関連文章の著述，図表の準備，及び動作するシステムを作成するために画面上の文書
類に必要なソフトウェア要素を適用することから成る。文書類の作成プロセスで，文書類作成者は，文書
化計画で指定されたように文書類の製品を組み立てるために，技術的に正確な文書類のトピック項（オブ
ジェクト又は塊とも呼ぶ。）の原版を準備する。
注記 個々の文書を作成するプロセスは繰返しのプロセスである。ソフトウェアが変更されると，文
33
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
書化計画及び文書類の変更が必要になるかもしれない。
8.1
プロトタイプ及び草稿
プロトタイプは，それぞれの種類の文書に対して文書類の設計の妥当性を確認するのに使ってもよい。
詳細なプロトタイプを作成し，使用性の目標の中で利用者が必要とするものを文書化の取組が提供してい
ることをテストしてもよい。文書類のプロトタイプはアプリケーションソフトウェアのプロトタイプと同
時に作成してもよい。プロトタイプは，また，完成したアプリケーションで使う，機器の組合せ，及び言
語又は地域の版のために準備してもよい。各プロトタイプについて，文書類作成者は，次に示す質問を考
えることが望ましい。
− その目的は何か。プロトタイプのテスト又は試用によってどんな情報を集めようとしているのか。
− その適用範囲は何か。アプリケーションのどの部分を対象とするのか。どのような種類の文書類を含
むのか。
− テスト及び試用を，どのように実行し，記録し，そして，それに続くフェーズでどのように使用する
のか。
プロトタイプはまた，文書類の設計を完了する前に，画面上の文書類の技術問題が解決していることを
検査するためにも役立つ。
プロジェクトの後になってから問題が起こるのを避けるために，文書類作成者が最初の草稿段階で次を
行うことが望ましい。
− 文書化に関連した新しい方法及びプロジェクトで使うツールを試用する。使用すべき方法及びツール
の例には，図表の作成若しくは取込みのためのもの，又は様々な媒体への内容の出力のためのものが
ある。
− 最終的な制作方法を使って文章及び図表の見本を作成する。
− オンライン文書類について，アプリケーションの特徴にトピック項の内容が結び付いていることを検
査する。すなわち，内容を写像する技術が正しく働いていること及び正しい内容の識別子が使われて
いることを確認する。
注記1 印刷した文書を計画するとき，文書類作成者は，プロトタイプ及び草稿の提示に完成版で
使う画面又はページレイアウトを使うかどうかを，文書ごとに決めることが望ましい。完
成した文書のためのレイアウトを使うことは，完成した文書類がどう見えるのかについて
草稿で注釈を付けるのには役立つが，レビュアが文書の技術的内容ではなくページレイア
ウトの特徴に注目してしまうかもしれない。
次に示すときに文書類が作成されることが望ましい。
− 詳細な文書化計画の概要が認可されたとき。
− 機能の要求事項文書が受け入れられたとき。
− アプリケーションソフトウェアの十分な安定した情報が利用可能になったとき。
文書類を作成する前に，アプリケーションソフトウェアの対応する部分が存在することが望ましい，さ
もなければアプリケーションソフトウェアに関する要求事項及び用語体系の合意済みの集合があることが
望ましい。必要な情報が，スケジュールで指定された日付までに利用できないならば，文書類作成者は，
プロジェクトマネージャにプロジェクトのスケジュールを再検討するよう進言することが望ましい。
34
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
文書類作成者が作業指示の下書きをする前に，プロジェクトチームは，メニューの選択肢，アイコン，
ナビゲーション機能の名前などの作業で使うアプリケーションの機能の名前に合意していることが望まし
い。文書類作成者は，プロジェクトの用語集を準備して，一貫してそれを適用することが望ましい。スタ
イルの明快さ及び単純さは，翻訳される文書で特に重要である。文書類作成者は，俗語，業界用語，及び
ユーモアを避け，かつ，直喩及び比喩は慎重に使うことが望ましい。さらに，文書類作成者は，慣用句及
び隠喩が正しく翻訳できないかもしれないこと，対象の言語に同等なものがないかもしれないこと，又は
別の文化では実際には不快かもしれないことを意識していることが望ましい。
注記2 翻訳される文書類のために，プロジェクトチームは，プロジェクトの用語集にどの用語が元
の言語で残るかについて合意することが望ましい。そして，対象の言語に翻訳される用語に
ついては一貫した用語法を使うことが望ましい。
文書類作成者は，情報には利用者が必要とするもの全てを含み，かつ，無関係のものは何も含まないこ
とを確実にすることが望ましい。文書類作成者は，文書化する作業を検査するアプリケーションソフトウ
ェアを使うことが望ましい。草稿は，技術的な情報の次の発生源に基づいて，技術的に正確であることが
望ましい。
− 文書類設計情報
− システム設計情報
− SME又はソフトウェア開発者の情報
注記2A SMEとはSubject Matter Expertの略語で，対象領域専門家（ある事柄についての専門家）
のこと。
− システム又はそのプロトタイプの個人的な使用経験
注記3 文書化チームのメンバは，利用者の観点から作動するソフトウェアを詳細に調査する最初
の人であってもよい。文書類作成者がそのソフトウェアを使うことで，例えば，矛盾を識
別することによって，開発チームにシステムの厳密なテストを提供し，及び貴重なフィー
ドバックを与えてもよい。
注記4 文書類を設計計画するとき，文書類設計者は，レビュアに対しそれぞれの文書の最初の草
稿の部分的な索引又は草稿全体を提供し，草稿中からのトピック項の検出及び草稿の残り
の部分のレビューと索引の体裁のレビューとが一緒にできるようにすることが有用である
かどうかを決めることが望ましい。
8.1.1
作成の間の構成管理
文書類の作成に責任をもつ組織は，プロジェクトのための構成管理システムの要求事項が励行されるの
を確実にしなければならない。承認された文書類版は，安全に保守し，かつ，作成のために持ち出す複製
とは別々に保守しなければならない。レビューのために発行した各草稿は，一意に識別されなければなら
ない。文書類の原本の控えの複製は，安全に，かつ，文書類の作成に使っているシステムとは別に，保存
することが望ましい。
8.1.2
翻訳及び地域化した文書類の作成
完全で承認された文書類を翻訳すること又は地域化することは，これから大きく変更される可能性のあ
る作成途上の文書類を翻訳すること又は地域化することに比べれば簡単ではあるが，ソフトウェア製品を
リリースするときには，文書類は同時に複数の言語又は地域に対応させてリリースしなければならないこ
とがある。輸出すべき幾つかのソフトウェア製品には，文書類が翻訳されているという法的な要求事項が
あってもよい。
35
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
翻訳は，元の言語を母国語とする人ではなく，対象とする言語を母国語とする人によってされることが
望ましい。対象とする言語の地域的な変動のために，地域化した版が必要になることがある。地域的な変
動の例としては，ヨーロッパ系のスペイン語とメキシコ系のスペイン語，英国の英語と米国の英語などが
ある。
翻訳プロセスにおける第一歩として，プロジェクトの用語集（用語及びその定義のリスト）を翻訳しな
ければならない。用語の翻訳したリストが承認された後にだけ，文書類を翻訳しなければならない。ある
言語に複数の翻訳者が関わるとき，これは特に重要である（用語集の構造は11.12に示す。）。
翻訳プロトタイプの間に元の文章に不正確さ又は曖昧さが見つかったとき，文書類作成者はできるだけ
早い機会に原文を改訂することが望ましい。
翻訳及び地域化した文書類は，基本の版と同様にレビュー及びテストすることが望ましい。
8.2
文書類の評価
文書類の評価の目的は，その文書類が目的に合っていることを確実にすることである。文書類の評価は，
再利用又は拡張の考慮のため，最初の草稿から改訂まで，文書の作成，制作，及び保守を通して実行する。
選択する評価方法は，次を含む様々な要因に依存する。
− 評価を行う理由
− 評価が実行されているライフサイクルにおけるフェーズ
− 利用できる資源
− 利用できる時間
− 文書類に関して利用できる情報の総量
− 適切な範囲の経験及びスキルがある利用者の利用可能性
− 文書類設計の専門家の利用可能性
− 使用性に関する専門家の利用可能性
文書類の作成の間，文書類の完成後，及び文書類が使われる特定の期間における異なるフェーズにおい
て，異なる方法が使われてもよい。方法の組合せはそれぞれ異なる。
この箇条は，文書類評価の2種類のプロセス，すなわち，レビュープロセス及びテストプロセスについ
て示す。
文書類のレビュープロセスは，次のレビューを含む。
− 計画，要求事項，及び確立した標準と比較した，文書類の構造，体裁，及びスタイル
− 提示された情報の適用範囲及び詳細さの水準
− 扱っているトピックの範囲
− 技術的な正確性
− 製品との一貫性
− 安全（危険又は誤りから守るための重大情報の規定）
文書類のテストプロセスは，次を含む。
− 文書類が正確に，かつ，応答できるように動くことを確実にするための運用試験（例えば，画面上の
文書類がソフトウェアのトピックに適切にリンクしており，ナビゲーションは，一貫していて，かつ，
予想したとおりである。印刷した文書類の索引は，正確な参照である。）
− 意図している読者層がその文書類を使って彼らの作業を遂行できるかどうかを決定するための，ソフ
36
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
トウェア製品を使っての文書類の使用性のテスト
文書類テストの要求事項は，明確で，かつ，測定できなければならない。
文書類がリリースされた後も，（コメント用紙及びメッセージを通して）利用者からの反応の形で，並び
に独立しているソフトウェア製品のレビュー雑誌及び報告からの反応の形で評価は続く。調査及びインタ
ビューも，リリースした文書類の利用者及び顧客の意見及び態度を収集するのに役立つかもしれない。指
導者，販売要員及び顧客サービスが集めた問題報告もまた，文書類又はソフトウェア製品の改善が必要か
どうかを示す。
注記 JIS X 25012［ソフトウェア製品の品質要求及び評価（SQuaRE）−データ品質モデル］のよう
に，文書類は，また，ソフトウェア製品の評価に含まれている。ISO/IEC 9126規格群（ソフト
ウェア製品の品質）もこの目的のために使ってもよい。JIS X 0133規格群（ソフトウェア製品
の評価）はソフトウェア製品の評価を扱う。
文書類の評価は，次の四つのアクティビティを含まなければならない。
− 計画：文書類の設計者及び作成者は，受入れ可能な性能又は品質に対する要求事項を識別し，次のこ
とを指定することによって，評価を実施する準備をすることが望ましい。
− テストをいつ行うか。
− どんな資源が必要か。
− 評価をどう実行する（テストの粗筋及び脚本）か。
− 結果をどう測定し記録するか。
− 結果をどう分析するか。
− テストの合否判定基準は何か。
− 実行：文書類の設計者及び作成者は，測定結果を取得及び記録して，要求事項に対して文書類を評価
することが望ましい。テストが系統的及び完全であることを確実にするために，前もって作成したテ
ストの脚本に従って，プロジェクトチームのメンバは，通常は作成の間にテストを実行する。
− 点検：文書類の設計者及び作成者は，次のステップを推薦し，評価結果の分析及び報告をすることが
望ましい。
− 処置：文書類の設計者及び作成者は，文書類の改訂，テストの結果及び推薦に基づくソフトウェア製
品への変更の提言，並びに次の評価サイクルが必要かどうかの決定を行うことが望ましい。
受入れ可能な結果を生むために，プロジェクトのスケジュール及び文書化計画の変更，又は要求事項の
変更さえも伴ってもよい。例えば，拡張機能の文書化を後のプロジェクトのフェーズまで延期してもよい
し，又は受入れ可能な文書類ができるまで，製品のリリース日を延期してもよい。
8.2.1
文書類の品質の評価における他の人々の役割
文書類の評価は，要求された特徴及び品質に基づかなければならない。文書類品質の評価は，受入可能
性の様々な側面の認識に依存する。最終利用者が最終的には受け入れることになるが，その前に最終利用
者以外の人々が文書類が受入れ可能な品質であると承認しない限り，文書類が最終利用者に届くことはな
い。承認に関係する人々は，次を含む。
− 管理者の視点 管理者は，特定の品質特性よりも総合的な品質に関心をもってもよい。管理者は，市
場で商業的に利用可能なもの及びより安く制作できるものと文書類とを比較することによって，組織
のビジネスニーズを反映するために，ある特性に異なる重みを付けてもよい。管理者は，文書類の品
37
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
質が顧客支援及び将来の販売のための費用にかなり影響しても差し支えないことに注意することが望
ましい。
− 技術担当編集者の視点 技術担当編集者は，総合的な文書の品質及び一貫性を総合評価するとともに，
分析フェーズの間に提示した構想及び計画を文書類が満足することを確実にするために働く。
− 開発者の視点 ソフトウェア開発者は，ソフトウェア製品が利用者の作業をどう支援するのかよりも，
新規機能又は拡張機能の中でそれがどう動作するかに関心をもってもよい。
注記 しかしながら，開発者はソフトウェア製品のすぐ近くにいて，かつ，より洗練された利用者
である。
− 保守者の視点 文書化システムを保守しなければならない人には，他の文書類作成者の要求事項に加
えて品質のための特別な要求事項がある。保守者は，例えば，文書類の構造の簡単さ及び明快さ，文
書類の新しい版が作成されたときの容易さ，並びにコンテンツの管理及び制作に関する新技術への移
植性に関心をもつ
− 利用者の視点 利用者は，要求した情報の発見及びその適用の容易さと同様に，正確な情報及び関係
する情報を含んでいることに関して品質を測定する可能性が高い。
8.2.2
文書類レビュー手順
文書類のレビューは，使用性のテストの前に行い，文書類の品質を向上させるとともに，テストで識別
すべき残っている不備及び欠陥の個数を減らし，結果後の段階で必要になる改訂及び再テストの量を減ら
すことが望ましい。文書類の草稿は，次の点に対してレビューすることが望ましい。
− 技術的な正確性 文書化計画で識別された承認の権限者は，ソフトウェア製品の文書類の技術的な正
確性及び技術連絡担当者からの矛盾するコメントの解消に対して責任をもっている。
注記1 教育手順の技術的な正確性は，レビューよりもソフトウェアを使って文書類をテストする
ことによってより良く検証される。（ポップアップヘルプのような）組込文書類の技術的レ
ビューは，ソフトウェア製品のテストと一緒に最もうまく実行される。
− 安全性 専門家は，ソフトウェア製品の使用に関連するリスクに対する警告，注意，並びに適切な回
避及び回復の指示を含むことを確実にするために，文書類をレビューすることが望ましい。レビュア
は，意図している利用者が容易に気付き，かつ，理解できるように，警告及び注意が適切に配置され，
かつ，言葉で表現されていることを検証しなければならない。
− 理解の容易さ ソフトウェア製品にあまりなじみがない少なくとも一人が，理解しやすさの検査を実
行することが望ましい。草稿を検査する人は，潜在的な読み間違え及び誤解に注意を怠らないことが
望ましく，かつ，それらを強調することが望ましい。
− 適合性及び一貫性 文書類の作成者又は編集者は，選択された規格並びに組織の方針及びスタイルガ
イドの要求事項に文書が適合し，文書化計画及び設計計画に従い，並びに外観及び専門用語で互いに
矛盾していないことを検査するのが望ましい。レビュアは，参照又は文書若しくは文書集合の他の部
分へのリンクにおける一貫性及び正確性を検査することが望ましい。総合評価のこの水準は，文書類
が利用者を満足することを保証しないが，利用者が文書類を完全に不十分であるとは思わないことを
確実にすることが望ましい。
− 完全性 文書類は，利用者が必要とする情報を含んでいるか又は参照していることが望ましい。でき
れば，ソフトウェア製品にあまりなじみがない少なくとも一人が検査を実行することが望ましい（11.1
参照）。印刷した文書類及び画面上の文書類の集合全体を，ソフトウェアと統合される品目を含めてレ
ビューすることが望ましい。一貫性及び完全性を検査できるように，文書類は，まとめてレビューす
38
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ること，又は同じ人々がレビューすることが望ましい。
− 編集の一貫性及び正確性 編集者は，スペル，文法，句読点，編集の標準，並びに全ての文書類の構
造，体裁，及びスタイルの要求事項について最終稿に近い草稿を検査することが望ましい。
− セキュリティ及び法律的な正確性 組織のセキュリティグループ及び弁護士は，機密の情報及び所有
権の情報の保護，法律的な要求事項への適合性，並びに商標の適切な取扱いのための正確な通知を含
むことを確実にするために，最終稿に近い草稿を検査することが望ましい。できれば，知的財産法（IPL）
の法律家が，この検査を実行することが望ましい。
文書類作成者及びプロジェクトマネージャは，レビューへの参加者及び手順を決定することが望ましい。
レビュアは，同僚，編集者，技術専門家，指導者，管理者，又は顧客であってもよい。レビュアは，専門
的技術，要求事項及び規格への精通，並びに徹底的及び使用可能なコメント及び訂正を提供する能力に基
づいて選ばれることが望ましい。レビュアが文書類の全ての側面に同時に焦点を当てるのはまれである。
別々のレビュー又はレビュアが，文書類の組織，技術的な正確性，意図している読者層の適切さ，並びに
文法，スタイル，及び体裁の一貫性を評価することが望ましい。
その上，技術的内容が正確で，かつ，一貫したものになる前に詳細な編集上のレビューを行うのは効率
が悪い。
トピック項，節，及び部分的な文書をレビューしてもよい。長い文書に対しては，文書類作成者は，全
体の文書が終わる前にレビューのためにソフトウェア開発者に新しい章を送ってもよい。制作の前に，文
書類は全部をレビューしなければならない。
レビュアは，相違する意見及びコメントを提案することがある。組織は，他のレビュアのコメントを見
て適用するかどうかを決定するのは誰かを，プロジェクトチームの中で決めることが望ましい。レビュー
及び受入れの手順は，変更の受入れ及び実装の最終的な権限は誰かを指定しなければならない。
注記2 タイムリーなレビュー応答を確実にするために，文書類作成者，レビュア，及び管理者は，
レビューの回数及び期間を，例えば，各レビュー当たり1週間のように，合意することが望
ましい。さらに，合意した期間内にレビューコメントが提出されないとき，このような手抜
かりは文書作成者に文書類作成の次のフェーズに進むことへの承認を与えることに，利害関
係者が合意することが望ましい。これによって，例えば，一人以上のレビュアが代わりのレ
ビュー参加者を指名せずに欠勤したときに生じるような，スケジュールの遅れを避ける。
情報をレビューする異なる方法は，異なる特徴を検査するのに適している。レビュアが使用するのに適
切な方法を次に示す。
− レビュアは，文章及び図表の印刷した複製を調べてもよい。この方法は，次をレビューするときに使
うことが望ましい。
− 情報の正確性
− 編集のスタイル
− 節当たりの情報量（内容の詳細さの水準）の適切さ
− レビュアは，ソフトウェアから独立に画面上で文書類を調べてもよい。この方法は，次をレビューす
るために使うことが望ましい。
− ソフトウェアとは独立に作動できる情報システム
− それを通して，利用者が必要とするものを見つけるために，その中を自分で動き回ってもよい項目
の集合から成る情報
39
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 利用者が必要なものを見つけるのを助けるために提供された索引及び検索
注記3 印刷及び画面上の文書類のスタイル及び提示をレビューするために，これらの方法は不可
欠である。
ソフトウェアとともに画面上の文書類を画面でテストすることは8.3で示す。草稿は，次のものととも
にレビュアに配布することが望ましい。
− レビュアが何に集中する必要があるかの明確な記述を含む，明確なレビューの基準
− コメントを準備する方法及びレビューツールの使用のための指示
− 資料をレビューするのに費やすべき時間の目安
− 質問又は問題があった場合に，レビューの間に連絡する要員の詳細
− 指定した期日までに，指定した人へコメントを戻すことに関する指示
文書類作成者は，余白に側線を引くなどして，前回の草稿に加えた変更を強調することについて考える
ことが望ましい。こうすれば，レビュアは，変更されていない文章を再読しなくてもよくなる。この手法
を使うときは，検査する必要がある全ての節を強調しておく必要がある。なぜならば，レビュアは強調さ
れていない節は読まないからである。
注記4 あまりに多くの変更があると，強調が逆効果になるかもしれない。一つの技法は，25 %の規
則を適用することである。すなわち，文書の変更が25 %を超えたならば，全ての強調を取り
除くことが望ましく，かつ，レビュアには文書全体を読むように指示することが望ましい。
レビュー指示では，レビュアがコメントを供給する方法を規定することが望ましい。提出方法には，次
のようなものがある。
− 印刷した複製にマーク付けして提出する。
− 電子版の草稿に明瞭な電子的注釈を付けて提出する（修正済みの電子版は，文書類作成者が識別でき
るように変更を強調することが望ましい。）。
− 草稿とは独立した電子的なレビュー文書として提出する。
また，レビュー指示は，次の規定を採用するかどうか明記することが望ましい。
− コメントにレビュアの名前が結び付けられていることが望ましい（これはレビューツールによって自
動的に扱われてもよい。）。
− レビュアは，セキュリティ又は構成管理の制限範囲内で，草稿の写しを保存してもよい。
少なくともレビューの次のサイクルが完了するまで，レビュアのコメントは構成管理の下に保有しなけ
ればならない。多くのレビュアが，次の草稿をレビューする間に以前の自分のコメントの複製を見ること
を期待している。
編集の正確性（最初の草稿へのコメントが正しく組み込まれ，かつ，矛盾を導入していない。）を確認す
るため及び技術的な正確性を確認するために，改訂草案をレビューすることが望ましい。特に最初の草稿
以降にソフトウェアの設計を変更したときには，技術的な正確性の確認が重要である。レビュー及びテス
トの結果，文書類に反映されることが望ましいアプリケーションソフトウェアへの変更を識別するために，
ソフトウェア製品の構成管理に責任をもつ人々とともに，文書類作成者が検査することが望ましい。
内容のこれ以上の変更が許されなくなったときに最終稿を準備することが望ましく，かつ，適切な権限
40
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
による最終承認の前に，体裁及び誤植のためだけにレビューすることが望ましい。
コメントが矛盾するところは，製品権限者が決裁することが望ましい。
8.3
文書類のテスト
文書類のテストは，ソフトウェアに関連して文書類の妥当性確認及び検証を行う。製品を一般にリリー
スする前の使用性テストと同様に，ユニットテスト及びシステム統合テストを含めて，アプリケーション
ソフトウェアが利用可能になったときにアプリケーション開発の各段階で，文書類作成チームは，文書類
をテストすることが望ましい。
8.3.1
文書類テストの種類
システムテストは，組込文書類及び分離形文書類の両方を含んでいることが望ましい。システムテスト
は，次の事柄を検証することが望ましい。
− 文脈依存の文書類及びウィザードのためのアクセス法とナビゲーション機能とは，適切に働く。
− 関連情報のためのリンク及び相互参照は，正しく働いている。
− 与えられたそれぞれの状況で（エラーメッセージなどの）正確な情報を表示する。
− 文書類の中の指示は，実行したとき望みどおりの効果をあげる。
注記 特に，文書類及び学習書の例は，システムで徹底的に検証することが望ましい。
− 文書類の見出し，検索，及び索引項目は，利用者がその作業を実行するのに必要な情報に素早く導く。
8.3.2
使用性テスト
利用者テストは，利用者が必要とする情報が文書類に提供されていて，かつ，利用者がそれを見つけ，
理解し，適用することができることを検査する最も受け入れられる方法である。この方法は，最終版に近
いソフトウェア及び文書類の評価に役立つのはもちろんのこと，文書類を変更する時間がまだある間は，
部分的に開発されたシステムの評価に役立つ。中間的な水準の使用性の保証として，文書類が指定された
質的な使用性の目的と合致するかどうかを総合評価するために，使用性に関する専門家は，文書類をレビ
ューしてもよい。このアセスメントは，主観的であってもよいし，又は特定の目的に適切な分析方法を用
いてもよい。
経験に基づいた評価は，選択した作業を行うために文書類を使用している利用者（実際の利用者又は意
図している読者層を代表する他の人）を観測する専門家によって実行される。テストの間に観察者がメモ
をとること，利用者を録画すること，又は利用者が何を及びなぜ行っているのかを説明することを依頼す
るような，様々な異なる記録手法を使ってもよい。システムのアセスメントは，インタビュー，アンケー
ト，又は集団討議によって作られていてもよい。
製品の一般的なリリースの前に妥当性確認テスト又は実地試行があれば，文書類の利用者の構造的な観
測及び非構造的な観測の別の機会を準備してもよい。妥当性確認作業及び実地試行の両方で，文書類作成
者は，ソフトウェア及びその文書類を一緒にして問題を識別し，かつ，ソフトウェア及びその文書類を一
緒に考えることによって問題の解を求めることが望ましい。
妥当性確認及び実地試行によって製品の主要な問題が強調されたならば，それらの問題を解決するため
に製品全体が別の設計段階を必要としてもよい。したがって，文書化もまたこのプロセスの一部として別
の設計段階を経る。
使用性テストのための計画は，次を含む。
− テストの目的の定義
− 使用性テストを始めるための出資者の合意
− テストされる作業及び受入基準の識別
41
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 設備を含む資源の準備
− テストのスケジュール
− テストを実施する方法
− テストの結果を記録する方法
− 目標を満たしているかどうかを決定する方法
− プロジェクトのために将来の設計及び開発アクティビティにテストの結果を組み入れる方法及び計画
− テスト参加者の識別及び募集
最高水準の確信を得るためには，管理された利用者テストからのシステム性能の数値を必要とする。試
行では，利用者の有効性及び効率に関して示した，定義された使用性の目的に対して，文書類をテストす
るために設計した作業を実行しながら，文書類を使って働いているとき，利用者が使用性に関する専門家
によって観察される。テストの間のアンケート又は利用者のコメントは，利用者満足度の水準の総合評価
において貴重である。テストは，ソフトウェア製品の利用場面に関連する測定の指定した場面で実施する。
結果の性能水準と要求水準とを比較する。この確信の測定量は，文書類の使用性を確実にするために必要
である。
注記 文書類の使用性のコメントは，また，ソフトウェア製品との問題を明らかにするかもしれない。
9
制作
制作は，内容の作成及びテストが一度済んだ時点での，文書類製品の統合，準備，再制作，こん（梱）
包，及び納入のプロセスである。したがって，制作は，最終的な組立て及びレビューを含む。文書類の制
作に必要なアクティビティは，異なる種類の情報がソフトウェアに統合している度合いに依存する。
9.1
最終的な組立て及びレビュー
最終稿が承認されたとき，出版若しくは製作要員，編集要員，又は文書の著者以外の人は，次のことを
行わなければならない。
− 最終的な目次及び索引の準備
− 文章の校正
注記 自動的なつづり及び文法のチェッカ並びに他の著作用ツールが役立つかもしれないが，常に
目視で確認する。
− 相互参照の最終確認
− 図表に対する最終的な仕上げの準備及び確認
− 図表が，正しく置かれていること（12.18参照）及び選択した提示方法が（画面上又は印刷した用紙で）
十分に明確であることの確認
− 文書を印刷すべきならば，（それが組織独自のスタイルならば）主要な節が新しいページから開始する
こと，及びリスト又は短い節が改ページで分割されていないことを確認し，最終的なページ付けのレ
ビュー
− また，次のことを確認する。
− 全てのページ又はトピック項がある。
− 全てのページが正しく付番されている。
− 全ての見出し，表，及び図が正しく付番されている。
42
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
9.2
承認
文書類は，リリースする前に，文書類計画又は契約で指定したように承認されなければならない。供給
者は，文書類の作成のための次に示す全ての条件が満足されたことを検証することが望ましい。
− 文書化ライフサイクルプロセスに従っている。
− テストを実行し，かつ，完全である。
− 草稿をレビューし，訂正している。
− 使用性の目標を満たしている。
− 法律的な承認を得ている。
9.3
構成管理
構成管理プロセスは，文書類のリリースした版の管理版を維持するのに使わなければならない。文書類
が完成したときに，文書類作成者は，文書類の新しい版を準備できるようにするために十分な情報を提供
することが望ましい。組織は，発行した版に含まれていた全ての項目（文章及び図表を含む。）の版の記録
を保守することが望ましい。これによって，ちょうど今準備したように文書類の版を作成できる。
9.4
更新及び保守
適切に設計及び作成した文書類は，より容易に更新及び維持される。設計者は，次のことの結果として
修正を行うと予想することが望ましい。
− ソフトウェア製品の新しい，カスタマイズした，再集結した，又は更新した版の作成
− 既存のソフトウェア製品又は文書類における誤りの発見
− 既存の内容を再利用することによって文書化できる新しいソフトウェア製品の開発
システム設計の変更の結果として文書類に施す必要のあるどんな変更も，全体の製品のための正式な変
更管理手順又は文書管理システムを使うことが望ましい。画面上及び印刷した文書類の修正のための計画
は，ソフトウェアの修正の計画と統合することが望ましい。
ソフトウェアの新しい版を発行するとき，文書類の新しい版も発行できるよう，文書を可能な限り設計
しておくことが望ましい。画面上及び印刷した文書類のためのプロジェクトの要求事項及び制約条件が，
文書類を修正又は更新すべきかどうか，及びもしそうならばどのようにすることが望ましいか，を指定す
ることが望ましい。
リリースノートは，ソフトウェア製品の変更の簡潔な概要を既存の利用者に提供するために使ってもよ
い。しかしながら，リリースノートは，新規の利用者には分かりにくいものであり，文書類の完全な更新
の手近な代用としては使わないほうがよい。新しいリリース（翻訳を含む。）によって影響を受ける文書類
の内容，特に教習手順は，更新しなければならず，かつ，ソフトウェア及び文書類の保守のために契約し
た顧客に供給しなければならない。
注記 印刷した文書類を含む製品の完全に新しい版が購入されているか又は製品の更新のたびに配布
されるならば，変更したページを利用者に発行しないほうがよい。製品の代替品が発行される
場合，完全な，印刷した又は画面上の文書が再発行されるならば，印刷した文書類の利用者に
とってはより便利である。交換ページは，紛失することがあり，かつ，文書の全ての所有者に
常に届くわけではないので，利用者が有効期限切れの文書で仕事をするリスクがある。交換用
に印刷したページを発行することによって更新するのは，利用者が僅かな大部な文書だけにす
ることが望ましい。
43
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
10 文書類の構造
印刷した文書類及び画面上の文書類の構造は双方共に，分冊又は区分を構成する方法及び利用者にそれ
らを表示する順序を含んでいる。文書類は，単独の文書として構造化してもよく，印刷した文書又は画面
上の文書集合として構造化してもよい。文書類の構造は，利用者が情報の内容を見つけること及び理解す
ることを助けることが望ましい。文書集合が甚だしく異なるニーズの読者層を扱うとき，次の構造の少な
くとも一つを使わなければならない。
− 一つの読者層に固有なニーズを扱うそれぞれの節の集まり（序文で，どの節が利用者にとって意味あ
るものかを識別できるように，対象とする読者層及びその読者層のニーズを具体的に識別しなければ
ならない。）
− それぞれの特定の読者層のための別々の文書又は文書集合
10.1 文書類の全体的な構造
一つの文書集合は一つ以上の文書から成ってもよい，かつ，文書集合の各文書は1巻以上であってもよ
い。例えば，印刷した命令マニュアルは，命令の半分を含む1巻及び命令の残りの半分を含む第2巻があ
ってもよい。文書は，固有な内容で構成単位に構造化しなければならない。うまく構造化した文書類では，
情報が必要なところで冗長性なしで利用可能になる。
この後の記述において使用する用語群（章，トピック項など。初出時に斜体で示す。）は，この規格で規
定する文書類の構造を記述するためのものである。印刷した文書は，章と呼ぶ論理的な構成単位に構造化
され，かつ，ページと呼ぶ物理的な構成単位で印刷される。章は，トピック項に細分され，トピック項は
サブトピック項に細分されてもよい。長い参照資料は，附属書又は付録で提示される。画面上の文書は，
トピック項と呼ぶ論理的な構成単位に構造化され，かつ，ページ又は画面と呼ぶ物理的な構成単位で提示
される。物理的な表示装置の違いから，ここで使う画面という用語は，利用者に表示する情報を必ずしも
一度に全部表示することではなく，むしろ簡単なスクロール操作で情報の全体の集合を使えるようにする
ことを示している。
文書類の見出しは，各セクションにどんな情報が含まれているかを明確にかつ一意に示すことが望まし
い。
各ページ又は画面は，一意に名付けなければならない（例えば，ページ若しくはトピック項の番号，又
は画面の名称若しくは番号）。画面上の文書の各トピック項は，それを見る又は印刷する場合，親文書に属
すことを識別できることが望ましい。例えば，ステータスバー又はヘッダが文書又はファイル名を示す。
文書類の構造，章又はトピック項の長さ，及びページ又は画面（物理的な構成単位）に表示する情報の
量は，次の幾つかの考察に依存する。
− ソフトウェアを使用している間の文書類へのアクセス
− 情報の量
− 情報の複雑さ
− 必要な図表の個数及び大きさ
− 読者層の情報への精通
− 媒体の制限
− ユーザインタフェースから見るソフトウェアの構造
− 利用モード
文書類設計者は，印刷した短い文書をたくさん作らないほうがよく，また，多くの情報を一つの扱いに
44
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
くい文書にまとめないほうがよい。文書が大きくなり過ぎたならば，文書類設計者は，次によってそれの
分割を考えることが望ましい。
− 概念的及び教習の情報を一つの文書に入れ，かつ，参考情報を別の文書に入れる。
− 異なる種類の参考情報を別々にしておく。例えば，概念に関連する情報のための一つの文書及び早引
きの検索のための別の文書。
小節が文書内のどこにあるのか利用者が分かるように，小節の階層は制限することが望ましい。印刷し
た文書は，章の中では3水準を超えない細分で構造化しなければならない。例えば，小節番号の1.2.3.4が
最も低い水準の細分である。画面上の文書は，トピック項の最初のページから3回を超えないジャンプ（す
なわち，3回を超えないリンク）で情報にアクセスできるように構造化しなければならない（文書を開く
ために必要な動作は数えない。）。
訂正によって若しくは更新によって，又は別の言語への翻訳によって生じる情報の量の変化に容易に適
応できるように，文書類設計者は，文書類の構造を柔軟にすることが望ましい。
文書類の構成は，利用（教習又は参照）モードを支援しなければならない。文書が教習及び参照の両方
の資料を含むとき，この二つは，異なる章若しくはトピック項に明確に分離するか，又は章若しくはトピ
ック項の中で体裁設定によって区別しなければならない。
10.1.1 教習モードの文書類の構造
作業指向の教習モードの文書類は，利用者の作業に従って構造化された手順を含まなければならない。
関連する作業は，同じ章又はトピック項にまとめることが望ましい。章及びトピック項は，学習を容易に
するため，簡単な作業を複雑な作業の前に，一般的な作業を頻繁には行わない作業の前に，初期作業を後
続の作業の前に提示するよう構成することが望ましい。また，作業を実行するのに必要な論理的な順番に
章及びトピック項を構成してもよい。
10.1.2 参照モードの文書類の構造
参照モードの文書類は，個々の情報の構成単位へのランダムアクセスを容易にするために配置すること
が望ましい。総合的な参照文書は，逐次的には使われない。文書内の任意の場所で，利用者が以前の節で
扱った情報のどれかを見ているだろうと仮定してはならないので，相互参照又はリンクを使う。利用者が
問題をもっているとき，関連する項目をすぐに見つけられ，かつ，それによってすぐに答えを見つけられ
るように，参照文書に情報を示す。情報は，アプリケーションの特徴によるのと同じく，利用者の質問又
は問題のキーワードによって検索可能又は索引付けられることが望ましい。例えば，利用者が特定の結果
を達成するために，ソフトウェア製品の機能又はキーボードのキーのどれを使う必要があるかを説明する
ための早引きの情報は，ソフトウェア製品の機能又は使う必要があるキーに基づくだけでなく，利用者が
達成したい結果に基づいて構造化できる。
ソフトウェアの命令のリスト又はエラーメッセージは，アルファベット順又はメッセージ番号順に並べ
ることが望ましい。
注記 アルファベット順が使用されていて，かつ，文書類を翻訳するならば，順番が変更されるかも
しれない。
問題解決又はトラブルシューティングの情報は，早引きのために構造化されることが望ましい。例えば，
アプリケーションのどの部分に適用されるのかに従って，又は利用者が行う作業の種類に従って，質問を
グループ化するのがよい。
10.2 読者層のニーズに従った文書類の構造
文書類でどんな情報を供給したらよいかを決めるために，文書類設計者は，情報プロファイル（12.3参
45
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
照）及び利用場面の詳細を調べることが望ましく，かつ，文書類によってどのニーズを支援するか及びど
のニーズを支援しないかを決めることが望ましい。
情報プロファイルの必ずしも全ての情報を文書類で納入する必要はない。対象の読者層の情報ニーズは，
文書化計画の中で（できるだけ）識別することが望ましく，かつ，可能ならば納入の仕組みも識別するこ
とが望ましい。それぞれの読者層に対して，文書類設計者は，要求される手続的な情報及び概念的な情報，
並びにその情報を納入する方法を指定する必要がある。計画が承認されたとき，特定の納入経路の適切性
に関するどんな仮定も確認又は改訂されてもよい。読者層に情報を納入するための代替経路には，次があ
る。
− 教育訓練
− ソフトウェアユーザインタフェースへの組込み
− 利用者同士が情報を共有できる，実際に役立つ交流の場の提供
− 他の製品の利用者用文書類，高等教育，商業訓練コースなどの他の情報源の利用
ある利用者に必要なセキュリティ情報は，他の利用者のための情報とは別の文書に構造化されることが
望ましい。例えば，マルチユーザシステムのアクセス制御セキュリティの管理に関する情報は，最終利用
者のための情報と同じ文書に含めないほうがよい。代わりに，文書類設計者は，その情報の場所の参照を
提供することが望ましい。
図8及び図9は，読者層の情報ニーズを文書類の集合の構造がどのように支援できるかを示している。
情 報
読 者 層
管理者
保守管理者
運用者
監査員
使用したアルゴリズム
ハードウェアの要求事項
コードの構造
報告の定義
図8−文書内容を決定するための読者層の情報ニーズの利用
プログラムマニュアル
管理者マニュアル
オンラインヘルプの報告
×は，この読者層にこの情報が
必要なことを示す。
×
×
×
×
×
×
×
×
×
46
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
管理者
一般利用者
専門的利用者
概要
設計概念
タスク
複写する見本
参照
図9−発送方法を決定するための情報の種類及び用法の使用
10.3 画面上の文書類のトピック項の大きさ
文書類設計者は，使用するツールではなく利用者のニーズによって，利用者に供給する個々のトピック
項の大きさを決めることが望ましい。トピック項の大きさを決めるとき，文書類設計者は，次を考慮する
ことが望ましい。
− 最も一般的に使われている出力装置で，利用者がスクロールせずに一度に見ることができる情報の量
− 利用可能な情報の量に対して，利用者が実際に必要とする情報の量
− 利用者が知らなければならない情報は何か，そのために，ある情報を常に表示し，かつ，追加の情報
を欲しい人をそこへ案内できるように追加の情報が使えることを示すこと
− ヘルプの必要性の緊急度を考慮に入れて，利用者が吸収できそうな情報の量
− 情報が1か所で提供されない場合，利用者が行わなければならない追加のナビゲーションステップの
個数
可能ならば，文書類設計者は，トピック項全体が一度に見えるようにすることが望ましい。これができ
ない場合には，文書類設計者は，スクロール又はページ替えの方法を提供し，かつ，利用者が情報の中を
どれくらい遠くまで移動したかを明確にすることが望ましい（12.13参照）。利用者が多量の文章の中をス
クロールする場合，文書類設計者は，利用者が興味をもっている特定の対象が簡単に見つけられるように，
文章を構造化することが望ましい。
注記 紙に印刷することを特に意図する文書のための設計の特徴は，附属書Dに含む。
読 者 層
印刷できる画面
上の設計指針
オンライン
ヘルプシステム
情報の種類
印刷できる画面上のセ
キュリティ指針
セキュリティ機能の
概要
セキュリティタスク
保守タスク
設計機能の概要
単純な設計概念
単純な設計概念
高度な設計概念
単純な設計タスク 単純な設計タスク
高度な設計タスク
見本の設計
見本の設計
各画面又は領域の
詳細の早引き
各画面又は領域の
詳細の早引き
各画面又は領域の
詳細の早引き
47
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
10.4 利用者用文書類の構成要素
表2に，要求される及び任意の文書の構造，内容，及び体裁の構成要素を列挙する。構成要素は，印刷
した文書類ではこの順番に配置してもよい。
情報が存在しないか又は特定の文書には適用できないとき以外には，要求される構成要素は，文書類に
含まれていなければならない。例えば，取決めの記述は概要の文書に適用しなくてよい。構成要素の名称
を変えてもよい。例えば，序文のために提案した情報は，”まえがき“と名付けた節に入れることができる。
表2で指定された要求事項は，組織又はプロジェクトのニーズを満たすために修整してもよい（2.1の適
合性の定義を参照。）。
表2−文書類の構成要素
構成要素
箇条
必要か
識別データ（パッケージ名称及び／又は表題ページ） 11.3
はい
目次
12.14.1
識別データの後が約8ページを超える文書のと
き，はい。
図表リスト（又は図及び表で別々のリスト）
12.14.3
任意
序文
10.5.1
はい
文書類の使用のための情報
11.4
はい
運用の概念
11.5
はい
手順
11.7
はい（教習モード）
ソフトウェアの命令の情報
11.8
はい（参照モード）
エラーメッセージ及び問題解決
11.10
はい
用語集
11.12
文書類がなじみのない用語を含んでいるとき，は
い。
関連情報源（参考文献，参考文献リスト）
11.13
任意
ナビゲーション機能
12.13
はい
索引
12.14.4
約40ページを超える文書のとき，はい。
検索能力
12.14.5
約8ページを超える画面上の文書のとき，はい。
文書の集合の中の文書のための最初の構成要素は，その文書の主題よりむしろ集合との関連で文書を定
義する章を含んでもよい。しばしば“この文書について”と呼ぶこの章は，“最初にお読み下さい”の情報
の形である。また，この章は，識別，ナビゲーションの方向，免責条項，及び警告のようにしばしば個々
の文書よりむしろ集合に共通な形である。この情報の分離によって，序文は，文書集合ではなくて特定の
文書の主題に関することに制限できるようになる。この章は主題に関することではないので，しばしば目
次に先行する前付として提供され，別冊の“手引”文書の代わりにできる。
10.5 利用者用文書類の構成要素の配置
10.5.1 初期構成要素
それぞれの個別の文書は，目次（12.13参照）及び序文が後に続く識別データ（11.3）から始まるように
構造化しなければならない。すなわち，序文は，文書の最初の章又はトピック項である。
序文は，文書の意図している読者層，適用範囲，及び目的について説明し，かつ，ソフトウェアの目的，
機能，及び運用環境の簡潔な概要を含まなければならない。利用者が文書類を使用する前に幾つかの用語
を理解する必要があるとき，文書類作成者は，例えば，用語集又は運用の概念のような，情報をどこで見
つければよいかを利用者に教えることが望ましい。
文書の中で各章及びトピック項に序文を提供しなければならない。文書化するソフトウェアのそれぞれ
の主要な特徴又は機能のために入門の節を準備することが望ましい。入門の節は，トピック項の概要，機
48
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
能の目的，及びそのトピック項に特有な環境の要求事項，警告，注意，又は利用者の要求事項を提供しな
ければならない。
10.5.2 重大情報の配置
重大情報は，文書類の中で際立った場所に置くことが望ましい。ソフトウェア又は文書類の利用の間中
適用される一般的な警告又は注意は，最初の構成要素に現れなければならない。利用者が知っている必要
がある致命的な情報があるならば，文書類作成者は，例えば，最初にアプリケーションを開始するとき又
はアプリケーションを開始するたびごとのいずれかにその情報を表示することで，全ての利用者がその情
報を見ることを確実にすることが望ましい。
特定の警告及び注意は，同じページ又は画面に，かつ，注意を必要とする手順又はステップの直前に，
現れなければならない。
注記 文書類作成者は，注意，注，及び警告を正しく区別するために，文書類のために使うスタイル
ガイドを調べることが望ましい。
11 利用者用文書類の情報の内容
この箇条は，完全性及び正確性（11.1及び11.2参照）を含む，利用者用文書類に含める情報の特性を規
定する。この箇条は，また，利用者用文書類（11.3及びそれ以降を参照）で含める必須情報を定義する。
この箇条で要求している情報は，情報が存在しない場合又は特定の文書には適用できない場合以外は，文
書類に含まれなければならない。
文書類の内容は，利用モードに関連する。ソフトウェアの利用者は，ソフトウェアの使い方を学ぶ（教
習モード）ため又はソフトウェアについての記憶を回復する（参照モード）ために文書を必要とする。教
習モードの文書は，情報指向又は作業指向であってもよい。情報指向の文書は，ソフトウェアを正しく使
うために必要な概念及び技術的な情報について利用者に指示する（11.5参照）。作業指向の文書は，目標に
到達するための手順を完了する方法を利用者に示す（11.7参照）。参照モードの文書類は，例えば，入力可
能なデータ値又は命令を表示する，ポップアップリスト又はドロップダウンリストのように，状況依存で
あってもよいし，かつ，ソフトウェアと統合してもよい。
教習用又は参照用文書類はいずれも，文書類の内容を例及び図表を含めることで改良してもよい。
注記 JIS X 0171:2014は，利用者用文書類を含む，ライフサイクルを通じて要求される情報項目（ド
キュメンテーション）の内容の指針を提供する。
11.1 情報の完全性
文書類は，全ての重大な（その故障が安全に影響を与えることがあったり，又は大きな財政的若しくは
社会的な損失をもたらすことがある）ソフトウェアの機能のための，教習用及び参照用の完全な情報を提
供しなければならない。教習モードの文書類は，読者層の中で最も経験のない人々がソフトウェアの機能
を使って選択した作業を遂行できるために完全な情報を含まなければならない。参照モードの文書類は，
文書化するように選択した要素の全ての事実を含んでいなければならない。例えば，参照モードの文書類
が，ソフトウェアの命令の部分集合を包含しているならば，その部分集合に関連する利用者が入力する命
令及びシステムが表示する命令並びにエラーメッセージを含んでいなければならない。
ソフトウェアについて及びそれがどう機能を実行するかについては，膨大な情報が利用可能であっても
よいが，教習モードの文書類は，利用者が作業を実行するために必要なものだけを含んでいることが望ま
しい。
49
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
11.2 情報の正確性
文書類は，適用可能なソフトウェアの版の機能及び結果を正確に反映しなければならない。文書類の前
の版がもはや正確でなければ，ソフトウェアの更新版又は性能向上版を取得する顧客のために，現在の文
書類が利用可能でなければならない。文書類の訂正及び更新は，ウェブサイト上の新しいマニュアル，リ
ードミーファイル若しくは訂正表，又はダウンロード可能なファイルで提供してもよい。
11.3 識別データの内容
文書類は，一意な識別データを含まなければならない。識別データは，次を含まなければならない。
− 文書類の題名
− 文書類の版及び発行日付
− ソフトウェア製品及び版
− 発行組織
識別データは，包装を開けずに読むことができる包装の名札，及び題名のページに表記しなければなら
ない。題名のページが包装を開けずに読むことができるならば，包装の名札は必要ない。文書集合の各文
書には，一意な題名のページがなければならない。早引きカードのような1ページの文書に関しては，識
別データは文書の残りと同じページに現れてもよい。
文書の題名は，その性質及び適用範囲を示すことが望ましく，かつ，意図している読者層にとってなじ
み深くない略語又は頭文字語を含んでいないことが望ましい。ソフトウェアの異なる版が異なる運用環境
で利用可能ならば，題名ページは，ハードウェア，情報伝送，及びオペレーティングシステムの版を含む，
適用可能な操作環境を指定することが望ましい。
次に示すその他の情報は，包装の名札及び題名ページ又はそれ以降のページに含まれてもよい。
− 文書及びソフトウェア製品の部品番号
− 通し番号
− 使用の制限
注記 ソフトウェア製品の識別には，名前，オペレーティングシステム，刊行物の版（edition），ソ
フトウェアの版（version），使用可能言語，及び日付を含んでもよい。
包装の名札及び題名ページのすぐ後ろに続くページには，次を含むことが望ましい。
− 国際標準図書番号（ISBN）
− 著作権及び商標表示
− 文書類の複写及び配布の制限
− 発行組織（利用者のコメントのため）に連絡するための情報
− 教育訓練及び関連する支援，ソフトウェア支援，品質保証，並びにソースコードの利用可能性を含む，
製造業者の法的責任及び消費者の権利のような，製品保証，契約上の義務，又は免責条項
− 文書が複数の部分からなるとき，全ての部分のリスト
− 文書が印刷された国
− 一般的な警告及び注意
− 適合の度合い又は水準を示して，ソフトウェアが従う規格の参照
− 承認
50
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
文書類設計者は，アプリケーションに関する著作権及び版の詳細について含まなければならないものに
ついて，法律的な助言を得ることが望ましい。このデータは，国ごとに異なる。
製品の製造業者又は供給者，及び文書の出版社又は作成者を問合せ先情報に提供してもよい。問合せ先
情報には，郵便の宛先，電話及びファックス番号，電子メールの宛先，並びにURLを含めてもよい。
文書及びソフトウェアの識別は，発行組織又は取得組織の構成管理の実践と一致していなければならな
い。情報（変更履歴）は，最新版の発行日及び版番号を記録するために文書集合に提供しなければならな
い，かつ，文書類の各旧版のための情報を含んでもよい。
利用者が支援を求めたときアプリケーションについての詳細を引用する必要があるならば，これらは簡
単に見つけられることが望ましい。
ソフトウェア製品を翻訳すべきならば，文書類設計者は，例えば，会社又は製品のロゴとして，グラフ
ィックを製品識別情報の一部として使うかどうかを慎重に決めることが望ましい。製品の異なる言語の版
のために，元とは異なる翻訳したグラフィックが必要であってもよい。
11.4 文書類の利用のための情報
文書類は，それをどう使うべきかの情報（例えば，ヘルプを使うためのヘルプ），及び記法に関する説明
（体裁及び取決めの説明11.12及び12.11参照）を含まなければならない。文書集合の少なくとも一つの文
書が，その集合の中の全ての文書の題名及び利用の意図を明らかにしなければならない。このとき，各読
者層が参考にするのが望ましい文書類中の節を明確にしておくことが望ましい。多くの巻又は文書類の製
品からなる文書集合では，この情報は，文書集合の別の“手引”又は指針で提供してもよい。文書類は，
文書集合及びソフトウェアの旧版からの顕著な変更の識別及び詳解を含んでもよい。
11.5 運用の概念
文書類は，ソフトウェアを利用するための概念的な背景を説明するに当たり，プロセス又は作業フロー
についての視覚的又は言語的な概要説明といった手法を用いてもよいし，運用についての理論，原理，ア
ルゴリズム，又は一般的な概念を示すといった手法を用いてもよい。運用の概念に関する説明は，作業及
びソフトウェアの機能のための特殊な専門用語がどれだけ利用者にとってなじみ深いかの予測に基づき，
その程度に合わせることが望ましい。文書類は，それぞれの文書化した機能を全体のプロセス又は作業に
関連付けなければならない。作業フロープロセスの概要記述は，関係する人々の役割及び責任を識別する
ことが望ましい。概念的な情報は，一つの節の中又はそれぞれの適用する手順の直前に示してもよい。図
表は，プロセスを記述するためにしばしば役立っている。概念の記述が，ソフトウェア製品の特定の機能，
又は特定の作業に言及する場合，文書類で，利用者がそれらの機能又は作業についての情報にリンクする
ことを許してもよい。
命令又はデータ入力の入力例は，特に日付についていつも明確に説明することが望ましい。
例 顧客の生年月日を入力しなさい。例えば：12/10/1980。
上の例では，要求する書式についての情報（mm/dd/yyyy又はdd/mm/yyyy）がないので，利用者にとっ
て，月優先，日優先のいずれを使えばよいのかが分からない。
利用者からの入力の説明の例を図10に示す。
51
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
数式
例
数式を用いて，値の計算を実行し（実際に計算するのは計算機だが。），結果をセルに入れることができる。
式に使う値は，次であってもよい。
− 入力する数値。
− セル参照で与えた，他のセルに入っている数値。
− システムが提供する関数を利用して得た数値。
＋ −*/などの演算子を使って計算を指定する。
例：= (D6/D10)*100
この式は，セルD6及びセルD10に格納した数値の比の百分率を計算し，表示する。
式で使っているセルの中でどれかの値を変更すると，プログラムが自動的に式の結果を更新する。
関連項目
関数のリスト
手動再計算モード
図10−例の提示の見本
利用者用文書類は，ソフトウェア機能の組織よりむしろ利用者の作業を支援するために組織化されるこ
とが望ましい。しかし，新しい利用者にとっては，アプリケーションの機能の説明が有用であってもよい。
図11にソフトウェア機能の概要説明の例を示す。
NIGELとは何か。
NIGEL（ネットワーク統合型グラフィカル実体位置表示）は，販売及び候補の追跡システムである。これは，次
に示すことができる。
− 顧客及び顧客候補の記録の作成
− 各顧客の担当者（“連絡先”）の記録
− 各連絡先を呼び出すための備忘録の設定
− 顧客候補の詳細の記録
− 顧客との会話の詳細の記録
NIGELはOPSYS並びに特にOPSYSの仕事の付番及び仕事の追跡機能と結び付いている。NIGELはまた，販売
統計の追跡，及び販売活動に関する定期的な報告の提供を行う。
関連項目
OPSYSの概要
NIGELのメニュー構造
図11−ソフトウェア製品モジュールのための概要の見本
アプリケーションの機能の画面上の記述のために，文書類作成者は，利用者が画面上の文書類と同時に
アプリケーションの画面を見ることができるかどうか決めることが望ましい。次の指針は，機能に関する
説明のために適用することが望ましい。
− 機能名を主な見出し又は情報ウィンドウの題名として使うことが望ましい。
注記 “題名”は，情報ウィンドウ又は画面の第1水準の見出しを指し，ここでいう“見出し”は，
第2水準又は第3水準の見出しを指している。
− 利用者が，これが興味をもっている機能であると確認するのを助けるために，機能の目的の短い文を
一番初めに含むことが望ましい。
52
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 機能が，使用できる状況及び使用できない状況を説明することが望ましい。
− 機能を使ったとき利用者が実現できることを説明することが望ましい。
− 利用者が，アプリケーションがどうなるのかを決めるための動き方又は機能の使い方を理解する必要
があるならば，その情報を含めることが望ましい。
11.6 ソフトウェアの一般的な利用のための情報
作業指向の教習モード文書類は，ソフトウェアの一般的な利用に必要な次のような定例作業についての
指示を含まなければならない。
− ソフトウェアの導入及び削除（利用者が実行する場合）
− グラフィカルユーザインタフェースの諸特性（12.11参照）についての概要教示
− ソフトウェアへのアクセス，すなわち，ログオン及び利用終了など
− ソフトウェアのナビゲーションによる，機能へのアクセス及び機能からの離脱
− データ操作（入力，保存，読込み，印刷，更新，及び削除）。データ入力方法の普通ではないどんな特
徴（例えば，スライダ，ボタン，若しくは特別なキーの使用，又は表示されたリストからの選択）も，
指示が取り扱うことが望ましい。
− 操作の取消し，中断，及び再起動の方法
注記 ナビゲーション又はデータ入力の典型的な方法を実行すると誤りを引き起こす場合，文書類
は，そのことを示すのが望ましい。例えば，“ʻ支払い受領ʼメッセージを受けとるまでは，
ブラウザの戻るボタンを使わない，又はその他のどんなキーも押さない。”と示す。
これらの共通な手順は，これらがより複雑な機能で使用されるとき，冗長さを避けるために一度だけ提
示することが望ましい。
11.7 手順及び学習書のための情報
教習モード文書類は，手順を実行するための指示を提供する。手順は，次を含まなければならない。
− 準備の情報
− 教習のステップ
− 完了の情報
11.7.1 手順のための準備の情報
数個の手順の集合に共通な準備の情報は，冗長さを避けるために組み合わせ，かつ，一度に提示しても
よい。手順のための準備の情報は，次を含まなければならない。
− 手順の目的の簡潔な概要，及び他の場所には含まれていない必要な概念の定義又は説明の簡潔な概要
− 作業を始める前に行わなければならないどんな技術的又は管理上の活動の識別
− 利用者が作業を完了するために必要な資源のリスト。これには，データ，文書，パスワード，付加的
なソフトウェア，及びドライバ，インタフェース又はプロトコルの識別を含んでもよい。
注記1 ソフトウェアの依存は，導入プロセスの間に重大な問題かもしれない。これらの依存には，
時代遅れのソフトウェア，以前に導入した版，所有権付きで導入したソフトウェアを含む
かもしれない。
− 手順全体に適用される，関連する警告，注意，及び注
注記2 関連する警告，注意，及び注は，それぞれの適用する教習のステップ又は一組のステップ
の直前に置く。メッセージの情報が，ある動作を実行するかどうかの利用者の意思決定に
影響するかもしれないならば，意思決定を行う位置にメッセージを表示することが望まし
53
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
い。
注記3 文書類作成者は，注意，注，及び警告を正しく区別するために，文書類のために使ってい
るスタイルガイドを参考にすることが望ましい。
11.7.2 手順のステップ
手順のステップは，アラビア数字を使って番号付けし，かつ，実施する順番に提示しなければならない。
利用者が，どの代替又は繰返しのステップを実行するか又は飛ばして進むか及びどこで主要な手順に戻る
かを簡単に決められるように，代替又は繰返しのステップを明確に示すことが望ましい。可能ならば，文
書類作成者は能動態を使うことが望ましい。受動態及び能動態の構文の追加の指針をB.2.6に示す。しか
しながら，既存の企業又は顧客のスタイルを観察することが望ましい。
英語，フランス語，及びその他の言語で，命令形が存在し，かつ，文化的に許されるならば，文書類作
成者は，利用者の動作を記述するために命令形を使うことが望ましい。
手順のステップは，予想した結果又はシステムの応答を示さなければならない。
手順のステップは，許容できる範囲，最大の長さ及び適切な体裁の文書類，並びに利用者が供給するデ
ータのデータ欄の計測の単位を含むか又は参照を提供しなければならない。
手順のステップは，エラーメッセージ及び回復手順の説明を含むか又は参照を提供するかしなければな
らない。
早引きの情報は，相互参照又はリンクを使う作業指示で必要なところに含むことが望ましい。
注記1 許容されるデータ形式及び値は，ポップアップリストによって通常は注釈付けられる。
手順は，複雑な作業又は考えを完全に説明するように，より簡単な構成要素へ分解することが望ましい。
しかしながら，文書類作成者は，複雑な作業を実際よりも簡単に見せることを避けることが望ましい。ソ
フトウェアが効果的に利用者の作業を実行するための働き方を，利用者が理解することが必要ならば，文
書類作成者は，動作の前又は準備情報の一部として簡単な説明を提供することが望ましい。
注記2 多くのステップがある手順は，ステップの少数の集合に構造化することが望ましい。作業が
長いか又は複雑な場合，文書類作成者は，より小さい作業がお互いにどう関連しているかを
示すプロセスのトピックとともに，一つの作業をより小さい作業に分けることを考えること
が望ましい。
11.7.3 手順のための完了情報
全ての手順は，手順が首尾よく完了したことが，利用者にとって明らかであることを確実にしなければ
ならない。この明確化は，手順の最終ステップの結果に関するフィードバックを，利用者に単に提供する
ことによって達成してもよい。手順が条件付きのステップ又は飛び越しを含むならば，手順は数個の論理
的な終点をもつことができる。この場合，利用者がどんな残りのステップも続けるのを試みないことを確
実にするために，それらのステップのフィードバック情報の後に“手順完了”の句を挿入することが望ま
しい。必要に応じて，利用者が手順を終了する望ましい方法及び次の典型的な活動は何か（モジュールの
文書類では，普通これは分からない。）を記述することもまた望ましい。
表3は，手順の例である。
54
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表3−要素を明確にした手順の例
内容の種類
内容の例
題名
新しい連絡先の作成
目的
取引先の会社でシステムにまだ登録されていない人を見つけたときに，新しい連絡先を作成
する。
準備情報
取引先の会社は既にシステムに登録されていなければならない。少なくとも顧客の姓又は名
前，及び電話番号又はEメールアドレスが必要である。
前提条件
その連絡先に入る前に，姓を検索し以前に扱ったかを明らかにするために，メニューの“登
録項目を開く”を使う。顧客が異なる組織に移っている場合には，以前の登録項目に注をリ
ンクするか，又は以前の登録項目に“離脱”の印を付ける必要があるかもしれない。
教習のステップ
新しい連絡先を作成するには，次を行う。
1. “会社”のドロップダウンリストから，取引先会社の記録を選択する。
2. メニューから“新規の連絡先”を選択する。
3. 取引先の種類の選択肢から“連絡先”を選択し，“はい（OK）”ボタンを押す。
4. “連絡先”パネルで，連絡先の詳細な情報を入力する。
5. “保存”ボタンを押す。
完了情報
システムは，メッセージ“保存しました，更に追加しますか。”を返す。
関連項目
補足的記録（取引先の注記）の設定
連絡先の削除
注記 画面上の手順では，しばしば指示の短縮形を使う。表3の例の，ステップ3では，“はいを押す
（OK）。”，ステップ5では“保存を押す。”が好まれる。
11.7.4 学習書
学習書は，管理できる作業の節に構造化することが望ましい。開始学習書に対しては，作業の節を平均
的な利用対象者が最大10分で作業を終わるようにすることが望ましい。教習を目的とするためには，複雑
な作業を副作業に構造化することが望ましい。学習書は，利用者がすぐに情報を見つけるのに慣れるよう
に，利用者に参照資料を指し示すことが望ましい。学習書は，教育訓練用に提供された見本の原ファイル
を変更せずに，利用者が自分の作業を保存できるようにすることが望ましい。学習書中の例は，それが正
しいことを確実にするためにテストすることが望ましい。ステップの系列を説明するために例を使う所で
は，系列中で例が一貫するようにする。
11.8 ソフトウェアの命令についての情報
文書化しているシステムの構文を観察して，文書類作成者は，必須パラメータ，任意パラメータ，省略
時のオプション，命令の順序，及び構文（12.11.1参照）を含む，利用者が入力するソフトウェアの命令の
書式及び手順を説明しなければならない。マクロ及びスクリプトの開発及び保守についての文書類を提供
してもよい。
注記 省略時のオプションとは，特に指定しなかったとき初期設定として指定されている値又は設定
を指す。
参照モードの文書類は，予約語又は命令の参照一覧表を含まなければならない。
例は，命令の使用法を説明することが望ましい。問題の解決法を見つけるために，利用者は普通，自身
の問題の状況と同様な具体的な実例を，マニュアルで検索する。
文書類は，命令の実行中に操作を中断及び復元する方法並びに可能ならば再実行する方法を説明しなけ
ればならない。文書類は，命令の実行が成功したか又は異常終了したかを見分ける方法を示さなければな
らない。図12は，ソフトウェア命令の機能の文書類の例である。
55
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
acos
ラジアン単位のxのアークコサイン（逆余弦）を与える。アークコサインはコサインがxとなる角度である。
構文
acos(x)
ここに，xは範囲−1≦x≦1の10進数である。
結果
範囲0≦A≦πのラジアン単位の角度A。
xが範囲外のとき，ERR（エラー）を表示する。
例
acos(0.5)は1.047（π/3ラジアン）となる。
acos(−1)は3.142（πラジアン）となる。
関連関数
ラジアンを度に変換する：rad2deg
角度のコサイン（余弦）を求める：cos
図12−表計算の関数のための関数の記述例
11.9 データ入力欄の説明
GUIの設計では，利用者がデータの入力をしてもよいとき又は表示されているデータを変更してもよい
ときを明確にすることが望ましい。GUIの設計では，利用者が理解できる専門用語で欄の記述又は名前を
含むことが望ましい。その欄の短い説明は，ポップアップ又は埋込みのヘルプに含めてもよい。この方法
は，画面上のあらゆる欄又は選択肢のための長たらしい個別の文書類の替わりとなることがある。データ
入力欄の文書類は，許容される選択肢の全範囲，例えば，“パスワードは，8〜10文字で，少なくとも数字
1文字及び英大文字1文字を含まなければならない。”を示すことが望ましい。
条件付きの欄，すなわち，状況又は他の欄の設定に依存する欄については，現在の状況の下でどんな選
択肢が使えるかを説明する。文書類は，選択肢及び適用する条件を説明してもよいし，又は利用可能な選
択肢だけを含めてもよい。
注記 指針の文書類及び学習書は，一般に使用する選択肢だけを記述し，選択肢の完全なリストを参
照用文書類に残してもよい。
文書類は，欄に表示した情報の意味を説明してもよいし，また，その値が他のとり得る値にどう関連す
るかを説明して表示した値の意味を示してもよい。
11.10
エラーメッセージ及び問題解決の内容
ソフトウェアシステムは，特にトランザクション処理が結果を即座に返さないとき正常な操作を確認す
るため，及び誤りを利用者に知らせるために，メッセージを提供することが望ましい。参照モードの文書
類は，問題の識別，推定される原因，及び利用者が行うことが望ましい是正処置とともに各エラーメッセ
ージを含まなければならない。
注記 できるだけ早く，文書類作成者は，明確で，簡潔で，正確で，かつ，役に立つことを確実にす
るためにエラーメッセージの言葉遣いに関して，ソフトウェア開発者に指針を提供することが
望ましい。
文書類は，利用者が自分で問題から回復するか又は技術支援要員に問題を明確に報告するかのいずれか
を行うのに十分な詳細さで，ソフトウェアを使うときの全ての既知の問題に対処することが望ましい。早
引きカードは，より詳細な参照用文書類を利用者が参照することでエラーメッセージに対処してもよい。
問題解決の文書類はまた，ソフトウェア又はその文書類の問題の報告のため，及び改良の提案のための連
56
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
絡先情報を含んでいなければならない。
メッセージは，利用者が選択した動作の効果を記述することが望ましい。例えば，“取消しを押すと，こ
のセッションは購入なしで終了します。”と表示する。システムの応答は，利用者が応答を選択したとき，
実際に何が行われるのかが分かるように，“はい”又は“いいえ”ではなく“削除する”又は“削除しない”
か，“削除”又は“取消し”かのように，特定の作業の選択を利用者に提示することが望ましい。システム
メッセージは，保存していないデータの削除，アプリケーションの終了，又はセキュリティリスクに対す
るアプリケーションの開始のような，重大な結果を生じる可能性がある動作をアプリケーションがとる前
に，要求の取消し又は修正の機会を利用者に与えることが望ましい。
エラーメッセージは，複数のステップからなる解決を避けることが望ましい。複数のステップが避けら
れないとき，ソフトウェアは，利用者に別の指示を参照させてもよいし，又は適切なウィンドウを表示す
るために状況依存ヘルプのボタンを加えてもよい。
文書類は，利用者が必要とする情報にアクセス又は参照して，是正処置についての質問に具体的に，か
つ，包括的に答えることが望ましい。例えば，“プリンタのページサイズをリセットする。”ことを利用者
に指示するよりむしろ，文書類は，利用者が使う必要があるのはどの機能か及び変更する必要がある詳細
は何かを利用者に伝えるか，又は適切な手順のトピック項へのリンクを与えることが望ましい。
セキュリティへのアクセスエラーに関連するメッセージは，権限のない人の侵入を助長することがない
ように，必要以上の情報を提供しないほうがよい。
文書類作成者は，ソフトウェア製品そのものに精通するだけでなく確立した基盤及びオペレーティング
システムの情報メッセージに精通していることが望ましく，これによって矛盾する助言を与えてトータル
システムに対する全般的な責任を背負い込んだりする可能性を避けることが望ましい。
利用者へのエラーメッセージは，技術的業界用語及びシステム指向の情報の使用を避けることが望まし
い。メッセージを構成するとき，文書類作成者は，次の指針を使うことが望ましい。
− 言葉又は用語の省略形は，使わないことが望ましい。技術的なメッセージでは特に，短縮形は理解す
るのに時間がかかるし，うまく翻訳するのが難しいかもしれない。
− 利用者を責める又は利用者の誤りをほのめかす言い回しは，避けるほうがよい。
− アプリケーション又はハードウェアが考えたり又は感じたりするかもしれないことをほのめかす表現
又は言葉遣いは，使わないほうがよい。
11.11
警告及び注意の内容
警告又は注意は，次の部品を含まなければならない。
− 見出し語，例えば，“警告”又は“注意”
− 図記号
− 危険の簡単な記述
− 危険を避けることに関する指示の文章
− 利用者，設備，ソフトウェア，データ，又はサービスが危険を被る結果
− もしあれば，不都合な結果に対する利用者の救済策
潜在的な物理的な危険又は命を脅かす状況の警告に使われている確立した安全グラフィック及び安全記
号を，他の目的に使用しないほうがよい。結果が利用者にとってどんなに厳しいものであっても（例えば，
データが削除されてしまうように厳しいものであっても），文書類は，注意のためには別の図記号を使うこ
とが望ましい。
注意及び警告の体裁設定についての情報は，12.15を参照。
57
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記 文書類作成者は，注意，注，及び警告を正しく区別するために，文書類のために使っているス
タイルガイドを参考にすることが望ましい。
11.12
専門用語の情報
文書類は，利用者になじみがある簡単な語彙を使うことが望ましい。専門家の語彙が特定のアプリケー
ション領域で使われているとき，文書類は，一般に使っている不適切な語彙よりはむしろその専門家の語
彙を使うことが望ましい。
ソフトウェアのユーザインタフェース又は文書類の中の用語又はそれらの特定の使い方が，読者層の中
の初心者になじみがない傾向がある場合には，文書類は用語集を含まなければならない。用語集は，用語
及び定義の五十音順のリストを含まなければならない。また，用語集はインタフェース要素の欄の定義並
びに名前及び用途のような情報項目を含んでもよい。用語集は，ソフトウェア開発者の用語ではなく利用
者の用語で，語彙を定義することが望ましい。
注記 用語集における専門用語及び用語の順序は，翻訳によって変更される。
印刷した文書類では，用語集若しくは同様の参照用文書，又は記述的な文書類の中に用語の定義を常に
含んでいることが望ましい。
文書類作成者は，ソフトウェアインタフェース，メッセージ，及び文書類で一貫していて，かつ，正し
い専門用語を確実にするために，ソフトウェア開発者に指針を提供することが望ましい。文書類は，同じ
ような条件に対しては単語及び言葉遣いが一貫していることが望ましい。定義した用語は，どこで出現し
ても同じであることが望ましい。
用語定義の例を図13に示す。
連絡先
顧客（親会社）に関連しているNIGEL（ネットワーク統合型グラフィカル実体位置表示）システムに登録された人。
候補者と比較する。
図13−用語の定義の例
11.13
関連情報に関する情報
文書類は，参考文献，参照のリスト，又は関連するウェブページへのリンク（図14）のような関連情報
の源へのアクセスについての情報を含んでもよい。文書類は，強制的な（必須の）要求事項又は参考とな
る背景資料を参照が含むかどうかを示すことが望ましい。
関連情報の源及び参照は，次を含んでもよい。
− 命令参照ガイド又は管理者マニュアルのような，現在の文書類の集合における他の関連している文書
− ソフトウェア及び文書類のための要求事項仕様，設計仕様，及び適用可能規格
− ソフトウェア及び文書類のためのテスト計画及び手順
− ソフトウェア及び文書類のための構成管理方針及び手順
− ハードウェア及びソフトウェア環境のための文書類
− 運用の概念又はソフトウェアで具体化された科学的，技術的，若しくは業務のプロセスに関する説明
58
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図14−関連情報へのリンクの例
11.14
利用者が提供した内容
画面上の文書類は，利用者が彼ら自身の内容を加えるか又は既存の内容をカスタマイズするのを可能に
するための機能を含んでもよい。提供された機能には，会社のロゴ，許容値のリスト，既存のトピック項
への簡単な注釈，又は利用者自身の画面上の情報システム若しくは文書へのリンクの追加を含んでもよい
（関連項目は12.17参照。）。
利用者が提供又はカスタマイズした内容は次のとおりであってもよい。
− 大域的，すなわち，全ての利用者から見えてもよい。
− グループ，すなわち，利用者の特定のグループから見えてもよい。
− 局所的，すなわち，それを提供した利用者だけから見えてもよい。
製品供給者は，知的所有権を保持するための措置，並びに供給者及び顧客にはカスタマイズした文書類
に対してどんな法的責任があるかを明確にするための措置を講じることが望ましい。修正できる体裁で文
書類を供給するならば，供給者は，次のことを確実にしなければならない。
− 利用者は，重大な警告のように他の人が見なければならない情報を削除してはならない。
− 誤りは，修正されてもよい。
− 元の情報は，供給されたとおりに復元してもよい。
取得者は，カスタマイズした情報がソフトウェア製品の新しい版にも適用されるかどうかは分かってい
ないので，アプリケーション又は標準の文書を更新したとき，利用者が修正した情報がどうなるかを考え
ていることが望ましい。供給者は，供給された画面上の文書類の新しい版に，この情報を組み入れるため
の自動的な方法を提供してもよい。
宣伝情報のメニューの例
ウェブアドレス
コース
初心者コース
上級コース
専門家ワークショップ
文書
ファイル 編集 表示 Go ヘルプ
グループ及びイベント
国内クラブ
地域グループ
国内イベント
地域イベント
教材
設計
作業技術
参考図書
設計
作業技術
設計ライブラリ
59
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
12 文書類の提示体裁
12.1 一般
この箇条は，利用者用文書類を提示するための体裁を，次の点について示す。
− 容易に理解するために情報をどのように提示するか。
− 画面上の文書類でナビゲーションするために提供する仕組みは何か。
− 文書の著述及び図表の作成に使うスタイル及び手法は何か。
注記1 印刷した文書類のために附属書Dで追加情報を与える。
文書類の体裁は，画面上なのか印刷なのかの選択，並びに文体要素，印刷要素及びグラフィック要素の
ための提示の取決めを含む。この箇条は，様々な文書類の構成要素の体裁を規定する。
利用者用文書類の体裁設定における基本的な決定は，それを印刷又は画面上の媒体のいずれで納入する
かである。印刷した文書類は，早引きカードから包括的なマニュアルの集合まで，様々な体裁のものがあ
ってもよい。
画面上の文書類もまた，次の幾つかの体裁のものがあってもよい。
− 画面上で見ることを意図しているが，アプリケーションソフトウェアとは独立している（例えば，ヘ
ルプファイル，支援するウェブサイト，学習書など，利用者は画面上の文書類を見るためにアプリケ
ーションソフトウェアから抜け出る。見ることができる文書類はまた，場合によっては印刷されても
よい。）。
− 状況依存ヘルプ，エラーメッセージ，ポップアップ，ウィザードなど，ソフトウェアに埋め込まれて
いる。
注記2 アニメーション又はビデオセグメントは，画面上の文書に組み込んでもよく，人間が介在
する作業のように静的な図表では説明が容易ではないプロセス及び概念を示すために非常
に役立つ。例えば，“プリンタへの紙の補充方法”がある。
様々な要因によって，どんな体裁及び媒体が情報を提示するのに最も効果的であるかが決まる。これら
の要因は，次を含む。
− 視聴者の特性及び情報ニーズ
− 文書化する作業の本質
− 利用場面
− 情報の量
− 作成及び保守の費用
− 使用性
− 市場性
文書類の設計者は，できる限り最も便利な文書類を利用者に与えるという制約条件の中で働くことが望
ましい。例えば，文書類設計者は，全ての印刷した文書類が，定められた要求事項でない限り，本又はカ
ードでなければならないと仮定しないほうがよい。利用者のニーズによりよく合致するならば，例えばキ
ーボードテンプレート，掛図，名札などの他の形を考えることが望ましい。
12.2 印刷用の体裁又は画面上の体裁の使用
システムが使用不可能になる場合，印刷した文書類は，利用者が利用できる唯一のヘルプである。画面
60
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
上の文書類を提供するか否かに関係なく，次の文書類は製品のソフトウェアとは別に印刷した形で提示さ
れなければならない。
− ソフトウェア及び文書類のためのハードウェア，オペレーティングシステム，ブラウザ，及びその他
のソフトウェア要求事項
− 導入の指示に対する回復及びトラブルシューティングの情報を含む，導入及び構成の情報
− ソフトウェアを起動するための指示
− 画面上の文書類にアクセスするための指示
− 技術的支援の連絡先又は利用者が利用可能な回復動作の実行のための情報
電子的に入手可能なソフトウェアの場合，供給者はこの情報をウェブサイトで印刷可能な体裁で提供し
てもよい。このようにすれば，ソフトウェアをダウンロード又は導入する前に，利用者がこの情報を印刷
することができる。箱の中にこん（梱）包されて納入されるソフトウェアの場合，この情報は，印刷され
箱の中に収められていなければならない。
利用者がシステムから離れている間にも学べるので，利用者の便利のために，文書類の次に示す部分は，
印刷した形が好まれる場合がある。
− 利用初期に習熟するための情報
− 長い例
− 特にソフトウェアの高度な機能を利用するための，構造化した参照用資料
− 処理のためのチェックリスト
プリンタに接続して使うように設計したソフトウェアシステムでは，画面上の文書類を印刷できるよう
にするために設計したソフトウェア機能を含んでいることが望ましい。画面上の文書類を印刷する方法の
記述は，画面上及び印刷した文書類の両方に含むことが望ましい。システムは，利用者が次を印刷できる
ようにすることが望ましい。
− 現在のトピック項
− 一つの図表
− 一群のトピック項
− もしあれば，用語集。
− 早引きの情報（この情報が画面上で提供される場合でも，同等な印刷文書を提供しないときには，利
用者側で印刷可能であることが望ましい。）
注記 利用者は通常，画面上の情報の短い項目（アイコンの名前を与えるのに使っているものなど）
を印刷する必要はない。
画面上の文書類を提供するとき，ソフトウェアへの利用者入力が可能であるときはいつも，その文書類
が表示できなければならない。利用者は，機能を実行することとそれに関連する機能に固有な画面上の文
書類を読むことを同時に行えることが望ましい。利用者は，システムを操作している間，画面上の文書類
を見ることができ，かつ，関連するソフトウェア機能へ案内できることが望ましい。
12.3 適切な媒体及び体裁の選択
文書類の体裁の設計は，読者層及び作業の各組合せを考えることが望ましい。この組合せによる利用場
面によって情報の体裁を決めることが望ましいので，例えば次の点について考慮する。
61
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 情報が一時的にだけ必要であるか，又は見えたままで（永続的に）残ることが望ましいか。
− 利用者がアプリケーションを使って作業するのと同時に，情報が利用できなければならないか。
− 利用者に，回答をどれだけ早く提供する必要があるか。
− ソフトウェア製品が動かないときにヘルプを見つけるための情報など，アプリケーションが利用でき
ないときに，情報が使える必要があるか。
文書類設計者は，読者層及び作業の組合せ（情報プロファイル，例えば，表4のそれぞれについて，必
要なデータと各データに対する設計結果とを記録することが望ましい。
表4−一つの作業及び一つの読者層のための情報プロファイルの例
作業：旅行の見積り取得 読者層：切符取扱人
必要な情報
量
アプリケーシ
ョンと同時
永続的又
は一時的
緊急性
媒体
見積り取得のための作業の指示
− 出発地及び到着地の確定及
び入力
− 期間，総人数，及び切符種別
の入力
− 入手可能性のチェック
− 価格の算出
10までの
作業ステ
ップ
はい
永続的
急ぎ
画面上のヘルプシステム
の作業トピック
地点コードの一覧表
数百
はい
一時的
急ぎ
状況依存ヘルプ
切符種別の一覧表
50まで
はい
一時的
急ぎ
状況依存ヘルプ
旅客種別の一覧表
最大10
はい
一時的
急ぎ
状況依存ヘルプ
データ形式のための欄の使用法
の情報
一行
はい
一時的
急ぎ
ユーザインタフェース上
に表示
12.3.1 媒体の比較
しばしば，解決策は多様な媒体の使用を含む。文書類設計者は，表5からの媒体，特定のプロジェクト
に適合して使える又は発明されるかもしれないその他の媒体を加えて考えることが望ましい。
注記 これらの媒体の大部分は分離した文書類のためのものである。他の媒体は，分離した又は組込
み文書類のためのものであってもよい。
62
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表5−様々な媒体の利点及び欠点
媒体
利点
欠点
着脱式媒体
多くの文書を含むことができる。探すのが容
易。
安い制作費用。
適切なハードウェアが必要。
本
ページへの注釈付けが簡単。
携帯できて，システムから離れても使える。
大きくて，かつ，重いと，持ち歩くのが困難。
制作費用が高くなることがある。
更新が困難。
カード
少量の早引き情報に適する。
頻繁に必要な情報を表面に，及びまれに必要
な情報を裏面に置いてもよい。
片面だけが見える。
簡単に置き忘れる。
掛図
多量の早引き情報に適する。
表示のために比較的大きくきれいな壁の空間
が必要。
コンピュータに付
帯する通知
コンピュータでいつも必要である少量の情報
に適する。
あまりに多くの小さい通知でコンピュータを
取り散らかす危険。
リーフレット又は
パンフレット
保持する必要はない認識情報に適する。
学習書に便利であるかもしれない。
（ラミネート加工しない限り）連続使用の耐
久性はない。
画面上のヘルプ
キーの押下げ又はマウスのクリックで利用可
能。
早引き情報に適する。
長く続く文章には，適当でない。
アプリケーションの実行中にだけ，組込文書
類が使用可能である。
ビデオ
複雑な情報を簡単に吸収する。
ほとんどの利用者に受け入れられる，広く使
われている媒体。
作成は高価になることがある。
見るためには適切な支援ソフトウェアが必
要。
音が含まれているならば，利用者はイヤホー
ン又はコンピュータのスピーカが必要。
ウェブサイト
利用者に連絡せずに更新できる。
アプリケーションから自動的に開始できる。
利用者は，ウェブへのアクセスが必要。
12.3.2 アプリケーションの表示への情報表示の関係
画面上の文書類中の全ての制御の提示は，アプリケーション又はシステムのための制御と一致している
ことが望ましい。しかし，画面上の文書類は，利用者がアプリケーションの画面を見ているときと文書類
を見ているときとを区別できるように，提示することが望ましい。次の方法などを使用する。
− スタイルの異なるウィンドウ
− ウィンドウの明確な表題
− 異なる色
注記 JIS Z 8511〜JIS Z 8519及びJIS Z 8521〜JIS Z 8527は視覚表示装置（VDTs）による事務のた
めの人間工学的要求事項を定義する。JIS Z 8522:2006は，画面に情報を表示するときの詳細
な指針を与える。
アプリケーションインタフェースと同時に必要な情報は，少なくとも次の一つの方法で表示することが
望ましい。
63
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 組込文書類として情報を提供する。
− 情報及びアプリケーションの画面が同時に見えるように表示する。
− これらの二つの間を切り替える簡単な方法を提供する。
− 印刷した文書で情報を提供する。
画面上の参照モードの文書類を提供する場合，文書化するソフトウェアからアクセスしやすくなければ
ならず，かつ，文書類からの退出及びそのソフトウェアへの復帰のための明確な手段を提供しなければな
らない。ソフトウェアは，次に示すものなど様々な方法で，オンラインヘルプ，学習書，又は参照モード
の文書類にリンクしてもよい。
− トピック項のリスト又はヘルプシステムへの入口にリンクしたヘルプメニューを通して。
− 特定のトピックの情報を提供するソフトウェア画面上（ダイアログボックス及び欄についてのヘルプ）
のヘルプボタンを通して。
− 状況依存ヘルプ及びポップアップの文章（吹出し）を通して。
情報が常に必要な場合，利用者がキーを押すとき又は別のウィンドウを選択するときに，それを閉じな
いことが望ましい。
情報が一時的にだけ必要な場合，その情報を取り除くために利用者が特別なステップを採る必要がない
ように，利用者がアプリケーションで次の動作を行うときに，表示ウィンドウを閉じることが望ましい。
例えば，標準的な位置のポップアップウィンドウ又は一行の文章を使ってもよい。
12.4 状況依存の情報
文書類は，次の状況依存の情報を提供してもよい。
− 現在の欄
− 現在の作業
− 現在のアプリケーションの機能（ダイアログボックス，トランザクション，コマンドなど）
− 現在のメッセージ
− ユーザインタフェースのオブジェクト
利用者がヘルプを必要とする状況を決めることができないならば，表示するために上述の一つを選択し，
かつ，利用者が他の情報を選択するための仕組みを提供する。
情報が状況に依存するならば，次を行う。
− 状況に特定の項目を表示する。
− 要求される情報が長いトピック項の一片の場合，それが利用者の見る最初の情報になるように，情報
領域の最初に関連情報を表示する。
表6は，情報の異なる種類に対して適切かもしれないアクセス方法の幾つかの例を示す。
64
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表6−アクセス方法の例
情報の種類
アクセス方法
現在の作業のための作業記述
現在の機能のための機能記述
現在のメッセージの説明
特定のキーを押す。
ヘルプボタン又はアイコンをクリックする。
アイコンの名前
アイコンの利用法
欄の利用法
用語の定義
画面上のオブジェクトの上にポインタを置く。
オブジェクトを活性化する方法とは異なる方法を使
って，例えば，オブジェクトを強調，クリック，又
は接触で画面上のオブジェクトを選択する。
プロセス記述
概念
説明の情報
よくある質問
アプリケーションの概観
文書類の概観
画面上の情報を使うための指示
メニューから選択する（12.14.2参照）。
内容リストから見つける（12.14.1参照）。
索引から見つける（12.14.4参照）。
12.5 アクセスしやすい文書類
文書類は，作業環境における利用者の予想したグループにとって，利用しやすく，かつ，利用可能でな
ければならない。
12.5.1 理解できる文書類の提供
製品の文書類は，印刷又は画面上にかかわらず，作業の語彙を使って行える範囲で，明確で，かつ，簡
単な言葉を使って書くことが望ましい。
注記 機能性又は製品について明確に説明することが求められるところでは，技術的な用語の使用が
許される。
例 CAD（コンピュータ支援設計）システムの文書類は，製図分野からの専門用語を使用できる。
12.5.2 アクセスしやすい電子的な形式での利用者用文書類の提供
全ての利用者用文書類は，印刷及び画面上のいずれも，適用できる文書類のアクセシビリティ規格を満
たす電子的な形式で納入しなければならない。この文書類は，製品と一緒に，又は要求に応じて適時に及
び追加費用なしに提供しなければならない。
注記 “利用者”の区分は管理者を含む。ソフトウェア開発のソフトウェアのために，利用者には，
ソフトウェア開発者を含むことになる。
12.5.3 画面上の文書類における代替文章の提供
ソフトウェアによって画像及びグラフィックで示された情報は，また，代替の方法で読めるように，画
面読上げ，印刷，又は点字変換に適した説明文として提供しなければならない。
注記 情報の伝達のために文章及びグラフィックの両方を（省略時の提示として）同時に使うことは，
65
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
他方を補強するために一方を使う読者層及び情報処理の好みのスタイルが異なる人々（例えば，
視覚対聴覚）にとって，しばしば役立っている。
例 利用者は，オンラインヘルプの文章部分を印刷することができ，かつ，どんな埋込みグラフィッ
クの文字列記述も読むことができる。
12.5.4 不要な装置を参照しない指示の著述
ソフトウェアのための指示は，印刷又は画面上にかかわらず，特定の装置を参照しないで利用者の動作
及び結果の出力を言及するように書くことが望ましい。マウス又はキーボードのような装置の参照は，そ
れらが今与えている助言に不可欠であるとき及び理解するために必要であるときだけに行うことが望まし
い。
注記 マウスなどの特定の装置の操作が必要な状況に関しては，一般的な記述ができないかもしれな
い。しかしながら，そのような特定の記述の必要性は全ての状況ではなく，その装置の利用に
ついてのヘルプで生じるだけである。
例1 ヘルプの作業記述は，利用者が，それを使用するユーザインタフェース要素の色を認識するこ
とを必要としないので，“緑のアイコンをクリックする。”という文章は使わない。代わりに，
アイコンの名前を使う。
例2 アプリケーションは，利用可能なできるだけ多くの異なる入出力様式（例えば，マウス，キー
ボード，音声など）を使って作業を実行する方法の記述を提供する。
12.5.5 アクセシビリティ機能についての文書類の提供
印刷及び画面上の文書類は，アクセシビリティ機能の利用可能性についての一般的情報並びにそれぞれ
の機能の目的及び使用法についての情報を提供しなければならない。
注記 ソフトウェアのアクセシビリティ機能を容易に発見できることは，利用者にとって大切である。
例1 オンラインヘルプは，障害のある人々にとって興味がある機能について記述する節を提供する。
例2 オンラインヘルプは，キーボードだけでのソフトウェアの使用について説明する。
例3 オンラインヘルプは，フォントの大きさを調整する方法を記述する。
例4 製品は複数の色彩設計をもち，かつ，文書類及びオンラインヘルプは色覚異常の人々にどの色
彩設計が利用可能かを記述する。
12.6 体裁の一貫性
文書類は，ユーザインタフェースの構成要素，データ要素，欄名，機能，ページ，トピック項，及びプ
ロセスについて，文書集合を通して一貫した専門用語を使わなければならない。
体裁設定の取決めは，文書類の集合を通して適用しなければならない。体裁設定の取決めには色，境界，
字下げ，行間隔，及びフォントの変化を含んでもよい（12.13参照）。
アプリケーションがアイコン又は記号を使う場合，画面上の文書類は，それが何を表すかを説明しなけ
ればならない。文書類は，同じオブジェクトを表すためには同じアイコンを使うことが望ましい。文書類
は，他のオブジェクトを表すためにそれらのアイコンを使ってはならない。
画面上の文書類の中で，例えばナビゲーションのために，コントロールを必要とするところでは，それ
らは文書類のために合意された取決めに従うことが望ましい。
警告，注意，注などの，特別に重要な情報を強調するための体裁設定の取決めは，文書集合を通して一
貫して適用しなければならない。
注記 文書類作成者は，注意，注，及び警告を文書類の中で正しく区別するために，使用しているス
タイルガイドを調べることが望ましい。
66
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
文書類は，新しい内容又は変更した内容を識別するために特別な体裁設定を使ってもよい。
指示の集合などの類似した構成要素は，一貫した体裁で表現しなければならない。
別の操作環境，言語，又は文化の下で使うために文書類を適合させる場合，文書類の作成者及び翻訳者
が一貫性を維持するのを助けるために，文章及び図表のための一般的な用語集及びスタイルガイドを使う
ことが望ましい。原版の意図している意味を保存したまま，文書類を，より容易に適合，地域化，又は翻
訳できるようにするために，文化に特有ではないグラフィック及び色の選択を考慮することが望ましい。
画面上の文書類は，次の一つの“ルックアンドフィール（見た目及び使い勝手）”の体裁と一致している
ことが望ましい。
− 文書化しているソフトウェア
− 同じ一組の他のソフトウェア製品，又はその一組の親ソフトウェア製品
− オペレーティングシステム
− 利用者が使い慣れているかもしれない画面上の他の文書類
12.7 専門用語の一貫性
文書化のプロジェクト及び組織は，一貫した専門用語のために標準的な辞書を作成及び維持することが
望ましい。同じ意味になる所では同じ語句を使うことが望ましく，文をもっと興味深くするために異なる
語句を使うといった凝った変化は避ける。異なる語句を使うと，異なる意味を意図していると利用者に考
えさせてしまうことがある。文書類を翻訳するとき，この問題が受け継がれてしまう。なぜならば，翻訳
者は，異なる単語には異なる訳語が必要であると思い込むからであり，これによって余分な時間・労力が
費やされる。
文書類は，時々不正確に使われる語彙を避けることが望ましい。複数の意味をもつ単語を使うときには，
文書類はどの意味で使っているかの意図を明らかにすることが望ましい。頻繁に誤用される用語では，著
者が意図した意味ではなく，別の意味を意図していると利用者が考えるかもしれないので，その用語の正
確な意味が伝わることを当てにしないほうがよい。
次の指針によって，一貫した専門用語の使用を達成するのを助けることが望ましい。
− 産業特有の専門用語は，正しく使うことが望ましい。例えば，プロセス記述には，対象産業で使われ
ている職種を使うことが望ましい。
− 新しい用語の導入は，できるだけ少ないことが望ましい。新しい用語が必要なとき，それらは短く，
覚えやすく，かつ，言いやすいことが望ましい。
− 業界用語は，避けることが望ましい。業界用語の正確な代替用語があるならば，それを業界用語の代
わりに使うことが望ましい。代替の用語が全くないときには，その業界用語を定義することが望まし
い。
− 産業特有の又はその他のあまり目にしない頭字語を使う場合，それらを文書類で定義することが望ま
しい。文書類が画面上にある場合，頭字語を使っている各トピック項の中で，利用者がその定義を表
示できることが望ましい。文書類の長さを減らすための短縮形として，新しい頭字語を導入しないほ
うがよい。
− 利用者の環境又はアプリケーション領域で一般的な専門用語を使い，かつ，正しく使うことが望まし
い。文書類作成者の環境では一般的であるが，利用者の環境ではそうでない専門用語は，避けること
が望ましい。文書類作成者は，利用者の環境又はアプリケーション領域を十分に調査することが望ま
しい。疑問が生じたならば，利用者の調査を実施するか，又は利用者の環境の権威に相談する。
67
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
12.8 画面及びページのレイアウト
文書類設計者は，類似した情報の体裁のために一貫したレイアウトを準備しなければならない。
12.8.1 グリッド
設計者は，文書類を見るための最小及び最大の画素領域を決定することが望ましい。設計者は，利用者
がウィンドウの大きさを変更できてもよいことを念頭に置いて，それぞれの種類の画面上の文書類のウィ
ンドウ内で必要な要素をどう置くかを示すためにグリッドを準備することが望ましい。例えば，オンライ
ンヘルプのためには，グリッドが次を含むことが望ましい。
− トピック項の題名の領域
− （ウィンドウを閉じるなどの）ウィンドウのコントロール
− （スクロールバーなどの）ナビゲーションコントロール
− 情報の領域
− 余白
− 非スクロール領域及びスクロール領域
− 現在の情報がトピック項の中のどこにあるかを示す目印
− 注釈の配置
− 図表の位置決め
同じ種類の表示には，名前が付けられ，かつ，位置が決まっているナビゲーションコントロールを一貫
して使う設計が望ましい。設計者は，ウィンドウの大きさを変更したとき情報の領域，文章及び図表の大
きさ，並びに非スクロール領域に起こることを計画していることが望ましい。図15は，ヘルプシステムの
ナビゲータ及びトピック項ウィンドウのためのグリッドの例を示す。
68
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図15−ヘルプシステムのナビゲータ及びトピック項ウィンドウのためのグリッドの例
12.8.2 非スクロール領域
非スクロール領域に次の参照情報を表示し続ける設計が望ましい。
− トピック項題名（ウェブブラウザのウィンドウではタイトルバーに表示してもよい。）
− 主なトピック項又はホームページに戻るためのナビゲーションリンク
− 関連したトピック項に移動するためのナビゲーションコントロール
12.8.3 ウィンドウの配置
幾つかのウィンドウを同時に画面上で見ることができるときに，利用者が各ウィンドウ内で意味のある
ヘルプシステムの題名
ウィンドウのコントロール
メニュー
ファイル 表示 ヘルプ
表示アイコン，
及び新しいウィ
ンドウに表示の
アイコン
検索
ナビゲータのタブ
文章領域
幅325ピクセル
×
高さ440ピクセル
メニュー
索引
目次
文章領域
幅420ピクセル
×
高さ450ピクセル
ナビゲーション
コントロール
トピック項の
タイトル
関連する
トピック項
ヘルプシステムの題名
ファイル 実行 ツール
ウィンドウサイズ
幅450ピクセル
高さ600ピクセル
関連するトピックス
スクロールバー
ウィンドウ
のコントロール
69
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
量の情報を見ることができるように設計することが望ましい。アプリケーション及び文書類は，画面上で
のウィンドウの省略時の配置を固定してもよいが，利用者がウィンドウの省略時の配置及び大きさを無効
にし，かつ，利用者自身の配置を選択してもよい。ウィンドウの省略時の大きさ及び配置は，利用者が，
ウィンドウを移動せずに又はサイズを変更せずに，必要とする情報を見ることができ，かつ，アプリケー
ションで仕事を続けられるようにすることが望ましい。重複した（重ね合わせた）ウィンドウでは，ナビ
ゲーションコントロールを曖昧にしないほうがよい。重複したウィンドウは，次のときに適している。
− 時に応じて表示すべきウィンドウの個数及び大きさが異なる。
− 表示画面の解像度が非常に低いので，タイル表示のウィンドウでは利用者が意味のある量の情報を見
ることができない。
− 重なって見えない領域は必要でない。
12.8.4 情報領域（文章）の体裁
文章の体裁は，理解を助けることが望ましい。多量の連続した文章は追うのが難しい。明確な節見出し
とともに，文章を短い節に分割することが望ましい。これによって，利用者が文書の中のどの位置にいる
のかの確認及び特定のトピックについて必要とする情報の発見を助ける。
多量の連続した文章に対しては，惜しみなく行間を空けるように設計することが望ましい。文書類設計
者は，各節を新しいページから始め，かつ，利用者が情報を見つけられるように各ページに大きな見出し
を付けることを考慮することが望ましい。印刷した文書類は，それぞれの節又は章を区別するために仕切
りページを使ってもよい。それぞれの節へアクセスするために，辞書の小口で“あ行”，“か行”などを示
している目印のような，ページの縁の別々の縦位置に黒又は色の付いた目印（爪見出し）を使ってもよい。
ページレイアウトは，見出し及び注のための一つの欄並びに文章のための別の欄のような複数の欄を含
んでもよい。連続した文章は，上下方向又は前後方向のスクロールを避けるために単一の欄に提示するこ
とが望ましい。情報領域は，一度に表示するには長過ぎる情報には，利用者が全体を垂直にスクロールで
きるようにすることが望ましい。文章又は図表の全体の幅を見るために，利用者が水平にスクロールする
必要はないほうがよい。文字列は，画面上の文章領域内で折り返すことが望ましい。情報の題名は，利用
者が垂直にスクロールしたときでも目に見えるまま残ることが望ましい。連続した文章を表に提示する場
合，文章を読むのが難しくなるので，設計は，欄の幅が過度に狭くならないことを確実にすることが望ま
しい。
注記 英語に対しては，最大行長を約60文字にすると読解しやすいかもしれない。
12.8.5 見出しのための体裁
トピック項の階層構造での見出しの水準は，フォントサイズ及び太字の使用のような，印刷の取決めに
よって示すことが望ましい。小見出しを表すためには，しばしば字下げを使う。しかし，利用者が文書類
を読んでいるとき，一度に目に見える見出しの水準は一つしかないかもしれないので，字下げによって階
層構造の中の見出しの位置をすぐに決めることはできない。
意味のない見出しが意味のある見出しより重要に見えるのを避けるために，水平方向の間隔を慎重に使
うように設計することが望ましい。節番号を左そろえではなく右そろえで並べると，長い番号の方が短い
番号よりも目立つので，このようなことが起こるかもしれない。
利用者にとって文書中の一意な位置又は長い手順における進捗を意識することが重要なとき，見出しに
付番することが望ましい。実践的には，区別できる体裁をもつ3水準の階層構造があれば，利用者は，章
の初め，トピック項，又はサブトピック項を読んでいるのかどうかを理解できる。
見出しを準備するとき，文書類作成者は，利用者が文書類を見て生じるかもしれない質問の種類を考慮
70
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
することが望ましい。可能ならば，題名及び見出しは，どんな質問に答えられるのかを示すことが望まし
い。
12.8.6 余白及び境界
ウィンドウに提示された要素を明確に分離するように設計することが望ましい。線又はその他の境界を
描くよりも，空間を空ける（余白を使用する）ことで，視覚的な妨げが減少し，ウィンドウに一様な外観
を与える。利用者が，（警告及び注意のような）特定の種類の情報を区別すること又は関連する情報をひと
まとめに保つことを助けるために，枠で囲んだ文章，図形（境界）を使ってもよい。枠及び境界を，装飾
のためだけには使わないほうがよい。
注記 余白は，“白い”間隔（空白）とも呼ばれる。12.12参照。
12.8.7 行間
文書の階層構造を示すために，上位及び下位の見出しに対して行間を一貫して使うように設計すること
が望ましい。
− ページ又は画面上のトピック項の最初の見出しを除いて，第2水準の見出しの上の行間よりも第1水
準の見出しの上の行間を大きくすることが望ましい。同様に，第2水準の見出しの上には，第3水準
の見出しより大きな行間があることが望ましい。
− 各見出しは，少なくとも本文の段落と同じ大きさの行間で，本文と離れていることが望ましい。
− 追込み見出し及び下に行間を取っていない最低水準の見出しは，あまり強調されない。
注記1 “追込み見出し”とは，“本文と同じ行に置かれる見出し”のこと。
段落は，行間を空けることが望ましい。この空間は，一つの段落の終わり及び次の段落の始まりがどこ
かを利用者が見るのを助け，並びにひとまとまりの情報の量を減らす。段落間の空間には，描線又は他の
装飾図形を使用しないほうがよい。
注記2 段落間に行間があるところでは，段落の最初の行を字下げする必要はない。
段落間の行間は，見出し及び本文の垂直的な階層組織を保つように，本文の行送りの半分以上かつ2倍
以下であることが望ましい。例えば，印刷した文書類で12ポイントの行幅のときには，段落間の空間は6
ポイントから24ポイントの間が望ましい。
本文の行が互いに接近し過ぎて見えるのではなく，利用者がある行から次の行に容易に動けることを確
実にするように，本文の行送り（“レディング”）を選択する。本文の大きさより2又は3ポイント大きい
行送りが推奨される。例えば，10ポイントの本文には，行送りを12ポイントにする。
注記3 レディングは，印刷用語で横書きの文字で，行間隔を決める文字上部の余白のことである。
12.9 視認性
印刷した文書類及び画面上の文書類は，予想した作業環境における利用者と文書類との間の距離を考慮
に入れて，利用者にとって読みやすくなければならない。文書類は，予想した背景（紙の色又は画面の背
景色）に対して読みやすいフォントスタイル及び色を使わなければならない。
法的な要求事項でなければ，1文以上の連続した文字列に大文字を使わないほうがよい。全て大文字の
文章は読むのが難しく，かつ，その結果，利用者がそれを無視するかもしれない。
図表に文字列を含む印刷した文章は，ページ上で測定した大文字が2.75 mm未満であってはならない。
設計者は，画面に表示した文字列の測定量としてポイントサイズの内部の設定を当てにしない方がよく，
使用される全ての種類の画面に表示した大きさを測定することが望ましい。
画面上の文書類は，コンピュータ用モニタ又は表示装置とソフトウェアグラフィックドライバとの予測
71
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
した組合せを含む，利用者の予想した作業環境で読みやすいことが望ましい。読みやすさは，次のような
出力装置（モニタ及びプリンタ），すなわち，1) 白黒である，2) 解像度が低い，3) 別の色で描画する，又
は4) 表示できる色に制限がある，の影響を受ける場合がある。指定したフォントが利用可能でない場合，
幾つかの出力装置は代替のフォント又は特殊文字を適用してもよい。
二つ以上の階調の色又は灰色の色調に依存する区別は，見えないかもしれない。ある利用者は色を区別
できないので，文書類は，意味を伝える唯一の方法として赤又は緑のような色を使うのではなく，文章で
手掛かりを提供することが望ましい。また，着色した文字列の補助にアイコンを手掛かりとして使っても
よい。
12.9.1 書体及び本文の大きさ
設計者は，計画した提示技術又は再現方法に容易に利用できる書体を選択することが望ましい。画面上
の文書類に使用する書体と大きさとを選択するとき，設計者は次を考慮することが望ましい。
− 使用される異なる表示装置の画面の範囲及び本文の大きさを変更する利用者の能力
− 利用者のシステムで利用可能な省略時の書体及び大きさの範囲
注記1 文書類に利用者のコンピュータに実装していないフォントを使うと，コンピュータはそれ
らのフォントを省略時のフォントに取り替える。
− 文書類が使われる異なる物理的環境
− 文書類の翻訳：必要な言語のための必要な文字集合は，利用可能である必要がある。
− 文書類に必要とされる特殊文字（著作権記号など）の利用可能性
− 選択したフォントの文字の大きさ
注記2 名目上同じフォントサイズが異なる書体で全く違って見えてもよい。コンピュータの表示
装置上で計画した活字フォントの視認性を常に確認する。
小文字のL，大文字のI，及び数字の1が区別できない，又は数字の0と大文字Oとが区別できない書
体を設計は使わないほうがよい。
設計者は，3個以下の異なる書体を選択し，それらを一貫して使うことが望ましい。書体の選択した大
きさ及び重さは，情報をどう使うのかを考慮に入れることが望ましい。選択した書体は，次の情報の要素
を区別するのを助けることが望ましい。
− 見出し
− 通常の文章（書体は見出しのために使ったものと同じであってもよい。）
あまりに多くの異なる書体を避けるために，印刷した文書類のヘッダ情報及びフッタ情報は，本文又は
見出しに使った書体の一つを使うことが望ましい。
12.9.2 文字列の強調
文字列の強調は，意味を伝える通常の文章の書体とは異なるものを一貫して使うことによって達成して
もよい。
太字文字列は，次に示すものなどの重要な情報を強調するために一貫して使ってもよい。
− 見出し
− 表の欄見出し
− 図及び表の題名
72
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
数語以上の単語では斜体の文字列は，特に画面上で読むのが難しいかもしれない。斜体の文字列は，次
に示すものに使ってもよい。
− コマンドの変数
− 新しい用語の導入
− 記事及び書名の参照
下線付きの文字列は，アクティブなハイパーリンクを表すためにだけ使うことが望ましい。画面上の文
書類では，リンクはまた，選択すると色を変更することが望ましい。文章中のアクティブ領域ではない見
出しに下線を使用しないほうがよい。
角括弧及び波括弧のような特殊符号で囲んだ文字列は，特別な種類の文字列，特に利用者が入力した文
字列，を識別するために使ってもよい。
次に示す強調の方法は，利用者の視覚を紛らわすので避けることが望ましい。
− 文字のディセンダに交差する下線を引くこと
注記 ディセンダは，yの下部のような英文字の基準線より下の部分のことである。
− 明滅及びアニメーション（文字列自体を明滅することで，単語を強調しないほうがよい。必要ならば，
文字列の横に，明滅してもよいマーカを表示することが望ましい。）
− 単語又は句の全体の大文字による表記
12.9.3 文章の列
左から右へ読む用字において，文章は右そろえではなく，左そろえで並べることが望ましい［右端不ぞ
ろ（揃）い］。
注記 この規格は，ソフトウェアの文書類ではないのでこの体裁は使用せず，JISの体裁設定規則に
従う。
分離禁止スペースは，読みやすくするために使うことが望ましい。例えば，測定の量と単位との間に改
行がないほうがよい。
良くない体裁設定
望ましい体裁設定
標本抽出率は1
kHzである。
標本抽出率は
1 kHzである。
12.10
リストの形式
リストは，次に示すことに役立つ。
− どの選択肢が必要かを利用者が一目で見ることができるような選択肢の集合
− 順番に実行する必要がある動作
− 別々の要点とみなしてもよい一連の情報
厳密にいうと，リストは，図表ではなく文章である。しかしながらリストは，ときには強調のために境
界で囲み，題名を付けた図として扱ってもよい。
リストの提示の取決めは，利用者が情報を理解するのを助けることが望ましい。リストの体裁は，個々
の項目に注意を向けさせるために項目間に間隔を空ける。リストは，より簡単に理解できるように，下位
区分の入れ子の階層の深さは二つ以下にすることが望ましい。過度に細分したリストは，幾つかのリスト
に分割することが望ましい。一つのリストが画面上又は1ページ内で一度に見えないほど長いならば，選
73
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
択したナビゲーション手法を使ってアクセスしやすいように，別々の文章に細分することが望ましい。
設計者は，リスト内及びサブリスト内の項目を識別するため，及びリストのそれぞれの項目の終端に句
読点を打つ（又は打たない）ために一貫した取決めを確立することが望ましい。一般に，リストは黒丸又
は他の特殊文字で開始することが望ましい。第2水準のリストには，異なる文字及び字下げを使うことが
望ましい。リスト中の事象の順番又は項目の正確な番号が重要な場合にだけ，リストの項目に番号を振る
ことが望ましい。ローマ数字は，長さが大きく違い，素早く読みづらく，かつ，全ての文化でよく知られ
ているわけではないので，文書類では使わないほうがよい。
注記 文書類作成者は，利用者が順番に従わなければならない一連のステップのためにはアラビア数
字を使うことが望ましい。手順についてのステップがサブステップを含んでいる場合，これら
のサブステップはその文書を書いたアルファベットの最初の文字で始まる連続した文字で示す
ことが望ましい。
リストの黒丸がナビゲーションコントロール（ラジオボタン又は選択肢ボタン）として使われているな
らば，それらの外観は本文の非アクティブ領域における黒丸とは区別することが望ましい。
12.11
ユーザインタフェース要素を表すための体裁
次の様々な要素と文章とがそれぞれ区別されるように，一貫したグラフィック又は印刷の体裁によって，
文書類の中で表現しなければならない。
− ボタン，アイコン，並びに可変のカーソル及びポインタのような，ソフトウェアのグラフィカルユー
ザインタフェース（GUI）要素
− キーボードキー又はキーの組合せの特別な利用法
− システムの応答
文書類は，実際の操作の例で，要素の表現，その目的，及びその動作（機能的結果）の説明を含むこと
が望ましい。画面上の文書類は，GUI要素のためのポップアップの文字列の名札を含んでもよい。
ソフトウェアでの実際の対話から取った文字列を組み込む文書類は，文字列を文字ごとに正確に複写す
ることが望ましい。
12.11.1
コントロール及びコマンド入力の表現
利用者が入力するコマンド又はコードのための文書類の体裁は，定数（表示したものと全く同じに入力
するもの）と変数（利用者が準備するもの）とを明確に区別しなければならない。例えば，変数のファイ
ル名は，実際のファイル名に置き換えなければならない一般用語として使ってもよい。文書類は，独特の
形（例えば，斜体）で変数を表すことが望ましい。
丸括弧，波括弧，不等号（より大>）及び不等号（より小<），並びに他の記号の正式な記法は，参考文
献における参照のための［…］を除いて，それを使用するあらゆる文書の中で定義しなければならない。
引用符は，利用者がそれらを文字どおりに入力することが望ましい場合以外は，コマンドの表現に使って
はならない。
例
画面に次のメッセージを表示する。
最初のコマンドを入力してください。
最初の文字列レコードを作成するために，レコード名をそのレコードに付けたい名前に置き換
えて，次のコマンドを入力し，それからEnterキーを押しなさい。
レコード名を作成する。
74
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
12.11.2
特別なキーボードキーの表現
文書類は，特別なキーボードキーを表現するために一貫した取決めを確立し，かつ，入力に特別なキー
を使用するソフトウェアのために文書類でその取決めについて説明しなければならない。文章中で，文書
類は，次に示すものの一つなどの，取決めによって他の状況で使用される同じ文字と，個々のキーボード
キーを参照する用語又は記号とを区別することが望ましい。
− 特別な活字書体又はフォント：例えば，大文字，小さな大文字，又は太字の使用。
− キートップの画像：画像が文書の普通の文字列より大きいならば，画像は余白，リスト，又は表に置
いてもよい。
− 用語又は記号を囲むための“<”及び“>”などの特殊文字：それらの文字自体を，同じ方法で表す必
要がないことを注意深く調べる。>キーを表す<>>又は二重引用符を表す<”>などの文字列を避ける。
文書類は，予想した利用者の作業環境におけるキーボード又はデータ入力装置の相違に言及することが
望ましい。文書類は，キートップの文字が異なる，異なるキーボードが使えるかどうかを示すことが望ま
しい。文書類は，Enter，Shift，及びTabのようなキーの名前のために一貫した取決めを設定することが望
ましい。ソフトウェアのための指示及びヘルプは，特定の装置を参照せずに利用者の動作及び結果の出力
について言及するように書くことが望ましい。マウス又はキーボードなどの装置について述べるのは，そ
れらが文書類で与える助言の理解に不可欠であるとき及び必要であるときだけにとどめることが望ましい。
間隔を表するための取決めがしばしば必要になる。文書類は，文書類又はソフトウェアのいずれかで他
の目的に使われない文字を使うことが望ましい。
キーの図表は，明るい背景に暗い文字を使うことが望ましい。逆の文字列（暗い背景の明るい文字）は
図表では読みにくい。
12.12
色の使用
色は意味を伝えるために役に立つ方法であるが，設計者は，色が文書類に不可欠かどうかを考慮するこ
とが望ましい。グラフィックソフトウェア又は可視化ソフトウェアに関して，ある文書類では，色の正確
な表現が不可欠であり，かつ，白黒の文書類は不適切である。大部分の他の文書類では，色は強調のため
に使われるが，色盲又はある色を知覚又は区別できないかもしれない視覚障害のある利用者が，ソフトウ
ェアを使う場合がある。この状況において，意味を伝えるために色だけを使うのではなく，図表の網掛け
又は陰影のパターンの異なる種類などの強調の別の形式も同様に採用する設計が望ましい。
色は，作業の状況から利用者の注意を簡単にそらすので，利用者の効率を下げるかもしれない。通常，2
又は3色で十分である。設計者は，白黒の設計から始めることが望ましく，使用している他の強調手法に
追加の強調を提供するところで色を加えることが望ましい。色の選択は，濃淡階調又は白黒に変換したと
き，明暗差及び色調の値で十分な差があることを確実にするために，妥当性を確認することが望ましい。
オブジェクトの知覚性は背景色によるので，設計者は背景には中間色を選択することが望ましい。設計
者は，白ではない背景に着色したオブジェクトを置くときに注意することが望ましい。背景用又は表示領
域を埋めるためには無地（白など）の色を使う。設計者はまた，画面上にパターン効果を引き起こす色を
避けることが望ましい。
色を使用するとき，設計者は，次を行うことが望ましい。
− 利用者の表示装置で利用可能なカラーパレットを決定する。何人か又は全ての利用者が，白黒の表示
装置しかもっていないかもしれないことを考慮する。どの範囲の色が使えるようになるか決定する。
全ての利用者に適した色彩設計及びパレットを選ぶ。利用者の画面に色を正しく表示するために，文
75
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
書類の納入ツール（もしあれば）の標準のパレットからの色だけを使う。利用者は，複数のパレット
又は代替のパレットを同時に表示できないかもしれないので，これらを使用しない。
− 利用者が白黒のプリンタで文書類を印刷しそうかどうか，又は利用者がカラープリンタをもつと予想
されるかどうか決定する。内容をカラー及び白黒のプリンタで印刷するとき，色がどう現れるかに注
意する。
− どの色及びどの色の組合せが，最もよく再現及び表示するのか，かつ，最も混乱を引き起こさないか
をテストする。
− 組込みの文書類と印刷した文書類との間で色の一貫性が重要なところでは，提案した色を徹底的に確
認する。
− 色盲の利用者への色の使用の影響を考える。青及び緑，又は赤及び緑のような，多くの場合に区別で
きない色の組合せの選択を避ける。
− 色の文化的な解釈及び用法を考える。国際的な読者層のために，異なる色の組合せの文化的な言外の
意味を考える。
− 色を扱うことが可能な印刷文書類のための印刷方式を選ぶ。色の一貫した再現は難しいかもしれない。
ある方法は，他の方法より色をゆがめてしまう。コンピュータ用モニタ又はインクジェット式プリン
タで利用可能なRGBの色域を使って選択した色は，CMYKの色域を使用する装置（オフセット又は
カラーレーザ技術）で印刷すると，同じには見えないかもしれないことに特に注意する。
− フルカラー印刷は，黒だけの場合又は黒に1色を加えた場合よりも通常は高価なことを記憶にとどめ
ておく。決定する前に，印刷する組織とともに再現のための費用見積りを検証する。
12.13
ナビゲーションの機構
ナビゲーションのための機構は，次を含む。
− 章及びトピック項の題名並びに見出し
− ページ又は画面の題名
− 章，題名，ページ，及び画面番号
− タブ
− ページヘッダ及びフッタ
− しおり
− リンク
− 相互参照
− ナビゲーションのアイコン
− ボタン
文書類は，通常とは異なるような，柔軟な，又は複雑なシステム固有な及び複雑な文書固有な，ナビゲ
ーションの機構の説明を含まなければならない。
注記1 分析及び設計プロセスは，例えば，ある時間内に又はある個数のステップを使って正しい情
報を見つけることができるべきという，速度及びアクセスの容易さのために使用性の目的を
設定する（6.4参照）。
ナビゲーション機構は，利用者が現在の位置から動いてもよい位置を示すことが望ましい。階層構造の
異なる部分のトピック項にリンクするための機能を提供するならば，文書類は，そのトピック項が階層構
造のどこにあるかを示してもよい。利用者が画面上の文書類のトピック項の間を動き回るならば，文書類
76
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
は現在のトピック項が全体の構造のどこにあるかを示してもよい（“ブレッドクラムトレール”又はホーム
ページ若しくは主メニューからの経路。）。例えば，文書類のトピック項の題名にそれが文書構造のどこに
属するかを説明する単語若しくは線図を含めること，又は目次リストで新しい位置を強調することが望ま
しい。
注記2 “ブレッドクラム（トレール）”は，パンくずで印をつけた足跡のように利用者がウェブサイ
ト内を移動した経路を示す機構である。国内では“パンくずリスト”という用語が使われて
いる。
ナビゲーション機構は，文書類の利用者が次の場所に行けるようにしなければならない。
− 戻る。直前のリンク元の節又は直前のページ
− 次へ。（もしあるのならば）トピック項の系列中の論理的に次のトピック項又は次のページ
− 前へ。（もしあるのならば）今見ているトピック項又はページの論理的に直前のトピック項又は直前の
ページ
− （もしあるのならば）目次又は最上位のメニュー
− （もしあるのならば）索引
文書類は，画面上の情報から脱出する簡単な方法を提供することが望ましい。脱出方法は，画面上の情
報の全てにおいて同じであることが望ましい。
12.13.1
トピック項中の位置を示すための体裁の使用
トピック項が一つのウィンドウだけで見えるよりも長い場合，文書類は，トピック項の中のどこにいる
かを知る明確な方法を利用者に与えることが望ましい。次の手法を適用してもよい。
− 利用者がある種類の情報をどこで見つけることができるかが分かるように，同じ種類のトピック項は，
同じように構造化することが望ましい。例えば，“目的”，“指示”，“例”，及び“関連作業”などの作
業を説明する見出しを付ける。
− 全体の情報の中でどのくらいまで進んできたのかを単純に示すのではなく，全体の構造の中のどの場
所を見ているのかが利用者に分かるように，見出しに付番することが望ましい。
− スクロールバー又は節番号及び終端表示のような他の指標は，情報の終わりまであとどれくらいかを
利用者に示すことが望ましい（指示の長い集まりで特に役に立つ。）。
− 長いトピック項は，次々に見ることができるようにより小さいトピック項へ分割することが望ましい。
トピック項の完全な集合を示すためにメニューを使い，かつ，既に見たトピック項を示すためマーカ
を使う。
文書類は，更に詳しい情報があるかどうか及びそれにアクセスする方法を常に明確にすることが望まし
い。
12.13.2
同じ情報の再発見
印刷した又は画面上の文書類の中で利用者が自分の位置を決定できるように，ナビゲーションのための
機構を提供しなければならない。印刷した文書類では，各ページは，一意なページ番号をもっていなけれ
ばならない。画面上の文書類では，各ページ又は画面は，利用者が見ることができる一意な識別子（英数
字又はキャプション）をもっていなければならない。画面上の文書類が本文のスクロールを許す場合，ナ
ビゲーション機構は固定した場所にアクセスしやすいまま残すことが望ましい。情報領域が長い場合，本
文をスクロールしたときに題名は，表示され続けることが望ましい。
77
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
文書類は，現在のセッション又は別のセッションにおいて，利用者が後で情報に戻れるようにすること
が望ましい。この復帰は，次の手法によって達成してもよい。
− 利用者がこのセッション，又はこのセッション及び以前のセッションのいずれかで見たトピック項を
累積したリスト。利用者はそこからトピック項を選択してもよい。
− 利用者が戻りたいと思う場所のマーク付けを可能にするしおり。
− 利用者が同じ経路をたどることができる明確な構造。
− 利用者がどのトピック項を見たかを示す，注釈を付けた又は強調したメニュー。
使用する手法は，一貫し，かつ，簡単に使えることが望ましい。例えば，リストが維持されているなら
ば，それが使えるところならどこでも，利用者がそのリストにアクセスするために同じ方法を提供する。
12.13.3
連続したトピック項の閲覧
トピック項の幾つかのグループ（ブラウズの系列）のための自然な順序があれば，文書類は，利用者が
前及び後の両方向に順番にトピック項を見る方法を提供することが望ましい。
提供した方法が，前方及び後方に動かすために特定のキーの組合せを利用者が使うことを要求する場合，
画面上にこれらを表示することが望ましい。
そのような系列で，画面上の文書類は，例えば，次のいずれかによって，系列の始め及び終わりに達し
たときを利用者に明確に示すことが望ましい。
− “次へ”又は“前へ”のコントロールを強調しない。
− 薄暗くする。
− マーカを含む。
12.13.4
アクティブ領域のための体裁
利用者が，文字列を選択すると何が起こるかを理解するように，異なる種類の対話的な文字列は明確に
区別することが望ましい。次に示すことを区別する必要がある。
− 現在のトピック項に置き替える別のトピック項へのリンクを引き起こす文字列のアクティブ領域
− 現在のトピック項はそのままで（通常は別ウィンドウ又はポップアップウィンドウに）追加情報の表
示を引き起こす文字列のアクティブ領域
設計者は，次に示す中のいずれか一つのように，文章中のアクティブ領域をそれぞれの種類別に表すた
めに区別できる方法を選択することが望ましい。
− ポインタがアクティブ領域の上に移動したときその形を変更してもよい。
− アクティブ領域は，その領域を別の強調方法又は別の表示方法を使って示してもよい。
− 異なる動作に対して異なるアイコンを使ってもよい。
注記 実線の下線でマークした文字列は，アクティブなハイパーリンク（ジャンプ）を表すだけに
使うことが望ましい。画面上の文書類では，ハイパーリンクは，選択されたとき，また，色
を変更することが望ましい。
12.13.5
情報のリンク
リンクは，利用者が必要な情報に到達するために一つ以上の追加のリンクをたどることを要求するより
も，一つのジャンプで利用者が期待する情報を提供することが望ましい。
リンク先が文書類の外であるならば，利用者にはその文書類を離れることを知らせることが望ましい。
外部のリンクが壊れていた又はリンク先が取り除かれていたときのために，文書類は，情報の場所を見つ
78
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ける代わりの方法を利用者に提供することが望ましい。
関連したトピック項の間のリンクは，利用者がいずれのトピック項に最初にアクセスしても，もう一方
のトピック項の関連情報へジャンプできるように，双方向でなければならない。
リンクはリンクの目的地の明確な指示を提供しなければならない。例えば，ここをクリックよりトラブ
ルシューティングの追加ヒントを使う。
文字列のアクティブ領域を利用者が選択することでリンクするための機能を提供する場合，文書類は，
周囲の文章及び説明を入手するために使う文章のアクティブ領域から，この文字列を区別することが望ま
しい。説明を入手する要素は“関連トピック項”又は“関連項目”などの見出しの下でトピック項の始め
か終わりに集めることが望ましい。
12.14
情報を発見するための文書類の体裁
10.4で示したように，文書類は，目次，索引，検索機能などのような情報へのアクセスを提供する機構
を含まなければならない。
12.14.1
目次
目次は，それぞれのためのアクセスポイント（先頭ページ番号又は電子的なリンク）とともに，文書の
章又はトピック項の見出しを列挙しなければならない。識別データ以降が約8ページ未満の文書は，目次
を省略してもよい。印刷した文書では，目次は，識別データの直後に続かなければならない（11.3参照）。
目次は，総合的又は単純であってもよい。総合的な目次は，章又はトピック項の題名及び見出しを第3
水準まで列挙する。単純な目次は，第1水準の見出しだけを含む。文書集合の少なくとも1巻は，集合の
全ての巻の単純な目次を含まなければならない（10.4参照）。
分量が大部となる印刷文書では，必要な情報へのより便利なアクセスを利用者に提供するために，総合
的な目次及び単純な目次の両方の型の目次を使ってもよい。印刷した文書ではまた，ナビゲーションを支
援するため，それぞれの章又はトピック項の初めに，補助的な総合的目次を含んでもよい。
画面上の文書類は，過度のスクロールなしで見出しの最上位及び詳細へのアクセスを提供するために，
展開及び折りたたみ可能な体裁（木構造）で目次を表示してもよい。補助的な総合的目次は，メニュー，
展開可能なリスト，又は副ウィンドウを通してアクセスできてもよい。
目次は，目次に続く前付及び後付（例えば，付録，用語集，及び索引）を含む，文書類の全ての部分を
含まなければならない。目次の中の見出しは，章又はトピック項の番号を含めて，言葉遣いが文書中と同
じでなければならない。目次の体裁は，一貫した印刷デザイン又は字下げによって見出しの階層構造を区
別しなければならない。印刷した文書類では，目次は本文と同じ順序に見出しを列挙しなければならない。
画面上の文書類に対して，目次はブラウズの順番，作業，トピック項の種類，又はほかの論理的な評価基
準に従って見出しを並べることが望ましい。
画面上の文書類では，文書類ウィンドウのナビゲーションウィンドウの中，又は文書類ウィンドウ内の
別の枠として，内容リストを表示してもよい。内容リストは，利用者がトピック項ウィンドウ又は枠でト
ピック項を選択しそれを読んでいる間，利用者が，それを閉じるまで，表示したままにすることが望まし
い。内容リストの各項目は，それが説明する情報に直接リンクすることが望ましい。
文書類の異なる節に含まれる異なる情報の種類を示すため，又は異なる状態を示すために，アイコンを
内容リストで使ってもよい。アイコンだけではなく，アイコン及び関連する文字列の両方がアクティブな
リンクであることが望ましい。
図16に一部を広げた内容リストの例を示す。
79
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図16−内容リストの例
12.14.2
メニュー
メニューは，ソフトウェア及び画面上の文書類（図17）において補助的な目次である。メニューは，利
用者が階層レベル又はトピック項を選択できるようにし，かつ，利用者の選択肢へ直行するように自動的
に進むことが望ましい。メニューを情報ウィンドウ又は枠に表示してもよく，かつ，利用者が項目の一つ
を選択したとき，トピック項によって入れ替わってもよい。メニューは，通常，階層構造から一つ又は二
つの階層レベルだけを一度に表示する。
図17−文字列メニューの例
メニューがアイコン及び文字列を使うならば，アイコン及び対応する文字列の両方がアクティブなリン
クであることが望ましい。
メニューに使う名前は，各項目を使ってどんな情報が得られるのかを明確に示すことが望ましく，かつ，
クロスステッチのデザイン教科
ステッチについて，デザイン及びステッチの方法
布及び糸を選ぶ。
デザインを描く。
取り込んだ絵をデザインに使う。
デザインライブラリを使う。
図としてデザインを印刷する。
文字列の追加
ナビゲーション及び図形の選択
図形描画
部分の選択
輪郭及び充塡
移動及び複写
移動及び複写について
ドラッグによる移動
キーボードを使った移動
ドラッグによる複写
キーボードを使った複写
部分の回転
回転について
図形の回転
サイズ変更
80
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
トピック項の題名及び見出しと一致していることが望ましい。メニューの設計は，メニュー表示のそれぞ
れの項目の簡潔な（ポップアップ）記述を含んでもよい。メニューは，長たらしい説明を含まないほうが
よい。
メニューの階層構造において，望むトピック項へのナビゲーションを迅速にするために，設計者は，そ
れぞれのメニューの階層レベルに表示する項目の個数及びメニューの階層レベルの個数を慎重に割り当て
ることが望ましい。階層レベルの個数を減らすために，各階層レベルでの選択肢を増やすか又は各メニュ
ーで同時に多数の階層レベルを表示するかの設計が望ましい。
12.14.3
図表リスト
文書に5個以上の番号付きの図表があり，かつ，本文からその図表を参照するときに同時に図表が見え
ないとき，文書類には，表のリスト，図のリスト，又は（表及び図の両方を含む）図表のリストを入れる
ことが望ましい。図表のリストは，それぞれの（最初のページ番号又は電子的なリンクなどの）アクセス
ポイントとともに図表番号及び題名を列挙しなければならない。表，図，又は図表のリストの題名は，表，
図，又は図表の番号を含め言葉遣いが文書中のものと同じでなければならない。図表の体裁についての情
報は，12.18参照。
12.14.4
索引
索引は，それぞれのアクセスポイントを付けたキーワード，グラフィック，又は概念のアルファベット
順のリストである。索引は，重要な情報検索の手段であり，かつ，利用者が探している情報の場所が簡単
かつ一貫した方法で見つけることができるように構築することが望ましい。約40ページを超える印刷した
文書は，アクセスポイントがページ番号，トピック項番号，図表番号，又は別の索引項目への参照であっ
てもよい，索引を含むことが望ましい。約40を超えるトピック項の画面上の文書は，検索ツール（12.14.5
参照）又はアクセスポイントが電子的なリンクである索引のいずれかを含まなければならない。索引項目
は別の索引項目への相互参照であってもよいが，参照先の項目は，文書類へのアクセスポイントを与えな
ければならず，かつ，3番目の索引項目を指してはならない。
次に示すものは，文書類に索引を付けるための優れた実践の指針である。
− 索引は，文書類で使った用語の代替の専門用語を含むことが望ましい。利用者が選ぶかもしれない異
なる用語を決定するためには，利用者がなぜトピックを調べたいと思っているのかを考える。利用者
が調べそうな単語を使い，かつ，文書中のトピック項も列挙する。アクセスのための代替の用語を提
供する同義語を使う。十分に索引を付けた文書類には，普通1トピック項当たり2〜5個の項目がある。
− まえがき，付録，警告，注意，及び注を含むことが望ましい。グラフィック（及び画面上の文書類に
おけるマルチメディア）のような文章以外の項目にも索引を付けることが望ましい。
− 項目として，あまりにも一般的なキーワード及び利用者限定の用語を避けることが望ましく，かつ，
主な単語を最初に置くことが望ましい。例えば，本文の見出し“使い方，ファイルマネージャ”に対
して，索引の見出しには，“ファイルマネージャ，使い方”を使う。
− 項目は二重に掲示することが望ましい。例えば，“サイトライセンス”及び“ライセンス，サイト”の
両方の索引を付けたトピック項は，二重に掲示されている。
− 情報の重要性は，主要なキーワードの下に副次キーワードを置くことによって示すことが望ましい。
文書中に複数の参照がある項目は，トピック項のどの局面を扱っているのかを示す副項目に分割する
ことが望ましい。例えば，各項目は，その情報が単に定義，機能の記述，又は手順であるかどうかを
明確に示すことが望ましい。二次又は三次の項目より，詳細な一次の項目を使うことが望ましい。
− 任意に，主要なページの参照は，ページ番号を太字でマークして識別してもよい。
81
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 任意に，文書集合において，個々の巻の索引に加えて総合索引を含んでもよい。総合索引は，個々の
文書の索引で情報を調べる代わりに，一つの索引の中で情報を探す手段を利用者に提供する。それぞ
れの項目の位置の参照は，ページ番号に加えて簡約した文書題名を含むことが望ましい。
12.14.5
検索能力
画面上の文書類は，文章中の単語の場所を見つける方法を提供しなければならない。電子的な検索能力
は，文書又は文書集合の全文検索，要求したトピックとの近さを示す検索からの順位付けをした結果，図
表の中の単語の検索，キーワード探索，現在のトピック項での文字列の発見，ブール検索，及び特定の章，
トピック項，又はページへの検索の制限を含んでもよい。（英語の“the”などの）普通の，深い意味のな
い言葉の検索は行わないことが望ましい。
設計者は，情報を探すとき利用者が使いそうな用語を，できれば利用者から直接引き出して決定するこ
とが望ましい。これらは，メニューの見出し及び目次の項目とすることが望ましく，また，索引の項目に
もすることが望ましい。
利用者が，最初にカーソルを検索のテキストボックスに置かなくても，検索の基準を入力し始めること
ができるように，カーソルが検索のテキストボックスに入っていることを確実にするように，設計するこ
とが望ましい。
12.15
警告，注意，及び注のための体裁
警告（warning），注意（caution），及び注（note）は，普通の文章又は指示のステップから容易に区別で
きる一貫した体裁で表示しなければならない。見出し語（例えば，“警告”，“注意”，又は“注”）が，付随
の文章の前になければならない。“注”という用語は，危険を識別するために使ってはならない。警告及び
注意は，一貫し，かつ，他と異なり区別できる図記号，例えば，感嘆符又は三角形の中の稲妻，によって
識別しなければならない。
注記 文書類作成者は，注意，注，及び警告を文書類の中で正しく区別して使うためにスタイルガイ
ドを調べることが望ましい。
画面上の文書類では，警告，注意，及び注を印刷した文書類に使ったものと類似の体裁で表示してもよ
い。また，副ウィンドウに表示したメッセージは，コマンドの結果を利用者に通知するため，処理を進め
る前に意思決定を必要とする条件若しくは状態であることを利用者に警告するため，又は処理を継続する
前に介入が必要な深刻な条件を利用者に知らせるために使ってもよい。
12.16
指示のための体裁
指示のステップは，連続して付番しなければならない。主作業，サブステップ又は動作，代替のステッ
プ，及び手順の繰返しのために，一貫した付番又は文字での取決めを確立することが望ましい。必要なら
ば，指示に対するシステムのどんな応答も簡潔に説明することが望ましく，付番しない方が望ましく，か
つ，空白行によって前の指示と切り離すことが望ましい。
注記 アラビア数字を使うことが望ましい。漢数字は，上から下へ読む日本語で使ってもよい。
12.17
利用者が付けた注釈のための体裁
供給した情報に利用者が注釈を加えるのを許す機能が使えるならば，文書類は，利用者が注釈を加えた
場所に，注釈自体，アイコン，又は目印のうち少なくとも一つを表示することが望ましい。注釈を表示す
る場合，他の情報とそれとを区別することが望ましい。例えば，それが文章ならば，異なる方法で強調す
るか又は特別な記号で囲むことが望ましい。常に表示する又は利用者がそれを見るのを求めたときだけ表
示するかにかかわらず，異なる書体のように，異なる提示形式を使用することによって，供給された文章
から情報自体を区別することが望ましい。
82
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
12.18
図表のための体裁
12.18.1
図表を使うとき
図表は図及び表を含む。文書類は，次に示す幾つかの種類の図を使ってもよい。
− 対象物の実際の外観を表す画像。次に例を示す。
− 写真
− 線画
− 表示装置の画像
− 抽象概念の空間表現を与える線図。次に例を示す。
− 組織図又は木構造
− 折れ線グラフ
− 棒グラフ又は円グラフ
− 流れ図
図表は，次のために使うことが望ましい。
− 重要な情報に注意を引き付けるため（図表は，しばしば利用者がページ又は画面で見る最初の要素で
ある。）。
− プロセス，関係，階層構造，ネットワーク，構造，形，位置，統計，傾向，方向，割合，相関関係，
写像，及び他の概念を表すため。
− 利用者が物の部分又は物自体を識別するのを助ける対象物の外観を表示するため。
− 情報を覚えやすくするため。
設計者は，次のことを考慮することが望ましい。
− 考え又は関係は，言葉を使うよりも画像を使うことでよく説明されてもよいのかどうか。
− 何らかの詳細に注意を引き付ける必要があるのかどうか。
− 品目は，外観で識別する必要があるのかどうか。
言葉又は数よりも更に明確にかつ覚えやすく情報を伝えるならば，グラフ及びチャートを使うことが望
ましい。グラフ及びチャートは，通常，特定の数量を伝えるよりも大きな違い又は一般的な傾向を伝える
ときに効果的である。特定の数量を提示するためには，表がより適切である。
それぞれの種類の図表に対して，設計者は，全ての種類の利用者がそれを理解することを確実にするた
めに，利用対象者のプロファイルを調べることが望ましい。利用者が，同じ情報をリスト又は表の形で理
解するよりも，線図を解釈する方法を学ぶ方が難しいことが時々ある。例えば，流れ図が理解されるとい
うことが利用対象者のプロファイルから推論される場合にだけ，流れ図を使う。
注記 設計者は，全ての図表に対して，視覚障害のある利用者がそれらの内容にアクセスできるよう
にする同等物を提供することが望ましい。
12.18.2
図表における詳細さのレベル
図表に示す詳細さのレベルは，その目的を遂げるのに必要なものだけであることが望ましい。文章は，
図表に表した情報を参照することが望ましいが，同じ情報を繰り返さないほうがよい。文章は，図表を明
確にする又は説明するために使うことが望ましい。
注記1 参考情報の利用者は，しばしば関連する文章を読まずに，図表及び表を見る。
83
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図表は，必要な情報を含んでいることが望ましい。利用者は，それぞれの線図の全体をひと目で見るこ
とができることが望ましい。画面上の文書類では，図表は予期している表示装置で，スクロールせずに，
全体として読みやすく，かつ，見やすい大きさにすることが望ましい。設計者は，スクロールせずに一度
に見えるように，大きなグラフィックの顕著な特徴だけに簡素化するか又はそれだけを示すことを考える
ことが望ましい。
注記2 画面上では，図表全体が見えるときに十分な詳細を見ることができないならば，拡大の方法
又は図表の部分を拡大する能力を提供する。
12.18.3
図表の識別
5個以上の図表がある文書類では，各図表は一意の番号及び題名をもつことが望ましい（12.14.3図表の
リストを参照。）。これらの図表は，図表のリストに含まれていることが望ましい。本文中で一度しか参照
していない又は本文からの参照がない非公式な図表は，題名及び番号がなくてもよい。
12.18.4
図表の一貫した提示
文書類におけるGUI要素の表現は，文書化するソフトウェアの版と一致していることが望ましい。
文書類製品が国際的な読者層によって使われる場合，イメージは，様々な文化で一貫して理解でき，か
つ，受け入れられることが望ましい。
文書を翻訳する場合，図表は，翻訳で生じるかもしれない長くなった文字列を文字列領域が収容しても
よいように，整えることが望ましい。英文の2倍の長さの翻訳した文章を許容することが，様々な言語の
ために十分なものにするために望ましい。付随的な目的にだけ使われる非公式な図表は，製品が翻訳され
る場合，文字列を含まないほうがよい。
注記1 印刷した又は画面上の文書類の中の図表を発行するために文字列を画素データに変換するな
らば，図表の元のアプリケーションのファイルは，文字列を編集又は翻訳して新しく画素デ
ータに変換した図表を作れるように，もち続けることが望ましい。
注記2 幾つかの対象言語には，原言語の用語に対応する用語がないかもしれない。これらの場合，
翻訳した文章は元の文章より何倍も長くてもよい。
図表は，印刷したとき又は予想した種類の画面で見たときに読みやすいことが望ましい。画面上の線は，
紙に印刷した対応する線より太く見えてもよい。異なる太さであることを意図する線が画面上で異なって
見えることを確実にする。文書類作成者は，文字が明瞭に読めることを確実にすることが望ましい（12.9
参照）。図表は，予想した種類の全ての画面でテストすることが望ましい。
類似した内容の図表の体裁は，縮尺，画面サイズ，フォント，線幅，及び色使いについて，一貫してい
なければならない。線図（及び適切な場合，線画）に対して，設計者は，文書内の全ての図表が一貫して
いることを確実にするために，次に示す取決めを設定することが望ましい。
− 線幅：描いた線は，明確に見えるため及び意図した再現技術又は提示技術を使ってうまく再生するこ
とができるために，十分に太いことが望ましい。線図が文字列を含んでいる場合，主なメッセージを
損なうほど太い線を避けることが望ましい。
− 文字列の書体及び大きさ：全ての線図及び図表に同じ書体を使うことが望ましい。
− 矢頭及び他の接続記号の大きさ：大きさは線図中のそれらの重要性のために適切であることが望まし
い（一般に，一見して分かるけれども小さい。）。
注記3 ISO 4196は推奨の矢印の形及び使用方法を定義する。この国際規格は，2001年に取り下げ
られ，現在はJIS Z 8221-2:2006が対応する。
− 陰影：陰影は情報を伝達するためにだけ使うことが望ましい。灰色の広い領域などのような，装飾的
84
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
な陰影は避けることが望ましい。
注記4 陰影は，低解像度での再現及び提示技術で困難が生じる。
− 題名の提示：図表の題名は，図表の上又は下のいずれかに置くことが望ましく，かつ，太字又は標準
のいずれかの文字列を表及び図の両方の題名に一貫して使うことが望ましい。
12.18.5
図表の配置
文章に伴う図表は，文章中の最初の参照のすぐそばに現れることが望ましいので，関連する文章及び図
表は同時に見えてもよい。グリッド（12.8.1参照）は，図表を情報領域の中にどう置くのが望ましいかを
指定することが望ましい。同じ種類の利用者のニーズに役立つ，同じ種類の図表は，一貫して表示するこ
とが望ましい。
図表の幅がページの余白を超えている場合，別のページに置き，かつ，左に90度回転することが望まし
い。
12.18.6
画面表示の図表
画面又は他のソフトウェアの表示の図表は，次のために使ってもよい。
− ソフトウェア製品の画面表示の一般的又は特定の特徴を示す。
− 一連の指示の正しい段階に到達したことを，利用者が確認することを助ける。
文書類における画面表示の図表は，動作中のソフトウェア製品と容易に区別されることが望ましい。実
際のソフトウェアへのリンクを許す画面上の文書類には，ほんの少しの図表だけが必要であってもよい。
注記 文書類の設計者及び作成者は，あまりに多くの図表を使うことに用心深いことが望ましい。あ
まりに多くの図表を使うと，簡単な作業も長くかつ複雑に見えるかもしれない。利用者用文書
類を，各画面イメージのシステムリポジトリにすることを通常は意図しない。
画面の図表を使う場合，文章は，その図表が付随する本文中のアクティビティの前，間，又は後の表示
を示しているのかをはっきり示すことが望ましい。
全体の画面の表示又はメニュー若しくはダイアログボックスのような画面の表示の一部の図表は，一つ
の文書を通じて一貫して同じ縮尺にすることが望ましい。全体の画面表示のためのもの及び画面の一部の
ためのものの，最大でも二つまでの異なる縮尺を使うことが望ましい（図18）。
85
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図18−画面表示のための二つの縮尺の使用
12.18.7
印刷出力の図表
印刷出力の図表（例えば，プログラムの行）は，次のことに基づいて選択することが望ましい。
− その出力がなぜ利用者に示されているのか。
− 特に，利用者がその中の全ての文字列を読むことが必要なのか，又はそれがどういうデータを含むか
を単に見るだけなのか。
これらの考慮は，次の事項に反映することが望ましい。
− 図示する出力の量
− 示すデータの型
− 文字列の大きさ及びそれに従って図表の大きさ
注記 文書類作成者は，読者が資料を理解するのに必要なときだけに，印刷出力の例に日付を含め
ることが望ましい。特に本文中の例が文書類の幾つかのリリースを通して変わらないままで
残っている場合，日付は，年代及びそれに基づく資料の関連性又は正確性について間違った
印象を読者に与えるかもしれない。
12.18.8
表
表の設計は，利用者が正確なデータを簡単に利用できるようにすることが望ましい。表では，比較すべ
き項目は，隣接した列ではなく隣接した行で示すことが望ましい。さもなければ，行及び列の順序は，ア
全画面の例
このトピックは，画面全体の一般的な配置を縮小して示す。
ズーム
コントロール
グラフ領域
特性
注記
注記
特性
準備済み
画面の断片の例
このトピックは，アプリケーションの画面全体の
小さな部分を示す。
準備済み
86
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ルファベット，量，時間，使用頻度などの順のように，参照を簡略化することが望ましい。
行又は列の間の境界は，読者を重要なデータへ導くことができる。セルごとの境界が気を散らすかもし
れないが，組織独自のスタイルでその使用法を決めることが望ましい。
文章が翻訳される場合，表内の文章の長さが変更され，かつ，翻訳した見出し及び文章は，より多くの
場所を必要としてもよい。
1ページに入らない長い表は，それぞれのページに表の題名及び行又は列の見出しを繰り返すか，又は
見開き2ページを使わなければならない。複数のページにわたる長い表はまた，枚数番号，例えば，“表
15．メートル単位（4枚中の2枚目）”，で識別することが望ましい。
大きい表は，意味のある方法で表示するためには特別な注意を必要としてもよい。利用者が画面に表示
した表をスクロールしなければならない場合，又は印刷した表が1ページに収まらない場合，表の題名，
列見出し，及び行見出しを常に表示するように設計することが望ましい。設計者は，幾つかの文章が見え
なくなるかもしれないし，又は列内の文章の配置が変わるかもしれないので，ウィンドウのサイズを変更
したときの効果をテストすることが望ましい。
問題があれば，設計者は，次を考慮することが望ましい。
− 表を数個のより小さい表に分割する。
− 表を一連のリストとして表示する。
表の幅がページの余白を超えているならば，別のページに置き，かつ，左に90度回転することが望まし
い。
12.19
アイコン及び目印
12.19.1
アイコン及び目印を使うとき
アイコンは，同等な文字列の名札又は説明よりも小さい領域で，オブジェクト，動作，又は概念を表す。
詳しい情報を表示することができるので，アイコンはウィンドウの空間を節約する。また，適切な画像は，
しばしば多くの行の文章よりも早く意味を示し，かつ，翻訳を必要としない。
注記1 単語はすぐに理解されるのに対して，グラフィック及び記号が自明でないならば，利用者は，
アイコンの意味を解釈し，学ばなければならない。利用者は，ソフトウェア及び文書類に使
われているアイコンの全体の語彙を学ぶ必要がある。その結果，利用者は，アイコンが単語
と同じくらい使いやすいことが分からないかもしれない。
目印は，特定の場所を示す一片の文字列，記号，又は小さなグラフィックである。目印は，次のために
使うことが望ましい。
− ある情報の構造のどの部分にいるのかを，利用者が理解することを助ける。例えば，階層構造のどの
水準にいるかを示す。
− 情報の特定の種類を示す。例えば，ある指示，トピック，又は概念。
注記2 JIS X 9303シリーズが，ソフトウェアインタフェースのための一般的なアイコンの設計及
び表示を扱っている。
12.19.2
アイコン及び目印の設計
アイコンでの使用又は目印としての使用のための，グラフィックの設計者は，次の指針を考慮すること
が望ましい。
− アイコンは，利用者の注意をそらさないほうがよいが，必要以上に位置合わせを正確にしなくてもポ
インタで選択できるくらい大きいことが望ましい。
87
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 文書類をソフトウェアに関連付ける簡単で，かつ，一貫した方法を利用者が使えるように，文書類で
は，ソフトウェア製品と同じ記号又はアイコンを使うことが望ましい。単に文書化の目的のために，
代わりの記号又はアイコンを創作しないほうがよい。
− 可能ならば，アイコンは，現実世界のオブジェクト（プリンタ，ファイリングキャビネット，ファイ
ルフォルダ，紙）又は動作を表すことが望ましい。
− アイコンは，製品を使う全ての文化において認識できることが望ましい。国際的な読者層のために，
文化に依存するグラフィックの使用を避けることが望ましい。
注記 文化に依存するグラフィックが使われているならば，翻訳プロセス又は地域化プロセスの一
部としてそれらを取り替えることが望ましい。ソフトウェア製品及び文書類における一貫性
を保つのに，このやり方は追加の負担を課す。
− アイコンは，オブジェクト又は機能を一意に表すことが望ましい。異なる記号又はアイコンを，同じ
オブジェクト又は機能には決して使わないほうがよい。異なるオブジェクト又は機能を，同じ記号又
はアイコンによって表さないほうがよい。
− オブジェクトとその他のオブジェクトとを区別する図形要素を強調する設計が望ましい。
− オブジェクトの識別に寄与しない要素を排除する又は強調しないことによって，表現を簡素化する設
計が望ましい。できるだけ少数の図形構成要素を使うことが望ましい。余分な詳細は，認識及び理解
を妨げる。
− ソフトウェア製品又は組織に対して，図形構成要素の視覚的な比喩，縮尺，向き，色，及び位置の再
利用を通して，アイコン及び目印の設計及び構造は一貫していることが望ましい。アイコン及び目印
の標準を，ソフトウェア製品の文書類のために確立し，かつ，一貫して使うことが望ましい。
− 文書類を翻訳するとき，翻訳した版を代わりにしない限り，アイコン又は目印の中に文字列を使わな
いほうがよい。
− アイコンが，ある項目の状態の変更を表する場合，比喩は，一貫して使うことが望ましい。例えば，
本の画像がひとかたまりの情報を表す場合，閉じた本の画像及び開いた本の画像は，二つの異なる状
態を表すために使うことができる。同様に，異なるレベルについて比喩を続けるためにページの画像
を使うことができる。
− 利用者がグラフィックスを意図したように解釈するのを確実にするための利用者テストの間に，グラ
フィックスの適切性を総合評価することが望ましい（8.3参照）。例えば，受話器の画像を使っている
ならば，利用者にとっては，それがダイアルアップ接続のための画面上の情報を表すか，又は顧客支
援に電話をかける番号を表すかどうか不確かであるかもしれない。
12.19.3
アイコンの名前の表示
アイコン又はコードの意味は，“ツールチップ”などのそれらの名前を表示するための方法を提供するこ
とによって強化することが望ましい。“注文を確約”又は“空の用紙を表示”のように，メニューに使うの
と同じ型種類の名前を使って，名前だけを提供することが望ましい。
アイコンによって表されたオブジェクト又は機能の名前を表示する場合，設計者は次の質問を考慮する
ことが望ましい。
− 空間を節約するため，及びインタフェースの他の要素を隠すことを避けるために，単語は十分に簡潔
か。
− 利用者がアイコンに慣れたとき，アイコンが覚えやすく，かつ，使いやすいことを利用者が分かるか。
− グラフィックに加えて言葉を表示したままにするかどうかの選択を，利用者に許すことが望ましいか。
88
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− アイコンの名前は，翻訳されるか。
アイコンに対して，次のように名前を表示することが望ましい。
− アイコンのすぐそば（上，下又は隣）に常時表示し，名前及びアイコンの両方をアクティブにする。
− 利用者が必要とするときに一時的に表示する。例えば，ヘルプの状態表示の行，吹出し，又はツール
チップの中に表示する。
利用者が画面上のユーザインタフェース要素の名前を見ることができるならば，それらの幾つかだけで
はなく，そのような全ての要素の名前を提供することが望ましい。
12.20
文書類の包装
製品全体のための包装の要求事項は，文書類設計に影響する。設計者は，少なくとも次を考えることが
望ましい。
− ソフトウェア製品及び文書類は，一緒に包装すべきかどうか。
− 包装のための組織独自のスタイルがあるかどうか。
− 製品を配布するのにどんな媒体を使うか。
− 製品を物理的に輸送するため，又は電子的に納入するためにどんな方法を使うか。
− 包装は，前の版又は類似した製品に使ったものと同じであることが望ましいかどうか。
89
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書A
（参考）
利用者用文書類のスタイルガイドの内容
スタイルガイドは，特定の文書に使うべき文体，図表，及びレイアウトの具体的な形式について，文書
類作成者のための標準及び指針を提供する。この箇条は，スタイルの仕様の内容を詳しく示す。スタイル
ガイドの情報の多くが言語に特有である。
文書類作成者はまた，読者，作業，他の分析及び設計文書類へのアクセスを与えられることが望ましい。
A.1 文体
附属書Bは，文体の指針の中で取り組むべきトピック項に関する推奨事項を含む。専門化した標準及び
スタイルの指針は，スタイルの仕様に追加してもよいし，又は文書化計画から参照してもよい。
A.2 言語
適切ならば，国特有の変形とともに，言語を指定することが望ましい。例えば，（カナダの）フランス語。
A.3 つづり
必要な場合，言語に対して，任意の例外のリストとともに，つづり辞書を指定することが望ましい。
注記 大部分の読者の国籍にとって適切なその国の標準的な辞書を指定することが望ましい。できれ
ば，辞書がスペリングチェッカのファイルとして利用可能であることが望ましい。
A.4 文法及び用法
文法及び用法のスタイルマニュアルを指定することが望ましい。
注記 大部分の読者の国籍にとって適切な文法及び用法の標準を指定することが望ましい。
90
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書B
（参考）
利用者用文書類のための文体及び手法
この附属書は，英文法及び用法を記述する。国家機関は自国の言語の規則及び取決めに合わせてこの附
属書の自国版を準備してもよい。
B.1
一般
この附属書は，利用者用文書類のために適切な文体及び図表のスタイル及び手法を扱う。
利用者用文書類は，次とともに，利用者が理解するために，明確で，曖昧でなく，かつ，簡単であるこ
とが望ましい。
− 語彙は直接的であることが望ましい。
− 全ての専門用語を簡単に説明することが望ましい。
例えば，コマンドの仕様など，印刷した用紙での特定の種類の情報に対して，利用者が特定のスタイル
に慣れているならば，画面上の文書類のために同じスタイルを考えることが望ましい。逆に，画面上で特
定の種類の情報に対して，利用者が特定のスタイルに慣れているならば，異なるスタイルに対する非常に
強い利用者の事例がない限り，印刷した文書類に同じスタイルを使うことが望ましい。
文体は，利用者の理解の水準及び現在の状況にできるだけ限定していることが望ましい。
利用者が複雑な構文又は複雑な語彙によって気が散らないように，文体は，簡単かつ直接的であること
が望ましい。意味は，明確であり及び理解が簡単であることが望ましいが，文書類は単純な考えを説明し
過ぎることで利用者を見下さないほうがよい。
ユーモアは慎重に使うことが望ましい。一度読んだときに面白くても，頻繁に参照する文書類では煩わ
しくなる。要点を説明するための漫画の使用は，幾つかの入門の文書に役立ってもよいが，利用者がそれ
らを飛ばせることが望ましい。ユーモアは，異文化に必ずしも翻訳する必要がないので，文書類を他の文
化で使うのであれば，全ての対象の文化でその適切性を確認する。
段落は，短いことが望ましい。
節見出しは，本文を読む利用者を動機付けるために短くかつ明確であることが望ましい。表形式のデー
タは，できるだけ簡易化した形で提示することが望ましい。
B.2
文のためのスタイル
構文は，簡単なことが望ましい。利用者は，それらを理解するのが難しいことを分かってもよいので，
文書類作成者は，複雑な文法構造を避けることが望ましい。翻訳がより難しくなり，したがって，より高
価になるので，長い文を避けることが望ましい。
文中の強調は，重要な点にあることが望ましい。一般に，文は，利用者が既にもっている情報から始ま
ることが望ましく，かつ，利用者を新しい情報に導くことが望ましい。
B.2.1 懸垂分詞
英文法及び英文による記述に特有な部分のため，JISには必要のない記述であるので不採用とした。
91
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
B.2.2 類語反復及び冗長句
英文法及び英文による記述に特有な部分のため，JISには必要のない記述であるので不採用とした。
B.2.3 冠詞及び代名詞
英文法及び英文による記述に特有な部分のため，JISには必要のない記述であるので不採用とした。
B.2.4 肯定構文及び否定構文
英文法及び英文による記述に特有な部分のため，JISには必要のない記述であるので不採用とした。
B.2.5 条件のためのスタイル
文書類作成者は，コンマによって文の残りと分けて，文の最初に条件部を置いて条件を明確に説明する
ことが望ましい。コンマがないと，文の意味が不明瞭であったり，又は最悪の場合は間違ってしまったり
するかもしれない。例えば，次に示す簡単な条件文は，条件がはじめにあり，かつ，条件と文の残りとを
切り離すコンマがある，そして，いずれの文も明確である。
もしリターンキーを押したとき画面が空白になれば，システムがデータを保存します。
もし画面が空白になれば，リターンキーを押したときにシステムがデータを保存します。
コンマがないと，意味が不明瞭になってしまう。
二つの条件が必要な場合，それぞれの条件が明確に述べられていることが望ましく，かつ，“及び”又は
“又は”を使って正しく結び付けることが望ましい。文章は，“両方”，“少なくとも一つ”，“いずれか一つ”
及び“一つだけの”などの用語を使うことによって複数の条件を強調することが望ましい。
複雑な条件に対しては，文書類作成者は，言葉で条件を与えるよりむしろ，リスト又は表（12.18.8参照）
を使うことが望ましい。例えば，表B.1の情報は，連続した文章としてよりも表として提示されたほうが，
利用者が理解するためには，はるかに簡単である。
表B.1−表として提示した条件の例
X
Y
結果の角度A
正
正
0≦A＜π/2
負
正
π/2≦A＜π
負
負
−π≦A＜−π/2
正
負
−π/2≦A＜0
流れ図などの線画は，複雑な条件を図示するのに使ってもよいが，対象の利用者がそれを理解できるか
どうかを，文書類作成者は総合評価することが望ましい。
B.2.6 能動態及び受動態
英文法及び英文による記述に特有な部分のため，JISには必要のない記述であるので不採用とした。
B.2.7 時勢
英文法及び英文による記述に特有な部分のため，JISには必要のない記述であるので不採用とした。
B.2.8 単数形及び複数形の動詞
英文法及び英文による記述に特有な部分のため，JISには必要のない記述であるので不採用とした。
B.2.9 句読点
英文法及び英文による記述に特有な部分のため，JISには必要のない記述であるので不採用とした。
B.3
段落のためのスタイル
各段落は，一つの考えだけを扱うことが望ましい。可能なところならどこでも，段落は短く保つことが
92
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
望ましい。考えが複雑なので長い段落が必要ならば，リスト又は表を使ってそれらを分解することを考慮
する（12.10及び12.18.8参照）。
同じトピック項の他の部分の参照は，最小限に保つことが望ましい。
各段落の中では，利用者が説明に従ってもよいように，各文が前の文とどう関連するかを示して，一つ
の文から別の文までの流れが明確なことが望ましい。
例 作業を保存したいならば，コンピュータのドライブのUSBメモリを使う。この予防策は，もう一
つの場所に格納すべきバックアップ用の複製の入手を確実にする。
同様の手法の使用はまた，関連する段落をリンクするために役立っている。
B.3.1 ハイフン
英文法及び英文による記述に特有な部分のため，JISには必要のない記述であるので不採用とした。
B.3.2 不定詞
英文法及び英文による記述に特有な部分のため，JISには必要のない記述であるので不採用とした。
B.3.3 大文字及び小文字
英文法及び英文による記述に特有な部分のため，JISには必要のない記述であるので不採用とした。
B.3.4 擬人化
特に画面上の文書類で，システムが制御し，かつ，利用者が制御していないという感じを導入するかも
しれないので，コンピュータ又はアプリケーションに人間の特性を与えないほうがよい。また，アプリケ
ーションの能力への誤った期待を利用者に与えるかもしれない。動作を実行するかどうか又は実行する方
法について利用者が決定権をもつところでは，文は，システムではなく利用者が制御されているという知
覚を強化することが望ましい。前もって決定したステップの系列を通じて，システムが利用者との相互作
用を開始し及び制御するところでは，文がこれを明らかにすることが望ましい。
例えば，次では，利用者は，どんな動作を取ったらよいかを決めてもよい。
レポートの印刷した複製が欲しいならば，報告書印刷コマンドを使う。
次では，システムは，利用者が何らかの動作を行うことを要求する。
別の注文を開く前に，注文確認コマンドを使って注文を確認しなければならない。
B.3.5 比喩及び隠喩
比喩又は隠喩を使うことで，利用者が複雑な考えを理解するのをときには助けてもよい。しかし，比喩
又は隠喩を文章中で使うならば，利用者を誤った推測に導かないことを確実にするために細心の注意を払
う。
文章は，情報を説明する代わりに比喩又は隠喩を説明しないほうがよい。比喩又は隠喩，及び情報の両
方を説明するか，情報だけを説明するかのいずれかが望ましい。
隠喩を使うならば，それらは一貫して使うことが望ましい。ユーザインタフェースが隠喩を使っていれ
ば，文書類は同じ概念に対して異なる隠喩を使わないほうがよい。同じ隠喩を使うか，又は隠喩を全く使
わないことが望ましい。
隠喩は，正しく翻訳又は地域化できないかもしれないので，製品を翻訳又は地域化するならば，隠喩が
適切であることを確実にするために確認するか，又はそれらを避けることが望ましい。
B.4
早引き情報のためのスタイル
早引き情報は，意味が明確なままで残っている限り，完全な文よりもむしろ単語及び短い句を使っても
よい。
93
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
早引き情報のそれぞれの集合は，関連しているが短い見出しで明確に名付けることが望ましい。
利用者は必要な情報を見つけるためにしばしば文書を一目見るだけなので，有効で，テストした例だけ
を使うことが望ましい。間違った例又は悪い例を使うと，避けるべきことの単なる図表であっても，利用
者がそれらを複写するかもしれない危険がある。したがって，これらを使うならば注意が必要である。文
書類作成者は，それらが間違っている又は無効であることを明確に名付けることを確実にすることが望ま
しい。
B.5
導入指示のためのスタイル
ソフトウェアを導入する作業は，通常，一度だけ行うので，利用者は，普通は初めてソフトウェアを導
入している。指示は，簡単で，明確で，かつ，完全にする。
利用者が慣れないかもしれない用語は避けることが望ましい。用語は他の利用者用文書で説明されてい
るかもしれないが，特に，文書類作成者は，ソフトウェアを導入する利用者が，それらの他の文書を読ん
だと仮定しないほうがよい。
B.6
学習書及び作業指示のためのスタイル
注意及び警告は，必要ならば，危険の簡単な記述とともに必要な処置を明確に示す，命令形で示すこと
が望ましい。11.11及び12.15を参照。
可能ならば，項目は，利用者に“押す”，“タイプする”，又は“選択する”を指示する動詞から始まるこ
とが望ましい。条件が動作に関連しているならば，それらは，コンマによって文の残りと切り離して，文
の始めに示すことが望ましい。
例 緑のインディケータが点灯したら，ディスケットを取り除きなさい。
文は，それらを行うことが望ましい順序で動作及び効果を示すことが望ましい。幾つかの場合，情報を
正しい順序で提示しないと，指示に従うことで深刻な問題を引き起こすかもしれない。例えば，次の文，
すなわち，“プログラムを終了するためにʻ終了ʼを選択する，最初にファイルの保存を忘れずに”では，
利用者が文の残りを読む前に“終了”を選択するかもしれず，したがって，重要なデータを失うリスクが
ある。同じ情報は，次のとおりに表現するほうがよい。
1) ファイルを保存しなさい。
2) プログラムを終了するには“終了”を選択しなさい。
B.7
ユーザインタフェース要素の記述のためのスタイル
利用者は，ユーザインタフェースの要素が何をするかを知る必要があるかもしれない。文書類は，能動
態の構文を使い，かつ，動詞から始まる一つの条項として情報を提供することが望ましい。例えば，“選択
の準備ができている注文マスターファイルに注文を送る”又は“新しい空の預金書式を表示する”。
B.8
記述及び説明のためのスタイル
文書類作成者は，ある主題に関して利用できる情報よりむしろ，利用者が必要とする情報に集中するこ
とが望ましい。
文書類作成者は，利用者が知っていることから利用者が見つけたいことまで，利用者を連れて行くこと
が望ましい。この原則は，トピック項の水準と同様に文に適用される。これを理解するには，情報のため
に利用者が検索を行ってしまう質問の種類を想像する。例えば，次のとおり。
94
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 利用者が“これは何を意味するか。”又は“これは何だ。”と尋ねるかもしれないならば，記述が必要
であって，その順序は，“xの意味はy。”（“yは，xが意味することである。”ではない。）が望ましい。
− 利用者が，“特定の効果を得るために私は何をするか。”又は“私はどのようにこれをするか。”を尋ね
るかもしれないならば，“yを達成するために，xを使う。”（“xはyを達成する手段である。”ではな
く）のように，事実を指示として書くことが望ましい。
最近取り入れた情報に言及する文より，以前に幾つかの文を取り入れた情報に言及する文を読むために，
利用者が長くかかる，したがって，関連する考えは一緒にしておくことが望ましい。
記述又は説明が，異なる利用者又はシステムが行った動作についての情報を含んでいるならば，各動作
を誰が又は何が実行するか，特に，利用者がどの動作を実行しなければならないか及びシステムがどれを
実行するか，が明確であることが望ましい。
B.9
画面上の情報のためのスタイル
画面上の情報を書くとき，文書類作成者は，ウィンドウの情報領域の大きさを考慮することが望ましい。
空間が制約されているので，文書が簡潔なことが重要である。文書類作成者は，次を行うことが望ましい。
− 用語の定義を毎回含めるよりもむしろ，見るかどうかを利用者が選べるようにする。
− 利用者に概要を示し，そして，概要から利用者が見たい節を選択できるようにする。
B.10 リストのためのスタイル
リストの全ての項目は，同じ構造であることが望ましい。例えば，リストの中の指示は命令形を使うこ
とが望ましい。
前置きの文でリストを紹介してもよい。リストの各項目が同じ単語から始まるならば，その単語は前置
きの文の一部であることが望ましい。
リストの提示の指針に関しては，12.10を参照。
95
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書C
（参考）
翻訳及び地域化のための利用者用文書類のスタイル
注記 附属書Cは，英文による記述スタイルを述べているもので，JISとして必要ない記述であるの
で不採用とした。
96
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書D
（参考）
印刷した情報の設計，作成，及び制作
D.1 序文
この附属書は文書類の版を印刷した形で提供するときに含まれる追加の活動及び意思決定のための指針
を与える。
D.2 設計
D.2.1 印刷した文書類の制作方法の決定
文書類設計者は，異なる制作方法に対する助言，価格，及びタイムスケールについて，幾つかの印刷組
織に相談することが望ましい。考えているあらゆる解決策のための見本を手に入れる。
注記 再現の品質は，プリンタの解像度に依存する。例えば，300 dpiは文字列及び線画に対して読み
やすい複製を制作するが，写真及び陰影の再現には，少なくとも600 dpiの方がよい。
第三者が文書を制作するのであれば，文書類設計者は，文書を移すための余裕時間をもつことが望まし
い。
表D.1は，それぞれの主な特徴に関して，複数の複製を制作する幾つかの方法を示している。
表D.1−複数の複製を制作する方法
方法
品質
速度及び利便性
費用
ローカルプリンタでの
印刷
使用する印刷装置の品質に依
存する。
しばしば結果がとじておらず，
片面印刷で，使いにくい。
非常に便利。
2，3ページだけの複製が必要な
ところで役立つ。
いつも速くはない。
単にページを入れ換えること
で，土壇場での変更が非常に簡
単。
印刷装置の種類及び労
働コストに依存。
高速レーザプリンタで
のPDFファイルから
の大量の印刷
素晴らしい。
非常に速い。
安い。
写真複写
素晴らしい結果を与えること
ができる。
様々な種類の紙を扱うことが
できる。
非常に速くできる。
ページを入れ換えることで間
際での変更が非常に簡単であ
る。
特に，白黒だけのとき，
及び少量のときは，安
くすることができる。
オフセットリソグラフ
ィ
結果は素晴らしい。
広範囲の効果を達成できる。
カラー印刷のためにしばしば
好まれる。
専門家の印刷組織が必要。
時間がかかることがある。
少量のとき高価になる
ことがある。
D.2.2 ページ，節，図表，及び表のための付番体系
D.2.2.1 ページ番号
各文書に対して文書類設計者は，ページへの付番の適切な方法を選択することが望ましい。例えば，次
に示すとおりである。
− 文書の全てのページを，1から始まるアラビア数字のページ番号で順番に付番してもよい。索引又は
97
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
目次のページでのページ番号の参照に対して，その本の中でそのページがおよそどの程度のところに
あるのかを示す。この体系は，使えるところならばどこでも推奨される。
− ページは，ページ番号を含めて節を識別する番号，文字又は名前を，それぞれの主要な節の中で付番
してもよい。このスタイルは，“章ごとのページ番号”として知られていて，読者がどの章にいるかを
明確に示す利点がある。ページ付番のこのスタイルのもう一つの利点は，ページ付番への重要な本文
編集の影響の減少である。この二つの要素を含んだ付番は，ルーズリーフ式の刊行物のために推奨さ
れる。ページ番号の二つの部分は，ハイフン又はダッシュで切り離されることが望ましい。例えば，
次に示すとおりである。
1-1，1-2，1-3，…2-1，2-2，2-3
序文-1，序文-2，学習書-1，参照-1，参照-2
番号付きの付録又は附属書は，次の体裁をとる。
A-1，A-2，…B-1
− 文書を物理的に別々の巻に分割する場合，巻数は，ページ番号に含めることが望ましい，例えば，次
に示すとおりである。
第1巻，1-1，第1巻，1-2
− 文書の導入部のページ（前付），すなわち，序文及び内容リストを含むページに，（組織独自のスタイ
ルでそれ以外の指示がない場合を除き）文書の残りの部分とは別の順番に付番することが望ましい。
例えば，次のとおりローマ数字を使う。
i，ii，iii，iv
− 数字がページに印刷されていなくても，全てのページが付番した順番に数えられることが望ましい。
例えば，文書の先頭に（表紙とは別に）表題ページがある場合，その表題ページのいずれの面にもペ
ージ番号を印刷していないかもしれないが，それでもページi及びページiiと数える。
− ページは“yのx”形式で付番してもよい。ここで，“x”は現在のページ番号及び“y”が文書の総ペ
ージ数である。これは“最大ページ”ページ付番として知られている。この方法を使う利点は，次の
とおりである。
− 読者は，最後のページがなくなっているかどうかがすぐ分かる。
− 導入部のページ及び本体の両方に同じページ付番方法を使うので，文書テンプレート設計がより簡
単になるかもしれない。
D.2.2.2 節番号
文書類設計者は，使用するページ番号と節番号との間には，明らかな区別があることを確実にすること
が望ましい。
文書類設計者は，節番号の厳密な階層構造を作ることが望ましい。ここで，節番号を引用するときは常
に，階層構造の全ての水準を識別している文字又は番号を全て使う。
節番号のための推奨する体系は，次のとおりである。
− アラビア数字
− 主節は，1から始まる連続番号を付番する。
− 各主節は，適切な小節（第2水準）に分割し，かつ，最高水準の中で連続して，例えば，1.1，1.2と，
付番する。この細分方法は，例えば，水準1.1.1，1.1.2のように，次の水準へ続ける。可能ならば，階
層構造を三つの水準の細分までに制限する。
− 異なる水準の細分を指定する数字は，終止符（ピリオド）で切り離し，最後の数字の後の終止符（ピ
98
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
リオド）は付けない。
D.2.2.3 図番号及び表番号
図及び表が本文に全て埋め込まれ，かつ，ほかの場所から参照していない場合を除き，文書類設計者は，
図及び表に付番することが望ましい。
付番するとき，次が望ましい。
− 図及び表に別々の付番系列を使うことが望ましい。
− 文書のページを節ごとに付番する場合，同じ水準の節の中の図及び表は，別々に付番することが望ま
しい。文書のページを通しで付番するならば，図及び表も文書を通して付番することが望ましい。
− 例えば，図6，表10などのように，項目の種類を図表及び表の題名に含めることが望ましい。題名は
文書中で一貫して使うことが望ましい。
次は，図及び表の付番体系の例である。
表1，表2…
図1，図2…
図表1-1，図表1-2…
表1.1，表1.2…
D.2.3 ページレイアウト
D.2.3.1 用紙サイズ及び方向
利用者が後で印刷すると決めてもよい画面上の文書について，文書類設計者は，ソフトウェア製品を使
う異なる国の利用者が利用可能な用紙サイズを考えに入れておくことが望ましい。
前もって印刷する文書について，文書類設計者は，利用者の環境で便利な用紙サイズ及び方向を選ぶた
めに印刷組織と連携することが望ましい。文書類設計者は，文書を広げるのに使える可能性がある平らな
面の大きさを考えに入れておくことが望ましい。最初に，利用者のニーズに基づいて用紙サイズを見積も
る。それから，次に示すステップに従って実際の用紙サイズを決める。
− 最初の見積りと大きさが同じような適切なA版を選択することが望ましい。ISO 216:2007は，国際的
なAサイズの用紙の詳細を規定している。例えば，A4，A5，又はA6が異なる種類の利用者マニュア
ル又は小冊子に適しているかもしれない。より大きいAサイズは掛図に適切かもしれない。
− どんなA版も適切ではないが，適切なサイズをA版の簡単な比率を使って作ってもよいとき，文書類
設計者は，そのサイズを使うことが望ましい。例えば，A4の1/3は参照カードに適切かもしれない，
いずれかの向きでもA4の2/3は，利用者マニュアルに適切かもしれない，A4の4/3は折り畳みの参
照カードに適切かもしれない。
− 完全に異なるサイズが必要な場合，文書類設計者は，それを定義することが望ましいが，文書を制作
する印刷組織とともに，制作方法及び費用の詳細を確認することが望ましい。
注記 文書類設計者はメートル法ではない市場での紙のサイズに注意することが望ましい。例えば，
メキシコではレターサイズ（215.9 mm×279.4 mm）及びリーガルサイズ（215.9 mm×355.6
mm）を使う。A4のためにイギリスで書いた文書は，それらを納入する前のある時期に米国
のレターサイズに再構成してもよい。顧客がソフトコピー版を印刷する責任をもつという意
図でソフトコピー版を送る場合，これも考える。
− 利用者ニーズの分析が，何人かの利用者が，一つ以上のサイズのある文書類を，例えば，一つは事務
所で使うために及び一つは旅行のとき使うために，必要としてもよいことを決定する場合，文書類設
99
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
計者は，同じ文書を異なるニーズを満たすために使ってもよいかどうかを決めることが望ましい。も
しそうならば，本文が異なるサイズで読みやすくなるように，文書を設計することが望ましい。もし
そうでなければ，文書類の異なる版を，異なるニーズを満たすために設計することが望ましい。
文書類設計者は，長辺が左及び右（縦方向）又は上及び下（横方向）のいずれかにページを方向付ける
ことが望ましい。
長辺をとじた縦長書式の文書は，最も普通であり，利用者文書の大部分に使うことが望ましい。長辺を
とじた横長書式の文書は，開くと同じ形及びサイズになるが，ページめくりの方法は一般的ではないので，
より広いページに対する特別な利用者のニーズがある場合にだけ使うことが望ましい。短辺をとじた文書
は，それほど一般的ではない。短辺をとじた横長書式の文書は，多量の資料を一度に見なければならず，
かつ，利用者の予想した作業環境に空間があるときに使える。上部をとじた縦長書式の文書は，仕事のた
めに使う補助文書として時々使われる。
D.2.3.2 基本的な印刷用ページレイアウト
設計者は，原本となるページを準備するのに選ばれた方法を使うことで，すぐに達成できる単純なペー
ジレイアウトを採用することが望ましい。
設計者は，それぞれの種類のページ（図D.1及び図D.2）のためにページグリッドを準備することが望
ましい。典型的な異なる種類のページは，次のとおりである。
− 通常の文章ページ
− 出版事項のページ
− 題名ページ
− 内容リスト
− 節の開始ページ
− 索引
100
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図D.1−A5ページグリッドの例
25 mm
10 mm
25 mm
210 mm
148 mm
20 mm
13 mm
10 mm
フッタはこの線の上に置く。
行，図表は左側の余白まで。
右側のページ
テキスト及び図表は，この領域に入れる。
この線の下からヘッダを置く
（章の最初のページを除く。）。
101
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
EASとは何か 第1章
この章は，例題アプリケーションシステム（Example Application System）を
紹介します。ここでは，読者がEASを使って実行できるタスクの概要を述べ，
メニューシステムがどんなものか及びどう働くのかを説明し，かつ，EASを
使って仕事をするときの道具を記述しています。
EASでできること
EASは，記録管理及び報告書作成を含む仕事の一部を実行するときの時間
及び労力を節約します。EASは計算を行い，かつ，情報を記録するときに間
違いを犯す危険を減らします。読者がEASとともに通信回線を使うと，電話
回線を使って本社に報告書を電子的に送ることができるので，郵便に頼る必
要がなくなります。
EASは，次の二つの主要部分に分かれています。
− 事業週報
− 出欠及び就業時間
読者のEASシステムは，これらのうちの一つの部分だけでも構いません。
読者は，必要に応じて毎日又は毎週を単位として，情報を記録するために
EASを使えます。読者が記録する必要があるかもしれない情報の種類の例を
次に示します。
− 会議のための飲料の収入
− 会議のための食物の収入
− 少額の現金支払い
− 窓掃除又はクリーニングなどの支出に対する領収書
− 会議での要員の各メンバの作業時間
− 要員の休暇時間
− 合計預金額
eas 1/001 ページ 1
図D.2−A5ページの例
ページグリッドを準備するとき，文書類設計者は，2ページが視野に入る状態で文書が開いているとき，
文書がどのように見えるかを示すために，左手側及び右手側の両方のページを並べて考えることが望まし
い。
− グリッドは，ページの余白がどこになるかを示すことが望ましい。
注記 文書類設計者は，孔をあけるための空間が英国と米国とで異なることを知っていることが望
ましい。
− ページの内側の余白は，製本の方法で使うために十分広いことが望ましい。最も簡単な場合は，ペー
ジの左右の余白は同じであってもよい。しかし，文書類設計者は，ページの内側の端（すなわち，右
側のページの左の余白及び左側のページの右の余白）に，より広い余白をとることを考えていること
が望ましい。図D.1は，ステープルでとじた（中とじした）小冊子のA5のページのためのページグ
102
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
リッドを示す。繰返しではあるが，内側の余白は外側の余白より広い。図D.2は，図D.1のページグ
リッドを使って設定したA5のページの例を示す。
− グリッドは本文に使うべき段数を示すことが望ましい。普通の本文ページには，通常は1段組の本文
が適切である，しかし，リーフレット，パンフレットなどのある文書には，2段組又は3段組が合う
かもしれない。文書類設計者は，本文の印刷デザインに関連して本文の段幅を決めることが望ましい。
− 文書類設計者は，ページの余白の量の割合としての本文の量，及び必要なページ数の推測を考慮する
ことが望ましい。本文の行が長過ぎるようならば，文書類設計者は，本文の本体を余白から字下げす
ることが望ましい。
− 索引に対して，グリッドは，使うページ数を減らすために2段組又は3段組の本文を使うことが望ま
しい。
− グリッドは，図及び表の配置を示すことが望ましい。文書類設計者は，図表及び表が幾つ使われてい
ても，ページがいつもきちんとし，一貫して見えるように，できるだけ単純な配置戦略を作ることが
望ましい。幾つかの文書に対しては，おそらく画面表示の図表又は報告書が一方のページにあり，対
応する文章が対面のページにある状態で，見開きの2ページが一緒に見えるならば，利用者に役立つ
かもしれない。
− 文書類設計者は，次を考慮に入れて，カード及びチャートをどう折り畳むかを決めることが望ましい。
− 利用者は，文書そのものをどう取り扱いたいのか，かつ，文書が含む情報をどのように利用したい
のか。
− 文書にとじ孔をあけるかどうか，もしあけるならどこに。
− 一緒にこん（梱）包する他の文書の大きさはどのくらいか。
D.2.3.3 基本的なページ要素
ページグリッドの上では，文書類設計者は，ページに現れる次の基本要素の正確な位置を定義すること
が望ましい。
− ページ番号
− 文書参照番号
− 利用者を助けるためにあらゆるページの天及び地に必要な情報（それぞれ，ヘッダ及びフッタ）
ページの本体とヘッダ及びフッタの文字列とを分離するために，水平線を使ってもよい。
注記 文書類設計者は，特別な必要がない限り，縦線の使用を避けることが望ましい。
文書類設計者は，読者が読んでいる場所が分からなくなる傾向があるので，できれば脚注を避けること
が望ましい。情報は，アクセスしやすい文章中に配置することが望ましい。より小さい活字サイズ又は異
なるフォントを，文章中の注を示すために使ってもよい。
D.2.4 図表の提示
図表が（縮小した後でも）1ページに入らないくらい広いならば，次を行う。
− 文書類設計者は，利用者が本文の異なる部分から図表（例えば，鍵盤配列図）を参照する必要がある
場合，折り畳み式のページを使ってもよい。
− 文書類設計者は，図表を左に90度回転してもよい。
文書類設計者は，できれば同時に見えるように，図表を参照する文章の後に，各図表を配置することが
望ましい。文書類設計者は，見開きのページを計画することが望ましい。
103
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
利用者が関連する文章と同時に図表を見る必要があり，かつ，同じページに余地がないならば，文書類
設計者は，余白を残して，図表及び文章を新しい見開きページヘ移動することが望ましい。
D.2.4.1 印刷出力の図表
印刷出力の図表が含まれるならば，文書類設計者は，出力を含む理由を考慮に入れることが望ましい。
利用者用文書類の図表に，結果として印刷出力となる電子的なテキストファイルを取り込むことは望まし
い。しかしながら，出力は，印刷した形式又は体裁を整えていない文字列の形式だけで利用可能であって
もよい。文書類設計者は，印刷出力の図表を準備するための次の二つの一般に使われる方法を考えること
が望ましい。
− 文書類設計者は，イラストの原版として実際の出力を使うことが望ましい。それは，電子的なシステ
ムにスキャンされて，イメージとして再生してもよい。
− 文書類設計者は，体裁が印刷出力に類似した本文を再現することが望ましい。
可能なところならばどこでも，印刷出力の図表は印刷したページに縦方向で提示することが望ましい。
広い本文の全体の幅を図示しなければならず，かつ，縦方向のページに入らないならば，報告書の先頭が
ページの左側になるように，本文を左に90度（横方向に）回転してもよい。
D.3 制作フェーズ
D.3.1 完成した文書の品質及び耐久性
D.3.1.1 紙の重さ
文書類設計者は，次を考慮して紙の重さを選ぶことが望ましい。
− 文書の種類及び大きさに合う。
− 強いイメージ及び繊細な詳細の両方を印刷する。
大部な参考文書に対して，文書類設計者は，完成した文書の重さ及び厚さを抑えるためにより薄い紙を
使うことが望ましい。文書の認知のためには，より厚い紙を使う。
平方メートル当たり80〜130グラム（gsm）の重さの紙が，ほとんどの利用者用文書類のニーズに適し
ている。
仕切りページのために，300 gsmの紙のような，厚紙又は薄いカードを使うことが望ましい。
両面の文書に対しては，一方の面から他の面が透けて（にじみ）見えないように，不透明な紙を使うこ
とが望ましい。
文書類設計者は，印刷組織又は紙の供給者から助言を求めることが望ましく，また，選択した制作方法
を使って幾つかの見本をテストすることが望ましい。
D.3.1.2 紙の表面
つや消し仕上げの紙は，学習書又は参考文書などの利用者用文書に使うことが望ましい。しかし，パン
フレット及びリーフレットに対しては，光沢仕上げ又は半光沢仕上げの紙が利用者により適切なイメージ
を提示する。
湿っている又は汚い環境，例えば，物置で使うかもしれない文書のために，文書類設計者は，ページの
ラミネート又はプラスチックの使用を考えることが望ましい。仕切りページ，特にタブ付きの仕切りに対
して，同様の考慮を払うことが望ましい。つや消しのラミネートは，まぶしさを避けるために，可能なと
ころならどこでも使うことが望ましい。
104
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
D.3.1.3 紙の色
何らかの特別な利用者ニーズがない場合，無地の白紙は最良の選択である。白紙は広い範囲の明度で利
用可能である。ありそうな利用者の環境を考え，及び適切な明度の用紙を選ぶ際の助けのために，プリン
タ又は紙の供給者に相談する。
D.3.1.4 製本
文書の望ましい製本の種類を選ぶために，文書類設計者は，文書がどのように使われるかを考えること
が望ましい。各文書に対して，次などの質問をする。
− 文書は，平にして開く必要があるか。
− 文書は，開いたままにする必要があるか。
− 文書の重さが大切か，例えば，文書を持ち歩きまわる必要があるか。
− どれくらい頻繁に文書を使うと予想されるか。
− 大きい体裁が必要か。
− 文書は，文書題名が付いた背表紙が見える必要があるか。
− 交換のページ又は節を，利用者に発行する必要があるか。
文書類設計者は，上の質問の答えに基づいて，どの種類の製本が各文書に適しているかを決めるために，
印刷組織に相談することが望ましい。
文書は別々にとじることが望ましい。例えば，二つの文書を同じリングバインダでとじないほうがよい。
（利用者は，1冊のリングバインダの内容が一つの文書であると理解し，及び一つの内容リスト及び一つ
の索引があると予想する。）情報の数個の集合を，同じリングバインダで同じ利用者に提示するならば，お
そらく別の部として，情報を1冊の文書に集めるが，内容リスト及び索引は一つだけにする。
背表紙情報は，背表紙全体にわたって読むことが望ましい。背表紙が狭過ぎるならば，情報は背表紙に
沿って読むことが望ましく，現場の取決めで方向を決めてもよい。背表紙の情報は題名，巻数，及び文書
の版（1を超えていれば）を含むことが望ましい。また，文書類設計者は，会社の名前又はロゴを含める
ことを考えることが望ましい。ISO 6357:1985は背表紙の題名の提示のための推奨事項を与える。
D.3.1.5 制作のための原本となるページの提出
原本となるページが制作のために送られる前に，文書類設計者は，次のことについて文書の制作を行う
組織と合意することが望ましい。
− 各文書の冊数
− 各文書のための正確なページサイズ
− 使用すべき紙の種類
− いずれかのページに必要なラミネート又は他の特別な仕上げの詳細
− カード及びチャートのための折り畳みの指示
− 各文書の製本の種類並びに表紙及び背表紙の情報の詳細
− 色の使用上の指示
− 文書の丁合いのための指示。例えば，仕切りカードを入れるのが望ましい場所。
原本となるページを制作のために提出するとき，次の事柄について本を制作する組織と合意する。
− 本を納入する日付，時間，及び場所
− 検査するための見本の納入の日時
105
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 見本へのコメント及びそれらの承認を戻す日時
− 出来上がった文書の納入のための日時
− 費用
文書類設計者は，元のセットがなくなるか又は破損したならば，原本となるページの新しい集合が作成
されてもよいように，文章及び図表の原本となるページの画面上及び紙の複製を安全に保管することが望
ましい。
文書類設計者は，文書の完本を検査することが望ましい。
D.3.1.6 文書及びソフトウェアの媒体の包装
文書類設計者は，幾つかの文書又は1冊の文書を包装するために前の空いた箱（外箱）の使用を考える
ことが望ましい。
外箱はしばしばリングとじの文書を保持するために使用されるが，利用者の一つの種類に対して文書の
完全な集合を保持するために使うならば，文書類設計者は，様々な製本のために外箱を考えることが望ま
しい。ケースは別あつら（誂）えであってもよい。ケースは，ソフトウェア製品の外観を改良し，文書類
の耐久性を増し，及び利用者に便利な保管方法を与える。しかしながら，ケースは製品の包装費用を増加
する。
取り外し可能な媒体が印刷した文書類とともに包装されるならば，文書類設計者は，次を考えることが
望ましい。
− これらの品目自体のリングバインダにとじたプラスチックの入れ物にこれらの品目を入れる。
− 導入の指示又はある他の利用者文書と同じリングバインダにとじたプラスチックの入れ物にこれらの
品目を入れる。
− 文書に伴う外箱の中に入れた，バインダ又は本と同様のサイズの箱の中の，特別に成型したプラスチ
ックの媒体ケースの使用。
文書及びソフトウェアの媒体を包装する前に，文書類設計者は，次の点について包装組織と合意するこ
とが望ましい。
− 別々の文書及びソフトウェアの媒体を一緒に包装する方法の詳細
− 必要な図柄を含む，包装の外側に含めるべき情報
− 使用する包装の形の詳細
− 必要な包装の個数
文書類設計者は，文書及びソフトウェアの媒体をどのように包装すべきかを記述するための包装の線図
（ときには間取り図として知られている。）を作成することを考えることが望ましい。
個々の文書の複製を制作する組織とは別の組織によって包装が行われるならば，文書類設計者は，包装
する前に検査すべき文書の複製及び包装する組織に送る複製を手配することが望ましい。
文書の複製を制作したのと同じ組織で包装をするならば，文書類設計者は，包装見本とともに文書見本
を検査することが望ましい。
ソフトウェアの媒体を文書類とともに包装するならば，文書類設計者は，媒体の複製を包装組織に届け
るように手配することが望ましい。
文書類設計者は，次を含む包装の指示を包装組織に与えることが望ましい。
106
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 納入の指示
− 検査する見本の納入のためのタイムスケール
− 見本へのコメント及びそれらの承認を戻すためのタイムスケール
− 完成した包装の納入のためのタイムスケール
− 費用
D.3.1.7 完成した文書及び包装の検査
文書類設計者は，全ての複製ではなく，個々の文書の見本及び文書類製品全体の見本を検査することが
望ましい。
制作及び包装の組織が検査のために少数の見本を制作することは普通に行われている。文書類設計者は，
多量に制作する前に，これらの見本の誤りを修正することが望ましい。文書類設計者は，多量の文書から
の無作為標本を検査することが望ましい。
制作プロセス及び包装プロセスの結果は，次のことを検証するために確認することが望ましい。
− 文書類の全ての要素は，きれいで，かつ，きずなどがない。
− 表紙は正しく，かつ，表紙の情報は正しく提示されている。
− 印刷の品質は適切であり，かつ，見本を通して一貫している。
− 図表の品質は適切である。例えば，描かれた線及び文字列は明瞭である。
− 色を使っているならば，それらは正しく，かつ，一貫している。
− 文書は，正しく組み立てられている。仕切りは正しい場所にあり，ページは正しい順序に並んでいる，
など。
− 文書は，正しく製本及び包装された。
D.3.2 アクセシビリティ
代替の体裁（12.5参照）を求める要求に対応して印刷した文書類を提供するとき，文書類作成者は，次
を考慮することが望ましい。
− 大きい活字（12ポイント以上）での印刷
− 低い反射率又は低コントラスト紙への印刷
− 文書類が人の手を借りずに開いたままでいるような製本
107
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書E
（参考）
利用者用文書類のためのチェックリスト
注記 附属書Eのチェックリストに関する著作権は，ISOが放棄している。
次のチェックリストは，テクニカルコミュニケーション学会の国際大会でマニュアル及びオンラインヘ
ルプの判定に使うチェックリストからの抜粋である。
E.1
印刷したマニュアルのためのチェックリスト
1. 指針 次の指針は，次を含む全てのマニュアルに適用する。
− ソフトウェアガイド
− ハードウェアとソフトウェアとの組合せガイド
− コンピュータハードウェアガイド
− 非コンピュータ機器ガイド
各評価基準について次の評価の一つを選ぶ。
SD＝強く反対
D＝反対
N/A＝適用しない
SA＝強く賛成
A＝賛成
内容及び組織
基準
SD
D
A
SA
NA
記述の調子及びスタイルが，目的及び読者層にふさわしい。
語彙及び読解レベルは，読者層に対して適切である。
組織及び取決めは，本質的に理解できる又は説明される。
情報を組織化するための総合的な戦略は，主題にふさわしい。
同様の情報は，一貫して提示される。
記述は，利用者及び作業のための詳細さの適切な水準での主題の論理的
展開によって，はっきりし，かつ，公平である。
記述は，性的又は人種的な偏向がない。
技術的な複雑さは効率的に扱われている。
図形要素は，それらが補助する文字列の近くに置かれている。
注，注意，及び警告は，明確に識別され，適切に配置され，並びにそれ
らの意味に対する取決めに従っている。
専門用語は，効果的な場所で定義される。
それらが役立ち，かつ，適切であるときに，クィックスタート手順，学
習書，用語集，付録，又は参照部が含まれている。
適切に，見つけやすい顧客支援情報が含まれる。
108
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
原稿の編集
基準
SD
D
A
SA
NA
つづり，句読点，文法，及び大文字化は，正しく，かつ，一貫している。
記述の調子及びスタイルは，一貫している。
見出しの言葉遣いの処理は，一貫している。
原稿には，明白な技術的誤りがない。
専門用語は，一貫して使用されている。
全ての要素（リスト，例，表など）の処理は，一貫している。
マニュアルの内部及び外部の情報への参照は，正しく，かつ，一貫して
いる。
表，図表，写真及び他の支援資料に対する，ラベル付け，キャプション
及び見出し記号は，一貫している。
頭文字語及び略語は，文字を省略せずに書き出されており，かつ，初出
で定義されている。
目次は，包括的で，役立ち，正確で，かつ，よく編集されている。
索引は，同義語を有効に使うとともに，包括的で，文書中の相互参照し，
正確で，かつ，よく編集されている。また，情報にどうアクセスするか
に関する読者層の観点を考えている。
視覚的な設計
基準
SD
D
A
SA
NA
目的に対して，カバーを含む総合的な設計は，統一されていて適切であ
る。
ページ要素のレイアウトは，読みやすさと使用性に貢献している。
活版印刷は，効果的なデザイン要素として使われている。
活版印刷は，読みやすい。
ヘッダ及びフッタは，読者層が情報を見つけるのを助けるとき視覚的な
効果がある。
その他のナビゲーション機構が適切に使われている。
グラフィックは，出版物の内部の一貫性を維持している。
アイコン及び記号（使われるならば）は，説明され，かつ，効果的に使
われている。
グラフィックは，調子，スタイル，及び内容が読者層にふさわしい。
グラフィックは，効果的に内容を支援する。
グラフィックは，一貫してよく設計されていて読みやすく，かつ，きち
んと行われている。
表，チャート，及び線図は，グラフィック要素として扱われる。
キャプション及び見出し記号は，図表，表，写真，及び他のグラフィッ
クに対して効果的である。
色（使われるならば）は，有効に出版物の魅力及び使用性を高め並びに
設計を効果的に統一する。
目的及び読者層に対して，サイズ及び製本は適切である。
制作材料には，適切な耐久性及び品質がある。
印刷品質は，出版物の読みやすさ及び使用性を支援する。
109
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
全体的に見て
基準
SD
D
A
SA
NA
意図している読者層に対して，目的を達成している。
読込み可能で使用可能な出版物に全ての要素を統合する。
創造性又は独創性に関する証拠を示している。
出版物の後援者の専門的イメージを与える。
E.2
オンラインヘルプのためのチェックリスト
尺度 5
弱さが僅かであるか又は全くないことで最高の品質を示している。
4
強さが弱さに勝っている。
3
強さと弱さが同程度である。
2
弱さが強さよりも重要である。
1
弱い領域が有効性を大いに損なっている。
ヘルプ項目はその目的を満たしているか。
（区分全体の評点として数字の下にXを付ける。）
1
2
3
4
5
評価要因
はい
いいえ
適用な
し
読者層定義
ヘルプが取り組む明確に定義した読者層があるか。
ヘルプは意図している読者層のニーズを効果的に満たしているか。
目標又は目的
ヘルプの目標又は目的は明確に述べられているか。
ヘルプは，必要なところで質問に答えるか又は適切な援助を提供しているか。
ヘルプにアクセスするために，有効な方法が複数あるか。
状況への依存度の水準は適切であるか，かつ，それは役に立つ情報に導くか。
ヘルプ項目にまとめた目標について，文書類作成者は次のために適切な選択をしたか。
− ヘルプ設計
− 状況依存度
− 言語
− リンク
− 対話性
ヘルプの内容は述べられた目標に適切に対処しているか。
ヘルプシステムは，作業を完了する方法について明確かつ十分な指示を提供し
ているか。
110
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
高品質な内容があるか，及びそれは有効に伝えられているか。
（区分全体の評点として数字の下にXを付ける。）
1
2
3
4
5
評価要因
はい
いいえ
適用な
し
著述
ヘルプシステムは，うまく書かれているか。
文体は，読者層及び扱っているトピックに対して適切か。
言語は，ヘルプシステム中で一貫しているか。
言語は，対象に対して適切か。
（使われるならば）手順は，明確な順番のステップで示されているか。
内容の設計
題名及び見出しは，これに続く情報を明確に識別するか。
リスト，表，及びグラフィックは，有効に使われているか。
ヘルプは，利用者を導くための目印を提供しているか。
総合的な品質
ハイパーリンクなどのナビゲーションの要素の全てが，正しく解決し，予期した方
法で誤りなく振る舞っているか。
ヘルプのナビゲーション（ハイパーリンク）に誤りはないか。
読者層に対して，内容は，一貫しかつ適切であるか。
インタフェースは，一貫していて，使いやすく，かつ，信頼できるか。
111
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
内容は，うまく統合及び組織化されているか。
（区分全体の評点として数字の下にXを付ける。）
1
2
3
4
5
評価要因
はい
いいえ
適用な
し
組織又は統合
ヘルプシステムは，うまく組織化され及び読者層のための組織は適切か。
組織は，明白か。
情報は，適切なトピック項に組織化されているか。
情報は，適切なサブトピック項に組織化されているか。
トピック項の間で容易に動き回れるか。
関連する外部の文書，トピック項，又はサブトピック項への直接のリンク又はテキ
スト参照があるか。
目次（又はナビゲーション用の同等物）
内容は，目次又はナビゲーション用の同等物の中で明確に識別されるか。
目次又はナビゲーション用の同等物は，完全かつ包括的であるか。
目次又は他のナビゲーション用の同等物は，内容にアクセスする又は情報の分岐を
通って動くための簡単な方法を提供しているか。
索引
索引項目は，うまく選ばれているか。
索引は，トピック項のために，相互参照及び代替語（同義語）を使っているか。
逐次検索欄，アルファベットナビゲーションボタン，又は他の仕組みを使って索引
を簡単にブラウズできるか。
検索
ヘルプシステムには，有効な検索機構があるか。
全文検索能力があれば，使いやすいか。それはワイルドカード，大文字小文字の区
別，及び単語の変化を扱えるか。
検索範囲を指定できるか。
ナビゲーション
特定の情報の発見，情報の中のナビゲーション，及び出発したところへの復帰が簡
単か。
ナビゲーションの援助手段があるか及びそれらはヘルプを通じて一貫して使われ
ているか。
状況依存度
ヘルプは，状況依存ヘルプを有効に採用しているか。
使用性
インタフェースは，直感的で，容易に解釈でき，かつ，一貫しているか。
ヘルプ，ヘルプのヘルプ，動作の手がかりなどの利用者を補助するために提供さ
れた情報があるか。
112
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
情報伝達メディアは効果的及び適切に使用されているか。
（区分全体の評点として数字の下にXを付ける。）
1
2
3
4
5
評価要因
はい
いいえ
適用な
し
基盤の取決め及び特徴
ヘルプは，基盤の標準的な取決め及び特徴を適切に使っているか。
例えば，ヘルプがWindowsヘルプファイルであれば，適切に内容ファイル，索引
機能，設計の選択肢など標準のWinHelpの特徴を使っているか。
速度
ヘルプは，すぐに反応するか。
ヘルプは，性能を最適化するように設計されているか。
対話性
ヘルプは，選択を提供するか，及び利用者はペースを制御することができるか。
利用者は，部分を省略すること，又は繰り返すことができるか。
利用者は，容易にヘルプから出られるか。
画面設計及びアクセシビリティ
設計は，魅力的かつ誘惑的か。
画面は読みやすいか。
活字の大きさは読みやすいか。必要ならば，活字の大きさを変更できるか。
設計は，可能なところならどこでもスクロールする必要性を最小にしているか。
ヘルプシステムは，それらを必要とする利用者のためにツールチップなどの適切な
アクセシビリティ機能を提供しているか。
グラフィック
グラフィックは，概念を伝えるために有効に使用されているか。
グラフィックは，魅力的かつ高品質であるか。
メディア
メディアの要素（音，ビデオ，アニメーション，及び対話的な要素などの）は，使
いやすいか。
高品質のメディアの要素（音，ビデオ，アニメーションなど）であるか。
メディアの要素は，適切に使われているか。それらはヘルプの伝達の目的を強化し
ているか。
メディアの要素は，お互いどうしと調和しており，かつ，内容と調和しているか。
113
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書F
（参考）
文書化プロセスのための要求事項の箇条及びチェックリスト
この規格の利用者の都合のために，この附属書は，文書化プロセスのために要求事項（指示若しくは要
求又は禁止の文）を含む箇条を識別する。この規格への適合性について検証するとき，次の表は，特定の
要求事項を使っている場所を識別する。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
2.2
適合性の状況
利用者用文書類の適合性は，
様々な状況に応じてそれぞれ
に解釈される。適合性の主張の
前提となる状況は，適合性の主
張の中で，次のように明示しな
ければならない。（リストが続
く。）
6
プロジェクトの要求事項，目
標，及び制約条件
利用者用文書類の作成者は，
文書類の構成要素の設計に影
響する要求事項を理解するた
めに，プロジェクト全体のより
広い範囲の情報を集めたり，又
は受け取ったりしなければな
らない。
6.1
プロジェクトの目標
プロジェクトは，次に示すソ
フトウェア製品に要求される
標準の情報を保守しなければ
ならない。
6.4
利用者及び使用性の目標
したがって，使用性の要求事
項及びそのテストの方法は，利
用者のその他のニーズが決ま
る分析フェーズで指定しなけ
ればならない。
6.4
利用者及び使用性の目標
ソフトウェア製品のために
使用性の達成目標を設定し及
び測定するとき，文書類はソフ
トウェア製品に不可欠な部分
として扱わなければならない。
114
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
6.4
利用者及び使用性の目標
ソフトウェアの使用性から
独立している文書類の使用性
の測定には，次を含まなければ
ならない。（リストが続く。）
6.6
プロジェクト計画
文書化計画プロセスの結果
は，制作すべき文書類を網羅
し，かつ，それぞれの文書品目
のための個別の計画（概要又は
仕様）を含む，文書化計画に記
録しなければならない。
6.6
プロジェクト計画
文書化計画は，次に示すそれ
ぞれの主なアクティビティの
ために責任及び権限を割り当
てなければならない。（リスト
が続く。）
6.6
プロジェクト計画
文書化計画は，文書以外の残
りの製品とともに承認される
ことが望ましく，かつ，文書化
計画以外の残りのプロジェク
ト計画とともに変更管理手順
の下になければならない。
6.6.2
版管理及び変更管理
利用者用文書類を管理する
ためには構成管理（CM）プロ
セスを使わなければならない。
6.6.2
版管理及び変更管理
プロジェクトのための変更
管理手順は，文書化アクティビ
ティの要求事項を考慮しなけ
ればならない。
6.6.4
スケジュール
プロジェクト実装フェーズ
の間，組織は，文書化アクティ
ビティのために準備段階のス
ケジュールを準備しなければ
ならない。
115
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
6.6.4
スケジュール
プロジェクトの他の部分の
ための基本計画の一部として，
それぞれ独立した文書を作成
するためのより詳細なスケジ
ュールを，設計及び作成フェー
ズの間に作らなければならな
い。
6.6.4
スケジュール
ソフトウェア製品及び計画
された納品日の変更は，関係者
に即座に伝えなければならず，
かつ，文書類に対するこれらの
変更の影響を評価しプロジェ
クトマネージャに伝達しなけ
ればならない。
7
分析及び設計
文書類は，読者層分析及び作
業分析に基づかなければなら
ない。
7.1.1
読者層分析
設計者は，ソフトウェア製品
の意図している利用者の種類
を列挙し，かつ，利用者を読者
層へと分類しなければならな
い。
7.2
利用者用文書類の設計
利用者用文書類の設計者は，
次の二つの主要なアクティビ
ティを実行しなければならな
い。（リストが続く。）
7.2.2
体裁の設計
組織は，全ての文書及び文書
集合，トピック項，章，前付，
後付，序文，技術的専門用語，
アイコン及び記号，ナビゲーシ
ョンコントロール，並びにシス
テムメッセージに対して，全て
の製品，プロジェクト，又は組
織のための取決めを設定しな
ければならない。
8.1.1
作成の間の構成管理
文書類の作成に責任をもつ
組織は，プロジェクトのための
構成管理システムの要求事項
が励行されるのを確実にしな
ければならない。
116
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
8.1.1
作成の間の構成管理
承認された文書類版は，安全
に保守し，かつ，作成のために
持ち出す複製とは別々に保守
しなければならない。
8.1.1
作成の間の構成管理
レビューのために発行した
各草稿は，一意に識別されなけ
ればならない。
8.1.2
翻訳及び地域化した文書類の
作成
翻訳プロセスにおける第一
歩として，プロジェクトの用語
集（用語及びその定義のリス
ト）を翻訳しなければならな
い。
8.1.2
翻訳及び地域化した文書類の
作成
用語の翻訳したリストが承
認された後にだけ，文書類を翻
訳しなければならない。
8.2
文書類の評価
文書類テストの要求事項は，
明確で，かつ，測定できなけれ
ばならない。
8.2
文書類の評価
文書類の評価は，次の四つの
アクティビティを含まなけれ
ばならない。（リストが続く。）
8.2.1
文書類の品質の評価における
他の人々の役割
文書類の評価は，要求された
特徴及び品質に基づかなけれ
ばならない。
8.2.2
文書類レビュー手順
安全性。レビュアは，意図し
ている利用者が容易に気付き，
かつ，理解できるように，警告
及び注意が適切に配置され，か
つ，言葉で表現されていること
を検証しなければならない。
8.2.2
文書類レビュー手順
制作の前に，文書類は全部を
レビューしなければならない。
117
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
8.2.2
文書類レビュー手順
レビュー及び受入れの手順
は，変更の受入れ及び実装の最
終的な権限は誰かを指定しな
ければならない。
8.2.2
文書類レビュー手順
少なくともレビューの次の
サイクルが完了するまで，レビ
ュアのコメントは構成管理の
下に保有しなければならない。
9.1
最終的な組立て及びレビュー
最終稿が承認されたとき，出
版若しくは製作要員，編集要
員，又は文書の著者以外の人
は，次のことを行わなければな
らない。（リストが続く。）
9.2
承認
文書類は，リリースする前
に，文書類計画又は契約で指定
したように承認されなければ
ならない。
9.3
構成管理
構成管理プロセスは，文書類
のリリースした版の管理版を
維持するのに使わなければな
らない。
9.4
更新及び保守
新しいリリース（翻訳を含
む。）によって影響を受ける文
書類の内容，特に教習手順は，
更新しなければならず，かつ，
ソフトウェア及び文書類の保
守のために契約した顧客に供
給しなければならない。
118
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書G
（参考）
文書類製品のための要求事項の箇条及びチェックリスト
この規格の利用者の都合のために，この附属書は，文書類製品のために要求事項（指示若しくは要求又
は禁止の文）を含む箇条を識別する。この規格への適合性について検証するとき，次の表は，特定の要求
事項を使っている場所を識別する。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
10
文書類の構造
文書集合が甚だしく異なる
ニーズの読者層を扱うとき，次
の構造の少なくとも一つを使
わなければならない。（リスト
が続く。）
10
文書類の構造
一つの読者層に固有なニー
ズを扱うそれぞれの節の集ま
り（序文で，どの節が利用者に
とって意味あるものかを識別
できるように，対象とする読者
層及びその読者層のニーズを
具体的に識別しなければなら
ない。）（リストの項目。）
10.1
文書類の全体的な構造
文書は，固有な内容で構成単
位に構造化しなければならな
い。
10.1
文書類の全体的な構造
各ページ又は画面は，一意に
名付けなければならない（例え
ば，ページ若しくはトピック項
の番号，又は画面の名称若しく
は番号）。
10.1
文書類の全体的な構造
印刷した文書は，章の中では
3水準を超えない細分で構造化
しなければならない。
119
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
10.1
文書類の全体的な構造
画面上の文書は，トピック項
の最初のページから3回を超え
ないジャンプ（すなわち，3回
を超えないリンク）で情報にア
クセスできるように構造化し
なければならない（文書を開く
ために必要な動作は数えな
い。）。
10.1
文書類の全体的な構造
文書類の構成は，利用（教習
又は参照）モードを支援しなけ
ればならない。
10.1
文書類の全体的な構造
文書が教習及び参照の両方
の資料を含むとき，この二つ
は，異なる章若しくはトピック
項に明確に分離するか，又は章
若しくはトピック項の中で体
裁設定によって区別しなけれ
ばならない。
10.1.1
教習モードの文書類の構造
作業指向の教習モードの文
書類は，利用者の作業に従って
構造化された手順を含まなけ
ればならない。
10.4
利用者用文書類の構成要素
情報が存在しないか又は特
定の文書には適用できないと
き以外には，要求される構成要
素は，文書類に含まれていなけ
ればならない。
10.5.1
初期構成要素
それぞれの個別の文書は，目
次（12.13参照）及び序文が後
に続く識別データ（11.3）から
始まるように構造化しなけれ
ばならない。
10.5.1
初期構成要素
序文は，文書の意図している
読者層，適用範囲，及び目的に
ついて説明し，かつ，ソフトウ
ェアの目的，機能，及び運用環
境の簡潔な概要を含まなけれ
ばならない。
120
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
10.5.1
初期構成要素
文書の中で各章及びトピッ
ク項に序文を提供しなければ
ならない。
10.5.1
初期構成要素
入門の節は，トピック項の概
要，機能の目的，及びそのトピ
ック項に特有な環境の要求事
項，警告，注意，又は利用者の
要求事項を提供しなければな
らない。
10.5.2
重大情報の配置
ソフトウェア又は文書類の
利用の間中適用される一般的
な警告又は注意は，最初の構成
要素に現れなければならない。
10.5.2
重大情報の配置
特定の警告及び注意は，同じ
ページ又は画面に，かつ，注意
を必要とする手順又はステッ
プの直前に，現れなければなら
ない。
11
利用者用文書類の情報の内容
この箇条で要求している情
報は，情報が存在しない場合又
は特定の文書には適用できな
い場合以外は，文書類に含まれ
なければならない。
11.1
情報の完全性
文書類は，全ての重大な（そ
の故障が安全に影響を与える
ことがあったり，又は大きな財
政的若しくは社会的な損失を
もたらすことがある）ソフトウ
ェアの機能のための，教習用及
び参照用の完全な情報を提供
しなければならない。
11.1
情報の完全性
教習モードの文書類は，読者
層の中で最も経験のない人々
がソフトウェアの機能を使っ
て選択した作業を遂行できる
ために完全な情報を含まなけ
ればならない。
121
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
11.1
情報の完全性
参照モードの文書類は，文書
化するように選択した要素の
全ての事実を含んでいなけれ
ばならない。
11.1
情報の完全性
例えば，参照モードの文書類
が，ソフトウェアの命令の部分
集合を包含しているならば，そ
の部分集合に関連する利用者
が入力する命令及びシステム
が表示する命令並びにエラー
メッセージを含んでいなけれ
ばならない。
11.2
情報の正確性
文書類は，適用可能なソフト
ウェアの版の機能及び結果を
正確に反映しなければならな
い。
11.2
情報の正確性
文書類の前の版がもはや正
確でなければ，ソフトウェアの
更新版又は性能向上版を取得
する顧客のために，現在の文書
類が利用可能でなければなら
ない。
11.3
識別データの内容
文書類は，一意な識別データ
を含まなければならない。識別
データは，次を含まなければな
らない。（リストが続く。）
11.3
識別データの内容
識別データは，包装を開けず
に読むことができる包装の名
札，及び題名のページに表記し
なければならない。
11.3
識別データの内容
文書集合の各文書には，一意
な題名のページがなければな
らない。
11.3
識別データの内容
文書及びソフトウェアの識
別は，発行組織又は取得組織の
構成管理の実践と一致してい
なければならない。
122
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
11.3
識別データの内容
情報（変更履歴）は，最新版
の発行日及び版番号を記録す
るために文書集合に提供しな
ければならない，
11.4
文書類の利用のための情報
文書類は，それをどう使うべ
きかの情報（例えば，ヘルプを
使うためのヘルプ），及び記法
に関する説明（体裁及び取決め
の説明11.12及び12.11参照）を
含まなければならない。
11.4
文書類の利用のための情報
文書集合の少なくとも一つ
の文書が，その集合の中の全て
の文書の題名及び利用の意図
を明らかにしなければならな
い。
11.5
運用の概念
文書類は，それぞれの文書化
した機能を全体のプロセス又
は作業に関連付けなければな
らない。
11.6
ソフトウェアの一般的な利用
のための情報
作業指向の教習モード文書
類は，ソフトウェアの一般的な
利用に必要な次のような定例
作業についての指示を含まな
ければならない。（リストが続
く。）
11.7
手順及び学習書のための情報
教習モード文書類は，手順を
実行するための指示を提供す
る。手順は，次を含まなければ
ならない。（リストが続く。）
11.7.1
手順のための準備の情報
手順のための準備の情報は，
次を含まなければならない。
（リストが続く。）
11.7.1
手順のための準備の情報
関連する警告，注意，及び注
は，それぞれの適用する教習の
ステップ又は一組のステップ
の直前に置く。
123
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
11.7.2
手順のステップ
手順のステップは，アラビア
数字を使って番号付けし，か
つ，実施する順番に提示しなけ
ればならない。
11.7.2
手順のステップ
手順のステップは，予想した
結果又はシステムの応答を示
さなければならない。
11.7.2
手順のステップ
手順のステップは，許容でき
る範囲，最大の長さ及び適切な
体裁の文書類，並びに利用者が
供給するデータのデータ欄の
計測の単位を含むか又は参照
を提供しなければならない。
11.7.2
手順のステップ
手順のステップは，エラーメ
ッセージ及び回復手順の説明
を含むか又は参照を提供する
かしなければならない。
11.7.3
手順のための完了情報
全ての手順は，手順が首尾よ
く完了したことが，利用者にと
って明らかであることを確実
にしなければならない。
11.8
ソフトウェアの命令について
の情報
文書化しているシステムの
構文を観察して，文書類作成者
は，必須パラメータ，任意パラ
メータ，省略時のオプション，
命令の順序，及び構文（12.11.1
参照）を含む，利用者が入力す
るソフトウェアの命令の書式
及び手順を説明しなければな
らない。
11.8
ソフトウェアの命令について
の情報
参照モードの文書類は，予約
語又は命令の参照一覧表を含
まなければならない。
124
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
11.8
ソフトウェアの命令について
の情報
文書類は，命令の実行中に操
作を中断及び復元する方法並
びに可能ならば再実行する方
法を説明しなければならない。
11.8
ソフトウェアの命令について
の情報
文書類は，命令の実行が成功
したか又は異常終了したかを
見分ける方法を示さなければ
ならない。
11.10
エラーメッセージ及び問題解
決の内容
参照モードの文書類は，問題
の識別，推定される原因，及び
利用者が行うことが望ましい
是正処置とともに各エラーメ
ッセージを含まなければなら
ない。
11.10
エラーメッセージ及び問題解
決の内容
問題解決の文書類はまた，ソ
フトウェア又はその文書類の
問題の報告のため，及び改良の
提案のための連絡先情報を含
んでいなければならない。
11.11
警告及び注意の内容
警告又は注意は，次の部品を
含まなければならない。（リス
トが続く。）
11.12
専門用語の情報
ソフトウェアのユーザイン
タフェース又は文書類の中の
用語又はそれらの特定の使い
方が，読者層の中の初心者にな
じみがない傾向がある場合に
は，文書類は用語集を含まなけ
ればならない。
11.12
専門用語の情報
用語集は，用語及び定義の五
十音順のリストを含まなけれ
ばならない。
125
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
11.14
利用者が提供した内容
修正できる体裁で文書類を
供給するならば，供給者は，次
のことを確実にしなければな
らない。（リストが続く。）
12.2
印刷用の体裁又は画面上の体
裁の使用
画面上の文書類を提供する
か否かに関係なく，次の文書類
は製品のソフトウェアとは別
に印刷した形で提示されなけ
ればならない。（リストが続
く。）
12.2
印刷用の体裁又は画面上の体
裁の使用
箱の中にこん（梱）包されて
納入されるソフトウェアの場
合，この情報は，印刷され箱の
中に収められていなければな
らない。
12.2
印刷用の体裁又は画面上の体
裁の使用
画面上の文書類を提供する
とき，ソフトウェアへの利用者
入力が可能であるときはいつ
も，その文書類が表示できなけ
ればならない。
12.3.2
アプリケーションの表示への
情報表示の関係
画面上の参照モードの文書
類を提供する場合，文書化する
ソフトウェアからアクセスし
やすくなければならず，かつ，
文書類からの退出及びそのソ
フトウェアへの復帰のための
明確な手段を提供しなければ
ならない。
12.5
アクセスしやすい文書類
文書類は，作業環境における
利用者の予想したグループに
とって，利用しやすく，かつ，
利用可能でなければならない。
126
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
12.5.2
アクセスしやすい電子的な形
式での利用者用文書類の提供
全ての利用者用文書類は，印
刷及び画面上のいずれも，適用
できる文書類のアクセシビリ
ティ規格を満たす電子的な形
式で納入しなければならない。
12.5.2
アクセスしやすい電子的な形
式での利用者用文書類の提供
この文書類は，製品と一緒
に，又は要求に応じて適時に及
び追加費用なしに提供しなけ
ればならない。
12.5.3
画面上の文書類における代替
文章の提供
ソフトウェアによって画像
及びグラフィックで示された
情報は，また，代替の方法で読
めるように，画面読上げ，印刷，
又は点字変換に適した説明文
として提供しなければならな
い。
12.5.5
アクセシビリティ機能につい
ての文書類の提供
印刷及び画面上の文書類は，
アクセシビリティ機能の利用
可能性についての一般的情報
並びにそれぞれの機能の目的
及び使用法についての情報を
提供しなければならない。
12.6
体裁の一貫性
文書類は，ユーザインタフェ
ースの構成要素，データ要素，
欄名，機能，ページ，トピック
項，及びプロセスについて，文
書集合を通して一貫した専門
用語を使わなければならない。
12.6
体裁の一貫性
体裁設定の取決めは，文書類
の集合を通して適用しなけれ
ばならない。
12.6
体裁の一貫性
アプリケーションがアイコ
ン又は記号を使う場合，画面上
の文書類は，それが何を表すか
を説明しなければならない。
127
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
12.6
体裁の一貫性
文書類は，他のオブジェクト
を表すためにそれらのアイコ
ンを使ってはならない。
12.6
体裁の一貫性
警告，注意，注などの，特別
に重要な情報を強調するため
の体裁設定の取決めは，文書集
合を通して一貫して適用しな
ければならない。
12.6
体裁の一貫性
指示の集合などの類似した
構成要素は，一貫した体裁で表
現しなければならない。
12.8
画面及びページのレイアウト
文書類設計者は，類似した情
報の体裁のために一貫したレ
イアウトを準備しなければな
らない。
12.9
視認性
印刷した文書類及び画面上
の文書類は，予想した作業環境
における利用者と文書類との
間の距離を考慮に入れて，利用
者にとって読みやすくなけれ
ばならない。
12.9
視認性
文書類は，予想した背景（紙
の色又は画面の背景色）に対し
て読みやすいフォントスタイ
ル及び色を使わなければなら
ない。
12.9
視認性
図表に文字列を含む印刷し
た文章は，ページ上で測定した
大文字が2.75 mm未満であって
はならない。
12.11
ユーザインタフェース要素を
表すための体裁
次の様々な要素と文章とが
それぞれ区別されるように，一
貫したグラフィック又は印刷
の体裁によって，文書類の中で
表現しなければならない。（リ
ストが続く。）
128
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
12.11.1
コントロール及びコマンド入
力の表現
利用者が入力するコマンド
又はコードのための文書類の
体裁は，定数（表示したものと
全く同じに入力するもの）と変
数（利用者が準備するもの）と
を明確に区別しなければなら
ない。
12.11.1
コントロール及びコマンド入
力の表現
丸括弧，波括弧，不等号（よ
り大>）及び不等号（より小<），
並びに他の記号の正式な記法
は，参考文献における参照のた
めの［…］を除いて，それを使
用するあらゆる文書の中で定
義しなければならない。
12.11.1
コントロール及びコマンド入
力の表現
引用符は，利用者がそれらを
文字どおりに入力することが
望ましい場合以外は，コマンド
の表現に使ってはならない。
12.11.2
特別なキーボードキーの表現
文書類は，特別なキーボード
キーを表現するために一貫し
た取決めを確立し，かつ，入力
に特別なキーを使用するソフ
トウェアのために文書類でそ
の取決めについて説明しなけ
ればならない。
12.13
ナビゲーションの機構
文書類は，通常とは異なるよ
うな，柔軟な，又は複雑なシス
テム固有な及び複雑な文書固
有な，ナビゲーションの機構の
説明を含まなければならない。
12.13
ナビゲーションの機構
ナビゲーション機構は，文書
類の利用者が次の場所に行け
るようにしなければならない。
（リストが続く。）
129
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
12.13.2
同じ情報の再発見
印刷した又は画面上の文書
類の中で利用者が自分の位置
を決定できるように，ナビゲー
ションのための機構を提供し
なければならない。
12.13.2
同じ情報の再発見
印刷した文書類では，各ペー
ジは，一意なページ番号をもっ
ていなければならない。
12.13.2
同じ情報の再発見
画面上の文書類では，各ペー
ジ又は画面は，利用者が見るこ
とができる一意な識別子（英数
字又はキャプション）をもって
いなければならない。
12.13.5
情報のリンク
関連したトピック項の間の
リンクは，利用者がいずれのト
ピック項に最初にアクセスし
ても，もう一方のトピック項の
関連情報へジャンプできるよ
うに，双方向でなければならな
い。
12.13.5
情報のリンク
リンクはリンクの目的地の
明確な指示を提供しなければ
ならない。
12.14
情報を発見するための文書類
の体裁
10.4で示したように，文書類
は，目次，索引，検索機能など
のような情報へのアクセスを
提供する機構を含まなければ
ならない。
12.14.1
目次
目次は，それぞれのためのア
クセスポイント（先頭ページ番
号又は電子的なリンク）ととも
に，文書の章又はトピック項の
見出しを列挙しなければなら
ない。
130
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
12.14.1
目次
識別データ以降が約8ページ
未満の文書は，目次を省略して
もよい。印刷した文書では，目
次は，識別データの直後に続か
なければならない（11.3参照）。
注記 対応国際規格におけるこ
の項目の位置が誤りであ
ったので，正しい位置に
移動した。
12.14.1
目次
文書集合の少なくとも1巻
は，集合の全ての巻の単純な目
次を含まなければならない
（10.4参照）。
12.14.1
目次
目次は，目次に続く前付及び
後付（例えば，付録，用語集，
及び索引）を含む，文書類の全
ての部分を含まなければなら
ない。
12.14.1
目次
目次の中の見出しは，章又は
トピック項の番号を含めて，言
葉遣いが文書中と同じでなけ
ればならない。
12.14.1
目次
目次の体裁は，一貫した印刷
デザイン又は字下げによって
見出しの階層構造を区別しな
ければならない。
12.14.1
目次
印刷した文書類では，目次は
本文と同じ順序に見出しを列
挙しなければならない。
12.14.3
図表リスト
図表のリストは，それぞれの
（最初のページ番号又は電子
的なリンクなどの）アクセスポ
イントとともに図表番号及び
題名を列挙しなければならな
い。
131
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
12.14.3
図表リスト
表，図，又は図表のリストの
題名は，表，図，又は図表の番
号を含め言葉遣いが文書中の
ものと同じでなければならな
い。
12.14.4
索引
約40を超えるトピック項の
画面上の文書は，検索ツール
（12.14.5参照）又はアクセスポ
イントが電子的なリンクであ
る索引のいずれかを含まなけ
ればならない。
12.14.4
索引
索引項目は別の索引項目へ
の相互参照であってもよいが，
参照先の項目は，文書類へのア
クセスポイントを与えなけれ
ばならず，かつ，3番目の索引
項目を指してはならない。
12.14.5
検索能力
画面上の文書類は，文章中の
単語の場所を見つける方法を
提供しなければならない。
12.15
警告，注意，及び注のための体
裁
警告（warning），注意
（caution），及び注（note）は，
普通の文章又は指示のステッ
プから容易に区別できる一貫
した体裁で表示しなければな
らない。
12.15
警告，注意，及び注のための体
裁
見出し語（例えば，“警告”，
“注意”，又は“注”）が，付随
の文章の前になければならな
い。
12.15
警告，注意，及び注のための体
裁
“注”という用語は，危険を
識別するために使ってはなら
ない。
132
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
箇条
番号
ガイドライン
適用性
適合性
はい
又は
いいえ
適用できない理由
はい 部分的 いいえ
注釈
12.15
警告，注意，及び注のための体
裁
警告及び注意は，一貫し，か
つ，他と異なり区別できる図記
号，例えば，感嘆符又は三角形
の中の稲妻，によって識別しな
ければならない。
12.16
指示のための体裁
指示のステップは，連続して
付番しなければならない。
12.18.4
図表の一貫した提示
類似した内容の図表の体裁
は，縮尺，画面サイズ，フォン
ト，線幅，及び色使いについて，
一貫していなければならない。
12.18.8
表
1ページに入らない長い表
は，それぞれのページに表の題
名及び行又は列の見出しを繰
り返すか，又は見開き2ページ
を使わなければならない。
133
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
参考文献
[1] ISO 216:2007，Writing paper and certain classes of printed matter−Trimmed sizes−A and B series, and
indication of machine direction
[2] ISO 999:1996，Information and documentation−Guidelines for the content, organization and presentation of
indexes
[3] ISO 6357:1985，Documentation−Spine titles on books and other publications
[4] JIS Q 9000:2006 品質マネジメントシステム−基本及び用語
注記 対応国際規格：ISO 9000:2005，Quality management systems−Fundamentals and vocabulary（IDT）
[5] ISO/IEC 9126-1:2001，Software engineering−Product quality−Part 1: Quality model
注記 ISO/IEC 9126-1:2001は廃止され，JIS X 25010:2013 システム及びソフトウェア製品の品質
要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル，対応国際規格：ISO/IEC
25010:2011，Systems and software engineering−Systems and software Quality Requirements and
Evaluation (SQuaRE)−System and software quality models（IDT）に置き換わった。
[6] TS X 0111-2:2009 ソフトウェア製品の品質−第2部：JIS X 0129-1による外部測定法
注記 対応国際規格：ISO/IEC TR 9126-2:2003，Software engineering−Product quality−Part 2: External
metrics（IDT）
[7] TS X 0111-3:2009 ソフトウェア製品の品質−第3部：JIS X 0129-1による内部測定法
注記 対応国際規格：ISO/IEC TR 9126-3:2003，Software engineering−Product quality−Part 3: Internal
metrics（IDT）
[8] TS X 0111-4:2009 ソフトウェア製品の品質−第4部：JIS X 0129-1による利用時の品質測定法
注記 対応国際規格：ISO/IEC TR 9126-4:2004，Software engineering−Product quality−Part 4: Quality
in use metrics（IDT）
[9] ISO/IEC TR 9294:2005，Information technology−Guidelines for the management of software documentation
注記 ISO/IEC TR 9294は廃止され，ISO/IEC/IEEE 26511:2011，Systems and software engineering−
Requirements for managers for user documentationに置き換わった。
[10] JIS Z 8511〜JIS Z 8527人間工学−視覚表示装置を用いるオフィス作業
注記 対応国際規格：ISO 9241-1〜ISO 9241-17，Ergonomic requirements for office work with visual
display terminals (VDTs)（MOD）
[11] JIS Z 8521:1999 人間工学−視覚表示装置を用いるオフィス作業−使用性についての手引
注記 対応国際規格：ISO 9241-11:1998，Ergonomic requirements for office work with visual display
terminals (VDTs)−Part 11: Guidance on usability（IDT）
[12] JIS Z 8522:2006 人間工学−視覚表示装置を用いるオフィス作業−情報の提示
注記 対応国際規格：ISO 9241-12:1998，Ergonomic requirements for office work with visual display
terminals (VDTs)−Part 12: Presentation of information（IDT）
[13] JIS Z 8520:2008 人間工学−人とシステムとのインタラクション−対話の原則
注記 対応国際規格：ISO 9241-110:2006，Ergonomics of human-system interaction−Part 110: Dialogue
principles（IDT）
[14] JIS X 8341-6:2013 高齢者・障害者等配慮設計指針−情報通信における機器，ソフトウェア及びサー
134
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ビス−第6部：対話ソフトウェア
注記 対応国際規格：ISO 9241-171:2008，Ergonomics of human-system interaction−Part 171: Guidance
on software accessibility（IDT）
[15] ISO 10007:2003，Quality management systems−Guidelines for configuration management
[16] JIS X 9303-1:2006 情報技術−ユーザシステムインタフェース及びシンボル−アイコン及び機能−第
1部：アイコン一般
注記 対応国際規格：ISO/IEC 11581-1:2000，Information technology−User system interfaces and
symbols−Icon symbols and functions−Part 1: Icons−General（IDT）
[17] JIS X 9303-2:2006 情報技術−ユーザシステムインタフェース及びシンボル−アイコン及び機能−第
2部：オブジェクトアイコン
注記 対応国際規格：ISO/IEC 11581-2:2000，Information technology−User system interfaces and
symbols−Icon symbols and functions−Part 2: Object icons（IDT）
[18] JIS X 9303-3:2006 情報技術−ユーザシステムインタフェース及びシンボル−アイコン及び機能−第
3部：ポインタアイコン
注記 対応国際規格：ISO/IEC 11581-3:2000，Information technology−User system interfaces and
symbols−Icon symbols and functions−Part 3: Pointer icons（IDT）
[19] JIS X 9303-5:2010 情報技術−ユーザシステムインタフェース及びシンボル−アイコン及び機能−第
5部：ツールアイコン
注記 対応国際規格：ISO/IEC 11581-5:2004，Information technology−User system interfaces and
symbols−Icon symbols and functions−Part 5: Tool icons（IDT）
[20] JIS X 9303-6:2006 情報技術−ユーザシステムインタフェース及びシンボル−アイコン及び機能−第
6部：動作アイコン
注記 対応国際規格：ISO/IEC 11581-6:1999，Information technology−User system interfaces and
symbols−Icon symbols and functions−Part 6: Action icons（IDT）
[21] JIS X 0160:2012 ソフトウェアライフサイクルプロセス
注記 対応国際規格：ISO/IEC 12207:2008，Systems and software engineering−Software life cycle
processes（IDT）
[22] ISO 13407:1999，Human-centred design processes for interactive systems
注記 ISO 13407:1999は廃止され，ISO/TS 18152:2010 Ergonomics of human-system interaction−
Specification for the process assessment of human-system issuesに置き換わった。
[23] ISO/IEC 14598-1:1999，Information technology−Software product evaluation−Part 1: General overview
注記 ISO/IEC 14598-1:1999は廃止され，JIS X 25000:2010 ソフトウェア製品の品質要求及び評価
（SQuaRE）−SQuaREの指針，対応国際規格：ISO/IEC 25000:2005，Software engineering−
Software product Quality Requirements and Evaluation (SQuaRE)−Guide to SQuaRE（IDT）に置き
換わった。
[24] ISO/IEC 14598-2:2000，Software engineering−Product evaluation−Part 2: Planning and management
注記 ISO/IEC 14598-2:2000は廃止され，JIS X 25001:2012 ソフトウェア製品の品質要求及び評価
（SQuaRE）−計画及び管理，対応国際規格：ISO/IEC 25001:2007，Software engineering−
Software product Quality Requirements and Evaluation (SQuaRE)−Planning and management（IDT）
に置き換わった。
135
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
[25] ISO/IEC 14598-3:2000，Software engineering−Product evaluation−Part 3: Process for developers
注記 ISO/IEC 14598-3:2000は廃止され，JIS X 25040:2014 システム及びソフトウェア製品の品質
要求及び評価（SQuaRE）−評価プロセス，対応国際規格：ISO/IEC 25040:2011，Systems and
software engineering−Systems and software Quality Requirements and Evaluation (SQuaRE)−
Evaluation process（IDT）に置き換わった。
[26] ISO/IEC 14598-4:1999，Software engineering−Product evaluation−Part 4: Process for acquirers
注記 ISO/IEC 14598-4は廃止され，JIS X 25040:2014 システム及びソフトウェア製品の品質要求
及び評価（SQuaRE）−評価プロセス，対応国際規格：ISO/IEC 25040:2011，Systems and software
engineering−Systems and software Quality Requirements and Evaluation (SQuaRE)−Evaluation
process（IDT）に置き換わった。
[27] JIS X 0133-5:1999 ソフトウェア製品の評価−第5部：評価者のプロセス
注記 対応国際規格：ISO/IEC 14598-5:1998，Information technology−Software product evaluation−Part
5: Process for evaluators（IDT）
[28] JIS X 0133-6:2002 ソフトウェア製品の評価−第6部：評価モジュールの文書化
注記 対応国際規格：ISO/IEC 14598-6:2001，Software engineering−Product evaluation−Part 6:
Documentation of evaluation modules（IDT）
[29] JIS X 0170:2013 システムライフサイクルプロセス
注記 対応国際規格：ISO/IEC 15288:2008，Systems and software engineering−System life cycle
processes（IDT）
[30] JIS X 0171:2014 システム及びソフトウェア技術−ライフサイクルにおいて生成する情報の内容（ド
キュメンテーション）
注記 対応国際規格：ISO/IEC/IEEE 15289:2011，Systems and software engineering−Content of
life-cycle information products (documentation)（IDT）
[31] ISO/IEC 18019:2004，Software and system engineering−Guidelines for the design and preparation of user
documentation for application software
注記 ISO/IEC 18019:2004は廃止され，その内容はこの規格に含まれている。
[32] JIS Z 8221-2:2006 機器・装置用図記号の基本原則−第2部：矢印の形及び使用方法
注記 対応国際規格：ISO 80416-2:2001，Basic principles for graphical symbols for use on equipment−
Part 2: Form and use of arrows（IDT）
[33] IEEE 1063-2001，IEEE standard for software user documentation
[34] Barker, T. T. Writing Software Documentation: A Task-Oriented Approach, 2nd ed. New York: Longman, 2002
[35] Barnum, C. M. Usability Testing and Research. New York: Longman, 2002
[36] Bias, R. G., and Mayhew, D. J. Cost-Justifying Usability, Second Edition: An Update for the Internet Age, 2nd
ed. San Francisco: Morgan Kaufmann, 2005
[37] Dicks, R. S. Management Principles and Practices for Technical Communicators. New York: Longman, 2004
[38] Farkas, D. K., and Farkas, J. B. Principles of Web Design. New York: Longman, 2002
[39] Hackos, J. T., and Redish, J. C. User and Task Analysis for Interface Design. New York: John Wiley & Sons,
1998
[40] Hackos, J. T., and Stevens, D. M. Standards for Online Communication: Publishing Information for the
Internet/World Wide Web/Help Systems/Corporate Internets. New York: John Wiley & Sons, 1997
136
X 0153：2015 (ISO/IEC 26514：2008)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
[41] Hackos, J. T. Managing Your Documentation Projects. New York: John Wiley & Sons, 1994
[42] Hargis,4 G., et al. Developing Quality Technical Information. Upper Saddle River: Pearson Education, 2004
[43] Kostelnick, C., and Roberts, D. D. Designing Visual Language: Strategies for Professional Communicators.
New York: Longman, 1997
[44] Nielsen, J., and Loranger, H. Prioritizing Web Usability. Indianapolis: New Riders Press, 2006
[45] Rockley, A. Managing Enterprise Content: A Unified Content Strategy. Indianapolis: New Riders Press, 2003
[46] Schriver, K. A. Dynamics in Document Design: Creating Texts for Users. New York: John Wiley & Sons, 1994
[47] Section 508 of the US Rehabilitation Act, http://www.section508.gov/
[48] Tufte, E. The Visual Display of Quantitative Information. Cheshire, CT: Graphics Press, 1983
[49] Wheildon, C. Type & Layout: Are You Communicating or Just Making Pretty Shapes? 2nd ed. Mentone,
Australia: The Worsley Press, 2005
[50] JIS X 25012:2013 ソフトウェア製品の品質要求及び評価（SQuaRE）−データ品質モデル