こんにちは。株式会社GaudiyでPMやってるmiyatti（みやっち）といいます。（Gaudiyとはどんな会社かというところは、ぜひリブランディングが話題の会社ページをみてみてください）

Gaudiyに入って1年4ヶ月。初期は代表PO（CPO）として全体のPMプロセスを整備したりするようなことをやりつつ、ここ半年は現場のPMとしてそのプロセスにうまくのっかりながら、ここだ！というようなプロジェクトに全勢力を上げて邁進してきました。そのプロジェクトもクローズドではありますが一定のアウトカムを出しつつあり、これからGaudiy盛り上がっていくぞという段階にきてると思ってます。

なのですが、いきなりサラッと書いてしまうのですが、実は私この度新たなチャレンジをするため、Gaudiyを卒業させていただくことになりました。この記事はいわゆる世で言う「退職エントリ」と言うものになるかと思います。

ただ、もともとこの記事はそう言った目的で書かれておらず、特に自分の退職についてなにか細かくかくつもりはないです。単純にGaudiyの自分としてどんなチャレンジをしてきたのか、現在のGaudiyがどんなプロダクト開発組織なのか、どう変わったかというところを振り返ってみようかなと思って書いております。読者の方向けには、せっかくなのでPMプロセスのHowTo的な記事にしようかと。具体的には

• Gaudiyに導入しようとしてきたトリプルトラックアジャイルとはなにか？

• 開発中心のプロダクトチームに、どのようにUXデザイン（Discoveryプロセス）が根付いていったのか？

• プロジェクトの初期段階、どのようなプロセスで経営レイヤーと、企画や方向性の擦り合わせなどをおこなったのか？（Senseプロセス）

• 開発プロセスでPMが特に意識すべき重要な点はなにか？（Deliveryプロセス）

この辺の話をこの記事ではできるといいなと思っています。

1. 現在、Gaudiyはどんなプロダクト組織になったのか？そのコアとなる組織コンセプトとは？

現在のGaudiyにおけるプロダクト組織を一言で表すと、開発中心もしくはビジネス中心の偏った組織ではなく、ビジネスやUXデザイン、開発の３つの領域が心地よく絡み合い、小さな仮説を繰り返し検証する組織になっている、と言えると思います。

よくあるアンチパターンとしては、経営層がトップダウンに、これやってよという話が現場に落ちてきて、それを無思考でとりあえずUIデザイナーがデザインし、開発も言われた通り作る、みたいな、「社内クライアント-ベンダーモデル」。

そうではなく、経営やビジネスから出てきた仮説をベースに、本当にそれあってるの？と現場レイヤーもまじえながら熱く議論し方向性を仮決定、そしてその内容を元に今度は現場メンバー中心にUIUXレベルでブラッシュアップ、そして最後その磨かれた施策案をWhyと共に、開発メンバーにも伝え、納得感を持って開発をすすめていくような形にほとんどの場合なってると思います。

「まぁあたりまえじゃない？」という方は、ここから先お読みになる必要はないかもしれませんw 

そう、理想系としてはそうだよね！という話でよくPM方法論でも語られたりするフローですが、実際にスタートアップでプロダクトマネジメントに取り組んでる人ならある程度わかると思うのですが、言うは易し、というところでまぁ難しい。

その辺をどんな感じに、やっていったのか？と言うところを今回はお伝えしたいです。

全体のプロダクト開発フローの整備からはじめる「Sense -> Discovery -> Delivery」というトリプルトラックアジャイル

POになった当時、インタビューを受けた記事に、初期のPMプロセスの方向性をしゃべってます

とまぁわかったような、わからないようなプロセスについてふわっと書いてます。そして続きをよむと

と、かいてるのですが、今となってみると、大まかSenseが企画（ビジネス）、Discoveryがデザイン、Deliveryが開発、という単純な話でもいいと思います（おい）。

色々運用してみて、この時そういう細かい思想的な話よりも、むしろ開発（Delivery）以外のプロセスを、明確に定義し、ブラックボックス状態をなくすことができる、というのがこの考え方のいいところだな、ということにきづいたからです。

（いや、上の記事で書いてる通り、実際はもちろん、こんな綺麗にわかれてしまうと、縦割り組織問題とかでてきてよくないとかはあるんですが、大まかな理解としてはこれでよいとおもう）

イメージ的にはこんな感じですね。

Discovery&Deliveryのプロセスだけをとると、よくデュアルトラックアジャイルという名前でとりあげられる、有名なプロセスです。ここにSenseというプロセスをくっつけたプロセスをトリプルトラックアジャイルと言いたいと思います。

ちなみにトリプルトラックアジャイルという言葉はこの記事をかくときにはじめて考えましたw Sense Discovery Deliveryというフローを一言でいうとなんになるかなーというと、この言葉になるかなと。

調べてみたらUbieさんも、トリプルトラックアジャイルという名前でフローを回してらっしゃるようで、かなり近い感じかなと思います。

ちなみに余談としては、エクサウィザーズ時代に書いたこの記事のプロセスの短縮バージョンでもあります

• １週目 Discovery-sense -> Discovery-respond ->

• ２週目 Delivery-sense -> Delivery-respond

という流れを上の記事では書いていたのですが、これを 

• Discovery-sense = Sense

• Discovery-respond = Discovery

• Delvery-sense -> Delivery-respond = Delivery

とした感じです。多くの人に理解してもらうのに細かすぎるプロセスは伝わらないので、やはりなるべくシンプルにするのが大事ですかね。ただ、やるべきこととか中身はわりと上の記事の頃から特に変わってないです

開発は、どんな組織でも明確なプロセスがあるが、企画やUXデザインはブラックボックスになりやすい

上の文章でもかきましたが、ここは組織によっては、トップやPMが属人的に勢いでやっちゃうことが多いです。開発前のちょっとした、カオスな領域みたいになりがち。ここに「Sense」とか「Discovery」とか名前をつけるだけで、開発＝「Delivery」と同じぐらい、独立したプロセスとして認識できるようになるんだとおもいます。

まずは、フレームワークを意識することで、あるべき組織の状態、目標というのが見えた

多分この話をして、PM間だけでこのフレームワークの話をしているとき、PM以外は全然まだぴんときてなかったはず。ただ、それでも、PMの中ではこっちの方を目指すのがいいのだ！という認識はあったきがする。

ただ、こっから「Discovery」および「Sense」を実際に、組織に根付かせるためにはまだやることがありました。

まずはDiscoveryをどう根付かせるか。

2. Discovery - Discoveryは実際にどう根付いていったか？

ブログの記事的には、Senseから順を追って話す方がわかりやすそうなんですが、Gaudiy的にはまずDiscoveryプロセスの定着が最初にとりくんだことだったりするのでまずはここから。

プロセスがあるだけでもうまくいかない。「User Developmentチーム」というDiscoveryのためのチームの誕生。

Discoveryを会社に根付かせるために、プロセス・フレームワークをメンバーが認識するだけでいい、とかでうまくいくんだったら誰も苦労はしない。このプロセスに責任をもつロールがあり、またそのメンバーのモチベーションが高い状態というのを作る必要があります。

初期はUIデザインチームとUXデザインをやるメンバーというのは分かれていたのですが、ここをくっつけてUserDevelopmentチームとし、Discoveryチームというのが誕生しました。

ここをデザインチームとしたり、UXチームとしたり、いろんな名前がつくことが多いと思うのですが、そのどちらもとらずUserDevelopmentチームとしたのは良かったと思います。

顧客開発チームとし、UIでもUXでもどっちでもいいから、顧客のニーズを探索し、ソリューション案を考える、ユーザー中心のチームという側面をだすことができたし、またDeliveryはDevelopmentチームという名前なので、そこと対等な感じっぽい名前になっていて、DiscoveryとDeliveryのバランスみたいなのもだせたきがします。

また、ここにUDev代表というリーダーをおくことで、POは、DiscoveryおよびDelivery両方とちょうどいい距離感をおくことができるようになった。

POはほっとくと、この企画・Discoveryプロセスにも責任を持ちやすくなるが、今度はそうするとDeliveryから遠ざかってしまいがち。DiscoveryプロセスはUdev代表、DeliveryプロセスはDev代表に任せる、という立て付けができたのもよかったと思います。

（会社の体制についての詳細はここでは割愛しますが、気になる方は弊社カルチャーデックをごらんください！）

UDevチームの詳細についてはこちらの方が詳しいかも

UDevチームができてからは早かった。優秀なメンバーがどんどん入ってきて、より良いプロセスを提案していき、精度＆スピードがどんどんあがっていった。

チームができることの利点は、もちろん組織にそのプロセスが根付いていくことにもありますが、枠ができることで、外から採用がしやすくなる、という点もあったと思います。

UX/UIデザインを中心にやるチームがあるから、UXデザインに興味がある人はどんどん入ってください！といいやすくなり、経験豊富なメンバーがぞくぞくとはいってくるようになった。そして、新しいUXデザインの仕組みを導入してくれて、よりよくなっていった。（そのひとつに高速Discoveryの仕組みなどがある）

Discoveryスプリントの仕組みのブラッシュアップ

ということで、基本的にはUdevメンバーが独自にチームを作ってきました。PMとしては、Devもそうだが仕組みの方向性とプロをアサインするところまでやったら、ある程度任せきるのが大事だとおもっています。

ただ、Discoveryだけでなく、SenseやDeliveryとどう連携するのか、といった部分、情報連携の仕組みなどはPO/PMが考えるべきです。

まぁ、言うは易しなところがありまして、大まかな全体フローは合意がまだとれやすいのですが、細かいフロー設計、仕組み作りは本当に、いままでメンバーそれぞれ使い慣れたツールというものもあります。ここの使い勝手次第で、業務の生産効率性もめちゃ変わるので、みんないろんな意見を持って当然です。

代表POの時、実際全体の仕組みとして色々提案し実験してきましたが、全体として完全に細かいところまで統一するのは難しいな、と思うようになりました。流石にツールがばらばらだと辛いですが、そのツールをどう使うか、どう言うフローにするかは、チームごとにある程度使いやすいものを試すのがいいかなとおもってます。

以下記すのは、自分がここ半年現場PMとして、１チームををどう運用したか、という例になります。

たとえば、チケット管理。Designers系とEngineers系では、使いたいツールも好みも割と違うものですが、ここで全く違う仕組みを採用してしまうと、危惧している縦割り組織感が強まってしまいます。

そこで、やはり基本的にはJiraなどの使いづらいけど、いろんなパターンに対応できる高機能なツールで全体の仕組みを運用するのがベストプラクティスとかんがえ、採用してます。

ただ、Jiraで開発（Delivery）チームが使うScrumボードとは独立して、Discovery用のボードを作り、そこでUX/UIデザインタスクのチケットを管理するようにしました。

（具体的には、基本的にはEpicで１つの仮説・施策をあつかい、そこにDiscovery用のチケット、Delivery用のチケットをつくってひもづけます。それぞれのチケットのIssueTypeは、Discovery専用、Delivery専用のものを使います。Boardは、それぞれフィルタで、その専用チケットだけが表示されるようにし、そうすることで専用ボードが作られます）

これは、色々一般的には議論があるところで、BoardはDiscoveryもDeliveryも同じボードを使う方がいいとされることも多いとおもいます。

が、Discoveryチームが立ち上がったばかりの組織は、多分一旦分けて運用するのがいいとおもうし、ミーティングも分かれてやるのがいいと思っている。理想状態は１チームで明確にDiscovery,Deliveryチームにわかれることなく、柔軟にあるときはみんなDiscovryをし、あるときはみんなDeliveryするみたいなことができるようになると、わけないほうがいいのだけど、いきなりそんなオールマイティなメンバーばかりになることはないです。

その状態で下手にまぜると、Discovery側にはDeliveryのチケットがノイズになるし、逆もそうなる。この辺は初期は分けて運用することが良いと思います。

チケット管理の方法については、細かく書くといろいろTIPSがたくさんあるのですが、ここでそれを書くとそれ専用の記事になってしまうため、今回は省略します！

というわけで、Discoveryという活動は、Gaudiyに文化レベルで根付くことができた

今となっては当たり前のように、社内で「開発する前に早くDiscoveryしなきゃー」とか超普通にSlackとかでつぶやかれてるのをよく見かけるのですが、Slackで過去遡って調べたら、このSense,Discovery,Deliveryプロセスが提案されてから、はじめてみんなの意識に「Discovery」という活動が定義されたきがようで、そっからちらほらその言葉がつかわれはじめたのが見えます。

いまとなってはUserDevelopmentチームのみならずコーポレートメンバーやBizメンバーなど、いろんな場所で普通にDiscoveryという言葉が使われてます。

これが、このプロセス、フレームワークの導入、そしてそれを担うUserDevelopmentチームができた最大の効果なきがするのです。

3. Sense - Senseプロセスとはなにか？Gaudiyではどう機能しているのか？

次に、Senseのプロセスにいきたいとおもいます。Discoveryより一歩手前のステップになります。

SenseはDiscoveryほどには、まだ組織で意識はされてないし、チームなどは存在していないのが実情。

ということで、Discoveryはチームも存在し、色々な仮説検証を高速で回すメンバーが活躍してる状況になりました。

それに対して、Senseは、まだまだ現状でも難しいプロセスです。Discoveryプロセスほど、フローとして確立されているわけでもないし、チームも明確にあるわけではないのが正直なところ。

ただ、Discovery同様、”Sense”というステップがあり、それに名前がついているという共通認識が、PM中心にあったりすることで、今までブラックボックスになりがちだったプロセスの民主化みたいなことはおきているきがします。

Senseは、プロダクトの全体戦略を考え、Discoveryする施策のアイディアを生み出すフロー。

いろいろな条件・状況がビジネスのまわりにはあります。いわゆる３Cというやつで、Company（社内）・Customer（市場）・Competitor（競合）などの状況は刻々と日々かわっていて、ここに個人的にはTechnology（技術トレンド）なんかも気にしますが、そういう変化のなかで、Product Managerは、アウトカム達成＝PMFのために意思決定をしなければいけません。

何の意思決定か。解決すべきProblem＝Burning Needsをみつける。それをベースになにをSolutionとしてつくるべきかを考える。一度とくべき課題や探るべきソリューションがみつかれば、それはDiscoveryフェーズに移行し、User Developmentチームに任せることができる。

その前段階として、なにからDiscoveryをし、なにをDeliveryすべきか。作るべきアイディアを考え、その優先順位を決めていく必要があります。

その意思決定のためには、いろんな情報を整理し、Sense（知覚）する必要がある。そう言った情報を整理し全体戦略を考え着手すべき施策を決めるプロセスがSenseプロセスです。

Senseというステップを仕組み化しようとさまざまなチャレンジをしてきた

例えば自分がやったことの一つには、PMやUserDevelopmentチームと一緒に全体でDesign Sprintをオフサイト的に実施したりしました。

また、代表石川さんが発案した「蠱毒」という仕組みで、全体の方向性を議論バトルする、なんていうのも自分が言うところの”Sense”プロセスです（蠱毒はSenseだけでなく、Discoveryプロセスでも利用できるものですが）。

属人的に直感でやるのでなく、俯瞰的に仮説をたて、みんなで検証するためのツール＝キャンバスアプローチ

ということで、いまだ明確なプロセスとして定まってはいないのですが、いくつかのやり方は、割とどのチームでもやられているものがあるので、それを紹介します。

一つ目は、キャンバスアプローチです。私はどちらかというと、情報を俯瞰的に整理したり、コラボレーションするような仕組みを好みますが、このキャンバスはまさにそれにうってつけです。

POとしていろんな案件で、PMをサポートする時はまずは、LeanCanvasやOpportunityCanvasなどをつかって、いろんな側面から今考えている仮説を整理することを勧めてきました。

思いなどをベースにすすめると、勢いはつくのですが、意外と考えに穴があったりすることも多かったりするので、こう言った形でやはり一度可視化して、メンバーで議論するのは重要だったりしますね。

Gaudiyはさまざまなステークホルダー、さまざまな考えや立場の人が内外入り乱れてプロジェクトが進むことが多いです。そして、また一人一人が熱い思い、直感、仮説をもっている。そうした全ての仮説を冷静に俯瞰するキャンバスアプローチは有用です。

私がよく使うのはオポチュニティキャンバスのほうだったりします。LeanCanvasは、完全な新規立ち上げのときに使い、OpportunityCanvasは既存の案件の改善系とかに使うのがいいとされることが多い気がします。

Senseの段階でも、だからこそ、アイディアを物語として説明し、わくわくするかを確認する＝ダーティプロトタイプ＆ユーザーストーリーマップ

もうひとつSenseの段階で、普通だとやられないけどやっぱりやったほうがいいね！となってきてるのがダーティプロトタイプ。荒削りのアイディアの段階だと、とりあえずもう開発はいろう、つくらないとわからないし、となってしまったりしがち。

そうじゃなくて、この段階でも、この段階だからこそ、実際にユーザーがそのソリューションを使ったらどんな楽しいことが待っているのか、というのを物語として語り、他のメンバーが「あ、これは実際にたのしいやつだ」と実感できる程度に解像度をあげるのが有効です。

そのために、ダーティプロトタイプ、ラフに適当な絵でもいいから、かいてみて絵にする。

そしてもう一つ大事なのが「物語る」こと。それをユーザーが本当に体験したとしたら、と言うシミュレーションをし、それをエンタメちっくに紙芝居的な作品にしたてあげること。

Gaudiyでは、あるプロジェクトで、がっつり PMのyuriettyさんが蠱毒において「短編小説」をかいてきたことで有名になったきがしますw 実際にやろうとしているアイディアが、本当にうけそうなのか、小説的に書いてみると「いやここは現実的には絶対お客さん喜ばなさそうだな」とかみてくるものなんですよね。こういった濃い作業を”Sense”の段階でもやりきるというのが重要ですね。

そこまでいかなくても、最低限ユーザーストーリーマップやカスタマージャーニー方式で、流れを書き出してみることはわりとやってます。

 

Gaudiyでは、蠱毒などで、次第にこういったプロトタイプやユーザーストーリーを語る方が勝ちやすい、という経験則などもひろまり（？）、アイディアをちゃんと具体化して検討するというHowが浸透していった気がします。

Senseで最も大事なのは、ゴール設定と、ロードマップ＝勝ち筋を議論し、登り方をきめること。

そして、代表POとしてここ1年最も重要だと考え、何度も議論してきたSense的活動が、多分この勝ち筋をつくること、な気がします。

もちろんここはPOがしのごの考えなくても、経営やBizが大まか方針をもっているものなんですが、そこに対してプロダクト側として、ビジネス観点だけでなく顧客観点および技術観点まで考慮した勝ち筋を考えることが重要、特に、どんだけ儲かりそうな話だったとしても、ユーザーが本当にそれを欲しいと思うのか、そこにバーニングニーズが存在するのか？という観点で、議論を深めることが重要でした。

そして、ロードマップ作成。おおまかな勝ち筋に関する仮説が生み出された後、どういう順番でどんな仮説検証をしていくのか。いきなりすべてをつくって、1回切りのリリースで全ての仮説検証をするのはリスクが大きいです。やはり、不確実性の高い仮説を検証できる最低限のプロダクト＝いわゆるMVPを作る。それを段階的にリリースしていく。

こうやって細かくきざんで検証しながら、最終的なプロダクトに仕立て上げていくというようなことをSenseの段階では計画することをやり、そう言った進め方は一般的になったと思います。

SenseからDiscoveryへの最後の仕上げ、ユーザーストーリーマップをDiscovery（オポチュニティ）バックログに変換

ここまでで、成果物としては

• キャンバス

• ダーティプロトタイプ

• ユーザーストーリーマップ

• ロードマップ

などができています。じゃあ、これをもとにDiscoveryフェーズに入りましょう！といっても、で、結局なにをすればいいんだっけ？となってしまいます。

そこで、直近の自分のプロジェクトやいくつかのチームでやっているのが、ユーザーストーリマップをEpicに変換して、Discoveryバックログとしてつみあげることです。

この作業のために、Miro - Jira連携の仕組みをつかっています。ここまでのフェーズでユーザーストーリーマップをつくるのにMiroを使うことが多かったです。

まずはこんな感じでつくります（以下はサンプルです）

ユーザーストーリーマップがこんなに最初から綺麗に項目にわかれてることはないです。Epic単位にきりやすいように、整理します。名前の付け方も工夫していて、フォーマットとしては“「XXXX」機能によってYYYYはZZZZZZということができるようになる” という書き方で統一してました。この書き方だと、「XXXX」機能というのが冒頭にあらわれるので、Epic名が省略された時もどんなEpicなのかというのがわかりやすいということと、それと同時に、それによってどんないいことがユーザーにおきるのか？というのもかけるので、一石二鳥なのです。

で、このカードをJIRAのEpicに変換します

こんなかんじで、簡単にEpicに変換できます。これを全部のカードにたいしてやります

そうすると、こんな感じになります。これ一つ一つが、実際にJIRAのEpicになってるので、DiscoveryやDeliveryのチケットを紐付けられる形になります。

jiraのボードでもリストとしてこんな感じで表示されます。

また、ロードマップの計画に沿って、スライスしたりもします。

ちなみに、このEpicに対してステータスを変更することもできるので、今このEpicの進行状況もユーザーストーリーマップとして一覧表示できるのでそれも便利です

Epicのステータスは今、Senseフェーズなのか、Discoveryフェーズなのか、Deliveryフェーズなのか、がわかるようなものにしてました。以下は実際に使っていたボードです。（ぼかしてるのでみえづらいですが、緑色になってるやつは完了しているEpicで、黄色が作業中とか一覧でみれます）

まぁこんな感じで、EpicをPMがきり、それにDiscoveryチームで、タスクをひもづけたりすることからDiscoveryがはじまっていきます。

全体像を俯瞰して見るのはチーム全員がやるわけではなかったりで、このボードも基本はPM中心にしかみないことは多いですが、バックログでリスト形式でみているより、今現在どこまで進行しているかとかが一目瞭然だったり、ここのステップは施策が薄いな、とかアイディアが出てきたり、色々便利なのでおすすめなやり方かと思います。

4.Delivery - Deliveryでは、しっかりDiscoveryチームからWhy（なぜやるのか）を伝えきるのが大事

Discovery,Senseの話をかいたので、Deliveryについても最後に書きたいのですが、Deliveryに関しては、まっとうにScrum的な開発プロセスをもともとまわしており、自分的にはここで何か書けるほど、改善したプロセスはなかったりします。

トリプルトラックアジャイルのように、役割別にプロセスを分けてしまう弊害はある

ひとつあるとすると、トリプルトラックアジャイルの弊害を以下に最小限に抑えるか、というところを意識したところでしょうか。なにかというと、Discoveryプロセスを明確にDeliveryと分けたことによって起きる一番よくないこととして、縦割り組織になってしまい、DiscoveryとDeliveryの連携、SenseとDeliveryの連携がなくなってしまうことだったりします。

つまり、Deliveryが、もうひたすらSense,Discoveryからおちてきたものを、かたっぱしから開発してしまう、みたいなことはほっとくと起きてしまう。
そして実際案の定起きてしまったり、起こしてしまったりしたこともありました。

特に、Gaudiyはいろんなプロジェクトを少ないメンバーで回すことも多く、常にリソース不足で、油断すると目の前の開発に追われることが多くなるのです。

縦割りの克服のための、アウトカム中心のマインドセット、そして「All Ownershipment」

PO/PMとして、一応スローガンとして「アウトカム」を意識しよう、アウトプット、考えなしにただ単にリリースすることを目標にするのはやめよう、というような話は伝えたりしましたが、特段それがこの問題解決に役立ったかはわかりません（ゼロではないとおもいつつ）

どちらかというと、もともとGaudiyメンバーは、All Ownershipというカルチャーがあります。たしかに、余裕ないとたしかにWhyなくともすすんでしまったりすることもあるし、企画側もWhyつたえなくてもいいか、となってしまうこともあるのですが、やりながら「いやこのやり方はやっぱり変だ」と思うメンバーが多く、自然とRetroなどの振り返り会でこの課題が論じられ、もっとWhyを伝えよう・聞こうという方向に改善されることが多かったです。

結局フレームワークとかプロセス、とかというのは、大元のモチベーション、そしてマインドセットがあって初めて成り立つもので、自分にできること、できたことは、そこの土壌に、ちょっとした型を伝えて、刺激を与えることぐらいだったな、と振り返って思ったりします。

5. 反省とまとめ - ということで、PO/PMとしてトリプルトラックアジャイルを理想としてすすめてきてみた結果

入社当時、自分が考える理想のプロセスをGaudiyに導入してやるぞ、と内心は息巻いてました。そして、初期は基本的にもともとGaudiyメンバーがやりたいこと、というか組織変革の方向性が自分と同じ方向を向いていたこともあり、ほんとそんなに苦労もせず、Discoveryプロセスの浸透はうまくいきましたし、途中からUDevチームが自律的にどんどん改善していくようになりました。

スタートアップで、まだPMFを明確にしていないフェーズだと、焦りもあり、プロダクト自体をがむしゃらによくすることに全力でリソースをさき、仕組みみたいなところにあまりフォーカスを当てない会社も多い中、自分的にはいい会社に入れたなと思った記憶があります。

実際この仕組みに対するマインドセットを代表やメンバーがもともともっているか、というのは超重要なところかと思います。ここを大事にする文化がそもそもないと、やっぱりこういうプロセス変革はうまくいかないですね。

Discoveryプロセスの導入とかがスムーズにいったのも、もともとマインドセットが強くあったからだと思います。

自分がちょっとした壁にぶつかったのは、やっぱりSenseプロセスだったかなとおもいます。上で書いたように色々なチャレンジはしましたし、一定の仕組み化はできたところはありましたが、DiscoveryやDeliveryほど定着する基本プロセスのようなものになったわけでもないですし、またそのプロセス改善のなかで、プロセスのおかげで「これだ！」というアウトカムがでてきたか、というと、どちらかというと泥臭く深夜までメンバーで議論しまくりなんとかかんとか捻り出したりしたもののほうが圧倒的に多いと思います。

その理由は、シンプルに、やはりSenseは、UXや開発だけでなく、Bizサイドの観点や会社のビジョン、ステークホルダーの思いなど、より不確実性の高く重要な情報を扱うからです。ここをハンドルしてScrumプロセスの一部として仕組み化するのは、長年チャレンジしてますが難しい。

むしろ私が、代表POをやめて、現在のPOのkaaazuさんにバトンタッチして、その後Senseのプロセスの洗練みたいなのは進んでいったのは素晴らしかったです。自分はその段階で現場PMとしてやっていたこともあり、そこのプロセス化はそこまでタッチしてなく、ここで十分にはかけないので、ぜひ別のタイミングでkaaazuさんからここに関するブログが公開されるといいなと思ってます。

現在は、このまだまだ進化していってるプロセスや後は泥臭い仮説検証の繰り返しをやっていく中で、プロダクトとしても、間違いなくこれだ！というような強い仮説が見つかってきていまして、全力でそこのSense,Discovery,Deliveryをおしすすめているところです。

そんななか、前述のようにプロセスを確立するのは難しかったですが、POをやりながらここにフォーカスするべきと思う仮説をたて、自分がPMとしてそこをおしすすめ、一定そこにバーニングニーズがあるかも、と思える検証ができたのはよかったかなと思います。

プロダクトの性質上なかなか、まだオープンにできないことも多く、クローズドで進んでいる案件が多いので、まだそのアウトカムを世の中に見せられないのが残念なのですが、本当に近い将来その成果物を見せることができる日がくるとおもいます。

冒頭でも書きましたが、今回会社を退職することになりました。PMプロセスの完成という意味でも、また現場PMとして、アウトカムを実際に世に出すというところでも道半ばで、申し訳ない思い＆反省もさまざまあるのですが、引き続き自分としては新しい場所で、Gaudiyで学んだ知見をいかしてPMプロセスにもこだわりながら新しいミッションをもって、アウトカム達成をやっていこうと思っています。

いま動いているやばいプロジェクトは本当にやばくて早く世に出てGaudiyのすごさが世の中に見える形になり、Gaudiyメンバーの苦労が報われるそんな日をやってくるといいなとおもってます。

じゃあなんでそんなやばい成果が出そうな会社をやめるんじゃい、という話で、いや本当にそうで、メンバーひとりひとり優秀ですし、ビジョンドリブンで、多分スタートアップ界隈で一番思想的にはハマってたと思います。

そんな流れで、一応最後に辞める理由みたいなのも書いてみようかと思うのですが、シンプルに自分がトライしてみたいとおもえる新たな領域というところに出会った、というところがあります。以下のインタビュー記事でこたえたのですが、色々領域かえて転職を重ねてるのって大変じゃないですか？的な質問に

自分がやりたいこと＋自分が入って貢献できるフェーズ、という会社さまとたまたま出会ってしまった、というところです。自分としては引き続きGaudiyでもトライしていた、そのベースとなる思想ややりたいことは持ち続け、新たなチャレンジをしていきたいと考えています。

引き続き私にも、またこれからのGaudiyにご注目いただければとおもいます！