DevNomi忘年会

エンジニアの忘年会が飲むだけとかつまらん！
ということで、忘年会でDevNomiやりました。
今回は１人３行ルールで。
３行くらいがちょうどいいね。

結果

２時間ちょっとで結構いけた。
JSHintがひどいのはご愛嬌(^^;)

コミットログ

各自の時間はこんな感じ。
（くじびきくんで記録）

-----
15番目 20:14:04 いちかわ
14番目 19:58:24 うえだ
13番目 19:55:05 こん
12番目 19:46:22 いたがき
11番目 19:30:13 いしかわ
10番目 19:18:37 いたがき
9番目 19:11:26 こん
8番目 19:08:48 いちかわ
7番目 19:05:54 いしかわ
6番目 18:59:07 うえだ
5番目 18:46:24 いたがき
4番目 18:35:37 うえだ
3番目 18:26:56 いしかわ
2番目 18:18:10 いちかわ
1番目 18:10:54 こん

「はじめてのハッカソン」に参加しました

イベントページ

もともと、ハッカソンには興味があった。
でも、ハッカソンって怖いでしょ。
だって、ハッカーのマラソンなんだから。

だから、ひよこエンジニアでもできるハッカソンってないかなぁって、ずっと思ってて、「ひよこソン」っていうのを仲間と企画してた。
ひよこエンジニアでも成立するように、事前に、githubとかオールインワン系のフレームワークとかの勉強会をして、その後、ハッカソンをする的なアイディアで。

それにしても、主催者がハッカソン未経験ではまずいだろうと、勇気をだして、一回くらいハッカソンで恥をかこうと覚悟してたんだ。
でも、できるだけ傷は小さい方がいいということで、なるべく怖くなさそうなハッカソンを探して、「はじめてのハッカソン」にたどり着いた。

参加してみての感想は、

楽し過ぎてびっくり！

まいったなぁー。
自分主催の勉強会とかやってて、仲間が協力してくれてて、本当に楽しくていい勉強会ができてると思ってるんだけど、自分の理想に近い勉強会を、あんなカワイイ女の子がやっちゃってるんだから。。。

13:00〜13:30 ハッカソンの説明、名刺交換＋グループ決め

ハッカソンの説明の中で、インセプションデッキの紹介があった。
アジャイル開発やってるので、インセプションデッキは知ってるんだけど、正直、あまり好きじゃない。
なんとなく、恥ずかしい感じになるから。
でも、主催者の「みま」さんの説明は恥ずかしくない感じになっててよかった。
そして、気づいたら、こんな感じになってた。

私「ここだけはぶれちゃいけないポイントとかは決めたいよね。」
メンバー「あ、それ、インセプションデッキの次のヤツだよ。」

私「とりあえず、やりたいことはリストアップしたけど、優先順位とか実現可能性とか整理したいよね。」
メンバー「あ、それ、インセプションデッキの次のヤツだよ。」

インセプションデッキ、自然にやってる。。。

あ、あと、名刺はもっと持ってくればよかった。

13:30〜14:30 アイデアソン

アイディアは比較的すぐにまとまった。

水本さん「統計局がデータを公開してるので、ビジュアライズしてみたい。」
私「いつもイライラしてるので、感情を記録してビジュアライズしたり、分析したい。」
上田さん「図書館をよく利用するので、記録して活用したい。」
石崎さん「感情を記録するなら、文章を解析してネガボジ判定するエクシングAPIってあるよ。」
水本さん「あと、顔の写真で感情判定できるReKognition APIってあるよ。」

じゃあ、この線で攻めようかってことで、色々アイディアがでて、すぐにまとまった。
アーキテクチャも、フロントメイン（JS）でバックはCakePHPで薄く、UIはデザイナーがいないのでこだわらず、Bootstrapで迅速にってことですぐに決まって、役割分担もスムーズ。
このあたりは、チーム構成的にラッキーだった。
あ、これもみまマジックなのかな？

14:30〜19:20 各自作業

まずは、Trelloにアイディアをどんどん登録して、1時間ごとのタイムボックスでToDoを決めて、やってった。

で、最初の2タイムボックスくらいはうまくいったんだけど、後半、連携＋マージで結構手間取って、思ったより時間がかかった。

で、できたのは次のとおり。

• 感情とその度合（0-100）を自分で登録して、時間とその時に書いたメモ（任意）をDBに登録
• 登録した感情を円グラフで表示
• 感情登録時に写真をとって、DBに登録
• 写真をReKognition APIで分析して、感情を判定

ソースはこちら。

本当は、登録したデータのうち、Happy, Sad, Angry, Fear別に一番度合いが高いときの写真を表示するところもできてたんだけど、マージに失敗したらしく、そこはできなかった。
残念！！！

19:20〜20:00 発表＆片づけ

私としては、自分のチームは、短時間で集中してがんばったつもりでいたんだけど、時間が足りず、やりたいことのほんの一部しかできなかった。
自分のチームも悪くなかったと思うけど、他のチームも、本当にはじめて？って感じのクオリティだった。

で、気づいたんだけど、githubは必須で、bootstrapはかなり人気。
下火かと思ってたPHPは以前、人気。
あと、Web APIを何か使ってうまくやるってのがセオリーで、使い慣れたWeb APIがあるとかなり有利。
今は、Web APIをうまく使うと、短時間でそこそこのものができるからね。

お礼

主催の「みま」さん、こんなステキな場をつくってくれてありがとう。
チームメンバーの水本さん、石崎さん、上田さん、色々な刺激をありがとう。この続きはどこかでやりましょう。

あと、「はじめてのハッカソン」があるから「ひよこソン」はもういいかなぁって思ったけど、「はじめてのハッカソン」でもひよこエンジニアにはハードルがあるので、「ひよこソン」はやろうと思います！

「UX、デザイン思考、リーンスタートアップのためのワークショップ ファシリテーション入門」に参加しました

@株式会社アイ・エム・ジェイ 本社 青葉台カフェ

一番、印象に残ったのは、懇親会で言われた「今持ってる知識で中途半端に理解したり、持っているスキルの範囲でやったりせずに、バカになって教わったことを愚直にやって失敗した方が学びが多いのに。」ということ。

ワークショップってそもそも何？

ワックショップは、
主体的に参加したメンバーが恊働体験を通じて創造と学習を生みだす場

ワークショップは、
言葉、頭中心に行うのではなく、身体の動きも含めて、全身で感じたものを個人個人が出しあいながら、集団で作り上げる手法

ワークショップの特徴

身体性、創造性、恊働性、共有性、過程の重視

会議とワーショップは何が違う？

会議とワークショップって、ある意味言い方の違い。
要は、ワークショップは、上記の特徴をもったもの。
だから、ワークショップ型会議っていうのもある。

普通の会議、ちょっと変わった会議、変わった会議

普通の会議、ちょっと変わった会議、変わった会議の順にやってみて、どう変わるかを体験するワークショップをしました。

普通の会議

議長と議事録係を決めます。
発言は１人ずつ。
割り込む場合は、挙手。

ちょっと変わった会議

ふせん紙を使って、見える化しながらやります。

変わった会議

途中、途中で指令書がでます。
こんなの。

Workshop facilitation method card from Naoka Misawa

グラフィックファシリテーションとリアルタイムドキュメンテーション

Visual Thinking from Naoka Misawa

懇親会でグラフィックファシリテーションとリアルタイムドキュメンテーションの紹介がありました。
グラフィックファシリテーションは高いスキルが必要そうなので、練習が必要そう。
リアルタイムドキュメンテーションはやればなんとかなりそうだから、どこかでチャレンジしたい。

リアルタイムドキュメンテーションでググったらこんなのあった！
visual recordingでググったら色々みれる！

PI Study #3 「jQuery入門（ハンズオン）」

@東京都豊島区東池袋３丁目４番３号池袋イースト10F テラインターナショナル株式会社
http://pistudy.doorkeeper.jp/events/13570

仲間とはじめた勉強会の3回目。
とてもよい勉強会でしたが、私個人としては深く反省しなければならない回になりました。

今回は私のプロジェクトの若手に講師をしてもらいました。
もともと、凄腕エンジニアをよんで講師をしてもらうのではなく、エンジニア同士で学び合う場にしたいと思っていたので、それが形になってきたことは本当に嬉しい限りです。
しかも、今回は、私の仲間がきてくれて、本当に楽しい時間を過ごせました。

勉強会の後の懇親会にも、新人のとてもかわいらしい女子とフリーランスの凄腕エンジニアがきてくれて、しかも、今度は講師をしてくれると言ってくれて、自分の目指していたものが思っていたよりもいい形で実現して、感動でした。
でも、懇親会でフリーランスの凄腕エンジニアに言われた一言に大いに反省させられました。

-----
勉強会は内容もよく、楽しかったけど、1つだけ気になったのは、固有名詞が飛び交い、内輪の雰囲気が強すぎでした。
-----

これは、完全に私のせいです。
前述のとおり、自分の仲間がたくさん協力してくれて、嬉しくて、はしゃいでしまいました。
そのせいで、本来は楽しめたはずの人たちに、不快な思いをさせてしまいました。

今日、不快な思いをさせてしまった皆様、本当に申し訳ありません。

これまでは、正直、私と友人の2人の勉強会でしたが、今回を機によりよい勉強会にしていきたいと思います。
初心をもう一度、自分自身に言い聞かせます。

http://prezi.com/lxfns481sybw/?utm_campaign=share&utm_medium=copy&rc=ex0share

DevNomi（easy mode）in BOOKSHELF CAFE

アジャイル開発のプロジェクトで暫定版リリース後のスプリント１発目！
ということで、DevNomi（easy mode）をやりました。

DevNomiについて

• 説明：http://xpfriend.com/DevNomi/#/start
• ソース：今回はeasy modeとして、説明スライドからリンクされているネタとは違うネタでやりました。

メンバー構成 

• 開発者：3名
• インフラエンジニア：1名
• 新人営業：1名
• DevNomiディレクター（笑）：1名

結果

2時間半やって、そこそこ書けました。
ちょっとだけプログラムを教えた新人営業がそこそこ書けてびっくり！
最後の方でエラーがでてたので、帰ってからコードをのぞいてみたら、変数を初期化していないため、値が代入されないパターンのときに値がNaNになってました。
まだまだですな。

会場（Bookshelf Cafe）について

http://www.bookshelfcafe.jp/

iPadが使いたい放題で、プロジェクターも使えるとてもすてきな場所です。
飲み物もこだわり系で、おいしい！
IT系の勉強会を開く予定で、初回の9/8はインフラ初心者向けのDocker入門だそう。
こちらも、要チェックです。

MeCabで形態素分析してTwitter Cloudをつくってみる

PHP、JavaScriptでやってみます。
環境はMac。

使ったもの

• XAMPP
  PHPのall in one開発環境
• MeCab
  形態素分析ライブラリ
• php-mecab
  PHPでMeCabを使うためのライブラリ
• jqcloud
  タグクラウドをjavascriptでつくるためのライブラリ
• twitteroauth
  twitterの認証ライブラリ

準備

参考にしたURL：
http://www.aoharu-b.com/cgi/sk/2013/09/vpsmecabphpcentos64php533542.html
※準備はこっちを見たほうが丁寧です。。。

XAMPPをインストール

インストールは省略。
macの場合、デフォルトでPHPが入ってて、XAMPPのPHPと混ざってちょっと困る。
なんで、XAMPPのPHPを使うように、以下の設定をしておく。

1. 自分のホームディレクトリの .bash_profile ファイルに以下を追記（ファイルがなければつくる）。

export PATH="/Applications/XAMPP/bin/:$PATH"

2. macのデフォルトのphpを退避

sudo mv /usr/bin/php /usr/bin/php_org

3. ターミナルを再起動

which php

=> /Applications/XAMPP/bin//php

4. apacheを再起動

mecabのインストール

cd
wget https://mecab.googlecode.com/files/mecab-0.996.tar.gz

tar zxfv mecab-0.996.tar.gz cd mecab-0.996

./configure --enable-utf8-only

make

make install

辞書のインストール

wget http://sourceforge.net/projects/mecab/files/mecab-ipadic/2.7.0-20070801/mecab-ipadic-2.7.0-20070801.tar.gz
tar zxvf mecab-ipadic-2.7.0-20070801.tar.gz
cd mecab-ipadic-2.7.0-20070801
./configure --with-mecab-config=/usr/local/bin/mecab-config --prefix=/usr/local/ --with-charset=utf8
make
make install

autoconfのインストール（php-mecabのインストールに必要）

cd
wget http://ftp.gnu.org/gnu/autoconf/autoconf-latest.tar.gz
tar xfvz autoconf-latest.tar.gz
cd autoconf-2.69
./configure
make
make install

php-mecabのインストール

cd
wget https://github.com/downloads/rsky/php-mecab/php-mecab-0.5.0.tgz
tar xzvf php-mecab-0.5.0.tgz
cd php-mecab-0.5.0
phpize
./configure --with-php-config=
/Applications/XAMPP/bin/php-config --with-mecab=/usr/local/bin/mecab-config
make
sudo make install

設定ファイルの修正

vim /Applications/XAMPP/etc/php.ini

以下を追記
extension=mecab.so

twitter apiのアカウント作成

以下にアクセスしてログインする。

https://apps.twitter.com/

[Create New App]する。

API KEYSタブで次の作業をする。

• [Cange App Permissions]
• [Create my access token]

で、以下をメモ。

• API key
• API secret
• Access token
• Access token secret

プログラム

以下をXAMPPのhtdocs配下に置く。
https://github.com/itagakishintaro/twitter-cloud

TwitterAPIHandler.phpを開いて、apps.twitter.comでメモした部分をコピペ。
XAMPPマネージャからApacheを起動。
ブラウザから以下を開く。
http://localhost/twitter-cloud/index.html

おしまい。

クロスプラットフォーム、クロスブラウザのテストを仮想環境で簡単に

仕事でIE8のテストをしなければならなくて、そんな端末ねーよ！って思ってたら、仮想環境で簡単にテストできたのでメモ。

いやー、時代が変わったなぁ。。。

以下の手順の6と8は日本語対応のため。

XPのCDがあれば、以下の手順でOSレベルで日本語対応できるみたい。

コントロールパネル

->Regional and Language Options

->Languageタブ

->Install files for East Asian languagesにチェック

->Apply

あと、XP以外であれば、他にも方法があるらしい。

1.VirtualBoxのインストール

https://www.virtualbox.org/wiki/Downloads

2.仮想イメージのダウンロード

以下から、Windows, Virtual Box(Windows上)を選択し、IE8-XPのファイルを全てダウンロード
http://modern.ie/ja-jp/virtualization-tools#downloads

3.ダウンロードしたexeファイルを実行する

4.作成されたovaファイルをダブルクリックする

5.VirtualBoxマネージャーの設定から以下を実施

共有フォルダー
->画面右上の追加アイコンをクリック
->任意のフォルダを追加（読み込み専用、自動マウントの両方にチェック）

6.フォントをコピー

C:¥Windows¥Fonts 配下のMSゴシック、MS明朝を共有したフォルダーにコピー

7.仮想環境を起動

8.仮想環境でフォントをコピー

共有したフォルダーのフォントをC:¥Windows¥Fonts配下にコピー

9.Lets's TEST!!!

OSは英語でもブラウザでは日本語がみれる！

PI Study #2 「ペアワイズ法を使ったテスティングワークショップ」

@東京都豊島区東池袋３丁目４番３号池袋イースト10F テラインターナショナル株式会社
http://pistudy.doorkeeper.jp/events/11043

仲間とはじめた勉強会の2回目。
1回目はSTARの良質なコンテンツを使ったので、余裕だったけど、今回は1からつくったので、なかなか大変でした。
で、一人KPT。

KEEP

• 講義を聞くだけではなく、実際に手を動かす
• モクモクとやるのではなく、チームで話しながらやる
• 講師は気負わず、知ってる範囲で知ってることを伝え、共に学び合う
• みなさん熱中してくれた（休憩もとらずにやってた）
• 「他の勉強会も色々でてるけど、平均より良い勉強会ですよ」と言ってくれた
• 永井くんが「Gebを勉強して今度は僕がやります！」と言ってくれた

PROBLEM

• ペアワイズ法と銘打ったにも関わらず、ペアワイズ法を深堀りしなかった
• 2因子網羅の部分の説明が足りず、理解してもらえなかった人がいた
• DevNomiテスト編で、計算が複雑すぎてそこで無駄な時間を食ってしまった
• チームに発表してもらったときに、気の利いたコメントが言えなかったし、チーム間でディスカッションするファシリテーションができなかった
• 若手向けを意識したけど、若手は勉強会にはあまり来ない

TRY

• 絶対に持ち帰って欲しいものを1つ決めて、そこはきちんと深堀りして準備する
• ディスカッションの時間をきちんととり、準備したうえでファシリテーションする

DevLOVE「オブジェクト設計とリーン開発、その実践」に参加しました

@名古屋市中区錦1-15-8 アミティエ錦第一ビル 4F Coworking Space A+LIVE セミナールーム

正しいものを正しくつくる
ギルドワークス創業おめでとうございます！
増田さんのプロジェクトで増田さんに叱られながら仕事してみたいなぁ。

第一部 オブジェクト設計エクササイズ [13:10〜14:00] 増田亨氏

実践的な設計って、なんだろう？ from 増田 亨

設計とは、変更コストを下げるためにコードを整理整頓する実践的な工夫

プロセスやツールよりも設計

コードを整理、整頓する。
それは、変更コストを下げたいから。
（作って終わりならいらないけどね。）

実践的ってなんだろう？

いくつかの観点で、対岸を行ったり動きながらバランスを取る。
（全体<->部分、長期<->短期・・・）

具体的にどうやるの？

変更コストの原因を知る。
変更コストの最大の敵は「重複したコード」。

重複したコードのいやな臭い（Martin Fowler "Refactoring"）

• 長いメソッド
• 大きなクラス
• たくさんの引数

マスダ流重複の臭い判定基準

• クラス：50行（100行）
• メソッド：3行（5行）
• 引数：0（1）

これを超えたら警戒警報！
（カッコの中はチーム用に緩めた数字）

コード整理の基本パターン

• Value Object
• 振る舞いを持った区分
• ファーストクラスコレクション

Value Object

immutableがポイント。
例）Stringクラス
内部の値を変えずに、新しいObjectを返している。

getメソッドをつくらない。
getをつくるとロジックが散らばる。
データのある場所にロジックを寄せる。
setメソッドもつくらない。
setをつくると状態管理のコードが散らばる。
=> immutable（不変オブジェクト）

プリミティブなクラスは使わず、業務（ドメイン）固有のクラスを作る。
例）
String, StringBuilder, List<String> => ProductName, Remarks
BigDecimal, Integer => Money, Quantity, Unit
Calendar, Date => InitialDate, DueDate, ValidTerm

振る舞いを持った区分

enumにメソッドを持たせる。
定数も、関連するロジックはそこに閉じ込める。

ファーストクラスコレクション

privateなコレクション、publicな振る舞い。
コレクションをgetして操作するとあちこちにコードが登場する。
例）
Customers, OrderLines, UsageHistory, ToDoList・・・

コードの整理　アンチパターン

• Smart UI（画面単位で設計）
• トランザクションスクリプト（機能単位で設計）
• Active Record（テーブル単位で設計）

=> 必ずコードが重複する。

Smart UI => 画面間で重複が発生する。トランザクションスクリプト => 機能間で重複が発生する。
Active Record => テーブル間で重複が発生する。

コードの整理　グッドパターン

• ３層＋ドメインモデル
• 業務の関心事（業務知識）に基づき設計する

=> 変更が簡単

• 仕様変更は業務から発生する
• 業務の関心事の依存関係がクラスの依存関係になっている
• 変更の対象箇所以外でわけのわからない副作用がおきない

第二部 リーン開発の現場 [14:10〜15:00] 市谷聡啓氏

理想とはたとりつくべき場所のことではなく、ありたい姿に向かい続けることなんだ！

誰かが正解を持っている訳ではない

開発の命運を握る２つのレバー

• 期待
• リスク

期待

関係者が互いに持っているプロダクト/プロジェクト/チームへの暗黙的な望み

期待マネジメント

期待を明らかにして適切に調整しつづける。役割と時間を超えて。

チーム => プロジェクト => プロダクト => ビジネス => 組織

レイヤーごとに目的と期待がある。
レイヤーを超え、役割を超えた理解が必要。

Moving Management Target

期待とリスクのバランスは時間とともに変わっていく。
時間を超えた理解が必要。

インセプションデッキ

期待マネジメントのツールの１つ。
大事なのは、アウトプットではなく、その過程でお互いに理解しあうこと。

仮説検証型と最短距離型

目的実現のための選択肢がいろいろある。
=> 何を選ぶか決めるために試行し検証する。
=> 検証から何をどう作るか徐々に決められる
=> 手段と対象がわかれば、最短距離でつくる

スコープが決まってないのに期限だけ決まってる
=> 超危険
=> 仮説検証時は期間契約、スコープが決まれば請負契約

大事なのは、フェーズによって戦い方が変わるということ。

仮説検証型のPlan

リーンキャンバス（仮説）
=> エクスペリエンスマップ（検証）
=> ユーザーストーリーマッピング（仮説）
=> インセプションデッキ（検証）

参考）
「開発戦略は「意思決定」を遅らせろ！」（稲垣 公夫）

最短距離型のPlan

CCPM
パーキンソンの法則：バッファを使いきってしまう。
=> バッファをプロジェクト全体で管理する。

荒ぶる計画を飼い慣らす

• 要求レベルをMust, Want, Tryで可視化する
• プロジェクトの8-9割でMustを実現できる見込みを立てる
• 残った工数でWantを開発する

仮説検証型のDo

なんのための反復？
何を検証するのか？

カンバン（仮説検証型、最短距離型）

仮説検証型：タスク、課題解決の可視化 => タスクボード
最短距離型：全体フローの見える化 => カンバンボード

仮説検証型と最短距離型の見極め

=> インセプションデッキ

ソフトウェアを創り上げるもの

誰が、誰と、誰のために
どういうルールで、何を作るか

リーン開発の現場 P.109

理想とはたとりつくべき場所のことではなく、ありたい姿に向かい続けることなんだ！

第三部 Q&A [15:10〜16:00]

• DDDをどれくらいかけて覚えれば？
  => 2008年からはじめてわかりはじめたのが2012年。現場で続けるのが一番。
• フレームワークを使っている場合（コード自動生成）の折り合いは？
  => 大嫌いだから使ってない。折り合いの付け方もノウハウ。
• クラスが多くなったときのまとめ方は？
  => 業務にあわせてパッケージを構成している。
• お客様に丸投げされたときにどうすれば？
• バッファと見積の合意方法は？
  => QCDSのトレードオフスライダーを使ったりする。
• そもそもドメインって何？
  => まあ、気にしないほうがいい(^^)。カタカナは日本語にするとよい。
• インフラからプログラマになるとき何を学べば？
  => 今はインフラもコードで自動化する時代。そこからはじめては。
• 設計の価値をどう伝えれば？
  => 相手が開発者であれば、変更が大変だったネタを思い出して盛り上がる。そこからスタートすると伝わりやすい。設計とは何かとか良い設計とはとかのアプローチは必ず失敗する。ただ、人がつくったコードで痛い目あってる体験共有からだとうまくいかない。
• 期待をどうマネジメント？どうまとめる？
  => インセプションデッキを使う。困ったらぜひギルドワークスへ(^^)。インセプションデッキの期待が高くなり過ぎないようにしれっとね。
• 設計の考え方をどう共有するか？
  => 経験がないのでわからない。若い頃は意地になって相手を潰すぐらい勉強した。
• カンバンをどう広めるか？
  => いきなり実プロジェクトでやるのはリスクが高い。カンバンだったら、まずは、自分でやれる範囲でやるとか。失敗できるところでやってから。
• どんなドキュメント管理してる？
  => クラス図やドキュメントを全部作ってない。ドメイン知識が増えれば、ドキュメントがなくてもわかる。新しいメンバーにはドキュメントではなく、業務を覚えてもらう。業務がわかれば、ソースが読める構造になっている。
  => IDEが優秀だから。IntelliJ IDEAがオススメ。すぐ乗り換えよう。
• どんな工程？
  => 全部網羅的に設計せずに、重要な部分だけ抜き出して設計してる。
• 開発スピードが落ちない？
• マスダ流は厳しすぎない？
  => 実践でいきなりやるのは難しいかもしれないが、実際にやって、まずは体験してみて。
• なんのロジックも持たなくて、単純な置き換えでもクラス化する？
  => する。名前がほしいから。

SeleniumとGebとCasperJSの比較

STARの教材を使って、SeleniumとGebとCasperJSを比較してみました。

どれも詳しくなく、軽く触っただけですが。

比較結果

個人的には、Geb（+spock）が好きです。

ただ、Web系でJavaScriptバリバリの人が多いなら、CasperJSは有力でしょう。

コマンド一発でインストールできて、テキストエディタ一本で開発できちゃうし、動作もサクサク。

この軽量さは好感が持てます。

クロスブラウザができないという弱みはありますが、結局、クロスブラウザって目視確認しないと微妙な崩れとかわからないので、実はそんなに弱みではない場合も多いと思います。

操作性

操作性はGebが圧倒的です。

JQueryライクに要素をとれたり、すべてのhtmlコントロールでメソッドが大体同じだったり、シンプルにコードが書けたり、とにかく気が利いています。

CasperJSもJQueryライクに要素がとれて便利ですが、メソッドを揃えるような工夫はあまりないです。

あと、JavaScript全般に言えることですが、入れ子が多くなって私は嫌いです。

Selenium(Java)は、とにかく長たらしく書かなければならないので面倒です。

Selenium：☓

Geb：○

CasperJS：△

環境整備の容易さ

Seleniumを普通とすると、Gebは少し面倒でした。

groovyとspockのバージョンの整合性ではまったり。。。

比較ということでGebを☓にしましたが、SeleniumとGebはそんなに変わらなく、CasperJSが圧倒的に簡単です。

コマンド一発で環境整備できちゃいます。

（「WEB+DB PRESS vol.80」がとてもわかり易いです。）

Selenium：△

Geb：☓

CasperJS：○

クロスブラウザ

CasperJSはPhantomJSで動かすものなので、そもそもクロスブラウザという概念がありません。

SeleniumとGebはクロスブラウザ対応しています。

Selenium：○

Geb：○

CasperJS：☓

コード

GebとCasperJSは私が書いたので、あまりキレイではないかもしれませんが、コードを比較してみてみるとおもしろいです。

Selenium

STARリポジトリ　のanswer参照。

Geb

https://github.com/itagakishintaro/STARHandsOnGeb

CasperJS

https://github.com/itagakishintaro/STARHandsOnCasperJS

「UX、デザイン思考、リーンスタートアップのためのインタビュー入門」に参加しました

UXD/HCD ワイワイCAFE「UX、デザイン思考、リーンスタートアップのためのインタビュー入門」@株式会社アイ・エム・ジェイ 本社 青葉台カフェ

UI/UXに限らず、業務システムの業務ヒアリングなどでも使えるとてもよいワークショップでした。

v=f(x)：「ユーザーの声を聞くべからず」

ユーザーインタビューなのに、ユーザーの声を聞いてはならない。
それはなぜ？
ユーザーの声は、ユーザーの体験をユーザーが分析したものだから。
v=f(x)のvはボイスで、xはUX。
UXを素人であるユーザーが分析した結果であるユーザーの声を聞いてはならない。
ユーザーの体験そのものを理解し、我々が分析しなければならない。

弟子入りゲーム

アンケートもグループインタビューもユーザーの声を聞く手法。
では、どうやって、ユーザーの体験そのものを知るのか。
その答えが「弟子入り」。
ユーザーを師匠と見立て、弟子になったつもりで聞く。

基本

基本は次のとおり。

• クローズド質問（Yes/Noで答えられる）ではなくオープン質問（体験を自由に語ってもらう）
• 文脈をクリック（気になるところがあったら、そこを掘り下げる）
• 意見や判断を聞かない
• 仮説検証（こうだったらどうします？）はダメ、体験を聞く

ゲーム1回目（5分で3センテンス正解）

師匠（ユーザー）と弟子（インタビュアー）に分かれます。
師匠は、ユーザー体験がA4で4ページくらい書かれたスクリプトを読んで、ユーザーになりきる。
弟子は、インタビューをして、師匠の体験をインタビューして書き取る。
さて、どのくらい聞き取れるでしょうか？
私はボロボロで3センテンスしか正しく聞き取れませんでした。

ゲーム2回目（10分で15センテンス正解）

インタビューの仕方を少し教わります。
コツは次のとおり。

• 占い法はダメ（当てに行かない）
• 次は何をします？と聞いていく
• ある程度いったら、戻って、その前は何をします？と聞いていく
• 知ったつもりにならない

これを聞いた後、やり直したら、びっくりするくらい正しく、多くスクリプトを読み取れました。
1回目の後だし、時間も倍になっているので当たり前ではありますが、コツを意識するだけで、圧倒的にやりやすくなりました。
（1回目はアンチパターンの「占い法」でいってしまっていました。。。）

インタビュー設計

KJ法

聞きたいことリストをKJ法で整理します。
KJ法はおなじみですが、少し誤解があるそう。

• 似たものを近くにするとき、今、貼られているカードの中での相対的な距離で考える
• トップダウン的思考になるので見出しを先につけてはダメ、あくまでボトムアップ思考
• 縦横整列させず、空間をめいっぱい使う

写真は私のチームの成果物です。

シーケンス＋質問を考える

次に、インタビューのシーケンスを考え、見出しと聞きたいことを一列に並べます。
その後、質問を考えます。
質問は、弟子入りゲームで学んだことを活かして考えます。
写真は私のチームの成果物です。
※見出しのカードの字体が素敵でしょ。チームにたまたま不思議書体女子がいました(^^)

懇親会

懇親会が熱かった！

リアルタイムドキュメンテーション

リアルタイムにドキュメンテーションする方法らしいです。

1チームが実験台になって、スタッフに観察＋リアルタイムドキュメンテーションされ、これを使ってふりかえりが行われました。

カードの分類は以下のとおり。

• 黄色カード：事実の記録
• 黄色カードに赤い枠：講師の言葉
• 青カード：観察者の主観（気になったコト）
• 青ミニ付箋：残念な点
• 赤ミニ付箋：よかった点

これを観察者が説明して、観察されたチームが反論するというもの。

はじめてみたのですが、とても面白かったです。

でも、やるのはちょっと難しそう。。。

アプリデモ

UI/UXの賞をとったIMJさんの子供向けアプリ。

本当に、UI/UXが考えられたおもしろいアプリでした。

メンタルモデル

書籍「メンタルモデル」の訳者の1人、羽山祥樹さんによるメンタルモデルの解説。

その解説に、今回の講師の樽本さんが割り込んでディスカッション。

熱かった！

ちなみに、メンタルモデルは「ユーザーが期待、想像するもの」的なメンタルモデルとは別。

行動観察ではなく、インタビューから読み取るものなのでメンタルモデルと名付けられたそう。

混同するからよくないよね。

PI勉強会#1「Selenium勉強会」

@テラインターナショナル

記念すべき第1回は、2013年12月1日に大盛況のもと行われた、システムテスト自動化カンファレンス2013 ハンズオン「実践で学ぶ、効率的な自動テストスクリプトのメンテナンス」のコピーです。

こんな良質なコンテンツをフリーで公開しちゃうなんて、STARありがとう！
コンテンツ作者のTRIDENT伊藤さん、ありがとう！

以下、オリジナルコンテンツに対して、私なりにちょい足しした内容をメモしておきます。

メソッドチェーン

※SHIFTの玉川さんに教えてもらいました。ありがとうございます。

模範解答では、以下のようになっています。

pageObject.method1(foo);
pageObject.mothod2(bar);
・・・

これより、次のようにメソッドチェーンで書いた方が美しいコードになります。

pageObject.method1(foo)
               .mothod2(bar)
                ・・・

SpockとGebの紹介

※Gebはきょんさんに紹介してもらいました。ありがとうございます。

ハンズオンはJUnitですが、Spockの方が書きやすい。
Groovy, BDDとか言うと、何だか難しそうに思えるけど、実はSpockを使った方が簡単ということを伝えました。
口頭だけなので、どこまで伝わったかわかりませんが。。。
（JUnit実践入門もとってもおすすめしたので、どっちやねん！って感じだったかも。。。）

Gebは、JQueryライクに要素をとれてスッキリ楽々なことと、値の入力、取得がほとんどのコントロールで同一なので、むしろSeleniumより覚えること少なくて楽だということを伝えました。
こちらも伝わっていればよいのですが。。。

データ駆動とキーワード駆動の紹介

※もし、間違ってたら、誰かやさしくコメントください。

キーワード駆動（もどき）のデモ

※あくまで、もどきです。

これは結構ウケました。
えー、こんな簡単に、こんなことまでできちゃうのー的な(^^)

https://github.com/itagakishintaro/DevNomiTest

pages配下：テスト対象のコード

src/test配下：テストコード

（KDTcore.groovyがコアのコード）

※Groovyの環境設定はREADME.mdを参照してください。

「サービスデザイン思考入門（オージス総研）」に参加しました

サービスデザイン思考入門@オージス総研

ペルソナ、カスタマージャーニーマップ、ビジネスモデルキャンバスを使いながら、病院のサービスを題材にサービスデザイン思考をしてみる4時間のワークショップ。
個人的にはとてもよい勉強になったけど、会社でやるのはなかなかに大変だなぁ。

資料は、フェイスブックの「デザイン思考コミュニティカレッジ」で公開してくださるそうです。
なんで、資料はそちらから。

ペルソナの設定

はじめに、エンパシーマップを使って、ペルソナを設定しました。

私が知っているペルソナとは違うやり方なので、おもしろかったです。

「共感」を大事にしているデザイン思考にあったフォーマットなんですかね。

カスタマージャーニーマップ（AsIs）

流行りのカスタマージャーニーマップ。

ググると色々なフォーマットがありますよね。

今回は、とてもシンプルなフォーマットを用意してくれていました。

横軸が時間で、縦軸は「アクティビティ（シーン）」、「インタラクションズ」、「感情の起伏」の３つだけ。

インタラクションには、「気持ちとかも入れていいよ」というゆるい感じ。

やりやすいですね。

テーマ設定

カスタマージャーニーマップを踏まえて、テーマを決めます。

「感情が下がったところが狙い目だけど、視野を広く持ってテーマを決めましょう」とのこと。

でも、やっぱり、感情が下がったところをテーマにしちゃいました(^^)

アイディアだし

テーマに沿って、アイディアだしをします。
ここも、多少テーマからズレてもOKとのこと。
あと、「枠からはみだせ！」と。
いっぱいアイディアがでました。

カスタマージャーニーマップ（ToBe）

アイディアを適用したときのカスタマージャーニーマップを書いてみます。
感情のマイナスがなくなりました！

寸劇とフィードバック

できたカスタマージャーニーマップをもとに、寸劇を披露します。
（恥ずかしいけど、結構、雰囲気ができあがってるからできてしまう。）
で、寸劇をみた他のグループからフィードバックをもらう。
「良かったところ」、「改善点」、「疑問点」、「アイディア」の4分類。
意外に、見た人から「こんなのどう？」的なアイディアももらえたりしたのがおもしろかったです。

ビジネスモデルキャンバス

ビジネスモデルキャンバスは有名ですね。
（リーンキャンバスも有名。）
ググればすぐでてきますが、私は書いたことはなく、初体験。
ここで、スイッチが現実モードに切り替わります。
で、かなり「うーん」ってなってしまいました。
現実では、キャンバスの時点やプロトタイプをリリースした後のフィードバックで、何度もやりなおすんでしょうね。

ピクト図解

ピクト図解はワークはなくて、説明だけでした。
でも、ルール自体は簡単なので、使うのは簡単そうです。
使いこなすのは難しいんでしょうが。

ふりかえり

KPTです。

まあ、おなじみのやつです。

懇親会

色々なバックボーンの人の色々な話を聞けて、とてもよい懇親会でした。
中でも「実際には、叩かれまくるフェーズが絶対必要！」というのが印象に残りました。
そりゃそうですよね。

お礼

4時間コースで、懇親会の軽い飲食があって1000円。
えらいぞ、オージス！
これからも頑張ってオージス！！
ということで、オージス総研さん、ありがとうございました。

DAD本読書会#4に参加しました

DAD本読書会#4 @21cafe

DAD本こと、「ディシプリンド・アジャイル・デリバ​リー エンタープライズ・アジャイル実践ガイド」の
読書会#4です。
今回は、監修者の藤井さんに質問して、お話を聞いたり、みんなでディスカッションする方式でした。
DAD本勉強会ですが、RUPの話で盛り上がってしまいました。
以下、メモです。
誰がしゃべったのかは、もう覚えてませんので、藤井さんの見解とズレもあると思いますので、ご注意を。

方向付けフェーズ

方向付けフェーズは重厚じゃない。ゆるいRFPをつくるイメージ。

お客様がアジャイルについてわかっていないとDADを提案するのは難しい？
教育をして、DADでできるか判断する。
RFPでてからだと遅い。

検討不足と学習や発見との違いは？

そもそも、検討不足と学習や発見の分類に意味がない。
抜けが見つかってよかったと言えばいい。
結果的に価値のあるものをつくるために、つくってみて、動くものをみた方が抜けを見つけやすいことが多い。

推敲フェーズ

Unified Processの「アーキテクチャ中心」は捨てた？

なんでDADでは推敲フェーズがないのか？

出版前には推敲フェーズがあった。
Unified Processの「アーキテクチャ中心」を完全に捨てた訳ではない。
アーキテクチャを初期に確定させるのはNGだけど、変える前提で、ある程度アーキテクチャの見通しをたてて、リスクを潰すという発想。
そうなると、フェーズとして残さない方がよいという判断だと思う。

XPではアーキテクチャをはじめに考えない？

Kent Beckはテクニカルなリスクを優先順位に一切考慮しないと言っていて、Martin Fowlerは少しは考慮すると言っている。
このレベルの人たちは、飛行機の中でxUnitつくっちゃう人だから、頭のなかでアーキテクチャのこともちゃんと考えてるから崩壊しない。
DADでも他でもそうだが、stabilizationという機能を追加しないでアーキテクチャの整合をとるためのイテレーションを設けることがある。
大規模開発や金融系の開発をバックボーンに持つ人はアーキテクチャを重視する傾向にある。

DADは合意を重視

DADはアジャイルスケーリングモデルの中間。
意思決定やコミュニケーションの仕方を整理している。
常に早くリスクヘッジする。
それがビジネスリスクかテクニカルリスクかは問わない。
重要なのはそれを合意すること。
フェーズの区切りは、合意ができていること。

WaterfallとUnified Processは何が違う？

Waterfallで1次開発、2次開発とやっていたら、繰り返し。
Waterfallはアーキテクチャを重視する。
そもそも、ロイズの論文ではWaterfallは規模が大きい時は2回は繰り返すと言っている。
だったら、WaterfallとUnified Processは何が違う？

ユースケース駆動

UPの「ユースケース駆動」、「アーキテクチャ中心」、「インクリメンタルかつイテレーティブ」の3つで残るのは、ユースケース駆動。
あとは、1年を2回とかで反復と言えるか？

日本での大規模開発はRUPがいい

RUPはヘビーという誤解がある。
RUPは成果物を決めているが、成果物は紙ではない。
決めなければいけないことを定義しているだけ。
アジャイル開発でプロジェクトを進めるときは、バラバラの要素を組み合わせる必要がある。
RUPはまとまっている中から省いていく。
そうとらえると、日本の大規模開発では、RUPがあっているように思う。

業務システムでアジャイル開発は難しい？

業務システムは機能も多いし、ある程度まとまらないと評価できないので、アジャイル開発が難しいのでは？
BPRをしたいが、ステークホルダーが多くて、かつ、ITリテラシーが低い人ばかりなので、使わせて確認しながらやりたいというお客様の要望でやってうまくいったことがある。
業務システムという区切りではなく、何をしたいかが重要。
ゴールが不明確でアジャイルと言っているケースが多い。
BPRしたいとか、変えたいという意思がないとアジャイル開発する意味は無い。

大規模ではアジャイル開発は難しい？

なんで大規模だとアジャイル開発は難しい？

意思決定が難しいのでは？

Waterfallでも意思決定しているはず。ものを見せずに意思決定できるのなら、ものを見せたらもっと意思決定がしやすいはずでは？
みせる人数が多くて大変だったり、みせると意見がですぎてまとまらないのでは？
人数については、機能ごとに対象者は絞られるので、そうでもない。
ただし、バラバラにでた意見のまとめ役は必要。
意見はいっぱいでていい。
くだらない意見がいっぱいでて、実際に動くものをみると、くだらないことがわかるようになる。

複数システム、プロジェクトと連携するマルチベンダーの場合は？

アジャイル開発というかイテレーション開発になるが、統合リスクを管理するために、定期的に統合するメリットはある。

感想

アジャイル開発の勉強会で出席者がSIの人ばっかりってのはめずらしい。
貴重な場です。

あと、21cafe。すごくおしゃれで、無料。すばらしい！
いつか自分もここで勉強会を主催したいなぁ。

お礼

藤井さん、21cafeさん、ステッカーありがとうございました！

DevNomi in 梅村

DevNomiを六本木の梅村でやりました。
メンバーは、以下。
@s_banban @nekoasuka @ItagakiShintaro @snsk @hinac0

とにかく、楽しかった！
ソフトウェア開発の楽しさ知りたい人、思い出したい人は俺んトコこい！

@snskの「楽しく学ぶJavaScript」

15:00～18:00（30分くらい延長したかな。）は、@snskさんによるJavaScript入門をやりました。

正直、「んー、for, ifから入って、fizzbuzzかぁ。これは、ちょっとDevNomiはきついかなぁ。」と思ってました。
でも、所々、深い話もしてくれるので、まぁいいかくらいの感じで聞いてたんですが、途中、彼はすごいことを言いました。

大丈夫、絶対みんな書けるようになる。

おいおい、カッコよすぎだろう！！！

DevNomi

19:30位～22:15は、DevNomi。
酒を飲み、鍋をつつきながら、くじが当たったペアはコードを書く。
ペアプロも、テスト自動化の大切さも、人のコードの読み取りも、自然に学べちゃいます。
DevNomiでは、こんな会話が繰り広げられます。


「アスカくんのロジック変化球すぎるよー」

とか

「あ、こうしたらいけるよー」

とか

「あれっ、いけると思ったけど、このパターンのときダメじゃん」

とかとか


現場でもあるよね。
DevNomiはそれを楽しく、ギュッと凝縮して体験できるのがすごい！（自画自賛(^^)）

あと、本当に、個性がでる！
@snskさんは、丁寧に丁寧に説明するし、自分がナビゲーターじゃないときも様子をみてて、ホントに面倒見がいい。
@nekoasukaくんは、盛り上げ役。
女性陣（@s_banban @hinac0）は、とっても真面目。
自分は、いいかげん。。。

結果

2週して、なんと、全員がGreen化を体験！
これは、またやらないとだめでしょう。
テスト編もあるので、また頼みますよ、@snskさん！

Sublime TextでJavaScriptを書くための環境設定

Sublime TextでJavaScriptを書くための環境設定メモです。
以下はwindowsを想定していますが、Macなどでも基本は同じです。

1.Sublime Textをインストール

以下からダウンロードしてインストールします。

http://www.sublimetext.com/

2.Package Controlをインストール

以下のURLを開いて、SUBLIME TEXT 2枠内のPythonコードをコピーします。

https://sublime.wbond.net/installation#st2

sublimeエディターのメニューからView→Show Consoleを選択し、入力欄に上記をペーストし、Enterします。

sublimeエディターを再起動します。

3.Node.jsのインストール（JSHintを動かすため）

以下のURLの「INSTALL」ボタンをクリックし、インストーラをダウンロード、実行します。

http://nodejs.org/

4.JSHint（規約チェックツール）のインストール

コマンドプロンプトで以下のコマンドを実行します。

npm install jshint -g

5.JSHintの動作確認

JavaScriptファイル「ｓample.js」を次のとおり作成します。

name = 'test'; console.log(name) window.open()

 

コマンドプロンプトで、以下のコマンドを実行します。

jshint sample.js

出力結果：

sample.js: line 2, col 18, Missing semicolon.

sample.js: line 3, col 14, Missing semicolon.

6.SublimeへのJSHint Packageのインストール

1. Preferences→Package Controlを選択し、メニューからInstall Packageを選択します。
2. 入力欄にjs gutter と入力し、JSHint Gutterを選択します。
   ※エディタの一番下をみておくと、インストール中であることがわかります。
3. Tools →JSHint→Set node pathを選択します。
4. ファイルが開くので、次のように編集して保存します（node.exeのパスは環境に合わせてください。）。
   
   "node_path": "C:/Program Files/nodejs/node.exe"
5. Sublimeを再起動します。
6. sample.jsファイルを開いて、Tools→JSHint→Lint Codeを実行します。
7. 構文エラーが表示されることを確認します。

7.JS Prettify（整形ツール）のインストール

6と同様に、Package Control で　HTML-CSS-JS Prettify　をインストールします。エディター画面上で右クリックして、HTML/CSS/JS Prettify →　Prettify Codeをクリックすると自動で整形されます。

8.Sublimeのカスタマイズ

基本的なものだけ記載します。
後は、自分で色々いじってみてください。

カラーテーマの変更

Preferences→Color Schemeで色のテーマを変えられます。
ちなみに、私は、Solarized(Light)が目にやさしくてお気に入りです。
（黒バックの方がプロっぽいけど、どうもあわない。）

サイドバー

View→Side Barでサイドバーを表示します。
sublimeエディターにフォルダーごとドラッグ&ドロップします。
そうすると、サイドバーにエクスプローラー的なものが表示されます。
たくさんのファイルをいじるときは便利です。

ジャンプと検索

Ctr-p + : + n　でn行目にジャンプできます。
Ctr-p + @　でメソッド名などで検索できます。
もちろん、Ctr-fで普通の検索もできます。

画面分割

View→Layoutで画面分割できます。
ファイル比較などするときに便利です。

Vim化

私には完全に不要なのですが、お好きな方もいらっしゃるようなので。。。
Preferences→Settings - Userを開きます。
以下を追加します。
(Defaultでは"ignored_packages": ["Vintage"]でVim化を無視するようになっています。)

"ignored_packages":  []

その他

Preferences→Settings - Defaultを開きます。
気になる部分をコピーします。
Preferences→Settings - Userを開き、ペーストします。
なんとなく、いじってみます。
で、どうなるか試してみます。
こんな感じで設定を変えます。

「TDD LOVE!」(DevLOVE#157)に参加してきました。

 「Growing Learning Feedback Loop, Guided by TDD & Patterns」家永英治氏

TDDの範囲はいろいろあるけど、今日の話は、Acceptance TestingとUnit Testingの2重ループがメイン。

TDDでは、素早く、小さく失敗し、学習しながら前に進むメカニズムが重要。

オートメーションは、学習フィードバックループの回転を加速させる。

TDDのエントリーポイント

• 1-2人で、対象を絞って実施
• PO-開発者の受け入れテストから始める
• チームでScrumに取り組み、デモを始める

学習ループのコアとなる3つの問い

• Why:ユーザーがほしい？
• What:期待する振る舞いは何？
• How:どうすると読みやすい？

この問いに答えるのは人。

初手で行われているコツ

• テスティングフレームワークの準備
• まねて学ぶ
• Red-Green-Refactorのリズム
• 素振り（写経）
• ちょと実装-テスト
• TDDBCに参加する

• 1人でひっそり
• 気の合う同僚
• 界王拳（自発的残業）
• 個人のタスクボード
• タイムボックストライアル
• 適切な時期

TDDBC、素振り（写経）で準備は王道！

「リーダブルコード」も読んでみよう。

TDDを学びあう同僚を見つけよう。

書籍「リーン開発の現場」からのヒント

• 新機能は普通にTDD。
• 重要なものからリストアップ。
• End to Endよりにテストを補強。

その他のヒント

• 書籍「FEARLESS CHANGE」から
• 書籍「xUnit Test Pattern」から

「テスト自動化のアプローチ拡張トレンド 〜Excel項目定義手動テストから自動テストへ〜」福井修氏

20140212 develove from Fukui Osamu

るびま　に詳しく書いています。

今日はポイントだけ。

DSL（ドメイン特化言語）

• Chef
• Fluentd
• RSpec
• Gherkin
• Capybara

今日は、GherkinとCapybara中心に。

結論を先に

• Rubyの進んだテストツールを使うと自動テストもおいしくええとこどりできる
• エンドツーエンド（e2e）は、Gherkin+Capybara+Turnipが有利
• 外部テスト管理もExcelからWebDBに

視点

• 書籍「継続的デリバリー」のテスト自動化ピラミッド
• テストのWモデル
• IPA「高信頼化ソフトウェアのための開発手法ガイドブック」
• テストの種類（単体、結合、システム、受け入れ、回帰）
• 内部テストと外部テスト（e2e）
• DevOpsでDevはカジュアルにテスト、Optの前にフォーマルにテスト

Unitテスト自動化→e2eテスト自動化

• Gherkinでベタからメタに
• CucumberとTurnip

gherkin書式

• TDD/BDD：プログラマー視点
• e2e：ユーザー視点

どちらも必要。この境界を書けるのがgherkin書式。

gherkin書式の導入でプログラマ以外がテストを書ける。

1. 機能feature
2. シナリオ
3. ステップ

.featureファイルとxx_step.rbファイルがあれば自動化できる。

step.rbファイルを記述するには、Capybara, Rspecの理解が必要。

テストコンテンツの管理

ExcelからWebDBへ。

Rtestdeck：Webから操作できるGUIツール化。

質問＆相談

• TDDを依頼するとすごい見積もりに。。。どうすれば？
  ->1週間とか試してすり合わせてから全体を見積もるとよい。
  ->お試しで小さくやってみるところからはじめるとよい。
• Turnipを使って、DBを使うプログラムのテストはどうするのがよい？
  ->DBの設定は内部テスト。Turnipは外部テストなので、レイヤーが違う。
• POがgherkin書式で書いてくれない。エンジニアがやるならメリットないのでは？
  ->作った人じゃない第3者が書くことが重要。
  ->ボトムアップかトップダウンかが違う。
  ->エンジニアが書いて、レビューしてもらうパターンもある。
  ->ビジネスサイドとエンジニアがペアでやるのもよい。
• リファクタリングをどこまでやったらいいか基準は持ってる？
  ->同僚に求められる暗黙の基準、期待はクリアする
  ->完璧なリファクタリングは無理。納期などの制約に応じてやるしかない。
  ->理想へのシナリオを用意して、空いた時間にやったこともあった。
• 同僚がクリーンって言ってくれるまでやってたら、お客様がそこまで要らないと言ったら？
  ->ホントはダメだけど、仕方ないよねというのはある。
  ->後々、お客様にも痛みがあるので、考えながらやるしかない。
  ->制約の中でやるので、あきらめることも必要。
• 年度が変わったときなど、データをうまく扱うにはどうしたら？
  ->前提データをどれだけ簡潔にメンテできるようにするかが重要。
  ->時間をコントロールする道具も必要。
  ->テストを維持するにはコストが必要。コードを変えるならテストもメンテが必要。
• テストの文化を広めるときに具体的にどうすれば？
  ->困っていることを話すことから。
  ->TDDBCに2,3人でいってみるのがおすすめ。
• TDDを社内全体に広めるときにはどうすれば？
  ->そこまで狙わなくても。。。TDDBCに参加しましたとか少しずつ。
  ->「FEARLESS CHANGE」にいろいろあるけど、まずは自分のまわりから。

DevNomi（テスト編） in BOOKSHELF CAFE

アジャイル開発のプロジェクトでスプリント0が終わった！
ということで、打ち上げ＋本格的な開発に向けての決起大会を兼ねて、DevNomi（テスト編）をやりました。

DevNomi（テスト編）について

• 説明：http://itagakishintaro.github.io/DevNomiTest/slide/index.html
• テスト対象：http://itagakishintaro.github.io/DevNomiTest/pages/index.html
• ソース：https://github.com/itagakishintaro/DevNomiTest

メンバー構成 

• 開発者：4名
• デザイナー：2名
• DevNomiディレクター（笑）：1名

結果

1時間くらいやって、テストケースを2つしかできませんでした。。。
「酔っ払って、計算出来ないよー」とのこと。
ということで、次回に引き続きですね。

賞品はあげられないので、参加賞として、全員にHolsteeのマニフェストを印刷したカードをプレゼントしました。
（アジャイルエバンジェリスト平鍋さんのマネです。）

会場（Bookshelf Cafe）について

http://www.bookshelfcafe.jp/

iPadが使いたい放題で、プロジェクターも使えるとてもすてきな場所でした。
飲み物もこだわり系で、たくさん飲み食いするより、おいしいものを少しっていうタイプの私には最適！
今後、IT系の勉強会を開く予定だそうなので、要チェックです。

「LEAN UX」を読みました。

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

本の中のこの言葉。

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

LEAN UXの3つの基盤

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

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

原則

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

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

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

テンプレート

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

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

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

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

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

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

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

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

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

プロセス

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

スタイルガイド

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

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

MVPと実験

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

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

プロトタイプ作成の基準

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

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

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

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

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

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

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

継続的ディスカバリ

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

Lean UXとアジャイルの統合

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

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

組織的な移行

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

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

teian-labで発表しました

徹夜で作った提案書では負け。 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 真太郎 板垣