テストする人。

ソフトウェアテストってわかんない。テストとQAのゆるゆるブログ。

「いちばんやさしい教える技術」を読んだよ

読書感想グラレコ
読書感想グラレコ

いちばんやさしい教える技術

いちばんやさしい教える技術

インストラクショナルデザインというらしいけど、
それを知らないけど「教えるって難しいよね」って言う
わたしみたいな人が読むのにすごく手に取りやすい本でした。

というか、子どもに読ませてもいいのかもしれない。

グラレコは、視覚優位のわたし向け覚書。
読んで好きだったところを抜粋。
で、以下、その感想的な何か。

教えることについて

他にも書いてあったのだけど、「おぉ!」と思ったのが、この2つ。
『教えたい人に、教える側の希望を言うのではなく、具体的な行動をゴールとすること』
『教えるには、3つのスキルがあること』

『教えたい人に、教える側の希望を言うのではなく、具体的な行動をゴールとすること』

だれかに教えたいときって、「こうなって欲しい」と言いがちだった(ような気がする)のだけど、
それよりも、具体的な行動を決めてゴールにすることが大事なんだそうです。
たしかに、希望とか期待言われても困るわ・・・ってことは身に覚えがある。
それよりも、その希望とか期待のゴールを行動として出してもらえると、そのActionPlanはたてやすいよね。ってなるよね。ってなりました。

『教えるには、3つのスキルがあること』

これは、次のスキルです。

  • 運動スキル
  • 認知スキル
  • 態度スキル

この中でも、態度スキルというものは、結果として教えたい人のやる気スイッチを押すことになるので*1
一番難しいスキルになるそうです。
それぞれのスキルについては、次に書きます。

3つのスキルについて

運動 スキル

ここで好きだった話は次の2つです。(本書はもっと他にも書いています)

  • スモールステップ

小さく行動して成功させて、次のステップに進ませる方法です。自転車の練習を例に書かれています。
ここには「俺の背中を見て盗め」みたいな方法は書かれず、小さく成功体験を続ける方法が書かれていて、すごくいいな。と思いました。
だって、背中みたってわからないものはわからないんだもん(とくに教育が目的であるなら、それはただの怠慢だと思うし、本書もそれに近いことが書いてある)

  • 『情報フィードバック』をおこない、『評価フィードバック』をしない

これは結構ぐさっときました。情報フィードバックとは、行動にたいして『できたか』『できてないか』を教えたい人に伝えることです。
一方、評価フィードバックは、行動にたいして『すごいね』といった評価まで伝えてしまうことです。
この評価フィードバックの何がよくないかというと、行動にたいして評価まで伝えてしまうと、その評価がプレッシャーとなってしまう。
ということでした。
 わたしの場合、わりとすぐ「天才」「すごいね」「まじ神」って言ってしまうので*2
教える側としては、教えられる側に余計なプレッシャーを与えてしまっていたのかもしれないなと思いました。

では、そういう評価はしてはいけないかというと、そうではなくて
しかるべきタイミングで褒めるとか評価するとよいみたいです。(本書では、サプライズという項目になりそうです)

認知スキル

 私はあまり勉強ができる方ではないこともあり、このスキルが一番勉強になったかも。
この認知スキルにはさらに3つの項目が紹介されていました。(いや、3つだけってことでもないけど)

  • 記憶すること
  • 問題を解決すること
  • 話すこと・書くこと

次に、一つずつ説明します。

記憶すること

ここで一番ぐっときたのは、教える相手が視覚優位か聴覚優位かで、教え方を変えるべし という内容でした。
わたし自身、視覚優位(それも図形や絵が好き)で、
仕事の説明もよく絵を描いて理解するようにしています。(なのに、この画力やばい)
教える側になるときは、自分の得意な方で教えても、教えられる方は理解ができないので
教えられる方にあわせるようにしなさい。ということでした。

聴覚優位の人の場合、時系列など順番に教えることがよいそうです。(なるほど)

問題を解決すること

ここは、算数とか数学が好きな人は得意かもしれないです。

  • 解き方のパターンを知ること
  • スキーマを持つこと

この2つは同じことを言っています(と私は思っています)
解き方のパターンのことを、本書では『スキーマ』といい、そのスキーマの数を多く知っているほど
活用できれば、応用も解けるようになる ということでした。

『問題を解決する』というタイトルに対して、これだけでは解けないかもしれないですが
パターン化できるスキルは、あらゆるシーンで役に立ったり、楽になれるなぁと思っています。

話すこと・書くこと

ここでは、次の3つがとくによかったと思います。

  • コーネル式ノートの取り方
  • 文書の型を知る
  • スピーチは繰り返し練習する

コーネル式ノート とは、ノートを3つのエリアに区切って、
『箇条書き』『図やヒント、キーワード』『まとめ』でノートを書くことです。
こうすることで、記憶に残りやすい(または思い出しやすい)ノートになるそうです。
 わたしも学生時代にそうできていたらなぁ。。というか、今の仕事でも、自分はノートに書くこと多いので
ちょっとやってみようかな。と思ったり思わなかったりします。

文書の型を知る。については、起承転結然り、論文の書き方然り、色々な文書はある程度型が決まっていて
その型を教えることで、書きやすくなるよ。というお話しでした。
とくに読書感想文などは、わたしの子どもも毎年頭を抱えているので、ものごと(文書)には型があるよ。って
前もって知っておくだけで、かなり生きやすくなるなぁと思いました。

スピーチについては、練習はするけど、記憶したものを話すのは面白くなくなるから一旦忘れる。という
わかるけど、なかなか豪快な方法でした。
よいかどうかは、、、もっとよい案があるといいなぁ。

態度スキル

最後に態度スキルです。
このスキルは最も大事(難しい)スキルと紹介されていますが、それもあってか
あんまりグッときませんでした。

主に次の3つについて書いてありました
* 質問力
* 対話する
* コーチン

ざっくりいうと、教えられる人がみずからやる気を出すように、
質問という形で対話をして、教えられる人にあったストーリーをくみ上げていくような話でした。

ここで、わたしがモヤモヤしたのが、自分が教えられる人だった場合、
教える人から、あれこれ質問されて、微妙な質問だったりして、ゴールが自分が向かいたい方向かわからないまま
であったり、
答えやアドバイスが欲しくて話しているのに、質問返しされたりして、解決してくれないの?
アドバイスほしいんだけど・・・
ってことが、わりとあるなぁと思ったので、モヤったんだと思います。

きっと本書とわたしの経験のシチュエーションが違うのかな?とも思いますが
わたし的に腑に落ちる対話ができるといいなぁと思います(とはいえ、自分は教えたがりすぎということが本書でわかったのでした)。

さいごに

わたしは、なかなか本を最後まで読み進められなくて、今回めずらしく最後まで読めたし、学びもあってよかったです。
(本を読む人なら、数時間で読み終わるのではないかと思います)
今回ご紹介した話以外にも、色々とエッセンスが詰め込まれた本なので
さらっと読んでみられるとよいと思います。

今回この本を読むことにしたきっかけツイートがこちらです。
よい本をご紹介いただいて(わたしにじゃないけど)どうもありがとうございました。

*1:やる気スイッチなんて書いてなかったけども

*2:むしろそこまで言うとプレッシャーでもないかも

ターニングポイントを踏んだかもしれない

週末、東京に行っていました。

 

そこで、朝から夜まで色んな話をすることができました。(メインの活動もやったのですよ)

 

最近は疲れることもあったり

もっと考えるべきことや

できていないことが色々わかってきて、

でもハードワークである自覚もあったのですけど

結果として、もう一つがんばってみようかな。ということを決めました。

 

わたしの周りには、

わたしよりお仕事も

社会的な立場も

その他世界的に活躍してされている方がたくさんいて、

 

そんな方が

自分でもできることがある ということや

ワクワクできることを心から楽しんでいることなど

色々やる気をいただきました。

 

そんな中、

「りなちゃんもできるよ。やった方がいいよ。」

 

と言っていただけて、

やってみようと思いました。

 

やらずに後悔はしたくない。

 

これから大変だろうなぁと思うのだけど

わたしたちも先人たちのように、

自ら楽しんで

ワクワクして

それが他の人にも伝わって

ワクワクしてもらえる活動になると

いいなと思います。

 

JaSST'19 Tokyoでお話しをしてきたよ

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

日本最大のテストシンポジウムであるJaSST'19 Tokyoで
2つセッションをしてきました。

なんか、すごいぞ、わたし!(自画自賛

チュートリアル

1つ目はJSTQB Advanced Level テストアナリストのシラバスでテストを学ぼう という
中級者向けのチュートリアルセッションをしました。
JaSSTソフトウェアテストシンポジウム-JaSST'19 Tokyo-セッション概要

こちらは有料セッション(JaSST自体も有料なのですが、さらに有料セッションをしています)
であったのですが数十名にご参加いただきました。
(同僚、そして今の会社の最初のボスにも参加していただいて もう震え声)

宿題の回答

「原因結果グラフとドメイン分析の使い分けがわからないので教えてほしい」という宿題がありましたので
相方の見解をご紹介します。

このセッションへの思い

わたしは、JSTQBの技術委員という活動をおこなっていて、
活動をとおしてISTQBのことであったり
テストマネジメントってなんだっけ?とか
テストアナリストってどんなことするんだっけ?をより深く理解していっています。

その回答は実はシラバスに書かれているのですが(体系的なものですからね)
そのシラバスを活用するためのコツというか、手を動かすことによってヒントになるといいなぁと思います。

個人的な反省はありつつも、相方(というにはおこがましい、大半を彼がやってのけた)とともに
セッションを担当できてよかったです。

彼とは東海地方と九州地方というリモートでのやりとりをして、そのまま本番を迎えました。
彼とのこのセッションのレビュー会は楽しかったし、理解が深まってよかった。やっぱすげぇや。

最終的に(元)ボスにもチームのメンバーみんなに参加してもらいたいね。というような
ことを言っていただけたのでうれしかったです。

テストマネジメントセッション

2つめのセッションは、テストマネジメントのセッションです

www.slideshare.net

こちらでは、初めてモデレーターに挑戦しました。
underscore42rina.hatenablog.com

またモデレーターとしては、前日に開催された(元)ボスのセッションが
ほんと毎回すごいなーって思います。(それで、急遽スライド変えたくらい!さすがや!)

パネリストとは、技術委員として一緒に活動もしているし
彼らの登壇は数々観てきたし、
さらにはモデレーターというには申し訳ないほど、
お膳立てしていただきまくりだったので大船に乗ったつもりでいましたが、
逆に私がいるのが邪魔なのでは、、、水を差してしまったらどうしようというような悩みがあったくらいです。
結果よいセッションになったと思うので、よかったです。

数日前から咽頭炎などに悩まされましたが
ちょっとくらい体調悪くてテンションが無駄にあがらずよかったかもしれないですね。。。

こちらからまとめも確認できます
togetter.com

このセッションへの思い

テストマネジメントのセッションは、毎年恒例となっているセッションのひとつです。
その中で、わたしがモデレーターを任せていただいたことにより
より身近に感じてもらえたらうれしいなぁと思っていました。

わたし自身は、明示的にテストマネジメントをビジネス要求されたことがなかったのですが、
(というと語弊がありそう。プロジェクトの大半を一人でQA活動することが多く、
一人テストマネジメントみたいな形になっていた)
その中でも多くの共通点や、学びがありました。
また、今はWebサービスというところにいる中でも同じで、このセッションで多くの学びがあり
色んな方に聴いていただきたいな。と思っていました。

あとでお話しした方で「言葉が出てこないのですが、とにかく楽しかったです!」というような
ことを言っていただいたので、きっと成功だったと思います。

ほんと打合せのときから、楽しくて、わたしが一番勉強させていただきました。
ありがとうございます!

JaSST東京ってやっぱりすごい

語彙力なさの極みなんですけど、やっぱりね、JaSSTの東京ってすごいです。
今回聴講内容を記載していないのですけど
熱量のひとつひとつがすごいし、参加者であったり、ブース展示されている方であったり
あれだけの人数が、あれだけの熱量をもってやれるのはすごいことだと思います。

去年実行委員長が「期待していてください。われわれは期待を超えていきます」って言っていたのが
めちゃくちゃ印象的だったんですけど
わたしは、それに少しでも貢献できたのかな?

そして、今年のあいさつでは
「Jasstをもっとアジアや世界の人があつまるような、
国際的なシンポジウムにしたい」とお話しされていたので
来年も、できれば、何かの貢献ができるといいなぁとちっちゃく思うのでした。

モデレータに初挑戦するぞい

前回書いたのですが、
今度、モデレーターというものに初挑戦します。

JaSSTソフトウェアテストシンポジウム-JaSST'19 Tokyo-セッション概要

テストマネジメントのセッションは
この数年実施されている人気セッションです。

そのモデレーターというものに任命されて
ほんとうにありがたいわけですが、
何しろモデレーターも初めてだし
テストマネジメントもきちんとやったこともないわけで・・・・

さて、どうしようかと思ったら、あの t_wadaからありがたい
お返事をいただきました。ネ申かよ(ちがうよ、ライオンだよ)

ありがたく拝聴拝見しました。
ほんとよい内容でした。

実践したい内容

名前と紙とペンを用意しておく

今回のセッションは気心も知った(と勝手に思っている)仲なのですが
もし緊張で名前が飛んでしまったら・・・・

また、何か次までに言わないといけないことを思い出したり
全体の流れを把握するのにも アナログの紙とペンは必要かなって思います。

紹介は短く

podcastの方かな?にあったのですが、紹介がいつまでも続き本題に入らない。
パネルディスカッションは、そのディスカッションの臨場感を聴きたいのに。という話し。
たしかに私もありました。30分くらい紹介されているの。

もう、すぐ!すぐ入れるようにがんばります。

まもなく本会です

パネリストの方々は、もうその3人で話していれば間違いなく面白いし
めちゃめちゃ勉強になる(セッションのためのミーティングの時点でめちゃめちゃ勉強になるわけです)のはわかっているので
モデレーターの腕の見せ所はないかもしれません。
それで、モデレーターのせいで台無しにならないように
がんばろうと思います。

できれば身内感を出さずに
最大限参加者も含めたみんなでキャッキャできるといいなぁ

JaSST'19 Tokyoでお話しするよ

うっかりツイートから半月以上経ってしまいましたが、
JaSST'19 Tokyoでお話しすることになりました。

JaSST'19 Tokyoってなにさ

www.jasst.jp

きっとこのエントリーを読んでくださる多くの方はご存知かと思いますが、
日本で一番大きいソフトウェアテストのシンポジウムになります。

そんなところでお話しするよ

今回は、自分の会社のお話することはなく、JSTQBチュートリアルの講師と
テストマネジメントセッションの司会・・・モデレーターに挑戦します。どきどきです。

楽しみです

2013年から、ほぼ毎年参加しているわけですが、毎年モチベーションだだあがりさせてもらえる
すごいシンポジウムだと思います。
セッションはもとより、たくさんのエンジニアが来られるので、色んなものやつながりを持ち帰ることができます。

今年は参加者だけではなく、提供をする側として、参加していただけるみなさまに
たくさん持ち帰れるものをがんばって用意します!

ご登録がまだの方もぜひぜひお越しくださいね:)

AQA POP TALK でお話ししてきたよ

すっかり書くのが遅くなってしまいましたが

underscore42rina.hatenablog.com

でお話してきました。

発表資料はこちら

www.slideshare.net

反省しているところ

  • 話す内容が多すぎて散らかっちゃった

わたしがよくやらかしてしまうのですが 、 お話しするときに あれも、これも と
話したいことを詰め込みすぎてしまって 結局何が伝えたかったのかわからない

しかも、そういうときの「お伝えしたいこと」が
ふんわりしちゃう(あれもこれも話すから、そりゃふんわりしちゃいますよね)

もういい加減脱却したいのですけど
もうちょっと訓練が必要そうです
次回がんばります(次回とは)

お話ししたかった内容

今回お話ししたかったのは次の3つになります(うん、多いね)

  • 入社して3か月でやったこと
  • QA「チーム」としてのプロセスについて
  • 今まで働いてきた会社と、今の会社でおこなっている開発のプロセスの違い

入社して3か月でやったこと

オンボーディングやメンターが福岡にきてくれた話など
あんまり話してないかも

QA「チーム」としてのプロセスについて

基本的なQAは一人で担当しているので、今までとあまり変わらない(それがこの会社の魅力だと思っている)のですが
Automationチームがいるという環境なのと
チームでも活動するものがあるよ。てお話しをしました。

リリース判定テストというフェーズは今までなかったのでこの業界ならではだろうなというのと
Automationチームが専属でいるので、リグレッションテストのうまいやり方で
さらにスピードがあがるといいなぁと思います。(うん、ふんわりしている)

今まで働いてきた会社と、今の会社でおこなっている開発プロセスの違い

私が一番入社して苦労したのは、たぶんここだと思います。

今まで働いていた会社では、リリースや納品は1システム1チームでおこなうため
わたしは、納品に間に合うようにシステムテストだけに集中すればよかったです。

しかし、今の会社では(Webサービス企業はあたりまえかも?)
1システムに複数のチームがそれぞれ別のプロジェクトを遂行しているし
1プロジェクトでも、アプリと、裏側のバックエンドでリリース時期が異なるし
リリースも段階解放があったりするので、それぞれの組み合わせでもうまく動くようにしなければならないし
そのリリースタイミングにあったテストスケジュールやテストケースを考えないといけません。

また、バックエンドリリース時点で、アプリ側(クライアント側と呼んでいます)が
できていないこともありますので そんなときは、APIツールを使ったりしてテストをおこなう必要があります。

今までの会社とは違う大変さと面白さがあるなぁと思っています。
そして、めちゃくちゃわからんくて、もう何度もエンジニアやメンターに教えてもらっています。

今でもきいてる。神かよ。

立ち上げ関する話

そういえば、立ち上げに特化した話できてないのでは・・・
立ち上げってチームビルディングになるので そうするとQA要素って減っちゃうんですよね。。

でもこれだけで何時間が話ししそうなので、いつかまた。

そんなわけで

もうちょっと、ちゃんとびっくりした話ができたらよかったなという反省とともに
次回、なんか楽しい話ができる機会があるといいなと思います。

大好きなチームで社内表彰されたよ

ということで、プロジェクトチームで表彰してもらいました。うれしい。

わたしたちの会社では4半期(quarter)に1度、表彰の機会があります。
表彰はいくつかの賞があるのですが、
今回わたしたちは プロジェクト賞としてチームメンバーみんなで選ばれました。うれしい。

10月に入社して、最初のquarterで選ばれるってとても運がよいと思います。
わたしたちは開発拠点の立ち上げをがんばっていたところで
そこにがんばれるプロジェクトに携われて
結果うまくいったので
それらをまとめて評価してもらえたということだと思うので
すごくうれしい。

ちょっと前から、わたしたちの誰かかなーという話をしていて
こっそり「本日の主役」タスキを用意していたのだけど
チームメンバー全員で表彰されて、うれしい。(わたしは、このうち少しでも貢献できたのだろうか)

わたしは、やっぱり運がよくて たまたまが重なっただけなので
きちんとこのチームで価値がだせるようになろう。