Webナントカ

個人開発、読んだ本、サービスの話などを書きます╭( ･ㅂ･)و ̑̑

「Airbnb Story」を読んだ

読んだ

Airbnbの創業ストーリーをまとめた本。ワクワクしながら読めた。臆面なく、度胸を持って、色々なことに取り組んでいきたいと思わせる本だった。

Airbnb Story 大胆なアイデアを生み、困難を乗り越え、超人気サービスをつくる方法

Airbnb Story 大胆なアイデアを生み、困難を乗り越え、超人気サービスをつくる方法

ストーリーは、美大出身のデザイナーのチェスキーとゲビア、エンジニアのブレチャージクの三人で、赤の他人を自宅に泊めるという奇抜なアイデアを、様々な問題を乗り越えながら形にして、時価総額3兆円の会社にしていく話。

アイデアの奇抜さから、投資家から投資を受けるまでに苦労した話や、ホストの部屋が荒らされたり、既存のホテルや法律との戦いなど、たくさん失敗の経験談が細かく描かれている。

以下、ネタバレを含んでいるが、個人的に印象に残ったエピソードや言葉を書いていく。

シリアル

サービス開始当初、資金不足で継続がままならない時に、大統領選にちなんだデザインのシリアルを作成して売り、後にYコンの面接でシリアルの話が活きたというエピソード。創業時の泥臭さがにじみ出ていて良かった。

のちにグレアムは、例のシリアルが決め手だったと言っていた。「4ドルのシリアルを40ドルで売れるなら、他人のエアベッドで寝るようにみんなを説得できるだろうと思ったんだ。たぶんね」

プロダクトへのこだわり

Airbnbのウェブサイトは、3つのこだわりを持って作られていた。

  • 簡単に使えること
  • 掲載物件が美しく見えること
  • 必ず3クリック以内で予約が完了すること

掲載物件を美しく見せるために、プロの写真家をホストの家に派遣していた。3クリックルールはジョブズがiPodを開発した時に3クリックで楽曲が手に入るようにデザインさせた話から由来している。

このプロダクトへのこだわりが熱烈なファンの獲得に繋がったと思う。

ウィムドゥを買収しない選択

パクリサービスにヨーロッパに先行された時の判断。アツかった。

メイソンは、ウィムドゥがエアビーアンドビーを殺す可能性もあると言った。ザッカーバーグは買わないほうがいいと言う。一番いいプロダクトを持つ会社が最後に勝つ、と。決定打になったのは、ポール・グレアムのひとことだった。エアビーアンドビーとウィムドゥの違いは、エアビーアンドビーの創業者は伝道師で、ウィムドゥの創業者はカネで動く傭兵だということ。たいていは伝道師が勝つ。「自分に賭けた」瞬間だった。チェスキーたちは、ウィムドゥを買わないと決めた。

「ゼロをひとつ加える」

ホストの家が荒らされた時の対応の決定が内部でモメたことにより、和解が遅れた時の話。共同創業者のアンドリーセンがチェスキーの送ろうとした被害者への手紙の賠償額に0を一つ加えたエピソード。

この経験から、チェスキーが学んだのは、コンセンサスで決定するなということだ。「危機のときコンセンサスで決めると、中途半端な決定になる。それはたいてい最悪の判断だ。危機のときには、右か左かに決めるべきなんだ。」それ以来、考え方をひとつ上のレベルに持っていくことを、「ゼロをひとつ加える」と呼ぶようになった。

「文化を壊すな」

チェスキーは文化を壊さないために、日曜の夜に社員向けのメールを送り、社員が300人になるまで、必ず面接をしていた。文化を守ることによって、イノベーションが生まれやすい環境を作るというのは、ベンチャーっぽい考え方で良い。

ティールはただ、「文化を壊すな」と言った。投資した理由のひとつが、エアビーアンドビーの文化だが、企業規模が拡大すればかならず文化が「壊される」、とティールは言う。チェスキーはこれを挑戦と受け止め、以来エアビーアンドビーの文化に執着と言っていいほどの注意を払ってきた。「文化が壊れるってことは、プロダクトをつくる機械が壊れるってことだ」チェスキーはそうブログに書いた。文化が協力であればあるほど、社員を信頼でき、その分正式な規則や手続きが少なくて済む。手続きがすくなければそれだけ管理も軽くなり、イノベーションが生まれやすい環境ができる。

3人だからこそ

ゲビアの言葉がアツかった。この3人だったからこそ成功できたという言葉が、かなり印象的だった。

3人が違っていたからこそ成功できたと彼らは言う。「ひとりじゃ絶対にできなかった。ふたりでもできなかった。ネイトとブライアンと僕の持ち寄るものがひとつになったから、この数年の困難を乗り切れたと思う」とゲビアは言う。

エアビーアンドビーは投資家の考え方を変えた。

どこからどう考えても、エアビーアンドビーはありえなかった。3人ともそれまでほとんどビジネスの経験はなく、起業してからずっと独学だった。これまでのビジネスの常識とは反対のことをした。最初の頃は、規模拡大に集中する代わりに、大陸の反対側の一握りのユーザーにありったけの力と資源を注いだ。お金をかけてプロの写真家を雇い、一件ずつ訪問した。ありとあらゆるリスクのありそうな奇妙なサービスを、世間に受け入れさせたばかりか、流行らせた。

3人の才能が集まったからこそ、成し遂げられた。

すべてを可能にしたのは3人のめずらしい才能の組み合わせだった。このトリオだからこそ、巨大な障壁を乗り越え、複雑すぎる問題を解決できた。グローバルな決済プラットフォームをつくり上げ、検索照合の手法を開発し、リスクをできるだけ排除して安全を育むシステムをデザインした。そうしたイノベーションのすべてが、その後に生まれる類似サイトに標準装備されるようになった。スムーズで速くて親しみが持てて使いやすいサイトと奇妙なアイデアの組み合わせに、待ちかねていたファンは飛びついた。3人はそれらをすべて取り込んで、拡大した。よく見逃されているが、エアビーアンドビーは今も昔も実行力で抜きん出ている。

おまけ（作中に出てきた本）

ブレチャージクは下記の書籍から経営に関する知恵を得ていた。

ビジョナリー・カンパニー ― 時代を超える生存の原則

ビジョナリー・カンパニー ― 時代を超える生存の原則

あなたのチームは、機能してますか？

あなたのチームは、機能してますか？

キャズム

キャズム

まとめ

創業時のエピソードがたくさん盛り込まれていて、スラスラ読めて面白かった。臆面なく、度胸を持って、色々なことに取り組んでいきたいと思わせる本だった。うめさんに漫画化して欲しい。

コートエシエルのリュックを買った

買った

2016年秋にSサイズが販売されたので、買った。通称餃子バッグ。半年以上使ってみたが、かなり満足している。

(コートアンドシエル) Cote&Ciel Laptop Rucksack/Mサイズ/（13-15インチ） ノートパソコン/Macbook 収納 リュック/バックパック [並行輸入品] Black | CCLRS150-BLK

(コートアンドシエル) Cote&Ciel Laptop Rucksack/Mサイズ/（13-15インチ） ノートパソコン/Macbook 収納 リュック/バックパック [並行輸入品] Black | CCLRS150-BLK

買ったのは、これのSサイズの黒。

以前からコートエシエルのリュックは使っている人が多くて、気になっていたのだが、いかんせんデカいと感じていて、自転車とかならともかく、電車乗る時とか大変そうだなー、小さいサイズがでないかなー、と思っていた。

そう思っていた矢先、2016年秋にちょうどSサイズが出たので、実店舗に行って、背負わせてもらったところ、とても背負いやすくて、気に入ったので、買った。

ちなみに、エンジニアのリュックとしての下記の要件を満たしていた。

  • 13インチのMacBookProが入ること
    • 入る
  • 雨の日にも中が濡れない
    • 雨を弾く素材
    • 使っている中で、中まで浸水したことはない
  • 背負うのが楽
    • 肩まわりの形状がしっかりしていて、かなり背負いやすい
    • MacBookProを入れていても重さをあまり感じない
    • 以前、物理的な重さがかなり軽量なタイプなリュックを使っていたが、その時よりも背負うのが楽に感じる

Mサイズとは形状が異なり、ファスナーの位置や中の構造が違っていた。この辺りは実物を見てから決めた方が良さそう。Mサイズの方が当然のことながら、容量は大きいし、収納力は高く便利なのだが、普段使いにはオーバースペックだと感じたので、Sサイズに決めた。YAGNIの精神。

ちなみに、小物の収納力が乏しいので、これを入れて、小物を整理して使っている。見た目の相性も悪くない。

コクヨ バッグインバッグ Bizrack A4タテ ブラック カハ-BR23D

コクヨ バッグインバッグ Bizrack A4タテ ブラック カハ-BR23D

あと、リュックによくついている上部の取っ手がかなり丈夫で、家の中では、地べたに置かず、こんな感じで机の高さに吊るして使っている。帰ってきて、リュックからPCを取り出し、机に置く動線がかなり楽。PCを入れたまま吊るしても、全然壊れる気配はない。

f:id:kikunantoka:20170707020908j:plain

長く大切に使っていきたい。

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がどんなもので、どのように開発しているかを眺める
      • 面白い
      • 興味が湧く
  • 野良コードレビュー
    • 社内の複数アプリを全体的に眺める
    • 同じ轍を踏まない
    • 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に習う
      • 基本はそうだけど、こっちのほうが便利じゃない？

Easyを作る体制を作る

  • 楽をするための努力を惜しまない
  • 足回りは最初に整える
  • テスト
    • もちろん書く
  • CI/CD
    • もちろん回す
  • メトリクス
    • もちろん取る
  • シンプルに始める
    • routes
      • REST準拠
    • schema
      • 正規化を崩さない
    • ブランチ運用
      • github flow
    • Issue / PRのテンプレートを書いておく
  • 改善がまわる環境づくり
    • ふりかえり
    • 定点観測

『技術的負債とリファクタリング』

@sinsoku_listyさん（株式会社grooves）

  • DB制約
  • 変更しやすいコード
  • リファクタリングいつする？

DB制約

  • null: falseは基本的に必須
  • null: falseがつけられなければ、Tableを分ける
  • unique制約

変更しやすいコード

  • コードの可視性
    • private
    • Refinement
  • 読みやすいコード
    • 命名
    • ABCSize
    • 過剰なDRYより分かりやすさ

リファクタリングいつやるか

  • 良いコードは伝説
  • ソフトウェア開発は難しい
  • 少しずつ直していく
  • コードを読んでいくタイミングで
    • 理解した内容をコードに反映する
    • スコープを狭くする（未使用なら消す）

『ドリコムで使ってるgem一覧』

@sue445さん（株式会社ドリコム）

ドリコムで使ってるgem一覧 #railsdm

  • 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
    • google
  • テスト
    • 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やReactでアプリケーションを書くようになって、OSSにはお世話になりっぱなしなので、ドキュメントでもなんでも構わないので、機会があれば、貢献していきたい所存。

mochaを買った

サービス 買った

MacのHatena Blog用のMarkdownエディタとして、mochaを買った。240円。

mocha

mocha

  • Reo Hokazono
  • ライフスタイル
  • ¥240

使い初めて3ヶ月ぐらい経ったけど、継続して使っている。

それまでMarkdownエディタとして、kobitoでHatena Blogの記事も書き、タグで管理していたが、Hatena Blogといい感じに同期をして欲しかったので、探してみた。

要件として、

  • Hatena Blogと同期を取ってくれる
  • Markdownで書けて、プレビューできる
  • シンプル

の3点があり、mochaはこれらを満たしていた。

ウィジェット系はサポートされていないので、下書き専用として使っていて、公開時にWeb上からウィジェットを追加して、予約投稿を行っている。

ウィジェット系と予約投稿のサポートと少しのUI改善があれば、文句なしだが、現状でも240円出す価値は十分あると思う。

以下、購入時の感想

トップへ戻る