未経験からスマートショッピングのエンジニアに転身してみて
Japanese follows English (英語の後に日本語が続きます)
Introduction
Hi, I am @hiropalla1692 who joined SmartShopping as a frontend engineer about 6 months ago. Through the job-change I finally move back to Tokyo for the first time in 6 years. Even under the unfortunate circumstances where omicron variant has widely spread, a part of what makes me re-recognize I came back to Tokyo is a time when I find a good place to go (like a good taste indie record shop) on the Internet and find out it is located on the area I can visit on foot. In my opinion living in the heart of Tokyo still deserves more than a high rent!
Anyway, when I was thinking about writing an entry post, what is unique about myself is I was not a Software Engineer before (maybe at this point I am the only member who do not have engineering background nor career in the team), so I would like to write first about how I feel about the engineering team of SmartShopping from the point of view of ex-non-engineer and secondly the path which led me to be a software engineer from a different career. It is not my intention to focus on following my own story, but to some extent might be, sorry. I would be happy if this post could give something valuable to those who try hard to become a Software Engineer from a different career like me.
How I feel about the engineering team of SmartShopping
First, the below is a part of what I did as a frontend engineer for this first six months.
What I did for the six months
- Tiny improvement tasks about existing functions (Vue.js / Nuxt.js)
- Built a new function with reference to existing functions (Vue.js / Nuxt.js)
- Made specific design of a new function with Pdm & Designer team and implemented the functions (Vue.js / Nuxt.js)
- Wrote some unit tests (Vue Test Utils)
- Wrote some E2E tests (Cypress)
- Redesigned this engineering blog (React / Next.js / Tailwind CSS)
At first almost everything I saw was new to me and felt anxious vaguely whether I would do well as an engineer, but thanks for several good cultures at SmartShopping, I was able to get off to a good start as an engineer and contribute to the products much more than I had expected. I would like to show you some of the cultures.
1. Easy to ask
This doesn’t look ambitious culture, but I feel this is technically one of the most important one especially for junior or unexperienced engineers. Team members often said to me that I should not hesitate to ask questions whenever I am in trouble for a long time. Of course, a part of the reason why they often said to me was the fact that I started working as an engineer for the first time, but except me, members frequently asked questions and always well communicated with each other as needed even about a little things.
The way to ask questions depends on how serious the trouble is. If it is a small one, we use text messages of Slack, and if it is the one we will take some times to solve, we can do pair programming sharing an editor screen with Google Meet. Under the great environment, I was able to do my jobs without unnecessary pressures like I have to solve everything around me by myself.
2. Documentation culture
We always have a motivation to enhance the both quality and quantity of documentations. We all have shared the idea that enhancing the documentations is a way that helps us to unite our thoughts and shorten time to solve something. When it comes to on-boarding, we have continued to add new documents about how to setup development environment and how our systems really work in details, which enables a new member to catch up easily. In addition to that, there are some documents which help us to develop smoothly in practice. In my case, I had never written a test code before the join (omg), so having documents of tips and templates about Vue Test Utils was so helpful to understand how they work and learn in advance anti-pattern that many encounter.
3. Personal OKRs
We set both team and personal OKRs every semi-annual. Both share the same objects and each member set personal key results which is more specific than team one. After setting key results, we have a regular opportunity to observe and review them through 1on1 meetings with managers.
This is the first time that I have worked with the indicator, and there are several points that affects how I work in a good way. For instance, whenever I had spare time, without thinking about what I should tackle next, I was able to jump in the tasks related to my key results, which gained my productivity as a result. On the other hand, when I had too many things to do at the same time and picked up one, it is easier to prioritize the task related to my key results and personal OKRs are always open to team members, so which tasks I prioritized is comprehensible for them anytime.
What I will do next
As described above, I am very satisfied with where I am now because of the great team and team members though as a frontend engineer, there are a lot of things that I have to catch up and learn. Some members are now working on building a new function using React and GraphQL in the front-side, so in the near future I hope I can contribute to the project.
As an extra, I would like to describe a part of what enabled me to become an engineer from scratch in hindsight.
Finished the tutorial, but what’s next?
When I decided to learn coding by myself, I first just started taking online courses and tutorials that many people said are suitable for beginners without any deep consideration. By spending a lot of my time to take these courses mainly on weekends, I was actually able to understand a very basic syntax (in my case Javascript). However at some points I realized that unlike entrance exams, there is no concrete target where I should aim at in terms of learning coding and felt puzzled about what I should do next.
I suppose that is a kind of typical situation where many self-taught engineer would encounter while learning, so I would like to introduce the path I chose next.(I’m not sure whether it is practically good or not.)
Solve the problem you are really in trouble
I mostly agree with the idea which many pointed out that after taking several tutorials you should develop your own service as a portfolio which you can show in the job interview. What I could add to this is that you should develop services that solve the problem you are really in trouble in your daily life instead of cloning existing services which is just for the appeal of your coding skills. In my opinion, it doesn’t matter how large or small the problem you chose to solve is, and the key point is the process you go through when solving your own problem. While solving the problem by the power of engineering, you can automatically experience some processes that an engineer usually go through in practice.
Let’s compare the two examples.
a. Cloning an existing service
- (HOW you develop)
- WHAT you develop
When cloning existing service, maybe the service is popular one, and I suspect it is not difficult to find out on the Internet how to create and what kind of technology are being used. Therefore, the main thing you focus on is to comprehend how it works and actually develop as it is like. That sounds not a bad flow you would practice, but the other one seems a bit more special to me.
b. Creating a service which solve your own problem
- WHY you develop
- HOW you develop
- WHAT you develop
When you create a service which solve a unique problem, you have to start off grasping the reason why you feel a trouble and deliberately defining the concept of what you will create to solve what makes you feel inconvenient. Next you try to think about how to develop and what kind of technology you will use, and at this phase there seems more things that you have to take into consideration than developing existing service since you need to develop a unique service which you can not discover the perfect tutorial of how to develop. After going through the processes, you can finally develop what you really want to develop!
When I actually developed the service 🏊♂️swimgood.io which enables you to instantly analyze individual U.S. stocks, the process was like the below.
- WHY you develop
- you want to reduce the time to collect the financial data to analyze
- you want to quickly analyze the stock
- HOW you develop
- you access 3rd party api which gives you adequate amount of financial data
- you adopt JS framework which enables you to use server-side rendering (Next.js) to avoid exposing the secret key of the 3rd party api
- you don’t need any DB because you don’t need to login and logout
- you adopt recharts to make graphs
- you adopt useContext which is simpler than Redux as state management system because you preserve very limited variables like the symbol of the stock you search
- WHAT you develop
- the service which enables you to instantly analyze individual U.S. stocks by visualizing 10-year transition of how the condition of the stock has changed
For those who do not have the experience of engineering in practice, it is pretty hard to pass your application form partly because there are few factors which allow recruiters to imagine the situations where they want to work together compared to people who had experiences as an engineer before. In terms of how to pass your application and interview, being able to writing up and telling the above engineering process with a lot of enthusiasm would be a silver lining for you because as I mentioned before, that is in some ways the similar thing that engineers really go through in practice when developing something new, which makes it easier for recruiters to imagine how they work together.
Some claim that thinking about why you develop might be out of the scope of what an engineer should care about, but when it comes to a startup, there is much room to improve almost everything, so the mindset is a part of the elements that I think are well-received in having an interview.
はじめに
半年前にフロントエンドエンジニアとしてスマートショッピングに入社しました、@hiropalla1692です。転職を機に、6年ぶりに東京に帰ってきました。オミクロン株が蔓延する不幸な状況下でも、東京に帰ってきたことを再認識するのは、ネットで見つけた良い店（センスの良いインディーズレコードショップなど）が、徒歩で行けるエリアにあることを知った時です。都心に住むということは、高い家賃以上の価値があります。(自分に言い聞かせる。)
さて、入社エントリーを書こうと思ったとき、私自身のユニークな点は、以前はソフトウェアエンジニアではなかったことです（おそらく現時点で、チーム内でエンジニアのバックグラウンドもキャリアもないメンバーは私だけかもしれません）。そこで、まずは元・非エンジニアの視点からスマートショッピングのエンジニアチームについてどう感じているか、次に、私が別のキャリアからソフトウェアエンジニアに至る道について書きたいと思います。私自身のストーリーを追うことに重点を置いているつもりはありませんが、ある程度はそうなってしまうかもしれません、すみません。この記事が、私のように異業種からソフトウェアエンジニアを目指そうとしている人たちにとって、何か価値あるものになれば幸いです。
SmartShoppingのエンジニアチームについて感じたこと
まず、この半年間、フロントエンドエンジニアとしてやったことの一部を紹介します。
半年間、私がやったこと
- 既存機能（Vue.js / Nuxt.js）の細かな改善作業
- 既存機能を参考にした新機能の構築（Vue.js / Nuxt.js）
- Pdm & Designerチームと新機能の具体的な設計を行い、機能を実装した (Vue.js / Nuxt.js)
- ユニットテストの作成 (Vue Test Utils)
- E2E テストをいくつか作成 (Cypress)
- テックブログのリデザイン(React / Next.js / Tailwind CSS)
最初は見るもの全てが初めてで、エンジニアとしてやっていけるのか漠然とした不安を感じていましたが、スマートショッピングのいくつかの良い文化のおかげで、エンジニアとして良いスタートを切ることができ、自分が思っていた以上にプロダクトに貢献することができました。その文化のいくつかを紹介したいと思います。
1. 気軽に質問できる
これは一見野心的な文化には見えませんが、技術的には特に若手や未経験のエンジニアにとって最も重要なものの一つだと感じています。チームメンバーからは、「困ったことがあったら遠慮なく質問してください。」とよく言われます。もちろん、私が初めてエンジニアとして働き始めたということもありますが、私以外のメンバーも頻繁に質問をし、些細なことでも常にコミュニケーションをとっていました。質問の仕方は、トラブルの深刻さによって変わります。小さなものであればSlackのテキストメッセージを使い、解決に時間がかかるものであれば、Google Meetでエディタ画面を共有しながらペアプログラミングを行うこともあります。このような素晴らしい環境の下、「周りのことを全部自分で解決しなければならない」というような余計なプレッシャーを感じることなく、仕事をすることができました。
2. ドキュメンテーション文化
私たちは常に、ドキュメントの質と量の両方を高めたいというモチベーションを持っています。ドキュメントを充実させることは、お互いの考えを一致させ、解決までの時間を短縮することにつながるという考えを、全員が共有しています。オンボーディングに関しても、開発環境の構築方法やシステムの仕組みなど、新しいメンバーがすぐにキャッチアップできるようなドキュメントを継続して追加しています。それに加えて、実務でスムーズに開発できるようにするためのドキュメントもあります。私の場合、入社するまでテストコードを書いたことがなかったので（笑）、Vue Test Utilsに関するTipsやテンプレートのドキュメントがあることで、その仕組みを理解し、多くの人が遭遇するアンチパターンを事前に学ぶことができ、とても役に立ちました。
3. 個人のOKR
半期ごとにチームと個人のOKRを設定しています。どちらも同じ目標を共有し、各メンバーはチームよりも具体的な個人目標を設定します。設定後は、マネージャーとの1on1ミーティングを通じて、定期的に観察・レビューする機会を設けています。私は今回初めてこの指標に基づいて仕事に取り組みましたが、良い意味で仕事の進め方に影響を与える点がいくつかありました。例えば、時間が余分にあるときは、次に何をやろうかと考えずに、自分の成果に関連する仕事にすぐ着手することができ、結果的に生産性が上がりました。逆に、やりたいことがたくさんあって、どれかひとつに絞るは、自分の成果に関連するタスクに優先順位をつけやすく、個人のOKRは常にチームメンバーに公開されているので、どのタスクに優先順位をつけたかは、いつでもメンバーに理解されるようになっています。
次にやること
以上のように、フロントエンドエンジニアとしてキャッチアップしていかなければならないことは引き続きたくさんありますが、素晴らしいチームとメンバーに恵まれているため、今の自分のいる環境にとても満足しています。現在、フロントサイドでReactとGraphQLを使った新しい機能を構築しているメンバーもいるので、近い将来、自分もそのプロジェクトに貢献できればと思っています。
—
おまけとして、ゼロからエンジニアになれた理由の一端を、後から振り返って述べてみたいと思います。
チュートリアルを終えたけど、次はどうする？
私がコーディングを独学で学ぼうと思ったとき、最初は多くの人が初心者向けと言うオンラインコースやチュートリアルを、深く考えずにただ受講し始めたのです。週末を中心に時間をかけて受講することで、ごく基本的な構文（私の場合はJavascript）を理解できるようになりました。しかし、受験とは違い、具体的にどこを目指せばいいのかという目標がないことに気づき、戸惑うこともありました。これは多くの独学エンジニアが遭遇する典型的な状況だと思うので、私が次に選んだ道を紹介したいと思います(実践的に良い道かどうかは分かりませんが)。
本当に困っている問題を解決する
多くの方が指摘されている、チュートリアルを何度か受けた後、自分のサービスをポートフォリオとして作成し、面接で見せるという考えにはほぼ同意します。ただ、これに付け加えるとすれば、自分のコーディングスキルをアピールするために既存サービスを模倣するのではなく、自分が日常生活で本当に困っていることを解決するサービスを開発するべきだということです。私が思うに、解決しようとする問題の大小は関係なく、重要なのは自分自身の問題を解決する際のプロセスだと思うのです。エンジニアの力で問題を解決していると、エンジニアが普段実践しているようなプロセスを自動的に経験することができるのです。
2つの例を比較してみましょう。
a. 既存サービスのクローン
- (どのように開発するか)
- 何を開発するのか
既存のサービスのクローンを作る場合、もしかしたらそのサービスは人気のあるものかもしれませんし、作り方やどんな技術が使われているのか、インターネットで調べることは難しくないのではないでしょうか。ですから、その仕組みを理解し、実際にその通りに開発することに主眼が置かれます。それはそれで悪くない流れだと思いますが、もう1つはもう少し特殊な気がします。
b. 自分の問題を解決するサービスを作る
- なぜ開発するか
- どのように開発するか
- 何を開発するか
独自の問題を解決するサービスを作る場合、まず自分がなぜ困っているのかを把握し、その不便さを解決するために何を作るのか、コンセプトを明確にすることから始めなければならない。次に、どのように開発するか、どのような技術を使うかを考えますが、この段階では、既存のサービスを開発するよりも、どのように開発するかの完璧なチュートリアルが見つからないユニークなサービスを開発する必要があるため、考慮しなければならないことが多いようです。このようなプロセスを経て、ようやく自分が本当に開発したいものを開発することができるのです。
実際に私が米国個別銘柄を瞬時に分析できるサービス 🏊♂️swimgood.ioを開発したときは、以下のような流れで進めました。
なぜ開発するか
- 分析する財務データの収集時間を短縮したい。
- 素早く銘柄を分析したい。
どのように開発するか
- 十分な量の財務データを提供するサードパーティのAPIにアクセス。
- サーバーサイド・レンダリング（Next.js）を使用できるJSフレームワークを採用し、サードパーティAPIの秘密鍵の公開を回避。
- ログイン、ログアウトが不要なため、DBが不要。
- グラフを作成するためにrechartsを採用。
- 検索する銘柄のシンボルのような非常に限られた変数を保持するため、状態管理システムとしてReduxよりもシンプルなuseContextを採用。
何を開発するか
- その銘柄の状態がどのように変化したのか、10年間の変遷を可視化することで米国個別銘柄を瞬時に分析できるサービス。
実際にエンジニアの経験がない人にとっては、エンジニアの経験がある人と比べて採用担当者が一緒に働きたい場面を想像できる要素が少ないこともあり、エントリーシートを通過するのはかなり難しいです。応募書類や面接を通過する方法としては、上記のエンジニアのプロセスを熱意をもって書き上げ、伝えることができれば、先にも述べたように、それはある意味、エンジニアが新しいものを開発する際に実際に経験していることと似ているため、採用担当者が一緒に働きたいと想像しやすくなるため、あなたにとって光明となるのではないでしょうか？なぜ開発するのかを考えるのはエンジニアの範疇ではないと言われることもありますが、スタートアップの場合、ほぼ全てに改善の余地があるので、このマインドセットは面接で評価される要素の一つだと思います。