想定質問とその回答
Q: 「フロントエンドもできるんですね？」
A: はい、Next.jsでの開発経験もありますが、あくまでバックエンドエンジニアとして、API連携やデータフローを理解するために必要な範囲で取り組んできました。専門はサーバサイドで、特にAWSのサーバレスアーキテクチャ設計が得意分野です。
/icons/hr.icon
Q: 「マネジメントとエンジニアリング、どちらがメイン？」
A: メインはバックエンドエンジニアです。マネジメント経験はプロジェクト推進の必要性から身につけましたが、技術的な設計・実装が最も得意で情熱を持って取り組んでいる領域です。キャリアとしては自分自身の技術を深めていきたいという思いが強く、その過程で求められればリードやマネジメントを担うこともあります。
/icons/hr.icon
Q: フルスタックでのご経験とのことですが、バックエンド（AWS + Python）の中でも特に自信がある領域、あるいは工夫した実装について教えてください。技術選定の理由やパフォーマンスへの配慮があれば、ぜひそこも含めてお聞きしたいです。
当時のお客様から、インフラやミドルウェアの保守はなるべく避けたいという要望がありました。そこで、スケーラビリティと運用コストを考慮して、AWS Lambdaを採用しています。
言語にはPythonを選定しました。理由は2つあります。1つは、プロジェクト初期に非定型コンテンツに対する類似検索機能の要望があり、将来的に機械学習や自然言語処理との親和性が高いPythonが適していた点。もう1つは、Lambdaとの相性の良さです。事例も多かったため、開発初期の立ち上げやメンテナンスのしやすさを重視しました。
/icons/hr.icon
Q: Lambdaで構築されたバックエンドということですが、例えばAPIの構成やバッチ処理など、具体的にどのような機能を担当されたか教えてください。特に、設計面や工夫したポイントがあれば、ぜひお聞かせください。
A: APIはAPI GatewayとLambdaの構成で、WAFを使ってプロテクトする構成にしています。
バッチ処理では、まずSQSとLambdaを組み合わせた非同期分散処理を作りましたが、ジョブ同士の連携が煩雑でログの追跡が難しさや状態管理の複雑化に課題がありました。そこで、Step Functionsを導入し、ジョブ全体を一元管理することで処理の見通しやすさを大幅に改善しました。また、処理の成功・失敗状態を可視化でき、ログ収集も効率化し、特に開発環境での調査やデバッグに非常に役立ちました。顧客数がまだ少ないため、運用面での大きな効果はこれからですが、将来的に顧客が増えれば運用工数の削減にも繋がると考えています。
/icons/hr.icon
Q: AWS Lambdaを使ったシステムの開発経験が豊富とのことですが、Lambdaの課題や制約に直面したことはありますか？もしあれば、それにどう対応したか、具体的なエピソードを教えてください。
A: AWS Lambdaにはいくつか制約や課題がありますが、私のプロジェクト経験の中で特に意識して対応したのは大きく3つの点です。
1つ目は、デプロイパッケージのサイズ制限です。
機械学習関連の処理で外部ライブラリが多く、サイズが大きくなりがちでした。
不要な依存を極力削減しつつ、必要に応じてEFSをマウントしてライブラリを外部参照する検証も行いました。
ただ、検証したところネットワーク速度の低下により参照が遅くなってしまい、一旦EFSの利用は見送りました。
次に、RDSの接続数制限です。
Lambdaはスケーラブルに同時実行されるため、コネクション数がすぐ上限に達しやすいという課題がありました。
このためRDS Proxyを導入し、接続の効率化とエラー防止に取り組みました。
3つ目は処理時間です。Lambdaの最大実行時間は15分という制約があるため、長時間のバッチ処理についてはStep Functionsを使って処理を分割し、タイムアウトを回避しました。
さらに、同時実行数にも注意を払い、SQSを用いたキューイングでリクエスト数を調整し、スロットリングを防いでいます。
これらの制約や課題を踏まえつつ、AWSのマネージドサービスを組み合わせて柔軟かつ安定したシステムを設計・運用してきました。
/icons/hr.icon
Q: Lambdaを使った開発で、特に工夫したポイントやパフォーマンス改善の経験はありますか？具体的に教えてください。
A: AWS Lambdaは最大実行時間が15分という制約があるため、1つの関数に機能を詰め込みすぎず、小さく切り出す設計を心掛けています。これにより処理の見通しが良くなり、メンテナンスも容易になると考えています。
（適切な粒度に注意を払っています）
パフォーマンス面では、Lambdaプロジェクトでは扱うデータ量が比較的少なかったため大きな問題はありませんでしたが、別のプロジェクトで本番環境へのクエリが30分以上かかり、システムの負荷を増大させてしまった経験があります。
この経験を通じて、本番環境に対しては必ずクエリの実行計画を確認してから実行することを徹底し、以降の開発ではデータ量やアクセスパターンを意識した設計・実装を心掛けています。
/icons/hr.icon
Q: これまでのプロジェクトで、チームマネジメントやプロジェクト推進に関して意識していたこと・工夫したことはありますか？
A: チームマネジメントにおいて、私が特に意識しているのは、情報の可視化と個々に最適化されたコミュニケーションです。
まず、説明や相談の際は口頭だけでなく資料を用意することをしています。聴覚だけでなく視覚からも情報を得られることで理解度が高まり、後から見返すこともできるため、方針説明や技術共有の場では必ずドキュメントを準備するようにしています。
また、タスク設計においては、メンバーの特性に合わせて最適な粒度で依頼するようにしています。自走できるメンバーには大まかな方向性のみ伝え、逆に細かい指示が必要なメンバーには、手順化や細分化を行ったうえでタスクを依頼しています。
そのためにも、日々のコミュニケーションを通じて、個々の得意・不得意や特性を把握することを重視してきました。こうした取り組みによって、チーム全体のパフォーマンスを最大化できるよう努めています。