はじめに
今年の4月に新卒でログラスにエンジニアとして入社したカワサキです。
ログラスに入社して3ヶ月目から共通基盤プロジェクトの立ち上げの開発に携わり、エンジニアとしてアプリケーション部分の開発全般を行いました。入社してすぐにコードをたくさん書くことが出来るプロダクト開発に携わる機会をいただき、その中で学んだことをまとめました。
取り組んだこと
この記事では具体的な技術スタックの細かい説明には踏み込みませんが、前提となるプロジェクトの背景と、自分が担当した範囲について簡単に紹介します。
背景：マルチプロダクト戦略と共通基盤の必要性
ログラスはマルチプロダクト戦略を掲げており、その実現に向けて共通基盤の構築を進めています。
既存事業ではユーザーおよびテナント発行の仕組みがありました。一方で、新規事業側のいくつかのプロダクトでは、いまだに手動オペレーションに頼っている部分も多く、次のような課題がありました。
- 特定のメンバーに依存した、運用負荷の高いオペレーションが残っている
- 新規事業を増やしていくうえで、開発コスト・運用コストが徐々に積み上がっていく
- プロダクトごとに管理方法がバラバラで、社内オペレーションの統一がしづらい
こういった課題を解消し、複数プロダクトを統合的に運用できるようにするために、「社内向けの共通アドミン画面（共通基盤）」を新規で立ち上げることになりました。
プロジェクトの概要
共通基盤として社内向けの管理画面アプリケーションを新規で立ち上げるプロジェクトでした。
インフラや認証まわりは先に整備されており、私は主にアプリケーション部分の開発全般を担当しました。具体的には、既存プロダクトの仕様をキャッチアップしたうえで管理画面向けに機能を再設計し、統合管理画面を0から作成しました。
管理画面という性質上、基本はCRUDが中心ではあるものの、既存プロダクトの仕様を理解したうえでの再設計が必要であり、メインプロダクトの管理画面については0からの作り直しでした。さらに、一部これまで触れたことのない技術スタックも含まれており、約2ヶ月というスケジュールで開発しきるのは、自分にとって決して簡単な内容ではありませんでした。
学んだこと
アウトプットではなくアウトカムを意識する
開発当初は、細かく分割してもらったタスクを、仕様どおりに実装して進めていました。「その日に自分がやったこと＝出したPR」のような焦りから、PRを出して、レビューを受けて、修正して、マージすること そのものが目的になってしまっていました。
- 自分は何を理解し、次にどうつなげられたのか？
- ただ仕様どおりに作るだけでなく、「今の実装より良いやり方」はないのか？
- 自分が作っているものは、どんな人にどう使われて、どんな価値につながるのか？
- それは会社のビジネスや、これからやろうとしていることにどうインパクトを与えるのか？
こういったことを考えて初めて、「この実装順で本当にいいのか」「この機能は今実装するべきか」 といった、意味のある判断ができるようになっていくと感じました。
テックリードと話すたびに、「目の前のタスクを終わらせること」だけに意識が向いていて、その先のアウトカムまで考えられていなかったことを痛感しました。実際には、仕様どおりに機能を実装することに集中してしまい、「この共通基盤を使うプロダクトが増えたときにどう拡張しやすくしておくか」といった視点や、「この画面を誰が・どんな場面で使うのか」といったユーザー視点をほとんど持てていませんでした。
本来であれば、将来の拡張性や運用メンバーの利用シーンも踏まえて、「この設計でいいのか？」「ここは共通化したほうがいいのか？」といったところまで含めて提案できたはずです。そうした長期的な目線とユーザー目線を持てていなかった分だけ、自分の影響範囲を自分で狭めてしまっていたと感じています。
同じ技術力を持っていても、どれだけアウトカム（結果・価値）を意識できるかによって、エンジニアとして 創れるものの価値 は大きく変わると感じました。AI の精度が上がり、基本的な実装にかかるコストが下がっていく中で、当初自分がイメージしていた以上に、「技術そのもの」以外の部分プロダクトが生む価値を想像する力や、事業への目線が求められていると強く感じました。
技術力以外に大事なこと
自分自身は今回の実装で目の前の機能を開発することにしか目を向けられていませんでしたが、テックリードは機能開発だけでなく
- 他のプロダクトはどんなドメインでどのような課題があるのか
- 今後共通基盤はどのような方針で進めようと思っているのか
- リリース後の運用や改善のことまで想像できているか
といったところまで含めて日々意思決定を行っていました。そうすることで、「今やるべき重要なこと」や「今後どのようなことが課題になりそうか」を考えながら、プロジェクトを前に進めていました。こうした視点をどこまで自分ごととして持てるかで、たとえ技術力が同じでも、エンジニアとして出せるアウトカムは大きく変わると感じました。
AI時代だからこそ技術が大事
この開発を始めたタイミングでちょうどClaude Codeがリリースされ、今回のプロジェクトではそれをかなり積極的に活用しました。実装量がとにかく多いプロジェクトだったので、短期間でやり切るにはAIの力がほぼ必須だったと思います。実際、AIを使うことで自分のアウトプットは大きくブーストされましたが、その分だけ 土台となる技術力の差もはっきり出る と感じました。
特に重要だと感じたのが、基本的な設計の理解です。今回のプロジェクトのバックエンドではオニオンアーキテクチャを採用していました。レイヤーごとの責務や依存方向についてはある程度理解できていたため、「何を、どの順番で作るか」を自分で組み立てることができました。実際、AIが出してくるコードは一見それっぽくても、責務が混ざっていたり、適切な層に実装されていなかったりすることがあり、そのたびに「どこをどう修正すべきか」を判断する必要がありました。
0→1で実装を進めていく中でコードベースが育ってくると、同じようなプロンプトでもAIが既存の実装をうまく参照してくれるようになり、出力の質はどんどん上がっていきました。「0→1はAIが強い」とよく言われますが、しっかりしたプロダクトを作るうえでは、最初に設計の土台をきちんと固めておくことが後から効いてくる と感じています。最低限のプロジェクト構成や設計方針が決まったあとは、基本的な仕様とI/Oを渡してAIに実装してもらい、自分はレビューと微修正に集中することで、スピードをかなり上げることができました。ただ、ある程度の規模のプロダクトを開発する場面や、ドメイン理解が重要な部分の実装は、まだまだAIだけに任せるのは難しいと思っています。
また、言語やライブラリごとの細かい仕様については、AIに質問しながら「根本的に何をしているのか」さえ押さえればよくなり、すべてを暗記しておく必要性は以前より下がったと感じています。その一方で、AI が出力したコードを読み解き、良し悪しを判断できる「内部品質を扱う力」 が、改めて重要だと感じました。
手を挙げる、行動することで大きく変わる
新卒として日々いちばん意識していたのは 「まず手を挙げてやってみる」 という姿勢でした。今回の開発も、少しチャレンジングな内容だと思いましたが、良い挑戦の機会 と思って手を挙げました。
背伸びしたボールを自分から取りにいく
日々のコミュニケーションの中で、「現状の自分より少し上のレベルのボールを投げてほしい」と伝えていました。少し背伸びをして、自分の限界を少し超えたレベルの仕事に挑戦することで、成長のスピードは確実に上がります。実際、そうやって意思表示をしていたおかげで、当初想定していたよりも多くのことを任せてもらえるようになり、想像していた以上のことを経験できました。
正解より、前に進めることが大事
開発を進める中で強く感じたのは、「正解」はあまり存在しないということです。技術選定ひとつとっても正解はなく、必ずトレードオフがあります。期限もある中で、「今の前提で何を優先するか」を決めて取捨選択する場面が何度もありました。そして正解探しで止まるより、動きながら学ぶことが成長につながると思います。
振り返ってみると、ストレッチな目標に対してトライし、量をこなしてフィードバックをもらうというサイクルを高速で回せたことが、大きな成長につながったと感じています。
これから
学びもできたことも多くあった一方で、自分自身はまだまだ技術的に足りないことも多く、できなかったこともたくさんありました。それでも、新卒入社3ヶ月目で得たこの学びは、これからの成長の土台になると感じています。今回自分が取り組んだ実装部分は特段難しいことはしていませんが、それでもログラスが今後大きくなっていく中で、社内の多くの人が日常的に使うことになるであろう重要な機能を任せてもらえたのは、大きな経験になりました。
このプロジェクトを通して、技術力はもちろん、ドメイン理解やプロジェクトを前に進める力など、まだまだ足りない部分をたくさん実感しました。だからこそ、「スタートアップに来た意味は何か？」「この環境でどんな成果を残したいのか？」をこれからも自分に問いかけながら、できないことを一つずつできるようにしていきたいと思います。がんばります！！！
Discussion