2011-12-18

※最後に2つ追記しました。

この話面白い。

11の「やめたこと」で実現した1000万ダウンロード突破【スマホ2011冬】 - デジタル - 日経トレンディネット
http://trendy.nikkeibp.co.jp/article/column/20111215/1039018/

スマホゲームアプリの開発を命じられたのは、東日本大震災直後の今年3月。
出された課題は
「4月から開発に着手し、7月末までに70タイトルそろえる」
「開発スタッフは既に決まっている人間で進める」
「8月にTVCMなど大々的なPRを行うため遅延は許されない」の3点

『11のやめたこと。』

1.「組織の細分化、階層化をやめる」
マネジャーが増えるということは、ゲームの作り手が一人減るということ。
優秀な人間がマネジャーになるほど、アプリの制作力は低下する。

2.「職種別の目標設定をやめる」
プログラマー、企画など職種別に目標を設定すると、
自分の担当部分しか見なくなる。
評価はまずそのアプリの完成度に注目。
その中で自分がどれだけ貢献したかというポイントに変更した。

3.「作業量の見積もりをやめる」
作業する本人が3日間徹夜で仕上げるつもりでも、
上司はバッファを見て一週間と報告してくることが多い。
どんどん仕事を依頼し、本人が「ここが限界」と自己申告すれば、
そこまでにする「ギブアップ申告制」に変更。

4.「スケジュール管理をやめる」
スケジュールありきだと、
だれもがクオリティーよりスケジュールを優先してしまう。
スケジュール表をまとめただけで仕事をした気になってしまうのも問題。

5.「データ分析をやめる」
過去のデータを分析しても新しいアプリは生まれない。
消去法でアプリを作成すると、センスのある人間の意見がつぶされてしまう。

6.「お客様のご意見どおりのアプリ変更はやめる」
お客様のご意見は、あくまでもアプリに問題があるかどうかのバロメーターとする。

7.「メンバーの教育はやめる」
優秀な人間を教育担当にするほどチームの制作力は低下する。

8.「承認はやめる」
「○○さんがいいと言ったので」という甘えを断ち切る。
常に危機感のある状況にする。

9.「アドバイス／助け合いはやめる」
分かっていない人間に理解させるより、
分かっている人間が作業したほうが早い。
問題点は「ここがよくない」とストレートに事実だけを伝える。

10.「会議をやめる」
時間の無駄。制作チーム同士の席を近くするだけで問題ない。

11.「報告書をやめる」
自分自身がプロジェクトの進行具合を知りたい担当者のところに、
知りたいタイミングで歩いていけばいいだけ。

この記事だけでは細かいことまでわからず、
以下憶測で書きますが
これ、たぶん｢最初から開発終盤体制｣なんですよね?

最初から開発終盤に追い込まれてたら凄い

ゲーム開発に限らず、たいていのプロジェクトは
締め切り終盤のときに物凄い効率的な進捗を見せるじゃないですか?
終盤は普通にやってたらどうやったって締め切りに間に合わないので
残業するわ、泊まりこみするわ、
もうその段階でだらだら会議なんかやってられないし
進捗報告は現場が報告書作るひまあるわけなくて
プロジェクトリーダーが直接聞きに来るしか無い。

教育にかまけてる時間は1秒もないし、
出来る人がどんどんやる、作業量の見積もりも何も
｢どう計算しても間に合わない｣のだから
全員が｢ギブアップ申告制｣。
つまり、せっかく用意したどの機能やエリアやキャラクターを
泣く泣く削るか、クオリティを落とすかの妥協を
スタッフの意地でどこまで抑えることが出来るかどうかの瀬戸際。

この段階では、組織の階層化も縦割りも関係なく
(社員が悪さしないよう)セキュリティのために作った
いろんな社内ルールを無視するのも効率のもとに黙認されて
現場同士が勝手に壁を破って密につながり、
普段なんにも発言しない人達も衝突構わずガンガン口を開く。
そのときまで判断に迷ってるような細かい案件は
プロジェクトリーダーの承認待ちではなく、
現場のやった者勝ち(あるいはやらずに切り捨てたもの勝ち)です。

こういう開発終盤の追い込みの物凄い効率化は、
現場の物理攻撃とスピードにステータスを極振りしたみたいで、
(HP消費も凄いけど)
｢絶対間に合うわけない｣という段階から、劇的な効果があります。
締め切りの力というのか、別に残業や泊まり込みがなくても
｢最初にこの力が発揮されてたらなあ｣と悔やむほど
終盤の追い込みは凄いです。

ではなぜ、この目の前にある｢銀の弾丸｣はギリギリまで使われないのか?
もちろん締め切りギリギリまで体力温存しておきたいとか、
なるべくリスク回避して、衝突もしたくないとかもありますが
それだけならどうにか改良できそうですが、そうじゃない。

もう少し具体的に言うと、
なぜ会社は、非効率な｢管理主体｣の組織構造になるのか?
なぜ、効率的な｢現場主体｣の組織構造をわかっててもできないのか?
を考えます。

ハンゲームチームの危険性

現場生産効率100%主義で、
｢管理｣や｢教育｣などの雑事を捨て、見事一定の市場を手に入れました。

これは彼らを管理する｢会社｣にとって脅威です。
このやり方で、実績を2〜3積んでしまうと
そのチームは会社の管理がなくても、
明確な目標と資本金があれば高い生産性で結果を出せるということになります。
つまり管理を必要としない｢出来る人達だけ｣で独立が可能になり、
そのうえ｢教育｣や｢ノウハウの伝達｣が軽視されてるから独立後のダメージが大きい。
(PS1時代は結構こういう大手内からの実績ある独立チームが新会社をたくさん作りました)

もちろん優秀な人材の独立を防ぐには、
それなりの報酬を支払えばいいのですが
この結果の場合、
現場の上に立つ管理者(マネージャー)なしで達成したわけです。
つまり現場の出来る人達は、上司である管理者より給料が高くないと
いずれ働きに対して割が合わないようになってくる。

じゃあ、管理者より現場に給料多く払うとすると、
他のチームも、｢管理｣と｢教育｣を捨てたやり方をしたいと言うでしょう。
そうなると出来る人と出来ない人でコミュニケーションや協力はうまれず、
常にギスギスして、離職率高いモラルハザードに近くなって、
管理者の立場がなくなり、組織図変更の大きな軋轢を生み出す。

するとこの優秀な｢出来る人達｣にちゃんとした給料を、
周りが納得するよう払うには、
その人達を｢管理職｣に上げて下の｢指揮｣や｢教育｣に重点を置いてもらうほうがいい。
こうすると、管理職として上司として適切な給料を与え、
かつ｢会社｣の底上げとしての｢ノウハウの教育｣がつちかわれ、
一人のヒーローに頼るのではなく、
｢会社全体としての力をつけていこう｣と舵をとれるわけです。

ま、これが結局はピーターの法則にはまって、
非効率な管理会社になる考えで、

ピーターの法則 - Wikipedia

1, 能力主義の階層社会に於いて、人間は能力の極限まで出世する。
　すると有能な平（ひら）構成員も無能な中間管理職になる。

2, 時が経つに連れて人間は悉く出世していく。
　無能な平構成員はそのまま平構成員の地位に落ち着き、
　有能な平構成員は無能な中間管理職の地位に落ち着く。
　その結果、各階層は無能な人間で埋め尽くされる。

3, その組織の仕事は、まだ出世の余地のある、
　無能レベルに達していない人間によって遂行される。

ハンゲームチームはこの法則の逆をやったから乗り切ったのですが。

1.「組織の細分化、階層化をやめる」
マネジャーが増えるということは、ゲームの作り手が一人減るということ。
優秀な人間がマネジャーになるほど、アプリの制作力は低下する。

7.「メンバーの教育はやめる」
優秀な人間を教育担当にするほどチームの制作力は低下する。

9.「アドバイス／助け合いはやめる」
分かっていない人間に理解させるより、
分かっている人間が作業したほうが早い。
問題点は「ここがよくない」とストレートに事実だけを伝える。

ピーターの法則にはまらずに、優秀な人材を引き止めるには?

現場のままでいいから、管理職以上の給料を払う。

本来優秀なプログラマーは、
無能なシステムインテグレーターより給料が高くあるべきでしょう。
今絶好調のDeNAなんかは、社長より給料高い人が3人いたということで
役職が給与を決めるわけじゃないということを、
最初から意識してたのかもしれません。

ただ、それをすると主体がますます出来る人依存になるので、
組織図の命令系統塗り替える覚悟が必要ですし
従来組織からの変更は必ず軋轢がでてくるでしょう。

かといって、ヒーロー依存が悪いということでもなく、
現場の宮崎駿を支えるために、その上に立つ鈴木プロデューサーとか、
本田宗一郎の開発を誰にも邪魔させないための、藤沢武夫だったり、
井深大、盛田昭夫でも現場に口出ししまくるジョブスでもいいですが、
新たなチャレンジをする場合の革新や抜本的改革をするためには
現場主体のヒーロー依存体制の方が効果高い。

もちろん、ほっといても市場やシェアが右肩上がりだったり
利益が確実に安定してるのであれば、
ヒーローに頼る必要も無いので
ミスを減らし、モラル高め、より安定するよう
安全な｢管理｣と｢教育｣の方に力を入れるべきかと。

それに、必ずしも｢独立｣を引き止める必要はないのかもしれません。

クリエーターが独立してもIPは残る

優秀な人材が｢独立｣するだけの自信と実績を積むときに
一定の市場獲得や、人気シリーズやキャラクターなどのIPとかは、
会社に残るものですから、まずそれらを安定運用したらいい。

会社が成長するに連れ、出来る卵達も入ってきますので
安定運用する部署と、
ヒーローを中心に革新していく部署を使い分ける。
ちょっと違うかもしれませんが、
コナミのように、サッカー、野球、カードゲームを確実に抑えつつ
小島監督のスタジオが革新していくと、
会社の運営は非常に安定したまま、
最先端へのチャレンジも外さないですね。

逆に、現場だけで独立してしまうと
｢現場のトップが会社を管理運営してしまう｣というピーターのワナ
にはまる独立会社も多く
｢実質社長でも開発に専念できる｣ための鈴木敏夫や藤沢武夫のような
プロデュース、財務面を任せられる人を捕まえてないと
思ったほど生産性が上がらず、独立も長く続かなかったりします。

しかし、雑多な会議や管理がないほうが
ずっと現場の生産効率が高いとすると、
そもそも多くの会議や管理は必要なのでしょうか?

会議や、管理はもちろん必要

これらの目的は、

会議で｢何を作るか(やるか。やらないか。)を決める｣
管理で｢より効率的な組織運営｣を実現する。

なのですから、大なり小なり
これらがあってこそより生産性の高い組織になるわけです。
そして生産性の低い組織になる理屈も同じ。

1,人材やスケジュールを無駄にしないため、コスト効率のための会議や管理には、どれだけコストを掛けても構わないという矛盾

無駄なコストを省きたいのはどの会社も同じで、
隣で遊んでる人なんかいたら、
一生懸命やってる人のモラルにも影響します。

それを効率化するための、会議や管理業務は仕方がないのですが、
会議や管理そのものがいつも高コストになりがちで、
今度は会議のための会議や、管理のための管理が必要になるほど迷走して
いったいいつ現場に戻って作業するんだ?
というぐらい、雑務に時間が失われる日もでてきます。

便利で効率的だと思ってFireFoxのアドオンいれまくってたら、
めちゃくちゃ重くなったようなもんですね。
一つ一つのアドオンはちゃんと便利で効率的だからこそ
なんで効率化の結果がブラウザクラッシュするのかわからないようなw

2,プロジェクトが長期化するほどひっくり返されて無駄になる会議、スケジュール、報告

会議だの、スケジュールだの、報告だのを突き詰めたら
これは現場の力を最大限にするためではなく、
プロジェクトの市場ターゲットを、
1発で正確に撃ちぬくための｢照準調整｣なんですよね。

できるだけ真ん中を撃ち抜きたいから、
締め切りギリギリまで調査して調整しなおして
これ以上時間がないところまできて、やっと砲台が固定され
市場にあった玉が開発され、磨かれて、セットされる。

でも市場という獲物は常に変化してるので、
当初の予測からはたいてい少しズレる。
照準精度を上げてるうちに、
充分な火薬や市場を惹きつけるエサを買う金が足りなくなることもあり。
照準精度を上げてるうちに、
他のライバルがほんの一瞬先に獲物を撃ちぬくこともあり。
照準精度を上げてるうちに、
獲物そのものがやせ細っていくこともあり。
二転三転と狙いがブレるとその前の会議やら調整はなかったことになり、
何度もリスケジュールされ、
時間をかけるほど問題が増えていきます。

それでもなんとか獲物をしとめれたら、
｢照準精度を上げるためのこれまでの全ての活動は正しく報われた!｣
ということになるんですけど、
実は、必要なのは
後半の砲台が固定されてから発射までの時間
の方であって、
砲台の狙いをちょっとでも良く定めるためにギリギリまで見極める前半
の作業はほとんど無駄です。

照準精度を高めるために、時間を掛けて情報を集め分析して
会議でみんな考えこむのですが、
情報を集めて分析することで命中度が上がり、
情報を集めて分析するためにかかった時間で命中度が下がり、
コストだけはどんどんかさむという矛盾。

照準のわずかな精度を高めることに時間掛けるよりも、
最初から現場の砲台の力を最大限にすることにコストを使い
獲物を見つけたらネタやアイディアが新鮮なうちに
さっさと2〜3発発射して、力強い爆風で獲物を仕留めるようなスピードを優先したら
いろんな問題を発生する前に決する可能性が高くなります。
1発打てば100回マーケティング会議するより
ずっとはっきりしたフィードバックもあるのですから、
3発目は狙いもより正確になります。

会議や管理のどこまでが効果的で、どこからがやり過ぎ、非効率なのか?

これはもう組織それぞれ千差万別でしょうが、
｢風通しが悪く、現場の生産性が悪く、業績が悪化してればやり過ぎ。｣
という最終出力の数字が目安にはなるでしょう。

会議や管理ひとつひとつを効果測定しても、
FireFoxのアドオンのようにひとつひとつは全部プラス効果だったりします。
でも全部足すとマイナスになることがある。
なので数値は最終出力に近いところを見るのが大事で、
部分の効果から判断するのは難しいでしょう。

この思想はみんながそれぞれの部品を完成するために動くのではなく、
みんなが全体を完成させるために動くという行動にも現れますね。

2.「職種別の目標設定をやめる」
プログラマー、企画など職種別に目標を設定すると、
自分の担当部分しか見なくなる。
評価はまずそのアプリの完成度に注目。
その中で自分がどれだけ貢献したかというポイントに変更した。

3.「作業量の見積もりをやめる」

とはいえ、｢みんなが一丸となって全体のために動く。｣というのは、
それこそ宇宙人が攻めてきたみたいな、
普通にやってたら絶対勝てないぐらいの目標がないと、
各国が、みんな個別最適化のバッファばかり増やして、
宇宙人に侵略されたりします。

最終出力の数字が悪いというのは、市場が悪化してる時に
目標設定が、頑張ればなんとかなる｢努力目標｣
になってるから抜け出せないのかもしれません。

答えは松下幸之助にあり?

松下幸之助名言 -
http://www.fesh.jp/detail_8029.html

５％や１０％の改善は、
時には５０％の抜本的改革よりもっと難しい。

それは５０％の改革が現状否定からスタートするのに対し、
５％や１０％の改善は現状肯定からスタートするからである。

このメソッドは、
普通にやったら3年かかるプロジェクトを1年に設定。
1年かかるプロジェクトを半年に設定することにやって、
｢増員なし｣で、｢努力｣や｢根性｣、
ましてや｢残業｣や｢泊まり込み｣なんかやっても
どうにもならないような期限に制約することで、
現状を抜本的改革する｢知恵｣を現場から搾り出すことでしょう。

勘違いしやすいのは、
｢同じ時間で2倍も3倍も働け｣ではなく、
｢同じ時間で2倍も3倍も楽をする方法を編み出す｣こと
｢常識で効果的なことを全部やるのではなくて、
その同じ労力をどこに集中すると2倍や3倍の売上になるか?｣
を探すことです。
だからもうすでに｢ベストであるはずの現状のやり方｣を否定する
ことからはいるしかない。
もしかしてエースプログラマー達を全ての煩わしさから開放して、
みんなと不平等に扱い、そこに充分な時間が集中することで
100倍の生産性を叩き出すかもしれない。
(自宅作業したいとか言い出しそうだけど…)

会社側の制限なしで考えるならば、
現場の人の知恵が何も出ないなんてことはなくて、
多分、会社によっていろんなしがらみが、、
特に会社のこれまでの方向性や、
会社の別部門とのバッティングとか、
これまでプロジェクトを推進してきた社内派閥のメンツとか、
それこそ悪いことしないためのセキュリティなどの鎖が、
現場本来の力をかなり抑制してる事は多いと思います。
そのための会議や管理でもありますしね。

普通は、このしがらみにとらわれるしかないのですが、
こういうとんでもない目標設定が与えられたら、
このしがらみや鎖を引きちぎってくれます。

現状のベストや根性ではとてもクリアできない目標設定によって、｢最初から終盤進行の勢い｣は可能である。

ハンゲームチームに出された課題、

「4月から開発に着手し、7月末までに70タイトルそろえる」
「開発スタッフは既に決まっている人間で進める」
「8月にTVCMなど大々的なPRを行うため遅延は許されない」の3点

この上、｢製品クオリティは落とさない｣という
松下幸之助ばりの無茶振りが
｢11のやめたこと｣
という、非常識な現場の知恵を引き出し、
｢最初から締め切り終盤進行｣を可能にさせたのではと考えます。

We choose to go to the moon

我々は月に行くことを選択した。

1961年当時、J.F.ケネディのありえない無茶振りです。

ハンゲームチームからは、とても学ぶことがあり長文となりましたが
最初に必要なのは、(短期間のうちに)ここから月へジャンプしようという
ありえない大志を抱くことがその第一歩になるのではないでしょうか。

追記

はてブからいい質問が。

id:bash0C7
"現状のベストや根性ではとてもクリアできない目標設定"で
大炎上する場合とすごい結果を生み出せる場合との違いは何なんだろう

大炎上も、小さなプロジェクトだと別にたいした傷にはならないですけど、
大きなプロジェクトだと偉いことですね。
(傷が大きいから大炎上というのか)

例えば、過去にヒット率ほぼ100%の実績積んだクリエーターがいたとして、
常に変化する市場に、次の大作も100%ヒットするかというと
それは｢絶対｣じゃないんですよね。
ただ、そういうヒーローに任せる事が一番確率高いと説得されると
社長も誰も納得せざるを得ない。

出来るクリエーターの暴走を防ぐには?

それで現場中心に権力が移っていくと、
｢70億かけて革新的なオープンワールドゲームを作る!!｣とか、
｢100億かけて映画事業に乗り出す!!!｣とか
超ハイリスクに挑むことになったりします。

これが、グランド・セフト・オートのように、
｢前作が1000万本売れたから、シリーズ最新作に100億ぶっこんでも大丈夫｣
だったらまだいいのですが、
まったくの新規IP狙いで100億はハイリスク過ぎます。

このときの目標設定で大事なのはやはり、
｢期限とコストの制約｣から｢革新性の知恵を生み出す｣ことです。

スタートでいきなり社運までかけないように、
｢20億で、革新的なオープンワールドゲームを作る!!｣
｢30億で、新規映画事業に乗り出す!!!｣
ならば、同じ70億や、100億使うにしても3発撃てますよね。
この1発目をフィードバック得るために使うのがとても大事で、
それこそ現場次第で、30億の映画が、100億の映画より面白く無い
なんてことはないのですから、3発目の大ヒットを狙うための
無茶振り制約であっていいわけです。

ドラゴンクエストは最初から｢III｣を作りたかった。

ウルティマや、ウィザードリィに強く影響を受けた堀井雄二は
最初から｢転職可能｣｢4人パーティ｣である、
｢ドラゴンクエストIII｣を作るつもりでした。

でも当時｢RPG｣すら知らないファミコンユーザーに、
いきなりそれは難しすぎる。
少しづつ慣れてもらうという意味でも、
当時のROM容量やスタッフや予算制約などもあって
一人旅のRPGでドラゴンクエストI は始まり、
出てくる全装備品もたった17個。
IIで容量が倍になり、3人パーティーが実現して、
IIIのさらに容量倍で、やっと本来の｢転職｣｢4人パーティ｣にまでなって
本格的な社会現象となりました。

もし、I や II の難易度や、インターフェースフィードバックがなく、
II のときの当時めずらしい複数人プログラミング体制の大混乱を経験せずに、
いきなり、III を作ろうと高いROM受注や、大規模スタッフ、大規模予算の投入を
してたら、果たしてプロジェクトが完遂できたかどうか、
あれだけ洗練されたゲームにしあがったかどうか、
そして社会現象にもなったかどうか? と思うと怖いものがあります。

ファミコン世代で育ったクリエーターであれば、
｢いきなりドラクエIII を作るな!
3部作の中でどうしてもやりたいことを、1部として完結し。
そのフィードバックをとれ!｣
と言えば、暴走抑止に対する説明がわかりやすいかもしれません。

I、II、が順調にヒットしたのなら、前作がこれだけうれたから
より洗練させてボリューム増やして倍プッシュ
といっても炎上確率は低くなるでしょう。

追記2 大規模開発には当てはまらない?

確かにこういう勢いは短期向けプロジェクトのほうが、
よりしっくり来るかと思います。

11の「やめたこと」で実現した1000万ダウンロード突破【スマホ2011冬】 - デジタル - 日経トレンディネット
http://trendy.nikkeibp.co.jp/article/column/20111215/1039018/

「なぜこうした改革を思いついたのか？」という来場者からの質問に馬場氏は
「以前に所属していたPCオンラインゲームの部署では、
上記11項目をすべて実施していて、ヒットがなかなか生まれなかったため、
すべて変更してみた」とキッパリと回答。

PCオンラインゲーム開発と、スマホ定番ゲーム開発では、
確かに極端な規模の違いがありますね。

しかし、管理や教育より｢出来る人の力を最大限に｣という意味で
FF11 メインプログラマーの話聞いたらびっくりしますよ。

イマドキの面接のFAQ - ゼペットの休日
http://d.hatena.ne.jp/hotmiyacchi/20111209/1323405480

会社のサイズという意味では常々よく聞く勘違いで、
「FFチームとかよほどの大人数がいれば話は別だが」
的な引き合いをたまに聞くのですが、
恥ずかしながら自分がFF11作った時は
PS2に関わったプログラマなんか３人だったんですよね
（最終的にはもうちょっと増えるけど、基本少人数）。
(略)

基本的に「えっへっへ、あっし、なんもしてませんて、ホントですよ旦那ぁ」
と上司に誤魔化す日々を１年ちょいほど断行したのですが、
「C++を使ったら無駄にバグるのでは！」な追求が激しかったので、
ほぼ完成するまでろくに状況や進捗を公開できない状況で、
気分は大脱走でした。

C++を禁止してC言語に統一したい論調の根源が
「C言語だけにすれば全プログラマが作業できるので増員しやすい」
だったので、議論以前に全部C++で作ってしまえば、「そんな増員いらない」
と言えると思ったわけです。
(略)

特に少人数にこだわったわけではないのですが、
今となっては解説する手間もそんなかからないと思いますが、
高度に管理されたオブジェクトやリソースを安全に動作させる
動的な再配置やスワップなどの退避処理はC++じゃないと厳しく、
そこがメモリの少ないPS2には生命線で、
理解できない人が勝手なリソースを消費するようなプロジェクトだったら
一瞬で破綻してたのは自明なのですが、
その理解構築に数年費やすくらいなら自分で全部作ったほうが良い
とプロジェクトの当初に見切って進めた仕事でした。

いわゆる「FFは大規模プロジェクト、大勢が働ける選択を尊重すべき」
という既成概念的カルチャーにまっこうからカウンターした思い出なのです
(略)

正直、理解を得られない時の上司からの評価は苦笑ものに最悪でしたが
（全部完成してヒットした後、晴れて初任給から超昇給しました、ほぼMAXレベルに）、
今でも誇りをもってやってよかったと思える仕事です。

ともあれ、FFを始め、素晴らしい製品ほど、強く偉大なイメージがある故に
強大なモノ（得てして大人数）が作ったように思われがちですが、
それはイメージから生まれる誤解に過ぎず、良い製品を作りたいと思うなら、
自分がやりやすい最適な人数を考えて進めることが
とても重要ということをこれらの実践で学びました。

少人数の持つ重要性とも言えますが、
主要なITサービスや名作ゲームのほとんどは少人数から生まれており、
大人数になるのは生まれたあとサポートしてるに過ぎないことが多いのです。

モバゲーの基礎部分を一人3ヶ月で作った川崎さんの話も有名ですよね。

ASCII.jp：「モバゲー」を1人で開発した男──川崎修平氏の素顔（後編）
http://ascii.jp/elem/000/000/108/108179/

開発に専念し続ける取締役、モバゲー川崎氏の戦略 − ＠IT自分戦略研究所
http://jibun.atmarkit.co.jp/ljibun01/rensai/leader/25/01.html

FFの話なんか聞くと、出来る人達と出来無い人達を混ぜたチームでは
どれだけ膨大なコミュニケーションロスが発生しているのだろう?
と決して数字で見えないそれを考えなおさせられ、
同じレベルの出来る少人数スペシャルチームと、
教育、管理すべきところは別に考えたほうがいいんじゃないかと、
ハンゲームの話と共に、このエントリーを上げてみました。

多分、上司、マネージャーは、
自分の部下であるエースの本当の力を知らないでチーム編成してると思うんですよ。
自分がエースじゃないからその力を測れない、というより
エース自身も自分の本当の限界を知らないのかもしれませんね。
普通の会社でハンゲームのような
現場最優先の全く邪魔されない環境とでかい目標で働く機会は
まず無いでしょうから。