オブジェクトの広場はオージス総研グループのエンジニアによる技術発表サイトです

インタビュー

アジャイル開発はWhyから始める

アジャイル実践者インタビュー第3回:市谷聡啓さん
2018年7月18日
市谷 聡啓(いちたに としひろ)
市谷 聡啓(いちたに としひろ)
ギルドワークス株式会社

今月は、ギルドワークス株式会社で仮説検証とアジャイル型開発のご支援をされている市谷聡啓さんへのインタビューをお届けします。インタビューでは正しいものを正しくつくりたいということを、情熱を持ってお話しされていた市谷さんが印象的でした。2017年12月にご講演された『アジャイル開発はWhyから始める』のお話しを中心に、市谷さんのお仕事やお仕事感について、弊社の藤井拓がお聞きしました。

インタビュアー:藤井 拓
(編集:水野 正隆)

新規事業創出の支援

―― 本日はお忙しいところありがとうございます。今回のインタビューは、2017年の12月にエンタープライズアジャイル勉強会でご講演いただいた『アジャイル開発はWhyから始める』を中心にお聞きしたいと思っています。基本的なこともお伺いすることになると思いますが、よろしくお願いします。

市谷さん― よろしくお願いします。

発表スライド

市谷さん発表スライド)アジャイル開発はWhyから始める

―― この講演のときにはお聞きできなかったんですけど、市谷さんの仮説検証とアジャイル開発のご支援ですが、お客様はスタートアップがやっぱり多いんですか、それとも大企業もあるんでしょうか。

市谷さん― そうですね。結構変わってきていまして、我々が会社をつくった4,5年前はスタートアップやベンチャーが多かったんですね。何か1つ、既にサービスを立ち上げられて、成功も収められていて。ですが、踊り場に来ているような、次の展開を考えなきゃいけないというような会社が最初は多かったです。今は、いわゆる大企業と呼ばれる会社のほうが多いですかね。

―― 新事業創出みたいな感じですか。

市谷さん― はい。そうです。

―― そうなんですね。ちょっと意外でした。ご講演の中では仮説検証が大事だということと、作らずとも仮説検証はできるという話があったんですけれども。この考え方とサービスデザイン思考やLean UXという話と関係しますか?

市谷さん― 関係します。デザイン思考やUX方面のいろんな道具立て、やり方があります。何を作るべきかをはっきりさせていくために、そういう道具や手段を使いますね。

―― ご講演でお話しされたものを見ると、伝統的な要求開発的なアプローチ、例えばインタビューとか、アンケートとか。従来の要求開発的なアプローチですね。なぜこのセットになってるのでしょうか。

市谷さん― そうですね。大きく二つ考え方があります。1つは顧客開発という、スティーブ・ブランクという人が考えたものがあります。そこからエリック・リースがソフトウェア開発に適用したリーンスタートアップをまとめて、いろんなリーンキャンバスや、いろんな派生の手法があってというもの。この流れのいろんな道具ややり方です。もう1つはUXデザインからのもの。サービスブループリントやカスタマージャニーマップなどです。どちらかしか使わないということはなくて、支援するテーマの内容に応じて道具立てをうまく取捨選択します。「今回のテーマではインタビューをやってカスタマージャニーマップでまとめて、プロダクトマップを見立て、MVPに必要な範囲を決めましょう」とか、そういった感じです。

市谷聡啓さん

―― そういう場合、「作らずとも検証する」ということを誤って捉えて、下手をすると分析麻痺的な、なんと言うか自己満足的なところに陥っちゃう危険性はないのでしょうか。

市谷さん― それはあるあるです。当然それは避けます。何をしたら次やるべきことが分かるのかを考えるのが作戦です。ソフトウェアを作ることは一つの手段ですが、ソフトウェアを作ってユーザーが体験できないと、その次に本当に進んでいいのかどうかが判断できないなら作るべきだと思うんですね。

一方、そもそもプロダクトのビジョンがない状態だとソフトウェアを作るという話にならないじゃないですか。なので、まず仮説キャンバスを描きましょうかと。それで「誰」の「何の問題」を解決するのかをまとめます。で、この次に進もうと思ったとき、まだソフトウェア早いでしょと。ここで言っているユーザーは本当に我々が想定している考え方を持っていて行動をしているのかと。それが分かってるのだったらインタビューしなくていいんですけど、分からないんだったらじゃあ、その反応を見に行こうってことでインタビューをする。こんな風に、次に何が必要なのか、次に動くために必要な情報は何か、それを得るための活動をやるという形なんですね。

なので、次にやるべきことを分かるためには何をすればよいのかを考えると、同じことぐるぐるやることはありませんね。

常に着地を考えながらやる

―― 新事業創出といった状況でのビジネスの仮説検証をする場合、仮説検証を早く回す必要があると思うんですが、気を付けておられることはありますか。先ほどの分析麻痺の質問に近いですが。

市谷さん― そうですね。常に着地を考えながらやるんですよ。探索的な活動なのでスケジュールは引かないと思われるかもしれないですけど、引くんですね。例えば1カ月半で何か結論を一つ出したいときに、1カ月半後にプロダクトの規模感を把握したいので、プロダクトバックログを出すっていうことがあったとします。そこまで行くためには、スタートラインが今で、何をしていけばいいのかという見立てをするんですよ。

期間が1年だったらいろんなことができますけど、1カ月半でここまで行こうと思ったら、最小限のタスクでやる必要があります。それを組み立てます。最初は見立てしかなくて、やっていく中で「インタビューやったけど、その次またインタビュー一周ぐらいやんなきゃいけないな」ってことはよくあるので、当然タスクは入れ替えします。だけど、基本的な時間制約みたいなのを意識しながらタスクの組み換えをしていって進めます。

市谷聡啓さん

市谷さん― ただ、時間切れで「なんかよう分からんな…」ということはあります。インタビューしたけど10人聞いても分からなかった、20人聞いても分からなかった、ということはあります。そういうとき、これだけインタビューしても分からなかったんだから このアイデアは駄目という判断もあるし、もうワンセット期間を伸ばしましょうという判断もあります。まだやれる検証があるんだったら、次の1カ月半でやりましょうと。こんな感じでタイムボックスを増やすというのはありますね。

―― 仮説検証もタイムボックスがあって、その中で何をやるのかというように考えるのですね。スクラムのアプローチにも似ていますね。

市谷さん― そうかもしれないです。こんな感じで進めるので、ずっと分析するようなことはあり得ないです。

ビジョンと目的のセットで仮説を捉える

―― 講演の中でもお話にあがりましたが仮説キャンバスというツールが出てきました。市谷さんのオリジナルということですが、ビジネスモデルキャンバスと比べてビジョンや顧客の気持ちを掘り下げていくような感じで拡張されているのが面白いなと。これはどういうふうに発想されたのですか。

市谷さん― 最初はビジネスモデルキャンバスを使って仮説を立てていました。しかし、顧客の課題を書けないので何のための提供価値なのかが分からず使いづらかったのです。すぐにリーンキャンバスに乗り換えました。リーンキャンバスをしばらく使っていましたが、現場で使っていく中で不都合があって、自分たちで変えようということになって仮説キャンバスに至りました。その不都合は何かというと、リーンキャンバスには課題と価値提案を書きます。その観点は良くて、検証の中で内容が詳細化されて具体的になっていきます。ただ、逆にだんだん、話が小さくなることがあるんですよ。「この問題を解決することが本当に嬉しいことなんだっけ」とか、「この方向性で進んでビジネスとしてスケールするのか」みたいな感じになるんですよね。

課題の解決には何が合っているのかだけを求めて検証していくと、その観点ではどんどん分かってきます。しかし、それが解きたい問題だったかっていうと、ズレていく可能性があるんですよ。ある人たちの「生活をこんなふうに変えたい」というビジョンだったり、自社の事業がこういうふうになりたいっていう目的だったりそういうところから事業を進めるはずです。それが置き去りになって目の前の問題だけを追いかけていくと、解きたい問題ではなくなっちゃうっていうことが起きました。なので、事業のビジョンや目的とセットで、仮説を捉えていこうってことで、この構造にしてます。

講演資料

出典)『正しいものを正しく作る Beyond Agile』より

―― ビジネスモデルキャンバスは事業する観点で考えてるから、ユーザー体験的な内容っていうのはなかなか盛り込めないっていうところなんですね。

市谷さん― そうです。はい。講演では話さなかったんですけど、何を検証するのかということも別キャンバスでまとめるんですよ。検証キャンバスって言っていますけど。で、何を分かりたいからこういう手段で検証するっていうのを整理した上で、じゃあソフトウェアとしてこれが必要だみたいなことをちょっと整理して開発するんですね。

常に仮説立てて、検証手段は何だ。必要なバックログはこうだ、作る、試す。検証キャンバスで言ってたことはどうだったのか。何か分かった。じゃあ仮説は合ってたのか。「あれ?間違ってた」ってなったら、じゃあ仮説キャンバスからまた練り直すか。みたいな感じで進めています。

―― 最初に仮説がしっかりある程度、考えられて、何を検証すべきかっていうのが明確になってる状態で、機能の詳細はある程度、確かめながら、開発していくっていうことですね。

参考) HypoCanvas - 仮説キャンバスをオンラインで作成できるツール。

仮説検証と開発が一つの体のように動くことを目指すべき

―― ゴールデンサークルのお話がありましたね。ゴールデンサークルのWhy、How、Whatが、それぞれ「仮説検証」「設計、プロセス」「機能開発」にマッピングされているのがすごく分かりやすいなと思いました。それで「WhyとHowとWhatの重なりをつくる」ために、Why、How、Whatの練度を高めようと講演の中で仰っていました。Whatには例えばスクラムを導入するというのは分かるんですけど、WhyとかHowの練度を高めるっていうのは例えば何をするのでしょう。

少しずつ練度を高めよう

出典)『アジャイル開発はWhyから始める』より

市谷さん― 開発側が何の根拠も持たず、機能だけいっぱい作っているような状態ではプロダクトの成功は難しいと思います。仮説検証と機能開発で分断するのではなく、重なりを作ってちゃんと繋いでいかないといけません。この話は講演の時より自分の中で進んでいるのですが、重なりというより、仮説検証と開発やってる人・チームが一つのチームで、1人の人間として考えたほうがいいと思っています。例えば、「手を動かそう」って頭で思ったときに手を動かすって、人間は何の意識もなくやれるじゃないですか。そんな感じで、仮説検証でも「なんかこんなんがええんちゃうか、なんか分かってきた」ってときに、バックログアイテムとして形にすることを頭で考えて、1週間ぐらいたってから手が動くみたいなんじゃなくて、即座に動くのが理想かなと思っています。重なり以上に一つの体のように動くことを目指すべきだと思っているんですね。

その理想を目指すとき、頭で考えるとか手を動かすなどのそれぞれにすごく時間が掛かっていたらスピード感出ないですよね。だから、まずそれぞれの役割のところでの質っていうんですかね。スピード感みたいなものを高める必要があって、それを練度って言ってます。

―― なるほど。Why・How・Whatをシームレスに連携していくようなところをゴールとしていきながら、段階として、それぞれがまずしっかりできるようにしていきましょうっていう話なんですね。次第に一緒になってやるようにして、WhyからWhatまでを行き来できるようにしていくことによって、より柔軟に価値を探索しながら開発することが実現される。

市谷さん― 今、思っているのは、ユーザーストーリーは共通言語として必要で書くんですけれども、これがまた足かせになっているなとも感じていて。結局、記述じゃないですか。ユーザーストーリーという記述があって足りない部分を会話で補完しようってことでやるわけですけども、会話も言語じゃないですか。言語化できるものはそうやって会話やユーザーストーリーでやれるんですけども、プロダクト作りをする中で全て言語化できるのかっていうと、言語化しきれないなっていう感じがあって。

―― そうですね。

市谷さん― でも、開発者は最後、コードの一行をどう書くかを決めなきゃいけない。trueにするのかfalseにするのか決めなきゃいけない。となると言語化や記述っていうのはもちろん大事で必要なインプットなんだけど、それだけでは足りなくて、その開発者の中に彼なりの基準がないとプロダクトの質やスピードは高まらないなと思ってます。その基準を作るためには、例えば私が仮説検証者だったとして、ユーザーと話をして現場も見て解釈して、いっぱいアウトプットして、「はい。読んどいて」では、開発者の中に基準が生まれるかっていうと、ちょっとあやしいなと。開発者を同じように解釈の場に連れて行かなきゃいけないなと。ユーザーがいる場所とか、その活動が行われている場所に連れて行かなきゃと。

その場所で何が起きてたのか、これはどういうことでこれは問題だというような解釈はやっぱり大事。この解釈がどこまでできるかは、経験とか観点によって見えたり見えなかったりするので、そこは見た後にお互いどんな解釈ができるかっていうのを話し合って理解してもらう。「あ、なるほど。だからこのプロダクトってこんな動きしなきゃいけないんだ」とか、「こんな使われ方されるからこんな機能しなきゃいけないんだ」ということを、開発者の中に基準を作ってもらうことが次の理想かなと思って、そういうことを取り組んでますね。

市谷聡啓さん

―― 今の説明をお聞きしててちょっと思ったのは、モブプログラミング。チームでもビジネスや作るべき価値を考えるところから実装するところまで一体となってやっていくようなね。そういったことと、市谷さんが思われていることって結構近いんですか。

市谷さん― 一緒に現場観察するのは、ある意味モブやっているような感じだと思います。しかし、ただ一緒にやりゃいいってもんじゃないと思っていて。現場を見て、みんなが「こんなバックログアイテムが必要だ」などと思いつくかっていうと、そんな訳はないと思っています。先ほど言ったように、その後でどういう解釈ができるのかをお互いに知見を共有したりフィードバックし合うみたいなところがすごく大事だと思ってます。

―― 今のご説明を聞いて、SECIモデルが浮かびました。

市谷さん― そうですね。すっきり説明ができる気がしてきました。

―― 暗黙知を表出化していく過程が、言語で必ずしも語れないんだけどっていうところと近いなって感じて。

市谷さん― SECIモデルのプロセスを3カ月とか半年かけて回すのではなくて、1日の中で回すのが理想かなと思っています。実際、今やっているプロジェクトでも、現場を観察して必要なプロダクト作ろうと思ってるんですけど。開発者ももちろん現場に行って、意外と現場は暗いなとか、外なので風が吹いてるなとか、そんなことを現場で体感してもらっています。細かい操作を手元では無理だなという理解につながり、当然そういう現場でプロトタイプのテストとかしますから、その場でプロトタイプを改修して動きを変えて、もう一回試してみようみたいなことをやってたりするんですね。なので、分かって形にするということ、現場でSECIモデルを回すことが1つの理想と思っています。

これからの方向性

―― 最後に、市谷さんの今後の夢や、この先に目指しておられることをお聞かせください。

市谷さん― 世の中の価値感が変わっていってる気がするし変わったほうがいいなって思っています。ちょっと大げさな話ですけど、お金があればなんでもやれるんでしょみたいなマインドセットと言うんでしょうか。どっちかって言うと今までそういう感じだったと思うんです。値付けできないから価値がないのじゃなくて、お金が付かないだけですごくその行動とか表現には価値があることも、やっぱり一方ではあると。そういったことをもっと扱いたいなっていう感じがしています。お金でいくら儲かるのかみたいな話がファーストではなくて、例えば人を応援するとか、人と人との信頼が扱えるようになるというか、そういうのを表現できるようになるんだとか。そういう事業なりサービスに自分の時間を使っていきたいなって思っています。

―― 今現在は金銭的に評価されないんだけど、良いものっていうか、それを越えて良いものがあったら、そういうものを作ることに貢献していきたいっていうことなんですかね。

市谷さん― そうですね。そうなると領域は、マス向けの大きい話というよりはちょっと限定的なところかなと。ある世界ではすごく必要なもので助かるみたいな話とかに寄っていく感じです。僕はそれでいいと思っていて。マス向けの広告をバンバン打ってやっていきますみたいなのは、やりたい人たちがやればいい。でも、うちはどっちかっていうと次のことをやっていきたいなと思っていますね。

―― なるほど。お聞きしたい事はまだたくさんありますが、時間がきてしまいました。本日は、お忙しいところありがとうございました。