はじめに
こちらは、アソビュー Advent Calendar 2025の23日目（裏面）の記事になります。
こんにちは。
アソビューでプロダクトマネージャーをしているやまうちです。
クリスマスイヴまであと1日ですね。
皆さん、クリスマスプレゼントはもう決まりましたでしょうか。
私は先日参加したトレイルランの大会中にiPhoneを水没させてしまい、新しいiPhoneが自分へのクリスマスプレゼントになりました。動作がサクサクで、とても快適です。笑
さて今回は、開発チーム以外にもプロダクトゴールを共有したことで、アウトカムを生み出すチームの人数と役割が拡張した話をしたいと思います。
僕らのチームについて
僕らのチームは、「アソビュー！チケット管理」というプロダクトの開発を担当しています。
水族館や動物園などを運営する事業者（アソビューでは「パートナー」と呼んでいます）が、アソビュー！サイトや自社サイトで販売するチケットの管理や、売上データの確認・分析を行えるようにするためのプロダクトです。
開発メンバーは、5人で構成されています。
一方でこのプロダクトには、
- カスタマーサクセス
- パートナーサポート
といった、異なる部署に所属しながら、日々パートナーと向き合っているメンバーも深く関わっています。
本記事では、こうした「パートナーと向き合っているメンバー」と、開発メンバーが部署の垣根を越えて協働した話をします。
共有したのは「やること」ではなく「到達したい状態」
チーム発足当初、プロダクトの目指す姿であるプロダクトビジョンと、直近で到達したいアウトカムとしてのプロダクトゴール（到達したい状態）を策定しました。
このゴールは、特定の機能をリリースすることや、「◯◯ができるようになること」を定義したものではありません。 「このプロダクトが価値を発揮していると言える状態は、どんな状態か」という問いに対する答えを、チームとして言語化したものでした。
そのため、機能開発はあくまでアウトカムに近づくための手段の一つという位置づけでした。
このアウトカムとしてのゴールは、開発メンバーだけでなく日頃からパートナーと向き合っているメンバーにも当初から共有していました。
これまでの進め方
今振り返ると、当時の進め方は次のようなものでした。
- 実際に手を動かす主体は、開発メンバー
- ゴールに近づくために、開発メンバーが機能開発を進める
開発メンバーは、開発生産性を高める施策やGitHub CopilotやCursorを活用した開発などを通じて、ゴール達成を目指していました。 ただ、あるタイミングからこんな見立てを持つようになりました。
「機能をリリースするだけでは、アウトカムとして目指している状態には、70%くらいまでしか届かないのではないか」
開発は順調。
リリースもできている。
それでも、パートナーの行動や業務の変化といったアウトカムには、あと一歩届かない。
この見立てが、次の一手を考えるきっかけになりました。
部署の垣根を越えて、「アウトカムを担う」仲間を増やした
アウトカムとしてのプロダクトゴール自体は、チーム発足当初から開発メンバーだけでなく、日頃パートナーと向き合っているメンバーにも共有していました。
ただ当時は、「アウトカムを実現する主体は、主に開発チームである」という前提が、暗黙的に置かれていたように思います。
そんな中で生まれたのが、次の疑問でした。
「アウトカムに繋がる打ち手って、本当に“開発チームの中”だけにあるんだっけ？」
この疑問をきっかけに、パートナーと向き合っているメンバーと改めてディスカッションを始めました。 すでに「目指している状態（アウトカム）」は共有できていたからこそ、
- 「じゃあ一緒に考えよう」
- 「現場側でできることも洗い出してみよう」
といった会話が、ごく自然に生まれました。
ここで踏み出したのは、アウトカムそのものを共有することではなく、「そのアウトカムを、誰が・どう担うのか」を、部署の垣根を越えて再定義することでした。
このタイミングで改めて共有したのは、直近の数値目標だけではありません。
- プロダクトビジョン
- その背景にある課題意識
- なぜこのゴールを目指しているのか
- 現在の施策と、今後やりたいこと
僕らが考えていることを、できる限りすべて言語化して伝えました。
するとメンバーたちは、すぐに解決策を作り始めるのではなく、
- 自分たちの業務の棚卸し
- 課題解決におけるボトルネックの特定
- そのボトルネックをどう解消できるか
を考え始めました。
さらに、一次情報を得るために、他の社内メンバーや実際のパートナーへのヒアリングも自発的に行ってくれるようになりました。
プロダクトマネージャー的な思考で、現場メンバーが「アウトカムを担う側」として動き始めた瞬間だったと思います。
開発チーム以外のメンバーに起きた変化
一次情報をもとに施策を考えた後は、実際に「作る」フェーズに移ります。
プロダクト開発の経験があるメンバーはいませんでしたが、AIを活用しながら、
- GASによるダブルチェック業務の自動化
- 作業ミスを減らすための効率化施策
- フォーム改修のためのLP制作
- Slackフローの構築
- Chrome拡張機能の作成
など、次々とアウトプットを生み出し、社内に展開してくれました。
一方で、「作ったものの、あまり使われていない」「アウトカムに繋がっていない」施策もありました。
その際も、「なぜ使われないのか」「どうすればアウトカムに繋がるのか」を自らヒアリングし、「使われるものを作る」思考をさらに強めていったのが印象的でした。
改善を重ねる中で、施策の効果も徐々に現れ始めました。
AIが「ソフトウェアエンジニア化」を加速した
これまで事業側は、プロダクトチームに「この機能がほしい」と要望を出す立場でした。
しかしAIを活用することで、自分たち自身がソフトウェアエンジニア的な役割を担い、実装まで行える状態になりました。
その過程で、
- 思ったより使われない
- 仮説が外れる
- 改善が必要になる
といった、ソフトウェア開発特有の不確実性や難しさも実感してくれたと思います。
だからこそ、「何を作るか（What）」だけでなく、「なぜ作るのか（Why）」をより丁寧に磨き込む必要性を、各々が強く意識するようになりました。
今では、現場メンバー自身がPRDを作成し、「アウトカムを生み出すものでなければ意味がない」とまで言ってくれています。
チームはどう拡張されたか
結果として、開発メンバー5名に、現場メンバー3名が加わり、合計8名体制で同じプロダクトゴールに向かって動くチームになりました。
プロダクトビジョンとアウトカムとしてのゴールを共有し、AIを活用することで役割や部署を越えてアウトカムを担う仲間が増えていった。
これは、チームが「拡張された」と言える状態だと思っています。
プロダクトゴールの達成まで、あと少し。
これからもチーム全員で課題に向き合い、アウトカムを出し続けていきたいと思います。
「アウトカム思考」の布教活動から始める。「やみくもな機能リリース最優先」から脱却する方法 | レバテックラボ（レバテックLAB）
アソビューのアウトカム文化の浸透は、こちらのCPO横峯さんの記事でも触れています。
横峯さんとは日頃からいかにしてアウトカムを出すかを会話させていただいています。
まとめ
AIによって自分のできることを拡張し、役割や組織の垣根を越えて課題解決に向かうことがますます重要になっていると感じています。
むしろ、越境できない人は取り残されていく時代とも言えるかもしれません。
「これは自分の担当ではない」「やったことがないからできない」という言葉は、もはや言い訳にしかならないと感じています。
自分自身も、顧客の課題解決のために何ができるかを考え続け、組織や役割、事業の枠を越えてアウトカムを出し続けたいと思っています！！
アソビューでは、プロダクト組織全体で絶賛採用中です。
一緒に越境したい方、お待ちしています！
