ディップは新卒一年生でも活躍できる爆速成長環境だった

はじめに

エンジニア1年の振り返りとして新卒研修とそれぞれの配属されてからのお話しをしたいと思います。

新卒研修

研修内容について

開発研修ではディップでの開発業務の基礎を学び、実践しました。新卒3人で2ヶ月間にわたり、1つのシステムをリリースしました。

先輩方から実際の業務レベルの指導を受けながら 19新卒主導で要求整理からリリースまで行いました！

具体的には、

リクエスタからの要望を整理(要求整理)
必要な要件の定義(機能要件定義・非機能要件定義)
システム設計・DB設計
開発
リクエスタとの受け入れなどの調整
リリース
ユーザーマニュアルの作成

を行いました。

研修を通して、私たちは開発業務の基本を学ぶことができました。特に今でも学べてよかったと思う内容として、

社内のウォーターフォール開発の進め方
チーム開発でのgithubの運用
「自分が作りたいものをつくる」個人開発との違い
プロジェクト全体のタスク管理の大切さ
先輩/上長への進捗の報連相
基本的な資料作成

...など、配属前に大切さを実感できてよかったと思います。

作り上げたもの

「社内用語がいい感じにわかる」物が欲しいという要求に対して、私たちはSlackで知らない単語を簡単に検索できるシステム「スラケン」をリリースしました。

f:id:satoshi-baba:20200408144908p:plain

Slackでask "知りたい単語"を送信すると、登録されている言葉を検索し、送信したチャンネルに検索結果を返してくれます。検索結果には正式名称や読み方、その他の呼び方と意味が表示されます。

f:id:satoshi-baba:20200408144927p:plain

発音や綴りがわからない言葉も検索できるように、あいまい検索を実装しています。あいまい検索の解説はこちら

f:id:satoshi-baba:20200408144941p:plain

新卒研修でリリースして数ヶ月経ったスラケンですが、今も部署全体で使われており、他の部署でも使いたい！と要望が出ているサービスです。自分たちで苦労して作ったサービスが使われて、先輩たちが盛り上がっているのを見ると、サービスの開発って楽しい！もっと使われるようにしたい！と開発がもっと好きになりました。

個別の振り返り

@ogihara_xxx

初めましてこんにちは。19新卒でモバイルアプリ開発を担当している@ogihara_xxxです。
今回はディップに入社して1年目の様子について紹介したいと思います。

1年目、どんな事した？

私は、「バイトル」のモバイルアプリを開発するチームで業務を行なっています。掲載されているお仕事の内容を見やすくしたり、応募しやすくなるようなアプリの改修や、ストアにアプリのアップデートを反映させるリリース業務などを行なってきました。
1年目でも重要な機能の開発や、リリース業務に携わることが出来た事で、iOSだけでなく Androidも含めアプリ全体として考えられる視点を身に付ける事が出来たのは大きな学びの１つです。

そんな中で、技術的に印象に残っている事を紹介します。

A/Bテストの実装で...

アプリを改善していく中で、どちらの施策の方が効果的に改善できるかA/Bテストで判断することは多いかと思います。
A/BテストだとAパターンとBパターンの両方実装する必要があり、大変ですね。
抜け漏れも起こりやすくなってしまうと思います。

そんな時、例えばA/Bテストのパラメータなどを定義する場合
実装の仕方を工夫することを学びました。
swiftで値定義する際を例に示します。
２つの同数のパラメータを定義する場合

enum ABTestName: String {
      case testA = "normal"
      case testB = "changed"
}
enum ABTestId: String {
      case testA = "1234"
      case testB = "5678"
}

という書き方も出来ますが、ABTestIdとABTestNameが同数ならば
以下のような書き方も出来ます。

enum ABTestName: String {
    case testA = "normal"
    case testB = "changed"

    func ABTestId() -> String {
        switch self {
        case .testA:
            return "normal"
        case .testB:
        return "changed"
        }
    }
}

このように書いた場合、testBパターンのABTestIdを書き忘れてしまったとしても
switch文のお陰でコンパイルエラーとなり、書き忘れに気付くことが出来ます。
コードを書いていく段階でバグの原因を減らしていく事が
効率的にプロダクトを運用していく上で大切であることに気がつきました。
これはどんなプロダクトや言語にも通じる事だと思います。

1年目を終えて

入社して比較的すぐにメインプロダクトの開発に携わってきた中で
大規模なプロダクトを作っていく中での緊張感や大変なこともありますが、
改善していったアプリがユーザーの方々に使ってもらえて、良いレビューを頂けた時は
とても嬉しく思います。まだまだ、技術者としては駆け出しですが、
より深く技術力をつけてアプリをグロース出来るように頑張ります！

@r-tsuzuki

こんにちは、@r-tsuzukiです。 19新卒で唯一の文系web開発未経験エンジニアとして入りました。入社当初はGitHubの使い方やwebサービスの開発経験がなく、新卒研修で初めて本格的な開発をしました。

1年目の業務

開発演習を終えた後、求人媒体の一括管理サービスである「バイトルマスター」の開発チームに配属されました。開発チームでは、企業の採用効率が良くするための機能や、一目で内容がわかるような画面を開発しています。

今回は、レスポンシブデザインの開発で学んだ話を共有します。

画面サイズが違っても、わかりやすくしたい

Webサービスは、ユーザーが自分にあった使い方ができると思います。じっくり吟味したいときはパソコンの大画面で見比べたり、簡単に確認したいときはスマートフォンで片手でさっと見たり...

画面サイズが変わったとしても、違和感なく、内容がわかるようにすることが大切だと思います。

例えば、パソコンでは違和感なく読める長い項目名がスマートフォンでは折り返したり、隣り合った項目を画面外に配置してしまったりしたら見るためにスクロールしたり、画面を横向きにする必要が出てきてしまいます。

調べた結果、閲覧する画面サイズにあわせて表示を変える方法があることを知りました。

CSSの@media screen and (min-width: 画面の最小の幅)を使うと同じ長い項目の表示でも、

パソコンの大画面で見た時→全部表示するスマートフォンで見た時→最初の数文字だけ表示する

という具合に分けて画面表示を変えられました。

それまで、端末毎に表示を変えられることを知らなかったので、開発で使っている画面のみでの表示確認を行なっていましたが、ブラウザ/画面毎での表示を確認するようになりました。

1年目を終えて

他にも、連携している求人媒体の取り込み処理や、深夜に動くバッチの改修も担当させていただきました。当初開発経験がなく、何をしたらいいかわからなかった状態からフロントエンドからバックエンドまで幅広く経験を積むことで、自分からどういう実装・仕様がいいかの意見を持てるようになりました。

まだまだエンジニアとして技術の理解や視野が狭い部分もあるので、これからより使いやすいwebサービスを開発できるように頑張っていきたいと思います。

@r-kirishima

19新卒としてディップに入社した@r-kirishimaです。
大学は物理化学系で、情報系の知識はおおむね独学です。

開発研修後の本配属では「ナースではたらこ」のユーザサイトを中心に改修するチーム(以下ナースチーム)に所属しています。
ナースチームの特徴として様々な言語や技術を用いたシステムの保守・改修を上流工程からリリースまでがっつり関わることができる、というものがあります。
私自身、様々なプロジェクトへのチャレンジによって技術だけでなく、上流工程でのコミュ力や提案力も大きく伸ばすことができました。

具体的なお仕事の例

速度改善

ある時、企画部門から下記の要求を受けました。

速度改善ツールであるPageSpeed Insightsで[画像の遅延読み込み]をするべきという指摘をされているので対応して欲しい

しかし、対象のページはほとんど画像のないページであるため違和感を覚えました。
そこでフロントエンドを中心に改修を行っているチームと協力して調査を行ったところ、重たいのは確かに画像ではあったのですが、ページの下の方で用いられているGoogleMapの地図データでした。
地図データの受信メカニズムをChromeの開発者ツールNetworkを用いて調べたところ、通常の[画像の遅延読み込み]系の処理を組み込むだけでは読み込み時の地図データ受信を遅らせることはできないことがわかりました。そこでGoogleMapを遅延読み込み化させられるライブラリlazyLoadGoogleMapsを今回は利用することにしました。

調査結果を元に改修方針を企画部門に相談し、無事実装を終えることができました。
その結果として、同サイトの他ページと比べてPageSpeed Insightsのスコアが低かったページを他ページと同等の水準まで引き上げることができました。
また、副次的な効果として画面内にGoogleMapの描画エリアが入るまでAPIを叩かない設定にしたのでAPIを叩く回数が減少し、サービスのコストダウンにもつなげることができました！

本プロジェクトを通しての個人の成長としては下記について学べました。