関連記事

プロジェクトの全体像については、インタビュー記事「人材紹介業界の課題を解決した新規事業「JOB FREAK」開発ストーリー｜株式会社アイビス」をご覧ください。

1. テキストではなく「画面」で対話する

miroで画面のベースを作成する

スパプラでは、専門知識や開発経験がない方でも理解でき、積極的に意見が出せるプロジェクト運営を心がけています。

そのために実践しているのが、サービスアイデアが整理できた次のタイミングで、すぐに画面のベースを作り、ユーザビリティについてディスカッションすることです。ホワイトボードツール「miro」を使い、その場で必要な画面を描きながら対話を重ねていきます。

例えば「このボタンをホバーした時にツールチップを表示します」という仕様があったとします。テキストで書かれるとイメージするものは人それぞれですが、実際の画面で見れば誰でも理解でき、全員が同じ認識を持てます。

「ここはもう少し右側に配置したほうがいいかもしれません」
「このボタン、もっと大きくしたほうが押しやすそうです」

専門知識がなくても、画面を見ながらなら誰でも議論に参加でき、後から「そういう意味じゃなかった」という事態も防げます。

Figmaプロトタイプで体験をつくる

画面のベースが固まったら、次はFigmaで操作可能なプロトタイプを制作します。静的な画面設計から、実際に触れる体験へ進化させます。

「ボタンを押したら何が起こるのか」「画面遷移はスムーズか」、動くもので確認することで、さらに課題が見つかり、改善を積み重ねていきます。このサイクルを繰り返すことで、全員が納得するサービス設計が完成します。

2. ユーザーを「観察」して「体験」を磨く

プロトタイピングの目的

今回は、人材紹介会社のための業務支援システムの立ち上げプロジェクトでしたので、FigmaによるベースUIができた段階で、紹介事業を行っている会社数社にご協力いただき、Figmaのプロトタイプを操作してもらう「プロトタイピング」を実施しました。

今回の目的は、以下の2つです。

• 現在の画面構成で直感的に操作ができるのかを確認する

• ユーザビリティの方向性を定める

利用者のIT習熟度や普段利用しているサービスによって、必要な画面の設計は大きく変わります。「簡略化したアイコンボタンでもストレスなく操作できるのか？」「ボタンはどこに配置したほうが無意識で操作できるか？」こうした細かなユーザビリティの方向性を決めることでユーザー体験が向上します。

観察から生まれる課題と改善

プロトタイピングでは、具体的な画面の説明は行いません。「面談をしながら記録してください」「候補者に提案する求人を選んでください」のように、主要なアクションのみを伝えて操作していただきます。

ここで注力するのは、マウスや目線の動きを「観察」することです。その上で「◯◯の時、1回マウスを下に動かしましたが、何のボタンを探していましたか？」のような具体的な質問をします。

「どう思ったか？」「欲しい機能はありますか？」というオープンな質問は避けるようにしましょう。サービスの世界観とは異なる機能要望を多くいただき、プロジェクトが混乱する可能性があるからです。

3. 最終形態から「引き算」して最初の一歩を決める

アジャイルな事業展開の基本指針

プロトタイピングによって、デザインの方向性や必要な機能が整理されました。完成系の全体像が見えてきた段階で、開発計画を立てます。どの順番で何を開発していくのかを決める工程です。

やることを決めるのは比較的容易ですが、「やらないことを決める」のは勇気が必要です。普段利用しているサービスは成熟したものが多く、その品質を基準にしてしまうからです。しかし、ここで重要なのが「一気に作らないこと」です。

リサーチフェーズでの意見は、実際に導入を検討する場面ではないため、ポジティブな意見が出やすい傾向にあります。そのためポジティブな意見を鵜呑みにして投資すると、思い通りに事業が伸びなかった時に、既存機能が邪魔で軌道修正が難しくなります。

リサーチフェーズでいい反応をもらっていたのに、リリース後に提案すると導入に至らないというのはよくあることで、便利そうだから導入するという単純な結果には至りません。市場の反応を見ながら、必要な機能をその時その時に判断し、優先順位を変えながらサービスを拡張させていく。

これがアジャイルに事業展開をしていく基本的な考え方です。

解決すべき「ペイン」から段階的なリリース計画を策定

優先順位を決める上で重要なのが、どんなペイン（課題）を解決するためのサービスなのかという原点に立ち戻ることです。プロジェクトが進んでいく中で、色んな課題や要望に触れるため、それがないと使ってもらえないと錯覚を起こしがちですが、そうではありまえん。

本プロジェクトでは、「ATSの普及に伴い、ツールの行き来が生じて業務効率を阻害していること」が初期に設定した問題提起でした。（プロジェクトの全体像はこちらをご覧ください。）

世の中には紹介会社向けの業務管理サービスがすでに存在しています。「求人票の一元管理」という体験に「お金を払ってでも利用したい」というニーズが確認できなければ、事業としての未来は描けません。

最終的に、以下のようなロードマップを策定しました。

第1段階:求人管理
価値を感じてもらえなければ、事業としての存続が難しい。最も重要な機能。

第2段階:候補者管理
面談履歴を管理し、業務効率を向上させる。

第3段階:案件進捗管理
業務フロー全体をカバーする包括的な機能。

第4段階:ユーザー画面
候補者の体験向上を図る機能。

この段階分けにより、市場の反応を確認しながら必要な機能を追加していく道筋が明確になりました。

まとめ

要件定義で最も大切なのは、プロジェクトに関わる全員が同じ認識を持つことができるコミュニケーション手段を選ぶことです。現時点では、それは「UI（画面）」だと考えています。

JOB FREAKのサービス設計では、次の3ステップで実行しました。

1. 画面でアイデアを発散する
miroで画面を作りながら話し、Figmaで実際の操作感を確かめる。

2. 観察を通じて収束する
プロトタイピングでユーザーの動きを観察し、無意識の行動から最適なUIを見つけ出す。

3. 引き算してMVPを決める
完成形から「やらないこと」を決め、市場の反応を見ながら段階的に機能を増やしていく。

ここだけの話…

実はテキストベースの資料はエンジニアにとっても分かりづらいことをご存知でしょうか？ Excelの仕様書が開発工程を複雑にし、認識齟齬を起こす原因になっています。

そのため、スパプラではエンジニアとの議論も画面を中心に進め、スプレッドシートは補助的に使用します。プロジェクトメンバー全員が同じ画面を見ながらユーザー目線で議論することで、開発者からも改善案が生まれるようになり、結果としてプロダクト品質の向上につながる要件定義が完成します。

クライアント情報