事業をゼロイチから立ち上げ続けて早5年
市谷聡啓氏：僕で最後ということで、よろしくお願いします。僕が話す内容は「いい感じの状況を作る」という話です。ちょっと酔っぱらってます。あの、大目にみてください。
（会場笑）
私は3社で事業を立ち上げていて、「立ち上げ続け業」っていうのを4年ぐらいやってます。それから5年目で、今自分の手元に残っている3つの大切なこととはなにかについて話をしたいと思います。
あらためまして、ギルドワークスという会社をやっています市谷と申します。17年ぐらいやってますね。司会の関くんと一緒に会社をやったこともあります。『カイゼン・ジャーニー』っていう本も書いているんですが、この本を持っている方はどれくらいいらっしゃいますか？
（会場挙手）
ありがとうございます！ 持ってない方はぜひ買ってください。
僕はゼロイチの文脈が多いですね。ギルドワークスでなにをやっているかっていうと、楽しいものを開発するってことやってます。
最近リリースしたものに、『カイゼン・ジャーニー』を紹介する仮説をインターネットで作れるようなツールを出しました。これからどんどん自分のやりたことをかたちにしていきますので、注目していただけれなと思っています。
200件の事業を立ち上げ、あとに残った大事なこと
4年間で、延べ200件ぐらい事業の立ち上げに関わってきました。最後までいたものもあるし、途中で終わったものもあるし、いろんなものがあるんですが、たぶんだいたい200件ぐらいです。
仮説検証をバンバンやっていく、リーンなスタッフを増やしていく、すてきなチームを支える、企業間に寄りそっていく……。これは全部大事なことなんですけども、じゃあ私にとってWHYなのかっていうと、そうじゃないなと今日改めて考えたんすね。
いろいろ悩んだんですけども、私にとってのWHYは、いい感じの状況をつくるという、ちょっとフワっとしたものです。いい状況でもないです。正しい状況でもないです。そんなものはたぶんない。「いい感じ」なんです、あくまでも。
たぶん現場のサービスづくりというのは、そういう局面においていろんなステークホルダーとかユーザーがいて、そのなかで「これっていい感じだよね」ってところを作っていくというのが僕のWHYです。
その状況を覆っているのは、ひょっとしたら親子のコミュニケーションを改善するなにかかもしれないし、魚市場のなんかを改善するモノかもしれない。これはさまざまです。チームの組織を変えたいって話もよくありますね。
間違っているものを正しく作ってしまわないために
僕の中では、「いい感じの状況を作る」っていうのもバージョン3までありまして、順を追って話していきたいと思います。
それぞれについて、3つの大事なことをまとめていきます。3つにまとめるとわかりやすいなと思ったのは、一昨日この本を読んだからです。『デザイナーが未来に残したい私の3ヵ条』。これ、けっこう読みやすくって、わかりやすかったです。なので、3つにまとめます。
まず1.0なんですけども。「１、私が大事にしたい『START WITH WHY』」。これはみなさんご存知のゴールデンサークルです。サイモン・シネックが言っているやつですね。当時、201X年ごろまで、これでやってたなあって振り返ってます。よくわからないものはやめで、自分たちはいい感じで開発をやるということですね。ご存知ない方はぜひ。サイモン・シネックの本を読んでください。
自分たちにとっていい感じの開発をやるっていうのがどういうことかっていうと、共感できるかどうかが大事で、わからないものはもうやらない。これは現場によっていろいろあると思います。これがまず違和感になるんですね。
この、「いい感じの状況をつくる1.0」だと、間違っているものを正しく作るってことになりかねないんですね。やり方は、アジャイルのスクラムでやっていく。型どおりです。むしろ型を超えてます。でも、いくらやり方を正しくやっていたとしても、間違ったもの、つまりユーザーに使われないものをつくっている限り、目的を果たせることはないですね。そこに対する違和感があるんです。 いろんな役割分担があって、自分はどういうところを担当して、自分の居場所を守ろうってあると思うんです。だけども、たぶんそれをやっているうちは、正しいモノを探せる目はないなと、つまりユーザーが必要とするものに出会えないなと思うんですね。
だいたい、こっちが決めた相手の境界にプロダクトオーナーがいて、プロダクトオーナーの向こうからなんかバックログ投げてくれればいいみたいな開発をやっているうちは、たぶんたどり着けないなと。
役割を越境することで、正しいものを探すための目を養う
ということで、2.0です。さっき言ったように、自分たちで決めた向こう側にいかないといけない。正しいものがみつけられないならば、自分たちから越境することが大事だと思っていて、これが2つ目に入ってます。
越境すると、わからないことがいっぱいあります。ユーザーがなに考えているかわかんないし、関係者がなに考えているかもよくわかんない。そのよくわからないなかで、どうやってわかるようにするかっていう作戦を立ててやっていく。
これをやるために、2015年にギルドワークスって会社を立ち上げたんです。このときの「START WITH WHY」はなにか。みなさんが忠誠を誓う対象はいろいろあるかと思いますが、僕にとってはアジャイルでも技術でもクライアントでもユーザーでもない、目的なんですね。その目的に、忠実にいきたい。
そのためには、その役割を選んでいる場合じゃない。「POだから」「開発だから」とそんなこと言っている場合じゃないし、あらゆる人を巻き込まなきゃいけないし、あらゆる手段をとらなきゃいけない。そもそも、この目的はオレたちの時間を使う意義のある内容なのか？ っていうのを問い続けなきゃいけない。
それが大事だと思っているし、そのためには、躊躇なく飛び込んでいくということをやらなきゃいけないと思います。
ベンチャーと大企業、両極端なその違い
わからないモノをわかるようにするって、けっこうテクニカルな話で。僕は仮説検証型のアジャイル開発にまとめてまして、（スライドを指して）こんな感じです。これは基本的にリーン開発で、こういう開発をやっていくと、なにを作るべきかがだんだんとわかるようになってくる。
逆にいうと、これじゃないというのを排除していきながら、進めていくと。そのために仮説検証でいくのが大事ですね。
ベンチャーから大企業までいろいろ一緒にやってますけど、ベンチャーの場合はこの幅が広い。そのままずっと先にいくので、選択肢がむちゃくちゃいっぱいあるんですね。あとで社長から「こうじゃないの？」って話でコロっと変わっちゃう。で、開発がついてこないみたいな。裁量の失敗ってのも起きやすい。
大企業の場合は逆で、とにかくやめるとか「違う」みたいな。なにか未来を予測したり予見できないと前へ進めないみたいなことですね。とにかく却下されるってことで、当然それだけ却下してたら筋のいいものもあるのに、どんどんなくなっていくっていうのが失敗です。
なので、スタートアップの場合は「らしくないものは作らない」という裁量の失敗をどれだけ減らせるかってこと、大企業の方は、正解はそんなに出せるわけではないので、まず仮説検証を取り入れましょうっていうことをよくいってます。
このとき僕が思っていたのは、「わかったことがモノを楽しくするんじゃないか」ってことなんですね。本当にそれでブレークスルーできるのか？ 本当にユーザーに必要なものを提供できるのか？ というと、それは違うなと。
意図的にわからないことを増やす方が、まだ可能性がある
それで3.0です、最初は、自分から越境するっていう話をしました。2つ目はわからないものを増やす。3つ目は、「人のときを想う。JT」。これ、2018年からやってます。まず、起業家は、課題はもってても、悩みはもってないなあと思うんですね。
開発チームが動いてくれないっていうのは悩みです。一方、課題としてとらえるのは、動いてくれない、じゃあどうしようみたいな話なんですね。たぶん、悩んでいるうちはまだ越境が足りないんだと思います。解決できない課題もあるし、解くべき問題じゃないこともある。解決できる問題をどんどんやっていくっていうのがここでのやり方じゃないかなって思ってます。
それでもう1個、「わかることを増やす」ってさっき話したんですけども、これは楽しそうにみえて危ないところがある。わかることをバンバン増やす、仮説を検証してどんどんいろんなことを理解する。そしてわかる範囲の中で、次の判断をするんだけども、そもそもそこの正解が含まれているかどうか。当然ですけどわかんないですよね。それで、わかることをどんどん増やし、それを絡めるみたいなことをやっていくよりは、意図的にわからないことを増やすっていうのをやった方が、まだ可能性があるなと思います。
わからないことを増やすってことは、自分が理解できないことを変数に入れて、わかるという活動をしていくし、その中で次なにやっていくかってのを考えていく。これは自分の理解を超えることができるってことですね。それをやるためには、目線の高さを変えなきゃいけないよって話になります。
高さを変えると、見える範囲も変わりますよと。じゃあ「高けりゃいいんでしょう？」って話になったりもするんですが、そうじゃなくて。目線は1つで行き来できるか？ 自分でその行き来をコントロールできるかがすごく大事だなあと思っていて。
でもそれは容易じゃない。なので、「上・上・下・下・左・右・左・右・B・A」のように、強制的に視座を変えていくことがあるかなと思います。わからないものを増やす、これは当然、安定性に欠けます。そして気持ち悪くもなる。この気持ち悪さとどれだけ向き合えるかってことだと思っていて。
開発するのも気持ち悪いです。僕は次に、イメージでつくるってのをやっていきたくて、その開発自体は言語化しなきゃいけない。会話なり、記述なり、言語化しなきゃいけないことが鬼門だと思うんですけども、たぶんそれをやっているヤツは、そこが上限。プロダクトオーナーが語っていることがすべてになっちゃう。
現場でプロダクトをイメージできるということ
それを超えていくためには、「自分の中で何を作るべきか」って基準を作らなきゃいけない。基準を作るためには現場に行かなきゃいけない。ユーザーが使っている現場にいって、そこで一緒に体験し、感じて、だからこういうモノが必要なんだって思わなきゃ、たぶん超えられないだろうなあと。
最近、魚市場のサービスに取り組んでいるんですけど、実際にこういう市場に行くんです。午前3時でもいいから、ともかくみんなで集まると。それで市場でやっていることに混じる。毎回午前3時にいってると大変なんで、疑似的に状況つくってやってみるっていうこともぜんぜんOK。
大事なのはその現場です。オフィスで開発現場ってのもたしかにありかもしれないけど、ユーザーが使う実際のリアルな場所にいくこと。そこでどんどん試したくなる。その場でコードを書いて、実際動かして試してみる。
僕は、現場っていうのはまさに使われるそのときなんだろうと。そこにプロダクトが入るはずだから、行く行かないじゃなくて、「全員来い！」と思います。
いい感じの状況を想像できるようにするためには、そこにいる人たちがどんな活動をして、どんなことを思っているかを想像できなきゃいけない。人のときを想わなきゃいけないって話になると思っています。
いい感じの状況を作るっていうことを僕は求めています。みなさんにとって、この会が次のいい旅につながるといいですね。
どうもありがとうございました！
（会場拍手）
