はじめに
Dress Code Advent Calendar 2025 の 4 日目の記事です。
今年の 1 月に Dress Code 株式会社 にジョインをして、およそ 1 年が経過しました。
まだ自分が若いと信じていたので「過去は振り返らない」ことにしていましたが、体力の衰えと老いから来るであろう体調の不安定さを感じずにはいられなくなりましたので、観念して振り返り記事を書いてみます。
記憶力が悪いので多少脚色している部分があるかもしれませんが、ご容赦ください 🙏
対象読者
- 0 年目のスタートアップってどんな感じなん？が気になる方
- Dress Code という会社に一ミリでも興味を持っていただいている方
- DRESS CODE という製品に一ミリでも興味を持っていただいている方
- 未来の自分
会社 / チームを振り返る
定量的な振り返り
数字で振り返れるところを見てみると、この 1 年でこれくらいの変化がありました。
| 観点 | 2025-01 | 2025-12 |
|---|---|---|
| プロダクト数 | 4 | 22 |
| チーム数 | 1 | 3 |
| プロダクトチームの人数 | 7 | 16 |
| 対応している言語数 | 3 | 6 |
| カンファレンス等への登壇 | 0 | 6 |
| ADR の数 | 15 | 157 |
| マージされた PR の数 | 1,871 - backend: 1,216 - frontend: 655 |
3,933 - backend: 2,467 - frontend: 1,466 |
| CI/CD の実行回数 | 2,826 - backend: 1,950 - frontend: 876 |
9,677 - backend: 1,551 - frontend: 8,126 |
| リリース回数 | 53 - backend: 20 - frontend: 33 |
323 - backend: 87 - frontend: 236 |
| リポジトリの規模(メインのみ) | backend: 93,233 行(6,841 コミット) frontend: 124,255 行(4,014 コミット) |
backend: 728,540 行(20,788 コミット) frontend: 576,425 行(11,297 コミット) |
弊社はコンパウンド戦略を採用しており、創業時からプロダクトを横展開できるように工夫して開発が進められています。
この 1 年での圧倒的なプロダクトの増加、それに伴うコード量の増加は、基盤が整いスケールする準備ができたと言い換えられそうです。
横展開するプロダクトは「引き算思考」で考えられており、後々破綻しづらいようにデータモデルを中心に設計が進められています。
引き算思考については @syoryu89 が登壇した開発生産性 Conference 2025 の内容に譲ります。
チームの規模も 2 倍以上に増えており、まさにスタートアップにおけるスピード感を肌で感じられる環境になっています。
定性的な振り返り
AI の導入・利用が爆発的に拡大した
一番大きいのはやはり AI / LLM が開発を伴走する体制になったことです。
1 年前は開発者が個人で Cursor に課金、利用して開発をするような状況で、利用は個人の裁量に委ねられていました。
この 1 年で、開発者には Cursor が支給され、Devin も常駐し、コードは Gemini がある程度レビューしてくれるようになりました。
AI の登場機会が増えるごとにガードレールも整備されていき、AI と伴走しながら開発をするスタイルが主流になりました。
全社的な課題解決・仕組み化が進んだ
週次で行われる「こまった巻き物の会」で個々人が感じた「こまりごと」を組織的に解消をする流れが加速しました。
「こまった巻き物の会」については、私が Platform Engineering Kaigi で登壇した資料にて軽く触れています。
これによって属人化していた領域が組織的に対応され、仕組み化・効率化が行われています。
細かいところで言うと npm から pnpm への移行、マイグレーションの自動化、ビルド・テストの速度改善など。
また、MTG の運用方針やリリースを盛り上げる仕掛けなどプロダクトチーム全体で発見した課題に対して取り組んでいく文化が醸成されています。
特にスタートアップだと属人化を許容して前にどんどん進むような風潮もありますが、定期的に足元を固める運動が自発的に出てきているのが素晴らしいことだと感じています。
Notion の活用が進みドキュメントが充実した
弊社ではナレッジベースとして Notion を利用しており、この活用が 1 年でかなり成熟しました。
Notion を SSoT (Single Source of Truth) とする活動が発生し、課題管理だけではなく全社 OKR や MTG の議事録、ADR なども Notion で一元管理するようになっています。
この活動と、Notion AI の活用によって、ナレッジへのアクセスが容易になり、特にオンボーディングのコストがだいぶ圧縮されたと実感しています。
Notion の整備に伴い、開発組織には ADR (Any Decision Record) を書いて決定事項を文書化する文化も定着したと感じています。
Any Decision Record については @syoryu89 の発表資料に詳細が書かれています。
開発者が自発的にドキュメントを書き、みんなで読み合わせを定期的にする時間を確保しているので、脳内にインデックスが整えられ、Notion AI で探し出せるようになりメンタルモデルのアップデートが容易になったと感じています。
個人を振り返る
主な取り組み
- コンパウンドの基盤となる仕組みの設計・実装
- プロダクトセキュリティ
- Platform Engineering 的な活動
コンパウンドの基盤となる仕組みの設計・実装
元々これをやるつもりで入社したわけではありませんでしたが、必要に駆られて実装しました。
ビジネスフローを制御するための機構として動くもので、現時点で 20 以上の業務フローを支える基盤として機能を提供できています。
入って 1 ヶ月が過ぎるくらいで着手し、3 月末にはリリースしたので、実質 2 ヶ月弱で実装・リリースをしたことになります。
弊社では Platform Capabilities として共通基盤として提供すべきものを事前に定義しており、その領域に該当します。
個人的には基盤をゼロから設計・実装する経験は得るものが多く、非常にありがたいところでした。特に基盤としての機能を、抽象と具体を行き来して利用シーンを想定しながら設計・実装するシーンはそう多くないので希少な経験を得られました。
振り返ってみると、初期から非同期処理をベースにしてスケールできるようにしたのは運用の観点からも良かったですし、責務を明確に分離して保守性を高められるという点でも良かったと感じています。
一方で、利用者側やフロントエンド側の視点が欠けており、UX に改善の余地が残るのは反省点です。
取り組み方として、大型のリリースの後には定期的にリファクタリングの時間を確保し、負債を溜めないように進められたのは非常に良かったです。
ただ、思った以上に利用する機能側がスケールしたので、リリース優先で妥協した部分が負債として顕在化してしまった実感があります。
とはいえ、2 ヶ月弱で実装した機能が、現時点で 20 以上のフローを支えられているのはポジティブに捉えています。
来年は倍以上にスケールできるように整えていきたいですね。
プロダクトセキュリティ
弊社は創業初期からセキュリティにもちゃんと投資しており、ISMS と SOC2 Type1 の認証取得を早い段階から計画・実装していました。
私もこれに多少関わっており、以前にも Zenn で書いたような取り組みをしました。
GuardDuty の通知の集約や Security Hub の導入、Trivy の CI への組み込み、DAST の導入など、プロダクト全体のセキュリティ向上に関わらせてもらいました。
個人的には、ライブラリの脆弱性対応が最も運用の負荷が高い領域でした。
ここに対して、Devin を活用して影響範囲調査や簡単な動作確認をさせ、負荷を下げられる仕組みを作れたのが良かったです。
具体的には、Devin の Playbook を用意して、Renovate が PR を作成したことをトリガーとして GitHub Actions から Devin の API 経由で Playbook を実行する構成を構築しました。
結果、ライブラリのアップデートをかなり省力化できるようになりました。
Shisho Cloud も使っていますがあまり活用しきれていない実感があるので、来年は DAST にも力を入れていきたいところです。
Platform Engineering 的な活動
Platform Engineering Kaigi ではプロセスを整えることも Platform Engineering だよね、という話をしました。
個人的な活動としては、本番環境での調査やデータ分析の基盤として Redash を Fargate 上で動作させるようにしたことがファインプレーだったかもしれません。
Redash の運用コストを可能な限り下げるために Fargate で動作させるようにした結果、運用開始して半年以上経ちますがサーバーダウンは経験していません。
PoC 用に作ったリポジトリがあるので、参考になれば幸いです。
Redash を自前で持つことは管理するサーバーを増やすことになるので運用コストに見合うのか不安でしたが、Redash 導入以前は CS からのデータ取得依頼も開発が都度対応していたため、そのコストも削減できました。
今振り返ると、このタイミングでデータ分析環境を民主化できたのは非常に良かったと感じています。
現在はダッシュボードは 4 つ、クエリは 100 以上登録されており、開発以外も含めた全社的な利用も拡大しています。
来年は仕組みで解決できる領域を増やしていきたいなぁとおもうところです。
その他
初めて OSS に PR を送ったのも今年が初めてでした。
修正範囲の割に時間をかけ過ぎてしまったので、徐々に慣れていきたいところです。
そこから OSS へのコントリビュートが止まってしまっているので、少しずつでいいからやっていきたいですね。
ちゃんとしたイベントで登壇するのも今年の Platform Engineering Kaigi が初めてでした。
思ったよりも話すことに夢中で緊張が薄かったのが思い出深いです。質疑応答のほうがよっぽど緊張しました。
ちゃんと想定質問集を作ってたのに頭に入れるのすっかり忘れて、頭が真っ白になってしまったので次回はそこも頭に入れておきたいところです。
他にも、もう少し顔をあげて話そう、とか、余裕を持って資料を作ろう、とか反省点は無限にあります。
終わりに
振り返ってみると、スタートアップらしい変化の大きい 1 年でした。
定年説もある 35 歳になる年度で、いまだに新しい領域にチャレンジできる環境に感謝しつつ、今後も柔軟に対応できるようにしていきたいな、と改めて感じました。
会社の成長も AI 活用によるところが大いにあると思っています。
この AI とコンパウンドという未知の領域で、新しいチャレンジをしたい方はまだまだ募集中です。
興味が湧いて話をしてみたい、と言う方がいれば気軽にお話ししましょう。
DRESS CODEのProduct & Technologyチームによるテックブログです！ プロダクトマネジメントからモデリング、アーキテクチャ、フロントエンド、バックエンド、SRE、セキュリティなどなど様々なテーマで情報を発信しています！
Discussion