プレセナ・ストラテジック・パートナーズ Advent Calendar 2025 6日目です
こんにちは、プレセナでe-Learningシステム（PLS）のリニューアルを担当しているKubotaです。
みなさんは、普段「デザインレビュー」にどのくらい深く関わっていますか？ 要件定義や設計には参加しても、デザインに関しては「見た目はデザイナーの専門領域だから」と、一歩引いてしまうエンジニアも少なくないと思います。
しかし、今回のリニューアルプロジェクトを主導する中で、私はその考えを改めました。 特に、既存のシステムを作り直す「リニューアル」においては、エンジニアがデザインの決定プロセスに早期に関わることが、プロジェクトの成功に直結すると痛感したからです。
本記事では、デザインレビューの現場でよくある実例をもとに、なぜエンジニアがデザインレビューに積極的に参加すべきなのか、その理由についてお話しします。
1. PLSリニューアルについて
まず、私たちが取り組んでいる「PLSリニューアルプロジェクト」の背景について少し触れておきます。
今回のリニューアルの最大の目的は、サービスの競争力を取り戻すことです。 長年の運用を経て、既存のデザインは徐々に古くなり、競合優位性が低下していました。そこで、段階的なデザイン移行による全面刷新を進めています。
リニューアルだからこそ生まれる「制約」
新規開発と異なり、リニューアルには常に「既存の資産」という制約がつきまといます。
- 変えるのが難しい既存のデータベース構造
- 長年積み重なった複雑なビジネスロジック
- 「なぜ今の仕様になっているのか」という過去の経緯
これらは一見、デザインの自由度を奪う邪魔なものに見えるかもしれません。しかし、こうしたシステムの裏側や過去の経緯（ドメイン知識）を把握しているエンジニアの視点を加えることで、よりスムーズに解決策を見つけられることもあります。
表面的なデザイン変更だけで進めようとすると、裏側のロジックと矛盾が生じ、必ずどこかで破綻します。だからこそ、この「制約」を知るエンジニアが、初期段階から関わる必要があるのです。
2. デザインフローとレビュー体制
私たちのチームでは、Figmaを中心とした開発フローを採用しています。 WF（ワイヤーフレーム）で構成を決め、その後に詳細なカンプを作成するという流れです。
具体的なレビュー体制としては、一度で全員の合意を取るのではなく、明確に2つのステップに分けて実施しています。
Step 1：開発チーム内（エンジニア × デザイナー）での検討
まず、作り手であるデザイナーとエンジニアだけでレビューを行います。 ここでは、技術的な実現可能性、データ構造との整合性、UIの状態など、実装を見据えた詳細なすり合わせを行います。
Step 2：ステークホルダーを含めた検討
Step 1で開発チーム内の合意が取れた後、ステークホルダーや事業責任者を交えてレビューを行います。 ここでは、ビジネス要件を満たしているか、スコープが適切かといった観点で最終決定を行います。
いずれのステップも、参加者がZoomなどを繋ぎ、Figmaの画面を一緒に見ながら議論する時間を設けています。 テキストだけでは伝わりにくいニュアンスや、その場でのアイデア出しを大切にしているためです。
3. デザインレビューでの「あるある」と「アプローチ」
では、実際に私たちがFigmaを見ながらのオンライン通話でどのような議論をしているのか。 エンジニアがデザインレビューに参加する際、特によく遭遇するケースと、私たちが実践しているアプローチをご紹介します。
① 今のデータ構造で、それは実現できるか？
- あるある： 「前回ユーザーが閲覧した時点からの差分を表示したい」「ここに正答率を表示したい」といった一見簡単そうな要望。でも、実はそもそもデータを持っていなかったりするケース。
- アプローチ： ここでデータ構造を理解したエンジニアが「それを実現するにはDB改修が必要で、工数がこれくらい増えますがどうしましょう？」と相談します。「それなら、代わりに既存APIで取れるこのデータを使うのは？」と、実装コストを抑えつつ目的を達成できる代替案を一緒に探します。
② パターンの抜け漏れはないか？
Figma上では、主要な画面デザインは作られていても、条件によって発生する派生パターンが抜け落ちていることがあります。
- あるある： 検索結果が「ある」状態のデザインしかない。
- アプローチ： エンジニアは条件分岐のプロとして、「検索結果が0件の時はどう表示しましょうか？」「エラーが出た時の表示はどうしましょう？」といった「状態（State）」について質問します。早期に確認することで、実装直前になって「画面がない」と慌てる事態を防ぎます。
③ 「ハッピーパス」だけでUXを判断していないか？
Figmaにある「理想的なデータが入ったきれいな状態（ハッピーパス）」だけを見て、「使いやすい」と判断してしまうことへの懸念です。
- あるある： ダミーテキストが1行でスッキリ収まっていて見やすい。しかし、実際の本番データは文字数が多く、情報が探しにくかったりする。反対に本番データは想定しているより文字数が少なかったりする。
- アプローチ： 「本番データの9割は3行以上になるので、このUIだと一覧性が低く、使い勝手が悪くなる可能性があります」と指摘します。現実的なデータ量に基づいたUIに修正することで、「見た目はいいけど使いにくい」というUXの乖離を防ぎます。
④ 実装コストと効果のトレードオフ
デザインの実現にかかる工数を正しく伝え、チームとして費用対効果を判断します。
- あるある： こだわりの独自UIコンポーネントや、複雑なアニメーション。
- アプローチ： そのこだわりを尊重しつつ、「標準コンポーネントなら1時間ですが、独自実装だと3日かかります」と選択肢を提示します。「それなら標準でOK」「ここは重要だから時間をかけてでもやる」と、デザイナーが適切な判断を下せる材料を提供します。
⑤ それは「こだわり」か？「偶然」か？
エンジニアが勝手に「デザインの意図」を深読みしすぎてしまうケースです。
- あるある： 微妙に特殊な余白やフォントサイズ。エンジニアが「デザイナーの意図があるはずだ」と苦労して再現しようとするが、実は単なるドラッグミスだった。
- アプローチ： 実装する前に「これって意図的な指定ですか？」と軽く確認します。聞いてみると「あ、ごめん。手が滑っただけ。標準でいいよ」となることも多く、お互いの無駄な作業を減らすことができます。
4. まとめ
今回、リニューアルプロジェクトを通じて改めて感じたのは、「エンジニアがデザイン段階から関わることのメリットは想像以上に大きい」ということです。
振り返ると、具体的には以下の4点が大きな成果だったと感じています。
- 実現可否を早期に判断できる（手戻りの最小化）
- 要件漏れ・エッジケースを防げる（品質の向上）
- 開発工数の温度感を擦り合わせられる（ROIの最大化）
- ユーザー視点（本番データ）を取り入れられる（UXの現実化）
実際、早い段階ですり合わせをおこなうことで、「あ、これ今のDBだと重くなるかも」「このパターン、抜けてそうだな」と一言声をかけるだけで、その後の開発が驚くほどスムーズになることを改めて実感しました。
これからの展望
今はエンジニアが知識を補うことでうまくいっていますが、本来は職種を問わず、チーム全員がシステムの特性を理解しているのが理想です。 これからは、エンジニアの頭の中にあるドメイン知識をもっとオープンに共有して、チーム全体の視座を揃えていくことにも力を入れていきたいです。
新しい技術も柔軟に取り入れつつ、チーム全員で「良いサービス」を作っていけたらと思います。
