プロダクト開発の導入/開発事例や活用/成功事例について

プロダクト開発は、Webメディアなどと違い、作る前の判断が成否を左右します。市場に出したあとも検証を重ね、ユーザーに使われる形へ育てていく必要があります。

ここで取り上げるのは、導入・開発・活用・成功の一次事例です。全体像はプロダクト開発の完全ガイドもご覧ください。

UI/UX改善で売上が4,111%成長したプロダクト事例

UI/UX改善は、プロダクトの成果が数値に表れた事例です。機能を継ぎ足すうちに画面が複雑になり、ユーザーが目的を果たすまでの摩擦が増えることがあります。

機能継ぎ足しの複雑化から立て直したClickの事例

象徴的なのが、NOROSHIとMikoseaが手がけた「Click」の事例です。開発当初はエンジニア主導で機能を継ぎ足し、UXが複雑になって離脱率が悪化しました。改善では次の対応を進めています。

  • 専門家レビュー:UX上のボトルネックの洗い出し
  • プロトタイプ検証:実装の前に仮説を確かめる
  • 体験の整理:デザインシステムを使った画面の整理

改善後、売上は前年比4,111%成長しました(出典:NOROSHI×Mikosea)。成果を左右したのは、機能の多さよりも、ユーザーが迷わず目的に到達できる体験です。

発注側は、機能を盛り込めば必ず価値が上がるとは限らず、かえって離脱を招く場合もあると学べます。

伸び悩みでは、機能不足だけでなく体験の複雑さも疑います。第三者レビューとプロトタイプで反応を確かめてから実装すれば、不要な開発費を大幅に抑えられます。

成功には、機能を足すだけでなく「引き算の設計」ができるかを問うことも大切です。

プロトタイプ検証とデザインシステムが成長を支えた理由

Clickの成長を支えたのは、単発の改善よりも、検証ループを回せる仕組みです。このループを続けられるかが、長期的な成長率を左右します。

  • 仮説検証:数値の変化を基にした施策の判断
  • 共通言語:デザイナーとエンジニアが同じ部品・ルールで作る

デザインシステムにより画面ごとの体験が統一され、改善速度も上がりました。ただし、導入しただけで効果が出るとは限りません。

既存プロダクトから乖離した仕組みは運用コストを増やします。Clickでは、実態に合わせて育てたことが成功の分岐点でした。

ポイント

UI/UX改善では、機能を増やす前に、ユーザーが迷わず目的を果たせるかを専門家レビューや試作で確かめられるかが、判断の目安になります。

定量評価で開発の手戻りを削減した事例

富士通のIxD評価で示された修正調整時間と修正率の変化、被験者数を4枚のパネルで示した図。
人数を抑えた検証設計も、定量評価の効果を支えています。

プロダクト開発では、使いやすさを定量評価する取り組みが見落とされがちです。UI/UXは感覚で語られやすく、レビューで意見がぶつかることもあります。

評価を数値化すると調整が速まり、手戻りも減らせます。その効果を明確な数字で示したのが、富士通のIxD評価の事例です。

修正調整時間87%削減・修正率31→100%の富士通IxD評価

富士通のIxD評価(インタラクションデザイン評価)では、開発者との修正調整時間を87%削減しました。さらに、使いにくさに起因する問題の修正率は、31%から100%に上がっています(出典:富士通)。

  • 調整時間:評価の根拠を示し、開発者の納得を促す
  • 修正率:指摘された問題をすべて修正する状態への移行

指摘が後回しにされ、リリースまで放置されることもあります。そこで、評価を仕組み化すれば、分かっていても直さない問題を確実に解消できます。

評価の仕組み化は、品質の底上げにつながる再現性の高い成功パターンです。

被験者4人で16名分のコストを削減した検証設計

富士通はユーザーモデルマッピングを用い、被験者4人で十分な問題検出率を保ちました。その結果、本来16名で行う検証のコストを削減しています(出典:富士通)。

  • 少人数で検証:適切な設計による主要な問題の検出
  • 小さく速く改善:結果を次の判断に活かす

検証は少人数から始められるため、踏み出せずにいる事業責任者の背中を押す根拠になります。

予算が限られていても、要点を押さえたテストは、机上の議論より判断の精度を高めます。特に初期段階では、完璧さよりも検証を繰り返すことに価値があります。

ポイント

定量評価では、時間と修正率のように数値で示せる指標を持ち、評価を仕組みとして回せるかが、手戻りを減らせるかを見極める材料になります。

稼働中システムを止めずに改修したプロダクト事例

MICINが稼働中システムのデータベース構造を変更した4段階を、順に並べた流れ図。
新旧テーブルを並行させ、参照先を段階的に切り替えます。

プロダクト開発はリリースで終わらず、その後の改修に技術的な難所が集中します。そのため、無停止改修の事例は、運用中のプロダクトを抱える企業に実践的な学びをもたらします。

MICINの無停止DB構造変更4段階の事例

MICINは、稼働中の受付システムに時間帯予約を追加する際、障害ゼロでデータベース構造を変更しました(出典:MICIN)。中間テーブルと専用テーブルにデータを分け、次の4段階で移行しています。

  1. 新規テーブルを作成し、データを同期する。
  2. 参照先を新しいテーブルへ移行する。
  3. スキーマキャッシュを無効化するため、ignored_columnsを設定する。
  4. 不要になったカラムを削除する。

段階的な切り替えにより、ユーザーが利用中でもサービスを止めずにテーブル構造を変更できました。本番テーブルを一度に書き換えず、新旧を並行させる設計が重要です。

新規開発より稼働中システムの改修は難しく、特にDB変更はデータ消失や停止につながるおそれがあります。無停止移行を設計できるパートナーが、運用時の安心感を左右します。

運用フェーズの技術実装が事業継続を支える事例

MICINの無停止移行は、技術の見せ場というより、事業を止めないための取り組みです。停止中はユーザーが使えず、機会損失や信頼低下につながります。

医療や予約のように毎日稼働するプロダクトでは、メンテナンス停止も許されない場面があります。

  • 要件定義:リリース後の改修方針の話し合い
  • パートナー選定:運用中の無停止改修まで見据えた設計の確認

無停止で改修できる技術力は、事業の継続に直結します。初期構築だけでなく、運用時のリスクも見積りや要件定義の段階で見ておく必要があります。

運用を見据えた設計は、長期的なTCO(総保有コスト)を抑えることにつながります。また、riplaはフルスクラッチ受託と国内開発の立場から、運用しながら育てる設計を重視しています。

ポイント

稼働中のシステムを改修するときは、本番の表を一度に書き換えず、新旧を並行させて切り替えられるかが、事業を止めないための判断の目安になります。

失敗から軌道修正したプロダクト開発事例

現場の実装や既存プロダクトへの適合、部品やルールの育成、役割の再定義を確認項目として並べた図。
仕組みの導入と分業の両面に、見直しの観点があります。

事例の価値は、華やかな成功談だけでなく、失敗の理由や立て直し方を知れることにもあります。発注側は、現場のリアルな経験から、同じ失敗を避ける判断を学べます。

プロダクト開発の失敗は、技術力より組織や意思決定、進め方に起因することが多くあります。

デザインシステムが使われなくなったニジボックスの事例

ニジボックスの事例からは、導入する技術や仕組みが現場の実装と既存プロダクトに合うかを見極める必要があると分かります(出典:ニジボックス)。

  • ツール先行:Tailwind CSSやFlowbiteが実装要件と合わず、連携に失敗
  • 他社模倣:自社プロダクトと乖離し、運用コストが増えて使われなくなった

流行ツールを導入すること自体が目的になると、現場の作り方に合わず、開発の足かせになります。他社の完成形を持ち込むことも、運用の負担につながります。

そこで、既存プロダクトを観察し、繰り返し使う部品やルールを抽出して育てることが大切です。

Clickは自社に合わせたデザインシステムで成長しました。一方、ニジボックスは中身より器を先に整えたため、自社の実態と噛み合わず、使われなくなりました。

過剰オーナーシップが分業を壊した事例と立て直し

「UXの電球」では、あるデザイナーが強いオーナーシップで仕事を抱えました(出典:UXの電球)。

  • 抱え込み:明示的なリーダーの形骸化と分業の崩れ
  • 役割の再定義:責任の境界の明確化と、一人に依存しない体制への復帰
  • 目的の共有:リサーチ・デザイン・実装を分け、定期的に目的を確かめる

半年間UI実装に没頭した結果、本人は本業のUXリサーチから離れました。「誰のどんな課題を解決するか」を見失い、最終的にバーンアウトに至っています。

優秀な個人の頑張りで一時的に進んでも、その人に頼る状態は長く続きません。そのため、技術や予算よりも、役割と責任を見直すことが回復につながります。

失敗・リスクの全体像は、『プロダクト開発開発/導入の失敗/課題/注意点/リスクについて』もご覧ください。

ポイント

失敗から立て直す事例では、導入する技術が自社の実態に合うかと、一人に頼らず役割を分けられるかを要件を決める前に見ておくことが判断の材料になります。

まとめ

成功も失敗からの回復も、作る前の検証、作った後の計測、個人ではなく組織で育てることに行き着きます。

たとえば、Clickは前年比4,111%の成長を遂げ、富士通は修正調整時間を87%削減しました。

富士通は被験者4人で検証コストを抑え、MICINは4段階の移行で稼働中のシステムを改修しました。一方、ニジボックスと過剰オーナーシップの事例は、進め方の失敗を示しています。

事例を読むときは、機能よりも「なぜユーザーに使われたか」を見ます。自社の実態に照らし、引き算の設計と小さな検証から始めましょう。

riplaはフルスクラッチ受託と国内開発を組み合わせ、検証を前提とした要件整理と、運用しながら育てるプロダクトづくりを支援します。全体像は完全ガイドをご覧ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。