Cookpad Product Internship 2018 の振り返り

新規サービス開発部の出口 (@dex1t) です。普段はデザインからアプリ開発まで、新規サービス立ち上げに必要なことを浅く広くやっています。

さて、R&Dインターン技術インターンに続きまして、9月10日~14日にかけてデザイナーとサービス開発エンジニア向けのプロダクトインターンシップを開催しました。私は本インターンの全体設計と講師を担当しました。この記事ではその内容を簡単にご紹介します。

f:id:dex1t:20180926223117j:plain

このインターンはざっくりいうと、デザイナー・エンジニアでペアを組み、ゼロから"使える"サービスを作るという内容です。なかなかハードですね 😉

今年は「一人暮らししている人の料理が楽しみになるサービス」というテーマで、5日間のサービス開発を実践していただきました!

Day 1-2. 基礎編 ✍🏻

1日目から2日目午前は、「サービス開発を実践するための道具を提供する」という建て付けで、講義やミニワークを行いました。

ざっくり以下のような内容で、体験やコンテキストといったサービスデザインに関する抽象的な話から、サービス開発における具体的な手法・ツールまで駆け足で網羅しました。

  • サービスとは?体験とは?
  • サービス開発におけるマインドセットとプロセス
  • ユーザー理解
    • ワーク: ユーザーインタビューの実践
  • アイデア発想と言語化
    • ワーク: 価値仮説とストーリー作成
  • 試作とテスト
    • ワーク: ペーパープロトタイピング、アクティングアウト

サービス開発に初挑戦の方も多くいたこともあり、調査・発想・試作・試行の各ステップをなるべく丁寧に説明しました。実際の講義資料 (公開可能分のみ) はこちらです。

Day 2-5. 実践編 💪

2日目の午後からはいよいよテーマに沿って実践編のスタートです。

参加者の方にはテーマだけをお渡しし、具体的にどんなサービスを作るのか、言い換えるとどんな問いを立てるのか、その解き方も含めて、全てチーム毎に自ら考えて実行してもらいました。各チームには現場のデザイナーが専属メンターとして付き、全力でチームをサポートします。

序盤

肌感覚をつかむための最初の一歩として、インタビューを各チーム自発的に行っていました。参加者同士でのインタビューはもちろん、その場にいる社員を捕まえたり、電話インタビューしたりと、限られた時間のなかでインプットを増やすために各チーム工夫して動いていました。

f:id:dex1t:20180911180345j:plain

中盤

インタビューを繰り返し、課題が見えはじめたところで、次はコンセプトの設計です。メンターに企画案を壁当てしながら、各チーム頭を悩ませていました。コンセプト設計には、価値仮説シートやストーリーシートなど、初日に講義の中で紹介した道具を活用してもらいました。

f:id:dex1t:20180911180304j:plain f:id:dex1t:20180911175934j:plain

三日目の午後は中間発表です。ここでは企画案とその動作モックを使って、アクティングアウト形式での発表を必須としました。アクティングアウトは体験のプロトタイピングとも呼ばれる手法で、寸劇形式でサービスの利用体験を表現することで、そのリアリティの有無を確かめることができます。

この中間発表の様子は、動画撮影をして発表者自身にも確認してもらいます。こうすることで、この時点での企画案を客観視することができ、自らの判断で軌道修正するチームも見られました。

また講評者の観点では、テキストベースの企画書を読み込むよりも寸劇形式のほうが理解しやすく、より本質的なフィードバックに集中できるという利点もあります。

f:id:dex1t:20180914171016j:plain
即席の名札で登場人物を演じ分けているチームも

終盤

終盤はいよいよ実装です。残り少ない時間の中で、実装すべきところはどこなのか、どこを捨てるのか判断するのはサービス開発エンジニアの腕の見せ所です。弊社オフィスのキッチンで、自分たちのプロトタイプを試しに使いつつ料理するチームも出てきました。

f:id:dex1t:20180911180620j:plain

最終発表

5日目の夕方には最終発表として、成果物のデモを中心に発表してもらいました!タイトなスケジュールのなかで、全チーム何らかの形で試すことができるサービスが出来上がっていて素晴らしかったです。

f:id:dex1t:20180914174147j:plainf:id:dex1t:20180914173128j:plain

最終発表では、弊社CTOやデザイナー統括マネージャーを含む5名が審査員となり、優秀賞1チームを選ばせていただきました。

優勝チームは「その場限りのコミュニティでの料理通話体験」というコンセプトで、通話をしながら料理が楽しめるアプリの提案でした。デザインの観点では「料理経験が浅く失敗が多い」「1人で作って1人で食べるのが孤独」というマイナスをただ埋めるだけでなく、「失敗やハプニングも含めてみんなで楽しもう」という考え方でプラスに転換している点を評価しました。また、赤の他人との料理通話をどうアイスブレイクするかといった細かい配慮が、UIとしても表現できており素晴らしかったです。エンジニアリングの観点では、時間が無い中で「通話しながら料理する」という多くの人にとって未知な体験を、実際にその場で試せるクオリティで仕上げた点を高く評価しました!

f:id:dex1t:20180914191259j:plainf:id:dex1t:20180914210033j:plain

最後は懇親会で終了しました!チェキコーナーも人気 ✌️

ということで、5日間でゼロからサービス作りをするというハードな内容でしたが、皆さんやり切っていただけました👏👏👏

プロダクトインターンシップで伝えたかったこと

ここからは裏話として、インターンの設計面についてです。今回5日間に渡って講義や実践を行いましたが、伝えたいことは大きく3つありました。

リアリティのある仮説をもつ

サービス開発は正解がなく、「やってみないと分からない」が大前提なのですが、無闇にやればいいという訳でもなく、仮説の質を上げるのが大事なポイントです。

良い仮説 (企画) とは何なのか。非常に難しい問題で私も分かりませんが、そのひとつにリアリティがあること、企画を聞いただけでサービスを使う情景がありありと目に浮かぶことは必要条件であると私は思います。(十分条件ではない😑)

講師側としては、問いの立て方をインターンシップで教えることは難しく、1day形式など特に時間が限られるワークショップでは、問いが立てやすいように仕立てた材料を、ペルソナのような形で渡しています。

ただし現場のサービス開発では、ペルソナが上から降ってくることはあり得ません。自分たちで情報を取りに行き、肌感を掴むことが求められます。

そのやり方も現場では人それぞれ様々ですが、今回は最も汎用的なツールとして、ユーザーインタビューを実践してもらいました。各チーム自ら工夫して情報を取りに行き、自分たちで見聞きした一次情報を元にしているからこそ、リアリティのある仮説が立てられることを体感してもらえたかな、と思います。

とりあえずやってみる

今回講義の冒頭では、次のようなインターン中に求める姿勢を明文化しました。過去に開催したこの手のワークショップでの反省も踏まえてなのですが、コンセプトワークだけでなく実際のモノに落とし込む部分を強く求めました。

f:id:dex1t:20180926224726p:plain

この3つは、デザインファーム IDEOのValuesから表現を一部借りています。余談ですが、このValuesは新規サービス開発をやってる人間としてすごく共感できます。

やってみないと分からない状況下では、長々と議論やブレストをしても非効率になり得ます。荒削りでも良いので一度形にしてみると、正解でなくても、その形が間違っていることは最低限分かります。そうして徐々にボケた輪郭をシャープに描いていく姿勢は大切です。

試作と試行を繰り返す

また形にするのは一度限りではありません。それを壊してまた作ってを繰り返すのがサービス開発の基本姿勢です。今回最終発表で評価が高かったチームはいずれも、プロトタイプを何らかの形で自分たちで試してみたチームでした。今回優秀賞となったチームは、初対面の社員を捕まえて実際に電話しながら料理したり、帰宅後もお互いに通話しながら料理したりと、試行錯誤を繰り返しつつサービスを形づくるプロセスも素晴らしかったです。

f:id:dex1t:20180926224914p:plain
インターン生 (奥) が初対面の社員 (手前) と通話しながら料理する様子

5日間という現場以上にハードなスケジュールなこともあり、繰り返しができても1, 2回だったことは講師としての反省点でした。またインターンの制約上、テストする対象が自分たちや社員止まりでしたが、本来は実際の想定ユーザーにテストできるとベストです。これらの点は来年のインターンシップでは改善できればと思っています。

まとめ

今回のサマーインターンシップでは、講師により仕立てられたサービス開発ではなく、より実践的なリアリティのあるサービス開発を体感していただけたかな、と思います。参加していただいた皆さま、本当にありがとうございました!!

また、このようなサービス開発は現場でももちろん実践しています。新卒・中途問わず、ご興味あるかたは各ポジションにご応募いただくか、@dex1t までお声がけください 🙌

Cookpad Summer Internship 2018 10 day 技術インターンシップ を開催しました

技術広報を担当している外村(@hokaccha)です。

クックパッドでは毎年恒例となっているサマーインターンシップのうち「10 day 技術インターンシップ」を開催しました。今年は8月6日〜8月17日、8月27日〜9月7日という日程で二度開催し、たくさんの学生の方に参加していただきました。

f:id:hokaccha:20180828130243j:plain

今回の 10 day 技術インターンシップは、前半5日が講義パート、後半5日はOJTコースとPBLコースに分かれるという構成でした。OJTコースではクックパッドの現場に配属され、メンターの指導のもとサービス開発を実践してもらい、PBLコースではチーム開発でプロジェクトを運営していく手法について学びながら、サービス開発の実習に取り組んでもらいました。

前半パートでの講義について資料を公開いたします。

1日目: 基礎技術

初日はインターンで必要になる基礎的な知識の足並みを揃えるために、GitやRuby、JavaScriptなどについての講義を行いました。

2日目: サービス開発

2日目は、毎年恒例となっているサービス開発の講義で、コードは一行も書かずクックパッドで実践されているサービス開発の手法を実践してもらいました。プロトタイピングやユーザーインタビューを通じてサービスの設計をしました。

3日目: API(サーバーサイド)

3日目はRailsを使ったWebアプリケーションの講義です。今回のお題はチャットアプリケーションで、途中まで実装したRailsアプリケーションこちらで準備し、そのアプリケーションを完成させたり、思い思いの機能を実装してもらいました。

4日目: ReactNative

4日目は、3日目に作ったチャットアプリケーションのクライアントアプリをReactNativeとTypeScriptで作るという内容でした。Expoを使い、簡単にネイティブアプリの開発を始められるという体験をしてもらいました。

cookpad/cookpad-internship-2018-summer react-native - GitHub

5日目: インフラ

最終日のインフラの講義では、AWSやDocker、パフォーマンスチューニングなどの基礎的な知識について解説し、3日目に作ったRailsのアプリケーションを高速化するという課題に取り組みました。サーバーのパフォーマンスをコンテスト形式でスコアを競い、大変盛り上がりました。

cookpad/cookpad-internship-2018-summer infra - GitHub


全員が真剣に講義に取り組み、後半のOJTコースとPBLコースでの実践に活かしてくれました。参加していただいた皆様、本当にありがとうござまいました。

クックパッドアプリはみんなが寝ている間にサブミットされる

こんにちは、技術部モバイル基盤グループの茂呂(@slightair)です。 先日のiOSDCは大盛況でしたね。とても楽しく、実りあるカンファレンスでした。この記事で僕は ididblog! ということにしようと思っています 😋

クックパッドからは @giginet と僕の二人が登壇しました。発表を聞きに来ていただいた方はありがとうございました。 @giginet詳解Fastfile という発表中でさらっと話された、”毎週自動的にリリースされる”という言葉が気になった方はいるのではないでしょうか。実はこのリリースフローについての話もプロポーザルに出していたのです(もっともっと細かくリリースをしてユーザーに最速で価値を届けるためのリリースフロー)。

この記事ではこのリリースフローについての話をしたいと思います。

クックパッドアプリの開発体制

クックパッドアプリの開発体制は人数の変動はあるものの、ここ数年で大きく変わっているものはありません。 この記事にあるように、モバイルアプリを専門で開発するようなチームはなく、有料会員獲得やレシピ投稿、検索結果の向上などを目的とした部署に所属するエンジニアがそれぞれの目的に合わせた機能追加・修正のPRを出しマージして定期的にリリースする、というスタイルを続けています。

開発環境のメトリクスとして記録している数字を見ると、最近では各リリースごとにだいたい10数人のコミットが含まれているようでした。この数字にはアプリのコードを書くエンジニアだけでなく、テストエンジニアや画像リソースなどを変更するデザイナー、更新文言やアプリの説明文などを編集するディレクターの数も含まれます。

以前のリリースフロー

基本的には前述の記事で説明しているように開発期間やテスト期間などの日を細かく決め、その期間で各チームが開発を行い、コードフリーズ後に動作確認を行ってサブミット、審査が通ればリリース、というフローを回していました。1イテレーションはだいたい2週間のペースです。ひとつのイテレーションが終わると開発関係者で集まって振り返りを行い、課題や改善点が見つかれば次のイテレーションで解決するというのを繰り返すことで、不具合を抑え安定したペースでリリースし続ける状況を維持していました。このフローは僕たちの組織構造にも合っていて長年うまくいっていたリリースフローなのですが、問題もありました。

ひとつめはリリースマネージャーの負担が大きいことです。リリースマネージャーというリリースに責任を負う人物を立てて、問題なくリリースが行えるように部署間の施策の調整をしたり、スケジュールの調整を行う役目を担ってもらっていました。次のリリースに入るはずの機能がマージできていないときに関係者をつっつくような役目も持っていたので、とにかく細かい作業や人間の間の調整で忙殺されてしまうのです。リリースマネージャー役を関係者間で交代するようにしたり、リリース作業とリリース進行役を別の人間で分担するようにもしてみましたが、手順がまとめられていても人によってケアの仕方に差がでたり関係者が増えることによる負担は増加する一方でした。

ふたつめはだいたい2週間に一度のリリースのペースを守ろうとしていてもばらつきが起きていたこと、場合によってリリース間隔が開いてしまっていたことです。ある部署の大事な施策の開発が遅れているのでリリーススケジュールを遅らせたい、広範囲にわたる変更があるので他の部署の開発は次のリリースでは我慢してもらいたい、というようなリリースごとの特別対応が求められるケースがたびたび発生していました。そのような調整作業をまとめているリリースマネージャーがさらに疲弊してしまったり、想定のリリーススケジュールが守られず期待していたタイミングで機能を提供できない、価値検証がうまく行えない、タイミング次第では検証に基づく変更を反映するのに時間がかかりすぎてしまうというチームが出てしまう状況でした。

つまり、リリースマネージャーを立てて様々なケースに融通が利くようなフローにしていた結果、当事者間の調整コストが高まって色々な問題を引き起こしていたのです。

新しいリリースフローは「機械に人間が合わせる」

当事者間の調整でみんなが苦しんでいるのがわかったので、この「調整」を無くすことはできないだろうかと考え始めました。もう調整はしない!

そこで僕たちは可能な限りサブミット・リリース作業を自動化する仕組みを構築し、人間が動かなくても自動でアプリがサブミットされる状況を作ることにしました。 タイミングが来ると自動でサブミットを行うジョブが実行されるのでそれに合わせて開発するスタイルです。人間たちの準備が整ってからサブミットを実行するのではなく、機械のペースに人間が合わせて行動するということです。開発が間に合わなかったら次のリリースには入れられるように頑張ってね、という感じになります。

具体的にはこのようなルールで運用しています。

  • リリース予定日は毎週月曜日と仮定する
  • バージョン番号には 年.リリース予定日の週番号.パッチ番号.0 を採用する
    • 基本的に再サブミットを行わないのでパッチ番号は 0 になる
  • 毎週金曜AM2:00にサブミットジョブを実行し、その時点のmasterブランチの内容をビルド、サブミットする
  • サブミット後に開発関係者各自で動作確認を行いリリース判定を行う、あわせてAppleの審査を通過したらリリースを行う
    • もし致命的な不具合が見つかったり、バイナリの変更が必要な理由で審査に落ちたらそのバージョンのリリースをあきらめ、次のバージョンで問題を解決する
    • ある程度の不具合を許容する。リリースサイクルが早いので次の機会で確実に直せればよいと考える。
  • master ブランチには確実にリリース可能なコードのみをマージする。もしマージ後に問題が発覚すれば即リバートする。

「機械に人間が合わせる」というコンセプトでリリースフローを設計したので、ある意味ドライな意思決定がされるようになった部分もありますが、思い切った変更により自動化できる箇所が増え、開発者の負担を減らしたり毎週というリリースサイクルでも回せるようになりました。

このリリースフローに切り替えてから、毎週金曜日に出社したり仕事を始めようとするとサブミットが終わっている状況になっています。早いときは審査が終わっている場合もあります。ジョブの実行を金曜の早朝に設定している理由は、なにかサブミット作業で問題が起きたときに金曜日中に対応できるようにするためです。

f:id:Slightair:20180913183311p:plain

自動化しているもの、機械がやってくれること

以下のタスクを自動化しています。実際のサブミット作業だけでなく、このリリースフローを安定して回したり当事者間のコミュニケーションを促進する施策を実行します。

  • 更新文言(fastlane/metadata/ja/release_notes.txt)の変更があるか確認
    • AppStoreReviewガイドラインの最近の変更(2.3.12)のため、毎回同じ更新文言を出さないようにしている
    • 各チームから文言を決めるissueに書き込んだり、PRを出してもらう形にしている
    • サブミットジョブの終わりでテンプレートファイルを用いてリセットする。diffがなかったらサブミット失敗として扱う。
  • リリースに含まれるコミットをしたメンバーをリストにしたリリース前確認issueをGHEに作成する
  • git タグを作成する
  • アプリをビルド、サブミットする (fastlane deliver)
  • アプリのバージョンを更新しリポジトリにpushする
  • GHEへ次の次のマイルストーンを作成する
  • groupad(社内Wiki)に次のバージョンのリリース内容を記述するページを作成する
  • サブミットしたアプリと同等のバイナリをRC版としてビルドし、haneda(社内アプリ配信サービス)にアップロードする

一連の作業は fastlane と Jenkins で実現しています。人間がやる作業はアプリを開発したりメタデータを更新すること、動作確認をして全員の確認がそろったらリリースボタンを押すだけです。

アプリの品質管理について

新しいリリースフローに移行する前は、開発後にコードフリーズを行いテストをする期間を設けていました。この期間で開発者が動作確認するのはもちろんですが、テストエンジニアが自動シナリオテストを実行したり重要な機能の動作確認を集中的に行い、不具合を含んだアプリがリリースされてしまうのを防ごうとしていました。この方法ではテストエンジニアがアプリの品質に対して集中的に責任を持って守れる一方、アプリが持つ機能の詳細や新規機能、修正内容を把握した上で動作確認を行う必要があり、情報のキャッチアップにも動作確認にも時間がかかってしまっていました。スケールもしません。

そのため新しいリリースフローに移行すると同時に、開発するチーム単位でも品質をコントロールできるようにする取り組みも始めています。これはリリースサイクルを早めるためにも必要な試みで、機能を開発するチームが自分たちの担当する部分の品質をコントロールしてリリース可否や不具合対応方針を決められる体制のほうが健全であり、結果的にスピードも出るだろうという考えです。

ある程度の不具合を許容すると前節で書きましたが、正確には不具合を見つけたとしてもすべてを解消してからリリースすることを目指すのではなく、不具合とどう向き合うのかも含めて機能を開発しているチームがアプリの品質をコントロールし動けるようにする、ということです。

リリースフローを運用してみて

新しいリリースフローに移行してからだいたい1ヶ月くらい、リリース回数でいうと4,5回行ったところですが、今の所大きな事故はなく、うまくいっています。以前と違いAppleの審査時間が短くなったのもこのリリースフローが成立する理由のひとつです。うれしいですね。

移行してからリジェクトもいくつかありましたが、メタデータリジェクトが多く、この場合は修正してリリースを行っています。 一度だけサブミット後にバイナリに変更が必要な状況になり、どうしてもということでリリース延期を行わずイテレーション内の再サブミットを実行しています。可能な限りこのような特別対応は無いほうがよいと思っていますが今後はどうなるでしょう、様子をみていくつもりです。リリース前確認もすりぬけて致命的な不具合を含んだ状態でリリースしてしまい、1週間は待てないのでそれを修正するための緊急リリースをしたいということもいつかは起こってしまうはず。どういう対応が必要になってくるかはこれから見えてくると思います。

単純にリリース回数が多くなっただけではないということを繰り返し社内でも伝えていますが、調整をしたがる声が時々出てしまっています。難しいですね。気持ちもわかるし、このやり方が定着するにはもう少し時間がかかりそうです。

まとめ

iOSDC では発表できなかった、クックパッドアプリの新しいリリースフローの取り組みについて紹介しました。機械に人間が合わせるというコンセプトをもとに、自動化できるところはとことん自動化し機械にまかせることで、リリースサイクルを早めたり開発関係者の負担を下げられるような努力をしています。このリリースフローが今後もうまく続けられるかどうかはもう少し経ってみないとわかりませんが、なかなかおもしろい取り組みなのではないかと考えています。