PLAID Engineer Blog

PLAID Engineer Blog


KARTEを提供する株式会社プレイドのエンジニアブログです。プレイドのエンジニアのユニークなパーソナリティを知ってもらうため、エンジニアメンバーたちが各々執筆しています。

PLAID Engineer Blog

新卒エンジニアから見たPLAID、そこで得られた経験と学び

Kei TamiyaKei Tamiya

こんにちは。エンジニアの@kei-tamiyaです。2018年4月に新卒で入社して8ヶ月ほど経ちましたが、エンジニアとして実際に何を学んだのか、入社する前に思っていたイメージは実際働いてみてどうだったのか、について振り返ってみたいと思います。
 こちらの記事はPLAID Advent Calendar 2018 4日目の記事でもあります。

想定読者

PLAIDの「人」や「考え方」に興味を持っている方
PLAIDにはエンジニアとしてどんな成長機会があるか知りたい方

入社前に抱いていたイメージ

入社する前には累計2,3ヶ月ほどインターンをしていました。その間に、入社すると思考面と技術面に関して以下のようなことが経験できて得られそうだなと考えていました。

思考面

(A) 物事の本質を捉える力を高められそう

  • 常に目的に対して正しいと思う意見をぶつけ合う
  • 間違っているものや考えはガンガン捨てる

(B) 自分が最高に楽しいと思える何かを見つけられそう

  • プロダクト愛と熱量を持っている人が多い
  • その環境でのめり込んで開発すると気づきがありそう

技術面

(C) 全般的な開発技術を習得できそう

  • フロントエンド・サーバーサイドで職種を分けていない

(D) サーバーサイドの開発力をしっかり高められそう

  • これまでフロントエンドの経験が多めだったのでサーバーサイドを強めたい
  • 高トラフィックを前提にして、多種のDBを扱う経験ができそう
  • GCPをメインで使い倒していて、かなりのトラフィック・データ量がありそうなのも面白そう

(E) 早い段階で高難易度な経験を積めそう

  • KARTEが機能単位でプラガブルな(拡張性の高い)実装になっている
  • 一人で丸ごと実装を担当できそう

これらそれぞれが実際にはどうだったのかを振り返ってみます。

実際にはどうだったのか

思考面

(A) 物事の本質を捉える力を高められそう

実際にこの考え方を感じる場面・実践する場面は非常に多いです。「これってなんでやってるんだっけ?」「そもそも何を解決したいんだっけ?」という問いに立ち返り、元来の目的を再認識した上で現状で取りうるより良い方針に修正をし、トライするといった改善を行えるのは非常に建設的で面白い環境だなと思います。

そもそも私は人の感情を考えてなるべく不快な気持ちにさせないように発言・行動することを大切に生きているので、言葉を意識しすぎて逆にわかりにくくなったり、わざわざ議論しなくてもいいかと問題解決から遠のいてしまうことが多い人間だったのですが、「ああ、ここまではっきり言っていいんだ」と気付かされたのは大きな驚きでした。

「自分たちが解決したいことは目の前の課題および長期的な目標であり、それは達成すべき非常に重要なものである」という前提に立って考えると、事実ベースで課題の本質を認識して発言・共有することでチームとして向き合って解決していくことが重要で、目先の考えすぎな気遣いや感情等は不要なものである場面がほとんどなのだと認識できたのは思っていた以上に自分が成長できたことだなと感じています。

(B) 自分が最高に楽しいと思える何かを見つけられそう

私はそもそも何か特別にやりたいことがある人間ではありませんが、最高にのめり込めることを見つけることが目下の人生の目標だったりします。弊社のメンバーは前職までの経験でWeb上のユーザー体験に対して疑問や課題を感じたために、KARTEの「多様なデータをひとりの人として理解し、一人ひとりに合わせた体験づくりをする」という世界観に共感しているメンバーが多く、そのモチベーションを間近で感じて自分の探したい「何か」の参考にしたいなという思いがありました。

最近では月に1度エンジニア全体で、長期的な未来にKARTEを通して成し遂げたい理想像を全員でディスカッションするような場を設けています。普段の開発で精一杯になって視野が狭くなっていましたが、一歩引いて開発している意義を理解することによって、以前よりも主体的な立場で将来を見据えて開発に取り組めるようになりつつあると感じています。
 
自分の中でまだ「何か」は見つかってはいませんが、何かを成し遂げていくということは「圧倒的な熱量」と「覚悟」が必要なんだなと学んでいます。

技術面

(C) 全般的な開発技術を習得できそう

経験できています。役割を完全に分離して開発する形態は、どこか一部門の開発が遅れることでボトルネックになった場合に開発全体が滞ってしまったり、効率が悪くなってしまうような状態が好きではなかったので、機能ごとにIssueを切ってプロジェクトの進行状況やチームの状況次第で誰がどのIssueを担当してもある程度開発できる点はストレスフリーで良いです。

しかしながらまだまだ自分の開発速度も遅く、機能単位で担当する分、大きな機能を丸ごと実装する際はかなり時間がかかってしまって自分がチームのボトルネックになってしまうケースは多いです。この点は課題ですが、割と重要な機能であっても、実力がある程度伴っている場合においては自分で手を挙げれば任せてもらえるので、もっとできることを増やしていこうというモチベーションは高まります。

(D) サーバーサイドの開発力をしっかり高められそう

これも経験できています。学生の頃はフロントエンドの開発をメインで行っていましたが、先述したように幅広く開発技術を習得したい思いもあり、大規模トラフィックを考慮したDBの設計・運用ができて、開発速度の速い環境が良いなと考えていました。実際に規模の大きい配信機能の修正を担当する機会もあり、使われている諸々のDBの仕様を色々調べてキャッチアップし、コードを順に追いつつ理解して実装することで少しずつ実装力が上がってきていると感じています。
 
今年特に多く触れた機能の例としては、Node.jsからのBigQueryやSpannerの操作、QueueとしてのMongoDB, Spanner, Redis, Cloud Pub/Subの活用、Redisを用いた重複配信の制御などの実装・修正・レビューを行い、課題の解決手段の幅が非常に広がりました。

(E) 早い段階で高難易度な経験を積めそう

開発要件が多い新規の機能を少人数のチームで実装していたこともあり、大きな機能単位で担当する機会は早い段階で得られました。方針が定まっていない状態で大きめの機能を担当した際は、必要要件は何があるのかを誰に聞いて、どの粒度でIssueを分割してどの順で開発を進めれば良いのかがわからず相当な時間がかかってしまいました。技術力が至らなかったのはもちろんですが、どちらかというと仕事の進め方・コミュニケーションの取り方の点で圧倒的に力不足を感じて悔しかったので、「エンジニアリング組織論への招待」を読むなどして自分の何が問題だったのかについて冷静に理解して、不確実性と向き合う日々を絶賛送っています。

学んだこと

ここまでの内容を一度まとめると、以下のことを学び、徐々にできるようになってきているなと実感しています。

  • 目的を達成するために、不要な感情を切り離して、本質的な課題に対して向き合うこと
  • 適切なコミュニケーションによって課題を理解し、解決可能な単位に分割すること
  • 目の前の課題と長期的な課題を適切に捉えることで、主体的に開発に参加すること
  • Node.js, Vue.js, 各種DB(MongoDB, Redis, BigQuery/BigTable/Spanner等のGCP周り)を用いた開発力の向上
    • 大規模トラフィックを考慮した実装
    • 実装力(適切な実装方法を考える力、コーディング速度や可読性)
    • 知らない技術を使用する際のキャッチアップ力

思考に関しては、入社前に体験できそうだと思っていたことを実践し自分なりの解釈をすることで新たな発見と学びを獲得し、技術に関しては新たな「学び」というよりは着々とできることが広がっている感覚です。

逆に自然には学べていないこと

もともと得たかったものは意識して取り組んでいることでもあり、ある程度身につくのは当然なので、逆にあまり伸びていない能力や課題感についても触れておきます。

  • フルスクラッチでの開発力・企画力
  • 厳密なスケジュールや方針を立てる力・厳格なテストを書く力
  • 確実に予定通りに達成していく力

現状での開発は基本的にKARTEの開発がメインで、新規事業としてはKARTE for AppKARTE Datahubなどの規模感の大きい機能を実装する形式なので、新規プロダクトを完全にゼロから開発する機会はまだ経験していません。現状で稼働している環境との親和性を考えてアーキテクチャを考える機会は多いですが、フルスクラッチでアーキテクチャ・フレームワーク等を考えて実装したり、ビジネスプランそのものを考えるなどの機会は少ないです。

また、スピード感をかなり重視し、今書いているコードは全て壊すぐらいのつもりで書く文化なので、全体の完全な設計や綿密なスケジュールを立てたり、仕様書通りに実装をするといったスキルは身についていません。テストに関しても、サーバーサイドのユニットテストがメインでコア部分をしっかり守る程度で、厳格に取り組んだ対象とは言えないです。

綿密な計画を立てないのは、より良い方針が浮かぶことでの仕様変更があったり、差し込みがあることを前提としていたり、「その場しのぎの実装」ではなく「少し時間をかけても根本的解決・より良い状態となる実装」を選ぶ傾向があるため、決められた時間内にある一定量のタスクを確実にこなしていくようなスキルは意識しないと高まらないと感じています。社内の開発スピードは非常に早いので、現状では成長余地を見込んで任せてもらえる内容も、「より良いものを作るためならどれだけ時間をかけてもいいんだ」といった勘違いをしてズルズルと長引かせていては自分がボトルネックになってしまいます。

そのため、意識的にミニマム機能を実装する期限を設定したり、この時間内にこれだけの機能を実装し終える、といった目標設定を都度しながら開発する必要性を感じています。

まとめ

本記事では、PLAIDの新卒エンジニアとして8ヶ月働いたことで私が学んだことを、入社前に抱いていたイメージと実際に感じたこととを比較することで考察しました。
特に、課題への向き合い方や適切なコミュニケーションの重要性についての思考の変化と、KARTEの開発を通して経験できた技術/あまり自然には学べてはいない能力の一例を紹介しました。

なお、この記事の内容は完全に私の主観によるものですが、チーム環境や開発時の状況によって得られる経験も違うため、あくまでも1人のエンジニアの体験記として捉えていただけますと幸いです。

最後に

CX(顧客体験)プラットフォーム「KARTE」を運営するPLAIDでは、KARTEを使ってこんなアプリケーションが作りたい! KARTE自体の開発に興味がある!というエンジニア(インターンも!)を募集しています。
詳しくは弊社採用ページまたはWantedlyをご覧ください。もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください!

Kei Tamiya
Author

Kei Tamiya

Comments