リスキルテクノロジー

From: 松田航

リーンスタートアップ。

IT、さらに言うと、ITスタートアップの界隈で話題になっている（なった）起業の方法論です。

これがなんで話題になったかというと、起業のプロセスがようやくすこし科学的になったからです。

キーワードは「検証」です。

今からリーンで立ち上げるプロジェクトがあるため、復習がてら書いてみます。

スタートアップはギャンブル？

スタートアップというのは、当たるかどうかが正直わからないものです。チャレンジングなものほどその傾向が強く、Googleもそうですし、Facebookもそうです。仮に私が記憶がない状態で、過去に戻ってFacebookの創業メンバーと会っていたとしても、なんだこの連中？ くらいにしか思わず、投資なんて考えもしなかったでしょう。

実際100社に投資して、1,2社当たればいいや、というある種のギャンブルです。

急成長するスタートアップになるのか？　という疑問どころか、そもろもターゲットがいるのか？　その商品にお金を払ってくれるのか？　そもそも悩みが独りよがりでは無いのか？　

そういう不安を押しのけつつ、作って、当たれー！！！と祈るのが、スタートアップだったわけです。（いい過ぎですが）

リーンスタートアップでは、起業のリスクを最小限にし、意味のある失敗を繰り返すことで、成功へ近づいていく方法論を確立しています。これはとても革新的で、ちゃんとビジネスとしてやりましょうね、というのがひとつの案として示されたということです。

リーンスタートアップの要訣

リーンスタートアップの要訣はなんといっても、「検証による学習」にあります。

(1)すごく前

完璧なものをつくって、リリース。ウォーターフォール

(2)すこし前

とにかく早くリリース。全力で書け。アジャイル

(3)リーンスタートアップ

ちゃんと検証して、それが本当に必要なのか見てから、最小限作ろう。リーン

というのがざっくりな違いです。前と書いてありますが、現在でも主要は上の２つでしょう。

しかし、(1)(2)ですと、無駄なものを作る可能性が高くなります。どれだけ自信満々に作り始めても、まったくユーザが欲していないものを作りがちです。（実際に、僕は全力で利益にならないものをつくってしまいました）

そうすると、それまでに使った費用や工数はすべて無駄になり、だいぶ厳しいスタートアップ生活を余儀なくされます。bootstraping起業（自己資本起業）ならともかくとして、投資家がいたらより厳しいでしょう。詰められます。

だからこそのリーンスタートアップです。

顧客の課題・それに対するソリューション（解決策）・価格（収益）・チャネル、をきちんと検証し学習して、それからスケール（拡大）を考えよう、という話です。

例えば、靴の販売で有名なザッポスは、地元の靴屋の靴をそのままオンラインで販売してみて、ニーズを確認しました。

このように、実際に必要とされているものを、ユーザがいる+チャネルで売れている、という確認が取れれば、事業化および拡大に安心して走れることになります。

反面、ダメだった場合、すぐに調整してのピボットや、そもそものアイディアの再構築に時間がさけます。

やり方

やり方はだいたいこんな感じで流れます。もちろん考え方や本質の方が大事なので、参考までに。

①プランA（本来の計画）を作る

②プランで最もリスクの高い部分を見つける

③プランを体系的にテストし続ける

① プランAを作る

はじめのプランを作ります。ビジネスモデルの仮説を捕まえて、書き出します。

プランAはソリューションではなく、ビジネスモデル全体です。

なんの課題を持っているか？
↓
では、ソリューション（解決策）は？
↓
チャネルは？
↓
収益は？

の流れです。ソリューションに拘り過ぎるのはやめましょう。ここ考えるのが一番楽しくて、大体の起業家が得意なところでして、その結果はまるのもここです。

もうすこし細かいところを考えるのであれば、リーンキャンバスというツールがいいでしょう。『実践リーンスタートアップ』の著者アッシュ・マウリャ氏が作成しているものです。

これら９つのブロックに内容を記述していき、ひとつのプランとするのです。

このリーンキャンバス何がいいって、作成するのに３０分もかかりません。１５分くらいで作成できます。

何枚も作成して、それをまともな相談相手に相談しましょう。まともな相談相手とは、起業or事業についての理解があり、相談に対してなんらかの適切な反応が得られそうな人です。

② プランで最もリスクの高い部分を見つける

「成功する製品の構築 = リスクを減らす」ですよね。なので、成功するためにはリスクを低減しないといけません。

スタートアップの最も大きなリスクとは、「誰も欲しく無いものを作ること」です。そのため、３段階に渡ってテストします。

■ 第1ステージ　課題/解決フィット

解決に値する課題があるのか？をテストします。

実はアイディアはとても安いのです。なんらかの課題を頭に入れつつ、１０冊くらい起業家やマーケターの本を読んでみてください。きっと、新規のアイディアが2,3ノートに書かれているはずです。

しかし、そのアイディアに対して取り組むのは高いコストが必要です。

・それは顧客が必要としているものですか？
・顧客はお金を払ってくれますか？
・それは解決可能ですか？

この３つの問いに答えるために、顧客にインタビューをしましょう。

知り合いの知り合いくらいの距離感がちょうどいいですが、

■ 第2ステージ　製品/市場フィット

続いて、誰かに必要とされるものを構築したか？ をテストします。

簡単に言えば、必要最低限のものだけを用意して、実際に売ってみるということです。

とにかく必要最低限のものです。売るのに必要最低限。コア部分だけという意味ですね。アーリーアダプターが好みそうなあれです。

実際に売ってみるのも手っ取り早いのですが、顧客へのインタビューを挟むのもいいでしょう。そして、買ってくれた人がちゃんと使ってくれるかを確認しましょう。

使ってくれていないのであれば、またインタビューです。で、修正するところは修正する。

■ 第3ステージ　拡大

ここまでできて初めて拡大を考えます。

成長するための方法をひとつに絞って、時間や資金を投下します。これもちゃんとテストをしているはずですから、安心してお金を入れられるはずです。

ここまでしっかりと検証・学習に時間を費やせば、安全側な起業ができるようになります。

③ プランを体系的にテストし続ける

そして、一度検証して終わりではなく、構築 - 計測 - 学習のループを回し続けます。

常に、仮説=>検証=>結果を確認します。

・顧客はこれを悩んでいるんじゃないか？
・これだったらその悩みを解決できて、そこでお金がもらえるんじゃ無いか？
・実際に小さいものを用意して売ってみようか？ 小さい機能追加してみようか？
・売れた？　じゃあ、本格的に用意をしよう

です。

なので、失敗するのであれば、一刻も早く失敗する。それが学習ループです。

リーンスタートアップとはこのような起業方法です。従来の方法に比べて、かなり精度が高くスタートできるのがわかります。

サイバネティクス理論を取り入れた、誘導ミサイルみたいなものですね。

ただし！！！

リーンスタートアップがよくわからず、悩んで足が止まるくらいだったら、いいからガンガン進めちゃった方がいいんじゃないかと、個人的には思っています。

普通の人や、スタートアップ初心者がごちゃごちゃ考えると、たいてい進まずに諦めるもんです。

特にその分野自体をはじめてやる場合、どちらにせよ、よくわかりません。

検証とか言われましても。。。というのが正直なところだと思います。

突っ込んで、一回叩きのめされて、２回目突っ込む時に「ああ、リーンスタートアップって正しいよね。これだよね」というふうに言えるようになったほうが健全だと思っています。

業界に詳しければ、別なんでしょうが、強くそれを感じています。理論だけの人は行ったり来たりで進まずに、割と大変そうだなぁ、とはたから見て思います。

ただ、なんにせよ、最低限のテストを実施して、失敗するまでの速度を速めるという感覚は、持っておくといいのではないでしょうか？

松田

From: 松田航
新宿本校にて

「今日、あなたはなんの仕事をしましたか？」

この質問に明確に答えられるエンジニアは幸いです。

新人エンジニアや新しい職場に入ったばかりのエンジニア、もしくはフリーでやっているエンジニアは割ときちんと答えられるでしょう。

しかし、企業に長くいればいるほど、本来やるべき仕事から遠く離れたことに時間を使ってしまいがちです。時間管理術を身につけると、仕事の効率が格段にあがります。

本来やるべき業務ができていない

設計だったり、コーディングだったりすると思いますが、あなたが本来するべき仕事がほとんどできていない日が多くあるはずです。とくに最近では、1日２時間も生産的な時間が取れていないという感想を持ったエンジニアが急増しています。

本当の力から言えば、３時間で終わるような機能追加が、異常なほど時間が取られ、３日経っても終わらないというようなことがあるはずです。

これには、主に二つの理由があります。

大きく時間を取られることが沢山ある

これは会議や顧客への訪問などです。

会議を至上命題と捉えている会社員は多いもので、会議が多ければ多いほど、その分生産に使える仕事が減っていきます。

これは仕方ない部分もあり、会議がないと進まない場合もあるのですが、時間は制限すべきですし、最低でも区切るべきです。いらなくなった人は随時リリースするなど。

大きい時間がまるごとドカっと取られていると、そこに至るまでの時間もなかなか集中できません。集中しても、すぐに会議があるとわかっているからです。

ですから、会議の数は少なく or まとめてやる。

そして、会議自体も時間を少なくしても、目的に沿ったものにしましょう。

時間節約のアイディアは沢山あり、例えば、立って会議をするなど。弊社では実行していますが、会議の時間が20-30%ほど減ります。

短い時間のロスが沢山ある

とはいえ、なかなかどうして大きい時間のロスは減らしにくい物です。とくにあなたが上の立場でもなければ、、、まず意見するのは難しいでしょう。

それは仕方がないことです。階層社会にいる訳ですから、上司の命令にはある程度従うべきです。（そのために会社組織があるわけですし）

では誰しもが解決できる問題はというと、短い時間のロスをなくすということです。短い時間というのはそれこそ、３分や１分、３０秒といった極短い時間です。

実はこの時間がかなり大事なのです。

なぜか？　

人間は一度切れた集中力を戻すのに、ものすごい時間と体力を必要とするからです。

一度集中状態に入ったら、その状態をなるべく維持する努力をしなければいけません。プロの将棋を見ていればわかりますが、誰も音を立てようとしません。音を立てる対局者は全般的に嫌われます。

それくらいノイズなどの集中力を妨げるものはアウトとみなされるのです。

その中でも特に対処が必要はのは、下記の３つです。

時間泥棒その１メール

メールというか、メッセージといった方が正確でしょうか？

SlackでもChatworkでもスカイプでも構いませんが、なんらかのメッセージです。メッセージが来るたびに、アラートを発信して、それを読みにいっている人がいますが、あれほど非効率なことはありません。

アラートなんて全部切りましょう！

通知はすべてオフ。

そして、読む時間を限界まで制限しましょう。例えば、メールは１日に３回も見れば十分です。とにかく見ない。

見るときはそれようの時間をあらかじめスケジュールに追加しておく。それくらい、見ない。その時間以外は見ないという固い意志をもってください。

もっとも大きな時間のロスがこれです。

確かに人付き合い的には厳しくなるかもしれませんが、生産性は１０倍くらいになります。一週間でいいので試してみてください。（本当に）

また、当然ですが仕事中にSNSにアクセスするとかもNGの極みです。同様の理由で。

時間泥棒その２ 電話

これはできる人だけやってください。できない人もいるでしょう。

しかし、電話から極力離れるという考えは持っておいて損はないです。電話の近くにいて、いいことはないです。

当たり前ですが、かかって来たらとらなくてはいけないのですから。

対顧客の部署では電話がもっとも大事なものなので、必ず、一瞬でも早く取るべきです。

しかし、エンジニアは違います。エンジニアの存在目的はプロダクトを作ることです。内戦の電話や顧客からのマニュアルに書いていあるようなサポートのために存在するわけではありません。まして、営業の電話をうけるのなどは論外です。

とにかく電話から逃げましょう。（逃げられるなら）

※ 顧客サポート部隊に属しているのに、逃げるとかは職務怠慢なのでやめましょうね。

時間泥棒その３ 話かけらる

話しかけられるのはエンジニアの常です。他のエンジニアからだったり、営業さんからだったり、PMからだったりしますが、とにかく常に話しかけられます。IT企業以外でエンジニアをやっている人ほどそれを理解しているでしょう。

なぜなら彼らは他の人の時間や集中力を大事なリソースだと思っていないからです。

ではどうするべきか？

まずは、話しかけるなオーラを出しましょう。いえ、不機嫌そうにしろというわけではなく、イヤホンをして、画面にのめり込むように仕事をしましょう。それだけで、話しかけてくる人の数は激減します。びっくりするほど。

イヤホンは極力大きい物。イヤホンよりはヘッドホンの方が良いです。

そしてちなみに、コーディングをしながら、音楽を聴くのは止めましょう。明らかに集中力を切らします。マルチタスクは、人間には向いていません。

音楽はOFF。見せかけだけのヘッドホンを装着しましょう。

つづいて、打ち合わせの時間を決めてもらう。

５分でも１０分でも打ち合わせの時間を決めてもらう習慣を持ちましょう。

ちなみに６０％くらいの質問は時自分で解決できるものだったりします。調べるのが面倒だから聞いたりですとか、自分で考えるのが億劫だから聞いたりですとか、責任を一緒に追ってねという意味での質問が大体です。

なので、これだけで質問が４割くらいは減ります。なぜって、会議を設定するよりは自分で考えた方が楽だからです。

時間が倍増する

これだけで、今までの２倍は集中の時間が取れるようになります。そうすれば生産性があがりますし、バグを直すのも、顧客からの希望機能を作ることもできます。結局社内全体にとってはいいことだらけです。

性格悪くなれ、というわけではなく、自分の集中力を最大限生かすためにはどうすればいいのかを意識しましょうという話です。

これがなかなか難しいという人は、自分がどこに時間を使っているか、測ってみることをおすすめします。かなりの危機感を覚えて改善の方向に向かおうと思い出すはずです。きっと！

時間というリソース、あなたは大事に扱えていますか？

松田

PS

ちなみに、だからこそ、自分もそれをするのをやめましょうね。
相手の集中が切れたときを見計らって、話しかけたり、依頼をしたりしましょう。

PPS

プログラミング・エンジニアリングを学ぶならこちらから

From: 松田航
サザンテラスのスタバにて

「えっとここって何が書いてあるんですか？」

「ああ、これは◯◯している場所ですね」

「これって何してる関数ですか？」

「これは△△のモデルにデータを取りにいっています」

「ここで宣言している変数って何に使っているんですか？」

「えっと、これは、、、」

うちのスタッフとの会話です。

彼はかなり育ってきたスタッフで、スラスラとコードを書いてくれるようになっています。ほとんど放置しても大丈夫で、とても楽になってきました。

しかし、最近プルリクでコードを確認すると、上記のような会話が頻発するようになってきました。

僕の理解力が低いのではという話は置いておいて、これは少しまずい傾向です。

初心者を抜け出して、少しコードが書けるようになってくると、陥る罠があります。

かっこよく書きたくなる

ビギナーのレベルを超えた人間が次に目指すのは「かっこよく」です。特に男性陣はその傾向が強い。

・とにかく短く書こう
・とにかくライブラリ化して使いまわせるようにしよう
・関数をたくさん作ろう（何をとってきてんだかわからんgetホニャララ）

とか、そのような感じです。これは初心者ゾーンを抜けたエンジニアによくある病です。

当然、これらが100%いけないわけではありません。向上心も二重丸です。しかし、程度もんだという話です。

目指すべきゴール地点がずれているのです。

かっこよく書くのがゴールか？

なぜ、コードを短く書くかというと、その方がわかりやすく読みやすくなる「可能性が高い」からです。

1万文字の文章と3000文字の文章、どちらの方が早く読み終わるでしょうか？

後者の方が、時間がかからないですよね？　

コードも一緒で、3000行のコードと1000行のコードを読むとき、後者の方が早く読めます。

だからこそ短く書くべきなのです。

ライブラリや関数を作って使うのは、それが再利用できて、便利で、コードが読みやすくなるからです。

解読難度の高い１行を作った時点で、どんなに短いコードであっても、読むのに時間がかかるようになります。

少なくとも今は一回しか使わないものをライブラリ化しても、工数も無駄にしますし、コードを読みに行くのが非常に手間です。（３回くらい同じこと書く必要ができたらやるべき）

ゴールは読みやすく

「かっこよく」という定性的な自己満足ではなく、「読みやすい=他人が読んで時間がかかりずらい」という定量的なゴールを目標にすべきです。

自分だけ知っているニッチなフレームワークの隠れ関数を叩いても、他の人にとっては邪魔なだけです。

自分以外が読んでもわかるか否かを基準にコードは書くべきなのです。

どうしても使いたくなったら、上にわかりやすいコメントを書きましょう。（社内wikiは読みに行くのが手間だし、そもそも調べにいかないことが多々）

メンバー全員が、「周りの人が読みやすいコードを」を意識して書いてくれれば、それだけでいいプロジェクトになりますし、メンバーが仮に抜けたとしても、その後のフォローは格段に楽になります。

読みやすいコードを書くには？

オライリーのリーダブルコードを読みましょう。

以上！　笑

あとは、コミュニケーションと一緒です。一人で暴走しないようにしましょうね。周りに合わせて話す大きさと速度を変えましょうね、ということです。

松田

PS
空気を読めという話ではないので、それが全員に伝わるように研修をやるとかも可。

ただし、新しく入ってくる人がわからないので、マニュアルを作るか（面倒だけど、、）、もういっそプログラムごとの標準的コーディング規則およびドキュメントや本に頼りましょう。

PPS
プログラミングを学ぶならこちら