読者です 読者をやめる 読者になる 読者になる

毎日がもふもふ

渋谷で月額制受託開発「開発チームレンタル」を運営するmofmof inc.のブログ

手を動かしたい系エンジニアのための、リーンスタートアップのやり方

f:id:redhornet96:20170306191130j:plain

ごきげんよう。mofmof inc.のエンジニア兼代表取締役のはらぱんこと原田敦です。

エンジニアの皆さん。例えば自分の作ったプロダクトが成功して、もう働かなくて良くなったら何したいですか?

ぼくはハワイに住んで、イルカの絵を生成しているラッセンさんと談笑しながらOSSにpullreq送る生活が夢でしたね。ぼく「その絵、ディープラーニングで描けるよ」、ラッセンさん「hey、何言ってるんだガイ!暑さで頭がどうかしちまったのかい?haha」みたいに微笑ましいアフタヌーンを過ごしたい。

ちなみに、ピカソより、ゴッホより、ラッセンが好きか?と聞かれると、そうでもないです。

さて、今回のテーマは「エンジニアのためのリーンスタートアップ」です。今となっては起業プロセスの定番中の定番のリーンスタートアップですが、エンジニアがリーンスタートアップをうまく実践するコツみたいな話をします。

リーンスタートアップとは

今更リーンスタートアップとは云々なんて話をしてもアレですし、みなさん知っているとは思うのですが、前提の確認ということで、まずリーンスタートアップとはなんぞやって話を少しだけしておきましょう。

参考までに。

「リーンスタートアップ」─小さな失敗を重ねて育てる:日経ビジネスオンライン

要約すると、可能な限りのムダを排除して、小さい失敗を効率的にたくさん積み重ねることで、机上の空論ではなく事実を元に学習し、新規事業の妥当性を検証しましょうっていう起業プロセスですかね。

昔から新規事業といえば、まずは顧客インサイトを取るってことで、アンケートなどによる定量的市場調査とかが一般的でしたが、それよりもリアルに課題を持っている顧客を探して出して、直接インタビューすることで、定性的に仮説が正しいことを検証するというようなスタートするのが特徴的かな。

エンジニアにとってリーンスタートアップはツラい

f:id:redhornet96:20170306191303j:plain

で、このリーンスタートアップですが、手を動かすことが主たる業務で、それに慣れているエンジニアにとっては実はちょっとツラい。

起業プロセスの中から徹底的にムダを排除するわけなんだけど、立ち上げ初期のプロダクト作り込み作業もムダとされているわけです。

リーンスタートアップでは、初期において最も重要とされることは、「高速に学習すること」なので、プロダクト開発は優先度が低いのです。代わりにインタビューだったりとかテストマーケティングだったりとかが優先度の高いプロセスになるので、ほとんどそればっかりやることになるんです。

一般論として、日本でいうエンジニアという職種の人間は、要件に基づいてアプリケーションを、実際に手を動かして作り上げるという作業を主たる業務としていて、そこに喜びを見出す人が多いと思う。かくゆうぼくもその1人だし。

そういう人にとって、これはけっこう精神に堪える。モヤモヤする。ヤキモキする。

ストレスの少ないリーンスタートアップ

だからと言って、まどろっこしいから作ってしまえ!作ってから考えるぜ!おりゃ!っていうのはほぼ失敗します。断言してもいい。

誰も使ってくれないんですよ。とりあえずなんとなく作ってみたものなんて(反省)。

WEBアプリケーションだったり、スマホアプリだったり、便利なものが溢れている現在において、なんとなく適当に作ったものでは勝てないです。

なんでもいいけどポケモン捕まえたいから、とりあえずその辺の草むららへんにモンスターボール投げてみたらミュウツーが捕まった!やったあ!ってくらいに現実的じゃない。リザードンでもいいよ。

だから、誰のどんな課題に対して、どうやって解決出来る、どういうものなのか?を徹底的に分析して、グサっと刺しに行かないとなんです。もはやこれは避けて通れない道。

具体的にどうやるのか?

分かっていながらそれが苦しいのがエンジニアなんですけどね。じゃあどうやればいいの?と。ミュウツーの捕まえ方は知らん。聞くな。Yahooでググれ。

  1. 動くMVPを3日以内で開発する
  2. 作ったものに対して仮説立てして、最低10人以上にインタビューし、随時アップデートする。
  3. 課題仮説を確定させて、対応するソリューションの草案を作る
  4. ソリューションのデモを作る
  5. デモを使ってテストマーケティングをして、お金を払ってくれる顧客を最低1人見つける
  6. 顧客が見つかったら、晴れてプロダクト作り込みを解禁

ポイントは、1と2が一般的なリーンスタートアップとは逆なところと、6ですかね。

動くMVPを3日以内で開発する

ちなみにMVPとは(Minimum Viable Product)のことで、詳しい理解は話の軸がずれるので省略しますが、要するに必要最低限の機能を備えたプロダクトとでも言っておきます。

MVPを開発する際に、エンジニアがハマりがちな3つの罠。

  1. 作っている途中でイケてる(と思っている)機能を思いついて実装してしまう
  2. 細部にこだわり過ぎる
  3. バグのない完璧なものを作ろうとする

残念ながらこれらは、MVP開発においてはこれらは全てはムダにあてはまってしまいます。これをやっている限り数ヶ月かけても出来上がらないです。いや下手したら数年かけても出来上がらないかも。

この3つの罠は絶対に肝に命じて、全力で罠を踏まない努力をしましょう。粗いプロダクトを世に出すという、エンジニア美学に反することであることは分かっています。でも自分の心との闘いなのです。負けてはなりません。

おすすめのやり方は、MVP開発は開発合宿でやりきること。これまじ超絶オススメ。

実際に、mofmof inc.のMy-opeという人工知能チャットBotサービスは1泊2日の開発合宿でMVP版を作りました。

www.my-ope.net

お金を払ってくれる顧客が最低1人見つかったら開発開始する

2〜4のプロセスはリーンスタートアップの一般的なプロセスなので省略して、開発をいつ開始するかっていう話を。

ぼくの実体験からすると、開発出来ない期間が長ければ長いほど、台風の日のビニール傘のように心がポキっと折れそうになります。そこで、開発を開始して良いルールを明確にすると良い。

オススメのルールは「お金を払ってくれる顧客が最低1人見つかったら開発開始OK」というルール。

「開発を進めたい」というい欲求を満たすために、先にビジネス的な課題をクリアしなければならないというプロセス構造を作ることで、モチベーションのベクトルをそっちに向かわせるということが出来るのです。

個人でサービス作るときにも使えるやり方なので、こんな感じでプロセスを工夫しながら進めれば「一生懸命作ったのに誰も使ってくれない」っていうのを圧倒的に減らせます。どうぞお試しあれ。

mofmof inc.では経営企画エンジニア募集してます

ぼくがエンジニア出身(しかも手を動かすのが好きなタイプ)ということもあり、エンジニアならではの悩みに向き合いながら日々頑張っております。

「オレもエンジニアだけど将来自分で事業作りたいからスキルを磨きたい」って方とか「自分でチャリンチャリンビジネス立ち上げたいなー」って方とか、ぼくが苦しんだ経験談とか役に立てるかも。応募お待ちしてます。

自宅で勉強が出来ない全てのエンジニアに告ぐ、弱い心に打ち勝つ方法

f:id:redhornet96:20170208180426j:plain

mofmof inc.エンジニア兼代表取締役の原田です。今回のテーマは、エンジニア人生に切っても切れない「勉強」について。

エンジニアのみなさん。勉強してますか勉強。

このブログを見てくださっている方はきっとステキな人しかいないと思うので、みなさん寝る間も惜しんで切磋琢磨していることは疑いようもありませんね!すごいや!

そんなステキエンジニアのみなさんに勉強の仕方について弁を述べるなどというのは、不遜極まりない愚行と思いつつも、どうやったらコンスタントに技術的な勉強を続けられるかという話を、恐れずに書いていこうと思います。

勉強スタイル

まずはぼくがどんなスタイルで勉強しているかを説明した方がいいかな。

毎日コツコツ型なんですが、平日全て自宅に帰ったら必ず何かしらのテーマで勉強をします。時間がない日は30分だけでも何かしら着手してます。

コツとしては学習したことをブログにアウトプットするのがいいです。ホントに月並みですが、ぼくはこれがなければコンスタントに勉強を続けられないかも知れない。

なんというかインプット系の勉強って基本退屈なんですよ。やってもやんなくても世界は変わらないし、実際に使わなければムダだし。ちゃんと実際にいかせるイメージがないとやる気が湧かないですよね。

鎌倉幕府とかいうのが1192年に出来たとか知ってて何になるんだよとか思ってたでしょ?だってオレ荘園とか持ってないし豪族じゃねえしとか頼朝マジひどいとか思ってたでしょ。ところで鎌倉幕府は最近は1185年って教わるの?

ブログを書いておくと、実際にその技術を使うときに自分の記事を見れば思い出せるし、あとでGoogleアナリティクスでPV見てニヤニヤすることも出来るし、アクセス数からトレンドもわかるし、いいことづくめですよ。更には「原田さんの記事にいつもお世話なってますよ!」ってリアルの知り合いに言ってもらえたりしたらめっちゃ嬉しいです。

ちなみに「マサカリこわい…(((( ;゚Д゚)))ガクガクブルブル」とか「間違ったこと書いたら恥ずかしい」という気持ちは無視して大丈夫。なぜなら最初のうちはどうせ誰も読んでくれないから。それにぼくは5年くらいはブログ書き続けているけど、マサカリは一度も飛んできたことないから安心していいぞ。

土曜日はゆったりしながら出来るので、基礎力をつける系の勉強をすることが多いです。例えば、最近は機械学習にハマっているので、オンライン動画で微積を復習したりとか、機械学習の基礎とか、ベイズ統計とか。

これも毎週続けるのがキモですかね。でも日曜日はあまりやりすぎないように注意してます。休み大事。

なぜ勉強できないのか?

f:id:redhornet96:20170208180448j:plain

なぜ勉強する時間がとれないか?答えは簡単あなたが怠惰だからです。以上オシマイ。頑張れ。

と言ったら元も子もないけども、まあ実は怠惰なのはあなただけではないです。ぼくも怠惰だし、周りの人も怠惰。人類は皆怠惰です。ジンルイミナタイダ。

めんどくさいことはやりたくないし、楽な方があれば楽な方を選択するのが普通。これが前提にあることを理解するのが第一歩ですかね。

自分は怠惰であり、意志と根性がみなぎる努力マンではないということを知りましょう。

心は直接コントロールできない

帰ったらテレビつけるやん?

テレビつけたら金曜ロードショーでナウシカやってるやん?

ナウシカってノーパンなの?って気になるやん?

この先どうなるんだっけ?って気になるやん?

最後まで見ちゃうやん?

テレビつけるとこうなる。ジブリ好きじゃない人はお好みで沈黙シリーズとか007とかジャッジドレッドとかで適当に読み替えてね。

もうね、ムリなんですよ。気になるなーってなったものから離れるのは。CMの最中にテレビを切るとかってあんなの至難の技ですよ。たぶん聖徳太子でも失敗するよ。巧妙に続きが気になるところでCM入れやがるから。

心を直接コントロールは難しい。だから行動をコントロールをするですよ。

この例で言えば、どんなことがあろうと帰宅後にテレビをつけない。ただこのたった一つのルールを守るだけで相当な時間を捻出することが出来るですよ。

他にはこんなことをルールづけてます。

  • 帰宅後絶対にテレビを付けない
  • 帰宅後必ず30分は何かに取り組む
  • すぐに実戦に生かせないテーマはやらない
    • 英会話とかはこの最たる例。今使わないなら今勉強しない
  • つまらないなーと思う勉強はムリして続けない
    • モチベーションの設計がうまくいっていないのでやり方を変えた方が良い
    • ブログにアップする習慣にすると楽しくなることもある

勉強の1サイクルを極力小さくする

実際のメリットにつながるまでの距離が遠ければ遠いほど飽きが来やすくなります。一通りやりきるのに数ヶ月かかるようなテーマはかなりしんどい。

ここも気合と根性で頑張って継続するのではなく、工夫しよう。「勉強の1サイクルを極力小さくする」ことで解決出来る。

例えばRailsとか新しいWEBフレームワークをマスターしたいって場合には、1サイクルを極力細分化して「基本的なバリデーションのやり方」くらいにする。1サイクルの最後にブログに書いて完了。これなら数時間〜1,2日で出来る。

次は「検索処理の実装の仕方」とかっていうテーマでも良い。これも同じくらいの時間で完了出来る。こういうのを継続的に繰り返していくと、なんということでしょう!いつの間にRailsが使えるようになっているじゃないですか。

Rails勉強してまーす☆って方は是非試してみてね。

参考までに昔Rails勉強中のときに書いたエントリ

j-caw.co.jp

やりすぎ注意

習慣の力は絶大。このように間接的に自分をコントロールできるようになると、これが楽しくなって来ちゃって、時間を忘れてブログジャンキーになったりして体壊します。

昔から勉強とかプログラミングがすごい好きだったので、毎日終電帰りで仕事して、帰宅後に別言語で個人受注の仕事をやってたりして、お金もらいながら勉強出来るヒャッハー(゚∀゚)!!とか思ってたら、いつの間にか体力の限界を超えてダウンしたのは本当にあった怖い話。用法用量は守りましょう。

エンジニア募集中

mofmof inc.では緩やかな事業の拡大にともなって、緩やかにエンジニアを募集しております。良かったらポチってね。ランチとかでもいいですよ。

mofmof inc.がどんな会社なのかも前にブログにまとめたので良かったら読んでくだしあ。

everyday.mof-mof.co.jp

mofmof inc.入社ガイド。これから入社するあなたへ。

f:id:redhornet96:20170125135950j:plain

mofmof inc. エンジニア兼代表取締役のはらぱんこと原田です。最近mofmofで一緒に仕事したいと思ってくれる方、および一緒に仕事をしたい方と思う方を探してます。

いつも仲良くしていただいている「創るを楽しむ」を標榜するおもしろベンチャーの「9課」さんが人を増やすにあたり入社ガイドをアップされていて、ステキな取り組みだなーと思い、mofmofでも作ってみました。

ちなみに9課さんはNintendo64のスマッシュブラザーズを一緒にプレーする仲なので、もしあなたが9課さんに入社されたら、まずはぼくの超絶ファルコンコンボをお見舞いされることになるでしょう。その時が楽しみで胸が踊ります。

mofmof inc.とは何者であり、どこへ向かっているのか

mofmof inc.とは?

mofmof inc.は2015年4月1日に、当時フリーランスエンジニアだった原田敦が、同じくフリーランスの2人と一緒に立ち上げた会社です。2017年1月現在、もうすぐ2期目が終わろうとしているところ。

メインの事業は2つ。

  • 社内問い合わせ対応専用AIチャットボット「My-ope office
  • 月額制受託開発「開発チームレンタル」

mofmofのビジョン

f:id:redhornet96:20170125140131j:plain

ビジョンは「つくって人をしあわせにする」です。

  • 欲しい人(クライアント、あるいは経営層)
  • 使う人(ユーザー)
  • 作る人(エンジニアやデザイナーなどのクリエイター)

単純なことだけども、作る人はものを作ることに誇りと喜びを感じながら仕事をし、使う人はシステムの恩恵を受けて何かがラクになったり便利になったりする。そして欲しい人(提供者)はコスト削減か利益を得ることで財布が潤う。

ぼくがやりたいのはこれだけ。実は意外と難しいことだったりもするけれど。

mofmofのミッション

ミッションは「新しいテクノロジーを使って新しい価値を創造し、より一般的なものに変えること」。

技術に戯れてヒャッハーするだけでは価値を生まない。価値を生まないものはお金にならない。お金にならなければヒャッハーは続けられない。

ならば、ぼくたちの存在意義・目的は「技術」とそれが生み出す「価値」に喜びを見出すことであり、その手段が「ビジネス」だということ。

そんな想いが込められたミッションです。このミッションけっこう気に入ってる。

社名の由来

株式会社mofmof(もふもふ)ってまたファンキーな社名をつけたもんですね。由来。なんでしょうね。

ぼくの個人的な嗜好で、小動物をもふもふするのが好きなことが由来だったと思います。

ところで小動物はいいぞ。

ネコ・犬・ウサギ。その他たくさんの小動物がこの地球には生息しています。彼らは万人にとって疑いようもなくカワイイ。あの毛玉のような手触り。仕草。なんて素晴らしいのだろうか。

カワイイは正義。

もふもふは正義。

そう、もふもふはジャスティスだ。

さて。

あとは「◯◯ソリューションズ」的なビジネスビジネスした感じが好みじゃなかった(そういう社名を否定する意図はない)のと、なんだかパッションがたぎるような激アツネームも性格的に合わないし、程々のゆるふわ感があるのがいいなーって思っていたけれど、結果的に程々どころか、完全にゆるふわになってました。

記憶に残りやすいし、ウケはいいのでまあ気に入っているんだけど、未だに名乗るときに「株式会社もふもふの原田と申します(モジモジ)」という具合なのはナイショ。

mofmofがやらないこと・やること

やらないこと

ものづくりと関係のないビジネスをすること

あくまでもクリエイター中心組織でありたいので。例えば人材紹介のみで収益を上げるビジネスとかは向いてないなーと思う。

根性論ありきの働き方

根性が必要なときはあるけれど、容易な根性論持ち出しは思考停止につながる。あくまでも課題には具体的アクションというアプローチを。

身の丈に合わない急成長・急拡大

mofmofの存在意義や目的は、早くたくさんお金を稼ぐことではないので。ただし、エキサイティングなものづくりを実現するために、どうしても急成長が必要ならこの限りではない。

枯れた技術で無難に稼ぎ続けること

どのあたりから「枯れた技術」とするかは難しいけれど、どんな技術でどう稼くかは技術の進化とともに変化し続けたい。

技術だけにしがみつくこと

我々が行使した技術で利益を生み出し続けなければ、我々は存続することが出来ない。技術と価値提供は常にセットであることを忘れないこと。

やること

機械学習・人工知能

今期に続き来期もこの路線でアクセルを踏みたい。この領域はまだまだ出来ることが隠されていて大きなポテンシャルを感じる。

受託開発

外部資本に頼らない自己資金での経営がしっくりきているので。我々がチャレンジし続けるための資金源でもあり、かつ技術を行使することで価値提供するビジネスとして受託開発は続ける。

新規事業

組織として常になにかしら新規事業に取り組んでいたい。チャレンジングな新しい技術の受け皿は新規事業にこそあり。

メンバーの個人ビジネス

クリエイターはどんどん個人プロダクトを作ってビジネスをやったらいいと思っている。まだ具体的には描けていないけど、そういう活動のバックアップをしてみたい。

これから入社するあなたへ

学習し続けること、学習を楽しむこと

技術の進化は日進月歩で、ついていくのが大変なんて言われますが、むしろそれを楽しめちゃうような人と一緒に働きたいです。

新しい技術が新しい価値実現の幅を広げていると考えているので、そういうところにテンションが上がっちゃう人はフィットすると思う。

反省し改善し続けること

経験をつみ、実力や結果を身につけるごとに、他人から手痛く指摘されたりすることは減ってしまいます。自ら失敗を認識し、反省し、改善する努力を怠ってはいけない。良い組織、良い仕事の根源はここにあるはず。

エンジニア募集しています

f:id:redhornet96:20170125140517j:plain

おかげさまで新規事業(AIチャットBot)や受託開発ビジネスも粛々と成長していて人が不足気味になってきました。

もしこういう会社好きだなーとか、おもしろそうだなーとか、ヒャッハーしたいなーとか、スマブラ地元最強だったし入社して吠え面かかせてやる、とか思ったらお気軽にメッセージくださいな。今すぐとかじゃなくても全然良いのでランチとかお茶とかしながらでもお話しましょう。

シェアリングサービスやマッチングサイトをいち早くリリースするための最短の道。クライアントインタビュー(ユキサキ様)

今回は、この夏に弊社でリリースしましたシェアリングエコノミースターターパッケージの件で、クライアントインタビューをさせて頂きました。

シェアリングエコノミースターターパッケージとは、その名の通り、シェアリングエコノミーサービスやマッチングサイトに定番で備わっている基本的な機能を予め実装した土台プログラムパッケージです。
今すぐシェアリングエコノミーサービスをリリースしたい!という方向けに、いちからサービス仕様の洗い出しをすることなく、当パッケージにデフォルトで備わっている機能をベースに追加開発をしていくことで、極めて短期間のうちにリリース可能なサービスプロダクトに仕上げることが出来ます。

さて、インタビューにご対応頂いたのは、京都のデザイン会社で合同会社ユキサキの神野代表です! f:id:mofmofnishii:20161122211626j:plain

よろしくお願い致します!

※以下、シェアリングエコノミースターターパッケージをSESPと表記します。

SESPカスタマイズプランをご利用頂き、まずは大枠でのご感想をお聞かせ下さい。

はい、概ね良かったかと思っています。今回はリリースまで約1か月という短期間であったにも関わらず、無事予定通りサービスをスタートさせることができたことに満足しています。

最もよかった点は?

一番に思いつくのは、担当エンジニアの方がこちらの意向をしっかりと理解しご対応下さったことですね。
こちらのやりたいことに対して、技術的な難易度や工数などを俯瞰的にとらえた上で、開発における具体的な提案を積極的にして下さいました。
またやりとりもとてもスムーズでした。時間的制約がある中で、サービスをリリースさせるという目的が互いにしっかりと一致していたので良かったのだと思います。

改善ポイントがあれば教えてください。

これは自分の側の課題でもあると思うのですが、UI、UXの部分ですね。
あくまでも、まずはサービスリリースができる状態にまで持って行くということなので、必要最小限の開発になってしまいます。そうすると、どうしてもUI、UX部分は後回しになり、改めて出来上がったものを使ってみると、もっとこう出来たのではないか?という視点もいくつか出てきました。ただ、それをすべて拾っていくというのはスピード面や費用面から考えて現実的でなかったというのも事実です。

SESPを検討されている方へ一言

いい経験だったと思います。WEBサービスはやる気さえあれば立ち上げられるので、まずやってみるというのが大事だと思います。mofmofさんで紹介されているSESPのデモや開発プロダクトをよくさわってみてたくさん使ってみながら開発を進めていくことが開発成功の鍵になるのではないかと思います。

最後に

神野様、この度は貴重なご意見をありがとうございました!

ユキサキ様のシェアリングサービス

エーヨ!は自分のチラシを置きたい人とチラシ設置スペースを貸したいお店のマッチングサービスです。
f:id:mofmofnishii:20161122231133j:plain

エーヨ!~A4サイズの棚シェア!~

開発会社だったらお金が入るならどんな仕事でも請けるべきか?

結論から言うと、開発会社というか、弊社mofmof inc.としてはあまり望ましくないなと考えてます。

実はこれについては前々から長い葛藤があって、なかなか結論を出せずにいたんですが、最近少しだけ糸口が見えた感があった。

あっ、mofmof inc.エンジニア兼代表の原田が書いております。

f:id:redhornet96:20161107144355j:plain

ソフトウェア開発会社というビジネス

ビジネスという活動を超超簡単な言葉にしてしまうと「サービスを提供して対価を得ること」だと思うのですが、それに従って考えれば「ソフトウェアを提供する」あるいは「技術力を提供する」というサービスに対して対価であるお金を得るという話は至極当たり前な話。息を吸ったら息を吐くってくらい普通な話。飲んだら乗るなってくらい常識的な話。ちなみにぼくはお酒は嗜む程度には飲みますが、ビールは少し苦手です。

ともすると、出来るだけたくさん営業して、出来るだけ高い金額で受注して、出来るだけ低いコストで、出来るだけたくさん仕事をこなす、ということがこのビジネスの作用点になるはず。

じゃあそれを努力すれば儲かるんだよね?やればいいんじゃん。って話なんですが、こじらせちゃった系エンジニア社長のぼくとしては、そうは問屋が卸さないわけです。

本当に価値を提供しているのか?という問題

f:id:redhornet96:20161107144441j:plain

どういうことかというと、我々が「ソフトウェアを提供する」あるいは「技術力を提供する」ことが、あるクライアントにとって本当に価値があることなのか?という疑念を抱いてしまうのですよ。

何が言いたいのかというと、我々が提供出来るのはソフトウェアを作るという手段なんだけど、クライアントが実現したいのはそれじゃなくて、それを持って何かを作り上げて収益得る(あるいはコストを削減する)ことであるはず。手段を提供した結果、何かを手にして欲しいのですよ。ぼくは。

さて、ここでフワフワっと問題が浮上してきます。それはですね、

「それ作って本当に儲かるの?」

とか思ってしまうことがあるですよ。ぼくのような小者めが、おこがましいことこの上ないが。

こういうときは大体「まずはビジネスモデルのキャンバスを作って検証してみましょう」とか「ターゲットとするユーザー層にインタビューしに行きましょう」とかっていう話をしてしまうことが多いかも。

誤解がないように言っておくと、決してビジネスモデルを否定してるわけじゃないです。ぼくにも実際うまくいくかどうかなんてサッパリわからんわけですから。でもちゃんと検証して、可能性があるポイントを見つけてから開発にお金を投資した方がムダが減るし、成功率も上がるじゃんって思うですよ。本当に真心を持ってそう思ってる。出来ることならぼくの真心を取り出して見せてあげたい。真心よりも下心が見たいという方は個別にお問い合わせください。見せないけどね!

で、こういう話をするとどうなるかというと「わかりました。もうちょっと検討してみますね…ハハハ」とかそんな感じの微妙な空気になっちゃう。もしイケイケゴーゴーな開発会社だったら「いやーお客さんマジすげぇっすね!パネェ。そのアイディアはなかったッス。他社がやるまえに早く作っちゃった方がイイっスよ!!まず見積もりはですね…ごにょごにょ」みたいなこと言うのかな。すげえな。

でもまあそりゃそうですよね。開発会社に期待しているのは開発してもらうことであって、アドバイスじゃないですもんね。ハテこういうときどうしたら良いんだろうな。

とにかく、手段を提供した結果、何かを手にして欲しいのですよ。ぼくは。(大事なことだから2回)

失敗することも価値のうち?

「作って失敗することにも価値がある」

こう考えるのもアリなのかな?

ぼくも小者ながらベンチャー企業の社長という立場なので、新規事業を企画してはつぶしてーを繰り返してきました。ぼくも何度も失敗しているわけです。ものを作っちゃったのもあります。でもそれらがムダだったかというと、全くそうは思っていない。近道は通れなかったし、回り道もしたけど、少なくとも今は確実に前に進める方法を知った気がする。

結局どれだけ仮説検証を一生懸命やったところで、失敗するものは失敗するし、どうしてかわからないけど成功しちゃうこともある。数%の可能性を変えるだけに過ぎないかも知れない。だったらさっさと作っちゃって、実物で検証しようぜって考えもナシじゃない(検証活動をしないことを肯定するわけじゃないけどね)。

質の良い失敗をしよう

f:id:redhornet96:20161107144456j:plain

それでもまだモヤモヤとしていたんだけど、「質の良い失敗をすること」が出来ればそれも良いのではないかと考えるとちょっとスッキリした。これまた誤解のないように言っておきますが、失敗を前提としているわけじゃないですよ。成功してちゃんとお金が稼げることが一番です。でも新規事業においては失敗することなんて山ほどあるわけだから、その中でも価値のある失敗をしようぜということを言いたい。

価値のある失敗とは何か?深掘りしていくと今回のテーマを逸脱して収拾がつかなくなる気配を感じるのでサクっと考えたいところですが、つまりは次に繋がる失敗をすれば良いってことかなと思う。失敗に対して真摯に向き合い、なぜ失敗してしまったのかを学習し、次はどうすればうまくいくのかを探し出すことが出来れば、それは価値のある失敗なんじゃないかと。

そうすると、価値のある失敗が出来るかどうかは、起案者の能力でも、ビジネスモデルの妥当性でも、市場の大きさでもなく、新しいビジネスに真剣に向き合う人そのもので決まるのではないかという結論に至った。

具体的にどうするか

どういう人なら価値のある失敗が出来るかをまとめると、

  • 事業に情熱を持って主体的に行動出来る
  • うまくいかなかったこと・失敗してしまったことを個人の責任にせず、自身あるいはチームの責任と考え対処出来る
  • やったことないこと・知らないことでも必要とあればひとまずチャレンジしてみる

こんな感じの人だろうか。少なくともぼくはこういうが好きだ。こういう人と仕事をするのは楽しい。ハッスルハッスルだ。

まだ全然プロセスが確立していないんだけどこんな風に進めてみるのはどうかなと思ってます。この間1ヶ月〜のイメージで、あえて一切ソフトウェア開発に着手しない。これによって上記のような人であることを確かめたい。同時にクライアントは我々と仕事をすることがベターなのかを判断して欲しい。

  1. 開発の相談、やりたいビジネス、作りたいものをうかがう
  2. ビジネスモデルキャンバスを書いて、それをもって議論する
  3. 画面遷移図、手書きのワイヤーフレームを書いて、またしても議論
  4. インセプションデッキを作り、MVPをもって検証したいポイントをハッキリさせる
  5. ユーザーストーリー(要件出しみたいなもの)を出してきていただき、具体的に作りたいもののイメージを固める
  6. 開発始動!

こんなことにチャレンジしてみたいと思っているのですが、もし一緒に仕事してみたいなーと思っていただけたら、ぜひお気軽にお問い合わせくださいませ。「ブログ見ました」とか書いておいていただけると話が早いかもです。

www.mof-mof.co.jp

ぼくたちは「つくって人をしあわせにする」というビジョンを持つ会社です。 だから、手段を提供した結果、何かを手にして欲しいのですよ。ぼくは。

【登壇してきました!】CEATEC JAPAN 2016にて、NRIハッカソン2016 “STARTUP AWARD”

10月7日(金)幕張メッセ。

CEATEC JAPAN 2016にて野村総合研究所が主催する「NRIハッカソン2016 “STARTUP AWARD”」が開催され、今回弊社代表の原田がトップバッターで登壇しました! f:id:mofmofnishii:20161014165117j:plain

発表させて頂いたのは、最近自社プロダクトとして開発を進める「社内問い合わせ対応専用チャットボット My-ope office(マイオペオフィス)」です。 マイオペオフィスとは、企業内のあらゆる部署から繰り返し来る、さまざま総務問い合わせや簡単な情シスに関する問い合わせ等を、担当スタッフに代わって一手に請け負ってくれる社内問い合わせ対応専用の人工知能チャットボットです。

My-ope officeは、今年の6月に先行して発表しました人工知能チャットボットMy-opeシリーズの第一弾として、企業の社内問い合わせに特化したチャットボットシステムとして企業様に導入させて頂いております。

さて、NRIハッカソンの様子、原田登壇のレポートをさせていただきます~。

午後2時。 幕張メッセに所狭しとブースが立ち並ぶ中をくぐり抜け、登壇者は皆さん控室で打ち合わせです。 原田はトップバッターで午後3時45分から登壇。 f:id:mofmofnishii:20161017091438j:plain

発表にあたっての注意事項の確認、登壇者どうしのご挨拶などを終え、ステージに向かいます。 準備中の様子。 f:id:mofmofnishii:20161017091851j:plain

原田も準備中。 f:id:mofmofnishii:20161017092127j:plain

すべての企業が発表後、各ブーステーブルが設けられており、質疑応答はそこで実際にプロダクトを動かしながら直接質問ができるという仕組み。質疑応答時間のためにmofmofスタッフも脇で準備中です。

そして、NRIハッカソンがスタートしました。 NRI社のデジタル開発部の部長が開会のご挨拶をされてました。 f:id:mofmofnishii:20161017092646j:plain

そして、がやがやとギャラリーが盛り上がってきます!ほぼ満席となったところで、原田登場。My-ope officeの発表をしっかりとさせていただきました! f:id:mofmofnishii:20161017093037j:plain f:id:mofmofnishii:20161017093051j:plain

その後、他企業さんの発表が続々となされましたが、ここでは割愛(´ω`)申し訳ない!笑 素晴らしい技術と見識をもった企業ばかりで、その意識の高さ、本気度に感銘をうけました!

発表後はみんなで写真撮影。なぜかガッツポーズをしました。 f:id:mofmofnishii:20161017093514j:plain

そしてそして、懇親会で結構飲んだくれる原田と弊社岡のショットでしめましょうw f:id:mofmofnishii:20161017093750j:plain

それではまた!

発表でしゃべりましたMy-ope officeの導入相談も承っております。お気軽にお問い合わせ下さい~♪

www.my-ope.net

わずか3日でMVPを作りきる合宿型爆速開発サービス「いきなりMVP」クライアントインタビュー(ABEJAさま)

わずか3日でプロトタイプを作りきる合宿型爆速開発サービスの「いきなりMVP」。その「いきなりMVP」で初となるクライアントインタビューに行って来ました!

mofmof広報の藤方です。

今回のクライアント様は、IoT、ビッグデータ、人工知能技術ソリューションをあらゆる産業に最適化し提供する、あのABEJAさん。そしてインタビューにご対応いただいたのは取締役CTOの緒方さんです!


株式会社ABEJA様

ABEJAさんWEBはコチラ


f:id:mofmofnishii:20160726093846j:plain


※緒方CTO

是非ご一読下さい!

いきなりMVPでの開発をご依頼頂いた一番の理由を教えてください。

自分たちのビジネスにおいて、今回は研究開発という位置づけで新しい設計を立てていたが、その設計が正しいのかどうかを検証する上で、既存システムではなく新しくフルスクラッチでのシステムが必要でした。
新システムをいち早く開発し、運用に乗せてその仮説が正しいのかどうか、早く検証したかったというのが理由ですね。
わずか3日で新システムがほぼ完成したことには、非常に満足しています。


最も良かった点は?

開発スピードももちろん期待どおりだったのですが、mofmofさんと弊社で開発チームを組んで開発を行う中で、チームのメンバーが全員同じ最終ゴールに向かってプロジェクトに取り組めた点が、最も良かったなと思っています。
一般的な受託開発会社に頼んだ場合は、こちらで全て座組みを立ててからじゃないと発注できないわけですが、mofmofさんの場合は弊社のやりたいビジョンに対して、しっかりとプロダクト開発に向き合ったうえで、どこを一番のバリューポイントにおいて開発を進めていくべきかというところまで一緒になって考えてくれました。


もっとこうすれば良くなるのでは?というポイントがあればお聞かせください。

開発合宿に入る前にチーム全体での事前準備はして行くのですが、エンジニアリングの部分においては、事前にソロで準備できるところがもう少しあったのかなとも思います。
ただ、微妙な線引きになるので一概には言いきれないですね。参考程度にしてくださいね 笑


最後に

緒方さま、大変貴重なご意見を頂きありがとうございました!