現場の人と指揮する人

現場あがりで指揮をする人が自分が現場にいるつもりで指揮を出し続けると大抵大変なことになると思う。

全体で10の作業ができるとすると現場の人は10の作業を1つのプロジェクトに割り当てることができるんだけど、指揮する人はそうは行かなくてせいぜい3がいいところだと思う。指揮する人が現場の人間のつもりだと、作業を割り当てれる時間が減っているのに自分も全てを知らないといけないと思っちゃって全部に口出ししちゃう。でも、作業時間が減ったのに同じパフォーマンスを出すとか無理なわけで、指揮を出す人ってそのプロジェクトがどこに向かっているのかだけに目を向ければ十分なんだと思う。プロジェクトがどこに向かっているかを把握して向かっていく場所を修正してあげるっていうのが指揮する人の役割で、プロジェクト自体を動かすのは現場の人間というスタンスのほうがうまくいくんじゃないかな。

指揮する人がいつまでたっても現場の人間のつもりで作業してしまうと、指揮する人の作業量が増えすぎて「指揮する人が倒れる」or「指揮する人の作業が全て中途半端になる」ってことになりそう。だって、絶対的に作業時間が足りないんだもの、どれだけ効率化しようとしても無理なのはしょうがないよね。「頑張ればなんとかなる!」とかいって、自分の作業量を増やして中途半端に指揮する人が現場に絡んだら、どんな作業をしていたのかの報告をきくだけで作業が終わるとか本末転倒な未来しか想像できないよね。現場も疲弊するし指揮する人ももやもやするしで双方に全く利益がないことになりそう。

これってすごく難しいバランス感覚だと思うんだよなー。端的に知りたい部分だけを聞いて現場の人の作業を想像してうまく言ってるかどうかを判断して作業は現場の人間に任せて方向性が合うようにうまく指示を出す。書いてみるとわかるけど神業だよな。作業しちゃいけない立場だけどプロジェクトは成功させないといけないってどう頑張ればいいのかわからなくなりそう。

パズドラが正解ってわけではないと思う

↓を読んで思ったこと

でも、作っていて「このチェックリストは絶対では無い」と思っていますし、自分にもそう言い聞かせています。

チェックリストってゲームで作るのは難しいんだと思う。ゲームにはそれぞれで狙っているターゲットってものがあるはずで、万人に受けるゲームなんてそもそもないんだと思う。尖っていない丸いゲームを万人ウケのゲームって称されることが多いと思うんだが、それって万人に受けるって言うよりも万人ができるってゲームなだけなんじゃないのかな。

上記の通り、僕がコンサルを担当していたら、パズドラはパズドラじゃなくなっていたでしょう。

そう。パズドラってすごく絶妙なバランスで出来上がってるんだと思う。そもそも初回開発の時は全然違うゲームだったって以下のリンクでも言ってる。

運ですね。これをやったから上手くいったんじゃないかという分析は、正直くだらない。僕たちが作っているゲームは妥協せず、すべて魂を込めて作っています。

合計で4回作り直しています。開発期間は5カ月で、デザインのほか、感触を何回も確かめました。最初は四方にしか動けなかったので、爽快感がない、テンポが悪いということで自由に動けるようにしましたが、そうすると逆に簡単になり過ぎてしまったので、タイムゲージ(制限時間)を導入しました。ドロップ(パズル)を1回動かすときのタイムゲージを4秒にしたのは、そのためです。

そのゲームが面白くなるための試行錯誤を繰り返した結果で、これは面白いって思ったとしても刺さらないことがあるんだろう。まず、パズドラがこうだからこれが正解だって思ってしまっているのは間違いなんだと思う。パズドラはパズドラが狙っているゲーム層とゲーム性が合わさってああいう訴求方法をやっていてそれがあたったていう事実はあるんだろうけど、じゃあ別のゲームでパズドラがこうだからこうしましょうっていう考え方は多分違う。自分が作ったゲーム性・対象ユーザによって訴求方法は変えるべきで何かを参考にするのではなく新規にそれぞれで考えるものなんじゃないのかな。

そのそれぞれに新規で考える時にその人の経験したノウハウが活かされてうまくいく確率っていうものが変わっていくんじゃないかな。パズドラに縛られる必要はないと思う。言われているように違う人がプロデュースしたら今のパズドラは出来上がってないんでしょう。けどもしかしたらそっちのほうが今より売れているかもしれない。早めに海外展開を考えて今よりも市場が大きいところに行っていたのかもしれない。たらればで言えばいくらでも色々なことが言えるしパズドラっていうのは最近では一番流行っているけどそれが正解ってわけではないと思うよ。

Androidの開発環境を更新した(ADT Bundle)

僕の環境にAndroidの開発環境を入れたのが今から1年ほど前なので時間があったのでアップデートしてみた。

開発環境の構築がスゲー楽。前はEclipseダウンロードしてきて、AndroidSDK入れて、パス通してとかやらないといけなかったのに、今回は上記リンクからダウンロードしてきて解凍するだけで基本的に終了、なんと素晴らしいことでしょう。やっぱり開発初心者の方が始めようと思って開発環境の構築でつまずいてしまってヤル気を失うのはもったいないので、プラットフォームを売るっていう意味で裾の尾を広げるには開発環境を楽に作れる状況を作るってのは大事なんだろうね。と、思ったけど何点かつまずいたので備忘録。

アプリケーション作成ってやっても画面がでない

なんか初期画面でこういうことでいますよって画面が出てるんだけど、これが新規アプリケーションを作成しても自動に閉じない。アプリケーションのコードを表示している画面がその裏にあるせいで、新規作成されたアプリはどうやって開けばいいってちょっと悩んだんだけど、普通に表示されている画面の右上にいる×ボタンで閉じればみなれた画面が出てくる。

Layoutファイル画面がエラー

アプリを開くと自動的にLayoutファイルが開かれるみたいなんだけど、いきなりエラー画面がバーンって出てくる。慌てず騒がず[windows]→[Android SDK Manager]を使って必要なモジュールをダウンロードしましょう。いきなりエラー画面が出るのは親切なのかなんなのかよくわからないけどちょっとビビった。

フォルダを移動すると動かない

解凍すると「sdk」「eclipse」って2つのフォルダができて、どうも起動時にAndroidSDKのパスに自動的に「/folderName/sdk」が設定されるみたい。だからフォルダを移動するとSDKが見つからんって怒られる。[Prefarence]→[Android]で[SDK Location]を変更したパスに変えてあげれば大丈夫。

まとめ

環境構築が楽なのは嬉しいですね。起動時に出てくる画面が違うってのもちょっといいかも。でもそのせいでEclipse使ってるっていうことを知らずにEclipseの便利なことが検索されなさそうな気がしなくもない。

ソーシャル性の濃さはゲーム性によって決めるべきだよね

これを読んでちょっと思ったので。

確かにおっしゃるとおりソーシャル性が薄ければ薄いほど新規の人は入りやすい。けどそれってやめやすいってことの裏返しでもあると思うんだよね。ソーシャル性が強ければ強いほど自分がやめると人に迷惑をかける、もしくは自分が人に役に立ってるっていう状況が出来上がって、それが辞めづらい状況っていうものを作り上げていくと思うんだ。だからグラフで書かれている初期獲得ユーザから後期獲得ユーザにつれてソーシャル性が高ければ下がっていくっていうのはそうかもしれないけど、ソーシャル性が高ければ高いほど継続日数は上がる事になるんだと思う。そう考えると、後期になればユーザ数は増えにくいけど継続しだすとずっと続くっていうのがソーシャル性が高いゲームだと考えられて、平均すると同程度のユーザ数・継続率に落ち着くんじゃないのかな。

もともとフックする材料がちがっていて、ゲーム性で楽しむ要素が強いものはソーシャル性を薄くしてゲームを楽しむことをフックに人を集めて継続してもらう。ソーシャル性はおまけ。コミュニケーションで楽しむ要素が強いものはソーシャル性を濃くしてコミュニケーションを楽しむことをフックに人を集めて継続してもらう。っていう違いなんだと思う。ただ、コミュニケーションで楽しむゲームでも本質となるゲーム要素が全く面白くなかったらそもそも流行らないから、ゲーム性もある程度担保しないといけないことになって、こっちのほうが作るのは難しいんだろうね。流行るものが出来ればソーシャル性が強いもののほうが根強い人気がでると僕は思ってるんだけど。

まぁ、何でもかんでも「ソーシャルを強くすれば人が集まって継続率が上がる!」みたいな考えは間違ってると僕も思う。人と人とのつながりはそれなりにコストが高い動作だからそれを全面に押し出すと使うのがめんどくさくなるのは目に見えて言えることで、人と人とがつながる必然性が無い状況で「継続率が低いから人と人をもっと結びつけてどうにかしてやろう!」みたいな安易な考えでやってるとやられるんだろうなぁ。

サイドバーが途中でついてくる奴作った

最近よく見かける下にスクロールしてるとサイドバーが途中から上部で固定される奴がどういう実装になってるのか気になったからちょろりとjquerypluginとして実装してみた。基本的には高さとってposition:fixedを変えてるだけ。

(function($) {

    $.fn.sidebarFixed = function(action, option){

        var sidebarFixed = function(self) {
            var $self = $(self);
            var top = $self.offset().top;
            self.isFixed = false;

            $(window).on('scroll', function() {
                if(!self.isFixed) {
                    if(top <= $(window).scrollTop()) {
                        $self.css({
                            'position': 'fixed',
                            'top': '0px'
                        });
                        self.isFixed = true;
                    }
                } else {
                    if(top >= $(window).scrollTop()) {
                        $self.css({
                            'position': 'static',
                        });
                        self.isFixed = false;
                    }
                }
            });
        };

        return this.each(function(i) {
            sidebarFixed(this);
        });
    };
})(jQuery)

↓がデモ。

やってることはpluginを読み込んで、途中で止めたいdivを↓みたいにpluginに渡してやるだけ。

    $(document).ready(function() {
      $('.fixed').sidebarFixed();
    });

サクッと書いたけどFirefoxとChromeでは動くみたい。IEは環境がないからよくわからん。jsはさくっとかけてさくっと試せるからやっぱり便利。

sakuraでApacheとnode.jsを同居させる

httpのportってdefaultが80だからApacheとnode.jsを同時に起動させるとどっちかしかアクセス出来ないもんだと思ってた。んで、しょうがないから、http://hogehoge.jp:8080みたいにportを指定してnodeの場合はアクセスしてたんだけど、カッコ悪いし不便だしなんか方法ないかなぁと調べたら案外あっさりできた。

ReverseProxyの設定でapacheにアクセスしてきたやつを吹き飛ばせばいいみたい。

<VirtualHost *:80>
    ServerName hogehoge.your.domain
    ProxyPass / http://localhost:3000/
    ProxyPassReverse / http://localhost:3000/
</VirtualHost>

こんなふうにhttpd.conf書いてやれば、hogehoge.your.domainでアクセスしてきた奴がport:3000にアクセスしたことになるから、後はnode.jsを3000で上げてあげればポート指定が入ってなくてもアクセスしてくれるというメモ。

PCで悪いことして捕まっても大丈夫な方法を考えた

最近巷でこのニュースが騒がれてる

これ見て掲示板に書き込みとかではなくて著作権違法のものをダウンロードするウイルスとか出せたらボタンひとつで気に食わない奴を刑務所送りにできる時代がきそうで怖いなーとか思ったんだけど、よく考えればすべてをウイルスのせいにしてしまえばなんとでもなるんじゃね?って思ったりした。

手順は簡単

  1. 自分のPCに定期的にどこかサーバにアクセスするようなものを仕込んでおく
  2. どこかの掲示板に手製のウイルスをダウンロードするリンクを貼る
  3. わざとそのリンクを踏んでウイルス落として感染しておく

こんだけ。

後は適当にそのPCで悪いことしまくって捕まったとしても、定期的にアクセスされているサーバで一定期間アクセスがなかったら手製のウイルス経由で「警察のバーカ。愉快犯だよ~ん」みたいな犯行声明を出させるようにしておけば、捕まって取り調べを受けてる間ずっと「僕はやっていない」って一点張りしてるうちに犯行声明が出てきて無事に開放される。みたいなね。

これでPC使ってわるいことしまくれるな。

個人でのプロジェクト振り返り

今回のプロジェクトを振り返ってみての雑感+戒め(*1)。

見積りはどのようなものが出来上がるまでの時間なのかを周知する必要がある

僕の見積りはざっと見積もった時の見積もり方が非常に甘い。僕がこれぐらいでできるって思っているときは大抵出来上がりの完成度合いが人と違うんだと思う。僕がこれぐらいで作れると思う時間というのは動くものができるという時間で周りが求めているものは動く+見た目が整っているというものを指しているという齟齬があるんだと思う。50%ぐらいの時間で動くものは作れるわけだがそこからこのデザインを当てるだの何だのが出てくるものだということを考慮して倍で見積もったほうがいいのかもしれない。ただ、余分に時間を見積もるというのはあまり好きではないし、本来であれば見積りは正確であるべきなので、作れるというのは動くものが作れるというのはきちんとみんなに伝える必要がある。

人が少なければ小回りは効くけど結局人数が多い方が捗る

大人数での開発というのは意思疎通のためにいろいろ手間がかかる。技量もバラバラでコードの書き方も千差万別なのが当たり前なので、それを一つのプロジェクトとして統一するためにはコーディング規約で縛ったりReadmineでタスクを管理したり色々と少人数でやるときはやらなくても良い作業をやる必要が出てくる。プロジェクトを円滑に回すためにはこれは当然で大人数で開発するというのはここらへんの作業も含めて工数を考えるべき。僕は管理をするための工数は出来る限り削りたいと思っているしタスク管理のためにいろいろやったり、技量を合わせるためにいろいろやったりするのははっきり言って無駄だと思っている。なので少人数での作業を好んでやる癖があるし昔を考えても少人数での作業を行なってきた経験が多いのでわざとではないが自分でそうなるように仕組んで動いているのかもしれない。ただ人が少なければ工数は減るけど結局日数がかかる。2人での作業が1人の倍になるわけはないが1.5倍ぐらいにはなる。技術が低い人が入ってきてしっちゃかめっちゃかされて逆に1人でやったほうが早かったんじゃね?って思ったことも昔はあったけど、結局は1人でやるより2人でやったほうが早い。これまでにこの作業をってなったら管理工数がかかるのは置いといて人数を増やしてやるべきなのだろう。

テストコードはなにがあってもかくべき

まだうまい書き方っていうのをわかってはいないんだけど、テストコードは絶対に書くべき。単体テストについてはあまり効果を感じたことは少ないんだけど、結合テストのコードは書かないとまずい。まずいというかソースに手を入れるたびにどこかしらがデグレって結局自分の首を締めることになる。テストコードを端折れば動くものが出来上がるのは早くなるけど、何がしかの変更を入れた時にそこがきっちり動くことを証明するために人の手を使ってまたテストをすることになるから非効率的すぎる。UIのテストをどうすればいいのかまだ上手い方法がわかってはいないんだけど、結合テストのコードはなにか機能を実装するたびに書かなければまずい。アジャイル開発をやるんであれば今あるもののうわっかぶせで作り続けることになるんだから、今あるものが動くというのを証明し続けるテストというのは絶対的に必要で、テストを書く工数がもったいないとか思って逃げると逆に工数がうわづまれることになる。

まとめ

書いたことはふつうのコトなんだと思う。きっちり作業をするって思われている人っていうのは当たり前のようにこれをやっているからきっちり作業をするって思われてるんだと思う。そうなれるように今後の戒めとして。。。



*1: まだ終わったわけじゃないけど

再帰っていいよね

組み合わせを出さないといけなくなって作るのめんどくさくなったからPGで出力。1〜4までの数字の組み合わせを出そうとしたとして、javascriptで単純に書こうとすると、

var combination = function() { for(var i=1 ; i<=4 ; i++) { for(var j=1 ; j<=4 ; j++) { // めんどくさいのでここまで } } } [/code]

って言うのがすぐ思い浮かぶけど、これだと書くほうがめんどくさい。しかも数字の種類が4個だからまだいけるけどこれが100個とかなると死ぬことになる。なので再帰。

var length = 4; var combination = function(start, comb) { if(typeof comb === ‘undefined’) comb = ”; if(comb.length == length) { console.log(comb); } else { for(var i=start ; i<=length ; i++) { tempComb = comb + "" + i; combination(i, tempComb); } } } [/code]

これなら100個になろうが1000個になろうが余裕。再帰素晴らしい。

jQueryのajaxを使って動的にjsファイルを読み込む

読み込みファイルとか増えるとファイルが多くなって見づらくなるからなんか方法ないかなーと思って調べるとscriptタグを無理やり差し込んで読み込む奴がよくヒットする。そんな力技じゃなくて普通にjQuery使えばいいんじゃね?っと思って書いてみた。

// 渡されたPathに存在するScriptを全部読み込んでCallbackを実行する
var ajaxLoadScript = function(paths, callback) {

  var loadCount = 0;

  $.each(paths, function(index) {
    $.ajax({
      type: "GET",
      url: this,
      dataType: "script",
      success: function(msg){
        loadCount++;
        if(loadCount === paths.length) {
          callback(true);
        }
      },
      error: function(msg){
        callback(false);
      }
    });
  });
}

// 使用例
$(document).ready(function() {

  // ここで読み込むやつを記載しておく
  var scriptArray = [
    './js/a.js',
    './js/b.js',
    './js/c.js',
    './js/d.js',
    './js/e.js',
  ];

  // 動的読み込み。aStringとかはa.jsとかに定義してある
  ajaxLoadScript(scriptArray, function(result) {
    if(result) {
      console.log(aString);
      console.log(bString);
      console.log(cString);
      console.log(dString);
      console.log(eString);
    }
  });
});

外部のファイルだとクロスサイトスクリプティングで弾かれるからできないけど、同一ドメインだったらScriptタグに書いたりしないでこんな感じで書けばスマートに書けるんじゃないかと。まぁ、同一ドメインにあるファイルたちだったら圧縮するべきだろっていう話はあるんだけど、ファイル分けたほうが複数人で作業する場合は捗ることも多いし、テスト環境で試すときとかなら簡単にこんなのを書けばいいんじゃないかな。

他になにかいい案があれば教えてください。