DMMのサマーインターンに参加した

ãdmmãã®ç»åæ¤ç´¢çµæ

recruit.dmm-corp.com

サマーインターンのURLどこだっけ...?(笑)

 

 

参加した経緯

ジースタイラスさんの逆求人で、DMMと出会った。

www.gstylus.co.jp

自分は、まだ参加すらしてなかったジロッカソンで世界を取ることを約束した。

逆求人なのに、出てすらいなかったハッカソンのアイディアについて、面白そうに聞いて頂きありがとうございました!

mikamimikami.hatenablog.com

そして、世界を取った

この有言実行が実ったのか、DMMのインターンに参加させて頂いた。

 

インターンで何をやったか

menus-recipe.com

menusという健康的な献立レシピをレコメンドするサービスのバックエンドエンジニアを1ヶ月間やっていた。

DMMでは、menusは新規サービスに当たる?のだが、大きいIT企業での新規サービスの開発・雰囲気が知りたくてmenusの事業部を選んだ

このmenusがリプレイス段階で、menusのAPIをDjagoからRailsへ移植・改善を行った。

 

f:id:mikamimikami60:20180918113546p:plain

主には、この画面のAPIを担当した。現在は、それぞれの項目を編集後、右上の保存を押さないと更新されないので、それぞれの項目を編集後、独立してPatch処理を投げるように改善しながらリプレイスする。項目によっては独立して更新ではない部分もあった(これが、ちょっと大変だった)

 

仕様が曖昧だったので、PO(プロジェクトオーナー)に仕様を突き詰めたり、場合によっては栄養士さんに確認していただかないといけない部分だったりがあった。社員の方にフォロー頂きながら進めたが、DB設計からAPI実装までやりきった。

 

流れは、

  1. DB設計
  2. テスト
  3. API実装
  4. CLIツール作成(API確認用)
  5. Swaggerに書き起こす

インターンに参加して思ったこと

仕様をPO,アプリチームに確認する

自分みたいに、途中からジョインするような人(前からいる人も)は、とにかくコレが大事だと思った。実装中に、リプレイス前のアプリ(現行)のもので見つかった仕様なども逐次確認していた。

あとは、アプリ側が逐次APIを叩くか、キャッシュするかとかはサーバーだけで考えるものじゃないし、アプリ側の処理によってはAPIのパラメータに含める内容も変わって来る。

SQLの発行回数を考える

当たり前のことだが、テストでも、SQLの発行回数を考えるのは重要だと思った。

コミットログ

これを一番指摘された気がする。

コミットしたソースコードで何をしたかは、コードを見ればわかるので、「何をしたか」ではなく、「何でこうしたか」を書くべき。コミットログに関しては、短いよりは長いほうが良い。

 

自分は「何でこうしたか」は、基本的にPR に書いていたが、このやり方では、GithubからBitbucketに乗り換えたりした時にログが残らなくなってしまう(乗り換えなければ気にしなくても良いのかも…)。でも、レビューされる時など、なんのための変更かわかるようにすることは重要だと思った。将来の負債にも関わる大事なことだと思った。

レビューする側になる

自分がインターンであるとか、立場に関わらず人のコードをレビューする。インターン参加はじめの頃は、たまに[ask]を投げる程度であったが、後半の方は自分が指摘されたことを共有する意味でもレビューすることができた気がする。

他の人のインターン内容が聞ける

DMMは、事業の幅が広いので、他の部署でインターンしている学生がいる。DMMにインターンに来ている学生は、みんな超優秀でコミュ力が高かったので、わかりやすく何をしているか教えてくれる。(ビッグデータ、プラットフォーム、インフラ...etc)

残念だったこと

作成した機能が、実際に世に放たれて、ユーザーの反応とかが見れたら最高だったと思ったが、それができなかったのが心残りという感じ。

六本木の飯は美味い

下の2つはまじでおすすめ

f:id:mikamimikami60:20180919235708j:plaintabelog.com

 

 

f:id:mikamimikami60:20180919235711j:plain

tabelog.com

 

 

 

 

 

 

Cookpadのサービス開発インターンに参加した

参加したきっかけ

まず、参加したきっかけについて

参加したきっかけは、サポーターズさんの逆求人で、「サービスに近いエンジニア(サービスリードなエンジニア)になりたい」と「デザイナーのお友達が欲しい」ということをCookpadさんにお話した所、自分の実力と思いがマッチしたのか、ありがたいことに特別選考パスを頂けたので参加しました。

supporterz.jp

 

インターンシップのテーマ

「本気でサービスづくりに挑戦する」

5日間のインターンシップなのですが、最終日の ゴールとしては実際に使えるサービスが出来上がっていることでした。

 

スケジュール

1日目:講義 / ワーク

2日目:講義 / チーム作業

3日目:チーム作業 / 中間発表

4日目:チーム作業

5日目:チーム作業 / 最終発表

 チーム作業は インターンシップに参加しているデザイナーの方と2人1組で行う作業です。これが、めちゃめちゃ良い。

他の人は、どういう環境なのかわかりませんが、私は同世代のデザイナーの方と一緒にサービス開発をする機会なんて、学生にはほとんどなかったので良かった!

エンジニアとデザイナーは相性が良い

エンジニアとデザイナーは、働く上で、めちゃめちゃ相性が良いと思いました。

  • お互いの得意が違うので、尊重し合って働くことができる(エンジニア同士だと、プライドが邪魔してしまうことがあるかも…笑)
  • エンジニアは基本、聞かれたがりな所(偏見)があるので技術的なことを聞かれると嬉しい
  • デザインが良いと、開発のテンションが上がる

  

基礎編:そもそも、サービス開発とは?

サービス開発者がやることは「サービスを作ることで体験を提供し、価値を届ける」こと

現在、体験モノよりも価格で売れることがある

 しかし、ただ体験を売れば良いというものではない「最大のムダは誰も欲しがらないモノを作ること」

そのためには、ユーザー理解が必要!

ユーザーにはそれぞれ、「欲求」「課題」「コンテキスト」があり、どんなユーザーが、何を欲しがっていて、それのために何を解決する必要があるかを調査する必要がある。

 そのための手法の一種として、ユーザーインタビューがあり、Cookpadインターンではこれを行った。

 ユーザーインタビュー

このユーザーインタビューがめちゃくちゃ重要 で、サービス開発のアイディアは、これによって決まると言っても過言ではない。コツは、根掘り葉掘り聞きまくること。なぜ?なぜ?ねぇ…なぜ?って

このワークで見えてくるもの

  1. 利用者:そのサービスは誰が使うのか?
  2. 欲求:そのユーザーは何をしたいのか?
  3. 課題:その欲求を満たすために、何が問題なのか?

この3つが見えてくると、この課題を解決するためのアイディアを発想する!

 

実際にやってみて

自分はこの順に考えるのが、苦手ということがわかった…(泣)

私は、アイディアドリブン人間なので、苦手すぎる。アイディア考えてから、そのアイディアが、誰のどんな課題を解決するのかに寄せて行くほうが楽しい。

実際には、このやり方でも全然良くて、リアルにその体験を必要としてるシーンが有るかどうかが問題だと思った。アイディアドリブンなのは全然OKだけど、価値仮説(どんなユーザーが、何を欲しがっていて、それのために何を解決する必要があるか)自体の一貫性はどちらの進め方でも大事!

 ユーザーストーリー

リアルにその体験を必要としてるシーンが有るかどうか

 これに説得力を持たせるのがユーザーストーリーであると感じた。

実際に使ってるシーンを想像させる物語を作る。こんなシーンあるよね〜みたいな

これについては、自分自身でそのシーンを実際にやってみることが重要だと思った。これは、自分たちの想像でのストーリー(シーン)を実際にやってみると、新しい課題や欲求が見えてくるし、あれ?こんなシーンあるか?みたいな根本的な部分に気づくことができる。

動作モック

プロトタイプを作ることで、「仮説」「試作」「テスト」を繰り返す。

  • 自分たちで考えた仮説をなるべく早く失敗することを発見するため
  • 発想を促すため
  • 具体物により、抽象を避けるため

  実践編:実際にサービスづくりをする

 実際にサービスづくりを行った。

テーマは「一人暮らしの料理を楽しくするサービス」

流れは、基礎編と同様に以下の順に行った。

  1. ユーザーインタビュー
  2. 価値仮説の洗い出し
  3. ユーザーストーリー作成
  4. 動作モックの作成

 中間発表は、動作モックまで作り、サービス実装して大丈夫か?(本当にリアルかどうか)の確認をしてもらう。

 

中間発表の結果

ひどいものだった。価値仮説は筋が通ってないし、サービスづくりをしている自分たちも楽しくない。 

ここから、大逆転のために、地獄のユーザーインタビューとアイディアドリブン丸を並行して行って、一貫性のある価値仮説が作れるように相方(デザイナー)と夜鍋した。

中間発表後は、最終発表までに実際に使えるサービスを作ることまで求められていたので価値仮説からユーザーストーリー作成,ユーザー体験まで、ほぼ1日で行った。

最終発表

f:id:mikamimikami60:20180917181306p:plain

一人暮らしの料理の楽しいとは?

まず、一人暮らしの料理の楽しいについては、ひとりではなく、みんなで料理をする時が楽しいと、ユーザーインタビューを通して定義した。

 

 

f:id:mikamimikami60:20180917165414p:plain

価値仮説
  • ユーザー:いつも集まる友達(いつメン)が決まっている、 料理レパートリーが少ない一人暮らしのA君 は
  • 欲求:普段自分が作って食べない新しい料理を作りたい が
  • 課題:一人で新しい料理に挑戦すると、 失敗してしまった時にテンションが下がる ので
  • 製品の特徴:あえてレシピを隠し、みんなでゲーム感覚で 新しい料理を楽しめることに 価値がある

ユーザーストーリー

f:id:mikamimikami60:20180917165608p:plain

+ 動画で表現した。できるだけ、審査員(大学生じゃないのでw)にシーンを想像させるようにした。

 

実際に作ったサービス

ヒデンのレシピ!(HIDDEN NO RECIPE!)

製品の特徴としてはあえてレシピを隠し、みんなでゲーム感覚で 新しい料理を楽しめる である

f:id:mikamimikami60:20180917162321p:plain

 

実装後、少ない時間であったが、 仮説 → 実装後 → 検証(ユーザー体験) を回してみた気づきがあり、サービスに改良を加えた。

 ユーザーがまず、料理に対して何をしたら良いかわからない(友人との議論でも解決しない)

ことから生まれた ヒント機能

f:id:mikamimikami60:20180917171946p:plain

 

コミュニケーションが活発になることはいいことだが、実際に行動しない ユーザーが出る

ことから生まれた タイマー機能

f:id:mikamimikami60:20180917172031p:plain

 

実際にレシピを見ずに、ビーフストロガノフを作ってみた

f:id:mikamimikami60:20180917175704j:plain

合ってんのか?コレwww

 

Cookpadインターンに参加して

  • Cookpadのサービス開発のノウハウを知ることができてよかった。自分はハッカソンとかで、大雑把な問題を解決するサービスしか考えて来なかったので、実際にユーザーインタビュー・価値仮説を通してサービスを考える経験が得られた。
  • サービスを開発する中で、開発者自身が楽しんでいることが重要だと思った。この「楽しい」は、開発が楽しいとか人に使ってもらえて楽しいとか何でも良いと思う。
  • 評価してくれる人に対して、その需要があることのリアルさを表現することが大事。価値仮説は、その1つの方法であって、やり方は無限だと思った。
  • デザイナーの友達ができたのが最高
  • クッ社のエンジニア・デザイナーは強い。クッ社に限っては職種はただの肩書に見えた。デザイナーもコード書くし、エンジニアもユーザーインタビューするし…。なんでもできるイメージを持った。
  • Rubyのコミッターが普通に歩いてる。Matzもいた。
  • 飯がうまかった

f:id:mikamimikami60:20180917175740j:plain

このインターンに参加して、自分が目指しているサービス開発者に少し近づいた気がした。

 

 

ジロッカソンで優勝した話

ジロッカソンというハッカソンがある。二郎ライフをハックするハッカソンでした。

supporterz-seminar.connpass.com

matome.naver.jp

作成したアプリケーションについて。。。。。

クーポンましまし

サービスの概要

サービスの概要としては以下のような感じです。

  1. 二郎へ行く
  2. ジロリアンは二郎を撮り、それをSNSに投稿する
  3. その際に、写真のクオリティをAIによって判定させます
  4. AIの判定結果によって、それに応じたクーポンを発行します

 

f:id:mikamimikami60:20180609224205p:plain

 

 ユーザーのメリット

まず、このアプリケーションのユーザーのメリットとしては、写真を撮り→SNSに投稿するという、今では当たり前の行為にクーポンという報酬が付与されます。

私の考えとしては、SNSはいわば広告のようなものです。報酬を貰えった方が嬉しいでしょ?

f:id:mikamimikami60:20180609230626p:plain

お店側のメリット

お店側の方がメリットが大きいのかなと考えています。

まず、このアプリケーションはクーポンを発行しますが、「次回以降利用できる」というのがポイントです!次回以降利用できるということは、もう一度行きやすいという、お得感が生まれます。

f:id:mikamimikami60:20180609231048p:plain

次に、SNSはいわば「広告」です。さらに、身内の口コミは、広告よりも効力があると考えています。

f:id:mikamimikami60:20180609231107p:plain

最後に、クーポンは写真のクオリティによって発行されるため、ユーザーはクオリティの高い写真を撮影し、SNSに投稿しようとします。これにより、SNSにクオリティが高い写真しか出回りません!

お店側としては、食べかすや食べ残しの写真をSNSに上げるられることは良いことではないでしょう。この問題も解決できるのではないかと考えています!

f:id:mikamimikami60:20180609231112p:plain

 

開発環境

Webアプリケーション

機械学習API

技術選定の理由としては、開発スピードが鬼速いRailsと画像識別(機械学習)に強いPythonという所です。ハッカソンは、時間が限られた短い期間なので、VGG16モデルのファインチューニングを用いています。

qiita.com

 

写真投稿画面 

f:id:mikamimikami60:20180609233559p:plain

クーポン画面

 

 f:id:mikamimikami60:20180609224800p:plain

 

サービスを考えるときはできるだけ、みんなが幸せになるようにと考えたアプリケーションです。ジロリアンもお店側もWinWinな最強のアプリケーションかなと思っています(笑)

自分は学生なのですが、社会人の超優秀なエンジニア方々と競うことができて良い経験になりました。

アイディアを形にできて、それに対して、優勝というフィードバックが貰えて最高です。

 

ジロッカソンはハッカソンの中でも特にカオスでおもしろいハッカソンかなと思っています。ぜひ参加してください!!