Chapter 22無料公開

┣ 不確実で不安なものから先に手をつけ、うるせーだけのやつはスルー

Yoshio Kakehashi
Yoshio Kakehashi
2021.12.14に更新

見通せないものから先に潰す

「イシューからはじめよ」等でも書かれていることだが、不確実性のあるものは先に手をつけるべきだ。体験をゼロから作るのは作業ではなく、創造だ。創造には多くの不確実性が伴う。

開発終盤で「すみません、できると思ってたんですが、この手法だとできませんでした」となっては困る。これは3本の指に入るほどのあるあるネタでもある。

先につぶしておくものベスト3

実装ではさまざまな不確実な要素があるが、頻繁にでくわすものをあげる。

  1. センシングまわり
  2. APIができあがったら、まずは疎通
  3. デザインが入った状態で確認したい人々

1. センシングまわり

  • センサーはどいつもこいつもクセだらけ
    • クセ = 落とし穴
  • Reactみたいなメジャー系と比較すると、センサー情報はググっても情報が少ない
  • 環境によって向き不向きがある
    • 日光が入ると動かなくなる赤外線系
    • 光学系は遮蔽物・反射物・環境光の変化がないように
    • 慣性系はしばらくするとズレる
  • 「とりあえず動いた!」ではなく「体験が気持ちよく仕上がっているのか? 」をシビアな目で見る
    • 気持ち悪い体験だとレビュー会でこきおろされる
  • 詳しくはセンサーとの向き合いかたにて

2. APIができあがったら、まずは疎通

ここでのAPIとはすでに世の中に存在しているAPIではなく、新規に開発しているAPIのこと。

サーバーサイドの人が作ったAPIも、最初から万全ではない。何度も叩いて「こなれさす」必要がある。

あるあるネタとして、以下が挙げられる。

  • CORSでひっかかる
  • クラウドのインスタンスがしょぼすぎて、そもそもさばけてない
  • POSTしたら500エラー
  • 想定していない値の送受信が発生する
  • APIドキュメントに書いてることと、実装が違う
  • 使っていくうちに足りてないAPI・パラメータが見つかる

誰しも、最初からすべてを見通して作れないので、APIサーバーができた時点でサクッと試して、問題点を早く見つけることが大切。

3.デザインが入った状態で確認したい人々

残念ながら、ワイヤー等を提出してもまったく見ず、デザインを実装した段階でないと体験しないひとがいる。
逆にいうと、デザインを入れ込んで初めて本当の体験に近づく、ということでもある。

とはいえ、実装側からすると、捨てるかもしれもないものを実装するなど、シンプルにめんどくさい。

ここでのパターンは

  1. とりあえずのデザインを入れて、肌感を得たいひとがいる
  2. デザインを入れないとそもそも確認しない人もいる
    • その人を後回しにすると、どんでん返しの可能性がある

といったところだ。どちらもほっとくとリスクしかない。

しかし、デザイン入れ込みを優先すると、開発が進まなくなるので対処が必要だ。

  • 開発のキリのいいところまでデザイン入れ込みを待ってもらう
  • あとからごちゃごちゃ言われないために、デザインを一緒に確認する時間を作る
  • ある程度デザイン面での不安が解消したら、それ以降のクオリティアップは後回しにしてもらう交渉をする

こういった対応を積み重ねて、どんでん返しリスクを減らしながら、体験の正解に近づけていこう。

逆に放置しておくもの

  1. アクセス解析なんて誰も見ない
  2. 口だけのうるせーやつ

アクセス解析なんて誰も見ない

アクセス解析など誰も見ない(本当に)。

ただ、たまにアクセス解析の力が必要になるときがあるので、最後の最後にちゃんと実装したほうがいい

  • KPIめっちゃ大事案件
    • ちゃんとレポートしないといけなくなる
  • ド派手に失敗した案件
    • 失敗した案件はとりあえずいろんな数字を列挙して、それっぽい失敗の原因や今後の展望を語らなくてはならない

口だけのうるせーやつ

  • 手は動かさないくせに、うるせーやつがたまにいる
  • 的外れなことばかり言ううるせーやつは「はい、そうですね!ありがとうございます!」と言って放置しておく

うるせーやつをほっとくのはなかなかの精神が必要だが、この仕事を続けるならその数十倍の精神力が必要。 なので、うるせーやつは精神鍛錬の練習台と思ってたらいいんじゃないかな。

まとめ

うるせーだけのやつをうまく"いなし"て、不確実なものから潰していこう