母校での講義で、僕が伝えたかったこと
元nanapi CTOの和田修一さんを迎えて中央大学での学生起業授業「ビジプロ2」だん。
— 高橋亮平 (@ryohey7654) 2016年11月10日
熱と想いのこもった講演とその後の質疑応答も盛り上がり、学生たちによるビジネスプランのプレゼンには可能性を感じた。
まだ荒削りだが、昨年に続き今年は複数社がここから起業してくれる事を期待。 pic.twitter.com/kYaW5QEQO1
僕の出身大学で講義をしてきました。ベンチャーの立ち上げだったりを推進している授業のゲストとして呼ばれて、過去の経験やなぜCTOとして起業するに至ったのかみたいお話をさせて頂きました。
「人生でやりたい100のこと」というリストを管理しているのですが、その中に「母校で講義をする」というのがありました。そのため呼ばれたときは本当に嬉しかったです。紹介をしてくれたSkylandVenturesの木下さん、中央大学特任准教授の高橋さんには感謝です。
なぜ講義をしたかったのか
当然、僕は自分自身のことを優秀な人間だとか成功した人間なんて全く思っていません。僕なんかより素晴らしい人間や経験をしている人は沢山いますし、実際にそういった方々の話を聞いて今でもすごく刺激をうけています。
でも、僕だからこそ伝わる内容はあると思っていますし、僕だからこそ伝わる人達に向けてはやっぱり出来る限りの情報を届けたいと思っています。誰もが最初から大きなビジョンを掲げて生きているわけじゃないし、しょうもないことを沢山積み上げながらそのなかでいろいろな選択をし小さな成功を掴んていくわけじゃないですか。そんなことが少しでも伝わったらいいなぁなんて思っています。
なので承認欲求を満たしたいとかそんなチンケなものではなく、社会貢献に近いような思いです。
そんな思いがあったので、ずっと思っていた一つのことを達成できて嬉しく思っています。スライドだけで伝わるのは一部ですが、一応こちらにスライドをおいておきます。
学生向けのキャリアの考え方的なことも話せたので、話してくれみたいなのがあればいつでも伺います。
未来を思い出す
「未来を思い出す」っていう言葉を考えなしに発声してみたら「名言だ」と言われたんですけど、どういう意味なんでしょうね。世の中にある名言の5%くらいはこういうノリで作られていますよね。
— けんすう (@kensuu) 2016年10月6日
少し前にこんな会話を雑くしてたことがあったのですが、個人的には割りと好きな言葉だったんですね。結構自分の考え方というか思考法がまさにこんな感じなので少し書いてみたいと思います。
結構、僕は未来というか将来こうなっていたいというイメージとか想像をよくするほうで○○年後で何歳のときはこうなっているみたいなイメージが強いと思います。
仕事は当然ですが、それだけでなくプライベートも含めかなり具体的にイメージをしていたりします。住んでいる家や持っているもの、一日のスケジュール、そのときにやっていたい趣味とか体重などなど。そのイメージを強く持っていると、比較的近い将来がやってくるなという実感があります。
当然、数年単位でズレることはありますしすべて思い通りの未来がやってくるというわけではないんですけど、想像できる未来がたぶん最上級なんですよね。どうあがいても想像している以上の自分になることはないので、できるかぎり良いイメージをし続けるということを意識しています。この良いイメージってのは社会的な成功に限った話ではなく、人としてどうなりたいかというところですね。
そのイメージを強くしすぎると、自分がその未来に立っているような気がしてきて、近い未来なんて過去のように感じてしまうくらいに思い出すことができてしまいます。だから未来を思い出すという言葉が意外としっくりきた、というところでしょうか。
一つ問題があって、これをやりすぎて本当に自分の年齢を勘違いしてしまうことがあるという問題があります。
新規事業と「ざっくり力」
新規事業ってあまりにも変数が多すぎて考えないといけないことだらけです。本来であれば一定以上はやってみないとわからないものだらけなのですが、どうしても細かいリスクに目が行きがちで議論が深まってしまいます。
本来であれば、とにかく意思決定は早くしプロジェクトをどんどんと前にすすめるほうが見えることも多いです。
しかしなかなかそうはいかないこともあるのが現状。そのときに使えるスキル「ざっくり力」というものに会話をしていて気づきました。
立ち上げ時のワナ
まずありがちなのが、細かなリスクやこういうときにこうだったらというとにかく多くのケースの想定です。
当然、出来る限りリスクを想定しておくことは大事なのですがこのリスクを潰そうとすることをやりすぎてしまうとプロジェクトがなかなか前に進みません。とくに「予算が多い」「関わる人間が多い」となるとそうなりがちかなと思います。
確かにそれは間違ってはいないと思いますし、ベンチャーではない大企業の新規事業立ち上げになるとどうしてもプロジェクト内だけで決められることは一定で、関わる部署すべてが納得するための材料づくりなどが必要になってきます。しかし、それによって失うものが出てきます。
慎重すぎることで失うモノ
結局、最終的にはやってみなければプロジェクトが成功するかどうかなんてわかりません。そもそも方向性が合っていたのか、市場に受け入れられるものなのかというのはいくら市場調査をしても答えは出てきません。
だからこそ、ある程度の段階で意思決定をしプロジェクトを進めていくほうが早期の段階で気付きを得ることができ、またそれをプロジェクトの改善へとつなげることができると思います。
ざっくり力が新規事業を救う
そこで活かせるスキルは何か。それを「ざっくり力」と呼んでみました。
当然、ざっくりと言っても適当に決めるわけでもないし、他の人のことを無視するという意味ではありません。ただ、一定以上の変数にはある程度目をつぶり、「決め」を作ることである程度の方向性を仮設としてつくってしまうというものです。
プロジェクト内にいる意思決定者がこのスキルを持っていることで、プロジェクトはとにかく前にすすみます。
そして、リリースまでいかなくてもざっくり決めておいた仕様が実際にプロダクトとして見えてくることで初めて見えてくる問題点もたくさんあります。
スクラムとざっくり力
まさにこのざっくりした意思決定はスクラム開発に向いているものだと思います。いま開発しているプロダクトでも実際にそのような流れをとっていて、
- 細かなバグは許容し、最低限うごくプロダクトをつくる
- ある程度うごくプロダクトを触って、再度判断する
- 必要な軌道修正をした上で、プロダクトを作り込む
のような流れで開発をすすめることができます。
このようにスプリントをただの開発期間とだけ定義するのではなく、それぞれに意味をもたせることでよりプロダクトの軌道修正がしやすくなります。
エンジニアリングにざっくり力は必要か
とはいえ、コードを雑に書くという意味ではありません。あくまでプロダクトの意思決定をざっくりしようという意味です。それに対してエンジニアができることは、「常に変わりうる仕様に耐えるコードを書く」ということです。
そのために継続的インテグレーションやデリバリーの仕組みを導入し、ざっくり開発をできるための硬いベースを作っておくというのが重要になってきます。
ざっくり = 適当 ではない
改めて記述しますが、ここで言う「ざっくり」は適当とは違います。ある程度考え抜かれた上で、一定以上のことは一旦考えずにプロジェクトを進める力という意味です。
当然、その意思決定をする人は責任を背負いますしリスクはあります。また、どのレベルまでざっくり決めるべきかというのもプロジェクト次第ではあります。
ただ、あまりにも細かい点が気になりすぎてプロジェクトが前にすすまないと思うときがあったら必要以上に考え過ぎかもしれないことを振り返ってみてもいいかもしれません。
チャレンジするなら若い方がいいし、失敗の数だけ強くなる
http://www.ishidanohanashi.com/entry/2016/09/15/193000www.ishidanohanashi.com
なんか思ったより厳しい大人が多いなぁと思うのですが、僕は個人的にすごく応援したいと思っています。世の中にはいろいろな18歳がいると思うんですけど、少なくとも自分はごく普通の18歳だったのでこんな選択肢は出てこなかったんですよね。
僕自身は、普通に大学を卒業して普通にそこそこ大きい会社で新卒として4年くらい働いて、共同創業者として起業したという経歴です。なので起業に関しては1回しか経験をしていないわけですが、これがなんどか経験していたらもっとうまくやれたんだろうなぁなんて反省は沢山ありました。
確かに彼の行動って若さ故の過ちのように見えます。でもこういったチャレンジをしていくのって早いほうが良いと思うんです。たぶん、本当に大変なことだらけだろうし、失敗しても学ぶこともたくさんある。それでも、またチャレンジすればいいだけだと思うんです。僕がCTOをつとめていたnanapiは立ち上げてからM&Aされるまで約5年間だったけど、いま彼が起業して5年後にM&Aされてもまだ23歳なわけです。嫉妬しそうになるくらいに若い。
人生の中で今が一番若いのは誰にも共通していること。大学辞めなくてもというのも意見の一つではあると思う。でもやらない理由なんていくらでも見つけられるので、自分からすぐに戦わざるを得ない環境をつくるというのは戦略のひとつとしてあると思う。
自分が何者であるかを決めるのは自分自身だし、そうやって胸はって生きていくのがいいよね。
iOS10でSSKeychainがうごかない
まず、いつの間にかSAMKeychainなんて名前になってた。
https://github.com/soffes/SAMKeychain/issues/149
let foo = SAMKeychain.passwordForService("hoge", account: "fuga")
でsetしていた値が返って来なくなる。KeychainSharingをONにして解決。
実機転送できなくなったとき
実機転送時のエラー
普段開発してる環境と別のとこでビルドしたら出てくる時があるコイツ（台風のため家で普段と違うマシンでやったら出た）
対処法
キーチェーンアクセスから探して「この証明書は取り消されました」ってやつを消せばOK。
スタートアップにおける点の正義と線の合理性
テストを書くかどうかみたいな話がよく議論に上がりますが、毎回賛否両論なわけです。CTO向け1on1を続けていく中でも近い話がよく議題としてあがりました。
当然な話でどっち側の意見も間違っているわけではなく、話している背景が違うのが根本的な原因なんだと思っています。そこを自分なりに考えをまとめてみました。
点で語る正義
これはまず一方からだけみた正しい回答のことを指します。まずこの点でみたらテストの議論に関して言えば当然「書いたほうが良い」という結論になります。会社の経営的な話で言えば「赤字よりも黒字のほうがいい」ですし、人事観点だけで言えば「人はやめないほうが良い」という事になります。
点で語ることは非常に大事なことですし、世間に様々な先人の知恵があります。点だけでみると変数は少なく、判断しやすいと思います。一方で圧倒的な正義になりやすく、これを振りかざされてしまうと正直なところ反論が難しい。なぜならその点においては間違っていないからです。
線からみた合理性
一方で、ビジネスというものは点だけでは成り立ちません。どんな組織であれ会社である以上は、何らかの収益を生み（もしくは生むことを目的とし）プロジェクトを進めていきます。そうなると、点で語るべき正義がどんどんと増えていきます。
エンジニアだけの組織であれば点の正義だけで通用しやすいと思いますが、お金のことが絡んできたりするとどうしても合理性も考慮して考えないといけないことは多々あります。そのため、技術的な正当性よりもリリースが優先されるようなことが起きます。一方でこの合理性という観点だけでも非常に危うい側面をもっていて、むちゃくちゃな労働環境などはこちらの合理性のみの観点から生まれるものです。
なのでこの二点はAll or Nothingではなくバランスが必要というわけですが、このバランスは事業の特性よって大きく左右されるのではないかと思います。
ビジネスモデルが成立している場合
ある程度市場が確率していて、ビジネスモデルがたてやすい場合は新しく始めるとしても既存の仕組みのリプレースに近いものなので、変数は比較的少ない。
ということはある程度の予測はたてることができ、それに応じた経営ができるということになります。こうなると最初から合理性だけで突き進むのは危うく、点の正義を最初から意識したプロダクト開発が必要になる。ピボットする可能性は低く、固く作ることそのものがプロダクトの価値になるからです。
ビジネスモデルが確立していない場合
スタートアップに多いケースですが、ビジネスモデルがないけどなんかでかいチャンスがありそうみたいなケースがこちらです。こちらに関して言うと、いま進んでいる方向が正しいのかどうかなんてまぁわからないのが普通です。
BtoCのサービスなんて暗中模索の中進んでいき、小さなピボットを繰り返し、偶然からうまれるマネタイズで奇跡的に成功するみたいなものだと思います。
こうなるとどうしても目の前の合理性のほうが重要視され、リリースが再優先になってきます。程度の違いはあれど、どうしてもそうなる傾向にある。サービスの進化という点において立ち止まってられない時期はあります。
大事なことは経営とのコンセンサス
そのため、自分の目線だけで語ることではなく経営とコンセンサスをとっておくことだと思います。
いまでこそエンジニアが活躍できる会社は増えています。あれもただ総判断したわけではなく、経営陣が会社の成長に必要だという経営判断をしているからです。
とはいえ会社のフェーズによってもこのあたりの判断は変わっていくと思うので、判断基準は固定になるものではなく常にアップデートしていく必要があるのだと思います。
