cookpadTV ライブ配信サービスの”突貫” Auto Scaling 環境構築

 インフラや基盤周りの技術が好きなエンジニアの渡辺です。

 今回は私が開発に関わっている cookpadTV の Auto Scaling 環境を突貫工事した事例をご紹介します。 同じチームのメンバがコメント配信回りについても書いていますので興味があれば合わせて読んでみてください。

クッキングLIVEアプリcookpadTVのコメント配信技術

 本エントリは Amazon EC2 Container Service(以降 ECS) をある程度知っている方向けとなっています。 細かいところの説明をしているとものすごく長文になってしまう為、ご了承頂ければ幸いです。

Auto Scaling について

 一般的に Auto Scaling は CPU やメモリ利用量によって増減させるのが一般的です。*1 私が属している部署で開発保守している広告配信サーバも、夕方のピークに向けて CPUUtilization の最大値がしきい値を超えたら指定台数ずつ scale-out するように設定しています。 scale-in も同じく CPUUtilization が落ち着いたら徐々に台数を減らしていっています。

 クックパッドもサービスとしてはピーキーなアクセスが来るサービスで、通常だと夕方の買い物前のアクセスが一番多いです。 ECS での Auto Scaling 設定当初は 5XX エラーを出さず、scale-out が間に合うように細かい調整を行っていました。

イベント型サービスと Auto Scaling

 ライブ配信の様にコンテンツの視聴出来る時間が決まっていて特定の時間にユーザが一気に集まるサービスでは、負荷に応じた scale-out では間に合わないことがあります。 立ち上げ当初はユーザ数もそこまで多くなかったということもあり、前述の負荷に応じた Auto Scaling 設定しか入れていませんでした。 その為、一度想定以上のユーザ数が来たときに scale-out が間に合わずライブ配信開始を 40 分ほど遅らせてしまいました。 基本的に cookpadTV のライブ配信の番組は週一で放送されていますので、1 週間以内に対応しないと同じ番組でまたユーザに迷惑を掛けてしまいます。 そこで cookpadTV チームではこの問題を最優先対応事項として改善を行いました。

まずはパフォーマンス・チューニング

 Auto Scaling の仕組みを改善する前にまずは API 側のコードを修正することで対応を行いました。 こういう細かい処理のロジックを見直すことで最適化、高速化することももちろん効果的ですが、ピーキーなアクセスで最も効果的なのは短期キャッシュです。 キャッシュは適切に使わないと思わぬトラブルを生むことが多く、出来れば使用は避けたいものです。 しかし短期キャッシュであれば情報の更新頻度次第ではあまり問題にならない場合があります。 そして今回のケースにおいてはライブ配信の時間は事前に決定し変更はされない、レシピ情報も事前に確定することがほとんです。 その為、短期キャッシュを入れる事でキャッシュのデメリット無くアプリケーションのスループットを上げることが出来ると判断しました。

 想定外のユーザ数が来た時に一番問題になったのは cookpadTV の更に先にある別の Micro Service(サービス B) への API リクエストでした。 サービス B は Auto Scaling 設定が入っておらず、大量にアクセスが流れてレスポンスタイムが悪化、cookpadTV API の unicorn worker が詰まって Nginx がエラーを返し始めるという状況でした。 ここの部分の API コールを短期キャッシュすることでスループットを大幅に上げることが出来ました。

f:id:wata_htn:20180426204103p:plain

Auto Scaling の改善

 さて、アプリケーション自体の改善は 1 週間以内で出来ることはやりました。 次は Auto Scaling 側の改善です。 冒頭でも記載した通り、負荷が上がった後では間に合わないのでライブ配信が始まる前に scale-out を済ませておく必要があります。 傾向からしてもライブ配信開始 15 分前ぐらいから徐々に人が来はじめ、直前ぐらいに push 通知を受けてユーザが一気に来ます。 その為、何かあったときに備え、余裕を持って 15 分前には scale-out を済ませておきたいと考えました。

クックパッドでの ECS Service の Auto Scaling

 クックパッドでは ECS Services の desired_count、pending_count、running_count を定期的にチェックして、pending_count を解消できるように EC2 インスタンスが scale-out されるようになっています。 その為 desired_count を何かしらの仕組みで増やすことが出来れば、後は EC2 インスタンスも含め scale-out されていきます。

単純に desired_count を増やせば良いわけではない

 ただし、単純にライブが始まる 30 分前に desired_count を増やすだけではまだ負荷が高くない為、徐々に scale-in されてしまいます。 さらに、API サーバは全配信で共有のため、複数番組同時に放送されると時間帯によっては単純に「番組配信前に指定 task 数増やす」だけではうまく行きません。 事前に scale-out したのが配信前に scale-in してしまっては意味が無いので、desired_count を単純に上げるのではなく min_capacity をライブ開始 30 分前に指定し、ライブ開始時間に min_capacity を元に戻す方式を採用しました。 この時限式に min_capacity を調整するのは、Aws::ApplicationAutoScaling::Client#put_scheduled_action を使用して実現しています。

 コードとしては以下のような形です。

def schedule_action(episode)
  scale_out_time = [episode.starts_at - 30.minutes, 1.minute.after].max
  scale_in_time = episode.starts_at
  aas.put_scheduled_action({
    service_namespace: "ecs",
    schedule: "at(#{scale_out_time.getutc.strftime('%FT%H:%M:%S')})", # UTC で指定する必要があります
    scheduled_action_name: "EpisodeScaleOut##{episode.id}",
    resource_id: "service/xxxx/cookpad-tv-api",
    scalable_dimension: "ecs:service:DesiredCount",
    scalable_target_action: {
      min_capacity: reserved_desired_count(from: scale_out_time), # ここで scale-out するための min_capacity を計算
    },
  })
  aas.put_scheduled_action({
    service_namespace: "ecs",
    schedule: "at(#{scale_in_time.getutc.strftime('%FT%H:%M:%S')})", # UTC で指定する必要があります
    scheduled_action_name: "EpisodeScaleIn##{episode.id}",
    resource_id: "service/xxxx/cookpad-tv-api",
    scalable_dimension: "ecs:service:DesiredCount",
    scalable_target_action: {
      min_capacity: reserved_desired_count(from: scale_in_time + 1.second), # ここで scale-in するための min_capacity を計算
    },
  })
end

def aas
  @aas ||= Aws::ApplicationAutoScaling::Client.new
end

 やっている事を図で表すと以下の通りです。

f:id:wata_htn:20180426204251p:plain

 min_capacity が引き上げられると結果的に desired_count も引き上げられ、running task 数が増えます。 上の図の結果、running task 数は以下の図の赤線の推移をします。

f:id:wata_htn:20180426204317p:plain

 そして、ライブ配信が被った時間帯に配信されることも考慮して、重複した時には必要数を合計した値で min_capacity をコントロールするようにしました。 勿論 min_capacity を戻す時も被っている時間帯の配信も考慮して計算しています。 先程の図に番組 B が被った時間に配信されるとすると以下の様になります。

f:id:wata_htn:20180426204341p:plain

running task 数で表現すると以下となります。

f:id:wata_htn:20180426204406p:plain

 そして、番組毎に盛り上がりが違うので、それぞれ違う task 数が必要です。 そこで番組毎の必要 task 数を、以前の近しい時間帯に配信された番組の視聴ユーザ数から割り出すようにしました。 前回とかでなく「近しい時間」としているのは、番組によっては週によって配信時間が変わったりし、そして平日だとお昼よりも夜の方が来場数が多かったりするからです。

以前の配信のユーザ数等のデータ処理

 さらっと「以前の近しい時間帯に配信された番組の視聴ユーザ数」と書きましたがこれは以下のように利用できるようにしています。

  1. ユーザの視聴ログから bricolage でサマリを作成(Redshift -> Redshift)
  2. redshift-connector + Queuery を使って MySQL にロード

 クックパッドでは全てのログデータは Amazon Redshift に取り込まれるようになっていて、そのデータを Tableau を使って可視化しています。 それをデータ活用基盤を利用して加工、アプリケーションの MySQL まで取り込んでいます。

 後は番組情報が作成、更新されたらその付近で配信予定の番組も合わせて min_capacity が再計算されるようになっています。 これらによって予約された Auto Scaling を管理画面からも確認出来るようにしました。

f:id:wata_htn:20180426204438p:plain ※画像はイメージです

初回と突発的な対応

 以前の配信がある場合はこれで対応出来ますが、初回や突発ケースにはこれだけでは不十分です。 初回はさすがに読めない部分が多いのですが、SNS での拡散状況等や、番組のお気に入り数等から来場ユーザ数を人が推測し予め設定出来るようにしました。 来場ユーザ数が指定されていると、それに必要な task 数を計算し、上記の流れと同じ様に Auto Scaling が行われます。 なかなか完全にはシステム化は難しく、こういう人のが介在する余地はまだまだ必要だったりします。 (勿論 SNS の情報を引っ張ってきて、人の予測ロジックをアルゴリズム化しても良いのですが)

退出

 忘れていけない事として、ライブ配信開始時の突入だけでなく退出があります。 ライブ視聴を終わったユーザが一気にアプリの他の画面に移動するため、ライブ開始時と同じぐらいの負荷が来ます。 ここをクリアするために scale-in はゆっくり目にして、一気に task 数が減らないようにして対処しています。 ライブ配信の終了時間は読めないため、ここは予定を組んで置くことが出来ないためです。

 参考までに突入と退出の負荷がどれくらいなのかリソース利用量のグラフを貼っておきます。

f:id:wata_htn:20180426204505p:plain

今後の発展

 同時アクセスが大量に来るのは push 通知によっても発生することがあります。その為、今後は remote push 通知を送信する前に送信件数をベースに Auto Scaling する仕組みを導入していく想定です。

補足

 Micro Services でサービスを開発していると、他チームの Service に依存して、自分達の Service だけ Auto Scaling してもサービス全体としては成り立たないことがあります。 その為その境界線を意識し、自分達の開発しているサービス内でカバーできるような設計にしていく必要があります。 キャッシュやリトライ戦略は各 Service が個別に開発するというよりはサービスメッシュ*2によって統合管理が達成出来るのではと考えています。

最後に

 イベント型サービス向けの Auto Scaling が必要になってから、突貫で作った形ではありますがクックパッドの既存の基盤のおかげでなんとか運用が回る Auto Scaling 環境が出来ました。 この辺りの基盤がしっかりしている事は今回非常に助かりました。

 さて、今回の事例紹介は以上ですが自分だったら、もっと改善出来る!という方で一緒にやっていきたいと思ってくださった方は是非私までお声がけください。

【開催レポ】Cookpad Tech Kitchen #15 〜料理動画・広告のBtoB領域の開発事情〜

こんにちは!人事部の冨永です。

2018年3月28日に「Cookpad Tech Kitchen #15 〜料理動画・広告のBtoB領域の開発事情〜」を開催しました。クックパッドではこのイベントを通して、技術やサービス開発に関する知見を定期的に発信しています!

第15回の今回は、最近リリースをしたクッキングLIVEアプリ「cookpadTV」をはじめとした料理動画事業の開発の裏側や、クックパッドの広告配信周りの開発について等をテーマに、7名が登壇しました。アプリからバックエンドまで具体的な事例を用いてたっぷりとご紹介したイベントの様子をお届けします🎉

cookpad.connpass.com

クックパッドの料理動画事業をご紹介🎬

まずはクックパッドの料理動画事業を簡単にご紹介します。

クッキングLIVEアプリ「cookpadTV」
ライブ配信を見ながら、プロの料理家やシェフから料理を学んだり、有名人と一緒に料理を楽しむことができるアプリです。コメント機能を使ってわかりづらいポイントをその場で質問でき、双方向型コミュニケーションを実現した新しいクッキングアプリとなっています!また、クックパッドに投稿されているレシピの1分動画もご覧いただけます。ぜひ使ってみてくださいね ♪
App Store: https://itunes.apple.com/app/id1344736966
Google Play: https://play.google.com/store/apps/details?id=com.cookpad.android.cookpad_tv

「cookpad storeTV」
全国のスーパーマーケットなどの流通チェーンと連携し、店頭の生鮮売り場にクックパッドオリジナルのサイネージ端末設置して料理動画を配信するサービスです。2018年1月より、大手食品・飲料メーカーの商品を活用した料理動画広告のトライアル配信も開始しております。あなたのお家の近くの店舗でも見られるかも!

詳細はこちら:~クックパッド、料理動画事業に本格参入〜第1弾は『cookpad storeTV』大手流通チェーンと連動し、売場で料理動画を配信12月より日本全国のスーパーマーケット約1,000店舗にてスタート

「cookpad studio」
クックパッドスタジオは、クックパッドのレシピ投稿者が自分のレシピを動画にするために、無料で利用できる動画撮影スタジオです!動画の撮影経験がない初心者の方でもクオリティの高い料理動画の制作が可能です。完成動画はクックパッド内で公開できるほか、Instagramをはじめとする個人のSNSにも投稿することが可能です。昨年12月に東京・代官山に1号店をオープンし、今年5月には心斎橋に2号店をオープン予定です!
公式ページはこちら:「cookpad studio」

これらの事業に沿って、それぞれのメンバーが何を開発しているのか、どんな技術を使っているのか、何を目指しているのかといった内容をお話しました。

f:id:mamiracle:20180423214451j:plain (cookpad storeTVのサイネージ端末)

cookpadTVのライブ配信の裏側

まずはじめにAndroidエンジニア石本と、サーバーサイドエンジニア長田からクッキングLIVEアプリ「cookpadTV」のコンセプトやアプリ構成についてお話しました。LIVE配信・コメント・いいね機能などに関する技術的課題と工夫についてお話しました。

speakerdeck.com


speakerdeck.com


cookpadTVのアプリ開発〜現状とこれから〜

iOSエンジニアの鶴川からは、クッキングLIVEアプリ「cookpadTV」の技術構成や、今後の展望についてお話しました。現在はプラットフォーム間での挙動や体験の違いを、技術的アーキテクチャの統一により解決することを目標にしており、それを前提に置いた基盤開発の工夫についてもご紹介しました。

speakerdeck.com

cookpad storeTVの開発事例

サーバーサイドエンジニアの三浦からは、動画サイネージ事業「cookpad storeTV」の開発事例をご紹介しました。ユーザー(店舗でのサイネージ端末運用者)が使いやすいサービスの設計や、それを実現するために工夫した技術についてお話しました。

speakerdeck.com

cookpad studioでの撮影環境について

iOSエンジニアの氏からは、ユーザー向け料理動画撮影スタジオ「cookpad studio」での、カメラ選定や通信方法などといった撮影環境構築についてお話しました。撮影に適した環境をつくるまでのガジェット選定や設計の工夫などについて詳しくご紹介しました。

speakerdeck.com

動画事業でのデータ収集、分析、活用

サーバーサイドエンジニアの今井からは、動画サイネージ事業「cookpad storeTV」のログの活用方法についてお話しました。当時苦戦してた課題から、現在導入しているTableau®の事例までをご紹介しました。

speakerdeck.com

cookpad storeTV 広告配信 いままでとこれから

サーバサイド / Androidエンジニアの中村からは、動画サイネージ事業「cookpad storeTV」における広告配信についてお話しました。店舗に設置したサイネージに動画広告の配信をしており、これからは imp ベースで行っていきます。

speakerdeck.com

付箋形式でお答えするQ&Aディスカッション😊

Cookpad Tech Kitchenではより気軽に質問をしていただくために、付箋で質問を集めています。この日はメディアプロダクト開発部長 渡辺が司会となってQAディスカッションを行いました。

f:id:mamiracle:20180423214502j:plain (付箋に質問を貼ってもらいます)

アプリのアーキテクチャでAndroidとiOSで統一することでUXを統一できる理由が知りたいです

アーキテクチャを統一することで、API へのリクエストタイミング、エラーハンドリング等の設計がプラットフォーム間で共有出来るようになるからです。そうすることで、ローディングの時間やエラーダイアログの表示等をあわせやすくなり、結果的に UX を似せることが出来ます。

cookpadTVのアプリ開発が少数精鋭で驚きました。レビューはどうして回していたのでしょうか?

レビューに関しては正直自分達のチームだけでは回しきれない部分があったので、技術部モバイル基盤チームのメンバに手伝って貰っていました。

ログの量が多そうですがデータ量削減のための工夫はしていますか?(圧縮形式など)

クックパッドのログ基盤はしっかりしているので、サービス側から送るログの量を制限して欲しいという依頼は来たことがありません。そのため、データ量削減の工夫はしていません。

ほんの一部ではありますが、上記のような質問にお答えしました!

シェフの手作り料理🍳

Cookpad Tech Kitchen ではおもてなしの気持ちを込めてシェフ手作りのご飯を振る舞っています!食べながら飲みながらカジュアルに発表を聞いていただけるように工夫しています。みなさまも次のイベントはぜひ遊びに来てくださいね。

f:id:mamiracle:20180423214534p:plain (オリジナルロゴケーキと陳麻婆豆腐焼きそば)

f:id:mamiracle:20180423214521p:plain (いつも美味しいご飯を作ってくださる川嶋先生)

クックパッドでは仲間を募集しています😊

今回のイベントでは、最近リリースした、料理動画事業や広告事業に関する新規サービスについてご紹介しました。ぜひこれを機にみなさまにもクックパッドの料理動画サービスを使っていただけたら嬉しいです。

そしてクックパッドでは料理動画事業や広告事業、その他新規事業、レシピサービス事業などに携わる新しい仲間を募集しています!クックパッドで「毎日の料理を楽しみにする」ことに興味を持ってくださった方は、ぜひ下記のリンクからご応募もお待ちしております。

Android アプリケーションエンジニア(料理動画・広告配信)

バックエンドエンジニア(料理動画・広告配信)

iOSアプリケーションエンジニア(料理動画・広告配信)

また、今後のイベント情報についてはConnpassページについて随時更新予定です。イベント更新情報にご興味がある方は、ぜひメンバー登録をポチっとお願いします!

cookpad.connpass.com

料理をつくる人はどんな課題を抱えているのか? 〜ユーザーの課題を施策につなげるインタビューの取り組み〜

こんにちは。投稿開発部 ディレクターの五味と申します。 初日の記事から5日間に渡ってお届けしてきた「クックパッド MYキッチン」の連載も、いよいよ今回が最終回です!

私たち投稿開発部では、クックパッドユーザーの中でも特に「レシピを投稿するユーザー」にとって最適なアプリを追求するために、「クックパッド MYキッチン」アプリをリリースしました。ではこれからそこで、ユーザーにどのような体験や機能を提供していくべきでしょうか。

今回は、ユーザーの課題を起点に次の施策を発想していくために行なっている、ユーザーインタビューの取り組みについて紹介します。

f:id:natsuki53:20180419194028p:plain App Store / Google Play

料理をつくる人はどんな課題を抱えているのか

投稿開発部は現在「クックパッドにレシピを投稿するユーザーを増やすこと」を目標とし、その戦略として「レシピ投稿の継続率を改善すること」と「レシピを投稿し始める人を増やすこと」の2点に注力することを決めています。

施策を考える上では、目先の数字を稼ぐのではなく、レシピ投稿を、何らかユーザーの課題を解決する、ユーザーが使いたくて使う手段にすることを重視しています。それを実現する指針を得るためには、料理をつくる人が抱えている課題を知り、できるだけ深く理解をする必要があります。

チームではそのため、アプリ開発と同時並行でユーザー調査を進めてきました。

調査の計画:ユーザーの実際をもっと知りたい

ところで投稿開発部は2018年に新設された部署です。メンバーは部長含め、サービス開発の経験はあれど、レシピ投稿者にフォーカスして取り組むのは初めての面々でした。さらに部内には、ユーザーインタビューを通してユーザーの課題を発見するための設計をしたことがある人もいません。そのため、部の発足当初から、定性的なユーザー調査に積極的に取り組むことは計画していました。

2月に入り「クックパッド MYキッチン」アプリの開発目処が立ってきた段階で、計画の実行に着手しました。投稿開発部のメンバーは7名と多くはないのですが、知見を自分たちのものにするためにも、インタビュー対象者のリクルーティングからすべて自分たちの手で行うことにしました。

まず有効な調査手法を手っ取り早く学ぶため、『ユーザビリティエンジニアリング*1』を参考図書とさせていただきました。書籍を読んで、サービス開発で重用する定性的ユーザー調査は大きく3つに大別されると考えました。

▼私の理解は以下の通りです f:id:natsuki53:20180419192007p:plain

当時ようやく主要機能が動くようになっていた「クックパッド MYキッチン」アプリがある状況で、投稿開発部としてユーザー調査を始めるなら、そのアプリを用いたユーザビリティテストから行うことが順当に思えました。

開発チーム全員が参加するインタビューに

インタビューを始めるにあたり意識していたことが、この取り組みにエンジニア含めたチーム全員が直接関わり、ユーザー理解を一緒に深められるようにすることです。

そのため、すべてのインタビューに中継機材とカメラを用意し、別室に待機するチームメンバーがインタビューの様子を同時中継で見られるようにしました。モニター室では各自メモを取ってもらいながら、ユーザーに聞きたいことがあれば、ファシリテーター役をしている私のPCにチャットで質問を入れられるようになっています。これによって、メンバー全員が当事者としてインタビューに関わることができるようになりました。

インタビュー開始と早々の方針見直し

ユーザーのリクルーティングや調査票・スクリプトの設計、会議室や機器設置に手間はかかったものの、リハーサルなども行いながら、何とか3週間程度でインタビューの開始に漕ぎつけました。しかも実際テストを開始してみると、新しいアプリは思った以上に円滑に操作され、用意したタスクリストは大きな問題なくこなされ、上々に過ぎていきそうに見えます。しかしその反面、ポジティブな反応も希薄なことが徐々に気がかりになってきました。

チームの興味は段々、アイスブレイクとしてヒアリングしていたユーザープロファイルに移っていきました。思えばチームメンバーにとって、「既存/潜在作者」とされる社外のユーザーにきちんと話を聞くのはそれが初めてだったのです。その人物像や生活背景への自分たちの理解の浅さに気がつくまで、時間はかかりませんでした。

結局私たちはインタビュー開始3日目には、開発中のアプリのユーザビリティよりもずっと前の段階に自分たちの問題点があると判断し、テストは早々に切り上げ、ターゲットユーザーの日常生活に潜む課題を見つけるための生成的調査へ転換することにしました。

生成的調査の試行錯誤

既に存在するプロトタイプの調査をするユーザビリティテストに比べ、まだ目に見えないユーザーの課題を対話の中で引き出す生成的調査は、難易度が高いと思います。この種のインタビューは漫然と行うと、得られる学びも漫然のまま終わることは経験してきているため、やるからには確固たる学びを得たいと考えていました。

- 苦慮したポイント1:設問設計

設問設計には当初から苦心しました。先述の『ユーザビリティエンジニアリング』には、ユーザーとの対話の中からキーワードを見つけて根掘り葉掘り質問をしていく手法をお薦めされており、「事前にインタビューガイドを作っても絶対にその通りにインタビューするな」と書かれています。しかし私たちのインタビュー対象者は、普段実際にクックパッドをご利用いただいているユーザーさんでもあるので、会話が途切れたり失礼を働くことが怖くなってしまい、結局、電話営業のトークスクリプト並みにがっちりと設問を並べた台本を用意してしまいました。

- 苦慮したポイント2:インタビュー後の振り返り

インタビュー後の振り返りの仕方にも悩みました。そもそもの課題抽出を目的とする生成調査は、検証調査やユーザビリティテストのように、答えを出す項目が先に存在するわけではありません。事前に想像できる範囲には限りがあるため、結局最初の1〜2回のインタビューを実地演習と割り切っていくつかの手法を試すしかありませんでした。

振り返りは、モニター室でインタビューを見ていたメンバーのふせんメモとホワイトボードを使うのが効率的です。ふせんメモをネガティブ/ポジティブで整理してみたり、対話中に見せたプロトタイプの種類別に整理してみたり、いくつかパターンを試した結果、ユーザーに語られたエピソードからメンバー各自気になったものを出し合い、「事実」と「(ユーザーご自身の)意見」に分けて整理する手法に今は落ち着いています。

「事実」「意見」ごとにKJ法を用いて重要そうなキーワードを見出したら、その周辺のエピソードを洗い出し、背景にある動機を想像して、各対象者が持っている「料理に関する課題」を推察して書き出せたら、その回の振り返りは完了です。

▼振り返り時の板書のイメージ(内容は架空です) f:id:natsuki53:20180419192140p:plain

振り返りの手法が固まると、インタビューの構成も、こちらが用意する質問に広く浅く答えてもらうのではなく、ユーザーの言葉で普段の料理や食事を取り巻く状況を語ってもらうものになっていきました。それに従い、設問もおのずとシンプルになります。当初20問近くあった設問が、最終回のインタビューでは2問まで減ったのは、とても印象的な出来事でした。

f:id:natsuki53:20180419192214p:plain

得た学びを確実にする作業:総括レポート

ユーザーの普段の料理の状況を根掘り葉掘り聞き出し、インタビューごとにチームで振り返りを行って、彼らが料理に関して持っている重要な課題を書き出す手法により、個別のインタビュー対象者ごとの理解は深められるようになりました。対象にしたユーザーごとに書き出した課題をリスト化して、次の施策を考えるネタにもできそうです。

しかし、インタビュー全体としての評価はどうでしょうか?得られた学びが何だったか、明言はできるでしょうか?コストをかけてしっかり行ったインタビューなので、結果はうやむやにせず、チーム全員で得た学びを確実にものにしたいです。

そこで私たちは、普段プロジェクトごとに作成している施策設計・評価用のレポート「report.md*2」を、インタビュー調査でも作成するようにしました。

インタビュー調査は機能開発とは施策設計が異なるため、report.mdの構成も少々見直し、以下の項目で作成しています。

- 目的
- 対象ユーザー
- スクリプト
- 議事録
- 結果
- 次のアクション

インタビュー調査の計画時・完了時にこのレポートをGitHub Enterpriseの自部署のリポジトリにPull Requestで作成し、チームメンバーにレビューしてもらいます。こうして1枚の簡潔なレポートにまとめることで、調査計画も、全回のインタビューを経た考察や結論も明確に提言され、またチームメンバー間での理解の差も埋められ、結果を次の施策に生かしやすくなりました。

「クックパッド MYキッチン」での検証へ

私たちはいま、このインタビュー調査から得たユーザーの課題リストを元に、次に注力するユーザー課題を絞って取り組んでいます。メンバー全員が一連のインタビューの様子や結果を共有しているため、調査以前に比べてターゲットの人物像から具体的に解決策のイメージが湧くようになったことを実感しています。

ここから得た理解やアイデアを元に、次の施策のプロトタイプを鋭意進めています。近日中に「クックパッド MYキッチン」アプリで検証を始める予定でおりますので、リリースを楽しみにお待ちください。

アプリのインストールはこちらから! App Store / Google Play

終わりに

5日間に渡りお届けしてきた「クックパッド MYキッチン」の連載記事、いかがでしたでしょうか。最後に今一度、これまでの連載記事と、執筆した開発メンバーを紹介させていただきます!

クックパッドMYキッチンアプリ、ならびに、投稿開発部にご興味を持ってくださった方、一緒に開発に取り組んでくださるメンバーを募集中です!

採用サイトまで、お気軽にお問い合わせください!!

*1:橋本徹也 著『ユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法』amazon

*2:クックパッドのサービス開発チームで行なっている、施策レポートの取り組み。詳細は私の昨年の記事で触れています。

/* */ @import "/css/theme/report/report.css"; /* */ /* */ body{ background-image: url('https://cdn-ak.f.st-hatena.com/images/fotolife/c/cookpadtech/20140527/20140527163350.png'); background-repeat: repeat-x; background-color:transparent; background-attachment: scroll; background-position: left top;} /* */ body{ border-top: 3px solid orange; color: #3c3c3c; font-family: 'Helvetica Neue', Helvetica, 'ヒラギノ角ゴ Pro W3', 'Hiragino Kaku Gothic Pro', Meiryo, Osaka, 'MS Pゴシック', sans-serif; line-height: 1.8; font-size: 16px; } a { text-decoration: underline; color: #693e1c; } a:hover { color: #80400e; text-decoration: underline; } .entry-title a{ color: rgb(176, 108, 28); cursor: auto; display: inline; font-family: 'Helvetica Neue', Helvetica, 'ヒラギノ角ゴ Pro W3', 'Hiragino Kaku Gothic Pro', Meiryo, Osaka, 'MS Pゴシック', sans-serif; font-size: 30px; font-weight: bold; height: auto; line-height: 40.5px; text-decoration: underline solid rgb(176, 108, 28); width: auto; line-height: 1.35; } .date a { color: #9b8b6c; font-size: 14px; text-decoration: none; font-weight: normal; } .urllist-title-link { font-size: 14px; } /* Recent Entries */ .recent-entries a{ color: #693e1c; } .recent-entries a:visited { color: #4d2200; text-decoration: none; } .hatena-module-recent-entries li { padding-bottom: 8px; border-bottom-width: 0px; } /*Widget*/ .hatena-module-body li { list-style-type: circle; } .hatena-module-body a{ text-decoration: none; } .hatena-module-body a:hover{ text-decoration: underline; } /* Widget name */ .hatena-module-title, .hatena-module-title a{ color: #b06c1c; margin-top: 20px; margin-bottom: 7px; } /* work frame*/ #container { width: 970px; text-align: center; margin: 0 auto; background: transparent; padding: 0 30px; } #wrapper { float: left; overflow: hidden; width: 660px; } #box2 { width: 240px; float: right; font-size: 14px; word-wrap: break-word; } /*#blog-title-inner{*/ /*margin-top: 3px;*/ /*height: 125px;*/ /*background-position: left 0px;*/ /*}*/ /*.header-image-only #blog-title-inner {*/ /*background-repeat: no-repeat;*/ /*position: relative;*/ /*height: 200px;*/ /*display: none;*/ /*}*/ /*#blog-title {*/ /*margin-top: 3px;*/ /*height: 125px;*/ /*background-image: url('https://cdn-ak.f.st-hatena.com/images/fotolife/c/cookpadtech/20140527/20140527172848.png');*/ /*background-repeat: no-repeat;*/ /*background-position: left 0px;*/ /*}*/