＜　SaPIDのポリシー【4】人が中心になる　＞　　http://www.software-quasol.com/sapid2-0/

何をやるにも結局それを実践するのは人間です。機械ではありません。

人間は、モノゴトを徐々に習得する。やりそこなったり間違うこともある。

何を大事にしているかは人によって異なる。得手不得手がある。

認められれば前向きになりやすく、心が通わなければ後ろ向きにもなる。。。などなど人間が持つ特性に適切なアプローチが必要です。

例えばソフトウェア工学的な取り組みを行う場合、それをどのように感じるか、どのように実践に結びつけるのが良いのかは、実際にそれに取り組むメンバーやチームの特性を考慮しなければなりません。

それを実現させるために、SaPIDでは”人間の行動特性”を考慮したアプローチを随所に採用しています。

このことをさらにわかりやすくするために、具体的な例を一つあげてみます。

SaPIDにはSTAGE0～3の4STAGEに、STEP0～9の10STEPがあります。

その中の「STAGE1：現状把握」は以下の3STEPで構成され、現状を明らかにします。

　STEP1：問題洗い出し・引き出し

　STEP2：事実確認・要素精査

　STEP3：問題分析・構造化

「STEP2：事実確認・要素精査」では、「文章表現7つの原則（例：事実準拠）」・「文章表現5つの禁則（例：対策型）」を活用して、「STEP1：問題洗い出し・引き出し」で提示された多くの”問題”情報から、適切な問題を明らかにしつつ、相応しい表現にあらためていきます。

（詳細は、書籍「ソフトウェアプロセス改善手法SaPID入門」P52を参照）

実は、SaPID解説やミニワークなどを受講いただいたみなさんから、この原則・禁則に対して、「これは役立つ！」「自分もこの原則・禁則を体得して適切な問題表現を書けるようになるぞ！」などプラスの反応が多いのです。

よい反応が多くてうれしい！・・・・・・っと、おやおや、ちょっと待ってください。

もし、この原則・禁則を体得したうえで問題を表現するとしたらその実践は「STEP1：問題洗い出し・引き出し」で行うということになります。

STEP1で問題を表現する前に、みなでこの原則・禁則を把握（あるいは情報共有）しておいて、適切な表現の問題だけを書けば（STEP2が必要なくなるので）効率的！ということを考える人もいました。

SaPIDのSTEP2でこの原則・禁則を活用しているのはおかしいんじゃないの？・・・・・そんな意見をお持ちの方もいるかもしれませんね。

いやいや、SaPIDではあくまでも意図的に、原則・禁則を”STEP2で（問題を表現し終えてから）”利活用することにしています。

それは”人間の行動特性”を考慮しているからです。

では、効率的と思われる段取り（原則・禁則を事前共有しSTEP1のみ）と、SaPIDが意図する段取り（STEP1・STEP2と進め、原則・禁則はSTEP2で活用）の2つがどのように異なるのかを見てみましょう。

以下に示す2つのアプローチでは、どちらがどのような結果になるでしょうか？

いや、このようにアプローチされた（問題を書こうとしている）人間が、どのように考えて行動し、どんな結果になると思いますか？

※（自分なりに考えてみてから、次を読んでください）

いかがでしょうか。

ここまで極端ではないかもしれませんが、特徴は掴んでいると思います。

アプローチ1では、それぞれのメンバーの頭の中にある情報がなかなか出てこなくなる傾向があります。

それは「原則・禁則」が心理的なストッパーの役割をしたからです。

一方アプローチ2では、「間違ってもいいよ」「自分の思った通り」「自分の言葉で」などにより心理的なストッパーを排除し、むしろ情報提供を促進するようにしています。こうやって、関係者が持つ情報（ダイヤの原石）をSTEP1でたくさん収集し、STEP2で磨いてダイヤに仕上げていきます。

これは一つの例でしかありませんが、SaPIDは、目先の効率を求めず、欲しい効果を重視して「人間の思考→行動→結果」を予測してSTEPを設計してあります。

次はISO/IEC 33063の解説、のはずでしたが、その代替案として2015.12末に開催されたコミックマーケットに頒布された「Software Testing ManiaX　Vol.10」への寄稿記事「ソフトウェアテストプロセス評価モデル微考ｗ」を掲載します。

内容的にはテストプロセスモデル3つ：TMMi、TPI NEXT、ISO/IEC 33063の比較結果を書いたものです。

寄稿記事なので、である調で記載していますのであらかじめご了承ください。

ソフトウェアテストプロセス評価モデル微考ｗ

１．はじめに

2015年3月にふと思い立ってTMMi Foundationの翻訳をはじめた。とはいえ英語力もなく使える時間も週数回昼休み30分程度で歩みは超遅い。そんな矢先、9月にソフトウェアテストプロセスのアセスメントモデルISO/IEC 33063（ISO/IEC33020が縦軸、 ISO/IEC /IEEE 29119-2ソフトウェアテストプロセスが横軸）が制定され、翌月10月にはTPI NEXTの日本語書籍が発売された。ということで、2015年は日本におけるテストプロセスアセスメント・改善の元年ではないかと勝手に決めた。

せっかくなので今回これら3モデルの特徴をざっと整理し、これらをどう使うか？について考えてみたいと思う。

２．大枠の特徴

まずはそれぞれのモデルの大枠の特徴を示す。

ISO/IEC 33063とTPI NEXTはそれぞれ取り上げたプロセス毎の能力レベルを問うContinuous（連続）モデルであるのに対し、TMMiは組織の成熟度レベルを問うStaged（段階）モデルであることが大きな違いの一つである・・・なんて、いろいろな側面で比較するのもいいかなと思ったが、今回はそれぞれのモデルが「どんな風にプロセスを提示しているのか」に注目してみたい。

３．プロセスの特徴

独断と偏見でプロセスの分類を決め、それぞれのモデルが提示しているプロセスを割り付けてみた。ここでいうプロセスとは、モデルで「プロセスエリア」とか「〇〇プロセス」と称しているものを指す。なお、1プロセスがいくつかの分類に関連する場合もあるが、主にどの分類に関連するかを（直感的に、いや、思いつきで）一分類に割り付けた。

さらに、特にそれぞれのモデルが持つ特徴的なプロセス（他モデルにはないもの、あるいは表現がユニークなもの）については“●”を付与した。

以下、それぞれのモデルが持つ特徴的なプロセス（●）を取り上げた理由を記す。

＜ISO/IEC 33063＞

●問題解決管理：他モデルではインシデント・欠陥管理が存在する中、さらに広く捉えた問題解決管理を取り上げている。

●静的分析：レビューに加え、さらに静的分析を取り上げている。

＜TMMi＞

●高度なレビュー：ピアレビューで終わらずに、さらに高度なレビューを取り上げている。

●製品品質評価・品質制御・欠陥予防：開発プロセスとテストの連携（による開発全体の効果、効率を目指すこと）を強調している。

●非機能テスト：唯一、このモデルのみ非機能テストを単独で取り上げている。

＜TPI NEXT＞

●利害関係者のコミットメント：プロセスに実効性を持たせる重要な要因を単独で取り上げている。

●テスト担当者のプロ意識：内容はエンジニアのトレーニング、スキル管理だが、インパクトある表題で取り上げている。

●報告：コミュニケーションがあるにも関わらず、あえて報告を単独で提示している。

●手法の実践：手法･様式の明文化に基づく実践をインパクトある表現で提示している。

●テストウェア管理・テストツール：他のモデルでは目立たないテストウェア管理、テストツールをあえて前面に出している。

４．活用方法

以上の特長を踏まえ、それぞれのモデルをどのように活用するのが良いのかをおさわり程度に整理してみる。

整理した結果をみて、、、いまいちな内容だと実感した。（苦笑）

５．そんでもって

　モデルの特長を把握して使いこなすことも重要だが、そんなこといちいち考えるもの面倒だし、できるだけ手間をかけずにそれぞれの良いところを全部のせしたい、というものぐさな方もいると想定している。

ということで、3モデルを解析して統合し、一度アセスメントすると3モデルそれぞれに対する結果を出力できるしくみを構築した。まだ素案であるため、近日中に手を挙げてくれた組織でトライアルアセスメントを実施する予定だ。

また、フルアセスメントによる改善アプローチは、費用、工数が膨大にかかり、その効果も詳細すぎて大事なポイントが玉虫色にもなりやすい。そこでソフトウェアプロセス改善手法SaPIDを拡張して、フルアセスメントに頼らずとも、モデルを生かして有効な改善対象を特定できる手法と、アセスメント結果とビジネスゴールとの関係性を図式化して関係者で共有し、納得しながら進めることができるも手法も合わせて開発した。これらもトライアルを回しながら精度を上げていこうと思う。

業界ではSLCP、QMS、CMMI、Automotive SPICE、ITSMS、ISMS、今回ご紹介したテストプロセスモデル群のような「プロセスモデル」「プロセス要求事項」であふれているにもかかわらず、使いこなせずに思考停止している組織やチーム、管理者・エンジニアが未だに多いのは嘆かわしい。プロセスモデルに弄ばれず、使えるところを思い切り活用して（使えないところは捨てて）成果を上げていくようにしたいものだ。

ところで・・・TMMi Foundationの翻訳っていつ終わるんだろうか。→自分（爆）

■チェックポイントとクラスタセット

TPI Nextのキーエリアには、成熟度レベル毎にチェックポイントが設定されています。（全部で157あります）

チェックポイントとは、レベル達成を判断するための指標になるもので、それぞれの判定は[Yes/No]の2段階で行われます。

※国際標準での判定方法では[None][Partially][Largely][Fully]の4段階ですので、判定が容易である一方で、達成状況だけでは詳細な把握ができない可能性もあります。（細かくやりたい人は4段階で判定すればよいだけですがねｗ）

このようにチェックポイントは、キーエリアの成熟度レベル判断の基準を示しながら、段階的に成熟度を上げていく際のロードマップを指し示してくれます。

さらに、このチェックポイントは、キーエリア内部として、そしてキーエリアを越えた「テストプロセス全体」として、どのように段階的に改善していくのがよいのかをA～Mまでの優先度として示しています。このしくみを「基本クラスタセット」と呼んでいます。

この基本クラスタは、テストプロセスを全体的に少しずつ改善していく際に活用するものです。（だから”基本”と付けているらしいです）

ビジネス主導で改善を進めようとした場合は、ビジネス主導要因に基づいて関連付くキーエリアとチェックポイントを選択します。

（これを”クラスタの修正”と呼んでいるようです）

■ユニークなキーエリア1：利害関係者のコミットメント

TMMiでは個別のプロセスエリアのSPに付与されているコミットメントですが、このモデルでは一つ目のキーエリアとして単独で切り出しています。一つ目であることは「最重要である」という意味に捉えてよいと思います。

アセスメントは下手をすると「形式チェック」になりがちですので、どのくらい本気で自らの役割や責務を認識し、実践しているかを確認する必要があります。

■ユニークなキーエリア2：コミュニケーションと報告

コミュニケーションと報告をキーエリアとして切り出し、かつ別々に扱っているのがユニークだと思います。

二つは一緒でもよさそうに感じますが、あえて別出しにしているのは、コンサルタント実績上で重要な要素と認識したからに他ならないと思われます。テストチーム内の協力体制や開発チームとの連携などを実現するのも、コミュニケーションや報告による状況把握が不可欠であるとの認識ではないでしょうか。

■ユニークなキーエリア3：テストツール

他の2モデルには存在しないのが「ツール」です。（TMMIではSPレベルまでの話です）

これもコンサルタント実績上で重要な要素と認識したからに他ならないと思われます。

特に効率化を考えるなら不可欠な要素ですよね。

■ユニークなキーエリア4：テストウェア管理

他の2モデルには単独では存在しないものです。（他の2モデルでは細かいプラクティスの中に埋没していると思います。）

テストウェアとは「テストプロセスを通じて作成される、テストの計画、設計、実行に不可欠なもの。たとえば、ドキュメント、スクリプト、入力、期待結果、セットアップとクリーンアップの処理手順、ファイル、データベース、環境、その他、テストで使用する付加的なソフトウェアやユーティリティなど（JSTQBソフトウェアテスト標準用語集（日本語版）Ver2.2.J02より）」です。

その保管、アクセス、追跡可能な状態の維持、移行、再利用などについて明確化しています。

■ユニークなキーエリア5：キーエリアに”レビュー”は存在しない

今回比較している他の2モデルとの大きな違いの一つは、キーエリアに「レビュー」が存在しないことです。

他の2モデルは（おそらく、ですが）ISTQBとの整合を意識しているためテストの中に（静的テストとして）レビューが含まれており、それを単独のプロセスとして切り出しています。

とはいえ、キーエリア「関与の度合い」や「見積と計画」の効率化レベルには”テスト容易性を把握するレビュー”が載っていますので、決して考慮されていないわけではありません。

■おわりに

いろいろと見てきましたが、テストの有効性を高める意味において、内容が非常に実務的で無駄を削ぎ落として構築されているように感じています。

いよいよ次は最後。ISO33063です。

オランダSogeti社が開発したテストプロセス改善モデルで、主に欧州で活用されているとのことです。

2015年9月20日に『TPI NEXT® ビジネス主導のテストプロセス改善』が発刊され、国内で一気に認知度が上がりました。

■基本情報

情報はここにあります。

　http://www.tmap.net/tmap-next

■モデルフレーム

テストプロセスの構成要素を「キーエリア」と呼び、それぞれのキーエリアに成熟度レベルが４段階あります。

＜成熟度レベル＞

成熟度レベルには

　　初期→コントロール→効率化→最適化

の4段階があります。しかし、初期レベルはレベル名のみで具体的な内容はありません。

つまり、具体的な内容を伴うのはコントロールレベル以降の3段階で、コントロールレベルの内容がどれも実現できていない場合は”初期レベルである”と判定されます。

初期段階からまず取り組むべきなのは、それぞれのキーエリアのコントロールレベルで定義されたチェックポイントです。

チェックポイントは、それぞれのキーエリアに期待されていることであり、Yes/Noで判定することを想定しています。

これらを確実に実践できるようになる（Yesと言える）こと＝すべてできるようになったら”コントロールレベル”の達成です。

その次は”効率化レベル”を目指し、さらにその先に”最適化レベル”が待っている、というシナリオです。

キーエリアごとに成熟度レベルが設定されている・・・・・それって（キーエリアとしての）”能力レベル”ではないのか？という個人的な疑問がありますがまだ解消されていません。

※書籍では、「各キーエリアには複数の成熟度レベルがあり、キーエリアの組合せによってテストプロセス全体の成熟度が定義できる」とあります。

＜キーエリア＞

テストプロセスの構成要素をキーエリアと呼んでいます。

全部で16あり、それぞれのキーエリアは特定のグループに属しています。

グループとは、テストプロセス構成要素の大枠の分類名で「SR：Stakeholder Relation　利害関係者との関係」「TM：Test Management　テスト管理」「TP：Test Profession　テスト業務の専門性」の3つがあります。

また、キーエリアの題名の工夫により、テストの実効性・有効性を高めるための大事なポイントをわかりやすく提示しています。

テストコンサル会社が立ち上げたモデルとのことなので、その実績から抽出されたポイントをまとめた結果なのだと思います。

プロセス、というととかく手順・手続きばかりが取り上げられがちですが、「利害関係者のコミットメント」や「関与の度合い」「コミュニケーション」「報告」「手法の実践」「テスト担当者のプロ意識」などを前面に押し出し、これが有効性を高めるために重要だ、ということを戦略的に伝えています。

■ビジネス主導（Business Driven Test Process Improvement = BDTPI）

モデルに適合させる（合わせる）ことは、対象領域を全体的に改善していく傾向を強め、明確な効果がわかりにくく、手段（モデル適合）そのものが目的化しがちです。

TPI Nextでは、ビジネス目的を達成するためのテストプロセス改善を実現するためのしかけが用意されています。

　ビジネス主導要因の特定

　→ビジネスゴールをITゴールに変換

　→ITゴールを達成するための重要なキーエリア、重要でないキーエリアの特定

　→チェックポイントクラスタ配置の再調整

モデル適合を目指す場合にも使えるようにしつつ、ビジネス目的達成を目指す場合にも使えるような”しかけ”がある。

これは、他のモデルと異なる大きな特長だと思います。

 （その２に続く）

■プロセスエリア（Process Area：PA）

プロセスエリアは以下のようになっていて、大枠で「Level番号の下から順に改善していくといいよ」というメッセージになっています。

このようにTMMiは多くの組織で使える大枠の方向性を示すものとして汎用的に構築されたものですので、どんな組織でも必ずぴったりくるものではなく、単にポイントになるコトを集約したものである（モデル、とは特徴的なところを反映し、それ以外の枝葉を省略したものです）ことに注意してください。

その割にどうしてあんなに情報量が多いのか？というと、アセスメントで適切に判断できるように詳細な情報（プロセスｰプラクティス-アクティビティ・・・事例などを含む）を載せているからなのだと思います。

■取り上げられているプロセス(1)－管理面のプロセスが多い

TMMiで取り上げられているプロセスをざっと分類してみましょう。

かなり荒っぽい分類方法ではありますが、管理面のプロセスがたくさん並んでいることがわかると思います。

現在はスピードが求められる時代、ソフトウェアの規模も大きくなり、さまざまなものと連携する場面が増えている現状からも、テスト必要なリソース･期間の提供、スキルの獲得、計画的な運営、状況把握による問題早期発見・解決、適切な判断などの的確な管理が求められることに疑問はないと思います。

一方で「利益も必要なのだからそんなにできないよ」という意見があるのも事実です。

ここで注意したいのは、沢山管理をするのだからその分だけ比例して工数も期間もかかると考える「線形思考」に陥っていないか？ということです。

本質的にLevel 4～5の組織は「難しいコト、すごいコトをさりげなくやってしまう」組織です。

そう、沢山のすごいコトを短い時間･期間、少ない手間でやってしまうほどの腕っこき組織なので、上図に記載されているような沢山のプロセスを（ツールの活用や自動化などを上手に活用することで）無駄なく、効率的に実施できるのです。

Level 1～2ではその実現は難しく、具体的にイメージが湧かないために「そんなに沢山は無理」と考えてしまう。

致し方ない面もありますが、線形思考の罠に陥らないように注意したいものです。

■取り上げられているプロセス(2)－テストから開発全体へ

TMMiはテストプロセスモデルなので、Level 2～3のほとんどは「テスト」のことを取り上げています。

しかし、Level 3の一部から4～5になるにつれて、開発プロセスとテストの連携や開発全体の最適化・効率化に向けたプロセスに移行していることを理解してください。

つまり、Level 2～3にかけては「テストが適切に、確実に実施できるようになること」が中心。

以降は「テストの技術を開発全体に活用して開発効率を上げること」にシフトします。

テストの適切な実施を継続しつつ、開発過程でレビューを活用し、テストの視点で要求や仕様、実装における欠陥を早めに検出・処置したり、過去の実績や開発過程で検出した欠陥情報から欠陥の作り込みを低減する（欠陥予防）など全体最適を目指すプロセス群で構成されています。

■TMMiのまとめ

以上のようにTMMiを見てきましたが、

・大枠ではあるがテストプロセス改善の方向性が明確である

・今回取り上げる他のモデル（TPI Nextや33063）に比べてLevel毎に取り上げられたプロセスが詳細な情報である

・組織成熟度を高めることを目的とした段階モデルであるため、個別プロセスの改善段階を詳細に把握できない場合がある

というのが特徴になると思います。

その１からの続きです。

■縦軸：成熟度レベル

TMMiの縦軸（成熟度）には下図のようにLevel1～Level5の5段階があります。

（これは組織の成熟度を示す軸であって、プロセス単位の能力レベルではないことに注意してください。）

Software-CMMの開発時に考案された成熟度ですが、大枠で以下のような意味があると思います。

（あくまでも私の理解です。本家であるSEIから見ると異なっているかもしれませんのでご注意ください）

・Level1（初期）：

管理面、モノづくり面の両面でいろいろ実践が不十分な状態。

作業は場当たり的で、人により実践方法がバラバラになっている。

プロジェクトの成功は、リーダや担当者の頑張りと経験・能力に依存してしまう。

要求を満足するソフトウェアやサービスを提供することもあるが、過少見積による予算超過、納期遅延、納品後障害などが多い。

にもかかわらず、組織としてどのような状態なのかを把握していない、改善も魔女狩りや見当違い／形式的な対策で効果が得られにくいなど、管理面が非常に弱いとも言える。

・Level2（管理された）：

Level1の状態を打開する意思を持ったチーム･組織が、その対策を実践することでLevel2に上がってくる。

（その意思もないのに形式的に真似るだけでは成果に結びつかないことに注意）

チーム内での作業方法をできる限り同じにするために必要なプロジェクト標準なども整備され、その内容に基づき運営する。

要件を管理し、計画に基づくプロジェクト運営を実践する。

監視・測定に基づき粗いながらもマイルストン時の状況が把握でき、そのタイミングでのコントロールが実践される。

現実的な見積に基づく運営になっていくため、要求を満足するソフトウェアやサービスを提供する確率が高まり、予算超過、納期遅延、納品後障害などはLevel1の状態より改善される。

ただし、これらの内容は「プロジェクト単位」のもので、組織全体で見るとプロジェクト間にバラつきが存在するのが特徴。

・Level3（確立された）：

プロジェクト毎にばらついているLevel2の状態を組織全体で統制し、組織的・系統的に実践できるようにしたのがLevel3。

体系的かつLevel2より厳密な組織標準群を立ち上げ、それをベースにそれぞれのプロジェクトを運営することで一貫性を確保する。組織標準をベースにしつつ、プロジェクトの背景や特性に適切に対応するために、テーラリング（仕立て直し）を導入するが、この内容と実践が成果を左右するカギの一つとなる。

以上のように組織的な統制を重視するが、その管理は定性的なものが中心となっている特徴がある。

※組織的に統制することがどのような成果につながるのかを明確化せずに取組み、形はあるが中身が伴わない状態に陥ることも多いので要注意。

・Level4（定量的に管理された）：

Level3では実践不足となっていた品質、プロセスの両面での”定量的な”管理が実践され、それぞれを制御するのがLevel4。

その実現を後押しするのが”計測・測定”。その実践によりモノゴトを定量的に把握することができ、先の見通し＝予測して適切な対策が打てるようになる。この手段を使ってプロセスと品質を制御する。

・Level5（最適化している）：

Level4の実践により精度を高め、漸進的（順を追って少しずつ目的を遂げる）な改善策や革新的な技術の改善策を使いこなしてさまざまな変化に対応し、機会を活かしながら、常に欲しい成果を実現しつづける状態がLevel5。

定量的な状況把握や原因分析に長け、的確な先読みによる予防処置を実践できる。

成熟度では、レベルが高まるにつれてその対象が「個人→チーム→部署→部門→組織全体」と拡大していることがわかります。→Level1～Level3までに主な対象が「個人→チーム→部署→部門→組織全体」と拡がっています。

ではLevel4以上の対象はどこなのか？というと（CMMIを構築したSEIが定めたアセスメントとしては）、Level4はLevel3までが実現できていないと”×”となっているため組織全体でLevel4と5が問われます。

(組織の成熟度を問うモデルなので当然といえば当然ですが)

しかし、それはモデルを構築した方達が決めたことであって”ねばならない”わけではありません。

成熟度がLevel1であっても問題なく成果を上げている組織もありますし、組織全体ではなく個別のチームや部署だけで定量的な管理を実践したり革新的な運営を実現してもよいわけです。

よってこの縦軸（このモデル）に沿わなければならない、とかLevel1よりLevel3が偉い！すごい！、などと画一的に考える必要はありません。

重要なことは「われわれはどうしたいのか？どうなりたいのか？」です。

公的な認証やある組織が決めた基準の下での判断を仰ぐ場合は、それぞれのルールに従うのは当然ですが、自分達がその道具を理解して独自に使いこなすことも可能です。

自分達の目的を達成するためにこのモデルが使えるなら使えばよい。使えない、効果が期待できないなら使わなければよい。

すべてを活用することが達成に役立たないなら一部の役立つところだけを使ってもよいわけです。

これはCMMI、TMMi、QMS、TPI Next、ISO29119-2(33063)などどれを取っても同じコトですのでよく覚えておいてください。

自分達で考えることを放棄し、外部基準や偉い人や組織が言うことにのみ依存するようなことにならないようにしたいものです。

1990年前後にQS（現在のQMS）やSoftwareCMMから始まったプロセスモデルのアプローチですが、現時点でさまざまなプロセスモデルが提案され、充実してきたにもかかわらず、モデルに弄ばれている組織やそれを隠してごまかしている組織が多いのがとても気になります。

さらにその正反対の状況＝「そんな高尚なことやってるヒマはない／形式だよね！」といって中身を見もせずに手も足も出さない組織やチームが多いことも事実であり、モデルの本当の意味や実践方法を理解できていないにすぎない状況もとても残念なことです。（思考を停止し、画一的な捉え方しかできない人たちが多いということですよね）

これまでのIT産業の経験則が詰まったプロセスモデルが充実してきた今、自分達の成し遂げたいことをはっきりさせ、その実現に役立つ手段を自分達で選択し、使いこなしながら進めることができるかどうかが今後ますます問われると思います。

なお、この記事は「プロセスモデル」を擁護したり、一方的によいものである、だから使うべき！ということを伝えるものではありません。ゴルフのクラブのように、道具ごとの特性を理解し、自分が使いこなせる道具の選択肢をいろいろ揃えておく、そして状況に応じて選択できるようにしておくことの大切さを伝えようとしています。

文章が下手なのでわかりにくいと思いますが、念のため。

（その３につづく）

TMMi Foundationという組織が提供しているテストプロセス改善のモデルです。

■基本情報

情報はここにあります。

　http://www.tmmi.org/

　http://www.tmmi.org/pdf/TMMi.Framework.pdf

■ISTQB用語・シラバス内容がベース

このモデルで使用されている用語は、ISTQB用語やシラバスのそれがベースになっています。

（全ての用語を精査したわけではないので”すべて”と言い切れるほどの確信はありませんが）

ISTQBテスト技術者資格をお持ちの方は、とても読みやすい、わかりやすい内容だと思います。

■CMMIのモデルフレームで記述

TMMiはCMMIのモデルフレームをそのまま活用しています。

（参考）CMMI日本語版はこちらです。

記述構造はこのようになっています。

成熟度レベル（1～5）→　プロセスエリア(目的 - 導入説明 - 範囲)　

　　　　　　　　　　→　固有ゴール＆固有プラクティス　＋　共通ゴール＆共通プラクティス

1～5の成熟度レベル（例：成熟度レベル2）があり、レベル2～5のそれぞれに複数のプロセスエリア（例：成熟度レベル2－プロセスエリア1：テスト方針・戦略　プロセスエリア2：テスト計画・・・）が割り付けられています。

そしてそれぞれのプロセスエリアに特徴的なゴール（固有ゴール）と実践事項（固有プラクティス）、共通的なゴール（共通ゴール）と実践事項（共通プラクティス）が提供されています。

また、CMMIのどのプロセスエリアをTMMiがサポートしているかの情報も付記されていますので、CMMIに慣れている方は読み解きやすく、またCMMIではテストプロセスを詳細に把握することが難しいので、TMMiを併用することでその弱点を埋めてくれることになると思います。

■段階表現と連続表現

CMMIには段階表現と連続表現があります。

段階表現とは、混乱しているならまずは成熟度レベル２に位置付けてあるプロセス群から改善してごらんよ。次にそれらができるようになったら成熟度レベル３のプロセス群に取り組み・・・・・というようにプロセス全体の中の改善優先度を「成熟度レベル」として段階的に提示しているものです。

一方、連続表現とは、プロセス全体の改善優先度を提示せずにプロセスの一つひとつに対して能力レベル1～5（レベル0は不完全な実施）を付与しているものです。プロセス全体の成熟度ではなく、個々のプロセスとしてはどのような段階を経て改善を進めるのが良いかを「能力レベル」として提示しています。

■固有ゴール＆プラクティスと共通ゴール＆プラクティス

それぞれのプロセスエリアには、固有ゴール＆プラクティスと共通ゴール＆プラクティスがあります。

「固有ゴール＆プラクティス」とは、そのプロセスエリアに特徴的なゴールとプラクティスです。

例えば、成熟度レベル2－プロセスエリア（Process Area=PA）2の「テスト計画（以降、PA2.2 テスト計画と記載します）」では以下のような固有ゴール（Specific Goal＝SG)＆プラクティス（Specific Practice＝SP)が定義されています。

---------------------------------------------------------------------

SG 1 製品リスク評価の実施
　SP 1.1 製品リスク分類とパラメータの定義
　SP 1.2 製品リスクの識別
　SP 1.3 製品リスクの分析
SG 2 テストアプローチの確立
　SP 2.1 テストすべき項目と特徴の識別
　SP 2.2 テストアプローチの定義
　SP 2.3 開始基準の定義
　SP 2.4 終了基準の定義
　SP 2.5 中断・再開基準の定義
SG 3 テスト見積の確立
　SP 3.1 上位レベルWBSの確立
　SP 3.2 テストライフサイクルの定義
　SP 3.3 テスト工数とコスト見積の決定
SG 4 テスト計画立案
　SP 4.1 テストスケジュールの確立
　SP 4.2 テスト要員の計画
　SP 4.3 利害関係者関与の計画
　SP 4.4 テスト製品リスクの識別
　SP 4.5 テスト計画の確立
SG 5 テスト計画へのコミットメント獲得
　SP 5.1 テスト計画のレビュー
　SP 5.2 作業とリソースレベルの調整
　SP 5.3 テスト計画へのコミット獲得

※SG-SPの意味＝SGを達成するためにSPが存在している

---------------------------------------------------------------------

どれもが「テスト計画」に特徴的な内容であることがわかりますね。

一方、「共通ゴール＆プラクティス」は、どのプロセスエリアであっても共通的に求められるゴールとプラクティスです。

PA2.2 テスト計画に定義されている共通ゴール（Generic Goal＝GG)＆プラクティス(Generic Practice＝GP)は以下の内容です。

---------------------------------------------------------------------

GG 2 管理されたプロセスの制度化
　GP 2.1 組織的方針の確立
　GP 2.2 プロセスの計画
　GP 2.3 リソースの提供
　GP 2.4 責務の割り当て
　GP 2.5 要員の訓練
　GP 2.6 構成を管理する
　GP 2.7 関係する利害関係者の特定と関与
　GP 2.8 プロセスの監視と制御
　GP 2.9 客観的な遵守評価
　GP 2.10 上級管理者との状態レビュー

GG 3 定義されたプロセスの制度化（TMMi level 3の適用のみ）
　GP 3.1 定義されたプロセスの確立
　GP 3.2 改善情報の収集

※GG=GPの意味＝GGを達成するためにGPが存在している

---------------------------------------------------------------------

この内容はプロセスエリアに特化したものではなく、共通的に求められる事項です。

例えば、「テスト計画」を（管理されたプロセスとして）制度化することを「GG2」として求めています。

そしてその達成には、テスト計画を実施するためのリソースの提供（GP 2.3 ）やテスト計画を立案できる要員の訓練（GP2.5）が必要になるということですが、これらは「PA2.3 テスト監視・コントロール」であっても「PA2.4 テスト設計・実行」であっても同じです。

※それぞれのプロセスエリアが関係する成熟度レベルにより割り当たるGG-GPが多少変化しますので注意してください。

■情報が詳細

記載されている内容は、成熟度レベル（1～5）→　プロセスエリア(目的 - 導入説明 - 範囲)　→　固有ゴール＆固有プラクティス　＋　共通ゴール＆共通プラクティス、そしてさらにその下には サブプラクティスや事例が示されているのでモデルの意味を理解しやすく、また実務や成果物と比較する際に判断しやすくなっています。

一方で、詳細に書かれているからこそ、文書として分厚くなり、全体を捉えるのが難しくなりがちです。

この罠にハマると、現状評価が膨大な工数と期間になってしまったり、個々の詳細記述に合わせるだけの形式的なアプローチになる、あるいは全体状況の意味を理解できないまま改善を進めてしまう（その結果、何を目指しているのか、何が効果なのか不明になる）など、モデルに弄ばれることになります。

モデルは自らの目的達成のために活用するものですので、十分に理解してから使いましょう。

→その２に続きます。

先日ソフトウェアテストのプロセス改善モデルTPI Next®の翻訳本が発行されました。

また、CMMIの構造をベースにソフトウェアテストプロセス向けに作られたTMMIや、プロセスアセスメントの国際規格ISO33000シリーズの中に、ソフトウェアテストの国際規格ISO29119-2をベースとしたISO33036があるなど、ソフトウェアテストプロセスの状態を評価し、改善につなげようとする動きが目に見えるようになってきました。

この機会に、ソフトウェアテストプロセスを評価し、改善することを目指すために提案されている”テストプロセスアセスメントモデル”を個別に紹介しようと思います。

今回取り上げるのは以下のモデルです。

　　□TMMI　　□TPI Next　　□ISO33036(ISO29119-2)

なお、これらの中ですでに日本語化されているのはTPI Nextのみです。

以外は英語情報しかありませんので、私の仮訳でご紹介します。

英語力のない私（笑）のことですから、訳文がおかしいなどの懸念もあります。

また、無計画に記述していきますので何回で終わるのか、いつ終わるかはわかりません。（笑）

予めご了承ください。

この規格はシステム／ソフトウェア利用時の品質を計測・評価するために作られたものだと思っています。

とはいえ、突然計測指標や評価方法を解説すると核となる"そもそも何を意図しているのか”がわからなくなる可能性もあるため、今回は「用語の意味」を中心に解説しました。

これらの意図や意味を確実に捉えることがこの規格の使いこなしの基盤となり、必要な計測指標や評価方法も導出しやすくなると思います。

では最後にまとめを。

■この規格の意味

あくまでも私の主観ですが、この規格は、利用者（人間）が、システム／ソフトウェアの利用を通じて、どのような要素で満足する（不満と感じる）のかをモデル化したものの一つであり、提供するシステム／ソフトウェアを利用者の立場に立ってつくることの重要性を伝えていると捉えています。

「想定する利用者」が存在していること、そしてシステム／ソフトウェアの外側にいる利用者の立場で「どう（満足を）感じるか」を捉えていることを忘れないようにしましょう。

（立ち位置）　利用者（★ココです！）←→システム／ソフトウェア

■個別要素は関係している

これまで見てきた通り、個々の要素がすべて並列・横並び、バラバラに存在しているわけではなく、それぞれが関係して構造を持っています。

機能が提供する「有効性」を核として、それがどのくらい効率的かを示す「効率性」、有効性の背後で実利用に伴うリスクをどの程度回避するのかを示す「リスク回避性」、想定内外の利用者の状況をどの程度カバーするのかを示す「コンテキストカバレッジ」が存在し、これらの結果、最終的にどの程度満足するのかを示す「満足性」がある。

このような関係（構造）が存在していることを理解して活用（参考に）したいものです。

■活用時の注意事項

この規格は決して「これらを考慮すれば完璧！」とか「これ以外の要素はない」ということを主張しているわけではないことに注意しましょう。

その内容は絶対視するべきものではなく、対象をよりよく理解し、システム／ソフトウェアを作り上げる・提供するための参考情報として活用する、というのが適切な距離感と取り扱い方になると思います。

もちろん「そんなの理解しなくても売れるシステム／ソフトウェアを提供できるから大丈夫さ！」という方は使わなければよいだけです。

モデルとは、「さまざまな領域で共通的に活用できるように代表的な要素で構成したもの」ですから、ある特定のドメインで活用する場合には過不足が存在する可能性が（大いに）あります。

「地図と実際が異なっている場合は目の前の景色（事実・実際）を信用せよ」ですので、実活用時は

・規格の用語、内容が実務にうまく合わないところがあれば適宜読み替える

・規格には存在するが、実務には存在しない要素があれば適用しない

・実務において規格に存在しない必要な要素があれば適宜追加する

・現実とはあまりにかけ離れている場合や使いこなせない場合は、無理に規格を活用しない

などの適切な（現実的な）取扱いが望まれます。

■使いこなせるようになるまで

最初からうまく使いこなせる人はまれです。

運転技術のように何度も実践しながら理解を深め、徐々に使いこなせるようになっていくのが通常ですので、３回程度は「トライ→フィードバック・改善」を重ねてください。

当初のトライアルの対象として規模の大きな対象や難易度の高い領域はお勧めしません。

小さな対象や難易度が低い領域から始めて徐々に規模と難易度を上げていくと、程よいチャレンジ感を得つつ、許容範囲の失敗リスクテイクになると思います。

何度も使っていくうちに利用者の立場からモノを見る、そして感じることの重要性を理解できるようになっていくと思いますのでお試しください。

■私が伝えたかったこととお礼

私がこのしがない連載を思い立ったのは「相手の立場に立ってモノゴトを捉え、考え、行動することの重要性を伝える素材になりそうだなぁ」と思ったからでした。

そもそも自分自身がちゃんと理解できているのかを確認するすべもなく、執筆時間を捻出できずに主に昼休み時間を活用したため不備もたくさんありましたね。その辺は大目に見てやってください。（笑）

お読みいただいたみなさんからのフィードバックをいただきつつ、さまざまなやり取りができたのはとても楽しかっただけでなく、自分の理解不足を解消したり、より深い理解を獲得することにつながりました。

この場を借りてみなさんにお礼申し上げます。ありがとうございました。

この情報が多少なりともみなさんの実務の参考になればうれしいです。

以上で「利用時の品質」の解説（もどきｗｗ）はおしまいです。

定義はこうなっています。

　製品、システムが定められた利用状況下で利用された時のユーザニーズに対する満足の度合。

利用者の状況下（コンテキスト）で実際にシステム／ソフトウェアを利用し、有効性、効率性、リスク回避性を獲得した結果、満足したかを把握するものですね。

この特性には副特性がたくさんあります。

一つずつ、例で説明していきます。

□目的達成度(Usefulness)

システムを利用する目標（ふるまいや最終結果）に対して実際に得た結果への満足の度合

現時点での公式な日本語訳は「実用性」だそうです。

「目的達成度」は他特定と同じような紛らわしい表現と感じていました。「実用性」の方がしっくりきます。

電車などの改札システムや企業内のセキュリティゲートなどで、カードをタッチしているのに通過できない、反応が変に遅い、意味不明な動作をする、などの経験はありませんか？

その局面で感じることは「どうして（ちゃんとタッチしているのに）通過できないの！」などの不満足感情だと思います。

うしろの利用者も前進しないので迷惑しますし、しまいには「おまえのせいで面倒なことに！」なんて顔で横をすり抜けて行ったり。「え～！俺のせいじゃないのに！」なんて思ってカードをよく見ると「違うカードだったｗｗ」（大笑）

これらのシステムは、通常利用時はスムーズに動作しないと役をなさない（通勤ラッシュ時に改札ゲートがのろのろ動くなんてありえません）ですし、適切なカードをタッチした際はスムーズな動作を（われわれは暗に）求めています。

一方、駅員さんや企業の立場では、不適切なカードをタッチされた際にはゲートを通過できないようになることを実現するためにもシステムを導入しています。上記の例では異なるカードをタッチしてもゲートが開かないのが正解なのです。

このように、利用者（今回の例では、ゲートを通過する人、駅員・企業）のニーズが実現され、それに満足する度合を指しています。

□信用(Trust)

製品、システムが想定されたふるまいをする能力の度合

この副特性は現時点での公式な日本語訳も「信用」だそうです。

実際には15万円の口座残金があるのにATMで残高参照をすると10万円と表示される。あるいは、振込済みなのに振込先口座にお金が入っていない、など金融関連システムが、実際の状態と異なる表示・動作や誤った処理をしてしまうのはあってはならないことです。

このように、システム／ソフトウェアのふるまいが、利用者が想定したとおりになることへの（信用）度合を指しています。

□喜び(Pleasure)

個人のニーズを遂行することから喜びを得る度合

現時点での公式な日本語訳は「快感性」だそうですが、個人的にはちょっと違和感がありました。

最近はどこのお店でもポイントカードを取り扱っていますね。航空会社のマイレージカードも同じです。

活用した分だけポイントが貯まる、特定の日にそのカードを見せると5%OFFになる、などのサービス（システム）が提供されています。

このように、システム／ソフトウェアの利用で何かのメリットや特典を獲得し、うれしいと感じる度合を指しています。

□安らぎ(Comfort)

身体的安らぎに対する満足度合

現時点での公式な日本語訳は「快適性」だそうです。

以前、実家の母にマッサージチェアを送りました。

なので帰省すると毎日マッサージチェアに座ります。（笑）

いろいろなモード（全身・頭～肩・背中・腰・足など）があり、コリのある箇所を中心にグリグリしてもらいます。

終わるとカラダや肩がが軽くなったり、気持ちよくて眠くなったりしますよね。

このようにシステム／ソフトウェアの利用による身体的な安らぎの度合を指しています。

以上が満足性の内容ですが、たくさん副特性がありますね。

満足にもいろいろある、ということでしょうか。

これでそれぞれの特性についての解説は終わりです。

次回はサマリ情報をお知らせしてこのシリーズを締めくくりたいと思います。

コンテキストカバレッジ（公式には「利用状況網羅性」となっているようです）とは、利用者のさまざまな背景や状況に対応してシステムがその目的や目標を達成できる度合を指します。

定義はこうなっています。

「定められた利用状況や、想定外の状況で有効性、効率性、安全性、満足性をもって利用できる度合。」

ここでは、利用時品質を構成する他の特性すべて（有効性・効率性・安全性（これは「リスク回避性」に読み替えるのがいいですね）・満足性）を包含していることに着目してください。

コンテキストカバレッジの土台の上に、これらの特性がすべて載っている、というのが利用時品質の全体像イメージになります。

コンテキストカバレッジには２つの副特性が存在します。

・状況適合性：要求で定められた利用状況下で有効性、効率性、安全性、満足性など利用される度合

・柔軟性　　：要求で定められた利用状況以外で有効性、効率性、安全性、満足性など利用される度合

状況適合性は「要求（想定）した利用状況下」を、柔軟性は「要求（想定）した利用状況以外」を対象としていて、それぞれ異なる領域を見守る副特性であることがわかります。

状況適合性は、要求（想定）した利用状況（領域）をどこまでカバーするのかを示すもの。

柔軟性は、要求（想定）した利用状況（領域）を超えて、さらにどこまでの利用状況をカバーするのかを示すもの。

一見「状況適合性はフルカバー」で「柔軟性も高いカバー率」が理想のようにも思えますが、薄く広くをカバーする＝あれもこれもそれなりに機能を搭載して、何が特徴なのかがわからないシステム／ソフトウェアになる可能性もあり、注意が必要です。

この場合、構築・維持コストが高く、利益は小さいシステム／ソフトウェアになる可能性もありますよね。

何でもできる＝何もできないのと同じ、なんてことにならないようにしたいものです。（爆）

さて、残りは満足性と総括です。

リスク回避性、最後の副特性は「環境リスク」です。

定義は

　利用状況下で環境や資源への潜在的リスクを軽減する度合

となっています。

環境や資源へ影響を与えるシステムやソフトウェアはこのリスク回避性が重要になると思います。

まずは、環境・・・公害や環境破壊・悪化につながる可能性のある要因が対象になります。

次に資源ですが、環境リスクや環境問題につながる資源、と捉えるのが適切かなと思っています。

”資源”を調べてみるとあーあーあー（笑）、天然資源、人的資源、観光資源、電波資源(初めて聞きました)、経済的資源、コンピュータ資源、などなど、いろいろありますね。

これらの中で直接的に環境リスクに影響を与えるものがあればそれが対象ということになります。

最近、節電を目的に家庭で発電・給電・売電することが当たり前になってきています。

例えば、発電量や節電量などをモニタリング・コントロールするシステムが誤動作し、無駄に電気を浪費するなど、思うような節電・節約ができなくなるようなら問題になりますよね。

また、工場の排気・排水、廃棄物などをモニタリング・コントロールするシステムが意図しない動作をするなどはその事例の一つです。公害に関連するもの＝土壌の汚染、騒音、振動、地盤の沈下、及び悪臭、また最近の話題では放射能汚染なども関連してきそうですね。

以上ですが、若かりし頃（笑）、ロジックに問題のあるコードが無限ループしてCPUを使いまくる、なんてことをよく見ました。（はい。まるで他人事のように表現してみました。自分が原因で目の前で起こっていたことなのにｗｗ）

これも電気を、そしてコンピュータ資源を、さらにはオペレータさんの工数や汗をムダに浪費する環境問題・・・だったのかもしれないなぁとぼんやり回想してしまいました。（爆）

※次はいよいよ最後の特性、コンテキストカバレッジにチャレンジします。

表題を読めばそれとなくわかると思いますが定義です。

　利用状況下で人への潜在的リスクを軽減する度合

ここでの対象はあくまでも「人」です。

システム／ソフトウェアの利用により人の生命や健康状態に害を与えるような事象を発生させない、あるいは仮に発生しても最小限に食い止めることができるようにしたいものですね。

以前の書き込みでは「放射線照射システムの誤動作→必要以上の放射線を浴びる／異なる箇所に照射してしまう」を例として上げましたが、他の例では、ランニングマシンのような健康増進のための機器に組み込まれたソフトウェアが誤動作（例：急に止まる・勝手にどんどん速くなる、など）して転倒事故などが起きると思わぬけがをする可能性があります。

さらに別の例では、緊急地震警報や避難誘導連絡のシステムが適切に動作しない場合、そもそも住民への安全が保証されなくなってしまいます。また、車載システムの誤動作で事故が起きると（人（施設・設備に対しても））同じことになりえます。

そして他の特性でも同じですが、”利用状況下で”ということを見逃さないようにしてください。

利用状況（コンテキスト）とは、システムやソフトウェアを利用する場合、どのような人（年齢・性別・嗜好・リテラシーレベル・健康状態など）、場所（国・地域・田舎/都会・屋内/屋外・海上/地上、など）、環境（天候・気温・湿度・明暗、など）、用途や局面で使うのか？ということです。

せっかく苦労してシステム／ソフトウェアを提供しても、コンテキストを考慮しないと（ある利用状況下では）役立たなくなったり、利用者に被害を及ぼしかねないので注意が必要となります。

以前このBlogでご紹介した書籍「Teaｍの力（西條剛快著）」の”方法の原理”をシステム／ソフトウェアに置き換えてみます。

　　【方法の原理】

　　　方法の有効性は状況と目的により変化する

　　　　↓ 

　　（”方法”を”システム／ソフトウェア”と読み替え）

　　　　↓

　　【システム／ソフトウェアの原理】

　　　システム／ソフトウェアの有効性は状況と目的により変化する

つまり、システム／ソフトウェアが目指す効果（有効性）を発揮する（その目的を達成する）ためには、さまざまな状況下での利用を想定してシステム／ソフトウェアを作り込むことが求められる、ということになります。

なお、システム／ソフトウェアのしかけ／しくみそのもので”すべての状況下”でのリスク対応を取る必要はありません。

取扱説明書などにシステム／ソフトウェアでは対応できない状況下での利用を禁止・制限する注意書きを載せるなどの対策を取ることもありえます。

利用状況の重要性をしっかり把握して、システム／ソフトウェアの効果を充分に発揮しつつ、リスクは最小限としたいものですね。

今回はちょっと中休み的な補足情報とさせていただきますね。

昨日の書き込みではこんなことを言っておりました。

----------------------------------------------------------------------------------------------------

「他の資源への潜在的リスク」ですが、これまでに登場しない他の資源・・・以上の説明には登場していない自らが持っている設備・備品や権利などはすべて該当します。具体的には・・・なんだろう？ちょっと出てきませんでした。

これについては思いついたら書き込むようにします。

----------------------------------------------------------------------------------------------------

といことで、今回は思いついた事例を提供します。

※必要十分ではないと思いますが、何もないよりはマシ、ということで。（笑）

資源＝ひと、カネ、モノ、情報、などと言われます。

カネ、モノについてはすでに述べていますので、それ以外のいくつかの事例を書き込んでおきます。

システムを利用することによってこんなことになるのが事例になると思われます。

・自らの所有地の価値が下がる（例えば、環境（土壌・空気・水など）が悪化などの背景から）

・自組織の人材が流出する

・自組織要員の士気が低下する

・自組織が持つノウハウや情報が流出する

このあと説明する内容（例：環境的リスク）と重複するようなものもありましたが、システムやソフトウェアを利用した結果どうなるのか？に関心がある特性として「一面的な（〇〇となる）」だけではない（〇〇となり、その結果さらに□□になる、というような）内容も想定されることにもご注意くださいね。

今回は以上の補足のみで終わります。

リスク回避性の副特性の一つ目は「経済リスクの危険性」です。

※公式な規格では、”危険性”を”緩和性”としているようですので適宜読み替えてください。

経済的リスクの危険性の定義は、

　利用状況下で経済的状況、運用効率、商業的所有物、評判、他の資源への潜在的リスクを軽減する度合

となっています。

軽減する程度、なので、公式の表現”緩和性”という方が題名と定義が一致している感じがしますよね。（笑）

「経済的状況への潜在的リスク」は副特性名と同じ用語があるのでわかりやすいと思います。

システムを利用することによって意図しない金銭的な損失がないこと、ですね。

代表的にはお金になると思いますが、証券や株券、商品やサービスを受け取れるお客様ポイントなど金銭的価値のあるものはすべて対象になると思います。

例えば以前、取り扱う金額が非常に大きな商取引関連のシステムで「０（ゼロ）」を一つ間違えて入力し、そのままOKしたためにとんでもない損失が・・・という話が以前ありましたね。100円が1000円になった程度なら許容できますが、100万円のつもりが1000万円になったり、1000万円のつもりが1億円になるととんでもない損失になりえます。

この事故のあと、金額の大きな取引を取扱うシステムは入力値の再確認STEPを踏んでからOKに至るような改善をしたと聞いています。

「運用効率への潜在的リスク」とは、システムを利用する際の手間や、その後の対応などが必要以上に大きくならないことを指します。システムを利用することでかえって手間がかかったり、必要のない余計な手続きが多いと、目的を果たすまでに使う時間と工数が無駄になってしまいますよね。こういうのを不便、と言います。

システムがあると便利！というのが暗黙のニーズですから不便になると損をしたと思うのは当然の話です。

「商業的所有物への潜在的リスク」ですが、当初私はてっきり知的財産権などを指すのかな？と思っていました。

そもそも「商業的所有物」という言葉そのものを聞いたことがありませんでしたし。（みなさんは聞いたことがありますか？）

営業秘密に当たる情報や商標、サービス・マーク及び商号、その他の商業上の表示などは該当しそうですが、どうして”商業”に限定しているのかはちょっとわかりません。

仮に知的財産権が該当するとした場合、システムの利用によって著作権や特許・実用新案・意匠・商標などが侵害されないようにすることがこの意味だと思います。

「評判への潜在的リスク」は、システムを利用することで自らや組織、企業の評判が失われる危険性を指していると思います。

例えば、あるサイトにメンバー登録しているだけで、「あの人（会社）、表面的にはクリーンなイメージだけど実はやばいんじゃないの？」と思われるようなことにはなりたくありませんよね。

最後は「他の資源への潜在的リスク」ですが、これまでに登場しない他の資源・・・以上の説明には登場していない自らが持っている設備・備品や権利などはすべて該当します。具体的には・・・なんだろう？ちょっと出てきませんでした。

これについては思いついたら書き込むようにします。

一つ目のリスクは以上です。 

リスク回避性は、以前のバージョンでは存在しなかった新しい特性のようにも見えますが、「安全性」を包含して拡張したもののようです。

定義は「製品やシステムが経済的状況、生活、健康、環境への潜在的リスクを軽減する度合」となっています。

利用者が持っている課題や問題を製品やシステムが解決する（有効性）だけではなく、その利用時に思わぬ別の問題が発生することを避ける度合い、ということですかね。

例えば、商品購入サイトを利用すると、自分がいるロケーションで欲しいモノが簡単に購入できる（＝有効性）のだけれども、時々多めに金額がとられてしまうとか、購入してもいないものの支払いが割り付けられる、あるいは個人情報が流出して変なメールや書簡が届くようになる、、、なんて勘弁してほしいですよね。

また、放射線治療システムのバグにより、患者さんに予定の数十倍の放射線を浴びせてしまったり、狙った患部と異なる場所に照射してしまうような事故が起きたのをTVのニュースで見たことがあります。

さらに別の例では、石油精製プラントを制御するシステムで、精製過程で発生するガス（人間の健康に影響を与えるもの）の排気コントロール機能の誤作動で規制レベルを大幅に超える大量のガスを排出してしまう・・・周囲の住民の健康や地球環境上、大きな問題になりえます。

システム・ソフトウェアの利用によりこのような意図しない不利益を被る可能性がどのくらい低いのかを取扱います。

※余談ですが、一般的にリスクマネジメントでは、リスクへの対策に「回避」「軽減」「移転」「保有」を挙げていますが、リスク回避性では”軽減”を扱っています。

副特性には以下のものが挙がっています。

①経済リスクの危険性

②健康安全リスクの危険性

③環境リスクの危険性

どれも人間の生活に影響を与えるものが並んでいますね。

先ほどの例を①②③の危険性と合わせてみると

・時々多めに金額がとられてしまう　＝　経済リスク

・購入してもいないものの支払いが割り付けられる　＝　経済リスク

・個人情報が流出して変なメールや書簡が届くようになる　＝　健康安全リスク

・予定の数十倍の放射線を浴びせてしまう　＝　健康安全リスク

・狙った患部と異なる場所に放射線を照射してしまう　＝　健康安全リスク

・規制レベルを大幅に超える大量のガスを排出してしまう　＝　健康安全リスク＋環境リスク

というような感じです。

ではこの後の更新ではこれらの危険性を一つずつ見ていくことにしましょう。

次は「効率性」です。

定義は「利用者が目標を達成する際に、正確さと完全性に費やした資源の度合」となっています。

想定している利用者がやりたいことを実現する過程と結果（＝有効性）を得る時に、どのくらい資源を使うのかを示す特性ということですね。

ここでの「資源」とは、システム・ソフトウェアの利用者（や関係者）が持つ・・・時間（や期間）、努力量（工数や手間、人手など）、お金などを指します。

たとえば、自宅から通学可能で、自分の持つ能力に見合う大学の情報が欲しいという利用者がいて、国内の大学関連情報を提供するWebシステムを使うとします。

（そのシステムはまさにそのような利用者を想定して構築されたと仮定します）

自宅のロケーションや自分の現在の成績、希望する分野などを入力し、検索ボタンを押すと・・・欲しい情報が一覧形式で画面に表示されました。それがまさに利用者が欲しい情報が含まれていたとすると「有効性」は見事クリアですね。

目標達成！よかったよかった！もういいですよね！・・・いやいや、ちょっと待ってください。

もし、検索条件を入力するまでにどのように使ったらよいのかがよく分からない・・・難解な操作を必要としているために、条件を入力して検索を指示するまでに３０分もの時間が必要だったとしたらどうでしょうか？

そして、検索指示後に情報が画面に表示されるまでに１時間かかるとしたらどうでしょう？

さらに、検索結果が大量に表示され、本当に欲しい情報に絞り込む方法がないために、表示された情報の中から自分であれこれ探す必要があるとしたらどうでしょう？（結果的に見つけられるとしても・・・ですよ）

さらにさらに、その情報を入手するのに１０００円の支払いが必要（検索機能の利用料として）だとしたらどうでしょうか？

極端な例を並べましたが、このように有効性を実現するだけでは「これ便利！」「今後もこれを是非使う！」ということにはなりません。つまり、どうがんばっても外せない「有効性」と一緒にくっついている特性の一つ、というふうに捉えるとわかりやすいと思います。

このようにシステム・ソフトウェアの利用を通じて得られる成果を内訳として”分解”したもの（のうちの代表的なもの）が利用時の品質（特性）です。

PS：

庶民的な感覚（笑）では効率を含めて「有効である」と捉えると思いますが、利用時の品質では目的達成と効率（＋今後解説する別の特性を含めて）を個別に分けて捉えようとしていることに注意が必要です。

実際の活用時には、あらかじめ設定する目標の中に「必要になるお金」や「手間・工数」などを入れておき、それらすべてで「有効性」を評価することもできます。

この場合、「～ができること」＋「効率がよいこと」のように有効性の枠内でいくつかの「サブ目標」を設定することになるはずです。

有効性と効率性を別々に評価するのも、有効性の中に効率を含めて個々の評価結果をサマリするのも、結局は同じ意味を持つように思います。分けなければならない、ということではありませんので、やりやすい方を選択してください。

「利用時の品質」はシステム・ソフトウェアそのものの特性ではなく、ソフトウェアを利用する際に、そして利用した結果どうなるか？なので、対象としているのは「システム・ソフトウェアの外側」であることはおさえておいたほうがよいですよね。

それを心にとめつつ、要素を一つずつ見ていきましょう。

今回は「有効性」です。

【有効性】

利用者が指定された目標を達成するうえでの正確さ、完全性の度合い

難しい言葉が並んでいるので一つずつ崩していきましょう。

まずは「指定された目標」。

「あらかじめ目標を定めている」ことが前提になっています。

利用者が何かをしたい、成し遂げたいと思っている。

それを目標として明らかにしてすることができれば、「有効かどうか」を確認することができるというわけです。

なるほどなるほど。

そもそもシステム・ソフトウェアって、普段の生活や業務の中に存在する「もっと簡単にできないかな？」「こういうことができれば便利なのに！」などのさまざまなニーズ・要望の中から、「システム・ソフトウェアの機能として（置き換えて）利用すると解決する！もっと便利になる！」ということを狙って作りあげますよね。

最近では身近な問題・課題解決だけでなく、ライフスタイルやビジネススタイルなどを革新するシステム・ソフトウェアも登場しています。

そうか、そもそもシステム・ソフトウェアを作り上げる狙いは何か？を明確にするとよいんだな、と。

つまり「このシステム・ソフトウェアで狙っている効果は何？」の答えが有効性ということになります。

なので他にもいろいろある特性要素の中で、特にこの「有効性」はもっともコアな、大事な、欠かせない要素となります。

（例：やりたいことがまともにできないのに、安く・早く済んでもしょうがない、など）

※この手の列挙された要素群（満足性、有効性、効率性、・・・）を見ると”すべてが横並びで均一”に見えてしまいますが、そうではありませんので注意しましょう。

ところで、システム・ソフトウェアを作り上げている人たちは、想定する利用者が誰で、どんなことに困っていてどうやって解決しようとしているのか、何をウリにしようとしているのか？　などなど「有効性」を把握するための情報をどのくらい理解しているのでしょうか？　多段階請負構造での開発になると下の層に行けばいくほど「何のために構築するものか、誰のためのものか」が見えにくくなりますよね。・・・自分を含めてちょっと不安になりました。（笑）

次に「正確さ、完全性の度合い」

・正確さ：正しさ・・・間違いなく、ということでしょうかね。

・完全性：必要なことがすべてそろっている、ということですかね。

もろもろをまとめると・・・

想定した利用者が、システム・ソフトウェアの利用（の過程と結果）を通じて、間違いがなく、必要なことがすべてそろった状態であらかじめ定めた目標を達成している程度を「有効性」という。

ふ～。説明って難しいですね。

疲れましたので今日はこれでおしまいにします。

PS:前回の説明に対して、akiyama924さんからリスク回避性の説明（下記）がイマイチ！とコメントをいただきました。

コメントいただきありがとうございます！

　・やりたいことをやる際とやった結果、危ないことに遭遇しないよね？・・・リスク回避性

リスクの中には、安全面だけではなく健康面（例：けが）・経済面（例：金銭的損害）・環境面（例：公害・汚染）・社会面（風評）などさまざまな側面があり、それを「危ない」と表現したのがイマイチだと、、、。はい。その通りです！

この詳細はこのあとの個別解説「リスク回避性」で取り上げる予定ですのでそれまでお待ちくださいね。

他にもさまざまなコメントをいただきありがとうございます。

一見難しそうな内容をちょっとだけ崩してみようと試みています。

マイペースでゆるゆると進めていきますので生暖かい目で見守ってください。（笑）

よろしくお願いしま～す。