新しいことは小さく、単純に始める

新しい試みや、実験的なプロジェクトはとにかく小さく、単純に始めたほうがいいという話です。

当たり前のことだと思うかもしれませんが、実践するとなると意外と難しいです。いつのまにか余計なものがくっついて規模が大きくなったり、条件や内容が複雑になったりします。

そうならないようにするにはどうするべきか、そして、そもそもなぜ「小さく、単純に」が重要なのかを解説していきます。

「小さく単純に」があてはまるのはどういうケースか

すべてのことにあてはまるわけではありませんが、あてはまる範囲は広いです。

方向性の定まっていない試みや探索的なプロジェクトの場合は特に有効です。

例えば、下記のようなケースです。

顧客データを使って新しいCRMを始めるとき
新しい営業手法を試してみるとき
チームに新しいコミュニケーションツールを導入するとき

プロジェクトによって進め方は千差万別なのであくまで例えばという話ですが、「小さく単純に」というのがどういうことかというと、

新しいCRMプロジェクトであればクライアントの分類を単純に適応する手法も2種類にする
営業手法の実験であればまずは1人で始める、旧手法からの変更点は1つだけにする
チャットツールをチームに導入する場合は狭い範囲で最低限の機能を使ってもらう

という感じです。

なぜ「小さく、単純に」始めるのがいいのか

「始める」ことに対する心理的ハードルが低くなる

新しい試みはまず始めることが最重要ですが、大規模で複雑なことが最初からやろうとすると、想定される作業量の多さに尻込みしてしまい最初の一歩が踏め出せなくなります。

新しい試みの最大の敵は「始められない」ということなのです。

できる限り最初の作業やコストを小さくすることで、まず行動に移すことができます。

プロジェクトの方向性を早い段階で見極められる

小さい試みやテストは成否の結果が早い段階で出ます。

結果が早く出れば、その結果をふまえて、また次のテストや作業に進むことができます。つまり、テストを短い期間で複数回できるということになります。

それによって、進むべき大まかな方向性が合っているかどうかの確認が早い段階でできます。間違っていた場合は早い段階で軌道修正できます。

またテストの内容が単純であれば成否の要因も判断しやすいので軌道修正が的はずれなものになりにくいというメリットもあります。

コスト的な理由

プロジェクトを大きく始めると当然、投資額は大きくなり、失敗したときの損失が大きくなります。

失われるのはお金だけではなく、そのプロジェクトの費やした時間も無駄になります。

時間とお金をかけてしまうと心理的にも組織的にもプロジェクトが畳みづらくなるというデメリットもあり、結果、撤退判断を誤る可能性も高くなります。

上司の承認

上記のコストの話とも関連しますが想定される最初の投資（お金や時間）が大きいと、プロジェクトを始めることに対して上司からGOサインが出にくくなります。

また、上司を説得するためにはそのプロジェクトの意義を説明する必要がりますが、内容が複雑なものは理解されにくいです。

上司は現場の細かいことや技術的なことをわかっていない場合が多いので、特に説明は大変です。

うまく理解させることができなかった場合は、投資額大きい場合と同様にGOサインが出にくくなります。

そういう事態を避けるためには「そのプロジェクトは何をしようとしているのか」、「そのプロジェクトがうまくいくとどういうメリットがあるのか」を誰でもわかるレベルで説明する必要があります。

プロジェクトの設計を単純にし、「要はこういうことです」と一言で説明できるくらいが理想的です。

「小さく、単純に」の障害になるもの

○○も考慮したほうがいいという意見

考慮したほうがいいと言われれば、否定できないことが多いです。いくらでも時間とお金があるのであれば、全てのことを考慮したほうがいいに決まっているので。

そういう意見は一見正しいそうに聞こえますが、間違っています。いかに削ぎ落とすかということを強く意識しましょう。

周囲に対しては小さく、シンプルにすることをしっかり説明します。

大抵の人は小さく始めることに対しては寛容ですが、シンプルにすることに対してはけっこう反対派が出てきますので、それを退ける勇気が必要です。

正確に精密に考えたり、関係者全員が納得するものをと考えたりすると設定はどんどん複雑になります。
結果、「小さく、単純」からどんどん離れていってしまうので要注意です。

打ち合わせ

〇〇したほうがいいという意見が大量に出るのが打ち合わせです。特に部会やチーム会など中規模の打ち合わせはその傾向が顕著です。

そういう打ち合わせは極力減らしましょう。

意見をもらった以上、無下にできないという感情も働き、どんどん余分な要件や検討事項が増えていきます。

とはいえ、他人の意見を聞くことは重要なので頼りになる特定の人にヒアリングするのがおすすめです。

様々な角度や見地から意見ともらったほうが三個になるので、ヒアリングする人の得意分野や担当部署は分散させます。

やっていることを自体を報告、共有しておかないとまずいので打ち合わせの場を設けるという人も多いと思いますが、初期の段階では関係者全員の認知、承認を得る必要はありません。

まずは1つ2つ、手堅いアウトプット出してからで十分間に会います。

打ち合わせにはかなり時間も取られます。メリットはほとんどありません。

スケールすることについて

単純に始めて成功したものを複雑にするほうがその逆よりもハードルが低いです。

目に見える結果があればそれに追加の時間をかけることに対して周囲の理解が得られやすいからです。

スケールしていく時に急にレベルを上げないように気をつけましょう。あくまで漸進的に複雑にしていきます。

まとめ

以上が新しいことをはじめる時に心がけるべきことです。

進め方をまとめると下記のようになります。

まずは1人でできる範囲で通常業務の余剰の時間を使ってやる
- 1人でできる範囲の実験、テストを進める
- それを他人に説明できる形にまとめる
- ある程度意味があるアウトプットであれば次のステップに
頼りになる数人に趣旨説明（公式な場ではなく）
- アドバイス、意見をもらう
- 集合知に陥らない範囲でアドバイスを反映
- 軌道修正してさらにアウトプットを出す
  - 条件を変えて追加で複数のテストを実施するなど
- それでも意味のありそうなアウトプットが出せれば次のステップに
より広い範囲にアウトプットを共有する
- 自分の所属するチームや部署
- さらには自分の上司
- 実験の規模を広げたり、予算を確保するために意味のあるプロジェクトであることを説明する