とむのブログ

興味関心のあることを書いていくよ〜

VOYAGE GROUPさんのインターン「Treasure」に参加してきたお話

f:id:tomu28:20190821225813p:plain

もの創り実践プログラム「Treasure」とは

voyagegroup.com

一言でいうと3週間で、講義+チーム開発を行うインターンです。

それでは、どんなことを考えて過ごしていたのか、どのように変わっていったのかなどを書いていこうと思います。 かなりボリューミーな内容になっているので、興味をもってくださった部分から気軽に見てくれると幸いです笑

参加した理由

実際に利用するユーザー視点を常に持ちながら、本当に価値のあるサービスとは何なのか共に議論し考え抜き、一緒にチーム開発を行うことで技術力・思考力をより高めていきたいと思い、参加しました。

日程スケジュール

  • 8/12 ~ 前半戦の講義
  • 8/21 ~ 後半戦のチーム開発

となっていて、Treasureが始まるまでの間に事前課題がありました。

事前課題

  • 前半の講義をスムーズに進めるための内容がそれぞれ用意されていました。

それぞれの課題に対して丁寧なレビューをしてもらえたので、インターン当日までにリファクタリングして理解を深めていきました。

前半戦の講義内容

それでは、まず前半戦の講義について書いていきます。

1日目 8/12(月)

午前中ではみんなと顔合わせを行い、これから始まる3週間がより楽しみになりました!
そして、好きなエディタなどは、各々こだわりがあって改めて面白いなって思いました。

Goの講義 その1

午後からは、ペアプロ形式でGoの学習を進めていきました。
内容としては、Goでcurlコマンドを実装したり小さなコマンドラインアプリケーションを作ったりしました。

自分だけでなくペアの方も読みやすいコードを心がけることが生産性を高めていくために重要なことだと再認識しました。
そして、実装で詰まってしまった時ほどしっかりエラー文を読むことが何より大事だなって痛感、、
ドキュメントを読めばあまり悩まず実装できることが多かったので、コードジャンプなど便利な機能はしっかり使っていき、仕様を理解してコードを書いていきたいです。

振り返り

  • 分からないことは、どう悩んでいるのかしっかり言語化して早めに質問していくことで効率よく理解を深めていきたいと思いました

2日目 8/13(火)

Goの講義 その2

2日目は、Goで書かれたベースアプリにAPIを追加していきました。

実装の流れの例

  • 現状把握
  • テーブル、エンドポイントを設計
  • migration sqlを追加
  • migrate up
  • エンドポイント作成
  • ロジックを書く
  • curlを投げたりインテグレーション用実行ファイルに追加して動作テストする

といった手順でAPI実装を進めていきました。

途中でCTO 小賀さんのLTがありました

内容をまとめると

  • 圧倒的成長のコツは、限界的練習
    • その中で、自分は「何ができるか」を把握し、学んでいくことが大切
  • コンフォートゾーンの外側で、常に現在の能力をわずかに上回ることを行うことで成長していける
    • 小さく挑戦し続けることで、いきなりの大きなリスクを回避できる。早く失敗し、早く学ぶ
  • フィードバックし、修正するサイクルを取り入れる。 とくに初期段階
  • 最適な技術で最高のプロダクトを作るために、メンテナンスビリティの高い技術を選定するなど本質を見極める必要がある

これからTreasureでコンフォートゾーンの外側で挑戦し続けていけるように意識していこうと思いました!

フロントの講義 その1

インターネット技術の時代の流れについての紹介後に

  • JSのsync, async, defer
  • classとclojure
  • fetchやaxios

について比較しながら学んでいきました。

3日目 8/14(水)

フロントの講義 その2

フロントの講義では、

クロージャとクラス

  • クラスだと.thisに依存する
    • bindしたいオブジェクトにはbindを忘れずにすること

Promise

  • fetchの返り値
    • 基本的にfetchはnew Promiseしなくても良い
  • Canselできない
  • .then()でチェーンする時は、横に伸びるコードを書くより、行を分けた方が可読性が良い
fetch(function(res) {
  return res.json();
}).catch(function(error) {
  display(error);
});

よりも

function parseJson(res) {
  return res.json();
}
fetch.then(parseJson).catch(display);

の方が短く記述できる

また、axiosというライブラリの方がエラーハンドリングや処理の記述が容易に行えたりするので便利だったりします。
しかし、fetchは外部リソースを読み込む必要がない・対応しているブラウザがaxiosより多いといったメリットもあるので、どの技術を使用して実装するのかお互いの側面を理解した上で選定していきたいですね。

フレームワークの選定

  • いち早くIndexされるのが重要
  • 便利なフレームワーク・ライブラリはあるので、日々キャッチアップするのは大切

Parcel

  • 設定不要で、ファイル変換・’依存解決・バンドルまで行う
  • Configファイルを書かせない
    • Webpackと真逆の立ち位置

React/Vue

2つの種類のComponent

  • Stateless Component
    • Reactの例:Function
    • stateを持たないので、依存するのは親からのprops
    • Viewとロジックが分割されるので責務が明確になる
  • Statefull Component
    • Reactの例:Class, Hooks
    • lifeeycleを持つ

などの内容を学んだ後に、Reactで先日のGoの講義で作ったAPIを使って機能追加していきました。

4日目 8/15(木)

データベースの講義

データベースでは、

データベースの種類について

  • RDB
    • データの不整合を防止し、堅牢かつデータ利用がしやすいデータストア
    • ユーザー情報、取引履歴など整合性が重要なデータのリアルタイムな更新・参照といった用途で使用される
  • DWH
    • RDBを分析用に特化したもので、データ更新は苦手で低速
    • データ集計が主な用途
  • KVS
    • SQLを使わずに、独自プロトコルによりデータを操作する
    • RDBの補助的な役割で、重い計算結果を格納して再計算のリソースを節約などの処理を最適化することが主な用途

データベースの選択と特性

  • ACID
    1. Atomicity(原子性)
    2. Consistency(一貫性)
    3. Isolation(独立性)
    4. Durability(永続性)

  • BASE

    • ACIDよりも柔軟な分散システムの考え方
      • Basically Available(基本的に利用可能)
      • Soft-state(柔軟な状態)
      • Eventual Consistency(結果整合性)
  • 結果的に整合性が取れればよい場面ではKVSを使えば高速で良い

などの内容を最初の講義で学びました。

グループワークのモデリング実践入門

そして、次はグループワークに入る前にモデリングの講義がありました。

データモデリング

  • データ≠情報
    • データは事実
    • 情報は見たい内容
      • 情報ベースでデータ設計しないこと(UIなど見た目に引きずられない)
  • エンティティとは
    • リソース
      • サービス運用に必要となる実体
    • イベント
      • 過去のある時点に発生した「こと」
      • 誰がいつ何に対して何を行なったか
        • 7W2Hで考えるとよい
      • 時間を属性として持つ

モデリングの技法

1. 論理モデルの作成

  • 1.1 ユースケースを考える
  • 1.2 エンティティ抽出
  • 1.3 リレーションシップを張る
  • 1.4 主要属性の定義(リソースとイベント)
  • 1.5 主キーの選定
    • 以下の選定基準(1つでも満たさない場合はサロゲートキーを使用する)に則って1つ選ぶ
      • 一意に定まるもの
      • 値の変わらないもの
      • できるだけ桁数の短いもの
      • 複合キーでの連結が多くならない
      • 必ず存在するもの(NOT NULL)
    • サロゲートキーの追加を考慮する
      • システム側の都合で付ける無機質なコードだが、論理モデルの段階ではなるべく使用しないようにすること
  • 1.6 正規化し最終的なER図の作成

2. 論理モデルから物理モデルへの変換

  • 論理モデルから実際にDBに実装する段階まで落とし込む
  • 代理キー(サロゲートキー)が必要であれば使用する
    • 自然キーを使用すると主キーの変更に弱い
      • ユーザー名を主キーにした後にユーザー名を変更できるようにしたくなった場合など
    • しかし、代理キーを使用するとサービスに関係無いカラムを増やすことになるため要検討

モデリングの講義の後は、3人チームとなって架空サービスのデータモデリングを行い、migrationを適用しました。
なぜ、このようなテーブル設計にしたのか3人で何度も見つめ直すことで仕様漏れの防止に繋がったと思います。

社内LTにも参加しました

どれも非常に楽しい内容で充実した時間になりました。
(進捗を最高にするイヤホン・ヘッドホンの選び方やBash Scriptで3分APIサーバー作成など笑)

f:id:tomu28:20190904194800j:plain
美味しくいただきました!

5日目 8/16(金)

中間課題

5日目は中間課題の発表がありお題は、

  • 最高に面白い何かを作ってください!!

というものでした。

何を作ろうかと考えた時に、最近困っていることは何だろうと思い書き出していきました。

困っていること

1. 前に見ていたページを探したいと思った時に、開いているタブが多いと、ページタイトルが見切れてしまい切り替えることが困難
2. 見ているページをスマートフォンiPadですぐに見たいときに、Slackなどで送るのは手間
3. Chromeのタブをたくさん開いていると、メモリを沢山消費しているので開いているが不要なタブを削除したい

  • しかし、タブを沢山開いているとFaviconしか表示されないような状態になってしまい、不要なタブの判断がしづらい

f:id:tomu28:20190903145737p:plain
タブを開きすぎている様子

上記の問題の解決策

  1. 開いているタブの一覧を表示して、タップするとそのページに遷移できるようにする
  2. 開いているタブのQRコードを読み取ることで、スマートフォンiPadでも別のサービスを経由することなく瞬時に開くことができるようにする
  3. 複数ページを開いている際に「いくつタブを開いているのか」すぐに見ることができ、知りたい情報が記載されているタブがどれだったのか、「タイトル」「ロゴ」を表示して知ることができるようにする

そして、Chrome APIを使ったChromeプラグインを作ろうと決めて開発していきました。

8/17,18(土日)

オフィスで行き中間課題に取り組んでいました。
今回のChrome拡張を作る上で使用した技術は、 React, ChromeAPI, Material-UIです。
Chrome拡張のデバッグでは、React Developer Tools を使うことができなかったので大変でした笑

Reactは、あまりキャッチアップし切れていない現状でしたが、少しずつ書けるようになってくると、ライブラリ・ドキュメントの充実度が高くて楽しくなってきました。
今回の中間課題に取り組んだことで、Material-UIやAtomic Designを意識したコンポーネント分割には少しずつ慣れてきて、後半のチーム開発でも活かしていけたかなと感じています。

6日目 8/19(月)

中間発表

  • 午前中は各々が開発してきたものを見せながらプレゼンを行いました

最終的に出来上がった僕の成果物は以下のような画面になります。

f:id:tomu28:20190903154901p:plain
Chromeプラグインの動作画面

QRコードを表示」ボタンにマウスオーバーすると、それぞれのQRコードが表示されます。
実装したかった機能は動作するので、UIを少し整えてchromeウェブストアにリリースしようと思います。

セキュリティの講義

午後からは様々なセキュリティリスクや、攻撃手法(XSS, SQL Injection, セッションハイジャックなど)について学びました。
今後は、脆弱性が生まれてしまうコードは書かないように気をつけていきたいです。

7日目 8/20(火)

認証の講義

午前中は認証の講義で、自前で行う古典的Cookie認証やOpenID Connectなどついて学びました。

OpenID Connectのよくない実装例と、推奨する実装例として以下のようなものがあります。

よくない実装

  • IDToken(sub)を発行してもらい、受け取ったものでサーバーとの通信リクエストする
    • つまり、subをゲットすればバックエンドサーバを簡単にリクエストできる

推奨する実装

  • IDTokenをバックエンドで検証する
    • それがOKだったら認可コードを返す
    • サーバーとのリクエストを送るときは、認可コードでやりとりする

講義で学んだ重要なことを要約すると、

ライブラリを選定できる知見が必要

  • インクリメンタルな開発にはリスクがある
  • 選定できるリテラシーが必要

途中で株式会社fluct COO 望月さんのLTがありました

内容をまとめると、

  • ビジネスサイド、開発サイドの温度差があることを踏まえて、お互いが歩み寄ろうとする姿勢を大切に
  • 初期設計を間違えると、製品ができないことになりかねないので、ニーズを慎重に聞き取ること
  • 問題が起きた時に、現象・バグ・事象なのか断定して対処法を判断すること

インフラの講義

午後はインフラの講義で、Application Load BalancerやCI/CDについて学びました。
講義を受けて、後半のチーム開発ではCI/CDを回して動く状態を継続し小さいスプリントを回していきたいと思いました。

後半戦のチーム開発

そして、前半の講義が終わってからは学んだことを全力でアウトプットするチーム開発が始まりました!

チーム発表

この日の最後にチームメンバー発表があり、チーム開発を本格的に始める前に事前課題が1つ与えられました。
その内容は、 「チームのSOULを決めてくること!」 でした。

SOULとは

チームの「価値観」「考え方」「想い」などを表すもの  
SOULを共有、形にして悩んだときに立ち返ることができるようにする

というものです。

SOULを置く意味

  • イデアを選ぶ際のチームの共通言語
  • イデアへの納得感を確立させるため

SOUL決め

ご飯を食べながら、全員がどんな人になっていきたいのか、どのような思いを持っているのか本音で言い合うことでメンバーみんなの見る方向性が明確になりました。
僕は「多くのユーザーの方に幸せ・楽しい・便利と思ってもらえるサービスを提供していきたい!」と思い中心にあるということを話しました。

みんなが持つ共通の思いを言語化していき、最終的に僕たちのチームのSOULは、
「世の中のスタンダードに」
に決定しました。

また、モラルはわきまえて発言(相手の意図を汲み取る前に否定し強い発言をしないなど)しつつも、まずは自分を信じて考えを伝えることを妥協しない姿勢は大事なことで、お互いを尊重し合えるチームは良いチームだなと思いました。

チームの開発方針

サポーターの方の提案で、実際の業務で徹夜はしないしTreasureもインターンとはいえ、毎晩夜遅くまで開発をして体を壊して欲しくないという考えの元で、僕たちのチームは10時〜18時の決められた時間の中で集中して成果を出そうということを意識して進めていくことにしました。

与えられた時間の生産性を最大化するために、僕たちのチームは最初に、KPTを意識して現状分析し、次に行うべきことを明確にして開発の進め方をブラッシュアップし続けていこうと決めました。
KPTとは、Keep(良かったこと)・Problem(現状の問題)・Try(意識していくこと)から構成される振り返り手法の1つです。

また、各々が認識した課題は全員が把握できるように、チームメンバーが見ることのできる日報に書き、日々の課題を可視化したり、毎朝行なったスタンドアップ・ミーティングで共有していました。

進捗や現状の進み具合は、2時間おきに報告し合い、進み具合や各々の担当箇所を考慮してペアプロしたりしていきました。

それでは、日々どのような振り返りをし、得た気付きを元にどのように行動を変化していくことができたのか対比しながら書いていこうと思います。

8日目 8/21(水)

これまでの講義内容に関する補講

午前中には、これまでの講義で質問が多かった部分に対して補講が行われました。

  • Vue.js, ReactのXSSについてのセキュリティリスクについて
  • state, component設計について
  • 2日目のGo講義で使われたアプリケーションのアーキテクチャの補足

イデア講義

午後からは、価値あるプロダクトのアイデアを考える方法についての講義がありました。
イデア講義の最初に、成功しているソフトウェアの特徴はどのようなものがあるのか紹介がありました。

成功しているソフトウェア

  • 問題を限定しうまく解決をしている
    • あらゆる問題を下手に解決するのではなく、多くのユーザーの共通の問題点をうまく解決している
  • 複雑さを隠す
    • 複雑な事であっても簡単な事をしているように見せるべきである
  • 開発者は常にユーザーを意識することが重要

イデア出しの手順

その後、以下の手順に沿ってアイデア出しを進めていきました。

時流ワークショップ

  1. たくさん「時流」を洗い出す
  2. 適切な粒度に揃える

イデアワークショップ

  1. 考える領域を一つ決める
  2. 領域にいるプレイヤーを洗い出す
  3. 考えるのみ使う時流を選ぶ
  4. 領域 × 時流をかけ合わせて「その領域で起こっていきそうな事象」を考える
  5. プロダクト案を考える

イデア出しでのKPT

Keep

  • イデアの数がたくさん出せたこと
  • お互いを尊重し発言できていた

Problem

  • イデアワークショップの領域が広すぎてしまい、お互いの共通認識を具体的に持つことが出来なかったこと
  • どのようにアイデアを形にするのか実装イメージが湧かないことがあったこと
    • 「趣味」という粒度でアイデア出しをしていた時に、人それぞれ異なるので、プロダクト案をうまく選定出来なかったこと
  • 「なぜ」をもっと掘り下げて議論を展開できていなかったのでアイデアを深めていくことが出来なかったこと

Try

  • 今回のように早くうまくいかなかったことに気づいた時、Problemを振り返り修正のサイクルを回していくこと
  • 時間・集中力は有限なので、限られた中で良い成果を生み出せるように意識する
  • 思うことがあったら、(チームギークの言葉を借りると)HRTの精神を持ちつつ発言したりして積極的にコミュニケーションをとっていく

9日目 8/22(木) チーム開発初日

まずは、昨日の反省を踏まえて、再度アイデア出しを行なっていきました。
何度か領域選定からプロダクト案の選定までのサイクルを回したのち、全員が納得できるアイデアが固まってきました。
そして、プロダクト案をより固めていくためにホワイトボードにターゲットや、必要な機能などを洗い出していきました。

f:id:tomu28:20190905135556j:plain
プロダクト案を固めている様子

f:id:tomu28:20190905135721j:plain
必要な機能の洗い出し

チーム開発初日でのKPT

Keep

  • 「なぜ」をもっと掘り下げて、お互い議論を展開していくことができたので良かった
  • 必要な時(領域決め)は時間をしっかりとり、余裕があれば次の手順へいったりでき、時間管理がうまくできていた
  • 一回アイデア決めのサイクルを回したがうまくプロダクト案がまとめられず次はどうしようとなった時に、しっかり領域決めから再度話し合うことができたこと

Problem

  • 議論が詰まった時に、深めていくのができない時があったこと

Try

  • まず全員が同じ認識を持っていけるように、具体的な用語で説明することを意識してUI設計を進めていく
  • デザインを伝える際に言語化するだけでは人によってイメージが異なってくることが往々にしてあるので、適度に図を書き伝えていきたい

振り返り

  • 議論が止まってしまった時は、視点を変えて(ユーザー・ニーズを具体的にしたり、抽象的になっている自分のアイデアを図を書くなどしてメンバーに伝える)みることは大事
  • ユーザーとニーズを最優先で考えることを続けること

10日目 8/23(金) チーム開発2日目

イデアが固まり、プロダクト案を実装フローに落とし込んでいく段階になりました。

行なったこと

  • UI設計
  • 技術選定
  • DB設計

今回開発する「eeNotes」というアプリについて

f:id:tomu28:20190905142643p:plain
eeNotes

一言でいうと

あなたの書いたノードが価値を得る!
ノート投稿型シェアリングサービス

ターゲットユーザー

  • ノートを投稿する側:電子デバイスでノートを取っている学生
  • ノートを閲覧する側:全学生

ニーズ

  • ノートを投稿する側:アウトプットがポートフォリオとして評価される
  • ノートを閲覧する側:わからない授業を補足できる

特徴

  • SNS的に公開できる
    • ノート検索ができる
      • 同じ大学内の学生のノートを一覧で見ることができる
    • ノートにいいねがつけられ、お気に入りのノートを保存することができる
  • マーカー
    • 重要な部分をマーカーとして残せる
    • ノート投稿の際に、マーカーを簡単に挿入できる
  • 投稿
    • マーカーを使って投稿できる
    • リッチエディタを用いてノート整形

マーカーとは、ノートの本文をドラッグ&ドロップしたら以下のように強調表示され、
右の一覧画面にある「ノートに追加ボタン」を押すとノートに挿入されるというものです。

f:id:tomu28:20190905144720p:plain
マーカーの動作画面

技術選定で意識したこと

  • 現在実装を進める為に、最低限必要ならばそれらの技術を導入することを考える
    • 例えば、propsのバケツリレーが発生してしまったらReduxを導入する必要があるが、基本的にStatelessコンポーネント中心でアプリを形に出来るならReduxを使う必要性はない など
  • 最近流行っているからや、導入メリットを具体的に説明できなければ導入コストのある技術を安易に取り入れてはいけない

チーム開発2日目でのKPT

Keep

  • 全員で話し合いながら、UI設計・DB設計・技術選定・必要なタスクやコンポーネントを洗い出すことができ、進捗が順調だったこと
  • 根拠を持つために具体的なペルソナを定めて話し合っていくことで、アプリの核となる機能・不要な機能が明確になったこと

Problem

  • 話が入り込んでいくと、本質とは異なる内容に議論が逸れていくことがあった

Try

  • 今は何を決めるために話し合っているのか常に意識しながら進めていくこと

学んだこと・考えたこと

  • 今回のような限られた時間の中で最大限の進捗を出すためには、まず小さいゴール(投稿機能をデプロイすること)をチームメンバー全員で共有しておくことで、次に行うことがより明確になったのでPDCAを小さく刻んで回していきたい
  • UMLユースケース図を書き具体的なロールモデルを想定することで、本当に必要なのか根拠・自信をもって意見を伝えていくことができた
  • 技術の選定を行う上で、確かな視点で導入できるように日々キャッチアップすることは重要
  • DB設計を見直す際にも、UI画面にデモ値を入れてこのDB設計で本当に表示することができるのか考えることが有効だった

f:id:tomu28:20190905132423j:plain
DB設計の様子

8/24,25(土日)

  • フロントエンドは、どのようなコンポーネント設計で実装していこうか決めた
  • バックエンドは、SwapperでAPI設計を行なった

axiosでGET,POSTする際にはSwagger Hubを見ることで、APIのエンドポイントやResponseの形式が一目で分かるため、すごく便利でした。
また、サーバーのAPIが立つまでにSwaggerHubのモックサーバーを叩くことも出来たので、フロントとサーバーサイドをスムーズに繋ぐために動作確認することもできて良かったです。

11日目 8/26(月) チーム開発3日目

この日から、コードをガンガン書いていきました。
最初はフロント2人・バックエンド3人の構成で僕はフロントエンドの開発を始めました。

行なったこと

  • Makefileを書き直した
  • Gitのブランチ運用・作業把握・レビューについてチームの方針を決めた
  • Linterの設定
  • ノート投稿機能の開発

中間課題のフィードバック

この日は、中間課題のフィードバックがありました。

  • Reactと関係のある処理(setStateなど)はReactの中で記述する必要はあるけど、Reactと関係ないピュアJSのメソッドで切り出せるものは切り出した方がいいよ
  • React Developer Toolsでのデバッグが出来ない今回のケースでは、 debugger;を使うと、その処理を通過した部分で、Developer Toolsが止まるのでデバッグしやすいよ〜
  • フロントエンドのテスト周りやバリデーションについて(バックエンドと対比して)

などのことを話していて、疑問に思ったことは掘り下げて聞いていたら1時間くらい経っていましたw
丁寧に答えてくださりありがとうございました!!

チーム開発3日目でのKPT

Keep

  • ノート投稿機能のUI部分は割とサクッと作ることが出来たのでよかった
  • Reduxを導入しなくても、書き方次第(StatelessComponentで実装可能な場合はそのように定義するなど)で任意の処理を書けていたこと

Problem

  • 自分が今どのタスクを行なっているのかうまく共有出来ていない時間帯があったため、実装に詰まってしまった場合、どういった問題で苦労しているのか言語化するハードルが上がってしまった
  • 今日は、完了までにかかった時間の共有があまり出来ていなかったため、他のタスクの所用時間があまり見えてこなかった

Try

  • 議論の時は、今は何を話し合っているのか常に意識していくことが大事だったように、開発の際は、今誰がどのタスクに取り組んでいて進捗はどのくらいなのか全員が把握できることが重要だと感じた
    • また、タスクの粒度が大きいほど(個人的な感覚だと45分以上かかるもの)は、タスクの全体像が見えにくくなってしまっているように感じた
    • そのため、時間のかかり過ぎるタスクは実装する機能を分割できるはずなので、その点を意識していきたい
  • 時間を区切り、15分しっかり考えても解決出来そうになかったら、メンバーやサポーターに自分なりの考えを伝えてから質問する
    • せっかくチーム一丸となって開発しているのだから、頼っていける部分や自分1人で悩むより質問したら解決の糸口が見えてくるかもしれない場合は積極的にコミュニケーションを取っていく
  • コンポーネントは、スコープのことも意識しながら、使いづらくならないように区切っていく
  • メンバー・サポーターの方に今何をしている時間なのかしっかり共有すること

学んだこと・考えたこと

  • 親から子へのコンポーネントのやりとりは、設計で工夫できる部分は色々あると学べた
    • 他のUIパーツとの連携が容易に行えるMaterial-UIを中心にUIを構築したため、propsの値リレーを減らすことができた
  • 開発フェーズとなり、意識していくことが先週と比べ変化しているが、チームで開発しているということを第一に意思疎通を心がけていく
  • ペアプロする際は、今どのように実装しようとしていて、何で詰まっているのか背景を具体的に説明してから一緒に考えるようにしていきたい

12日目 8/27(火) チーム開発4日目

行なったこと

  • ペアプロで作成したAPIのPOSTリクエストを送信できるようにした
  • マーカーという概念をチームの共通認識で持てるように話し合った
  • マーカーコンポーネントを作成

最終的に「マーカー」という言葉になったのですが、開発の初期は呼び方が曖昧でした(付箋・しおり・ハイライト・クリップボード etc.)。

また、開発をしていて本当にその機能が必要なのか議論する場面もありました。

f:id:tomu28:20190905151856j:plain
その機能本当に必要?

f:id:tomu28:20190905151949j:plain
その機能本当に必要? その2

チームで良いものを作るために大切なこと

  • 共通言語で語る
  • 具体的なユースケースで考える
  • サービスをより良くするために、ユーザー・ニーズを常に意識する
  • 本当に必要な機能は妥協しない

チーム開発4日目でのKPT

Keep

  • 午前中は、予定通り実装を進めることが出来たので、午後からの議論にスムーズに入れたこと
  • 15分考えても前に進んでいなかった場合は、原因やどのような実装を考えているのか伝えて相談して解決することができたこと
  • 自分や他のメンバーが取り組んでいるタスクをホワイトボードに貼り見やすい形で管理出来ていたこと
  • 2時間起きのミーティングが行えていたこと
    • 次は、ミーティングをより有意義にするために、疑問や決めておきたいこと・共有しておきたいことがあれば言っていくようにしていきたい

Problem

  • フロントとサーバーサイドが作成してくれたAPIを繋ぐ際に少し詰まったが、流れを注意深く見てデバッグしていきたい
    • まずリクエストの形式(特に定義された型になっているか)は正しいのかよく確認すること
  • PRがよく上がってくると、コードレビューされずに溜まってしまうことが想定されるのでバックエンド・フロントエンド共にコードレビューしていきたい
  • 実装が難しいものほど、エンジニア視点で物事を考えてしまいがちだが、まずは初心に戻りユーザー視点を忘れずに実装フローを考えていきたい

Try

  • マーカーという言葉で共通認識を持つことができたので、気になることがあればすぐに言語化・共有したりして迷いのない実装をしていきたい
  • マーカーが引かれたら、その情報をDBに保存するPOSTリクエストは、マーカーが引かれるたびに非同期処理で送るようにしたい
    • マーカーが引かれる・削除されるたびにPOSTリクエストを送る実装でいく予定
    • 非同期の部分は工夫できる箇所がいくつかあるが、時間対効果と相談になりそう
      • 連続でマーカーが引かれたり削除された場合、並列処理でPOSTを送る
      • すぐに生成されるコンポーネントにはルーティング表示するなど行なってUXを良くしたい

13日目 8/28(水) チーム開発5日目

行なったこと

  • マーカー機能のベースを作成
  • コンポーネントを切り出し、マーカーが引かれたらPOSTを送る処理の実装
  • ペアプロで、マーカーの一覧表示を行えるようにした
    • マーカーが追加されたら変更を検知して、一覧表示を再レンダリングする部分も実装

チーム開発5日目でのKPT

Keep

  • お互いが実装した部分を繋ぐ際は、ペアプロを有効に行なっていくことができていた
  • 行いたいことを似たような流れで他のメンバーが実装している場合は、そのコードの意図などを参考にすることで、開発スピードを落とさずに実装することもできていた
  • どのようなUIや配置にしたらユーザーは使いやすいだろうか考えて開発していけていたこと
    • 時間のある限り、どんどんヒヤリングや色々なユーザーに触ってもらって、ブラッシュアップしていければ最高

Problem

  • 今書いてあるコードを元に、次に実装したいことを考え込んでしまい、結果として複雑な実装になってしまっていることがあったこと
    • 時には、一旦考え方を変えてみるとよりスムーズな実装が浮かぶこともあるので、実装に詰まってしまっても現状のコードに捉われずに解決策を思考できるようになっていきたい

Try

  • 相互レビューをより良いものにするためには、レビューしてほしいこと・あえて行なったことは、GitHubのコメントに書くこと
    • コードに直接コメントを書くよりも、GitHubにコメントがあった方がレビューする際に分かりやすいため

学んだこと・考えたこと

  • ネストが深くなりすぎないように、うまくコンポーネントを分割しようとしていたが、結果的に使いづらい形でスコープが切れてしまうことがあったので、機能単位で分割するように心がけた
  • propsで親から子へ値を渡す際に、statelessでうまく設計できれば値の受け渡しが減ったり、直感的なコードになったりするので、明日も適切な使い方を心がけていく
  • 議論やペアプロ、タスク管理が日々改善されているため、お互いが進捗を最大化できている感じがして、チーム開発がとても楽しいです!
  • 開発期間が残り短くなってきましたが、協力しつつより良いプロダクトを作れるように取り組んでいきたい!

14日目 8/29(木) チーム開発6日目

行なったこと

  • ガンガンペアプロ最後の追い込み開発
  • スモークテスト
  • プレゼン用として、DBのseedを作成

ペアプロ・モブプロについて

ペアプロやモブプロをしていて、うまく実装できてモノが動いた時は、
ハイタッチして喜びを共有したり、モチベーションを高め合うようにしていました
(諸説あり??)

15日目 8/30(金) チーム開発最終日

行なったこと

  • 最終デプロイ
  • プレゼン資料を作り、発表

最終プレゼン後

最終プレゼンの後、Treasure生とサポーター全員で3週間を振り返り、一言言う場面があったのですが、3週間の色々な思いがこみ上げてきてとても感慨深い気持ちになったのは今も鮮明に覚えています。

懇親会が終わった後も、チームメンバーやサポーター・Goの講師と最終成果物のフィードバックをして下さった すずけんさんで終電くらいまで、色々なエピソードについてみんなでワイワイと話し合い、本当に別れ惜しかったですが、アツい握手を交わしてオフィスを後にしました。

f:id:tomu28:20190905155440j:plain

チーム開発を振り返ってみて

  • より良いプロダクトを作るために、考え抜き議論し実装するチーム開発が本当に楽しかったです!!
  • 後半のチーム開発は、常により良いものを作るために言語化・思考し続けることが出来てよかった
    • 各々のKPTを日報やスタンドアップ・ミーティングで共有する習慣があったことで、お互いが意識していることを認識しながら開発を進めることが出来たので、課題の共有は開発を効率化させていく上で重要だと学びました
    • 今後のチーム開発でもしっかり行なっていきたいと思います
  • 僕たちも全力でコミットしていましたが、サポーターさんも常に様々な視点でアドバイスやコミットして開発を手助けして下さったおかげもあり、エンジニアの生産性効率化の形をたくさん学ぶことができました
  • 無駄のないチーム開発をしていくために、その場その場の状況に応じて臨機応変に選択肢を提示していけるようなエンジニアになっていきたいと強く思うようになりました
    • そうなっていくために、本当にこの進め方でいいのだろうか・今の開発体制で問題はないのだろうか、現状を常に俯瞰して見ていけるように心がけていきます
  • コードを書いていた期間は4日ほどでしたが、自分たちが大事にしているコア機能を実装することが出来たことは自信になりました

Treasureを振り返ってみて

  • 一見難しそうでキャッチアップ出来ていなかったことでも、抵抗なく挑戦していくことが出来た3週間だったなと思います
    • 常にコンフォートゾーンの外側に身を置くためにKPTを習慣付け、日々Problemを解決するためにTryし、振り返る。そうすることで、今日出来なかったことを明日は出来るようになるために挑戦し続けることができました。
  • 日々学びがあり考え方が広がったことで、実装やチーム開発を進める上での引き出しが増えました
    • これから先も、Treasureの時に常に心がけていた「なぜ」を掘り下げて考えることを大事にしていきたいです
  • 時間的な制約がある中で常にどうしたらより良い開発が行えるだろうか考え、チーム一丸となり妥協せずにプロダクト開発を最後までやりきることができたことは大きな自信になりました
    • しかし、まだ未実装の機能であったり修正できていない部分があるので、最後にチームで決めた「リリースまでもっていく」という目標を果たせるように取り組んでいきます!

まとめると

前半の講義で幅広いWeb開発の知見を広げ
後半のチーム開発では以下の流れ全般を、常にKPTを意識しながら学ぶことで

  • イデア出し
  • 開発の流れの効率化
  • タスク管理
  • 実装

チームでの、ものづくりの楽しさを改めて感じることが出来ました!

そして、

  • 疑問を持つ → 考える → (質問する ) → 解決

イテレーションを高速で回し続けてきたことで
問題をしっかり言語化して解決へ導いていく力が、参加前の自分と比べて向上したかなと思います。

開発以外のこと

シェアハウス

遠方から来る参加者のためにシェアハウスを用意してくださり、8/11から過ごしていました。 みんなバックグラウンドが異なり、初日は日付が変わるまで様々な話で盛り上がりました。(ちょうどMacの充電が切れなかったらまだまだ話しこんでいたでしょうw)

Vue Nativeを書いていた方や機械学習周りも強い方、CG系のスキルも凄い方まで各々でした。 みんなのやってきたことを話すのは、知らないことが知れて有意義ですね。

途中でVGクルーの方も加わり計8人で毎日賑やかに楽しい日々を送っていました。燻製を毎日作っている人も入れば、置いてあるスピーカーでベートーヴェンを毎朝かける文化が生まれたりw
美味しい燻製を作るためには、いかに水分を抜くかがコツらしいです。

f:id:tomu28:20190904162842j:plain
毎朝ベートーヴェンがかかるスピーカー

3週間一緒に過ごしていて幅広く知見が広がったように感じています。仲間たちと一緒って最高でした!

15時の差し入れ

インターン期間中は、毎日クルーの方が差し入れをして下さりました!
バラエティ豊富で、どれも美味しかったです!

f:id:tomu28:20190905130234j:plain
クレープ

f:id:tomu28:20190905131009j:plain
ふわふわドーナツ

f:id:tomu28:20190904163151j:plain
わたあめ

f:id:tomu28:20190904163225j:plain
みんな大好きラムネ

VGクルーさんのサポート体制

Treasureではサポートがとても手厚く、僕たちが困った時・迷った時・どうしたら良いかわからない時に一緒に考えたり、解決の糸口になりそうな考え方を幾度となく示してくれました。

チームとして納得感をもって開発するための手助けや
イデア出しや各々のタスク振りの流れを効率化するためのアドバイス
技術的には実装に対する多面的なアプローチをしていただいたおかげで 多くのこと吸収し続けることが出来ました。

最後に

VGクルーの方々・TAさんには、事前課題から始まり、8月の3週間の間最大限サポートしてくださり本当に感謝しています!
そして、この8人で一丸となってチーム開発していくことができて本当に良かったです!!

サポートしてくださったみなさんと次に会うときには、今回の学び・経験を活かしてより成長した姿を見せられるように頑張っていきます!!

最後になりますが、 一緒に学び合ったTreasure生
3週間共に生活したシェアハウスのみんな
一緒にeeNotesを作ったチームメンバー
本当にありがとうございました❗️

f:id:tomu28:20190905131910j:plain
最高の夏の思い出