CookpadTechConfに行ってきました #CookpadTechConf

しょこです。
昨日はCookpadTechConfに行ってきました！
資料やらtogetherは以下にまとめました。

sd-ts1017.hatenablog.com

各セッションの感想

基調講演: ユーザーのために、技術をどう活かすか

• ユーザーファーストを実現するためには仮設→実行→検証サイクルを回す
  以降のセッションでもこのベースは変わらなかった。クックパッドの基本がこれ。

  ユーザーファーストを実現するための技術

• Chanko, RRRSpec
• その時にあった技術・開発を行っていくよう変化を受け入れる。
• 得意な技術・開発を捨てて変化できる開発者が大事。

  ユーザーファーストを実現するための組織

• 議論の決まった経緯を全員がわかるようにする
  1.対面で決まったこと：Groupadで共有 (Qiita:Teamみたいなやつ)
  2.オンラインで決まったこと：GitHubのIssueで議論して、Issueの履歴で見れる
• 社内発信が社外・お客様へ発信する練習・訓練になる
• エンジニア一人ひとりのスキル向上も大事。GHEでのコードレビューは一役買ってる
• エンジニアが主体的に組織改善に関わることを評価する。（1. 行動評価 2. 社内外に影響を与えているか)

  まとめ

• 当たり前のことを当たり前にでき続けることが大切。当たり前にユーザーのために価値を考え続けることを個人組織の両方でできる

おでかけスポット検索のむずかしさ - Holiday を支える検索技術

• Holidayは「いつもの休日のお出かけを楽しくすることで人生を豊かにする」サービス
• お出かけ先検索「中目黒、中目黒にない問題」（イメージする中目黒は住所でいうと中目黒ではない）
• 全文検索だけでは検索しきれない→ElasticSearchを使って全文検索と地理検索を組み合わせる
• 検索時の形態素解析をするときは流行語や新語にも対応する（mecab-ipadic-NEologd）

Railsアプリ開発環境の高速化

高速すぎてついてけなかった・・・

R&D at Foodtech company

• 企業での研究開発の目的は「お金を稼ぐこと」
• 研究開発は以下の5分野についてやっている。
  1.機械学習・自然言語処理
  2.IoT
  3.食文化
  4.ヘルスケア領域
  5.食みらい研究所
• NIIにクックパッドのデータセットを提供している
• 非専門家（例：アプリケーションエンジニア）が機械学習を使ったサービスを作れるシステムを開発中

技術力を事業の強みするために必要なこと

• 必要なこと
  1.事業と計画
  2.責任範囲とリーダーシップ（今日のトピック）
  3.行動とフィードバック　
• 「議論や調整じゃなくて決定とテスト」そのためには責任範囲と決定権を持つ人を決めることが重要
• 仕事について責任領域と責任レベルを定義することで評価をしやすくする
  1.責任領域：4つ(tech/user/revenue/team)
  2.責任レベル：3つ(成果を定義する/仕事を定義する/仕事を遂行する)

  まとめ

• 分解可能な事業成果を定義して、分割して分担して、行動の定義と促進する仕組みを作る。

開発した新技術から、新しい価値を作るためのクックパッド検索チームのプロダクト開発手法

• 技術から製品を作ってはいけない。課題への解決策は一度忘れて検討する。
• 技術→製品→価値ではなく技術←製品←価値にする
• チームメンバーだけでなく周りを巻き込んで「価値を形にするMTG」を行う
  最初はなかなか成果が出なかったので苦しい時間もあったとのこと。
• 要望は「あれを作りたい！」ではなく「ないと困る！死ぬ！（悲しみ・失望）」ベースで解決策を考える。
• ユーザーの要望を分析(Whyのロジックツリーとか)した上で、初めて解決策を考える。
• いいアイデアが浮かんだら「温泉が湧いた！！」
• 続きはWebで！ techlife.cookpad.com

「今日なに作ろう？」を支えるデザイン

• ユーザーファースト推進室：クックパッド全体のサービスを、横断的・俯瞰的に捉えてユーザーファーストを加速させる部署
• ユーザーファーストなサービスとは以下の３つを満たすサービス
  1.「ユーザが期待した通りの結果を得ることができる」
  2.「ユーザがついつい夢中になってしまう」
  3.「人にオススメしたくなる」
• 常にユーザーを主語に考える。
• デザイナー→エンジニアへ渡す時は色は変数名で管理。その変数名をスタイルガイドにも適用。
• 作成したデザインはGitHubにIssueを立てて他のデザイナー・開発者にレビューしてもらう

確かめながら作るユーザー体験

• 誰も答えを知らない問題に対しては、なるべく多く仮説を試すことで対処する
• 機能の要件定義をするのではなく、ユーザーにどのような体験を提供するのかを定義する
• サービス開発を定義するステートメントを書き、今後の開発の指針にする。迷ったらステートメントに戻る。
• ステートメントのレビューを最初にする。コア機能が多すぎたら、それをシンプルにする。
• 続きはWebで！ techlife.cookpad.com

モバイルアプリのインタラクションプロトタイピング

• 価値のあるプロダクトを作るために 速さ・品質のバランスを取るのが難しい
• サービスと比べてモバイルアプリは審査等あってなかなか仮設→実行→検証の実行に時間がかかってしまう
• モックツールうまく使う(Flinto/Invision/Prott)

モバイルアプリ開発の"標準"を探る

• クックパッドはモバイル端末からのアクセスが過半数。アカウント持ちユーザ→スマホのみが8割。ゲストユーザ→スマホのみが7割 -「標準的な開発」の定義「効果とコストのバランスが良く納得感のある開発」
• クックパッドの考える標準的な開発
  1. 新技術の導入
  2. CI, Test, QA
  3. FTS (Failure Teaches Success)
• 新技術は積極的に導入するが、それがどういう問題を解決するのかをきちんと示すこと
• モバイルアプリの難所
  1. ユーザーが使うバージョンを制御できない。アップデートを強制することもできるがやらない方針。
  2. 実行環境を制御できない。端末のスペックOSのバージョン通信環境etc.. -CIはJenkins使ってる。静的解析の結果をPRにポストしたり。
• 「気をつけて実装する」は障害のもと。FTS使って技術的に解決しましょう。

DWHに必要なこと

• 「データ活用基盤」を構築する上での戦略・知見
• DWHは(ざっくり言うと)分析用のきれいなDB => 普通のDBは汚い
• DWH作成方針
  1.データは一箇所に集める
  2.データを三層に整理する(ソースデータ／DWH／アプリ)
  3.SQLで全ての操作をする
• 共通のDBを作ってそれからアプリケーションをどんどん作る。rails newはダメ絶対。
• SQLで操作する＝SELECTしたものをそのままINSERTする。Rubyプログラムとか挟まない
• 今日のポイント：ウェブとDWHじゃSQL違うんやで

基調講演: クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について

• 世界最大のRailsプロジェクトがクックパッド（不名誉）重すぎるからリニューアルしたくて試したけど失敗した。
• リニューアル失敗した時の学び(1)仕様の整理とリファクタリングを同時にやってはいけない(2)手遅れになってからやらない
• リニューアル失敗で得た知見でChanko作った。
• Chanko使って既存コードを修正するのではなく、既存コードを元にパッチを当ててく。
• コード品質がビジネスに影響する。品質が悪いとコードの寿命が短くなる。
• コードレビューをする。観点：コーディング規約に従っているか。
• 些細な文法についてもコーディング規約に入れれば、些細な文法についても揉めなくなった。（最初は反対意見も多かった）
• 些細な文法に異議があればスタイルガイドのリポジトリで議論すればいいって分けられる。
• インフラの老朽化（サーバとか）は式年遷宮を見習う。
• 作り直すことを前提にすることで長寿命化
  確かに、基本は長年使えるってことを売りにしていることが多いけど、時代の流れについていけなくなるからそこだけを推してはいけないね。
• 細かく成功体験をつくり、アップデートの価値を組織に実感させる

感想

クックパッドみたいな素敵な世界で開発できる会社が増えるともっと幸せになれそう。
ユーザファーストって言うは易し行うは難しだなと本当に思いました。
あと懇親会とかで自己紹介すると「あ、ハッシュタグですごいつぶやいている人ですよね！」と言われたw
有益なことを速やかにつぶやけるようになりたい。