Cookpad Tech Kichen #10 〜Product Design Talk〜 に参加してきた
概要
- Cookpad Tech Kichen #10 〜Product Design Talk〜 - connpass
- テーマ: 自社サービスで取り組むデザイン
- ハッシュタグ: #cookpad_tech_kitchen
所感
- 各サービスのデザインに対するこだわりのポイントを知れた
- 手がけた機能の具体例の話が中心で、分かりやすかった
「料理の追体験」を実現するデザイン」
若月 啓聡 - @puzzeljp
- クックパッド株式会社
タイムラインを作った
- つくれぽとレシピがある
- 「自分のフォローしている人が同じ料理を作った」が分かる
- つくれぽを通して、レシピ投稿者とコミュニケーションが生まれる
- 返信がもらえてないものはコメントを表示しない
- 誰が作ったかわかる
- タイムラインについて検証
- 社内インタビュー
- ユーザインタビュー
- ユーザさんの懇親会
- タイムライン上部に利用開始後に意見を送るボタンを設置
「6年続くはてなブログの世界観になじむデザイン」
松井 沙織 - @mazco_dx
- 株式会社はてな
はてなブログ
- しっかりも簡単も
- 書くことを邪魔しないように
- サイドバーの出し分け
- 機能ごとにON、OFF
- 読まれるブログ
- はてなスター
- はてブ
- 6周年
- デザイナー2名体制
- 東京でリモート
- なじむようにデザインする
- 新画面でも、ユーザからすると、体験の延長
- 履歴画面
- 既存のUI
- Dropboxのバージョン管理
- GitHubの差分のUI
- 簡略化しすぎない
- アイコン内に色々格納しすぎないようにする
- 元のデザインから情報整理
- 既存のUI
- 新機能
- こよみモード
- 読み返せるように
- 手帳、日記帳のように
- セリフフォント
- 続けた分だけ、楽しい、嬉しいを可視化する
- こよみモード
- まとめ
- サービスを知ろう
- ちょっとずつ変えていこう
- デザイナー募集中
「温度のあるサービスづくり」
木坂 名央 - @naomeme
- GMOペパボ株式会社
minne
- 国内最大級のハンドメイドマーケット
- ハンドメイド作品を売ったり買ったりできる
- 人の手のぬくもりを伝えたい
- 施策
- こっそり褒める
- 作家に近づく
- こっそり褒める
- 嬉しいタイミング
- 作品がお気に入りされた時
- 売れた時
- …
- 紙吹雪が振るアニメーションでおめでたい演出
- アプリを開いた時にポンと出る
- みんなTwitterでつぶやいてくれる
- 嬉しいことに気づくきかけと、それをシェアするきっかけ
- 嬉しいタイミング
- 作家に近づく
- リアルイベント
- アトリエ
- ものづくり部
- 作家さんを呼んで社内でワークショップ
- より身近に感じてもらえたり、雑談の中からヒントが得られる
- エンジニア募集中
「自然さを追求した音楽体験のためのUX」
冨樫 晃己 - @kokiiiviii
- CyberAgent, Inc. / AWA Co. Ltd.
AWA
- 1350万DL
技術軸でモックアップを複数作った
- こういう見せ方できるよ
- レコード風にジャケットを丸くするとレーベルさんから怒られた
- テーマ
- GAPLESS
- 現実世界にありえる自然な動きにする
- 背景のパララックスで位置関係
- ブラーをかけて後ろにあることを分かりやすく
- …
- GAPLESS
- 音楽認識機能
- 楽曲数が3000万曲を超えたタイミングでリリース
- 認識中のインタラクション
- 水の表現に着目
- 何もできないとストレス
- 音に反応して、波紋が広がる
- 触ることで波紋が広がる
- 周囲の音に反応していることが分かる
- 以前に作っていたインタラクションが活きた
- その場で使えなくても、チームで色々作ってみる
「Airbnb Story」を読んだ
Airbnbの創業ストーリーをまとめた本。ワクワクしながら読めた。臆面なく、度胸を持って、色々なことに取り組んでいきたいと思わせる本だった。
Airbnb Story 大胆なアイデアを生み、困難を乗り越え、超人気サービスをつくる方法
- 作者: リー・ギャラガー,関美和
- 出版社/メーカー: 日経BP社
- 発売日: 2017/05/25
- メディア: 単行本
- この商品を含むブログ (2件) を見る
ストーリーは、美大出身のデザイナーのチェスキーとゲビア、エンジニアのブレチャージクの三人で、赤の他人を自宅に泊めるという奇抜なアイデアを、様々な問題を乗り越えながら形にして、時価総額3兆円の会社にしていく話。
アイデアの奇抜さから、投資家から投資を受けるまでに苦労した話や、ホストの部屋が荒らされたり、既存のホテルや法律との戦いなど、たくさん失敗の経験談が細かく描かれている。
以下、ネタバレを含んでいるが、個人的に印象に残ったエピソードや言葉を書いていく。
シリアル
サービス開始当初、資金不足で継続がままならない時に、大統領選にちなんだデザインのシリアルを作成して売り、後にYコンの面接でシリアルの話が活きたというエピソード。創業時の泥臭さがにじみ出ていて良かった。
のちにグレアムは、例のシリアルが決め手だったと言っていた。「4ドルのシリアルを40ドルで売れるなら、他人のエアベッドで寝るようにみんなを説得できるだろうと思ったんだ。たぶんね」
プロダクトへのこだわり
Airbnbのウェブサイトは、3つのこだわりを持って作られていた。
- 簡単に使えること
- 掲載物件が美しく見えること
- 必ず3クリック以内で予約が完了すること
掲載物件を美しく見せるために、プロの写真家をホストの家に派遣していた。3クリックルールはジョブズがiPodを開発した時に3クリックで楽曲が手に入るようにデザインさせた話から由来している。
このプロダクトへのこだわりが熱烈なファンの獲得に繋がったと思う。
ウィムドゥを買収しない選択
パクリサービスにヨーロッパに先行された時の判断。アツかった。
メイソンは、ウィムドゥがエアビーアンドビーを殺す可能性もあると言った。ザッカーバーグは買わないほうがいいと言う。一番いいプロダクトを持つ会社が最後に勝つ、と。決定打になったのは、ポール・グレアムのひとことだった。エアビーアンドビーとウィムドゥの違いは、エアビーアンドビーの創業者は伝道師で、ウィムドゥの創業者はカネで動く傭兵だということ。たいていは伝道師が勝つ。「自分に賭けた」瞬間だった。チェスキーたちは、ウィムドゥを買わないと決めた。
「ゼロをひとつ加える」
ホストの家が荒らされた時の対応の決定が内部でモメたことにより、和解が遅れた時の話。共同創業者のアンドリーセンがチェスキーの送ろうとした被害者への手紙の賠償額に0を一つ加えたエピソード。
この経験から、チェスキーが学んだのは、コンセンサスで決定するなということだ。「危機のときコンセンサスで決めると、中途半端な決定になる。それはたいてい最悪の判断だ。危機のときには、右か左かに決めるべきなんだ。」それ以来、考え方をひとつ上のレベルに持っていくことを、「ゼロをひとつ加える」と呼ぶようになった。
「文化を壊すな」
チェスキーは文化を壊さないために、日曜の夜に社員向けのメールを送り、社員が300人になるまで、必ず面接をしていた。文化を守ることによって、イノベーションが生まれやすい環境を作るというのは、ベンチャーっぽい考え方で良い。
ティールはただ、「文化を壊すな」と言った。投資した理由のひとつが、エアビーアンドビーの文化だが、企業規模が拡大すればかならず文化が「壊される」、とティールは言う。チェスキーはこれを挑戦と受け止め、以来エアビーアンドビーの文化に執着と言っていいほどの注意を払ってきた。「文化が壊れるってことは、プロダクトをつくる機械が壊れるってことだ」チェスキーはそうブログに書いた。文化が協力であればあるほど、社員を信頼でき、その分正式な規則や手続きが少なくて済む。手続きがすくなければそれだけ管理も軽くなり、イノベーションが生まれやすい環境ができる。
3人だからこそ
ゲビアの言葉がアツかった。この3人だったからこそ成功できたという言葉が、かなり印象的だった。
3人が違っていたからこそ成功できたと彼らは言う。「ひとりじゃ絶対にできなかった。ふたりでもできなかった。ネイトとブライアンと僕の持ち寄るものがひとつになったから、この数年の困難を乗り切れたと思う」とゲビアは言う。
エアビーアンドビーは投資家の考え方を変えた。
どこからどう考えても、エアビーアンドビーはありえなかった。3人ともそれまでほとんどビジネスの経験はなく、起業してからずっと独学だった。これまでのビジネスの常識とは反対のことをした。最初の頃は、規模拡大に集中する代わりに、大陸の反対側の一握りのユーザーにありったけの力と資源を注いだ。お金をかけてプロの写真家を雇い、一件ずつ訪問した。ありとあらゆるリスクのありそうな奇妙なサービスを、世間に受け入れさせたばかりか、流行らせた。
3人の才能が集まったからこそ、成し遂げられた。
すべてを可能にしたのは3人のめずらしい才能の組み合わせだった。このトリオだからこそ、巨大な障壁を乗り越え、複雑すぎる問題を解決できた。グローバルな決済プラットフォームをつくり上げ、検索照合の手法を開発し、リスクをできるだけ排除して安全を育むシステムをデザインした。そうしたイノベーションのすべてが、その後に生まれる類似サイトに標準装備されるようになった。スムーズで速くて親しみが持てて使いやすいサイトと奇妙なアイデアの組み合わせに、待ちかねていたファンは飛びついた。3人はそれらをすべて取り込んで、拡大した。よく見逃されているが、エアビーアンドビーは今も昔も実行力で抜きん出ている。
おまけ(作中に出てきた本)
ブレチャージクは下記の書籍から経営に関する知恵を得ていた。
- 作者: ジム・コリンズ,山岡洋一
- 出版社/メーカー: 日経BP社
- 発売日: 1995/09/26
- メディア: 単行本
- 購入: 33人 クリック: 196回
- この商品を含むブログ (276件) を見る
- 作者: パトリック・レンシオーニ,伊豆原弓
- 出版社/メーカー: 翔泳社
- 発売日: 2003/06/18
- メディア: 単行本
- 購入: 6人 クリック: 16回
- この商品を含むブログ (11件) を見る
- 作者: ジェフリー・ムーア,川又政治
- 出版社/メーカー: 翔泳社
- 発売日: 2002/01/23
- メディア: 単行本
- 購入: 21人 クリック: 373回
- この商品を含むブログ (182件) を見る
まとめ
創業時のエピソードがたくさん盛り込まれていて、スラスラ読めて面白かった。臆面なく、度胸を持って、色々なことに取り組んでいきたいと思わせる本だった。うめさんに漫画化して欲しい。
コートエシエルのリュックを買った
2016年秋にSサイズが販売されたので、買った。通称餃子バッグ。半年以上使ってみたが、かなり満足している。
買ったのは、これのSサイズの黒。
以前からコートエシエルのリュックは使っている人が多くて、気になっていたのだが、いかんせんデカいと感じていて、自転車とかならともかく、電車乗る時とか大変そうだなー、小さいサイズがでないかなー、と思っていた。
そう思っていた矢先、2016年秋にちょうどSサイズが出たので、実店舗に行って、背負わせてもらったところ、とても背負いやすくて、気に入ったので、買った。
ちなみに、エンジニアのリュックとしての下記の要件を満たしていた。
- 13インチのMacBookProが入ること
- 入る
- 雨の日にも中が濡れない
- 雨を弾く素材
- 使っている中で、中まで浸水したことはない
- 背負うのが楽
- 肩まわりの形状がしっかりしていて、かなり背負いやすい
- MacBookProを入れていても重さをあまり感じない
- 以前、物理的な重さがかなり軽量なタイプなリュックを使っていたが、その時よりも背負うのが楽に感じる
Mサイズとは形状が異なり、ファスナーの位置や中の構造が違っていた。この辺りは実物を見てから決めた方が良さそう。Mサイズの方が当然のことながら、容量は大きいし、収納力は高く便利なのだが、普段使いにはオーバースペックだと感じたので、Sサイズに決めた。YAGNIの精神。
ちなみに、小物の収納力が乏しいので、これを入れて、小物を整理して使っている。見た目の相性も悪くない。
コクヨ バッグインバッグ Bizrack A4タテ ブラック カハ-BR23D
- 出版社/メーカー: コクヨ(KOKUYO)
- メディア: オフィス用品
- この商品を含むブログを見る
あと、リュックによくついている上部の取っ手がかなり丈夫で、家の中では、地べたに置かず、こんな感じで机の高さに吊るして使っている。帰ってきて、リュックからPCを取り出し、机に置く動線がかなり楽。PCを入れたまま吊るしても、全然壊れる気配はない。
長く大切に使っていきたい。
Rails Developers Meetup #2 (東京会場)に参加してきた
概要
【増枠】Rails Developers Meetup #2 (東京会場) - connpass
所感
- @onkさんの話が日常の開発で大切だと感じた
- ドリコムでの共通認識の作り方が参考になった
- bundle update当番や野良コードレビューとかはやってみたい
- 開発環境を良くしていくために投資していきたい
- ドリコムでの共通認識の作り方が参考になった
- DB制約大事
- 今関わっている案件的にshibaraku使えそう
『クラシルのwebサイトをちょっとした改善で100倍速にした話』
奥原 拓也さん(dely株式会社 リードRailsエンジニア)
- webの表示改善
- 59.7sec => 0.70 sec
- キャッシュの導入
- 画像の最適化
- 不要なimportの削除
キャッシュの導入
- ページキャッシュ
- 廃止
- アクションキャッシュ
- 廃止
- フラグメントキャッシュ
- 期間を指定してキャッシュできる
- 1549ms => 131ms
- key/valueがあったら読み、なかったら書く
- 更新したい場合は?
- 特定のフラグがあるとキャッシュを更新する
画像の最適化
- 画像の圧縮
- TinyPNG
- brew install jpengtim
- brew install pngguant
- 画像の最適化
- デバイスに最適なサイズを読む
不要な外部ファイルの削除
結果
- 早くなった
その他
- テックブログ書いてる
- denyはRailsエンジニア一人らしい
『ふつうのRailsアプリケーション開発』
大仲 能史さん(株式会社ドリコム スペシャリスト) @onk
- RailsエンジニアがRailsエンジニアらしい仕事ができること
- bin/setup, bin/update
- 1コマンドで開発準備が整うようにしておけという話
- SimpleとEasyの違い
- 設計に筋が通っていて、すっきり(絶対的)
- 使う時に、簡単(相対的)
- Kaminari
- 各環境向けのコードをプラグインとして切り出すことで、コアの設計指針をSimpleに保つ
- 認証系のgemはそうなっていないのでは
RailsとEasy
- CoCを知っている人にとってはEasy
- 90%のことをやる
- 一般的でなくても、使う時にEasyなら取り入れていく
- rails5.1のsecrets.ymlのshared機能
- 共通認識の元でEasyであることを加速させていくフレームワーク
ドリコムとEasy
- Will2Kaminari
- to_id
- count_by
- activerevord-unsigned-column-ext
- activerecord-turntabke
- ユーザ認証
- 自作するが、deviseとIFを合わせる
共通認識を作る
- まずは個人で始める
- 自分の認識と世の中の認識を揃える
- 大量にインプットする
- はてブ
- Qiita
- 自分の認識と世の中の認識を揃える
- bundle update当番
- 使っているgemがどんなもので、どのように開発しているかを眺める
- 面白い
- 興味が湧く
- 使っているgemがどんなもので、どのように開発しているかを眺める
- 野良コードレビュー
- 社内の複数アプリを全体的に眺める
- 同じ轍を踏まない
- not null
- unique
- Datetime -> Time
- ユーザの持ち物はcurrent_userから辿る
- ユーザの持ち物のモデルにはUserを付ける
- 重複コードをgem化する
- 最後まで直しきる
- 複雑なことはしない
- MVC
- FromObject以外はほとんど使わない
- Serviceはやりきるなら導入する
- あまり導入しない
- OSS文脈に乗る
- onkcop
- CI/CD
Easyを作る
- 発生しないようにする
- 自動化の鬼になる
- 手順書を見かけたら自動化可能だと思え
- 全自動が無理ならせめてスクリプト化する
- 時間がかからないようにする
- db:migrate:resetではなくdb:setupを使う
- デフォルト値を入れる
- 書きたくないものを書かなくても良いようにしたい
- 認証をbefore_actionでやっているなら、ApplicationControllerに書けないか検討する
- すべてに適用してから一部を外す
- 一般的かどうかを意識する
- DHHに習う
- 基本はそうだけど、こっちのほうが便利じゃない?
- DHHに習う
Easyを作る体制を作る
- 楽をするための努力を惜しまない
- 足回りは最初に整える
- テスト
- もちろん書く
- CI/CD
- もちろん回す
- メトリクス
- もちろん取る
- シンプルに始める
- routes
- REST準拠
- schema
- 正規化を崩さない
- ブランチ運用
- github flow
- Issue / PRのテンプレートを書いておく
- routes
- 改善がまわる環境づくり
- ふりかえり
- 定点観測
『技術的負債とリファクタリング』
@sinsoku_listyさん(株式会社grooves)
- DB制約
- 変更しやすいコード
- リファクタリングいつする?
DB制約
- null: falseは基本的に必須
- null: falseがつけられなければ、Tableを分ける
- unique制約
変更しやすいコード
- コードの可視性
- private
- Refinement
- 読みやすいコード
- 命名
- ABCSize
- 過剰なDRYより分かりやすさ
リファクタリングいつやるか
- 良いコードは伝説
- ソフトウェア開発は難しい
- 少しずつ直していく
- コードを読んでいくタイミングで
- 理解した内容をコードに反映する
- スコープを狭くする(未使用なら消す)
『ドリコムで使ってるgem一覧』
@sue445さん(株式会社ドリコム)
- 11アプリのGemfileを集計
- 集計スクリプト書いた
- 社内gemは除く
- メジャーどころ集まりすぎたので、マイナーどころを紹介
- komachi_heartbeat
- 死活監視
- global
- yamlの設定をいい感じに扱う
- onkcop
- ドリコムのrubocop
- spec-parameterized
- パラメタライズをテストする
- shibaraku
- start_at/end_atがあるmodelを扱うgem
- activerecord-simple_index_name
- index名からtable名を除く
- activerecord-turntable
- DBを水平分散する
『ペパボで使ってるgem一覧』
@kenchanさん(GMOペパボ株式会社)
- shu-cream.net
- こちらもメジャーどころではなくテーマを絞る
- 文字系
- moji
- makimoto/romaji
- mwunsch/rumoji
- willnet/gimei
- 日本語のテストデータ作成
- ペパボ発
- hsbt/minitest-power-asert
- yml_ref_resolver
- capistrano-release-notification
- rspec-default_http_header
- global_sign
『データフィードの現場で書く Rails アプリケーション』
@284kmさん(株式会社フィードフォース)
- Webmockの話
- データフィードの現場とは
- データフィードとは
- 保有している商品などのデータを外部サービス(広告配信先など)のフォーマットに変換して送信する仕組みのこと
- データフィードとは
- ふつうでありたい
- とはいえ、特殊もある
- koala
- テスト
- http
- web mockを使う
- httpリクエストがあたかも行われたかのように振る舞う
初めてOSSにコントリビュートをした
対象PR
Fix auto diagram generation by kikunantoka · Pull Request #252 · voormedia/rails-erd
経緯
- 下記のように、公私で作るRailsアプリケーションは大体、タスクを追加して、
rails db:migrate
するとER図が自動出力されるようにしていた - ただ、プロジェクト毎に、同じタスクを生成するのも面倒なので、ジェネレータを作ろうと試みている時に、本家にジェネレータがあることに気づいた
- しかし、下記issueにもある通り、動作していないようだった
- issue内に修正方法が提示されていたので、修正を行い、ドキュメントを追記し、PRを送った
- 1ヶ月ぐらい放置された後、しれっとマージされて、リリースされていた
結果
rails-erd 1.5.1からrails generate erd:install
するとタスクが生成され、開発環境で、rails db:migrate
する際にER図を出力できるようになった。
しれっとマージされた様子
rails-erdにPR出してみた
— キクナントカ (@kikunantoka) 2017年4月20日
こっそりマージされて、こっそりリリースされてた https://t.co/VOAx6BxfaA
— キクナントカ (@kikunantoka) 2017年5月25日
今後
RailsやReactでアプリケーションを書くようになって、OSSにはお世話になりっぱなしなので、ドキュメントでもなんでも構わないので、機会があれば、貢献していきたい所存。