システムとソフトウェアの品質：8．品質に対応したプロセスデザイン

全文

(1)特集システムとソフトウェアの品質. 品質に対応した 8.. 応専般. プロセスデザイン. 中島毅（三菱電機（株））山田淳（（株）東芝）福住伸一（日本電気（株））組織における品質指向の開発・保守プロセスをデザイン. セスのライフサイクルや詳細なプロセスをデザイン. システム・ソフトウェアまたは運用支援サービス. 図 -1 に示すように，開発組織は一般に要求分析，. には，利用者の環境や利用目的によって異なる品質. 設計，実装，テストという段階を設けた標準開発プ. 要求がある．たとえば 24 時間無停止で運用できる. ロセスを決めて，段階ごとに品質管理およびプロジ. 程度まで信頼性を高める要求や，高齢の利用者の使. ェクト管理を行う．要求分析段階では，サブシステ. いやすさを高める要求が挙げられる．一方，1 つの. ムや機能別の品質要求分析も行い，それぞれの品質. 開発組織で，複数分野に関連した数種類のシステム. 要求の重要度と開発リスクを明確にする．. を扱う場合があり，1 つのシステムの中でも，サブ. これらに対応させて，各段階の中で，品質実現対. システムや機能別に異なる品質が求められることも. 策を設計・実装に作り込む作業や検査活動，品質測. ある．. 定・評価と品質改良を繰り返す機会を増やすように. することが，品質を作り込み，管理するために効果的である．. 1）. このため ISO/IEC 25010 にあるような品質（副）. プロセスを設計することができる．たとえば，幅広. 特性ごとの要求事項と，それらの重要度や開発のリ. い年齢層や地域，身体的特徴を持った利用者とのユ. スクの内容と大きさを分析し，サブシステムや機能. ニバーサルな対話型インタフェースや，複雑な機構. 別のリスク対策をもとに，システム開発や保守プロ. の長時間制御，高速の実時間処理など，品質要求の開発リスクが大きいサブ. システム・ソフトウェアの開発プロセスのライフサイクルプロセス例（品質要求の重要度やリスクの大きさの違うサブシステムや機能別に複数プロセスを使い分け）要求分析（+品質要求分析）フェーズ機能適合性. 性互使信セ保移対能換用頼キ守植策機効性性性ュ性性能率リ種性テ別ィ. 設計フェーズ. 実装フェーズ. テストフェーズ. 対策プロセス展開. 対策プロセス展開. 対策プロセス展開. 複数案調査試作測定評価. 評価. 評価. 評価. 計・実装・テストを反復し，複数回の測定・評価・改良を繰り返せるとよい．これには，アジャイル手法も含めイテレーいる（図 -1 ②③④）．一. 実装. テスト. 設計. システムテスト. テスト. テスト. 実装. 設計. テスト. 実装. ションプロセスが適して. テスト実装設計分析テスト実装設計分析テスト実装設計分析. … … ④ …. 評価. 評価. 分析テスト実装設計分析. -. 測定. 利用者試行β テスト測定. 過負荷テスト. 分析. -. テスト. -. テスト実装設計分析テスト実装設計. 大大大大 -. 実装. - 大大大大 … … ③ …. 実装. -. 設計. -. 設計. -. 評価. テスト. ① (品質要求の重要度や … リスクの大きさを分析） … ② …. 評価. 過負荷テスト. 測定. 利用者試行α テスト測定. 設計/ 実装レビュー測定. 設計. 小小小小小小小小. 中中中中中中中中. 利用者利用者参加レ参加ビューテスト測定測定. システムや機能は，設. 方，開発組織が品質要求の実現方法に経験を持っており，リスクが小さいサブシステムや機能は反復せずウォータフォールによる順次作業で開発することが可能であろう. 図 -1 開発プロセスのライフサイクル例情報処理 Vol.55 No.1 Jan. 2014. 51.

(2) 特集. システムとソフトウェアの品質（図 -1 ①）．. 要素の統合・検証. さらに，品質に関連施する段階やイテレー方式設計. ションに展開して割り. テスト対象の範囲が広ければ探索範囲が膨大となり網羅度を上げるテストは事実上無理．. 適格性確認テスト. 要求分析. するリスク対策を，実. 全体. 構成要素. 結合テスト. 当てる．これにより，詳細設計. プロジェクトや開発組織の中で，特徴のある. 単体. コード作成. 品質要求と開発リスクに対応できる柔軟で選. 単体テスト. テスト対象の範囲が狭ければ網羅度を上げることができる．作業並列度が高く，エラー修正コストも安い．. 図 -2 V 字モデルと網羅度の関係. 択可能な複数のプロセスを組み合わせた，標準プロセスをデザインするこ. 快感，快適を感じられるか，想定外の状況にど. とができる．. れだけ対応できるかである．原則 2：リワークによって開発に大きな影響を与える. 品質特性から考えるリスクベースの品質向上施策. 欠陥を早期に検出する. ◉◉品質向上施策立案上重要な原則. 解して割り当てることは困難で，それらが組み合わ. 品質を確保する活動は，期間とコストの壁があり. さって初めて実現できる創発的な特性である．創発. 潤沢に実施できないことが多い．そのため有限の期. 的な特性に関する欠陥は，その修正が広範囲に及ぶ. 間とコストで最大効果を持つ設計と検査の戦略が求. ため，大きなリワークを生じ，開発全体の品質・コ. められる．以下の原則は戦略立案上重要である．. スト・期間にインパクトを与えることになる．その. 原則 1：運用で重要な品質の達成を重視する. ため，開発のなるべく早期に対策を打つことが望ま. システム開発は「利用者に情報システムが果たす. しい．. 価値を届ける」ために実施する．したがって，情報. 原則 3：対象範囲が狭いところで網羅度を上げる. システムが利用者の運用環境で持つべきより重要. 検査対象の範囲が狭ければ，網羅度を上げやす. な品質の達成を優先することが望ましい．ISO/IEC. い．図 -2 に示すように V 字モデルの右のテストで. 1）. 25010. で定義する利用時品質で考えると以下のよ. セキュリティは，システムを構成する要素個々に分. は，なるべく早い段階で網羅度を上げるとよい．. うになる．. ある統合状態で実施するテストは，その統合によ. ① リスク緩和性：重大な問題を起こさないことは. って可能になる検査に集中することが望ましく，コ. 最も重要である．情報システムがもたらす可能. ーディングミスのような欠陥は単体レベルで検出す. 性のある経済，健康・安全，環境への悪影響，. る方がずっと効率がよい．システムを統合した状態. その潜在リスクを考える．. でいくら頑張ってテストをしても，コードカバレッ. ② 有効性・効率性：次に重要なのは情報システムが本来目指す目標，すなわち利用者が情報シス. ジが 50% 以下であるという報告もある．. テムを利用することに対する有効性と効率性に. ◉◉リスクベース品質向上施策の立案. 寄与できることである．. 品質向上と，開発のコスト削減および期間短縮は，. ③ 満足性・利用状況網羅性：最後に利用者の満足を得ることができる優れた実用性があり，信用，. 52. 製品の品質特性，特に性能効率性，信頼性，使用性，. 情報処理 Vol.55 No.1 Jan. 2014. 開発現場の重大なトレードオフ事項である．決まりきった方法と単一の品質目標のもとで戦略なく品質.

(3) 8. 品質に対応したプロセスデザインムを構成するサブシステムなどがある．. STEP1 主要なシナリオ／機能を列挙. STEP2：重要な品質特性を選択し品質要求を記述. STEP2 主要な品質特性を選択し，品質要求を記述. 検査対象で重視すべき品質特性を列挙し，各品質. STEP3 品質要求が満たされない場合のリスクを評価. 特性に対して測定量とその目標値を明確にする． STEP3：品質要求が満たされない場合のリスクを. STEP4 対策の基本方針を決定. 評価. STEP5 対策を選択. 以下①と②の 2 つのリスク観点について品質要求. が満たされない場合の影響を評価する．①は原則 1，. STEP6 開発プロセスの施策として具体化図 -3 リスクベースの品質向上アプローチ. ②は原則 2 に基づいている．. ① 重大さ：運用環境で問題が生じた際の重大さ向上の活動を実施していたのでは，コストと期間を. 大. 重大な事故／社会的な損失に繋がる. 掛けた割に，重大な不具合が市場に流出しかねず，. 中. 製品の価値が著しく損なわれる. それによって事業の足をすくわれることさえある．. 小. 製品の価値が少なからず損なわれる. リスクベース品質向上アプローチは，原則 1 ∼ 3 を. ② 影響度：リワークの大きさ. 用い，品質リスクを事業推進上許容できる範囲内に. 大. システム全体の設計の見直しに繋がる. 抑えるように開発プロセスを設計する方法である．. 中. サブシステム／機能ブロック間にまたがる. 図 -3 にこのアプローチの手順を示すとともに，以下手順を詳述する．図 -4 はこのアプローチの各 STEP を順に実施した例である．. 設計変更に繋がる小. 機能ブロック内にとどまる設計変更である. STEP4：対策の基本方針を決定. STEP1：主要なシナリオ／機能を列挙. STEP3 で評価したリスクの対策の基本方針を選. 検査対象となる主観点を列挙する．主観点には，. 択する．対策の基本方針は，重大さと影響度によっ. システムを利用するシナリオ，主要な機能，システ. て決定する．基本方針には後述する 3 つの方針，①. 使用性. 対策の基本方針. 現行機能仕様との追跡性の現行機能を網羅していること大（不明）検査網羅度の向上確保とレビューの徹底現行データによる運用が可検査網羅度の向上疎通テストの実施大（不明）能であること位置，数量などの表示データに誤りがないこと画面操作と表示内容が，操作員に誤操作を引き起こさないこと. テスト網羅度の向上. 大（不明）検査網羅度の向上観点レビューの導入. 中. 大. すべての表示が3秒以内で時間効率性あること. システムの状態の誤った機能正確性把握がなくかつ遅れなく（5秒以内）把握できること YY管理機能 24時間運用，可用性99.94% 障害許容性以上. STEP2. 中. 大. 大. 大. 大. 大. STEP3. 要コスト効果採否求分析. 方式設計. 詳細設計. ○. ○. ○. 採. △. ○. 採. △. ○. 採. ○ ○. △. ○. △. 採. コーディング規約の利用. ○. △. 採. 早めのV&V. 仕様調整用プロトタイピング開発. ×. ○. 採. 検査網羅度の向上. システムテスト：現行テスタによる確認. ×. ○. 採. 設計品質の向上. STEP1. 可能な対策. タイミングチャートの利用. ○. △. 採. コーディング規約の利用. ○. △. 採. 観点レビューの導入. ○. △. 採. ○. ○ ○ ○ ○. ○. 採. ○. ○. 採. ○. 早めのV&V. 擬似運用環境構築. △. ○. 採. 観点レビューの導入. △. ○. 採. 複合条件化での網羅度向上. △. ○. 採. ×. ×. 否否. 設計品質の向上. ｻｰﾊﾞ2重系採用と可用性設計. △. ○. 採. STEP4. STEP5. ○ ○. ×. 擬似運用環境の構築. ○. ○. ○. ×. 早めのV&V. ○ ○. 検査網羅度の向上内部・外部専門家のレビュー参加反復開発→性能検証早めのV&V. 検査網羅度の向上. ○. 適格性確認テスト. XX表示機能. 影響度②. 結合テスト. 機能正確性. 重大さ①. 単体テスト. 機能完全性. 品質要求. コーディング. ｼﾅﾘｵ/機能/ 重視すべきｻﾌﾞｼｽﾃﾑ品質特性. ○. ○. ○ ○ ○. ○. ○. STEP6. 図 -4 リスクベースの品質向上施策立案手順の実施例情報処理 Vol.55 No.1 Jan. 2014. 53.

(4) 特集. システムとソフトウェアの品質設計品質の向上，②検査網羅度の. ユーザビリティ. 向上， ③早めの V ＆ V（Verification. 有効さ. and Validation）があり，その中か. 効率. インタラクション設計は，ユーザビリティを支援. ら以下のように，相応しい方針を選択する．. 対話の原則. 「重大さ」が大の場合：当該品. 仕事への適合性. 質に関する欠陥の混入を防止す. ユーザの期待への一致. 自己記述性. 学習への適合性. ること，混入した欠陥を可能な. 可制御性. エラー許容度. 個人化への適合性. 情報設計は，インタラクション設計を支援. 限り検出すること，の両方面か. 提示情報の特性. ら活動する．それぞれ①設計品. 明瞭さ. 質の向上と②検査網羅度の向上に対応する．. 満足度. 見分けやすさ. 簡潔さ. 一貫性. 気づきやすさ. 視認性. 把握のしやすさ 4）. 図 -5 ユーザビリティ，対話の原則，提示情報の特性の関係（ISO 9241-110. を改版）. 「影響度」が大の場合：当該品質の達成をなるべく早期に確認する．③早めの V ＆ V が対応する．. ① 設計品質の向上は，欠陥の混入プロセスに適用 ② 検査網羅度の向上は，混入欠陥をどのプロセスで除去すれば効率的かを考え展開. STEP5：対策を選択対策の基本方針を実装する可能な対策を列挙する．対策にかかるコストと期待効果のトレードオフで採. ③ 早めの V ＆ V は，早いプロセスで施策を展開. 否を決める（図 -4 の例では○△×の 3 段階で評価）．. プロセスデザインの詳細. できないので，何らかの対策を選択する．以下に①. 品質に対応したプロセスデザインに関して，要求. ∼③の基本方針に対する可能な対策の例を示す．. 分析，アーキテクチャ設計，V&V の 3 つの重要な. 重大さあるいは影響度が大のものを放置することは. ① 設計品質の向上：設計をしっかり実施することで，品質の向上とバラツキの抑制を図ることが. プロセスに焦点を当て，利用可能なアプローチを紹介する．. できる．対策例として，設計モデル・技法・パターンの利用，外部専門家の利用などがある．. ◉◉人間中心設計の開発プロセスへの取り込み. ② 検査網羅度の向上：ほかの検査観点に比べて，レ. いかなるシステム・ソフトウェアにおいても，そ. ビュー密度，およびテストの網羅度（観点，因子，. れらの利用者が存在する以上，製品品質はもちろん，. 水準，組合せ）を上げる．対策例として，観点レ. 利用時の品質を高めることは提供側の責務である．. ビューの導入，静的解析の利用，境界値テストの. この利用時品質は，前述のように ISO/IEC 25010. 徹底，テスト組合せ技法の利用などがある． ③ 早めの V ＆ V：検証と妥当性確認を，なるべく. 早い段階で実施する．対策例として，使い捨てプロトタイプの利用，シナリオレビューの導入，実データを利用したテストの早期化などがある．. STEP6：開発プロセスの施策として具体化 STEP5 の対策を展開し，開発プロセス. 54. 2）. ごとの. 3）. で規定されており，人間工学規格 ISO 9241-11. で. 規定されているユーザビリティの定義を含んでいる．また，ISO/IEC 25010 では，製品品質モデルを定義しているが，その中で「使用性」が取り上げられている．これは，同じく人間工学規格 ISO 9241-110. 4）. の対話の原則を参照している．さらに，ISO 924112. 5）. で，提示情報の特性が規定され，これらの規格. 施策として具体化する．施策展開のポイントは以下. は図 -5 に示すような関係になっている．. である．. ユーザビリティは，機能や価格と並び，顧客がシ. 情報処理 Vol.55 No.1 Jan. 2014.

(5) 8. 品質に対応したプロセスデザインされる必要がある．人間中心設計の計画. これらの活動の中で，特に「利. 利用者はどんな人で，どのような操作を，どのような環境で行うのか？. ユーザの要求事項にあった設計. 用状況の把握と明示」，「利用者の「利用状況」と関連させ，要件を抽出する. 利用状況の把握と明示 ①企画・計画. 要求事項に対する設計の評価 ④設計評価・品質管理. と主な対象業務の抽出」，「顧客要. ②基本設計. 求明確化」，「要求実現のための要件抽出」，「画面操作・表示イメージの具体化」であり，さらに，設. ③詳細設計・製造. 計工数に影響を与える要件を明ら. 図 -6 人間中心設計活動の相互依存性（出典：HIS2012）. ③機能に展開. 品質要求. かにし，顧客との合意形成に繋げ 7）. ることも行う．. 分解して要素に割り当て. 機能仕様. ソフトウェア構成要素. ④分解して要素に割り当て. 関係. ソフトウェア構成要素. ＋詳細設計の方針や維持発展のルール. 段階で特に重要である．設計のアウトプットとしては，「代表利用者. ユーザの要求事項の明示. ユーザの要求事項にあった設計による解決策の作成. 機能要求. 要求事項の明示」が，開発の上流. このように，開発プロセスに人ソフトウェアアーキテクチャ. 定義・インタフェース・動的振舞い・共通リソースとその利用方式. 間中心の考え方を取り込むことによって，システム・製品の利用時品質は高められると考えられる．しかし，実際にプロジェクトで適用可能とするためには，開発者が. ①構造で実現 ②詳細設計以降の設計方針として展開. この考え方をいかに負担なく適用できるようにするか，が重要とな. 図 -7 品質要求のアーキテクチャ設計への展開. 8）. ってくる．ステムやソフトウェアに求める重要な要素となってきている．しかし，ほかの品質要求と同様，ユーザ. ◉◉品質に対応したアーキテクチャ設計（AD）. ビリティに関する要求事項として明確に定義するこ. プロセス. とが難しく，しばしば開発手戻りの発生や利用時品. 品質要求の展開. 質の低下を招いてしまう．このため，工数やコスト. 品質要求の多くの部分はアーキテクチャ設計. を増加させることなくユーザビリティを向上させる. （AD）で実装される．アーキテクチャとは，構成. ために，開発の上流段階でユーザビリティに関する. 要素と，構成要素間および構成要素─環境間の関係，. 顧客要求を明確にする必要がある．. 設計と発展をガイドするルールに具体化されたシス. この課題を解決し，ユーザビリティを高める手段. テムの基本的な構造（組織）である．. の 1 つとして，図 -5 に示すそれぞれの特性や原則. 機能要求が，機能要求を分解して，構成要素に割. を捉える，人間中心設計の考えを開発プロセスに取. り当てることで実現できるのに対して，品質要求の. り込む方法がある．これは，利用者に焦点を当てて，. 実現はもっと複雑である．品質要求は次の 4 つの方. 利用者が求めるシステム・製品を開発できるように 6）. 9）. 法で展開される（図 -7）．. する考え方／手法である．図 -6 に人間中心設計. ① 構造で実現. の考えに基づいた活動を示す．この図に示すように，. ソフトウェアアーキテクチャで実現する．たとえ. 人間中心設計の考え方は 4 つの活動から構成されて. ば呼び出し関係が整理されたレイヤ構造はソフトウ. おり，それぞれが開発プロセスに組み込まれて実施. ェアの保守性を高め，適切な並列タスクの設計は効. 情報処理 Vol.55 No.1 Jan. 2014. 55.

(6) 特集. システムとソフトウェアの品質. S1 入力の確認と整理. S2 開発範囲の明確化. S3 設計方針の明確化. S4 分解と実現. アーキテクチャ設計に必要な情報を抽出（必要なら収集）する（基本機能要求，事業上の制約事項，技術的な制約事項，品質要求）開発するシステムの境界を明確にする（プラットホーム，他システム，周辺装置）（流用時）新規作成する部分，修正を行う部分を明確にする要求の実現に関する基本方針を立てる（実現方針，優先する品質要求，分解の目標粒度）要求が満足するまでBuild&Scrap，目標粒度に至るまで分解する各視点で検討しやすい品質要求が異なる【静的視点】レイヤ構造（+責務）の設計，共通ライブラリの設計 ⇒変更容易性，振舞いの設計【動的視点】タスク構造（+割り当てルール） ⇒時間効率性，信頼性，分析性，テスト容易性. 【配置的視点】物理構成への設計結果のマッピング ⇒セキュリティ，信頼性，スケーラビリティビルド構成の設計，パラメータ設定方式の設計 ⇒設置性 S5 インタフェースの設計. 外部提供インタフェースを定義する内部インタフェースを定義する（含実現機能・品質要求，例外処理ポリシー）. S6 詳細設計以降への方針展開. 下位設計で守るべき制約事項を記述する（実装方針，例外処理ポリシー，エラーメッセージ，初期化・終了方式，デバッグのためのコーディング方法，設定ファイル）. 率性を高める． ② 詳細設計以降の設計方針として展開アーキテクチャを壊さないための詳細設計ルール，例外処理のポリシー，セキュリティ要求を満たすためのコーディングルールなど，詳細設計以降の設計の進め方に対する方針として展開される． ③ 機能に展開. に AD のプロセスの一例を示し，これを用いて説明する．. S1 で，要求分析結果から AD に必要な情報を確認・整理し必要なら再獲得する．S2 で開発範囲を明確にし，S3 で AD を進める基本方針を決める．S4 が. AD の核心部である．制約事項を満足し品質要求を最大限実現するためのアーキテクチャを作り上げる. 品質要求の中には機能として実現されるものがあ. ために，静的／動的／配置的の各視点で構成要素へ. る．たとえば，セキュリティ要求がアクセス制御機. の分解を進めていく．この過程は試行錯誤的である．. 能，改ざん防止機能に，分析性要求がロギング機能. 品質要求ごとに，アーキテクチャの表現に適した視. に展開されるなどがある．. 点が異なるので，適切な視点を選択し，設計と評価. ④ 分解して要素に割り当て. を繰り返す．さらに，要求からのトレーサビリテ. 品質要求の中には，分解され機能の構成要素に割. ィ確保のため，設計したアーキテクチャがどの品質. り当てるものがある．たとえば，応答時間要求は要. 要求をどのように満足しているかを設計根拠として. 素ごとの処理時間に展開される．. 残す．複数候補から選択した場合には，品質要求に. 品質要求を実装するプロセス. 対するトレードオフ表を作成し文書化することでそ. 品質要求には，絶対満足すべきものからなるべく. の結果を残すことも必要である．. なら満たしておきたいものまで優先順位がある．そ. S5 と S6 は，AD の成果物の利用者が必要とする. れらの適切なバランスが重要である．そのため AD は，アーキテクチャ候補の作成と品質要求面からの評価を繰り返す試行錯誤のプロセスとなる．図 -8. 56. 図 -8 品質要求を実現する AD のプロセス. 情報処理 Vol.55 No.1 Jan. 2014. 9）. 情報を提供する．.

(7) 8. 品質に対応したプロセスデザイン ◉◉検証と妥当性確認のための V&V プロセス要求分析された品質特性ごとの品質要求事項やその実現への開発リスク対策項目が設計や実装で反映されているかを，レビュー・テストで確認する．結果は問題指摘や不具合として検出・測定し，許容範囲内かどうかを比較検討して検証する．検査網羅度の向上が特に重要な項目については , ① プロジェクト全体より目標基準を高くする．. ② レビューでは，レビュー密度について高い基準を明確に設定する．. 4） ISO9241-110 : Ergonomics of Human-system Interaction – Part 110 : Dialogue Principles (2006). 5） ISO 9241-12 : Ergonomic Requirements for Office Work with Visual Display Terminals（VDTs）– Part 12 : Presentation of Information (1998). 6） ISO 9241-210 : Human-centred Design for Interactive Systems (2010). 7）福住，谷川，池上：ユーザビリティ関連規格の現状と活用方法，ヒューマンインタフェースシンポジウム 2012, pp.147-152 (2012). 8）谷川，大久保，福住：ソフトウェア技術者がユーザビリティ向上に取り組む上での課題の考察∼人間中心設計プロセス支援環境の検証実験を通じて∼，ヒューマンインタフェースシンポジウム 2013，pp.167-170 (2013). 9） Lumsde, A. J. : Architecture-centric Design Method，（邦）アーキテクチャ中心設計手法（Jan. 2011）．. （2013 年 9 月 24 日受付）. ③ テストでは，テスト対象の範囲および入力値の選択の仕方，並びに組合せ網羅度について高い基準を明確に設定する．システム利用中に不具合が発生すると影響が大きい項目ついては，妥当性確認のレビュー・テストケースの網羅性を高める．このため，過負荷や例外・異常処理，入力エラー処理などが起こり得るシステム利用シナリオを増補する．また，直接操作運用す. ● 中島毅（正会員） [email protected] 三菱電機・設計システム技術センター主管技師長．早稲田大学理工学研究科修士課程修了．博士（工学）．ソフトウェア工学専門．ISO/ IEC JTC 1/SC 7/WG 6 国内・国際委員．. る利用者や保守者に加え，直接操作しないが運用の影響を受ける間接的な利用者も含めて，利用目的・利用状況などを網羅するようなシナリオも補う．層別した利用者群から各代表者を選び，テストに参加. ● 山田淳（正会員） [email protected] （株）東芝ソフトウェア技術センター主幹．大阪大学大学院工学研究科修了．ソフトウェア工学，プロセス・品質技術に従事．ISO/IEC JTC 1/SC 7/WG 6 国内・国際委員．. してもらう方法もある．参考文献 1） ISO/IEC 25010 System and Software Quality Model (2011). 2） ISO/IEC 15288 System Life Cycle Processes (2008). 3） ISO 9241-11 : Ergonomic Requirements for Office Work with Visual Display Terminals（VDTs）– Part 11 : Guidance on Usability (1998).. ● 福住伸一 [email protected] NEC 情報・ナレッジ研究所技術主幹．慶應義塾大学大学院工学研究科修士課程修了．工学博士，認定人間工学専門家．HI 学会理事． ISO TC 159/SC 4（HCI）国内委員会副主査および ISO/IEC JTC1/SC 7/ WG 28 国際セクレタリー．. 情報処理 Vol.55 No.1 Jan. 2014. 57.

(8)