TOCfEシンポジウムに参加してみました

昨日はTOCfEシンポジウムに参加していました。
「教育のための」ってつきますが、対象は教育者に限らないです。
むしろ日本は教育関係者より企業人のほうが圧倒的に多い・・・笑
(それはそれでいかがなものかとも思ったりはしますがぁぁ・・・
教育関係の方々にも興味をもってほしいなぁと思います。)

第7回教育のためのTOCシンポジウム
http://tocforeducation.org/info/symposium-7/

基調講演はMarta Piernikowska-Hewelt さん。
ポーランドで教師・カウンセラーとして10年にわたり重度の脳性麻痺や自閉症などの症状や特性を抱えるの子ども達とのコニュニケーションを改善するためにTOCfEを活用していて、今回は事例を交えて普段の活動についてのお話が聴けました。

何らかの特性によってコミュニケーションがうまくできない方々に対して、お互い誤解したまま諦めてしまうのではなく、その人の可能な手段で時間を設けてその人の考えていることを見せてもらうことの大切さが伝わる素敵な内容だったと思います。

懇親会のときにMartaさんに質問ができる機会をいただけたので、「ポーランドの学校では、世間で健常者と呼ばれる子どもたちと障害者と呼ばれる子どもたちが半分づつクラスに存在している状態で授業を受けている」という現状に対して、日本ではそのようなことが実現できていないので、なぜうまく実現できたのか？を質問してみました。
ポーランドでも以前は日本のように普通クラスと特別クラスとで分離していたそうです。そこから小さい規模で活動していき、「子どもの頃から様々な子どもと一緒に学ぶほうがよい」ということを親も子どもも実感するようになったので、現状に違和感を感じなくなったそうです。なぜそのほうがよいと感じるようになったかについては、いずれにせよ子どもたちが大人になり働くようにれば、そこには健常者も障害者も様々な人が一緒に存在していて、一緒に仕事をしていく必要がある。それならば子どもの頃から同じ状態で学んでいくほうがよい。例えば数学の進みが悪くなるとかいうことがあるかもしれない。だけど社会で生きていくために必要なこととしては学校の教科で得ることなんて一部にすぎない。学校の教科よりも様々な人との関わりのほうが学びは大きい。ということを大人も子どもも実感したからだそうです。
そして、短い期間で変化できたわけではなく、現状になるまでには20年かかったそうです。諦めないことって本当に大事だと思いました。

午後の事例発表も家庭や職場や恋愛など(笑)様々な取り組みを聴けて面白かったです。
親子で発表することもあるのがこのシンポジウムの魅力ですね。

あとはワークショップが何人いても楽しめるし学べるし無理やり知らない人と話せるしという仕掛けが入っていて面白かったです。私は暑さ負けしていたから参加できなかったけれども(；・∀・)

今の日本の学校教育にTOCfEを導入するためにはトップを動かさないといけないから簡単には実現できないということを前夜に若林先生から伺いました。だったら学校以外の場で子どもたちに体験してもらうのがよいのだろうなぁと思いました。家庭でも使えるし宿題をするときにも使えるので、親世代に普及させていくのがよさそう。個人的には企業研修に導入したらいいのになぁって思っています。うまく考えられないことで損しているよなぁということは職場でもたくさん起こっているし・・・

大人も子どももいまより上手く考えられるようになって納得のいく選択ができるようになるといいなぁと思うし、自分も鍛えていきたいしサポートしていきたいと思っています。

勉強している様がみられないひとは勉強したくないのか？

ソフトウェアテストのコミュニティの中で会話をしていると、現場でテスト設計やテスト実行をしている人たちが進んで勉強をしない、社内で勉強会を開いても参加しようとしない、という話をたびたび耳にします。私も現場で体験してきているし、そういう話をします。少なくともそういう事実はあります。

以前JaSSTでにしさんがソフトウェアテストの人材育成トライアングルという話をしました。
http://www.jasst.jp/symposium/jasst14tokyo/pdf/H8-6.pdf
この最下層「Novice層」に位置する人たちを対象にした話です。

勉強しないよね、という話があがるときに、なぜそうなるのか？という問いをすると、「成長する気がない」「言われたことをやることを望む」という意見がでてきます。
確かに作業を望む人や勉強してまで時給を上げたいわけではない人はいます。これも事実。
ただ、どうもそのような人にフォーカスがあたりやすく、そうではない人までそのような目で見られてしまっていることに最近気づきました。Novice層にいる人達をひとまとめに扱ってはいけない！と。
私もバイアスをかけてひとまとめに見てしまうことがあります。だけどそれは本当ではない。存在の懸念があるわけです。

Novice層の中に様々なタイプの人がいるのですが、ものすごくざっくり分けると、4つかなぁと思っています。

• 決められた作業をやりたい人(そもそもソフトウェアテストには向かない人)
• 現状に満足していてなにも変えたくない人(ソフトウェアテストに向いているかもしれないけれど勉強や成長は望まない人)
• 現状を変えたい(勉強したいし成長したい)のだけれど自分の時間も大事にしたい人
• お金や時間が無いなどの制約に阻まれてどうしたらよいのかわからないでいる人(制約が取れれば社外で勉強することにも抵抗が無い人)

上2つに該当する人たちになにかを働きかけても効果は無いなぁ、と思っていますし、ソフトウェアテストの仕事をするうえで雇うのはどうかなぁと思います。
だけどNovice層の多くは実は下の2つのどちらかに該当していると私は考えています。

働く人のすべてが働く時間以外に勉強する時間を設けられるかといったらそれは難しいことで、子育てをしていたり介護をしていたり疲れやすい体質だったり他にやりたいことがあったり・・・様々な背景を持っている。勉強する時間を持てない人は勉強したくないのかというとそんなことはない。
だけど自身がたまたま勉強する時間を持てて、勉強することの価値を感じている人は、自分の周囲を基準にするから、単に「勉強したくないんでしょ」という一言で片付けてしまう。それは誰にとっても嬉しくないことなのにね・・・

そう、違うんだよ。勉強したいって声は実は多くの人から発せられている。でも自分のライフスタイルの中では業務時間の中で勉強できることが理想なだけなんだよ。現状維持したいわけじゃない。給料は上げたいし成長できたら嬉しいとも思っている。そんな人はひょんなきっかけで成長する可能性を持っている。本当になにも成長せずにただ現状維持できて考えずに仕事ができたらいいって思っている人は、実はごくわずかなんだと思う。

そしてすべてのひとが同じように勉強すれば成長するわけではない。ひとりひとり、理解するために必要なアプローチが異なっている。さらに、そもそも受けてきた教育が一方的に与えられたもので、暗記したり言われたことをやったりという学び方をしてきているのだから、そういう人たちを相手に画一的な勉強会を開いても、言われたようにやることだけにとどまるからそれをどう活用したらよいのかまで考えられない。そもそも理解に達しない。疲れちゃう。理解できないことが辛くて続けられない。

従って、どれだけひとりひとりに寄り添えるか、一緒に考えて進めるか、それが課題になっています。

しかしながら、現実的にひとりひとりのケアは難しい。そして自社の後輩ではなくて委託先ともなればコンプライアンスが立ちはだかってなおさら手が出せない。それを踏まえてなおも手を出したところで、相手の立場からすると別の現場に行かされたらその時点ですべてリセットされる・・・周りの環境も、自分の報酬も。だって多くの現場はテスト設計技術なんてスキル評価の対象になっていないのだから(単にテスト設計の経験年月しか問わないのだから)、学んだ内容がステップアップに繋がる可能性は極めて少ない。
さすがにテスト自動化技術に関しては着目されているけれど、実際に現場でなにもない状態から自動化の学習ができることはほとんどない。やってもテスト設計技術に比べたらさらに学習時間を要して結局身につかない中途半端な状態で終わることのほうが多い。次の現場で引き続き学べるかどうかは運次第。だって送り込む側は送り出す人の成長よりも遊休期間をつくらないことを重視するか送り出す人の成長なんてどうでもいいかのどっちかになることが多いから。

・・・こんな現状は変えたい。ひとりの力ではどうにもならないことだけど、地道にどうにかしようと現場で奮闘している育成者はいるのです。そして社外で名の知れた実力ある人達からみたら「はぁ？！なにそれ？それで勉強しているって言えるの？」って言いたくなるくらいほんの少しだとしても、学ぶ側は現場で少しずつ学び成長しているのです。ものすごくゆっくりしたペースでしか進めない彼らにトップの世界を見せても通じない。遠すぎて目指せない。過去底辺にいたひとが自力で抜け出した実績があったとしてもその人と同じになんかできない。そうじゃない。ひとりひとりにそれぞれ異なる嬉しい変化の可能性をみせたい。小さくていいんだ。

そのために今やらなきゃいけないのは、ひとりひとりの学習効率を高めること。学生のときの学習方法とは異なる学習方法を知ってもらい得させること。考えることの楽しさと大切さを実感してもらうこと。自分で決めて自律的に動けるように考えられること。

私もこれまで全然うまくできなかった。なんで？なんで勉強しようと思わないの？なんで楽しいと思わないの？私だってみんなとスタートラインは同じだったんだよ？無知なところから必死に学んだんだよ？・・・って周りを責めたし馬鹿にした。でもそれ、なんにも嬉しくない。そしてよーくよーく観ていたらそうじゃなかった。いろんな背景があった。諦めていることとかもあることがわかった。様々なアプローチを試さないとだめなこともわかった。
この先機会を得られるかどうかはわからないけれど、機会が得られたならこれまでより上手くアプローチできるようにしたいなぁ、と思っています。

どうしてそうなった？を考える

少し前に炊飯器を新しく買い替えました。

炊飯器もいろいろ進化していて、ごはんは美味しく炊けるしどうやらパンも焼けるらしい。色も白じゃなくて嬉しい。(家電は白じゃないほうが好き。そしてできるだけその空間にあった色にしたいと思っている！)

だけど一点困ったなぁと思っていることがあります。

炊飯器の内蓋を外してしまうと外蓋が閉まらないのです・・・内蓋を洗って乾かしている間は蓋が開きっぱなし；炊飯器は蒸気が出るので湯沸かしポットと一緒にスライドする台に置いているのです。だけど写真のように天井があるので、ポットを使う度に蓋が擦れちゃうよ〜・・・

ところで、どうして内蓋を外すと外蓋が閉まらないつくりになったんでしょう？？？
商品の企画者ではないから背景は推察でしかないのですが、考えてみました。

内蓋を外すと外蓋が閉まらないようにしたかったのではないかな？
どうしてそうしたかったのかな？
きっと内蓋を取り付けるのをわすれて炊飯しちゃうケースがあるんじゃないかな？
そのまま炊飯すると蒸気だけでなくお湯とか米とかが吹き出しちゃうんじゃないかな？
それを「使う人が気をつける」ではなくて、気をつけなくてもそういう事象が起こらないようにしたほうがよいと思ったのではないかな？

そんな風に考えたら、あぁそうかそりゃそうしたいよねって思ったのでした。

だけどやっぱり困るんですよね(笑)
そして私はこういうマイノリティーな立場になることがなんか多いんですよねぇぇ・・・(；・∀・)

何を探しているのか？

テストを行うときに「バグを探す」と言われるのだけれども、私はそういう感覚かと問われると、そうである場合もあるけれどいつもそういうわけではないなぁ、と答えます。
常に間違い探しをしている感覚はあまり無いんですよね・・・

仕様に関する何かしらの情報が入ってきたときに、条件反射的に思うのは「この仕様で起こりうることはなにか？」「なにか忘れられている気がかりはないのか？」「前提条件が崩れる何かがないか？」ということであって、それは間違いとかじゃないんですよね。頭が可能性を探ろうとしている感覚がある。
気になることに対して対策が用意されていたら「おぉ、素晴らしい！」って思うし、用意されていなかったら「どうなる？どうする？」と開発側に確認してみる。その確認タイミングがたまたま実装後だったらバグとしての報告になっちゃうかもしれないけれど、バグを見つけたいわけじゃない。

実装物を操作してテストを行なっているときは、操作に着目して、バグを見つけようと思っていることが多いかもしれない。だけどそのときは、探すというよりお決まりのパターンを試すって感じなんですよね・・・探してないよなぁって。探しているのは「お決まりのパターンが適用される箇所」な気がします。
そして、実装物の操作がテストの目的ではなくて仕様の学習だとしたら、先に書いたように気がかりを探す。なるほど、目的によって分けているかもしれません。

最近は実装物を相手にするよりもドキュメントを相手にすることが多いし、実装物を相手にするときも仕様の学習をしていることのほうが多いから、あまりバグを見つけようとする機会が無くて、だから余計に「バグを探す」感覚が無いのかもしれません。

そして、バグを探すとか間違いを探すとかいう言葉は、テスト担当者を疎ましい存在にしやすくなっているんじゃないかなぁとも感じていて、だから探しているものは何なのか？を考えるのは思っているより大事なことなんじゃないかなぁと感じたのでした。

仕様を理解するということ

この記事を書く前に、いや似たようなこと以前に書いたっけ？って確認してみたら、やっぱり書いていました・・・ネタ自体は「仕様を理解しないでテスト実行してもよいのか？」という話だったので今回言いたいこととはちょっと違うかな。

仕様を理解する＝仕様書を読む、仕様書に書かれていることを(表面的に)理解するということではない

だけど、仕様書を読めば仕様は理解できるって思っている人は多いのではないかなぁ？そして、仕様書を読めばテストケースは作れるしテストできると思っている人もまだまだ多い。

だから、開発者とテスト担当者が分かれている場合に、仕様を共有しようという考えに至らないのかなぁ・・・でもそういう組織って開発者同士でも仕様を共有しきれていないと思う。実際そういうケースに遭遇することがある。

仕様を理解するというのは、仕様書に書かれている文章がわかるということではないよね。
文章は読めばわかる。読んでわからない用語を調べれば、文章としてはわかる。
だけど、それは理解したことにはならない。
仕様を自分の言葉で説明することができるかというと、できない。

仕様を理解するためには、
仕様が定められた背景、根拠というものを知る必要がある。
そして、仕様書に記された文章の裏に暗黙的な情報が隠されている。
それらを見出して自分の中で考え咀嚼して初めて理解できる。

そしてその理解が必ずしも全員一致しているとは限らない。
だから理解の内容を共有して認識を合わせる必要がある。

そんなことを普段の開発活動で行っているだろうか？
開発担当者は行っているかもしれない。
テスト担当者はそこに存在しているのだろうか？
・・・これまで私が関わってきたところの多くは残念ながら仕様の共有が行われていませんでした。

私は、無駄なテストというのは仕様が共有されていないときに「心配だから」とか「念のため」とかいう理由で追加されてしまうテストの中に含まれていることがあると思っています。肝心の仕様が共有されていないから見当違いなテストを行っていたりする。
(その他にテストレベルを意識せず重複させてしまうテストも無駄なテストになりますが、ここで言っているのは完全に意味のないテストです。)

もうひとつ、
仕様を理解したらすべてのテストケースが作れるわけじゃない。
仕様を理解した時点で見えてくるものがある。それは仕様の外側にあるもので、テストは仕様と外側にあるものとをつなげて考える必要がある。
だから、テスト担当者が仕様を理解するのは前提にある必要条件なんだと思っています。必要条件が揃わずにテストを考えようとしても、そりゃ無理だよね・・・

だから、もしテストが独立している組織であれば、開発者はテスト担当者との仕様共有をないがしろにしてほしくないし、テスト担当者は仕様を理解したうえでさらに仕様を補う役割を担っていることを自覚してほしい・・・と願っています。

勘と経験ってなんだろう？

11月3日に盛岡でちょこっとお話をしてきました。

（スライド移設したらリンク貼ります。）

探索的テストについて話をしてほしい、ということでした。探索的テストとはなんぞや？という話ではなく、私が実際どうやって探索的テストをしているのか？というあたりが聴きたいということで。
その後、主催者側から、「アドホックテストの時に何をしたらいいか悩んでしまうことが多く、どのような経験と勘を頼りにしてテストを進めているのか知りたい」というメッセージが届きました。

・・・経験と勘ねぇ・・・よく言うんだけれどねぇ・・・

その後更にヒアリングしていくなかで、同じようにテスト実行をしても発見するバグの数に違いがあり、それは勘、経験、センスなどによると思うという話がでてきました。

・・・そうなのよね。そこらへんのワードが出た時点でなんか止まっているのよね。
私自身も、勘とか経験とかセンスとかそういったものはあるよね、とは思います。
もう少し言うといくつか特性が必要でそれをどれだけ持ち合わせ、うまく組み合わせて能力を発揮させているイメージがあります。

でもそれだと属人性だから仕方がないよねっていう話で終っちゃう。そういうのを求めてはいないわけですよ。現場も、今回の参加者も。

じゃぁなにをしたらいいんだろうね。
まずは自分たちが思っているものを外にだすのがいいんじゃないかな？
きっと、勘という言葉に対する認識はそれぞれ違うよ。
経験ってひとことでまとめているけれど、どんな経験が必要か見つめていないよ。
・・・そう思ってみんなで考えて共有するワークをいれてみました。

実際、参加者のみなさんは、それぞれ少しずつ異なる見解を持っていました。各自が抱く見解を見せないままに「勘」とか「経験」で済ませてしまうと、なんか共通認識を持っているようにみえて全然共有できていないんですよね。

そして、私は「勘」に対してこう考えている、という見解を紹介しました。
もちろん直感というものもあると思いますし、他の見解もあるはずです。ただ、コントロールできるものを示すことで、なにをしたらよいかが見えてくると思いました。

私は、勘が働くときには何かしらのコンテキストが存在していると考えています。
なにもコンテキストがなければなにも思いつかない。気付くとき、考えるときには常に土台となるなにかがある。それを「情報をつなげる」と表現しました。
土台となる情報があって、新しい情報が入ったときに、情報をつなげて考えることで発想が行われる。
探索はつまりそういうことを行っているのではないでしょうか？

一方の経験ですが、これは仕事上の経験だけではないんですよね。雑学のレベルから、普段の生活から、人との交流から、生きていく中で得る様々な情報が役に立つことがある。だけどそこから得た情報をそのまま蓄積しても上手く使えなくて、自分の中で一般化させることで活用範囲を広げると上手く使えるようになる。

そして、情報をうまく活用するには、好奇心だったり観察力や俯瞰力だったり、洞察力だったり、学習理解力だったりと、いろいろ必要であることは感じています。(勘とは？に対してこのような特性や力を挙げている方もわりと多かったです。)ただ、だからといって属人性だけで片付けてしまうよりも、トレーニングできるところはあるはずだし、情報を活用することが必要なんだねっていうことを意識したら暗記だけではダメなことや情報そのものを集めるだけでなく一般化できなきゃうまく活用できないことも見えてくるんじゃないかな？ということを伝えようとしました。伝わったかなぁ？

ちなみに、このスライドにもロジックブランチを利用して、情報を因果の関係でつなげて示しています。情報をつなげる解説に対して情報をつなげるツールを用いてみたのです。
ソフトウェアテストの活動において考えるときに、ロジックブランチはとても相性が良く使いやすいと思っています。

余談ですが、私のStrengthsFinder TOP5って、
1 収集心
2 適応性
3 内省
4 着想
5 慎重さ
なんですよね・・・・・
幅広く学習し、場当たり的に対処でき、よく考え、発想し、判断して疑うんですよ^^;
あーもうそうですねまさにそのとおりですって自分で納得しちゃいました。

テスト設計者の思ったとおりにテスト実行してもらえないとき

テスト設計からテスト実行までを一人で行っていた人が、テスト設計だけを担当してテスト実行を他の人に任せるようになったときに、テスト設計者の暗黙知が表現できていないなどの理由でテスト実行者が異なる認識でテスト実行することがある、「ここまでみてほしい」と思うところまでみてもらえない、というもどかしさを感じる、ということを経験したことがあるかたはどのくらいいるのでしょうか？

私も初めてこのケースに遭遇したときは「なんでそこまでみないのっ？？！」と驚いたり、自分でできたらこんな見落としはしないのに・・・と思ったりしました。。。今でも思うことはありますね(^^;

このようなことが起こると、テスト設計時の狙いが実行時に漏れてしまうため、なるべくテスト設計者とテスト実行者のずれを少なくしたいと思うのですが、その際に「誰でも同じようにできる」を目指してしまうことがあります。特に10年前とかそういう傾向が強かったように思います。しかしながらその結果が嬉しかったかというと、メンテナンス性の悪いテストスクリプト、殺虫剤のパラドクスになりやすいテストスクリプトというものができあがり、テスト実行時に気付いて欲しい他の問題にも目がいかなくなるという問題が起こりました。

これらの現象をロジックブランチにしてみました。
※使い勝手がよいのでastahのアクティビティ図のツールをつかっていますが、アクティビティ図ではなくてロジックブランチです。バナナ型はさすがにないので楕円で代用。

もし、テスト設計者と実行者が異なる場合、かつ、テストスクリプトに対してテスト実行者が違う解釈をすることを防ぐならば、結果として、誰もが同じようにテスト実行できるテストスクリプトを目指そうとする。その結果として嬉しくないことが起こる。

逆に、もし、テスト設計者と実行者が異なる場合、かつ、テストスクリプトに対してテスト実行者が異なる解釈をすることを許容するならば、結果として、テスト実行者によって実行内容が異なってしまう。こちらのケースではテスト設計者の想定外の不具合を見つけることができるかもしれないけれど、テスト設計者の意図したテストは実行できないことがある。その結果として嬉しくないことが起こる。

この問題については解決法は一つではないと思うし、組織やプロジェクトの背景により対策は変わると思います。
私が考える案として同じくロジックブランチで示してみます。
緑のところが追加した部分。

私は、人が実行する場合はテスト手順や値に自由度を持たせるほうがよいと思っています。そのほうがテスト実行者の思考がかたまらないのと、テストウェアとしての再利用度が上がると思っているからです。そのかわり、確実に「そのテストは何を確認したいのか？」というテスト設計者の意図を記入しています。あとは、テスト実行者もいろいろ考えて試せると信頼するほうがよいと思います。

そして、考える必要が無いほどのテストスクリプトであれば、できるだけ自動化を目指したほうがよいし、そのようなテストは繰り返し行う可能性のあるテストに絞り込んでいくほうがよいと思っています。

もうひとつ、テストの値や操作方法を入れ替えることが容易にできるような、再利用の仕組みを考えることも有効だと思います。これは自動化であれ手動のままであれできることです。その仕組みをもつテスト管理ツールもありますね。

みなさんの現場ではどうしていますか？それはなぜですか？その結果どうなっていますか？そんなことをこの様に図にしてみることで、「ここはこうしたらよいかもしれない」「ここが変わればよいかもしれない」ということに気付くかもしれません。