HouseeS

与件を受けて最初に取り組んだこと。それは社内で「なぜいまYahoo!不動産のスマホアプリが必要か」議論することだった。そもそも先方の依頼だから「必要」なのは当たり前？ そう言われればその通りだ。「Yahoo!不動産」はすでに業界大手の地位を確立する一方で、当時スマホアプリはAndroidのみ対応。本格展開はこれからだった。もちろん後発でも、ビジネス的にはメリットがある。「ウチの店で決めてもらう」ための窓口は多いほうが良いし、その選択肢としてスマホは今後外せないはずだから。

ただ、ユーザーにとってはどうなんだろう？すでに世にあるものと似たアプリが市場に並ぶことで、彼らの住まい探しに新たな付加価値が加わるのか。つまり、このプロジェクトはユーザーにとってどんな意味があるのだろう？

あえてこうした「疑うステップ」を入れることで、案件のより深い理解や、後の発展につながる可能性は高まる、と僕らは考えている。

これは示されたゴールを、自分たちで咀嚼する試みといってもいい。そこまで遡ることではじめて共有できるクライアントの想いもあるはず。「従来のマンション探しアプリとは違うもの」という彼らのシンプルな言葉も、きっと上述のような想いを経由している。こうした思考をたどり共感することで、垣根を超えたチームを作っていきたい。

そう、今回の僕らの仕事は、看板違いの類似アプリ作りではない。「マンション探しに新しい価値を与えたい」というこのチームの意思を、デザインで表現することなのだ。

目指すアプリの輪郭が見えてきたある日、田口・西垣のふたりで深夜の集中クイックシンク！主要画面のラフスケッチをざっと描き上げた。こういうときは何だかんだ言っても手描きがとにかくスピーディで、コミュニケーションも取りやすい。最近はUI Stencil などが、スマホ画面の考案用に使い勝手のいいシートも提供している。

僕らは勢いに乗り、さらにこれをそのままプロトタイプツールに突っ込んでみた。今回はfluidを使って3時間程で作業完了、これでプロトタイプが出来上がり。早い段階でイメージ共有とフィードバック取得ができる利点は大きい。関連ツールの進化と共に、プロトタイプ活用は今後より重要性を増していくと思う。

続いては提案書。通常、僕らはこれを「与件整理＋方針」「コンテキスト分析」「プロダクト」「コスト＋スケジュール」「体制」の流れでまとめている。プロダクトの説明では、ネット経由のマンション探しにおける基本行動となる、以下の流れを解説した。

「検索→リスト表示→詳細表示→お気に入りをストック→シェア・コンバージョン（資料請求・見学会申込）」

その上で、各ステップで最適な機能化を図ることを提案した。今回はいわば、『「鉄板」の流れを押さえつつ、細部をバージョンアップする。』というやりかただ。プレゼンで工夫したのはそれぞれの機能の「決め台詞」。たとえば今回は目指すアプリの検索性について、対人的な柔軟さを表す言葉として「ふわピタ ファジー検索」などを打ち出した。プレゼン時のウケ具合はまた違う意味でファジーだった（!?）かもしれないが、開発前にこうした言葉でイメージを共有してもらうのはとても大切なはず。。

プレゼンの結果、僕らのプロジェクト参加が正式に決定された。

契約手続きにかかる時間も無駄にならないように、進められる部分は出来る限り実作業に突入する。ただしいきなり制作開始ではなく、僕らはここでユーザー分析の仮説検証を試みた。これは考案したアプリの機能が、想定ユーザーの要望をきちんと満たすのかどうかを探るヒントとなる。

テストの概要はこうだ。対象は、今回KPIとしても挙がった「マーケットプレイスでの評価」が高い競合アプリ。これを被験者に使ってもらい、その反応を動画とインタビューで観察する。対象は社内のデザイナー・ディレクターを中心に、グループの社長も駆り出して行なった。
今回は被験者群を「マンション購入意欲」「スマホ操作の慣れ具合」の２軸でとらえ、4象限のタイプに分類。

・具体的に購入予定 ＋ スマホ操作に慣れている
・具体的に購入予定 ＋ スマホ操作に不慣れ
・購入に関心はあり ＋ スマホ操作に慣れている
・購入に関心はあり ＋ スマホ操作に不慣れ

結果、全ユーザーの共通点（とにかく候補物件を多く見たい）、またスマホに不慣れなユーザーの予想外のハードル（使い易いか以前に「自分にも使えるか」で早々に挫折）などが浮かび上がった。これに基づき仮説部分を一部訂正、改めて資料化していく。

ユーザインターフェイス（UI）構築では、まずサービスの垣根を超えて人気アプリ群を調査、今回ヒントになりそうなものをピックアップした。その上で、西垣やアートディレクターの石田康太らクリエイティブチームが「こんな感じ？」と共通認識を持てる部分を抽出。「とっつきやすい」「わかってくれる」「ライトなわくわく」などキーワード化も行い、方向性と質感をかたちづくっていく。

リサーチでピックアップされた参考アプリ群。業態にはこだわらず、ヒントとなるものを探った。

一方この過程では、検索結果のリスト表示で定番の縦並びの画面だけなく、あえて横方向スライド式の画面なども実験。最終的にはやはり縦リスト画面を選択したけれど、個別物件の写真群閲覧で横スライドを取り入れるなどしている。また、この世界特有っぽい細かい対応も随所に。たとえばサムネール画像において、マンションの画像は中央揃えで切り取るより、青空と最上階が表示される上揃えが見栄えもいい。また検索ワードの入力時、ユーザーをただ待たせずに、ヒット件数を先に表示する機能なども盛り込んだ。

先行フェーズを受けてデザインコンセプトを策定。サービス（アプリ）名は「HouseeS」ということで決定し、並行してアプリロゴにも取りかかった。石田が考案した最初のロゴはここまで打ち出してきた「親しみやすさ」を反映し、「HouseeS」の語感からのイメージもふまえてキャラクター性を持つポップなもの。しかし、このアイデアは充分に検討いただいた結果、要再考となった。クライアントの求めるスタイリッシュさ・シンプルさと必ずしもマッチしなかったのだ。
ユーザーゴールを元にしたイメージ構築は間違いではないが、ブランドはその上位概念であり、この土台への意識は十分に配慮されなければいけない。

そこで根本的に再検討し、シンプルな色使いとデザインの現ロゴが完成。これは競合アプリ各種との効果的な差別化にもつながった。なお「Yahoo!不動産」は賃貸マンション探しのスマホアプリ「Rent RooomS」も進めていて、このロゴも同じコンセプトで提供させて頂くことになったのだ。

HouseeSはPC版「Yahoo!不動産」と共通のデータベースから、既存の専用APIで情報を引き出す。そこで、APIの仕様やデータ構造の詳細を理解した上で情報設計を行う必要があった。各管理項目とその入出力ルールを確認し、得られるデータがそのまま広取委の不動産表示ルールを満たすのか？なども細かくチェック。機能の実現性をスタディしつつの情報設計になった。なお、前述のグループ会社・イーサグラムが「Yahoo!不動産」の業務に参加していたので、彼らとの情報交換も助けに。横断的なミーティングも短期間で実施し、グループ会社の強みが活かせた一場面とも言える。

ユーザーの指定条件に厳格になりすぎず、かといって的を外さず、というアプリ実現のため検索UIは大きな柱だ。そこでAPI動作の確認用に、まずPCブラウザ上で動く検索UI呼出プログラムをHTML+Javascriptベースで作成。

実動作を詳細に確認すると、やっぱり実際ふれてみてはじめてわかることが出てきた。さらにユーザービリティの視点からも、快適な検索フローの実現見込みなどを検証する。

一方このころ、デザイナーサイドも設計たけなわ。プロトタイプをワイヤーフレームに起こし、情報のひも付きを可視化、コンテンツマップを作成する。さらに検索リスト、詳細表示それぞれの表示、コンバージョンにあたるボタンの位置やサイズまで、ユーザインタラクションも含めて続くデザイン作業に備える。

もちろん、両者は互いの状況を把握し合いながら作業する。実装へ落とし込んでいくプロセスでは、こまめなミーティングの積み重ねも忘れなかった。

こうして主要ページが揃い、検索機能を除くHTMLベースの遷移モックアップを実現！レビューを繰り返し、主要インターフェイスはほぼ完成版レベルまでブラッシュアップされた。やっとここまで、という気もするが、実際はプロジェクトが本格スタートしてから約1ヶ月半というところ。モックアップの利点は、メンバーが実際にふれながら各所を確認し合えること。さらにいいのは、ユーザーテストが実施できること。やはり、生の反応がナンボの世界。

ユーザーテストはヤフー社のテストルームを会場に、丸3日かがりで行った。デザイナーやデベロッパー、さらにヤフー側チームも一緒に、関係者総出のディスカッションに突入。ホワイトボードがみるみる文字と図で埋まっていく……。

並行してアイコンレベルから各種インタラクションまで、グリグリと修正が入り詳細が仕上げられていく。ともすれば初見ユーザーの感覚から離れてしまう時期だけど、直前のユーザーテストの副次効果もあり、皆の目線はしっかりユーザーを向いたまま、議論が進められた。一方、微修正が常に行える環境は、議論が詳細に及んでしまう場面もあり、プロジェクト管理の面では課題も残した（これは記事の最後にふれたい）。
ともあれ、これで実機への搭載前に検証できる環境は整った！

今回、iPhone／Android版の同時対応もあり、実装では開発経験の豊富なフューチュレック社に加わってもらった。実機での開発を彼らに進めてもらいつつ、僕らは何をしていたか？　HTMLベースのモックを作成し、これまで挙った要確認トピックを実験していた。

「動くもので試せる」環境を整えることは、開発の重要なポイントになった。もしこれを省いて実機開発に進んでいたら、意図せず重要な検証をすっ飛ばしたかもしれず、テストで気づかなかった問題に対応できなかったかもしれない。コスト面での大事な検証を、後回しにせざるを得ない可能性もある。それらの懸案をクライアントと試行錯誤しつつ、実機での動きをフューチュレックと確認し合う、という手順を並行させた。

そして、初春のスタートから季節も入れ替わった夏のある日――。ついに物件データ部を切り離した状態で動作する実機試作版アプリが完成。メンバー一同がヤフー本社に集結し、「Housees」アプリの産声を体感した。

とはいえ作業はさらに、API部の実組込へと続く。この段階でも、さわればさわるほど「ここはもっとこういう感じだと…」との声は尽きず、納得いく使い心地になるまでブラッシュアップは続いた。ちなみにここでもHTML製モックは活躍、インターフェイスの負荷やレスポンスなど、使い勝手を確認しながらの作業をスムースにしてくれた。