"State of Testing Survey 2016"が1/7より実施
あけましておめでとうございます。本年もよろしくお願いいたします。
1年ほど前、State of Testing Survey 2015(ソフトウェアテストの現状調査)に回答し、2015年12月下旬にState of Testing Survey 2015(ソフトウェアテストの現状調査)の結果が日本のテストコミュニティ有志により日本語訳として公開されました。
Practitestのblogによると、State of Testing Survey(ソフトウェアテストの現状調査)が2016年1月7日(※イスラエル時間)から実施されます。英語による設問ですが、英語に怖じけずに日本からも回答してみましょう。
昨年(2015年)に私が回答したとき、どのような設問があったか概要を下記に書きましたので、参考頂ければ幸いです。
2015年をふりかえる
2015年も残り1週間を切りましたので、今年やったことを振り返ってみます。
1月
・初の海外＠フィリピン(WARAI in Philippines)
関西のソフトウェアテスト勉強会(WARAI)の企画で、WARAIメンバーでフィリピンでテストマネージャとして活躍されているGakuさんの会社で勉強会行われ、私は参加者側で参加しました。
後に、GakuさんがJaSST'15関西の招待講演でフィリピンでのテストチーム立ち上げの話がありました。
・State of Testing Survey 2015に回答。
ソフトウェアテストの現状調査が世界規模で行われていたので、日本からの回答者の1人として回答しました。
なお、7月に調査結果が公開され、12月下旬に日本のテストコミュニティ有志により日本語訳が公開されました。
2月
・Rapid Software Testingのスライドを読んだ。
3月にJaSST'15東京で基調講演されたMichael Boltonの講演内容を予習するため、Rapid Software Testingのスライド内容を読み、概要をまとめました。
3月
・JaSST'15東京に参加しました。
Rapid Software Testingについて聴講でき、開発とテストのあるべき姿について一考するきっかけとなりました。
・James Bachのblog記事"Exploratory Testing 3.0"を目にする。
下記記事を少しずつ読み、探索的テストが変化していることを掴み始めました。 http://www.satisfice.com/blog/archives/1509
4月
・第3者検証課から開発課に異動しました。
3年間所属していた第3者検証課から、入社時に所属していた開発課に異動、つまり出戻りしました。
5月
・開発課でピンチヒッターな案件に参入していました。
異動前からのプロジェクトで炎上している案件があり、諸々支援することになりました。
6月
・探索的テストの活動モデルをblogで発表しました。
探索的テストについて議論するとき、課題を明確にしようと思い、悩みながら表現しました。
・JaSST'15関西に参加しました。
・AAA(Asiyan Automation Alliance)2015に参加しました。
7月
・開発課で新規開発プロジェクトのテスターとして参入しました。
5月のピンチヒッターな案件が終わった後、休む間もなくテスト実施の日々でしたが、製品のあるべき姿が描けていないため、大量のインシデントレポートを登録することに...
8月
・考える大人になるためのツール 国際認定プログラム 2015に参加しました。
「考える大人になるためのツール 国際認定プログラム 2015」に参加し、「ロジックツリー」「クラウド」「アンビシャス・ターゲット・ツリー」を4～5名のチームで取り組みました。また、懇親会では「ロジックツリー」「クラウド」を書いたものを見て頂いたり、他の方の「クラウド」を作る課程を見たりして、充実した4日間でした。
9月
JaSST'15北海道に参加＆ライトニングトークスで発表しました。
「探索的テスト」祭りでしたが、国内で探索的テストの情報がまとまりつつあり、時代が進んだと思いました。
10月
・JaSST'15九州に参加しました。
セキュリティテストに関心があり、参加しました。また、九州のコミュニティの方々のセッションもアツイなぁと思いました。
11月
・JaSST'15東海に参加しました。
Concolic Testについて関心があり、参加しました。開発でのテストについて、工夫する余地があると思いました。
・blogを毎週書いてから2年経過
継続は力なり。時間の使い方を意識しないと、継続して取り組めないと思いました。
12月
・システムテスト自動化カンファレンス2015に参加。
自動テストのキャズムを超えた先の世界でした。また、マネージャや経営層に自動テストのメリット&デメリットを説明しないと、形骸化して失敗に至ると危機感がありました。
さいごに
駆け足でふりかえってみましたが、他地域のイベントに参加することが多い1年でした。また、探索的テストに関するアウトプットが(質の良し悪しがありますが)少しずつ出てきたと実感しています。探索的テストに関しては、さらに探究していきます。
来年ですが、探索的テストを探究することの他に、マネジメントや経営などの分野も開拓してみます。
JaSST15東海(2)「特別講演：はじめてのコンコリックテスト ～基本原理から知るホワイトボックステストの新技術とその応用～」
11/6(金)に開催されたソフトウェアテストシンポジウム2015東海(JaSST'15 Tokai)に参加しました。私が聴講したセッションは下記です。
セッション1 基調講演：「テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」 松尾谷 徹(デバッグ工学研究所)
セッション 4-1 特別講演：「はじめてのコンコリックテスト ～基本原理から知るホワイトボックステストの新技術とその応用～」 植月 啓次(フェリカネットワークス)
セッション 4-2 事例発表：「安全系組込ソフトウェア開発におけるユニットテストの効率化」 岸本 渉(デンソー)
セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」 鈴木 三紀夫(リコーＩＴソリューションズ)
情報交換会
前回書いた記事
今回は、セッション 4-1 特別講演：「はじめてのコンコリックテスト ～基本原理から知るホワイトボックステストの新技術とその応用～」です。
セッション 4-1 特別講演：「はじめてのコンコリックテスト ～基本原理から知るホワイトボックステストの新技術とその応用～」 植月 啓次(フェリカネットワークス)
(1)シンボリック実行(Symbolic execution)
- プログラム解析後、実行パスの抽出と実行パスを実行するための入力データを特定する技術。
- 入力データ：シンボリック(Symbolic)として扱う。
- 静的テストに分類される。
(2)SAT(充足可能性問題)
- 論理式の変数True/Falseの組み合わせで、結果がTrueかFalseかを判定する問題。
- 論理式をコンピュータで解くアルゴリズムを利用。
- SATソルバで解く。
(3)動的実行
実行結果の値を入力してSATソルバで解かせる。
(4)Concolic = Concrete + Symbolic
"Concolic test"は、具体的な値(Conclete Value)を使った動的実行とシンボリック実行(Symbolic execution)を組み合わせたもの。
流れは以下。
- 入力する変数を指定する。
- 入力する変数に任意の初期値を指定
- 実行の過程で出てきた数値を次のテストに入れて、SATソルバに解かせる
(5)Concolic testを現場適用するときの障壁
- パス数が爆発
10回のループが2つ並んだら→100回。 - ソルバの制約
- 種類によって得意不得意。
- 浮動小数やポインタは苦手。
- オラクル問題
入力は求められるが、期待結果は求められない。
(6)ツール
- PathCrawler
- C
- Web上で試行できる。
- CUTE
- C/Java
- 更新が滞っている。
- CREST C
- KLEE LLVM
- Microsoft Pex
- SPF(Symbolic Path Finder)
- DART(非公開)
(7)実例
Fuzzテストで応用されている。MictosoftのSAGEというツールの事例が有名とのこと。
(8)課題
- パス数の爆発
- 処理能力Upで改善。
- 部分適用で工夫する。
- ソルバの制約
- ソルバの進化で改善。
- SMTソルバ。
- オラクル問題
(9)デモ
- Symbolic Path Finder
- 植月さんのblog(http://blog.utkeiji.com/?cat=2)に詳細情報が掲載されている。
所感
Concolic Testは、1～2年前から時折耳にしていますが、概要は分からない状態でした。近い将来、concolic testを適用する場面が出てくると思いますので、開発者と連携して取り組もうと思います。まずは、情報収集と活用できるところの検討から始めたいと思います。
JaSST15東海(1)「基調講演：テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」
11/6(金)に開催されたソフトウェアテストシンポジウム2015東海(JaSST'15 Tokai)に参加しました。私が聴講したセッションは下記です。
セッション1 基調講演：「テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」 松尾谷 徹(デバッグ工学研究所)
セッション 4-1 特別講演：「はじめてのコンコリックテスト ～基本原理から知るホワイトボックステストの新技術とその応用～」 植月 啓次(フェリカネットワークス)
セッション 4-2 事例発表：「安全系組込ソフトウェア開発におけるユニットテストの効率化」 岸本 渉(デンソー)
セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」 鈴木 三紀夫(リコーＩＴソリューションズ)
情報交換会
今回は、セッション1 基調講演：「テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」です。
セッション1 基調講演：「テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」松尾谷 徹(デバッグ工学研究所)
(1)背景 検証指向設計とは
(1-1)背景
(1-1-1)オブジェクト指向
(1-1-2)流用技術
- 簡単にコード書ける。 →逆に言うと、バグを書くと簡単にシステムが停止する。
- プログラム規模が増大し、テストの規模増大という事情がある。
(1-2)開発オーディション
テスト能力の範囲でソフトウェアを設計する。
(2)派生開発
(2-1)確認すべき2つの仕様
- 追加、変更、削除された機能やふるまい。
→派生部分のテスト。 - 何も変わっていない機能。
→回帰テスト(Regression Testing)
(2-2)回帰テスト設計
- 入力となる仕様(成果物)は「？(変更なし)」である。
- linuxの世界では、回帰テストの部分も含めてリリースしている。
- 1行変更や追加すると、テストを書くことが当たり前の世界である。
- 日本は、回帰テストはビッグバーンテストとなっているのが実情である。
(2-3)後工程
(2-3-1)製造業の美徳
「後工程はお客様」
(2-3-2)製造業のの内なるソフトウェア業では
Cowboy Programmingで我流でソフトウェア開発するが、共倒れになる。
(2-3-3)解決策
- 美徳で守るプロセスへ改善
→精神論では... - 現実を受け入れる。
→新たな解決方法へ
(2-4)派生開発の回帰テスト
- 問題点
- 仕様ベースのテストでは不可能。
- 実装ベースのテストで乗り越える。
- Concolic Testing
前のバージョンと現バージョンの動作結果を比較する。
(3)スキルの成長
(3-1)元NECの東さん
バグとテストケースの対応は...
- 半分くらい。
- テストケースの重複。
- テスト準備でバグを見つけることも。
(3-2)プログラミング演習
演習法は、「机上でプログラミング→プログラミング組んで実習」よりは「早く習得→早く書いて、早くデバッグ」を行うことにしている。
(3-3)諸々のスキル習得
(3-4)プログラミング
確かめながら作る。つまり、動かしてみないと分からない。
(3-5)ソフトウェア工学
1968年NATOの時代に「早期警戒システムの失敗」がきっかけで始まった。
(3-6)テストスキルの実態
- テスト設計の問題を解く。
8割の網羅達成者は、全体の5%以下であった。 - テストスキルが身につかない。
原因は、テストケース書くがテストケースのデバッグが無い。 - テスト(デバッグ)
テスト対象プログラムとgcov
(3-7)テスト対象の出来栄え
本質は、「検算」である。
(3-8)テストのモデル
(4)テストのモデル：探索モデル
(4-1)OR(Operations Research)
Uボードを探索する方法を考案することがきっかけ。
(4-2)探索要素
- 探索空間
- 探索目標
- 有効探知幅
- 探知速度
(4-3)ランダム探索
発見確率から見ると非効率である。
(5)プログラムの探索行動
(5-1)問題
- そもそも探索していないので、探索漏れがある。
- 時間や工数がかかるのが探知効率の問題である。
(5-2)テスト技法の問題
- テストケースを詳細化するが、全体を網羅していない。
- 系統的な技法が敬遠される。
(5-3)テストのデバッグ課題
- テストケースの重複
- 実施済みテストのフィードバック
(5-4)マイヤーズの三角形問題
CFD(原因流れ図)で解く。
(5-5)探知効率
平行探索に持って行く必要が...
(5-6)まとめ
- 検算できるようにする必要がある
- ブリコラージュ＋科学的手法
所感
ソフトウェアが望まれた動作するか検算できるようにモデルを考えるためには、小さなサイクルで失敗して学んでフィードバックしながらスキルを高めることが必要と痛感しました。また、世の中でやっているソフトウェア設計やテスト設計を幅広く知り、開発プロジェクトで試行することも私にとっての課題の1つと思いました。
JaSST15九州(3)「招待講演：テストエンジニアを育てるためのポイント」
10/9(金)に開催されたソフトウェアテストシンポジウム2015九州(JaSST'15 Kyushu)に参加しました。私が聴講したセッションは下記です。
基調講演：「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」
徳丸 浩(HASHコンサルティング)
事例発表・経験発表：「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」
木下 真哉(九州ソフトウェアテスト勉強会)
事例発表・経験発表：「テストする人。の思うところ」
福田 里奈((九州ソフトウェアテスト勉強会)
招待講演：「テストエンジニアを育てるためのポイント」
鈴木 三紀夫(リコーＩＴソリューションズ)
企画イベント(JaSST Kyushu実行委員会)
今回は、招待講演：「テストエンジニアを育てるためのポイント」です。
招待講演：「テストエンジニアを育てるためのポイント」 鈴木 三紀夫(リコーＩＴソリューションズ)
(1)講演資料
JaSST'15九州のサイトに掲載されていますので、ご参照下さい。
http://www.jasst.jp/symposium/jasst15kyushu/report.html#invitation
(2)テストエンジニア育成 3つの段階
テストエンジニアの成長段階にあわせ、指導方法を変える。
(2-1)テストエンジニアになりたて
- 長所を伸ばす
- のびのび取り組んだ人：2～3年後劇的に変わる
- 型にはめ込まれた人：伸び悩む
(2-2)自信がついたころ
自己流ではなく、世の中でやってること(Test.SSF、HAYST法など)を知る。
- 自己流でやり続けないという意味で学ぶとよい。
- 自己流でやり続けると、行き詰まる。
- 自己の欠点を補うため。
「テストケース」という言葉は、仕事した人と話しても通じない。
- 理由：テスト設計のイメージがそれぞれ異なる。
- イメージ例：仕様書をコピー&ペーストしてモディファイしたテスト。
(2-3)リーダになったころ
- InputからOutputへ移行。
- Outputすると、伸びる!!
- テストプロセスの改善。
- 人を動かすほうが評価される。
(3)まとめ
(4)付録の話
(4-1)3色ボールペン法
メリットは、テストケースを考えるとき、仕様書を読みながらぼやいていたことを逃さずに書くと気付きがあり、テストケースを書くときに効果抜群であった。
(4-2)Test.SSF
- テストプロセスをアクティビティに分割すること
- 逸話
JaSST'04東京の情報交換会でテスト設計の話をじっくり聞いた人がいた。翌年のJaSST'05東京の情報交換会でテスト設計の話をじっくり聞いた人から「テスト設計がよかった」と話をされ、理由を聞くと「テスト設計の概念を社内で話したら、バグ検出が向上した。」とのこと。 - テスト要求分析
テストの質が上がる。 - テストアーキテクト設計
無駄なテストが見えてきた。
(4-3)テスト観点リスト
- 資産である。
- 「何をテストしたいか？」のノウハウが蓄積されている。
(4-4)不具合蓄積リスト
- プログラムを書く前に半日バグについて情報を集める。
- 過去のバグを引き出す
- 「どういうバグがあるか？」
- 気付いたバグは、バグを埋め込まれない。
- コストがかからず、効果が出る。
所感
本講演は、現場で工夫されたことを第3者に伝える形でまとめられているので、自組織でも実践できると思いました。「世の中でやっていること」を知ることは、失敗しないための工夫を知ることになるので、さらなる工夫ができるように開発メンバーに伝えつつ、共に進めようと思います。また、本講演資料から何らかのヒントが得られると思うので、開発現場で工夫するネタを考えてみようと思います。
JaSST15九州(2)「事例発表・経験発表：『開発エンジニアがどうしてソフトウェアテストに関心を持ったか』『テストする人。の思うところ』」
10/9(金)に開催されたソフトウェアテストシンポジウム2015九州(JaSST'15 Kyushu)に参加しました。私が聴講したセッションは下記です。
基調講演：「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」
徳丸 浩(HASHコンサルティング)
事例発表・経験発表：「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」
木下 真哉(九州ソフトウェアテスト勉強会)
事例発表・経験発表：「テストする人。の思うところ」
福田 里奈((九州ソフトウェアテスト勉強会)
招待講演：「テストエンジニアを育てるためのポイント」
鈴木 三紀夫(リコーＩＴソリューションズ)
企画イベント(JaSST Kyushu実行委員会)
今回は、事例発表・経験発表：「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」と「テストする人。の思うところ」の2講演です。
事例発表・経験発表：「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」
(1)テストに関心をもったきっかけ
仕様書に書いた内容を満たしてもバグは発生する。原因は、「テストのやり方がよくなかった」「テストの手法を知らなかった」であった。
(2)テストを勉強する上での問題
情報収集の限界があったとき、Facebookページの「九州ソフトウェアテスト勉強会」に出会った。
(3)九州ソフトウェアテスト勉強会に参加
- 月1回の勉強会。
- コミュニティに参加すると、情報が集まってくる。
- JSTQB FLの情報を知り、勉強して合格した。資格取得がテストを勉強するために有効であることを実感。
- テスト設計コンテスト
- 今の知識でどれだけできるか試したくて参加した。
- 学んだことは、「テストも設計すること」「テスト仕様書がよくても、ソフトウェアの構造がダメだと、テストの効率がよくない。」ことである。
(4)まとめ
- テストを楽しめる仕組みをつくる。
- 開発エンジニアもテストに興味を持てる。
- テストを学ぶコミュニティの存在は大切である。
事例発表・経験発表：「テストする人。の思うところ」
(1)blogからのネタ
ユーザ登録時に設定するユーザIDの桁数に関する疑問の記事。
(2)ユーザIDの桁数
ユーザID登録時の文字数が6～14桁であるが、「なぜ、桁数制限があるか？」疑問に思ったとのこと。
(3)徳丸さんに聞いた
セキュリティの理由は思いつかないので、画面デザインではないか？
(4)エンジニアに聞いた
- お客様に安心感を与えたいから
- なんとなく守られている感
- 意味のある言葉をつけてほしい
聞いたエンジニア本人の感覚であり、上限の14桁は深い意味はない...
(5)テスターのあり方
- ユーザのため
- 一般的なものから逸脱してないか？
- 使用性
- エンジニアのため
- バグが混入しにくいようにする。
- 意図を理解し、システムを改善する。
所感
開発現場の問題や疑問を解決するため、地域コミュニティを知って情報交換や議論することで、(JaSST'15九州のテーマである)「知識の広がりは可能性の広がり」を実現したんだなと肌で感じたセッションでした。また、本セッションを聴講後、地域からネタを発信することで開発現場の問題を解決するためのヒントが地元や他地域の方からフィードバック頂けるので、「知識の広がりは可能性の広がり」から新たな道が見つかると思いました。
JaSST15九州(1)「基調講演：ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」
10/9(金)に開催されたソフトウェアテストシンポジウム2015九州(JaSST'15 Kyushu)に参加しました。私が聴講したセッションは下記です。
基調講演：「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」
徳丸 浩(HASHコンサルティング)
事例発表・経験発表：「開発エンジニアがどうしてソフトウェアテストに関心を持ったのか」
木下 真哉(九州ソフトウェアテスト勉強会)
事例発表・経験発表：「テストする人。の思うところ」
福田 里奈((九州ソフトウェアテスト勉強会)
招待講演：「テストエンジニアを育てるためのポイント」
鈴木 三紀夫(リコーＩＴソリューションズ)
企画イベント(JaSST Kyushu実行委員会)
今回は、基調講演：「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」のメモをまとめました。
基調講演：「ソフトウェアテストとしての脆弱性診断と開発プロセスの継続的改善」 徳丸 浩 （HASHコンサルティング）
(1)脆弱性とは？
(1-1)悪用可能なバグ。
サーバーの設定不備により、できないはずのことができてしまう。また、できてはいけないことができてしまうこと。
(1-2)脆弱性の例
- バッファオーバーフロー
C言語のメモリ確保関数 - SQLインジェクション
文法ルールを守っていないこと - XSS(クロスサイトスクリプティング) 悪意のあるスクリプトが実行される
(2)進入経路
- 認証突破
簡単なパスワードで入られる - ソフトウェアの脆弱性を悪用
基盤ソフトウェア
自開発のアプリケーション
(3)あらゆるバグは脆弱性に通じる
排他制御の漏れなど。例えば、仙台の某アイドルグループのライブ開催におけるホテル予約殺到で、ダブルブッキングやトリプルブッキングした事件。
(4)脆弱性＝バグと捉えるのが一般的
(4-1)脆弱性の責任
発注者に責任がある(徳丸さんの意見)。
(4-2)家具インテリアECサイト
- 東京地裁でSQLインジェクション攻撃と断定。
- SQLインジェクション対策を怠ったのは、重過失。
- 考察
専門家としての責務を重視。
「安全なWebサイトの作り方(https://www.ipa.go.jp/security/vuln/websecurity.html)」に記載している対策は、最低限対策したほうがよい。
(5)デモ
(5-1)SQLインジェクション攻撃＠EC立方体
EC立方体の初期状態(インストール直後)で、都道府県の欄に
'OR" "a-a" init 10 #
と入力すると福岡県のはずが北海道が出力される。
UNION SELECT 1, cardname ...
UNION SELECT文でカード情報を取得し、information_schemaでテーブルを取得し、その情報から攻撃。
(5-2)PHP入門書
- 掲示板の削除ボタンのリンクにあるIDに"?id=729-1"を付与すると、728番目の書き込みが消える。
- extractvalue関数で故意にエラーのあるクエリを入れ、わざとエラーメッセージを出して、個人情報を取得。
- sleep関数を利用して時間差で情報を盗む。
(5-3)横浜市のCSRF悪用
- XSS
見えないiframe。
投稿欄にjavascriptを仕込む。
利用者側で注意はできないので、サイト側で対策の必要がある。
(6)脆弱性対策と開発プロセス
- 実装や開発者のテストでも脆弱診断するとよい
- 発注者側：仕様書にSQLインジェクション、XSS対策を書く
- 安全なWebサイトは、抽象的なので具体的に仕様を書くとよい
- RFPに「SQLインジェクションなどの対策」などの範囲があいまいなので、セキュリティ要件は開発標準に盛り込んで明確化する。
- セキュリティテストを内部でこれからのトレンドになりそう。
(7)脆弱性診断
- リモート(ブラックボックス)診断
害の無い攻撃(疑似攻撃) ツールを使った診断もある - ソースコード(ホワイトボックス)診断 ツール(Fortify)
- グレーボックス リモート(ブラックボックス)診断とソースコード(ホワイトボックス)診断を組み合わせる。
(8)Webアプリ脆弱性診断
- 脆弱性診断は、テストの一種。
- テスト環境を準備
DBが壊れてもOKな環境 - 課題
費用高額
安全性(DB破壊など) - ネットの情報を鵜呑みにしない
- 脆弱性検査するときは、1箇所だけSQLインジェクションして、その他は正常データを入れて検査。
- whileのところは、orよりand使う。andはプロが使う。
- 新しい攻撃手法は、それほど出ていない。もし出たら、大騒ぎするレベルである。
(9)質疑応答
Q1
サーバ側の脆弱性診断したいが、jsで弾かれたので脆弱性診断がやりにくいが、どうすればよいか？
A1
Burp Suiteなどのツールを利用するとよい。本ツールは、サーバにパケットを投げる前に色々仕込める。
Q2
セキュリティ検査を社内で実施するのがトレンドだが、第3者的な監査は残るか？
A2
第3者的な監査は残ると思う。
Q3
非属人化が問題だが、どうすればよいか？
A3
- 人はなかなか集まらない。
- ツールの進化に期待する(ただし、緩やかだが...)。
- Webアプリ開発経験者を教育するのが現実的だと思う。
所感
初め、脆弱性のイメージがピンと来なかったですが、脆弱性が「悪用可能なバグ」という話でガッテンしました。また、Industrie4.0が当たり前の時代になり、脆弱性や機能安全の対応を疎かにすると市場不具合が発生したときに、多大な損害を被ることになりますので、開発もテストも予防できることは何か、どのようなアプローチがあるか、情報のアンテナを張り、日頃から議論したり考えていこうと思う。
JaSST15北海道(4)「JaSST Hokkaidoセッション：『ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか』」
9/18(金)に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)に参加しました。
私が参加したセッションは下記です。
セッション1 基調講演：
「探索的テスト - アジャイル時代の効率的なテストを考える」
セッション3-3 探索的テストチュートリアル：
「やってみよう！探索的テスト。テストの常識を変えませんか？」
セッション4-1-1 ライトニングトークス
セッション4-1-2 ビブリオバトル
セッション4-1-3 JaSST Hokkaidoセッション2：
「ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか」
以前書いた記事
今回は、セッション4-1-3 JaSST Hokkaidoセッション2：「ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか」の聴講メモをまとめました。
セッション4-1-3 JaSST Hokkaidoセッション2：「ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか」 相沢 直人(インサイト)
(1)資料
下記を参照下さい。
http://jasst.jp/symposium/jasst15hokkaido/report.html#session2
(2)ユーザビリティとは？
ISO9241-11やニールセンのユーザビリティの定義があるが、一言で言うと...
「ユーザビリティ≠使いやすさ」
(3)ユーザビリティテスト
下記2種類ある。
- ユーザテスト
ユーザが評価 - エキスパートテスト
第3者が評価
やりやすさはユーザテストよりも優位
(4)ユーザビリティテストのガイドライン
(5)10年のユーザビリティテストの変化
- ソフトウェアからサービスへ
- 「使いやすい」から「楽しい」へ変化
(6)UXの時代へ
(6-1)UXの考え方、モデル
- ジェシー・ジェームス・ギャレットのUX
見た目のデザインしか考慮していない問題がある。 - ピーター・モービル
UXハニカム - UXPA
UXプロフェッショナル - UPA(現：UXPA)
ユーザエクスペリエンスフロー
(6-2)UXの期間
- 利用前
予期的UX - 利用中
一時的UX - 利用後
エピソード的UX - 利用時間全体
累積的UX
(6-3)UX事例
- UXを意識して設計
airbnb, LINE, ディズニー< スタバ - 次も体験しようとする設計
- 使う前、使う後、また使いたくなるのがUX
→ゲーミフィケーションも似ている。
(7)ユーザビリティからUXへシフトしたのか？
(8)ユーザビリティの担保は必要
(8-1)ユーザビリティの検証
楽しさ・心地良さは、ユーザビリティのようにテストできるか？
(8-2)UXテスト
- 楽しさ
生理指標。 - 心地よさ
サクサク感。
触覚。 - 価値がある
ある程度の期間を使って判断。
(8-3)リーンUX
- ユーザテスト
お金、時間、スキルが必要。
(9)UXを考慮したサービスの企画開発
- ISO9241-10
人間中心設計 - デザインリサーチ
定量調査(アンケート、データマイニングなど)
定性調査(インタビューなど) - カスタマージャーニーマップ
どのようにやっているか、思考過程を書く。
(10)まとめ
この先、魅力的な製品をつくるためにUXを考慮することは欠かせない。
(11)今後の参考情報
- SQuaRE
ISO25010 - CIF(ISO25062)
Common Industory Format for usability test
(12)デザイン北海道ブログ
http://designhokkaido.blogspot.jp/
所感
業務用組み込み系機器開発でも5～10年の間に「使い勝手」という言葉を経営層から管理者→開発リーダ→担当者の方向へ耳にするようになりました。しかし、現場の開発エンジニアからは「「使い勝手」をどのように考えて設計すればよいか分からない」との悲痛の声があがっていますし、テスト担当者からも「「使い勝手」をどのように考えてテストすればよいか分からない」との悲痛の声があがっています。悲痛の声を減らすには、ユーザビリティのガイドラインから仕様を具象化してみることも進めようと思います。また、UXについてはぼんやりとしたイメージしかないので、参考文献から理解を進めようと思います。
JaSST15北海道(3)「ビブリオバトル」
9/18(金)に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)に参加しました。
私が参加したセッションは下記です。
セッション1 基調講演：
「探索的テスト - アジャイル時代の効率的なテストを考える」
セッション3-3 探索的テストチュートリアル：
「やってみよう！探索的テスト。テストの常識を変えませんか？」
セッション4-1-1 ライトニングトークス
セッション4-1-2 ビブリオバトル
セッション4-1-3 JaSST Hokkaidoセッション：
「ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか」
以前書いた記事
今回は、セッション4-1-2「ビブリオバトル」を聴講メモをまとめました。
セッション4-1-2 ビブリオバトル
(1)セッションの内容
下記を参照下さい。
http://www.jasst.jp/symposium/jasst15hokkaido/report.html#bibliobattle
(2)ビブリオバトルのメモ
(2-1)書籍：「UNIXという考え方」 Mike Gancarz(著)、戦人：鶴谷 俊之
- 言いたいことは、表紙に書いてある。
- 表紙の内容にビビッと来る。
- 薄い本。
- lsコマンド。
- プログラムを作るときの哲学に通じる。
(2-2)書籍：「ソフトウェアプロセス改善手法SaPID入門」 安達 賢二(著)、戦人：長友 優治
- プロセス改善は仕組みが分からないことが多い。
- 安達さんとの出会い
- 本の中の人は、優しい(分かりやすい)。
- 問題構造図から因果関係が分かり、現場の人が取り組むので、適用範囲が広い。
- みんなを巻き込む。
(2-3)書籍：「「超」入門 失敗の本質 日本軍と現代日本に共通する23の組織的ジレンマ」 鈴木 博毅(著)、戦人：奥 大輔
- ビジネス書。
- 戦略、組織、指標。
- 初期のソースコード中にconst修飾子が3箇所あったが、開発が進む毎にconst修飾子の箇所が増加して保守で困ったが、本書で学んだことを応用し、const修飾子を使うことを止めた。
- 零戦に勝つことで、指揮を変えた。
(2-4)書籍：「これだけ！KPT」 天野 勝(著)、戦人：坂 静香
(2-5)書籍：「はじめよう! 要件定義 ～ ビギナーからベテランまで」 羽生 章洋(著)、戦人：浦山 さつき
- 2015年4月に出版された本。
- 要件定義を目玉焼きをつくるコックさんに例えている。
- 目玉焼きを食す人は、テスターと同じ。
- 企画→要件→要件定義だが、企画については書籍に書かれていない。
(2-6)書籍：「ゲーミフィケーション―<ゲーム>がビジネスを変える」 井上 明人(著)、戦人：根本 紀之
- 上手くのめり込むためのメタ。
- バグ報告時に実施したテストにプロレス技名を付けて点数化。
- 節電アプリで、ゲーム化。
- ドラクエ風スキルマップで、役割を明確にした。
所感
書籍との出会いは、何かを動かす一歩と思う。5分間に込められた現場の工夫や想いを書籍を通じて伝えることで知恵を巡らせることも必要だなと痛感しました。
JaSST15北海道(2)「探索的テストチュートリアル：『やってみよう！探索的テスト。テストの常識を変えませんか？』」
9/18(金)に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)に参加しました。
私が参加したセッションは下記です。
セッション1 基調講演：
「探索的テスト - アジャイル時代の効率的なテストを考える」
セッション3-3 探索的テストチュートリアル：
「やってみよう！探索的テスト。テストの常識を変えませんか？」
セッション4-1-1 ライトニングトークス
セッション4-1-2 ビブリオバトル
セッション4-1-3 JaSST Hokkaidoセッション：
「ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか」
前回書いた記事
今回は、セッション3-3 探索的テストチュートリアル：「やってみよう！探索的テスト。テストの常識を変えませんか？」でやったことをメモとしてまとめました。
セッション1 基調講演：「探索的テスト - アジャイル時代の効率的なテストを考える」 高橋 寿一
(1)資料
下記、JaSST'15 Hokkaidoレポートに掲載されていますので、参照下さい。
http://www.jasst.jp/symposium/jasst15hokkaido/report.html#tutorial1
また、基調講演の資料の26～43枚目もあわせて参照下さい。
(2)お題
スマートフォンのアプリを1つ選び、探索的テストを行う。
(3)選んだアプリ
電卓アプリ(Android OS)
(4)流れ
1.探索的テストのPass/Fail基準を書く。
2.下記5項目のタスクシートを書く。
1.タスクの記述
2.探索アプローチガイド
3.結果
4.終了条件
5.FAQ
※当日は、時間切れで2.探索アプローチガイドまで実施。
3.実際に探索的テストを行う。
※当日は、時間切れで未実施。
(5)私がやった記録
(5-1)探索的テストのPass/Fail基準
| 定義 | Pass基準 | Fail基準 |
|---|---|---|
| 機能性 | 四則演算ができること | 四則演算ができないこと |
| 信頼性 | 計算結果が正しいこと | 計算結果が誤っていること |
| 機能性 | ボタン入力が正しく入力されること | ボタンを入力しても何も出力(表示)されないこと |
| 機能性 | 最大桁数まで数値が入力できること | 最大桁数まで数値が入力できないこと |
| 信頼性 | 何らかの要因で電卓アプリが落ちないこと | 何らかの要因で電卓アプリが落ちること |
| 使用性 | メッセージ内容が理解できること | メッセージ内容が理解できないこと |
| 信頼性 | 様々な押し方をして、電卓アプリがクラッシュしないこと | 様々な押し方をして、電卓アプリがクラッシュすること |
| 信頼性 | 住宅ローンの金利計算が正確であること | 住宅ローンの金利計算がデタラメであること |
| 信頼性 | 飲み会の割り勘計算を何度行っても結果が同一であること | 飲み会の割り勘計算を何度行っても結果がバラバラであること |
| 信頼性 | 電卓アプリを動作することにより他アプリがクラッシュしないこと | 電卓アプリを動作することにより他アプリがクラッシュすること |
| 信頼性 | 年末調整の控除金額の計算が正しいこと | 年末調整の控除金額の計算が誤っていること |
(5-2)タスクシート
| 項目 | 内容 |
|---|---|
| タスクの記述 | 教科書の計算式を手計算と電卓アプリの2通りで行う |
| 探索アプローチガイド | 複雑な科学計算や役所の複雑な制度をネタにする。 |
| 結果 | (時間切れで記載できず) |
| 終了条件 | (時間切れで記載できず) |
| FAQ | (時間切れで記載できず) |
(6)頭をかち割るアイディア
(6-1)機会損失が無いことが品質
例えば、機会損失：デジタルカメラのバッテリ残量が知らないうちに無くなり、シャッターチャンスを逃すこと。
(6-2)ユーザ欲しいもの
どのような品質か？(例：満足度)
(6-3)いつ探索的テストを終わらせるか？
例：バッテリが切れるまで
(7)まとめ
探索的テストは、アプリケーションによってアプローチが違う。
所感
Android OSのスマートフォンに触るのは初めてであったが、電卓アプリの操作を試して挙動を確認した後、実際にPass/Fail基準やタスクシートを書いてみると、様々なアイディアが浮かんできました。本チュートリアルでは、3名1チームでワイワイ話し合いながら発表をまとめていましたが、2名の方のアイディアから新たなアイディアを思いつきましたので、探索的テストをペアで行うことも1つのアプローチと思いました。
頭の中にあるアイディアを書き出すと、記憶が揮発してもアイディア内容が復元できるだけでなく、プロジェクトマネージャにテストで考えたことや実施したことを説明できるので、探索的テストとad hocテストやランダムテストの違いを理解する一助になると思いました。
JaSST15北海道(1)「基調講演：探索的テスト-アジャイル時代の効率的なテストを考える」
9/18(金)に開催されたソフトウェアテストシンポジウム2015北海道(JaSST'15 Hokkaido)に参加しました。
私が参加したセッションは下記です。
セッション1 基調講演：
「探索的テスト - アジャイル時代の効率的なテストを考える」
セッション3-3 探索的テストチュートリアル：
「やってみよう！探索的テスト。テストの常識を変えませんか？」
セッション4-1-1 ライトニングトークス
セッション4-1-2 ビブリオバトル
セッション4-1-3 JaSST Hokkaidoセッション：
「ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか」
今回は、セッション1-1「探索的テスト - アジャイル時代の効率的なテストを考える」の内容で印象に残ったことをメモとしてまとめました。
セッション1 基調講演：「探索的テスト - アジャイル時代の効率的なテストを考える」 高橋 寿一
(1)講演資料
下記、JaSST'15 Hokkaidoレポートに掲載されていますので、参照下さい。
http://jasst.jp/symposium/jasst15hokkaido/report.html#keynote
(2)網羅せずにどうやって品質を担保するか？
デイリーリリースに対応するには？
→今までのテストのやり方で解決できない。
そこで、探索的テスト。
(3)開発現場の状況
(3-1)アメリカ(90年代)
- システムテスト
- テクノロジーがあれば、システムテストで全部のバグ見つかると妄想していた時代。
- Cem Kaner
- 全数テストは無理なので、探索的テストを考案。
→全数テストしきれないので、やり方を転換した。
- 全数テストは無理なので、探索的テストを考案。
(3-2)スクラム、アジャイル
- スピードが要求される
開発スタイルによって、テストのやり方を変える。 - 自動化テスト
Salesforce社などの企業で進んでいるが、日本は逆にあまり進んでいない。
(3-3)ゆっくり手動テストとかしていませんか？
開発スピードが速い状況で、ゆっくり手動テストするやり方がよいのか？
→旧来のテスト。
(3-4)旧来のテスト
- 徹夜したテストが実りあるものか？
- 現在は、開発者がコード書く速度が速くなった
- 網羅できているか？
- しかし、網羅するにはコストがかかる
- 自動車系：膨大なコードで、(網羅したテストが望ましいが)全部テストするのが難しいジレンマが...
(3-5)スキルのあるテスター
テスターの給料は、開発者より安い。
→しかし、テストはスキルが必要。特に創造力が必要。
(4)探索的テストとは？
(4-1)ソフトウェアテストの1つのスタイル
スタイルと手法は違う。
(4-2)テスト手法を駆使して探索的テストする
境界値分析や状態遷移テストなど。
→細かいテストケースは書かない。書く暇があったら、テストしよう。
(4-3)同時実行
短時間で分析～実行を行う。
(4-3-1)省くのは文章化
時間がかかるのは、文章化である。
(4-3-2)省くのは文章化時間がかかるもの
- 仕様の不明点を聞く
- 無駄な会議
上記は、テストしていない時間が多い。つまり、製品品質を上げる時間が少ないと言える。
(4-4)バグ発見
(4-4-1)テストケース10万件の0.5%しかバグ発見できない。
テスト仕様を書く時間で予算が多く費やされる。
(4-4-2) テストケースからは見つからない
- スキルのあるテスターが触りながらテスト。
- バグが見つかる。
- テストケース書かなくてもよくないか？
(4-4-3) 修士論文＠フロリダ工科大学大学院の話
- 「自動化で繰り返しテスト」
- Cem Kaner:
「それでバグが見つかるか？意味があるか？」 - 教訓:
バグの原因を開発者と考えることが大切。
- Cem Kaner:
(4-5)テストケースベースドの限界
要求が不明確で、変化するかもしれない。
→モノが出てから考える。
(4-6)要求仕様
(4-6-1)「要求仕様の抜けからバグが出てくるのでは？」 by 高橋寿一氏
(4-6-2)形式手法で書けば...
前提は、ちゃんとできるならば。
(4-6-3)早い段階で要求仕様のバグを発見
例えば、仕様追加部分でささっとテストして1～2日程度で済ませる。
(5)探索的テストのやり方
(5-1)情報源
(5-1-1)"General Functionality and Stability Test Procedure"
・James Bachの資料
http://www.satisfice.com/tools/procedure.pdf
「本資料をベースに探索的テストをやってみては？」 by 高橋寿一氏
(5-1-2)Cem Kanerのサイトに膨大ない資料がある
(5-2)探索的テストの定義
人によってバラバラ。
※補足：
『ソフトウェアテスト標準用語集 日本語版 Ver.2.3.J02』では、下記で定義している。
非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。[After Bach]
「Cem Kanerベースで定義を築きあげるとよい。」 by 高橋寿一氏
(5-3)探索的テストの成果
- バグの数、市場バグの数
- ウォータフォールのテストと比較してみる。
探索的テストチーム vs スクリプトテストチーム
(5-4)探索的テストとランダムテストの違い
(5-4-1)ランダムテスト
- 戦略が無い
- モンキーテストと同義
- 単位時間当たりのバグ発見件数は少ない。
(5-4-2)探索的テスト
- 戦略がある。
- 単位時間当たりのバグ発見件数は少ない。
(5-5)多くのテストケース
- 殆どが無駄になる。
- 一方、開発者の「嫌だな～」というところをテストケースを作ると、バグが出てくる。
(5-6)バグがどこに出てくるか？
(5-6-1)最近の傾向(研究)
- ファイルが長い(サイズが大きい)
- ファイルが頻繁に変更
(5-6-2)7%(hotspot)のファイル
理論的には全てのバグが出る。
(5-6-3)80%のバグは全体の20%のモジュールから発見され、50%のモジュールにはバグは含まれていない。
50%のモジュールから市場不具合としてインパクトは小さい。
→レアケース
(5-6-4)テスト実行前に何のコンポーネントがバグがあるか分からない。
(5-7)タスクシート
- テストリーダが戦略を書くべき。
- ノウハウを共有するという意味でで書いておくとよい。
- テストケース(状態遷移とか)を考えるようなスキルセットが必要。
- 何かニオイを感じる人。
- 戯れているだけの人。
(5-8)探索的テストで大切なこと
ユーザにとって嫌な思いをさせないテスト。
(5-8-1)ユーザにとってそのソフトウェアをユーザの権利を奪わずにテストを担保できるか？
- 例：Excelの90%は使われていない機能。
- どこが必要な機能か？
- 頭を使う
- 要求仕様
- ユーザクレームから、製品のあるべき姿を考える。
- ユーザ視点を考える。
(5-8-2)バグの出るポイントでちゃんとテスト
(5-9)ドキュメント
- 最低限、戦略は書く
- Pass/Fail基準
- １つ１つのテストケースは書かない
(6)探索的テストの注意点
(6-1)非機能テスト(セキュリティなど)は探索的テストをあまりやらない
- 理由:
- 大変なため
(6-2)ユーザビリティテストは有効
(6-3)探索的テストのみに頼らない。
(6-4)終了判定
基準を決めておくとよい。
「"テストケース99.7%Passしたら出荷する"や"信頼成長曲線が寝たら..."は、違和感がある」 by 高橋寿一氏
(7)探索的テストの人材の問題
どういうスキルが必要か？
→プログラミングのスキルは必要。アメリカでは、コード書けるテスターが必要。
(8)Q&A
Q1：探索的テストで品質担保の説明をどうすれば...
A1：テストケースから品質担保の説明はできないと思う。
- コードの20～30%しかテストできていないのため。
- どうやって品質を担保できるかというone of themで探索的テストがある。
Q2：探索的テスト初期段階に陥りやすいことは？
A2：数チームでやりながら悩んで、メトリクスを取ってみる。
探索的テスト以外のチームと仲良くなり、探索的テストと探索的テスト以外で比較してみる。
Q3：「探索的テストの人材」の話でプログラミングスキルが必要と言及していたが、どういうところで必要か？
A3：境界値テストの場合、プログラミングのif/else文を理解する必要があるから。
例えば、sleep()のところにバグが多いな！など。
→プログラミングの構造を知ることが大切。
所感
探索的テストとad hocテスト/ランダムテスト/モンキーテストの違いがよく分からない話題が時折見かけるが、「戦略の有無」がポイントの1つであることに気付いた。また、タスクシートでPass/Fail基準を明確化すると、ad hocテスト/ランダムテスト/モンキーテストに陥らないので、工夫する内容の1つとして実践しようと思います。
私の中で暗黙的にPass/Fail基準はあるが、製品のあるべき姿を開発者と話したり、インシデントレポートに図解することで形式知として共有することを続けていこう。
今後の課題は、プログラミング構造を深く知ることである。テストケースを細かく書かなくても、バグを発見できるようにすることで、開発で手戻り工程が少しでも減らせるよう、多少のテストケースを書きながら工夫してみようと思う。
過去の私が書いたblog記事も探索的テストを実施する際のヒントになると思いましたので、時折読み返そうと思います。 masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com masaoapril.hatenablog.com
考える大人になるためのツール 国際認定プログラム2015(4)「アンビシャス・ターゲット・ツリー」
2015/8/13(木)～16(日)に京都大学で開催された「考える大人になるためのツール 国際認定プログラム 2015」に参加しました。参加した内容及び感じた事を書きます。
アジェンダ
<1日目>
自分の行いに責任が持てるようになる「ブランチ」
<2日目>
論理的に考え、検証できるようになる「CLR」
<3日目>
ジレンマを解消できるようになる「クラウド」
<4日目>
夢をかなえる「アンビシャス・ターゲット・ツリー」、全体のまとめ、認定資格授与式
以前書いた記事
<4日目>夢をかなえる「アンビシャス・ターゲット・ツリー」
(1)アンビシャス・ターゲットとは？
- 前向き、大変望ましい目標。
- 目標達成するには、戦略的計画が必要。
(2)アンビシャス・ターゲット・ツリーの作成手順
(2-1)手順1：ターゲットを特定
(2-1-1)前向きな目標を見つける。
(2-1-2)ポイント
- 明瞭に定義する。
- 専門用語を確実に理解。
- 学ぶべき主張や概念。
- 全員が確実に理解する。
(2-2)手順2：一連の障害(できないこと、言い訳など)を認識し、リスト化
(2-2-1)障害
- アンビシャスターゲットを妨げる。
- 疑問系ではなく、状況。
(2-2-2)障害を認識
障害を対策する方法を考える。
(2-2-3)障害を特定
既存知識を必要とする。
(2-2-4)ポイント
- 目標の「主語(目標のために行動する人)」が何か明確にしないと、空中戦になることもある。
- 全ての障害を出しきる必要はない。
- 途中で障害が追加されることもある。
- 事実関係の確認
- 暗示されている詳細情報を推察する。
- 「本当か？」
- 「なぜ、障害が目標達成を阻害していると感じるか？」→「なぜなら、･･･」
- 暗示されている詳細情報を推察する。
(2-2-5)例
(2-3)手順3：中間目標を提示
「何を、どういう形になればよいか？」
(2-3-1)例
(2-3-2)ポイント
- 中間目標を考えるとき、「行動」＋「目標」と混同することがある。
- 決め打ちで作るときは仕方がない。
- 「行動」が混入しないようにするのが望ましい。
例：
・Before
もやしを育てる。
・After
船内で食料が出てくる。
(2-3-3)中間目標を評価
「もし、◎◎ならば、結果として△△」で説明できるか？
(2-4)手順4：中間目標を整理、並べ替える
(2-4-1)順序
- 仮定や推測が隠れている
- 前提を想定する
- 根っこの中間目標を達成すると、以降の中間目標が達成しやすくなる。
- やりやすいことから行動するのではなく、やるべきことから最初に行動する。
(2-4-2)検証
「中間目標1」が「中間目標2」より前に発生しないといけない理由を説明できるか？
(2-4-3)例
(2-5)手順5：一連の行動をリスト化
(2-5-1)ターゲット
- 障害
目標達成を阻害する状況。 - 中間目標
障害を克服するための状況。 - 行動
中間目標を実現するための具体的な行動。
(2-5-2)例
(3)アンビシャス・ターゲット・ツリーを作成後の変化
好奇心や考える力により問題解決能力が向上する。
例：
・Before
闇雲に練習する。
・After
中間目標を確認し、できたか否かを確認する。
所感
今回の演習を通じ、「目標に対する阻害要因(障害)は何かを認識すること」「目標達成するまでに至る中間目標の繋がりを整理すること」「一連の行動をリスト化することにより、自分ができたこと/これからやることが明確になること」を念頭に置くと、悩みを解決することが楽しくなると思いました。業務でもプライベートでも問題vs我々(私)の構図でアンビシャス・ターゲット・ツリーを書いてみようと思います。
考える大人になるためのツール 国際認定プログラム2015(3)「クラウド」
2015/8/13(木)～16(日)に京都大学で開催された「考える大人になるためのツール 国際認定プログラム 2015」に参加しました。参加した内容及び感じた事を書きます。
アジェンダ
<1日目>
自分の行いに責任が持てるようになる「ブランチ」
<2日目>
論理的に考え、検証できるようになる「CLR」
<3日目>
ジレンマを解消できるようになる「クラウド」
<4日目>
夢をかなえる「アンビシャス・ターゲット・ツリー」、全体のまとめ、認定資格授与式
前々回、前回
<3日目>ジレンマを解消できるようになる「クラウド」
(1)対立事項の分析
- 解決方法を考えること
- 自分が非難されたとき、何が起こるか？
- 結果：反発して守りに入る。
- 悪影響：正しい論理で思考しない。反発して守りに入ることで、問題解決から遠くなる。
- 立場や解釈により、見え方が異なる。
問題解決に向けて
- Step by Stepで考える。
その他
- 絵で表現した事例もある(5歳児)
- 書籍「ザ・ゴール 2 ― 思考プロセス」に実践例がある。
(2)クラウドを書く
(2-1)問題を特定する。
- 対立やジレンマ
- 「対立」：同時に行動できないこと
(2-2)解釈、分類、自らの言葉で話す。
(2-2-1)意思決定する基準
- 行動に至る要望を特定
- 「要望」:強い動機付け
(2-2-2)問いかけ
- 「重要か？」
- 「必要か？」
- 「得られるものは？」
(2-2-3)注意事項
- 行動と要望を混同しないこと。
- 行動と要望の区別(境界)は？
- 行動→異動したい
- 要望→異動させたくない
(2-3)目標を設定する
- 解決策ではなく、2つの対立の共通目標。
- 「共通目標」：理想的な状況(※ただし、解決策ではない)
- 複数の要望
- 一番強い要望に対する目標
(2-4)一例
(3)解決策を評価
(3-1)避ける、あきらめる
Win-Winの関係にならない。
→Win-Lose関係または、Lose-Win関係。
(3-2)強制、綱引き、妥協
Lose-Loseの関係
(4)Win-Winの関係を見つけるには？
(4-1)直感的方法
クラウドを書いて、見直したときに直感的に思いつく。
(4-2)システマティックな方法
仮定を崩せるか検証。
(4-2-1)検証方法
- 「この仮定は本当ですか？」
- 「この仮定は、実在しますか？」
- 「常にそうなのか？」
(4-2-2)仮定を崩せる案＝解決案
仮定にチャレンジするから、解決策が考えられる。
(4-2-3)ポイント
- 「仮定」を常にチェックせよ
- 「要望」-「対立」の仮定に感情が入っている。
仮定の詳細を深入りし、感情を尊重する。
(5)Q&A
Q1：「クラウドを作るとき、どの程度、調査するか？」
A1：「当事者とクラウドを作るとよい」
Q2：「一人でクラウドを作るとき、一方の仮定が多くなり、他方の仮定が少なくなるのはよくないか？」
A2：「Win-Win関係への解決なので、仮定の数が同じである必要はない」
所感
今回の演習を通じ、頭の中にあるものを紙やディスプレイにクラウドの形で出すことで、自分という立ち位置を仮想的に第3者として見ることができると実感しました。書いてみてふりかえることは、習慣として諸々進めようと思います。
