変化の時代で勝つための開発組織のあり方株式会社 Aiming

ジェネラルマネージャ / テクニカルディレクター

2011年12月22日 於代々木系 （開発）

小林 俊仁 ( @toshi_k )

About: 小林 俊仁@toshi_k

http://about.me/toshi_k

オンラインゲームを作って早10年

人と人のつながりがデータとして見える世界が超おもしろくて

Community Engine でオンラインゲーム作って (2001~2003)、中国で子会社作ってモバゲータウンの中国版（加加城）とか Play Online China とか作って (2003~2007)、子会社を閉じて日本に帰ってきて、その後オンゲの技術ディレクターとかプロマネとかやってた (~現在)

About: Aiming

今年の5月にできて、今 169人。

オンラインゲームに必要な、企画・プロデュース・開発・運営アライアンス・海外展開等の機能が丸っと揃った組織。

About: Aiming のプロダクト作り中のものを含めると

スマフォ: 6

Web (HTML5+JS): 1, Web (Flash): 5

PC: 1

ジャンル（全てオンライン）

MMOG, MOG, クエストクリア型, ストラテジー, 街ゲー, アクション, etc...

About: Aiming の開発組織

大阪スタジオ:JSS (1998~オンゲ) → Dwango (2000~) → Games Arena (2006~) → ONE-UP (2010~) → Aiming (2011~)

東京スタジオの開発グループ:JSS → Community Engine (2000~) → ONE-UP (2010~) → Aiming (2011~)

Aiming の技術ポートフォリオ

言語など

C#, C++, Objective-C, Java, etc..

Ruby, PHP, JavaScript, ActionScript, HTML5 etc..

リアルタイム通信技術, 3DCG

開発環境・ツールなど:

git, gerrit, Jenkins CI, etc..

Unity, DirectX, etc..

市況変化人組織市況変化

機会

非連続な市況変化非連続な変化は常に外からやってくる（ゲーム業界）

3D屋 → 2Dゲーム市場の破壊

家電屋（CD-ROM） → マスクROMゲームの流通の破壊

Web屋（ソシャゲ） → 3D据え置きゲーム市場の破壊

電話（スマフォ） → ポータブルゲーム機市場の破壊

多くの会社が変化に対応できずに滅亡していった

未来予測ではなく変化の利用

「破壊的イノベーションに直面したときに打ち出す戦略と計画は、実行するための計画というより、学習し、発見するための計画であるべきだ」by クレイトン・クリステンセン イノベーションのジレンマ

「Acquisition cost. NOT revenue predictions.」by Dave McClue, 500 Startups

「未来を予測するだけでは混乱を招くだけである。なすべきことは、すでに起こった未来に取り組み、あるいは来るべき未来を発生させるべく働くことである。」by P. F. Drucker 創造する経営者

今起ころうとしている変化スマフォの隆盛 → みんなが携帯用ゲーム機持って歩いてるようなもの

投資額の変化 → 携帯ソーシャルよりは多額、コンソールよりは少額

グローバル化

カジュアルなユーザの増加

全てがオンラインに

ソーシャル → バイラル、バトル、協力

KPI 分析

組織人組織市況変化

機会

最適化と陳腐化の構造優秀な組織は成長する市場において価値を生むプロセスを確立しようとする

先鋭化スパイラル（と呼ぼう）

既存顧客が歓迎する高度化・美麗化 → 喜んだ → もっと高度に、美麗に…

特定の市場や顧客や製品に対する組織の最適化

しかし、あらゆる活動は陳腐化する

→ 明日の成功を阻むのは、昨日の成功体験である。

→ 優秀な組織ほど変化への耐性が弱い？？

諸行無常例:

過去に大作 RPG を何本も当てた会社があった。既存のヒットに満足せず、利益を再投資して複雑・美麗なゲーム開発し、ファンの要望に応えていった。大きくなる市場と共に、投資規模は十億～数十億、チームメンバーは数十～100人以上で1本のゲームを作る体制になった。 組織はこのために最適化されていった。 これは先鋭化スパイラル（前述）であった。

携帯のソーシャルゲームが芽を出し始めた頃、新しくゲームを手に取りはじめた携帯ユーザは、彼らの目には入らなかった。既存顧客の満足を高める。これは彼らにとっては正しい判断だった。

しかし、変化は急であった。気がつけば、市場ではオンラインやソーシャルの売上がコンソールゲームの売上を抜く会社も出てきた。組織論において、大が小を兼ねることはない。過去に最適化され、硬直化した組織の危うさに気づいた一部の社員は脱出した。気がつけば「重厚長大にしか作れない開発チーム」と「重厚長大なゲームにしか go を出せない経営者」が残っていた。

なので考えるべきことは？起こりつつある変化を見て見ぬふりをしていないか

変化を発見するには何をしたらいいか

変化を利用するには何をしたらいいか

変化に有限な経営資源を割り当てるには何を捨てなければならないか

それにはどういう組織・人であるべきか

1. 意識的に廃棄する経営資源は有限である

ゼロベースで廃棄する

もし過去のしがらみが何も無いと仮定したら、今これを始めるか？No であればやめて新しいことをやる

技術の選択においても同様

僕らは C++ の会社だから、僕らのプロダクトは全部 LAMP だから→ これらはしがらみと捉えてもよい

でも、固執する人もいたりする（本当に組織や製品のため？ 自分の価値の保全では？）

2. 多様性を高める

「戦闘単位としてどんなに優秀でも、同じ規格品で構成されたシステムは、どこかに致命的な欠陥を持つことになるわ。組織も人も、特殊化の果てにあるのは緩やかな死」by 草薙素子, GHOST IN THE SHELL / 攻殻機動隊

2. 多様性を高める組織の中の多様性の価値: 変化を受け入れる力をくれること

変化への対応が迅速に : X が流行るかも → それはもう A さんが使って遊んでたよ → じゃあ A さん中心に研究チームを組もう

単一のプラットフォーム、単一の技術や言語、単一の国 等と心中しない

Aiming の場合:

Web野郎、Game野郎、リアルタイム通信野郎、インフラ野郎とかいろいろ

Unity, Ruby on Rails, Flash あたりに乗っかってるけど「変えるかも」前提

結構外国人もいる。台湾オフィス設立 (2012.1-2月), フィリピン子会社設立 (2012.春)

3. 機会を探す

Aiming におけるプロジェクトの起こし方

ゲームの根幹を考える時：超マーケットイン

開発中：超プロダクトアウト

売る時、サービスする時：超マーケットイン

アジャイル開発

変化を受け入れるのはプロジェクトにおいても同じ

Agile 開発 : ムダとケンカと失敗を最小限に抑え、ソフトウェア開発で幸せになるための手法

「早すぎる完璧」に対する防御

変化のプロセス化

チームのものを増やす

チーム対問題の原則

問題の理由を個人に求めない

見積もりポーカー → 見積もりをチームのものに

工数を1人で見積もらず、皆の意見が一致するところまでやる

KPT の把握 → 反省・問題・続けることをチームのものに

コードレビュー (gerritを使用) ・ペアプログラミング → コードをチームのものに

1つのコードを複数人が見るようにし、「お前のコードが悪い」をなくす

目的志向の組織縦割り組織の弊害

「失敗の原因を求めやすいあちら側」ができる

結果、試行錯誤ができずクソゲーを作ってしまう

「技術的にムリって警告したのに直さなかった企画が悪い」「いやいやリスクをちゃんと説明しなかった技術が悪い」など

Aiming の場合: 目的志向の席配置

一丸となって目的を達成すべき人たちを近くに

プロジェクトベースは変化への対応サイクルが早い

ツッコミビリティの担保よくある失敗 :

トップダウンすぎる組織でチームと製品が大規模化 → 一人の人間が把握することが困難に → 裸の王様と、諦めちゃった部下

Aiming の Practice : ツッコミビリティの確保

→ 問題に気づいた人がツッコミを入れられるような、適度なユルさ。「これそもそもおもんなくね？」を含む

問題の findability をチームで担保する、という考え方

メールよりチャット

人人組織市況変化

機会

自律的なチームの構成員

やれるやつが、やれることをやる

要リーダーシップ

リーダーシップに関する間違いNOT「組織の管理者 ＝ リーダー」「仕切り屋 ＝ リーダー」

Change Leader = 変化を引き起こす人

部下AがXを提案した。部長Bは承認した。 → リーダーは X の推進者たる B

NOT 「スキルがまだ足りないからリーダーになれない」

自分のスキルセットに満足する日など来ない。

仕事は、スキルが充分な人ではなく、責任範囲を広く取る人のもとに集まる

NOT 「私はリーダーに向いていない」「私はリーダーではない」

→ 分解すると、メンバーは何らかの部分でリーダーシップを取り得る

リーダー

責任範囲を広く取る人

目的達成のための立場を取る人

他者に貢献する人

T型人間の価値リーダーシップを取るには他者への理解が必要

理解が無いと否定から入る：「DB 設計のせいだ」 → ケンカ

自分の専門分野に加えて、他社を理解できる程度の広く浅い知識が必要

好奇心が組織の多様性を作り、多様性は変化を受け入れる力をくれる（先述）

Aiming の場合: 週1回の勉強会

テーマの多様性がすごい : dotfiles 晒し, 本の紹介大会, UX / UI, マーケティング, デッサン, LT大会, 作曲, インフラ, ゲームエンジン, Webの脆弱性, etc...

個人への興味（技術者採用）

会社の仕事として何に参加したか、にはあまり重点を置かない

MBA 取ってようが大学院出てようが高卒だろうが中卒だろうが関係無い

「あなたが実際に生み出した価値は何か、何が好きか」に興味がある

技術者採用における評価ポイント：

github のコード、OSS への貢献、オレオレスクリプト、作りかけの dog food、ブログ、 Twitter, etc...

最後に

チームと人の価値について小林の体験:

Community Engine → ONE-UP → Aimingと変わったが、開発メンバーは少しずつ増えながら脈々と残り、今に至る。

会社はただの箱。 チームと人にこそ価値がある。箱の持ち主（株主）の論理では人を制御できないということを実感した。

小林のコミットメント:

なのでチームと人の価値を最大限に高めること、皆が最高にパワフルに働いて成果を出せる環境を作ることに対してコミットしている。

ありがとうございました。株式会社 Aiming

ジェネラルマネージャ / テクニカルディレクター

2011年12月22日 於代々木系 （開発）

小林 俊仁 ( @toshi_k )