こんにちは、スマートバンクでモバイルアプリエンジニアをしているロクネムです。
書籍『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』ではプロダクト開発には以下の4つのリスクがあると説明されています:
- 実現可能性のリスク: エンジニアが、持っている時間とスキルとテクノロジーで必要なものを作れるかどうか
- 価値のリスク: 顧客が購入するかどうか
- ユーザビリティーのリスク: ユーザーが使い方をわかるかどうか
- 事業実現性のリスク: ソリューションが、販売、マーケティング、財務、法律など、ビジネスのさまざまな分野でも問題がないかどうか
(順番は入れ替えています 🙏)
同書では、優れた開発チームはこれらのリスクに対して開発の早い段階で取り組むと記されています。
自分はこれらのリスクのうち「実現可能性のリスク」「価値のリスク」「ユーザビリティーのリスク」の3つについてはモバイルアプリエンジニア (ひいてはフロントエンドエンジニア) が取り組みやすく、ユーザーへより良い価値をより早く届ける上で重要な領域であると考えています。
本記事では、この3つのリスクに対してモバイルアプリエンジニアが取れる具体的なアプローチについて、自分が直近開発に携わったAIレシート読み取り・手入力機能における実例を交えてお話ししていきます。
- 1. 実現可能性のリスクを排除するためのプロトタイピング
- 2. 価値のリスクを素早く見極めるためのMVPの提案
- 3. ユーザビリティーのリスクを低減するためのフィードバックサイクル設計
- まとめ
- 最後に
1. 実現可能性のリスクを排除するためのプロトタイピング
モバイルアプリエンジニア (に限らずエンジニア) は実現可能性のリスクを低減する上で大きな力を発揮することができます。
代表的なテクニックがプロトタイピングです。
すべてを完全に作り上げるには時間がかかるため、プロトタイピングで実装を進めて実現可能性をより手前で見極めるという方法です。
例えば、先日リリースしたAIレシート読み取りの機能においては、そもそも実現可能であるかどうかというところを素早く検証するために、モバイルアプリエンジニアの自分がプロトタイプを作って試してみることにしました。
プロトタイプなので、LLMでの分析もOpenAI APIをクライアントから直接叩くという素朴な実装で進めました。
完成したプロトタイプはこんな感じです:
このプロトタイプを通じて、AIレシート読み取りの機能の実現可能性については問題ないことがわかり、さらに驚くことに、従来の技術のみで提供されている他のレシート読み取り機能と比べてプロトタイプの方がかなり高い正答率を叩き出しました。
このように、何か動くものをフロント込みで作って検証するというのはモバイルアプリエンジニアならではのスキルであり、実現可能性のリスクを低減させてプロダクト開発を前へ進める上で非常に強力な武器となります。
2. 価値のリスクを素早く見極めるためのMVPの提案
その機能に本当に価値があるのかを素早く見極める上で、MVP(Minimum Viable Product)の定義は極めて重要です。
最小の単位でリリースしたのちにユーザーのフィードバックを経て次の打ち手を考えられた方が、その打ち手の精度も格段に向上します。
何を持ってミニマムであるかを考える上で、工数の観点も合わせて話を進めていくとさらにミニマムに作れることもあります。
例えば、先日リリースしたAIレシート読み取り・手入力機能において、自分はアプリエンジニア観点で工数感をざっくり洗い出しながら、それを機能単位に切り出していきました。
さらに、切り出した機能単位で「工数感」と合わせて「残論点」「体験面」を大・中・小という単位でスコアリングし、機能ごとの画面をFigmaで組み上げて資料に書き起こしていきました。
この資料を元に、PM・デザイナー・エンジニア交えて職能横断でミニマムについて議論を進めました。
結果としていくつかの機能を1st releaseからスコープアウトし、工数を1, 2ヶ月ほど削減できました。
このように、モバイルアプリエンジニア視点での工数を踏まえて改めてミニマムについて議論をしてみると、より必要最小限なプロダクトの輪郭が見えてくることもあるのです。
3. ユーザビリティーのリスクを低減するためのフィードバックサイクル設計
チーム内で高速に仕様を叩き上げていくと、チームメンバーにはドメイン知識が蓄積されるとともに、知識のない状態でのユーザーの体験を想起しづらくなってしまいます。
またプロダクトを開発する上では、どうしてもコードを書いて動かしてみないと分かり得ない体験なども存在します。
このような観点からユーザビリティーのリスクを低減する上で、モバイルアプリエンジニアの視点で最小のフィードバックサイクルを意識した開発スケジュールを立てることが効果的です。
例えば、先日リリースしたAIレシート読み取り・手入力機能では、まずはより不確実性の高いAIレシート読み取り、次に手入力機能のコア価値に対して、それぞれ最短でフィードバックをもらえるように実装の優先度付けを行いました。
1の時点では、チームのPM・デザイナー・エンジニアでひたすらレシートを読み取りまくって、どういうケースで読み取れないのかなどの情報を収集していきました。
2の時点では、チーム外のメンバーも広く募り、実際に開発環境でビルドを配布して手元の実機で動作を見てもらい、ドメイン知識がない状態での新鮮なフィードバックを同期的に収集しました。
そして、得られたフィードバックへの対応を進めつつ、3で残りの機能の充足を進めました。 例えば、レシートのアニメーションは開発期間の最後の1週間でガッと作っていました。
最近がんばって実装したアニメーションです🧾 pic.twitter.com/P8cHS4JvFq
— ロクネム (@_rockname) October 23, 2024
このように、モバイルエンジニア視点で適切な粒度で機能を分解して不確実性を考慮した優先度を付けていくことが、最速でフィードバックを得てユーザビリティーのリスクを下げる上で非常に有効です。
まとめ
本記事では
- 実現可能性のリスクに対しては、フロント込みのプロトタイピングで
- 価値のリスクに対しては、工数観点を踏まえたMVPの提案で
- ユーザビリティーのリスクに対しては、最小のフィードバックサイクルの設計で
モバイルアプリエンジニアは貢献できるというお話をさせていただきました。
本記事が、モバイルアプリエンジニアがプロダクト開発を前に推進する上での参考になりましたら幸いです。
最後に
スマートバンクでは一緒にB/43のアプリを開発していくメンバーを募集しています！ カジュアル面談も受け付けていますので、ぜひお気軽にご応募ください💪
