UNIX的なアレ

UNIX的なこととかいろいろ

新規事業と「ざっくり力」

新規事業ってあまりにも変数が多すぎて考えないといけないことだらけです。本来であれば一定以上はやってみないとわからないものだらけなのですが、どうしても細かいリスクに目が行きがちで議論が深まってしまいます。

本来であれば、とにかく意思決定は早くしプロジェクトをどんどんと前にすすめるほうが見えることも多いです。

しかしなかなかそうはいかないこともあるのが現状。そのときに使えるスキル「ざっくり力」というものに会話をしていて気づきました。

立ち上げ時のワナ

まずありがちなのが、細かなリスクやこういうときにこうだったらというとにかく多くのケースの想定です。

当然、出来る限りリスクを想定しておくことは大事なのですがこのリスクを潰そうとすることをやりすぎてしまうとプロジェクトがなかなか前に進みません。とくに「予算が多い」「関わる人間が多い」となるとそうなりがちかなと思います。

確かにそれは間違ってはいないと思いますし、ベンチャーではない大企業の新規事業立ち上げになるとどうしてもプロジェクト内だけで決められることは一定で、関わる部署すべてが納得するための材料づくりなどが必要になってきます。しかし、それによって失うものが出てきます。

慎重すぎることで失うモノ

結局、最終的にはやってみなければプロジェクトが成功するかどうかなんてわかりません。そもそも方向性が合っていたのか、市場に受け入れられるものなのかというのはいくら市場調査をしても答えは出てきません。

だからこそ、ある程度の段階で意思決定をしプロジェクトを進めていくほうが早期の段階で気付きを得ることができ、またそれをプロジェクトの改善へとつなげることができると思います。

ざっくり力が新規事業を救う

そこで活かせるスキルは何か。それを「ざっくり力」と呼んでみました。

当然、ざっくりと言っても適当に決めるわけでもないし、他の人のことを無視するという意味ではありません。ただ、一定以上の変数にはある程度目をつぶり、「決め」を作ることである程度の方向性を仮設としてつくってしまうというものです。

プロジェクト内にいる意思決定者がこのスキルを持っていることで、プロジェクトはとにかく前にすすみます。

そして、リリースまでいかなくてもざっくり決めておいた仕様が実際にプロダクトとして見えてくることで初めて見えてくる問題点もたくさんあります。

スクラムとざっくり力

まさにこのざっくりした意思決定はスクラム開発に向いているものだと思います。いま開発しているプロダクトでも実際にそのような流れをとっていて、

  1. 細かなバグは許容し、最低限うごくプロダクトをつくる
  2. ある程度うごくプロダクトを触って、再度判断する
  3. 必要な軌道修正をした上で、プロダクトを作り込む

のような流れで開発をすすめることができます。

このようにスプリントをただの開発期間とだけ定義するのではなく、それぞれに意味をもたせることでよりプロダクトの軌道修正がしやすくなります。

エンジニアリングにざっくり力は必要か

とはいえ、コードを雑に書くという意味ではありません。あくまでプロダクトの意思決定をざっくりしようという意味です。それに対してエンジニアができることは、「常に変わりうる仕様に耐えるコードを書く」ということです。

そのために継続的インテグレーションやデリバリーの仕組みを導入し、ざっくり開発をできるための硬いベースを作っておくというのが重要になってきます。

ざっくり = 適当 ではない

改めて記述しますが、ここで言う「ざっくり」は適当とは違います。ある程度考え抜かれた上で、一定以上のことは一旦考えずにプロジェクトを進める力という意味です。

当然、その意思決定をする人は責任を背負いますしリスクはあります。また、どのレベルまでざっくり決めるべきかというのもプロジェクト次第ではあります。

ただ、あまりにも細かい点が気になりすぎてプロジェクトが前にすすまないと思うときがあったら必要以上に考え過ぎかもしれないことを振り返ってみてもいいかもしれません。