ご無沙汰してます。
ずっと、CANVUSの開発に専念しています。もうちょいで良い感じになる。
マーケティングと開発と、並行して進めるべきなのかも知れません。
でもエンジニアの退職があったり、開発のスピード感を保つためだったりで、開発に重点を置いています。
結果的によかったかも。集中してなかったら、開発がずるずる行っちゃってたわ。
リリースだけを考えるなら外注使えばいいけど、その後のビジネスを考えると今が大事。無駄はないんだけど拡張性の高いシステムができてる。
しかしサービス開発は一筋縄ではいかないですね。受託開発のがよっぽど楽だわ。
すごく勉強になる。
今の開発が落ち着いたら（あと2週間の予定）、今度はマーケティングに専念！
もうひと踏ん張り、頑張ります。
東日本大震災からちょうど2年です。
改めて、被災された皆様にお見舞い申し上げます。
震災を風化させてはいけない、と皆が言っています。それはその通りだと思います。
ボランティアに行った時のブログを見返しました。色々考えるところは多いです。
でも、”風化させない”って、なんでしょう。
あの大震災で、多くの人が、色々なことを考えたと思う。
家族を大切にしようとか、もっと楽しもうとか、精一杯頑張ろうとか、感謝の気持ちを持とうとか、人それぞれでしょう。
僕は、仕事面では、こういった大災害があったときに、もっと色々できるように力をつけよう、会社を強くしよう、そう思った。
そういった思いを、その場限りではなく、持ち続けること。そして実行に移すこと。これが、”風化させない” という1つの形ではないだろうか。
僕自身、ずっと同じ思いを持ててはいなかったと思う。でも今日、改めて思いを強くした。
さあ、また頑張ろう。
自ら調べ自ら考える力のある人物
母校の「三理想」の一節です。
昨年後半より自社サービスの開発に着手し、年明けより収入を絶って専念しています。
その中でやっぱり思うのです。
自社サービスはTOPがそれにかける情熱と時間次第
そりゃそうだ。恥ずかしながら今さら自覚しました。
正直言うと、僕がお金稼いで他のスタッフでいいサービスにチャレンジしてほしいと思っていたこともあります。
でもそんなの無理。いや、無理じゃない会社もあるかもしれないけど、普通は無理。
だって、温かく見守ってたら素敵なサービス作ってくれる人なんて、普通いませんよ。
いるとしても、見つけられないですよ。てか、そういう人は会社作ってVCから金引っ張りゃいいしね。
ただでさえ、日本では起業家の育成が問題とか言われてるのに。
うちのスタッフは頑張っているし、優秀です。
でも、そういうことじゃない。チームメンバーができるとかできないとか、そういうことじゃない。
彼らのパフォーマンスは、僕のパッションに比例する
比例どころか三次曲線くらいだ。
彼らに場を与え、教育するとか、そんなことにパワーを使うなら、それを自社サービスに注いだ方がいい。
もう少し大きい組織にいたときは、スタッフの教育とか、組織論とか、リーダー論とか色々考えていたよ。
どうやったらイノベーションが産まれる組織にするかとか。
でも答えはシンプルだった。
イノベーションが産まれる組織にするには、自分がイノベーションを産む
それしかない。
自ら調べ自ら考える。そう、自らなんだよ。
僕の人格形成に一番大きな影響を与えた母校とそこでの出会いに感謝しつつ。
また間が空いてしまいました。
サービス開発の現状をご報告します。
知人を中心に、いろいろインタビューやヒアリングをさせていただきました。ありがとうございます。
僕なりの仮説があったのですが、非常に気づきが多く、実りがありました。
本当は、もっときちんとビジネスの仮説を構築した上で、インタビューを実施すべきかも知れません。
でも、ビジネスの仮説構築に慣れてない、スキルが無い中では、このタイミングでやって良かったです。
やっぱり、思い込みで進めちゃだめですね。
リーンキャンバスを利用して、再度ビジネスモデルを描いてみました。
インタビューで、カスタマーのセグメンテーションがようやくスッキリしました。
とはいえ、ビジネスモデル仮説を精緻化するところは結構苦労しました＆してます。
というわけで、ここで１つの判断をしました。
「考えるよりもある程度作ってしまおう。」
教科書どおりだと、仮説構築→顧客の声を聞いて検証、を素早く繰り返すのかと思います。
でも、
・仮説検証のLOOPが結構慣れていなく、時間が掛かりそう
・エイヤっである程度作ってしまっても実は期間は変わらなそう
・作りたいモチベーションを失いたくない
という理由から、作りながら考える方向に切り替えました。
というわけでここしばらくはずっと開発フェーズです。
そして、ようやく最初のGOALが見えて来ました。
思ったより時間かかった。
でも、何に時間がかかったのか、次から短縮できるのか、すごく分かった。
改めて整理しますが、やっぱり製品開発でのプログラムなんて、ほんの一部なんですよね。
特に元々開発ができるチームでは。
しんどいこともとても多いですが、勉強になることもたくさんあります。
リリースしたらもっともっと勉強できるでしょう。
そして、勉強だけで終わらせない！満足しない！
当たり前ですがこれ大事！！
成功からしか学べないものがいっぱいある。勝たないビジネスはただの自己満足。
よし、ブログ書いたら気合が入ったぞ。
年明けから、サービス開発に尽力しています。
やったことは下記。
キャッチフレーズは「日本をもっとクリエイティブに。サービス開発をもっと楽しく。」です。
経験上、会社間やチーム間で、言った言わない、仕様だバグだとか、マネジメントがめんどくさい。ストレス溜まる。
どっちが正しいか議論してもそれで製品はよくならない。でも利益確保や保身につながるので、やらざるを得ない。エネルギーの使い方、ベクトルが内向きなんです。
これ、不毛です。利益確保につながるから、優秀なエンジニアもそのやりとりに駆り出されることが非常に多いんですが、不毛であることを本能で理解しているから疲弊してく。
これを解消すれば、みんな幸せなんじゃないか、WEB関連のマネジメントをずっとしてきた僕らだからこそ、できるんじゃないか。
それがビジョンです。
で、解消するためには、企画側と開発側の入口（要件定義）と出口（テスト・検収）をちゃんとやることだという仮説を立てました。
また、要件定義もテストも、いまだエクセルやらパワポという汎用的なソフトでみんなやっている気がする。
プロジェクトマネジメントやチケット管理はいろんなSaaS、ASPが出ているというのに。ということはこれはビジネスチャンスでもあるんじゃないか、という仮説も立てました。
合わせて、市場規模としてビジネスチャンスがあるのかをざっくり検証しました。
（ちなみに僕の計算だと、WEBやアプリ関連のサービス開発は、内製など含めて、ざっくり3,000億円くらいかな、となりましたが、合ってるのかな。。）
次にやったのは仮説の構築です。色々と検討する際に、事実と仮説いずれであるかを意識して、今後検証するべき項目を洗い出しています。
・会社間やチーム間で不毛な調整、ストレスがある、という仮説
・優秀なディレクターやエンジニアが、その解消のために時間を割いている、という仮説
・要件定義とテストをしっかりやればマネジメント負荷、工数は大幅に改善される、という仮説
・多くのプレーヤーが、要件定義やテストというタスクにストレスを抱えている、という仮説
・多くのプレーヤーが、要件定義やテストのやり方自体の改善に着手していない、という仮説
・エクセルやパワポで作業している、という仮説
まずはいろいろな人へヒアリングさせてもらえるよう、アポを取りました。来週からぼちぼち行ってきます。
時間を割いてくれる友人は本当にありがたいですね。あ、アポの目的を伝えてない人もいますが、まぁ、何とかなるでしょｗ
アポで確認すべきことは今整理しています。無駄にしないように。
重要なのは、仮説をきちんと検証すること。思い込みで進め、工数かけ、全然売れないものを作るのはよくない！（と勉強しました）
こちらの期待している回答を押し付けたり誘導したら何の意味もないので、そのあたりは経験ですかね。
並行して、プレオープンページというか、製品の概要と我々のビジョンを記載したページを作成しました。
アクセス解析とかを考えながら。製品のデモとかではなく、まずニーズがあるのか、ビジョンはおかしくないのか。そういうことを確認するのが目的です。
これらを合わせて、もろもろ仮説を検証していこうと考えています。
以上、現状のご報告でした。