Sponsored：Dress Code株式会社
AIによって、エンジニアの働き方や開発組織はどう変わっていくのでしょうか。その一つの形を示しているのが、Dress Code株式会社です。同社は、AIを開発工程で活用するだけでなく、AIによって一人のエンジニアが担える範囲が広がることを前提に、仕事の分け方や組織そのものを設計しています。
エンジニアのロールは「プロダクトエンジニア」に統一。一人ひとりが複数のプロダクトに関わりながら、フロントエンド、バックエンド、インフラまで横断して担当します。さらに、PdMが担うリサーチや仕様策定など、隣接職種の領域にも「染み出す」ことで、プロダクトづくりに広く責任を持っています。
そんな働き方を、どのように実現しているのでしょうか。2025年7月にDress Codeへ入社したプロダクトエンジニアの内藤翔太さんに、日々の業務やAIの使い方、それを支える組織文化について聞きました。
プロフィール
内藤翔太
慶應義塾大学大学院でスパコンを用いた大規模分子動力学シミュレーションの研究を行いながら、複数社で開発インターンを経験。2023年にレバレジーズ株式会社に入社し、バックエンド / インフラ領域を中心にリプレイスプロジェクトを推進。2025年7月にDress Code株式会社へ入社し、フルスタックでのプロダクト開発に加え、採用や技術広報も担当。
複数プロダクトを、フロントエンド・バックエンド・インフラまで一人で開発
──まず、内藤さんの所属と業務内容について教えてください。
内藤：今は『DRESS CODE』の共通基盤を開発するプラットフォームチームと、そのうち人事・労務領域を一元管理する『HR Force』シリーズの開発チームの2つに所属しています。
プラットフォームでは、主に外部システムとのデータ連携基盤の開発に携わっていて、『HR Force』では、マイナンバーや在留カードなどを管理する「公的ID」や、従業員などの情報を一元管理する「メンバー管理」が担当ですね。
どちらもフロントエンド、バックエンド、インフラと領域を分けずに、必要なところを一人で横断して開発しています。
──複数のチームとプロダクト、さらに技術領域もまたぎながら開発しているんですね。
内藤：私みたいに2チームを兼任しているのはちょっとイレギュラーなんですが、一人が複数のプロダクトを持って、フロントエンドからバックエンド、インフラまで一気通貫で開発するのは、Dress Codeでは普通ですね。
ちなみに私たちは、『HR Force』の「組織管理」「メンバー管理」のような業務領域ごとの単位を「プロダクト」と呼んでいます。一般的には「機能」に近いイメージですが、一部はすでに単体でも提供していて、将来的には必要なものだけを選んで使ってもらう構想もあるので、それぞれを一つのプロダクトとして扱っているんです。
──いずれにしても、かなり広い範囲を一人で担うことになりますね。普段はどんなふうに開発を進めているんですか。
内藤：3か月ごとに引くロードマップをベースに、2週間に1回のリリースへ向けて進めていく形ですね。
直近の2週間だけでも、『HR Force』の「メンバー管理」で、一人のメンバーに同じ部署の複数役職をひも付けられるようにする改修をしました。同時にプラットフォーム側では、『DRESS CODE』から外部へデータを出す際に、条件によって出力するデータやファイルを振り分ける機能を開発していて、その合間に既存プロダクトのリファクタリングやバージョンアップもさばいていました。
エンジニアのロールは「プロダクトエンジニア」一つだけ
──一人がフロントエンド、バックエンド、インフラまで横断して開発しているとなると、そもそもエンジニアのロールも領域ごとには分けられていないということですか。
内藤：そうですね。Dress Codeのエンジニア組織にあるのは「プロダクトエンジニア」というロールだけです。
もちろん、それぞれの領域に専門性を持つこと自体は大事ですが、ロールを分ければ分けるほど、それぞれのロールの間にあるボールも落ちやすいし、「ここから先は任せました」になりやすいんですよね。
それに、バックエンドの担当者が一番仕様を理解しているのに、それをフロントエンド側にうまく伝えられず、想定と違うものができる、みたいなことも普通にあります。最終的に「じゃあ、このプロダクトは誰が責任を持つんですか」という話にもなる。
だったら、「一人で見られる範囲は一人で見た方がいいよね」という考え方なんです。フロントエンドからバックエンド、インフラまで一気通貫で担当できれば、間のコミュニケーションコストは減るし、プロダクトへの解像度も上がる。コードの一貫性も保ちやすくなるので、結果的にデリバリも早くなって、アウトプットの精度も上がると思っています。
以前だったら、「とはいえ、一人でそこまで全部見るのは難しいよね」となっていたと思うんですけど、AIがある今はそれも現実的になっている。だから、ロールで細かく区切るより、プロダクトエンジニアとして広く持つ方がやりやすい、ということですね。
──では、セキュリティのように高い専門性が求められる領域は、どのように対応しているんですか。
内藤：そこは、個人の判断に依存しない体制になっています。
たとえば、認可の設計やテナントの分離、監査の証跡のように、間違えると致命的になるところは、そもそもプラットフォームチームが責務を持っていて、各エンジニアがその都度判断しているわけではありません。そのうえで、もちろん一人ひとりが自分の実装で気をつけたり、重点的に見るメンバーもいます。
さらに、ISMSの認証やSOC2 Type 2の報告書も取得していて、外部の監査が継続的に入っています。SOC2 Type 2は一定の期間、運用がきちんと回っているかを見るものなので、個人の裁量だけでやっていたら通りません。
──個人の判断に頼らず、組織としてセキュリティを支える仕組みになっているんですね。一方、エンジニア組織にはマネージャーに当たる方もいないとお聞きしました。
内藤：今はいないですね。マネジメントを経験した人も含めて、自分で判断して進められるメンバーが揃っているので、2週間のリリースサイクルの中で何をどこまでやるかは、それぞれが自分で調整しています。
ただ、マネージャーがいないからといって、やはりすべてを個人の判断に委ねているわけではなくて。どの開発を優先するかはお互いに話し合って決めますし、開発工程で意思決定が必要な事柄があれば、各自PdMやCEOに直接相談します。品質についても、個人の感覚ではなく、リリースの判断基準が決まっています。言ってみれば、今はマネジメントの機能がないというより、その役割を特定の一人に寄せていない、という感じなんですよね。
もちろん、これから組織が大きくなれば、マネジメントをメインで担う役割が必要になる場面も出てくると思うので、ずっと置かないと決めているわけでもないんです。
AIによって、エンジニアの枠から「染み出す」
──複数のプロダクトをフロントエンドからバックエンド、インフラまで担当して、しかもマネージャーがいない中で、一人ひとりが自分で判断しながら開発を進める。ここまで伺うと、かなりの業務を一人で回している印象です。
内藤：そうですね。ただ、AIを使える前提であれば、そこまで驚くことでもないかなと思っています。
私自身、前職でもAIなしでフロントエンド、バックエンド、インフラまで見ていたので、「AIが使えるなら、複数プロダクトになっても何とかなるだろう」とは予想していました。実際、負荷は増えていますけど、設計の壁打ちから実装までAIを使えるので、対応できないほどではないですね。差し込みが入ればその分何を見送るかをその場で決めるので、タスクが積み上がり続けることもありません。
私は開発が速くなったことよりも、エンジニアという職種そのものから「染み出せる」ようになったことの方が、もっと本質的な変化だなと思っています。
──職種そのものから「染み出す」というのは？
内藤：たとえば、これまでPdMが中心になっていたドメイン調査や要件整理、概念・仕様設計も、AIのDeep Researchを使ったり、壁打ちしたりしながら、エンジニア側で一部を担えるようになりました。
テストフェーズでも、機能単位のシンプルなものであれば、AIに画面を操作させて正常系の動作確認をしています。最終的な検証はQAチームにお願いするとしても、その前に最低限確認しておけば、「そもそも正常系が動かない」と差し戻されるような往復は減らせるかなと。
──実際に、そうやってエンジニアの担当範囲が広がった例はありますか。
内藤：直近の「メンバー管理」の改修がまさにそうでしたね。
きっかけは、お客様からいただいた「個人が同じ部署で複数の役職を持てる仕様にはなっていないんですか」という問い合わせでした。
そこでまず考えたのは、「そもそも『DRESS CODE』として持つべき機能なのか」ということです。今の仕様になった経緯を確認した上で、国内外では複数役職をどう扱っているのかも調査しました。それを踏まえて「これは本来持つべき機能だよな」と判断して、CEO、PdM、エンジニアで仕様や設計を話すミーティングに持ち込んだんです。
結果的に合意が取れたので、そこから仕様を詰めて実装へ。影響範囲も見ながら開発して、最後は手元で動作確認を済ませ、QAに渡しました。
必要性を調べて、提案して、仕様を決めて、実装して、QAへ渡す。ここまでやって、実際にかかったのは2日くらいですね。
──単に担当する仕事が広がっただけでなく、「そもそも何を作るのか」という意思決定にまで、エンジニアが染み出しているんですね。
内藤：そうですね。こういう「染み出し」は、AI時代にはだんだん当たり前になっていくんじゃないかなと思っています。
一人ひとりの自律を支えるADRの文化
──各エンジニアが複数プロダクトを技術領域をまたいで担当し、さらにPdMなど隣接職種の領域にも「染み出して」いく。しかも一人ひとりが自律的に判断して動くとなると、その人にしか分からないことが増えてしまうことはないんですか。
内藤：そこはADRに残すようにしています。
ちなみに私たちのADRは、「Architecture Decision Record」ではなく、「Any Decision Record」を指していて、アーキテクチャに限らず、意思決定したことは何でも残すというスタンスなんです。
特に大事にしているのが、「採用しなかった案」まで書くこと。採用したものは最終的にコードベースに残りますけど、「なぜ別の案を採らなかったのか」「そのとき、どんな制約があったのか」は、書いておかないと消えてしまうので。
──実際、どんな場面でADRは役に立つんでしょうか。
内藤：たとえば今、『HR Force』の「メンバー管理」で、画面ごとにフロントエンドが個別にデータを取りにいく構造から、バックエンド側にデータ構造を持たせて、フロントエンドは描画中心にする形へ寄せています。
詳細画面の基盤は私が作ったんですけど、同じ考え方をほかのページにも適用していくので、「どんな構想で設計したっけな」と振り返るときに、自分のADRが結構便利なんです。
逆に、一覧画面は別のメンバーが作っていたので、私が対応するときにはその人のADRを見て、「こういうふうにバックエンドを構成して、フロントエンドに返してるんだな」と理解しました。実装用のAIもADRを参照しながら動いているんですが、人間側も背景まで分かっていた方がやっぱりやりやすいですね。
──それぞれのADRを見ると、項目もかなり充実していますし、図までありますよね。1つ作るのに、どれくらい時間がかかるんですか。
内藤：10分、長くても20分くらいですね。
そもそも設計する段階でAIと壁打ちしていて、なぜこの案にしたのか、逆に何を無視したのかといった議論がログに残っているので、その時点でADRの土台はできているんです。図もAIですぐ作れますし、そんなに大変ではないですね。
会社としてADRを書き始めて1年半ほどですが、すでに500本以上あります。新しく入ったメンバーも、入社して間もない時期に3本くらい書いていました。
──こういう記録づけはなかなか習慣にしづらいと思うんですけど、みなさんしっかり残しているんですね。
内藤：そこはやっぱり、文化になっているからだと思います。
もともと文化がないところに後から根付かせようとすると、やはり難しいですよね。「ADRを書こう」という動きはあっても、書く人もいれば、全然書かない人もいる。どうしても個人やチームの意欲に依存してしまって、組織全体の文化にはなかなかならないと思います。
Dress Codeは比較的早い段階からADRに取り組んでいて、定期的にADRの読み合わせもしています。特にここ1年くらいで文化として定着してきて、今ではみんなが当たり前に書くようになった印象ですね。
「PdMになりたい」から、ロールを越えて価値を出す働き方へ
──ここまで、Dress Codeならではの働き方や組織文化について伺ってきました。では、内藤さん自身は入社した当初から、こうした働き方を自然に受け入れられたんですか。
内藤：いや、そんなことはないですね。特にロールの考え方や、業務の染み出し方については戸惑うことも多かったです。今振り返れば、当初はむしろロールに縛られていたのかなと思います。
──というのは？
内藤：もともと私は、PdMになりたかったんですよ。正直、エンジニアの上位互換みたいに思っていた時期もあって。最終的なあるべき姿を描いて、「何を作るのか」を決める。自分が求めていた、抽象度が高くて責任範囲の広い仕事はこれだ、と思っていたんですよね。
だからこそ入社当初は、「ここはPdMに決めてほしい」と思うこともありました。
たとえば『HR Force』で電子申請機能を開発することになったときも、「どういう仕様・機能がないと電子申請が成り立たないのか」「今持っているデータだけで必要な情報を網羅できるのか」「行政APIの制約はどうなっているのか」といった概念設計やドメイン調査は、PdMがやるものだと思っていたんです。
ただ、調べていくと、どれもコードやデータモデルを見ないと判断できない論点ばかりだと分かった。つまり、PdMに渡しても、結局エンジニア側への確認が必要になるんですよ。「これはPdMの仕事だ」と自分で線を引いて止めていただけだな、と気づいて、それなら自分でやろう、と切り替えました。
当時は、協会けんぽ宛ての申請はe-Govでも出せた一方、健保組合宛てはマイナポータルしか選択肢がありませんでした。なので、当初はいったんマイナポータルを優先して進めていたんです。
ただ、仕様を確認するために問い合わせを重ねる中で、関係事業者向けの説明会に参加することになって。そこで健保組合宛ての手続きも今後e-Govに移行していく方針だと分かったので、e-Govを軸に進める形へ切り替えました。
──つまり、もともとは「PdMがやる仕事」だと思っていたところまで、自分で担ったと。
内藤：最初は「こっちでやった方が早い」という、実務的な理由だったんですけど、その後もいろいろな領域に染み出していく中で、だんだん「ロールって、仕事をやりやすくするためのラベルにすぎないんじゃないか」と思うようになりましたね。
大事なのはPdMというラベルそのものではなくて、そのラベルを外したときに、自分にどんな価値があるのか。エンジニアでも「何を作るか」という意思決定には関われますし、PdM側に染み出せる領域はあるんですよね。
逆に、エンジニアだからこそ持てる強みもあります。たとえば開発コストやシステム上の制約を理解した上で、意思決定を進められることもその一つです。
私自身、エンジニアリングは好きなので、今すぐPdM一本に振り切るというより、まずはAI時代のエンジニアリングをしっかり追いかけて、自分の専門性として持っておきたい。その上でPdM側にも染み出していく方が、自分がやりたいことには近いかなと思っています。
そういう意味では、今は結構おいしい立場だなと。
すべての原点は「お客様への価値提供」
──ここまで伺うと、一人ひとりの裁量も責任も大きい環境ですよね。実際に働いてみて、どうですか。
内藤：確かに自分で決めることは多いですね。何を優先するか、今回は何を見送るかまで、関係者とコミュニケーションを取りながら責任を持って進めます。
ただ、個人が抱えきれないほど負荷が積み上がる構造にはなっていないんですよね。3か月ごとにロードマップを引き直しますし、差し込みが入ったときは、その分何を見送るかもその場で決めます。品質についてもあらかじめリリース基準が決まっていて、個人の裁量や責任だけに委ねられているわけではないので、「間に合わないから雑に出す」ということも起きにくいです。
それに、そもそも自分のモチベーションって、仕事の量や難しさではなくて、やっていることに意味を感じられるかどうかで決まるんですよね。「この仕事、なんでやってるんだろう」と思いながら進むのが一番苦手で。今は、やる意味を自分で説明できる状態なので、そこで削られることがないんです。
──その「やる意味」は、どんなところに感じているんでしょうか。
内藤：まず、プロダクトそのものが面白いですね。
Dress Codeは、個別の業務SaaSをそれぞれ作るのではなく、複数の業務で共通して使える基盤を作って、その上にプロダクトを載せていく「コンパウンドSaaS」を目指しています。しかもグローバルでも使えるものにしようとしているので、考えなければいけない範囲がかなり広いんです。
そうなると、PdMはより大きな絵を描く必要があるし、個別のプロダクトに近いところは、エンジニアも自分で考えて意思決定していく。AIによって一人が担える範囲が広がる中で、エンジニア自身も一段上の仕事を持つようになっているのかなと思います。
──プロダクトの複雑さや、考える範囲の広さそのものが、仕事の面白さにもつながっているんですね。
内藤：ただ、何より大きいのは、お客様への価値提供を実感できることですね。実は、Dress Codeに転職した理由の一つも、プロダクトを通してお客様に価値を届けたいと思ったからなんです。
Dress Codeには、そこを大事にするメンバーが揃っていますし、振り返ってみると、ここまで話してきたことは、全部そこにつながっているんですよ。複数のプロダクトを技術領域をまたいで担当するのも、ロールを細かく分けないのも、必要ならPdMやQAの領域まで染み出すのも、意思決定をADRに残すのも、品質を担保しながら、お客様により良いものを、より早く届けるためですから。
しかも、そうやって作ったものに対するお客様の反応もちゃんと返ってくる。週1回、全社員でPMFに向けた戦略を話し合う場があって、そこでCSやセールスから「最近リリースしたこの機能に、こんな嬉しい声がありました」と共有してもらえます。そういう声を聞くと、やっぱりもう一段頑張ろうと思えますね。
Product & Technology テックリード 河村 勇樹と。先輩ながら、フラットに話し合える関係性。
──プロダクトや組織のユニークさに目が行きますが、その根っこにあるのは「お客様への価値提供」なんですね。
内藤：そうなんです。そこは絶対にぶらしたくないですね。
なので、今一緒に働くメンバーを募集していますが、まずはお客様への価値提供を大事にしている人に来てほしいなと。
そのために自分からいろいろな領域を見ていきたい、必要ならPdMやQAにも染み出していきたいと思える人には、かなり面白い環境だと思います。プロダクトエンジニアとして「ここまで」と決められている範囲はそんなにないので、「やりたい」と言ってもらえれば、できることはどんどん広げていけると思います。
──担える仕事の範囲は広がっても、向かう先は変わらない。AI時代のエンジニアの働き方を考えるうえで、とても示唆のあるお話でした。ありがとうございました！
（取材・文／山田 奈緒美）
