0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

2024年のプロダクト開発をふりえかる ~失敗と教訓~

Last updated at Posted at 2024-12-30

あと1日で2025年ですね。

エンジニアとしてこの1年間のプロジェクトを振り返ります。

今年地方メーカーの社内SEから都内SaaSのWEBエンジニアに転職し、開発者として4つのプロダクト開発に関わってきました。

得られた知見や課題を共有することで、私自身の学びを整理するとともに、同じ道を目指す方々への参考になればと思います。


目次

  1. 結論:エンジニアとしての基礎力がついた
  2. そうすけってどんなやつ?
  3. 今年のプロジェクト概要
  4. まとめと展望

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

1年間を通じて、PMやリーダー、フロントエンド・バックエンドなど立場でエンジニアリングに取り組んだ結果、総合力がついたと感じています。

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

それにより、技術者としての幅を広げ、視野を広げる年になったと振り返って感じます。


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

私の概要

  • 前職: 地方メーカーで食品開発・品質関連の業務に約5年、その後情シスで約2年(主にDB・バックエンド)。
  • 現職: 2024年に都内SaaS系のWebエンジニアに転職。フロント・API開発に携わる。

使用経験のある技術

  • フロントエンド: Vue(Nuxt)、React(Next)、TypeScript
  • バックエンド: Java、Ruby(Rails)、PHP(Yii)
  • データベース: MySQL

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

趣味

  • ボールパイソンという蛇の飼育。日々癒されています。

今年のプロジェクト概要

関わった主なプロジェクト

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

以下、それぞれのプロジェクトで得られた知見や課題を掘り下げていきます。


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

プロジェクト概要

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

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

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

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

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

image.png

要点

  • 良かったこと:

    • 要件定義に注力し、ユーザーに対して「なぜなぜ分析」を実施。ニーズを明確化。
    • 0からテーブル設計を考え、DB設計のスキルを向上。
    • リリース後のアンケートと改修を行い、ユーザー満足度の高いシステムを提供。
  • 課題:

    • 20年前のフレームワークでドキュメントがほぼ皆無。
    • ローコードツールによる実装の複雑化。
    • テストケースが不足しており、トラブル対応に手間。
  • 教訓:

    • 設計力は技術スタックに依存せず、重要なスキルである。
    • ユーザーとの対話を通じて現場のニーズを深く理解することで、設計の質が向上する。

振り返り

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

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

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

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

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

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


人事系アプリの開発

プロジェクト概要

社員4,000人の自己成長記録を管理するアプリの開発を担当しました。主にプロジェクトマネージャー(PM)として要件定義やスケジュール管理を実施。

要点

  • 良かったこと:

    • PMとして、要件定義からスケジュール管理までの上流工程を経験。
    • 上層部との調整を通じて、コミュニケーション能力が向上。
    • 優れたベンダーと出会い、要件定義の方法を学べた。
  • 課題:

    • 経営層のビジョンを汲み取るのに苦労。
    • 技術的な実装の機会が少なく、スキルアップに繋がらなかった。
  • 教訓:

    • メーカーとソフトウェアの開発のものづくりの違いを実感。
    • プロジェクト成功には、ビジネス的な視点やコミュニケーション力が不可欠。

振り返り

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

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

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

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

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

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

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

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

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

image.png

なので認識の齟齬が起きやすい構造になっています。
絶対に成功しない伝言ゲームのようなものです。

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

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

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

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

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


植物ショップ評価アプリ

プロジェクト概要

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

image.png

ポートフォリオアプリ紹介

要点

  • 良かったこと:

    • フロント、バックエンド、インフラをすべて担当し、フルスタック視点を獲得。
    • ユーザーニーズからサービスを作る体験ができた。
  • 課題:

    • こだわりすぎて制作時間が長引いた。
    • 初期データが少なく、ユーザー投稿型のプロダクトの難しさを実感。
  • 教訓:

    • 個人開発においても、コスト管理や運用の意識が重要。
    • クラウド環境の構築を学べたが、AWSのコストが高く、リソース選定の重要性を痛感。

振り返り

転職用に作成したのですが、クラウド環境の構築を0から組み立てるのは初めてで、大変貴重な学びになりました。

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

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

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

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


EC分析ツール 多言語対応

プロジェクト概要

新たに転職した会社のメインプロダクトで、多言語対応を実装しました。これにより、ユーザーが言語を簡単に切り替えられるようになり、UXが大幅に向上しました。

要点

  • 良かったこと:

    • Vue 3のコンポーネント設計や状態管理を深く学べた。
    • リロードなしで言語切り替えを実現し、製品の競争力を向上。
  • 課題:

    • Vue 2やJQueryから無理やり移行した結果、コードが複雑化。
    • 型安全性が低く、開発中にバグが頻発。
  • 教訓:

    • 大規模プロジェクトではコードが複雑になるのは避けられない。
    • 型安全性やコード品質の重要性を再認識。

振り返り

初転職だったわけですが、別会社のプロダクトの中身を見て思ったことは、やっぱりプロダクトの規模が大きくなればなるほど複雑になる、ということです。

image.png

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

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

IT企業のプロジェクトでも、大規模になるほど追加開発や仕様変更の積み重ねでコードが複雑化するのは一般的であり、むしろ設計やリファクタリングの重要性をより実感しました。

(バージョン管理されていて、メンバーの技術力もあるため、管理レベルは前職と比べて圧倒的にいいです)

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

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


まとめと展望

まとめ

2024年は以下のプロジェクトに取り組みました:

  • 工場内トラブル管理システムの開発
  • 人事系アプリの開発
  • 植物ショップ評価アプリ
  • EC分析ツールの多言語対応

この1年を通じて、設計力やプロジェクト管理の経験を積み、視野が広がったと感じています。

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

展望

来年は以下を目標に取り組みます:

  1. コストが掛からない個人開発: ランニングコストを抑えたプロジェクトに挑戦。
  2. 技術力の向上: フロントエンドを深めつつフルスタックを目指す。
  3. AI開発: LLM(大規模言語モデル)を活用したプロダクトに関わる。

2025年も、自分で選んだ道を正解にするためのアクションを積み重ねていきます🔥

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?