DEMODAY(Dive into code)に登壇してきました

審査員賞を3ついただきましたー!嬉しいです!!

f:id:PushRequest:20180402012329j:plain

審査員賞は

株式会社リブセンス 竹馬 力 氏

前回DEMODAY優勝者 小西 佑典 氏

株式会社Dive into Code 代表取締役 野呂 浩良

 以上の3名様からいただきました!!

 

改めまして、本日4/1(日)にDive into code主催のDEMODayに参加してきました!

今日のために2ヶ月間、このサービスを磨き続けていました。

中だるみもありましたが、無事今日を迎える事ができて本当によかったと思います!

 

ちなみに発表した作品はこちら。

www.push-request.com

具体的な発表内容はこちらのスライドに書いてありますが、「コードレビューで独学者、個人開発の作品の質をあげたい」を念頭にコードレビュワーマッチングサービスを開発しました。

www.slideshare.net

 

今回は、DIC主催の「DEMODAY」に出場して思ったことを書いていきます。

DEMODAYについてはこちら

diveintocode.jp

 

発表に関して

・プレゼン

 プレゼンはDEMODAYの中で一番緊張しました。発表の順番が一番最初だったのもあり、緊張感が拭えない雰囲気の中での登壇は手汗がやばかった(笑)。3分間という短時間できっちり自分の考えを伝えるのは難しいですね。前日に発表内容を大幅に変えると言う賭けに出たのですが、無難に正解だったと思います。少しは自分のサービスを聴衆のか方に響かせる事ができたかと思います!

 

プレゼン発表の様子(ガチガチに緊張してます)

f:id:PushRequest:20180401235615p:plain

 

・ユーザーテスト 

6分間、プレゼンターの好きなように自分のサービスを聴衆に紹介しました。こちらも時間は限られているので、自分のサービスの最適な魅せ方を考える必要があります。投稿型のサービスは聴衆に使ってもらう事に重きを置いているプレゼンターが多かったと思います。僕はマッチングサービスだったので簡単にデモを魅せて、あとは質問形式での対応となりました。やはり、僕のサービスについては「レビュワーのメリットが小さいのでは」と言う質問が多く出ました。しかし、Qiita記事の内容もあってレビュワーの方からの需要があることを説明できたかと思います(スライドに書いてあります)。

 

 

出て良かった事

 簡単にはなりますが、DEMODAYに出て良かったことをまとめてみました。

1.サービス内容が詰まる

2.プレゼンスキルの向上

3.仲間ができる

 

1.サービス内容が詰まる

  これは、単純に2ヶ月という限られた期間なので、必死にヒアリングしたり開発を繰り返します(笑)。さらにDEMODAY登壇者は2週間に一回のプレゼン練習、コードレビューで意見交換を繰り返すので、日が経つにつれどんどん内容が濃くなっていきます。

 

2.プレゼンスキルの向上

 3分間と限られた時間の中で、サービスの内容や解決したい課題を伝えきるのは難しいです(笑)僕も本番まで4回以上プレゼン内容を作り変えたり、何十回と発表練習をしました。聴き手にどう伝わってるかが全てだと思うので、練習では常に誰かに発表をしてfeedbackをもらうことを強くおすすめします(僕は兄に無理やり聴かせてました)。

 

3.仲間ができる

 これもかなり大きな利点だと思います。皆さんの周りには「起業したい」「サービスを作りたい」という方はいらっしゃいますか?もしいらっしゃるなら、とても恵まれているか、あなた自身がそういった方々が集まる環境に飛び込む行動力のある方なのだと思います。常に自分の事業を成功させるため、情報取集して発信して勉強する。また自分もライバルに負けないように必死に努力する。登壇者の方は皆、そういった高い意識を持っており、とても刺激的な関係になれます。また発表の時の緊張状態を共有すると一気に距離が縮むと個人的には思いました(笑)

 

こちらは同じく審査員賞を受賞された宮崎さんとのツーショット!!

f:id:PushRequest:20180402024136j:plain

 

今後の展開

 今回、一番の反省点としてはズバリ「ユーザービリティ」です。審査員の1人、株式会社リブセンス竹馬力さんによると、僕のアプリは「エンジニアが嫌いがちなカチッとしたアプリ」だそうです(笑)。なぜエンジニアの好みを聞いているかというと、僕のサービスのターゲットがエンジニアの方々だからです。いちいち、きっちりかっちりしたフローを踏まなければいけないのが好まれないそうです。僕はこの原因を「ユーザーに与える選択肢が多すぎる」ためと解釈しました。そこで、今後はユーザーの手間を減らすことに時間を費やすつもりです。頭の中で構想はできたので、すぐに(2週間くらい)実行していきたいと思います。ぜひ、楽しみにしていただけると幸いです。

 

 

以上、簡単にはなりますがDEMODAYに出場して思ったことをまとめてみました!に

次回以降に出場される、またはプログラミングスクール選びで迷ってる方の参考なればと思います!

ありがとうございました。

 

 

 

 

 

 

 

PushRequestの使い方(マッチング~お礼まで)

www.youtube.com

動画で確認してから以下の内容を読んだ方がわかりやすいと思います⬆️

 

使い方の前に...

 

PullRequestって何?

プルリクエストとは?【プルリクエスト】 | サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ

 

 

  登場人物   

・リクエスタロー(コードレビューして欲しい人)   

鹿瀬 桃水(レビュワー)

 

    ~大まかな流れ~

  1. レビュー依頼   
  2.  完了報告   
  3.  評価・お礼 

①レビュー依頼(リクエスタロー → 鹿瀬 桃水)  

  1.1リクエスタローが鹿瀬 桃水に対してレビューしてもらいたいPullrequest情報を送ります。

f:id:PushRequest:20180330021225p:plain

1.2鹿瀬 桃水はレビュー依頼を送られてきたPullRequest情報を元に吟味し、承認します。

f:id:PushRequest:20180330021247p:plain1.3リクエスタローは、該当Pullrequest詳細ページに表示されるレビュワーのGithubアカウント名からリポジトリのcontributorに招待します(レビューはgithub内で行われます)。

f:id:PushRequest:20180330021635p:plain

 

 

 

 

②完了報告( 鹿瀬 桃水 → リクエスタロー )  

鹿瀬 桃水はレビューが終わったら、リクエスタローに「完了報告」を行います。

f:id:PushRequest:20180330021657p:plain

 

③評価・お礼(リクエスタロー → 鹿瀬 桃水)

リクエスタローは、レビューに対する評価・お礼をPullrequest評価ページで行います。

f:id:PushRequest:20180330021721p:plain

 

以上が基本的な使い方になります!

 

もし「レビューをうけてみたい!」が、いきなり知らない人に頼むのは不安がある人は、DEMODay登壇者がレビュワーとの仲介いたします!気軽にご相談ください。

(今のところ、仲介できるのはRailsのレビュワーのみです)

みなみ@PushRequest (@twinsdevelopper) | Twitter

 

Githubレビュー機能を使ったことがない方へ

チーム開発を変える「GitHub」とは?導入方法・使い方を徹底解説!【第1回】【導入編】 | SELECK

チーム開発を変える「GitHub」とは?〜PullRequestの使い方〜【連載第2回】 | SELECK

この2つの記事をしっかり読めば大方把握できると思います!