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

プロダクトオーナーが成功のために

考えるべき戦略と戦術ゲーム開発事例からプロジェクトを

少しでも成功へ導く思考方法

2016/11/26有馬 もと

今日はこの会です 2/101

自己紹介

有馬さん・ゲーム開発歴 25 年 ! ( どこぞの平面カエルの教師みたいだ… )

・プログラマなんだけど、なんでも屋。プレイングマネージャとして開発したり企画したり外部交渉したりシナリオ書いたり売り上げの絵図を書いたり…

・チームマネジメントはいろいろたくさん。なんか任される。えらそう。

・古い人だと『遊びのレシピ』という本を書いた人だとわかりやすい ?

3/101

　スクラムはもうだめぽよ !

新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう !

というスライドが賛否両論になった

自己紹介 4/101

自己紹介

有馬さん・家族はゲームプランナーなうちの人と我が息子( 猫 )

・目黒区在住

・好きな本は CJ チェリィの『サイティーン』

5/101

今日のお話

今日は、戦略と戦術とプロダクトオーナーについて話すっ

ぽい ?

6/101

今日のお話 7/101

聞いてみたい

今日あなたがこのセミナーを聴いて、いまの問題にどう役立てたいのか教えてください。

解決方法を知りたいのか…　それともトレーニング方法を知りたいのか…　あるいは慰めてほしいのか…

それによっては講演内容を変更します。

8/101

今日のお話▼ 戦略と戦術とプロダクト運営初めてプロダクトを持ったり、あまり上手くいかないオーナーに向けて、「戦略と戦術」をキーワードにプロダクト運営とはなんじゃらほい ? 　というのをひも解いてみる。

▼ 戦略と戦術のフレームワークプロダクトを持ったとき、「戦略と戦術」をフレームワークとして利用することを考えてみると、プロダクトのいまが整理しやすくなり、成功へと近づけることができる ( はずだ ) 。わりと目標から逆算して今やることを決めたり、やらないことを決め

られる人が少ないと聞くので、そのあたりを説明する。ゲーム系プロダクトではない人もいるようなので、あんまりゲーム的な内容によらないようにしてみた。何か物を作るプロダクトでの問題、とでもしてもらえたら。

9/101

今日のお話▼ 戦略と戦術とプロダクト運営初めてプロダクトを持ったり、あまりうまくいかないオーナーに向けて、「戦略と戦術」をキーワードにプロダクト運営とはなんじゃらほい ? 　というのをひも解いてみる。

▼ 戦略と戦術のフレームワークプロダクトを持ったとき、「戦略と戦術」をフレームワークとして利用することを考えてみると、プロダクトのいまが整理しやすくなり、成功へと近づけることができる ( はずだ ) 。

わりと目標から逆算して今やることを決めたり、やらないことを決められる人が少ないと聞くので、そのあたりを説明する。ゲーム系プロダクトではない人もいるようなので、あんまりゲーム的な内容によらないようにしてみた。何か物を作るプロダクトでの問題、とでもしてもらえたら。

10/101

「戦略」と「戦術」って何？

「戦術とは戦闘における戦闘力の使用に関する規範であり、戦略とは戦争の目的を達成するための戦闘の使用に関する規範である」

「この狭義の兵学はまた再び戦術と戦略とに区分される。前者は個々の戦闘の形態を論じ、後者はそれらの行使を論じる」

「戦争におけるロジスティクスや経済面はそれ自体が自律的に対応することを想定しており、クラウゼヴィッツが戦略の対象とは考えていない。 ( 略 ) 今日のような科学技術が進歩し、燃料、食料、武器、弾薬の供給が、兵士それぞれの詮議と同じぐらい重要になっている時代においては、より危険度が増しているのである。このような観点から言えば、孫武の論じ方、見立ての方がより戦略と戦争を包括的に論じているのであり ( 略 ) 」

11/101

「戦略」と「戦術」って何？

… わけわかんなあい～

12/101

「戦略」と「戦術」って何？

ちょっとわかりやすくしてみます。

『孫子とクラウゼヴィッツ』はおススメですよ～さらに読むなら戦争論よりは孫子のほうが読みやすくて即戦的かな…

13/101

目標

『戦略』とは

・目標への過程

・今の時点から目標までの道のりがある

・その道のりを進むためのものが「戦略」

・目標までの過程を逆算して　「戦術」を選択し、目標に到達する　まで、その場面場面ごとに適切な　戦術を選択をし続けていく

・目標は分割し戦略の修正を適宜行う

・目標にたどり着くまで紆余曲折はある

・線でイメージしてみよう

今現在

戦術を選択

戦術を選択

戦術を選択

戦術を選択

戦術を選択

戦術を選択

14/101

目標

『戦術』とは

・戦略目標を達成するための方法や　手段を「戦術」とする

・戦術は戦略や今の状況でたくさん　考えられる。　どれだけ引き出しがあるかで変わる

・戦術はころころ変えられる。　戦略はそうは変わらない

・面でイメージしよう

・状況 A に対する戦術 A-1・状況 A に対する戦術 A-2

・状況 B に対する戦術 B-1・状況 B に対する戦術 B-2

状況 A

状況 B

15/101

戦略と戦術を決めるときの判断

リソース（人・物・金）

期間・時間

外的要因（他社では… / 今のトレン

ド）

内的要因（社内のこの人 /予算要

因）

マネージャーによる「こうしたい意思」戦術の結果が等価なら、より面白いほうにしたいよね、

とか

一般的な要因の大き

さ

16/101

戦略と戦術から見たプロダクトがたどる過程

・プロダクトの時期によってリソースは変わる。・戦略は時期によってはあまり変わらない ( 変ったらなにか一大事になっている )・プロダクトが進むにつれて予測できなかった問題が明らかになる・それによって戦術を変える・戦術結果が戦略目標に影響を与えることもある

17/101リソース

・人 5 人 /練度高し

・物　いろいろある

・金　あまりない

・時間　割と適切スタート !

できた !人がひとり辞めた !

競合会社が先に出した !

　　急遽機能追加作業内容を削る

予算追加できた !

そのぶんでデバッグ

他チームの応援配属

目標

10位以内に入る

などなど

聞いてみたい

・あなたの戦略とそれに使っている戦術を教えてください

・プロダクト以外でもかまいません。　同僚との付き合い方、会社との付き合い方、　女の子との付き合い方、お給料の増やし方、　生き方とか…

・○○がしたいので、これをやっている、という答えでぜひ。

18/101

うんうん…

「そんなんやってるよ！！」

19/101

そんなんやってるよ！！

いま言った戦略はうまくいってますか ?うまくいっていない？　じゃあ、なぜうまくいって

ないんですか ?

20/101

プロダクトから見た失敗要因

▼最初の「座組」で失敗している　　どのキーマンが何を担当するのか。それが明確になっているのか ?　　そもそも適切な人がアサインされていたのか。

▼真実を無視している。なんとかなると思っている。必ず起きる真実を無視している。　　「おまえ、もしかしてまだ、このプロジェクトが死なないとでも思ってるんじゃないかね？」

▼判断ミス　　正しい情報を得て、計測し、都度自分で適切なほうにジャッジすること。理由は何であれば、それで失敗することが多い

▼準備不足最近見た話で「アニメは作画に入ったら巻き返しは無理なんです」孫子も兵站の重要性について説いている。

21/101

プロダクトから見た失敗要因

▼最初の座組で失敗どのキーマンが何を担当するのかそれが明確になっているのか ?そもそも適切な人がアサインされていたのか。▼真実を無視している。なんとかなると思っている。必ず起きる真実を無視している。　　「おまえ、もしかしてまだ、このプロジェクトが死なないとでも思ってるんじゃないかね？」

▼判断ミス　　正しい情報を得て、計測し、都度自分で適切なほうにジャッジすること。理由は何であれば、それで失敗することが多い

▼準備不足　　最近見た話しで「アニメは作画に入ったら巻き返しは無理なんです」。　　孫子も平坦の重要性について説いている

22/101

プロダクトから見た失敗要因

▼真実を無視している

なんとかなると思っている。必ず起きる真実を無視している。「おまえ、もしかしてまだ、このプロジェクトが死なないとでも思ってるんじゃないかね？」▼判断ミス　　正しい情報を得て、計測し、都度自分で適切なほうにジャッジすること。理由は何であれば、それで失敗することが多い

▼準備不足　　最近見た話しで「アニメは作画に入ったら巻き返しは無理なんです」。　　孫子も平坦の重要性について説いている

▼最初の「座組」で失敗している　　どのキーマンが何を担当するのか。それが明確になっているのか ?　　そもそも適切な人がアサインされていたのか。

23/101

プロダクトから見た失敗要因▼準備不足　　最近見た話しで「アニメは作画に入ったら巻き返しは無理なんです」。　　孫子も平坦の重要性について説いている

▼最初の「座組」で失敗している　　どのキーマンが何を担当するのか。それが明確になっているのか ?　　そもそも適切な人がアサインされていたのか。

▼真実を無視している。なんとかなると思っている。必ず起きる真実を無視している。　　「おまえ、もしかしてまだ、このプロジェクトが死なないとでも思ってるんじゃないかね？」

▼判断ミス正しい情報を得て、計測し、都度自分で適切なほうにジャッジすること理由は何であれ、それで失敗することが多い。

24/101

プロダクトから見た失敗要因

いまのところこれしかプロダクトの失敗理由が見当たらない

だいたいこの 4 つに還元できる

25/101

浮き上がる真実

プロダクトが進むと噴出する『真実』はこうです

経験則です

26/101

真実 (1) 　

・放っておくと自分が死ぬ

27/101

真実 (1) 　放っておくと自分が死ぬ

・プレイングマネージャによくあるパターン。

・ついつい、できない部下を抱えて仕事をため込み、　最後プロマネが死ぬ。

・そもそもプロダクトマネージャは「共感力」が高いと能力も高いと判断されるので、よどんだプロジェクトでは、できるプロダクトマネージャになるほどそれを吸い取ってしまい結果的に死ぬ

28/101

真実 (2) 　

放っておくと開発が死ぬ

29/101

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

・完成間際でエンジニアが死ぬとかくいろいろ対応に忙殺されます。更新など自動化されていなくてエンジニアの手を借りるような仕組みだと必ず破たんします。

・デザイナーの修正量が多くなるとこれまた死ぬ。正確に「どういうものを作ってほしいのか」伝わっていないと作りなおしが多くなり容易に死ぬ。

・いま持っている以上のスキルや能力を引き出そうとすると、よく死ぬ。大人数のユーザーが参加するアプリの経験がないと DB 部分や通信でアプリが死ぬ。そもそもそうなる想像ができていない。誰かに教えを素直に乞えるチームならまだいい。

30/101

真実 (3) 　

善意の改善によって死ぬ

31/101

真実 (3) 　善意の改善によって死ぬ①・えらい人の干渉

「これこうしたらもっとよくならない ? 」　「いまどきのアプリでこの機能を持っていないのは、ちょっと…」　「クオリティをあげていただきたいのですが ? 」

・開発現場の干渉　「このブランチの管理方法ではだめです」

「この方法に変えたらもっとよくなると思うんですが」　「いちいちめんどくさくて、この方法はやっていません」　「それをやるのなら、いまの方式は変えましょう」　「そこはチャレンジしたいです」

32/101

真実 (3) 　善意の改善によって死ぬ②

そして肝心なところは誰も言わないし改善されないご意見は諸刃の剣であるし、目標にかなうものは受け入れる。ただやっぱり立場やそれを言ってきている人たちとの視点や目標が違うので、なかなかにピントがずれる。

ちなみに有馬はよく同業他社で同じことやっている人の意見を聞きに行ってる。あんまり外れがない。ありがたや、ありがたや。

33/101

真実 (4)

最初の座組で失敗したら取り返せない

34/101

真実 (4) 　最初の座組みで、もう…①

・だいたい最初から失敗しているスキル不足だったり、経験がなかったり。外部会社だと契約に縛られて、「これは御社担当の範囲だから」というのがあると、その外部会社で死ぬことがある。「こいつが悪い」で済めばいいけれど、それではプロダクトは完成しない。

・どんな人が必要なのか？　どんな人が足りないのか、それが明確ではない必要な内容から逆算して欲しい人材を得る。社内だとこれこれこういう人で…　と、だいたいアサインが決まることが多い。としたら、その人たちに足りないものを補えないと死ぬ。

35/101

真実 (4) 　最初の座組みで、もう…②

庵野秀明監督

「私の考えですけど、監督は作品に関して人のせいにはできない。脚本が悪かったというならば、やらなければいいと言うだけ。役者が下手だったのなら、その役者でも作品が成り立つようにするのが監督の仕事だというわけです。 ( 略 ) 少なくとも『あいつは最後まで役が下手なままでした』というのは監督が悪い。役者が悪いわけではないのです。」

http://diamond.jp/articles/-/1081101?page=4 より

36/101

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

人を増やしたら失敗する

37/101

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

・「時間が足らないので人増やしてください」　⇒素直に増やしてうまくいったためしがない。

たいがい「物量が必要なもの (アクセやカード ) を作りたいけれど人が足りない」「こういう難しい開発をこなす人がいない」「そもそもそれをやるべきかどうかわからない」といった現場が混乱しているだけのパターンになっている。

・人を増やすと、その人の教育をするのに 1週間、 0.5 人月ぐらい取られる。複雑ならその倍にも 3倍にもなる。とすると時間短縮のために人を入れたのに、全体では時間があまり短縮されない、という現象もよくおこる

38/101

真実 (6) 　

外的要因による変更はいつか来る

39/101

真実 (6) 　外的要因による変更

・同業他社と同じ機能が必須だ。でもリリース時期は変えたらダメ。・会社が傾いたので予算カット、人員カットね・プラットホームへの申請が増えて、この機能はダメになりました・ユーザーから評判良くないのでこの機能は外して、でもこの機能が　要望も多くてこれは盛り込みたいのですが…

・経営陣が変わったら予算承認が下りなくてですね…・この人使ってくれないと困るんですよ…

40/101

真実 (7) 　

モチベーションは必ず下がる

41/101

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

・最初はいいんだけど最後は修羅場よく見る。すごくよく見る。いろいろ理由はあれど、マネジメントが失敗してることが多い。

・「チームは仲良く」の失敗立川談志師匠が言ってました。「人間関係とは良い誤解か、悪い誤解」

・人間だもの相性とかはある。そもそもプロマネ自身でチーム内の全員を愛しているのか ?

・チームのモチベーションが下がっているときは、いろいろな信号がでている。不安や不信などなど…。

42/101

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

「他人のモチベーションを上げられない人間が　　自分のモチベーションを上げられるのかい ? 」

(某スケートアニメより )

43/101

真実 (8)

人材はいつか流出する

44/101

真実 (8) 　人材はいつか流失する①

・人の管理の失敗管理はよく放置される。

管理に失敗すると人は去っていく・結婚しちゃいました。実家から帰ってこいと言われて…どんなに手厚くしていても、事情により離れることはある。

・社内力学で人が取れられたりする

ちょっとでもプロジェクトがうまくいってないと　「ひとさらい」　が発生する

45/101

真実 (8) 　人材はいつか流失する②

・良い人ほど管理が難しい良い人ほど、適切な良い仕事と環境を与え、日々感謝していることを伝えて、何かあれば「私が助ける」という信頼感を与え続けないといけない。

・そもそも楽しくないと人は逃げてくだってほかにも働き口はあるし…　君のプロジェクトでなくてもいいんだよ…

46/101

真実 (9) 　

特有の目標達成要素がある

47/101

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

・どうしてもこの人がいないと成り立たない、売り上げ上がらない、が、ある

・プラットホーム申請など、特有な作業などがある。

・ゲーム開発はやはり属人性が高い。一部の人だけが持つ「センス」で支えられるものが多くある。

・そういう人が居続けられないとプロダクトが失敗する、というのもある

これらを無視するとだいたい失敗する。そして軽視されることが多い。

48/101

真実 (10) 　

どんどん管理は煩雑になる

49/101

真実 (10) 　どんどん管理は煩雑になる

・仕様書、チケット、納品物の提出…　管理量を超える

・ただでさえ多いのに人の管理がそこに入る「 A君と B君が、触ってはいけない J文式土器を…」

・増えるバグや修正の量

結果的にコントロールされていないとクオリティが下がったり動かないものができる

50/101

聞いてみたい

・あなたが経験したプロダクトの真実を教えてください。

・何もなかったとは言わせませんよ(笑 )

51/101

たぶん他にも…・増えるしがらみ　誰それさんに紹介されたのでこの会社は使わないといけない…などなど

・適切なクオリティチェックがされない　デバッグ会社を通せない、開発側に意識がない…

・ドミノが倒れない　開発側の手が止まってる→仕様書が来ない→企画の仕事量が多くて手が回らない

・堂々巡り　開発側の手が止まってる→仕様書が来ない→開発と相談待ち→仕様書作れない…

・目的が明確でない　俺たちは何のためにこれを作っているんだ…

52/101

分類すると…

ここで真実を分析してみて、どんな現象が起きているのか整理してみよ

う。

53/101

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

54/101

金

リソースの相関関係

・時間は、　人の量や人の質、　求める作品の質によって　足りなくなる

時間

人

質

55/101

リソースの相関関係

・人は、　マネジメントの不手際、　求める作品の質によって　足りなくなる 金

時間

人

質

56/101

リソースの相関関係

金は、　時間と、　人の量 / 人の質と　求める質に　比例してなくなる

金

時間

人

質

57/101

リソースの相関関係

クオリティ ( 作品の質 )は、　時間と、　人（数より質）、　お金、　作業量の積算で　得られる

金

時間

人

質

58/101

ということは？

・プロダクトには等しく同様にこれらの問題が存在する。

・成功したプロダクトとは、これらを乗り越えたものであり、失敗したプロダクトはこれらを何らかの理由をつけて対策しなかったものである。

・プロダクトオーナーはこれらを解決するように心がけ、そのプロダクトを少しでも成功へ導くように日々を使う

59/101

じゃどうしたらいいの？

・まあいろいろあんだけどねえー

・そもそもプロマネ自体が特殊な職種だし、　ぶっちゃけセンスや才能のあるなしとかも戦略と戦術のフレームワー

クを使ってなんとかしてみよう

60/101

フレームワークとは？

・柔道とかの型、 Unity とかのプログラミングフレームワークとか

・ SWOT 分析とか、考具とか、 GROWモデルとか…

・仕組みや手順がまとまっている方法、手順。

・「穴埋め問題的なものがあり、そこに答えをいくつか埋めたら、　なんか解決が自動的に図れるよ」という道具とでも思ってもらえたら。

・フレームワークのよいところは、「楽ができる」ということ。　「解決するベストな方法を網羅的に考える」　「解決方法を考えるための時間」を削減できるのがメリット

61/101

戦略と戦術のフレームワーク：概要①

目標

今現在

・目標を明確にする。　何を成したら成功とみなさせるのか

・チェックポイントを置く

・そのチェックポイントでの目標、　プロダクトの目標から逆算して　明確に決める

明確化

● チェックポイント

● チェックポイント

62/101

戦略と戦術のフレームワーク：概要②

目標・そのチェックポイントへの　目標に対する戦術を並べる

・戦術をリソースや状況に応じて、　チェックポイントへの目標から　逆算して取捨選択する

・次に取る戦術を取捨選択する

・これをプロダクト完成まで繰り返す

〇：状況 A に対する戦術 A-1

〇：状況 C に対する戦術 B-1

チェックポイント

選択

×：状況 A に対する戦術 A-2

繰り返す

63/101

・

フレームワーク：目標の決め方達成しなければならないもの　　└会社的目標、プロジェクトチーム的目標、自分的目標。それぞれ違う

人、金、物、時間、に照らし合わせて検討すると、あんまりブレない。

・達成しなくてもいいものを選択する　　 × ： 時間があふれてもいいものを作ろう　　〇 ： 予算内にそこそこのものを作ろう。あとは運営しながらよくしていく。

・達成しないとならないものを掘り下げる　　売り上げ、物量、人材育成　　　└それを開発する人数、費用、裏付け　　　└どういうスキルがいる？　誰が必要？　採算分岐ラインは？

64/101

フレームワーク：開発スタート前の決定事

要　素 内　　容

人 （誰が担当？　スキルは？）

金 （予算・毎月かかる費用目測）

物 （開発機材・ツール、ＰＪでの開発ルール）

時間 （開発期間）

戦術を組み立てるに、どのような決定が必要？

リソース（人・物・金）

期間・時間

まずこれ

ほんこれ

65/101

フレームワーク：開発スタート前の決定事

マネジメントにかかわらない場合、

リソースと時間がきまってない状態から JOIN に誘われたら、脱兎のごとく逃げましょう

66/101

フレームワーク：開発スタート前の決定事

最初の戦術

チーム内向け チーム外向け真実「　　」が「　　」にあるので、いま「　　　」をする

真実「　　」が「　　」にあるので、いま「　　　」をする

10 個書く

10 個書く

チェック期間いつ頃までに何をやる ?

次のチェックポイントの目標・何を知りたい？

・何ができていれば目標に近づく？

目標に沿わせる

67/101

フレームワーク：開発スタート前の決定事

チェックポイント

取りうる戦略真実「　　」が「　　」にあるので、いま「　　　」をする 10 個書

く次のチェックポイントの目標・何を知りたい？

・何ができていれば目標に近づく？・周囲の状況は ?

目標に沿わせる

68/101

・

・

　　　　有馬さんの場合①

目　標

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

69/101

　　　　有馬さんの場合②

リソース

要 素 内　　容

人 　エンジニアは優れた人 + 新人

金 　あまりない（具体的な金額は把握しておく）

物 　すでにいろいろあるのでこれを活用

時間 　さほどないけれど交渉次第

ざっくりでもいいので、戦略建てに必要なリソースを把握する

70/101

・・

・・・・・・・・・・・・・・・・・・・・

・

　　　　有馬さんの場合③

最初の戦術

戦術 1 質の高いエンジニア /デザイナーで爆速の開発力を持つ

何があってもすぐ修正できるようにする

戦術 2 ちょくちょく話を聞く。社内外ともに。それで軌道修正していくことをあらかじめ確認

する

戦術 3 いろいろな人が心配しだすので 1週間内で状況を報告していく。ところどころで社内テス

トしてもらう

取りうる戦略

71/101

　　　　有馬さんの場合④

チェックポイント

・・

・・・・・・・・・・・・・・・・・・・・

戦術 a-1 目標に叶うデザイナーの確保。うちのひとほか。たまたま元同僚を捕まえられた

戦術 a-2 デザイナーを説得、または期間を取れるように工作

いろいろ見せた　「この UI ひどいですけど…」

・・

・・・・・・・・・・・・・・・・・・・・

戦術 a-1 有馬さんの時間をそちらにふやした

戦術 a-2 開発側も対戦するようにした→時間がとれない→じゃあ時間決めてやろう

試した　「プレイヤー人数増やすと挙動が不安定」

72/101

目　標

　　　　有馬さんのよくなかった場合①

・

・

チーム目標・プロダクトを世に出すこと・予算内に出してもうけること

個人目標・クオリティをなんとかしたい。

73/101

リソース

　　　　有馬さんのよくなかった場合②

要 素 内　　容

人 　求められている状態としては厳しい　これは厳しいと思う人が何人かいる

金 　ない。予算枠がある。　契約の不備で身銭切るところも

物 　これからほとんど１から作る

時間 　変更不可

74/101

　　　　有馬さんのよくなかった場合③

最初の戦術

・・

・・・・・・・・・・・・・・・・・・・・

・

戦術 1 人が良くない→よそからひっぱれない ?→ だめだった

戦術 2 人が良くない→なんとかなだめすかして、望みの方向にもっていくよように→時間かかっ

た

戦術 3 目標が曖昧→この時期にはこうするというのを明確にした。チェックポイントの創

出

取りうる戦略

75/101

　　　　有馬さんのよくなかった場合④

チェックポイント

・・・いろいろあって死んだ

「クオリティが低い」と言われる

・・

・・・・・・・・・・・・・・・・・・・・

戦術 1 どうにもならんので有馬の方で修正→それようの時間を作る→いろいろ失敗

戦術 2 作り直しが予想される→先方の上司の好みを聞きながら対処した。担当希望と合わせて考えて提案出した

76/101

聞かせてください

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

77/101

戦略と戦術でよくある質問

よく聞かれたことをまとめておきます。

78/101

どんな戦術を取るべきですか？①

・ リソースと戦略から戦術を選択する・ 戦術は人、物、金、時間のどれかのパラメータを増減させることに還元できる

・ その戦術と戦略目標に関係性があるのなら、取るべきだ

・ その戦術と戦略目標に関係性がないのなら、排除していい

79/101

どんな戦術を取るべきですか？②

・ A案は人 -10 、金+10 となる。 B案は物 +10 、時間 -10となる。・目標が「クオリティが高いもの」であれば、 B案を取る。

　⇒Ｂ案採択：時間が犠牲となるので、そこは交渉する。

・一方目標が「期間内で予算内に」ということであれば、 A案となる。・そうすると作業人員が足りなくなる。

　⇒Ａ案採択：開発内容を整理、作るものを抑えるよう交渉

80/101

どんな戦術を取るべきですか？②

すべてがそう簡単な話ではないけれど…判断の失敗の理由を検討する　⇒目標が手札によってブレる　　⇒目標へのものさしを固定する　　　⇒「人、物、金、時間」が目標にあっているか？

人、金、物、時間、に照らし合わせて検討すると、あんまりブレない。

『フレームワーク：目標の決め方』より

81/101

戦術をどう増やしていくのか ?①

・どんな戦術が足りないのかリソース( 人、物、金、時間 ) から考える

・また内部 ( チーム内 )/ 外部 ( えらい人、会社情勢 )ごとに考える

82/101

戦術をどう増やしていくのか ?①偉い人のクオリティチェックがありそうだ　⇒　「外部 / 物」に当てはめる

・「外部 / 物」 ×時間 = なるべく早いうちにコアとなるところを見せておこう。

・「外部 / 物」 × 人 = 偉い人に対抗できる味方をつけよう・「外部 / 物」 ×金 = できるだけ実行予算を少なく回しておこう。別プロジェクトで実績を出しておこう。そうすると印象がいいはずだ。

・「外部 / 物」 × 物 = なんか買ってきた方が早いんじゃないか。早く作れる方法はなにか製品としてないのか ?と組み合わせて考えてみると広げられる。

あとは経験者に聞いていくとかして、戦術を広げておく。

83/101

　　　　有馬さん的戦術例①

「有馬さんが死なないようにする」

有馬さんはほっとくと死ぬよ！

なるべく管理する「方法」を用いない。そのためにはどうすればいいのかを考えている

そもそもガントチャートって何の目的で使ってる ?遅れは出ていることがわかっても、あんまり意味がないかもよ ?いつまでに何を、というのを明確にし、そこで出てきたもので判断する、としている。

84/101

　　　　有馬さん的戦術例①

「有馬さんが死なないようにする」

有馬さんはほっとくと死ぬよ！

上方向の対処礼儀正しく仲良くする。信任を得る。正しい報告をする。

いざとなったら助けてもらえるように、お付き合いさせていただいています。

参考　『日本のいちばん長い日』

85/101

　　　　有馬さん的戦術例①

「有馬さんが死なないようにする」

有馬さんはほっとくと死ぬよ！

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

86/101

　　　　有馬さん的戦術例②

「億劫にならないシステム」

エンジニアが死んでもいいようにしよう！

・ UI 変更などデザイナーだけで対応

・ガチャの入れ替えなどプランナーだけで対応・ビルドを自動配布して誰でも見られるようにしておく

・ wiki に書いときなー　書いときなー

87/101

　　　　有馬さん的戦術例③

「壮絶な開発スピードを得る」・何があっても「まあ作り直せばいいよね」と言える環境にする

1機能 1 日で作ったものなら、まあしょうがないと言えるけれど、 1 か月もかかるとなかなか捨てがらない。としたら爆速で機能を作って捨てる、というイメージができないとつらい

・すべてがそのクオリティにできないとしたら、それを目玉な部分で達成できるように、リソースを集中させる質のいいスタッフを取りそろえる

それを常に目指す

88/101

　　　　有馬さん的戦術例③

「質のよさとは何か？　その基準」

基準となるラインを有馬さん的に過去事例をベースに決めていて、それがよくなければチェンジするか、フォローしたり補完できる人を入れる

どうにもならなかったら作らないといけないものを減らす。楽しさは変えない。

その時の戦略で基準は変わる基準は自分で持っておく

89/101

聞かせてください

・あなたの戦術はなんですか ?・それはどんな目標があるときに使っていますか ?・それは達成できましたか ?

90/101

どうやって評価する？

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

戦略修正に対して

戦術修正に対して

OODA で評価PDCA で評価

91/101

OODA とは？

・監視： Observe敵を発見、確認

・情報判断： Orient監視段階で収集した情報から今どんな状態なのか判断

・意思決定： Decide情勢判断段階での状態から、対抗策を決定する

・行動： Act意思決定段階で決められた対抗策を施行する

これを繰り返す。サーチ＆デストロイという感

じ

92/101

OODA と戦略

と、「戦術を決める」ためにこんなループにしてみる

行動： Act戦術の実施。開発メンバーに危機感や感情とともにやることを共有して行動を実施させる

監視：Observe外部内部的に変更はないか、プロジェクトは目標に向かって進められるか確認。それぞれの人間へのヒアリングや成果物で確認する

情報判断：Orient

開発が遅れていたとしたら過去の状況からどれぐらいかかりそうか見積もる。また、どれぐらいプロジェクトに影響があるのか検討する。

意思決定：Decide取りうる戦術を検討し決定する

各チェックポイントごとで判断

93/101

PDCA とは？

・計画： Planこれまでの実績などから計画を作成し、決定する

・実施・実行： Do計画内容に従ってそれを実行する

・点検・評価： Check実行した内容が計画したときの予想とずれているかどうかを確認する

・処置・改善： Act点検・評価によって得られたよくないところを改善する

これを繰り返す。

94/101

PDCA と戦術①各戦術ごとで判断

計画： Planその戦術の具体的な内容を、戦略目標から決める( 戦略目標 : この日までに作りたい→チーム開発力を高めたい→勉強会をする )

実施・実行：Do勉強会してみた

点検・評価： Check実行した内容を評価する。このときはあくまで戦略目標と照らし合わせて評価する

例 )勉強会には 10 人ぐらい来て、和気あいあいとして楽しかった。 A さんの違う一面を見られた… ×

チーム開発力を高めるためには、開発能力がない人に参加してもらいたかったが出てきてくれなかった。そもそもチーム開発力ってなんだ ?…〇

95/101

PDCA と戦術①各戦術ごとで判断

・処置・改善 : Act評価で得られた問題点を検討する

チーム開発力って何？ …言われたことを期日通りにやる、としてみるなぜいまそれができない？ …開発者の中にできる人が少ないチーム開発力を高めるためには？ …できる人を多くする勉強会は何のためにやった？ …できる人を多くするため勉強会の結果は？ …増えなかった勉強会のほかに方法は ?　　…できる人と入れ替える。 …できない人をできる人に教育してもらう、　　…本当にそうなのかテストケースを走らせて計測 …などなど。あれ勉強会じゃなくてもいい？と、「戦術の実行結果をよくする」ために、こんなサイクル

にしてみるだいたい Act で深堀すると、ひとつの戦術の話が複数になることもよくある

96/101

戦略と戦術から見たよりよいプロダクトオーナー

人は戦術 (=ノウハウや方法 )ばかり語りたがるし、使いたがる。実はそれは些細なことなんだ。

混乱してるのなら一度戦術的な話を聞かずに、すべて忘れてみよう。

97/101

戦略と戦術から見たよりよいプロダクトオーナー

実際に重要なのは「いかに目標へ近づけるために自分で判断して、その方法を選択したか」という戦略になるんだ。

どうか戦略を立てて、未来を予測して今を逆算し、いろいろな戦術を使って、戦ってほしい

98/101

戦略と戦術から見たよりよいプロダクトオーナー

お仕事を一緒にした役員から聞いた言葉

「プロジェクトなんていろいろあることなんだから、それ自体を不安がったりしてはいけないよ。一番肝要なのは、それをどう対処していくか、そのことだけなんだ」

99/101

質疑応答

何でもは答えられません。知っていることだけ

100/101

宿題・何かの目標があり、それを逆算していまこれをやる、というクセをつけてみよう

・ かつて自分たちが参加したプロジェクトがどうなったのか考えてみよう。 どういうことが起きたのか、時間、リソース、人、　　 金の 4 つのカテゴリで 3つ以上出してみよう

・ それをもとに「そうならないようにどうしたらいいのか ? 」という戦術を考えてみよう

・ あるプロダクトを作れと言われたとき、いまあるリソースで、考えてみた戦術をどう適用するの考えてみよう。

101/101