毎日がもふもふ

新規事業に特化した渋谷の開発会社mofmof inc.を経営するエンジニア兼代表・原田敦のブログ

システム開発の目的は、成果物を実現することではなく価値を実現すること

f:id:redhornet96:20170908120216p:plain

開発「仕様通りに出来上がりました!検収お願いします。」

顧客「うーん。こうじゃないんだよなー。ここって直せませんか?」

開発「そういう仕様なので追加費用をいただかないと無理です。」

顧客「いや、でもそれじゃ困るんですよ。。。」

開発「いやいや、だってこうだって言ったじゃないですか」

システム開発の業界に従事している方ならあるあるーって話なんじゃないかと思います。

こんな経験がある方はぜひ今一度自分達が提供したものが本当に「価値」を実現していたかどうか、細い目で悠久の時に思いを馳せながら、ゆったりとリラックスした姿勢で続きを読み進めてください。

ところで価値とはなんでしょう?

ソフトウェアにおける価値とは非常に重要な概念であるにも関わらず、その抽象性の高さから、あまり議論の中心には上がることがなく、なんとなく暗黙的ままでプロジェクトが進行していることが多い。

今回は、普段システム開発に従事しているプログラマや、プロジェクトマネージャー、ひいてはプロダクトオーナーなど、システム開発に直接携わる人向けに「価値とは何か?」という話を書きます。

ソフトウェアにおける価値とは何か

改めてもう一度。価値とはなんだろう?

普通の人はそんなこと聞かれても「は?」とか「なんか意識高いキモいヤツが現れたぞ!逃げろ!」としか思いませんよね?

話を掘り下げるために対象物を用意しましょう。弊社の一事業である、AIチャットBotサービス「My-ope office」の価値がなんなのか考えてみよう。

www.my-ope.net

My-ope officeで想定している1つ目の価値は、従業員が業務に関して何か不明点が発生したときに、情報を探したり、誰かに質問することを躊躇したりという時間を減らし、組織として業務の効率をアップすること。

2つ目の価値は、総務部や情シス部など、質問を受ける側が、度々同じような質問を受け、その度に同じような回答を繰り返す、というオペレーションのムダを削減することです。これにより、担当者は自身の業務を進める時間をもっと確保出来るようになること。

どんな課題を解決出来たら、ユーザーが心から喜ぶのか?それを突き詰めて表現した言葉が「価値」を表します。

大きく分けると価値にはプロフィットセンターかコストセンターかで二種類に切り分けることが出来て、前者は利益を増やすもの。後者はコストを減らすものです。従ってMy-ope officeは後者にあたる。

利益かコストか、そのいずれかを大きく変動させるポイントが何か?それが価値に直結する。ちなみにコストには金銭的なコストだけでなく「心理的コスト」というものも含まれたりする。

煩わしいと思っていることをいかに減らすか?という点も価値につながるので、数値的なものだけでなく人の心理にも着目するとなお良い。

どうやって価値を理解するのか?

価値を理解するには自分がユーザーのつもりになって想像し、感じる必要があります。ぼく自身も作り手なので分かるのですが、作り手はこれが苦手なことが多いです。「機能を実装する」という手段にフォーカスし過ぎて目的を想像することが得意じゃない。

せっかくなので、それっぽいこと言っておくと、価値とは「点」なんですよ。「面」ではなく「点」。

「My-ope officeを導入すると業務が改善してコストが減るんですよ」という言葉は面でしか語っていないから、この言葉だけではユーザーがどういう風に心から喜ぶかが想像できない。

価値を「点」で表現するには、アジャイル開発におけるドキュメントの一つ「インセプションデッキ」の「エレベーターピッチ」というのがオススメ。詳しい説明は省きますが、どんな目的でどんなゴールを達成したいかを表現するものです。

ポイントとしては、顧客に作っておいてもらうだけでなく、開発サイドでも作ってみるのが非常に良いです。自分が立てた価値の仮説と顧客が考えている価値にどれだけズレがあるか分かるので大変面白い。

f:id:redhornet96:20170908120709p:plain

あとは普段から「価値」を理解しようという習慣を身につけるべし。価値を理解出来るようになるためにやると良いのはこんな感じ。

  1. まず一番最初に、自分は「価値」を理解しているという思い込みを一旦全て捨てる
  2. 作って欲しいものの相談を受けたら、一番最初にどの点が「価値」なのか仮説を思考する
  3. 思考した仮説を相手にぶつけてみる。「そうそうそう!それなんですよ!」というちょっと大げさな反応が出たら当たり(反応が小さくてもハズレとは限らない。個人差がある)
  4. 上記のことを開発相談されるごとに繰り返し、3の当たり精度を上げていく

これをやっていくと確実に価値を見極める仮説思考が鍛えられていくのでぜひチャレンジしてみてね。

計測したわけではないけど、こういう話が出来る人は実は少ないので、作り手サイドの人は受注率が上がるかも知れない。少なくともぼくは何か外注する時、こういうことをちゃんと考えられる人にお願いしたいと感じる。

成果物の実現ではなく、価値の実現を目指せ

everyday.mof-mof.co.jp

以前にイケてるエンジニアの振る舞いについて書きましたが、イケてる人はこの「価値」を確実におさえて、そこへ向かって仕事をしてる。そうでない人と決定的な程に差がある。

「言われた仕様の通りに作ったのに、顧客からこんなんじゃないって怒られた」みたいなトラブルは、この業界あるある話だけど、そもそも「価値」を実現しようとしないで「成果物」だけを実現しようとしてるからそうなるんじゃないかと思ってます。

作り手側の人で、あ、こういう経験あったな、と思った人は今一度自分は顧客が求める価値を理解して、価値を実現するためにものを作っていたかどうか自問してみてもらえたらいいな。

と若き日の自分に言いたい。

こんな話を書いていたらインセプションデッキを作り方を学ぶ勉強会を企画したくなってきた。もし「聞きたい!」という方もしいたら個別にメッセージがWEBサイトから問い合わせいただければ、開催時に招待するかもしれない。

www.mof-mof.co.jp

https://www.facebook.com/harada.at.sea4

ベンチャー企業の経営者は死ぬほど働いてはいけない

f:id:redhornet96:20170825175216j:plain

こんにちは、はらぱんことmofmof inc.代表の原田です。

今回はベンチャー企業の経営者やその役員など、普段忙しすぎてめまぐるしい日々を送っていてロクに寝ていない方向けに「ちゃんと寝るべし!」と主張したい。

1日3時間しか寝てないんすよーとか、お前はナポレオンなのか。偉人か何かなのか。すげえな。

「私は偉人です」という方は続きを読まなくていいです。偉人ならば仕方ない。ロシアあたりに遠征行ってろ!

かくいう、ぼくはエンジニア出身の凡人経営者なんですが、最近組織として10名を超えるあたりに来て、「組織を作る」とか「組織を動かす」とかいうことの重要性についに気づいてしまった。

やっぱりアレですね、エンジニアとしての仕事と経営者としての仕事はかなりギャップがあって、日々新しいことに気づいたり学んだりすることがいっぱいです。人生学ぶことは尽きませんな。

経営者は仕事は組織のパフォーマンスを最大にすること

ぼくは、経営者がやるべき最も重要な仕事は「会社全体のパフォーマンスを最大にすること」だと思ってます。偉そうに言い切っていますが、ぼくはこの考えに至るまで2年以上かかったりした。

ちょうど数ヶ月前、とある新規事業の開発業務とビジネス側の業務を一人でやっていたのですが、お客様と約束した機能を翌日までに実装しなければならないにも関わらず、ミーティングやら他業務に忙殺されて、いつになっても開発に取り掛かれそうにない状況に陥り、にっちもさっちも行かなくなって大変困ってしまったことがありました。

実は「俺最強だし本気出せば人の3倍くらい仕事出来ますしおすし」とか思ってたフシもあるのですが、そのときはじめて、いかに自分が気合を入れて猛烈に働いたところで、せいぜい人1.5人分くらいの成果しか出せず、目標に向かって成果を上げるにはチームで手分けしないと行き詰まることを身をもって知りました。

チームで成果をあげるためには、チームを導く人間が必要です。開発の仕事に集中してしまっていては、チームを見ている余裕がありません。ぼくがやるべきはチームとしての成果を最大にすべく、個々をチューニングし改善していくことだと気づきました。その方が自分で開発を続けることより長期的には成果を大きく出来るはず、そう考えました。

疲れていては人を思いやれない

f:id:redhornet96:20170825175417j:plain

チームとしての成果を最大にするために、経営者にとって最も必要なことは何か?と問われれば「経営者自身が常に元気でいること」だと思っています。

以前は「俺最強だし、1日18時間労働とか余裕ですしおすし」とか思って長時間労働が常態化し体力がカラカラに枯渇している日々を送っておりました。

そんなとき、自分に若手をつけてプログラミングを教えることになったのですが、言ったことちゃんとやってくれなかったり、いまいち気が利かないことだったり、些細なことにイライラし、ぶっきらぼうな態度をとりがちになってしまいました。

結果的に、見どころがあったその若手は、ぼくの態度に理不尽さを感じて1年たたずに退職するに至りました。このときの経験は、今の考えに至る大きなきっかけになっています。

組織を成長させて、成果を最大にするためには自分以外の人がパフォーマンスを上げてくれるように工夫しなければなりません。そうなったときに、仕事の成果はスキルや能力といったものより個々の「気持ち」と切っては切れない関係になります。

例えば以下のようなことが経営者の重要な仕事だと思っています。

  • メンバーが困っていることはないかを知り、それを取り除くこと
  • メンバーの良くない振る舞いにフィードバックを出し、良い方向へ改善していくこと
  • 会社としてどこへ向かっているかを表現し伝え続けること
  • 自らの意志で自発的な仕事が出来るように動機づけすること

ともすると、具体的なアクションは全て「コミュニケーション」になります。コミュニケーションにはテクニックのようなものもありますが、やはり基本は、おもいやりや誠意というような気持ちのベースの上に円滑に成り立つと思ってます。

人は疲れているとイライラしやすくなります。イライラをぶつけられた人間は理不尽を感じ、やる気を失ってしまいます。だから、常に誠意を込めて、相手を思いやったコミュニケーション出来るようにするために経営者自身が元気でなければならないと思うのですよ。

会社経営を短距離走と見るか、長距離走と見るか

よく「経営者は死ぬほど働け」と主張する方もいます。短期的にはそれでも良いかもしれませんが、実際それは精神論でしかなくて、「経営者はちゃんと休め。常に元気でいろ」って言ったほうが長期的には組織として良い成果が出せるはずだと思ってます。

ぼくは会社経営を長距離走だと思っています。自分の呼吸と体力の限界を超えたペースで走っていては、ゴールどころか途中リタイアもありえます。だったら少しずつだったとしても一定のペースをコントロールして前へ進み続けることの方が有益だなーと思っているわけです。

世の中の経営者はそんなにタフなんですかね。ぼくは1日でも徹夜したらダメです。翌日まるで使い物になりません。もうボロクズです。

でも世の中には実際猛烈に働いているのに関わらずいつも快活な人っているよね。ああいう人は死ぬほど働いていても大丈夫なのかな。不思議だ。

もしやナポレオンなのか?偉人なのか?

イケてるエンジニアor開発会社に外注したいときの3つの見極めポイント

f:id:redhornet96:20170710190325j:plain

mofmofのエンジニア兼代表取締役の原田ことはらぱんが書いてます。2017年8月、皆さんごきげんよう。アツはナツいですね。

例えばエンジニアのいない企業が、システム開発を誰かにお願いしたいなーと思ったとき、知り合いのエンジニアだったり開発会社に相談すると思うのですが、どういうポイントを見れば失敗する確率を最小限に出来るか考えてみた。

エンジニア採用の話ではないので誤解なきように。

そんなに頻繁ではないのですが、ぼく自身も専門外の仕事を誰かにお願いしたり、外注したりっていうこともあります。

とりあえず相談して話は聞いてみたりはするけど、どういう点を見ればいいかって意外と難しいし、正直発注した結果後悔してしまったことも少なくなかったです。

中でも複雑で曖昧なものを扱うシステム開発は、非常に難しい部類だと思っていて、ここでうまくやるか失敗するかでプロジェクト全体の運命を決めるといっても過言ではないです。

ぼくが過去会った人や一緒に仕事をしたことのある優秀な人達の振る舞いを思い出してみます。

良いエンジニア・開発会社を見極める3つのポイント

  • 具体的に何を作るかよりも先に、何を実現したくて作ろうとしているかを掘り下げてくれる
  • 仕様変更が発生することを想定した計画を立てることが出来る
  • 予算・期間・期待価値の3点を考慮し、最善の着地点を提案してくれる

これはエンジニアの仕事じゃねえぞって言う人もいそうですが、仮にエンジニアの仕事じゃなかったとしても、チームの中で誰かがこういうことを気にかけてないとコケる。

ちなみに焼きそばを焼くのはエンジニアの仕事なのかという件については、ぼくは焼きそば焼きたいタイプです。

何を実現したくて作ろうとしているかを掘り下げてくれる

f:id:redhornet96:20170710190654j:plain

良い作り手は、成果物を作って納品することではなく、作ったもので価値を実現することをゴールだと考えてます。なのでまず最初にその事業(プロダクト)のコアバリューが何なのかを理解しようとしてくれます。

例えば、転職希望者と企業をWEBでマッチングする新規事業を作ろう、という場面だったときに、もしかしたらTinderライクに右左にスワイプする気持ちいいマッチングUIで勝負したいのかも知れないし、実は在日フィリピン人特化のニッチなマッチングなのかも知れない。例は適当、他意はない。

それが分かれば、何を達成すればその成果物が価値を生むのか理解出来るので、あとはそれに実現するための計画を立てれば良い。極端な話、それさえ実現出来ればあとの機能とかは全てオプションなわけで、実はなくても構わなかったりもする。

一般的にシステム開発界隈では21世紀になってもなお「仕様変更だ!」「バグだ!」みたいな争いが未だに絶えないんですが、実はこの「ゴール」の認識がズレてるからそうなるんじゃないかと思ってる。ちゃんとゴールに到達していればこんな泥仕合にはならんと思うですよ。

なので、プロダクトや事業の概略を伝えた際などに「どのポイントが他サービスとは違うのか?」「どうやって利益を上げるのか?」みたいな作るものに関する直接的な仕様以外の話に興味を持ってくれる人は非常に頼りがいがあるし、実際うまくやってくれた。

仕様変更が発生することを想定した計画を立てることが出来る

ウォーターフォールとかアジャイルとかの手法に限らず、仕様変更は必ず発生するですよ。要件定義を完全無欠にして完璧なものを作り、仕様変更をゼロにする!とかいう幻想は捨てるべし。そんなん全然現実的じゃない。初登場時のクリリン一人で魔神ブウを倒すってくらい無理ゲー。クッキーにされて食べられちゃうよ。

なので、どういうやり方を取るにせよ仕様変更に対応出来るような計画を立てられることが重要。

スケジュール作成を含めてお願いしているケースであれば、設計・製造・検証やらのいくつかのフェーズで分かれていると思うので、検収フェーズ後に修正対応出来る期間が含まれているとちょっと安心出来る人。

ちなみにmofmofからどなたかに発注するときは、最初から仕様が変わることを想定して、月額制か時給制で契約していることが多いので普段はあんまり意識していることはないかも知れない。

予算・期間・期待価値の3点を考慮し、最善の着地点を提案してくれる

しばしばシステム開発と製造業は同じように取られることも多いけども、実際のところ「完成」という着地点が可変である点で違う。

一般的には、「不変」に出来ることを前提として、要件を固めるために、要件定義書とか設計書のExcel方眼紙が血でにじむくらい努力しているわけなんですが、上で書いたとおりそれはちょっと難しい。

予算・期間・期待価値を伝えたとき、予算と期間を固定した場合におおよそ実現出来そうな着地点と、期待価値を固定した場合の予算と期間を、回答してくれた人が過去にいて「こやつめデキる…!!」と感じましたし、実際相当手練なおじさんでした。

ちなみにポイントとしては、予算内で「実装できそうな機能」ではなく「実現出来そうな価値」ということを念頭おいて提案してくれたように思えます。言葉で表現すると難しいんだけど、実現したいことを実現するためのミニマムな投資がどれくらい必要なのかを伝えてくれる感じ。

他には一通りやりたいことを伝えた後に、後日機能を一覧化してそれぞれに重みをつけて「この中からどの部分を仕様から落とすことが出来ますか?」っていう風に話を進めてくれた例もあって割りと良いと思った。

価値を提供するのか、単なる成果物を提供するのかの違い

ぼくの過去の経験から良いなーと思ったケースを上げました。主観なので「ソースは俺」くらいの話かも知れないけど、つまりは「価値を提供しようとしている人か、単なる成果物を提供しようとしている人か」という違いだと思う。

前者の方が素敵なのは言うまでもない。

弊社mofmof inc.では月額制の受託開発「開発チームレンタル」をやっております。もし身近に良いエンジニアや良い開発会社なくて困っているーなんて方がいらっしゃいましたら、いつでも下記WEBサイトなどからお気軽にご相談いただければ嬉しいです。

www.mof-mof.co.jp

生産性が通常の3倍になる「タイムボックス」のススメ

f:id:redhornet96:20170726143741j:plain

生産性上げたいよね生産性。わかるわー。

最近ニュースで見ましたが、経済財政白書によると「労働時間短いほど生産性上がる」という画期的な事実が明らかになったようで、ついに時代がぼくの思考に追いついてきたな、とほっこりした気持ちになっています。

news.careerconnection.jp

ある人は生産性を上げて早く帰りたいのかも知れないし、またある人はもっと仕事の成果を上げたいのかも知れません。

それぞれ違った目的があるとは思いますが、生産性は高くて困ることはないので、まあ労使ともに一般的には生産性は上げるのは良いことだと考えていいかなと思います。

生産性とは?

そもそも生産性とは何だろう。なんとなく感覚的に使っている言葉ですが、どう捉えると良いか。

我らがWikipedia大先生にはこう書いてある。

生産性=アウトプット/インプット

つまり、少ないインプット(作業量)で多くのアウトプット(成果)を出せることを生産性が高いと言うことです。

ところでソフトウェア開発においては「成果の尺度」って難しいですよね。作った量を成果としてしまうのはLOC見積もりとかに例示されるように、本質的な価値とは比例しないし、かといって売上とか利益を成果をすると、ソフトウェア開発という営み単独では評価が出来ないという問題もあったり。

すみません、ただの余談でした。

まあこれを掘り下げてしまうと400字詰め原稿用紙が256枚くらい必要になりそうなので、あえて掘り下げないでおこう。

長時間労働は生産性を下げる

アウトプット割ることのインプットが生産性であるとした場合、長時間の労働はインプット過多だから、当然生産性が下がる。

簡単な算数の話ですね。最近のサルはgitも分かるらしいから、これくらいはサルでも分かるんじゃなかろうか。

従って、生産性下がるから長時間労働はやめて早く帰ろうぜー。おしまい。

と思いきや、そうも問屋が卸さない的な話でして、我らが日本国にはですね、苦難に耐えることを美徳とする厄介な文化があるとかで、結果とは無関係に「一生懸命頑張った」で評価されたりとかする傾向があるみたいです。

正直日本にしか住んでたことがないので、ホントのところ外国ではどうなのかは知らんけど。

ただ観測の範囲で言えることは、長時間労働することにより、確実に思考は鈍る。ぼくも経験があるけど、疲労は長期的に蓄積するものなので、解消するときにも長い時間がかかる。その間は明晰な仕事が出来なくなる。

鈍い頭でダラダラ仕事をすること(させること)は誰の得にもなっていないということです。

生産性を上げるにはタイムボックスを短くする

ぼくは生産性を最大限に引き上げるには「タイムボックス」を持つことが効果的だと思ってます。

タイムボックスというのはアジャイル開発の中の概念らしいのですが(今さっき初めて知った)、計画における固定された期間のことです。

例えばリリースのタイムボックスだとしたら、◯月◯日がリリース日です、と言った場合に今日からその日までの期間がタイムボックスになります。これは原則変更しちゃダメで固定するものとします。その固定されている箱の中で現実的にやれることを計画しようってことです。

このタイムボックスは小さいサイズで考えれば、作業の一つ一つにタイムボックスを設けることもできます。例えば、今度のプレゼンの資料を作るというタスクに対して、2時間というタイムボックスを設けるというやり方が出来ます。

この考え方をすることのメリットは、かの有名な悪魔の法則「パーキンソンの法則」の対策になります。パーキンソンの法則というのは「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」というアレです。これを読んでいる出来るビジネスパーソンの皆さんは既に知っているとは思いますけどね!

完璧・完全を目指せば目指す程、仕事の生産性は下がっていきます。必要最小限である仕事を高速にこなす方が結果的に良い仕事になるのです。だからタイムボックスを設けることは生産性に大きく寄与する。

f:id:redhornet96:20170726143529p:plain

ちなみにタイムボックスはある程度短い方が良いと思います。人間が直感的に理解できるのは直近のものごとだけで、期間が長いと人間はそのタイムボックスの大きさを直感的には把握できません。ほら夏休みの宿題とか、終了間際で気合でどうにかしてたでしょ?

仕事はそれを達成するためのミニマムのタイムボックスを設定すること。それが生産性を上げる秘訣だと思ってます。

ぼくは会社の定時というのをこのタイムボックスとして考えていて、残業をするという行為はタイムボックスの制限を変えてしまうということなので、例外的な場合以外はやらないほうが仕事の成果は高くなると思ってます。

結論とポモドーロについて

  • タスクに着手する前に費やして良い時間を決めて、必ずその範囲で終わらせること
  • なるべく定時になったら帰ろう(定時がない人は1日の仕事時間を予め決めておき、その時間を越えて仕事しない)

「何かを調査する」とか「プレゼン用のスライドを作る」とかそういうタスクって明確に終わりが存在しないから、やろうと思えば何時間でもかけることが出来てしまいますが、そういうタスクをやるときにタイムボックスをキープするには「ポモドーロテクニック」がお勧め。生産性3倍は赤い人もビックリですが、1.2倍くらいならイケそう。

詳細に書くとアレなので書きませんが、簡単に言うと25分仕事して5分休むっていうサイクルを繰り返す仕事法です。

245cloudというWEBサービスでみんなでポモドーロ出来るのでオススメです。

245cloud.com

f:id:redhornet96:20170801132226p:plain

さあこれであなたもプロダクティブな毎日を!

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

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)や受託開発ビジネスも粛々と成長していて人が不足気味になってきました。

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