UNIX的なアレ

UNIX的なこととかいろいろ

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

コラム Business

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

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

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

立ち上げ時のワナ

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

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

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

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

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

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

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

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

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

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

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

スクラムとざっくり力

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

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

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

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

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

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

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

ざっくり = 適当 ではない

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

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

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

チャレンジするなら若い方がいいし、失敗の数だけ強くなる

http://www.ishidanohanashi.com/entry/2016/09/15/193000www.ishidanohanashi.com

なんか思ったより厳しい大人が多いなぁと思うのですが、僕は個人的にすごく応援したいと思っています。世の中にはいろいろな18歳がいると思うんですけど、少なくとも自分はごく普通の18歳だったのでこんな選択肢は出てこなかったんですよね。

僕自身は、普通に大学を卒業して普通にそこそこ大きい会社で新卒として4年くらい働いて、共同創業者として起業したという経歴です。なので起業に関しては1回しか経験をしていないわけですが、これがなんどか経験していたらもっとうまくやれたんだろうなぁなんて反省は沢山ありました。

確かに彼の行動って若さ故の過ちのように見えます。でもこういったチャレンジをしていくのって早いほうが良いと思うんです。たぶん、本当に大変なことだらけだろうし、失敗しても学ぶこともたくさんある。それでも、またチャレンジすればいいだけだと思うんです。僕がCTOをつとめていたnanapiは立ち上げてからM&Aされるまで約5年間だったけど、いま彼が起業して5年後にM&Aされてもまだ23歳なわけです。嫉妬しそうになるくらいに若い。

人生の中で今が一番若いのは誰にも共通していること。大学辞めなくてもというのも意見の一つではあると思う。でもやらない理由なんていくらでも見つけられるので、自分からすぐに戦わざるを得ない環境をつくるというのは戦略のひとつとしてあると思う。

自分が何者であるかを決めるのは自分自身だし、そうやって胸はって生きていくのがいいよね。

実機転送できなくなったとき

iOS

実機転送時のエラー

f:id:wadap:20160823110326p:plain

普段開発してる環境と別のとこでビルドしたら出てくる時があるコイツ（台風のため家で普段と違うマシンでやったら出た）

対処法

f:id:wadap:20160823110428p:plain

キーチェーンアクセスから探して「この証明書は取り消されました」ってやつを消せばOK。

スタートアップにおける点の正義と線の合理性

テストを書くかどうかみたいな話がよく議論に上がりますが、毎回賛否両論なわけです。CTO向け1on1を続けていく中でも近い話がよく議題としてあがりました。

wadap.hatenablog.com

当然な話でどっち側の意見も間違っているわけではなく、話している背景が違うのが根本的な原因なんだと思っています。そこを自分なりに考えをまとめてみました。

点で語る正義

これはまず一方からだけみた正しい回答のことを指します。まずこの点でみたらテストの議論に関して言えば当然「書いたほうが良い」という結論になります。会社の経営的な話で言えば「赤字よりも黒字のほうがいい」ですし、人事観点だけで言えば「人はやめないほうが良い」という事になります。

点で語ることは非常に大事なことですし、世間に様々な先人の知恵があります。点だけでみると変数は少なく、判断しやすいと思います。一方で圧倒的な正義になりやすく、これを振りかざされてしまうと正直なところ反論が難しい。なぜならその点においては間違っていないからです。

線からみた合理性

一方で、ビジネスというものは点だけでは成り立ちません。どんな組織であれ会社である以上は、何らかの収益を生み（もしくは生むことを目的とし）プロジェクトを進めていきます。そうなると、点で語るべき正義がどんどんと増えていきます。

エンジニアだけの組織であれば点の正義だけで通用しやすいと思いますが、お金のことが絡んできたりするとどうしても合理性も考慮して考えないといけないことは多々あります。そのため、技術的な正当性よりもリリースが優先されるようなことが起きます。一方でこの合理性という観点だけでも非常に危うい側面をもっていて、むちゃくちゃな労働環境などはこちらの合理性のみの観点から生まれるものです。

なのでこの二点はAll or Nothingではなくバランスが必要というわけですが、このバランスは事業の特性よって大きく左右されるのではないかと思います。

ビジネスモデルが成立している場合

ある程度市場が確率していて、ビジネスモデルがたてやすい場合は新しく始めるとしても既存の仕組みのリプレースに近いものなので、変数は比較的少ない。

ということはある程度の予測はたてることができ、それに応じた経営ができるということになります。こうなると最初から合理性だけで突き進むのは危うく、点の正義を最初から意識したプロダクト開発が必要になる。ピボットする可能性は低く、固く作ることそのものがプロダクトの価値になるからです。

ビジネスモデルが確立していない場合

スタートアップに多いケースですが、ビジネスモデルがないけどなんかでかいチャンスがありそうみたいなケースがこちらです。こちらに関して言うと、いま進んでいる方向が正しいのかどうかなんてまぁわからないのが普通です。

BtoCのサービスなんて暗中模索の中進んでいき、小さなピボットを繰り返し、偶然からうまれるマネタイズで奇跡的に成功するみたいなものだと思います。

こうなるとどうしても目の前の合理性のほうが重要視され、リリースが再優先になってきます。程度の違いはあれど、どうしてもそうなる傾向にある。サービスの進化という点において立ち止まってられない時期はあります。

大事なことは経営とのコンセンサス

そのため、自分の目線だけで語ることではなく経営とコンセンサスをとっておくことだと思います。

いまでこそエンジニアが活躍できる会社は増えています。あれもただ総判断したわけではなく、経営陣が会社の成長に必要だという経営判断をしているからです。

とはいえ会社のフェーズによってもこのあたりの判断は変わっていくと思うので、判断基準は固定になるものではなく常にアップデートしていく必要があるのだと思います。

小規模スタートアップの技術的な方々の壁打ち相手的なことをやります

ひとことで言うと

CTOや技術の統括をしている小規模ベンチャーの人に対して、1on1をします

どういうこと？

CTO的な方だったりとか、技術的なマネージャーをやっている方って様々な悩みがあると思います。当然、それを僕が解決してあげるなんて偉そうなことはできるわけでは無いのですが、コーチング的な感じで話を聞き出すことはもしかしたらできるんじゃないかななんて思いました。

今も紹介ベースで相談とかを受けているのですが、今回はそれを公に募集してみようと思います。

ターゲットとなる方々

  • 小規模スタートアップのCTO
  • エンジニアのメンバーを抱えてるけどうまく回せていない
  • 技術者のマネージャーがいない

あたりでしょうか。

なぜやるの？

  • 自分自身、壁打ち相手がいなくて困ったことがあった
  • 頼みづらく、こういうのがあるといいかなというのをやってみた
  • 自分自身もっと成長したいので、上の立場からというわけではなく、あくまで壁打ち相手として話を聞きたい

※ 補足ですが、リクルーティング活動ではないので安心してください。変な勧誘などもありません。

費用など

費用はかかりません。カフェだったりとか食事を取りながらになると思うので、ご自身の分だけ負担していただければ結構です。

また、日中は働いているので、平日ランチタイム or 土日あたりかなと思います。場所は表参道〜渋谷あたりでお願いします。

どこまでこういうニーズがあるのかわかりませんが、気になったら気軽にご連絡ください。年齢や資格などは全く問いません。

連絡は以下からお気軽にどうぞ。

というかお前誰だよ

nanapiという会社CTOを6年くらいやってました。いまは現場でエンジニアやってます。

ストレングス・ファインダーをうけた

www.gallupstrengthscenter.com

というわけで受けてみました。昔も受けたことあるんだけど結果を忘れてしまっのがちょっと残念。

上位5件の結果

とりあえず上位5件の結果はこんな感じでした。

1. 調和性

調和性という資質を持つ人は、意見の一致を求めます。意見の衝突を嫌い、異なる意見でも一致する点を探ります。

2. 最上志向

最上志向という資質を持つ人は、強みを利用して、平均的ではなく最高の水準を、個人ないしは集団において追求します。単なる強みを最高レベルのものに変えようとします。

3. 自我

自我という資質を持つ人は、他人の目から見て非常に重要な人間になることを望んでいます。独立心に富み、人から認められたいと思っています。

4. 未来志向

未来志向という資質を持つ人は、未来がどのようなものかについて考え、そこからアイデアを得ます。未来についてのビジョンを語ることで、人々を高揚させます。

5. 個別化

個別化という資質を持つ人は、一人一人が持つユニークな個性に興味をひかれます。異なるタイプの人たちの集団をまとめ、生産性の高いチームを作ることに長けています。

下位5件の結果

下位5件はこんなかんじ。

30. 包含

包含という資質を持つ人は、他人を受け入れることができます。人の輪から外れている人に注 意を払い、そのような人を輪に入れようと努力します。

31. 運命思考

運命思考という資質を持つ人は、あらゆる人や物事は互いに結びついていると考えています。この世に偶然というものはほとんど存在せず、ほぼあらゆる出来事には何らかの理由が存在すると確信しています。

32. 成長促進

成長促進という資質を持つ人は、他人の持つ可能性を認識し、それを伸ばし、目覚めさせます。他人の小さな進歩の兆候を見逃さず、このような進歩を実現することから充足感を得ます。

33. 原点思考

原点思考という資質を持つ人は、過去や原型について考えるのが好きです。過去を調べることにより、現在を理解します。

34. 適応性

適応性という資質を持つ人は、「流れに沿って進む」ことを好みます。「今」を大切にし、それぞれの時点で進む方向をひとつずつ選択することにより、将来を見極めます。

気になること

調和性はあるけど適応性がないというなんだか面白い結果。似てるけど異なる性質ってことですね。