Today I Learned: 2017/10/19

何か学べたことはないか

チーム内ドッグフーディングもユーザーテストっぽくやる

特に目的もなくプロダクトや機能をさわってるだけでは、ドッグフーディングとしての効果は小さい。がむしゃらにモンキーテストのようなことをするだけでは見つかるものが足りない。

芝居じみていてもいいので、ユーザーテストでテスターにお願いするような、具体的な完了条件・目的があるタスクを、誰かに観察されながらやってみると、不思議といつもは見えてなかった問題点、改善できそうなポイントが見つかる。

それでも、実際にプロダクトが使われる環境とは大きく違うはず。それでもそういう環境と遠いよりは少しでも近い環境や気持ちでプロダクトを使えるようにしたほうがいい。

アイスブレイクのあとのスイッチON重要

ミーティングでの最初のアイスブレイクは後の議論を活発にするために大事な気がするけど、その後のON/OFFの切り替えを意識的にハッキリとやらないと、最後までずっとダレた感じになる。なった。

そうなると時間がもったいなくなる。効率が悪い。

ONとOFFの切り替えという意味では、ebacky さんの研修での動き方がすごく印章に残っている。聴衆全員のスイッチを一気にONにするような立ち振舞い。何か参考にできることはないか。スタートを「宣言」することが重要な気がする。

リリース作業には集中力が必要

自動化やChatBot等でいくら便利・簡単になっても、リリース作業はエネルギーや集中力が必要。一日のうちに使うことができる集中力のいくらかを消費してしまう。他の大事な作業の途中でリリース作業をして、かなりの集中力を使った感じがした。

すべてのバグ修正を緊急リリースすべきかというとそうではない。通常のリリースサイクルがあれば、それに載せた方がよいときもある。バグの重大さと、それによって発生するいろんな人にとっての不利益と、リリース作業に使うコストを天秤に掛けて常に考えるべき。

リリース作業に使うコストは、リリースフローや仕組みの成熟度だけではなく、修正やリリース作業を行う人のプロダクトや機能、リリースフローや仕組みに対する習熟度合いによっても変わる。

自分が少し安全に寄せすぎているのかもしれない。もっと、仕組みも含めてもっと効率的にできないか。

ここまで、書いて「そうなのか?」と疑問が湧いた。修正は即座にリリースするようにすれば、リリース作業のコストに対するヘイトが高まって、リリース作業を「自分が」改善しようという動きのもとになる力学になるんじゃないか。

9時間睡眠

今日は9時間ほど寝たが、スッキリした気分で目覚めることができた。9時間がベストな睡眠時間に近いのかもしれない。

もっとうまくやる方法はないか

  • 今作っている機能のユーザーテストのシナリオが、実際の環境とかけ離れている部分がないか検証し、そこを少しでも近づけられるように修正してみる。
  • ミーティングでアイスブレイクを入れた or そんな雰囲気になったら、議論のスタートがわかるように全員にハッキリと宣言してみる。(自分がファシリテーションしている場合も、そうでない場合も)
  • とりあえず、何か不具合をみつけたら緊急リリースしてみる。リリース作業をたくさんこなして、リリース作業に対する個人的なヘイトを高める。
  • 8時間寝たらどういう気分になるか試してみる。