ansibleやってみてる
久々の更新。そして久々の技術の話。(他の人には役に立たないただの日記)
新人研修として、実際にテストを体験してもらうというアクティビティをやる予定です。 テスト対象は私が作った全然いけていないイベント掲示板アプリ。 自分の勉強も兼ねてRailsで書いてみました。
じつは去年も同じことをやったので、その時のソースコード持ってきて環境だけ作る、みたいなことなのですが、去年は環境構築の部分をまるっと他の人にお願いしちゃいました。
今年はせっかく(?)なので自分でやってみようと。
新人3人分の環境を、Dockerのコンテナ(これは自動で作ってくれる社内サービスを利用)にansibleで構築し、ServerSpecで確認する、みたいなの。
今はansibleで格闘しているのですが、ansibleの書き方以前にわかってないことが多すぎ。 Linuxのこととか、ssh接続とか鍵認証とか、bitbucketからcloneするとか、、、
もちょっと理解のスピードを上げていかないとならない、と焦るものの、焦ってもすぐに理解できる頭ではないので、まぁ少しずつでも前に進もうと思いましたとさ。
JaSST'15 Tokyo クロージングパネル「テストエンジニアとデベロッパーとの幸せな関係」
JaSST'15 Tokyo のクロージングパネルを聞いていた時のメモが出てきたので記しておきます。テーマは「テストエンジニアとデベロッパーとの幸せな関係」でした。
このパネルを聞いて「開発とQAは対立するものじゃなく、一緒になっていいものを世の中に出そうぜ」っていうチームなんだよね、って改めて考えました。そのための共通言語としてコードで話ができたらカッコイイよね。
...もっとちゃんとしたまとめがこちらに公開されてたのを今気づいたデス。
- テストエンジニアとデベロッパーとの幸せな関係とは何か。開発効率の向上も、ゲームを面白くすることもテストエンジニアの領域に（前編） JaSST'15 Tokyo
- テストエンジニアとデベロッパーとの幸せな関係とは何か。開発効率の向上も、ゲームを面白くすることもテストエンジニアの領域に（後編） JaSST'15 Tokyo
※(さ)は私の感想です。★は私がいいなーと思ったところです。
チェンジビジョン 平鍋さん
- アジャイルのワークショップをテスターがやっていた。@アメリカ
- キャンディの話
- 開発者がテスターに聞きに来た時にキャンディをあげる
- 距離を近くする
- 人と人の距離を近くすることがアジャイルの本質
- 上着のジッパーの話。開発とQAを理解の食い違いを早い段階でなくしていく
- テスト側、開発側、と別れない方がいい
- (さ)アジャイルとテスト、が近づいている？
ACCESS 松木さん
- これまで
- テスティングは品質保証の主要な一部
- バグレポート中心の（devとの）コミュニケーション
- これから
- 開発チームの生産性を向上させる役割
- これまでのQAはなくならない、広がるイメージ
- 効果的なテスト自動化
- (さ)自動化じゃなくてもいいから「技術でテストできる」といいのでは？テストコードだけじゃなく。
- テスト実行環境を簡単に増やせる技術
- 非機能要件には高いスキルが必要
- ペネトレーションテスト
- アタックテスト
- これらにもツールができている
- コードが書かれてからお客さんに届くまでを早くすることにテストエンジニアがかかわる★
- (さ)具体的には？DevQUTのこと？
- DevQUT
- Communicatization（造語）
- 仲良くする、コストが下がる
- 開発と普段から話をする → 自信があるところないところとか優先度
- ユーザーと近くなる→ユーザーコミュニティとか製品についているフィードバックシステムをツールとして使って、開発に届ける
- (さ)ユーザーヒアリングとかにQAが関わるとかかな？
サイバーコネクトツー 八田さん
- ゲーム業界から見ると難しい話
- 品質保証の違う点は「バグがないこと」と「面白いこと」を求められる
- ゲームの仕様を決めるmtgに積極参加
- 仕様を早く把握することをチェック内容を予測できる
過去のバグ経験を元にして、実装チェックリストを開発者と共有
- 開発者に依存することなく過去バグを未然に防げる
Q:テスト技術の進化によってDevとQAの関係が変わってきてるのでは？と思っていたが、技術よりも距離を近くする、ということ？
- A:ゲーム業界も新たなハードが出たりして大きな変化はある。その中で求められるのはいかにDevとコミュニケーションとるか。不具合を出さないようにするか。がメイン。
- 新しい技術を完璧にデバッグするのは難しい
- Devが持っている情報をもらう
- 平鍋さん
- QAが仕様に入って一緒に決める、というのはゲームのほうが進んでる
- ビジネスの構造が違うのかもしれない
- QAの発注の仕方とかどう？
- 八田さん
- 人月で頼む。デバッグ会社に開発後期に頼む
- 社内にQAを置くことで早くから関わる。その後に外注と提携
- プロジェクタにデバッガをアルバイトで雇って、終わったら解散、が最初
- その後に社内にQAを作ろう
- ノウハウをためて開発者から頼られるようになった
- 野中さん
- 技術面でこうやったらもっと距離が縮まるよ、とか
- 松木さん
- 上流におけるQAの取り組みとしては、開発者とコミュニケーション取りながら、はそれがいい
- 下流では、ターンアラウンドタイム(バグが埋め込まれてから、発見されて、報告されるまでの時間)をどれだけ短くできるか。
- (さ)この考えを広めて社内でも具体化したい。実装直後にテストが書かれてるとか
- コード書いてその場のレビューで言われたらすぐ直せる
- 実装後3週間立って言われても遅い
- そのためには
- 機能テストを自動化すると大変。メンテが。
- ユースケーステスト、シナリオテストのような、「ユーザーはこうするよね」だけで自動テスト書く+CI
- QAと開発者が距離を置いちゃうは品質を神格化しているから
- 品質はよくわからないので怖がる。尊敬してる
- それをわかったようなQAを司祭として扱う
- もっと近いものにする
- 品質特性の中から何が大事かを、定量化に早く返せるようなツールを仕組みを作ってる★
- (さ)なにそれ？
- 平鍋さん
- 出荷判定会議が怖かった
- 有無をいわさず最高品質を届ける、という宿命
- Boltonさん
- 開発とQAの距離を縮める、について
- お互いの尊敬はキャンディではなく、お礼の気持で成り立っている★
- 大事なことがあって、技能を持って正確に伝えることができれば、devから聞きに来てくれる
- 品質を定量的に表現することに抵抗がある
- 何故かと言うと、数字を体現するものであって、数字そのものが何かを意味するものではない
- 厳しい会話を回避するための方法では？
- 難しい話し合いでもうまく対応する方法がある
- 自分自身のことを表現することは勇気がいる、勇気があると前に進める
- ターンアラウンドタイムを短くすることに関しては誰もが質問する
- PGをコードを生成することに責任を持つ？それともうまく動くコードをに責任を持つ？
- PGが機能するコードを書くことを責務とするならTRTIMEは長くなる
- フレデリックいわく2006@インド
- 完璧なコードをPGが生成することを期待はされていない
- こういう動きを確認しました、を言えることを期待されている
- テストとチェックの違いを分けて考える
- PGは書いたらすぐにチェックをする。
- PGに対してこうしろあぁしろというのは違う
- 言葉としてQAを使うのは嫌い
- 製品の質を高くすることは、プロジェクト全員の役割だから
- testerとしてはコードもスケジュールも予算もスコープも出荷日も出荷判定もコントロールできない
- このなかで、品質を確約することはできるのか？
- これらの権限をもっているのはデベロッパーやマネージャ
- 本当はこれらが「QA」
- testerとしては彼らに今の状態がどうなのかをわかるようにする★
- そのためには
- ソフトウェアは人々のrelationshipsでできている
- PGとQAを物理的にも近くする
- フロアレイアウトを変えてでもそうする
- コミュニケーションの一部がコード
- プロジェクトは常に時間との開発
- これまでに作ったことのないものにチャレンジしている→不確定
- 時間との戦い、ミスも起こる。自然なこと
- 短い時間で何かを学ぶ必要がある
- だれも実現してないことをやろうとする
- ソフトウェアは人々のrelationshipsでできている
- 開発とQAの距離を縮める、について
- 八田さん
- 平鍋さん
- QAがどのユーザーを巻き込むか、をアジャイルに取り込んでいるのは聞いたことがない
- 伝統的なQAは欠陥がないかをみる。
- ゲームが「面白いか」をQAが見るのは品質の定義が広がっている感じ。(すごい、という意味で)
- Boltonさん
- 使うことが「楽しいかどうか」を質問するのはいいこと
- ユーザーに「感情面」を聞くのは重要★
- 使いやすいかとかだけじゃなく
- 目的を達成できているか、とか
- (さ)そうなるとフロントエンドの動きとか、表現が大事って気がする。「体験」をどこから感じるか。。。
- 実装する人とテストする人はマインドセットが違う
- 作った人とは別の人が外の視点からみること
- 八田さん
- （QAをおいてうまくいった話だが、QAチームがなかったらどうなったか）
- その分PGを増やすことになったと思うが、テストをすることに手は回らないと思う
- 平鍋さん
- Boltonさん
- 45年前にすでにウォーターフォールはうまくいかない、と言われている
- 松木さん
- (テストを別組織にするべきかどうか、その場合何をするか)
- テストをする人は開発者の中
- テストのマインドをもった開発者
- チームが目指したい形と、そのチームを包含する組織(会社)の目指したい形が違うことがある
- 会社が目指す形にあっているかどうかを確認したい場合は開発からQAを別にしたほうがいい
- QAとマネジメントの違いはなにか？
- 組織として表現したいビジョン→マネジメントがもつ
- QAはそれがそうなっているかをチェックする部隊
テスコン2015に参加したときの話
(また技術の話じゃない、、、最近プログラムできてない、、、ブログ名変えようかな)
テスト設計コンテスト2015に参加した時の話を社内に共有しました。 それを会社のブログに載せてもらいました。
ご覧あれー。
Design Sprintに対する疑問点の解消
前回のエントリDesign Sprint Night! 参加してきた - 非開発者がプログラム技術を使ったQAを目指すブログ の中で「デザインスプリントに対する疑問点」を書いたのですが、なんと馬田さんに質問する機会があり、回答をいただけました！ありがとうございます！
以下、私はこう理解した、を書きます。(あくまで馬田さんとのやりとりの中で得た私の解釈です)
質問1
DSの効果としてBlueBottoleCaffeとかPocketで「こんな成果でました」という話があるが、これは最初からKPIとして設定していたのか、結果としてこうなったのか(なぜならデザインスプリント(以下DS)のプロセスの中で目標値の設定の話が出てこないから)
- Blue Bottle CoffeeもPocketも「KPI的な(数値としての)目標設定をしたかどうかはわからない。
- だけど結果の振り返りができる程度での目標設定はやっておくべき。
- 効果があったのか、なかったのか、どの程度だったのか、はわからないと意味が無いですよねー。
- ということはやはりDay1での課題設定の時に「何をどうすることがゴールなのか」をちゃんと決めよう、ということに繋がるんだなと思いました。
質問2
「ユーザーストーリー」というのがよく理解できていない。そのシステム、画面を使って、「ユーザーがある目的を達成するために、どういう手順で、何を操作するか」かな？
- 「ユーザーストーリー」というワードは明確に「これ！」という感じでは使われていないようです。
GoogleVenturesのサイトで参考になるURLを教えてもらいました。
↑これを読んだ私の感想としては当初思っていた「ユーザーがある目的を達成するために、どういう手順で、何を操作するか」というよりも「ユーザーに、どういう行動をしてほしいか」のほうがしっくりくるなと思いました。
- システムの画面遷移だけでなく、「Creating a new product concept」の時や「Improving conversion rate from a landing page」の時にもストーリーを書くようです。
- つまりモニタの中の話だけじゃなく、こちらの理想とする「ユーザーの行動(電話をかける、とか、旅行に行く、とかも含む)」を絵(図)に書くことなんだと理解しました。
質問3
Day5でユーザーテストするときはプロトタイピングしたもの。それを本実装するのはいつ？Day5で出てきた課題を解決できたかどうかは再度ユーザーテストが必要になると思うのだけど、そこはまぁ自分たち判断でいいのかな。
- 本実装への移行は自分たち判断になる。
- そこに関しての正解があるわけではない。
- ここでも「本番に反映したあとに測定」して効果を判断することが必要(例えばABテストしてみるとか、単純にBefore/Afterで比較するとか)
- それにはやはり「ゴール」が必要
質問4
「前進している感じがある」のと「やった結果が成果につながる」かは別だと思うのだが、成果になっているのかの確認もスプリント内にあるのかな？
- ここは「成果」を何であると定義するか、による。
- Day1 の課題設定に対して、Day4 のプロトタイプを用いて Day5 で仮説検証ができたのならそれは成果になる。
- 一方で「本番実装した後にわかる定量的な改善結果」に関しては(本番実装自体がDS後のものなので)スコープ外と考える。
- つまりDSの中では数字にとらわれるよりも、いいと思ったことをじゃんじゃんやってみようぜ、ってことかなと思った。
…というのが私の理解です。この辺りを踏まえた上で来週から社内で1スプリントチャレンジしてみます。
Design Sprint Night! 参加してきた
- 2015/3/6に行われたDesign Sprint Night! 〜 先駆者たちから聞くDesign Sprint の実際 - connpassに参加したときのメモと感想です。
- プログラムの話じゃないですけど、最近仕事でこういうのも関わるようになりまして、メモメモ。
- 本人の発言やスライドの内容をそのまま書いているわけではなく、私の受け取ったイメージで書いてるところもあります。
- 予備知識として「デザインスプリント」について知るには、まず下記の2つのスライドを抑えておくのがいいです。
私の疑問点
この勉強会の話をきいて、私が疑問に思ったことを先に書いておきます。教えて偉い人！
DSの効果としてBlueBottoleCaffeとかPocketで「こんな成果でました」という話があるが、これは最初からKPIとして設定していたのか、結果としてこうなったのか(なぜならデザインスプリント(以下DS)のプロセスの中で目標値の設定の話が出てこないから)
- 「ユーザーストーリー」というのがよく理解できていない。そのシステム、画面を使って、「ユーザーがある目的を達成するために、どういう手順で、何を操作するか」かな？
- Day5でユーザーテストするときはプロトタイピングしたもの。それを本実装するのはいつ？Day5で出てきた課題を解決できたかどうかは再度ユーザーテストが必要になると思うのだけど、そこはまぁ自分たち判断でいいのかな。
- 「前進している感じがある」のと「やった結果が成果につながる」かは別だと思うのだが、成果になっているのかの確認もスプリント内にあるのかな？
追記：こちらのエントリで疑問を解消できました↓ Design Sprintに対する疑問点の解消 - 非開発者がプログラム技術を使ったQAを目指すブログ
デザインスプリント概要 (Microsoft Ventures 馬田 隆明さん)
スプリント＝短い時間で区切って、いかに解決していくか
5日目のインタビューをとおして検証する。その結果の学習を活かして、新しいアイディアを回す
背景コンセプト
- 締め切り駆動開発＆制限による創造性
- 短いタイムボックスでどんどん決める、進める
- 集団の力
- 従来のブレストの効果を否定的に見てる。
- みんなで出すけど、決まったことに関して納得感が薄い、あるいは「結局誰かが決める」
- DSは「アイディアは個人。意思決定は集団」
- 従来のブレストの効果を否定的に見てる。
- Art&Fear
- 「質優先で一個つくる」より「量を優先してたくさん作ったものの中から出てくるもの」のほうが優秀
- 素早く作って、素早く失敗、そこから学ぶ
5日目にユーザーテストした時に「これじゃない」といういう声が聞けているのは成果だ
DSは顧客発見、開発、運用改善、あたりに効果がある(下記スライドのP12)
Day1
- 今あるチームの課題を知る → ユーザーストーリーを書いて、どこにフォーカスするか決める
- 「どの問題を解決するか」が最重要。課題を全ては解決できないので優先度を決める。
- これは登壇者みんなが言ってた。ここがズレてると無駄になるって。
- 小さい過ぎると意味が無い(1人でできるから。みんなで、1週間かけて取り組める粒感…)
- フォーカスポイントを決める時に、「HEART」フレームワークが有効。課題に対して解決するか、を決める。
- Day2
- 発散は個人、決断は集団
- Day3
- ユーザーストーリーをつくる。紙でもいい。
- 画面遷移図とか
- ユーザーストーリーをつくる。紙でもいい。
- Day4
Day5
- インタビューの結果、よかったところ、わるかったところ、気づいたところ、を色分けして書き出す(ヒートマップ的に)
- 30分インタビュー、30分振り返り、そのあと別の人に30分インタビュー、、、の繰り返し
- 1人がインタビュー、もう1人がメモ役。
- 操作しているところを録画する、画面キャプチャする、とかもありそうだが手間かかるよね
- 結果のメモを付箋に書いて張っていく → 学習が進む
- 課題が出てくる → 優先度が必要 → Day1に戻る
上記が基本だけど自分たちにあったプロセスに変えてく
- その後のセッションで数社の人の話があったけど、どこも「集まる人」とか「投下時間」は自分たちなりに変えていた
- 確かに通常業務がある中で5日間フルで拘束する、は厳しいよね...
- DSは全ての問題を解決できるわけじゃない
THE GUILD 深津 貴之さんの話
大事なこと
- 部署をまたいでいろんな人を呼ぶ
- 作業を時間で区切る
- 個人ワークとグループワークを高速で回す
Googleでは「お試し」として5日間ではなく、2時間でやるプランがある
- 5日版は全方向から情報を共有
- 2時間バージョンは、5枚の仮想ペルソナが設定してあってその人の1人に対して何かする
発散
- HMWの精神
- How might we?「我々はいかにして解決できるか？」
- 「どうせできない」という否定的な考えを排除する
- Crazy8
- 元はGameStormingの6-8-5の手法
- アイディアの共有では「YES AND」で答える。他人の意見に上乗せする
- DotVote アイディアの温度感がでる。最終決定者はいる。半民主主義みたいな感じ。
- HMWの精神
決断
- バトルロイヤル(複数の案をもっと練ってから決める) or ベストアイディア(この時点で「これだ！」を一点決める)
試作
- 個人で画面遷移(とは限らないけど)をつくる
評価
- 2時間のワークショップではユーザーインタビューの代わりに1分間のプレゼンをした
スプリントの長所
- 最初から全員を巻き込める
- 全ステークホルダーからの多角的なアイディア
- (関係者の思いの)全体を俯瞰できる
- 民意を把握しつつ責任が明確になる(合意形成)
- →軸がぶれない、政治でひっくり返らない
- エース不在でも、安定して８５点を出せる手法
有効に機能しないケース
- メンバーに突出した人がいるとその人に任せた方がいい(権限の集約)
- 自分の意見を通したい人がいる
- 思ってるより重い。スケジュールの確保とか。軽くする工夫どころが重要
- 全員が参加するだけの重要度が高いところだけやる工夫
- 参加出来ない人には決まったことに対して意見できないくらいの権限委譲をしてもらっておく
- 意思決定に高度な専門知識が必要なもの（新薬とか統計とか）←いろんな視点からの意見を持ち寄れる
- 最低条件
- スプリントの対象(何を改善したいのか)が的確
- 意思決定者から現場まで巻き込む
- フラットな立場で意見いえること
- 何度も繰り返すこと
こういう時は有効
- 全員が初めて会って思い・価値観がバラバラ
- 各人が何を考え、何を大事にしているのかわかる
- チーム内に声の大きい人がいる
- 後半に入ってきた人がひっくり返されることがある
- ボスの権限できまるかつ打率が低い
まとめるとこんないいことがある
- 俯瞰することで、ミスをなくす、
- 全員の共通認識で進められる
政治的にひっくり返されることをなくすために最初に合意できる
デザインスプリントの記事を翻訳している
- http://labs.theguild.jp
- (ここ、すごく役に立つので皆さんにも読んで欲しい)
ここでワークの時間
- 「ビルの入り方」の改善をテーマにCrazy8をやる
- 背景
- ヒカリエに入る時に名刺出したり、名前やIDを申告したりして大変
- もっとラクに入館したい
- とはいえセキュリティも大事
- これを解決するようなアイディアを8つ上げる
- やってみたが7つしか埋まらなかった…
これだけじゃ何のことやら、ですよねｗ
ワークはここまで。以下、感想
- 35秒というなかで絵に書くって、慣れないと大変。でも楽しい。
- その後のススメ方として
- 自分で書いた中で有力案3つくらいを人に見せられるように清書するみたい
- 全員分張り出す
- Voteする
DeNA 坪田 朋さんの話
- なぜDSか？
- 過去の課題
- ビジョンは分かったが、具現化フェーズで詰まる
- 特定の人（UI担当者とか）に負荷が集中する
- 思考フェーズが長いとスケジュールが押す。やり残したままリリース
作って、壊して、評価して、を超高速で回したい(半強制的に)
こんないいことが
- アイディアの具現化からユーザーテストまでが一連の流れになっていて、ゴールが現実的
- 時間が長い、プロセスが長いと論理破綻がしない
- 短い時間で可能性を出すような設計→全てのプロセスが高速に進む
- 知恵を「ひねり出す」のに体力は使うが、早い。
- 複数のブレストより、１人で考えた案を持ち寄るほうが質が高い
- サイレントクリティーク
- 意思決定者を中心にベストなデザインを決定するルールになっている
- 意思決定をしたことの納得度
- ？？？もう一個あったけど聞き逃した
- アイディアの具現化からユーザーテストまでが一連の流れになっていて、ゴールが現実的
- やってみると疲れる
- やりきった感、前進してる感がある
- エンジニア、企画の人、が中心になるといい
サイバーエージェント 大塚 敏章さんの話
- なぜDSか？
- ブレストで意見がまとまらない
- 結局、限られた人で集まって決める
- エンジニア、デザイナー、プロデューサーの思いや大切にするモノ、違う時間の使い方、ユーザー像が違う
- それで「ユーザーの事を考えて」作っていけるのか？
- みんなが譲りあって、曖昧になる
- 自分のアイディアも捨てきれない（採用されても思ってたんと違う)
- これまでの手法ではユーザーテストは終盤
坪田さん、大塚さんの対談
- DSにファシリテーターは必要か？
- チームメンバーの誰か、でもいいと思う
- ただ、始めの何回かは馬田さんのようにプロセスに慣れた人がいた方がいい
- ムズカシイところ
- いっしょにやる人に理解してもらうところ。
- デザイナ以外は絵を描くとか苦手
- それを促す雰囲気作り
- 時間の作り方。特に運用している案件に対するスプリント
- 集まった情報に対する個々人の理解度、専門性が高いとやりにくい
- 実際は？
O：5日でやってみた。が、次の週また5日拘束、とかは厳しい
T：新規案件の時は5日でガッツリ。
- とはいえ運用案件は全員フルコミットはムズカシイので、フレームワークは使いつつも、必要な人でやる
- ファシリテーターはどの立場の人がいいか？
- T：意思決定者に近い人はしないほうがいい。明るく場を和ませることができる人
- O:中立的な人。決定者はちがう。
- T:得手不得手はあると思うので、全員が回せるようになる、がいい。だれでもできる
- 大手企業ならではの導入しにくさ
- 採用までに政治で一苦労、とかあるらしい
- プロセスを可視化して共有する、のは大事。
- プロデューサーが数字しか見てないことがある。一回でも巻き込むと印象、意識が変わる。
- デザイン、てついてるけど、デザイナーがやるとは限らなくていい
- 「やって意味あるの？」に対しては「5日でデザインできてユーザーテストもできる」という返しは有効。
- オリジナルに忠実？変えてる？
- 試作を全員でやる、は重いので、出来そうなメンツでやっている
- 最初はフレームワークにそってやってるけど、次第に「ここはデザイナとエンジニアで」とかやってる
- スプリントが終わった後のレビューはやってるか？
- やっていない。ひたすら作る。レビューは評価の中で。それを活かして次にやる
- 繰り返しやっていく中でアイディアが固まったら分業になっていく。そこの切り替えしがムズカシイ
- 社内の反響は？
- そんなに浸透してないｗ ブログ書いて外から評価されてると中でもやりやすい。
- 偉い人からの理解
- エンジニアの人たちの巻き込み方は？コードを書きたがると思うのだが・・・
- 新規のときはやりやすい
- やってみるとエンジニアの感想もいいものになる
- なんでこのデザインになったのか、がわかる。
- 特にUIがなんでこうなってるのか、あるいはUIを作るまでの経緯(の大変さ)が考えられるようになる
- プロセス自体が面白い。UIを一緒に考えられる。オーナーともデザイナともシンクロできる。
- UIのプロセスがエンジニアはよくわかってない、が解消される
- やることになって、工数見積もったら間に合わない、的なこと
- 結局やれといわれるのかよ、的なことになりがち
- 品質を求められるときはスケジュールを動かす
- 期間内に成果をだす、は求められる
ココナラ 新明 智さんの話
- スタートアップに大事なこと＝Issue（ユーザー課題)を特定、解決するための多様な観点がある
プロトタイピング(を元にして下記が生まれる)
- concept
- communication
- improvement
タイムボックス
- 時間をかけるほど壊しにくくなる。愛着がわく
- 100%のものではなく、70-80%をどんどん出していく
- ユーザーテスト
- 出す前に触ってもらう
- 意図通りかどうか確認できる
これを繰り返す（Iteration)
苦労したこと
- ユーザーテスト協力者の確保
- 課題の収束のコントロール
- 意思決定者を長い間拘束できない
Standard Inc. 鈴木 健一さんの話
- サービス全体として
- 誰の、どんなことのために作るのか
- どのようにつかわれるのか、使ってほいのか
- どうすれば利用者、事業者にメリットがあるのか
新明さんと鈴木さんの対談
- スタートアップにとってデザインは重要
いろんな観点の人を巻き込むか（ユーザーのことを知ってるのはCSの人だったりする）
DSはスタートアップに対して効果はあるのか？
- 中にデザイナがいないこともある
- 何をしたらいいかわからない
- 短期間で発散と収束ができるのは有効
プロダクト製品(組込みなどH/Wがあるものとか)にも適用できるか？
- スプリント中にプロトタイプができるもの、なら実践できる
- 作って試してもらう、というのが重要
一体感は？
- チームとして何が課題で、どう解決するか、がわかっているのでその後の話がやりやすい
ダメだったところ
- Day1での共通認識が取れなかった
- 課題の設定をミスるとだめ。１週間かけてやることか？と
- 学びたい範囲をはっきりさせる（KPIが明確、とか。それを上げるにはどういう選択肢があるのかとか)
インタビューイの集め方
- 代々木公園で話しかけることもあった
- １周目が大変。２周目は集めやすくなる
- 協力者に協力してくれる人を聞く
- ユーザーテストを常に回してないと集めにくい
- FBの友達経由が多かった
ユーザーテストする歳に、どれくらいペルソナに近い人を集めたのか
- 実際は外れた人もいた
- ココナラ：年代と性別は重視（サービスによって変えるんだろうな)
- ココナラ：自分たちのサービスを知らない人(というターゲットだったのでここは意識した)
スタートアップならではの難しさ
- 人数が少なくてみんなでやってる、事業には向いている
- 分業になってくる（１３人位？）になってくるとやりにくいかも
- 時間拘束はされるので大変
何を課題にするか、は大事。ハマるもの、ハマらないものはある。
Day1で問題意識とか、ギモンを解消させるのはものすごく重要
まとめ
- 会社、文化にあったスタイルに変えていく
RSpec、Capybaraのお勉強中
このところ、Qiitaの@jnchitoさんの記事を見ながら。RSpec、Capybaraを勉強しています。 何がすごいって、この方の記事がものすごくわかりやすく、いい感じでまとまっていて初学者にとっても優しい感じなのです。
Ruby - 使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita シリーズ
RSpecの入門とその一歩先へ ～RSpec 3バージョン～ - Qiita シリーズ
RSpecもCapybaraも進化していて、何も考えずにGoogle先生に聞くとバージョンの古い記事がHITしてしまって困ったなーと思っていた時に出会ったのでとてもありがたいでございます。
そもそも本職プログラマではない私が無理くり「テストコード書けるようになりたい！」ってやってるので、Rubyで :name の「:」って何よ！？みたいなこととか調べつつやっております。休みの日もあれこれ楽しみで調べては動かしてみてます。とはいえ、早く実戦で使えるようにならないとな。
Ruby on Rails の基礎編終了
年明けから始めていたドットインストールのRails講座、ようやく完了。 初心者のとっかかりとして、このサービスはピカイチだと思う。(他のサービスを使ったことないから比較できないけど)
動画を見ながら、もちろん自分でも書いて動かしてみて、なんだけど一回やっただけだと絶対忘れるし、わかんないところを調べて記録に残しながらやってたので、1レッスン3分なのに、30分くらいかかったりもした、、、まぁ今は時間かかるのはしょうがないと思ってます＞＜ 早く慣れて勘所を掴みたい。(困ったときの調べ方とか)
ドットインストール - 3分動画でマスターする初心者向けプログラミング学習サイト
これでひと通り * SeleniumWebDriver * Rails * RSpec
のホント基本的なところはわかったつもり。 ちょうど社内案件のちょうどいいのがあるので、それをローカル環境(会社のPCね)で動かしてみて、そこにテストコードを書いていく、というのをやる。
っていうところにきて、このプロジェクトはCapybaraでテストが書かれてるみたいなので、ひとまずここにテスト追加できるようになろう。
