とりあえずやってみようの影に潜む勘違い
こんちには tacoyaky(たこやき)です。
今日はめずらしく仕事の仕方についてです。
最速にみえる進め方に潜む影(落とし穴)
とりあえずやってみよう。やってみれば気付きが得られるからそれをもとに改善を重ねて速く前に進もう。
この考え方や進め方は非常に賛成です。
特に不確実性が高い状況においてトライアルを重ねて進むことは非常に有効な手段です。
しかし、そこには大きな勘違いが潜みやすいとも感じています。
わりと陥りやすい落とし穴なんじゃないかと思います。
トライアルをやってみるというのは、何か試したいことがあるから実行できるのです。
手段を試す? ユーザ体験(UX)を試す? プロダクトを試す?
いずれにしても何をどのように試したいのかという設計が重要です。
試すということはその結果を検証する必要があります。
検証するためには比較する必要があります。
比較をするためには検証項目(変数)以外はできるかぎり条件を揃えることが望ましいです。
変数が定まっていなかったり多すぎたりすると結果がぼやけて適切に検証することができません。
とりあえず動けば初動が速く見えてやってるふうに見えるかもしれませんが、効果検証やその後の改善完了までのプロセス期間でみると設計が不十分だと手戻りや停滞期間が増えてしまって逆に遅くなってしまいます。
結果的に時間もお金も無駄にします。 有り余る余裕があるのならそれを楽しむのもよいかもしれませんが、なかなかそんな状況なんてなく最速で成果にたどりつくことが求められますよね。
試行(トライアル)と見切り発車は別モノ
なんでもかんでもとりあえずやってみるのがいいとは限りません。
「試したいことが明確なトライアル」と「なんとなくとりあえずやってみる」はまったくの別モノです。
考えなしにやってみるのは、勇敢でもなんでもなく単なる「見切り発車」です。
自分ひとりでやるならまだしも協力者が必要な場合、その人達を振り回したあげくになかなか進まないという状況になります。
振り回されている人はたまりません。フラストレーションがたまります。
はじめはポジティブに参加していた人も次第にモチベーションが下がってしまいます。よくないスパイラル。
せっかくならみんなでポジティブに取り組みたいものです。
時間がなかったりプレッシャーがかかる状況だったりすると落ち着いて判断できなくなって、しっかり設計してから進むことは難しいことが多いと思います。
多くのことは概要だけ決めて走り始めてよいと思いますが、「何を検証するのか」ということだけは明確に決めて関係者と合意形成をして進めないといけません。
そして、トライアルが進んで不確実性が変化することがでてきたら振り返りと向き直りを行い、次に検証することを決めてトライアルと改善を繰り返すのです。
まとめ
ちょっと思うところがあり、自戒の念も込めて私の考えを書き出してみました。
どんなことにもいえることですが、どんなに優秀な手段やツールも正しく使えないと効果を発揮することができません。適切に使うことが重要です。
最後までお読みいただきありがとうございました。
みなさんにもなにか気付きがあれば幸いです。
◎ 関連投稿 ◎
◎ o ◎ o ◎ o ◎ o ◎