2018/6/23(土)、「サプライズデザイン」の話を聞いてきました

オンラインの飲み会で @nemorine にサプライズデザインの話をしていただきました。

connpass.com

「サプライズデザイン」は @nemorine が得意とする、相手にサプライズを実行する際の方法論です。

サプライズデザイン（公開版） from Noriyuki Nemoto

www.slideshare.net

内容まとめ

全編通して面白かったのですが、特に印象に残った部分についてまとめてみます。

• 現実と認識を乖離させる

• 油断させる

• 感情の袋を大きくする

• 上手な伏線を張る

• 過去の記憶を呼び覚ます

現実と認識を乖離させる

現実と認識の乖離が大きいほど、サプライズとしての成功となる。サプライズを単発で、時間をおいて実施すると認識が戻ってしまう。そのため、サプライズは畳みこむように連続することで相手を混乱させて乖離を大きくさせる。サプライズが大きすぎると人が壊れるらしい。エゲツナイ。

油断させる

サプライズを効果的にするために、サプライズを相手が認識して緊張が解れたところに別のサプライズを畳みかける。緊張が解れたことで無防備になったところにサプライズをすることでサプライズの効果が増大する。エゲツナイ。

感情の袋を大きくする

「感情の袋」を大きくする。いかなる感情も一つの袋に入っていて、大きくなったり小さくなったりする。サプライズは驚きなどで相手の「感情の袋」を拡張させて、最後に嬉しい感情にすることで大きな嬉しさを相手に与えることができる。吊り橋理論なども「感情の袋」の考え方で説明できそうなので、自分の直感にも合う話だと感じました。

上手な伏線を張る

サプライズチェーン。サプライズを日常に紛れさせる。できるだけ相手の選択を活かすことで、本当に偶然なのか、仕組まれたのかを相手が判断できなくなる。疑心暗鬼になってくるらしい。エゲツナイ。

過去の記憶を呼び覚ます

過去の記憶を思い出させることをサプライズとして利用するのが、強い印象を相手に与えることができるので有効。過去の記憶というのは「非日常」なことでもあるので、サプライズに利用することが効果的なのは凄く納得できました。

まとめ

実施例の紹介もありましたが、サプライズが凄い練られていて相手が壊れる(お酒を飲んでいないのに酔っているような状態になる)のも仕方がないと感じました。みんなでサプライズ対象一人のことをこれでもかというぐらい考え抜いたからことできる凄まじさがありました。サプライズは自分ではとても真似できそうにありませんが、その要素の考え方はどこかで活かしたいと感じました。

2018/5/12(土)、とちぎテストの会議05に参加してきました。

隔年で行われる、とちぎテストの会議(とてか)に参加してきました。今回のテーマは『自画自讃』でした。

d.hatena.ne.jp

今年で3回目の参加になります。

とちぎテストの会議04
2016/4/23(土) 「とちぎテストの会議04」に参加してきました。 - toshimana's diary

とちぎテストの会議03
10/4(土)「とちぎテストの会議03」に参加してきました。 - toshimana's diary

「あのチーム」については過去に仙台で講演していただいたこともあり、その時のことも記事にしていました。*1

那須のチームに対して、何が羨ましいと思うのか - toshimana's diary

はじめに

申し込みが凄く早く埋まっていることから、とちぎテストの会議(「あのチーム」)に対する関心は凄く高いということが伝わってきました。

一般公演

一般公募で発表を希望した参加者による発表セッションです。フリーテーマにも近いので色々な話が聞けて面白かったです。

【新人さんからわかるテストマンガ「テスターちゃん」誕生秘話と製作法】

一部界隈では大人気の「テスターちゃん」の産みの親からの貴重な製作に関するお話。個人的には、上司：「テストの本って分かりにくいよね」→ 松谷さん「じゃあ作りますね」→ 上司「こんな風になるのは予想してなかった」の流れが面白かったです。

新人さんからわかるテストマンガ 「テスターちゃん」 誕生秘話と製作法 from Mineo Matsuya

t.co

【プロジェクトという絵】

メンバー選定からリリースまでかかわったプロジェクトの話。最初から最後までやったときの意図や、その結果どうなったかの振り返りの話が語られており、「生きた話」でとても参考になりました。

【テストへの視野狭窄に気づいた話】

「加賀ゆびぬき刺し模様シミュレータ」におけるテストケース見直しでの気付きを記載した発表でした。見直しにあたり、多くのテストケースを削除したけれど、それに対して「メンテナンスを助けるものではなかった」とした考えは見習いたいと思います。

play.google.com

テストへの視野狭窄に気づいた話 - Toteka 05 from ichiko_revjune

www.slideshare.net

【探索的テスト好きを作った話と、探索的テストからスクリプトテストを作ってみた話】

自分で考えてテストするのが得意でない人が探索的テストをできるようになった話と、探索的テストで行ったテストをよく記録するようになった話で、現場感の伝わる発表でした。探索的テストが好きになった代わりにスクリプトテストが嫌いになってしまった人の話は笑い事ではないけど面白かった。

探索的テスト好きを作った話と 探索的テストからスクリプト テストを作ってみた話 from Nobuhiro Yoshitake

www.slideshare.net

【QAテスターのいないWebサービス開発におけるテストと開発モデル】

QAテスターがいない開発でどうやって品質を担保しているかのお話でした。バディ(相棒)テストなど、品質を担保するために様々な工夫をしていて面白そうでした。

speakerdeck.com

【働きやすい職場をつくる「不安マネジメント」のススメ】

発表しました。

20180512 recommendation for_anxiety_management from Toshiyuki Manabe

t.co

【失敗事例に学ぶテストプロセスの改善】

過去のプロジェクトをTPI NEXTで評価・比較する内容の発表でした。コミュニケーションがそこそこ上手くいっても、仕事の段取りが上手くいかないとつまづく、というのは身につまされる話でした。

【テストラジオを支えるイロイロ】

テストラジオの誕生から現在の運用の話まで幅広く語っていただいた内容でした。1年以上継続しているからこその、安定した話し方は凄いと感じました。

t.co

『自画自讃』外から編

「あのチーム」について、秋山さん、和田さん、関さんを中心に議論するパネルディスカッションでした。中心とはいっても、参加者も割と発言できるようになっていて、どんどん議論が広がっていく感じがありました。

以下、4つのテーマがありました。

1. 毎日すべてのテストをしてるって、本当ですか？
2. TDDやめちゃったけど、どうしてですか？
3. 何が違うの？あのチーム
4. みんなの問題にする、ということ

『自画自讃』内から編

「外から編」はパネリスト間の議論が中心でしたが、「内から編」はより参加者通しで議論ができるようになっていました。「あのチーム」を疑似体験できるように、「あのチーム」内でよく使われている言葉を元に議論をしていきました。

以下、4つの言葉を対象に議論をしました。

1. 「上手くいったらどうなるの」
2. 「早く見つかってよかったね」
3. 「再現させたら、わかるの」
4. 「わかんない」

Party & LT

2分間のLTを会場で募集していたのですが、30人くらい話していた気がします。参加者の半分くらいはLTで話していたのではないかと思います。みんなの参加意識がとても高いところが、とてかの魅力の一つだと感じました。

おわりに

会場で活発に話し合いが聞こえてくるくらい、とても盛況な会議でした。楽しい時間を過ごすことができたのは、運営、講演者、参加者の力が合わさったからだと思います。ありがとうございました。

*1:「あのチーム」＝那須のチーム

HAYST法について考える。「Verification／Validation／Estimation」

はじめに

2018/1/26-27の二日間でJaSST東北実行委員会では「HAYST法」のワークショップ準備会を行いました。その中で得られたHAYST法の知見について整理もかねて公開します。今回は「HAYST法」の軸となる考え方の一つである「Estimation」についてまとめます。

※内容は理解途中のものです。予告なく変更する場合があります。

HAYST法

富士ゼロックス社の秋山浩一氏が考案したテスト技法です。

システムテストを対象として、テスト対象分析やテストアーキテクチャ設計まで網羅する総合的なテスト技法*1です。

特徴として、実験計画法や品質工学で使われている直交表を用いて、効率的な組み合わせテストを軸として扱うことが挙げられます。

www.fujixerox.co.jp

事例とツールで学ぶHAYST法―ソフトウェアテストの考え方と上達のポイント

ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方

VerificationとValidation

品質評価は「Verification」と「Validation」の2つの視点で語られることが多いです。

www.itmedia.co.jp

上記ページでは以下のように説明されています。

• 検証(Verification)

対象が仕様・設計・計画などの要求事項を満たしているかに関する確証

• 妥当性確認(Validation)

対象の機能や性能が本来意図された用途や目的に適っているか、実用上の有効性があるかについての評価

一般的なソフトウェアテストは「Verification」の意で使われることが多いように思います。しかし、「Validation」が満たされない場合、製品が目的を達成できないことになります。「Verification」だけでなく「Validation」も意識してテストをすることは非常に重要です。

Estimation

「HAYST法」は「Verification」と「Validation」のどちらになるのでしょうか。

HAYST法ではvalidationではなくestimationを行います。estimationを日本語にすると評価となります。普通はevaluationを評価と訳しますが、estimationを当てています。estimationは見積りつまり、未来の予測という意味です。

— akiyama924🍢 (@akiyama924) 2018年1月26日

「HAYST法」は「Estimation」とのことです。「Verification」と「Validation」のどちらでもありませんでした。

ここでは、「Estimation」は評価／予測の意で使われています。

目的機能による未来の予測

「HAYST法」における「Estimation」は「目的機能」が対応します。

何を予測しているかというと、FV表の目的機能を予測しています。
HAYST法ではテスターが予測した未来に対する合否基準をもとにテストを行って、その合否をエビデンスとして残します。

連ついお終い。

— akiyama924🍢 (@akiyama924) 2018年1月26日

「HAYST法」では、テスト対象のライフサイクルにおいて利用者に対する価値が最大になるような未来を「目的機能」によって予測します。「目的機能」によって定めた予測が正しいことを様々なテストによって評価します。

「目的機能」はテストエンジニアが渡された仕様書を元に創造力を働かせて設定します。「HAYST法」では「目的機能」を導く手順として「6W2H」や「ユーザーストーリー」などを用いた手法が想定されています。

おわりに

「機能が実現できているか(Verification)」や「目的を達成できるか(Validation)」は、ある時点(主に開発完了時)に着目した視点になります。「HAYST法」では「ライフサイクルにおいて利用者に最大の価値を届けられるか(Estimation)」を視点として加えることで、価値ある製品／サービスのためのテストを創造することができます。

宣伝

2018/5/25(金)に行われるJaSST東北では「HAYST法」に基づいたテスト要求分析／テスト設計のワークショップを行います。
振るってご参加ください！

JaSSTソフトウェアテストシンポジウム-JaSST'18 Tohoku

*1:フルスペックの場合。フルスペックではなく部分的に適用することも可能

「本当の支援」を実現するための技術

大層なタイトルで始まっていますが、2017年度振り返りを兼ねた記事になります。
2017年度に読んだ本として最も印象に残った「支援学」とその関連技術についてまとめました。

はじめに

個人的に人を活かすための技術についてを調べたりするのが好きなのですが、体系だった分野ではないので人と話をする機会がありませんでした。しかし、勉強会の一環で人を活かす技術をワーク形式で紹介したところ、予想以上に好評をいただいたのでまとめて公開してみようかと思いました。

支援学

ここでの「支援学」は、エドガー・H・シャイン先生による以下の書籍で論じられているものを指します。

人を助けるとはどういうことか 本当の「協力関係」をつくる7つの原則

支援については、監修者による序文で述べられた以下の言葉が分かりやすいです。

ヘルピング──人の助けになる行為が、原著の書名だ。ヘルプは「支援」、ヘルピングは「支援行為」と本書では訳しているが、いちばんいい日常語は、「相手の役に立つこと」。そして相手にそう思ってもらえる行為がヘルピングである。

人を助けるとはどういうことか 本当の「協力関係」をつくる7つの原則

「相手の役に立つこと」。分かりやすいですね。

本当の支援

シャイン先生は別の書籍で「本当の支援」についても言及しています。

謙虚なコンサルティング――クライアントにとって「本当の支援」とは何か

最初のたしかな支援とは、コンサルタントの手助けによって、クライアントが、問題となっている状況の本当の複雑さと厄介さを理解し、その場しのぎの対応や反射的な行動をやめられるようになることだ、と。そのうえで、適切なアダプティブ・ムーヴを展開し、本当の現実──コンサルタントとしてクライアントに目を向けてもらうようにすべき本当の現実──に対処することが、本物の支援なのである。

謙虚なコンサルティング――クライアントにとって「本当の支援」とは何か

書籍ではより具体的な内容についても記載されているので、ぜひ手に取ってみてください。私の理解として、本当の支援は「相手と自立／自律できるような手助けをすること」に言い換えられると考えます。

役に立つ支援のために

役に立つ支援を行うためには以下のようなことを意識する必要があります。

公式な支援をするには、支援者と「クライアント」──支援を受ける人々を私はこう呼ぶが──との間に、ある程度の「理解」と「信頼」がなければならない。

人を助けるとはどういうことか 本当の「協力関係」をつくる7つの原則

相手の理解

どんな支援が相手に役に立つかを知るためには、相手がどのような人間なのかを理解する必要があります。

支援者にとって「理解」が必要なのは、いつ支援を申し出ればいいか、助けを求められた場合はどうすれば役に立つかを知るためである。

人を助けるとはどういうことか 本当の「協力関係」をつくる7つの原則

相手が常に支援を必要としているわけではないし、支援が必要なのに周りに相談できない状況なのかもしれません。また、いざ相談を受けた場合に、相手が抱える問題に対してどのような支援が役に立つかを支援する側が知らなければなりません。何が相手にとって役に立つのかを知るために、相手を理解するプロセスが必要になります。

信頼関係の構築

相手が抱える真の問題を理解するためには、相手との信頼関係を築く必要があります。

クライアントにとって「信頼」が必要なのは、真の問題は何かを突きとめるためだ。そして、提供された支援を受け入れ、支援者との会話から生まれた解決策を実行するためである。

人を助けるとはどういうことか 本当の「協力関係」をつくる7つの原則

真の問題は相手の心の奥底に触れるものがほとんどです。迂闊にさらけ出したときに攻撃を受ける不安から、相手が真の問題を打ち明けられないことは容易に起こります。そのため、相手と信頼関係を築き、相手に「真の問題を打ち明けても危険がない」ことを理解してもらうプロセスが必要になります。

以下の構成

「本当の支援」を実現するためには、以下についてより深く理解する必要がありそうです。それぞれについて、私が個人的に重要だと思う技術／考え方について整理していきます。

• 相手の理解

• 信頼関係の構築

• 支援の仕方

相手の理解

相手を理解するための考え方として、以下の3つについて言及します。

• 相手の役割(ロール)を被る

• 目的論：アドラー心理学

• 仮説検証

相手の役割(ロール)を被る

これは相手を理解するための考え方として私が勝手に名付けている手法です。近い手法として「ペルソナ分析」や「ロールプレイングゲーム」が挙げられます。

jasst-tohoku.hatenablog.com

speakerdeck.com

ペルソナ分析やロールプレイングでは、仮想の相手や理想像を被りますが、ここでは実在の相手の役割を被ります。

相手のことを考える際に良く起きる問題として「過度の期待」を持つことが挙げられます。「相手ならどう考えるか」では、自分が相手に抱く理想像ベースで考える傾向があると思います。そのため、想像した相手の考えが実際と大きくずれる傾向にあります。

「相手の役割を被る」では、相手の役割や環境を自分が持っていると想定して「自分ならどう考えるか」で考えます。「自分が相手に向けていた期待を自分が受けたらどのように感じるか」を評価できるため、相手に対する「過度の期待」を抑制します。このことから、自分の想像と実際の相手とのずれを小さくすることができます。

目的論：アドラー心理学

アドラー心理学の中心的な考え方の一つとして「目的論」というものがあります。

嫌われる勇気―――自己啓発の源流「アドラー」の教え

彼が「目的」に沿った行動をとっていることは間違いありません。彼にかぎった話ではなく、われわれはみな、なにかしらの「目的」に沿って生きている。それが目的論です。

嫌われる勇気―――自己啓発の源流「アドラー」の教え

「目的論」は「全ての感情や行動はある目的を達成するために生み出される」という考え方です。相手の行動が相手にとってどのような意味を持つかを考えることは、相手を理解することに大きく貢献します。相手が何を大事にしているかは直接話をしてくれない場合が多いです。目的論に基づいて相手の行動からその目的を想像することは、相手の人物像を構築するのに非常に役に立ちます。

仮説検証

相手の考えを想像することは、相手を理解するために欠かせないプロセスです。しかし、相手に対して想像を働かせるときの注意点として「実際の相手」と「自分の想像」が異なることが挙げられます。あくまで自分が想像する相手は「仮説」であることを常に頭に置いておく必要があります。

仮説思考 BCG流 問題発見・解決の発想法

仮説検証は論文を書くときにも使われるプロセスですが、相手への理解を深めるプロセスとしても有用だと私は考えます。相手が自分の想像通りに動いてくれなかったときに、自分の考慮不足を相手の問題に置き換えてしまうことは良くある思考パターンです。自分の想像を「仮説」とすることで、相手が想像通りに動いてくれなかった時でも「仮説が誤っているから自分の想像を修正する」と健全な方向に向かいやすくなるように思います。

信頼関係の構築

信頼関係を構築するための考え方として、以下の3つについて言及します。

• 心理的安全性

• 謙虚に問いかける：支援学

• 対等な関係：アドラー心理学

心理的安全性

心理的安全性は社員の「生産性」を高めるための唯一の方法としてグーグルが2016年に公開し、有名になった言葉です。

gendai.ismedia.jp

www.nytimes.com

心理的安全性はエイミー・C・エドモンドソン先生による書籍が詳しいです。

チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

「心理的に安全な」というのは、人々が何か困ったことになるのではと不安に思うことなく自由に、関連する考えや感情を表現できる雰囲気のことだ。

チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

心理的に安全な環境であれば、自分の意見を率直に話すことができ、問題を打ち明けても周りが受け入れてくれると信じることができます。支援を実現するうえで、相手が真の問題を打ち明けやすくなるように心理的に安全な環境を構築することを常に意識しておく必要があります。

心理的に安全な環境を構築するためには、話しかけやすい雰囲気を作ったり、支援する側も間違えることを積極的に示すことが有効とされます。特に「弱さ」を自分からさらけ出すことは有用だと感じます。

なぜ弱さを見せあえる組織が強いのか――すべての人が自己変革に取り組む「発達指向型組織」をつくる

自分の弱さを隠すという「もう一つの仕事」に誰もが明け暮れている組織の状況を考えてみてほしい。経営者は、そのような仕事しかしていない人にフルタイムの給料を支払っている。しかも、弱点を隠している人は、その弱点を克服するチャンスも狭まる。その結果、組織は、その人の弱点が日々生み出すコストも負担し続けることになる。

なぜ弱さを見せあえる組織が強いのか――すべての人が自己変革に取り組む「発達指向型組織」をつくる

「真の問題を晒すことで自らの価値が低くなる」という不安は想像以上に大きく、私たちの「弱点を隠す」行為は真の問題に割くべき労力の大部分を占めることになります。支援する側として「弱点を晒しても問題がない」ということを自らの振る舞いで証明していく必要があります。

謙虚に問いかける：支援学

シャイン先生の「支援学」の中でも特に問いかける技術についてはこだわりを感じます。「謙虚に問いかける」ことは信頼関係構築の中軸となる技術といえます。

問いかける技術――確かな人間関係と優れた組織をつくる

「謙虚に問いかける」は、相手の警戒心を解くことができる手法であり、自分では答えが見出せないことについて質問する技術であり、その人のことを理解したいという純粋な気持ちをもって関係を築いていくための流儀である。

問いかける技術――確かな人間関係と優れた組織をつくる

相手の話を聞く以上に支援をする側が相手へ話し過ぎる場合があります。これは自分の知識を伝えたい、という想いが先行するからこそ行動だと思います。しかし、支援に必要なのは、相手が抱える真の問題を、相手の言葉で理解することにあります。謙虚に問いかけることにより、相手に何が問題と感じているかを表現してもらいます。問題の感じ方は人によって差が大きいため、自分が想像していたことと相手の認識が異なることを、問いかけることによって気付くことは大いに起こります。また、相手が忌憚なく自身を表現をするためには、「聴き手がその話に関心がある」という意識を相手が持てることが重要になります。謙虚に問いかけることは、支援する側が相手に関心があることを伝える有力手となるため、信頼関係を構築するための強力な武器となります。

対等な関係：アドラー心理学

支援の難しさとして、支援を受ける側が支援する側と比べて一段低い立場になりやすいことが挙げられています。

感情的、社会的に見れば、支援を求めた場合、人は「一段低い位置」に身を置くことになる。これは次にすべきことがわからないとか、できないといった、一時的に地位や自信を失った状態だ。独立心が失われ、他人から助言を受けたり、癒されたり、面倒を見てもらったり、助け起こされたり、支えられたり、さらには仕えてもらうことまで入っている。

人を助けるとはどういうことか 本当の「協力関係」をつくる7つの原則

しかし、支援する側と支援を受ける側が自由な意見を言いあるような対等な関係であるべきです。本当の支援を実現するうえで目指すべきは上下(縦)ではなく対等(横)の関係です。

アドラー心理学ではあらゆる「縦の関係」を否定し、すべての対人関係を「横の関係」とすることを提唱しています。

嫌われる勇気―――自己啓発の源流「アドラー」の教え

「縦の関係」が支援をする上で避けるべき理由は「自分よりも能力の劣る相手を操作する」意図が含まれやすくなることです。例えば、誉める行為は「能力があるものから能力が劣るものに対する評価」となり、支援を受ける側に対して「自分には能力がない」という意識を生み出すことになります。支援をする側と支援を受ける側は対等であることを目指し、支援をする側は支援を受ける側を「評価」せず、純粋な言葉を相手に投げかける必要があります。

支援の仕方

支援そのものを支える技術として、以下の2つについて言及します。

• アクティブラーニング

• 問題分析

アクティブラーニング

支援を受ける側の学習として、支援する側が教えるのではなく、支援を受ける側が自身で考えた方が物事をより深く理解することができます。いわゆる「アクティブラーニング」が効果的だと考えられています。

自分の頭で考えて動く部下の育て方 上司1年生の教科書

私は物分かりが悪いのでよく「すみません、今のところをもう一度説明してください」と頼む。するとどういう言葉なら私に分かってもらえるか、考えたうえで説明しようとする。そのように能動的に取り組むと、理解も深まり、忘れなくなるものらしい。　受け身ではなく能動的、主体的、自発的になることが理解と記憶を深めるらしい。「教えない教え方、これはなかなかいいぞ」　本書の「自発的部下醸成方式*1」に気づいた瞬間だった。

自分の頭で考えて動く部下の育て方 上司1年生の教科書

支援する側は教えず、基本的に考えることは相手に一任します。支援する側は相手に対して問いかけを行うことで、相手がより深く物事を考慮できるように支援を行います。アクティブラーニングの難しいところは、相手が答えを教えてもらえない事にストレスを感じる場合があることです。アクティブラーニングによる支援は、支援をする側と受ける側が「対面」に立つのではなく、「問題に対して同じ方向を向いている」事を示す姿勢が重要になります。そのため、相手の意見を尊重し、もっと良くするために何ができるかを一緒に考えていく必要があります。

問題分析

人が抱える問題は単純ではなく、様々な問題が絡み合っていることがほとんどです。相手が抱える真の問題を、支援する側が直接解決できることはほとんどありません。しかし、複雑に絡まった問題を整理し、相手がどこに力を割くべきかを知るための助力を行うことは可能です。

問題を分析する手法として世界的に知られているものの一つにTOC*2の思考プロセスがあります。

ザ・ゴール コミック版

また、個人的にはSaPIDという手法を用いることが多いです。TOC思考プロセルと比べて柔軟性があり、多くの状況に対応しやすいことが理由です。

ソフトウェアプロセス改善手法SaPID入門―現場力を引き出すシステムズアプローチ

問題を分析して見える化することで、問題同士の関係が整理できることが利点として挙げられます。それ以上に、問題を整理することで元々「真の問題」と思っていたことよりも、より重要な問題に気づける場合があります。現状の整理と今後の行動を決めるために、問題分析手法を用いたサポートは相手が前進する極めて大きな助けとなります。

おわりに

現時点の私が考える「本当の支援」とそれを実現するための技術／考え方をまとめてみました。良いものを作るためには専門的な技術も必要ですが、それ以上に人とどのような関係を築くかが重要だと考えます。私が関わる全ての人が前を向いて進めるような支援ができるように、自分にどのようなことができるのかはまだまだ考えて実践していきたいと思います。2017年で築いた自分の考えを晒すことで2018年はいろんな人と人を活かす考え方について色々話ができればいいな、と期待をもって2017年のまとめとしたいと思います。良いお年を！

*1:私はアクティブラーニングとほぼ同質と理解しています

*2:Theory Of Constraints.制約理論

11/18(土)、「未来予想型チーム運営ワークショップ」に参加してきました。

SaPID*1とTOC(CCPM)を組み合わせたリスクマネジメントのワークショップに参加してきました。

www.kokuchpro.com

今年の2月にも参加しましたが、前回は半日のワークだったのに対し、今回は一日のワークを体験してきました。基本的な流れは前回と同様だったので、主に差分について整理していきます。

toshimana.hatenablog.com

未来予想図についての議論と共有

前回と比べて、未来予想図の作成やワーク間における修正に多くの時間が割り当てられていました。前回は時間の制約が大きい中で、問題に対して進める案を何とか絞り出していました。それに対して今回はチーム内で十分な議論の上、他に案がないかを検討したうえで作業の方向性を決めることができました。チームメンバが4人(前回は6人)と、全員の意見を反映しやすい大きさだったことも踏まえて、未来予想図に関する議論は前回よりもかなり満足度が高かったです。

運営の方々も「過去のワークでは作業間の未来予想図に対するフィードバックが上手くいかないチームがいた」のに対して「今回はすべてのチームが未来予想図に対して上手くフィードバックできていた」と言っていたので、個人的には未来予想図の議論時間を増やしたことでワークに対する満足度が高まったのだと感じています。

未来予想図の修正

本ワークショップでは、最初に作成した未来予想図を、各作業で得られた知見をフィードバックしながら改良していく、というのが基本的な流れです。私たちのチームでは得られた知見を「足す」修正しかしていませんでしたが、運営の方からは「引く」修正も考えてみると良いとアドバイスを頂きました。

今回のワークは数回のフィードバックしかありませんが、実際の仕事で未来予想図を用いる場合は常に更新し続けることになるため、常に現状を表した未来予想図を保つ必要があります。「足す」だけだと、未来予想図は肥大化して扱いが困難になるため、適度に「引く」ことでチーム内が理解しやすい未来予想図のサイズに保ち続ける必要がありそうです。今回のワークでは「引く」実践はできませんでしたが、どこかで試してみたいと思いました。

運営の配慮

終わった後の懇親会で伺った話でもありますが、ワーク中に挟まれたアドバイスについてもとても参考になることがありました。例えばワークの中で「各自、気になったことを付箋で5つ挙げてください」とありましたが、それについても以下のようなことが考えられていたそうです。

• 気になったことが多すぎると後作業のモデル生成の整理が難しくなる(ワークを時間内に満足にこなすことが難しくなる)
• 数を絞ることで、その人が重要だと思うことを順序付けするようになり、付箋には重要な順に出てくるようになる。
• 数を絞ることで、気になったことをとにかく出し尽くす人を抑制する
• 数を多く出す人を抑制することで、意見が出にくい人が委縮しにくいようにする

他にも多くの配慮点がありましたが、それらの積み重ねによって全チームが満足度の高い状態でワークを実施できたのだと思います。

食事について

ワークショップの昼食に自分の実力に見合わない激辛ラーメンを食べるのはやめましょう。写真は昼食に食べた「蒙古タンメン中本」さんの「北極ラーメン」。

おわりに

個人的な満足度も高く、なおかつ全てのチームが良い成果が出せていたため、ワークショップ全体の完成度もかなり高いものだと感じました。@kitanosirokuma さんと@NoriyukiMizuno さんの二人ならではの他ではできない貴重な内容を学ばせていただきました。新ネタも検討中とのことなので、そちらも楽しみにしています！

ぼかし処理を施してます

*1:https://www.software-quasol.com/sapid2-0/

11/17(金)、「提案が断られないか検証する技術を試してみよう／VPC,BMC+マフィアオファー」に参加しました。

全体最適化の手法として有名なTOC(制約理論)にはDBRやCCPMのようにいくつかの方法論がありますが、その一つであるマフィアオファーについて @NoriyukiMizuno さんからお話を伺いました。

マフィアオファー*1とは営業方法論であり、魅力的で断りづらい提案を行うための方法です。面白そうな技法ですが、資料が少なくて独学で習得するのが難しい技法でもあります。今回は @NoriyukiMizuno さんが独自改良として、別のモデリング技法(VPC,BMC)と組み合わせた手法も踏まえて説明頂きました。

私は開発者ですが、マフィアオファーはよくある他社向け営業だけでなく技術提案などの内部営業(？)にも有効とのことなので、色々実用が出来そうだという期待を胸にお話を伺いました。

抵抗の6階層

人がソリューションを提案されたときに、以下のような6つの抵抗が生じるそうです。マフィアオファーではそれらを上から順に解決方法を検討し、最終的に顧客が納得しやすい提案を検討します。

1. 【ソリューションと問題のマッチング】問題の存在に合意しない
2. 【ソリューションと問題のマッチング】ソリューションの方向性に合意しない
3. 【ソリューションと問題のマッチング】ソリューションが問題を解決できると思わない
4. 【実現する際のリスク】ソリューションを実行するとマイナスの影響が生じる
5. 【実現する際のリスク】ソリューションの実行を妨げる障害がある
6. 【変化したことに対する影響への不安】その結果起こる未知のことへの恐怖

www.goal-consulting.com

マフィアオファーでは最終的に提案内容を「マフィアオファーシート」にまとめるのですが、今回は特に「1～3」について着目してお話を伺っています。

http://affordd.jp/forum/2014_05/mafiaoffer_sheet.pdf

VPC, BMC

VPCはValue Proposition Canvas, BMCはBusiness Model Canvasであり、どちらもスタートアップ(起業)系で知られている技法です。抵抗の6階層の「1～3」を整理するために、@NoriyukiMizuno さんがこれらの手法を用いる手法を提案しています。

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る

ビジネスモデル・ジェネレーション ビジネスモデル設計書

各モデルは以下のような関係になりそう、とのことです。

• VPC：ソリューションの「価値」
• BMC：ソリューションの「具体化(実現)」
• マフィアオファー：ソリューションの「検証」

VPCやBMCで整理した「価値」や「具体化」が有効かどうかを、マフィアオファーのフォーマットを用いることで「検証」するイメージです。

ワーク

マフィアオファーの勉強会のはずですが、実際はVPCのワークでした。とはいえ、ワーク自体は非常に効果的でした。

マフィアオファーは提案するソリューションの価値を提案者が十分に理解できている前提なので、参加者の実業務に合った提案をもとにVPCを検討しました。上手くいくかと思って始めましたが、提案対象者に対する価値と提案が上手く結びつかず非常に頭を悩ませる展開になりました。提案対象者をより明確に定義し、チームで提案対象者に対する価値を掘り下げることで最初よりも洗練された提案を挙げることができましたが、マフィアオファーで最も重要な「提案対象者の問題を解決できる提案を用意できるか」を深く考えさせられる形になりました。

画像にはぼかし処理を加えています

終わりに

マフィアオファーは“魅力的で断りづらい提案ができる”という、提案者にとって魅力的な提案に聞こえる手法です。しかし今回のお話を伺って「提案対象者の抱える問題に対して真摯に向き合い、納得してもらった上で提案に同意してもらう」という王道な内容だと思いました。営業のスキルだけでなく問題分析の高いスキルも必要なので十分に扱いきるには訓練が必要です。マフィアオファーはソリューションの「検証」に向いているため、自分が他者に対して提案をしたいときにマフィアオファー(+VPC,BMC)を用いて、本当に価値のある提案になっているかをセルフチェックする目的で使っても面白いかと思いました。

*1:Unrefusable Offer(URO)ともいうらしい

2017/11/3(金・祝)、第3回盛岡ソフトウェアテスト勉強会に参加しました。

昨年に引き続き、今年も盛岡ソフトウェアテスト勉強会に参加しました。

www.kokuchpro.com

以下は会場1Fのお店で食べたお昼のラーメンです。よく見ると海藻が浮いているのが分かります。

はじめに

「じゃじゃ!! 『テスト』ってなんだべ?」をテーマに、初学者・他社のテストに興味がある人を対象とした4つの講演がありました。
初学者向けということですが、テスト実行よりの話はほとんどなく、テストに対する考え方／捉え方を伝えるための内容が中心だったように思います。
単なる「テストが実行できる人」ではなく、「テストを通じて価値を創造できる人」を育成したいという講演者／実行委員の意思が感じられました。

単なる仕様チェックから卒業するために　～最初に抑えたいキホンのキ～

NaITE(長崎IT技術者会)発起人の池田さんによるテスト技術者がステップアップするための考え方の講演でした。

「キホンのキ」とあるから、テスト技法中心なのかと思いましたがそんなことはなくて、テスト分析／設計を中心とした話でした。
テスト技術者が考えておきたい全体観を示す構成であり、池田さんがテスト初級者に対して「より価値を創造できるようにするにはどうすれば良いか」を広める意思が伝わってくる内容だと感じました。

時間の都合で後半早足になってしまったことは惜しかったですが、直後に資料を公開してくださっています。ボリュームや構成が素晴らしく、とても勉強になります。

単なる仕様チェックから卒業するために　～最初に抑えたいキホンのキ～ from Akira Ikeda

www.slideshare.net

本当はやさしいユーザビリティ ～現場の事例と改善案～

盛岡ソフトウェアテスト勉強会の協賛企業でもある株式会社ヴェスから及川さんによる講演。第三者検証会社としての実務経験からくる実例に基づいたテストの考え方についての内容でした。

単なる機能テストではなく、使い勝手(ユーザビリティ)についての観点や、実際に顧客とのやり取りを踏まえた内容が現実に沿った形で纏められて、とても興味深く聞くことができました。

「勘と経験」の思い込みからの脱却 - なぜ探索的にテストができるのか -

JaSST東京実行委員である坂さんからは、なかなか他でも講演されることの少ない探索的テストに関する内容でした。

探索的テストは、その成果が個人にかなり依存する手法であり、なかなか上手く扱う方法を言語化して説明しにくい手法だと思います。本講演では、「勘」と「経験」に着目し、どのような考えで坂さん自身がテストを実施しているかも踏まえて探索的テストについて説明していただきました。

個人的にはTOC(制約理論)で使われるブランチによって内容が整理されていたことが興味深かったです。

宇宙開発とテスト

くまきちさんからは中々触れることのない宇宙開発をテーマにした内容をお話いただきました。

宇宙開発に使われる技術そのものは私たち普段から扱っている通常の組み込み開発と大差ない、という点はお話いただいて、とても興味深かったです。ただし、1つのミスが凄く大きな失敗につながる分野なので、一つ一つに検証に対する熱の入り方は一般的な組み込み開発と大きく差があるのかな、と感じました。

また、全体的に観客の興味を引くような作りになっていて、楽しく話を聞くことができました。以下、個人的にヒットした一言。

おにぎりと自動車の重量価値は大体同じ #morioka_swtest

— Toshiyuki Manabe (@ToshiManaPlus1) 2017年11月3日

勉強会の宣伝

勉強会当日の話ではありませんが、関係者に勉強会の宣伝方法を伺って、かなり考えてられていると感じました。
盛岡の企業にアピールするために、滝沢イノベーションセンターのFacebookで広告を出したり、盛岡のローカル誌に宣伝をだしたりしたそうです。

勉強会があまり開催されない盛岡で、「どうやったら興味がある方に気づいてもらえるか」を真剣に考えた行動だと思います。
実際に参加者と話をしていたら、上記の宣伝を受けて参加した、という方が何人かいました。
なので、今回の参加者数は実行委員の頑張りが身を結んだ形であり、見習いたい部分だと感じました。

おわりに

岩手に所縁のある方々が集まって開催されている勉強会であり、実行委員は必ずしも岩手に在住している方が多い訳ではありませんが、第3回となり、盛岡近郊の参加者が確実に増えている、と感じられる勉強会でした。
これから地域に根付いた勉強会になる成長過程を正に今見れているということで、とても貴重な経験をさせていただきました。
今後の活躍も期待しています！