1. プロダクトオーナーが成功のために
考えるべき戦略と戦術
ゲーム開発事例からプロジェクトを
少しでも成功へ導く思考方法
2016/11/26
有馬 もと

2. 今日はこの会です 2/101

3. 自己紹介
有馬さん
・ゲーム開発歴25年!
(どこぞの平面カエルの教師みたいだ…)
・プログラマなんだけど、なんでも屋。
プレイングマネージャとして開発したり企画したり外部交渉したりシナリオ書いたり売り上げの絵
図を書いたり…
・チームマネジメントはいろいろたくさん。
なんか任される。えらそう。
・古い人だと『遊びのレシピ』という本を書いた人だとわかりやすい?
3/101

4. スクラムはもうだめぽよ!
新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう!
というスライドが賛否両論になった
自己紹介 4/101

5. 自己紹介
有馬さん
・家族はゲームプランナーなうちの人と我が息子(猫)
・目黒区在住
・好きな本はCJチェリィの『サイティーン』
5/101

6. 今日のお話
今日は、戦略と戦術とプロダクト
オーナーについて話すっぽい?
6/101

7. 今日のお話 7/101

8. 聞いてみたい
今日あなたがこのセミナーを聴いて、いまの問題にどう役立
てたいのか教えてください。
解決方法を知りたいのか… それともトレーニング方法を
知りたいのか… あるいは慰めてほしいのか…
それによっては講演内容を変更します。
8/101

9. 今日のお話
▼戦略と戦術とプロダクト運営
初めてプロダクトを持ったり、あまり上手くいかないオーナー
に向けて、「戦略と戦術」をキーワードにプロダクト運営とは
なんじゃらほい? というのをひも解いてみる。
▼戦略と戦術のフレームワーク
プロダクトを持ったとき、「戦略と戦術」をフレームワークとして利用することを考えてみると、プロダクトのいまが整理しやすくなり、
成功へと近づけることができる(はずだ)。
わりと目標から逆算して今やることを決めたり、やらないことを決められる人が少ない
と聞くので、そのあたりを説明する。
ゲーム系プロダクトではない人もいるようなので、あんまりゲーム的な内容によらない
ようにしてみた。何か物を作るプロダクトでの問題、とでもしてもらえたら。
9/101

10. 今日のお話
▼戦略と戦術とプロダクト運営
初めてプロダクトを持ったり、あまりうまくいかないオーナーに向けて、「戦略と戦術」をキーワードにプロダクト運営とはなんじゃら
ほい? というのをひも解いてみる。
▼戦略と戦術のフレームワーク
プロダクトを持ったとき、「戦略と戦術」をフレームワークとし
て利用することを考えてみると、プロダクトのいまが整理しや
すくなり、成功へと近づけることができる(はずだ)。
わりと目標から逆算して今やることを決めたり、やらないことを決められる人が少ない
と聞くので、そのあたりを説明する。
ゲーム系プロダクトではない人もいるようなので、あんまりゲーム的な内容によらない
ようにしてみた。何か物を作るプロダクトでの問題、とでもしてもらえたら。
10/101

11. 「戦略」と「戦術」って何？
「戦術とは戦闘における戦闘力の使用に関する規範であり、戦略と
は戦争の目的を達成するための戦闘の使用に関する規範である」
「この狭義の兵学はまた再び戦術と戦略とに区分される。前者は
個々の戦闘の形態を論じ、後者はそれらの行使を論じる」
「戦争におけるロジスティクスや経済面はそれ自体が自律的に対応
することを想定しており、クラウゼヴィッツが戦略の対象とは考えていな
い。(略)今日のような科学技術が進歩し、燃料、食料、武器、弾
薬の供給が、兵士それぞれの詮議と同じぐらい重要になっている時
代においては、より危険度が増しているのである。このような観点から
言えば、孫武の論じ方、見立ての方がより戦略と戦争を包括的に論
じているのであり(略)」
11/101

12. 「戦略」と「戦術」って何？
…わけわかんなあい～
12/101

13. 「戦略」と「戦術」って何？
ちょっとわかりやすくしてみます。
『孫子とクラウゼヴィッツ』はおススメですよ～
さらに読むなら戦争論よりは孫子のほうが読みやすくて即戦的かな…
13/101

14. 目標
『戦略』とは
・目標への過程
・今の時点から目標までの道のりがある
・その道のりを進むためのものが「戦略」
・目標までの過程を逆算して
「戦術」を選択し、目標に到達する
まで、その場面場面ごとに適切な
戦術を選択をし続けていく
・目標は分割し戦略の修正を適宜行う
・目標にたどり着くまで紆余曲折はある
・線でイメージしてみよう 今現在
戦術を選択
戦術を選択
戦術を選択
戦術を選択
戦術を選択
戦術を選択
14/101

15. 目標
『戦術』とは
・戦略目標を達成するための方法や
手段を「戦術」とする
・戦術は戦略や今の状況でたくさん
考えられる。
どれだけ引き出しがあるかで変わる
・戦術はころころ変えられる。
戦略はそうは変わらない
・面でイメージしよう
・状況Aに対する戦術A-1
・状況Aに対する戦術A-2
・状況Bに対する戦術B-1
・状況Bに対する戦術B-2
状況A
状況B
15/101

16. 戦略と戦術を決めるときの判断
リソース
（人・物・金）
期間・時間
外的要因
（他社では…/今のトレンド）
内的要因
（社内のこの人/予算要因）
マネージャーによる「こうしたい意思」
戦術の結果が等価なら、より面白いほうにしたいよね、とか
一般的な
要因の大きさ
16/101

17. 戦略と戦術から見たプロダクトがたどる過程
・プロダクトの時期によってリソースは変わる。
・戦略は時期によってはあまり変わらない(変ったらなにか一大事になっている)
・プロダクトが進むにつれて予測できなかった問題が明らかになる
・それによって戦術を変える
・戦術結果が戦略目標に影響を与えることもある
17/101
リソース
・人 5人/練度高し
・物 いろいろある
・金 あまりない
・時間 割と適切
スタート!
できた!
人がひとり辞めた! 競合会社が先に出した!
急遽機能追加作業内容を削る
予算追加できた!
そのぶんでデバッグ 他チームの応援配属
目標
10位以内に入る
などなど

18. 聞いてみたい
・あなたの戦略とそれに使っている戦術を教えてください
・プロダクト以外でもかまいません。
同僚との付き合い方、会社との付き合い方、
女の子との付き合い方、お給料の増やし方、
生き方とか…
・○○がしたいので、これをやっている、という答えでぜひ。
18/101

19. うんうん…
「そんなんやってるよ！！」
19/101

20. そんなんやってるよ！！
いま言った戦略はうまくいってますか?
うまくいっていない？ じゃあ、なぜうまくいってないんですか?
20/101

21. プロダクトから見た失敗要因
▼最初の「座組」で失敗している
どのキーマンが何を担当するのか。それが明確になっているのか?
そもそも適切な人がアサインされていたのか。
▼真実を無視している。なんとかなると思っている。必ず起きる真実を無視している。
「おまえ、もしかしてまだ、このプロジェクトが死なないとでも思ってるんじゃないかね？」
▼判断ミス
正しい情報を得て、計測し、都度自分で適切なほうにジャッジすること。理由は何であれば、それで失敗することが多い
▼準備不足
最近見た話で「アニメは作画に入ったら巻き返し
は無理なんです」
孫子も兵站の重要性について説いている。
21/101

22. プロダクトから見た失敗要因
▼最初の座組で失敗
どのキーマンが何を担当するのかそれが
明確になっているのか?
そもそも適切な人がアサインされていたのか。
▼真実を無視している。なんとかなると思っている。必ず起きる真実を無視している。
「おまえ、もしかしてまだ、このプロジェクトが死なないとでも思ってるんじゃないかね？」
▼判断ミス
正しい情報を得て、計測し、都度自分で適切なほうにジャッジすること。理由は何であれば、それで失敗することが多い
▼準備不足
最近見た話しで「アニメは作画に入ったら巻き返しは無理なんです」。
孫子も平坦の重要性について説いている
22/101

23. プロダクトから見た失敗要因
▼真実を無視している
なんとかなると思っている。必ず起きる真実を無視して
いる。「おまえ、もしかしてまだ、このプロジェクトが死
なないとでも思ってるんじゃないかね？」
▼判断ミス
正しい情報を得て、計測し、都度自分で適切なほうにジャッジすること。理由は何であれば、それで失敗することが多い
▼準備不足
最近見た話しで「アニメは作画に入ったら巻き返しは無理なんです」。
孫子も平坦の重要性について説いている
▼最初の「座組」で失敗している
どのキーマンが何を担当するのか。それが明確になっているのか?
そもそも適切な人がアサインされていたのか。
23/101

24. プロダクトから見た失敗要因
▼準備不足
最近見た話しで「アニメは作画に入ったら巻き返しは無理なんです」。
孫子も平坦の重要性について説いている
▼最初の「座組」で失敗している
どのキーマンが何を担当するのか。それが明確になっているのか?
そもそも適切な人がアサインされていたのか。
▼真実を無視している。なんとかなると思っている。必ず起きる真実を無視している。
「おまえ、もしかしてまだ、このプロジェクトが死なないとでも思ってるんじゃないかね？」
▼判断ミス
正しい情報を得て、計測し、都度自分で適切な
ほうにジャッジすること
理由は何であれ、それで失敗することが多い。
24/101

25. プロダクトから見た失敗要因
いまのところこれしかプロダクトの
失敗理由が見当たらない
だいたいこの4つに還元できる
25/101

26. 浮き上がる真実
プロダクトが進むと噴出する『真実』はこうです
経験則です
26/101

27. 真実(1)
・放っておくと自分が死ぬ
27/101

28. 真実(1) 放っておくと自分が死ぬ
・プレイングマネージャによくあるパターン。
・ついつい、できない部下を抱えて仕事をため込み、
最後プロマネが死ぬ。
・そもそもプロダクトマネージャは「共感力」が高いと能力も高いと
判断されるので、よどんだプロジェクトでは、できるプロダクトマ
ネージャになるほどそれを吸い取ってしまい結果的に死ぬ
28/101

29. 真実(2)
放っておくと開発が死ぬ
29/101

30. 真実(2) 放っておくと開発が死ぬ
・完成間際でエンジニアが死ぬ
とかくいろいろ対応に忙殺されます。更新など自動化されていなくてエンジ
ニアの手を借りるような仕組みだと必ず破たんします。
・デザイナーの修正量が多くなるとこれまた死ぬ。
正確に「どういうものを作ってほしいのか」伝わっていないと作りなおしが多く
なり容易に死ぬ。
・いま持っている以上のスキルや能
力を引き出そうとすると、よく死ぬ。
大人数のユーザーが参加するアプリの経験がないとDB部分や通信でアプ
リが死ぬ。そもそもそうなる想像ができていない。誰かに教えを素直に乞え
るチームならまだいい。
30/101

31. 真実(3)
善意の改善によって死ぬ
31/101

32. 真実(3) 善意の改善によって死ぬ①
・えらい人の干渉
「これこうしたらもっとよくならない?」
「いまどきのアプリでこの機能を持っていないのは、ちょっと…」
「クオリティをあげていただきたいのですが?」
・開発現場の干渉
「このブランチの管理方法ではだめです」
「この方法に変えたらもっとよくなる
と思うんですが」
「いちいちめんどくさくて、この方法はやっていません」
「それをやるのなら、いまの方式は変えましょう」
「そこはチャレンジしたいです」
32/101

33. 真実(3) 善意の改善によって死ぬ②
そして肝心なところは誰も言わない
し改善されない
ご意見は諸刃の剣であるし、目標にかなうものは受け入れる。
ただやっぱり立場やそれを言ってきている人たちとの視点や目標
が違うので、なかなかにピントがずれる。
ちなみに有馬はよく同業他社で同じことやっている人の意見を
聞きに行ってる。あんまり外れがない。ありがたや、ありがたや。
33/101

34. 真実(4)
最初の座組で失敗したら
取り返せない
34/101

35. 真実(4) 最初の座組みで、もう…①
・だいたい最初から失敗している
スキル不足だったり、経験がなかったり。外部会社だと契約に縛
られて、「これは御社担当の範囲だから」というのがあると、その
外部会社で死ぬことがある。「こいつが悪い」で済めばいいけれど、
それではプロダクトは完成しない。
・どんな人が必要なのか？ どんな人が足りない
のか、それが明確ではない
必要な内容から逆算して欲しい人材を得る。社内だとこれこれ
こういう人で… と、だいたいアサインが決まることが多い。とした
ら、その人たちに足りないものを補えないと死ぬ。
35/101

36. 真実(4) 最初の座組みで、もう…②
庵野秀明監督
「私の考えですけど、監督は作品に関して人のせいにはできない。
脚本が悪かったというならば、やらなければいいと言うだけ。役者
が下手だったのなら、その役者でも作品が成り立つようにするの
が監督の仕事だというわけです。(略)少なくとも『あいつは最後
まで役が下手なままでした』というのは監督が悪い。役者が悪い
わけではないのです。」
http://diamond.jp/articles/-/1081101?page=4 よ
り
36/101

37. 真実(5) 人を増やしたら失敗する
人を増やしたら失敗する
37/101

38. 真実(5) 人を増やしたら失敗する
・「時間が足らないので人増やしてく
ださい」 ⇒素直に増やしてうまくいったためしがない。
たいがい「物量が必要なもの(アクセやカード)を作りたいけれど人
が足りない」「こういう難しい開発をこなす人がいない」「そもそも
それをやるべきかどうかわからない」といった現場が混乱している
だけのパターンになっている。
・人を増やすと、その人の教育をするのに1週間、0.5人月ぐら
い取られる。複雑ならその倍にも3倍にもなる。とすると時間短
縮のために人を入れたのに、全体では時間があまり短縮されな
い、という現象もよくおこる
38/101

39. 真実(6)
外的要因による変更はいつか来る
39/101

40. 真実(6) 外的要因による変更
・同業他社と同じ機能が必須だ。
でもリリース時期は変えたらダメ。
・会社が傾いたので予算カット、人員カットね
・プラットホームへの申請が増えて、この機能はダメになりました
・ユーザーから評判良くないのでこの機能は外して、でもこの機能が
要望も多くてこれは盛り込みたいのですが…
・経営陣が変わったら予算承認が
下りなくてですね…
・この人使ってくれないと困るんですよ…
40/101

41. 真実(7)
モチベーションは必ず下がる
41/101

42. 真実(7) モチベーションは必ず下がる
・最初はいいんだけど最後は修羅場
よく見る。すごくよく見る。いろいろ理由はあれど、マネジメントが失敗してる
ことが多い。
・「チームは仲良く」の失敗
立川談志師匠が言ってました。「人間関係とは良い誤解か、悪い誤解」
・人間だもの相性とかはある。
そもそもプロマネ自身でチーム内の全員を愛しているのか?
・チームのモチベーションが下がって
いるときは、いろいろな信号がでて
いる。不安や不信などなど…。
42/101

43. 真実(7) モチベーションは必ず下がる
「他人のモチベーションを上げられない人間が
自分のモチベーションを上げられるのかい?」
(某スケートアニメより)
43/101

44. 真実(8)
人材はいつか流出する
44/101

45. 真実(8) 人材はいつか流失する①
・人の管理の失敗
管理はよく放置される。
管理に失敗すると人は去っていく
・結婚しちゃいました。実家から帰ってこいと言われて…
どんなに手厚くしていても、事情により離れることはある。
・社内力学で人が取れられたりする
ちょっとでもプロジェクトがうまくいっ
てないと 「ひとさらい」 が発生する
45/101

46. 真実(8) 人材はいつか流失する②
・良い人ほど管理が難しい
良い人ほど、適切な良い仕事と環境を与え、日々感謝してい
ることを伝えて、何かあれば「私が助ける」という信頼感を与え続
けないといけない。
・そもそも楽しくないと人は逃げてく
だってほかにも働き口はあるし… 君のプロジェクトでなくてもいい
んだよ…
46/101

47. 真実(9)
特有の目標達成要素がある
47/101

48. 真実(9) 特有の目標達成要素がある
・どうしてもこの人がいないと成り立
たない、売り上げ上がらない、が、ある
・プラットホーム申請など、特有な作業などがある。
・ゲーム開発はやはり属人性が高い。
一部の人だけが持つ「センス」で支えられるものが多くある。
・そういう人が居続けられないとプロダクトが失敗する、というのもある
これらを無視するとだいたい失敗す
る。そして軽視されることが多い。
48/101

49. 真実(10)
どんどん管理は煩雑になる
49/101

50. 真実(10) どんどん管理は煩雑になる
・仕様書、チケット、納品物の提出… 管理量を超える
・ただでさえ多いのに人の管理がそ
こに入る
「A君とB君が、触ってはいけないJ文式土器を…」
・増えるバグや修正の量
結果的にコントロールされていない
とクオリティが下がったり動かないも
のができる
50/101

51. 聞いてみたい
・あなたが経験したプロダクトの真実を教えてく
ださい。
・何もなかったとは言わせませんよ(笑)
51/101

52. たぶん他にも…
・増えるしがらみ
誰それさんに紹介されたのでこの会社は使わないといけない…などなど
・適切なクオリティチェックがされない
デバッグ会社を通せない、開発側に意識がない…
・ドミノが倒れない
開発側の手が止まってる→仕様書が来ない→企画の仕事量が多くて手が回らない
・堂々巡り
開発側の手が止まってる→仕様書が来ない→開発と相談待ち→仕様書作れない…
・目的が明確でない
俺たちは何のためにこれを作っているんだ…
52/101

53. 分類すると…
ここで真実を分析してみて、
どんな現象が起きているのか整理してみよう。
53/101

54. プロダクトの開発が進むとどうなるのか?
・プロダクトの開発が進むにつれて、
予算、人、時間、物は予想よりも足りなくなる
・プロダクトの開発が進むにつれて、
作業量、管理対象、しがらみ、判断しないと
いけないことは予想よりも増えていく
・プロダクトの開発が進むにつれて、
開発内容や目標がブレていくように錯覚する
54/101

55. 金
リソースの相関関係
・時間は、
人の量や人の質、
求める作品の質によって
足りなくなる
時間
人
質
55/101

56. リソースの相関関係
・人は、
マネジメントの不手際、
求める作品の質によって
足りなくなる
金
時間
人
質
56/101

57. リソースの相関関係
金は、
時間と、
人の量/人の質と
求める質に
比例してなくなる
金
時間
人
質
57/101

58. リソースの相関関係
クオリティ(作品の質)は、
時間と、
人（数より質）、
お金、
作業量の積算で
得られる
金
時間
人
質
58/101

59. ということは？
・プロダクトには等しく同様にこれらの問題が存在する。
・成功したプロダクトとは、これらを乗り越えたものであり、
失敗したプロダクトはこれらを何らかの理由をつけて対策
しなかったものである。
・プロダクトオーナーはこれらを解決するように心がけ、その
プロダクトを少しでも成功へ導くように日々を使う
59/101

60. じゃどうしたらいいの？
・まあいろいろあんだけどねえー
・そもそもプロマネ自体が特殊な職種だし、
ぶっちゃけセンスや才能のあるなしとかも
戦略と戦術のフレームワークを
使ってなんとかしてみよう
60/101

61. フレームワークとは？
・柔道とかの型、Unityとかのプログラミングフレームワークとか
・SWOT分析とか、考具とか、GROWモデルとか…
・仕組みや手順がまとまっている方法、手順。
・「穴埋め問題的なものがあり、そこに答えをいくつか埋めたら、
なんか解決が自動的に図れるよ」という道具とでも思ってもらえたら。
・フレームワークのよいところは、「楽ができる」ということ。
「解決するベストな方法を網羅的に考える」
「解決方法を考えるための時間」を削減できるのがメリット
61/101

62. 戦略と戦術のフレームワーク：概要①
目標
今現在
・目標を明確にする。
何を成したら成功とみなさせるのか
・チェックポイントを置く
・そのチェックポイントでの目標、
プロダクトの目標から逆算して
明確に決める
明確化
● チェックポイント
● チェックポイント
62/101

63. 戦略と戦術のフレームワーク：概要②
目標・そのチェックポイントへの
目標に対する戦術を並べる
・戦術をリソースや状況に応じて、
チェックポイントへの目標から
逆算して取捨選択する
・次に取る戦術を取捨選択する
・これをプロダクト完成まで繰り返す
〇：状況Aに対する戦術A-1
〇：状況Cに対する戦術B-1
チェックポイント
選択
×：状況Aに対する戦術A-2
繰り返す
63/101

64. ・
フレームワーク：目標の決め方
達成しなければならないもの
└会社的目標、プロジェクトチーム的目標、自分的目標。それぞれ違う
人、金、物、時間、に照らし合わせて
検討すると、あんまりブレない。
・達成しなくてもいいものを選択する
× ： 時間があふれてもいいものを作ろう
〇 ： 予算内にそこそこのものを作ろう。あとは運営しながらよくしていく。
・達成しないとならないものを掘り下げる
売り上げ、物量、人材育成
└それを開発する人数、費用、裏付け
└どういうスキルがいる？ 誰が必要？ 採算分岐ラインは？
64/101

65. フレームワーク：開発スタート前の決定事
要 素 内 容
人 （誰が担当？ スキルは？）
金 （予算・毎月かかる費用目測）
物 （開発機材・ツール、ＰＪでの開発ルール）
時間 （開発期間）
戦術を組み立てるに、どのような決定が必要？
リソース
（人・物・金）
期間・時間
まずこれ
ほんこれ
65/101

66. フレームワーク：開発スタート前の決定事
マネジメントにかかわらない場合、
リソースと時間がきまってない
状態からJOINに誘われたら、
脱兎のごとく逃げましょう
66/101

67. フレームワーク：開発スタート前の決定事
最初の戦術
チーム内向け チーム外向け
真実「 」が「 」にあるので、
いま「 」をする
真実「 」が「 」にあるので、
いま「 」をする10個書く 10個書く
チェック期間
いつ頃までに何をやる?
次のチェックポイントの目標
・何を知りたい？
・何ができていれば目標に近づく？
目標に沿わせる
67/101

68. フレームワーク：開発スタート前の決定事
チェックポイント
取りうる戦略
真実「 」が「 」にあるので、いま「 」をする
10個書く
次のチェックポイントの目標
・何を知りたい？
・何ができていれば目標に近づく？
・周囲の状況は?
目標に沿わせる
68/101

69. ・
・
有馬さんの場合①
目 標
チーム目標
・いままでのタイトルのお客さんがスマホでも満足できるようにする
・クオリティを会社がいままで出したものより高くする
・月次1億を目指す。
そのためのクオリティ、サーバが落ちないなどを保証する
個人目標
・プロダクト自体の管理作業を行わない
69/101

70. 有馬さんの場合②
リソース
要 素 内 容
人 エンジニアは優れた人 + 新人
金 あまりない（具体的な金額は把握しておく）
物 すでにいろいろあるのでこれを活用
時間 さほどないけれど交渉次第
ざっくりでもいいので、戦略建てに必要なリソースを把握する
70/101

71. ・・
・・・・・・・・・・・・・・・・・・・・
・
有馬さんの場合③
最初の戦術
戦術1 質の高いエンジニア/デザイナーで爆速の開発力を持つ
何があってもすぐ修正できるようにする
戦術2 ちょくちょく話を聞く。社内外ともに。
それで軌道修正していくことをあらかじめ確認する
戦術3 いろいろな人が心配しだすので1週間内で
状況を報告していく。ところどころで社内テストしてもらう
取りうる戦略
71/101

72. 有馬さんの場合④
チェックポイント
・・
・・・・・・・・・・・・・・・・・・・・
戦術a-1 目標に叶うデザイナーの確保。
うちのひとほか。たまたま元同僚を捕まえられた
戦術a-2 デザイナーを説得、または期間を取れるように工作
いろいろ見せた 「このUIひどいですけど…」
・・
・・・・・・・・・・・・・・・・・・・・
戦術a-1 有馬さんの時間をそちらにふやした
戦術a-2 開発側も対戦するようにした→時間がとれない→じゃあ時間決めてやろう
試した 「プレイヤー人数増やすと挙動が不安定」
72/101

73. 目 標
有馬さんのよくなかった場合①
・
・
チーム目標
・プロダクトを世に出すこと
・予算内に出してもうけること
個人目標
・クオリティをなんとかしたい。
73/101

74. リソース
有馬さんのよくなかった場合②
要 素 内 容
人 求められている状態としては厳しい
これは厳しいと思う人が何人かいる
金 ない。予算枠がある。
契約の不備で身銭切るところも
物 これからほとんど１から作る
時間 変更不可
74/101

75. 有馬さんのよくなかった場合③
最初の戦術
・・
・・・・・・・・・・・・・・・・・・・・
・
戦術1 人が良くない→よそからひっぱれない?→だめだった
戦術2 人が良くない→なんとかなだめすかして、
望みの方向にもっていくよように→時間かかった
戦術3 目標が曖昧→この時期にはこうする
というのを明確にした。チェックポイントの創出
取りうる戦略
75/101

76. 有馬さんのよくなかった場合④
チェックポイント
・・・いろいろあって死んだ
「クオリティが低い」と言われる
・・
・・・・・・・・・・・・・・・・・・・・
戦術1 どうにもならんので有馬の方で修正
→それようの時間を作る→いろいろ失敗
戦術2 作り直しが予想される→先方の上司の好みを
聞きながら対処した。
担当希望と合わせて考えて提案出した
76/101

77. 聞かせてください
このフレームワークを想像しながら考えてみてください
・利用したうえで何か解決できそうな問題はありますか?
・それは目標から逆算できていますか?
77/101

78. 戦略と戦術でよくある質問
よく聞かれたことをまとめておきます。
78/101

79. どんな戦術を取るべきですか？①
・ リソースと戦略から戦術を選択する
・ 戦術は人、物、金、時間のどれかのパラメータを
増減させることに還元できる
・ その戦術と戦略目標に関係性があるのなら、
取るべきだ
・ その戦術と戦略目標に関係性がないのなら、
排除していい
79/101

80. どんな戦術を取るべきですか？②
・A案は人-10、金+10となる。B案は物+10、時間-10となる。
・目標が「クオリティが高いもの」であれば、B案を取る。
⇒Ｂ案採択：時間が犠牲となるので、そこは交渉する。
・一方目標が「期間内で予算内に」ということであれば、A案となる。
・そうすると作業人員が足りなくなる。
⇒Ａ案採択：開発内容を整理、作るものを抑えるよう交渉
80/101

81. どんな戦術を取るべきですか？②
すべてがそう簡単な話ではないけれど…
判断の失敗の理由を検討する
⇒目標が手札によってブレる
⇒目標へのものさしを固定する
⇒「人、物、金、時間」が目標にあっているか？
人、金、物、時間、に照らし合わせて
検討すると、あんまりブレない。
『フレームワーク：目標の決め方』より
81/101

82. 戦術をどう増やしていくのか?①
・どんな戦術が足りないのかリソース(人、物、金、
時間)から考える
・また内部(チーム内)/外部(えらい人、会社情
勢)ごとに考える
82/101

83. 戦術をどう増やしていくのか?①
偉い人のクオリティチェックがありそうだ ⇒ 「外部/物」に当てはめる
・「外部/物」×時間 = なるべく早いうちにコアとなるところを見せておこう。
・「外部/物」×人 = 偉い人に対抗できる味方をつけよう
・「外部/物」×金 = できるだけ実行予算を少なく回しておこう。別プロ
ジェクトで実績を出しておこう。そうすると印象がいいはずだ。
・「外部/物」×物 = なんか買ってきた方が早いんじゃないか。早く作れ
る方法はなにか製品としてないのか?
と組み合わせて考えてみると広げられる。
あとは経験者に聞いていくとかして、戦術を広げておく。
83/101

84. 有馬さん的戦術例①
「有馬さんが死なないようにする」
有馬さんはほっとくと死ぬよ！
なるべく管理する「方法」を用いない。
そのためにはどうすればいいのかを考えている
そもそもガントチャートって何の目的で使ってる?
遅れは出ていることがわかっても、あんまり意味がないかもよ?
いつまでに何を、というのを明確にし、そこで出てきたもので判
断する、としている。
84/101

85. 有馬さん的戦術例①
「有馬さんが死なないようにする」
有馬さんはほっとくと死ぬよ！
上方向の対処
礼儀正しく仲良くする。信任を得る。正しい報告をする。
いざとなったら助けてもらえるように、
お付き合いさせていただいています。
参考 『日本のいちばん長い日』
85/101

86. 有馬さん的戦術例①
「有馬さんが死なないようにする」
有馬さんはほっとくと死ぬよ！
チーム下方向の対処
兵種を見極める。開発に対するスピード感を知っておく。
何がその人にとっての価値なのか知っておく。
権限や担当を渡す。どんどん自分の仕事を「助けてもらう」
これが面白い、というのをまとめる。 絵コンテにしたり、対象作品につ
いて語ったり。
常に社内社外にアンテナを張っておき、何かあれば自分のチームに入
れられるようにしておく(リファラル採用のプロマネでできる版)
86/101

87. 有馬さん的戦術例②
「億劫にならないシステム」
エンジニアが死んでもいいようにしよう！
・UI変更などデザイナーだけで対応
・ガチャの入れ替えなどプランナーだけで対応
・ビルドを自動配布して誰でも見られるようにしておく
・wikiに書いときなー 書いときなー
87/101

88. 有馬さん的戦術例③
「壮絶な開発スピードを得る」
・何があっても「まあ作り直せばいいよね」と言える環境にする
1機能1日で作ったものなら、まあしょうがないと言えるけれど、1か月もかかる
となかなか捨てがらない。としたら爆速で機能を作って捨てる、というイメージ
ができないとつらい
・すべてがそのクオリティにできないとしたら、それを目玉な部分で達成できる
ように、リソースを集中させる
質のいいスタッフを取りそろえる
それを常に目指す
88/101

89. 有馬さん的戦術例③
「質のよさとは何か？ その基準」
基準となるラインを有馬さん的に過去事例をベースに決めていて、それが
よくなければチェンジするか、フォローしたり補完できる人を入れる
どうにもならなかったら作らないといけないものを減らす。楽しさは変えない。
その時の戦略で基準は変わる
基準は自分で持っておく
89/101

90. 聞かせてください
・あなたの戦術はなんですか?
・それはどんな目標があるときに使っていますか?
・それは達成できましたか?
90/101

91. どうやって評価する？
・戦略修正、戦術変更をプロダクト開発が終わるまで
常に続けていくことになる
・そのために事あるごとに「目標へのずれの確認」
「それはなぜ起きたのか」「それを修正する行動」を
繰り返すことになる
戦略修正に対して
戦術修正に対して
OODAで評価
PDCAで評価
91/101

92. OODAとは？
・監視：Observe
敵を発見、確認
・情報判断：Orient
監視段階で収集した情報か
ら今どんな状態なのか判断
・意思決定：Decide
情勢判断段階での状態から、
対抗策を決定する
・行動：Act
意思決定段階で決められた
対抗策を施行する
これを繰り返す。
サーチ＆デストロイという感じ
92/101

93. OODAと戦略
と、「戦術を決める」ためにこんなループにしてみる
行動：Act
戦術の実施。開発メン
バーに危機感や感情と
ともにやることを共有し
て行動を実施させる
監視：Observe
外部内部的に変更は
ないか、プロジェクトは
目標に向かって進めら
れるか確認。それぞれ
の人間へのヒアリング
や成果物で確認する
情報判断：Orient
開発が遅れていたとし
たら過去の状況からど
れぐらいかかりそうか見
積もる。また、どれぐら
いプロジェクトに影響が
あるのか検討する。
意思決定：Decide
取りうる戦術を検討し
決定する
各チェックポイントごとで判断
93/101

94. PDCAとは？
・計画：Plan
これまでの実績などから計画
を作成し、決定する
・実施・実行：Do
計画内容に従ってそれを実
行する
・点検・評価：Check
実行した内容が計画したとき
の予想とずれているかどうかを
確認する
・処置・改善：Act
点検・評価によって得られた
よくないところを改善する これを繰り返す。
94/101

95. PDCAと戦術①
各戦術ごとで判断
計画：Plan
その戦術の具体的な内容を、戦略目標から決める
(戦略目標:この日までに作りたい→チーム開発力を高めたい
→勉強会をする)
実施・実行：Do
勉強会してみた
点検・評価：Check
実行した内容を評価する。このときはあくまで戦略目標と照らし合わせて評価する
例)
勉強会には10人ぐらい来て、和気あいあいとして楽しかった。Aさんの違う一面を見られた…×
チーム開発力を高めるためには、開発能力がない人に参加してもらいたかったが出てきてくれな
かった。そもそもチーム開発力ってなんだ?…〇
95/101

96. PDCAと戦術①
各戦術ごとで判断
・処置・改善: Act
評価で得られた問題点を検討する
チーム開発力って何？ …言われたことを期日通りにやる、としてみる
なぜいまそれができない？ …開発者の中にできる人が少ない
チーム開発力を高めるためには？ …できる人を多くする
勉強会は何のためにやった？ …できる人を多くするため
勉強会の結果は？ …増えなかった
勉強会のほかに方法は?
…できる人と入れ替える。 …できない人をできる人に教育してもらう、
…本当にそうなのかテストケースを走らせて計測 …などなど。あれ勉強会じゃなくてもいい？
と、「戦術の実行結果をよくする」ために、こんなサイクルにしてみる
だいたいActで深堀すると、ひとつの戦術の話が複数になることもよくある
96/101

97. 戦略と戦術から見たよりよいプロダクトオーナー
人は戦術(=ノウハウや方法)ばかり語りたがるし、使い
たがる。実はそれは些細なことなんだ。
混乱してるのなら一度戦術的な話を聞かずに、すべて
忘れてみよう。
97/101

98. 戦略と戦術から見たよりよいプロダクトオーナー
実際に重要なのは「いかに目標へ近づけるために自分
で判断して、その方法を選択したか」という戦略になる
んだ。
どうか戦略を立てて、未来を予測して今を逆算し、いろ
いろな戦術を使って、戦ってほしい
98/101

99. 戦略と戦術から見たよりよいプロダクトオーナー
お仕事を一緒にした役員から聞いた言葉
「プロジェクトなんていろいろあるこ
となんだから、それ自体を不安がっ
たりしてはいけないよ。一番肝要
なのは、それをどう対処していくか、
そのことだけなんだ」
99/101

100. 質疑応答
何でもは答えられません。知っていることだけ
100/101

101. 宿題
・何かの目標があり、それを逆算していまこれをやる、というクセ
をつけてみよう
・かつて自分たちが参加したプロジェクトがどうなったのか
考えてみよう。どういうことが起きたのか、時間、リソース、人、
金の4つのカテゴリで3つ以上出してみよう
・それをもとに「そうならないようにどうしたらいいのか?」という
戦術を考えてみよう
・あるプロダクトを作れと言われたとき、いまあるリソースで、
考えてみた戦術をどう適用するの考えてみよう。
101/101