第1章: 新たな挑戦の始まり

私は23歳、プログラミングの世界に飛び込んで三年目になるエンジニアでした。何社かのSESを経験し、C#を使った実装や設計、RESTful APIの設計、マイクロサービスの開発など、一通りの技術は身につけていました。

しかし、その時の私は、自分自身で何か大きなことに挑戦したいという強い思いを持ちながらも、具体的に何を始めればいいのか見当もついていませんでした。

キャリアの方向性に頭を悩ませていたある日、友人から思いがけないオファーを受けました。「ECの新規開発案件があるんだけど、副業で手伝ってみないか？」2022年の2月、その提案は私にとって新鮮で刺激的なものでした。

本業は一段落していたこともあり、これまでの経験を活かし、さらに新しいステップに進む絶好のチャンスと感じました。個人事業主としての第一歩を踏み出し、税理士の紹介を受けるなど、開発に集中できる体制を整えました。

案件は、ECモールの自社開発。まだ何も決まっていない真っ白な状態から始めるプロジェクトでした。

私は、この自由な環境にテンションが上がっていました。既に頭の中では、最先端の技術を駆使し、私が理想とする開発環境を構築する計画を練っていました。

今思えば、この時は、ただ経験積んでいければいいと考えていました。
その後、多くの苦難と出会いが待っているとは考えもしませんでした。

第2章: 技術選定とチームビルディング

2022年の4月、私にとって新しい挑戦が始まりました。10人以下の小規模なチームでのプロジェクトで、私はバックエンドエンジニアとしてこの船出に加わりました。本業の合間を縫って、私を含むプロジェクトマネージャーと共に、インフラ、バックエンド、そしてフロントエンドの技術選定を行いました。

フロントエンドでは、効率的で手間が少ないアプローチを取り、Gatsby.jsを採用し、AWS S3にビルドされたファイルを配置しました。バックエンドは、Golangを使用してAPIを構築。Dockerコンテナを駆使し、Github Actionsでのマルチステージングビルドを実現し、AWS ECSへのデプロイを計画しました。インフラに関しては、AWSを中心に据え、ログ監視にはCloudWatchを使用。提供するコンテンツはCloudFrontを用いてCDNを介し、ローディングの高速化を図りました。そして、インフラの構築にはTerraformを用い、Infrastructure as Codeの実現を目指しました。

当時の私は、各技術に個別の経験は持ち合わせていましたが、未経験の領域も多く、その学びは簡単ではありませんでした。ChatGPTのような便利なツールもなく、解決策を求めて公式ドキュメントに食らいつく日々。バックエンドでは、クリーンアーキテクチャの適用に頭を悩ませました。エンティティの粒度、結合度、そしてクリーンアーキテクチャの理念をどこまで追求すべきか？これらの問いに、社内のエンジニアと何度も議論を重ねました。新しいことに取り組む楽しさと共に、様々な技術的な課題に立ち向かうことは、私にとってかけがえのない経験でした。

AWSの基盤からの構築も初めての経験。インフラエンジニアと協力しながらインフラ構成図を作成したり、AWSのロール設計に取り組んだり。インフラにこれほど深く関わることが初めてで、新しい知識と技術の海に飛び込むことに大きな喜びを感じていました。初めの頃は、すべてが順調に進んでいるように思えました。システムの設計やコーディングに没頭し、毎日が充実していました。しかし、この順風満帆な日々も長くは続かず、次の章で詳述するように、予期せぬ壁に直面することになります。

第3章: 言語の壁と文化の違い

2022年6月、私たちのプロジェクトは新たな段階に入っていましたが、同時に様々な困難も顕在化していました。プロジェクトの初期には、CTO役の経験豊かなエンジニアから貴重なアドバイスを受けていたのですが、彼の多忙さからそのサポートは次第に減少し、私たちは新しい技術の導入に頭を悩ませることになりました。

さらに大きな問題は、エンジニアの教育と採用でした。予算の制約から、経験豊富なエンジニアを十分に採用することができず、経験の浅いエンジニアたちの教育とサポートに追われる日々が続きました。私自身も本業を抱えながら、このプロジェクトの成果を出すためには時間との戦いでした。労力を惜しまずに尽力したものの、パフォーマンスの維持は非常に困難でした。

プロジェクトにさらに複雑さを加えたのは、外国人エンジニアの採用です。上層部の意向で、コスト削減と能力の高いエンジニアを求めて、日本語を話せるとされていた外国人エンジニアを数名採用しました。しかし、実際には彼らの日本語能力は期待ほどではなく、英語と中国語が主なコミュニケーション手段となりました。これが私にとってはまさに悪夢のような状況でした。DeepL翻訳を駆使しながらも、文化の違いや時差による課題、仕様の説明の困難さに直面し、英語での適切な表現を見つけるために苦労しました。

今振り返ると、この経験から得た教訓は大きいです。日本人エンジニアと比較してコスト削減のメリットと、日本語が通じない場合のブリッジエンジニアの必要性、そしてプロジェクトルールの徹底がいかに重要かを学びました。この状況は私にとってあまりにも無茶な要望であり、結局は上層部にこれ以上の無理はできないと伝えました。そして、今後はもっと計画的に、体制を整えてプロジェクトに臨むべきだと社長に強く提案しました。

フロントエンドエンジニアの不足も深刻な問題でした。私自身がフロントエンドに関わることもありましたが、バックエンドのタスクが山積みで、フロントエンドの開発は大幅に遅れが生じていました。そして、これだけでは困難は終わらず、エンジニアやマネージャーの離脱が続き、プロジェクトはさらなる危機に瀕しました。

次の章では、プロジェクトがどのようにして混乱し、私がどのような行動をとったのか、詳細にお話しします。これからもっと厳しい試練が待ち受けていたこと、そして私がどう対処したのか、次章で明らかにします。

第4章: 危機の到来と再出発

2022年の9月、私たちのプロジェクトは突如として危機の渦中に巻き込まれました。その時点での主な危機は三つありました。一つ目は、プロジェクトマネージャー(PM)の予期せぬ離脱によるディレクションの崩壊。二つ目は、その結果としてエンジニアのコントロール喪失に伴う離脱。そして三つ目は、リリース日が決定され、刻一刻と迫るデッドラインの圧力でした

PMの突然の離脱は、プロジェクトにとって大きな打撃でした。彼はバックエンドとインフラのタスクを一元的に管理しており、その突然の退場により、私を含む残ったメンバーは完全に立ち尽くしてしまいました。当時、私は開発業務に専念していたため、ディレクションは把握していたものの、20人近くいるチームの全体管理は困難でした。

この状況で、大量の未解決タスクが発生しました。数えきれないほどのタスクが散らばり、何が終わっていて何が終わっていないのかさえ分からない状態でした。全てのタスクを整理する作業は、フロントエンドディレクターと共に夜遅くまで一月以上続けました。しかし、その時点でバックエンドのエンジニアは私を除いて全員がプロジェクトを離れていました。

さらに困難を増したのが、言葉の壁によるコミュニケーション問題でした。前述の通り、外国人エンジニアの採用により、言語の障壁が生じ、プロジェクトの進行はさらに遅れました。この時点で、プロジェクトは文字通り破綻寸前でした。しかし、それでも来年の4月（2023年4月）のリリース予定は変わらず、私たちは事実上、絶望的な状況に置かれていました。

その後、11月に新しいPMがアサインされ、ディレクションと要件定義の整理に取り組んでくれました。さらに12月には新しいディレクターがバックエンドに加わり、1月にはプロジェクトに馴染んでくれました。この方々の加入は文字通り救世主でした。技術力があっても、スケジュール通りに物事が進まなければ意味がないということを痛感しました。私一人の努力だけでは不十分だったのです。

2024年1月現在でも、その時のPMとディレクターとは交流があり、私は彼らに深い感謝の念を持っています。彼らがいなければ、プロジェクトは決して成功しなかったでしょう。彼らの存在は、私にとって、そしてプロジェクトにとって、まさに光明でした。

最終章:最後の奮闘と奇跡のリリース

リリースに向けた最後の戦いは、私たちにとって最も過酷な試練となりました。2022年1月、PMとディレクターたちがプロジェクトに慣れ、要件定義の見直しに取り組むことになりました。その時点で私は、自身の覚悟を決め、前職を辞めてこのプロジェクトに本格的にフルタイムで取り組むことを選びました。1月と2月には全力を注ぎ、要件定義を完了させることができましたが、このプロセスも容易なものではありませんでした。

実際、法律的な側面を考慮せずに設計されていたことが明らかになり、店舗の審査に必要な書類などが不足していることが判明しました。これは、法的なアドバイザーをもっと早くに雇うべきだったという教訓と、ビジネス上の意思決定者に対するヒアリングの不足が原因でした。この時点で、私はPMたちと共に、遺漏なく実装できるよう要件を再定義しました。

しかし、時は既に遅く、リリースまで残された時間はわずか二ヶ月でした。私は、新たに優秀なバックエンドエンジニアを採用することに注力しました。私自身とバックエンドディレクターが厳密な判断のもとで選んだエンジニアたちは、このプロジェクトの救世主となりました。彼らがいなければ、完成は不可能だったでしょう。

3月に入り、バックエンドの開発はほぼ完了に近づいていました。しかし、新たな危機が降りかかりました。フロントエンドの購買者用サービスがほとんど完成していないことが発覚したのです。これは、フロントエンドディレクターや私を含む上層部の責任であり、開発環境や検証環境でのチェックが不十分だったことが原因でした。私はこの過ちを深く反省し、今でもそのことについて思いを馳せます。

その後、私はバックエンドのタスクを一人でこなし、フロントエンドの開発にもバックエンドエンジニアをアサインしました。これは容易な作業ではなく、バックエンドのタスクを私一人で進めることは、想像を絶する努力を要しました。しかし、他に選択肢はありませんでした。私たちは全力で突っ走り、インフラのビルドや本番環境の構築に苦戦しながらも、最終的にリリースのデッドラインをクリアしました。

リリース後、私はプロジェクトに携わった全員に感謝の気持ちでいっぱいです。不可能と思われた課題を乗り越え、サービスを世に送り出したのですから。この一年は、短いようでありながらも長く、濃密な時間でした。学んだことは数えきれないほどありますが、特にチームワークの重要性、ベンチャー企業での多様なスキルセットの必要性、適切な人員配置の重要性、そしてオフショア開発のリスクを痛感しました。

もしサービスがリリースできていなかったら、私は今ここにいないでしょう。しかし、幸いにも私たちはそれを成し遂げ、今後のサービス発展に向けて新たな道を歩む準備ができています。次は、リリース後のサービスの成長と展開についてお話ししようと思います。次回をお楽しみに！