エンジニアに読ませたら良いんじゃないかと思う『RUNNING LEAN 実践リーンスタートアップ』

新しいWebサービスやアプリを使ってご飯の種にしようとするなら、ちゃんとビジネスができないといけないと思っています。

『ものを企画して、発注、販売する』
という基本的な商売はやったことがあるものの、ソフトウェアを使ったものでもなく、本格的なビジネスを経験した訳でもありません。

そこで、どうやらビジネスモデルの作り方や、リーンスタートアップについて書かれていると聞いたのでこの本を読むことにしました。

主に印象に残ったのは以下の2項目でした。

それぞれについて、順番に説明します。

「これでビジネスになるのかどうか」を検証しようと思ったら、最低限はビジネスの元手が必要になるはずです。
ここで言う元手とは、商品やサービスなど、買手に対して提供されるものです。

いかなるビジネスを行うにしても、

独自の価値提案を明確にし、
課題に対する最低限の機能を実装する

ことをすべき、だそうです。

小さいものであれば開発にかかるコスト（時間コスト、金銭コスト）は小さく済ませる事ができますから、万が一「これはビジネスにならない」と判明しても捨てるのは容易だ、ということです。

また、規模が大きく複雑なものは、テストを行いづらいから、という要因もあるようです。

エンジニアとしては、

ビジネスプランにも単体テストが必要で、単体テストを行うためにもクラスの役割ははっきりさせた上で適切な粒度で実装する事！

と言ってもらった方がしっくり来る気がします。

MVPを構築したら、それが解決する（予定）の問題をどれだけ解決するのか（製品/市場フィット）をテストする必要があります。

その手法として、この本では見込み顧客へのインタビューを薦めています。

インタビューを行うにあたって、

が書かれています。

やはりプログラミングに例えて言うなら、

ビジネスプラン用のCI(継続的インテグレーション)ツールの紹介と、それを使った開発の進め方について

という内容です。

著者はこの本を制作する際にもこの手法を行っており、その時に実際に行った手順も紹介されています。

読めば読むほど、フレームワークの大枠はアジャイルプロトタイピングと近い印象でした。
もちろん、コンピューター相手にテストを行うのと人間相手に行うのとでは同じように行かないでしょうが、違いと言えばその辺りくらいではないかと思ってしまいます。

ビジネス、特にリーンスタートアップに興味がある人が読むべき本でしょう。
けれどもむしろ、ベンチャーやスタートアップで働きたいエンジニアに読ませるべき本なのではないかと感じました。

今日日、エンジニアは単なる技術オタクではいられなくなっています。

様々な役割の方々と協力しなければビジネスは回らないのですから、その方々とコミュニケーションをとるためにも知識が無いといけないでしょう。
具体的には、共通言語が必要になります。

エンジニア同士であれば、技術用語という非常に便利な言葉があり、スムーズに会話を行う事ができます。
同じような言葉と、その言葉が運ぶ概念を理解しておけば、スムーズなコミュニケーションが期待できるのではないでしょうか。

今度はデザイン関係の本も読んでみようと思いました。

Kikuchy's Second Memory