見通せないものから先に潰す
「イシューからはじめよ」等でも書かれていることだが、不確実性のあるものは先に手をつけるべきだ。体験をゼロから作るのは作業ではなく、創造だ。創造には多くの不確実性が伴う。
開発終盤で「すみません、できると思ってたんですが、この手法だとできませんでした」となっては困る。これは3本の指に入るほどのあるあるネタでもある。
先につぶしておくものベスト3
実装ではさまざまな不確実な要素があるが、頻繁にでくわすものをあげる。
- センシングまわり
- APIができあがったら、まずは疎通
- デザインが入った状態で確認したい人々
1. センシングまわり
- センサーはどいつもこいつもクセだらけ
- クセ = 落とし穴
- Reactみたいなメジャー系と比較すると、センサー情報はググっても情報が少ない
- 環境によって向き不向きがある
- 日光が入ると動かなくなる赤外線系
- 光学系は遮蔽物・反射物・環境光の変化がないように
- 慣性系はしばらくするとズレる
- 「とりあえず動いた！」ではなく「体験が気持ちよく仕上がっているのか？ 」をシビアな目で見る
- 気持ち悪い体験だとレビュー会でこきおろされる
- 詳しくはセンサーとの向き合いかたにて
2. APIができあがったら、まずは疎通
ここでのAPIとはすでに世の中に存在しているAPIではなく、新規に開発しているAPIのこと。
サーバーサイドの人が作ったAPIも、最初から万全ではない。何度も叩いて「こなれさす」必要がある。
あるあるネタとして、以下が挙げられる。
- CORSでひっかかる
- クラウドのインスタンスがしょぼすぎて、そもそもさばけてない
- POSTしたら500エラー
- 想定していない値の送受信が発生する
- APIドキュメントに書いてることと、実装が違う
- 使っていくうちに足りてないAPI・パラメータが見つかる
誰しも、最初からすべてを見通して作れないので、APIサーバーができた時点でサクッと試して、問題点を早く見つけることが大切。
3.デザインが入った状態で確認したい人々
残念ながら、ワイヤー等を提出してもまったく見ず、デザインを実装した段階でないと体験しないひとがいる。
逆にいうと、デザインを入れ込んで初めて本当の体験に近づく、ということでもある。
とはいえ、実装側からすると、捨てるかもしれもないものを実装するなど、シンプルにめんどくさい。
ここでのパターンは
- とりあえずのデザインを入れて、肌感を得たいひとがいる
- デザインを入れないとそもそも確認しない人もいる
- その人を後回しにすると、どんでん返しの可能性がある
といったところだ。どちらもほっとくとリスクしかない。
しかし、デザイン入れ込みを優先すると、開発が進まなくなるので対処が必要だ。
- 開発のキリのいいところまでデザイン入れ込みを待ってもらう
- あとからごちゃごちゃ言われないために、デザインを一緒に確認する時間を作る
- ある程度デザイン面での不安が解消したら、それ以降のクオリティアップは後回しにしてもらう交渉をする
こういった対応を積み重ねて、どんでん返しリスクを減らしながら、体験の正解に近づけていこう。
逆に放置しておくもの
- アクセス解析なんて誰も見ない
- 口だけのうるせーやつ
アクセス解析なんて誰も見ない
アクセス解析など誰も見ない(本当に)。
ただ、たまにアクセス解析の力が必要になるときがあるので、最後の最後にちゃんと実装したほうがいい
- KPIめっちゃ大事案件
- ちゃんとレポートしないといけなくなる
-
ド派手に失敗した案件
- 失敗した案件はとりあえずいろんな数字を列挙して、それっぽい失敗の原因や今後の展望を語らなくてはならない
口だけのうるせーやつ
- 手は動かさないくせに、うるせーやつがたまにいる
- 的外れなことばかり言ううるせーやつは「はい、そうですね！ありがとうございます！」と言って放置しておく
うるせーやつをほっとくのはなかなかの精神が必要だが、この仕事を続けるならその数十倍の精神力が必要。 なので、うるせーやつは精神鍛錬の練習台と思ってたらいいんじゃないかな。
まとめ
うるせーだけのやつをうまく"いなし"て、不確実なものから潰していこう