初めての⼤型実装で起きた失敗と得た経験

1. 初めての大型実装で起きた失敗と得た経験 2025/11/18 発表者: 榎本祐希
2. 榎本 祐希 (えのもと ゆうき) 所属 : 株式会社じげん 経歴 : 2025 年 4 月 新卒入社 Backend/インフラメイン LT 会は初めて (すごく緊張しています) 自己紹介
3. AWS SES を使ったメール一斉送信システムを構築 インフラ分野に強い興味があり、AWS の基盤から触れる最高のチャンス 技術的なキャッチアップも順調で自信満々 構成 前提
4. 実装フェーズで手探り状態に 「あれ？設計書に書いてないけど、この挙動、どうするんだ？」 次々と増えていく曖昧さ 実装スピードが目に見えて落ち始める 💡 この時点での気づき 大まかな挙動に目がいって細かい部分を無視していた 小さな違和感と設計の綻び
5. 設計不足がプロジェクト全体を巻き込む スケジュールは当初予定から 1 か月遅延 💡 遅延の本質 「コードが書けない」ことではなく、曖昧な設計が曖昧な指示や手戻りを生んでいた 遅延の始まり
6. 処理の分離の甘さ: アプリと AWS SES が密結合し、インフラなしではテストができない状態に 生成 AI の誤用: 曖昧なインプットでその場しのぎのコードを量産 保守コストの高い技術負債を高速で積み上げる 失敗の本質 (1) 致命的な考慮漏れ
7. あり得ない前提: 『自分の 120%のパフォーマンスを常に出せる』 考慮漏れ: 全体 MTG、リリース準備、エラー監視など実装外の業務 工数が圧迫され、自分を追い込む結果に 実装が終われば全て終わり、という狭い視野だった 失敗の本質 (2) 工数設定の大きな誤り
8. 失敗は「認識の甘さ」に集約されていた。 1. 技術知識の体系化不足 2. 工数見積もりの根本的なミス 2 つの決定的な気づき
9. 「動けば OK」ではない なぜその技術を使うのか？アーキテクチャ全体を理解する 生成 AI を正しく使うには、設計思想の深い理解が必要 気づき(1) 知識は体系化せよ
10. 工数管理はプロのスキル 「理想の自分」ではなく「現実の自分」で見積もる 余裕を持ったバッファを確保し、 「早く終わらせる」ポジティブな期待値調整を行う 気づき(2) 期待値調整のプロへ
11. 失敗はエンジニアとしての生き方を教えてくれた 知識の体系化と期待値調整が技術をステップアップさせた 失敗を恐れず挑戦し、学習を続けましょう！ ご清聴ありがとうございました！ まとめ / 次のステップ