株式会社estie・デザインエンジニアのkkaruです。
先日、社内で「タッグ開発 Night」なるイベントを開催しました。
事業開発やCS、営業などに携わる面々がソフトウェアエンジニア（以下SWE）とタッグを組み、日ごろ取り扱うプロダクトの機能を自ら追加・改善する企画です。
計13組に参加いただき、大大大好評でした。
ちなみに "タッグ" といえば……サトシとピカチュウじゃないですか ฅ(◍◕ܫ◕◍)⚡️
ポケモン 30周年おめでとうございます！
課題感
商談やサポート対応を通じて、顧客の声（以下VoC）を集めているビジネス職のメンバー。
その知見は日々プロダクトに活きています。
ただ、たとえ小さな改善でも、提供するまでに SWE の手を借りる必要がありました。
つまり SWE だけが実装を担う体制では、打ち手の数がどうしても限られる……。
AI Coding Agent の登場で、この前提が変わりつつありますよね。
VoC に最も近いひとが自らプロダクトに手を入れられるようになれば、仮説検証のサイクルは何倍も速くなるのでは？
そう考えて「タッグ開発 Night」を企画しました。
なぜ「タッグ」なのか
目的
たとえば以下のことを期待しました。
- ビジネス職のメンバーが VoC を起点に、自らプロダクトを改善できるようになること
- その視点を Pull Request（以下PR） として受け取れるようになり、プロダクト改善の方向がいっそう鮮明・多角的になること
- 非エンジニアが実装上の制約を肌で感じることで、仕様策定の質が上がること
Pull Request
プル要求は、コードの変更をプロジェクトにマージするための提案です。 pull request は GitHubの基本的な コラボレーション機能であり、変更をマージする前にディスカッションとレビューを行うことができます。 これにより、チームは共同作業を行い、問題を早期にキャッチし、コードの品質を維持できます。
（pull requests について - GitHub ドキュメントから引用）
タッグ制と役割分担
主役は非エンジニアの皆さんです。
AI Coding Agent を使ってコードを書き、PR を出すところまでやります。
SWE は伴走し、質問へ回答したり安全面に助言したりするのみで、手を動かすのはあくまで非エンジニア側というのがこのイベントの肝です。
（え、ビジネス職のメンバー x SWE x AI で “トリオ” じゃないかって？……トリプルバトルだ！）
ルール
簡易なまとめです。
- 題材：依存が少なく、失敗しても影響が限定的なもの
- アウトプット：1つ以上の PR + 動作確認用 URL + 口頭紹介（3分）
- 開発時間：55分（短いですが、スコープを小さく切る強制力として機能しました）
- 安全策：イベント中のマージは禁止。後日レビューを通してから判断すること
当日の様子
2月のある夜、会場に13組の参加者が集まりました。
簡単に説明を済ませて、各タッグはひたすら開発に挑みます。
途中いろいろな方に状況を聞いて回りましたが、誰もが楽しそう！！
レスポンスを待つあいだに、複数の VoC を並行して解いていく方も少なくありません。
開発後には、それぞれの成果を紹介。
実用的な改善から新サービスの試作まで幅広く、大いに盛り上がりました。
成果
PR の実績
翌朝、私はこんな投稿をしました。
PR はあくまでリクエスト。
それでも、複数のプロダクトにまたがり10件以上がマージされました！
いずれも日常的な VoC に根ざした改善です。
- 並び替え・フィルターの追加
- PDF出力の調整
- UI の折りたたみ対応 など
一方、すぐにはマージできなかったものもあります。
たとえば金額を扱う機能のように、十分なロジック検証が求められるケースです。
ただ、それらも開発チームが VoC として受け取り、継続的に対応を進めています。
またプロダクト群への PR だけでなく、社内業務を効率化する Chrome 拡張が2つ生まれました。
反響
イベント後の社内 Slack を見ると、「やってよかったなぁ〜」と感じる声が多くありました。
いくつかご紹介します。
とある BizDev メンバーの変化
実はこの企画の原動力になった存在として、上述のAさんがいます。
過去、ともに働くなかで「もっと力になれたら」と悔しく思うできごとがありました。
だからいまチームが分かれても背中を押したい、そんな思いが出発点でした（自分の仕事を減らしたいのもある🤫笑）。
Aさんは近ごろ、AI を使ってデザインモックを作ったり DB スキーマを定義したりしているようです。
イベント当日だけで終わらせず、要件の確からしさを自らの手で検証するところまで踏み込んでいて本当にすごい！
僭越ながら、とても嬉しく思っています。
作るひとが増えた先で、技術の深さが問われる
ここで少し視点を変えます〜！
作るひとが増えるほどリスクも比例するでしょう。
- 情報構造に矛盾が生まれたり
- 操作やふるまいの関係性がページ間で破綻したり
今回のイベントでも、開閉 UI のトグルが反転している PR がありました。
これ自体はすごく些細ですが、ちりも積もれば山となります（レビューを AI だけで済ませるなら特に）。
画面や機能をいくら実装しても、ユーザーに情報を届ける土台／界面を損なえばプロダクトの価値は高まりません。
ガードレールを設けたうえで、マルチプロダクトゆえの価値を増幅すること。
デザインエンジニアとしての、私の責務（矜持）はここにあると思っています。
estie はプロダクト数が多く、共通化と個別最適のバランスが難しいのですが、デザイン基盤を築き上げて1人ひとりの打ち手の質＆速度をブーストしたい！
たとえば（UIの）デザインパターン整備に取り組んでいます。
Atom Components や Design Tokens といった基礎的なレイヤーはすでにあるものの、それだけでは足りない……。
自社プロダクト固有のユースケースを含んだ "カタログ" が必要で、Molecules 単位でのパターン化を始めました。
これまで得た知見とアウトプットを資産化し、組織で運用・ドメインに集中できるようにすることが狙いです。
もしもこの先、旧来の UI の存在価値が揺らいだとしても、小さな単位なら再利用性を失いづらいはず。
上記はデザイン分野の例ですが、estie にはエンジニアリングのおもしろい課題もたくさんあります！
おわりに
「タッグ開発 Night」はたった一夜のイベントでしたが、開発プロセスや社内コミュニケーションを変えるきっかけとなりました。
もともと estie には職種を越えて協業する風土がありましたが、その可能性はさらに広がりそうです。
興味を持っていただけた方、ぜひお声がけください！
