00:07
おはようございます、ゼロトピックです。
今日はちょっとお便りをいただいたので、お便りに答えていきます。
匿名で、誰からというのはちょっとなしで、答えていけばなと思います。
はい、じゃあちょっと早速、2つあるんですけど、その内容を読み上げます。
1つ目、早速質問ですと。
前社長、過去社長から権限以上仕組み化ができていないとフィードバックを頻繁にもらえます。
権限以上の仕組み化する際のポイントなどはありますか?
ということで、ここから先が、ちょっとこの授業の内容が書かれているんですけど、
これはちょっとあんまり公開できないような感じなので、
テーマとしては、仕組み化、権限以上できるような仕組みを作りなさいという話。
その際のポイントですね。ポイントみたいなお話ですね。
そもそもなんですけど、何で仕組み化したいのっていうのが1個あるかなと思います。
うちが仕組み化する場合の目的は2個かなと思っていて、
1つはスケールできるようにすること。
例えば、1つでうまくいった成功事例があるとして、
これを再現しながら、例えば月に1回それができていたんだとしたら、
どうやってそれを10回にするのかとか、100回にするのかとか、
そういう論点を考えなきゃいけないんですよね。
そうすると、この時にボトルネックが個人の仕事の仕方に依存してしまっていたり、
そもそもどうやってその成功体験が生まれたのかを把握していないとスケールができない。
ので、この成功体験の要素を分解して、
1つ1つどうやったら人の手を省いた状態で再現できるのかっていうのを考えるのが
仕組み化の価値の1個かなと思っています。
なので目的の1個目はスケールするためだと思います。
もう1つはコストを下げるためかなと思っていて、
人の手を省くっていう発言が今の中にあったと思うんですけど、
例えば1つの成功体験を10にするときに、
必要な人数が10人になっていたら同じだけコストがかかってしまう。
そうすると要はリターンオンインベスティメントというか、
かけた、投下した作業料、コストに対して得られる期待値、リターンの割合って上がってないんですよね。
03:08
それをどうやって上げていくかっていうのが基本的に企業活動として前、
例えば限界利益をどうやって伸ばしていくかってことに密接に関係していくので、
仕組み化っていうのはその2つの目的であるものかなと思っています。
スケールするってことと、
なんだっけ、ROIを上げる。
あれ、なんかはじめ違う言い方してた気がするんですけど、
コストを下げる、ROIを上げる、どっちもいいや。
スケールするとROIを上げる。
その2つのために仕組み化っていうのは大事だなと思います。
例えば仕組みで世の中を良くしている会社、そういうミッションを掲げているのはラクスルっていう会社がありますけども、
ラクスルの中の優秀な方々とお話しすると、やっぱりこの意識強く持たれていて、
とにかく1つの成功事例をどうやってスケールするかっていうのをめちゃくちゃ突き詰めて考えていたり、
そのために手段を問わないっていうようなマインドセットが感じられます。
特にCOOであるビズデブのヘッドをやられている福島さんとお話ししたときに、
そのマインドセットはすごく感じました。
福島さんご自身の経歴はシステム系の会社、そして戦略コンサルティングっていう、
この2つ経験されてラクスルの経営人として今参画されているんですけど、
この2つを通じて、要はシステムを作ったり収めたり、
システムを通じてビジネス効率を良くするっていうのは、
まさにROIを上げるためにどうするのかっていうのを考えるとほとんど同じですよね。
あるいは戦略コンサルタントがよく、例えばコストカットの戦略を提案するときにやることも同じで、
経営の中のボトルネックを見つけて、
あるいは過剰なコストがかかっている部分の要因を細かく切り刻んで分解したときに、
どこに一番大きなポーション、ボトルネックのポーションがあるのかっていうのを見定めて、
そこに手を打つみたいな。
あるいはもっと複合的に1,2,3,4,5っていう依存の構造があるとしたら、
この1から5をまとめて解決する方法を提案するっていう、
そういう進め方が多いのかなと個人的に思うんですが、
福島さんのキャリア含めて、あとは今のラクスルの、
特に効率的に授業を伸ばしていくっていう席も追われている中でも、
そこの辺りはすごく磨かれていらっしゃっていて、
僕自身ものすごい勉強になるほどの言語化されているなというふうに思いました。
はい、というので戻ると、なんだっけ、
仕組み化する際のポイントはありますか?
今目的話したんで、ポイント化。
06:00
ポイント何かっていうと、何でしょうね。
2つかな。
1つは、僕はあえて仕組み化の中でも、
結局その仕組みってユーザーが欲しい状態になっているの?
みたいなのはものすごい意識します。
品質が足りているのかっていう問題ですね。
例えば、なんだろうな。
思い出した。
うちの中でプロダクト作るときにすごい重要にしているのが、
ユーザー1人の抱えているイシュー、
深く持っているペインみたいなものをちゃんと見定めて、
それを解決するもの、
その人が実際に使って役に立つものを作るっていうことを
1つ重要にしていて、
そういうものでないと10Xなものは作れないっていう風に、
すごく会社の遺伝子として埋め込んでいるんですね。
なのでNYインタビューっていう、
Nイコール1、1人のユーザーと会うっていうのを、
本当に年間100本以上会社としてやっています。
ただ、それは初めは僕が個人でやっていて、
それを浜坂さんという人にパスをして、
浜坂さんが今年はすごい100本ぐらい頑張っているんですけど、
浜坂さんだけがやっている状態だと、
スケールしないよねっていう、
さっきの1から10にできないみたいな話があって、
まさにこの仕組み化を進めているんですね。
だけどとはいえ、品質が伴ってない。
要はN1インタビューの最後のアウトプットって何かっていうと、
レポートなんですよね。
そのレポートも人一人のレポートもあるし、
同じテーマでN1インタビューを例えば5人10人やるとしたら、
そこから最後に抽象化して何が言えるのかっていうことを
レポートするっていうのがアウトプットなんですけど、
このレポートの品質が、
例えばプロダクトのメンバー、僕、
あるいはパートナーみたいな人が読んだときに、
ちゃんと伝わるレベルになってないと、
仕組み化をしても価値がないんですよね。
これなんだこれっていうレポートが上がってきた時点で、
その仕組み化はむしろバリューが低くて、
やらないほうが良かったことになっちゃうんですよね。
という意味では仕組み化した後に出てくるスループットの品質が
ものすごい高い状態をキープできるかっていうのが
ポイントの1個目かなと思ってます。
これについては結構順番があると思う。
プロダクトも同じだと思うんですけど、
例えば僕から浜坂さんに渡すときに、
どうやってどういうスループットが出てくるかっていう
期待値が明確にすり合ってて、
上がってきたフィードバック、スループットに対して、
いわゆるレポートに対して適切なフィードバックを加えて、
品質がちゃんと満足できる水準になっているかを
チェックするっていう機能が必要だと思うんですよね。
これがない限りは、
どういう品質のものが上がってきたらいいのかっていうのを
09:01
他の人がやったとき、あるいは、
もし機械をやるんだとしたら機械をやったときに、
その品質をジャッジできる状態にないと、
いわゆる無駄なスケールになってしまうので。
っていうのが一個かな。
ちゃんと品質を下げない、
それをジャッジできる機能は、
人が持っておくみたいなところですかね。
で、もう一つ。
もう一つは、
簡単に自動化にしないっていうことじゃないかなと思った。
今日神々だな、駄目だな。
何でしょう。
全てを自動にするっていうのにかかるコストが100だとすると、
実は8割ぐらいを省くのにかかるコストは、
20%ぐらい済んだりするんですよね。
あとは、
クイックスタートができる部分とできない部分みたいなのがあって、
多くの部分は、
例えば、難しい小難しいプログラムを書かなくても、
実は仕組みにすることって、
できるものが大半だったりすると思ってます。
なのでまずは、
できる形で仕組みに落とし込むっていう、
やりすぎない、
100点をいきなり目指さないみたいなのが、
仕組み化の上では重要なポイントなんじゃないかなと、
なんか思ってきました。
会社っていう存在自体が仕組みそのものなんですよね。
例えば人が集まって、
どのように動いてほしくって、
その動いた結果としてどういうものが出ると、
会社にとっては嬉しい、嬉しくないっていう判断基準が明確で、
それを通じてお金に変える、
会社が生み出したものをお金に変える仕組みが整っていて、
それが最大化していくことが仕組みとして整ってるみたいな、
会社っていうのは仕組みの塊なんですよ。
その時によく言われる大事なものって何かっていうと、
まさに会社のプレーティングシステム、OSと言われるような部分だと思っていて、
最も低いレイヤーですね。
それがよく言われる話なんですけどミッションとかバリューなんですよね。
この判断基準っていう言葉が出ましたけど、
まさにこのミッションとかバリュー自体が判断基準の役割を果たしますと。
で、さっきのN1インタビューをスケールするみたいな話とかも同じで、
結局解きたい意思は何なのっていうのと、
それが解けたら会社にとってどう嬉しい状態があるのっていうのと、
このミッションとバリューみたいなものと全部アラインしてないと、
基本的には意味が無かったり続かないものになっちゃうので、
そういう点は良いか悪いか品質をレビューする時にレビューができる必要があるみたいな話を冒頭にしましたけど、
なんか経営としてチェックする機能も必要なんじゃないかなっていうのは思います。
っていうのが1個目。
12:01
権限以上の話してないわ。
僕は権限以上はあんま考えたことないですけど、結構ね、僕できる方だなと思ってて、
いやなんか人からはできない方に見られるっぽいんですけど、
僕割と権限以上するタイプだなと思います。
権限以上っていうか僕一周をポンって渡しちゃうんで、
これを何とかしてっていう、これを何々な状態にしてっていう一周の状態でポンと渡しちゃうんで、
権限も何も自分がやるっていうことにそこまでこだわりがない。
むしろなんか自分がやらなきゃいけないもっとタスクなもの、権限を発揮しなきゃいけないものって、
もう少しレイヤーとして大きいものをやっていかなきゃいけないなっていう風に、
少しずつ自分も階段を登っているところなので、
そうするとやっぱり任せていくっていうのはどうしても必須になるかなと思ってて、
その時気持ちよく任されてもらうようなことはすごい考えますね。
ドキュメント書いたりとか、なぜそれが必要なのかとか、
なぜそれが必要なのかって言い過ぎて言い過ぎることがないみたいなぐらい、
口で言うっていうよりは僕はドキュメントに書くんですけど、あるかなと思います。
法愛はめちゃくちゃ大事ですよ。
次、2個目いきます。
頼り2個目。
試作のUI決定のプロセスについてお伺いしたい。
特定のページにおいて新しく機能を追加するとか、
すでにある機能のUIを変更するなどの仕様を決めていくときに、
今はこの方が勤める会社ね。
ビジネスサイドは上流からUIまで指定してデザイナーに渡す状態です。
ここのサイトがこうやってるんで、
このページのここにこういう画像を表示するイメージをお願いしたいです。
のようなUXみたいなことはあんまり考えられてない状態。
この方自身としてはユーザーの課題をどう解決するかとか、
体験として不自然じゃないかみたいなのを踏まえて、
UIに落とし込まれるべき。
おっしゃる通り。
そのため、現状ビジサイドが指定して開発方法を続けていくと、
プロダクトがユーザー視点から離れていく。
デザイナー組織が育っていかないというデメリットがある。
このフローを変えるべきじゃないの?って考えました。
おっしゃる通り。
開発フローについて上流の達成したいことなどの抽象化が高いところだけをビジサイドは固め。
どのようなUIにするかはデザイナーに任せる方法に変更しようかと考えています。
山手さんのご見解。
この状況においてどうするかを含めお伺いしたい。
めっちゃ生々しいやつですね。
これはすごく生々しいんですけど、
ビジネスサイドがUIまで指定してきて、
しかもこの指定の仕方がこのサイトがこうやっているので、
このページにこういう画像を表示するイメージをお願いしたいですみたいな話をすると、
ビジネスサイドの方の達成したかったことが何なのかはこの内容だけでは分からないんですけど、
15:06
結構きついなと思いますね。
きついなというのはこの事象自体があったよりは、
お互いに背中が向き合っていない状態だなという気がします。
なのでビジネスサイドがどこかで言われてきたなのか、
自分たちが考えた何かやりたいことを達成したいっていうのがあったときに、
その法愛がデザイナーとかに渡ってないわけなんですね、多分。
だからこの具体のHowの指定まで入ってきて、
デザイナーはそれを自宅するみたいな状態になっているのかなと想像します。
おっしゃるリスクというか、ユーザーの課題が解決できない状態になっちゃうんじゃないかとか、
UXが不自然になっちゃうんじゃないかとかみたいなのは、
この形式だとリスクとしては落ち、降り、消えますよね。
なのであまり良い状態ではないのかなというふうに思いますし、
フローを変えるべきって書かれてるんですけど、
変えるべきはフローじゃなくて、
一周ドリブンみたいな、
法愛から始める文化だと思いますね。
この事業サイドというかビズサイドの方が、
例えば本当に意思を見定めるとか、それを言語化するとか、
そういうことに心を砕いていれば、
こういう依頼の方法にはならないはずなんですよ。
そういう余裕もないし。
だってここのサイトがこうやってるのでって言わないでしょ。
言わないでしょっていうか、
こっちの会社でそれやったら結構おこですよ。
あくまで参考としてどういう類似事例があるかっていうのは、
もちろんプラクティス勉強するためにやるとは思うんですけど、
それってせいぜい参考情報としてGitHub Issuesにペタッと貼るぐらいで、
自社にとってどうベストかっていうのは、
自社の提供したい体験とか、
自社の解決したいユーザーの課題みたいなものからスタートして、
変えるべきだと思うので、
これはヘルシーじゃないなっていうふうに思いました。
なんで変えるのはフローではなくて、
マインドセットとか、
必ずIssueを言語化した状態で渡してねっていう、
なんかことかなっていうふうに思います。
そうですね、その意味で言うと、
その開発フロー、上流に達成したいことは、
抽象度が高いところだけビジュサイズを固めてっていうのは、
一個解決策としてはいいんじゃないですかね。
その部分は今どうやって渡されているのかすごい気になりますね。
どうしてですかね。
やっぱUIをデザイナーに任せる方法に変更するみたいなので言うと、
デザイナーさん何のためにいるかって話ですもんね。
デザイナーに任せる方法に変更するというか、
デザイナーはそれを何とかするために、
その席に座っているはずだし、
ビジュアルサイドは事業、
事業価値を上げるためにその席に座っているはずですよね。
18:02
事業価値を上げるって何するかって言うと、
要はあらりだと思うんですよね。
あらりってビジネスモデルに依存するとか商材に依存するんですよ。
原価ってなかなか下がらなかったりするので。
だからその商材が出している付加価値、
あるいはその掛け算、何人が買ってくれたかみたいな掛け算で、
結局あらりって決まってくる。
そうするとそれが事業価値だと思うんですけど、
じゃああらりを最大化するっていうのが、
僕は事業価値だと思っていて、
それは結局、いかに値下げしない、
原価を下げるみたいな。
供給のコントロールと、
あと売上の最大化っていう二つのテーマがあって、
これは事業開発というか、
ビジュアルサイドにしかできない仕事だったりするんですよ。
プロダクトをどんだけ磨いても結構難しいものがあります。
例えば、なんだろうな、
メルカリみたいな会社だと、
原価にプロダクトの開発の人件費とかがズゴンって乗ってくるので、
開発自体があらりにものすごいヒットするんですけど、
ECとかやってて仕入れがあるところだと、
原価に大きく入ってくるのは結局その仕入れの値段なんですよね、価格なんですよね。
そういうものを下げるって、
普段1個300円で仕入れてたものはある日急に290円で仕入れるようになるかってノーですよね。
何らかのサプライチェーン側への付加価値がない限り、
そういうイベントって起こしづらい。
交渉ってしづらいはずなので、
それをやり切るのがやっぱりビジュアルサイドだと思ってて、
そこはしっかり背中を合わせられる状態になるといいですね。
いいよね。
その意味でいうと、うちどうなんだろうな。
うちは背中合ってるよね、きっと。
きっと合ってる気がしますね。
では、プロダクトの開発についてはほとんどノーコメントなんですよ。
フィードバックはすることはあるんですけど、
結構スクスクとみんながプロダクトを作ってくれていて、
その品質に対してコメントすることはあったり、
ここはこう直せるんじゃないっていうのを気づきベースで出すことなんですけど、
もうそのすべてのイシューをマネージするとかしていなくて、
深くともそういうのがちゃんと自分がいなくても上手く流れる、
さっきの話じゃないけど仕組みになってんじゃないかなっていうふうに割と思います。
それをやってくれてるのはちゃんと別の人がね、
それを仕組みを運用する仕組みとして、
こなれた状態にブラッシュアップするってことをやってくれてるからなんですけど。
じゃあ自分とかビズサイドは何に専念するかというと、
まさに本当にパートナーをグリップするとか、
パートナーとビジネスのモデルを確定させるための交渉をするとか、
21:01
あるいは信頼を生むとか、
あとはうちのステイラってプロダクトを使って彼らの事業をセットアップするとか、
そういうことにコミットしてて、
ある種、お互いの領域がお互いを助け合ってる状態になってて、
それぞれが難しいんでフォーカスをしてるっていう。
ただフォーカスはしてるんだけど、
お互いの情報がないとうまくいくものもうまくいかないんで、
すごい緻密にコミュニケーションするみたいな、
そういう流れでやっています。
こんなもんかな。
お便りはこの2個だった気がしますね。
お便り、お便り、お便り、お便り。
こんなもんでした。
ということで、今日はお便りを2つ読みました。
お便り、お便りってなんかセンスねえな。
もう1個あったわ。
もう1個いきます。
山本さんがこの人と友達になりたいなって思う人はどんな人ですか。
この人とは飲みに行きたいって人ってどんな人ですかっていうのがあって、
いやー僕はお酒は飲まないし、
夜時間マジでないんで、
飲みに全然行かないんですよね。
あとその飲み会に行くっていう経験がもう、
ほんと最近ここ5年ぐらいなさすぎて、
なんだろうな、
飲み会って何がいいんだっけみたいな気持ちになってますね。
ちょっと分かんないですよね。
飲み会で何をみんながするのか、何が楽しいのかって。
でも代わりにお茶はね、お茶はよくしますね。
お茶は申し込まれることは結構あるので、
その血統みたいな感じですけど、
お茶はしますね。
お茶するときにはどういう人と話すと面白いかなと思うと、
やっぱ自分の知らないことを話してくれる人は面白いですね。
あとは、
あんま笑わかしてくれる人って周りにいないんですけど、
笑わしてくれる人ってめっちゃ面白いなと思います。
僕の大学時代の友人がいて、
大学4年間、大学院2年間同じ研究室で、
新卒入者も僕は丸見でやつは伊藤中みたいな、
モリソンっていうやつがいるんですけど、
そのモリソンはね、会うたびにネタを仕込んでるんですよね。
めちゃくちゃ面白いっていうか、
みんなハッピーになる。
例えば、どっかに駐在してたときに、
ナンパした女の子と何があってみたいな、
普通そんなのある?みたいな、
突っ込みたくなる話を毎回思ってて、
年に数回しか会わないんですけど、
あいつは天才だなと思ってます。
そういう人とは特に意図がなくても会いたいって思う気持ちがあるんで、
24:01
飲み会はこれに近いのかもしれないですね。
モリソンの独断症みたいな感じだったら飲み会行きたいなみたいな思うから、
多分そんな感じなんでしょうね。
なので、ぜひこういうふにゃふにゃの話をするのもしたいなと思うので、
募集してます。
ということで、
今日のゼロトピック以上なので、
ご意見おかそう。
ハッシュタグゼロトピックください。
あと最後宣伝なんですけど、
来週の土曜日、10月31日かなに、
僕と友人のヒカルがやってるフリーアジェンダっていうポッドキャストもあって、
それで初めて10時半からかな、
31日土曜日10時半から、
YouTubeライブで話すっていうのをやることになりましたので、
もしよければそちらもチェックしてください。
なんかその情報は、
アットフリーアンスコアジェンダっていう、
フリーアジェンダのTwitterアカウントで多分ツイートされてると思うんで、
ぜひ見てみてもらえると、
通知ボタンとか押しとくのかな、
わかんないけど、
やってもらえると嬉しいなと思います。
はい、それでは。
