
【暗号資産ウォレットを"使いやすく"改善】
Web3の純度より「使いやすさ」をコアに、導入を増やしたプロダクト設計事例
「新しい技術を使って、何か面白いことをやろう」 ブロックチェーンやAIといった先端領域のプロジェクトにおいて、この"技術起点"の思考こそが落とし穴になることがあります。技術が目的化した結果、生まれたのは"使いこなせない"プロダクト……。 そんなWeb3業界特有のジレンマを、徹底した「ユーザー視点」と「現場主義」で突破したのが、BizPMとして活躍するMiuraさんです。今回ご紹介するのは、暗号資産ウォレットの「使いにくさ」という普及の壁に向き合い、ユーザーと導入側の両面から設計を見直すことで、導入につながる形へ整えていったプロダクト設計の舞台裏です。
こんな方に読んでほしい記事です
- 新規事業責任者/プロダクト責任者(新技術を扱うが、使われる形まで落とし込みたい)
- 導入先の開発チーム(組み込みやすさ・運用しやすさが重要)
- 経営・事業企画("新技術を使うこと"が目的化して迷走しがちな状況を止めたい)
1. 本事例の背景(相談の入口)・課題

ブロックチェーンやAIといった先端領域の開発現場では、往々にして「新技術の活用」そのものが目的化しがちです。その結果、最新技術を積み上げながらも「誰も使わない」プロダクトが生まれる。この本末転倒な構造こそが、事業における最大のリスクでした。
今回の対象は、暗号資産の入り口となる「ウォレット」です。管理者を介さない自由な資産運用を可能にする一方、自己管理ゆえに「一度紛失すれば二度と取り戻せない」という極めて高いハードルがありました。技術としては最先端でも、一般ユーザーにとってはあまりに不親切。この"理想と現実のギャップ"が、普及を阻む最大の壁となっていたのです。
2. ゴール(何を"できる状態"にするか)
プロジェクトの起点として定義したのは、「技術的な新規性」ではなく、「ユーザーが迷わず使えること」をコアバリューに据えることでした。Web3の文脈では「Web2的なUXは忌避される」という風潮もあります。しかし、本プロジェクトではあえて"思想の純度"よりも"圧倒的な利便性"を優先。ブロックチェーンの知識がない人でも、無意識のうちに入口に立てる体験を要件として具体化しました。
「何を作るか」の基準は、理想論ではなく、普及の障壁となっている「負の体験」からの逆算です。議論が迷走しそうになるたび、私は繰り返し「結局、誰がどこでつまずくのか?」という問いに立ち戻り、設計の軸を固めていきました。
3. 進め方(アプローチ)
3-1. 技術起点の思考を「ユーザー課題」へ引き戻す

検討の出発点は常に「新技術」でしたが、私たちは定期的に原点へ立ち返る時間を設けました。「結局、お客様は何を求めているのか?」「この技術はどんな課題を解決しているのか?」。目的と手段が入れ替わる「技術の独り歩き」を防ぐためです。"誰が、どこでつまずいているか"を起点に据え直し、普及のボトルネックを「ウォレット体験そのもの」として定義し直す。この徹底した課題への執着が、全体の設計思想の柱となりました。
3-2. "一般層が使える入口"を仕様に落とし込む
一般ユーザーが離脱するのは、思想への不満ではなく「体験のストレス」です。そこで、例えばLINEログインを導入するなど、入り口の心理的・操作的ハードルを極限まで下げました。「Web3の知識がなくても使えること」を要件の最優先事項に据えた結果、一般層向けにブロックチェーンサービスを展開したい企業から、「これなら導入できる」という確かな支持を得ることができました。
3-3. "導入側(エンジニア)"の成功確率を要件に組み込む
プロダクトの成否を分けるもう一つの鍵は、導入企業のエンジニアが抱く「体験」でした。エンドユーザーにとって使いやすくても、実装するエンジニアにとって工数がかかる仕様であれば、検討は「後回し」にされ、結局は普及しません。そのため、SDK(開発者キット)の整備や導入支援の充実を重要な要件と位置づけました。エンドユーザーと導入企業の双方にとって「使われる確率」を最大化する設計を取り入れたのです。
3-4. 優先順位は"机上"で決めず、現場の声で更新し続ける
プロダクト開発において、「ユーザー向け機能」と「開発者向けSDK」のどちらにリソースを割くかは、常に難しい判断を迫られます。Miuraさんはこの判断をデスクの上だけで完結させませんでした。自ら営業現場に深く入り込み、リアルタイムの案件状況や顧客の懸念を直接回収。その一次情報をもとに、プロダクトバックログ(優先順位)をダイナミックに更新し続けました。固定観念に縛られず、"今の現実"に合わせて意思決定を下す運用が、プロジェクトを前進させるエンジンとなりました。
4. 工夫した点・意識した点
4-1. 「誰が、いつ、どこでつまずくか」――徹底したWhoの解像度
利用者像を「一般ユーザー」という曖昧な言葉で終わらせず、どんな人が、どんな状況で、どの瞬間にストレスを感じるのか。その一歩踏み込んだ具体化に徹底的にこだわりました。ターゲットの解像度が極限まで高まったことで、実装すべき体験の優先順位が自ずと明確になり、開発過程で仕様がブレることを防げました。
4-2. 「Web3の純度」よりも「使われる体験」をコアに据える
"Web3らしさ"という思想的な正しさよりも、一般層にとっての分かりやすさ、そして導入のしやすさを最優先しました。革新的な技術だからこそ、あえて入り口は「慣れ親しんだ手触り」にする。思想の純度に固執せず、普及を第一に考えた「迷いのない入口」の設計を貫きました。
4-3. 導入企業(エンジニア)側の「実装摩擦」を排除する
プロダクトのUXがどれほど優れていても、組み込む側のエンジニアに負担を強いるものは普及しません。私たちは「導入の重さ」を致命的なリスクと捉え、SDK(開発者キット)の整備など、導入摩擦を低減させるための要件を重視しました。「エンドユーザーが使いやすい」と「エンジニアが導入しやすい」。この両輪が揃って初めて、プロダクトは市場に広がると確信していたからです。
4-4. 優先順位は「現場の一次情報」で磨き続ける
優先順位の判断材料は、会議室ではなく営業現場に求めました。時には自ら商談に同行し、顧客の生の反応や懸念、今の空気感を直接回収。そこで得た一次情報をもとに、プロダクトバックログの上位を常に「市場の現実」に合わせてアップデートし続けました。
5. 制約・リスク(乗り越えるべき壁)
暗号資産領域において、避けて通れないのが厳格な法規制という壁です。企業側がユーザーの資産を直接「管理できてしまう」状態になると、法律上のリスクが飛躍的に高まります。そのため、「資産はあくまでユーザーが自己管理しており、提供側は支援ツールを供与しているに過ぎない」という建付けを、技術・運用の両面で成立させる必要がありました。
"使いやすさ"という理想を追求しながらも、決して法的な一線を越えない。この極めてタイトな制約の中で、いかにユーザー体験を損なわずにシステムを成立させるか。緻密な要件定義によって「安全」と「便利」の境界線をデザインすることが、プロジェクトの成否を分けるもう一つの鍵となりました。
6. 成果

結果として、一般層の迷いを払拭する「入り口」を重視した設計が市場から高く評価されました。一般層向けにブロックチェーンサービスを展開したい企業を中心に導入が加速。プロダクトが社会に溶け込むための基盤を築くことができました。
導入先のサービスを利用したエンドユーザーからも、「初めてだったけれど、迷わず使えた」「思ったよりもずっと簡単だった」といった驚きの声が届いています。Web3普及の最大の障壁であった"使いにくさ"を、技術と工夫で取り除く。当初の狙いが確かな手応えとして返ってきた瞬間でした。

7. 最後に:新技術を「社会のインフラ」へ変えるための視点
新技術としての「Web3らしさ」を追うこと以上に、「誰が使うか(Who)」の解像度を上げきることの重要性です。
どんな人が、どんな状況で、どのような不安やつまずきを感じるのか。そのポイントを冷徹なまでに具体化したことで、ウォレット体験における優先順位が明確になりました。
入り口となるUX(ログイン体験など)の劇的な改善に加え、導入側エンジニアの実装摩擦(SDK)を同時に解消する。「エンドユーザー」と「導入企業」の両輪でハードルを下げたことで、"使える"だけでなく"選ばれ、導入される"プロダクトを実現できました。
さらに、デスクにこもらず現場の一次情報をもとに優先順位を更新し続けたことが、普及に直結する打ち手への投資集中を可能にしました。技術の理想を語るだけでなく、徹底して「現場の現実」に寄り添う。この泥臭くも本質的なプロセスこそが、一般層への普及という確かな成果を引き寄せることにつながりました。
インタビュイー:Miuraさん
BizPM。コンサル、リクルート、Web3スタートアップ、広告代理店を経験し、新規事業のPM業の経験が豊富。不確実性が高い新規事業の中で、「検証すべきことを見つける」のと、「やってみてから考える」こととのバランスを取るのが得意。最近AIで遊んでいるうちに、実は自分がAIに遊ばれていることに気づく。
スキル・強み
- 新規事業PM: 仮説設計/検証設計/MVP推進
- 要件定義・設計: 課題整理/要件定義/仕様策定
- UX・プロダクト: Whoの解像度向上/コアバリュー定義/UX設計
- 導入設計・推進: SDK設計/導入摩擦低減/優先順位更新
本事例の情報
- 業界:Fintech(Web3/暗号資産ウォレット)
- 体制:代表直下/事業責任者/PdM+開発チーム(導入側SDK含む)
