＜　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つのアプローチでは、どちらがどのような結果になるでしょうか？

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

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

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

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

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

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の縦軸（成熟度）には下図のようにLevel1～Level5の5段階があります。

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

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には段階表現と連続表現があります。

先日ソフトウェアテストのプロセス改善モデル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さんからリスク回避性の説明（下記）がイマイチ！とコメントをいただきました。

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

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

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

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

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

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

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

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

前回は利用時の品質（特性）が大枠でどのように変わったのかを見てみましたが、これらは名称の通り「利用する時」に「どのようなことになるのか」を把握するための指標になるものです。

利用者の視点で、システムを利用した時に、どうなると品質が良いとか悪いとかいうのだろう？ということですね。

そして・有効性　・効率性　・満足性　・リスク回避性　・コンテキストカバレッジ、とバラバラに平坦に並んでいるように見えるこれらの要素は相互に関係して成り立っています。

正確かどうかは置いておいてイメージを書いてみましょう。

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

・やりたいこと、解決したいことが実現できるんだよね？・・・有効性

・いろいろな状況でもやりたいことをできるんだよね？・・・コンテキストカバレッジ

・やりたいことをやる際の手間や時間、使う資源は少ないよね？・・・効率性

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

・以上、やりたいことをやった結果どのくらい満足したのかな？・・・満足性

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

大枠ですがこんな感じです。イメージは湧きますでしょうか？

有効性を中心として、コンテキストカバレッジと効率性、リスク回避性がその周囲を取り囲み、その結果が満足性へとつながる、という図式になっています。

このように関係性があるのですから、各要素をバラバラに見る・活用するなんて「あーもったいない！」のです。（笑）

是非このことを理解して使いこなしたいものです。

ではまた次をお楽しみに。

PS:

S.Yさんに”コンテキストカバレッジは、JISだと「利用状況網羅性」ってなってるよ”とお知らせいただきました。

情報をありがとうございました。

当Blogでは、冒頭にお知らせした「報告書」の表現を採用しているためにこうなっています。

ご面倒ではありますが、適宜読み替えていただければ幸いです。

とあるお仕事の関係で

「システム／ソフトウェア製品の品質要求定義と品質評価のためのメトリクスに関する調査報告書」

というのを参照しました。

いやあ、ちょっと見ないうちに利用時の品質やソフトウェア品質特性が随分と変わっています。「品質は誰かにとっての価値である（by J.M.Weinberg）」なのですが、時代や時間が変わると（社会が求めるモノや価値観が変わるために）品質の定義も変わってくるのはわかりますよね。

国際標準って、さまざまな国や地域文化、価値観のぶつかり合いで出来上がるある意味妥協の産物とも言われていますが、タイムリーかどうかは別にして変化に追従しているのはすごいことです。

で、今回は「利用時の品質」をちょっとだけ見てみましょう。

以前の利用時の品質ってこんな感じだったんですよ。

　・有効性　・生産性　・安全性　・満足性

それが現在はこうなっています。

　・有効性　・効率性　・満足性　・リスク回避性　・コンテキストカバレッジ

そしてさらに満足性、リスク回避性、コンテキストカバレッジには副特性が存在しています。

有効性は以前と基本的に変化なし。

生産性と効率性は表現は変わったものの同じ定義と思ってよさそうです。

安全性を副特性として詳しく落とし込んでリスク回避性と改名。

満足性は詳しく落とし込んだ副特性を付与。

コンテキストカバレッジは、システム／ソフトウェアを利用する状況（コンテキスト）にどのくらい合っているのか、ということで初登場。

ということのようです。

ふむふむ。以前より内訳が付いてわかりやすくなった感じがする。

このあとも追って個別に内容を見ていくことにしましょう。

では次をお楽しみに。

この10数年ほどでテスト開発、テスト設計という概念が普及し、HAYST法（富士ゼロックスの秋山さん・吉澤さん・仙石さんが提案）、ゆもつよメソッド（日本HP湯本さんが提案）、NGT/VSTeP（電気通信大学にしさんが提案）などテスト開発方法論の詳細情報や実践事例も増えつつあります。

これらの概念や方法論にいち早く目を向け、それを理解し、実践しはじめた組織やチームが増えてきたなぁと実感する一方で、現状では組織の中の数人、チームの中の一人、のような比率にすぎずに周囲から浮いた存在になってしまう、現状からどのような段取りで変えていけば組織・チームとしてシームレスに移行できるのかがわからずに悶々とした日々を送る、結果的に既存のテストプロセスを変えられず、混乱したチームの状況に苦しんでいる組織やチーム、エンジニアも多いのではないかと推察しています。

いち早く方法論や手法の価値に気づき、情報収集・学習・一部実践などを重ねて自ら実践できるレベルに達した先行者のみなさんが次に迎えるステージはチーム・組織への展開です。

自分だけが新しい概念や方法論・手法が実践できても、チームや組織としての成果物がばらつき、かえって（一時的に）混乱する要因にもなりかねませんし、下手をすると異端児扱いされ、向き合ってもらえなくなる可能性もあります。

事務的な作業と違い、周囲の関係者に口頭や文書で教えればいい・・・と言うほど簡単に拡げられるものではないのです。

一般的に、人間は頭でわからないものは基本的に受け付けないものです。

新しい方法論や手法に興味を示して早速情報を収集し、その価値を把握するのは、普段から問題意識が高く、常に関連情報を収集→試行→実践と進めて自分のものにする一部の有識者の方たちと、さまざまな新しい知識だけを貯め込み「知ってる」ということだけがステータスになっている方たちです。

それ以外は当初は見向きもしないのがほとんど。

実践例や書籍が出ても反応はあまり変わらず、メディアなどが大々的に取り上げたり、顧客や関連組織が実践していてその適用に圧力がかかってはじめて形式的に適用しようとする、というのが（一般的な）実態ではないでしょうか。

また、多くの人たちは、新しい概念や方法論・手法の価値を簡単には理解できず、既存のやり方に固執しようとするもの。

人間は習慣の動物。最適より習慣を好む傾向があります。

どんなによいことだと頭でわかっても悪い習慣は簡単に変えられないことが多いのです。

さらに、適用したくても混乱の淵から脱しない限り、毎日が大変な状況で手も付けられない、という組織やチームもあります。

テスト設計のしそこないなどから多くの手戻り（仕事のやり直し）を発生させ、高稼動状態を続けている組織やチームでは、新しいことの試行・取り込みは（余裕が全然なくて）できない、ということです。

（こうやって、いつまでも混乱したままの組織やチームが出来上がります）

これらの「壁」を打破しない限り、 チーム・組織での実践は実現しません。

このような状態におけるアプローチには例えば次のような工夫が必要です。

(1)関係者が改善に参加したくなる理由から始める

(2)全員参画でのぞむ

 　各メンバーの実務における困り事を把握し、チームや組織で共有してからスタートする

　その解決のために改善を行う

　（自ら言い出したこと・自分にメリットがあることには取り組む姿勢を持ちやすい）

(3)存在するたくさんの問題から「取り組むべき」問題や狙いを絞り込む

　解決すると効果的な問題を特定し、使えるリソース（通常は少ない）を集中投下する

　特定した問題を具体的に把握し、改善の狙いや目標を明確にする

(4)改善による混乱を可能な限り回避する

　大混乱な状況での改善は回避する（当初の改善は不慣れなため負荷が大きくなる）

　現状の作業方法や成果物をできるだけ大きく変えずに最低限の見直しで効果が出るように仕立て直す

　当初は可能な限り簡単に効果が出る方法を採用し、そのあと徐々に高度化させていく

　改善開始から完了までのリードタイムをできるだけ短くする（改善対象を充分小さく絞り込む）

　部分試行など小さく開始し、改善手段をより磨きながら段階的に展開する

　これを繰り返しながら徐々に「あるべきプロセス」を作り上げていく

　当初はイベント的に改善を開始するが、最終的には普段の業務運営の中に改善機能を埋め込む

　（イベントではなく、業務運営の中であたり前に問題発見解決や改善が行えるようにする）

(5)メンバーが改善の効果や手応えをリアルに実感しながら進める

　改善により困り事が減った、なくなった、ということを事実情報で把握し、チーム・組織で共有する

　できるだけ短期間で「うまくいった！」ことを共有し、リアルに実感する

　うまくいかなかった場合でもその理由を特定して、次はこうすればうまくいくという見通し（手応え）を共有する

思いつくものをざっと書いてみましたが、一つひとつはそう難しくなさそうに見えるものの、これをよどみなく、機を逸さず確実に行うのは簡単ではありません。

これらの実践を可能な限り成功裏に進められるように考案したのがSaPIDと問題モデリングです。

そしてまさにいま、テスト開発方法論や手法を活用したテストプロセス改善に取り組むチームをSaPIDと問題モデリングで支援している最中です。

テスト開発・テスト設計の方法論や提案されているさまざまな手法を実務に適用し、チーム・組織に展開して効果を獲得するために、これらのポイントを参考にしてもらえればうれしいです。

私が「ゲーミフィケーション」という言葉に触れたのは、JaSST'13東北の基調講演「開発を楽しくするソフトウェアテスト」で湯本さんが取り上げたのを聴いたのが最初です。その後もこの用語をたびたび聞くことがありましたが、今年のJaSST'15東北終了後の”みちのくツアー（笑）”でJaSST'15東北実行委員長の根本さんがゲーミフィケーションのワークをやってくれましたので今回取り上げました。

ゲーミフィケーションとは、さまざまな活動にゲーム的な要素を取り入れ、関わる人たちがイキイキと楽しく活動できるようにするのが狙いです。

例えば、定型的な事務作業などを継続していくと次第に飽きてきますよね。

すると眠くなったり、注意散漫になると間違いも増えるし生産性もあがらない。

そこにゲーム的な要素を導入することで、誤りが減り、生産性もあがり、飽きっぽい仕事を楽しく取り組めるなどの効果が期待できます。

そういえば2001年頃に「フィッシュ!―鮮度100％ぴちぴちオフィスのつくり方」という書籍を読みました。

この本、130ページほどで、楽しい内容なのであっという間に読めてしまいます。（きっと今なら中古本もあると思う）

シアトルの「パイク・プレイス魚市場」を題材に、毎日ワイワイ魚が飛び交い、市場に来てくれた方がさまざまな楽しいアトラクションやゲームに参加してもらうなど、1日の多くの時間を占める「仕事」をお客さんと一緒に積極的に楽しみ、職場に活気を与える具体的な方法が寓話として書かれていました。実はこの本の事例を参考に、組織的な改善活動のしくみを検討し、実践した経緯もあります。

この本が出た当時はまだ「ゲーミフィケーション」という言葉は普及していませんでしたが、狙いは一緒ではないかと思います。

そして最近ユーザビリティ方面で定着した重要な概念の一つが「ユーザ体験（UX）」です。

人間中心設計HCD（Human Centered Design)とほぼ同義と言われる概念で、（ざっくりではありますがｗ）ユーザがシステムを使う際にどのようなイメージをいだき、感じ、体験するのかを設計・実装し、提供すること。もちろんわざわざ嫌な思いをするように設計することではなく（笑）、「ユーザがよりよい体験ができるシステムづくり」を目指します。

これ、ゲーミフィケーションと同じ方向性を持つ概念だなぁと思うのです。

ＵＸは主にシステムをデザインする際に活用されますが、自分の仕事や組織の仕事（これも一つのシステム！）をデザインするために活用することも可能ですよね。

プロジェクト・業務に一生懸命取り組むことも重要ですが、その取り組みそのものにも「楽しさ」や「うれしさ」がもっとあってよいと思いませんか？

難しい顔をしてＷＢＳを洗い出し、それぞれのタスクをメンバーに割り当て、実直に実践するだけではなく、どうすればメンバーが楽しく同じゴールに向かうことができるのかをゲーミフィケーションやユーザ体験のノウハウを活用してデザインし、実践するようなプロジェクト（計画立案・実践）があってもよいのではないかと考えます。

また、最近ではゲーミフィケーションを活用して実務を楽しく変えようとする人が増えているのはとてもうれしいことである一方で、誰かにしかけられないと仕事の仕方や意欲を変えられない受身なエンジニアや管理者が多いというのはどうしたものかとも思っています。

自分の仕事とそのやり方は自ら考えて作る。そしてやってみた結果からさらに楽しく、良い成果が上がるように見直し続ける。

その経験を活かして顧客の仕事や実務を楽しく、より成果が上がるように（UX）デザインし、実装する。

最終的には各自が自らの仕事を楽しくしつづける能動的なエンジニアが増えるのを期待したいですね。

最近はいろいろ立て込んでいて本を読む機会もあまり取れない状態が続いていましたが、久しぶりに無理してでも読みたい！と思える本に出会いました。

それが「チームの力　構造構成主義による”新”組織論」　西條剛央（ちくま新書）です。

東日本大震災の直後に現地の物流支援などを目的に任意で立ち上げた「ふんばろう東日本支援プロジェクト」を題材にしなやかなチーム作りのための実践理論、さまざまな原理の適用がもたらす効果などを解説する内容となっています。

この本を読みながら、（規模や成果はぜんぜん異なりますが）社内で生産革新活動を３年間主導した時の記憶がよみがえり、その時に分かったこと、感じたり実践していたものの明確な言葉にできずに終わったことなどが見事に解説されていて気持ち的にスッキリしました。

構造構成主義とはモノゴトの本質からなる原理を把握する学問で、価値の原理、方法の原理、人間の原理などの原理群からなる体系なんだそうです。そして原理とはいつでもどこでも論理的に考える限り例外なく洞察できる理路・・・と書いてありますが、あくまでも難しい言葉で困ったものです。（笑）

例えば「方法の原理」とは、”方法の有効性は状況と目的により変わる”ということ。

なるほど、あるところで有効な方法が別の状況下では役に立たないモノになりえる、その場合は（その状況に合うように）別の方法に変える必要があるのもその原理で説明ができます。（フムフム）

これらの原理を使って、プロジェクトや組織がうまくいかない要因とその対策、ある状況にどのように対応していくのが良いのかなどをふんばろう東日本支援プロジェクトでの事例を使って具体的に解説してくれています。

目指したのは以下のようなチームだそうです。

・くじらではなく小魚の群れになる（くじら＝動きが鈍い組織、小魚の群れ＝機動力がある自律したチーム群、の例えですね）

・明確な境界のない未曾有のチーム

・目的や理念がありながら状況の変化に柔軟に対応できるしなやかなチーム

それを東日本大震災で被災した現地で実践し、大きな成果を上げたことはすごすぎると思いました。

※2014年にアルス・エレクトロニカ賞のコミュニティ部門最優秀賞とベストチーム・オブ・ザ・イヤー2014を受賞したそうです。

とはいえ、明示されている原理が頭でわかればすぐできるようなものではありません。

また、イキナリ現場に飛び込んで経験しさえすれば体得できるような簡単なものでもありません。

実際に考えたこと、やったこと、あったことがホントにさらりと書かれているのですが、実際にはすさまじい状況の中で実践された内容であったはずです。そんなプロジェクトを統率してきた著者に頭が下がります。

私がこの本のおかげですっきりしたのは、組織とチーム、そしてグループの違い、そしてこのプロジェクトのゴールです。

個人的に”組織とチーム”についてうまく説明できていなかったのですが、とても腑に落ちました。

また、SaPIDのきっかけとなった生産革新活動の推進チームが掲げたゴールが、まさにこの「ふんばろうプロジェクト」のゴールと同じだったのはびっくりしました。

さらに、”自律したチーム作りに必要なこと”はSaPIDが目指すことでもあるため、とても共感しました。

他にも、リーダのあり方、誠実なチームや組織を作るには？、感謝を忘れたときチームは崩壊する、などチームや組織を運営する立場であれば把握しておいてほしい内容が目白押しです。

もし書店に寄ることがあれば、是非一度手に取ってみてほしい一冊です。

2015/6/16～6/17　ソフトウェアシンポジウム2015（SS2015）和歌山で、Working Group6（以降、WGとします）レビューを運営してきました。

http://sea.jp/ss2015/working_groups.html#wg6

このWGのリーダはフェリカネットワークスの栗田さんと私の２名でしたが、栗田さんはSS2015事務局対応もあるため進行役は私となりました。

参加者は、国内メーカのQA・SEPG、大学研究者、企業内PMOや技術系サポート役などいろいろな背景を持つ12名。

うち4名が女性（さらにそのうちの１名は大学生さん）で、なんと、1日目の途中まで松原友夫さん（書籍「ピープルウェア」や「ソフトウェア開発201の鉄則」の訳者さん）にご同席いただきました！

突然のことでびっくりしましたが、業界で最も古くから開催されているSSならではのうれしい出来事でした。

今回のテーマは「レビュー観点」。

これまでさまざまな組織に対してレビュー教育などを行ってきた際に、受講者のみなさんから「レビューの問題点」を収集してきました。その分析結果から、「レビューの結果や成果に直結する要因」と、「その背後で結果や成果を下支えしている要因」にわけられることがわかり、前者に着目したテーマ設定をしたのです。

まずは、メンバーのみなさんに事前に提出いただいたポジションペーパ(PP：簡単な自己紹介とテーマに対する自分の立ち位置を表明するもの)に沿って簡単な自己紹介とレビューに関する問題点を共有しました。

私の進行がよろしくないこともあり（すいませんｗ）、これで1日目が終了してしまいましたが、参加いただいたメンバーさんの状況やレビューに対する想いを共有することができました。（これだけでも十分価値のある内容でした）

PP紹介の中で、業界の重鎮Aさん（イニシャルではありません。あしからずｗ）からは『レビューは基本的に30年間変わってないよね』とコメントをいただきました。

なるほど言われてみると私が業界に入ってから（30年弱）レビューについてはさほど変化していない気がします。

（単に私の周囲が変わっていないのかもしれませんがｗ）

また、Bさんからは「現在のレビューは会議術についての議論ばかりなので、工学的な議論を期待したい」と。

このコメントは、先ほど記載した「レビューの結果や成果に直結する要因」と「その背後で下支えしている要因」にも符合するように受け取りました。

参加メンバーのみなさんが感じている問題点は、表現こそ異なるものの、どこの組織も同じ悩みや問題を抱えているなぁ、と実感できるものばかりでした。

（松原友夫さんからは「楽譜のレビュー」について貴重な体験談をいただきました）

2日目は、私が持ち込んだレビュー対象成果物（某ｗ要求仕様書）をベースに、メンバーが自由にレビュー観点を導出し、その一部をモデリングしてみました。

例えば「使いやすさ」に関連する要素として、操作性、簡単操作、手数、持ち運び、筐体の大きさ、などの観点が出ましたが、レビュー対象のどこの部分に対して、誰が、どのような性質をもって”使いやすい”とするのか、を整理し、関係者で共有しないと、レビューの場で具体的に”問題がある／なし”の判断ができないよね、ということになりました。

このようにみんなで要求仕様書のレビュー観点導出とモデリングをやってみましたが、関係者がみな同じ認識や判断ができるレベルまで観点を落とし込み、理解できる表現にするのは簡単ではありませんね。

例えば、「使いやすい」というのは非常に大雑把でわかりにくい。

一方で「72歳の健常者のおじいさんでも画面上のボタン表示が判読でき、迷いなくタッチできる」となると「使いやすい」がより詳細になっています。

この詳細化レベルについては、レビューアのスキルやドメイン知識により変える必要がありそうです。

さらに、この詳細化レベルをレビュー観点群の縦方向とすると、漏れなくダブりなく観点を導出する横方向にも難しさがあります。例えば「使いやすさ」に含まれる要素を漏れなくダブりなく出し切るのも簡単ではないです。

他にも観点導出とモデリングの過程で議論した内容をいくつか書いておきます。

・「レビュー対象成果物に書かれていること（例えば、目次に”非機能要求”と書かれていた）をレビュー観点として切り出す必要はあるのか、ないのか」についても議論になりました。書かれていないことだからこそレビューする必要があるのでは？という意見です。

これに対しては「私はレビュー対象成果物を直接読み込まずに、そういう製品なら一般的に（あるいは私なら）こういう観点で確認が必要だよね、と導出するので、観点に該当する言葉が書かれていたとしても（それが正しいか、適切かを）確認すべきだと思います。」というコメントがありました。

・「レビュー観点として明確化するのではなく、可能な限り開発関連のガイドに反映するアプローチを取っている」という方もいらっしゃいました。

レビュー観点を突き詰めると「開発で考慮すべき事項」を整理していることと同じ意味を持つので、そうしていると。

つまり、レビュー観点は、レビュー直前に整理するのではなく、要求定義や設計作業の前に行うこと、あるいはさらに発展してあらかじめ開発関連のガイドなどに反映して実作業に直接活かすことが必要になる、というこです。

・・・確かにその通りなのですが、実務ではまだまだどれも実践できてない場合も多い、ということは否定できません。

現在の状況から、どのレベルでレビュー観点にアプローチするのがよいのかを決める必要性を実感しました。

残念ながら時間の関係で、レビュー観点の導出とモデリングは途中で終了してしまいましたが、さまざまな背景を持つみなさんとの議論を通じていろいろなことに気づくことができたWGだったなぁと思います。

この続きもメーリングリストを通じて同じメンバーで継続していくことを確認してWG６は終了したのでした。

女性の割合が多いWGでしたので、ギスギスした感じがなく、とても穏やかに運営することができました。

バランスって大事ですよね。感謝感謝です。

WG6にご参加いただいたメンバーのみなさん、ありがとうございました！

SSには、2009年に札幌で開催されたのをきっかけにたびたび参加し、末端でプログラム委員もさせていただいています。

他のイベントとは違い、重鎮のみなさんから大学生などの若いみなさんまで分け隔てなく意見交換や議論ができるのはとてもすてきなことだと思っています。いや、そのような場はそうはありません。

北海道ゆえ、薄くではありますが、今後も関わっていければうれしいです。

和歌山は初めてでしたが、狭い三角の空き地まで田んぼになっていたり、ネコの駅長さんがウリになっているなど、肩の凝らないのんびりした居心地のよい街でした。よほどのことがない限りもう行くことはないかなぁ、と思いつつ、関西空港から帰路についたのでした。和歌山のみなさん、お世話になりました。

JaSST'15東北の前夜(2015.5.28）、東北デベロッパーズコミュニティ（TDC）さんの勉強会（ソフトウェアテスト勉強会～東北×東京×北海道×関西～）で「問題モデリング」の発表をしてきました。

翌日のイベント（JaSST'15東北）に参加するさまざまな地域のみなさんが集まり、持ちネタを披露する場だったのです。

http://tohoku-dev.jp/modules/eguide/?prev=1

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

トップバッターは、地元東北代表「うめつさん」（仙台ソフトウェアテスト勉強会）の「めんどくさいレビューをぷち改善してみた」。

次がJaSST'15東北でも発表された東京代表、クックパッド「松尾さん」の「モバイルアプリ開発体制の継続的改善」。

3番目が北海道代表の私「問題モデリング」。

そして最後は大阪代表、関西SWテスト勉強会(WARAI)「みずのりさん」の「20分でわかる”考える力”を高めるためのTOC（制約理論）」。

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

テストじゃないじゃん、というご指摘もあろうかと思いますが（笑）、それぞれの個性が発揮された内容で楽しい時間を過ごすことができました。

さて、私が発表した内容についてです。

問題モデリング（広義）とは、チームや組織に存在するたくさんの問題と、それらがどのように関連して何が起きているのか（因果関係）をわかりやすく表現し、関係者全員が問題を（最終的には全体構造と、個別詳細の両面で）把握・理解し、納得することで関係者全員に“問題発見・解決・改善の当事者”になってもらうことを目指す過程と結果の総称です。

その過程を「問題モデリングプロセス」、問題の表現方法を「問題モデリング（狭義）」と呼びます。

※補足：本来「モデリング」とは、対象の主な特徴を的確に捉え、主な要素を構造化し、枝葉情報は除外して表現するまでの試行錯誤の過程と結果を指す。（と思っています）

どうして問題モデリングなのか？というと、チーム内で問題を早期に発見して解決する、必要な改善を切り出してとっとと解決するなど関係者が当事者意識を持って自律的に運営するためには不可欠な内容だからです。

また、システム開発対象の領域（例えば、組織活動）に存在する問題点や課題となっている事項を特定する際にも問題モデリングは威力を発揮します。対象領域の関係者を巻き込んで問題や課題を明確化し、重要度レベルを付与したり、その解決方法を導出し、合意を形成する方法論でもあるからです。

つまり、問題モデリングの用途は

　①システム企画・提案・要求定義

　②プロジェクトマネジメント

　③プロセス改善

のすべてとなります。

そんな問題モデリングの実践と実現は簡単ではありません。

例えば、用途の②③で自律運営を実現させるには「チームとしての価値観と考え方」を変える必要があります。

いや、変えるというよりは「チームの成果を上げるために必要なこと、大事なこと」を認識して、それに沿って動いてもらう、というのが正しいかもしれません。

価値観と考え方の事例として「担当する作業は責任を持ってやり遂げる。わからないことを安易に周囲に聞くのは無責任だ。」という考え方があります。

これは一般的に否定されるようなことではありませんし、むしろその通りだ！と言われることが多い内容だと思います。

しかし、これが行き過ぎるとチームとしてどうなるか。ちょっと考えてみましょう。

　→問題が起きても（周囲も忙しいから）自分で抱え込む。→個別作業の進捗遅延になりやすい。

　→大きな問題に発展しやすくなり、結果的にチーム全体に大きな迷惑がかかる可能性がある。

このように、個人が持つ価値観・考え方、そして行動が、チームとしての結果や成果に影響を与える可能性があるのです。

実際に、ある新任の担当者が、作業で使用する機器の使い方（パラメータの設定方法）がわからず、数日進捗が止まっていました。周囲のメンバーも忙しそう、新任なので何でも聞いていたら周囲に迷惑をかける。

自ら作業ストップ状態を抱えたまま何時間も、何日もあれこれやってみるがダメ。時間だけがムダに経過していく。

そんな矢先にたまたま全メンバーに”現在の困り事”を聞いてみる機会があり、その人に尋ねたところ「使用する機器が思うように動かず、作業が進められません。困っています。」と。その場で別のメンバーが「あ、それね。みんなはまるんだよね。こうやって設定すればいいんだよ。」と詳細な設定情報を提供してくれてすぐに解決。

こんなことなら早く聞いてみればよかった、なんて事例もあります。

そう、プロジェクトの進捗は、このような些細な遅延が毎日重なって大きな遅れ（そして全員が不幸に）に繋がるのです。

こんなことにならないように「問題は一人で抱えず、できるだけ早く共有し、解決する」のがチームにとってもよいことである、とメンバー全員が認識することが必要になります。

※そうはいっても、自分で調べる方法を知っていることまで何でも人に聞くのがよいわけではありません。

　状況による使い分けが必要です。

では、各メンバーが問題を提供し、チームで共有すれば解決するよね！と思うかもしれませんが、そう簡単にはいきません。

例えば「問題がある」ということを言いにくい場（「なに！原因は誰だ！」など魔女狩りになるなど）になっている場合があります。その状況を解消しない限り、もし問題があってもみなに言う人はいないでしょう。

また「問題」とは何か？をメンバー全員で共有しておかないとグチや悪口、自分のことを棚に上げた戯言など余計な情報ばかりになったり、提示された抽象的な内容を具体的に確認する手間ばかりになりえます。

さらに、先ほどの機器設定の例は問題発見解決であって改善ではありません。

チームに存在するたくさんの問題事項の中から改善すべき事項を特定し、首尾よく解決できるようになるためには別視点での取り組みが必要になります。

以上のようなことをすべて考慮し、どのような段階を経て自律したチームを作っていけばよいのか、関係者に問題解決・改善の当事者になってもらうにはどうしたらよいのかをまとめたものが「問題モデリング（広義）」です。

これを書き込んでいる現在も、私は2チームの自律化を支援している最中です。

チームの状況やメンバーの特性も異なるため、都度、そしてチームごとにアプローチを変えて支援しています。

支援の過程で、当初曇っていたメンバーの顔が徐々に明るくなり、みんなで協力して問題を解決していくのが楽しくなっていく・・・そのさまをみることができるのは（支援はいろいろ大変なのですがｗｗ）本当に幸せです。

【参考情報1】

問題モデリングの簡単な解説PDFを「SaPID」コーナーの「問題モデリング」に置きました。

TDC勉強会での発表内容の多くを格納してありますので参考にしてください。

【参考情報2】

2015年度内に”SaPID Advanced Course”の一つとして「問題モデリング」のワークショップを開催する予定です。

それに先立って”SWEST17”にてSaPID解説＆問題モデリングワークを実施することが決まりました。

詳細は追ってお知らせします。

2015.5.29　JaSST'15東北の基調講演で私が最後に伝えたことは「相手の立場に身を置き、考え、行動することの重要性」でした。

レビューやテストの準備として観点を整理し、設計する場面やレビューコメント、テスト結果を相手に伝える際など（それに限らず、人間が生活していくうえでのあらゆる場面）には「相手の立場から考える」ことがとても大事だよ、というメッセージです。

基調講演の準備の過程で、これまで仕事や家族と経験してきたさまざまなことをふりかえり、総括するとこのメッセージに行きついた。今回はそれを素直に伝えたつもりです。

セブンイレブンの創業者、鈴木敏文氏によれば、人が「～のために」と考えるとき、”自分の立ち位置”から相手を見ていると。

自分→相手の図式。

この場合、自分の持っているものをベースにモノゴトを考えるため、相手に（自分の持っているモノを）押し売りしたりしかねない。モノが余り、多様な価値観や選択肢に囲まれている現在では、プロダクトアウトの発想は時代遅れだと。

本当に求められていることは、（当たり前ですが）相手が感じていることや真に求めていることを把握し、それに応えること。

そして、その変化を捉え、タイムリーに適応すること。そう、マーケットインの発想です。

その実現のために、相手の立場に身を置く（相手＝自分→の図式）のが効果的だ、ということになります。

創業時からこのことを徹底してきたセブンイレブンのその後は・・・言わずともわかると思います。

話は変わりますが、最近「デザインシンキング」という言葉をよく目にするようになりました。

私が初めてこの言葉を意識したのは、”SQiPシンポジウム2014”横塚氏の基調講演でのことです。

ビジネスやＩＴの変革を大きく推進するために、「品質｣も新しい考え方に基づく指標に変革していくことが求められる。

その実現には「デザインシンキング」が欠かせないと。横塚氏のプレゼンはインパクトのあるものでした。

詳細はここで触れませんが、デザインシンキングには5つのSTEPがあるそうです。

　STEP1：共感（Empathize）

　STEP2：問題定義（Define）

　STEP3：創造（Ideate）

　STEP4：プロトタイプ（Prototype）

　STEP5：テスト（Test）

ここで今回取り上げるのは「STEP1：共感」です。

対象となる人々や環境・境遇を理解し、共感することが重要である。

その実現手段として、例えば、同じ場所で暮らしてみる、サービスや製品を実際に使ってみる、リアルに体験してみる、などがある、とのこと。これはすべて「相手の立場に身を置く」ことに他なりません。

今回私が自らの体験をベースにJaSST'15東北で発信したメッセージが、これからのビジネスやITに不可欠なノウハウと符合したのは（単なる偶然ですがｗ）ちょっとうれしい気持ちになりました。

メトリクス。

これ、以前から結構人気があるし、いつになっても一定レベルでその人気は安定していると感じる。

しかし、メトリクスを使いこなし、効果を出すのはそう簡単なことではない。

メトリクスを活用したために、おかしな判断が下されたり、特定の人間が断罪されたりすることもある。

また、組織としてメトリクスを取ることが目的化して、多くの手間をかけて沢山の数値を収集するものの、経営層や外部の評価者（例えば顧客や審査員など）に”実践していることを取り繕う”ためだけに活用・・・本当の意味で役立っているのかが？？？になったりすることもある。

そもそもメトリクスは何のための道具なのか？

答えの一つは”モノゴトを客観的に見るため”なんだと思う。

でもね、対象の実態を表さないメトリクス（じゃ、客観的だって意味ないよねｗｗ）も多いので注意が必要だ。

客観的に対抗する言葉は”主観的”だ。

主観＝色眼鏡なので、その代表格は「人間」の受け取り方や感覚。

客観性を重視するメトリクスの敵は人間になったりする。

機械が行うことは客観的データとして取得しやすいが、人間や組織が行うことやその意味を客観的データで把握するのは非常に難しい。

定性的な質問事項に照らして「〇〇さんのスキルレベルは４（とみなそう）」「あなたの組織の成熟度は５だ」など、実は定性的なものを定量的に見せることも提案され、いろいろ使われている。

でも、客観性を高めることはできるが、評価・判断する人間の思惑などにも左右されるので怪しいところも多々ある。

さらに人間の感覚は間違っていることもある。

感覚がその日の体調や精神状態、人間関係などに左右されることもしばしばだ。

だからかもしれないが、メトリクス強行派（って名称がよいかはわからないがｗ）の中に、人間の実感や感覚を無視・軽視して、客観的なデータだけに目を向ける、信じ込む人が少なからず存在しているように感じることがある。

いやもしかすると、人間はめんどくさい・・・だから、すぐに答えがわかる（めんどくさくない）客観データにすがりつこうとしているのかもしれない。

あくまでも個人的な意見だが、主観情報と客観情報の活用バランス、なるものがあってよいかなぁ、と思う。

どっちかだけに偏ると見えるものが見えなくなったり、わかることがわからなくなったりするからね。

例1：テストやレビューでは「客観的な事実」で結果を示すことが重要だけど、その結論に至る過程というかきっかけは「ん？何かおかしいなぁ」とか「あれっ？」「具体的に言えないけど何かしっくりこない」っていう感覚だったりする。

例2：何かの数値情報が示された際に「ん～、実感と違うなぁ」って感じることがある。

最近ではさまざまな景気動向指数が発表され”景気がよくなっている！”と報道されるものの、街頭インタビューでは「ぜんぜん実感がない」と答える人が大多数、なんてのもこの事例。

IT業界では、進捗90%までは順調で、それ以降ず～っと進捗度が変化しない・・・という事例も多い。

メトリクスで本当の実態を表せないこともよくある話なのだから、100%完全には信用することができない人間の感覚を無視したり軽視するのはフェアじゃないし、むしろ余計な手間とお金がかからない人間の感覚をもっと重視してもよいのでは？と思う。

一つの数値や事実だけで〇×などの判断や全体の真実を把握できない、てことはよくある話だ。

複数の情報を活用して本当の状況把握や判断の精度を高める必要があるのだから、客観的なデータと関係者の感覚の両面を活用しない手はない、と思う。

テストやレビュー、あるいは別の人から説明を受けている際などに「ん？」と感じたら、そこをより深く掘ってみよう。

関係者の中で「ん？」と感じた人がいたら、みなが明確には気づいていない「何か」があるかもしれないと察して、調べてみよう。

そしてたとえそれが空振りに終わったとしても、その人の信用を落とす必要はない。

自分だって間違うことがあるし、人間だれしも間違うのだから。

それ以降も同じように人間が持つセンサーの「ん？」を大事にしよう。

それはメトリクスの効果、モノゴトの判断の容易さと的確さを高めてくれるだけでなく、”人間は基本的に信頼に値する”ことを共有することにつながると思う。

PS:書いてみて・・・ホントに文才ないな→自分ｗｗ

2015.5.29　仙台でソフトウェアテストシンポジウム2015東北が開催され、基調講演をしてきました。

お題は「現在のレビューに必要な次の一手を把握する　レビュー実践ウォークスルー」で110分間。

通常この手の基調講演は、ピーンと張り詰めた空気の中で行われますが、今回は基調講演の直前に会場の受講者のみなさんが”レビューの現状”などをワイワイ議論してからの開始となりました。

そのおかげで、受講者のみなさんの顔が緩くほころんでいる中でリラックスしながら進めることができました。

＃　JaSST東北実行委員会のみなさん、ありがとうございます！

準備したのは（110分で）140枚以上のスライド。実施する前から「それはボリューム的に無理でしょ」とわかる内容でした。

しかし、多くの構成要素を持つ「レビュー」の計画・準備・実施・評価判定・ふりかえり」を事例つきで、かつその過程を受講者と一緒に練り歩き（ウォークスルー）、解説するために、スライドを減らすことなく展開することにしました。

その分、すべての要素を均一に説明するのではなく、事前アンケートで収集した「レビューの困り事」の構造分析結果から”3つのポイント”に絞り込んで深く（以外のところは簡単に）説明することでメリハリをつけたわけです。

＃　受講者事前アンケート分析結果は、当日のみスライド＋解説でお知らせしました。

今回選択した”3つのポイント”とは、以下のものです。

①開始基準

②目的・観点設定

③効果を実感　　　　　　

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

①は「レビューする価値のある対象のみをレビューする」ためのものです。

これまで多くの組織やチームのレビューを見てきましたが、レビューパフォーマンスの悪い組織・チームほど、開始基準がない／曖昧、または実効性のない内容になっていました。

また、今回の受講者アンケート結果からも、この内容に起因する問題を抱えている方たちが多かったため、ポイントの１つに取り上げました。

開始基準とは、レビューに必要な情報やレビュー対象物の質、そして依頼者の考えが取り揃わない限り、多くの工数を費やすレビューを実施しない、ということです。

これが実現できないと、誤字・脱字・衍字（余計な文字）のような軽微な指摘事項に時間を費やすことになるため、工数をたくさん使うわりに有効な欠陥が検出できない、という罠に陥りやすくなります。

②目的・観点

有効な欠陥を指摘できない、というコメントもどこに行ってもかならず出てくるものです。

その背景には「有効なレビュー目的・観点が設定できていない」があります。

一度に一つのことしかできない、アンテナを立てないと欲しいものをキャッチできないのが人間ですから、どのような視点で確認するのかを事前に認識することが必要だ、というのが目的・観点の意図です。

今回は観点を整理、体系化することでレビュー目的も明確化する方法について、一部ワークを交えてお知らせしました。

③効果を実感

レビューパフォーマンスが向上しない原因の一つに、関係するメンバーがレビューの効果を実感していない（だから次のレビューもイヤイヤやる）、というのがあります。

レビューをどうやって評価するとよいのかがわからない、評価方法はあるが面倒な内容で、かつメンバーが効果を実感できるものではない、などがその要因となっています。

今回は、レビュー終了時にすぐレビューの効果をアナログ的に表にプロットする簡易な評価する方法と、その内容に基づき（これもレビュー終了直後に行う）ふりかえりにつなげる意味と事例をお知らせしました。

この評価方法だと、メンバーがレビューの効果を自ら評価し、実感できると思います。

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

基調講演なんてそうそう依頼されることはないので（笑）「自分流を貫いて楽しむ」ことを目標に取り組みました。

受講者他のみなさんから「楽しかった！」というコメントのほかに、「盛りだくさんすぎる」などのコメントもいただきましたが、レビュー全体のことをまとめている情報源は少ないことから、あえて「全部のせ」をやった、ということを付記しておきます。

今回初めて基調講演というものを経験しましたが、自分の伝えたいことは最低限何とか伝えることができたかなと思います。

そして、自分自身がとても楽しんで進めることができました。

これも、目を輝かせて受講いただいたみなさん、そしてたくさんの準備に加え、場をあたためてからバトンを渡してくれたJaSST東北実行委員会のみなさんのおかげです。 

本当にありがとうございました。

PS1：受講に来てくれたmiwaさんに「あだちさんに、基調講演のスライドのレビューはどんな観点でやったのか聞いてみたい♡」とつぶやかれました。（笑）

今回最も大事にしたことの1つは「レビューの最初から最後までを通過したとわかる内容にすること」です。

そしてもう一つの大事なことは「作者が納得する内容であること」です。

その結果が140スライドを超えた・・・多すぎですが、上記の2点を守れていたのでそのままとしました。（笑）

「現状の問題を教えてください。」

みなさんはこの質問にどのようにこたえるでしょうか？

ちょっと考えて、自分の答えが出たら読み進めてください。

これまでの経験では回答は大きく3つにわかれます。

①問題事象を提示する。

　例：欲しい情報を探すことが多く、そしてなかなか見つからず、作業が進みません。

②問題のように思えるが実は解決手段を提示する。

　例：情報共有ができていないことが問題です。（情報共有するのがいいです、と同等）

③解決手段を提示する。

　例：情報共有するのがいいです。

実際には②や③の方が意外と多いのが実態です。

つまり、問題をしっかりとらえている人は意外と少ない、ということになります。

「問題」は曖昧さを含んだ言葉です。

なので上記のようなばらついた回答が多くなってしまうのでしょうね。

残念ながら、問題を的確に把握できていない人・チームは、適切に解決することが難しくなります。

では、チームとして認識したい「問題」を的確に把握する方法はないのでしょうか？

これまでプロジェクトマネージャとして、あるいは問題発見・解決や継続的な改善実践をお手伝いしてきた経験から、質問の仕方を工夫すると「問題」を引き出す可能性が高まることを実感しています。

その質問とは「実務における困りごとはありませんか？」です。

仕事が着手できない、途中で止まってしまう、終えたはずなのにやり直しをしなければならなくなる、予定外の作業が何度も入る、、、このような事象は困りごとの代表的なものです。

そういう困り事があれば教えてください、とアプローチすると「問題」を引き出しやすい。

それでも②や③を提示してくる方はいます。ただ、圧倒的に少ないので大丈夫。

もし②や③を提示して来た際には「それが無いことで困ることを具体的に教えてください」と聞けば欲しい情報が得られやすくなります。

チームのメンバーの”実感”は、早期に問題を発見するための大事なセンサーです。

各自が持つ「困った！」センサーを利用すると問題が把握しやすく、共有しやすくなります。

そう、問題を早く解決したかったら、各自が把握した問題を早期に共有し、チームとして認識することです。

毎日朝起きて、ご飯を食べ、仕事をし、帰宅・就寝する。

そんな普通の毎日の中で自分が気がついていることはほんの少しなんだろうな、と思います。

自分が一つのフィルタになっていて、自分が見たいモノだけを（自分の色眼鏡で）見ているのかもしれないとさえ思います。

あまりよいたとえではありませんが、学校に行っている時、沢山の生徒の中から、自分の好きな子だけはちゃんと見つけることができる。知らない子は目にも入らないようにさえ感じる。（ちょっと言い過ぎ。笑）

運動会でたくさんいる子供たちの中から、自分の子供をちゃんと見つけることができる。

アンテナを立てると見えてくる。そんなことかもしれないと。

ある本では「チャンスは誰にも同じように訪れる。ただ、いつ来るかはわからない。だからチャンスが来た時に気づけるようにアンテナを立てておくこと。そしてその機会を逃さず生かせるように、普段から自分がやれる準備・努力をしておくべきだ。」と書いていました。

なるほど。自分の周囲には（見える、見えないにかかわらず）膨大な情報や機会が存在している。

その中から何を感じ取り、どのように活用して生きていくのかは、それぞれに任されているのかもしれませんね。

何かを意識し、意図して見ようと思うかどうか。それが大事だと。

そうしなければ、見えるものも見えないし、感じることもない可能性が高まるのではないかと。

確かに思い当るところがあります。

腕の良いプロジェクトマネージャやリーダは、問題となりそうな予兆を素早く捉えて手を打ってしまいます。

出来の悪いプロマネは、問題が大きくなって、誰が見てもわかるようになってから（挙句の果てに上司に怒鳴られてからｗｗ）後手後手の対応を始めます。

腕の良いレビューアは、他の人が気づかないところに目が行き、適切な指摘事項として相手に伝えることができます。

腕の良いテストエンジニアは、他の人が検出できない故障や欠陥を検出することができます。

どの例も、同じ情報をもとにしてやっていることなのに、他の人と結果が異なっています。

それは「何かを意図して見ようとしているかどうか」が要因になっているのではないかと。

目の付け所、着眼点、関心事、、、いろいろな言い方がありますが、これらを「観点」と呼ぶことにします。

レビューを例に考えてみましょう。

レビュー対象のドキュメントをいきなり渡されて「これ、レビューしてね」と漠然と言われる。

ぼんやりレビューしてもほとんど指摘ができないことが多い。

一方「こういう視点で確認してもらえますか」と具体的にお願いすると、指摘事項が出てきたりする。

「こういう視点（観点）で」と意識づけると見つけやすくなる。

人間の特性なのだからこれを活用しない手はありません。

レビューでまともな指摘が出ない、テストで欠陥が見つからない、問題が大きくならないと気づけない・・・などなどよく聞く話ですが、そのような問題が発生している背景には「その時に必要な観点が導出できていない」「必要な観点が具体的に設定されていない」という要因がありそうな気がします。

常日頃、何を大事にし、何を見ようとしているか・・・観点を大事にして仕事を、そして生活を充実したものにしたいものですね。