CIFの改訂
CIF(Common Industry Format for Usability Test Reports)はANSI規格(ANSI NCITS 354-2001)となった後、ISO規格(ISO25062)となってまだ日が浅いのだが、以前からNISTにおけるミーティングで、ハードウェアについての扱い、形成的評価への拡張など、その将来的な拡張が議論されており、さっそく改訂のための話し合いが行われることとなった。
CIFをISO化する議論では、TC159(人間工学)SC4とJTC1(ソフトウェア)SC7のどちらで規格化するかが問題となったが、結局成立までの期間が短くて済むからという理由でJTC1で規格化された経緯がある。そのため、改訂のための議論は、両組織の合同という形でおこなわれることになり、2006年8月24日と25日、GaithersburgのNISTでSC4/WG6の会合に引き続いて実施された。
そもそもCIFは1998年に産業界から調達におけるユーザビリティの規格化についてNISTに対して要請があり、その検討が始まった。その目標はソフトウェアのユーザビリティをもっと分かりやすく表現することにあった。産業界からはApple, AT&T, Bellcore, Boeing, Compaq, Dell, GE, HP, IBM, Intel, Lockheed Martin, Microsoft, Motorola, Oki, Philips, Samsung, SAP, Siemens, Sun Microsystems TI, Xeroxなど、ICTを代表する企業が多数参加した。国としても欧州から16ヶ国、極東から10ヶ国、その他中近東、オセアニアなどからも参加があり、当初からアメリカにおける国内規格というよりは国際規格という性格付けをもっていたといえる。
審議はThomas Geisを座長としてTC159メンバー(主にSC4/WG6のメンバー)とJTC1のメンバーの合同によって行われることになった。
最初、どのような議論をすべきか、その項目だしの作業が行われた。Thomasのキビキビした司会のもと、作業は順調に進行し、第一回目のミーティングでは次のような項目が審議された。
- Purpose of the documents to be produced
- Questions related to the scope of work of TC159/SC4-JTC1/SC7/JWG1
- Tasks to be supported by our “work products”
- Definitions related to the term “Requirement”
- Terms and definitions
- Agenda for the second day of the first meeting and how to proceed after the first meeting
- Mid-term planning
この中で、たとえば項番4では、IEEE610-12:1990, ISO9000:2000, ISO9241-110, DATech, ISO/IEC Directive Part 2 Clause 3.12.1, ISO/IEC 25000, ISO9241-11, ISO/IEC15288などが参考として持ち出され、侃々諤々の議論となった。
さらに、改訂CIFの利用者としては、business analysts, corporate purchasers, developers, managers, product managers, requirement developers, suppliers, usability professionalsなどがリストアップされ、それに加えて、editors of magazines, marketing professionals, quality managers, retail shop owners, union representativesなども考えられた。
関連する規格としては、ISO9241-13,14, IEEE610-12, EN60601, ISO13407, ISO17024, ETSI on icons, ISO25062, ISO20282-2,3,4, ISO25024, ISO25030, ISO9241-304, ISO9241-306, ISO9241-4xx, ISO9241-11, ISO9241-110などが列挙された。
最後に今後議論すべき内容として整理されたことには以下のようなものがある。
- Context of use for our documents
- Who are the intended users of our documents?
- Which types of situations do we want to cover? (e.g. purchasing a product, vs. defining a product, vs. long term monitoring)
- Which types of “work products (e.g. context data vs. requirements) as part of the lifecycle of a product doe we feel to be CIFfed?
- Which reader group would read which documents?
- Other standards
- Which standards are potentially relevant to our work (e.g. do serve valuable input to our work, or are “competitive”)?
- WHere is overlap between our standards to be developed and existing standards?
- Scope issues
- What will be the actual scope talking about that we put down in our documents?
- Do we need to go beyond the scope of testing?
- Which types of requirements are we going to classify?
- Do we explicitly want to include issues about diversity, accessibility, internationalization?
- How wide do we want the scope of products to be? (e.g. software and hardware as defined by the terms “interactive system” vs. “consumer products” vs. “office products” vs. “defense capability”)
- Are we defining a set of useful (usability related) templates or are we going to define a set of useful “usability reports”?
- Do we need to go into greater detail then the scope of measuing effectiveness, efficiency and satisfaction?
- Does our scope include safely as an attribute? Also do we include safety-critical systems?
- Does the scope include requirements for product attributes?
- Are we going to provide guidance on “how to generate” the data/information?
- Is the process of developing requirements part of our scope?
- Are the meta data currently sufficiently defined in the existing CIF?
- Must our scope include additional characteristics and/or sub characteristics of effectiveness, efficiency and satisfaction?
- Understandability of our documents
- How do we ensure the understandability and distinguishability of the formats for the intended user groups, especially regarding the “executive summary”?
- Risk management for our documents
- Do we need a set of clear definitions as part of our work?
- Do we have a common understanding of the term “requirement”?
- How de we ensure that any format we are supplying supports comaprability across products suffciently?
- How do we ensure that documents are not perceived as “static” but also can be dynamic in terms of “suitble for serving a database”, e.g. being implemented in requirements management systems?
- Do we have to reflect the “maturity of requirements” (new vs. approved, validated, vs. changed vs. probably changes”?
- How do we ensure the validity of context data (inteded context data vs. actual context data)?
- What whould be quality criteria for “well/formulated” usability requirements?
いささか長い引用ではあったが、ここにはrisk management, accessibility, lifecycle, longterm monitoringなど、ユーザビリティに関連して議論されるべき話題がほとんどすべて網羅されている。こうした結果になったのは、前日までのISO13407の議論で十分煮え切らなかった参加者の気持ちがここにきて爆発したからとも考えられる。ともかく、こうしたことから想像されるように、この議論は現在のCIFのスコープを遙かに逸脱したものとなっており、むしろISO13407と同じく、ユーザビリティに関連したすべての設計プロセスを対象にしようとしていると言っていい。いいかえれば、この方向性が維持されるなら、これから改訂されるCIFは、単なる評価に関する報告書ではなく、人間中心設計が適切に行われたかどうかを確認するための文書規格となる可能性があり、ユーザビリティにおけるISO9000のような位置づけとなることも考えられる。
今後は2007年1月にパリで、2007年5月にロシアで議論が継続される予定になっているが、なかなかに目の離せない動きとなってきた。