もう、生涯何度買い直しているか分からない『横井軍平ゲーム館』を
中古で購入し、読了しました。
横井軍平さんは、マジックハンド、ゲームウォッチ、ワイルドガンマン、
ゲームボーイを生み出した、元任天堂の超天才プロデューサーです。
これまた天才で、ピクミン、ゼルダ、ドンキーコング、
スーパーマリオブラザーズのプロデューサーである宮本茂さんの師匠でもあります。
残念ながら、1997年に北陸自動車道の事故により
非業の死を遂げられたのですが、彼の商品開発の歴史を振り返る本書は
現在でもとても示唆深い内容になっています。
繰り返し読んでいる本のひとつですが、毎回新鮮な発見があります。
- プロデューサーは技術を広く浅く理解しなければならない
横井軍平さんというと、「枯れた技術の水平思考」があまりにも有名ですが、
本書の末尾になるプロデューサーとは何か？という章も面白いです。
その中の一節に「プロデューサーは技術を広く浅く理解しなければならない」という
一節が出てきます。
この言葉には「例えば半導体の、回路図のように専門的なことは専門家に任せればいいが、
プロデューサーは少なくともその技術の原理は理解していなければならない」と続きます。
このスタンスは実は宮本茂さんも同様で、元任天堂社長であるの故・岩田さんが
ほぼ日刊イトイ新聞の対談企画でこのように表現しています。
宮本さん自身も自分の仕事のスタンスを解説しています。
それをまた岩田元社長がついで、こう表現します。
いずれも、「宮本茂はどういうふうに構造をつくっていくのか」より。
- 劇的に変わる開発効率
さて、このようなスタンスのプロデューサーがいると変わるのが、
開発効率です。
現在欲しい機能もそうですし、将来に関わる技術的負債も減るでしょう。
僕自身、現在アドテクプロダクトのプロデューサー職になり、
経験的に、以下のように思います。
自分のアイディアが、
1)「フロント」「サーバ」「DB」「インフラ」のどのレイヤーで実現されるのか？
2)「既存資産で実現可能」「既存資産にちょっと改変すると実現可能」
「既存資産に大きく影響を与えて実現可能」「全く新規の拡張を行って実現可能」
のどれに該当するか？
3)既存資産のうち、どこのシステムに関わるか
という3点を抑えられていて、チームの稼働状況を把握できていれば
エンジニアに相談する時に理解してもらいやすいです。
誰かにアイディアを相談された時も、
「すぐに実現できると思う」
「できるけど時間がかかると思う」
「できるだろうけど時間がかかるし難易度が高いと思う」
という目測を立てて大まかに答える事ができます。
ちょっとした雑談なのに、毎回「エンジニアに工数を確認します」だと、
見積もるサイドもやってらんないでしょう。
もちろん、全然検討がつかない時もあって、その時はエンジニアに相談するし、
正式にいつできるのかはエンジニアが見積もるべきだと思います。
技術が分からないアドテクプロデューサーは、
楽器の特徴が理解できない音楽プロデューサーのようなもの。
優れたビジネスセンスに加え、こうしたスキルも僕のチームでは
つけていって欲しいと考えています。
中古で購入し、読了しました。
横井軍平さんは、マジックハンド、ゲームウォッチ、ワイルドガンマン、
ゲームボーイを生み出した、元任天堂の超天才プロデューサーです。
これまた天才で、ピクミン、ゼルダ、ドンキーコング、
スーパーマリオブラザーズのプロデューサーである宮本茂さんの師匠でもあります。
残念ながら、1997年に北陸自動車道の事故により
非業の死を遂げられたのですが、彼の商品開発の歴史を振り返る本書は
現在でもとても示唆深い内容になっています。
繰り返し読んでいる本のひとつですが、毎回新鮮な発見があります。
- プロデューサーは技術を広く浅く理解しなければならない
横井軍平さんというと、「枯れた技術の水平思考」があまりにも有名ですが、
本書の末尾になるプロデューサーとは何か？という章も面白いです。
その中の一節に「プロデューサーは技術を広く浅く理解しなければならない」という
一節が出てきます。
この言葉には「例えば半導体の、回路図のように専門的なことは専門家に任せればいいが、
プロデューサーは少なくともその技術の原理は理解していなければならない」と続きます。
このスタンスは実は宮本茂さんも同様で、元任天堂社長であるの故・岩田さんが
ほぼ日刊イトイ新聞の対談企画でこのように表現しています。
宮本さんは、コンピュータやプログラムについて
体系的には学んでいないはずなんですけど、
コンピュータが非常にシンプルだった時代から
いろんなことを経験してきていて、
自分のやりたいことを実現させるために、
道具であるコンピュータのことは
ちゃんと理解しているんですよ。
宮本さん自身も自分の仕事のスタンスを解説しています。
そうですね。
あの、コンピュータをまったく知らない人って
やっぱり、無謀なことを提案してしまうので、
どうやってつくればいいのかが
本人にもまわりにもわからないんですよ。
だからぼくは、思いついたことを、
「こういうふうにしたらできませんかね？」
っていうのとセットで持っていくんです。
そういうことが、ぼくの仕事ですね。
ふつうに仕様を出すと「それは無理です」って
言われるようなことも、原因を探っていくと、
できるような形が見えてきたりします。
たとえば、ピクミンの仕様を出すとき、
「ピクミンはいろんなものを自分で考えて巣に運ぶ」
というと、中間に入ってるディレクターは
「それはたいへんです、そんな簡単にはできないです」
って答えたりするんですけど、
「網の目のようにルートを引いておいて、
最短のルートを検索できる？」って訊くと、
プログラマーは意外と
「あ、それならできます」
って言うようなことがあるんですよ。
それをまた岩田元社長がついで、こう表現します。
だから、たとえば、
「できない」って言うプログラマーがいたときに、
「なんとかしなさい」って言うんじゃなく、
「どういう仕組みになってるの？」って訊くんですね。
すると、仕組みを説明されるので、
「じゃあその仕組みをこう利用したら
こういうことはできないの？」って提案すると、
「それならできます」ってなるんです。
いずれも、「宮本茂はどういうふうに構造をつくっていくのか」より。
- 劇的に変わる開発効率
さて、このようなスタンスのプロデューサーがいると変わるのが、
開発効率です。
現在欲しい機能もそうですし、将来に関わる技術的負債も減るでしょう。
僕自身、現在アドテクプロダクトのプロデューサー職になり、
経験的に、以下のように思います。
自分のアイディアが、
1)「フロント」「サーバ」「DB」「インフラ」のどのレイヤーで実現されるのか？
2)「既存資産で実現可能」「既存資産にちょっと改変すると実現可能」
「既存資産に大きく影響を与えて実現可能」「全く新規の拡張を行って実現可能」
のどれに該当するか？
3)既存資産のうち、どこのシステムに関わるか
という3点を抑えられていて、チームの稼働状況を把握できていれば
エンジニアに相談する時に理解してもらいやすいです。
誰かにアイディアを相談された時も、
「すぐに実現できると思う」
「できるけど時間がかかると思う」
「できるだろうけど時間がかかるし難易度が高いと思う」
という目測を立てて大まかに答える事ができます。
ちょっとした雑談なのに、毎回「エンジニアに工数を確認します」だと、
見積もるサイドもやってらんないでしょう。
もちろん、全然検討がつかない時もあって、その時はエンジニアに相談するし、
正式にいつできるのかはエンジニアが見積もるべきだと思います。
技術が分からないアドテクプロデューサーは、
楽器の特徴が理解できない音楽プロデューサーのようなもの。
優れたビジネスセンスに加え、こうしたスキルも僕のチームでは
つけていって欲しいと考えています。