No profit grows where is no pleasure ta'en.: 1月 2014

2014年1月26日日曜日

「LEAN UX」を読みました。

「デザイナーの仕事は仕様を書くことではなく、価値ある製品とサービスをつくることなのです。」

本の中のこの言葉。

当たり前なんですが、本質に立ち戻り、今までのやり方見直すことが重要なんですね。

LEAN UXの3つの基盤

「Lean UXには、基盤となる3つの概念があります。」

デザイン思考
アジャイルソフトウェア開発
リーン・スタートアップ

原則

「Lean UXの体験を、学びの旅のようなものととらえましょう。あなたとチームを正しい方向に導くために、これらの原則を活用してください。」

価値、原則とくるところは、完全にアジャイルにインスパイアされてますね。

部門/領域横断的なチーム
小規模、専任、同一場所
進捗＝結果（アウトプット）ではなく、成果（アウトカム）
課題焦点型のチーム
無駄を取り除く
バッチサイズは小さく
継続的な発見
GOOB-新たなユーザ中心思考
共通理解
アンチパターン-ロックスター、エバンジェリスト、忍者
仕事の外面化
分析よりも形にする
成長よりも学習
失敗を許容する
中間成果物中心の仕事の進め方からの脱却

テンプレート

「開始点は、要件ではなく、前提になります。次に仮説をつくり、それを評価します。そして、望ましい成果が実現できているかどうかを、実験を通じて評価します。」

以下のテンプレートが紹介されています。

新しい独自のものというより、3つの基盤で使われているものを整理した感じです。

特にリーン・スタートアップの影響が強いようです。

課題ステートメント・テンプレート
ビジネス前提ワークシート
仮説ステートメント
ペルソナのフォーマット

コラボレーティブ・デザイン

「長い目で見れば、コラボレーションはヒーローズベースのデザインよりも、良い結果をもたらします。」

プロセスの部分は、デザインに限らず使えそうなので、様々なところで応用できそうです。

勉強会で素振りするといいかもしれないなぁ。

プロセス

課題の定義と制約の明確化
個別のアイディアの創出（多様性）
プレゼンテーションと批評
イテレーションと洗練（形成）
チーム全体でのアイディアの創出（集約）

スタイルガイド

良いスタイルガイドの特徴

アクセスしやすい
継続的に改善されている
実用的である

MVPと実験

「MVPをつくる最も効果的な方法の１つは、体験のプロトタイプをつくることです。」

MVPとは、Minimum Viable Productの略で、実用最小限の製品のことです。
プロトタイプは以下の基準で、どのレベルの忠実度にするのかを決めます。

プロトタイプ作成の基準

プロトタイプとインタラクションをするのは誰か。
何を学習したいか。
作成の期間はどれくらいあるか。

プロトタイプ作成のツールも紹介されています。
その中では、Balsamiqというのは、よさそうだと思いました。
あと、本には紹介されていませんが、個人的にはCacooがおすすめです。

フィードバックとリサーチ

「このプロセスでは、「軽量」「継続的」「コラボレーティブ」などのリサーチ技術を使います。」

実は、ここが一番難しいと思います。
コラボレーティブかつ継続的なリサーチは結構大変そうです。

コラボレーティブ・ディスカバリ

「コラボレーティブ・ディスカバリは、チーム全体がオフィスの外に出て（文字通り、あるいは比喩的に）、顧客に直接会い、そこから学習するというリサーチ手法です。」

継続的ディスカバリ

「定期的なペースで顧客を関与させることは、Lean UXにおける重要なベストプラクティスの１つです。」

Lean UXとアジャイルの統合

「Lean UXをアジャイルで機能させるためには、チーム全体がすべての活動（スタンドアップ、レトロスペクティブ、IPM、ブレインストーミング）に参加しなければなりません。」

Lean UXでは、対面コミュニケーションの重要性を非常に強調しているように思います。
私は、対面コミュニケーションの不足よりも、対面コミュニケーションの質に課題があるように感じています。

組織的な移行

「これらの手法をここで実践するにはどうすれば良いですか？」

はい。アジャイル開発でもよくだされるQAですね。
答えは、「あなたが考えなさい。」ってやつです。
わかってますよー。

2014年1月23日木曜日

徹夜で作った提案書では負け。 RFP受領前に勝敗決まる。

日経システムズのこの記事がはじまりでした。
徹夜続きでようやく提案書を書き上げた後にこのタイトルは私にとって衝撃的でした。
そこから、teian-labやAPMP Proposal Guideで勉強をし、実際の提案活動に活かしてみた経験をお話しました。

Executive Summary

提案概要は、普通につくっていると思いますが、RFP前にドラフトをつくってしまう！
私にとってはかなり驚きでした。
でも、実際にやってみると、本当に役に立ちます。
Executive Summaryをつくるためには、お客様と色々話をしなければなりません。
このプロセスが提案書作成の鍵をにぎると言っても過言ではないと思います。

参考
exective-summary

Schedule

計画を練るのは重要です。
私はAgile開発が好きなので、Agile開発のプラクティスを活用しました。
この部分はきっとプロジェクトごとにいろいろな工夫の仕方があると思います。

参考
daily-team-management
proposal-management-plan

Kickoff Meeting

キックオフミーティングは儀式ではありません。
提案には、知識体系があり、スキルがあり、正しくマネジメントすれば、徹夜なんてしなくても、いい提案書が書けるということを、根拠を持って伝えることが重要です。

参考
kickoff-meetings

Storyboad & Mockup

ストーリーボードは映画の絵コンテのようなもので、モックアップは骨子みたいなものです。
この2つは、提案書作成のキモです。
でも、うまくやるのはなかなか大変です。

参考
storyboad

FAB

Featureは機能や特徴で、要は、提案するソリューションです。
Advantageは自社のソリューションの強み、利点です。
Benefitはお客様にとっての価値、利益です。
Benefitをはじめに書き、その後に、AdvantageとFeatureを書くようにします。
これを口酸っぱく言い続けると、自然と顧客起点の提案書になってきます。

提案で勝つために

結局これが一番重要です。

RFPが出た時点で動き出したら、もう負けてるかもしれませんよ。

参考

capture-planning

bid-decisions

資料

プレゼン資料のフォントについてご質問を受けましたが、あんずもじというフリーのフォントです。

20140122teian lab itagaki from 真太郎板垣

2014年1月18日土曜日

「第1回日本Seleniumユーザーコミュニティ勉強会」に参加してきました。

コミュニティ開催のごあいさつ【伊藤望さん】

日本Seleniumユーザーコミュニティは、Seleniumに関する分からないこと・困ったことについてユーザー同士で助け合うグループ。

https://groups.google.com/forum/#!forum/seleniumjp

早速、私も登録しました。

登録したけどメールが届かない人メールの設定を見直してくださいとのことなので、1日1通まとめメールが届くようにしました。

今回の申し込みアンケートでは、Seleniumは、やっぱりWebDriverを使っている人が一番多くて、次がSelenium IDE。言語はJavaが圧倒的に多い。

招待セッション(通訳あり)【Jason Hugginsさん】

Seleniumの生みの親であるJason Hugginsさんのお話。

Selenium

2004年、Seleniumが生まれた。
その頃、Ajaxなどが生まれ、テストがしにくく、それを解決するためにSeleniumを作った。
Seleniumはロボットのようなものだ。

Selenium Job Trends（Seleniumを使える人に対する求人）でみると、2007年くらいから人気になり、2012年くらいからはQTPを上回っている。
QTPはMercuryが作っていて、Mercuryは水銀という意味。Selenは水銀の毒性をとる物質。そうなってるね(^^)

Appium

今、mobileが本当に大きくなっている。mobileのテストを無視できない。

mobile向けのseleniumの位置づけのappiumをつくった。

クロスプラットフォーム（iphoneとandroidの両方に対応）で、ネイティブアプリとハイブリッドアプリに対応している。

githubでソースを公開している。twitterは@AppiumDev。

Appium Philosophy

Rule 1

Test the same app you submit to the marketplace

Rule 2

Write your tests in any language, using any framework

Rule 3

Use a standard automation specification and API

Rule 4

Build a large and thriving open-source community effort

AppiumはSelenium WebDriverを使っている。

Selenium WebDriverはW3C working draftになっている。

コードを書かないでいいように、ブラウザベンダーに対応させたい。

Appium Architecture

iOS

Android

クロスプラットフォーム対応しているので、１つのテストでiOSもAndroidもテストできる。

ここでAppiumとHealthcare.govのdemoがありました。

Sample code

Selenium 3はWebとmobileのテストの両方に対応しようとしている。

アメリカの電話では数字とアルファベットが対応していて、4723はipadとなる(^^)

SeleniumはRobotだ

ということで、本当にロボットをつくったよ。

tapsterbot.com

@Tapsterbot

Legoと互換性があるよ（＾＾）

将来的にはSeleniumから操作できるようにしたい。

ここでtapsterbotのdemoがありました。

Sauce Labs?

宣伝じゃないよ(^^)

シミュレーターなどをクラウドで提供している。

どんなプラットフォーム、ブラウザにも対応。

Q&A

Q1:Selenium WebDriver, Client Server, Browserの3 つで動いている。Browserの進化にClientがどう追いつく仕組みになっている？

A1:Selenium3では、Browserについてはコミッターが責任を持たずに、Browser側に対応してもらう。非難がSeleniumにこないで、Googleにいくようにね(^^)

Q2:いつSelenium3がでる？

A2:Webページのタスクがすべて終われば。責任者も書いてるよ(^^)　RCはなくなるので、WebDriverに移行するいいタイミング。

Q3:Selenium3って？（質問を聞きのがした・・・）

A3:ゴールはコードを書かないこと。Browserが全て対応するのには時間がかかるけど。

Q4:Appiumはmobileのブラウザのテストはできる？

A4:対応している。

Q5:WebDriver vapクラス？？？はどうなる？？？（質問がよくわからなかった・・・）

A5:私は答えられない。ごめんね。WebDriver1はすべてJavaScript。WebDriver2からはOSのネイティブイベントを使ってる。

Q6:Selenium3の新機能を教えて。mobile対応の他には？Selenium2との互換性は？

A6:Selenium2と互換性がある。Platformname, Platformversionが入れられる。mobile独自のAPIへの対応。デスクトップ関連は新機能はほとんどない。mobile対応が主な新機能。

Q7:Gebの動作がIEだと遅かったり、たくさん操作すると異常終了する。Selenium3になると性能や安定性は向上する？

A7:テストが遅いなら、多くのマシンを使うのがいいよ(^^)Seleniumの外の問題も多い。httpプロトコルを使う部分に問題が多い。GoogleがSpeedyというプロトコルを提出している。Selenium3では対応できないけどね(^^)

Q8:Appium Loadmap資料もらえる？

A8:いいよ。

Q9:Selenium IDEやBuilderの話をお願い。違いとか。

A9:比較するとそれだけで1講演できる。IDEは笠谷真也さんがつくった。キャプチャー&リプレイの機能も将来的にサポートしていく。IDEもBuilderもFirefoxに依存している。でも、BuilderはFirefox依存を最低限にしている。Firefox以外への対応はBuilderが優れている。IDEの方がコミュニティは大きいけど、Builderの方が可能性がある。でも、Builderはたくさん改善の余地がある。Builderはundoがないなど、ユーザビリティに問題がある。

Q10:日本語を入力し、キーボードをタップするまでやるのが大変。キーボードを使わずに入力する方法はある？

A10:あるよ。デモの見栄えがいいからキーボードをタップさせてるだけ。直接テキストを入れられます。

Q11:Seleniumの正確な発音は？

A11:WikipediaでSelenのページに「ソフトウェアの話はこっち」ってリンクがある。eの発音が正しい。でも、イギリス英語みたいになっちゃう(^^) Alminiumをアメリカで違う発音するのと同じ。

Q12:テストは分析、設計、実行がある。Seleniumは実行？分析、設計までやって自動化では？

A12:Seleniumは実行。ロボットだ。実行だけでも要望がたくさんあるので、対象範囲を絞っている。実行の外は対象外。例えば、レポーティングとか。レポーティング機能のある製品もあるけどね。

Q13:WebDriverでテストしている。Jenkinsと連携するときに気を付けることは？

A13:JenkinsなどのCIサーバーとの連携が課題になる。JUnit、TestNGからXMLでテスト結果をXMLで取得できる。ブラウザのテストをするときに気を付けてほしいのは、エラー時にスクリーンショットをとること。スクリーンショットをgifアニメーションでとれる。Jenkinsを使うときもスクリーンショットなどを意識するとよい。

Q14:mobileのネイティブアプリのテストをしている。簡単にできる方法は？

A14:Appium InspectorはIDEやBuilderに似ている。まだiOSにしか対応していない。

ノンプログラマのためのSelenium DDTはじめの一歩【浦山さつきさん】

Selenium IDEを使ったテストのデモ。
Excelからテストスクリプトをはきだし、Selenium IDEで読み込んでテストするツールをつくった。
簡単でしょ。
データ駆動テストにしてます。

Enterprise開発でのSelenium活用事例【大田尾一作さん】

画面項目を自動で取得-->Excel-->データ駆動テスト。
ScreenShotを1行でとれるようにUtilを作成。
などなど
-->社内ライブラリ化

name属性がない、id属性が動的に変動・・・こんなのは、見送り。
1回の実施では30%～2倍のコスト。継続的な使用で効果が得られる。
エンプラでも使い始めている
いきなり全部だと非効率。一部からはじめるとよい。

Jenkins×Selenium 最初の一歩【玉川紘子さん】

Seleniumのテストは1回では元がとれない。
-->チームの意識が高くないと、すぐにテストが陳腐化してしまう。
-->Jenkinsで自動化。
JenkinsのSeleniumプラグインがたくさんある。
簡単で便利なものをご紹介。

Seleniumhq plugin

browser, startURLなどを設定すると、Jenkinsが実行してくれる。
結果も画面でみれる。

seleniumhtmlreport plugin

TestSuiteが多い場合は、これでレポートがみれる。
mavenなどでxUnit形式で出力すれば、Jenkinsでレポートがみれる。

Selenium plugin

Selenium Gridで並列実行するときにSelenium Hubを簡単に設定できる。

JenkinsでSeleniumのテストをするときに気を付けること

テスト環境は専用に
データの初期化の仕組みをつくる
ジョブは機能のカテゴリごとに小分けにするとよい（失敗したときに修正のモチベーションのため）
スクリーンショットをとる（Selenium Advent Calendar 2014でブログ書いたよ）

Selenese Runnerができるまで(仮)【岩室元典さん】(@vmi_jp)

SeleniumでCIするときに困ったことありませんか？

Selenium RCが動かない
テストがこけたときに何がおきたかわからない
WebDriverはメンテコストが高い

こんな人にSelenese Runner。

WebDriverベースなので、クロスブラウザ対応
ログとの突合せに必要な情報の出力
コマンド毎、失敗時のスクリーンショット
JUnit形式で結果出力

などなど

ここでデモ（クロスブラウザ、実行中にハイライト・充実したログ・スクリーンショットなどなど）

Seleniumと相性がいいテンプレートエンジンMixer@nabedge

Seleniumあるある

idかclassをつけておいてくれればややこしいxpathをつかわなくていいのに。。。

Mixer2はHTML, CSSでテンプレートを書いて、可変部分はJavaで書く。

なので、id, class属性が自然につけられるのでSeleniumでやりやすくなる。

ここでデモ（Mixer2の開発の書き方でテストもできる）

Mixer2はXHTMLパーサー、ジェネレーター、Object/XHTMLマッパー。

懇親会

普段は、こうゆうことしないんだけど、隣にいた女子が「写真とってもらいましょーよー」といったので、その流れで。

ナイスだ、後藤さん！

2014年01月18日
第1回日本Seleniumユーザーコミュニティ勉強会
東京都渋谷区道玄坂1-12-1
http://kokucheese.com/event/index/117476/

登録: 投稿 (Atom)