生産者の課題と、株式会社ビビッドガーテンの取り組み
西尾慎祐氏：「アウトカム思考なプロダクト開発を実現する組織作り」というテーマで、私たちの組織や開発チームがどういう体制でやっているかという話ができればと思っています。私は、株式会社ビビッドガーデンでCTOをしている西尾です。よろしくお願いします。
まずはその前に、私たちの会社がやっていることを紹介します。ビビッドガーテンは「食べチョク」というサービスを運用しています。一次産業の課題を解決する会社として、今は「生産者の”こだわり”が、正当に評価される世界へ」をビジョンに掲げプロダクト開発に取り組み、「食べチョク」というこだわりの生産者が集うオンライン直売所を運営しています。
私たちは農家さん・漁師さんの課題を解決しようとしていますが、日本の9割の農家さんはすごく小規模で、農業に従事する人口はすごく減っています。それはニュースとかでもよく聞く話だと思います。それはなぜかというと、やはりなかなか儲からない現状が課題のひとつとしてあります。
農家さんは、すごくいいものを作っても、あまり販路がありません。「ニンジンはこの値段」などのように既存の販路ではあらかじめ価格が決められているので、すごくいいものをこだわって作っても、結局売れる価格は同じだったりします。そうなると、いかに大量に作るかという勝負になりますが、小規模な農家ではなかなか難しいという課題があります。
そこで、すごくいいものを作って適正な価格で（売れる）。がんばっていいものを作ったら、その分適当な価格で売れるプラットフォームを作って、一次産業や農業が儲かるために私たちにできることがあるのではという思いでプロダクトを作り、「食べチョク」というサービスを運営しています。というのが、我々のサービスの紹介になります。
会社名はビビッドガーデンですが、現在はプロダクトは1つで、「食べチョク」を運営しています。私たちの置かれている状況としては、ここ2年で「食べチョク」の利用者や流通額、生産者がすごく増えています。
流通額はこの2年で128倍くらいに増えている。登録ユーザーも増えているし、生産者さんも2022年5月時点では7,000軒と書いてありますが、今はもうすぐ7,500軒に届くくらいに増えています。
私たちはスタートアップなので、前提として短い期間での非連続な成長が常に求められています。2年前はエンジニア数名で開発をしていましたが、今は40名くらいで、短い期間で大きな成長を求められている会社です。
株式会社ビビッドガーテンが重要視している「アウトカム」
私たち開発チームがすごく大事にしていることをひとことで言うと「アウトプット（結果）ではなくアウトカム（成果）を重視して、プロダクト開発を進める」です。
アウトプットやアウトカムについて一応ちょっと補足します。ここで指しているアウトプットとは、例えば、「今月は20件新しい機能を作りましょう」とか、「ストーリーポイントの消費を何ポイント上げましょう」という目標。目標というか、作った結果みたいなところがアウトプットです。
もちろんこれはすごく重要な指標だと思っていますが、開発チームが追っていく目標の最終的な結果が「とにかくたくさん開発する」「この機能をいっぱい作りました」になってはいけないと思っています。
それではなくて、私たちが追うのは、その機能を作ったことによってどんな影響があったのか、また、お客さんにどんな体験を提供できて、それによってどんな数字が上がったのか。最後はそれらをちゃんと追わないといけない。この成果をアウトカムと言っています。例えば、「カートの利用率を何パーセント改善して、どういう体験を提供できるか」というアウトカムを意識して開発することを、私たちのチームでは大切にしています。
「アウトカム」を重視する理由
重視する理由はすごく単純というか、新しい機能を作ってデリバリーするだけでは成長が難しいフェーズにきていると我々は思っています。
事業の初期のフェーズ、例えば、我々でいうと2020年よりも前の時が事業の初期フェーズでしたが、プロダクトとして足りないものがたくさんありました。
「これを作ったら明らかに数字が伸びるだろう」というものがすごく明確だった。こういう時は、いかに早くデリバリーできるかがとても重要です。何もないので早く作って早くリリースしたら成果が出るのが、初期のフェーズだと思っています。
この時期はたくさん作るとか、「今月は何件リリースするぞ」ということがすごく大事だと思います。もちろん今でも大事ですが、このフェーズでは特に大事だと思っていました。
ただ、フェーズがだんだん進んでくると、プロダクトとして最低限必要な機能は満たされてくると思っています。そうなってくると、だんだん足りないというか、「これを作ったら絶対数字が出るだろう」という機能をたくさん作ってリリースするわけにはいかなくなるなと思っています。
さらにフェーズが進むと、もちろん事業の目標も上がっていく。売上100万を1,000万にするのか、1,000万を1億にするのかという目標は、後のフェーズにいくほど高くなっていくと思います。常に非成形な成長を求められてはいるので、だんだんハードルが上がっていく中、とにかく何か作ってリリースしたら数字がバンと伸びるというわけにはいかなくなってくる。
作った結果にどんなインパクトがあるのかをあらかじめよく考えて作らないと、成果が出にくいフェーズにきています。そもそも、こういう思考にならないと成果が出せないフェーズにきていると思ってます。
アウトカム思考に合わせた開発体制作り
ということで、当たり前ですが、こういうことを大事にしています。「アウトカム思考にしましょう」と言うだけではなかなかなりづらいというか、開発体制もそれに合わせて作っていかないといけないと思っています。
（スライドを示して）開発チームが追っている目標みたいなもの、「ミッションで動く」と書いていますが、開発チームにはプロダクトチームがあり、その中にいくつかユニットというサブチームみたいなものがあります。
チームごとにミッションを置いて、それをどう達成するのかはチームが決める。例えば、具体的な数字の目標、「何かの目標をこのくらい上げましょう」みたいなミッションを置いて、それに対してメンバー全員でどうすれば達成できるのかを考えていくような開発体制にしています。ということで、エンジニアは仕様が来て（それのとおりに）ひたすら作っていくという感じではなく、みんながちゃんとアウトカムを意識できるような体制にしています。
どんな成果が出たのかは、数字を元に振り返っています。例えば、カートの利用率はその数字を見るし、どういう施策をやってどういう結果が出たのかを見て、あらかじめ数字の目標を設定し、それを見る努力をしています。もちろん、デリバリーの目標を置いているチームもあります。「いつまでにこれを作る」ということが大事なチームもありますが、そうではなく、「こういうミッションを置いて、それが達成できたのか」をちゃんと見ていく開発体制にもしているという感じです。
ミッションを達成するためのチームのあり方も考えないといけないと思っていて。できるだけ自分たちのチームの中で完結できるという施策を、すごく大事にしたいと思っています。自分たちのチームで完結できるというのは、
仮説検証もそうだし、あとは着想からデリバリー。例えば「こういうことをやったらいいんじゃないか」というアイデア出しみたいなところから、POが「じゃあこれやろう」と決めて、デリバリーして検証するところまで、なるべく自分たちのチームの中でできるということは大切にしてます。
これが、「考えるのは別のチームで、作るのも別のチームで、運用も別のチームで」みたいになると、施策やPDCAを回すスピードがすごく落ちちゃうと思うので、自分たちの中でできることは大切にしています。
ほかに、施策はできるだけ個人ではなくチームで取り組むということで。当たり前っちゃ当たり前なのかもしれませんが、「この領域の担当はAさん」「この領域の担当はBさん」となってしまうと、個人の方の負担も大きいし、計画が達成できるかが個人に依存してしまうので、チームでサポートしづらい体制になるのかなと思っていて。なるべくチームで取り組むことを意識しているという感じです。
このあたりの話は、最近ではないかもしれませんが、『チームトポロジー』という、書籍というより、もともとWebで公開されていたものの概念を取り入れてチームを作っています。例えば、自分たちの中の施策を完結できるようなチームは何かというと、ストリーム・アラインド・チーム。私たちもそういう名前で呼んでいますが、そういう概念があったり。
「チームでちゃんと取り組みましょう」「チームファーストの考え方をちゃんとしましょう」みたいなことは、この書籍から知識を入れて、開発体制を作っています。
今後の課題
今後の課題として、ミッションはより早く達成することをやらないといけないので、仮説検証とデリバリーのサイクルを早くすることは、当たり前ですが、がんばらないといけない。やはり、仮説を出して実際に検証していくのは、実際にやってみるとけっこう難しいです。何回もトライしながら、繰り返して練度を高めていくしかないと思っています
今回は、組織がテーマだったので組織の話ばかりしてしまいましたが、技術的なことが原因でデリバリーの速度が落ちている。（その時に）「仮説として、こういうのをやろう。だけどちょっと作りにくい」ということはやはりあります。
私たちがプロダクトをリリースしてからもう4、5年経っていて、かつ、2年前までは数人で開発してたのが今は40人いるという中で、技術的な負債が原因でデリバリー速度が落ちていることも、やはり正直あります。組織のあり方やチームの体制を変えるだけではなく、技術やアーキテクチャもセットで改善していかなくてはいけなくて、ここにはまだまだ課題があるし、これからもがんばらないといけない。
技術改善に取り組むエンジニアはまだまだ必要です。課題はたくさんあるので、手伝ってくれる方を募集しています。以上です。ありがとうございました。
