テストする人。

ソフトウェアテストってわかんない。ソフトウェアテスタ-による、ゆるゆるブログ。

テストランチを社内ではじめた話

2018年もよろしくおねがいします。

ブログではとくにふりかえり(100エントリーのふりかえりはしたけど)も
今年の決意表明もしていませんが
自分らしくやります。はい。

テストランチをはじめてみた

昨年から社内でテストランチというものをお試しではじめました。

テストランチとは

『ゆるく、長く』 をモットーに、 テストについて考える、勉強する、知る、共有する ことを ランチを食べながら設ける時間です。

  • 名前:『テストランチ』
  • 時間と場所:1~2週に1度程度。12:00~12:50 会議室
  • 対象者:何となくテストの話がしたい人(エンジニア、カスタマーサポート、マーケ、バックオフィス、役員問いません!)
  • テーマ:設けるときと、フリーのときを作ろうと思います
  • やること:必ずわたしがいます。テーマがあるときは、それに則った何か(発表者だけ、または全員)を持ち寄るでも、フリートークでもよいと思っています。
  • モットー: ゆるく長く! (事前勉強や宿題はできるだけ設けず、ゆるくやりたいです。ゆるく続けることで意義があればいいなぁ)

誰もいないときは、私が一人でもくもくする予定です(´~`)モグモグ
今のところ誰かしら参加いただいているので、雑談とともにお話しています。

テストランチを開こうと思ったわけ

色々とあるのですが、以下のことを思い、もっと自分が動かないとダメじゃん。 でも重いのは続かないし、カジュアルにはじめたい!と思いました。

  • テスターが複数人になると「お隣のテスターがどんなテスト(やりかた、気持ち、悩みなど)をしているかわからない」
  • エンジニアのテストってなんだっけ?
  • プロダクト(のIssue)以外でテストの話する機会がないよね
  • エンジニア同士、エンジニア、テスター、ディレクター・・・テストの話する機会ないよね
  • コンスタントにテストの話題、課題、やりたいこと、知っていることを話す機会を増やしたい
  • 勉強会を定期開催するのは重いなぁ
  • 一方的にブログや社内共有ツールやSlackに発信しても情報交換がなかなか進んでいない

もちろん↑にペアテストやればいいじゃん。とかすでに出そうな解決策もあると思うのですが
そういうのも含めて話す機会を増やしたいなぁと思っています。

この先のこと

コンスタントに開催が継続できそうであったら、話題に上がった中から

  • 勉強会をする
  • 読書会をする
  • 情報を発信する(ブログなどなど)
  • テストの戦略を考える
  • テストのやり方をかえてみる

とか始められるといいなぁと思います。

テストする人。は、テストできる人になったのか

記念すべき100エントリー目です♡ありがとうございます。

このブログを始めたきっかけ

・・・忘れました。何で作ったんだろう・・・

ただ、技術ブログ系は はてなブログだよね というよくわからないミーハー心で作ったのは覚えていますw

このブログタイトル名になったわけ

プログラマー時代から自覚してたんですが、ネーミングセンスが皆無なのです。
なので、どこかからあやかって付けたりするわけですが、これはUNICORNというバンドの曲名からつけたはず・・・なんだけど、っぽい曲名が「ママと寝る人」しかない・・・(゜-゜)

まぁいいのです。未だに自分の職業名に迷子なので「テストする人。」が一番あってると思っています。

本題

さて、100個くらいテストのこととかコミュニティのこととか書いたり書かなかったりしていますが 何か変わったのでしょうか?

期間にして5年程度。

変わっていないこと

バグ出し がとてもうまくなった 」という自覚は全くありません。ずっと同じくらいの感覚です。

変わったこと

5年前の比較だと、色々ありすぎると思います。

いじめる気持ちから、私がどう動かしたいかどう動いて欲しいか

個人的によく人とお話するのが「テストって意地悪な気持ちでやるんでしょ?」というもの。
それについて、全く気持ちが反対になりました。

以前は「バグを出してやろう」みたいな気持ちでやっていたんですけど、
今は「まず自分が思うように動くこと、その次に こんな動き方もあんな動き方もするよねー。」とネガティブな感情での活動ではなくなりました。

操作とか、試しているテストは結果として一緒なんですが^^;心持ちが正反対になったんですね。

バグを探すから、プロダクトはどうあるべきかを考える

↑が変わると何が変わるかというと、要望とか、操作性とか、プロダクトそのものについて考えることが増えたのではないかと思います。(もちろん、その他にもたくさん要因やキッカケはあるのですけど) それについては、以前SQiPシンポジウムでも少しだけ紹介しました。 www.juse.jp

エンジニアのために工夫するようになった

↑が変わるとともに少しずつ変わったのは、Issue(チケット)の書き方(項目ではなく、ニュアンスや粒度)とか、とにかく「エンジニアが負担にならないためにどう動くと、エンジニアが心地よく動けるか」を考えていたように思います。(とはいっても、もともと私の性格が口が悪い、調子に乗る、悪態をつく、と問題ありだったので、エンジニアたちにとってはそう捉えてもらっていないかもしれません)

Issueの書き方以外にも、やれることはチャレンジしたりしなかったりしています(自分のテストスピードが落ちるものはあまりやりたくない・・・)

説明できることが増えた

「なぜこのテストをするのか」「なぜしないのか」「やるべきか・やらないべきか」「なぜやらなかったか」 今まで 何かを聞かれたときに言葉に詰まることも説明できることが増えたと思います。(あくまでも昔の自分に比べて)

  • テストはやれるならやった方がいい
  • 不安だから多ければ多い方がいい
  • リリース後にバグがでたら、なぜそんな簡単なものも見れなかったのかに対する説明ができない

テスト神話に対する、今の自分の解答、わたしが働いている会社(やプロジェクト)で最適解の説明は できるようになってきたと思います。

QCDやチームの体制、プロダクトの性質で、自分の見解が言えるようになるのはテストをする上で強みになったと思います。
ただ、予算・工数ありきでをベースに考えているところがあるので、もっと必要な部分は、テストを増やすべきだと言えることもできないといけないのかなーとも少し思っています。(テスト軽視になるのも困るだろうし)

テストできる人。なのか

まだまだできないことが沢山(なにしろ、バグを出すのは最初からあんまり変わってない気がしている)あるので、まだまだ「テストできる人。」とは言えません。

200エントリーのときは、もっといろいろできるようになっているといいなぁ

コードを書かないテスターがテスト自動化にどのように介入するか

9日目です qiita.com

qiita.com

わたしの仕事

テストチームが組織としてあるわけではないので、「テスター」と名乗っています。
最近でいうと、「探索的テストを得意とするQA」というのが近いかもなぁと思っています。

何をしているのか

では、普段している内容です。

  • 画面詳細設計書レビュー
  • 探索的テスト
  • スクリプトテスト

探索的テストとスクリプトテストは、私は厳密に切り分けて考えていないことと スクリプトテストで使っている仕様書も、かなりざっくり(いいように言うと、高位レベルテストケース・・・といっていいかなぁ)したものを 使っています。完全に属人化しているテストです。

わたしは、細かいテストケースも書いていませんし、エビデンスのように「テストした形跡」をほとんど残していません。 不具合やカイゼン案はすべてIssueに記載していますので、問題点はすべて残しています。それらを以てエンジニアと合意をとっています。

わたしたちがやっているテスト自動化(テストコード)

わたしたちの会社では、プロダクトを作るエンジニアがテストコードも書きます。 (SETチームはいません) 現在はテストコードやどのテストレベルに対して書くかは、各プロダクトチームのエンジニアにおまかせしている状態です。

テスターはテストコードを書くべきか

今年発売された、こちらの本に紹介してありました。

初めての自動テスト ―Webシステムのための自動テスト基礎

初めての自動テスト ―Webシステムのための自動テスト基礎

これからはテスターも得意とする分野でテストコードを書いた方がよいよね(ざっくり)という内容もありました。
そして、そう思っているQAエンジニアも多いと感じています。

私も、テストコードやプロダクトコードは読めるに越したことはありませんし、テストが書けるのはよいなと思っています。

なぜテスターがテストコードを書かないのか

わたしはテストコードを書いていません。

一時期E2Eのテストコードが書けるとしあわせになれるだろうと、 Turnip+ Selenium の勉強をして、インストールおよび少し書くところまではしましたが 結局定着しませんでした。

何がだめだったか

「テストコードを書く脳」と「テストをする脳」が全く別物だったことと、
そのスピード感とスキルが違いすぎて、運用に乗せられませんでした。

(大前提に、そもそも私はエンジニアをしていた時代に、スパゲッティーコード製造機で、プログラムコード書くのが本当に苦痛だったんでした)

探索的テストが得意なエンジニアは、テストコードを書くのは難しいのではないかと思います。
(または超高速でかけてしまう探索的テスターもいちゃうのかもしれません)
動いた反応を見て、次々に関連付けや過去の経験から次のテストをおこなうため、 コードに落としていくのは勝手が違いすぎるんですよね。(なので、実現できる人はめちゃくちゃ凄いと思う)

テスト手順書をきちんと落とし込めるテスターであれば、得意になる可能性はぐっと高くなるのではないかと思います。
それでも、設計とプログラミングコードを書くときに使う脳が別 っていうタイプの人であれば
難しい感覚はわかるかもしれません

では、どうすればよいか

だいぶ言い訳くさい内容になってきましたが、今、わたしが考えているものは次のような構想です。

  1. どこを自動化するか、場所やボリュームを選定する  プロダクトに対して、テストコードを書くべき機能や内容をエンジニアと決めたいと思っています。
    現在もいくつかしていますが、もっとわかりやすく、テストのピラミッドを使ったり、テストレベルなど見えるようにしたいなぁと思っています。

  2. 必要なテストデータの選定をする  「十分なテストケース」はエンジニアの勘と経験に頼っているままにしているところがあります。  そこにテストの知見を入れられるといいなぁと思っています。

  3. 各人が「すべきテスト」誰がどのテストをするか見えるようにする  現在は「テストをしている」というざっくりとした意識と、Issueの内容しかエンジニアと共有できていないのですが
     各々が「しているテスト、していないテスト」誰がどういったテストをしているかをはっきりさせるとお互いが安心できると思います。

エンジニアと話してみた

このエントリーは数日前からコツコツ書き溜めていたのですが、
昨日(12/8)わたしの上長で兼マネージャー兼エンジニアと話す機会があって、↑の話になりました。

で、できそうなことがあったので追加。

4.お互いに最小限のコストからはじめられるところを探る  私はテストができますし、エンジニアはコードを書いたり、環境を用意したりが得意です。

 バグの再現手順をテストコードに書けないか?という話があがったのですが、いきなりテストコードを書くのはハードルが高いです。
 でも、バグの出た箇所だけなら、ボリュームは多くありません。ですので
 ■わたしができること
  * Issueを書くことができる。再現手順をテストシナリオのフォーマット(Turnipのようなイメージ)で書くならできそう
■エンジニア
  * Issueのテストフォーマットからテストコードを書くならコストがそこまでかからないかもしれない

 ということになりました。やっぱり会話大事。近く、わたしたちのテスト自動化はまた新しい道を進み始めるかもしれません。

で、さらに「初めての自動テスト」を読んで、

これらをユニットに落とし込めるかをエンジニアと話し合う→勝手に落とし込んでいる

状態がお互いにしあわせかもしれないなぁと思いました☺

勝手な結論とまとめ

  • 得意分野を活かすテストをする
  • 自分が持っているテストやバグの知見をエンジニアに共有する
  • 足りないテスト、できているテストをエンジニアに共有し、合意をとる

STAC(システムテスト自動化カンファレンス)に参加します

明日開催される、STAC(システムテスト自動化カンファレンス)に、エンジニア2名と参加します。

九州から遠征しますので、この機会に沢山の方とお話したいです。
アドバイスください!
見つけたらぜひお声かけください:) @rinaにリアクションしてもらえたら、全力で会いにいきます!

エイトソリューションというブレストをやっているよ

どうやらエイトソリューションについてのエントリーを書いていなかったようなので、ざっくり書きます。
後ほど追加します。

エイトソリューションってなぁに?

発案者の山崎先生からの説明を記載します。

今回,私が独自開発したエイト・ソリューションという方法を紹介します。ブレイン・ライティングに分類される方式の1種です。

【どんなときに使うか】
  • 各自が抱えている課題に対して,解法を集めたい
  • グループで議論する前に問題意識を明確にするアイスブレイクをしたい
【やりかた】
  1. 8人1グループで集まって,A3で印刷した用紙(画像)を配布する。
  2. 用紙の真ん中「お悩み,な?に?」に自分の問題意識を書く。
  3. 合図とともに左隣の人に用紙を渡し「こうしてみたら①」に問題への解法のアイデアを書く。
  4. 合図とともにさらに左隣の人に用紙を渡し「こうしてみたら②」に問題への解法のアイデアを書く。前の人が書いた解法と似たようなことを書いても気にしない。もちろん前の人が書いた解法を参考にしても良い。以下,順番に7人分回していく。
  5. そうすると自分の書いた用紙が手元に戻ってくるはず。これを元に議論をする。「こうしてみたら?まとめ」に議論のまとめを書きこむ。
モデレーターのスライド↓(Sway)

エイトソリューションをやってみよう

こんな用紙を作ってね(できればA3くらいがよいです)

f:id:underscore42rina:20171127185325p:plain

過去に開催したエイトソリューション

atnd.org
JaSSTソフトウェアテストシンポジウム-JaSST'17 Kyushu-レポート
JaSSTソフトウェアテストシンポジウム-JaSST'16 Kyushu レポート
JaSSTソフトウェアテストシンポジウム-JaSST'15 Kyushu レポート
JaSSTソフトウェアテストシンポジウム-JaSST'14 Kyushu レポート

意外とやってた

エイトソリューションをやってすごいところ

  • テーマがあってもなくても、成り立つ(悩みを共有できるし、解決策ができたりする)
  • シンポジウムのような「聴講」する参加者も「発言する」「アドバイスをする」ことで必然的にアウトプットの機会ができる(ブログに書いてるかも)
  • 参加者の満足度は軒並み高い
  • モデレーターの力をそんなに必要としなくても大丈夫!

エイトソリューションで気をつけるところ

  • 基本的に8人1組でやるワークなので、端数がある場合に時間をどう使うか考えないといけない
  • ディスカッションの際に全員が初学者の場合はお悩み内容によってはディスカッションしづらいかもしれない

次のエイトソリューション

先日思いついたんだけど

オンラインエイトソリューション

できるよ、これ。気が向いたら開催します:)

ファシリテーション勉強会 平日夜版(第7回)に行ってきたよ

f:id:underscore42rina:20171116124547j:plain

Fukuoka Growth Nextも初登校(名前が旧名称しか見つけきらんかった)

ということで、7回目にしてやっと念願のファシリテーション勉強会にいってきました。

なぜテスターがファシリテーションに興味をもったか

ふりかえりや問題解決にはファシリテーション能力が必要だと思うの

 私は年間30前後のプロジェクトのテストをおこないます。
 各プロジェクトは最後にふりかえり会をするので、私は社内でも一番ふりかえり会に参加しています。

そのときに、限られた時間の中で、問題に対する解決策がでていなかったり、 以前も同じような問題がでていたのにカイゼンされていなかったり、共有がたりないなぁと思っていました。

 私なりに質問をしてみたり、「こうじゃない?」「ああじゃない?」と言ってみることはありますが、  なかなかすべてが解決するのは難しいです。

 また、普段のテスト活動でも「どうしてこうなった?」をエンジニアと解決したいときがあります。
 そのときに「質問力」が大事だと思うんですが、ファシリテーションというものもあると、解決できることも増えるのではないかと思って
 興味を持っていました。

社外活動運営にはファシリテーション能力は必要

 他のエントリーを読んでくださってる方はご存じかと思いますが、私は勉強会やシンポジウムなどの運営に携わっています。
 その中でいくつか私が主体でやっているため、みんなの意見を出したり、まとめたりする必要があります。
 ただ、いままでは自分がやりたいこと!を押し出しすぎて、あまり積極的なディスカッションはできていないなぁと思っていました。
   そこで、もっとファシリテーション能力を身に着けられたら、もっと活発なディスカッションができるのではないかと考えています。

どんな人が参加しているのか

 IT関係問わず色んな方がいらっしゃってました。デザイナーもITエンジニアもコピーライターもいらっしゃいました。

なにをやったのか

 勉強会のファシリテーションは @Garyuten がおこないました。
  @Garyuten は昔から知っていたし、色々お話やら仕事のこととか話す機会はあったのですが、説明などしている姿はたぶん初めてみました。
 すごいわかりやすい!さすが講師されているだけあります!(うっかりだけじゃなかった!)(お仕事ぶりとかデザイナーとしてとか尊敬はしてるけど!)

 端的にでも、丁寧にポイントややり方を説明してくださいました。

まずは乾杯

 今回のワークショップはお酒と相性が良いということで乾杯からスタート(飲んでたのは半分くらいだけど、もちろん私もいただいちゃいました💛)

グランドルールを確認

 今回のワークショップをおこなうためのグランドルールを説明されました。

今回のグランドルールは 株式会社つくるひと が商標登録をしている「5グランドルール」を採用しました。
詳細な説明はこちらをごらんください。 www.biztool.jp

イノベーションカードを使った8question

 ワークショップではイノベーションカードを使いました。

 イノベーションカードについてはコチラ↓をごらんください。 www.dekir.co.jp

やり方

二人一組になって、ファシリテーションする側、される側でおこないます

1. 9つのブロックになるように 紙に縦と横に2本ずつ線を引きます
2. 真ん中に自分の問題(課題)を書きます(←環境に左右されないような悩みがよい)
3. ファシリテーションされる人が、イノベーションカードを1枚ひきます(トランプみたいな感じ)
4. ①と書いたブロックにそのカードの内容と、それについて考えを書きます
5. それを⑧まで繰り返します。

ファシリテートする側は、グランドルールに従って、声をかけたり見守ったりします。
他にも時間制約や、パスルール、カード交換不可などのルールがありました。

わたしの結果

こんな感じ。

f:id:underscore42rina:20171116124547j:plain
ワークの結果

チェックイン・チェックアウト

今回のワークショップではチェックイン・チェックアウトというものもしていて、
きちんとふりかえりや評価ができるようになっていました(長くなるので割愛)

感想

8人で参加しましたが、全員楽しく有意義な時間となったと思います。

私はいつもファシリテート(という自覚はないけど)するときは、たくさんの質問や「あぁじゃない?」「それってこうじゃない?」「それはなんでだろう?」と 質問攻めにしていたんだなぁと反省しました。

イノベーションカードについては、衝撃的だったのは「捨てられないもの」をひいた次の次に「全て捨てる」カードがでてきて

ふぁっ?!

ってなりました。びっくりです。
ただ、それで一度テーマを捨ててみると、まったく違う発想(AIにまかせる未来がきたら、英語できなくてもいいじゃん)になったので
おもしろかったです。
固定概念をぶちこわすの面白いですね。

おわりに

イノベーションカードはこのほかにもいろいろな使い方ができるそうです。引かせるだけでなく、ファシリテーターが指定するようなやり方とか。
なんとなくあーだこーだいうだけでなく、このカードがあることで、議論が活発になるのはおもしろそうだなーと思いました。

また、この会自体もよく構成が考えられていて(へべれけでもできるってすごい!すごいよ!)
会自体の運営もとても勉強になりました。
お持ち帰りできるもの!というキーワードは自分のシンポジウムでもすごく考えているところなのでうれしかったです。
さっそく、真似できるところは実践したいと思いますヾ(´∀`)ノ

ありがとうございました:)

いいんちょ2017

もうなんか、タイトルに「いいんちょ」つけないといけない気がしてきた。

過去のいいんちょエントリー
underscore42rina.hatenablog.com

underscore42rina.hatenablog.com

underscore42rina.hatenablog.com

気になったかたはtogetterも見てね

togetter.com

すごく肩入れして、その期待値を超えた会ができた

当然だけど、私が一番毎年 この会を参加者としてみたいコンテンツにしてきた。
毎年そうだけど、今年はさらに私のわがまま要素、無茶ぶり要素を取り入れてると思う。
(と、毎年思ってる気がする)

でも、絶対面白いし、絶対参加者の方に得られるものがあると思うし、 もう!私の住んでいる地域で絶対講演してほしいし
最前線のすごい人のすごい仕事の話も聞きたいし
関東だけじゃなくて、地元にもこんなにおもしろい、前のめりな人たちがいるんだよ!
ていうことを届けたくてコンテンツを構成した。

その期待は、私の期待をはるかに越していただいたおかげで
当日裏方として走り回っていた私は、逆に「まじで見たかった・・・」とうらやましく思ってる。
ほんと、聴講したかった(・´з`・)

あとから動画で見れるように撮ってるけど、それすらまだ手元にないのがはがゆいし
会場にいたとはいえ、すべて生でみたかった。ライブってそういうことだと思う。

いいんちょとして何ができたのか。

さて、今回4回目となるいいんちょ。少しだけ大人になった というより
そろそろ交代も意識していたし、またとても若い委員も入った(といっても、委員としては圧倒的戦力だった)とか
少しだけチャレンジとかした

レビューを入れた

今年、すっごく個人的なチャレンジとしては、ドキュメントレビューを何人かにいれてみた。
具体的には、タイトルとアブストラクト、最後ちょっとだけスライド資料も。

私のレビュースタイルは、特にトラディショナルなものではないけど、 普段テストしているのと同じ感じでレビューしてる。

私が入ったことによる成果があったのかどうかはわからないけれど、 一人は本当に出ることが不安になってしまっていたので、 自信を持って送りだすことができてよかったと思う。(といっても、彼女は本番にぜったい強いから大丈夫だったと思うけど)

普段どんなテストをしているか見たい って方は 何かドキュメント(文章でもスライドでも)持ってきてもらったら、 レビューすると、わかってもらえるような気がしてきた。

また、スライド入手と同時に、タイトルもあらためてつけなおす ということもしてみた。
本来なら、先の方を(仮)としておいた方がよかったんだろうけど。でも、より具体的につけられるならその方がいいよね。
私はそのスライドとタイトルを見て興奮した。

想うところ

ここ3年ほど(つまり、ひとりでいいんちょをやったすべての年で)当日は、激しく凹んでいる。
先に書いたとおり、本会は本当に盛り上がったと思うし、大成功だったんじゃないかと思う。

でも、自分が役目を背負いこみすぎて、主体的に動けずにいた人がいたり、
それを見て「抱え込みすぎじゃない?」と心配していただけたのがさらにプレッシャーになったり
あれもこれもと自分がやることによって、結局漏れとか見落としとか、当日に何度もお願いしなおすことになって
集中したいときに邪魔してしまったり、自分のせいで、他の方にかえって負担になってしまったり。

実際は委員で分担してもらったり、早めにヘルプ出していたので、当日まではそこまで・・・きっとそこまで 大変じゃないようにしたと思うのだけど。

当日心地よく過ごせてもらえた人はどれだけいたんだろう?とか思うと

本当に毎年自分がいいんちょで申し訳ないし、消えてしまいたいくらいの気持ちになる

そしてまた息を吹き返す

翌日からのお休みで、アンケートの集計をしたり、撮影した写真の整理とか、Twitter読んだりとかすると
参加者のみなさまからのフィードバックを見て、
やっぱりこの会は楽しかったんだ、やってよかったなぁと思う。

当日も、「楽しいです」という声や「九州のJaSSTはアットホームであたたかいです」というような声をいただいた(偶然だけど、去年もそういうことを言ってくれた方がいた)

プロデュースに目覚めたのかもしれない

多分昔からその素質はあったのかもしれないけど、最近はとくに
面白そうなネタとか人とかをいかに押し上げるかが楽しくなっちゃってるような気がする。

そもそもテストとかレビューとかって、人が作ったものを 「さらによくするにはどうすればいいか」って考えるものだと思っているので
自分よりも他の人に興味があるのかもしれない。

これからのいいんちょ

どうやら毎年「今年最後のいいんちょです」と言ってるらしい。
私も業界では全然ぺーぺーだけど、
それでも次の世代が新しいものを主体的に作っていって欲しいと思うので、毎年最後かなーと言ってる。

ただ、一旦凹みまくって、気力を取り戻すと、楽しかったこととか嬉しかったこととか思いだして
来年やりたいこととか思いついてしまったら最後、やりたくなっちゃうので
宮崎駿的な感じでやってるかもしれない(ってボスに言われた)

デブサミ九州に今年もいってきた、そして懇親会LTにちょっとだけでた話

ちょっともう走り書きのようになるけど

event.shoeisha.jp

にいってきました。あと、3年連続自分がやってる勉強会がオフィシャルコミュニティとして参加していました。

といっても、ほんとーにほんとーに仕事が切羽詰まっていて(久々にデータがっつりにらめっこしないと終わらないやつ)
泣く泣く1セッションしか見られなかったのですが・・・

そう思うと、弊社に近いアクロス最高!ありがとうアクロス!

聴いたセッションはこちら(それも遅れてしまっちゃったけど)

http://event.shoeisha.jp/devsumi/20170922/session/1457/

一言でいって、勉強は筋トレ、結果にコミット

知識だけあっても ただのうんちく王だし
筋トレ毎日しないといつまでも自分のものにならないし
ちゃんと結果にコミットするって大事だよね。コミットしなきゃね。

というすごくざっくりした感想と

セミナーだけ受けてわかった気になっても
それを読書会とかやって、勉強してわかったどうか理解して
勉強会とか発表するような場でアウトプットすることにより 自分が理解しているか、またそのフィードバックを受けられるということ

という3つの話が ものすごーーく腹落ちして、来てよかったー!ってなりました。

セッション終了後も会場で何人かお話したり、紹介していただいたり ちょっと聞きたい情報を教えていただいたり
次の勉強会の話をしたりと

会場に1時間居れなかったんですけど、ものすごーく有益な時間がすごせました。

ありがとう!デブサミ
デブサミ最高!ってなりました💛

来年は登壇できるような何かがあるといいなぁ。わたし。

懇親会はオフィシャルコミュニティのLTをさせていただけるとのことで
昨年同様勉強会の告知とシンポジウムの紹介をしました。
若干すべりましたが気にしません。強くなったぞ。

懇親会会場では、拝聴したセッションの登壇者である吉川さんがいらっしゃっていたので
後半がっつり捕まえてw
色々お話聴かせていただきました。おもしろかった💛

特にUX読書会でやってる8分読書はマジ目から鱗で 「もう、川に向かって天才!って叫びたいです!」って言ってました。えぇ言ってましたとも。

8分読書についてはこちらがとても参考になると思います。

nobkz.hatenadiary.jp

これなら、その時間にインターネットとテーマの本さえ手元にあれば 準備いらずでできちゃうやん!天才!すごいすごい!

と、興奮再びですが、とにかく今年もデブサミ九州参加できてよかったです。

ありがとうございました:)
来月以降テストクラスタ8分読書やろー💛