力学:全てに通じる考え方

力学。

 

世の中の人はこれを明確に意識して考えている人がどれぐらいいるのだろうか。

 

僕が知らないだけでそんなことはすっかり常識なのだろうか。

 

僕が「力学」と呼んでいるものは他の人は違う呼び名でよんでいるかもしれないが、ここでの意味は

 

人間の性質から「こうすればこうなる」という自然な成り行き

 

といったところ。

 

人間の性質とは

  • 何かを得たいという欲求
  • 何かを避けたいという欲求

みたいなもので、大半の人にとって(意識する・しないに関わらず)自然にそう思ってしまいがち、やってしまいがちなこと。

 

これを理解するための例はきりがないほどあるが、色々あげてみたい。

 

野菜の販売

売る側のコストは度外視して、買う側の気持ちと売上回収率について考えてみる。

 

買う側の欲求

  • 野菜が欲しい
  • お金は払いたくない

 

 

1.八百屋で売る。

八百屋は店員が対面で売るので、商品を選んでお金を払う流れがセットになっている。

提供した野菜と売上のトレードが完全に一致し、売上の回収率はほぼ100%だ。

 

2.無人販売所で売る。

お金を払う行為が買う側の良心に依存している。

店のオーナーと知り合いでもないし、監視カメラもない。

おそらく売上の回収率は70〜90%程度だ。

お金を払いたくない理由も掘り下げると一つではないだろう。

  • ケチ
  • 財布からわざわざお金を出すのが面倒くさい
  • お釣りが必要(だが無人なのでお釣りがなく、払い過ぎになってしまう)

3.無人販売所で、毎月持っていった野菜代金を自分で合計して月末にまとめて払う。

実際こんな例は存在しないと思うが、こんなの超絶面倒くさい。

自分で記録しないといけないし、支払いのタイミングも強制される。

そもそも購入数が下がりそうだが、この回収率も低そうだ。

「お金を払いたくない」気持ちをガンガン煽ってくる仕組みだ。

 

同じ「野菜と引き換えにお金を得る」行為なのに、「仕組み」が違うと売上回収率が変わってくる。

 

次はもう少しビジネスに近い例を。

 

ゲームの開発会社との契約

ゲームのパブリッシャーはしばしば自社でゲーム開発をせず、デベロッパー(開発会社)に開発を委託する。

 

委託は「契約」「支払い」といった要素で成立する。

パブリッシャーの立場からすると、開発は遅れては困るし、手を抜かれても困る。

 

まず、デベロッパーがどのようにして収益・利益をあげているかを理解する必要がある。

 

デベロッパーは、提示されたゲームを開発するための人件費を内部で見積もり、そこに5〜10%の利益を載せてパブリッシャーに対外的な見積もりとして出す。

 

締切に遅れず、期待されたクオリティで納品できれば成功だ。

 

もしデベロッパー自身の責任で納期が遅れると自己負担の人件費がかさみ、あっという間に想定利益5〜10%を食いつぶしてしまう。

 

では、デベロッパーの力学はどうなるか。

 

人件費を提示額よりも低く抑えたい

 

人件費を低く抑えると、利益率があがり、バッファが大きくなる。

内部では手を抜いたり他のプロジェクトを兼務していたりしがちだ。結果品質は落ちる。

また、社員の給料も上がりにくい。

 

そこで、契約の成果や支払いの定義は力学を考慮したものになる。

(契約には他にもいろいろな要素があるが、ここでは支払いに関してのみ)

 

1.マイルストーンに分ける

開発の途中経過を定義し、その物量とクオリティに達した場合に支払いをする。

開発費1億円を5分割して支払うようなイメージだ。

そうすることで、開発期間中ずっと緊張感を保つことが出来る。

 

2.マイルストーン支払いの比重を変える

何でも仕上げのクオリティが一番肝心だし、意外にコストがかかる。

後半に向けて支払額の比重を少し重くすることで、ラストスパートの熱量を上げる。

 

開発の成果 と 支払い という意味ではどのタイミングで支払っても全くかまわないように見えるが、力学が結果に大きく影響するのでそれを意識して設定する必要がある。

 

例えば、最後に完成したら一括で支払いするというような場合は、デベロッパーが頑張る力学が最高になるが、デベロッパーの資本体力が持たなくなる場合があるので現実的ではない。

小さな案件などに限りこのパターンで大丈夫なことが多い。デベロッパーがそう言ってくる場合は自信と覚悟と体力があるということだ。

 

逆に、開発開始時に一括で支払うとするなら最悪の結果をもたらす。デベロッパーからすればもうお金をもらっているので、頑張る力学がまったく発生しない。

 

また、売上に対してインセンティブを定義するのも定石だ。

デベロッパーはパブリッシャーと違い、売上に責任は持たない。

ゲームを作って渡せばそれで終わりだ。

しかし、例えば

10万1本から売上の3%をデベロッパーにインセンティブとして支払う

といった定義をしていれば、デベロッパーは売れるものを目指して頑張る力学が生まれる。懸念するデベロッパーの人件費出し惜しみへの抑制になる。

 

パブリッシャー社内のマイルストーン評価システム

これは今の会社で実際にある現象だ。

社内・社外の開発中のゲームは、進捗が芳しくなく、見込みが無ければクローズする。

そのため、全プロジェクト共通のマイルストーンをいくつか設け、クリアすべき要件を厳密に定義する。

最終的にクオリティの高いゲームのみを市場に出すというまっとうな考えのもと作られたこのシステムも、なかなか理想通りにいかない。

なぜか。

 

1.ゲームの作り方、順番が違う部分がある。

要件の定義が時期に合っていないこともある。

例えばガチャの商品としての絵があると大量に絵を発注しなければならず、開始時期、準備時期も逆算的に求められる。一方、絵が売りでなく、スタミナや時短のみがゲームの課金ポイントであるなら、絵のコスト比重は高くないし、準備や最終決定は結構後でもかまわない。

それを、中間時期で同じ基準で判断はできない。

これは力学というより柔軟性の欠如というべきものか。

 

2.要件をクリアするための努力をし、本当のクオリティアップに貢献しない。

こちらが力学による弊害だ。

本来クオリティアップのために設けられたシステムだが、サラリーマンはそのシステムをクリアするために、動いてしまう。

無駄な労力を割いたり、本来あるべき開発の順番を変えて対応してしまったりする。

 

これはどこか

 受験対策をする(手段) ≠ 地頭をよくする(真の目的)

と似ている気がする。

 

まあ、とにかく、世の中は力学を考えないといけない。

 

わかっている人は情報があればあらゆることの予想の精度があがると思う。

 

力学を言語化して明確にすると、予想の根拠も言語化できる。