見出し画像

「スピード重視」という思考停止を今すぐやめよう。

こんにちは。まつあきです。

僕は普段、数千人規模のITベンチャーでWEB寄りのマーケティング職として仕事をしています。僕が属しているような、マーケティング(特にデジタル)やWEB制作に関わる領域では「スピード重視」「まずは小さく始めてPDCAを回そう」と言った思想は当たり前になっていると思います。

僕も、この考え方は間違っていないと思うし、普段から心がけているとても大切な考え方です。
ちょっと大げさに言えば、現代社会において明日どんなパラダイムシフトが起こるか分からないし、どんなに考えても想定できないようなことが1回のスプリントで見えてくる、ということも往々にしてあります。
だからこそ、日々の仕事の中でのちょっとした発見にワクワクするし、全く予想もしていなかったような大きな成果が出ることがあるのが、変化の早い時代や業界で働く醍醐味だとも思います。

ただ、この当たり前になっている「スピード重視」という考え方は、万能な成功法則ではありません。あえて断言すると、「スピード重視」であるということだけでなんとなく正しいような感覚になるのは、単なる思考停止です。
特に「クオリティ重視」という考え方の対として、どちらかを立たせるとどちらかが立たないというトレードオフ関係として語られるときには注意が必要です。

「やってみないと分からない」「ただ考えてても答えは出ないから、まずはやってみよう」

こういう言葉が出てきたら、とても危険な状態だと思っています。

今回の投稿を一言で表すなら「スピード重視とクオリティ重視はトレードオフではない」ということです。「スピード重視」という言葉は、使われ方によってはとても危険な言葉であり、場合によっては思考停止してしまっている状態だということを述べていきたいと思います。そして「スピード重視」という言葉の健康的な状態はどういうものか、本当にパフォーマンスが上がる「スピード重視」とはどういうものなのか、僕なりの考えを提案したいと思います。

結果として今回の投稿が、読んでくださっている方の仕事やプライベートな活動を少しでも楽しくワクワクするものに、何らかの参考になればとても嬉しいです。

「スピード重視とクオリティ重視はトレードオフではない」なんて、当たり前。それがどうしたの?という方は、特に目新しい話はないと思うので、ここで読み終えていただいて大丈夫です。長い冒頭にお付き合いいただきありがとうございます。またの機会にお会いしましょう!
※Twitterでもっと雑多なことをつぶやいていますので是非フォローだけお願いします!(意見交換も大歓迎です)


スピード重視は手法の話、クオリティはあくまで求める結果

業種や職種の違いはあれど「スピード重視で試してみる」という言葉が出るタイミングは、おおむね下記のようなサイクルで業務を回したり、企画をしているような場合ではないでしょうか。

①なにか業務上の解決したい課題や達成したい目的がある
②そのための実行施策を検討する
③その実行施策の具体的なアクションプラン、実装方法、スケジュールを決める
④実行し、検証する
⑤検証結果を元に施策をアップデートする、または次の企画に活かせるよう検証結果を整理する

例えば、ECサイトを運営されているディレクターの方であれば、下記のようなプロセスで改善施策を実施するのは日常的に行われているのではないでしょうか。

① 「自分が運営しているECサイトのカート落ちが他サイトに比べて非常に悪い」という課題を発見した
②ユーザーがカートに商品を入れてから購入を完了するまでの導線を整理するため、購入画面のデザインを変更する企画を立てる
③実際にそのデザインをリリースするまでのタスク、ページ仕様、実装方法、スケジュールを他部署や専門の担当者と連携しながら決めていく
④リリースし、旧デザインと新デザインのパフォーマンスを比較する
⑤成果を上司やチームに報告し、次の企画を検討する

ECサイトのディレクター業務以外でも、デザイナー、エンジニア、マーケティング職などそれぞれの業務でもイメージが湧きやすいプロセスだと思いますし、日々の活動の改善を積み重ねている営業やサポート職の方もイメージに難くないのではないかと思います。

上記の流れは基本的に①から⑤にかけて進み、場合によっては前のフェーズに戻ったり、一旦概要だけ決めて先に進んでみたり、ということの繰り返しで実行されていきます。

僕はこの標準化された一般的な改善プロセスの中で、「スピード重視」と「クオリティ重視」は考えるべき範囲が異なると考えています。

すなわち、クオリティは①〜⑤の全体に対して影響がある要素なのに対し、スピードは③〜⑤の手法に関わる要素です。
先程のプロセスの流れに、それぞれ重視すべき考え方を割り振ると下記のようになると思います。

①【クオリティ】なにか業務上の解決したい課題や達成したい目的がある
②【クオリティ】そのための実行施策を検討する
③【クオリティ+スピード】その実行施策の具体的なアクションプラン、実装方法、スケジュールを決める
④【クオリティ+スピード】実行し、検証する
⑤【クオリティ+スピード】検証結果を元に施策をアップデートする、または次の企画に活かせるよう検証結果を整理する

言い換えると、

クオリティを上げるために解決すべき課題はなにか、達成すべき目的はなにか
クオリティを上げるための実行施策はなにか
クオリティを上げるためのアクションプラン、実装方法、スケジュールに対し、さらにスピードを考慮するならどうすべきか
クオリティを上げるための実行と検証を、さらにスピードを考慮するならどうすべきか
クオリティを上げるため検証結果を元に施策のアップデートをスピードを考慮して実行するにはどうすべきか。または、次回クオリティを上げるための施策を手っ取り早く情報が使える形に情報を整理するにはどうすべきか。

クオリティを上げることはあくまで目的であり最終的に求める結果のため、一連の改善プロセスの全ての過程で考慮する必要があります。一方で、スピードを上げることは手法の問題であり、「どうやって実行するか」ということを考える段階になって初めて考えるべきことなのです。

決してスピーディに施策を実行すること自体が、最終ゴールになることはありません。あくまで求めるべき結果はクオリティです
このクオリティとは、ECサイトのディレクターであればECサイトの売上でしょうし、デザイナーやエンジニアであれば対象としているプロダクトの目標や目的でしょう。マーケティング職であれば向き合っているサービスのバリュー向上だと思いますし、営業職であればやはり売上成績になってくると思います。それらを達成するために、場合によっては「スピード」が重要になるときがあるのです。

「たくさんPDCAを回す」ことは、現場では大きな罪

とは言っても「たくさんPDCAを回すことで何か新しい情報を発見できるから最終的には良い結果になるじゃないの?」という見方もできると思います。数打てば当たる戦法ですね。
僕は、この「たくさんPDCAを回す」ということも基本的には思考停止の状態であると思っています。「たくさんPDCAを回す」ということも手段であり、目的ではないためです。限られたリソースを最適に分配しながら成果を最大化させたい場合、たくさんPDCAを回すこと自体は全く良いことではありません。むしろ精度を高めて少ない試行回数で最適解に導くことが、結果的にクオリティ面でも、スピード面でも、コスト面でも良い結果になると思います。「たくさんPDCAを回すためにスピード重視であるべき」という発想は最悪な状態であり、むしろ大きな罪だとさえ思います。

健全で効果的な「スピード重視」

では最後に、推奨されるべき「スピード重視」というものはどういうものなのか、「スピード重視」をどのように実践すべきなのか、僕の考えをまとめていきたいと思います。   

端的に言えば、「試行回数をできるだけ少なくクオリティの向上を達成するためのスピード重視」であることだと思います。たくさんPDCAを回すことも、スピーディに業務を実行することも、最終的な目的ではないはずです。WEBサイトのディレクターであれ、デザイナーであれ、エンジニアであれ、マーケターであれ、いま目の前に置かれている実施すべき仕事はすべてユーザー(やお客さん)のための仕事であるべきで、その結果としての事業貢献のためであるべきです。

①【クオリティ】なにか業務上の解決したい課題や達成したい目的がある
②【クオリティ】そのための実行施策を検討する
③【クオリティ+スピード】その実行施策の具体的なアクションプラン、実装方法、スケジュールを決める
④【クオリティ+スピード】実行し、検証する
⑤【クオリティ+スピード】検証結果を元に施策をアップデートする、または次の企画に活かせるよう検証結果を整理する

①から⑤の改善プロセスの中で、僕は①と②に「スピード重視」という考え方を持ち込むべきではないと考えています。むしろ①と②で、何を解決し何を達成すべきで、そしてそれを達成するために最も効果的な施策はなにか。それをじっくりじっくり考えて企画をすることこそが、その後の施策を実行して最終的に成果が出るまでのスピードを決定すると考えています。

無駄打ちを少なくすることにはコストを下げるということだけでなく、もう一つ効用があります。自分自身やチームの士気(モチベーション)の維持です。場合によっては、あなたを評価する上司のプロジェクトに対する興味も含むかもしれません。
取り組んでいる仕事が事業やユーザーのためにどのように貢献しているのか明確でなく部署やチーム内になんとなく停滞感が生まれた、という経験は誰しも1回はあるのではないでしょうか。無駄打ちが多くなると関係者は疲弊し、「なんとなくダメかも」という雰囲気がチームを覆います。そして徐々にその停滞感がチームの士気を奪い、「今回もダメかも」といういわゆる負け癖が出てきます。ダメでもともとという発想から勝ちパターンは出てきません。
「1万回バットを振り続けてダメでも、1万1回目で満塁ホームランを打つことができた!」という美談は、現実にはとてもツラく過酷なものです。日常業務の中では精度を高め少ない試行回数でヒットを出すことのほうが精神衛生上は健全と言えるでしょう。

「スピードを重視する」ためには、逆説的に、解決したい課題や達成したい目的を明確にするプロセス(①のプロセス)や実行施策の企画(②のプロセス)にじっくりじっくり時間を掛けることが大事なのではないかと考えています。急がば回れ、選択と集中、あなたとあなたのチームの有限で貴重な時間や労力が、最大限活用されることを願っています。

最後に、以前たまたま出会って参考になった「問題を先送りにすることは悪と思われがちだけど、実はそんなこともないよ」というTEDの動画をご紹介します。

※もしよろしければTwitterのフォローもお願いします!


この記事が気に入ったらサポートをしてみませんか?