2018-09-14

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

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

2018-09-12

レシピ連動調味料サーバー「OiCy Taste」の設計情報を公開、解説します

エンジニア日記

研究開発部のスマートキッチングループ　プロトタイプエンジニアの山本です。専門分野はロボティクスです。
スマートキッチングループでは、 レシピを様々な機器とつなぐスマートキッチンサービス「OiCy」の開発を進めています。今年の５月、OiCyの開発を発表した際に、コンセプトモデルレシピ連動調味料サーバー「OiCy Taste」を公開しました。クックパッドからハードウェアが発表されたことに驚いた方も少なくないかと思います。かく言う私もその一人で、「OiCy Taste」を見てクックパッドのスマートキッチンの取り組みに興味を持ち、この夏からハード系エンジニアとしてプロジェクトに加わることになりました。よろしくお願いします。このエントリでは、このレシピ連動調味料サーバー「OiCy Taste」の設計情報を公開します。

最初に

皆さんは料理をしますか？料理を楽しんでいますか？料理とエンジニアリングはとても良く似ていると私は考えています。レシピが設計図で、材料の調達をして、加工（料理）をして、完成品を顧客に評価してもらう。加工の過程で廃材（生ゴミ）が出るので処分が必要で、設計図通り作ったはずなのに同じになるとは限らない図面や文章に載らないノウハウがあること。エンジニアリングが好きな人間は料理にもハマれると思います。何より、家族が美味しいと言ってくれたときの喜びは、苦労して作った製品やサービスが顧客からイイネって言われたときに勝るとも劣らない喜びだと思います。では、自分自身を顧みて、日常的に料理はしていますがその料理を楽しめているのか？と自問してみると、仕事や育児に追われて時間のない中で、料理をタスクの様に感じて必ずしも楽しめていない事に気が付きました。楽しくて当然のことなのに楽しめていない。この問題をエンジニアとしてどう技術で解決するのか？この気付きを与えてくれたのが、今年５月のクックパッドの[レシピを様々な機器とつなぐスマートキッチンサービス「OiCy」]との出会いでした。

レシピ連動調味料サーバー［OiCy Taste］の設計情報公開の意図について

動画：レシピ連動調味料サーバー「OiCy Taste」
※本品はコンセプトモデルであり現時点で発売の予定はありません。

レシピを様々な機器とつなぐスマートキッチンサービス「OiCy」では、クックパッドに投稿されたレシピを、機器が読み取り可能な形式（MRR: Machine Readable Recipe）に変換して機器に提供します。レシピのMRR化ついては、9/7の大谷のエントリ：OiCyサービス(開発中)の裏側〜レシピのMRR化〜で紹介されています。ぜひそちらも読んでいただければと思います。
さて、レシピ連動調味料サーバー「OiCy Taste」は、スマートキッチンサービス「OiCy」を利用した調理機器のコンセプトモデルです。クックパッドで作りたい料理を検索してレシピを閲覧すると、機器側が連動して簡単な操作でそのレシピで用いる調味料を配合して出すことができます。レシピを見ながらの調味料の配合は、レシピに書かれた分量を自分が作る料理の量に合わせて計算したり、各調味料の蓋を開ける、分量を測る、蓋を閉める、といった細かな作業の繰り返しです。実際料理をしていると、これはこれで結構手間がかかる作業で億劫だったりします。また、料理をしている最中は、手が濡れていたり汚れていたりしますので、音声を使って調味料を出せると手を拭く手間を省けますし、現在している調理作業を中断する必要がなくなり作業の効率性があがります。
本機の公開時、早期の商品化を期待するポジティブな声を多くいただきました。本当にありがとうございます、スマートキッチングループ関係者はますます奮い立っております。一方残念なお知らせになりますが、現時点でクックパッドが本機を製品化して販売する計画はありません。

本機は、レシピを様々な機器とつなぐスマートキッチンサービスOiCyを実証する一つのコンセプトモデルです。クックパッドの目指しているのは『毎日の料理を楽しみにする』ことであり、クックパッドの進めているスマートキッチンは『人間と機器が協調して調理』することを、スマートキッチンレベルの最高位のレベル５に掲げています。しかし、この取組はクックパッド一社だけで達成できるものではありません。料理をする作り手の皆さん、調理家電を開発販売する電機メーカー各社、キッチンを設計施工するハウスメーカー各社など、多くの関係者の協力があって初めて実現できると考えています。今回、レシピ連動調味料サーバー「OiCy Taste」の設計情報を公開するのは、スマートキッチンのムーブメントを盛り上げ、個人企業を問わず、一緒にスマートキッチンの研究開発に取り組む仲間を増やしたいという意図があります。今回公開された情報の利用に制限はありませんので、個人企業で本機のコピー機を開発するなり改良機を開発していただいてもなんの問題もありません。むしろウェルカムですので、その時は一報をいただけるとありがたいです。

免責事項：公開された情報を利用して開発製作行為をした結果生じたトラブルや損失・損害等について、当方は一切責任を問わないものとします。

OiCy Tasteのシステム構成

f:id:ymmttks:20180911143612p:plain — OiCy Tasteのシステム構成

調味料サーバー「OiCy Taste」は、本体上のボタン操作によって選択された調味料を設定量出すことができます。また、スマホのアプリ操作やスマートスピーカーの音声入力を用いて本体に触れることなく調味料を出すこともできます。このような本機のシステムは、上図の構成で実現されています。本機は、ボタン操作やWiFiコマンドにより指定された調味料を指定された量だけ出す様になっています。本体側には非常にシンプルな機能しか持っておらず、複雑な情報処理（レシピ情報から調味料の決定や分量計算、音声操作のための音声認識など）は、スマホアプリやクラウドサービス側で実装されています。そのため、調味料サーバー「OiCy Taste」本体には高度な情報処理を行うプロセッサや高度な認識認証を行うセンサ類は不要で比較的低コストに実現可能な構成になっています。

OiCy Tasteのハード構成

f:id:ymmttks:20180911143603p:plain — OiCy Tasteのハード構成

調味料サーバー「OiCy Taste」のハード構成は上図のようになっています。 4種類の液体調味料が独立した4本のガラスボトルに封入されていて、4つの独立したポンプでボトル内を加圧し液体調味料を押出してノズルから排出します。各ボトルとポンプをつなぐ空気流路は三股になっていて電磁弁が取り付けられています。この電磁弁は、調味料を出し終わった際にボトル内の気圧を大気圧レベルに戻せるようにするために取り付けられています。この電磁弁がないと、ボトルとノズルの間のチューブに液体調味料が残ってしまい、ノズルから残った調味料が垂れてきたりチューブ内で調味料が固まり流路閉塞をおこすなどトラブルの原因となります。
排出される調味料の分量は、ロードセルを用いて重量変化をフィードバック制御し管理されています。調味料の配合は、レシピ上で少々（＝小さじ1/8、1g未満）と記載されるレベルの精度が要求されます。開発初期段階では、単純にポンプの駆動時間によるオープンループ制御も検討されていましたが、要求される精度を実現することが困難で、電磁弁を用いたボトル内気圧の減圧機構が追加されました。イメージビデオでは、４つの調味料が同時に出ている映像が流れますが、これは電磁弁をつける前の状態で、現在の仕様では重量計測が配合調味料を受ける容器一箇所で行われている都合上、複数の調味料を同時に出すことができません。安価な非接触の液体流量センサーなど、いいセンサー情報をお持ちの方は是非教えていただければと思います。なお、４つの液体調味料は、醤油、みりん、日本酒、お酢が選ばれています。これは、クックパッドに投稿されたレシピとそのアクセス頻度などのデーターベースを活用し、最もよく利用される調味料の組み合わせとして選ばれています。
以下が、本機で使用した主要な機構部品と本体メカ部品の3Dデータ（STEP形式）です。一部の機構部品については現在入手が困難になっているものもありますので参考情報になります。また、３Dデータは重量センサーのロードセル対応前かつ電磁弁改良前の仕様になっています。

主な機構部品

OiCy Tasteの3Dデータ

OiCy Taste beta Mechanical design STEP file (9.5MB)

OiCy Tasteの電子回路構成

f:id:ymmttks:20180911143645p:plain — OiCy Tasteの電子回路構成

調味料サーバー「OiCy Taste」の電子回路構成の概要は上図のようになっています。以下、各ブロックごとに解説していきます。実際の回路図は下にリンクしています。

①マイコンボード

機体の制御は、電子工作等でおなじみのESPr® Developer（ESP2866)ボード（以降、ESPrボード）を使用しています。WiFi通信をする装置をプロトタイピングするにあたって、ESP8266や後継のESP32は低コストで導入できる最有力のマイコンボードだと思います。ただし、電源周りで苦労することが多いデバイスですので電源回路の設計、評価に注意が必要です。

②I/O拡張

スイッチやLEDなどのUI周りは、マイコンボードからSPIインターフェイス接続によりSPI I/O ExpanderのMCP23S17を用いて拡張します。マイコンの接続されるI/Oのうち入力は、『醤油』、『みりん』、『料理酒』、『お酢』を選択する4つのボタン入力、調味料を出す『出す』ボタン入力、分量切り替えと調味料を出す操作をするジョグダイヤルで3個の入力が必要で、合計8の入力ポートになります。出力は、『醤油』、『みりん』、『料理酒』、『お酢』の選択対象表示をするLEDが4個、ジョグ操作で切り替えられる調味料の量を表示するLED（小1、小2、大1、大2、大3、大4、連続）が7個、通電状態及びWiFi接続状況を表示するLEDが1個が必要となり、合計12の出力ポートになります。従って、入出力合わせて20個のI/Oが必要になるためマイコンボード単体のI/Oが不足します。そこで、SPI接続可能なMCP23S17を使ってI/Oを拡張するわけですが、MCP23S17で拡張できるI/Oポートは16個のためこれでもポートが不足します。そこで、調味料の出す量を表示するLEDは同時には一つしか点灯しませんので、デコードICの74HC138を使って3bitのI/Oから7個のLEDを制御してポートの不足を補っています。

③モータードライバ

ポンプの駆動は、I2C接続式のモータードライバIC DRV8830を用いています。ポンプのモーターを駆動する場合はモーターの回転方向を制御できる必要はないのでこのようなモータードライバICは必須ではありませんが、I/Oポートの数が限られている中で、DRV8830を使うと複数のモーター（ポンプを）I2Cバス最大9個までぶら下げて個別に回転数を制御できます。もともとは、複数の調味料を同時に出すことを想定して、各ボトルごとに独立したポンプをもたせる設計になっていました。しかし、重量センサーによるフィードバック制御で調味料を高精度に出すようになったことから同タイミングで複数のボトルから調味料を出せる必要性はなくなり、ポンプと電磁弁のコストバランス次第ではポンプを１つにして複数電磁弁による流路切り替えにしたほうが良いかもしれません。抜本的に再設計をする機会があれば、ぜひとも再検討したいところです。

④電磁弁駆動回路

電磁弁は、マイコンボードのI/OポートからFETを介して直接駆動しています。４つの電磁弁を１つのI/Oポートで駆動している回路の都合上、４つの弁は同じタイミングでしか開閉できません。このあたりは、設計データを見渡した際に「なんでこんな微妙な仕様になっているんだろう？」と気がつくところです。なんのことはない、開発の途中で必要になって追加された機能でポートが空いてなかったという話で、ハードウェアの試作開発ではよくある話です。リバースエンジニアリングで設計の時系列を読み解くのが楽しいのはこういう発見があることだと思います。

⑤アナログ回路

アナログ回路部分では、ひずみゲージを用いた重量センサーであるロードセルの出力、増幅、A/D変換しています。ロードセルは非常にデリケートなセンサーデバイスですので、信号はインスツルメンテーションアンプを用いた差動増幅で行っています。この出力を原点調整機能付きのヴォルテージフォロアを介して、I2C出力の12bit ADCにてアナログデーターをデジタル化します。この回路ブロックは、非常にノイズに対してセンシティブなため、基板回路設計において十分なノイズ対策を擦る必要があります。回路図を見るとわかりますが、当初はこのアナログ回路の電源は①のマイコンボードから供給される3.3Vのデジタル電源と共用になっていましたが、WiFi通信をするとこのESP2866のマイコンボードは電源電圧が暴れるためアナログ回路の電源が振られるという最悪の状態になってしまいます。そこで、アナログ回路は電源に自前のLDOを抱える仕様に変更されました。

主な電気部品

OiCy Tasteの回路図（改修指示含む）

OiCy Tasteのファームウェア

本機のファームウェアは、Arudino IDEで開発されています。組み込み系のプロトタイピングツールとしてすっかり定着したArudino IDEですのでESP8266向けの開発環境構築に関する説明は他の詳細に解説しているサイトを参照してください。一般的なArudinoのコードのように、setup()関数で周辺デバイスの初期化処理と内部変数の初期化を、反復的に呼び出されるloop()でメインの処理を行っています。メインループでは、HTTPリスクエスト（WiFiコマンド）の処理と物理UIボタン操作から、実行するべき操作を抽出し、動作に反映させるという処理を行います。このメインループとは独立に、モーターや電磁弁、重量センサーなどリアルタイムに処理する必要がある部分がタイマーtimer0_ISR()により10ms周期(100Hz)で制御されます。また、使用しているライブラリのバージョンアップによって、以前動いていたプロジェクトファイルを再ビルドするとビルドは通ってファームウェア更新はできるけれども実機で正しく動かなくなるという現象が起こります。このあたりはOSSを使っている場合に避けられない問題ですが、スマートな管理解決方法を教えていただきたいところです。以下が、本機のソースコードになります。元々公開を前提としていないプロトタイプ検証用のソースコードですので、アドホックな実装な部分が多々あるところはご理解とご容赦をお願いします。

OiCy Tasteのファームウェアソースコード

OiCy Taste Arudino .ino file (71.3KB)

公開設計情報のGitHubリポジトリ

https://github.com/cookpad/oicy-taste

おわりに

本エントリでは、コンセプトモデルレシピ連動調味料サーバー OiCy Tasteについて設計情報の解説をさせていただきました。
8月9日のプレスリリースで、レシピを様々な機器とつなぐスマートキッチンサービスOiCyのパートナー企業10社を発表しましたが、クックパッドでは「OiCy」と連携した製品やサービスの実用化をパートナー企業様と協力してすすめていきます。今後も、「毎日の料理を楽しくする」コンセプトモデルを開発公開していきますのでご期待下さい。

最後に、クックパッドの研究開発部では、「毎日の料理を楽しみにする」ためのスマートキッチンデバイスを開発提案する仲間を募集しています。ご興味がある方は採用ページを是非ご覧ください。ご連絡をお待ちしております。

− 中途採用：プロトタイプエンジニア（ハードウェア）

2018-09-10

【開催レポ】Cookpad Tech Kitchen #17 〜北欧で最新のインタラクションデザインを学んできた話〜

こんにちは。広報部のとくなり餃子大好き（ id:tokunarigyozadaisuki ）です。

8月22日にCookpad Tech Kitchen #17 〜北欧で最新のインタラクションデザインを学んできた話〜を開催いたしました。クックパッドではCookpad Tech Kitchenを通して、技術やサービス開発に関する知見を定期的に発信しています。

第17回はデンマーク/コペンハーゲンの新興デザインスクール、Copenhagen Institute of Interaction Design (CIID) のサマースクールに参加した社員3名による現地レポート。世界各国から集まったデザイナー、UXエンジニア、PM、研究者……様々なバックグラウンドを持つ参加者とともに過ごした1週間で学んだ、最新のインタラクションデザインについてお話させていただきました。サマースクールの内容だけでなく、それぞれが北欧でみた面白いものやコペンハーゲンという都市の環境についてもご紹介しましたよ。