2019.04.04

ビズリーチの新規事業における「0→1 DESIGN」

藤松裕士

プロダクトデザイン

はじめまして、デザイナーの藤松です。

ハイスキルエンジニア専用転職サイト「BINAR」（旧：BINARY）のデザインを担当しています。

ビズリーチでは「New Bamboo!」という新規事業の社内コンペが定期的に行われており、BINARはそこで可決された、「日本国内のIT業界の負を解決するためのサービス」です。

今回は新規事業のデザイナーとして取り組んできたなかで、重要だと感じたポイントや、意識していたこと、具体的なデザイン手法についてご紹介します。まだまだ生まれて間もないサービスですが、新規事業の立ち上げに挑戦する方の参考になれば幸いです。

新規事業「BINAR」はハイスキルエンジニア専用の転職サービス

はじめに、BINARの概要について説明させていただきます。

BINARは、ハイスキルエンジニア専用の転職サービスです。

私たちは国内のIT業界が抱えている負を解決したいと考えています。近年、IT産業の拡大にともない、ITエンジニアの需要は年々高まっていますが、日本国内のITエンジニアの給与水準は、アメリカやインドをはじめとしたIT先進国とされる国々と比べて高くありません。

これからの日本のIT産業が発展していくために、ITエンジニアがその価値に見合った評価を受けられる世の中にしていきたい。そのために、BINARで次のような循環をおこし、ITエンジニアが活躍できる業界をつくっていきたいと、私たちは考えています。

BINARでトップレベルのITエンジニアがそのスキルを活かせる企業に行ってもらうことで、ITエンジニアとしてより輝いてもらう
輝いているトッププレイヤーに憧れてITエンジニアを目指す人が増える
ITエンジニアの人口が増え競争が高まり、ITエンジニア全体のスキルレベルが上がっていく
ITエンジニア全体が高いスキルレベルに見合った評価を受けられるようになる

作り変えやすく、共有しやすい形式でアウトプットする

新規事業の立ち上げでは、特にリーンやアジャイルといった開発手法をとっている場合、プロダクトを作って議論し、作り変えながら前進することがとにかく多いです。そういった開発プロセスのなかでは「早くつくること」はもちろん、「作り変えやすいと思ってもらえること」が重要になると感じています。

「早くつくること」は純粋に、多くPDCAを回すことにつながりますし、「作り変えやすいと思ってもらえること」は、議論の活性化につながります。

作ったアウトプットがデザイナーしか使えないツールで作ってあったり、細部まで作り込んであると、「作り変えづらい」と思われてしまい、チームでの議論で「作り直す手間」や「作り直しにかかる時間」などへの遠慮で、意見が出にくくなります。そういったハードルを避け、少しでも多くチームで議論をすることを意識しています。

ここから具体的に、実際の開発プロセスのなかで作成したアウトプット例を紹介します。

カスタマージャーニーマップ・リーンキャンバスをスプレッドシートでつくる

サービスのコンセプトを設計するために活用した、カスタマージャーニーマップ（CJM）やリーンキャンバスはスプレッドシート上で作成しました。はじめは、手描きで作成・運用していたのですが、大きくなるにつれて参照しづらくなったため、オンラインに移行することになりました。

デザインツールではなくスプレッドシートで作成することで、編集にかかるコストが減り、かつメンバーの全員が編集することができるので「作り直す手間」や「作り直しにかかる時間」がハードルになることがありませんでした。

プロトタイプを共有・変更しやすいデザインツールでつくる

ProttやInVisionなどのプロトタイピング専用のツールにはメリットもありますが、デザインをアップロードのし直さなければならなかったり、アカウント管理をしないといけなかったりといった、手間が発生してしまいがちです。

プロトタイプを何度も頻繁に作り変えていくなかで、そういった小さい手間が積み重ならないようにするために、今回はデザイン作成から共有までを一貫して行えるSketchを使用しました。

デザイナーとして意匠のクオリティにこだわることはもちろん重要ですが、こだわり過ぎて進捗の停滞にならないよう、作り変えやすさとのバランスを取ったアウトプットを意識しました。

役割を分けたプロトタイピングで、効率良く仕様を設計していく

複雑なサービスの仕様設計では、提供価値を満たした機能になっているか、運用が正常に回るか、準正常系・異常系の考慮漏れが無いか、実装工数に無理が無いか…など、多くの点を考慮する必要があります。

これらのさまざまなパターンをひとつのプロトタイプで同時に検証しようとしても、観点が多角的になってしまうため、段階を分けて検討することが大切です。

焦点を絞って効率よくレビューをおこない、手戻りの少ない開発を行うために、決定すべき内容とその期間を3つの段階に分け、それぞれのフェーズに最適なプロトタイプを作成してレビューを行いました。各ステップを紹介します。

1. 画面遷移と各画面の提供価値を設計するための手描きワイヤーフレーム

プロトタイピングの初期段階は、手描きのワイヤーフレームで行いました。

こちらのプロトタイプでは、画面ごとの概要、画面遷移と各画面の提供価値を決定することを目的とし、レビューもそれらに焦点あてて行いました。

焦点を絞ることで「MVPが満たせているか」「機能として矛盾が無いか」「想定していたユーザー体験を提供できるか」など、ユーザー観点やプロダクト観点からサービスの基盤となる要件について議論をすることができました。

また、このプロトタイプの作成が完了することで実装に着手することができる状態になりました。

2. 具体的な表示要素や運営方法を設計するためのモックアップ

次に、デザインツールを用いた詳細なモックアップでプロトタイピングを行いました。

こちらのプロトタイプでは、具体的な表示要素や運営方法を含めた考慮漏れが無いかを決定することを目的としました。BINARでは、求職者向けの画面以外に、スカウトを送信していただく企業向け画面、審査などを行うための運営向けの管理画面が存在するため、それぞれの画面でのデータのやり取りも含めて、仕様を設計する必要がありました。

レビューでは「正しく運用が可能か」「実装が可能か」「ユーザー導線を考慮できているか」など、ユーザー観点やプロダクト観点に加えて運用観点から、具体的な開発仕様に焦点を絞った議論をすることができました。

このプロトタイプの作成が完了することで、フロントエンドを除くほとんどの実装が着手可能になりました。

スタイルを含めた最終仕様を設計するためのデザインモックアップ

最後にデザインモックアップを作成し、意匠やインタラクションに焦点を当てたレビューを行いました。これで、仕様設計を完了させることができました。

段階を分けて少しずつ仕様を固めていくことでレビューの精度も上がり、手戻りが少ない仕様設計を行うことができました。また、アウトプットが多く議論が活発に行えた結果、仕様決定までチーム内での透明性が高い開発を行えたように感じています。

チーム全体で同じ方向を向いてサービスを改善していく

MVPを満たすβ版をリリースし、改善を早めていく

仕様を決定したあとは、ユーザーに提供すべき、と決めた最低限の価値を満たすだけの機能を開発し、β版としてリリースしました。

ここまで決めてきたMVPとなるものは仮説に過ぎないため、その仮説を検証する必要があります。そのためまずはβ版としてリリースし、実際に運用をおこないながら、現在も仮説検証を繰り返し、日々サービスを改善しています。

メンバーの各々が課題を分析し、仮説検証を繰り返していく

重視すべき課題は、日々状況によって変わっていきます。しかし、正式版リリースも迎えていない新規事業のため、対応できる時間や人的なリソースは限られています。そのため優先度をつけて施策を実施しなければなりません。

それらの課題を、デザイナー、PM、ビジネス職、専属コンシェルジュ（ユーザーのサポートをする役割）、エンジニアといった各職能のメンバーが、それぞれの観点からブレイクダウンさせ、細分化された課題を基に実施する施策を検討していきます。

それぞれブレイクダウンされた課題は、週に一回行なっている施策優先度検討会で細分化された課題のなかでどれに取り組むべきかを議論し、メンバー全員で優先度をつけています。取り組むべきとされた課題は再びメンバーの各観点からソリューションを探り、施策として実施していっています。

開発プロセスについて、メンバーにも訊きました

日々の業務の流れは、問題発見、原因課題/仮説の抽出、対策案の検討、実行、効果測定が基本となっています。

様々な役割を担うメンバーが集い、問題を共有し、それが「現時点で」どの程度重要であるかを再認識する儀式は、各人が事業戦略を強く意識できる良い機会だと考えています。一方で、問題の粒度が細かすぎたり、対策案ありきの課題抽出になってしまうことがあります。今後も早いサイクルでサービス改善を行っていくためには、超えなければ行けないハードルの1つであると感じています。
（エンジニア）

新規事業というフェーズだからこそ、この施策優先度検討会議は非常に重要です。目まぐるしく状況や課題が変わり成果が見えない中で、いかにチームとして「変化＝成長」するかは、この会議で担っています。ですので、どんな些細な事でも全員が参加し、忌憚なく議論できる環境（心的安全）を作れるかが１つのポイントであり、失敗が多い中で進み続けられる推進力になると考えてます。実際、会議のちょっとした発言から、サービスのUX改善や集客施策が決まることもありますね。
（マーケター）

このように、課題の分析から施策の具体化までメンバー全員が関わりながらサービスを改善していることで、各々が納得性・主体性を持ちながらユーザーに最高の体験を提供すべく、正式版に向かって改善を進められているように感じています。