機械学習を用いてユーザーのご意見分類業務を効率化した話 - クックパッド開発者ブログ
こんにちは。研究開発部の @vanhuyz です。機械学習・自然言語処理を中心に研究開発しています。 今回は機械学習を活用してユーザーからのご意見を 81 のカテゴリーに自動分類し、ユーザーサポートスタッフによる手動分類の工数を半分にできた話を紹介したいと思います。 背景 クックパッドは現在約 5,500 万人の国内月間ユーザーがあり、日々ユーザーからたくさんのご意見やご要望を頂いています。創業してからユーザーの声を大事に扱う文化があり、どのご意見も一度目を通すようにユーザーサポートスタッフが努力しています。ご意見はスタッフによってさらに分類され、必要に応じてディレクターやエンジニアに振り分けられています。 例えば、こんな感じのご意見が来ています。「このレシピは簡単なので、子供とやってみました。楽しかったです」や「機種変更して、ログイン出来ません」や「もっと具体的な内容でも検索できるように
Chaos Engineering やっていく宣言 - クックパッド開発者ブログ
技術部のヨシオリです。 Netflix が Chaos Engineering の論文を公開して 2 年ほど経ちました。 クックパッドは最近、 Chaos Engineering を導入する事を決めました。 この記事ではその背景を紹介したいと思います。 そもそも Chaos Engineering とは Netflix では Failure Injection Testing として、営業時間中に意図的に障害を起す事をやっていました。Chaos Monkey というインスタンスとサービスを落すものから Chaos Gorilla、Kong という availability zone や region 単位で障害を発生させるものなどです。 その経験から Chaos Engineering というものが提唱されました。 Principles of Chaos Engineeringによれば C
無理をしないコードレビュー - クックパッド開発者ブログ
会員事業部の三吉（@sankichi92）です。 クックパッドでは、GitHub Enterprise の Pull Request を使ったコードレビューを広く実施しています。 この記事では、私がコードレビューすることに対する苦手意識をなくすために意識したことを紹介します。 クックパッドでは、テックリードや新卒、インターン、バイトといった肩書きに関係なく、誰もがレビュワー・レビュイーになります。 チームやプロダクトによって開発ルールは少しずつ異なりますが、私の所属する会員事業部では、PR を出したときに GHE やチャットで部内のエンジニアにメンションして、その時にレビューできる人がレビューするという形を取っています。 私は、昨年2017年に新卒入社したのですが、それまでは個人開発や研究用のコードしか書いたことがなく、短期インターンシップを除くチーム開発の経験がありませんでした。 配属当
大きな Rails アプリケーションをなんとかしよう。まずは計測と可視化からはじめよう。 - クックパッド開発者ブログ
こんにちは、技術部開発基盤グループの id:hogelog です。 RubyKaigi 2018 楽しかったですね。僕はおそらく RubyKaigi 2010 以来の久しぶりの参加でした。ああいう場の楽しさを思い出し、また今回はスポンサーブースから RubyKaigi に参加するという学生の頃は知らなかった楽しみも新たに知り、RubyKaigi を満喫させていただきました。 さて今回はそんな RubyKaigi で取り戻した Ruby に対する感情と関係あるようなないような、最近自分が取り組んでいるお台場プロジェクトとプロジェクト内で実施している計測と可視化について紹介します。 お台場プロジェクトの発足 クックパッドの開発といえば数年前までは cookpad_all という一つのリポジトリの中に詰め込まれた巨大なモノリシック Rails アプリケーションを社内のエンジニアが寄ってたかって開
Service Mesh and Cookpad - クックパッド開発者ブログ
こんにちは、開発基盤の Taiki です。今回は、マイクロサービスで必須のコンポーネントとなりつつあるサービスメッシュについて、クックパッドで構築・運用して得られた知見についてご紹介できればと思います。 サービスメッシュそのものについては以下の記事や発表、チュートリアルで全体感をつかめると思います: https://speakerdeck.com/taiki45/observability-service-mesh-and-microservices https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc https://istio.io/
MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
ユーザー基盤を作り直しながらRailsでのサービス層に向き合う - クックパッド開発者ブログ
こんにちは。パートナーアライアンス部の諸橋 (@moro) です。 突然ですが、わたしはいまクックパッドの「ユーザー基盤」を再構築しようとしています。 一口に「ユーザー基盤の再構築」といっても、そのゴールが何を指すかは(わたし自身にとってもまだ)漠然としており、固定されたゴールは見いだせていません。しかし後述するように、いくつかの問題は明確な形を取っています。言い換えると、それら明確な問題と向き合いながら『柔軟でいい感じのユーザー基盤を目指す』というのがこの再構築プロジェクトの目的です。 その第一歩目として、ユーザー登録部分を現状のクックパッド本体とは別の小さなRailsアプリケーションとして実装を進め、つい先日、一部の限定された利用者の方に向けて公開することができました。 今後も様子を見ながら公開範囲を拡大していく予定です。 再構築の背景 ではその「明確な問題」とはなんでしょうか。 最大
エンジニア全体ミーティング Tech MTGのすゝめ - クックパッド開発者ブログ
こんにちは。投稿開発部エンジニアの土谷(@taihaku0415)です。 Androidアプリとcookpad.comの開発を中心に担当しています。 現在、クックパッドには100人弱のエンジニアが在籍しています。普段エンジニアはそれぞれの事業部に所属して、業務を行っています。スマートフォンアプリを専門に書くエンジニア、広告領域を担当するエンジニア、インフラや開発の基盤を構築しているエンジニアなど、多岐に渡ります。 そのため、クックパッドでは、業務をする上で必須なものから、他のチームの開発の知見や生産性を上げるためのtips（ツールの紹介や使い方など）まで、様々な情報を共有して、開発力や技術力の向上に役立てるための取り組みを行っています。 例えば、技術領域課題共有会では各部署・チームの課題を話し合う場が設けてあります。また、Groupadという社内ブログサービス上で、全社員（エンジニアにかぎ
そのメールアドレス、現在も使っていますか？ - クックパッド開発者ブログ
こんにちは。ユーザーファースト推進室ディレクターの大黒です。 ありがたいことにクックパッドは今年で20年目をむかえ、数多くのユーザーに利用されるまでに成長しました。それ故に発生する課題もあり、今回はその中でもユーザー登録に使われているメールアドレスの課題と対策をご紹介したいと思います。 ユーザー登録の仕組み クックパッドのユーザー登録では、下記の項目が必要となります。 メールアドレス パスワード 郵便番号 生年月日 ※iOSアプリでは郵便番号と生年月日は任意入力となります SNSアカウント認証や認証コードでのアクティベートを採用するサービスが今では主流ですが、20年続くサービスであれば一般的なユーザー登録フローではないでしょうか。しかしながら最近のスマートフォンユーザーの多くはメールを使わないという実態も分かっているため、ユーザー登録にメールアドレスを使い続けるかどうかは、別途議論を進めて
実践 Pact:マイクロサービス時代のテストツール - クックパッド開発者ブログ
技術部の taiki45 です。 以前「サービス分割時の複雑性に対処する: テスト戦略の話」という記事で、サービス間のインテグレーションテストにおける問題について紹介しました。現在のクックパッドではこの問題の解決のために Pact というツールを導入して運用しています。この記事では、その運用の知見を紹介できればと思います。 Pact Pact は Consumer-Driven Contract testing (CDC testing) を実現するためのツールです。"Consumer"、"Provider" という見慣れない単語が出てきますが、この記事ではだいたい「Consumer = Web API クライアント」、「Provider = Web API サーバー」と対応ができます。この記事では具体的な Pact の利用例を通じて CDC testing がどういうものなのかについても
「現在時刻」を外部入力とする設計と、その実装のこと - クックパッド開発者ブログ
こんにちは。技術部 開発基盤グループの諸橋です。 クックパッドでは昨今の多くのWeb企業と同じように、GitHub EnterpriseのPull Requestを使ったコードレビューを広範に実施しています。わたしたちのコードレビューでは、ソースコードの字面にとどまらず、サービスの機能として魅力的かどうかや、保守性を含めた設計が適切かといった議論に発展することも良くあります。 きょうはそんななかで話題に上がった「現在時刻」の扱いかたに関する設計の話を書きます。 背景 サービスを開発・運営している我々には、時間帯によって出し分けたり、特定の期間のみに表示したいコンテンツがたくさんあります。 そのたびにデプロイし直すというのはつらいので(特に24:00に出なくなるコンテンツなど)なんとかしたくなりますが、一方で時限式のコンテンツはその時になるまでちゃんと動いているか確証が取れないので怖いです。
日本語形態素解析の裏側を覗く！MeCab はどのように形態素解析しているか - クックパッド開発者ブログ
こんにちは、買物情報事業部の荒引 (@a_bicky) です。 前回、「検索結果の疑問を解消するための検索の基礎」で単語単位でインデキシングする前提で説明しましたが、今回は文などを単語単位で分割するために使う技術である形態素解析について触れます。 形態素解析器には色々ありますが、中でもメジャーと思われる MeCab の仕組みについて説明します。 MeCab の解析精度を上げるために辞書に単語を追加したことのある方もいると思いますが、動作原理を理解することで単語を追加する際に適切な生起コストを設定できるようになったり、学習の際に適切なパラメータを設定できるようになったりするはずです。 なお、MeCab は汎用テキスト変換ツールとしても使用できます が、簡単のため MeCab + IPA 辞書のデフォルト設定前提で説明します。 アジェンダ 形態素解析とは MeCab における最適な解析結果の推
開発の見積もりとスケジュール管理 - クックパッド開発者ブログ
こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」＝「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
安心してRailsアップグレードを行うための工夫 - クックパッド開発者ブログ
こんにちは。技術部の国分 (@k0kubun) です。 3/28にクラウドワークスさんで行なわれたRails Upgrade Casual Talksで、Railsアップグレードの際にクックパッドが行なっている工夫について紹介しました。 影響範囲の予測が難しいRailsのアップグレードを安全に行なうための動作確認のやり方について参考になればということで、本記事でも改めて紹介いたします。 CookpadのRailsアップグレードの流れ Rails 4.1から4.2にアップグレードした際の例を紹介します。 CIにRails 4.2用ジョブを用意 まずはRails 4.2にアップグレードするためのrails42ブランチでテストを通します。リリースするまでこのブランチはmasterからrebaseし続けるので、リリースまでテストを通る状態を保つため、CIにrails42ブランチ用のジョブを用意しま
社内共用カメラのすゝめ - クックパッド開発者ブログ
舘野 (id:secondlife / @hotchpotch) です。 クックパッドでは会社の中心にキッチンがあり、社員同士でランチやお菓子を作ったり、イベントを開いたりと社内のコミュニケーション用途で広く使われています。そんなキッチンで作られている様々な料理や、楽しそうなコミニュケーションをその場に居ない人にも伝えたいなー、どうにか伝える方法は無いのかな〜と思っていました。 そんな中、より良い組織を作るために の中でも触れられているコミニュケーション改善の話をしている最中、社内に共用のカメラが置いてあって、撮った写真が何もせずとも自動で社員が見れる場にアップロードするだけの仕組みを提供するだけでうまく行くかも、と思ったので2014年末に作ってみました。 サービスのコンセプト 作るときに盛り込んだコンセプトは以下の二点です。 運用コストがゼロ アップロードコストがゼロ 運用コストがゼロ
テストを使いサービス開発を駆動していくために取り組んでいること - クックパッド開発者ブログ
技術部の松尾(@Kazu_cocoa)です。 最近、 @moroや私を中心に、テストから開発を駆動するという方向で、とある活動を始めました。その活動の中では、 @t_wadaさん を 技術顧問 として巻き込んで活動を進めています。そんな取り組みを少しここにまとめます。 取り組みの前段階 先日、私はテストエンジニアというロールに焦点を当ててテストという言葉に対する2種類の話をいたしました。TDDのようにテストによって開発を駆動していく側面の話と、人の認知・感じ方に寄った仕様自体含めてテストしていく側面の話です。 クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアのあり方〜 を開催しました！ クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアvol.2 Testing編〜 を開催しました！ その際、会の傍でt_wadaさんらと私たちが開発するWebアプリケーショ
Cookpad TechConf 2016 開催報告 - クックパッド開発者ブログ
こんにちは、Cookpad TechConf 2016 実行委員長*1の小川です。 先週の土曜日の2016/01/23、クックパッド初となる技術系カンファレンスCookpad TechConf 2016を開催しました。staffblogの方でも報告させていただきましたが、開発者ブログの方では発表内容の紹介をしたいと思います。 追記：動画を公開しましたので、それぞれリンクを追加しました。ただし申し訳ありませんが、一部の発表については撮影に失敗していて動画ありません。あしからずご了承ください。 基調講演: ユーザーのために、技術をどう活かすか by 舘野 祐一 まず最初は基調講演で、弊社CTO舘野さんによる発表です。ユーザファーストのためにクックパッドがどのように技術を活かしてきたのか。例えば仮説検証や効果測定を手軽にできるようにするためにどうしてきたのか。またエンジニア組織としてユーザファー
新規サービスの管理画面を短期間で見栄え良く実装する - クックパッド開発者ブログ
こんにちは、クックパッド料理教室の京和です。 管理画面はほとんどのウェブサービスに存在し、ユーザサポートやサービスの状況・KPIなどを確認するために、スタッフが毎日利用するとても重要なものです。にも関わらず、新規サービスでは人員が不足していることから、ついおざなりなデザインや実装になりがちなのではないでしょうか。 今回はクックパッド料理教室で採用している、RailsのMountable EngineとBootstrapのデザインテンプレートを使った、見栄えがよくメンテナンスしやすい管理画面を短期間で実装する方法についてご紹介します。 Mountable Engineとは Mountable EngineはRailsアプリケーション上で動く、ミニRailsアプリケーションのようなものです。 ミニと書きましたが、Railsアプリケーション(Rails::Application)はRails::
エンジニアが人事部に入ってやったこと - クックパッド開発者ブログ
人事部 エンジニア人事企画リーダー*1の小川（@conceal_rs）です。 前回はサービス開発に関するお話をしたのですが、今回はエンジニアが人事に入ってやったことについてお話したいと思います。 人事部との兼務のきっかけ そもそも去年から中途エンジニア採用には関わってきていました。主に書類選考や面接官をしてきたのですが、去年の終わりごろからはさらに、新卒を含めたエンジニア採用全般に関わるようになっていました。また同じような時期から社内のエンジニア評価に関しても関わりが強くなってきていて、業務のほとんどが「人事系の仕事では？」と思う時があるほど比重は大きくなりました。 そんななか、当然のように人事の方と一緒に仕事をすることが増えたのですが、なぜか一歩引いた状態で会話されているなと感じることが増えてきました。言葉では説明しづらいのですが、「手伝っていただいて恐縮です」という雰囲気で接してこられ
サービスの改善を、最も小さく、最も高速に行うために - クックパッド開発者ブログ
買物情報事業部の根岸です。寒いですか。僕は今名前がわからない簡易暖房みたいなものの前にいるのであったかいです。今日は、僕がサービス開発エンジニアとして行っているサービス改善プロセスの一部についてお話させて下さい。 サービスの価値を高めるための改善は、より少ない人数で、より速く行うことが重要になります。これは、意思決定を最小限必要な人数以上で行うとコミュニケーションコストが高くなること、また、意思決定は一定の確率で失敗するものなので、イテレーションの速度を早くすると結果的に全体の価値を高めることなどが理由です。 それでは、最小の改善とは、最速の改善とは一体どのようなものなのでしょうか。 最小の改善が行われる単位 最小の改善が行われる単位は、サービスの開発を行っている個人です。個人が、改善の対象となっているサービスの課題を発見して解決へと導くことが最小の改善になります。 リリースしたサービスで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
