はじめに
工数管理 SaaS 「クラウドログ」で開発エンジニアをしている馬渕です。
クラウドログにバックエンドエンジニアとしてジョインして、早いもので3年が経とうとしています。振り返ってみると、技術スタックの変化だけでなく、言語の壁や役割の変化など、非常に密度の濃い3年間でした。
この記事では、一人のエンジニアがSaaS開発の現場でどのような壁にぶつかり、それらを解決するためにどのようなことを行ったのか、1年ごとのリアルな軌跡をまとめたいと思います。
【1年目】「言葉」と「コード」の二重苦から始まったスタート
入社して最初に直面したのは、想像以上の「高さ」がある2つの壁でした。
1. アーキテクチャの理解という技術の壁
前職ではシンプルなフラットパッケージ構成のプロジェクトに携わっていました。規模が小さいうちは見通しが良いのですが、徐々に「どこに何が書いてあるか分からない」という課題を抱えがちな構成です。
それに対して、クラウドログのコードベースはクリーンアーキテクチャをベースとしたオニオンアーキテクチャ。責務ごとに厳格にレイヤーが分離されているため、そもそもこれらの設計思想への深い理解がないと、一つの機能を追うだけでも迷子になってしまいます。「なぜこの処理がここにあるのか」という意図が掴めず、コードを把握するのに非常に時間がかかり、自分の実力不足を痛感する日々でした。
2. 英語というコミュニケーションの壁
さらに追い打ちをかけたのが、フィリピンメンバーとの英語でのコミュニケーションです。
特に毎朝のDSU（Daily Stand-up）が鬼門でした。ネイティブに近いスピードで飛び交う進捗報告が聞き取れず、置いてけぼりになる感覚。また、開発方針の打ち合わせなど、複雑なロジックを口頭で議論しようとしても、頭にある思考が英語として口から出てきません。
先輩エンジニアが言語のフォローをしてくれたため、仕事として滞ることは一切なかったのですが、自分で解決できない、ということが何よりもきつい経験でした。
どう乗り越えたか：徹底した「型」の学習とルーティン化
このままでは戦力になれないという危機感から、私は2つのアクションを自分に課しました。
- アーキテクチャの再学習： ドメイン駆動設計（DDD）やオニオンアーキテクチャに関する書籍を読み込み、コード上の実装と理論を照らし合わせる作業を繰り返しました。「なぜこのレイヤーが必要なのか」という設計の意図が腹落ちし始めると、複雑だと思っていたコードベースが、むしろ「整理された読みやすい地図」に見えてくるようになりました。
- 朝の「英語集中トレーニング」： 始業前の30分〜1時間を英語学習に固定しました。注力したのは、聞き取った音を書き出す「ディクテーション」と、聞こえた内容を再現する「リプロダクション」です。単に聞き流すのではなく、音を細部まで捉えて自分で発音する訓練を繰り返したことで、DSUのスピードにも少しずつ耳が慣れ、自分の考えを口に出す心理的ハードルが下がっていきました。
【2年目】領域の拡大と「架け橋」としての役割
2年目に入ると、1年目に積み上げた基礎が芽を出し始め、開発の幅が大きく広がりました。
1. フロントエンドへの再挑戦と「型」の洗練
バックエンドだけでなく、Reactを用いたフロントエンドの実装にも本格的に携わるようになりました。
以前もReactの経験はありましたが、クラウドログのコードベースで採用されていたPresenter / Containerパターン（UIとロジックの分離）の徹底された設計には、当初戸惑いました。
また、以前経験していたプロジェクトがGraphQLだったのに対し、今回はREST API。バックエンドの構造を深く理解していたため、API通信周りの把握はスムーズでしたが、一番の壁はTypeScriptの複雑な型システムでした。
厳格に定義された型を正しく扱い、柔軟かつ安全にコードを書くための作法を習得するには、かなりの時間を費やしました。しかし、ここを乗り越えたことで、フロント・バック両面を俯瞰できる真のフルスタックな視点を持てるようになりました。
2. AWSとKubernetesへのステップアップ
インフラ面では、これまでGCP（Google Cloud Platform）の経験しかありませんでしたが、クラウドログの基盤であるAWSの運用にも携わるようになりました。
まず驚いたのは、GCPとは全く異なるUIと、ネットワークやセキュリティ設定の緻密さです。IAMの権限管理やVPCの設計など、GCPに比べると設定項目が非常に細かく、どこにどのリソースがあるのかを把握するだけでも一苦労でした。
さらに、Kubernetesの操作も少しずつ経験し、コンテナオーケストレーションの仕組みを実務を通じて学べたことは、エンジニアとして大きな自信に繋がりました。
3. 英語でのファシリテーションとチームビルディング
1年目に苦戦した英語は、それほどハードルの高い障害とは感じなくなってきました。
定例MTGのファシリテーションもスムーズに行えるようになり、さらにフィリピンメンバーとのチームビルディングイベントでは、司会を一人で務めることができました。
イベントの内容は、メンバーの意外な一面を知るためのクイズ形式のレクリエーション。約1時間、英語で喋り倒すというハードな挑戦でしたが、無事にやり遂げたときには、以前感じていた「喋ることへの抵抗感」が消えつつあることに気づきました。
言葉の壁を越えてチームが一つになる瞬間を、自分が主導できたことは大きな財産です。
【3年目】「与える」ことで深まる専門性と、AIによる次世代開発への挑戦
3年目に入ると、個人の開発タスクを完遂するだけでなく、チーム全体の技術力底上げや、プロダクトをビジネスの視点から捉える機会が増えていきました。
1. アウトプットを通じた知識の還元
この1年、特に力を入れたのが部内勉強会の開催です。セキュリティやデータベースといった、バックエンドエンジニアとして避けては通れない技術領域をテーマに選びました。
最も苦労したのは、単なる知識の伝達に留まらず、メンバーの理解度を深めるための「クイズ」を準備すること。しかし、その甲斐あって「非常にためになった」というポジティブなフィードバックを多くもらい、教える側としての喜びを感じました。アウトプットを前提とすることで、自分自身の知識もより強固なものへと磨き上げられました。
2. 「お客様の声」を技術的な解決へ繋げる
また、カスタマーサポート経由での技術的問い合わせへの応対も担当するようになりました。
ソースコードと向き合っているだけでは見えにくい「お客様がどこで不便を感じているのか」という肌感を直接得られたことは、大きな収穫でした。
調査の過程で、これまで自分が触れてこなかった古い機能や複雑な仕様についても深く理解することができ、プロダクト全体を俯瞰して、改善の優先順位を判断する視座が養われました。
3. 現在の挑戦：AIを活用した「仕様駆動開発」の導入
そして直近の半年間は、AIによる開発効率向上チームに所属し、バックエンド開発のあり方を再定義しています。
今、私たちが注力しているのは「仕様駆動開発（Specification-Driven Development）」の導入です。AIがコードを生成する精度は、与える「仕様（プロンプトや定義）」の質に大きく依存します。
単にコーディングをAIに任せるのではなく、まず厳密な仕様を定義し、それをベースにAIがコードを生成するフローを構築しています。
これにより、エンジニアは「どう書くか（How）」よりも「何を作るか（What）」というドメインの本質的な議論に集中できるようになります。3年前にDDDやアーキテクチャの理解に苦しんだ経験が、皮肉にも今、AIに正しい指示を出すための「言語」として役立っているように感じます。
【まとめ】3年間を振り返って
クラウドログでの3年間を振り返ると、それは「自分の限界を少しずつ押し広げていく過程」でした。
- 1年目： 英語とアーキテクチャに翻弄されながらも、ルーティン化で基礎を固めた。
- 2年目： フロントエンドやインフラへ領域を広げ、チームの架け橋となった。
- 3年目： 知識を還元し、プロダクトをビジネス視点で捉え、AIという未来の武器をつくる。
最初は英語でのDSUですら冷や汗をかいていた私が、3年を経てやっとしゃべることへの抵抗感が少なくなってきました。
技術の進化は速く、3年前の常識が通用しなくなることもあります。しかし、クラウドログで培った「不確実なものに飛び込み、学び、適応する力」があれば、この先の変化も楽しんでいけると確信しています。
