Comments
Description
Transcript
JIS Q 20000原案に対するパブリックコメントに寄せられたご意見の概要
JIS Q 20000原案に対するパブリックコメントに寄せられたご意見の概要及びご意見に対する対応 No. 項番/行 ご意見の概要 ご意見の内容及び理由 件数 ご意見に対する対応 <1>全般（第1部・第2部） <1-1>全般（第1部・第2部）・用語 1 全般 50件 片仮名表記については、JIS作成に関する規格で ①ISO/IEC 20000ではITILで使用されている用語が ①ISO/IEC20000はITILをベースとして作られた規格であ 多く使われており、こうした用語はITILの用語にあわ り、その中には多くのITILで使用されている用語が使われ （各用語に あるJIS Z 8301により、JISでは外来語をできる限り ています。そのJIS化にあたっては、これまで共通化されて 対するコメ 避けるという要求事項があるため、今回のJIS化で せるべきである。 いなかったIT業界の用語が、現在ITILの普及によって急激 ントも含 も、できる限り片仮名表記を避けた経緯がありま む） す。特に、他のJIS規格と整合をとる必要性から、用 ②片仮名用語は既に普及しており、わかりやすさの に共通化されてきているため、日本国内で広がっている ITILの用語（itSMF Japanによる翻訳された用語、言葉）を 語検討の際にも他のJIS規格の用語を参考にして 点からも英語表記に対応する片仮名表記を採用す 活かして欲しいと考えております。そのようにすることが、 おります。 べきである。 ITIL/ ISO20000/ JIS Q 20000に以前より取り組んでいる また用語に関しては、特に認証審査に使用される 人、これから活用していく人達の混乱が避けられ、より普及 可能性のある規格は、認証審査を実施する審査員 していく手助けになっていきます。 の誤解が生じさせないという配慮からも、既存規格 ②規格の表現は、わかりやすく、簡素で発音しやすく、規 で使用している用語との整合性を重視いたしまし 格原本(英語版)との対応がわかりやすいものにすべきであ た。 る。この規格が、活用され、日本におけるITサービスの適正 その他、詳細につきましては、「2.箇条別」をご参照 なマネジメント、品質向上等に寄与させるためである。した ください。 がって、2つの名詞を連結するような不自然かつ発音しにく いもの（例 容量･能力、運営管理）は絶対に避けたい。情 報技術サービスは「ITサービス」と呼びたい。カタカナ用語 がすでに普及し、英語表記に対応するものは、それを採用 すべきである。(例：ビジネス、コントロール、プロバイダ、サ プライヤ、インプリメント) 英語の同一の単語を、別の訳語 にすべきではない。（例：Identify）。 2 *20000-1 "business"を「顧客」と訳している箇所について、「事 7.2表題「顧客関係管理」を始めとして、”business”を 7.2表題 「顧客」としている箇所があります。しかし、こうした” 業」とすべきである。 7.2-5行目 business”は「顧客」とは特定できないため、「事業」と 7.3-P12の 表現した方がいいと考えられます。 下から5行 目 8.2-目的 8.2-4行目 8.3-目的 10.1-5行 目 7件 この規格では、”customer”と”business”が混在して おり、また、場所によっては”business”が「顧客」を 示す意味で使用されています。特に、20000-2 7.1 では図2とで、7.1本文では“customer”となっている のに対し、図2だけが”business”となっており、整合 がとられていないといった箇所も見受けられます。 そのため、”business”については大きな議論とな り、結果として、文脈によって「事業」と「顧客」とに 訳し分けることとしました。ご指摘の箇所は、検討 の結果、文脈から「顧客」を指していると判断いたし ております。 ※ 20000-1 6.3 3行目「顧客の事業計画」につきま しては、プロバイダ側の事業計画を含むものとは思 えませんが、目的のところで「顧客に対する」として いるので、コメントの趣旨を受けて「事業計画」とい たしました（No. 21参照）。 JIS Q 20000原案に対するパブリックコメントに寄せられたご意見の概要及びご意見に対する対応 No. 3 項番/行 *20000-1 1-1行目 1c) 6.4表題 6.4a) 他 ご意見の概要 ご意見の内容及び理由 （1）「情報技術サービス」を「ITサービス」にすべきで （1）①呼びやすい用語にすべきである。 ②ICT=ITであり、情報通信技術の意味に解した ある。 い。「情報技術」だと 狭い意味の誤解を生む。 （2）英文原文に"IT"とある箇所について、ITが訳出 されていないようですが、「IT」を訳出すべきである。 （2）①原典には、はっきりとＩＴの言葉が挿入されてい るので、矛盾と混乱を生じることと思わざるを得ない。 例： 20000-1 1c) 6.4表題 考え方には汎用性ある幅を持たせることも必要とは考 サービス → ITサービス えますが、次回、英文を更新する際には、考慮すべき 20000-1 6.4a) 内容とは思います。私見としましては、ＩＴで大方の 情報資産 → IT資産 サービスを提供していますので、逆にＩＴを削除する 考え方もあります。方針を決める大事な表現です。次 頁も同じです。本来のＩＴは、情報通信技術を指すも のですが、ＩＴが先行した経緯があり、例えばＩＣＴとか があります。 ②6.4a)の『IT』という用語はすでに一般化しているの でそのまま用いた方がわかりやすい表現であると考え られます。また、日本語に訳するのであれば『情報技 術資産』になるので『情報資産』とは持つ意味合いが 変わってくると思われます。 件数 4件 ご意見に対する対応 本規格の英文原文では「サービス（service）」、「IT サービス（IT service）」の両方を使用されています が、一方で本規格の「サービス（service）」は，実質 として「ITサービス」を指していると考えられます。 その点について英文原文では明確ではありませ ん。 JIS原案では、利用者の誤解・混乱を避けるという 趣旨から、この規格にある「サービス」は「ITサービ ス」であるとの理解の下，適用範囲で「情報技術 サービス」と明記し、他は英文原文の「ITサービス （IT service）」もすべて「サービス」と統一することと いたしました。 また、20000-1 6.4a)で"IT"が使用されているが、 原文は"IT assets"であり、ITサービスとは議論が違 うため、ここは「情報資産」といたしました(20000-2 の9.1.1も同様)。 <1-2>全般（第1部・第2部）・その他 4 4.3、9.1 補足説明を追加するために、本文に注記を追加す 原案では内容が明確でないため、補足説明が必要 5、5b),d)5 べきである。 である。 6.1、 6.2a),c) 7.3、9.1 7.3、6.6 15件 規格本文ではなく、規格に添付される「解説」部分 で言及することを検討いたします。 5 全体 各章にある目的の表記「目的：・・・ため」の「ため」を シンプルに表記すべき。 「ため」がなくても、意味は （各章の目 削除すべきである。 通じる。 的） 1件 27001、27002にこれと同じ表記が使用されており、 これらの規格と整合をとっているため、原案のまま といたします。 JIS Q 20000原案に対するパブリックコメントに寄せられたご意見の概要及びご意見に対する対応 No. 項番/行 ご意見該当箇所 ご意見箇所の修正案 ご意見の内容及び理由 件数 ご意見に対する対応 英語「Identify」は「特定する」の共通訳で、統一すべ きである。Clarifyは明確化するの訳でもよい。 1件 JIS Q 9001に同様の文言があり、整合をとっている ため、原案のままといたします。 原案では，書式や画面を変更要求と捉えているように 読み取られるおそれがあるため。複数の要員が変更 要求を見ても一意に解釈できるような仕組みや手段 をもつことが望ましいと考える。 1件 要求そのものではなく、要求が記載されている画 面や文書などのことを指していると考えられるた め、原案のままといたします。 <2>箇条別（第1部） 序文 6 序文 6行目 明確にし 特定し 2 用語及び定義 7 2.11 サービス又はインフラ 詳細を記録するために用い ストラクチャの構成品目 る書式又は画面によってな を変更する要求の詳細 される，サービス又はインフ を記録するために用い ラストラクチャの構成品目を る，書式又は画面。 変更する要求。 3 マネジメントシステム要求事項 8 3.1 目的 「経営陣は、～提供す 「トップまたは経営陣は、～ トップは経営陣の一角には違いませんが、ＩＳＭＳで るため」 提供するため」に修正すべ 経営陣の表現で、現場は混乱した経緯が相当数あり きでは。 ます。次回、英文を更新する際には、考慮すべき内 容とは思いますが。 1件 原文の"top/executive management"は、直訳する と「トップマネジメント／経営管理者」であり、一般に 執行役のうちでも上位にあたるCEOなどを指すと 思われます。しかし、対応国際規格では”CEO”と いうような明確な表現をとっていないこと、また、3.1 の表題が「経営陣の責任（management responsibility）」であることを考慮し、「経営陣」とい たしました。原案のままといたします。 9 3.1e) 運営管理 1件 規格に添付される「解説」部分で言及することを検 討いたします。 10 3.1 g) 適切であり、妥当であり 似つかわしく、適切であり、 suitable,adequateは それぞれ的確に訳すべきであ る。 1件 現在の訳語でも著しく妥当性を欠いてはいないと 思われるため、原案のままといたします。 サービスマネジメント ISO20000は大きく3つの機能で構成されると考えられ ます。①サービスマネジメント（3～5章）、②サービス デリバリ（6～7章）③サービスサポート（8章以降） 本文は経営陣の責任についての要求事項であり、経 営陣はその責務から全体をみる必要があります。ここ で求められているリソースの決定は前述の①～③全 体を指すことは明らかでありますが、原文ではサービ スデリバリ及びサービスマネジメントとしか表記されて いません。 本文においては、翻訳は『サービスマネジメント』と し、読者の理解を促すために「これにサービスサポー トを含む、マネジメントシステム全体についてをさす」 といった注記を追加した方がよいと考えられます。 もしくは、JIS原案のままとするとしても、上記のような 注記を追加したほうがいいと考えられます。 JIS Q 20000原案に対するパブリックコメントに寄せられたご意見の概要及びご意見に対する対応 No. 項番/行 ご意見該当箇所 ご意見箇所の修正案 ご意見の内容及び理由 件数 ご意見に対する対応 compatible withは意味的に このように訳すべきであ る。「両立する」では判らない。 1件 「整合しなければならない」は、主体が明記されて いない原文に合わせると、“整合の取れた状態に なっていなければならない”ということだと考えられ ます。「整合の取れた状態」とは「両立」であると考 えられるため、原案のままといたします。 4 サービスマネジメントの計画立案及び導入 11 4.1 両立できなければなら 整合していなければ 下から2行 ない 目 12 4.2e) 「e) ～要員の継続～」 「 e) ～要員の継続性～」に 原典では、～ continuity として表現をしています。 修正すべきでは。 1件 「性」を付加すると曖昧さが増すため、「継続」としま した。原案のままといたします。 13 4.4.2 アセスメント 『記録する』を『レコードする』と表現しないのと同様 に、読者が容易に理解できるように『評価する』とした 方がよいと考えられます。 1件 他のJIS規格（27001等）との整合をとるため、「アセ スメント（を行う）」としております。 評価 5 新規サービス又はサービス変更の計画立案及び導入 14 5 7行目 管理 運営管理 JIS原案では『management』を『運営管理』と訳してい るので、この箇所についても統一すべきだと考えられ ます。 1件 原案では、マネジメントシステムを構築することまで 含まれている場合は、JIS Q 9001、JIS Q 27001に 合わせて「運営管理」とし、それ以外は「管理」とし ております。この箇所は、上記の前者に当てはまる とことから、「運営管理」といたします。 15 5g) 尺度 指標 ISO/IEC20000翻訳では『指標』と訳されているのにた いして、JIS原案では『尺度』となっていますが、『尺 度』ではどうしても長さを測定するというイメージが強 いため、『指標』とした方が原文『measures』が示して いるITサービスの各プロセスあらゆる目標を対象とし ていることが理解しやすいと考えられます。 1件 「指標」と訳すと、この規格の中で何かしらかの基 準が指標として定義されている、もしくは規定され ていると誤解が生じる可能性があります。「手段」、 「測定値」という案もありましたが、こうした様々な案 を検討の結果、この箇所では「尺度」が適切という 判断に基づいているため、原案のままといたしま す。 16 5 サービス提供者によっ サービスプロバイダの承認 下から5行 て受け入れられなけれ を得なければならない。 目 ばならない。 『サービス提供者によって受け入れられる』という表現 は非常に漠然としており、具体的にどのようなことであ るかと考えると、ISO/IEC20000翻訳にあるように 『サービスプロバイダの承諾を得ること』であります。 JIS原案ではサービスププロバイダによる認可を『承 認』と表現しているので、本文は『サービスプロバイダ の承認を得なければならない』とした方が理解しやす いと考えられます。 1件 本来は、受入れ基準を満たさなければならないと いう意味だと考えられるため、原案のままといたしま す。 提供できるサービスの 提供できるサービスの全範 『上限から下限までの幅』という表現は自然ではなく、 上限から下限までの幅 囲 ISO/IEC20000翻訳の表現で簡潔に伝わるので、『提 供できるサービスの全範囲』とした方がよいと考えら れます。 1件 「提供できるサービスの全範囲」といたします。 6 サービス提供プロセス 17 6.1 2行目 JIS Q 20000原案に対するパブリックコメントに寄せられたご意見の概要及びご意見に対する対応 No. 18 項番/行 ご意見該当箇所 ご意見箇所の修正案 ご意見の内容及び理由 6.1 SLAを、変更管理プロ SLAを、変更管理プロセスの JIS原案では『contorol』を『管理』と訳しているので、こ 7行目 セスの下に置かなけれ 管理下に置かなければなら の箇所についても統一して『変更管理プロセスの管 理下に置かなければならない』とすることで、より要求 ない。 ばならない。 事項が明確に表現されます。 件数 1件 ご意見に対する対応 「変更管理プロセスの下」でも違和感はなく、むしろ controlを訳出すると冗長となるため原案のままとい たします。 19 6.2 目的 十分な情報に基づい た意思決定及び効果 的な伝達のための，合 意に基づく，適時の， 信頼できる，正確な報 告書を作成するため。 合意に基づく，適時の，信 頼できる，正確な報告書を 作成することで，十分な情 報に基づいた意思決定及 び効果的な伝達を行うた め。 報告の要件（合意に基づく～）と報告の効果（意思決 定と伝達）を区別するため。原案では，「～ため」が２ 度使われており，要件と効果が識別しづらい。 1件 英文では最初に、”To produce ~ reports”となって おり、一義的にはこれをよりフォーカスした訳文とし たいと考えるが、修正案では、この点では原案より も弱い表現になっていると思われることから、原案 のままといたします。 20 6.3 全体 「サービス継続」ではなく、 （1）ISO/IEC20000翻訳では「サービス継続性及び可 「サービス継続性」と表記す 用性管理」となっています。また、ここの章では継続 る。 性と可用性２つの観点からの管理を要求されており、 そのことが明示的であるため「継続性」と「可用性」を 並列で表現した方が理解しやすいと考えられます。 2件 「性」を付加すると曖昧さが増すため、「継続」としま した。原案のままといたします。 （2）ITIL日本語訳との整合性を確保するため。 21 6.3 3行目 顧客の事業計画 事業計画 ISO/IEC20000原文においては『business plans』と なっており、その翻訳においても『事業計画』と訳され ています。また、ここで可用性及びサービス継続性に 関する要求事項を特定するのに顧客の事業計画も 重要ではありますが、サービスプロバイダ自身の事業 計画も重要であるため、『顧客の事業計画』と特定す ることはできません。また、サービスプロバイダが把握 できる顧客の事業計画には限度があることが容易に 想定され、そのような観点からも顧客の事業計画に特 定することは困難です。以上より、本規定においては 『事業計画』という表現に留まるほうがよいと考えられ ます。 1件 プロバイダ側の事業計画を含むものとは思えない が、目的のところで「顧客に対する」としているの で、明記まですることを避けたいというコメントの趣 旨を受けて「事業計画」といたします。 22 6.3 4行目 システムコンポーネント システムコンポーネント終端 ISO/IEC20000原文において『end to end』とされてい 全体の可用性 間の可用性 ることと、『response times as well as end to end availability of system components』からシステムコン ポーネントのend to endは応答時間と同様（as well as）であることから、応答時間に対応する用語としては 『システムコンポーネント終端間の可用性』とするほう が自然な使い方であり、『全体』とした場合には『全 体』がどこを示すのか非常に曖昧となるため、 ISO/IEC20000翻訳で使われているように『システムコ ンポーネント終端間の可用性』と訳したほうが理解し やすいと考えられます。 1件 終端間では一般的には意味が通じにくいことから、 意訳することといたしました。この箇所では、サービ スを使っている人からみたend-to-endであるから、 すべてを含むと考えられます。顧客における相互 間のことも含み、メールサービスを使っているサー バを置いてある場合であれば、そのサーバも含 み、顧客はそのサーバを管理することなど、そうし たことすべてが含まれるのと思われるため、システ ムコンポーネント全体の可用性といたしました。原 案のままといたします。 JIS Q 20000原案に対するパブリックコメントに寄せられたご意見の概要及びご意見に対する対応 No. 23 項番/行 ご意見該当箇所 計画にない可用性の 6.3 下から9行 喪失 目 ご意見箇所の修正案 計画外の非可用性 注記 計画外の非可用性と は、計画に含まれていない 可用性目標の不遵守（イン シデント発生による稼働率 目標の未達成など）のことを いう。 ご意見の内容及び理由 ISO/IEC20000翻訳のように『計画外の非可用性』と いう訳も、JIS原案のように『計画にない可用性の喪 失』という訳もどちらも本質をつかみづらい表現となっ ていると思います。本章で求められているのは、可用 性を測定・記録し、目標未達成の場合は目標を達成 できるように是正処置を行うこと、であるので、原文に 近い形の訳である『計画外の非可用性』に注記として 『計画外の非可用性とは、計画に含まれていない可 用性目標の不遵守（インシデント発生による稼働率目 標の未達成など）のことをいう。』を追記すると理解し やすくなると考えられます。 件数 1件 ご意見に対する対応 「非可用性」とするという案もあげられましたが、や はり一般的に意味が通じにくいということになり、現 訳を採用いたしました。原案のままといたします。 注記につきましては、規格に添付される「解説」部 分で言及することを検討いたします。 24 6.3 試験が不合格 下から2行 目 テストの失敗 注記 テストの失敗には、テ スト自体を失敗して完遂でき ないこと、及び、テスト結果 がITサービスの提供に当 たっての目標値、基準に満 たないことをさす。 ISO/IEC20000原文では『test failures』となっており、 そのままの訳、『テストの失敗』で十分通じると思われ るため、原文からの誤認識を避けるために『テストの 失敗』と表現した方がいいと考えられます。 1件 「テスト自体を失敗して完遂できない」場合の、その ために必要な「処置計画」とは、テスト自体の変更 等を計画することを意味すると考えられます。テスト 自体の処置計画を、『サービス継続及び可用性の 管理』に対する要求事項とすることは考えられませ ん。ここは「テスト結果がITサービスの提供に当 たっての目標値、基準を満たさない」場合の、その 際に必要となる『サービス継続及び可用性の管理』 に対する処置計画であり、これを要求事項としてい ると考えるのが妥当である。したがって本箇所は原 案のまま『試験が不合格』といたします。 25 6.4 表題 2件 budgeting、 accounting、chargingは、いずれも予算 業務、会計業務、課金業務としました。特に、 budgetingは予算を立てることを含んでおり、立てた 予算を管理することではないと考えられることから、 原案のままといたします。 1件 27001との整合をとるため、「容量・能力」管理とい たしました。原案のままといたします。 サービスの予算業務及 （1）ITサービスの予算管理 （1）「予算」という単語は「あらかじめ計算して予定して び会計業務 及び会計 おく費用（大辞林 第二版）」のことを指し示しており、 「会計」という単語は「個人や企業などの経済活動状 （2）ITサービスの予算業務 況を、一定の計算方法で記録し、情報化すること（大 及び会計 辞林 第二版）」をいいます。「予算業務」では費用に ついてのなんらかの業務であることはわかりますが管 理であることまでは明示的ではありません。 ISO/IEC20000のこの章において求められているのは ITサービスの金銭面の管理についてですので、「IT サービス予算管理及び会計」ないしは「ITサービス予 算管理及び会計管理」とするのが理解しやすい表現 であると考えられます。 （2）シンプルに表記すべき。 「業務」がなくても意味 は十分通じる。 26 6.5 「容量・能力管理」 「能力管理」 キャパシティの和訳として、容量も含めて能力だと考 えられる。 JIS Q 20000原案に対するパブリックコメントに寄せられたご意見の概要及びご意見に対する対応 No. 27 項番/行 ご意見該当箇所 6.5 b) 明確な ご意見箇所の修正案 特定された ご意見の内容及び理由 英語「Identify」は「特定する」の共通訳で、統一すべ きである。Clarifyは明確化するの訳でもよい。 件数 1件 ご意見に対する対応 この箇所のidentifiedは、time-scales, thresholds and costs全体にかかっていると解釈いたしました。 identifiedに対する訳語として、一般に「特定され た」を当てること自体は問題ではありませんが、本 箇所に関しては、「特定された期間」「特定されたし きい値」「特定された費用」ということになります。日 本語訳としては硬ささを残していると思われ、「明確 な期間」「明確なしきい値」「明確な費用」と解釈で きる「明確な」を採用いたしました。 28 6.5b) 更新 ISO/IEC20000では『upgrade』という単語を用いてい ますが、サービスを上昇させることは、サービスを更新 させることではありますが、拡張（大きくする）こととは 同じにはならないと考えられます。例えば、サービス の品質を向上させるためにサービス規模を縮小する ことは、サービスの更新ではありますが、拡張ではあり ません。以上より、本文においてはISO/IEC20000翻 訳に使用されている『更新』という用語を使った方が ご認識が避けられると考えられます。 1件 この"upgrade"は、更新ではなく、サービス機能・能 力等の向上のことを意味していると思われるため、 原案のままといたします。 29 6.6 セキュリティインシデン 情報セキュリティインシデン JIS Q27001にあわせたほうがよい 下から6行 ト ト 目 下から3行 目 1件 6.6章全体が情報セキュリティを扱っていること、 20000-2の対応する項（6.6）では「情報セキュリティ インシデント」と表現していることを鑑みて、このセ キュリティインシデントは「情報セキュリティインシデ ント」と同一と思われます。ご指摘の箇所は「情報 セキュリティインシデント」といたします。 ISO/IEC20000原文においては『Subcontracted Supplier』となっていることと、『再請負契約先供給者』 とすると再契約が委任契約であれば管理不要である かのように理解されやすく、本プロセスの目的として は再契約先サプライヤもきちんと管理してサービスの 質を高めるところにある、というところからずれてしまっ ている。このため『再契約先サプライヤ』とした方がい いと考えられる。 ただし、本規定を日本国内にあわせた形で提供する ために、再契約先サプライヤの管理は請負契約のみ を対象とするとのことであれば、注記として『再契約先 サプライヤとは、請負契約を締結しているサプライヤ のみを対象とする』などと追記したほうがいいと考えら れる。 1件 「再契約」では、再度契約を結びなおすことになり、 ここでは違和感があるため、「再請負契約」といたし ました。原案のままといたします。 「サービスの予定通り～サー 原典では、～ transfer of service to another party と ビスの再委託を～」に修正 して表現をしています。 すべきでは。 1件 文章の前後から、サービスの提供から撤退してしま う場合のことについて言及している部分であるとい えます。原案のままといたします。 拡張 7 関係プロセス 30 7.3 図3他 再請負契約先供給者 再契約先サプライヤ （注記 再契約先サプライヤ とは、請負契約を締結して いるサプライヤのみを対象と する。） 31 7.3 「サービスの予定通り 下から4行 ～サービスの移管を 目 ～」 JIS Q 20000原案に対するパブリックコメントに寄せられたご意見の概要及びご意見に対する対応 No. 項番/行 ご意見該当箇所 ご意見箇所の修正案 ご意見の内容及び理由 件数 ご意見に対する対応 英語「Identify」は「特定する」の共通訳で、統一すべ きである。 識別でも意味は通じるが、共通訳語を使 うべきである。 1件 広辞苑によると、「特定」は、「特にそれと指定する こと」「特に定められていること」です。「識別」は「み わけること」となっています。 ここは「インシデントの原因を事前予防的に”みわ け”、分析することによって」と解釈し、「インシデン トの原因を事前予防的に”特に定め”、分析するこ とによって」ではないと判断いたしました。 8 解決プロセス 32 8.3 目的 識別し 特定し 33 8.3 7行目 予防処置は、例えば、 インシデントの発生数 及び種類の傾向を分 析した後にとることがあ る。 予防処置は、例えば、イン 予防処置は問題の分析結果から認識できる傾向に シデントの発生数及び種類 応じて実施されるため、そのことが理解しやすい文章 の傾向の分析にしたがって にしたほうがいいと思われます。 実施されたりする。 1件 修正案「予防処置は、例えば、インシデントの発生 数及び種類の傾向の分析にしたがって実施された りする。」を若干調整し、「例えば、インシデントの発 生数及び種類の傾向の分析に従って，予防処置 をとることがある。」といたします。 34 9.1 適切な構成アイテムの 適切な構成アイテムのベー ベースラインとはある時点におけるCIの状態のスナッ 下から9行 ベースラインを、稼働 スラインを、稼働環境への導 プショットであり、構成管理プロセスにおいて本文が 目 環境への導入に先 入に先立って残しておかな 規定されているのでは、変更・リリースの失敗への対 立って、決めなければ ければならない。 処、サービス継続性に対する対処などのためであり、 ならない。 ここにおいて「スナップショットと決めなければならな い」では、一体何を求めているのかわからない文章で あり、本質的に求められているのは「スナップショット を取っておくこと、残しておくこと」であるため、『適切 な構成アイテムのベースラインを、稼働環境への導入 に先立って残しておかなければならない』とした方が 理解しやすいと考えられます。 1件 「ベースライン」については、様々な案を考慮した 結果、この箇所については現訳が適切という判断 となりました。原案のままといたします。 35 9.1 ①「ディジタルの構成 下から8行 品目」 目 ②ディジタル 2件 ①「電子的な」はelectronicの訳語と取られる可能 性があるため、原案のままといたします。 ②ISO27001に合わせた表記としておりますので、 ディジタルのままといたします。 1件 「承認を得た後に点検を・・・」といたします。 1件 リリース＝成果物とは思えないため。また、JIS X 0160と整合をとっています。原案のままといたしま す。 9 制御プロセス（→統合的制御プロセス） 36 9.2 8行目 承認を得た後点検 を・・・ ①「電子的な構成品目」 ①言葉の使い方が、一般的では無い。 ②デジタル ②経済産業省名義で公開される他文書との整合性を 図るため。 承認を得た後に点検を・・・ 送り仮名を追加した。 10 リリースプロセス 37 10表題 10.1表題 ①10「リリースプロセス」 「成果物」 ②10.1「リリース管理プ 「成果物管理」 ロセス」 リリースプロセスは分かりにくい表現である。 JIS Q 20000原案に対するパブリックコメントに寄せられたご意見の概要及びご意見に対する対応 No. 38 項番/行 ご意見該当箇所 10.1 リリース管理プロセス 表題 39 40 ご意見箇所の修正案 リリース管理 ご意見の内容及び理由 他の管理プロセスと整合性を確保するため。（インシ デント管理、変更管理等は、”プロセス”という表記が ない） 件数 1件 ご意見に対する対応 この部分は、原文の通りにしています。 おそらくは原文のミスであると思われ、国際の委員 会を通じて、次期改定時での修正依頼を出しまし た。本バージョンでは原文のままといたします。 10.1 配付（広く配る，の意） 配賦（割り当てる，の意） 目的 （他、Q 20000-2、 9.1，及び 10.1） リリース対象を配送する先が特定あるいは追跡でき る場合は，配賦が適切であると考えられるため。 1件 この“はいふ”については、「配付」「配布」「配賦」 の3つを検討しました。「広く配る」の意としては「配 布」、「配賦」は割り当てるという意味で理解してい ます。したがってここでは“個々に配る”という意味 から「配付」を使用しています。原案のままといたし ます。 10.1 管理された受入れ試 下から7行 験環境 目 JIS Q9001にあわせたほうがよい 1件 本件の場合、他規格に訳を合わせることは、 acceptanceに相当する訳語をカットする合理的理 由にはならないと考えられます。原案のままといた します。 1件 同章の1行目に「この規格は、ITサービスマネジメ ントのプロセスの~」とあり、修正案の意図には賛同 します。ですが、これはISO20000全般に言えること ですが、全ての箇所で「ITサービスマネジメントの」 と規定対象を厳密に記述していないこともあって、 この種の補足的追加は最小限に抑えています。 この文の意としては、「製品アセスメントに用いるこ とは意図していない」の部分に重点が置かれてお り、前半部分の「プロセスについて規定した規格で あり」への追加補足の有効性は高くないものと考え られます。原案のままといたします。 規制の変化には，緩める場合と強める場合の両方 が考えられるため。 1件 規制強化の場合、tighter、stricter（もしくはこの類 語）などの形容を伴うのが一般的であり、 "regulation"を「規制強化」まで踏み込んで訳出す ることは、原文から判断して難しいと考えられるた め、原案のままといたします。 要件と効果，あるいは原因と理由の明確化を図るた め。 1件 修正案「費用と予算と照らして追跡することで，」を 若干修整し、「費用を予算と照らして追跡すること で，」といたします。 管理された試験環境 箇条別（第2部） 1 適用範囲 41 1 12行目 この規格は，プロセス この規格は，情報技術サー 規定対象の特定を図るため。 について規定した規格 ビスマネジメントのプロセス であり，製品アセスメン について規定した・・・ トに用いることは意図し ていない。 4 サービスマネジメントの計画立案及び導入 42 4.1.3 f) 業界の規制緩和及び 業界の規制緩和及び規制 規制 強化 6 サービス提供プロセス 43 6.4.3 5行目 費用を予算と照らして 費用と予算と照らして追跡 追跡することが，予算と することで，・・・ の差異を早期に警告 することが望ましい。 JIS Q 20000原案に対するパブリックコメントに寄せられたご意見の概要及びご意見に対する対応 No. 44 項番/行 ご意見該当箇所 ご意見箇所の修正案 未提供のサービスの費 サービスの損失額（赤字な 6.4.4 ど） 下から1行 用 目 ご意見の内容及び理由 ISO/IEC20000-2原文では『loss of service』となって おり、「loss」には損失、浪費といった意味があることか ら、また、本文では会計について実施することが推奨 される事項について言及しているので『未提供の サービスの費用』ではなく、『サービスの損失額（赤字 など）』のことを指していると考えられると思いますが、 いかがでしょうか。 件数 1件 ご意見に対する対応 この部分は、コメントでいただいている解釈以外に もいくつか考えられます。委員会WGでは全ての可 能性を検討し、現在の訳を採用しました。 原文はthe costs of low service levels or loss of serviceで、low service levelsと対になっていることも あり、原案のままといたします。 45 6.6.1 1行目 情報セキュリティは，情 情報セキュリティ管理は，情 「方針及び手順を体系にしたもの」は，章節題の「情 報，及び情報の格納， 報及び情報の格納，・・・ 報セキュリティ管理」を指すと考えられるため。 転送及び処理に関連 して使用される機器を 識別し，制御し，かつ， 保護するように設計さ れた方針及び手順を 体系にしたものである。 1件 「情報セキュリティ⇒情報セキュリティ管理」と「情 報、及び情報の格納⇒情報及び情報の格納」の2 箇所の指摘について。 ・「情報セキュリティ⇒情報セキュリティ管理」につ いて －原文に「管理」が入っていない －この文は、”Information security is the result of ～”となっており、”Information security”が”the result of ～”の”～”以降の部分の結果として得ら れるものであることを表していると解釈されます。す なわちこの一文は、”the result”を生み出す際の 「管理」に限定した言及というよりも、これらを含む 総体を指し示しているとみられます。この意味から も「情報セキュリティ」であって、「情報セキュリティ” 管理”」ではないと判断しました。 ・「情報、及び情報の格納⇒情報及び情報の格 納」について 修正案ではこの部分は「情報及び情報」となって しまうため原案のままといたします。 46 6.6.4c) 潜在的な事業影響 潜在的な事業上の影響 『潜在的な事業上の影響』としたほうが、日本語として 分かりやすいと思うので。 47 6.6.6a) 上級管理者が，情報セ 経営陣が、情報セキュリティ Q20000-1 6.6では経営陣が情報セキュリティ基本 キュリティ基本方針を 基本方針を定義し、 方針を承認するとなっているが、Q20000-2 6.6.6 a) 定義し， では上級経営者が定義となっている。 Part1および Part2で統一する必要があると思われる。 また、情報セキュリティ基本方針の定義・承認はJIS Q27001,Q27002においても定義されるが、いずれも 経営陣として記載されている。 1件 「潜在的な事業上の影響」といたします。 1件 20000-1の対応箇条（6.6）に合わせて「経営陣」と いたします。 JIS Q 20000原案に対するパブリックコメントに寄せられたご意見の概要及びご意見に対する対応 No. 項番/行 ご意見該当箇所 ご意見箇所の修正案 ご意見の内容及び理由 件数 ご意見に対する対応 1件 「初動対応」は、大規模災害などに対応するための 初期活動の意で使用される場合が多いように見受 けられます。また、「初動対応」自体は、「対応」に 付いた呼称であり、「第一線」が意味する要員やそ のチーム行動、あるいは役割の総称とはイコール ではないと考えられます。JIS原案のままといたしま す。 1件 「分析できるような様式をもって，・・・」といたしま す。 8 解決プロセス 48 8.2.1 g)下の注 記 注記 第一線とは，イン 注記 第一線とは，インシデ 呼称の例示によって，分かりやすさの向上を図るた シデントを最初に受け ントを最初に受け付けるレ め。 付けるレベルをいう。 ベルをいう。初動対応と呼 ばれることもある。 49 8.2.1 （関連情報を検索し、） 分析できるような様式をもっ 原案では，書式や画面を変更要求と捉えているように P20の12行 分析できるようなかたち て，・・・ 読み取られるおそれがあるため。複数の要員が変更 目 で，・・・ 要求を見ても一意に解釈できるような仕組みや手段 をもつことが望ましいと考える。 9 制御プロセス（→統合的制御プロセス） 「セキュリティ装置等」 コンポーネントは若干分かりにくい表現である。 1件 解説で補足いたします。 9.1.4他 「セキュリティコンポー ネント」 稼動 稼働 経済産業省名義で公開される他文書との整合性を図 るため。 1件 「稼働」といたします。 9.1.5a) 知的資産 知的財産 経済産業省名義で公開される他文書との整合性を図 るため。 1件 ここは原文がintellectual capitalとなっています。JIS WGでは当初この部分を「知的資本」と訳しました が、『「知」の「資本」』に違和感があるとの意見か ら、現在の「知的資産」にしました。知的資産をそ のまま英語にするとintellectual assets、修整案の 知的財産はintellectual propertyになります。他文 書はintellectual propertyの意味で知的財産という 言葉を使用しているものと思われます。原案のまま といたします。 50 9.1.2ｆ） 51 52