ビジネスとデザインとエンジニアリングを繋ぐために 一人のエンジニアは何ができるか osuzu デザインエンジニアMeetup @20250425 

自己紹介 osuzu ● SWE @株式会社カミナシ ● ex. 千葉大学デザイン学科 → 株式会社LIFULL → atama plus株式会社 @suzu415 

はじめに 学生時代にデザインを学んでいたこともあり、ずっとWebフロントエンド畑 でエンジニアのキャリアを重ねてきました。 過去に何度かUXエンジニアやデザインエンジニアといったロールで仕事をし たいと考えた時期もありました。 ですが前職と現職をSaaSのスタートアップで過ごすことで ● 0→1のプロダクトが売れて誰かの役に立った喜び ● ゼロから立ち上がったチームが機能していく喜び ● 戦略と現実のギャップでプロダクト開発がストップし、大好きだった チームを丸ごと失うことになった悲しみ などを経験し、少し考え方が変わってきた話を今日はしたいと思います。 

SaaSのスタートアップがひとつのプロダクトを作るまで 組織戦略 事業戦略 機能戦術 責務 どこで戦うか なにで戦うか どうやって戦うか プレイヤー 経営, Manager BizDev, Sales, PMM PdM, Eng, Des, CS/SP 形式的な概念図はこんな感じ。 現実には色んな戦い方があると思います。 Discoveryとして PMとDesで活動する 創業期のスタートアップCEOがSalesやPdMも兼ねる 事業開発として SalesとPdMが協業する Engは仕様通り コード書くだけ 

私の価値観について プロダクト作りに銀の弾丸はないと思いますが、私自身は以下のような価値 観を良いものと捉えています。 ● 責務において意思決定は大切だが、検証することも大切。 ● 戦略と戦術とその実行のフィードバックループがちゃんと回っているこ とを重視している。チームが学習していくことを良しとする。 

これまで経験や見聞きした 失敗のパターン 

失敗のパターン：組織に溝が生まれている ● 戦略から実行の連携に溝がある ○ 実行に関心が薄い（検証しない）BizDev ○ 事業戦略やGoToMarketに関心が薄いプロダクトチーム ○ Salesの顧客への機能開発コミットメントにより、プロダクトチーム の開発優先度が万年ロックされている ● ディスカバリーからデリバリーに溝がある ○ この分断がデザイナーとエンジニアといった職種間で起こるのは、 プロダクトチームにオーナーシップがなくなっている兆候 ○ ほとんどウォーターフォール開発なのに、アジャイル開発を現場の 働き方だけで取り繕ったり… ● SalesやBizDevが経営の戦略にアラインしていない ○ この間で溝が生まれているとその先も大体ダメになる 

溝を超えて成功するために カミナシの例を添えて 

溝を超えて成功するために：イネーブリング ● 経営が毎週の会議を伝わりやすい形でまとめ発信する ○ カミナシで行われている取り組みの一つですがとても良いです。 公開で終わらずに届けるところまでオーナーシップを感じます。 ● デザイナーやデザインエンジニアがFigmaにこだわって運用する ○ デザインシステムやコンポーネントカタログも こうした取り組みの一種と言えそうです。 ■ 弊社のデザインエンジニアの取り組みの例です。 Figmaでモックやプロトタイプを作りやすい仕組みを整備 ○ 今だとMCPやv0連携で全社員がプロト作れるようにもできる時代！ ● エンジニアが生のデータにアクセスできるよう届ける ○ 前職では毎日データファクトを届ける狂気（もちろん良い意味で） の発信を続けた人がおり、経営の意思決定を変えていました。 ○ 今なら単純にMCPつなげ自然言語でクエリできるようにするとかも 

溝を超えて成功するために：コラボレーション みんなで現場に行くこと プロダクトを作っていくエンジニアやデザイナーにとって、 これは売れそう（現場の役に立てそう）という肌感をもって作ることが、 要らないものを作らないためにも、本当に価値があると感じています。 カミナシでは、職種に限らず現場の一次情報を得る ことを大切にしており、 エンジニアがSalesやCSと一緒に現場訪問する機会も 度々あります。 現場へ行くたびこれを実感します… 

溝を超えて成功するために：コラボレーション 職種をまたぎドメインモデリングを行うこと カミナシにとってドメインモデリングとは、 現場の課題解決と、実現（現仕様の制約やデータベースの制約）との 間の溝に橋をかけることです。 同僚の記事もオススメです 

溝を超えて成功するために：コラボレーション ディスカバリーやGTM検討にエンジニアとして影響力をもつこと ここはプロトタイピング力や多職種をまたぐ専門性を通して、 デザインエンジニアが影響力を持てる領域だと考えています。 必ずしもリードする必要はなく、 責任を持つ人（多くはPdMやPMM）が「売れる」「撤退する」といった意思 決定を素早く、自身をもって実行できるように支援すること。 そしてディスカバリーを通して得られた学びを、作るところにまで一貫して 持ち帰れるはずです。 

溝を超えて成功するために：補足 イネーブリングやコラボレーションすることは、合議で決めることを推奨し たり、人の専門性を超え意見することを推奨するものではありません。 むしろ意思決定においてはちゃんと説明責任を果たす人を決め、その人が リードすべきと考えています。（権限移譲は必要だとも思いますが） 意思決定の速度や精度を上げるために、集合知で助けあうことを意図してい ます。（一人のエンジニアが果たせる役割はたくさんあるはず！） とはいえ、信じて任せることと無関心/無責任でいることとの間のバランスは 私もずっと悩んでいるテーマの一つです。。 

溝を超えて成功するために：補足 もっとシンプルに… 良いUIを作るのは、デザイナーとエンジニアがどれだけコミュニケーション したかにかかっていますし、 良い戦術を作るのは、経営やBizDevやSales、現場でプロダクトを使う顧客、 そしてプロダクトチームがどれだけコミュニケーションしたかにかかってい ると思います。※ここでのコミュニケーションとは同期で言葉を交わすことに限りません 泥臭いコミュニケーションをサボらないこと。凡事徹底。 SaaSを作る世界では、たった一つのコミュニケーションが成否を分ける場面 がたくさんあると感じています。 

デザインエンジニアから スタッフエンジニアへ 

デザインエンジニアからスタッフエンジニアへ 自身のバックグラウンドから、デザインとエンジニアリング両方への影響力 を発揮するため、デザインエンジニアになりたかった時期がありました。 とはいえ「デザインエンジニア」という職種は少なくとも国内で一般的では なく、採用やキャリアラダー面で課題があります。（私個人としてデザイン エンジニア職種の採用は増えてほしいと思いますが） ただし今は、スタートアップでプロダクトやその先のビジネスの成否に向き 合うなかで違った考えももっています。 大切なのは肩書きでなく何を為すかであって、そのオポチュニティは至ると ころにあったと気づいたのです。 キャリアの登り方は違えど、シニアやその先のスタッフロールで期待される バリューは同じなのではと。※ハイパースペシャリストとしてのキャリアは除く 

デザインエンジニアからスタッフエンジニアへ デザインエンジニアに期待されるレイヤーごとの役割イメージ デザインとエンジニアリング両方 に専門性を発揮し、 プロトタイピングでDiscoveryと Deliveryを繋ぎ、 失敗に陥りやすい組織の溝に橋を かける力が、きっとデザインエン ジニアにはあるはずです。 デザイン エンジニ アリング ミドル ディス カバリー デリバ リー シニア 戦略 戦術 スタッフプラス 溝に橋をかける 

さいごに 私自身、まだまだスタッフを名乗れるレベルに達してない中で恐縮ですが、 さいごに書籍「スタッフエンジニアの道」より好きな一節を紹介します。 「でも、取り組むべきインパクトのある仕事が積まれた魔法のバックロ グはどこにあるのでしょうか？」
 
 「あなたが創り出すのです！ 」
 
 
 『スタッフエンジニアの道』
 

AD カミナシの採用情報です