昨日は知り合いのおすし屋さんを貸しきって
ＮＤ局のメンバーの昇格祝い。
彼らはアメーバの中でもピグなどのフロント部分を
主に担っているスーパークリエイター達。
これからも更なる活躍を期待してます！
ＮＤ局のメンバーの昇格祝い。
彼らはアメーバの中でもピグなどのフロント部分を
主に担っているスーパークリエイター達。
これからも更なる活躍を期待してます！
一年前のＩＶＳで初めて「キャズムを超えろ！
」の
和蓮和尚に会って、そのコンセプト商品を見て
これは絶対に来る！と思ってECナビでも
ちょっとだけ出資させていただいたCEREVO 。
最近、ようやくその最初の商品、
「撮ったあと、送るまで」が劇的に簡単なカメラ
CEREVO CAMが発売予約が開始されました。
既にtwitter界隈でも結構話題になっているようですが、
http://twitter.com/#search?q=cerevo
先行予約に限っては５００円引きになったり、
限定カラーがあったりと特典がついてます。
そしてもちろんECナビでもECナビ会員限定で
発売記念キャンペーンをやってます。
http://point.ecnavi.jp/campaign/cerevo/
とりあえず僕が注文したのは初回限定バージョンの黒色。
早く手元に届くのが楽しみ。
ブログの投稿先に早くアメブロも入れて欲しいな。。。
和蓮和尚に会って、そのコンセプト商品を見て
これは絶対に来る！と思ってECナビでも
ちょっとだけ出資させていただいたCEREVO 。
最近、ようやくその最初の商品、
「撮ったあと、送るまで」が劇的に簡単なカメラ
CEREVO CAMが発売予約が開始されました。
既にtwitter界隈でも結構話題になっているようですが、
http://twitter.com/#search?q=cerevo
先行予約に限っては５００円引きになったり、
限定カラーがあったりと特典がついてます。
そしてもちろんECナビでもECナビ会員限定で
発売記念キャンペーンをやってます。
http://point.ecnavi.jp/campaign/cerevo/
とりあえず僕が注文したのは初回限定バージョンの黒色。
早く手元に届くのが楽しみ。
ブログの投稿先に早くアメブロも入れて欲しいな。。。
最近、ブログでの情報発信を意識的に多くしています。
事業部制、SBUの担当役員制を進めていくなかでどうしても
ダイレクトに現場の人とのコミュニケーションが
難しくなっているためです。
伝言ゲームじゃないけれど、
僕⇒担当役員⇒事業責任者⇒リーダー⇒現場
となると、圧倒的に時間がかかるし、途中で
メッセージ内容が変わってしまったり、亜空間に
飛ばされてしまうこともある。
例えばちょっとページのHTMLを直すような
すぐに修正できるようなことが指摘してから
１ヶ月や半年もほったらしかしになってしまったり。
事業ごとにビジョンや戦略をきちんと
明文化し、共有するのは大事。
ただここに注力しすぎるとみんなの意識が
戦略に向きすぎて、ユーザービリティといった
直接に収益を生まないようなところへの対応が
おろそかになったり、優先順位が下がったりする。
何をやるか、というTODOを決めるのではなく、
何を重視するのか、なぜ重視するのかという
本質を理解、共有し、どうやるかは現場で
考えられるチーム、これが僕の理想。
そういう意味でこうやってブログに書くことで
タイムリーに、かつダイレクトに僕の言葉で
皆に伝えることが出来る、というのは本当に便利。
素晴らしい経営ツールだと思う。
ただこれだけが全てじゃなく、より深く直接の
コミュニケーションも同時に必要だとも思う。
うまく組み合わせながらブレのないチーム作りを
支援していきたいと思います。
事業部制、SBUの担当役員制を進めていくなかでどうしても
ダイレクトに現場の人とのコミュニケーションが
難しくなっているためです。
伝言ゲームじゃないけれど、
僕⇒担当役員⇒事業責任者⇒リーダー⇒現場
となると、圧倒的に時間がかかるし、途中で
メッセージ内容が変わってしまったり、亜空間に
飛ばされてしまうこともある。
例えばちょっとページのHTMLを直すような
すぐに修正できるようなことが指摘してから
１ヶ月や半年もほったらしかしになってしまったり。
事業ごとにビジョンや戦略をきちんと
明文化し、共有するのは大事。
ただここに注力しすぎるとみんなの意識が
戦略に向きすぎて、ユーザービリティといった
直接に収益を生まないようなところへの対応が
おろそかになったり、優先順位が下がったりする。
何をやるか、というTODOを決めるのではなく、
何を重視するのか、なぜ重視するのかという
本質を理解、共有し、どうやるかは現場で
考えられるチーム、これが僕の理想。
そういう意味でこうやってブログに書くことで
タイムリーに、かつダイレクトに僕の言葉で
皆に伝えることが出来る、というのは本当に便利。
素晴らしい経営ツールだと思う。
ただこれだけが全てじゃなく、より深く直接の
コミュニケーションも同時に必要だとも思う。
うまく組み合わせながらブレのないチーム作りを
支援していきたいと思います。
全ての商品やサービスにはコストがかかる。
だからこそひとつひとつ買ったり、払ったりする度に
これは適正なコストなんだろうか。
もっと安くすることは出来ないんだろうかって考えます。
そして金額が大きいものは当然アイミツをとる。
ただ一方で、コストであってもそこに投資の
意味合いが含まれる場合もある。
例えばまだやったことのようない新しい手法の
広告だったり、オフィスの内装のように
投資することで中長期に渡ってリターンが
あるものがそれに該当する。
こういうコストに関しては、目先の金額の多
寡や直接的な効果だけで判断しないようにしている。
ただこういう部分ってともすると人によっては
なんで細かい部分はケチなのに無駄なことに
お金をかけるんだろう？って思うかもしれないけど。
経営者として当然のように筋肉質な組織を
つくり、コストも削減することは必要だけれど
それ以上にビジネスをどう成功させるかが
より重要なミッション。
会社にとってお金は株主から預かっている大事な資産。
これをちゃんとビジネスの成功につなげるためにも
無駄は省きながらも出来るだけ次に繋がる
生きたお金の使い方を意識していきたいと思います。
だからこそひとつひとつ買ったり、払ったりする度に
これは適正なコストなんだろうか。
もっと安くすることは出来ないんだろうかって考えます。
そして金額が大きいものは当然アイミツをとる。
ただ一方で、コストであってもそこに投資の
意味合いが含まれる場合もある。
例えばまだやったことのようない新しい手法の
広告だったり、オフィスの内装のように
投資することで中長期に渡ってリターンが
あるものがそれに該当する。
こういうコストに関しては、目先の金額の多
寡や直接的な効果だけで判断しないようにしている。
ただこういう部分ってともすると人によっては
なんで細かい部分はケチなのに無駄なことに
お金をかけるんだろう？って思うかもしれないけど。
経営者として当然のように筋肉質な組織を
つくり、コストも削減することは必要だけれど
それ以上にビジネスをどう成功させるかが
より重要なミッション。
会社にとってお金は株主から預かっている大事な資産。
これをちゃんとビジネスの成功につなげるためにも
無駄は省きながらも出来るだけ次に繋がる
生きたお金の使い方を意識していきたいと思います。
今朝のエントリーでネットサービスでは
UIを開発する専属チームがあったほうがいいという話を書きました。
で、このチームにおいて必要なのは改善し続けること。
１つの機能を作ったら、次の機能を作るのではなく、
どうやったらユーザーの体験が向上するかという視点で
改善し続けること。
例えばECナビラボで開発・運営している
ソーシャルブックマークのBuzzurl（バザール） では
βサービスということもありますが、開発者でもある
S藤さんが自分が欲しいと思うものを日々どんどん
変えながら改善していってます。
俊敏なベンチャーではこうやって日々改善しながら
（もちろんその裏には失敗もあるだろうけど）それでも
どんどん前に進み、改善されていく。
実際、mixiのソーシャルアプリではそれが顕著に
出ている。
そのためには繰り返しになるかもしれないけれど
エンジニアが自分で考えて自分で便利だと思うものを
日々改善していける、そういう権限委譲だったり、
そういうカルチャーを作らないといけない。
何かトラブルが起きたときに、それを攻めたりしては
いけない。そもそもそういうリスクがあることを前提と
してそういうやり方でやっているのだから。
そうやって周りでフォローしあってこそ、初めて
安心していいサービスが作れる。
あと、ユーザービリティの向上に関する開発（というか
チューニング）は日々どんどん変えていくべき。
そしてそのアクセス分析をABテストなどを繰り返しながら
フィードバックする。
最後にどんな改善をすべきか、についてですが
ディレクターや開発者は小さな開発（チューニング）を
軽視しがち。
でも大きな機能開発を１００日かけて１つやるよりも、
ユーザー目線で１日で出来ることを１００個やるほうが
ユーザービリティの向上には繋がりやすい。
特にユーザービリティに関しての失敗は日々次の
アクションに結び付けていくためには必要な１ステップ。
失敗なんて恐れる必要は全然ない。
これらを踏まえて良いサービスを開発し、
ビジネスを成功させていって欲しいと思います。
UIを開発する専属チームがあったほうがいいという話を書きました。
で、このチームにおいて必要なのは改善し続けること。
１つの機能を作ったら、次の機能を作るのではなく、
どうやったらユーザーの体験が向上するかという視点で
改善し続けること。
例えばECナビラボで開発・運営している
ソーシャルブックマークのBuzzurl（バザール） では
βサービスということもありますが、開発者でもある
S藤さんが自分が欲しいと思うものを日々どんどん
変えながら改善していってます。
俊敏なベンチャーではこうやって日々改善しながら
（もちろんその裏には失敗もあるだろうけど）それでも
どんどん前に進み、改善されていく。
実際、mixiのソーシャルアプリではそれが顕著に
出ている。
そのためには繰り返しになるかもしれないけれど
エンジニアが自分で考えて自分で便利だと思うものを
日々改善していける、そういう権限委譲だったり、
そういうカルチャーを作らないといけない。
何かトラブルが起きたときに、それを攻めたりしては
いけない。そもそもそういうリスクがあることを前提と
してそういうやり方でやっているのだから。
そうやって周りでフォローしあってこそ、初めて
安心していいサービスが作れる。
あと、ユーザービリティの向上に関する開発（というか
チューニング）は日々どんどん変えていくべき。
そしてそのアクセス分析をABテストなどを繰り返しながら
フィードバックする。
最後にどんな改善をすべきか、についてですが
ディレクターや開発者は小さな開発（チューニング）を
軽視しがち。
でも大きな機能開発を１００日かけて１つやるよりも、
ユーザー目線で１日で出来ることを１００個やるほうが
ユーザービリティの向上には繋がりやすい。
特にユーザービリティに関しての失敗は日々次の
アクションに結び付けていくためには必要な１ステップ。
失敗なんて恐れる必要は全然ない。
これらを踏まえて良いサービスを開発し、
ビジネスを成功させていって欲しいと思います。
昨日の開発のスピードアップに引き続き、
収益化とユーザビリティについて書いておきたい。
ビジネスを考えるうえで、収益化とユーザビリティは
両輪でどちらも欠けてはいけないのは自明なんだけど
難しいのはこのバランスをどうとるか。
そして事業責任者として結果が出る人と
そうではない人の差が出るのもここの差であることが
多いように思う。
収益化に走りすぎるとユーザービリティが落ち、
結果として中長期にメディア・サービスを育てていく
ことは難しくなる。
一方でユーザービリティに走りすぎると全然収益化
できなくて、そもそもサービスの継続が出来ない。
だからこそこの両輪をいかにバランスよく
まわすが重要なんだけど、どちらかに偏った
見方をしている人が多いように思う。
これはその会社が置かれている事業環境や
その会社の個別事情によっても違うので
一概にどうすればいいという正解があるわけじゃないから
難しいんだけど、ね。
僕が思うに事業も組織もある程度の規模になったら、
ひとつの事業部の中の組織を下記のように３つに
分けたほうがいいと思う。
①収益化を考えその事業化を考えるチーム
②ユーザービリティを考え、いかに便利にしていくかを考えるチーム
③オペレーションの効率化を考え、いかにコスト削減を行うか、というチーム
少ない人数だとどうしても兼務が多くなって
複数のミッションを背負って、やりがちだけど
その結果、何を重視するのか本人も誰も判別できなくなって
トップだけしか判断できない、そういう組織が出来上がって
しまう。こうなるとQに一回優先順位を決めてその開発を
行う、みたいなことになりスピードが上がるわけがない。
重要なのはひとりひとりに明確なミッションを与え、
裁量権を渡して自分で考え、自分で進められるような
チームを作ること。
こういうチーム構成にするともちろん無駄も発生する。
重複したり、非効率だったり。
それでもスピードが落ちることにより発生する
事業機会の逸失に比べたら全然マシなことが多い。
スピードが遅いことによる事業機会の逸失は見えない
ことが多い一方で、無駄や非効率はすぐに目につき
やすく、気になりやすいもの。
木を見て森を見ずとならないようにしたい。
収益化とユーザビリティについて書いておきたい。
ビジネスを考えるうえで、収益化とユーザビリティは
両輪でどちらも欠けてはいけないのは自明なんだけど
難しいのはこのバランスをどうとるか。
そして事業責任者として結果が出る人と
そうではない人の差が出るのもここの差であることが
多いように思う。
収益化に走りすぎるとユーザービリティが落ち、
結果として中長期にメディア・サービスを育てていく
ことは難しくなる。
一方でユーザービリティに走りすぎると全然収益化
できなくて、そもそもサービスの継続が出来ない。
だからこそこの両輪をいかにバランスよく
まわすが重要なんだけど、どちらかに偏った
見方をしている人が多いように思う。
これはその会社が置かれている事業環境や
その会社の個別事情によっても違うので
一概にどうすればいいという正解があるわけじゃないから
難しいんだけど、ね。
僕が思うに事業も組織もある程度の規模になったら、
ひとつの事業部の中の組織を下記のように３つに
分けたほうがいいと思う。
①収益化を考えその事業化を考えるチーム
②ユーザービリティを考え、いかに便利にしていくかを考えるチーム
③オペレーションの効率化を考え、いかにコスト削減を行うか、というチーム
少ない人数だとどうしても兼務が多くなって
複数のミッションを背負って、やりがちだけど
その結果、何を重視するのか本人も誰も判別できなくなって
トップだけしか判断できない、そういう組織が出来上がって
しまう。こうなるとQに一回優先順位を決めてその開発を
行う、みたいなことになりスピードが上がるわけがない。
重要なのはひとりひとりに明確なミッションを与え、
裁量権を渡して自分で考え、自分で進められるような
チームを作ること。
こういうチーム構成にするともちろん無駄も発生する。
重複したり、非効率だったり。
それでもスピードが落ちることにより発生する
事業機会の逸失に比べたら全然マシなことが多い。
スピードが遅いことによる事業機会の逸失は見えない
ことが多い一方で、無駄や非効率はすぐに目につき
やすく、気になりやすいもの。
木を見て森を見ずとならないようにしたい。
最近、社内で新規事業を井戸掘りに例えた話をよくします。
井戸掘りでやることはシンプルに３つ。
１．水の出そうなところを見つける。
２．掘るための道具や人を調達する。
３．水が出るまで掘り続ける。
いかに掘る力があっても、そもそも水脈の出ないところを
どれだけ掘っても水は出ない。
だからこそ井戸掘りでいかに水が大量に出るところを見つけるかが
重要なように、新規事業でもいかに成長しそうな事業領域を
見つけることが重要。
そしてもうひとつ。
というか、もしかしたらそれ以上に重要なのは、
そしてここだ！ってところを見つけたら、後は自分を信じて
掘り続けること。
いろんな事業をやっていて思うのは、そもそもそこに
水脈があることを信じずに僕に言われたから
やっている、という場合があるけれど
そういう状況でどれだけ頑張ってもなかなか水は出ない。
それにちょっと固い岩盤にぶち当たったらすぐに諦めてしまう。
そういう人が世の中には本当に多い。
スラムダンクの安西先生が言っているように
「あきらめたらそこで試合終了ですよ・・・？」
なわけです。
そこにどれだけの可能性を信じるか。
その信じる力こそが、固い岩盤をも突破する力になり
不可能を可能にする。
ECナビも立ち上げて５年でようやく月間での物流総額
（ECナビを経由してショッピングされた金額）が３０億円を
超える規模になった。
最初の時点で３０億円なんて途方もない数値だと思ったし、
社内の中にも信じていない人もいたと思う。
でも、それでもインターネット市場の拡大、
EC市場の拡大、ユーザーニーズ、時代背景を考えたら
ポイント還元型の価格比較サイ トというのは今後の
成長性は大いにあると信じて一心不乱に進んできた。
次の目標は月間での物流総額１００億円。
今の３倍以上の数値になるけれど、正直、この数値に根拠なんてない。
でも感覚としてこれぐらいいくっしょ。
それぐらいポテンシャルがあるのがEC市場だと思う。
これを目標に新たな井戸を掘り続けていきたいと思います！
井戸掘りでやることはシンプルに３つ。
１．水の出そうなところを見つける。
２．掘るための道具や人を調達する。
３．水が出るまで掘り続ける。
いかに掘る力があっても、そもそも水脈の出ないところを
どれだけ掘っても水は出ない。
だからこそ井戸掘りでいかに水が大量に出るところを見つけるかが
重要なように、新規事業でもいかに成長しそうな事業領域を
見つけることが重要。
そしてもうひとつ。
というか、もしかしたらそれ以上に重要なのは、
そしてここだ！ってところを見つけたら、後は自分を信じて
掘り続けること。
いろんな事業をやっていて思うのは、そもそもそこに
水脈があることを信じずに僕に言われたから
やっている、という場合があるけれど
そういう状況でどれだけ頑張ってもなかなか水は出ない。
それにちょっと固い岩盤にぶち当たったらすぐに諦めてしまう。
そういう人が世の中には本当に多い。
スラムダンクの安西先生が言っているように
「あきらめたらそこで試合終了ですよ・・・？」
なわけです。
- スラムダンク 完全版 全24巻セット/井上 雄彦
- ￥23,512
- Amazon.co.jp
そこにどれだけの可能性を信じるか。
その信じる力こそが、固い岩盤をも突破する力になり
不可能を可能にする。
ECナビも立ち上げて５年でようやく月間での物流総額
（ECナビを経由してショッピングされた金額）が３０億円を
超える規模になった。
最初の時点で３０億円なんて途方もない数値だと思ったし、
社内の中にも信じていない人もいたと思う。
でも、それでもインターネット市場の拡大、
EC市場の拡大、ユーザーニーズ、時代背景を考えたら
ポイント還元型の価格比較サイ トというのは今後の
成長性は大いにあると信じて一心不乱に進んできた。
次の目標は月間での物流総額１００億円。
今の３倍以上の数値になるけれど、正直、この数値に根拠なんてない。
でも感覚としてこれぐらいいくっしょ。
それぐらいポテンシャルがあるのがEC市場だと思う。
これを目標に新たな井戸を掘り続けていきたいと思います！
ECナビのクリードのひとつに
『スピード、スピード、スピード。スピード』と
あるようにスピードを重視している。
それでも気づくといつの間にかスピードが遅くなっている
ことに気づくことが多い。
ただ気になるのはサイト規模が大きくなっていくと
開発のスピードが落ちてしまうのはしょうがない
ことだと思う人が多いこと。
規模が大きくなっても俊敏な組織があるように
システムの規模が多くなっても開発スピードが
小さな組織のときと同じように上がるやり方ってあるし、
それを試行錯誤しながら進めてくのがベンチャー。
そこでシステムの規模が大きくなっても
開発のスピードをもっとあげるためには
どうすればいいのかってことを考えてみた。
・開発項目を減らす。優先順位を明確に。
・エンジニアはマルチタスクではなくシングルタスクにする。
・大きなチーム（７－８人）でやるより小さなチーム（２－３人）をたくさんに。
・スーパーなエンジニアがいれば機能をベースにしたチーム
編成ではなくその人を中心としたチーム編成にする。
・エンジニアに背景、目的を理解させたうえで権限をエンジニアに大幅に委譲。
（ディレクターは要件を決めすぎない。基本的な要件、外せないものは何かを
明確にしたうえで実装方法はエンジニアに任せる）
・３つのチームに分ける。大きな機能開発、UI開発、管理画面開発。
（UI部分を切り出してそこが独自に動けるようにするのが肝）
＊ここについては明日もう少し詳しく書きます。
これはあくまでも一例に過ぎないけれど常識を疑い、
どうすればもっとスピードアップできるかを
常に考え、試行錯誤していける組織にしたいと思います。
ベンチャーで開発が遅くなったら本当致命的なので。
『スピード、スピード、スピード。スピード』と
あるようにスピードを重視している。
それでも気づくといつの間にかスピードが遅くなっている
ことに気づくことが多い。
ただ気になるのはサイト規模が大きくなっていくと
開発のスピードが落ちてしまうのはしょうがない
ことだと思う人が多いこと。
規模が大きくなっても俊敏な組織があるように
システムの規模が多くなっても開発スピードが
小さな組織のときと同じように上がるやり方ってあるし、
それを試行錯誤しながら進めてくのがベンチャー。
そこでシステムの規模が大きくなっても
開発のスピードをもっとあげるためには
どうすればいいのかってことを考えてみた。
・開発項目を減らす。優先順位を明確に。
・エンジニアはマルチタスクではなくシングルタスクにする。
・大きなチーム（７－８人）でやるより小さなチーム（２－３人）をたくさんに。
・スーパーなエンジニアがいれば機能をベースにしたチーム
編成ではなくその人を中心としたチーム編成にする。
・エンジニアに背景、目的を理解させたうえで権限をエンジニアに大幅に委譲。
（ディレクターは要件を決めすぎない。基本的な要件、外せないものは何かを
明確にしたうえで実装方法はエンジニアに任せる）
・３つのチームに分ける。大きな機能開発、UI開発、管理画面開発。
（UI部分を切り出してそこが独自に動けるようにするのが肝）
＊ここについては明日もう少し詳しく書きます。
これはあくまでも一例に過ぎないけれど常識を疑い、
どうすればもっとスピードアップできるかを
常に考え、試行錯誤していける組織にしたいと思います。
ベンチャーで開発が遅くなったら本当致命的なので。