アジャイルマインド・インストレーション体験セミナー参加レポート

有償ワークショップのダイジェスト版を無料で体験できる太っ腹なセミナーが開催されるということで、1月24日にグラーツ社主催のアジャイルマインド・インストレーション体験セミナーに参加してきた。(募集サイト
このセミナーは13:30-16:30の半日のセミナーで、前半講演、後半ワークショップという構成だった。
参加者は15名くらいで、3〜4人のグループを4つ作ってワークショップに臨んだ。
参加者の属性は、SM経験者が半分くらい、PO, Dev経験者が数名、スクラム未経験者が2名くらい。
講演とワークショップの内容は以下の通り。

講演「アジャイルコーチと辿る価値と原則」(30分)

  • アジャイルソフトウェア開発宣言の4つの価値と12の原則、スクラムガイドの理論・価値基準・チームの紹介と、スクラムにおけるマネージャの役割の説明がメイン。
  • スクラムにおける"確約"を『スポーツ選手が「必ず勝ちます!」と試合前に宣言するようなイメージ』と説明していて、すごくいい説明だと思った。パクろう。
  • マネージャの説明はエッセンシャルスクラムとLeSSからの引用が多かった。マネージャとチーム間の権限委譲については、エッセンシャルスクラムに掲載の以下の表を参照しながら話すとスムーズとのこと。
    f:id:sonomirai:20200124210253p:plain
    Appeloによる7段階の権限レベルとその実例 (エッセンシャル スクラムより)
  • 組織にアジャイルを広める際には書籍「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」がとても参考になるとのことだった。読もう。
  • あと、昨年 技術書展で頒布された「アジャイルコーチからのアドバイス」についての言及もあった。読もう。500円だし。

ワークショップ「スクラム・ペルソナ・ロールプレイ」(120分)

  • 受講者がセミナ申し込み時のアンケートに記載した「アジャイルスクラムの困りごと」から各グループ1つテーマをピックアップし、そのテーマについてPO/SM/Devの視点で「問題への向き合い方」「対処」「予防」をディスカッションするというワークショップ。

  • 「ペルソナ」とある通り、架空のスクラムチームのペルソナを用意して、そのチームが受講者の挙げた「アジャイルスクラムの困りごと」に遭遇した場合にどう対処すべきかをディスカッションする。

  • ワークショップに当たって決まっていることはスクラムチームのペルソナのみで、スクラムチームが作るプロダクトのカテゴリやスクラムチームのロケーションといった細かい点については言及がなく、グループで仮定を置いてよいということで、以下の2点から丁度よく抽象化されているという印象を持った。

    • ロールプレイの設定と受講者の記載した「アジャイルスクラムの困りごと」がかち合ってディスカッションが進まないということもなさそう。
    • もしチームビルディングの一環でスクラムチームがこのロールプレイをやろうとした場合、ペルソナを設けていないとついつい自分たちのスクラムチームと重ねて個人攻撃をしてしまいそうだが、ペルソナを設けてあることで、自分たちのスクラムチームとは切り離してディスカッションをすることができそう。
  • 各グループの取り組む「困りごと」が、他のグループと被らないように決めたら、まず自分たちが取り上げた「困りごと」について30分ディスカッションし、PO/SM/Devの視点で「問題への向き合い方」「対処」「予防」をポストイットに書き出して、模造紙に貼る。模造紙は以下のような構造になる。

    PO SM Dev
    どう向き合うか
    どう対処するか
    どう予防するか
  • 次に隣のグループに移って、隣のチームが取り上げた「困りごと」について、20分ディスカッションする。(2回目以降は、前のグループが貼ったポストイットが残っているので、まずはそれを参照して、共感したらシールを貼った。)これを4チーム分繰り返した。

  • 今回選出された4つのディスカッションテーマと最終的な模像時の状態は以下の通り。

    f:id:sonomirai:20200124210433j:plain
    テーマ:個別最適の考え方が強く、全体最適の考え方を持ってチームが行動できていない
    f:id:sonomirai:20200124210625j:plain
    テーマ:品質とスピードをトレードオフの関係で捉えてしまう
    f:id:sonomirai:20200124210700j:plain
    テーマ:SMがアジャイルスクラムもよくわかっていない
    f:id:sonomirai:20200124210744j:plain
    テーマ:ビジネスサイドは日本、開発チームは海外子会社という環境で、効果的にスクラムを浸透させる方法が知りたい

  • なお「どう向き合うか」には、基本的にアジャイルの価値や原則、スクラムの理論や価値基準から選んだワードを記載する。(その他でもOK。)以下はワード選びのために配布いただいた資料。
    f:id:sonomirai:20200124210826j:plain
    アジャイルスクラムの価値・原則が載っている資料

感想

  • スクラムセミナーというと、ともすれば自己組織化の話やフレームワーク(ロール・イベント・成果物)の話が中心で、アジャイルの価値や原則、スクラムの理論や価値基準の説明はさらっと流してしまうこともあると思うが、このセミナーはアジャイルの価値や原則、スクラムの理論や価値基準について、受講生にしっかり考えさせるプログラムになっていて、とても勉強になった。
  • また普段はスクラムチームにおける自身のロールを前提として価値や原則を考えがちだが、このロールプレイは一回そこをクリアして、PO/SM/Devそれぞれの視点から、価値や原則に基づき、具体的なアクションを追求できるという点も勉強になった。
  • ぜひ組織に持って帰ってほしいということだったので、折を見て自社でもロールプレイをやってみたいと思う。(KPTの結果、なかなかTryに取り上げられない重めのProblemがあった場合には、このロールプレイのテーマに取り上げると、アジャイルスクラムの価値や原則と照らし合わせて、フラットなディスカッションができて良さそう、という印象を持った。)

スクラム関連書籍の簡単な書評とオレオレ読書術の紹介

8月はスクラム関連の書籍を3冊読んだ。

  1. エッセンシャル スクラム
  2. スクラム現場ガイド
  3. アジャイルコーチング

この記事ではそれぞれの簡単な書評と、3冊を読みながら編み出したオレオレ読書術を紹介したい。

簡単な書評

エッセンシャル スクラム

  • スクラムガイドには載っていないスクラム開発の具体的なノウハウが載っている書籍
  • スクラムガイドが将棋のルールについて述べた本だとするなら、この本は将棋の定石について述べた本というイメージ
  • この書籍を初めて手に取ったのはAgileJapan2019に設置してあった旅するアジャイル本箱だった。当時は計画会議の具体的な進め方(1部制?2部制?)や見積の単位(ストーリーポイント?時間?)について、人に説明できるほどの理解がなくて困っていたので、旅するアジャイル本箱の書籍を読みまくったのだが、そのあたりの具体的なノウハウが載っているのは、この書籍だけだったように思う。
  • スクラムマスターなど、スクラムを推進するような立場の人は手元に置いておいて損はないと思う。私はスクラム関連の書籍で一番のおすすめは?と聞かれたら、この本を挙げる。

スクラム現場ガイド

  • 3冊の中だと一番おすすめしない
  • 各章の構成が、冒頭でよくある失敗事例を紹介し、その後失敗を回避するための教訓を紹介する構成になっているのだが、この失敗事例に出てくる登場人物が毎回違うので、まずそこを理解しなければいけないのがだるい。読書の量に対する学びが少なく、コスパが悪いと感じた。
  • 取り上げられている教訓も、他の書籍で述べられているものが多い印象だった。「28 章アウトソースとオフショア」、「30章 契約の記述」あたりのトピックは初見だったので勉強になった。
  • この書籍を読むよりは、カイゼン・ジャーニーを読んだ方がいいと思った。スクラムのノウハウを、江島さん主人公の物語形式で学ぶことができて、一貫性もあって、感情移入もできるため。

アジャイルコーチング

  • スクラムマスターやアジャイルコーチの立場の人は、読んでおくと良いと思った。私はコーチングの経験がほとんどないままスクラムマスターになったため、自身がアンチパターンに当たるコーチングをしていないか若干の不安があったが、この書籍を読む限りそういったことはなさそうだと思え、自信に繋がった。
  • ただスクラムの経験、コーチングの経験の両方を有している人であれば、それほど目新しいトピックはないはずなので、読まなくても良いかと思った。

オレオレ読書術

簡単に言うと、電子書籍スマホの音声読み上げで聞きつつ読書するという読書術。
昔から音声読み上げ機能を使った勉強はしていたが、今回はその音声読み上げ機能を、読書の補助ツールとしてがっつり使ったという感じ。
ちなみに音声読み上げ機能を使った勉強方法についてはこちらで詳しく述べました。

必要なもの

スマートフォンだけでもいいが、個人的には電子書籍リーダーがあった方が、以下の点が良い

  • スマートフォンKindleアプリより電子書籍リーダーの方がハイライトしやすい(端末が大きい&慣れている)
  • スマートフォンKindleアプリの方は音声読み上げ機能が勝手にページ送りしてくれるが、電子書籍リーダーの方は(当たり前だが)ページ送りしてくれず、ボタン押してページ送りする必要があるので、少しだけ寝落ち防止になる気がする笑

メリット

  • ただ読むより集中できるので、書籍を早く読むことができる

具体的にどれくらいの速さで書籍を読むことができるか定量的に示したかったので、アジャイルコーチングの各章を読むのにかかった時間を計測してみた。

  • 1章 23分
  • 2章 17分
  • 3章 24分
  • 4章 20分
  • 5章 24分
  • 6章 18分
  • 7章 25分
  • 8章 15分
  • 9章 18分
  • 10章 21分
  • 11章 24分
  • 12章 16分
  • 13章 18分
  • 14章 15分

ということで、4時間38分(278分)で物理の本だと236ページの書籍を読み切れたらしい。
個人的な感覚だが、書籍一冊をこの時間で読み切れるのってだいぶ早い気がするので、今後もこのオレオレ読書術を使って、スクラム関係中心に様々な書籍を読みたいと思う。

第25回 Scrum Masters Night!参加レポート

はじめに

第25回 Scrum Masters Night!に参加してきたので、簡単にレポートします。初参加でしたが、めちゃめちゃ勉強になった&楽しかったです。

イベントの流れ

まず参加者は、事前に考えてきたディスカッションテーマを紙に書きました。次にディスカッションテーマを集めて投票し、テーマを9つに絞りました。その後は話したいテーマ毎に席に分かれて、途中参加・途中退席OKの形式でディスカッションを1時間行いました。(こういったディスカッション形式をオープンスペーステクノロジーOST)というそうです。)

取り組んだディスカッションテーマ

私は、希望した「スクラムチームの状態を可視化するためのメトリクスと、その取り方」というテーマが9つのテーマの1つに選んでいただけたので、このテーマについてディスカッションしました。人数の増減ありつつ、5〜10名くらいの方でディスカッションしました。ディスカッションテーマ記載用紙は以下のような感じです。

f:id:sonomirai:20190822004002j:plain:w400
ディスカッションテーマ記載用紙

メトリクスについての6つの学び

みんなが見ているメトリクス、見てないメトリクス

  • ベロシティはみんな見ていた。ストーリーポイントで見る方、時間見積で見る方、両方見る方と様々でしたが、みんなベロシティは見ているということでした。見る観点としては、予実の乖離、スプリント毎のブレなど。
  • サイクルタイムはみんな見ていなかった。これは少し意外だった。収集&評価が面倒という声があり、そうですよねぇと思った。

目標あってこそのメトリクス

私がこのディスカッションテーマを選んだ背景としては、「外部のステークホルダにスクラムチームの(改善の)状態を数値として見せるためにはどうすればいいか?」というのが念頭にあったので、最初はその方向で話をしていました。ですが参加者の方の「メトリクスを取る際は、今のスクラムチームの目標がないと、意味のあるメトリクスは取れないと思う。それなしでメトリクスを取っても、メトリクスに踊らされることになりかねない。」というコメントにはッとさせられました。その方は具体的に以下のように目標に対するメトリクスを設定して、目標を達成できたらメトリクスは捨てていたそうです。

  • 目標:スクラムイベントを極力減らして、価値を届ける時間に回したい
    • メトリクス:スクラムイベントにかかる時間を計測
  • 目標:使われる機能だけを作りたい(+メンテしたい?)
    • メトリクス:ロギング機能を仕込んでログから各機能の使用率を算出

自己組織化のメトリクス

  • この話題になってディスカッションがカオスになった。自己組織化おそるべし笑
  • ちょっと違うけど、クロスファンクショナルのメトリクスとしてはスキルマップが有効という話になった。

品質のメトリクス

  • これが品質のメトリクスだ!というのはなくて、むしろスクラムには動く成果物があるのだから、それをスプリントレビューでしっかり見るのが第一、という話になった。
  • 周りがウォーターフォールでリリース時に承認スタンプラリーやっている環境でも、スプリントレビューでお客様がOKを出してくれているのであれば、リリース承認時のスタンプラリーをスキップできる、という整理をしているスクラムチームもあるとのことだった。

メトリクスの取り方

「メトリクスを手動で取るのは辛くなってやらなくなるからアンチパターン、メトリクスを取るなら自動で取れる仕組みを入れよ!」みたいな話を聞いたことがあったので、その辺りを聞いてみたところ、皆さんその辺りにこだわりはないようでした。特に目標に沿ったメトリクスを取得するという文脈でいうと、チームの目標にぴったり合ったメトリクスが自動で取れることなんてそうそうないから、最初は全然手動でやるという話だった。それで目標が達成できた段階で、もう不要だとねといって捨てるメトリクスもあるし、継続的に必要なら自動化を考えればいいということだった。

カラーコードドット

チームの状態を可視化する方法のひとつとしてカラーコードドットというものもあるよ、と教えてもらったので、こちらについても調べてみようと思います。

ディスカッション時に作成した模造紙は以下のような感じです。

f:id:sonomirai:20190822004241j:plain
ディスカッション時の模造紙

おわりに

ただただ学びしかないイベントでした。主催者の皆さま、参加者の皆さまありがとうございました。今日の学びをうまく消化して、明日からの業務に役立てたいと思います。

Design Research Tokyo: Season 1 Episode 6参加レポート

[6/22 追記]

  • 雰囲気がわかるよう、Design Research TokyoのTwitterに載っていた写真を追加
  • 登壇者の方の資料・ブログへのリンクを追加

6/17に六本木のDMMで開催されたDesign Research Tokyo: Season 1 Episode 6に事業会社枠で参加したので、簡単にレポートする。 今回の勉強会は、参加者同士のワークショップあり、「リサーチチームの組織力」がテーマのトークあり、たっぷり時間をとったQAタイムありと盛りだくさんでとても楽しかった。

ワーク

「私」「自分の所属する部署」「顧客と接点のある部署」およびその繋がりを簡単に図示して、近くの席の人と共有した。私のグループは事業会社の人が多かった。経営者の方もいた。

トーク

リサーチチームの組織力(DMM) 伊藤さん

  • UXリサーチャー
  • 2009年頃 UXとの出会い
  • 産業技術大学院大学人間中心デザイン履修証明取得
  • どんどんサービス作る会社ならリサーチが必要になるだろうと思って2017年にジョインした

リサーチの組織

  • 専門組織はない、なくなった。
  • どうやってリサーチの業務をやっているのか?
    • 個別に来た話をきっかけにやっている。
    • もともとUX部があったけど、なくなって、メンバーはちりぢりに。
    • ただ逆にUXリサーチが認知されやすくなった
  • UXリサーチ相談の例
    • ブランディングワークってどうやったらいいですか?
    • 「課金してでも使いたい」と思うほどに価値を感じてくれるのはどこなんだろ
    • デザイナー「リニューアルに際して3つクリエイティブ作った。どれがいいか調査したい」(UX界隈の方はデザインの成果物のことをクリエイティブというらしい。)
    • SEO効果で流入が多いのはわかったけど、何を求めているかわからない
  • 競輪のUXリサーチに行った。その場でかけてみて、チームで使いやすい、使いにくいの評価をした。これは良かった。

リサーチチームの組織力(メルペイ) 松薗さん

リサーチチームの組織力(LIFULL) 小川さん

  • 資料:リサーチチームの組織力 評価からデザインリサーチヘ
  • ブログ:リサーチチームの組織力
  • 人間中心デザイン受講
  • UXリサーチではなく、組織横断で定性評価をメインにやっている。
  • 以下の通り、下流工程から徐々に上流工程に食い込んでいっている
      1. 運用前の評価:操作性を評価 使えるかの評価
      1. 設計・開発の評価:仕様を評価 伝わるかの評価
      1. 要件定義の評価:コンセプトを評価 魅力的かの評価
  • 人がデータベース化してしまって、スケールしないところが問題点
  • メルペイの松薗さんの話と共通するところ多い
  • これから試したいことは、プロジェクトチームに「すこしできる人・すこしわかる人」を増やすこと

ディスカッション

  • 3名の方のトークを聞いて、グループでディスカッションした。トークの中で以下の話題はスピーカーの中で共通するところあって、印象に残ったという話をした。
    • 組織にこだわらずUXリサーチを(勝手に?うまいこと?)やって、社内で信頼を得る
    • 「成果物の検証」工程からUXリサーチとしてチームに協力して、徐々に信頼を得て上流工程にも入り込む
    • 人が少なくてスケールできない点に課題感を持っている
  • 私は、下流工程から始めて徐々に上流工程に行くという話と、3名中2名の方が産業技術大学院大学の人間中心デザインを受講したという話が印象に残った。産技大の授業いいのかな。受講したいな。
  • あとディスカッションの中で「肩書大事」って話をした。私はそれまで肩書を自由に決められちゃったら、肩書の意味がなくなるのでは?と思っていたが、従来の肩書に加えて、自分が名乗りたい肩書を設定することで覚悟を決めたり、情報を集めやすくするのは大事かもな、と考え直した。よく考えると、肩書以前の部署の名前についても、その部署の現在の姿(AsIs)というより、その部署のなりたい姿(ToBe)を表している、ということはざらにある気もするし。(今の私の所属組織がそうだとは言う訳ではない)なので、肩書だってある程度自由度持たせてもいいのかもなと思った。

f:id:sonomirai:20190622110713j:plain
ワークショップの様子

QA

  • 定性評価での説明、説得って難しいのでは?定量評価でないと信頼されないのでは?

    • 相手がわかる言葉でN=1の重要性について説明することが大事。その後、ABテストで結果を見せてドヤる!
    • 定量主義の人は無視して、定性が知りたい人を最初は相手にした。それで結果を出すことで、定量主義の人も変わっていった。
    • 定量って「何でこうだったのか?」の説明には足りないので、定性評価も使う。
    • ちょっと話が変わるが、定性評価100人やって、その中で離脱率とかも測っておいた。それが定量評価の結果とほぼ同じだった。100人もやると定量評価に近づいてくるなと感じた。
  • 社内でのUXリサーチの知名度向上

    • 前職ではひたすら価値を伝え続けた。ただ自分の貴重な時間をずっと説得に費やすのはいかがなものかと考え、最初から職種にUXリサーチャがある今の会社に転職した。
    • 勝手にレポートを出し続けた。あと、見える場所でワークショップやるとか。
  • UXデザイナーとUXリサーチャーの違いは?

    • UXデザイナーとUXリサーチャーって、結構脳みその使い方が違う。UXデザイナーは仕組みづくりが仕事、UXリサーチャーはUXデザイナーとしての自分のアウトプットの検証が仕事だと思っている

MacのVSCodeでSpringプロジェクトを動かす

Spring BootのプロジェクトはSpring Boot Extension Packをインストールしたら簡単に動かせたのだが、Springのプロジェクトは動かすのに苦労したので、記録を残しておく。
前提としてSpring BootはTomcatを内包しているが、Springはそうではないので、Tomcatを準備して動かす必要がある。

ざっくりとした手順は以下の通り。

  1. VSCodeTomcat for Javaをインストールする
  2. MacTomcatをインストールする
  3. Tomcat for JavaTomcatのインストール先ディレクトリを選択する
  4. Springプロジェクトをビルドする
  5. Tomcatを起動する
  6. ブラウザアクセスする

ビルドツールはmavenを想定している。

1. VSCodeTomcat for Javaをインストールする

特筆事項なし

2. MacTomcatをインストールする

以下の通りインストールする

MacBook-Air-3:report anhirayuuta$ brew install tomcat
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> New Formulae
gcc@8
==> Updated Formulae
abyss           fastme          kahip           octave          r
armadillo       fftw            lapack          open-mpi        reprepro
arpack          gcc             libxc           openblas        root
bazel           gjs             lysp            packmol         scalapack
binwalk         grib-api        mmseqs2         petsc           scipy
cp2k            hdf5            mpich           petsc-complex   spades
dungeon         hdf5@1.8        mvnvm           pgplot
dynare          imake           netcdf          plplot
eccodes         json-fortran    nwchem          qrupdate
==> Deleted Formulae
minisat

==> Downloading https://www.apache.org/dyn/closer.cgi?path=/tomcat/tomcat-9/v9.0
==> Downloading from http://ftp.jaist.ac.jp/pub/apache/tomcat/tomcat-9/v9.0.19/b
######################################################################## 100.0%
==> Caveats
To have launchd start tomcat now and restart at login:
  brew services start tomcat
Or, if you don't want/need a background service you can just run:
  catalina run
==> Summary
🍺  /usr/local/Cellar/tomcat/9.0.19: 638 files, 14.6MB, built in 7 seconds
MacBook-Air-3:report anhirayuuta$ which tomcat
MacBook-Air-3:report anhirayuuta$ cd /usr/
bin/        libexec/    sbin/       standalone/ 
lib/        local/      share/

インストール先ディレクトリは「/usr/local/Cellar/tomcat/9.0.19」となった。

3. Tomcat for JavaTomcatのインストール先ディレクトリを選択する

  • 「⬆️ + command + p」でAdd Tomcat Serverと打つ。
  • Tomcatのインストール先ディレクトリの選択画面になるが、「/usr/local」みたいなパスが指定できない。
  • 「⬆️ + command + g」で「フォルダの場所を入力:」という覧が表示されるので、先ほどの「/usr/local/Cellar/tomcat/9.0.19」を入力する。
  • ここをTomcatのインストール先ディレクトリとして指定すると「Please make sure you select a valid Tomcat Directory.」というエラーが出るので、「/usr/local/Cellar/tomcat/9.0.19/libexec」を指定する。するとエラーは出ない。(問題なく設定できた旨のメッセージは表示されないっぽい。)

4. Springプロジェクトをビルドする

mvn package

BUILD SUCCESSのメッセージを確認する。

5. Tomcatを起動する

  • 「⬆️ + command + p」でRun on Tomcat Serverと打つ。
  • target配下のwarを指定する。
  • OUTPUTビューにTomcatのメッセージが出力される。

6. ブラウザアクセスする

  • localhost:8080にアクセスすると「Tomcat for Visual Studio Code」というページが表示されるので、「War Packages Deployed on this Tomcat Server:」からアプリを選択する。

かなりざっくりですが、こんな感じでできました。
こちらのQiitaを大いに参考にさせていただきました。

Design Research Tokyo: Season 1 Episode 5参加レポート

4/17に六本木のGoogle Japanで開催されたDesign Research Tokyo: Season 1 Episode 5に参加したので、その時のメモを掲載します。間違っているところや不足しているところも多々あるかと思いますがご了承ください。
3名の登壇者の発表はどれもとても勉強になりました。特に皆さんがおっしゃっていた「リサーチをプロダクトにどう活かすかを常に意識する必要がある」という話が印象に残りました。

タイトル見逃した(Yumi Koyama)

  • アメリカの大学でアートをやってWebやって2010年から2018年までGoogle Japan。現在はFarmnoteに勤務。

What's research for?

  • 体験談として聞いてほしい。
  • Google入ってから「どうやってユーザは使っているのか?」を疑問に思いリサーチを始めた。
  • 私にとってのリサーチは、ユーザにいいもの届けたいってだけ。研究ではなくて、もっとデザインよりに捉えて、どうやったらリサーチをデザインに活かせるかを常に意識している。
  • Googleには20%ルールがある。
  • Information Architect。やっていたことはUXリサーチとかぶるところある。
  • マーケティングウォーターフォールというか一発きりのイベントが多かった。
  • プロダクトはアジャイル。改善。リサーチャーのもとで実践を学んだ。

Online Masters of HCI program IOWA

  • HCI = Human Computer Interaction
  • Googleにいる間に学んだことを形にしたかったので受講した。
  • 長所:いつでもどこでも。働いていたので、習ったことがすぐ活かせた。
  • 短所:知り合いできない。コース全体のうちの30%くらいしかオンラインで受講できなかった。

Farmnote

  • 牛の首にセンサつけて繁殖サイクルとか病気とかを可視化するプロダクト。
  • 人間と一緒で、牛乳は仔牛産まないと出ない。いかに妊娠させるかが農家にとって重要。
  • 健康じゃないと繁殖しない。いかに牛の健康状態を可視化するかがプロダクトのミッション。
  • 営業についていって農家のリサーチした。
  • 病気の牛のミルクはタンクを分ける。
  • カードソーティングで何が農家にとって重要かをソーティングしてもらったりした。

GoogleとFarmnote

  • やってみて
    • 知り合いづてないと農家に会うのは難しい。知り合いいないところに飛び込みで行くのは相当厳しい。今回は会社の営業がリレーションを作ってくれていた。
    • 農家の方が報酬なしに色々話してくれて、最初は驚いた。あっちにとって見返りないのに。来てくれるだけで嬉しいみたい。
    • 小さい会社の方がリサーチ結果をデザインに反映しやすいので、それが良い。

QA

  • リサーチをするために、農家訪問前に何を準備した?
    • 何回かはついていくしかない。それで農家みんなが課題と思っていそうなところを深掘りしていく。基本は手探り。
  • 転職した理由は?
    • リサーチが好きな理由ってなんだろうと思った時に、全く知らないことを知るのが好きだったから。Googleには素晴らしいリサーチャたくさんいるので後ろ髪引かれる思いだったけど。
  • 他のチームを巻き込んだ経験は?
    • 転職したばかりなので、まだあまりない。営業と回っていて、営業は私のリサーチの手法(カードソーティングとか)を見ているので、やりたいと言われることはある。

定性調査を通じてエンパシー(共感力)を高めるには(Dara Gruber)

UXリサーチの歴史@Google Japan

インパクトのある定性調査の特徴

  • 反復可能性、透明性、楽しさ

理想的なプロセス

  • デスクリサーチ
  • エキスパートレビュー
  • プロトコル作成
  • 調査実施
    • リクルーティング
  • シンセシス
  • 知見の伝達
  • ???
  • 主要ステークホルダーにノートテイカーとしてセッションに参加したいかを聞きましょう
  • ステークホルダーがデータをどう解釈するのかを理解するために、シンセシスのワークショップ開催などグループでのアクティビティを行いましょう
  • 気に入っているアイスブレイクは、ペアになって、片方が2分間「〜〜だから熊はすごい」と言い続けて、片方が数を数えるアイスブレイク。競争っぽくなってたくさん言葉が出てくるのがいい。ステークホルダとの信頼関係が厚いほどクレイジーなアイスブレイクができる。

繰り返しのユーザリサーチがなぜいいプロダクトを生むか(坂田 一倫)

  • Pivotal Labsでは、お客様のチームにPivotal Labsのオフィスに来てもらってコーチングして、チームが自走できる状態にして返す、という事業をやっている。
  • プロダクトマネージャやっている
  • いいユーザリサーチってなんだろう。ユーザが欲しいものを作れて初めていいユーザリサーチと言える
  • Experiment-Driven Product Development
  • リーンスタートアップ
    • BUILD, MEASURE, LEARN
    • Learn: 思いこみから始まる
    • Build: 作る
    • Measure: 検証する
    • 自分たちの思い込みを信頼性あるものにする
  • "Experiments never fail." 実験は失敗しない。実験はし続けるものだから。
  • 早く失敗すると成功は近くなる
  • 紙に書いて壁に貼ると、人は見る。
  • JRはプロダクトへのフィードバックをGoogle Formで得ようとしている。JRが。それくらいフィードバックもらおうとしている。
  • ザッポスは事業性を調査するために、表のWebサイトだけ作って、裏の流通は作らずにサービスをユーザに使ってもらった。裏では社員が靴屋に靴買いに行って、梱包して送る、というのをやった。ユーザにとって裏の仕組みなんて関係ないから、これで問題ない。
  • 調査したことをどうプロダクトに活かすかを考えるのが大事。

isaax勉強会#27でLTしてきた

2019年4月1日追記:YouTubeへのリンクを追加


isaax勉強会#27でLTをしてきました。

LT風景はこんな感じです。

f:id:sonomirai:20190316115053j:plain
LT風景

YouTubeに動画も上がっています。 youtu.be

発表資料はこちらです。

LTの際はデモの準備ができていなくて、実際にGoogle Homeが動作するところをお見せできなかったので、遅ればせながら動画を撮りました。


Google Homeに部屋の温度を教えてもらう

こんな感じで、Google Homeに部屋の温度を教えてもらうことができるようになりました。
懇親会ではgoogle-home-notifierを使って、部屋が暑すぎる/寒すぎる時にGoogle Homeから教えてもらうのもいいのではないかとコメントもらったので、今後はそのあたりの改良を進めたいと思います。