@pinkumohikan 0→1開発 やってよかったこと4選 2024/03/22 テテミート #8

自己紹介 ✔ ぴんくもひかん ✔ 髪色が定期的に変わることに 定評がある (比較的) 若者 Software Engineer (自称) ✔ 普段はテテマーチで SINIS for X を開発 ✔ バックエンド寄りの技術が好き ISUCON毎年参戦中！ 2

今日お話しすること 自社SaaSプロダクトを0→1開発するときに試みて「良かった」こと 3 出典: https://x.sinis.jp/

1. 新人向けドキュメントの整備 ● 新人エンジニアが知るべきことを 広く薄く まとめる ● オンボーディングコストの削減に効く ○ 正社員・業務委託はもちろん、副業受け入れにも◎ ● 採用面談(面接)時の資料として ○ 面談専用の資料は維持コストが高い ○ これなら一石二鳥 ● ポイント ○ 最初に一人でガっと作り、受入直前にメンテする ○ オンボーディング終了後に新人にメンテを依頼 ○ 書きすぎない (詳細は別資料に分ける) 4

2. 技術選定の記録残し ● ADRやDesignDocみたいなもの (数年後の「なんで・・・」に備える) ● ポイント ○ 「まとめ (選定結果 + 理由)」と「経緯 （検討・議論の内容）」のパートを明確に分ける 5

3. ライブラリの定期的バージョンアップ ● ライブラリバージョンアップを毎週実施 ● 数年後に向けた開発生産性の維持、セキュリティリスク抑制のため ● ライブラリのバージョンを上げない → 技術的負債が生まれる典型パターン ○ セキュリティアップデートは基本最新バージョンのみ (古いとセキュリティリスクに直結) ○ ビッグバンバージョンアップ しんどすぎ問題 ● ポイント ○ 属人性の排除 (「チームメンバー全員」が「単独」で「バージョンアップ出来る」状態に) ○ Dependabot等 自動化ツールの活用 ○ 不具合を見落とすたび、静的解析やテストの追加・改善 ■ 見落としはゼロには出来ないが、既知の失敗は仕組みで防ぐ 6

4. 定期的なアプリケーションエラー・負荷チェック ● 毎週火曜日の午前中に、チーム全員で実施 ● アプリエラーの見落とし防止、インフラのキャパシティプランニングに効く ● 過去に見つけた事例 ○ いつもよりDB負荷が異常に少ない → 稀にバッチが動いてない不具合 ○ 周期的に特定の時間だけDB負荷が跳ねる → 変更によってindexが効かなくなっていた ○ CPU・メモリ使用率が常に余裕ある → FargateのvCPU数・メモリ量減らしてインフラ代節約 7

まとめ 0→1開発時にやってよかったこと 1. 新人向けドキュメントの整備 2. 技術選定の記録残し 3. ライブラリの定期的バージョンアップ 4. 定期的なアプリケーションエラー・負荷チェック会 8