Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
運用5年目の位置ゲームの新米プロダクト開発
Search
Kenta Kobayashi
October 24, 2016
Technology
11k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
運用5年目の位置ゲームの新米プロダクト開発
#pmconfjp 2016
Kenta Kobayashi
October 24, 2016
More Decks by Kenta Kobayashi
See All by Kenta Kobayashi
Perlの生きのこり - YAPC::Fukuoka 2025
kfly8
0
2.1k
プロジェクトの空気を読んで開発してくれるPerlのAIツールがほしい
kfly8
2
950
Perlの生きのこり - エンジニアがこの先生きのこるためのカンファレンス2025
kfly8
4
3.1k
Tシャツに書かれたコードを読む
kfly8
0
1.5k
Introduce Sub::Meta
kfly8
0
100
研修はイベントでなくコミュニティ作り
kfly8
0
2.3k
明日からできる新人のオンボーディングガイド
kfly8
0
900
メンター成長のためのふりかえり会
kfly8
0
1.4k
Interfaces in Perl5 at The Perl Conference 2019 in Pittsburgh
kfly8
0
3.3k
Other Decks in Technology
See All in Technology
フィジカル版Github Onshapeの紹介
shiba_8ro
0
320
新しいUbuntu/GNOMEが使いたいからXからWaylandへ移行頑張ってるの巻 2026-06-20
nobutomurata
0
160
「軸足」は 固定しなくていい - 熱量と強みで描く、しなやかなキャリアの形
kakehashi
PRO
1
270
GitHub Copilot 最新アップデート – 「一歩先」の実践活用術
moulongzhang
5
1.7k
MUSUBI 田中裕一『AIと共に行う「しごとのリデザイン」- スモールバックオフィス編』AI Ops Lab #4
musubi
0
310
2026 AI Memory Architecture
nagatsu
0
250
AI Agentをシステムに組み込む前にゆるく向き合ってみる
hayama17
0
140
元銀行員がAIだけでアプリを量産!「バイブコーディング実演セミナー 」
tatsuya1970
0
110
Multi-Agent並列開発を 安全に回すための技術 / Technology for Safely Multi-Agent Parallel Development
tooppoo
0
180
2026年6月23日 Syncable Tech + Start Python Club にて
hamukazu
0
150
時期が悪い!それでもRaspberry Piを買って遊んで活用するには / 20260627-osc26do-rpi-jikigawarui
akkiesoft
0
820
感情と身体を置き去りにしない、エンジニアの生きのこり方 ──いまから、ここから「自分の状態」を扱うという選択
saorimurooka
0
340
Featured
See All Featured
The Spectacular Lies of Maps
axbom
PRO
1
820
Mobile First: as difficult as doing things right
swwweet
225
10k
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
55k
The Limits of Empathy - UXLibs8
cassininazir
1
370
Crafting Experiences
bethany
1
190
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
120k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.5k
A designer walks into a library…
pauljervisheath
211
24k
Thoughts on Productivity
jonyablonski
76
5.2k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
65
56k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
Transcript
運用5 年目の位置ゲー ムの 新米プロダクト開発
自己紹介 小林謙太 ( @kfly8 ) Perl,JS,Math YAPC::Japan 運営側 Mobile Factory
2011/4 ~ 新卒入社( エンジニア職) 2015/6 ~ 駅奪取チー ム 2016/2 ~ 駅奪取チー ム PM 生後8 カ月の娘にメロメロ 娘の最近の好物は、 私のメガネ
お話ししたいこと エンジニアとして新卒入社した自分が、 今年から「 駅奪取」 のPM となり、 考えたこと、 失敗してしまったことなど
アジェンダ 運用5 年目の位置ゲー ム「 駅奪取」 サー ビス紹介 2 つの大問題 a.
どの問題から解決すれば良いかわからない b. 使いにくいドキュメントとKPI ツー ル 新米プロダクト開発 2 つの失敗 a. 「 成果を出さなければいけない」 b. 「 なんでやるの?」
運用5 年目の位置ゲー ム「 駅奪取」
サー ビス紹介1 おでかけを駅猫ニャッシュと一緒に楽しむ日本全国9 1 0 0 駅を集めるゲーム
サー ビス紹介2 安定的に収益をあげているプロダクト O2O の取り組みも積極的に行なっている 姉妹プロダクトの「 駅メモ!」 は、MF の花形製品
サー ビス状況 今年、 位置ゲー ムが世間的に有名になった 駅奪取も、 もっと多くの人に遊んでもらいたい
2 つの大問題 1. どの問題から解決すれば良いかわからない 2. 使いにくいドキュメントとKPI ツー ル
1. どの問題から解決すれば良いかわから ない
表面的に見える問題はたくさん 古き良きブラウザゲー ム / ガラケー 対応 多プラットフォー ム展開 ( 悪く言って)
百徳ナイフ、 プロダクト プロダクトの方向性にブレ?
どうするか? セオリー 的には、 プロダクトの方向性の整理? 学習/ 経験不足で、 やりきれるか? 問題の因果関係の収拾がつかない... 今の自分に見えていることは氷山の一角に過ぎない? そもそも、
プロダクトの方向性がしっかりなければ、 問 題設定がブレる 問題でないものを解決しても意味がない
やったこと 運用の効率化 今後大きなサー ビス改善をする余裕を持つ 駅奪取は元々 のままでも面白い 安定的に収益をあげているプロダクトな為 ズレた施策をいれるなら、 何もしない 成果が出やすい
チー ム内で完結でき、 効果も見積もりからブレにくい ユー ザへの施策だとアタリハズレはある
結果 運用コストが、 当初見込み通り、 半分ほどに改善 これで今後の改善ができそう
2. 使いにくいドキュメントとKPI ツー ル
見える問題 ドキュメント・KPI ツー ルが更新されていない 時期/ 作った人によって形式がバラバラ
どうするか? 更新のルー ル化? テンプレを用意する?
やったこと( ドキュメント) 最小限の手間で、 チー ムで把握したいことの整理に 注力 重要ドキュメントの再構成 目次/ タグの整理 古いものは放置
PRD( もどき) のテンプレ用意
やったこと(KPI ツー ル) 目標と進捗をカンタンに追跡しやすくする KPI のストー リー なぜその数字を見るのか サー ビスの健康を見る為か
/ 先行指標 仮説検証する為か / 洞察指標 いつ見るのか 誰が見るのか BI ツー ルの導入推進 DOMO
結果 自分自身のサー ビスの判断軸/ 材料は整理できた が、 チー ムへの浸透は足りない
チー ムへの浸透に至らなかった理由 自分にとって使いにくいドキュメント・KPI ツー ル 慣れている人は慣れていた エンジニアの時は、 自分もここまで気にしていなかった PM の立場になって重要度が上がった
課題 知識/ 成功パター ン/ 問題認識の違い 納得感醸成のコミュニケー ション不足
まとめ( 運用5 年の位置ゲー ム) どの問題から解決すれば良いかわからない 運用効率化の実施 急がば回れ 使いにくいドキュメントとKPI ツー ル
ドキュメントは、 チー ムで把握したいことの整理に注力 KPI は、 目標と進捗をカンタンに追跡しやすくする
新米プロダクト開発
2 つの失敗 1. 「 成果を出さなければならない」 2. 「 なんでやるの?」
1.「 成果を出さなければならない」
「 成果を出さなければならない」 と感じた 初めてチー ムの方針を決める立場になった為 長く愛されているゲー ムだった為
突然ですが... 懺悔
私は、 こっそり実装をしました
チー ムとしては、 健全なことではない 成果を上げられない怖さ。 余裕のなさ。 が招いた行動
対応 視点の調整 余裕を持つ( 少しでも...) 機会を待つ勇気( こわいけど...) チー ムや同僚の共感を持って、 チー ムで実行する必要が
ある 成果点の変更 BEFORE KPI 達成で、 成功 AFTER 変化を起こせれば、 成功 KPI 達成で、 大成功
2.「 なんでやるの?」
PM として、 なぜを「 考える」 のは必要 人への投げかけもそのまま「 なんでやるの?」 を使っていた それは厳しい言葉/ 否定的だった
背景 数学をやっていた時、 なぜの主語は数学だった 「(A->B となるのは) なんで?」 エンジニアの時、 なぜの主語はコー ド/ 技術が多かった
「( 何行目のこのコー ドは) なんで?」
立場が代わり、 なぜの主語は、 人に近くなった 「( この施策は) なんで?」 例えば、 施策を考える時、 大なり小なり主観はある 良かれと思って提案をしている。
絶対の正解は作りにく い世界。 論理は使うが、 主観も入る。 主観がある分、 考えた人自身への指摘にもなる
対応 聞き方の調整 「 何が良さそう?」 相手が、 肯定的に意見を述べやすい形の質問/ プレゼンテー シ ョンしやすい聞き方
まとめ( 新米プロダクト開発) 「 成果を出さなければならない」 成果点の変更も余裕を持つ手段 「 なんでやるの?」 相手が肯定的に意見を述べやすいよう聞き方を配慮する 「 何が良さそう」
ご静聴ありがとうございました! 募集 おでかけの楽しみを増やしてみたい方 エンジニアからPM にキャリアチェンジしてみたい方