「受託開発感」を軽減するためにデザイナーができることは何か？

この記事は mikan Advent Calendar 2025 - Adventar 22日目の記事です。
昨日は同じデザインチームメンバーyukko さんの「イラストレーターからデザイナーになった私視点の、mikanでデザインする面白さ」でした。

はじめに

こんにちは👋
mikanでデザイナーをしているナガタキ（@ayataki168）です🍊
今年の10月末で一人目のデザイナーとして入社してから丸4年が経ち、5年目に突入しました。時の流れが早い！

さて、今回はちょっとPM・デザイナーには苦いお話…
「受託開発感」について触れてみたいと思います。

あくまでトライ中のものとして書くのではっきりした正解があるタイプの内容ではないのですが、その分リアルかもしれません。

「受託開発感がある」

開発チームから、今年のある振り返り会でこんな声が上がりました。

実は初めてじゃないのです。
過去にもそんな声が上がり、開発共有のタイミングを増やしてみるなどの試みをしていた経緯がありました。
なので私はこの意見を聞いた時に、

• 「結構こまめに共有して巻き込んでるのにな」というショックな気持ち

• 「一緒に作れていない感があって寂しいのかな」という理解したい気持ち

• 「全員で納得いくように進めようとすると合意形成が遅れないかな」という不安な気持ち

の3つが混在してザワザワしました。

単純に人数が増えたこともありますし、なるべく早くリリースしたい意向もあり、ウォーターフォール気味の体制になっているのは確かでした。
ただし事業スピードを一番に考えた時には、ウォーターフォールは良い側面もあります。
なので一概に「ウォーターフォールが悪いこと」とは考えていません。

「受託開発感」は課題なのか？

では「受託開発感」は本当に課題なのでしょうか？
組織によってはYesにもNoにもなるかと思います。

mikanの場合は、少なくとも自分はYesかなと判断しました。
理由は、「一緒に作る」空気感は私も大好きだから。
mikanはプロダクトへの熱量が高いメンバーが多いので、チームのコミュニケーションの取りやすさにも繋がると思いました。

ただ、私たちがユーザーの学習体験を1日でも早くよくするために動いているという共通の目的を見失わないようにはしたいですね。

一体感のある動きでリリースのスピードも上げられたらベストです。
そのちょうどいいバランスを探していこうじゃありませんか🔥

巻き込んでいるつもりなのに、参加している実感を持てないのはなぜか？

さて、まず原因究明なわけですが、うまくいかなかった開発チームとの合流地点を振り返ると、共通していたのはこの状態でした。

この持っていき方だと、

• もう大枠は決まっている

• 選択肢が少ない

• 今さら言っても変わらなそう

という空気が生まれやすく、開発チームは実現可否の判断役に回りがちでした。

手応えがあったこと①「あえて"中途半端な共有"をする」

今年の9月ごろからはモバイルチーム（PM・デザイン・バックエンド・iOS・Android・QA）合同でのスクラムが本格的に始まる動きがあり、合流の構造そのものに変化が出てきています。

その流れで、週に1回は合同のリファインメント（見積もり会）が行われるようになりました。
最初は「見積もれる対象を持っていく場」だと考えていたのですが、何度かの振り返りを経て、実際には考え途中のものも共有した方がよさそうという感触が出てきました。

これまでは、PM・デザインの中である程度まとめてから「これなら良さそう」と思えるタイミングで都度ミーティングをセットするというやり方をしていました。

しかしPM・デザイナーで考え切ってから共有しようとすればするほど、開発チームとのミーティングは「解像度を上げてもらうこと」がメインになりますし、発言がほとんど上がってこない状態になりがちです。
「まだ中途半端…」と思っているくらいのタイミングの方が、開発チームにとってはいい意味で余白があって、発言が活発に感じられました。

ただ、持っていく側としてはどうしても意図的には区切りを決めづらいので、こういう時に定期予定はありがたいですね。笑

手応えがあったこと②「小さく渡す」

もう一つ変化があったのが、「小さく渡す」動きです。
以前は、

• 手戻りを避けたい

• 開発効率を落としたくない

という理由から、「これならもう変わらない」というタイミングまで待って、要件整理会では完成形に近いものを持って行って説明していました。
これはこれで正解だったと思っています。

ただ、ここにも開発チームが「作るだけの人」になりやすい一端がありました。

スクラム導入時に懸念をすり合わせたうえで、開発チームから「手戻りは厭わない」という言葉をもらえたので、状況に応じて小出しで渡すやり方を試し始めました。
例えば「ワイヤーフレームだけ先に渡す」、「データ設計に必要な材料だけ渡す」など。

結果についてはカッコつけたいところですが…
正直早すぎてトラブルになっていることもあります😂笑

それでも、開発チームの合流を多少強引に早くして並行して進めてもらうことで、スプリントレビュー（成果物の共有会）の時にみんなで動くものを早く見れたり、認識合わせの機会が早めにできたりするので、半年前と少し違う景色を見ているなと思います。

良い合流地点はどこか？

これまでの失敗とトライを踏まえて、「じゃあどこで開発が合流するのが良さそうなのか？」を自分なりに整理してみました。
あくまでまだ仮説ですが、現状だと以下の4段階くらいで考えておくといいのかなという所感です。

特に2・3の工程は、1回でやるより、少しずつタイムラグなく解像度を上げていく形式の方が、「みんなで作っている感」は生まれやすいです。

場合によっては開発チームに先行して実装イメージを膨らませてもらうことで、2・3の行き来を先に解像度高く持ってもらうこともできますし、気づいていなかった新たな選択肢や懸念に早く気づける可能性もあります。

ただし前述したように2・3を早めたことで混乱を生み、トラブルになるケースもあります。
例えば「早く共有して進めてもらったが、デザイン変更がありデータ設計もやり直しになってしまった」というような事象ですね。
もちろんある程度手戻りがあるかもしれないことを承知してくれてはいても、根幹のものであればあるほど影響範囲が大きく後から動かしづらくなってしまうので、変更はないに越したことはない…といったものです。

そういったトラブルを回避するためのポイントとしては、「PMやデザイナーが開発チームの動き出し内容とタイミングを決めないこと」が大事そうです。
本当に動けるタイミングかどうか、その材料が揃ってるのかは開発チームにしかわからない時があるからです。

「こまめに共有する中で、いつ何を着手するかは開発陣に決めてもらう」くらいが今のところちょうどいいのかなーと💭

とはいえまだ仮説なので、引き続きより良い形を見つけていきたいなと思ってます💪

おわりに

試行錯誤中の内容でしたが、同じような悩みを持つ方のヒントになれば幸いです。
mikanではそんなプロダクト愛の強い開発チームに参加して、一緒に学習体験を良くしていくデザインマネージャー・バックエンドエンジニアを大募集中です。
気になる方はぜひカジュアル面談でお話しましょう！