1
/
5

初めての実務経験から、プロダクト開発の最前線へ|Optixエンジニアインターンブログ

自己紹介

初めまして、株式会社Optixのインターンでエンジニアとして入った梅津と申します!

今Optixへのインターンを検討している人に向けて、僕がOptixのインターンを通じてどのようなことを学んでいるかなどを書いてほしいと言われてこの記事を書くことになりました。

Optixに入社した理由は、趣味開発だけでなく、ビジネスの世界で実務での開発経験を積みたかったからです。同じような気持ちの方がきっといるかなと思うので、ぜひ最後まで読んでみてください。

入社前

僕は、大学2年生の時、プログラミングの学習を開始し、最初はhtmlでウェブサイトのUIを作り始めるところからスタートしました。その後はJavaScript、TypeScript、 React、 Next.jsなどを学んでウェブアプリをいくつか趣味開発をして経験を積んでいました。

個人での開発を進めてきたおかげでプログラミングの力がついてきたなと感じた頃、個人レベルではなく実際に人に使ってもらえるようなサービスを開発したいという気持ちが高まり、pythonを勉強している友達を誘って4人のチームでの開発が始まりました。

僕が仲間を誘って集めたためリーダーのような役割を担っており、最初はみんなやる気十分で友達の家に集まってお互いの知識を出しながら技術選定、仕様などを議論して開発を進めていました。しかしながら2、3ヶ月ほど立って、僕たちのチームははあくまで会社ではなく友達同士のため当然遅刻、途中からさぼり出す、対面で会うはずがリモートになるなどのことが頻繁に起こり、メンバーのモチベーションを維持しながら開発していくのはとてつもなく難しいことに気付かされました。

次のレベルにステップアップしたいと感じていた時に、やはり実務の環境に身を置くしかないと考え、エンジニアのインターンを探していたところ株式会社Optixと出会いました。

僕が入社を決めた理由は以下の4つです。

  • 実務経験がなくても応募できた
  • CTOのMさんの技術レベルが凄かった
  • チームの平均年齢が20才と異常に若かった
  • 触れられる言語の多さ

特に、エンジニアのメンバーもまだ少なく、業務にも上流から関われるため、たくさんの言語やインフラと触れられ、ビジネスサイドのこともよく知れるなと思ったのが理由です。

面接では社長の黒田さんが緊張していた僕に最初から本題に入るのではなくて、軽い雑談から入り「カジュアルな感じで大丈夫ですからね」と言ってくれたため非常に話しやすかった印象が残っています。相手がどう対処するかを伺うような意地悪な質問もなくその人のことをちゃんと知ろうとするような多く、本音で喋ったことに対して意見を尊重する姿勢を見せてくれました。こんな人のもとで働きたいと思い、今に至ります。

入社して感じたこと

技術選定のレベル

2024年3月の半ばに入社し、実務で実際に使われている言語、ツール、選定される技術などを実際に知ることができたことに気分が上がりました。

未経験の状態だとなんとくなく流行っている技術を取り入れてそれぞれの技術がどういったアプリケーションを開発するのに向いているかなどを深く考えて選定してこなかったからこそ、実務で使うツールや技術のベストプラクティスを知れただけでも入社して良かったと感じました。

プロダクトも立ち上げ段階だったので、CTOのMさんが自社ウェブサービスのアプリ版を開発する時、例えばデータベースの技術選定をするとなった時にmySQLやpostgresqlなどの生sqlを書く必要がある言語を使うのか、それとも開発スピードが早く、認証機能などが備わっているが少しカスタマイズ性の低いnosqlを選定するのかなど、どの技術を採用するのかの選択を迫られていました。

そこでMさんはその場でビジネス側に様々なデータベースのメリットやデメリットを教え、自分の意見を述べた後に適切なコミュニケーションをとり、お互いの納得する意思決定を行なっていました。CTOのMさんのその場で技術の特徴を説明できる凄さ、そして実務における技術選定の重要さを知ることになりました。

また、何より驚いたのがCTOのMさんがビジネスサイドとエンジニアのどちらも参加するミーティングで社長の次に会社の方針などについて発言をしていたことでした。インターンに参加する前はエンジニアとは多少の不満はあれどビジネスサイドの要件をもとにコードを書いてアプリケーションを開発していくという雰囲気だと思っていたのですが、株式会社Optixではたとえその意見が間違っていたとしてもそれがより良いプロダクトを作るための意見ならもっと発言してほしいというスタンスでした。そのおかげで僕も頻繁に思ったことをぶつけ、少しでも違うと思ったことは議論することで不満を溜め込まないで仕事をすることができています。

最初のプロジェクト

入社して少しは慣れてきた頃、初めてのプロジェクトが回ってきました。

新規事業は、世界中のトレーディングカードの価格をAIによって集積し、比較できるようにするウェブプロダクトの開発でした。要件は、2週間で最低限の機能を持ったプロダクト(MVP)を完成させ、公開まで行うというものでした。

期限は自分の技術的に行けるか行けないかギリギリのライン、これが実務かと改めて感じたのを覚えています。

CTOのMさんからアドバイスもらいながら技術選定をして、フレームワークにはNext.js、データベースはVercel postgres、そのORMにPrisma、CSSフレームワークはTailwindcss、Shadcnとなりました。

この時Vercel postgresではなく使ったことのあるSupabaseを使いたかった気持ちがありましたが、seo的にデプロイ先とデータベースが同じという利点からVercel postgresの方が良いとのことだったので将来的に利点があるなら使ってみようと思い、選定したのを覚えています(結局デプロイ、ダッシュボードがかなり優秀だったのでVercelにしておいて正解でした)。

この時はフロントの経験はありましたがほとんどバックエンドを触ったことがない状態で、ましてやデータベースのer図という単語すら知らない状態で、CTOのサポートがあるとはいえ全て自分で作りあげなければならなかったため正直本当にできるのかなと思っていたのは印象に残っています。

DBの設計の難しさ

最初はTailwindやshadcnを用いてUIを構築する作業をしており、フロントが終わった後にPrismaやライブラリのインストール、データベースの紐付けなどを行なってバックエンドに着手しました。

そして次に待っていたのはデータベースを設計するためのER図の作成で、Mさんからいただいた資料を読んでみると一対多、多対多、中間テーブルなどそれらしいことが書かれているがデータベース設計初見だった僕は当時ほとんど理解できませんでした。とりあえずよく分かってないままPrismaのschemaを記事通りに書き、本当にこの書き方でリレーションできてるのかな?中間テーブルってなんでいるんだろう?と半信半疑のままの気持ちで書いていました。

GASの壁

この日からGoogle App Scriptという、google docu mentやスプレッドシートをjavascriptで操作できる拡張機能を用いてスプレッドシートに入っている情報をNext.jsのアプリケーションに送り、それをデータベースにPostするというタスクに着手していたのですが、gasが初めてなのもあって本当に苦戦したのを覚えています。

まずスプレッドシートのデータをNext.jsに送れること自体が初耳でした。リサーチして実行しても結果出ずGCPやNext Authなどの結局使わなかったものなどをひととおり試したが結果がでず、開発中で一番精神的に辛い時でした。

切り替えるために帰ってMさんと通話して質問したところ、後少しのところまでは辿り着いており、あとスプレッドシートの設定をひとつ変更すればデータをNext.jsに送れているという状態でした。実際に取得したデータをコンソールで確認した時の達成感は異常でした。

期限の最後の日、壁は消えたのであとは走り切るだけのラストスパートという感じでした。

フロントにデータベースから取得したデータを入れて整形して、などのまとめ作業をしていて間に合わせるために異常な集中でやっていました。完成し、形になったものをついにデプロイしようとした時、デプロイ時にエラーを吐かれ体力が尽きてしまい、帰宅しました。

次の日は疲れていたので休みをとり、夜にMさんが仕上げてデプロイしてくれました。

Mさんの助けもありましたが実際一人で大規模なアプリケーションを二週間で作り上げる経験をしたのは、今後一生自信になると確信しました。

入社してから最大の学びはチーム開発

とはいうものの、最初の数日は順調に進んでおり期限より早く完成するのでは?と考えていた時期もありました。しかし、数日もすると、すぐに私は未経験と実務の最大の違いであるエンジニアとビジネスサイドとのコミュニケーションについて苦労することになります。

まず、事業を開発するに当たってエンジニアが今何をしているのかをビジネスサイドに伝えなければそれぞれのやりたいことに齟齬が生まれ、結局両者の考えていたプロダクトになることはありません。

そういった経験がなかった私は自分の解釈だけで開発を進めコミュニケーションを疎かにした結果、最初は同じ軌道に乗っていたもののだんだん仕様にずれが発生し、機能が完成した後に修正する羽目になるという事態を何度か経験しました。

視座を上げる

しかしながらそういった失敗を身をもって経験することで私はこのプロダクト開発中におそらく未経験の頃の半年分ほど成長することができたと自負しています。社長の黒田さんに言われた「視座を上げる」という言葉はエンジニアのプロダクト開発における根幹のマインドだと私は考えています。

エンジニアというのは自分のプロダクトを完璧につくり、リリースしたいと考える生き物です。しかしながらビジネスサイドはそのプロダクトをマネタイズし、売り上げを上げることを目標としています。

同じ会社の同じグループにいる以上、売り上げを上げて利益を出すことがほとんどの企業の最終目標であるためエンジニアのエゴでデザインが崩れているからまだリリースしたくない、あの機能が実装できるまでは出したくないと思うこと事態が間違っていて、それは視座が低い状態だと言えます。

そうではなく、エンジニアがビジネスサイドと同じ目標を持ち、これを直すよりも先にリリースする方が確かに売り上げが出るからやった方がいいねと言える状態こそ視座が高い状態にあり、どんな状況でもそうあるべきだというのが新プロダクトを開発している時に感じた最大の学びでした。

未経験から実務になるということは思いがけないトラブルも発生します。しかしながらそれを飲み込んで学びにすることで、自らが成長し、プロダクト開発における楽しみを実感できるのではないかと私は心から感じました。

最後に

Optixでは随時インターンの方を募集しています〜!こちらからいつでもご応募ください!


Optixでは一緒に働く仲間を募集しています
2 いいね!
2 いいね!
同じタグの記事
今週のランキング