SMARTCAMP Engineer Blog

スマートキャンプ株式会社(SMARTCAMP Co., Ltd.)のエンジニアブログです。業務で取り入れた新しい技術や試行錯誤を知見として共有していきます。

エンジニアとして大切なことは全てインターンで学んだ 〜本日でスマートキャンプを退職します〜

f:id:tkgwy:20190301161901p:plain

こんにちは、スマートキャンプでエンジニアインターンをしている中村ノアです。

ついに今日が最終出社日となりました。 インターンを始めたのは去年の10月からですが、時間の流れの速さに戸惑うばかりです。

インターン中は新規サービスの開発を担当していました。

チームでのプロダクト開発で得られたスキル・経験を改めて振り返ってみようと思います。

あっという間でした...!!!

自分自身について

まずはざっくりとしたプロフィールです。

  • 19年卒(現在、学部の4年です)
  • インターンを始める前までは趣味でフロントエンド開発をやっていました

4月からWeb系エンジニアとして就職することが決まっています。

しかし、それまでプログラミングは独学のみだったこともあり、チームでの開発もしてみたかったところで、偶然紹介していただいたスマートキャンプでエンジニア長期インターンをさせていただきました。

成長したスキル

当初はフロントエンド技術くらいしかやらない想定ではじめましたが、実際に今考えると、フロントエンド技術、バックエンド技術、働き方の軸で圧倒的成長できた実感があります。

Vue.jsを使ったフロントエンド開発スキル

担当しているサービスはVue.jsを使ったSPA構成になっています。 テンプレートはpug、スタイルはSCSSで書いています。

個人開発では触れないような一定規模以上のコードベースならではの、プラグインの開発やコンポーネント設計、Store(Vuex)の実装などいろんなことを経験できました。

趣味で勉強していたことを上手く実際の開発にも活かせたりしてよかったです。

Vue Pluginの自作

アプリケーションの Notification 機能をVue Pluginとして自作しました。

f:id:noah_nak:20190228182847g:plain
Notification

もちろんOSSのライブラリも多くありましたが、どうしても開発中のサービスとトーン&マナーが合わなかったため独自のコンポーネントを実装する必要がありました。

開発にあたって既存のライブラリのコードリーディングも行い、良いところを取り入れつつ拡張性の高い・シンプルな Plugin が作れたと思います。

どのような呼び出し方(API)だと Plugin の使用者が楽かということを考える必要があり、普段とは異なる思考力も培うことができました。

また Vue Plugin という形で作ったので再利用性も高く、このまま1つのライブラリとして公開することも可能では!?と思えたことも印象深いです。

<transition-group> を使ったリッチなアニメーション

「動けば良い」というボーダーからさらに踏み込んで、どうすればユーザーが使いやすいかというところまで考えながら細かいところまで作り込むことができました。アニメーションもその1つです。

Vue.js の <transition-group> を使うことで、よりシームレスな表現ができました。

f:id:noah_nak:20190228182901g:plain
transition-group

ユーザーの操作の「結果」だけを唐突に表示するのではなく「過程」も含めて認識してもらうことで、アフォーダンスを高めることができました。

ロード状態の管理と表示

ユーザーにとって最もストレスフルな瞬間の1つが「ロード中」であることは間違いありません。 担当したサービスでは大量のデータを取得する必要があるページが複数あり、ロード状態の管理とその表示が必要不可欠でした。

そこで状態管理のためのライブラリ vue-wait を導入し、API ごとにロードの状態を Vuex で統括できるよにしました。

ロード中の表示には vue-content-loader を使い、Facebook や Slack のようなロード表示を作りました。

f:id:noah_nak:20190228180818g:plain
Loading 表示

このようなロード表示は使いどころが難しいですが、単純なスピナー(くるくる回る表示)よりも体感時間がかなり短くなるので効果的だと感じました。

Ruby on Rails を使ったサーバサイド開発スキル

Ruby on Rails 5 をAPIモードで使っており、レスポンスのJSONはjbuilderを使って生成しています。

個人開発では firebase を使ったいわゆるサーバレスな開発をしていたこともあり、サーバサイドの開発経験はほとんどありませんでした。

実際、Ruby on Rails はおろかRuby すら全く触ったことがないという有様でした。

チームの方針として、機能ごとにタスクを割り振る(サーバサイド・クライアントサイドまとめて)というやり方で分担しているため、スマキャンでのインターンは未知の領域にチャレンジする良い機会でした。

インターン当初は生まれたての子鹿のようにサーバサイドのコードに触れていましたが、今では苦手意識を持たずに開発できるようになりました。

サーバ側も作れるようになった結果、処理をサーバとクラアントどちらで行うか選ぶということができるようになりました。改めて振り返ってみて、これは大きな収穫だと感じます。

クラアントでは難しい処理もサーバでは簡単だったり、その逆もあり得るので、状況に応じて最適な選択ができるというのは開発をする上での大きなアドバンテージになります。

また、自分の守備範囲が広がることで出来ることも増え、対応力を磨くことができました。

共通認識、チーム開発のための行動力

担当サービスでは、ユーザーが3つの権限に分かれています。

権限によって必要とする機能も微妙に異なっており、どうやってコンポーネントを再利用すれば良いか頭を悩ませることが多いです。

なぜか僕の机の上に置いてあったAtomic Designの本を目にし、Atomic Designを導入すれば解決できるのでは...?!と思いました。

Atomic Design ~堅牢で使いやすいUIを効率良く設計する

Atomic Design ~堅牢で使いやすいUIを効率良く設計する

  • 作者:五藤 佑典
  • 発売日: 2018/04/25
  • メディア: 単行本(ソフトカバー)

その思いをメンターに相談したところ、全社内エンジニアに向けて勉強会を開くことになりました。 内容は、Atomic Designの概要、それぞれのレイヤーの責務・制約、実際のコンポーネント設計への適用を話させてもらいました。

結果として、社員の賛同が得られ、プロダクトにもAtomic Designを導入することができました 🎉

f:id:noah_nak:20190208173831j:plain
勉強会のようす

Atomic Designを実践してみて分かったこととして、「Atomic Designは厳格なルールではない」ということが挙げられます。

Atomic Designはあくまでコンポーネントを分割・分類する指標の1つであり、コンポーネントの粒度を表す共通言語を提供しているに過ぎません。

大事なことは、Atomic Designが提供する用語に対する共通認識をチーム内で形成するということだと感じました。

見積もりの勘、どれだけ正確に見積もりを出せるか

仕事としての開発と個人開発との最大の違いは、締め切りがあるということです。 仕事を頼まれた時には「いつまでに終わらせれば良いか」ということを意識するようになりました。

正確でない見積もりは、周りの人に迷惑をかけるだけでなく、自分の首をも絞めてしまいます。 僕自身、かなり楽観的な見積もりをしてしまいがちなので、工数の見積もりは意識して慎重に考えるようになりました。

この半年間の経験から、自分の直感の1.5倍の時間が実際の作業に必要で、最初の見積もりは当てにならないということが分かりました。

逆に、自分の直感の1.5倍の時間をあらかじめ想定しておくことである程度正確な見積もりを出せるというメソッドも得られましたが、これからは直感と現実のギャップを埋めていきたいです。

開発者のバイアスの自覚、答えはユーザーが持っているということ

幸いにもインターン中に、担当しているサービスの社内リリースと社外リリースの両方を体験できました。 この2つのイベントを経て、自分が作っているものの目的・意義を再確認する良い機会になりました。

リリースを機にサービスがより活発に使われるようになり、多くのフィードバックを貰いました。

エンジニアはサービスの内部構造まで知っているだけに、サービスの捉え方に少なからずバイアスがかかってしまいます。 ニュートラル視点からの評価をしてもらうことが良いものを作る際には必要不可欠だと感じます。

開発中に想定していた使い方と、実際のユーザーの使い方が異なるということはよく起こります。その際に、ユーザーの考えに寄り添う姿勢が大事だと学びました。

サービスが複雑になるにつれて、作る側と使う側で認識を完全に一致させることは難しく、擦り合わせを行うためにもフィードバックと改善のサイクルを回さなくてはいけません。

今回担当したプロダクトは、社内にもユーザーがいるためフィードバックを貰いやすいという利点があり、ユーザー目線でのサービス開発をする上で大いに参考になりました。

プロダクトの市場での立ち位置、競合との差別化への意識

幕張メッセで開催された「営業支援EXPO」にスマートキャンプも出展しました!

f:id:noah_nak:20190208173028j:plain
EXPOのようす

多種多様なサービスが一堂に会している様子は圧巻でした。

普段、会社の中で開発を行なっているだけだとあまり意識していませんでしたが、自分が開発しているサービスにも競合が存在しているという当然の事実を再確認しました。

他のサービスと比較して、どのような点で優れていて、どのような点で改善の余地があるかということを客観的に捉える良い機会でした。

会場では実際に他社のサービスのデモに触れる機会があり、とても良い刺激を受けました。

ソフトウェア開発と不確実性、持続可能な開発への意識

「リファクタリングの日」を開催しました。

通常の業務中ではなかなか手が回らないシステムの改修をチーム全員でまとまって行おうという企画です。

イベント感を演出するために、オフィスから出て街へ繰り出し門前仲町のレンタルスペースで丸一日リファクタリングを行いました。

f:id:noah_nak:20190219165403j:plain
リファクタリングの日のようす

ソフトウェア開発を続けていく中で不確実性は常にあり、最初は上手くいっていたやり方もいずれ変化を迫られるということを目の当たりにしました。

この日は Vuex の Store 周りを一気にリファクタリングし、より Vuex らしいやり方に統一するという作業をしました。 この改修作業を経て全体の見通しが良くなったと思いますが、もしかすると再びリファクタリングが必要になる日が来るのかもしれません。

新機能の開発を一旦ストップして現状のシステムを改修するということは、開発スピードを落とさないためにも必要不可欠です。

数ヶ月に1度「リファクタリングの日」を設けるというやり方は、長期的な視点から考えてもとても良いやり方だと思いました。 実際このイベントのおかげで、システムだけでなく自分の気分もリフレッシュでき、普段の開発に一層集中して取り組むことができました。

まとめ

記事中に書いたこと以外にもたくさんの思い出があり、次のようなことも学べました🤗

  • チーム開発、プロダクト開発フローへの理解
    • GitとGitHub flowの理解
    • 他の人にコードをレビューされる経験、他の人のコードをレビューする経験
    • 「コードを憎んで人を憎まず」の精神
  • パフォーマンスへの意識
  • セキュリティ対策
  • ゲーム(スマブラ、ぷよぷよ、ボンバーマン、FIFA)

スマートキャンプでエンジニアインターンをやってみようという決断は大正解だったな、と改めて思います。

サーバサイド・クライアントサイド両方の開発経験を積めただけでなく、チーム開発のノウハウやユーザビリティへの意識など、多くの学びを得られました。

また、スマキャンの掲げるバリューである「SOCS」(Smart thinking, Ownership, Collaboration, Speed)という考え方は僕の行動指針としてこの先変わらず在り続けるものだと感じています。

半年間という限られた時間でしたが、圧倒的な成長を遂げられたという実感があります。

スマートキャンプでのエンジニアインターンは、「ものづくり」という総合格闘技をしたい人におすすめです!

具体的には以下に列挙しておきます。

  • モダンなフロントエンド開発をしてみたい人
  • アットホームなチーム開発したい人
  • フロントエンドからバックエンドまで一気通貫で開発したい人
  • ユーザファーストなプロダクト開発に携わりたい人

改めてスマキャンの方々には感謝の気持ちでいっぱいです!本当にありがとうございました!!!

f:id:tkgwy:20190228185640j:plain