2018/05/15

”捨てる"ことで幸せになったものを紹介するよ

先日「自分が正当に評価されていないと嘆く君へ」という、組織における人事評価に関するエントリ (上から正しく評価されることを諦めると幸せになるよ、という趣旨) を書いたところ好評でした。

なので、他にもこんなものを「捨てる」と決めたら幸せになったよ、という個人的体験を軽く書いてみようと思います!

社内からの評価


先の blog エントリの通りですね。
ただよく考えてみたら、僕はその後ほどなくしてその会社を辞めているし、その過程で「別に今いる会社で評価されなくても、どっか別のとこで雇ってもらえればいいし、そうなれるように実績とスキルを積んでおこう」って思うようになったなぁと。

なので、本当に捨てたのは「1 つの会社にしがみつく生き方」とかそういうやつなのかもしれん。

未来は予想できる、という思い込み


昔々ぼくは、将来はこういう風になりたいから、そのためにはこういう能力を身につけて...と、将来から逆算して今の行動を決めていた。

でも、これまでのキャリアで、事前に予測できていたことってマジでなかったなぁと。

Google と楽天の内定を持ってて、楽天を選んだときには、3 年ちょっとで Google に転職するとは思ってなかったし。
(でもそのとき楽天を選んで良かったと思ってる)

楽天には (コード書いたことないのに) 開発側で採用されてたので、ほんとだったらエンジニアやるはずだったのに、経営企画的な部署に配属されて係数管理や M&A をやることになるなんて思ってなかった。
(でも凄い恵まれてた。人にも経験にも)

Google に転職したときには、まだ今所属してる AppLovin はこの世になかった。
AppLovin に転職を決める 3 ヵ月前までは、実はこの会社の名前さえ知らなかった。
(マジです)

事前に「何年後にこれをする」と決めていたら、(そもそもその通りにいかなかったと思うが) この人生はおそらく得られなかったわけだよ。
あぁおそろしい。

たぶん大前提として、世の中そのものが自分の予想のつかない変化を、予想のつかないスピードで起こすっていうことと、自分自身の興味関心が予想外に変わる、自分自身が変化するとそれまで見えてないものが見えてくる、という【外部】と【内部】の要因が、自分の人生の将来予測を困難にしてるんじゃないかなぁ...

これからも、その時その時の直感を信じて、【面白そう】で【誰かの役に立ちそう】で、できれば【中長期で投資対効果が高そう】なことに巡り合ったら、ちょっと考えて基本やる、という風にアクションをとっていこうと思っています。

もっと良い人生の伴侶に出会える可能性


ぼくけっこう早く (お互い 23 歳のとき) に結婚してるんですが、時々聞かれるのが、なぜその早いタイミングで結婚を決めたのかということ。

確かに、その人よりも良い (ここは議論のポイントじゃないので、あえてシンプルに) 人と将来ワンチャンある可能性は、その時点では十分あった。

秘書問題とかお見合い問題とか言われる数学の問題によると、生涯で結婚するチャンスがある人 n 人と出会うとすると、n/e 人目で結婚するのが最も「ベストな人と結婚できる確率」が高いらしい。笑
詳しくはこちら

妻自身、時々ぼくに「多分あなたには私よりも良い人と結婚できた可能性がけっこうあったよね」という趣旨のことを言ってくる。
ぼくも妻に同じことを言う。

序盤の序盤に意思決定するのがベストな選択肢じゃないってことに、おそらく彼女は直感的に、ぼくは論理的に、気づいているのである。

でも、あえて早く結婚して、「他のもっと良い人と結婚できてたかもしれない可能性」を捨てた (ちゃんと捨てたw) ことで、無視できないぐらい良いことがあった。

ひとつは、一定確率で【伴侶探しに大きなリソースを使っていた】かもしれない世界線を回避できたこと。
多分彼女つくるため合コン行ったり、マッチングサービス使ったり、メシやらモノやらでお金を使ったり、していたんだろう、少なからず今よりは。

貰い物の企業ノベルティ T シャツに短パン・クロックス、みたいな気楽な格好も出来なかったかもしれない。
(良い年こいた社会人としてそれどーなの、ってツッコミはあーあー聞こえなーい)

もうひとつは、早く結婚して早く子どもを (運良く) 作れたことで得られた、比較的体力のある若いうちに子育てが出来たり、今後子どもが親元を離れる時にまだ割と若い、という "同じライフステージを迎える人の中での相対的な若さ"。

結婚生活がわりと上手くいってるから結果論として言えるのかもしれないが、早くにサクッと結婚決めちゃうの、悪くないと思ってます。

仮にダメになっても早くにリセットできるし...とかは言わないほうがいいのかな

肩書き


これは今の会社に強く影響されてる自覚があるんだけど、自分や他人の肩書きに対してまったくこだわりがなくなりました。

うちの会社って、そもそもまだそこまで組織が大きくないからレイヤーが少ないってのもあるんだけど、肩書きが全然 "盛って" なくて超シンプルなんですよね。

外資 (特に海外支社) でけっこうよくあるのが、入社するときに条件として肩書きを出す (例えば、ほげほげマネージャー、ほげほげディレクター、みたいな肩書きじゃないと入社しないよ、みたいな) 人。
あるあるですね〜。

たぶん、その会社を辞めたあと次の転職をするときに、良い条件でオファーをもらいやすい、とかそういう理由がメインだと思うんだけど。
(そのほうが仕事が進めやすい、とくに BtoB の営業文脈で、というケースもたまにあるのかもしれない)

AppLovin はわりと明確にそういうタイプが嫌いで(笑)、むしろ、肩書きなんてどーでもいいぜ、良い仕事みんなでやって美味い酒飲もうぜ、みたいな人のほうが好き。
そして見てる感じ、そういうタイプのほうが実際いい仕事する傾向にある気がする。

1 つ目の項目とも共通するんだけど、肩書きなんかよりも仕事の実績とキャラクタで評価される時代だと思うので、別にタイトルが多少ショボかろうが関係ないし、むしろそのほうが良い仕事したときギャップで高い評価もらえるんじゃないかって気さえする。笑

あこがれ・関心がある仕事


昔は例えば (楽天でのニアミスがあったのもあって) エンジニアに対する漠然とした憧れみたいなものがあった。
ので、初心者のためのプログラミング講座みたいなのに参加したり、オンラインのプログラミング学習サービスを触ったりして、ちょっとかじって、モノを作り上げるところまで到達せず終わる、学んだこともほとんど忘れる、みたいなのを繰り返してきた。

けどあるとき気づいた。
これまで幾度となく始めて、一度も続かなかったってことは、多分ぼくはプログラミングそのものを楽しいと思っていないんだろう (きっと) と。

なので、自分がわりと苦労せず続けられて、他の人より比較的うまく出来て、お金を稼げることだけをやろうと。
自分に出来ないことや、得意じゃないこと、やりたくないことは、他の能力のある / 得意な / 好きな人にやってもらおうと。

みんなが自分の得意なこと・やりたいことだけをやって、そうじゃないことは (相互に) 発注し合うような社会になれば、社会全体がより効率的になるし、お金も回るし、いい事づくしじゃないかと。
(そこまで大きな話でもないんだけど)

なので多分ぼくは今後も、エンジニアリングをはじめとする (個人的には憧れがあるんだけど) 色んな仕事について、自分では手を出さず、お金で解決 or やれる人一緒にチームを組んでやると思います。
逆に自分も、得意な領域の仕事では「お金を払ってでもやってもらいたい」と思われるようになりたいな。


あと最後に、「捨ててよかったもの」ではなく「捨てたいもの」

脂肪


お後がよろしいようで。

Q

この記事が役に立った!という方は、よければ下記ボタンから投げ銭 (300円 | クレカ払い) をお願いします!ぼくのモチベーションが上がって、また良い記事を書くかもしれません!w

2018/05/11

【保存版】プログラマ・エンジニアを評価する方法

掲題に関する問いを Facebook に投げたところ、素晴らしい回答がたくさん集まったので、この知をより広く知ってもらうため、そして後世に残すために、内容をまとめておく。 

【問い】 プログラマ・エンジニアを評価する方法


先日「自分が正当に評価されていないと嘆く君へ」という、組織における人事評価に関するエントリを書いたせいで、読者の方からこんな相談が寄せられました。
皆さまの忌憚なきご意見・知見をお寄せいただきたく!

<相談内容>

例えばゲームやアプリの開発って、結果(アウトプット)が現れるまで数年ぐらいかかったりします。
その数年間の間に、真剣に作業に取り組む人もいれば、適当にサボる人など、色々差が出ると思うのですが、どうすればその差を、数年ではなくより(なるべく)短いサイクルで可視化できるものでしょうか?

評価の制度や指標をどのように設計すればいいか、あるいは、どのような設計方法があるのか、アドバイスいただけると幸いです。

(補足:相談者は、名古屋を拠点とする株式会社フリースタイル (http://freestyles.jp/) に勤めており、経営レイヤーから「エンジニアの評価制度を作る」というミッションを与えられた、エンジニア未経験者 - ご本人および経営陣から OK 出たので会社名追記しましたw)

集まった回答のまとめ


エンジニア組織にいる 3 つのジョブレイヤー

まず気をつけるべきことは、被評価者を「エンジニア」という 1 つのバケツにいっしょくたにせず、いくつかのレイヤーに分けること。つまり;
  1. 設計図とスケジュールが与えられていて、その通りに作るのが仕事の人
  2. ものを完成形まで作り上げることに責任を持つ人
  3. ビジネス課題を解決する、事業ゴールを達成するのがミッションの人
の 3 つのパターンがあることを理解する。

これらの 3 つは、必ずしも 3 > 2 > 1 の順番に偉い / 給与が高い必要はない。
「3」が達成出来ていなくも「1」がズバ抜けていれば「1」で評価すべきだし、掛け算でさらに高い給与にすることも必要かもしれない。
人材マーケットとの需給バランスでもあるため、高度人材になればなるほど評価は市場に依存させれば良い、という考え方もある。

評価する順番としては、
  • ビジネス課題から考えて解決できるレベルの人材に対しては「3」ベースで評価
    • もし3が達成出来なかった場合、プロセスおよび職能としての「2」で評価
    • そこでも評価しづらいエンジニアに対して「1」で評価する
という流れになる。

それぞれのレイヤーに対する評価方法


【3. ビジネス課題を解決する、事業ゴールを達成するのがミッションの人】はいわゆる KPI や KGI にコミットして貰って、そこで目標に対する達成度合いを計測する方法をとる。
あまりエンジニアかどうかは関係ない。

逆にこのレベルの人は、単に綺麗なコードをスケジュール通りに書ける、プロダクトを期限までに完成させられる、というだけでは評価されない。
それによって、会社や組織の定める事業ゴール・解決すべき課題を、達成できていないといけない。

定量的に評価できるので、ある意味では最も評価しやすいのがこのレイヤー。


【2. ものを完成形まで作り上げることに責任を持つ人】はアウトプットに対して評価する。
モノ自体を作る能力なので、QCD(※) のような一般的な SIer のノウハウで一定は観測可能。

(※ 「Quality (品質)」 「Cost (費用)」 「Delivery (納期)」 の頭文字を取った言葉で、主に製造業において設計・生産時に重視される3つの視点)

まず前提として、管理者が自分の裁量で、与えられたチーム・メンバーの実力で、アウトプットと開発スケジュールについてゴールを決めて関係者に共有・合意形成する。
(途中で大きな前提条件の変更があった場合は、計画をたてなおす)
その上で、できれば管理者として目標達成。
できなければ (自分がヘルプに入る、仕事を他の人に振り分ける、などで対応することが出来なかったということなので) 管理者のスキルが足りていないという評価になる。

管理者クラスにならないと成果物でのインセンティブは発生するべきではないという考えの人が多いようだ。
逆に、成果物でのインセンティブが欲しいのであれば、管理者になる (そのためのスキルを積む) ことが必要。
なおここでいう管理者とは、プログラマならプログラマの、グラフィックならグラフィックの責任者というイメージ。
他の職種の評価および業務の振り分けは難しい。


【1. 設計図とスケジュールが与えられていて、その通りに作るのが仕事の人】は "個の技術資産" に対する評価であり、「エンジニアの能力を評価する」と言ったときに恐らく多くの人が想起するであろうものがコレ。
ここは内容が厚いため、下記に別途章立てする。


"個の技術資産" に対する評価 - 誰が行うべきか


最も多く出た意見は「エンジニアの評価は、(優秀な) エンジニアが行うべき」というもの。
いくつかコメントを引用する。
  • エンジニアは特に、同僚からの評価が一番正しい
  • エンジニア未経験者がエンジニアを評価すると、だいたいエンジニアはどこかへ行く
  • ソースコードのよしあしは偉い人にはわからないし、売上にも進捗にも関係ない

なので、単に「上の人」が評価するだけでなく、例えばカヤックの行なっている「360度評価 (https://at-jinji.jp/blog/14848/ )」がいいのではないかという意見も。

エンジニア相互での評価のランクが【Aさん > Bさん > Cさん】で、給与も【Aさん > Bさん > Cさん】となってさえいれば納得感がある、という意見もあった。

どうして「エンジニアの評価はエンジニアが行うべき」なのか


エンジニアの「技術力」と呼ばれるものは、2 つの要素にブレイクダウンできるという意見が複数の人から出た。それは何かと言うと;
  • 他の人より仕事が早い 
  • 他の人が出来ないことができる
である。
この掛け合わせで、面積的に評価する必要がある。

前者の「く作れる能力」は、比較的、体感で計測可能。
なにしろ早いので笑。
後者は言い換えると「より難しい問題を解ける」能力で、これが特にエンジニア以外に計測が難しいポイント。

例えば;
  • 3 年後にきっとこういう改修が必要だから、エンドポイントを作っておいこう
  • 今はトラフィック少ないけど、1,000 倍になっても今書いているコードがボトルネックにならないように、ある程度高い処理性能が出ることを考えて実装しておこう
など、こういうことを考え予め実装できる能力が技術資産にあたる。

(もちろん、現在直面している難問を解ける、ということも含む)

こちらの方は「早さ」に比べて観測が極めて困難である。
なぜなら、初期に "未来を想定して" 実装されるものなので、アウトプット (完成物) やアウトカム (KPI/KGI) には現れないからである。

ゆえに、共に働くエンジニア以外には評価不能と言える。

具体的にどのように "個の技術資産" を評価するのか


①まずは、決められたスケジュールで、決められたものを作ることが出来たのかどうか。
その前提としては、上で出てきた「管理者」ロールの人が、誰に・何を・いつまでにやらないといけないのか、をきちんと定義できないといけない。

ちなみに欧米の会社だと、JD (Job Description = 職務記述書) や定期的 (半年とか四半期ごと) な目標設定で上記を明記し、 それを遂行できる人には決められた給料を払う、できなければクビ、という風になっている...っぽい。
たぶん。
たまたま自分が知ってる会社が "ちゃんと" 出来てるだけで、ほとんどの会社は実はグズグズなのかもしれないけど。笑

この評価は、ある意味では「進捗管理」とニアリーイコールになる。
「早さ」に対する評価はここに含まれる。


②次に、「スケジュール通りに決められたものを作った」とき、その中身を評価するプロセス。

中身とは具体例でいうと、 バグの少ない綺麗なコードを書けるとか、速く動くコードが書けるとか、ライブラリの使い方に精通しているとか、将来を見越して先に問題を潰しておけるかとか。

ちゃんと要求通りの味でチャーハンを作った 2 人のシェフがいたときに、こっちのシェフはニンジンの形を綺麗に揃えて切れてるねとか、完成した瞬間にすでにキッチンが片付いてるとか、翌日分の仕込みまで終わってるとか、そういったことかな。
客からは見えないし、「わかってる」シェフじゃないと良し悪しが判断できない。

「エンジニアの評価は、(優秀な) エンジニアが行うべき」というのは、エンジニアではない人、またはエンジニアとしてのレベルが高くない人には、この観点での評価ができないことが理由。

この観点での評価をどう行うかは、出ていた意見としては「数値化・制度化は困難」というもの。
まぁ確かに、決められたゴールを達成した上で、それプラスアルファの部分なので、定性的な評価にならざるを得ないという面はあるのかもしれない。

評価者となるのは、被評価者の管理者/上長など "上の人" が基本。
その人が日々の業務の中で、ソースコードをマージして読んでいれば、おのずとエンジニアのレベルは分かる、少なくとも複数いるエンジニアの相対的な評価は出来るはずだ、ということだ。

例えばお相撲さんが毎日稽古していて、誰が誰には勝てる・負けるというのは、稽古を毎日見ていれば自ずと解ってくるもの。
同じ組織で仕事していれば、相対的にだれが優秀かは解ってくるとのことだ。

この前提になっているのは、評価者がソースコードを見て、コードを書いた人のレベルを判断できる程度に十分優秀だ、ということ。
評価者は過去に、リードプログラマーとしてプロダクトをリリースまで持っていけた、など一定の実績がある必要がある。

なお、さらに 1 つ上のレイヤーの人になると、ソースコード読んでも分からない (あくまで管理職としてそのポジションにいる人であり、エンジニアとしての能力が高いからいるわけではないケース) こともあるので注意が必要。

インターネットサービス・プロダクトを開発するのは建築物を建てるのに似ていて、大工から電気工事から玉掛さんまで、いろんな能力を保有している人が必要になる。
なので、広く深く技術を理解して、評価できる人が 1 人でもいれば、評価としてrは安定する。それを CTO に求めているのが今の日本マーケットだと思うが、本質的には job description に分解して、情報工学上がりの人事部長がやることも可能。
今の日本では難しいかもしれないが - だそうな。 

評価者になれる人物が社内にいない場合は?


"個の技術資産" を評価出来ない組織、つまり、絶対的技術のトップがいない組織は、高電圧人材 (= 凄く難しいものをポンと解決できる人材) がいなくなる。
なので、常にアウトプットが出るわけではない (簡単な問題を解き続けることが不得意、飽きる) が、難問が発生した時に活躍する人材が欠乏する。

こういう組織は新規事業を作るのが遅かったり、トラフィックが突然増大した時にサーバーが落ちてどうしようもなかったり、といった事態が発生する。
また、そういう人材が評価されづらいので、その後も長きにわたってそういう人が集まりにくくなる。




以下は、上記の本論でどこに含めるべきか分からなかったが、トピックとして興味深かった点。

【オフトピその 1 - 日本と欧米の違い】


エンジニアの給料は欧米 (特に米国のテック系企業に顕著だと思う) のほうが日本よりも高い、特に優秀なエンジニアに対する払いは海の向こうのほうが随分高い、という議論がある。

この理由として、欧米では job description に書かれた業務が遂行出来なかったらクビ (契約解除) になることが前提だからこそ。
決められた仕事が出来ない人にまで給料を払う必要がないため、出来る人の給料が日本よりも相対的に高い (物価を考慮してもなお高い) のではないか、という議論があった。

そういう社会では、給料上げたければ、より給料の高い (仕事を出来るようになるか、スピード上げて仕事自体をたくさんやるかのどちらかしかない。

【オフトピその 2 - 正社員ではなく業務委託・契約社員】


より「出来る人に報いる」ため、日本でも欧米のような「出来なかったら去る」という状況を作り出すのは、雇用形態を正社員にすると難しい。
(解雇の条件が厳しいため)

むしろ、エンジニアを全員個人事業主の常駐委託契約にして、個別に条件交渉し、働き方も報酬も本人に決めさせる (合意の条件のもとで働いてもらう) という案も出た。
契約更新するかや、条件変更するかどうかは、都度判断というもの。

そのような世界線では、企業間での人材確保競争がより激しくなるので、企業としては優秀な人材を抱え込むこと難易度が高くなる。
が、他の企業が正社員中心で必ずしも優秀でない人材も雇用している状況のなかで、自社だけがこのような仕組みを導入したら、プロフェッショナルが残りやすくなる (優秀な人材はそうじゃない人材と一緒に働くのを嫌うという側面や、単に優秀な人材により高い報酬を払うことが出来るようになるので、相対的に採用力が増すという側面など) かもしれない。

【オフトピその 3 - アウトプットに対する報酬】


アウトプットに対して評価されるべきなのは、管理職・リーダークラス以上だけだ、というのがこれまでの論旨だが、高いアウトプットが出たときにそれより下のレイヤーのメンバーに報いてはいけないという決まりはない。

ある若いスタートアップの founder は、正社員の給与に関しては、基本給とインセンティブ給を分けるべきだという持論を語ってくれた。
(業務委託の場合は、決められた成果を達成したら決められた報酬が支払われるという契約関係なので、最初からインセンティブ給込み = わりと高給)

基本給はやってくれた仕事に対してあげるもので、インセンティブ給は成功を分かち合うというイメージ。
頑張ったことと、プロジェクト自体が成功するかどうかは別という考え方であり、頑張ったことに対しては基本給、成功したことに対してはインセンティブ給で報いましょう、と。

ぼく個人としては、これはいくつかの面で有効だなと思った。
  • 社内に「言われたことやってればいいんでしょ」というドライな雰囲気ではなく、「みんなで協力してプロジェクトを成功させようね」という一体感、協力し合おうという空気を醸成できる可能性がある
  • エンジニアが組織に属している目的が、「与えられたミッションを遂行して、決められた報酬をもらう」 + 「仕事を通じでスキルを高める (そしてより報酬の高い仕事を得る)」 だけでなく、「プロジェクトを成功させる」になる
  • それによって、エンジニアが自己と組織とをより同一視し、組織のゴールに対するコミットメントが深まったり、在籍期間が長くなったり (この組織が好きなんだ、この組織を成功させたいんだ、だからここにいるんだ) といった効果が期待できる (ような気がする)

また関連して、あるメガベンチャーの創業時からの CTO は、特に彼の新規事業チームに配属するエンジニアには全員「基本サービスがローンチして、利益出るまで据え置き」ベースで入ってもらっていると教えてくれた。
理由としては、"途中の評価は難しい" ことと、"評価プロセスが挟まることそのものがコストになってしまう" こと。
それよりは、2 年後成長してたらこのくらいの年収にはなってるよね、という年収をまず提示して頑張ってもらう方が良いかなと思っており、1 人 1 人とそういう話をして握っているとのこと。

(ただし、明らかに報酬が低いなと思ったメンバーは、途中で上げることもあるそうな)

この方法も、サービスを最低でも期待以上のクオリティでローンチさせ、成長させ、利益を出すことに対するメンバーのコミットメントを高めることができるという点がメリットになる。
また、スタートアップや新規事業など、全員がプロダクトの完成や成長にコミットすべきシーンでは、評価制度がどうとか報酬がどうとか議論するのに時間を使うのが勿体無いので、リソースを本来やるべきことにフォーカスさせるという利点もある。

一方で、想定通りにいかなかった場合 (サービスがリリースされなかった、リリースされたけどうまくいかず利益が出なかった、など) にどうするのかという問題がある。
また、口約束ベースだった場合、約束が果たされないとか、約束した相手が途中でいなくなってしまったりといったトラブルも考えられるので、よほど性善説にもとづいてやるか、よほど信頼のおける相手・組織でないと、安易に導入するのは難しいのではないか。

【オフトピその 4 - 評価その他】


某大企業歴戦のマネージャーからはこんな意見もあった。
"エンジニアに限らずだけど、1. 会社として定める「仕事に臨む姿勢」についてその人を周囲の人が評価する、2. その人が挙げた「成果・実績」をマネジメントが評価する、の2本柱でやってる。"

頑張ってやっていても、たまたま成果や実績につながらないときは確かにあるわけで、そのときにバサッとマイナス評価されてしまうと、確かに従業員としてはやる気なくしてしまう。
そんなときに「ちゃんと頑張ってたよね、見てたよ」と言われると救われるというのは納得できるし、そのときの評価者は (ともすると日々の仕事への取り組みまで細かく見てはいないかもしれない) 上長・管理者ではなく、周囲の人 (peer) だというのも納得感ある。

先日の自分の post 「自分が正当に評価されていないと嘆く君へ」でも、上の人が正しく自分を評価してくれることは期待するな!と断言したので、その主張にも合っていてちょっと自信がついたぜ。

最後に、エンジニア・マネジメントとしての大先輩 2 名からのメッセージを (若干編集して) お届けして、本 post を締めたいと思う。

- エースのエースたるゆえん - 


「ルーキーとエースを一緒くたにしたらあかん」
それなりの成績を長期間安定して続けてきたからこそのエースですから、かりにまぐれ当たりでルーキーが 20 勝してもエースと同じ年俸上げるわけにはいかないですよ。
ルーキーからエースになるまでには、それなりには年棒は上がっていることでしょう。
じぇどそこから先は、プロダクツによる成果が上がらないと評価されませんよ。
エースが 10 勝程度では評価されませんよと。

チームを勝たせてこそのエースです。

- エンジニアが正しく評価される組織作り、未だ道半ば -


若い業界ですし、現場上がりの管理職が増えるのはあと10年後くらいでしょうか。
先陣の皆様には頭が上がりませんが、後陣により良い道を残せるように頑張って参ります。


元スレ→ https://www.facebook.com/tatsuojapan/posts/10156073918866328  (ぼくのフレンド限定)

この記事が役に立った!という方は、よければ下記ボタンから投げ銭 (300円 | クレカ払い) をお願いします!ぼくのモチベーションが上がって、また良い記事を書くかもしれません!w



Q

2018/05/08

日本のハイパーカジュアルゲームアプリが世界でヒットしない理由

まず大前提として、この記事は「だから日本のアプリ/アプリ開発者はダメなんだ!」と偉そうに批判したり、「俺のほうがよく知ってるぜ!」とマウントを取りにいったり、といったことを目的としていません。


むしろ逆に、(自分がものづくり出来ないぶん特に) クリエイターの方のことを心からリスペクトしているし、日本に生まれ育ち・日本のゲームを楽しみ・日本のアプリデベロッパさんに非常にお世話になってきている身として、自分の持っている知見を業界に対して還元したいと思っています。

願わくば、この記事が日本のゲームデベロッパさんのお役に少しでも立ち、日本初でグローバルに大ヒットするゲームがどんどん出てくるようになればいいなと。



いまぼくは仕事として、日本だけではなく世界中のインディゲームデベロッパさんと一緒に、大ヒットするハイパーカジュアルゲームを作り出そうと奮闘しています。

「ハイパーカジュアル」についての説明は端折りますね。
詳しく知りたい方は こちらの記事 をチェック。

当然ながら全てのゲームがヒットするわけではないのですが、特に日本の (ぼくが積極的に関わっている) ハイパーカジュアルは今のところ残念ながら全敗。。。
諦めずにいろいろ試行錯誤しているところです。

ですが色々チャレンジする中で、失敗する理由にはいくつか共通点があるらしいことが見えてきました。
それも、わりかし「日本の」ゲームアプリに特有の理由。
下記にそれを記載します。
(前置き長かったなw)



1. デザイン

「デザイン」と大きく 1 つにまとめましたが、これは全く意味の違う「見た目」と「ユーザー体験」の 2 つの意味を含んでいます。

1-A. 見た目がマス受けしない = スケールしない

よくありがちな「一見イケてるんだけどグロースさせるのが難しいゲーム」が、可愛い猫とか鳥とか豚とか、動物をモチーフにしたゲーム
欧米のトップチャートを見てもらえればわかると思いますが、こういったゲーム、特に "いかにも日本っぽい" イラスト調のグラフィックで大ヒットしているゲームは、基本的にありません。

(例外としては、すでに IP になっている Angry Birds、ボクセル調の Crossy Road、たまたま有名 YouTuber に取り上げられた Flappy Bird など)

動物モチーフでワンチャンうまくいく可能性があるのは、日本と、文化的に近い東アジア (中国、韓国、台湾) ぐらいではないでしょうか。
ちなみに「うまくいく」の定義は、誰にも注目されてないとこからのスタートでも、プロモーションで黒字を維持しながら売上を押し上げて、月間売上で 1,000 万円を達成する、ってかんじかな。

同じことが動物モチーフ以外に、メインキャラクタが人間なんだけど絵がマンガ調のものや、細かいドット絵のものなんかにも言えます。
ゲーム自体は面白いのに、うぁぁそのテーマを載っけちゃったか...と感じるゲームは正直少なくないです。

これらのグラフィックに共通することは何か?

「見た目がイケてない」というつもりは無いです。
むしろ単純なビジュアルのクオリティでいうと非常に高いものもあります。
ただ決定的に言えるのは、「好きなユーザーと全く響かないユーザーに分かれてしまう」ということです。

ドット絵も、可愛い猫ちゃんも、アニメっぽいイラストも、全体の (わかんないけど) 3-6 割ぐらいは「好き!」っていうユーザーがいるのかもしれないですね。
が、逆に「このゲームは自分向きじゃないな」と思うユーザーも無視できないぐらいの割合いるようです。

例えばドット絵でいうと、いわゆるゲーマー層は好んでプレイするけど、女性の多くは逆に敬遠してる、とかなのかもしれません。
いや、実態どうかは知らないんですけど、傾向としてはどうやらそうっぽいんですよ。

それが何にあらわれるかでいうと、低 CPI で大量のユーザーを獲得するのを極めて難しくします。
広告わかる人向けに書くと、CTR, CVR がいずれも「幅広いユーザー層を対象にしたハイパーカジュアル」に比べて数割低くなってしまうため、CPM を上げられず、リーチがとれなくなってしまうのです。

プロモーションしたところで、CPI $0.5 だと 1 日に 100 件ぐらいしか獲得できないね...でもこれ以上は CPI 上げられないしね...詰んだわ...
となっちゃうわけです。

じゃあどういうのが良いかっていうと、あんまりラクして知っても身につかないので、とりあえず US App Store ランキングの過去半年ぐらいで TOP 25 に入ったハイパーカジュアルゲーム全部やってからね!





...って突き放せないのが優しすぎるぼくの罪。
これが全てではないのだけど、「フラットデザイン」 「無機質」 「「ミニマル」 「サイバー感」 「現代アート風」 「ボクセル」このあたりがキーワードとして挙げられると思います。

でも真剣に、20-30 個ぐらいトップクラスのハイパーカジュアルゲームやれば、デザインのことだけじゃなく、マネタイズや継続率 UP のポイント/ベストプラクティスなんかもだんだん掴めると思います。
本気で世界目指してるならここはサボらずにしっかりやるべきかと!

1-B. ユーザー体験

1-B-a. そもそもデザインの基本ができていない

専門外なので適切に表現できるか自信がないんですが...見てる感じ、大まかに分けると
  • 本来の階層構造とビジュアルが合っていない
  • ユーザーにとらせたい行動をビジュアルが合っていない
のいずれか、または両方が起きているゲームが多いように思います。

例えば、タイトル画面に
「プレイする」 「対戦プレイ」 「練習する」 「設定」 「SNS ボタン」 「自分の別アプリのアイコン①」 「自分の別アプリのアイコン②」
のボタンが、同じような大きさで、並列で並んでいるようなイメージ。
この気持ち悪さ、伝わるかな
この例でいうと、例えば Single play, Multiplayer, Practice をそれぞれ出すかわりに、大きく "Play" ボタンを中央に表示し、クリックしたときに次の階層で Single play, Multiplayer, Practice のどれにするかを選ばせる。
(階層構造を整理しつつ、一番やらせたい "Play" を物理的に押しやすくする)

同様に Twitter, Facebook シェア? 連携? のボタンは Settings の中にでも入れて、自社の別アプリのアイコンも直接ここには出さず、自社アプリ紹介コーナーでも作ってそこにぶち込んでおく (階層が合ってない / 重要度が低い)。
かわりに、ユーザーニーズが高く、収益にもダイレクトに効いてくるアプリ内課金への導線でも入れておくと良いと思います (ストアがあればそこへの導線、なければ広告除去など)。

階層を作って、重要度に応じて大きさを変えるだけで、ほらこんなにスッキリ。
分かるかな

このあたりは、できればちゃんと勉強した人、そうでなくても直感的に出来ている人はそのへんにいると思うので、自信がない人は素直に意見を求めにいったほうが良いです。
ぼくでよければ全然見ます。

これ次どこタップしたらええんやろ?っていうゲーム、ほんとに多いですから...

1-B-b. レベルデザイン

一言でいうと、難しすぎるゲームが多すぎます。
すぎる、って 1 文で 2 回使っちゃったよ、文章力ないかよ。

まずはこの スーパーマリオのステージ1-1から学べるUX という名記事を 3 周ぐらい読んでください。
短いし図解多いので、すぐ読めます。

スマホゲームの場合、スーパーマリオのステージ 1-1 でさえ難しすぎますし、そもそもファミコンのマリオは操作が難しすぎます。
(スマホ版のマリオについては賛否あると思いますが、僕はあれ最高にスマホに最適化してきたなぁと感動しました)

まず、ほとんどのスマホのハイパーカジュアルゲームでは、プレイ時の操作方法は 1 種類のみです。
「タップする」 「連打する」 「スワイプする」 「長押しする」 などなど。

あの名作 Crossy Road でさえ、「基本はタップ + 時々スワイプ」という 2 種類の操作の組み合わせなので、ちょっと難しすぎるのです。
(2018 年版で出しなおすなら、スワイプの動きはなくして、タップだけのタイミングゲームにしたほうがいいんじゃないかと思います)

また難易度も、 スーパーマリオのステージ 1-1 って、ほっとくとクリボーに当たって死ぬじゃないですか。
これダメです。

なんじゃこりゃ!死んだわ!むっず!
避けたらええんか?やっつけたらええんか?
どうやったらええかちゃんと教えろや!

ってストレスを感じて、それが序盤で 3 回ぐらい続いたら死んで (= 離脱して) しまうのがハイパーカジュアルゲームのユーザーです。
理不尽だと思いますか?
そういうもんです、諦めてください。

例えばスーパーマリオのステージ 1-1 なら、クリボーが近づいてきて「今!飛んで!」っていうタイミングで、全ての時を止めて、画面上に「TAP!」って文字と動く指のイラストを出して、ユーザーが画面をタップしたら再度時を動かして、なんというか 3 歳児でも死なずに必ずクリアできちゃうような、そんなレベルにまで難易度を下げるべきです。

キノコも、万が一とらずに先に進んでしまったら「キノコは強化アイテム」ってことを知らずに進んでしまうので、初回プレイ時はハテナブロックを叩いてキノコを入手するところも上記同様の 99% オートプレイ。

1-2 でいきなり難しくなるとこれまたそこで脱落しちゃうユーザーが出るので、序盤のほうは簡単なステージを続ける。
イメージとしては、最初の 10 分は幼稚園児でもクリアできるレベル、次の 10 分は小学校低学年、その次の 10 分で小学校高学年、そこからしばらくずっと中学生レベル。
ってかんじ。

かつ、序盤のほうになるべく「そのゲームを面白くする要素」をたくさん体験させる

例えば、経験値をためてレベル上げをしていくドラクエのようなゲームであれば、レベルが上がるタイミングを【3, 5, 10, 20 バトル目】にするのではなく、レベル 10 ぐらいまでは毎バトル後にレベル上がる、ぐらいの勢いで。
(そのかわりレベル上がったときに増やすステータスは小さめでもよい。成長実感さえあれば)

スライムと戦う → 経験値もらう → レベル上がる (気持ちイイ!脳汁ブシャー) → スライム 3 体を楽勝で倒せるようになってる (脳汁ブシャー) →  レベル上がる (ブシャー) → ドラキーも 2 ターンぐらいで倒せる (ブシャー) → レベル上がる (ブシャー) →・・・

というかんじで、このゲームは「敵を倒して、経験値を上げて、レベルが上がると気持ちイイ!そして強くなって、敵を楽に倒せるようになって気持ちイイ!を繰り返しながらどんどん先に進んでいく」ものなんだよ、っていう脳汁出るサイクルを、なるべく序盤のほうに高速で体験させるのであります。

なぜかというと、スマホユーザーはコンソールのように、ゲームを入手する段階で何千円も払っていません。
カジュアルゲームのユーザーはソシャゲのように、ゲームを始める前に何百メガバイトもデータをダウンロードさせられていません。

要するに、入り口のハードルがめちゃ低い分、よそのゲームに乗り換える心理的ハードルもめちゃ低いのが、ハイパーカジュアルゲームのユーザーなんです。

なので、あなたのゲームの面白さがわかるまで我慢して遊んでくれるなんて、思っちゃいけません。
操作は最初ちょっと難しいけど、学ぶまで 10 回も 20 回も遊んでくれるなんて、期待しちゃいけません。

最初っからプレイできて、すぐに脳汁が出て、思考停止した状態でも數十分ぐらいは気持ちよく遊んでくれる、そのレベルにまで難易度を下げてください。

ステージ制のゲームを作ってる方は今すぐに、序盤に猿でもクリアできる簡単なステージを 10-20 個ぐらい追加しましょう、今すぐに。(二回言ったよ)

ある程度まとまった時間をプレイしてくれたユーザーは逆に、投下した時間がサンクコストになって、他のゲームに浮気しようって気持ちが、少しは薄れます。
でも、あることをちゃんとやらないと、早い段階でユーザーは離れていってしまいます。

それが、この次にくる「コンテンツのボリューム」です。

2. コンテンツ

2-A. ボリューム

一言でいうと、アプリのボリュームが少なくて、すぐ消費されてしまうため、継続率が低くなってしまっているゲームがとても多いです。

ゲーム自体は楽しいタイトルって、たくさんあるんですよ。
でも多いのは、「楽しいんだけど、すっとやってると、1 時間もしないうちに、飽きちゃう」っていう類のもの。

昨年大ヒットした Voodoo の Dune! (iOS | Android) っていうゲームを例にとってみましょう。
やったことない人はここから先読んでもわからないと思うので、まずはダウンロードして、30 分ぐらいプレイしてきてね。
そんな時間ないよって人はこの動画でも見ておくといいよ。


(どうでもいいんですが、dune って英語で "砂丘" って意味だったんですね。死ぬ時のエフェクトが「デューーーン!」って雰囲気だからかなぁ、って思ってました。恥ずかしいww)

日本のデベロッパーさんでありがちなのが、「画面を押したら進む、離したら飛ぶ、飛んでるときに画面を押したら急降下する、砂丘の波形をスムーズに進んでいきましょう」っていうゲームの基本部分を作って、それで完成としてしまうこと。

「うん!面白いゲームできた!」

確かにゲーム自体は面白いんですが、さすがにそれだけだと何回か遊んだだけで満足して、次のゲームに移行してしまいます。

実は Dune! には、ユーザーを飽きさせない工夫がたくさん入っています。
例えば
  • ガワ替え - ボール、背景、砂丘の 3 種類のスキンを、それぞれ 30, 9, 8 種類に変更可能。見た目が変わるだけだけどちょっと新鮮な気持ちになる。
  • スキンの解放の仕方 - スキンの中には、単にポイントを蓄積すれば交換できるものもあるが、中にはそうでないものもある。例えば「1 プレイ中に X 回 Y をする」とか、「通算 X 日ログインする」とか、「通算 X 回チャレンジをクリアする」とか。
  • チャレンジ - 通常のエンドレスモードのほかに、1 プレイが必ず 30 秒以内で終わるような「チャレンジ」が 35 個用意されている。それぞれ、途中からは達成するのがけっこう難しい (でも頑張ってればマグレで or 実力がついて、クリアできたりする)。
  • チャレンジの複製 - 上記「チャレンジ」まったく同じ 35 種類が、通常モードのほかに、左右逆、上下逆、上下左右逆、の合計 4 パターンある。なので、なんと 140 種類の「チャレンジ」ステージがあるということに。

要するに、普通にプレイしてたらシンプルすぎて 1 日で飽きちゃうゲームなんだけど、常にユーザーの目の前に「次はこれをクリアしようかなっ?」っていう、適度な高さのハードルを用意してあるんですよね。

なので、ゲームプレイ自体は非常にシンプルで、それ自体は仮に数時間で作れるものだったとしても、たくさんスキンを用意したり (デザインリソースェ...)、チャレンジの種類をたくさん用意したり (ネタが...)、ステージ制のパズルゲームだったら何百・何千というステージを用意したりと、「ハイパーカジュアル」って名前のわりには全然カジュアルに作れないというのが現実なんです。

(いや、シンプルなゲームを "気持ちよく" 作るのってそれ自体すごく大変なんですよ分かってるんですよ、あくまでものの例えですよ)

そしてこの問題の根っこは、ひとつ飛ばして 3. チーム というところにあると思うのです。

2-B. トレンド

ひとことで言うと、"類似のヒットしてるゲーム" に対する研究が不足しているという話です。

1-B-b. レベルデザイン のところで「ほとんどのスマホのハイパーカジュアルゲームでは、プレイ時の操作方法は 1 種類のみ」って書きました。
そして世の中のほとんどのゲームは、あなたが今作ろうとしているものも含めて、「パズルゲーム」 「アクションゲーム」 「RPG」などの既存のカテゴリのどれかに当てはまります。

(どちらも当てはまらないのは、まったく新しい革新的なゲームである可能性は否めませんが、高確率で「ほとんどのユーザーにとって激しく馴染みづらいもの」になると思います。そういうのは、趣味でやりたいなら止めませんが、ビジネス的には任天堂さんに任せておいたほうが身のためです)

なので、操作方法とカテゴリのそれぞれ、またはどちらかで、あなたのゲームにはほぼ必ず「以前にヒットしたことがある、どこかしらが似ているゲーム」が存在しているはずです。

なのに何故それを探さないのか、探してやり込んで、面白さの源泉を理解しようとしないのか。
参考にすべきゲームが複数あったら、ヒットしてるゲームに共通している要素は何なのか、もっと深掘りすると「ヒットしてるゲームに共通している、やってないこと」は何なのか、など考察しないのか。

例えば最近のゲームだと、いわゆる "Good" 以上の "Great" なプレーを 1 回または複数回連続で達成したときには、自機を光り輝かせて、得られるポイントを一時的に倍増させているものが多いです。
一時的にフィーバーモード突入みたいな。
脳汁出ますね〜。

また、ちょっと気持ちいい瞬間には微弱な、わりと気持ちいい瞬間にはちょい強めの、バイブレーションを入れているゲームが非常に多いです。
いやなユーザーもいるので、トップ画面から 1-2 階層下ぐらいで、バイブの ON/OFF を設定できるゲームが多いなってことも、注意深くやってればわかると思います。

ぼくはゲームを丸パクリすることは反対ですが、要素要素に関しては過去のヒット作を、それも時期的に近いヒット作を参考にすることは全然アリだと思っています。
なぜならユーザーにとって、それらの要素はすでに慣れ親しんだものなので、いちいち新しい学習をする必要なく、そのゲームの面白いところにすぐに入っていけるからです。

すぐやりましょう。

3. チーム

これは特に日本で顕著なんですが、インディデベロッパというよりは個人デベロッパさん、その名の通り、ひとりで全部やりすぎです。
個人的にはある意味リスペクトしている面もあるのですが、2018 年にそのスタイルは正直かなりキツイと言わざるを得ません。

iPhone 出たての頃と違って、巷にはますます多くのハイクオリティなゲームが溢れています。
ソシャゲほどではないにせよ、ヒットしている、チャートで上位にいる、広告をぶん回している、つまりユーザーの目に触れる機会がより多いゲームは、ほぼ全てがかなりのハイクオリティ (儲かっているからこそ実現できるクオリティ) です。

相手のプロジェクトには、最低でもエンジニアリングとデザインに専念する人が 1 人ずつアサインされています。
あなたが 1 人でゲームを作っていたとして、エンジニアリングとデザインの両方、彼らと同等レベルのクオリティで仕上げることは出来ますか?

また、仮にそれが出来たとしても、完成させるまでにめっちゃ時間かかりませんか?

全てのアプリをヒットさせることなんて到底できないので、ヒットするまで数回程度は失敗 (作ったゲームがヒットしない) することは最初から織り込んでおかないといけません。
同じ期間に、相手は倍以上の数のアプリをリリースして、何をやったら上手くいくのか、何がダメなのかというノウハウを溜めてきます。

数回の失敗を許容できるようなキャッシュが無いと、目先の売り上げを作るために未完成の状態でアプリをリリースせざるを得なくなります。
当然ながらクオリティが十分でないため、継続率や ARPDAU は本来よりも低い水準になり、LTV が相対的に低くなり、そうするとプロモーションも満足にかけられず、結果として売上もそこまで上がらないという悪循環になりかねません。

ひとりで作りたいという開発者さんがいることは理解しています。
作りたいものを作る、自分のペースで作る、コミュニケーションによるストレスを感じずに作る。
そのプロセスが何よりも優先すべきことなら、それは尊重されるべきです。

ただ、ビジネス的に成功させようと思うのであれば、 1 人で全てをカバーすることは早く諦めてください。

自分は自分の最も得意な領域にフォーカスできるよう、最低でも一部の業務は外部に委託 - でもそれだとコミュニケーションや品質コントロールの面も含めて高コストになってしまうので、理想はやっぱり 2 人以上でチームを組んで開発すべきです。

最低でもエンジニアとデザイナー (グラフィックとレベル・ゲームデザインの両方が出来ると望ましい)、できればそこに企画・ディレクション・キャッシュフロー・広報宣伝など担当できるビジネスサイドの人が 1 人いて、3 人チームぐらいでキックオフしたいところですね。
(エンジニアとデザイナーはもうちょっと多くても良いかも。作りたいゲームと進めたいスピード感によっては。キャッシュが許すのであれば)

インディでもイケてるアプリデベロッパーさんの多くは、洋の内外を問わず、そういう体制でスタートしているところが圧倒的に多いです。

パートナーを探すのは簡単ではないですが、少なくともコード書いたことがないビジネスマンが起業時にエンジニアを見つけるよりは簡単なので、頑張りましょう。
基本的には色んなところに (オンライン・オフライン問わず) 顔を出して、パンチを打ち続けるしかないと思っています。

逆に 1 人でもうまくやれてるところは 2 つのパターンしかなくて、1 つは必要なリソースを遠慮なく外注しているタイプ、もう 1 つは個人のアート性が競争力の源泉になっているタイプです。



ちなみに最後にちょっとだけ自分の話もしておくと、僕は最近世界中の「いいゲームは作る力はあるんだけど、プロモーションやマネタイズがよく分からない、またはキャッシュフローに課題がある」インディデベロッパを、なんとか大人の力でw手助けするっていうのを生業にしています。

決してボランティアとか趣味とか副業ではなく、これが僕のメインの仕事なので、何かしら困ってるデベロッパーさんはほんと気軽に @tatsuosakamoto まで連絡してきてください。

逆にそこ変に遠慮されて、本当は世界を獲れるポテンシャルあるゲームが結果的に埋もれてしまうっていうほうが悲しいのでね。


というわけでめちゃ長くなったけど、この記事が世界を目指すハイパーカジュアルゲームデベロッパーさんの助けに、少しでもなっていれば幸いです!
一緒に世界とりに行きましょう!!

この記事が役に立った!という方は、よければ下記ボタンから投げ銭 (300円 | クレカ払い) をお願いします!ぼくのモチベーションが上がって、また良い記事を書くかもしれません!w



Q