上京エンジニア、2024年のプロダクト開発を振り返る

おはようございます!そうすけです!

運営者:そうすけ


愛媛出身の30代のブロガー兼ソフトウェアエンジニア
フロントエンド・API開発を行っています。

ITエンジニアとしての暮らしやキャリアなどの発信をしています。


趣味はガジェットと植物

あと2日で2025年ですね。

エンジニアとしてこの1年間のプロジェクトを振り返り、得られた知見や課題を共有することで、私自身の学びを整理するとともに、同じ道を目指す方々への参考になればと思います。

目次

結論:エンジニアとしての基礎力がついた

1年間を通じて、色々な立場でエンジニアリングしていたので、総合力がつきました

技術だけでなくプロジェクト管理やビジネス的な視点を養うことにも挑戦しました。

それにより、技術者としての幅を広げ、視野を広げる大きなステップとなりました。

そうすけってどんなやつ?

わたしの概要
  • 地方メーカーの食品開発・品質関連の業務に約5年
  • 情シスに異動して約2年。主にDB・バックエンド。
  • 2024年に都内SaaS系のWEBエンジニアに転職。フロント・API開発。
経験言語
  • Vue(Nuxt)
  • React(Next)
  • Typescript
  • Java
  • Ruby(Rails)
  • PHP(Yii)
  • MySQL

現在はSaaS企業でECデータ分析ツールを開発しており、主にVueやReactを使ったフロントエンド開発に携わっています。

趣味はボールパイソンというヘビの飼育です!


今年のプロジェクト概要

今年関わった主なプロジェクトは以下の4つです。

今年のプロダクト開発
  1. 工場内トラブル管理システム
  2. 人事系アプリ
  3. 植物ショップ評価アプリ
  4. EC分析ツールの多言語対応

これらを通じて経験したことや課題について、詳しくお話しします。

  • よかったこと
  • 課題
  • 学んだこと

それぞれのプロジェクトが私に与えた成長のきっかけや、得られた学びについて具体的に掘り下げていきます。

工場内トラブル管理システムの開発

工場内トラブル管理システムは、工場で発生する問題や改善点を記録し管理するためのツールです。

メーカーにはものを作るための工場が存在します。

その工場で作られる商品が一定の品質を満たしているかというISOという規格があり、外部監査によって審査され、認定されます。

企業の信頼性を作るため、どのようなメーカーでもこれを目標とすることが多いです。

このプロジェクトでは、初期段階の要件定義から運用までを主導しました。

要点
  • 良かったこと
    • 要件定義に注力し、ユーザーに対してなぜなぜ分析をしてニーズを洗い出せた。
    • 0からテーブル設計を考えて構築し、DB設計を考える力がついた。
    • リリース後アンケートと改修をすることで、より満足度の高いシステムを提供できた。
  • 課題
    • 20年前のフレームワークなので、ドキュメントがほぼない。
    • ローコードツールでコードを書いていたため、実装が複雑に
    • テストケースが不足していたため、運用後のトラブルシューティングに手間
  • 学んだこと
    • 設計力は技術スタックに依存せず、どのプロジェクトにおいても重要であると再認識。
    • ユーザーとの対話を通じて、現場のニーズを深く理解することが設計の質を向上させると実感。

小さいプロジェクトで初めてのリーダー経験でしたが、要件定義から設計・開発・運用保守までほぼほぼ1人でやりきりました。

そうすけ

私自身が工場経験者なので業務フローを知っていたので、開発しやすかったです。

フレームワークは20年前のローコードツールでしたので自由度は低い開発でした。ドキュメントもほぼなくて開発体験としていいものではありませんでした。

ですが、どうにもならない部分はいっそ諦めて、要件定義とテーブル設計に注力しPDCA回すと、特に問題なくリリースできました。

このことから業務フローとテーブル設計をしっかり整理することのほうがシステム開発において本質的で、フレームワークの古い・新しいは手段の一つであるということを実体験を持って学びました。

そして自分がゼロイチで作ったツールを社内の人に使ってもらって、喜びの声をもらえたときはやっぱり嬉しかったです。


人事系アプリの開発

社員4000人の自己成長を記録を管理するためのアプリケーション開発に携わりました。

ざっくりいうと目標設定アプリのようなものです。
自分の目標を書いて、それを記録して振り返るというシンプルなものです。

このプロジェクトでは、ベンダーに依頼する側のプロジェクトマネージャー(PM)としての役割を果たしました。
(実際にはPMOだけど、ほぼほぼPMをやってた)

要点
  • 良かったこと
    • PMとして要件定義からスケジュール管理までの上流工程の重要性を学んだ。
    • 上層部との社内調整をバカにせずこまめに行い、コミュニケーション能力が向上。
    • 優れたベンダーの人と出会い、要件定義の方法を学べた。
  • 課題
    • 経営層のビジョンや意図を正確に汲み取ることが難しく、要件定義に難あり。
    • 技術的な実装の機会が少なかったため、エンジニアリングのスキルアップに繋がらなかった。
    • 依頼部署が協力的ではなかった。
  • 学んだこと
    • プロジェクト成功には、技術力だけでなく、ビジネス的な視点やコミュニケーション力が不可欠であると理解しました。
    • 利害関係者との積極的な対話を行うことで、プロジェクトの方向性を調整する能力が向上しました。

特に強く感じたのは、ものづくりのアプローチがメーカーとソフトウェアで大きく異なるということです。

システム開発とメーカーのものづくりはかなり異なります。

システムはその柔軟性を活かして小さく世にだして改善をしていく方法をとるのですが、メーカーのものづくりは完成度が高いのものを作って世に出す手法を取ります。

例えば、ソフトウェア開発は「新しいドリンクメニュー」を試験的に提供し、改良を重ねるようなもの。

一方、メーカーのものづくりは「家を建てる」ように、最初から高い完成度を目指します。

故に、開発費を払う側の社長の期待値が高く、なかなかリリースができないのです。

また外部委託の場合、開発は関係者が多く要件定義が複雑になります。

社内の構図でいうと、こんな感じです。

社長 ⇔ 依頼部署(人事) ⇔ 社内SE ⇔ ベンダー

なので認識の齟齬が起きやすいです。

絶対に成功しない伝言ゲーム

機能を作る前の、「誰がどうするためになぜほしいのか?」という大事な部分が、全員異なる状態でした。

そんな状態で、いざ開発したアプリを作って社長や依頼部署に見せると、どんでん返しで再開発が何度も発生しました。

社内SEとして想像しながら開発してもいいものは作れず、そして社長の期待値は高くなるばかりでリリースできない。

現状を変えれなかった私の力不足なのですが、この構造を自分の影響の輪を超えてしまっているとも感じました。

このくらいから、大きいメーカー組織よりも、小さいSaaS企業ででプロダクトを作るほうが、いいものづくりができるのではないかと考え、転職を意識し始めました。

植物ショップ評価アプリ

個人開発として、植物ショップのレビューや情報を共有するためのアプリケーションを作成しました。

要点
  • 良かったこと
    • フロントエンド、バックエンド、インフラを一人で担当することで、フルスタックエンジニアとしての視点を広げることができた。
    • 運営しているブログのユーザーのニーズからサービスを作れた。
  • 課題
    • こだわりをいれすぎて制作時間をかけすぎた。
    • ユーザー投稿型のプロダクトは初期データがしょぼくなってしまう。
    • AWSのリソース選定がオーバースペックで、予想以上の費用(月額1万円以上)が発生してしまった。
  • 学んだこと
    • 個人開発においても、技術面だけでなくコスト管理や運用面への意識が重要である。
    • 全体を経験したので転職先でやれることが増え、個人開発は本業につながると実感

転職用に作成したのですが、クラウド環境の構築は初めてで、大変貴重なになりました。

ですが一番つらかったのもAWSの費用です。RDSやECSが特に高く、既存の設定で月1万くらいのランニングコストはかなり痛かったです。

ユーザー数もかなりの少数だったので、サービスを閉じることになりました。

しかしNoPain、NoGain。
身銭を切って開発すると、よりリソース選定の重要性のインパクトを感じました。

個人開発するときはいかにランニングコストを小さくするかが大事になると、強く感じました。


EC分析ツール 多言語対応

新たに転職した会社のメインプロダクトで、多言語(i18n対応)を実装するプロジェクトに参画しました。

この対応により、ユーザーが言語を簡単に切り替えられるようになりました。

要点
  • 良かったこと
    • Vue 3のコンポーネント設計や状態管理の活用方法を深く学ぶことができた。
    • リロードなしで言語を切り替えるというUX向上を実現でき、フロントエンドの可能性を広げた。
  • 課題
    • Vue2やJQueryから無理やりVue3に移行した感があり、コードがカオスになってた。
  • 学んだこと
    • 型安全性やコード品質を意識した開発が、結果的に効率や成果物の品質向上につながると学んだ。
    • 規模が大きくなると、どの現場でもソースが複雑で読み解くなる

入ってみて思ったことは、プロダクトの規模が大きくなればなるほど複雑になる、ということです。

社内SE時代、システム内のわけがわからないコードは、システム設計の技術がないからだ!とそう思ってました。

しかしいざ外に出てみると、そうでもなさそうと思いました。

IT企業のプロジェクトでも、大規模になるほど追加開発や仕様変更の積み重ねでコードが複雑化するのは一般的であり、理想的な状況ばかりではないことを実感しました。

その道10年以上の同僚の方も、カオスじゃないプロダクトに出会ったことがないとのこと。

社内システムだろうが、有名なソフトウェアだろうが、システム設計とリファクタリングは非緊急かつ重要な課題であることを再認識しました。


まとめと展望

今年は、設計力やプロジェクト管理の経験を通じて、より広い視点で物事を捉える力が養われたと感じています。

しかし、技術的にもポジション的にも、何かを深く掘り下げる時間が不足していたことも課題として残りました。

来年は以下の目標を掲げています。

  1. コストが掛からない個人開発: コストがかからない方法を考えてます。バッチ処理は24時間稼働の中古パソコン内で行うとか。
  2. 技術力の向上: フルスタックにやりつつも、業務で実装が多いフロントエンドを深めることで、より包括的なスキルを磨きます。
  3. AI使った開発:トレンドのLLMの開発プロダクトに関わりたい。

これらを通じて、自分で選んだ道を正解にしていくためのアクションを積み重ねていきたいです🔥

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

目次