ソフトウェアエンジニアになって８ヶ月。新規サービスの設計からリリースまで経験してできるようになったこと。
「駆け出しエンジニア」なんて、世間ではいろんな意味で話題に上がるけど、わたしもその「駆け出しエンジニア」のひとりだ。
昨年の９月に、現在の会社に中途入社し、ソフトウェアエンジニアになった。それから、早くも８ヶ月がたった。
入社したのは、自社でwebサービスを開発している３年目のスタートアップで、わたしが７人目のソフトウェアエンジニア。入社当時、ソフトウェアエンジニアとしてのキャリアはなく、前職で分析を少しかじっていたくらい。完全に業務未経験だった。
▽入社して３ヶ月たったころの自分。プログラミング言語（Typescript）も、API 開発も、Github もすべて初めてだった。すでに懐かしい・・・。
この note を書いてから５ヶ月がたった。
この間に、新機能のバックエンド開発とリリース、新サービスのバックエンド開発とリリースを経験した。まったく１から API をもうひとつつくった。その中で自信もついたけど、同時に自信を失ったりした。いろいろ失敗をして、迷惑をかけて、それでもなんとか、つくったサービスは大きな不具合を出していない。
◇
前置きが長くなったけど、これまでに経験したこと、できるようになったこと、今がんばりたいと思っていることについて書いておきたいと思う。ほぼポエムなので、サクッと情報だけ得たい人にとっては冗長な文章かもしれない…。そのときどきの苦悩したポイントも含めて書いていくので、気長にお付き合いいただけるとうれしい。
モノマネコーディングからの脱出
➖
入社当初は、先輩につきっきりになって教えてもらって、みようみまねでコードを書いた。他のレポジトリをあさって、やりたいことに近いことをやっているコードをコピーしてきて、多少アレンジすることで乗り切っていた。なんでこう書いてあるかはよくわからない。みんなそう書いてるからそうなんだろう、と、それなりにタスクももらっていたから、ある程度割り切ってしまっていた部分もある。
３ヶ月がたつ頃には、データベースからデータを出し入れしたり成形するだけの API ならつくれるようになった。このあたりから、「サービスとしてつくる」ことを意識するようになった。
将来的にサービスを広げていくときには、こんな機能がほしいし、ここを自由に設定できるようにしたい。もっと汎用的に、どんな要望にも答えられるようにしたい。次の開発のときには、バックエンドの設計から任せてもらえたから、必要な機能の上にそんなことも意識して設計した。今となっては、今使わない機能を自己満足でつくってしまって、なにやってるんだって感じだけど、当時はあれこれ考えるのが楽しかった。
フロントエンド担当のエンジニアとシステム構成やインターフェースを相談しながら、設計書や API ドキュメントもしっかりつくった。細かい仕様については、PM やデザイナー、QA とコミュニケーションをとって詰めた。至らない部分が多くてたくさんの人に支えられながらだったけど（途中危機に陥って夜遅くまでチームを総動員させながら…）、「言われたことをやる」から「自分で考えてつくる」への第一歩を踏み出せたように思う。
◇
落ち着いた頃、先輩との１on１（面談）で、「自分がなにを勉強したらいいのかわからない」という話をした。そのときに、「今目の前にあるコードをひとつずつ理解していけば、自然と技術はついてくる」と言われたことが印象に残っている。思えば、あのとき危機に陥った原因は、自分の書いたコードにミスがあったからだった。ミスに気づかなかったのは、書いてあることの意味を理解せずに、そのまま真似して書いていたからだった。
ソフトウェアエンジニアは、ソフトウェアをつくることに関するプロフェッショナルだ。プロだったら、知らなかったでは済まされない。知らなかったとしても、それをわかるようになるよう努力することが仕事だ。わたしはプロのソフトウェアエンジニアになりたいと、当たり前のことを自覚した。
◇
このときの１on１では、あのときこう思った、こう考えてたっていうことを結構吐き出した。自分なりに悩んでたということを伝えたかった。本当に子供っぽくて自分でもいやになるけど、全部聞いてもらえてすっきりした。ひとりで抱えていたら、今まで続いてなかったかもしれない。でも、今じゃなくてもっと早く伝えていたらとも思う。
忙しい現場だと特に、開発は結構孤独な戦いになる。間に合わないときに、自分ひとりで抱えて乗り越えたくなる。でも、手遅れになる前に、勇気をもってだれかに打ち明けることが重要だ。目の前の問題は自分の問題じゃなくて、チームの問題だし、会社の問題だ。わかってるけど、今でも自分ひとりでやり切りたくなってしまうのは自分の性格なのかもしれないけど、ちゃんと周りを頼って、逆にだれかが困っているときに頼ってもらえるようになりたい。
DDD（ドメイン駆動開発）への入門
➖
ある日、会社の先輩から、DDD のレクチャーを受けた。
最初はよくわからなかった。ドメインってなに？ユースケースってなに？依存ってなに？責務ってなに？本を読んでも全然わからないけど、質問したり、自分でコードを書いていると、ふと、そういうことかってわかるようになる。かと思えば、またわからなくなる。不思議だった。
当時はオブジェクト指向もよくわかってなかったので、本当にわかってなかったんだと思う。正直、今もよくわかってない。
でも、DDD でやりたいことは、なんとなくわかるようになってきた。アプリケーションによって「問題を解決する」ということを主軸に置いた設計手法。その思想はとても共感できた。それぞれの層で責務を分割し、コアのドメイン層では、そのアプリケーションが本来解決したいことに集中してコードを書く。やりたいことが変わったとき、システムや環境が変わったときに、どの層をどう修正すればいいかわかりやすい。
今までAPI のディレクトリ構成が謎で、なんでこんなに複数のファイルを経由するのかよくわからない…と思っていた。教えてもらっても、ドメイン層では Entity が… VO が…というのもなんじゃらほいだったけど、謎が解けた。あーあれはこういう意味だったのか、っていうのがつながった。
最初のレクチャーで参考にした資料は今でもお守りみたいに何度も見返しているし、DDD のカンファレンス（現場でDDD）や最近では松岡さんのオンライン勉強会にも毎回参加している。設計手法は本で読むより、実際に自分で書いたり、だれかの書いたコードを見たり、苦悩の軌跡をたどるのが１番理解しやすい。それは正解がないからだろう。定石は押さえた上で、この場合はどうかと考えることが重要だから、話を聞きながら、考え方のエッセンスを取り込んでいきたいと思っている。
▽ちなみに、今のお守りはこちら。常にこのPDF版を開いてる。手元には紙書籍版もある。
ドメイン駆動設計 モデリング/実装ガイド 松岡幸一郎 著
開発フローを考える
➖
DDD のレクチャーからしばらくあとに、先輩から TDD（テスト駆動開発）の動画を見ながらレクチャーを受けた。（忙しい中ほんとうにありがたい…）
テストって、コード書いたあとにだめ押しで書くと（なぜか）思っていて、書くのめんどくさいなぁと思ってほとんど書いてなかった。だから、TDDの手法は目からウロコだった。
動画の中では、最初にやりたいことを書き出して、小さな処理のコメントに分けてひとつずつ処理のアウトプットを確かめるテストを書き、コードを書く、という流れ。コードって、最初から頭の中にあったみたいに書かれてるなって思ってたけど、「言語化された仕様を分解して、処理に落とし込む作業」が、設計書かテストか頭の中で行われた上で書かれているのかと、プログラマーの思考を覗き見しているような感覚で面白かった。
実際は、全部テスト書いてるわけではないし、１度 TDD で VO つくってみたけどめちゃくちゃ大変だった。でも本当にコアの難しい処理を書くときとか、なにから手をつけていいかわからない状況での実装の糸口として実用的な手法だと思う。
▽ 松岡さんもいつもTDDで開発してるらしい。動画は、リンク先の視聴用URLから無料で見れる。決して松岡さんの回し者ではない。ただのファン。
◇
今は、設計するのに、手書きで書いたり、テキストで書いたり、スプレッドシートを使ったり、draw.io や PlanUML で図を書いたり、OpenAPI 使ったり、いろいろ試して自分に合うフローを探している。自分だけがわかればいい資料もあるし、だれかに共有するため、残すために必要な資料もある。完全にドキュメントしか書いてないわ自分大丈夫かって思うこともあるけど、他の人に怒られてないのでたぶん大丈夫（？）
「仕様が決まってから実装を始めるまでの開発フローを考えてほしい」というミッションが与えられたこともあった。そのときにいろいろ調べて考えて、ドキュメントにまとめてチームに発表したけど、たぶんそのとき考えたフローを参考にしている人だれもいないんじゃないか（わたしもあのドキュメントほぼ見ていない）。あれは確かに机上の空論だった。でもそのときの結論は結局、「実装を開始するのに必要なことはインターフェースを決めることだ」ということだった。細かい実装のことをすべて共有するのは現実的でないけど、どんなリクエストを受け付けて、どんなレスポンスを返すか、というバックエンドとフロントエンドの「インターフェース」に考えるスコープを絞れば、これを守る約束のもと各々実装を進められるし、変更したくなったときに相談したらいい。それに気づけただけでもよかった。
とはいえ、チーム開発のフローはもっといい形がある気がする。今ではエンジニアもメンバーが増えて、いかに円滑にコミュニケーションをとって、開発を進められるかは今も重要なミッションだ。もうちょっとちゃんと考えて、実践的な形でみんなに提案できるよう、いつかリベンジできたらいいな。
コンプレックスとプライド
➖
これだけたくさんのことを与えてもらっていながら、最近の自分はちょっと変だ。
いくつか新規サービスの立ち上げや、新機能のリリースに携わって少しは慣れてきたと思う。コードを書くのも、少し自信がついてきた。とはいえ、知らないことはたくさんあって、会話とか MTG で、みんなが何を言ってるのか全然わからないときがある。やりたいことをうまくモデリングできないとき、指摘を受けて自分が考えきれていないことに気付かされたとき、ああ、わたしやっぱり向いてないでは？と、必要以上に落ち込むときがある。
なんだか悔しい気持ちになる。悔しくて、それを表に出してしまうこともある。最初右も左もわからない頃は、悔しいなんて、思いもしなかった。いっちょ前にプライドだけ育ってきてしまっている。
自分の態度を振り返ってはまた落ち込むのだけど、こんなことで落ち込んでいることに意味がないこともわかっている。みんな、わたしに期待をもって、いい技術者になれるって思ってくれてるんだって信じてる。今まで１年もたってないけど、会社には結構入り浸ったし、会社のみんながどんな人かはちょっとずつわかってきた。みんな自社のサービスに共感して、これをもっと多くの人に届けたいって思って仕事してるのがわかる。だから自分も同じ方向に向かって、いっしょにものを作り続けたらいいって、これを書きながら思った。
どうしようもないコンプレックスとプライドは、物心ついたときからわたしの中にいる。だれかに認めてほしい気持ちがコントロールできないときがある。それをいい方向に伸ばすために技術者になった。ものをつくるために技術をつける、ものをつくって世の中に届けて、多くの人が今よりもっと好きになれる世界にしたい。それができる今の仕事が好きだし、これからも自分の想いで相手や自分を傷つけるんじゃなくて、そのエネルギーをサービスをつくることに注ぎたい。
どんなエンジニアになりたいか
➖
今扱っている技術的なところをざっとだけ書き出しておく。言葉の使い方とか間違ってるところがあればごめんなさい。（こっそり教えてもらえるとうれしいです…）
・Githubを使ったチーム開発
・Typescript, Node.jsを使ったAPI開発
・Vue.jsを使ったフロントエンド開発（社内ツールの改修のみ）
・Webサービスのバックエンド設計（API設計、データベース設計）
・MySQL（DB）
・AWS の設定（DNSとかCloud Frontとか、簡単な設定だけ）
・OpenAPIを使ったAPIドキュメント作成
・コードレビュー
（△頭に全部「基礎的な」をつけてくださいね…。）
無理をして書き出してみたけど、まだまだ一人前のスキルではないと思う。でも、これだけいろいろ経験させてもらって、なんとなく雰囲気はつかめてきたように思う。
これからこんなことがしたい、っていうのは、残念ながら明確にはまだない。自分は他の人より技術への好奇心が薄いのかもしれない。根本的にめんどくさがりで、この note も書き出すのに２ヶ月くらいかかった（本当はキリよく６ヶ月めで書きたかった）。
どんなエンジニアになりたいか、というより、どんなエンジニアでありたいか、という今の気持ちでいうと、「つくることのプロフェッショナルでありたい」。技術は、よほど苦手でない限りなんでもいい。言われたことをやるんじゃなくて、ユーザーや社内のメンバーのやりたいことを引き出して、プロダクトづくりに自分から関わっていきたいし、必要な技術や知識はどんどん身につけたいし、チームの力も引き出せるようになりたい。どんな方向にも伸びしろだらけだけど、やりがいはある。やればやるほど、仕事に活かせる自信があるし、やればやるほど世の中の役に立つ仕事だって思えるからだ。
◇
ここまで書いて、自分こんなこと考えてたんだって自分でちょっとびっくりした。人とゆっくり話すことが少なくなって、心の中のもやもやを言語化することがなかったからかもしれない。夜になるとぼんやりしてしまうことが多かったけど、自分の悩みがちょっとクリアになった気がする。
今、緊急事態宣言の影響で在宅勤務も２ヶ月めになった。みんなだんだん慣れてきて、いつもどおりに走れるようになってきた。在宅勤務でも、だからこそ、プレッシャーも感じている。がんばるだけじゃなくて、ちゃんとアウトプットが出せているか、意識するきっかけになった。まだまだできてないことが多くて申し訳なく思ってばかりだけど、このままみんなで走りきりたい。
この記事が気に入ったらサポートをしてみませんか？