2016年5月23日月曜日

JJUG CCC 2016sでボランティアスタッフとかしてきた

JJUG CCC 2016 Springがあったので、ボランティアスタッフと「AB-7 若者にJavaの好きなところ嫌いなところきいてみた」でパネルディスカッションのようなことしてきました。

前日日付変わるギリギリまで渋谷で飲んでいたので午前中はぐったりしてるんじゃないかと心配でしたが、仕事内容もそこまで無かったので良かったです。

ボランティアスタッフとしてやった事としては

  1. ロビーでの会場案内
  2. 部屋の片付け
  3. タイムキーパー
の3つぐらいでした。
ロビーでの会場案内はエレベーター前で立ってこっちですよーと書いた紙を持ってるだけ。丁度Raspberry Pi with javaの話があったタイミングでセッションで自分がしゃべろうとしてるネタと被ってないかと内心ヒヤヒヤして話聞きたかったタイミングでしたが、まぁ結果として問題なかったです・ω・
これは会場のルールなのか張り紙が出来ないからやってたそうですが、正直必要だったのかちょっと疑問。
午後からは役目自体がなくなったっぽかったです。会場の立て看板とか貸してくれたらいいのになー。
ただ、立ってて面白かったのが別の会場であった会議か何かの帰りの人に声をかけられて色々と定年後のお話を聞かせてもらったこと。立ってるだけで暇だったので凄く面白く感じた。

タイムキーパーは10分前と5分前に登壇者に紙を見せて時間をお知らせする役目でしたが、担当したセッションの登壇者の方々はよく訓練された発表者のようで11分前に時計を見る、6分前に時計を見る、とかなり正確な体内時計を持っていらっしゃるようで、ほとんど必要とされてませんでした(´ . .̫ . `)


AB-7のセッションではJavaの嫌いな話をしてくれと言われましたが、普段から全くと言ってJavaを使っていない人間だったのでちょっと困りましたが、組込っぽいエンジニアとしての目線で何故Javaを最近使ってないのかっていう話をしました。 資料
まさか、JavaのカンファレンスでJava嫌いな話をすることになるとは予想してませんでしたw
次は複数人のセッションでなく、LTなりセッションなりで話せるようになりたいですが、如何せんJavaを使わないので別の機会になりそうです。

また次回CCCがあればボランティアスタッフなりもう少し責任のあるスタッフをやりたいかなーと思いました。



#以下アフィリエイト用の広告です

-->

2016年3月27日日曜日

Thinkpad X1 Carbon 2016を買った

Thinkpad X1 Carbon 2016を買ったので今後いろいろとレビューしておこうと思う。


構成

買ったのはこんな感じの構成です。色つけたところが標準から変えたところ。
WiGig対応が欲しかったのでどうしてもWQHDのディスプレイにせざるを得なかった。

プロセッサーインテル Core i7-6500U プロセッサー (2.50GHz, 4MB)
初期導入OSWindows 10 Home 64bit
導入OS言語Windows 10 Home 64bit - 日本語版
ディスプレイ14.0型WQHD液晶 (2560x1440 IPS)
メモリー8GB LPDDR3 1866MHz (オンボード)
グラフィックスインテル HD グラフィックス 520
キーボード英語キーボード (バックライト付)
指紋センサー内蔵指紋センサー
内蔵 カメラカメラ(HD 720p対応)あり 、マイクロフォンあり
セキュリティーチップTPMあり
ハード・ディスク・ドライブ256GB ソリッドステートドライブ SATA (OPAL対応)
ポインティングデバイスThinkPadクリックパッド
バッテリー4セル リチウムイオンバッテリー (52Wh)
電源アダプター65W スリムACアダプター
ワイヤレスインテル Tri-Band Wireless-AC 18260(2x2、WiGigおよびvPro対応) + Bluetooth 4.1
WiGig Selection対応
WiGig DockWiGig ドック
Onelink+ アダプターHDMI-VGA変換アダプター
標準保証1年間 引き取り修理

買った理由

これまで使ってきたMac Book Pro Retina(2012 Mid)ですが、メモリ16GBにしてあり、家に置いて使うPCとしては未だ文句のでないスペックです。
CPUは2.3GHzの下のスペックですが、ほぼ文句なしです。メモリもてんこ盛りにしておいたのでChromeでタブを開きまくっておきながら、メモリ8GBを仮想マシンに割り当てても快適です。
まだMacが必要となる場面や家で高解像度、広い画面が必要となるような場面ではしばらく使い続けるでしょう。

でも、このMBPr、重いんです。カタログスペック2.02Kg。アクエリの2Lペットボトルをいつも持ち運ぶ気にはなれず、関東へ戻ってきてから行く機会が一気に増えた勉強会にはXperia Z4 Tabletにキーボードつけて行ってました。ただ、流石に画面がちょっと小さいのと、暇な時に開発もガッツリとやりたいなーと思い新しいPCを買うことにしました。

ちなみに、Xperia Z4 TabletでもCloud 9などのクラウド型の開発環境を使えばRubyとかの開発できます。SIM入れれば単体でいつでもどこでも開発可能!


ThinkPadにした理由

トラックポイント最高。ホームポジションから手を離さないでいろいろと作業ができるのが最高。
ThinkPadのBluetoothの英字キーボードを仕事で使っているのですが、アイソレーションタイプしか使ったことがないニワカなのでX220みたいな7段配列じゃなくてもOKでした。

X260とT460sと悩んだ

X1CとX260でかなり悩みました。
サイズ感、拡張性、どれをとってもX260が最高です。ただ、どうしても解像度が低いのが気になったのと、購入時にWiGig対応がなかったので仕方がなく候補から除外。
あとT460s。こいつは拡張性のあるX1Cのような存在。メモリが後付で増やせれたりSSDを交換できたりする。しかもGPUまで載ってる。

しかし、当初の予定の軽さ再優先、画面の広さを取りX1Cを買いました。

届いてみて

キーボードの打ち心地は最高です。トラックポイントもいい。Windows10も言われているほどクソでもなく調教のしがいのあるOSだなと。
ただ、Macと比べてテキストエディタでEmacsキーバインドでのカーソル移動ができなかったり、フォントが汚かったりと微妙な点も何点かありました。

最大のX1Cとして(というか高解像度)の欠点が、DPIを100%にするとめっちゃ文字が小さい。かと言って見やすい150%にするとフルHDよりも解像度が低くなるという問題が。
WiGigが不要でフォントが小さいと困るという人はフルHDにしたほうが確実に良いです。

高解像度が微妙だったので、X260がWiGig対応したらフルHDじゃなくてもいいのかもしれない。



#以下アフィリエイト用の広告です

-->

2016年3月26日土曜日

世界のビールと音楽を組み合わせてデータ分析を行うイベントに参加してきた


世界のビールと音楽の組み合わせをデータ分析で最適化!


ビール好きでデータ分析を始めてみたい私には最高のイベントがあったので前日に主催者のuzuramの宮本さんとFacebookでやり取りして参加してきました。

このイベント、音楽を聞きながらビールを飲んで、どの音楽と、どのビールが合うかを参加者が主観で決めていき最後に解析をかけて

「この音楽には、このビールが合うという人が多いです」

と言ったようなレコメンドができるようになろうというイベントでした。
最高か。ビールたくさん飲めて、データ分析の入門まで教えてもらえるとか最高か。

すこし残念だったのが他のイベントと被っていたのか直前キャンセルが多数あり参加者が講師含めて6名となってしまったこと。ただ、おかげでビール堪能できました。おつまみ買っていけばよかった。

講師の方は DATUM STUDIO株式会社 の中原さん。花粉症が辛いらしくティッシュが手放せない様子でした笑

ビール


今回のメイン。。。じゃなくて、解析対象となるビール。たくさんありました。
世界のビールと銘打ったイベントだけあって世界一周をしてました。(南極大陸はなかったので5大陸制覇ならず)
以下今回のビール説明と私の感想です。ビールの説明はイベントページからの転載です。

ネグラモデロ

産地:メキシコ  特徴:ダークモルト、ホップのバランスのとれた風味と繊細な香りを持つミュンヘンスタイルビール(ダークラガー)。メキシコで第1位、アメリカの輸入ビール市場で第2位のダークビールブランドで、クリーミーな泡と明るい黒褐色の液体が特徴。特別な食事や特別な瞬間を演出するのに最適なビール。

自分としてはこんな印象でした。
  • すこし甘めな印象(バーバーバーよりは甘くない)
  • 少し香ばしい香りがする

バーバーバー

産地:ベトナム  特徴:キレが良く、スッキリ爽やかな味わいは日本人の味覚にあったビールです。昨今のベトナムブームによるベトナムレストランの急増で、国内でも躍進しています。サイゴン社はベトナム最大手のビールメーカーで、製法技術はフランスからの影響を受けています。

自分としてはこんな印象でした。
  • ビール?って思うくらい甘い(比較的温度が高めだったからか?)
  • ホップ感は全く無い

フラーズ ゴールデンプライド

産地:イギリス  特徴:フラーズが誇るプレミアムストロングエール。深い琥珀色で優しい苦味と穏やかなホップの風味に芳醇な麦芽の味わいを持ち、甘いオレンジオイル、トーストしたパンを思い起こさせ、甘味と苦味がこの濃厚なビールにバランス与えます。

自分としてはこんな印象でした。
  • かなり濃い
  • 黒ビールっぽい
  • 一気に飲むと日本酒に近いアルコール感
  • 後味に残るアルコールの感じが日本酒に近いものがある

ベジエールレタス 瓶

産地:日本  静岡県: 特徴:産直団体(株)野菜くらぶのトレーサビリティーのしっかりしたレタスをふんだんに使い世界でも珍しい飲み物を仕上げました。食事に合い、フルーティーで爽やかな仕上がりが楽しめます♪
本物に徹底してこだわりました!だから、原材料も麦芽・ホップ・レタスのみ。 しっかりと酵母が効いた深い味わいでありながら、フィニッシュにレタスの爽やかさが駆け抜けます。 食前酒でも食中酒としても、楽しく豊かな時間を提供します。 野菜くらぶのレタスは、適地適作、産地リレー、契約栽培契約販売を基本に、群馬・静岡・青森・岡山の産地と技術を共有し、全国をリレーすることで一年通して安定的に出荷しています。 “VEGEALE LETTUCE”でも、“野菜くらぶブランド”のフレッシュなレタスを使用しています。
自分としてはこんな印象でした。
  • 泡、香りがすごいレタス感がある
    • 青臭いような嫌な感じではなく、さわやかな感じ
  • 他のビールと比べると軽い感じ
  • クラフトビールだけども大手のビールと同じような飲みやすさ(製法の問題?)
  • すごい日本人が好きな味

パウラーナー ヘーフェ ヴァイスビア

産地:ドイツ  特徴:50%以上の小麦を使用し、瓶詰め後も瓶の中で二次発酵します。白く濁ったやや濃い黄白色にクリーミーな泡立ち。バナナ、クローブ、パンの香りがあります。レモンのような柑橘系のさわやかな酸味とやさしい酵母の甘味とのバランスが素晴らしいビールです。
自分としてはこんな印象でした。
  • 軽めの味
  • 甘くもない
  • 香りも強くなく程よい
  • 泡がすごいフルーティーな味わいでバナナっぽい感じ

バドバー ビール 瓶

産地:チェコ   特徴:チェコの最高級ホップ、モルト、地下300mの良質の水により造られたバドバービールは、700年の伝統を誇ります。麦やホップが主張しつつも調和の取れた味わいで、後にバドワイザーのモデルともなった純粋ビールです。
自分としてはこんな印象でした。

  • 軽い。さすがバドワイザーのモデルとなったビール
  • すごい飲みやすいからはじめの一本に最適

音楽

音楽もまた古今東西いろいろでした。個人的にはEDMの曲がヒット。以前別のイベントで聞いたことあったけども曲名がわからなかったのが、このイベントで曲名がわかった!しかもAmazon Prime Musicにもあり大助かり。
会場では何故四季の夏なんだ?と疑問が出てました。なんでも参加予定だった方からのリクエストだったそうなのですが、何故夏なんだろう。。。もうすぐ春なのに笑

  • JPOP: 世界に一つだけの花
  • 洋楽: Oasis What ever
  • EDM: Timmy Trumpet - Freaks
  • クラシック: ビバルディ 四季夏
  • JAZZ: Take Five
  • 演歌: 津軽海峡冬景色

飲みながら音楽を聞いて、参加者からは積極的なデータ分析についての質問が飛んだりとワイワイできました。少人数の勉強会は参加するまでの敷居が高いですが参加さえしてしまえば講師の方とも距離感近いので良いですね。


そんなこんなで一応イベントの趣旨であるデータ分析を行うために音楽とあうビールをスプレッドシートへ入力していきました。一通りできたらCSVでダウンロードして入門編が始まりました。

Rとは?

Wikipediaによると

オープンソース・フリーソフトウェアの統計解析向けのプログラミング言語及びその開発実行環境である。

統計解析向けに作られているプログラミング言語だそうです。イベントの講師の方に質問してみたところ、よく解析に使われるPythonとか、Matlabと比較して見ても統計解析向けに作られているライブラリが多くあり簡単に使うことができるそうです。ただ、汎用的なプログラミング言語としては少し使いにくいところもあるそうです。


アソシエーション分析

集合論、包含関係
アマゾンのおすすめみたいな機能を実現するための分析
Supportでソートして、Confidenceで考察

頭に入れておいたほうがいい概念

支持度(suport)

  • 商品Xと商品Yが一緒に買われている頻度がどのくらいの規模で発生しているかを確認する指標
  • 調べたいケース/全ケース
  • まず一番最初に見るべき指標
  • 発生頻度でソートして頻度が少ないケースは無視したほうがよい

確信度(Confidence)

  • 一緒に買われやすいかを表現
  • XとYに方向性
  • Xを買った人がYをよく買っていればおすすめできる
  • 包含関係でおすすめは変わってくる
  • ベン図

リフト(Lift)

  • Lift = (Xを買う人がYを買う確率) / 全体の中でYが買われる確率
  • 何もしなくても商品Yをどれくらいの人が買っているかという確率に対して、商品Xを買った人でYも買う人がどれくらいいるかを確率(Confidence)を比較する指標

実装

実装はRStudio上で行いました。最終的なコードはGistにあげておきました。
中原さんがすごい丁寧に説明していただけるのですごいスムーズに実装でき、ビールも飲みながらでも実装が終わらせれました。
ただ、唯一の問題が前半戦でしこたまビールを飲んでいるので途中でかなりトイレに行きたくなってしまいました。お酒の入る勉強会はトイレ休憩を頻繁に入れたほうが良さそうです。

RStudioがすごい便利でMatlabと似たような統合環境だなといった印象。

コンソールでデータを表示



すごくエクセルです。


棒グラフで出現頻度を表した。


データの相関関係を図で表した

などなどがめっちゃ簡単に実装できました。アソシエーション分析のパッケージもPythonにあったので、そちらも試してみないと一概に言えないですがここまで簡単に表現が色々できるのであればもっと凝った分析や分析結果からモデルのストーリー建てなどのもっと重要な事に時間がかけれるようになりそうです。データ分析すげぇ!!楽しい!!

今回の考察としてはレタスビールとオアシスの曲がすごく相性が良さそうだというのが参加者としての共通認識だったようです。(人数少なかったしはじめに飲んだビール、はじめにかかっていた曲という事もありそうですが)


まとめ

個人的に感じたこととしてはデータ分析を見える化するまではツールで簡単にできましたが、そこからストーリーを組み立てていくということ、見える化された情報から何が起きているのかを意味付けするということが大変なのだと感じました。実際相関図をみてレタスとオアシスは相性良さそうというのは素人目でもぱっとわかりましたがそれ以上のことは正直わかりにくかったです。でも講師の中原さんはポンポンとストーリーを出していたのでやはり見えている世界がまた違ったようです。
こういう所がノウハウであったり強みになっていくのだと感じました。

ただ、分析しなくても分かった事があって、世界中のビールは美味しいということでした。
いや、もう少しデータの母数を増やしたいので、ぜひ次回の開催をお願いしたいです。


#以下アフィリエイト用の広告です

-->

2016年2月29日月曜日

JOT DASHをAmazonタイムセールで買った


【日本正規代理店品】Adonit Jot Dash ペン先1.9mm 高精度スタイラスペン iOS / Android OS 対応 チャコール ADJDC

AmazonのタイムセールでAdonit Jot Dashがちょっとだけ安くなってたので買ってみた。
もともとタブレットで裏紙代わりにメモを色々と書きたかったので丁度良いタイミングだった。

せっかくなので家にある色々な端末で書き味を試してみた

結果

iPad最高。普通の紙よりは書き味は劣るけども十分に実用になる。
ペン先も細くボールペンで書いているみたいな感じになる。
買って正解だったと思います。無駄な紙が減らせれるのでゴミ捨てが楽になりそう

それでは細かい内容です。

Jot Dashの評価

DASH!!

名前の通り書き出すのにダッシュで書けます。充電スタンドとペンが磁石でピタっとくっつくのですが、取り外して頭のボタンを1回ノックすればもうすぐに書けます。たまにノックするの忘れてそのまま書き出してしまい「アレ?」となることがあるくらいすぐに書けます。

ペン先

ただ、ペン先が固い+1ミリほど浮いてるので書いているとカチャカチャ音がします。静かな職場でカリカリ書いていると目立つかもしれないレベルです。
少しペンを寝かせて書くと静かに書けるようです。

書き味

ボールペンみたいです。だいぶ固めです。端末の画面が汚れていると書いた軌跡が見えるようになります。ペン先が浮いている分柔らかい書き味になるかと思ったのですがただ音を出しているような気がします・・・

それでは端末ごとの比較してみましょう。

比較端末

  • iPad mini(第1世代)
  • Xperia Z4 tablet
  • Xperia Z5
  • Nexus 5
  • KATANA 02
Jot Dash自体はガス工事のおじさんとかがカチャカチャ音を立てて使っているようなペン先の感じ。

アプリは以下の当たりで試してみました。
  • metamoji note lite
  • Onenote

iPad mini

世代としては初代なのでもう3〜4年くらい前の端末です。表面に保護シートあり。



metamojiでザクっとアルファベットを書いてみたらかなり精度良い。期待以上です。
字が汚いのでアレなんですが、ガタガタしない。Mとか自分の筆跡通りです。Sのカーブもキレイに出ています。

Xperia Z4 tablet

こいつはキーボード付きでいつも持ち歩いている愛用機です。表面に保護シートは無しです。


こちらもざっくりとアルファベットをmetamojiで書いてみました。しかし、細かい部分がガタガタになって正直残念な感じ。Sとかガタガタになってしまいましたし、QとかQじゃない感じに。。。
ただコレ、アプリというかスクリーン自体の性能っぽいです。試しにonenoteで書いてみました。


やっぱりダメっぽいです。Sとか悲惨。
アプリのダメだしですが、onenoteめっちゃ手書き使い難いです。消そうと思うと消しゴムツールで線を1本ずつ消す必要があります。UnDoもどこからやればいいのかサッパリ分からないです。

Xperia Z5

新しい端末なので少し期待。保護シートナシです。
スマホ画面なので少しメモには小さいので微妙ですが試しに書いてみました。


うーん。微妙です。Z4 tabletとそんなに変わらない書き味です。画面もタブレットと比べて小さいのでメモとしてはあまり期待は出来ないです。

Nexus 5

5Xじゃないです。初代です。保護シートアリです。


Z5よりも微妙な精度になってしましました。もう常用はしていない端末なのでオマケ程度です。

KATANA 02

Windows 10 mobileです。密かにお気に入りな端末です。Windows 10 mobileのアプリ開発のためにWindows 10のPCが欲しくなってます。
Windows 10 mobileなのでonenoteで書いてみましょう


アレ?


アレアレ?Onenoteじゃ手書き出来ない??
ストアにはインクを追加できるみたいなこと書いてあるのに?

仕方ないのでEvernote

Evernoteお前もかー!!!


ちくしょー!期待のmetamojiもストアにねぇじゃねか!!

ということでWindows 10 mobileでの手書きは諦めました。
何でも出来そうで、何もできないWindows 10 mobileかわいいなー。もー。

まとめ

結果にも書きましたがiPad最高です。手書き精度は頭1つ抜き出てます。Apple Pencil使うともっと精度いいのでしょうね。ただ、OSレベルでの文章などの共有がAndroidと比べるとまだイマイチな印象。IMEとかね。


iPad miniがWi-Fi版なのですぐにPCに共有したいとなった時に面倒だったので、とりあえずの運用としてはXperia Z4 tabletでできるだけ拡大して図を書きつつ、文字はキーボード入力でいってみようと思います。


#以下アフィリエイト用の広告です

-->

2015年11月27日金曜日

アジャイルジャパン・プレイベント企画「アジャイル初心者向けセミナー」

概要

  • 日時:2015年11月27日(金) 13:00~19:30
  • 場所:NECソリューションイノベータ

アジャイルジャパンのイベントが合ったので行ってきた。
その際のメモ。


初心者向け講義

13:00~15:00

  • 発表者:豆蔵 中佐藤麻記子

セミナーの背景

今回は春先にあるアジャイルジャパンのプレイベント
アジャイルジャパンは2016/5/31を予定

宿題

http://www.scrumguides.org/download.html
→Japaneseを選ぶ

アジャイルとは?

  • アジャイルソフトウェア開発宣言
    • 提唱者ごとにアジャイルの手法が様々あるので何が正解かというのが無い
    • XP
    • scrum
    • それぞれで用語も少しずつ違う

今回は情報が少ないXPベースで話をする

エクストリーム・プログラミング

以下のアジャイルプラクティスを最初に取り入れた手法

  • TDD
  • リファクタリング
  • CI
  • 顧客同席
  • ペアプログラミング

4+1の価値を実現するプラクティス
コミュニケーション、フィードバック、シンプリシティ、勇気+リスペクト

アジャイルプラクティスメトロマップ

http://guide.agilealliance.org/subway.html

アジャイルプラクティスの用語集
なんとなくの見方

  • グレーの線が基礎
  • ピンクがXPでよく使われるプラクティス
  • あとは左から右にざーっと見る

これで停車駅を決める⇒今回使うプラクティスみたいなのを決めると分かりやすそう

イテレーション

scrumではスプリントと言う
1週間から3ヶ月(3ヶ月は長すぎると思う)
要件分析から実装・テストまですべての開発を行う
イテレーションの終わりにはリリースできる動くなにかを用意する

会議体

  • 計画会議(スプリントプランニング)
  • レビュー会議(スプリントレビュー)
    • 作ったもののレビュー
  • レトロスペクティブ(ふりかえり)
    • チームのプロセスのレビュー
  • 日次スタンドアップミーティング(デイリースクラム)

ストーリー

ストーリーリスト(プロダクトバックログ)

  • 要件リストのこと
  • カード形式にしておいて優先度順で上から並べる

アジャイルで最低限使われるプラクティスは上記の3つ

アジャイルが継続できない

  • なぜアジャイルなのか?
    • 現状のプロセスに問題があるのでアジャイルを実施することになったはず
  • 価値にたち戻って考える

ウォーターフォール

  • input -> process -> output
  • WFが正しく動くには
    • 入力が正しいこと
    • 途中に落とし穴が無いこと
    • 設定されたゴールが正しいこと
    • 階層化されたプロセスにおいて100%正しくIPOが繋がっていること

アジャイルにたいする誤解

ウォーターフォールできっちりできる事であればアジャイルよりも絶対に効率がよい

アジャイルは少しずつ進んでは会議でチェックする

  • 作るものと作り方を進みながら変えていく
  • 変えてはいけ無いことを決める
  • インセプションデッキ(プロジェクト憲章)

継続的~~

WFと違ってすべて継続的
「アジャイルな計画と見積もり作り」

  • 計画を立て続ける
  • 要件定義をし続ける
  • 設計をし続ける
  • 実装をし続ける
  • テストをし続ける
  • プロセスを変更し続ける

価値にたち戻る

なんのためにやるのか??

  • コミュニケーション、フィードバック、シンプリシティ、勇気のどれかの価値を高めることができるか?
    • プラクティスが実現できない場合も価値にたち戻る

コミュニケーション

ソフトウェア開発で一番重要なのはコミュニケーション

  • 重要なのであればコミュニケーションをとりやすくするためになにをしているのか?
  • コミュニケーションの齟齬を防ぐ方法

フィードバック

  • 進捗
  • CI
  • TDD

シンプリシティ

よりシンプル、コストのかからないものを選ぶ

  • コミュニケーションの取り方
  • フィードバック
  • 設計

勇気

アクションを起こすための勇気/勇気を持てる仕組み

  • 悪い情報が外に出てこなければフィードバックサイクルは回らない
  • 嘘の無いコミュニケーション
  • 現実を受け止める
    • 受け入れてあげないと真実が出てこない

リスペクト

なぜ価値が4+1なのか?

  • 4の価値はプラクティスで実現される
  • 1の価値はプラクティスで実現できない
    • ベースとなること
  • 目指すゴールにたいするリスペクト
    • 完成したら世の中への影響があるんだ!というようなパッション

事例紹介

「事例聞きたい」病
↓ 対処療法で事例を聞かせると・・・
「でもうちの会社では」病

  • 世の中に全く同じチーム、同じ会社なんてものは無い
    • どこかの成功例を持ってきてもうまくいくわけが無い
    • 銀の弾丸は無い

アジャイルジャパン2016 テーマ

“あなたとつくるアジャイル”


今時のスマホゲーム開発事例、アジャイルテスト添え

15:10~15:40

グリー株式会社 Quality Assurance部
西脇春名氏 @haruna_nishi

資料

聞きたい内容

  • アジャイルテストの話が聞きたい
  • デメリットは?

今時のスマホゲーム開発

昔はビックバンテストやってた

  • 初期段階ではスクラムを採用
  • テスト期間が短い
  • 市場トレンドが変わりやすい
  • カジュアルからハードなゲームまで様々なニーズ

アジャイルテストについて

リリースサイクルの中で各サイクルの ストーリー に対するテスト。システムテストや受け入れテストに近いフェーズなので単体テストとかではない。

グリーの場合

  • 本開発が決まった時点で担当がチームにはいる
  • 毎日探索的テストを実施(仕様の理解・実行をその場で行う)
    • 不具合があれば修正
  • リリース前には従来と同様にマニュアルテストを実施する
    • ここで社内標準の品質保証を行う
  • 開発後期になるとメンバーが増えてアジャイルが消滅することもある
    • それでも探索的テストは続ける
  • 品質の底上げに繋がっている

アジャイルテストのメリット

  • 手戻りの最小化
  • 常にアプリを動作させられる環境を作っておくことができる
  • 実機とエミュレータの差分やパフォーマンスが早期でわかる

手戻り最小化

  • いつの変更でエンバグしたかがわかる
  • 品質保証をする最終フェーズでのテスト時まで重大な不具合を見つからないことがなくなる
  • 品質は製品に組み込むものという意識がチームに形成される

常にアプリを動作させられる環境を作っておくことができる

  • 毎日動作できる状態を維持することを意識させることがチームにできる
  • 継続的デプロイ

実機とエミュレータの差分やパフォーマンスが早期でわかる

  • エミュレータでの操作性と実機での操作性の違いがわかる

QA

  • ビジネス的な価値のあるまとまりは?

    • 機能単位
  • デメリット

    • 工数がかかる
    • やる人によってテストのクオリティに差がでる
  • 自動化は?

    • 自動化は特にしていない
    • ゲームは難しい
    • 画面遷移系はできそう
  • 探索的テストは誰がやってるのか?

    • チームごとで違う
    • 仕様を考える人、品質担当、PM的な人
  • どこのタイミングでやってるのか?
    • 朝と夜
  • なにか基準があるのか?
    • 品質担当が決める
    • 品質担当以外は仕様が満たされているかだけをチェック
    • 1時間ぐらい
    • チュートリアルは全部やる
    • チュートリアルには無い機能も大きな機能には実施している

雑感

  • 品質保証は探索的テストだけでは無理そう
  • 従来の品質保証としてのテストフェーズは必要となりそう

KPTが出なかったチームを自己組織化に近づけたふりかえり改善事例

15:50~16:20

yahoo株式会社 パーソナルカンパニー メール本部
川鯉光起氏

聞きたい内容

  • KPTの話を聞きたい

問題発生

  • 毎スプリント計画どうりに終わらない
  • ふりかえりで意見がでない

ふりかえり改善

沈黙

問題
- 発言が出ない
- 改善案が出なくて改善ができないのでふりかえりをやめようとか言い出す
- KPTが出ないとふりかえりができない

対策
- 大切なのは相手の環境や対場を理解すること。
- 批判や提案は後回し

チームを観察して、チームが困っているであろうことを探しだす
- チームに響く内容の問題を提案する方がよい

世の中一般のやり方を積極的にシェアしていく

結果
 ふりかえりの時間に例示をして話すハードルを下げた
 チームにTryを提案するハードルを下げる

費用対効果のよいものからやろう

問題が大量に出るようになってしまい、ふりかえりの時間が非常に長くなった

原因
 問題が大量
 それぞれに改善案を考えるので時間がかかる

対策
 問題と改善案を同時に考えるのを辞める
 みんなで問題の優先順位をつける

結果
 チームが費用対効果の高い問題から解決するようになった

表面的な問題の解決

問題
 毎回同じような問題が起きる

原因
 根本的な解決をしないで表面的な問題のみを解決してる
 同じことを繰り返す

対策
 問題の深堀
  どうして起きたのか?
 問題の整理
  カテゴリ分け
  抽象化

結果
 チームで根本的な原因を見つけられるようになった

自分ではどうにもならない問題

問題
 根本的な原因がチーム外にある
 偉い人がきめたこと

原因
 なにもできないと思ってる

対策
 ボトルネックをスコープの内にする提案
 無理だと思うことの対策を考える提案

結果
 チームが問題解決を考える前向きなマインドになった

まとめ

相手の立場を理解する
うまくいかないコンテキスト探しは大変
事前に仕入れて解決案をストックしておく

QA

  • 注目した観察点

    • チャット内でのネガティブな話
    • 残業
    • スクラムでの理想とされるチームとの差分
  • 毎スプリント計画通りに終わらない

    • 大きな粒度でみつもりをしていたのを細かな粒度でみつもるようにしたら改善した
  • 例示をあげてハードルを下げるの具体例

    • 具体的な見つけた案を恐る恐る言ってみる
    • ○○さんが残業続いてるけども大丈夫なんすかねー?みたいな
  • スクラムマスターがガリガリと改善をしてくモチベーション

    • 社内の憧れている先輩
    • 改善すると社内のすごい先輩が誉めてくれる
  • ふりかえりで工夫したことはなにかあるか?

    • 今回の発表内容を実施した
    • お菓子を食べながら
    • 空気がよくなるようにした
    • ケーキ買って食べながらやった

雑感

  • スクラムマスターを月ごとに交代は面白い試み。自分たちでも取り入れれそう
  • 相手の立場を理解する。チームを観察するってのは大切

アジャイル開発標準化という立場からのアプローチ

16:30~17:00

SBS株式会社
小林信氏

資料公開予定

聞きたい内容

  • 標準化について聞きたい

掴み

よいものを作り上げたい
 それを体現できるのがアジャイル

標準化という仕事

標準化チームがプロセスをつくって開発チームが使う
策定のためにステップを踏んだ

  1. 叩き台としてプロセス策定
  2. 試行錯誤
  3. プロセス改善
  4. 実開発

プロセス策定

  • スクラムとXPをベースにした
  • 実施する会議体、参加者、やり方を定義
  • 企業文化・体制の取り込み
  • 自動テスト環境、使用ツールの提示

施行開発

定義したプロセスで開発実施
スクラムマスターとして参加
失敗した

たどり着いた自分の答え

  • チームメンバが消極的で各イベントでの動きが鈍かった
    • 各々がチームに対して働きかけ、自己組織化する

自己組織化
 コントロールの分散化
 変化する環境へ継続的な対応

 サーバント型のチーム
  リーダー メンバーが自発的に働けるようにサポートする
  メンバー やりたい気持ちで行動する
       言われる前に行動する
       工夫しようとする

アジャイル開発をするにはチームのメンバーを長期的かつ継続的な教育が不可欠
 アジャイル開発者は幅広いスキルが必要

ウォーターフォールでもできる。アジャイルんい繋げる日々のと陸い

野望を持った旗振り役が必要
どうしてそれが必要なのか考える
助けてくれたら「ありがとう」を伝えよう

取り入れたプラクティス
 デイリーミーティング
 ふりかえり
 プランニングポーカー

デイリーミーティング
 アイスブレイク

ふりかえり
 実施タイミング:各工程の1本目が終わったとき

プランニングポーカー
 WFだとリスク高い

アドバイス

「利用者にとって価値のあるシステムを作り上げる」という原理原則を意識する

アジャイルソフトウェア開発の12の原則
リーン7つの原則

メンターを作る

 ホスピタリティ理論
 TOC(制約理論)
 SECIモデル

アペンディックス

QA

標準化は必要なのか?
 大きな枠組みとしての標準化は必要だけども、標準外のことをやることも大切
 標準化はレール。アジャイルは復車線。

ユーザー企業の期待値は何?
 ユーザー企業の期待値はアジャイル開発という言葉が一人歩きしてたので統一見解を作りたかった

チームへの意識付け
 意識付けが手抜きになっていたので失敗した
  言われたからやっている感がぬぐえなかった

タスクの定義を網羅的にする方法
 オブジェクト指向の考え方ができないと網羅的にあげるのは無理
  タスク分割するには基礎的な技術力が必要
 テスト自動化


組込製品開発組織でのアジャイル実践への道のり

17:10~17:40

DADベースのアジャイル開発プロセスの構築と実践
株式会社東芝 インダストリアルICTソリューション社
IoTテクノロジーセンター プロセス・品質技術開発部
石井裕志氏

聞きたい内容

  • 組み込みでの事例が聞きたい

東芝での事例

リリースサイクルの向上が求められる
モノを作ってみないと良し悪しがわからないプロダクトが増えている

導入障壁

組織として守らなければならない文化・制度
 品質保証の体系
 事業戦略
 既存資産の活用

複雑な利害関係
 それぞれの関係者を説得するのが難しい

CSM(認定スクラムマスター)

導入事例

プロセス構築
試行プロジェクトへの教育
プロジェクトでの試行
ふりかえり

背景
 組み込み製品のSWとそれを用いたシステム製品
 現在クラウドや携帯端末との連携が求められる

課題
 初期段階で要求を固めるのが難しい
 設計フェーズ以降の着手が遅れがち
 協力会社からアジャイル開発が求められた

目的
 設計、コーディングの着手遅れを減らす
 テストに時間をかける

プロセス構築

既存の品質保証体系とアジャイルのプロセスが合わないことが判明
DAT(Disciplined Agile Delivery)
 アジャイルをスケールアップするためのフレームワーク
 3つのフェーズを定義
 初期計画のフェーズが充実

方向付け
 プロジェクトがアジャイルで実施できるのか判断
  アジャイルでやる目的があるか?
  前提条件を満たすか?
  プロジェクト特性をもとにしたアジャイル開発適合性評価手法
 プロジェクトの計画立案
構築
移行
 従来の品質保証体系

プロセス構築の方法

プロセスの検討WGの開催
 隔週で半年
 参加者:設計、品質保証、支援メンバ(アジャイル)

教育フェーズ

参加者:プロジェクト関係者全員
目的:アジャイル・スクラムベースの仕事の進め方を理解する
体験演習5時間

アンケート結果
 ふりかえりに期待
 課題の早期発見
 スプリントレビューで適宜確認できる
 工数が増えないか心配
 変更要求の押し付け
 追加要求の増加

プロジェクトでの試行

捲土重来
成果物の受け入れ可否判断
マイルストーンレビュー
 プロセスがちゃんと回っているかのレビュー

スプリントレビュー

デモ・単体テストの結果確認
ふりかえり結果の共有
結構時間がかかった
 3~4時間かかった
 仕様確認とかもやってた

バージョンアップチャート

プロダクトバックログを適宜調整

審査会

上長がでてくる
バックログ、バージョンアップチャートを使った

ふりかえり

進捗確認がやりやすかった

プロダクトバックログの粒度が難しい
出張等で連絡がつかないとスケジュールが遅れる

進捗確認に効果があると感じた
要求の管理はしやすいが、初期の粒度に基準がほしい
スプリント期間中の品質可視化ができた

雑感

教育フェーズをきちんと利用できるかが勝負になりそう


ふりかえり

17:45~18:00