しるろぐ

いろいろ書きます。

GREE Tech Talk: GitHub:E Casual Talk に行ってきた #greetech02

勉強会

2013年1月23日に開催されたGREE Teck Talk #02 : GitHub:E Casual Talkに行ってきたのでメモ。

全体の感想

ちょっと導入を考えていたので、勉強になった。そして、ちょっとくじけた。

PullReqとかGHEの恩恵とかを理解していれば全然高くはないと思うんだけど、最初の導入時のハードルがでかいかなという印象。今のままでいいじゃん、って声が多分たくさんあがる。お金さえあれば、「まあまあ、試しに使ってみてよ」ってのんびり検証しつつ徐々に移行とかできそうだけど、そうでないなら、ちゃんとした計画立てないとつらそう。

ということで、本気で人やプロジェクトが多くなって「レビューつらい」と思うまではちょっと待っても良いかなという結論に落ち着いた。


19:00 トラブルシューティングから見るGitHub:E運用の勘所

グリー株式会社 大場光一郎

内容と感想

greeがたくさん苦労したからみんな楽してるんだ！という話。
一人あたり$20/monthぐらいなのでコーヒー二杯分（帝国ホテル）ですね！これっぽち払えない会社なんて！


19:20 GitHub:Eじゃなくてもいいじゃん

株式会社ドリコム Takafumi ONAKA

内容と感想

subversionからのGHEはさすがに厳しいので、まずは無料のgitlabで肩慣らししてる。でも、お金があったらGHEで問題ないよ、という話。

たしかに、subversionからgitは色々使い勝手違うし、暗黒時代の便利ツール群なんかも使えなくなるので、厳しそう。gitlabはrails詳しい人が社内に多ければいいかなーとも思うけど、gitlabメンテナンスのコスト考えるとGHEでいいんじゃねって気がする。

PullReq文化 VS お金というのは、すごい分かりやすいけど、PullReq文化に慣れてない人にどう文化を広めるかが大変そう。そこを、ドリコムはgitlabで文化浸透させてるみたいだけど、他の方法としては、なんかうっかりしちゃっても問題ないやつをgithubのプライベートリポジトリで運用して慣れさせるのもありかなって思った。文化広めるだけなら。

資料


19:40 GHEとAWSと私 クックパッド

クックパッド株式会社 高井直人

内容と感想

githubを使わないのはセキュリティ上の理由と、落ちたら困るから。
でも、開発者が増えてレビューが辛くなってきたのでPullReqしたいよねっていうのでGHE導入を検討。
今の運用とできるだけ変えたくないので、開発環境と自社のgitサーバーの間にGHEを入れて、GHEにデプロイはgitサーバーからにすることでGHEが落ちてもデプロイだけは出来る状態にしたという話。

Chrome拡張でfavicon変えてミスしないように、というのが面白かった。大事！

資料

20:10 なめらかにGHEに移行する方法

株式会社はてな Yohei Fushii

内容と感想

リポジトリが多いし、一気に移行すると混乱するのでなめらかに移行したい。
GHEと自社のリポジトリをミラーリングして、どっちを利用しても自社のリポジトリにはすべてのプロジェクトがある状態を保った、というのはクックパッドに似てる。

スライド

20:30 ペパボでのちょっと変わったGitHubの使い方

株式会社paperboy&co. Gosuke Miyashita

内容と感想

ペパボでの GitHub の使い方 - Gosuke Miyashitaとほぼ同じ内容。

ペパボはGHEじゃなくてgithubでサービスごとに組織アカウントを持っているらしい。
デザインプロセスの共有に使用するのはイイナと思った。
質疑応答で、デザイナはどうやって使ってる？という質問があったが、コマンドラインを使ってるらしい。すごい……。

ちなみに、当日の朝、GHE導入が決定したらしい。


20:50 GitHub:e運用錬金術!?

株式会社ディー・エヌ・エー 吉田拓真

内容と感想

「無理矢理書き換えて」「えっ」

スライド


21:10 特別講演：GitHubEnterprise

GitHub Inc. Drew Woods

内容と感想

次のリリースの内容とか。
どれぐらいのスペックがあればいいのさ、という質問があって、金と相談ではあるけど、最低メモリ8GB（可能なら16GB）でディスクIOは大切。CPUはさほど重要じゃないよという回答。あとは、ルートパーティション満杯にならないように気をつけてねとのこと。


参考

#cross2013 で継続的サービス改善について話してきました

勉強会

エンジニアサポートCROSS 2013の「継続的サービス改善のゲンバのハナシ」というパネルディスカッションに参加してきました。

実はこういうイベントで話すのは初めてで、すごい緊張してしまい、質問に答えるだけでいっぱいいっぱいだったのですが、何かひとつでも参考になる話ができていれば嬉しいです。
セッションオーナーの@tagomorisさん、一緒に登壇した@kentaroさん、@oranieさん、@tokorotenさん、ご来場の皆様、ありがとうございました。

話した内容

質問は結構範囲が広かったので、簡単にまとめづらいですが、一言でいうと「ユーザをちゃんと見る」ということを中心に話していました。サービス改善に限らず、集団でプロジェクトを動かすと、政治的なしがらみとかいろいろ面倒なことがあると思います。そんな中でプロジェクトの方向を定める一番の指標はユーザです。ユーザに価値を提供できるか、ユーザの問題を解決できるか、ということを考えれば、自ずと改善マインドが育って、継続的なサービス改善につながるんじゃないかなと思います。

サービス改善と聞いて何を思い浮かべるか

そんなわけで、ぼくがサービス改善と聞いて最初にやるのは、ユーザ目線での不満の洗い出しと解消です。自分たちのサービスは自分たちが一番使っていると自慢できるぐらい使い倒して、元々そのサービスが提供したかった価値がきちんと提供できているかというのを確かめます。その上で、企画者が考えるユーザ体験と、実際のユーザ体験との差を埋めるようにサービスを改善していきます。もちろん、ユーザ体験が大幅に違う場合は企画自体の見直しも視野に入れます。

また、これは個人的な好みなのですが、とにかく早いサービスが好きなので、表示速度の改善は常にやります。どこが遅いのか調べていると、サービス全体を触ることになるので、不満の洗い出しにもちょうど良いです。

サービス状況の把握

ユーザを第一に考えるにはユーザの声を拾う必要があります。自分が不満に思うところを解消、というのはある程度は良いのですが、一定の改善ラインを超えるとあまり役に立たなくなります。

ぼくがやったことをあげると、ページ速度の改善については、それ専用の社内サービスみたいなものを立ち上げて、だれでも、すべてのサービスの表示速度・SQLの実行速度を確認できるようにしました。これは週に一度レポートメールを送るようにしています。「だれでも」というのが重要で、ページ速度の改善は理解されにくく、「そんなことしてる暇があったら新しい機能を」みたいな返答をされたときに突きつけるためです。二月ぐらいデータ取ると、このページが徐々に遅くなってるねーとか、この新しく入ったクエリ遅いねーとかいろいろな発見があって面白いです。

ユーザの声については、ソーシャルメディアや某巨大掲示板の発言をIRCに流すようにしました。昔はユーザの声を拾うにはユーザ座談会やアンケート、お問い合わせぐらいしかありませんでしたが、最近は便利ですね。リアルタイムに情報が流れてくるので、不具合の発見につながったり、ユーザからの良い評価でモチベーションがあがったりして大変よろしい。弊社はIRCがあるのでそれに流していますが、そういったコミュニケーションツールがない場合は、それ用の社内サービス作ったり、メールで社内orプロジェクト全員に送ると良いんじゃないかなと思います。こちらも、だれでも見れるというのが重要です。

エンジニアと営業企画との対立


まーこの通りなんですが、立場ごとに向いている方向が違うと、意見が対立してしまったりしますが、ユーザを中心に考えれば対立なんてしないんじゃないかなーという考えです。もちろん、ユーザのためになるから一週間かかる作業を今日中に作ってよ！みたいなことを言われたら突っぱねますが、そういった時間的、物理的な問題じゃない限り、「なぜこうしたいのか」「それはユーザにどんな価値を与えるか」ということをしっかり話せば、案外スムーズに話がまとまるもんです。
弊社の場合は、「残業ありきのスケジュールを切らない」というモットーがあって、時間的な問題はないです。技術的な問題については、コストに対して効果はどうか、ということが主な判断基準になります。
「そんなこと言ってもうちの部長は！」みたいな場合は、上に書いたとおり、ユーザの声を武器にしましょう。

ユーザからの無茶なお問い合わせ

とは言っても、ユーザの言うことを全部聞けってことではなくて、そこはサービスの目的であったり、全ユーザのことを考えて、判断をする必要があります。
@tokorotenさんがフォードの話を例に出していましたがその通りで、ユーザは自分で自分の要望を分かっていないことが多々あります。そんなときに、力を発揮するのがユーザビリティ調査であったり、データ分析です。

改善案の提案と評価

改善案があるけどそれを許してくれない場合はどうしたら良いかというと、ひたすら啓蒙活動をしつつ、裏で作っちゃう、というのが一番楽です。実際に動くものを作れるというのがエンジニアの強みなので、そこを最大限に生かしましょう。

ぼくの場合は、日報であったり社内ポータルにいろいろ書いたりしつつ、diffを差し出して、「こういう理由でこんな変更を入れたいです」と言っています。だた、セッション中に「理想郷だ」と言われた通り、弊社は結構エンジニア的には恵まれているほうで、自分の意見が通らないということがあまりなくて、ちょっとよく分からないです。

今のところ、そういうようなことはないですが、もし駄目だと言われたら、「何かあったら全部自分が責任追うので、せめてA/Bテストだけでも！」と頼み込んで結果が思わしくなかったら静かに会社を去る覚悟です。逆に言うと、改善する場合はそこまでの自信（とそれを裏付けるデータ）が必要なんじゃないかな。

という意見がありましたが、もちろん誰にも知らせず変更するのはダメ！絶対！

改善と失敗

というのはちょっと言い過ぎな感じはありますが、

失敗したところでやめてしまうから失敗になる。
成功するところまで続ければ、それは成功になる

という松下幸之助の名言がありますがそれと同じで、継続的にサービスを改善するということはそういうことです。PDCAサイクルを常に回すことで、改善し続けるというのが重要です。評価をどうするかという話については、いろいろあると思いますが、上に書いたとおり、ユーザの声であったり、アクセス解析や表示速度などのデータ分析です。

サービスの立ち上げと運用

ページ速度の分析サービスを作ったときに、ただ作るだけじゃ利用されないなと思って、レポートメールの送信日にあわせて「負荷分析ミーティング」というのを開催し始めました。毎週金曜に時間をとって、各プロジェクトから最低1名参加を義務づけた勉強会です。内容としてはレポートメールを見ながら、すべてのサービスについてどう対策を取るか話し合ったり、先週のアクションプランを実施してどう改善されたかというのを話し合う会です。
運用を考えた開発をしないと、ここで苦労することになるので、運用に優しい開発ができます。

まとめ

ということがうまく伝わったかは分かりませんが、聞いていただいた皆様ありがとうございました。
他の登壇者の方と比べると、言葉に詰まっていたりしてお聞き苦しいところがあったかもしれませんが、こんなことを言ってました。

togetterにセッション中の発言まとめを作りましたので参考にしてください。
CROSS2013 「継続的サービス改善のゲンバのハナシ」 #cross2013 #cross2013a

最後に、発表の機会をくださった@tagomorisさん、エンジニアサポートCROSS 2013 実行委員会の皆様、ありがとうございました。

おまけ

Evernoteを有料版に変えてみた

雑記

年末に名刺の整理をしようと思って、「Evernoteで管理するのが良い」というのをどこかで読んだ気がして試してみた。

Evernoteを使った整理の方法としては、ScanSnapと組み合わせるのが良いらしい。
ただ、今回はScanSnapをそのために買う余裕もないので、EvernoteのiPhoneアプリで代用してみた。

Evernoteの使い方: Evernoteアプリだけで名刺・書類を快適にスキャン・管理する。 - たのしいiPhone！ AppBank

試してみたところ、スキャン機能はいい感じに名刺を切り取ってくれて便利。……なんだけど、一個だけ問題があって、画像のサイズが調整できない。
調子にのって次々と名刺をあげてたら50枚を過ぎたあたりで「容量危ないよ！」ってEvernoteに注意された。

¥4,000/年でプレミアム会員に

で、悩んだあげく、有料プランにアップグレードしてみた。

プレミアム会員になる主なメリットとしては、次のような感じ。

  • 月当たりのアップロード容量が60MBから1GBになる
  • ノートの変更履歴が見れる
  • ノート1つあたりの容量が25MBから100MBになる
  • PDFファイル内が検索できる

詳しいことは、Evernoteのサイトに書いてあるのでそちらをどうぞ。

各種サービスとの連携

有料プランにしたらすごい余裕出てきたので、いろいろなサービスと連携してみた。

他にもおもしろいものがあればいろいろ連携してみたい。
別に連携しなくても良いなと思ったら解除してノート消せば良いだけだし。

有料プランにして良かったなーと思うこと

余裕ができた

そんなに使い込んでいたわけではないけれど、いつ容量オーバーになるかひやひやすることがなくなった。
ウェブクリップも容量が怖くて使ってなかったんだけど、気にせず使うことができるようになった。
上にちょっと書いたように、Evernote連携系のサービスも「とりあえず」試してみるっていうのができるようになった。

Twitterのお気に入りを使うようになった

TwitterのつぶやきをEvernoteに自動保存
Twitterでのあなたのツイート、ダイレクトメッセージ、お気に入り、リツイートをまとめて毎日Evernoteに配送します。配送されるツイートの種類は管理画面で選択することができます。

http://twieve.net/

ツイエバに登録したのは、自分の発言をあとから検索したいなと思っていたからなんだけど、どうやらお気に入りも一緒に配送してくれるらしい。

お気に入り機能は月に一回ぐらい思い出したように使うぐらいだったけど、Evernoteに保存されるのが楽しくて、お気に入りする回数が増えた。
特に、気になるTweetや自分のTweetに関係するものをお気に入りしておくと、あとから読み直したときに、そのときのTLの様子とか会話とかが何となく伝わるので嬉しい。

読んだエントリをはてブするようになった

会社とかで「こういうエントリ見かけたよ」みたいな話をよくするんだけど、URLを忘れることがよくある。悔しい。で、忘れないようにはてブでブクマしていて、はてブは主に、そういう後から人に教えるかもな的なものとか、Twitterに投稿したいなというものを登録する専用のサービスとして使っていた。

ツイエバに登録して2週間ぐらい運用していると、もちろんはてブから投稿したTweetも一緒にEvernoteに保存されるわけで、読んだエントリがあとから検索できるのっていいなーと思うようになった。
だからと言って、読んだやつを全部Twitterに登録すると毎日のTweet数が100とか200になってしまうのでどうしたもんかなと思ってたら、はてブ自体がEvernote連携の機能を持っていたのでそっちを使うことに。

Evernoteとの連携機能をリリースしました - はてなブックマーク日記 - 機能変更、お知らせなど

まだテスト段階だけど、読んだページ（であとから見たいor検索に引っかかったら何かいいことあるかも的なページ）を一通りブクマする予定。

有料プランにして失敗したなーと思うこと

特にないです！
まー基本的に無料より有料が悪いということはないので当たり前か。年4000円もそこまで高い気もしない。

まとめ

Evernoteまだひたすら保存するだけで全然活用できていない気がするけど、ログ溜まるの見ていて面白いしイイヨ。

名刺……？　そういえば整理してない。

2012年と私

雑記 スライド

会社の忘年会議というイベントで、今年の振り返りをしました。

忘年会議は、弊社のエンジニアが中心となって毎年仕事納めの日の夜に開催しているイベントです。夜通しお酒を飲みながら、それぞれが今年を振り返る発表をします。参加は任意ですが、参加者は発表が必須となっています。

ぼくは2年目なので、今回が2回目の発表でした。
去年は、通勤通学時間とか、読書量とかtweet量が学生のときと比べてこんなに変わったよ、みたいな発表をしました。今年もそれ系の計測ネタを発表しようかなと思ったら、わりとガチな計測になってしまって、LTどころじゃない量になってしまったのが反省点。

スライド

発表内容

今年の8月から、timenoteというアプリで、時間トラッキングをはじめました。

こんな記事も書きました。

で、そのアプリで計測した項目のうち、5つを選んで、去年と比べてどう変わったか、みたいな発表をしました。
もちろん、去年は計測していなかったので、時間の比較はできませんが、読書数や、ブログのエントリ数などを比較しています。

読書

去年と比べると、平均的に読書ができました。
数年前から「年○冊読む！」みたいな目標を立てていて、去年は目標達成のために読む、みたいなことをしていました。今年はあまり気にすることなく読むことができたので、だいぶ読書が習慣化できたかなーと思います。

多読したいわけでも読了数を増やしたいわけでもないので、そろそろ年間の目標は作らなくても良いぐらいにはなってきました。もし来年目標を立てるとしたら、「人に薦めたくなるような本を○冊見つける」みたいな質を重視した目標になると思います。

おすすめ本はいろいろありますが、できるだけジャンルばらけるようにピックアップしました。

万能鑑定士Qの事件簿 I (角川文庫)新人諸君、半年黙って仕事せよアイの物語 (>角川文庫)
今すぐできる>「戦略思考」の教科書 ビジネス本を何冊読んでも身につかない人のためのバナナの世界史――歴史を変えた果物の数奇な運命 (ヒストリカル・スタディーズ)はじめての構造主義 (講談社現代新書)

万能鑑定士は「今更かもしれないが「万能鑑定士Qの事件簿」を読んだほうがいいよ #男色系男子」を読んで、面白そうだなと思って読み始めたのですが、予想どおり面白くて、今第二シーズンを読み始めてます。事件簿シリーズは全12巻です。

映画

映画は10月に「土日に一本ずつ見よう！」と決めてからの追い上げがすごいですね。
4-6月の映画数が少ないのは、3月にTSUTAYA DISCASからhuluに乗り換えて、ドラマを見始めたからです。
9月までにどんな動画を観たかは、

に書いてあります。


それ以降に観たやつではダントツに「罠にかかったパパとママ」または「ファミリーゲーム/双子の天使」が面白かったです。
このふたつは、「ふたりのロッテ」という児童文学が原作です。前者は1961年、後者は1998年に公開されています。
古いほうを先に見て、「あれこれリメイクされてるんだ」と連続で新しいほうを見てしまって次の日の仕事が辛かったです。


ファミリー・ゲーム [DVD]
posted with カエレバ
デニス・クエイド ブエナ・ビスタ・ホーム・エンターテイメント 2005-12-21

インプット

たんにRSSリーダーをながめていた時間を計測しただけなのですが、最近は、

のようなtwitterから良い感じにリコメンドしてくれる君の精度があがってきて、RSSリーダーから徐々に移行してます。

確実にこのサイトはウォッチしたい！という欲求はなくならないので、RSSリーダーはなくならないなと思いつつ、ニュース系は全部リコメンドにおまかせしちゃっていいなーという気がしています。

アウトプット

かなり社内ポータルや社内勉強会を頑張っていたようです。
アウトプットしている内容は、社内システムの中身的な話だったり、社外の勉強会のフィードバックだったりするので、外部では発表できないですが、もうちょっと外にいろいろ公開したいなーと思って、5月にブログ作りました。
まだまだ、更新もアクセスも少ないですが、三日坊主にはならなかったので、これからも継続的に更新したいです。

技術的なメモはこっちにまとめてます。

勉強

今年はいろいろな勉強会に出席したようです。
来年はどうも登壇側の人間になるようで、勉強会の雰囲気に慣れようと思って、11月、12月にたくさん出席しているのが涙ぐましい。

全部ではないですが、いくつかの勉強会は、感想（や内容）をブログに書いています。

まとめ

というわけで、読書、動画、インプット、アウトプット、勉強という項目を計測して去年と比較してみたというお話でした。

来年も引き続き計測して、今年と比較したい。
アウトプットが多くなっているといいな。

ロールオーバーのいろいろなやり方

勉強会 スライド

ちょっとした勉強会で発表することになった。

テーマは『スマホでタップしたらボタン変わるのどうやってるの？なんかjQuery使ってるぽいんだけど教えて』らしい。すごいピンポイント。困る。

資料はなしで、適当にホワイトボード使ったり、ネットに転がっているサンプル見ながら話してねと言われたけれども、いちいちホワイトボードに書くの面倒だし、説明に適したデモをネットで探すほうが手間な気がしたので、話に必要そうなソースをぺろっとはっておく。
たまたまググったら自分のブログが引っかかってしまった体で。


調子に載ってスライドまで作ってるけど、「やさしさゴシック」を使いたかっただけで中身はすっからかんなので見なくても全然問題ない。
このフォントのやさしさあふれてる感半端ないのでまた使いたいな。


話すこと

テーマがちょっとピンポイント過ぎるのでもっとざっくりした話をしたい。

ということで、『ロールオーバーの色々なやりかた』みたいな感じの話をする。


まず最初に思いつくこと

まず最初に「ロールオーバーしたい」って言われて思いつくのはこれだと思う。
on, offの画像(300x100)を縦に並べた一つの画像(300x200)を用意して、背景画像として表示。テキストはtext-indentで逃がしつつ、疑似クラス::hoverで背景画像positionをずらしてる。

HTML:

<a href="#" class="hoge">link</a>

CSS:

.hoge {
  display: block;
  width: 300px;
  height: 100px;
  background: url('hoge.png') no-repeat 0 0;
  text-indent: -9999px;
}

.hoge:hover {
  background-position: 0 -100px;
}

ただ最近は

-9999pxが無駄に領域確保するからパフォーマンス悪いという話があって、

  text-indent: 100%;
  white-space: nowrap;
  overflow: hidden;

とか

  height: 0;
  padding-top: 100px;
  overflow: hidden;

みたいに画像置換するのが増えてきている。

ほかにも

「CSSをONにしているけど画像をOFFにしていると何も見えない」みたいな文句を言う人がいて、それに対抗するために、

HTML:

<a href="#" class="hoge"><span></span>link</a>

CSS:

.hoge {
  display: block;
  position: relative;
  width: 300px;
  height: 100px;
}

.hoge span {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  z-index: 2;
}

みたいにz-index使う方法もあるけど、空spanが気持ち悪いよねーという意見が多い気がする。

ちなみに

display:noneを使う方法もあるけど、音声ブラウザで読まれないのでナシ。

HTML:

<a href="#" class="hoge"><span>link</span></a>

CSS:

.hoge {
  display: block;
  width: 300px;
  height: 100px;
  background: url('hoge.png') no-repeat 0 0;
}

.hoge span {
  display: none;
}

　

次に思いつくこと

そもそも、スマホ対応とか考えると画像はできるだけ使いたくないし、ある程度の画像ならCSSでがんばれる。
ということで、背景画像をやめてみる。

HTML:

<a href="#" class="hoge">link</a>

CSS:

.hoge {
  display: block;
  width: 300px;
  height: 100px;
  /* 良い感じにフォントをデザインすること */
  font-size: 64px;
  text-align: center;
  text-decoration: none;
  /* ボタン自体も良い感じにする */
  /* border-radius, linear-gradient, box-shadowなど */
}

.hoge:hover {
  /* 良い感じに表示を変える */
}

本気でスマホに対応させる場合

iPhoneやAndroidはデフォルトでタップしたリンクをハイライトしてくれるので、それを消してあげる。

a {
  -webkit-tap-highlight-color: rgba(0, 0, 0, 0);
}


次に、指を離してもhover状態のままだったり、ページを戻ったときにhoverのままだったりする端末があるので、疑似クラスを使うのをやめる。

.hoge.hover {
  /* 良い感じに表示を変える */
}

で疑似クラスではなくクラス名に変えて

$('a')
  .on('touchstart', function(){ $(this).addClass('hover'); })
  .on('touchend',   function(){ $(this).removeClass('hover'); });

のようにjsでクラス名をあてたり消したりする。


最終結果

ということで、今までのもろもろを考えると、こんな感じになるのではないかなー。
もっとイケてるやりかたあったら教えてください。

HTML:

<a href="#" class="hoge">link</a>

CSS:

a{
  -webkit-tap-highlight-color: rgba(0, 0, 0, 0);
}
.hoge {
  display: block;
  width: 300px;
  height: 100px;
  /* 良い感じにフォントをデザインすること */
  font-size: 64px;
  text-align: center;
  text-decoration: none;
  /* ボタン自体も良い感じにする */
  /* border-radius, linear-gradient, box-shadowなど */
}

.hoge.hover {
  /* 良い感じに表示を変える */
}

JAVASCRIPT:

$('a')
  .on('touchstart', function(){ $(this).addClass('hover'); })
  .on('touchend',   function(){ $(this).removeClass('hover'); });

スライド

Tap App Seminar に行ってきました #tapapp

勉強会

TapAppプロジェクトの一貫として実施されたTap App Seminarに行ってきました。
どこで知ったのか覚えてないんだけど、受付票見たらどうも8番目に応募していたらしい。
TapAppプロジェクトは、雑誌Web Designingでの全4回の連載、今回のセミナー、1/15応募締切のアワードが云々で、詳しくはTap App Awardsのサイトを見てください。

セミナーは、PARTYの中村洋基さんの基調講演に始まり、

  • スマートフォンWebアプリ最適化”３つの極意”
  • スマホコミュニティサービスの創りかた
  • アドビがオススメしたいWeb技術のスマホアプリ開発
  • WebアプリのUIレシピ

で、最後に懇親会という流れでした。

以下、メモと感想。


インタラクティブ基調講演 ～アプリアイデアとの正しい出会い方～

中村洋基さんの基調講演。最近どんな仕事をしたかとか、どのようにアイデアを生み出すかという話。


スマートフォンWebアプリ最適化”３つの極意” ーストレスフリーのスマホコーディング術ー

石本光司(@t32k)さんによるパフォーマンスの話。そのうちスライド公開されるかなーと思ってあまりメモ取ってない。

なぜパフォーマンス？

パフォーマンスをあげるためのツール

  • mobile boilerplate
  • sass/less, coffee script
  • backbone.js
  • codekit, sublime text
  • chrome developer tools
  • grunt

スライド


　

スマホコミュニティサービスの創りかた ーユーザをハマらせるためのサービスデザインー

サイバーエージェントの開発者4人（下山航平、熊切剛、鬼石広海、見上楓）によるパネルディスカッション的なやつ。リアルタイム意訳しながらのメモなので間違えていたらごめんなさい。
あと敬称略です。

コアターゲット層に合わせた世界観の作りこみ

下山
パシャペはどんなターゲット？
熊切
ペット飼っている人がターゲット。20から35歳の女性がメインだったが、少し上の方にも使ってもらっている。また、ITリテラシーが高くないというのも意識している → きっちりと説明をしてあげる
見上
ガールズトークは、20代後半から30代。18歳未満は利用不可。仕事も恋愛もやってきた女性がターゲット。割と普通の女性。
下山
UIでこだわった部分は？
見上
ヘッダーの色は、何色も並べて検討した。流行りの色は廃れたらダメなので省いたり、女性だからといってキラキラといったイメージも取っ払った。「みんなに打ち明ける」ドロドロしたものを打ち明けて欲しいので、「投稿」とかにはしなかった。聞く側は「共感」。
鬼石
ゴラクログは、10代から30代の男女で幅広い。そのため、デザインもプレーンなインターフェース。画像を引き立たせるために、それ以外はシンプルにデザインした。
下山
友達年鑑は、スプラッシュ画面に、こんな人に使って欲しいという意味を込めて写真を置いた。
熊切
デザインだけでなく、言葉も大切。

「継続性」と「回遊性」と「ユーザループ」

下山
ゴラクログだとどんなふうに意識している？
鬼石
継続性でいうと、毎日コツコツログを残してもらいたいため、マイページをカレンダーっぽいデザインにした。縦型のカレンダー形式にして、空きが気にならないインターフェースにした。ユーザループでは、感想を書くと、全体のフィードに感想が流れて、パチパチ（イイネみたいなやつ）を目立たせて、親指で押しやすい場所にした。また、パチパチをすると、相手にお知らせが行く。お知らせに「ありがとう」というボタンがあり、コミュニケーションのハードルを下げた。
熊切
パシャペの場合は、写真の上にいいねボタンがある。最初は小さくしたが、調査したところ、あげた日にいいねがつくと、次の日93％、7日後68％の継続率。これがユーザループ。さらにいいね数が4,5倍になった。マイページのアクセスがほとんどなので、タブを使わなくてもマイページからいろいろな情報が見れるようにした
下山
詰め込み過ぎない、というのはよく言われるが、回遊性を考えて色々なリンクを貼る、ということもある。
見上
ガールズトークでは、トップページの一番上にカテゴリ一覧があるが、その下に更新されたトークを載せるようにした。自分が書くとトップページに乗るので、書いた人はテンションがあがる。見る側は、カテゴリに行かなくても、更新されたトークにすぐいける。回遊に関しては、トークの詳細ページから、同カテゴリのトーク一覧や人気一覧に飛べるようにした。

変えていくデザイン

下山
内製なので変えやすい。パシャペはどんなことを？
熊切
最低でも週に一回は変えている。たとえば、お知らせ欄で、写真を大きくしたり、リンク先をユーザのページではなく、写真のページにしていいねをすぐしやすくした。ペットメインなので、ユーザのアイコンだけでなく、ペットのアイコンも表示するようにした。
下山
他にも何か変えてましたよね？
熊切
これはつい最近なのですが、カレンダー形式の表示から変更した。理由は、最初がすっからかんになってしまうのと回遊性が悪くなってしまうため。カレンダー形式だと、ユーザは埋めようとしてくれるので7日間だけ残して、その下は回遊枠にした。
下山
ゴラクログは？
鬼石
ゴラクログではネガティブチェック（ネガティブな意見をひたすら言ってもらう）を行なっている最中。会員登録前にオールフィードが見れるが、興味がないゴラクが表示されると離脱してしまうのではないか？と考え、話題のゴラクとしてユーザが知ってそうなゴラクを表示。

最後に一言

鬼石
半年前に転職したばかり。以前は広告でコンシューマ向けは初めて。革新的なインターフェースを作ろう！みたいなこだわりがあるとユーザが置いてきぼりになる。標準のデザインを参考にして、自分なりのデザインを加えていくのが大事。
熊切
同じく半年前に転職。ユーザがストレスなく使えるか、というところに気をつけないとどんどん離れてしまう。MTGに役員や社長、他のチームも来てかなりオープンにやっている。アメーバのユーザをつかってユーザテストも行えて面白い。
見上
ユーザがどんなシーンで使うかが大事。捨てることも大事。

質問

質問者
前の会社との違いは？
熊切
前の会社だとクライアントがいて、社長がどうたらというのはなかった。風通しがよい。ユーザ目線でのチェックを経営陣がやってくれる。スピード感はかなり早いので改修がしやすい
質問者
AかBかなやんでるけど明日リリースみたいなときはどうする？
熊切
リリース前ならとことん話し合うので、明日リリースであってもとことん話し合う。リリース後だと、データを見て判断する。
質問者
スマホならではのコミュニケーションスタイルがあると思うが、PCとのデザインやってた人から見るとハードルが高いのでは？
鬼石
ぼくは昔PCばかりやっていたが、うーん、縦長というのが大きいですね。スクロールはあまり気にならない。PCはファーストビューを気にするが、スマホはそこまで気にならない。ただ、基本的なところは変わらないのでは？
質問者
マネタイズとUI設計の関係について
下山
マネタイズはアメーバ全体で考える。我々のコミュニティサービスはどれだけ人を集められるか。

　

アドビがオススメしたいWeb技術のスマホアプリ開発 ーマルチプラットフォームを実現しやすい、PhoneGapでのスマホアプリ開発ー

轟啓介さんによるPhoneGapのススメ。Adobeを知るには http://html.adobe.com/jp/ を見てね、とのこと。
PhoneGapはいくつかの勉強会の抱き合わせ的な発表で何度か聞いてはいたんだけど、この発表聞いてすごい触りたくなった。というか触る。
とにかくすごいなー触りたいなーと思わせてくれる発表だった。

背景

  • Flashが得意な人はFlashで作ってもらって、そうでない人はぜひPhoneGapを使ってWEB標準で開発してほしい
  • 複数プラットフォームに対応するには、たくさんの言語を覚えないといけない
  • ひとつのコードで対応できたら素敵

PhoneGapとは

  • PhoneGap is a Wrapper
  • PhoneGap is a Bridge
  • プラグインで機能拡張できるよ
  • jQueryとかbackbone.jsとか他のフレームワークと組み合わせられるよ
  • Apache Cordova と Adobe PhoneGap

ツール

build.phonegap.com
  • SDKがなくてもビルドできる
  • 無料で、1プライベート、無制限でパブリック
  • 最悪テキストエディタだけで作れるってこと
  • debugメニューがあって、リモートでchrome developer toolsが使える
    • リモートで書き換えたりコンソールも使える
emulate.phonegap.com
  • ベータ版だけどそこそこ使える
  • デバイス動かしたりもできる
debug.phonegap.com
  • build使ってなくてもここでデバッグできるよ

Edge Code

  • タグ上でCtrl+E押すと対応するCSSの記述がその場に展開されてそのまま書き換えられる
  • とかとか。すごかった。触りたい。

スライド


WebアプリのUIレシピ

サイバーエージェントの開発者5人（神谷尚志、河合拓也、筒井豊、櫻井瑶子、平木聡）による発表。それぞれのアプリのUIでどんなことを工夫したかという話。
スライドが印刷されて配布されていたのでメモは少なめ。すごい良い資料だったので公開されるといいな。

ストレスを軽減する（天空のクリスタリア）

右下に三角形上に3つのボタンが配置されていておもしろいなーと思っていたゲーム。

  • ユーザの使用環境を把握
    • ターゲット、利用状況
  • 分かりやすいUI
    • ボタンは40-50px。Androidはずれるので余白を取る
  • ユーザが迷わない
    • 次のアクションを伝える、欲しい情報を提供
      • カード所持数とかでやりこみ度を判断して見せ方を変更している
質問
  • わくわく感を、いろいろなユーザにどう見せるか
    • ファーストビューに詰め込めばいいというわけではない。良いカードを見せたり、ヘビーユーザの場合は、自分のイベントのステータスがわくわくポイントなのでランキングとか仲間が負けた情報を表示してあげる。
  • 細かいんですね
    • ヘビーとライトに大きく分けたが、もっと細かく分けられる。初めてすぐの人とか2,3週間の人とか。

動的に変更されるUIのコツ（アルティメットレーサー）

スマートフォンUIのアニメーションについて｜1 pixel｜サイバーエージェント公式クリエイターズブログ
上の記事を読んでおもしろいなーと思っていたので話聞けて良かった。

運良くデザイナの方と懇親会で同じテーブルになって、質問しまくった。ありがとうございます。エンジニアの方ともお話したかったけど、タイミングがあわずに話せなくて残念。

  • 多くの情報を見せるには
    • 1ページに全部のせると、ごちゃごちゃしてライトユーザが離脱してしまう
    • 各情報を細かく分けると遷移が多すぎて迷子になる
  • やった施策
    • ぱっと見の印象をシンプルに
    • 色をしぼってユーザに注目して欲しいところは赤色で
  • どう軽くするか
    • 重くなるJSの書き方はしない
      • liではなくulでイベントハンドリングする（delegateを使う）
    • HTML、CSSでできることはJSでやらない
    • そもそもデザインを簡略化する
      • デザイナさんに、ちょっと要素多いんでなくしませんか
質問
  • 実装可能だけど実装する/しないの判断について
    • 動きと速さの両立。良いアニメーションでも、まず考える。ユーザの利益になるなら頑張るが、そこまで必要じゃないかな？と思えば別の技術を使う。
  • デザイナさんはかっこいいデザインやりたいですよね？
    • デザイナ側でサンプルアニメーションを作って、こんなの作れない？と開発に渡す。デザイナは細かいところにこだわってしまうが、開発側にそれはちょっと、と言われるのでお互いに落とし所を話しあう。

動的に変更されるUIのコツ（天下統一クロニクル）

面白くてメモるの忘れてしまった。マイページのファーストビューのデザインの変遷、みたいな話。

何度もデザインを変更していたのでどんな感じに決定しているのかなーと思って懇親会で聞いてみたら、毎週社長レビュー的なものがあって、その結果でデザインを変更したりするらしい。

よりよいUIのためのデバッグ方法（あそんではぐぺっと）

  • とにかく実機でさわる
    • 手に持って指を置いたときに気づくことも多い
  • 言葉に気をつける
    • ひらがな、漢字の与える印象とか
  • 感想や意見を集める
    • ユーザテスト5人
    • 思考発話法
  • 制作サイクルをたくさんまわす
質問
  • ユーザテストはどのタイミングでどんな人？
    • 新機能追加前にチーム内で触る。
    • リリースされていないゲームだと、部署全体で触る会がある。
  • 外部のユーザを読んで触ってもらうことは？
    • 身内の人に触ってもらうとかはある。

スライド

は、見あたらなかった（一瞬slideshareにアップされてすぐ消されてる）けど、似たような内容の記事があった。

スマホアプリ開発の最前線で使われている、UIデザインメソッド20

2012/11/30追記 スライド発見。

追記

スライドと動画が公開されたらしい。
Tap App Awards｜1 pixel｜サイバーエージェント公式クリエイターズブログ


さいごに

楽しかったです。ありがとうございました。
参加者特典で本が1冊もらえたのですが、「Unityで作るiPhone/Androidアプリ入門」をもらいました。Unity触ろう触ろうと思ってずっと放置していたけれど、本をもらったのでやらざるを得ない！


Unityで作るiPhone/Androidアプリ入門
Unityで作るiPhone/Androidアプリ入門
posted at 2012.11.17
山崎 透,野口 基之
マイナビ
売り上げランキング: 55706
Amazon.co.jp で詳細を見る

#aimingstudy 7 「ロードオブナイツ UnityからHTML化する際のアプリの設計とアジャイル的開発管理の話」に行ってきました

勉強会

前回の勉強会からちょっとしか経ってないのにもう次の勉強会。すごい。

というわけで、Aiming Study 7に行ってきました。

今回も事前にスライドが公開されていたので、メモは少なめ。
質疑応答はスライドに載ってないので、スライドをじっくり読んだあと、「質問」だけ読めば完璧ですね！


UnityのオンラインゲームをHTMLに移植してわかったこと- 設計と作業分担の視点から

移植の経緯と教訓について。

Unity版の開発

  • 当時リッチなゲームが少なかったので、さっと作って出せば勝てるのでは？
  • 使えそうなフレームワーク探してUnityになったが、部分的にHTMLを使用
  • 動くところはUnityで、更新頻度の高いところはHTMLで
    • 連携するネイティブプラグインを書いた
    • トリッキーな実装で後悔
  • コードレビューはgeritを使用

移植の話

  • クライアント側はUnity版と別メンバー
    • Unity版は大きめの開発してて忙しかった
  • クライアント側は別ソース
再利用性
  • Unityで作ったクライアント部分は全部作り直し
  • HTMLで作ったクライアント部分は再利用したが、テンプレートはデザインが変わったので作り直し
  • サーバ側はほぼ再利用

よかった

  • APIは超再利用性高い
  • JSON-RPCもデバッグしやすい
  • 通信設計が仕様書代わりになった

悪かった

  • UnityとHTMLの連携部分がトリッキーだった
  • もともと画面遷移させてたところをワンページアプリでどう実装するか
  • Unity版メンバー不在
    • 後半から入ってスピードアップ

移植の教訓

  • API設計はしっかりする
  • トリッキーな設計はしない
  • コミュニケーション大事

質問

  • 全部のコードをレビューするのは大変では？なにかコツは？
    • メインのレビュアーがいたほうがよい
    • コストはかかるが、変な設計や命名が減って追加コストを減らせるので結果的には良い
  • ペアプロってなにがおいしいの？
    • 仕様の理解度などの知識の偏りがあるときに効果がある
    • 知識が少ない人だけで実装してしまうと、隠れた仕様が抜け落ちてしまう
    • ペアプロにより、知識が共有でき、後々のバグや抜け漏れを防げる
    • リアルタイムコードレビューなので、コードレビューのコストが減る
  • どこらへんがトリッキーだったの？
    • レスポンスをフックしてURLをパースして云々みたいな
  • 次作るならどう作る？
    • Unityが4.0になったらHTMLでやってたこともUnityでできるので全部Unityで作るよ
  • 仕様書をredmineで管理ということだったが、Unityチームと移植チームのでどんな感じ？
    • Unity版の子プロジェクトとして移植プロジェクトを作った
    • 親プロジェクト見れる権限あるので、元々の仕様も見れる
    • 元々の仕様も、目を通した
  • それぞれの今後のメンテに対するメリットは？
    • どうなるかはこれから次第
    • HTML版はリリースまでの期間が短い（10分とか）
    • Unity版は審査があるので10営業日とかかかることも
    • Unityはマルチプラットフォームでさくさく動かせるのがメリット

スライド


大規模JSプロジェクト ロードオブナイツの管理手法紹介

「サムライエピソード」と「ゲームクリエイターが知るべき97のこと」の人。

スクラムマスター的な立場から、移植のプロジェクト管理の話。

黎明期：締め切り最優先になり体制組み換え

  • 全員新宿に読んで常駐化
    • 停止できそうなものを止めて人員確保
    • 技術的素養は違うがとにかく人を増やした
  • 環境整備

ポストイット期：工数わからなすぎる

  • 仕様が変わるので、思いついた端からポストイット
  • カオス化したが続けたのは、チームが前進している感
  • 進捗とかなにも管理していなかった
  • ゴールを決めたが完成しなくて検討がつかないのは変わらず
    • 大ざっぱに見積もったが全然間に合わない
    • 四天王調整
  • 小田レビュー
    • Doneの定義が曖昧だったので小田さんがOKしたら完了
  • ペアプロ表
    • これいいなー。と思いつつ人数多くないと効果無さそう
四天王
  • 時間
  • 予算；Unityメンバー呼ぶ
  • 品質
  • スコープ：IE8を切る

ストーリーカード期：リリース無理っぽいぞ

  • 手っ取り早く定量化したい
    • 大中小で見積り
    • 「全部」を定義できたのはよかった（バーンダウンチャートが作れるので）

Redmine期：リリース前

  • 場所が離れているので、オンラインじゃないと歩調合わせできない
  • リリース直前だと、あのバグなおった？とかが重要になってくる
  • バグの個数を測定
    • これを0にするのが重要

まとめ

  • フェーズによって必要なものは違う
  • 固定的な方法論や指標にしがみつくのは危険
  • 期間内にやることを明確にし、チームのコミットメントにする
  • 進捗を定量化して計測するために最適な指標を考える
  • 開発手法を変更しやすくする土壌を作る

質疑応答

  • 品質を下げる方向にいかなかったのは？
    • 品質落としたら……
    • リファクタリングせずに動いてるから出せ、だとメンテナンスが大変
    • マップをとりあえずリリースしてしまったが、実際に苦労したことがある
    • そもそも品質悪かったらPOがOK出さない
  • 品質の定義に細部の作りこみは含まれているか？
    • YEAH。リリース前の作りこみ期間がなかったことはない
  • モチベーションに関して
    • 納期優先だからとにかく作れはモチベーション下がる
    • テンション高く作れた
    • 移植元のアプリがあるので遊んで、仕様理解、距離把握
  • もろもろの管理方法を変える決定はどうやった？
    • 間に合わないと分かったとき超焦った
    • ペアプロとかSML見積りは自分が提案した
    • みんなの知恵が入ってこうなった
    • 自分はスクラムマスター的な関わりをしたが、「こうやれ」とは言わなかった
      • 自分たちでやってるんだぜ、というのがモチベーションになる
  • スプリントの期間について
    • 2週間は実は会社の中では長い
    • 運用がはじまると1週間じゃないと遅い
  • メンバーとの関わり方
    • チームではスクラムマスター
    • 外部との交渉はゼネラルマネジャー
  • リリース日がすでに決まっていることについてメンバーの納得感は？
    • やるまでわからん
    • とりあえず動いてみよう
  • 朝会夕会等の取り組みについて
    • 朝会＝いわゆるデイリースクラム（なにやるよ）
    • 夕会＝今日こんなことやったよ、残業対策
    • 振り返り＝KPT方式

スライド