べにやまぶろぐ

技術寄りの話を書くつもり

『【ヒカ☆ラボ】「HOME'S」の開発スタッフが語るスマートデバイスアプリ開発秘話 ～住まい探しアプリ、使いやすさNo.1への道～』に参加してきました #hikalab

本日はこちら https://at-agent.jp/service/event/92/ に参加してきました。講師は 株式会社ネクストのエンジニア、大坪 五郎 氏と 小屋敷 圭史 氏。ネクストは HOME'S を作っている会社ということで、 HOME'S アプリの裏側について話していただきました。

ちなみに、

  • 最近家具を扱う EC サービスを始めた。
  • ４年連続で『働きがいのある会社』のベストカンパニーに選出
  • エンジニアブログは http://nextdeveloper.hatenablog.com/

とのことです。

HOME'S アプリの裏側 (小屋敷 様)

  • 不動産業開発の iOS アプリを 2009年12月にリリース、現在 v3.0
    • 業務時間の20%を充てられる社内制度を活用して開発
  • iPhone/iPad 双方に単なるレスポンシブではなくベストな UI を提供
    • 物件検索
      • 2回目以降は初回の検索を走らせて最新の検索結果を予めとってきて見せている
    • 見学メモ
      • 内見のときの写真やメモが自動的に物件単位で整理される（撮った時間と位置情報を基準）
    • 画面レイアウト
      • 横レイアウトにして iPad の大きさを活用して比較できるようにした
      • 画面遷移せずに一覧から検索条件を変更
      • 詳細は全画面表示
  • 内製で社員全員でこだわって作っている。
    • ネイティブ、ユニバーサル、HOME'S API の利用
  • 物件一覧の表示の作り
    • 賃貸マンション、アパート、分譲、一戸建てなどマーケット・物件の数だけパターンが違う。
  • 多少強引だが ConnectionView が使えない事情があり、TableView を回転して横表示にしている。
  • 開発体制
    • 利用ツール : Git, ChatWork, Redmine, Wiki, TestFlight
    • 企画２名・デザイナー２名・エンジニア５名
    • 全員で施策を出した後に企画が仕様を決める
    • ２ヶ月に一度くらいのリリース
    • 朝会やアプリレビューランチ
      • ランチは隔週で実施していて各メンバーが良いと思ったアプリを紹介しあい、アプリの改善につなげる
    • Redmine ではタスクやバグだけではなくアイデアも入れている
    • Crashlytics を使ってクラッシュ情報を収集している
      • Apple のレポートはなかなか集まらない
      • クラッシュの統計情報が集まるので対応の緊急性が可視化される
      • クラッシュの発生箇所が確認できる
      • クラッシュした端末の状況が確認できる
    • 実機デバッグ機能 : デバッグモードでボタンを表すと画面下部から出現
      • メモる確認、ワーニング発生、API 接続先変更など
    • サーバーサイドは PHP/Ruby、API は Ruby

変わった UI をもつアプリ"へやくる!"について (大坪 様)

  • 他社アプリはユーザーとデータの距離が長い
    • 起動してから 10回タップしないとたどり着かない
    • へやくるは起動時に検索結果を出したりしている
    • くるくる動かすだけで家賃設定などができる
  • WISS2002 でウェアラブルの塚本先生に会った。また10年経った今でも面白いと思える研究に出会えた
  • 元々陸上自衛隊の車両メンテナンスや施策を担当していたが、あまりオリジナリティのある仕事ができていなかった
  • ランチ推薦アプリを研究発表
    • 一生懸命最初から考えるのではなくいっぱい出して選択に応じてどんどん狭めていくアプローチで作った
  • 自分が何が欲しいかわかっていないユーザーは最初に詳細な検索条件を入れさせるのは向かない。
    • 他社製のアプリはジグソーパズルの１ピースが抜けているユーザーをターゲットにしている
    • どんどん選ばせてどんどんフィードバックを与えるべき
  • ガイドブックの標準的な情報か口コミのようなやわらかい情報を区別するカーナビ UI なども開発した
    • 2003年時点では車の中でネット検索する理由は理解されなかった
  • 企業の研究のジレンマ (カーナビで bing 検索するなんてことになる理由)
    • 問題点 1 : 新しくて有効なアイディアを形にすること
    • 問題点 2 : 製品・サービス化に必要なリソースを獲得する
  • Facebook Paper はアプリ開発の敷居を一気に上げた
    • 一覧・詳細の切り替えが見事
    • 全てのものが有機的に動く
    • 手のひらの中でのインタラクションがマウスやキーボードと完全に違うという思想の表れ
    • 写真のデコードとインタラクションを別の CPU コアで行わせる高い技術力

質問時間ではなぜくるくるの UI にたどり着いたのか、またボツになった案はあったのかについてお聞きしました。

回答は、

  • 最初はアプリの名前がへやくるだから回していた
  • スライダーでも実装したが幅のメモリ調節が難しかった。それにスライダーを長くしすぎると指を動かしすぎなければならない。
  • プッシュするとジニーエフェクトが出るものなどあったがなぜボツになったかは多分見なければわからない
  • スライダーの領域をはみ出してひっぱれるような UI もボツになった
  • 理屈にこりすぎたのかもしれない
  • 楽しいし簡単というのが大事

という回答をいただきました。

個人的には WISS とか塚本先生とか出てくるとは思ってもいなかったので、元研究畑の人間としてはその辺のお話が面白かったです。大量の情報をいかに絞り込むかというのはほとんどのアプリで共通の課題だと思いますので、その辺に注力して研究してみるのも良いなと思いました。