作る仕事

作る仕事というのは非常にたくさんのことを要求されます。
　・何をつくるのか理解する
　・どうすれば作る事ができるのか考えたり調査する
　・どう作るのが最適か設計する
　・実際に作る　
　・作る上で問題となった事象への対処・報告

これを仕様が変わったり追加されたりする度に行います。

小規模な場合は誰かの頭の中で瞬時に。
大規模な場合は関わる人全ての人に理解してもらう。

この作業を如何に円滑に行えるかがチーム力と言っても過言ではなく、ここでボトルネックな要素こそ真っ先に排除すべきもの。


当初今のリソース分担で納得したのも、この作業を円滑に行うのに十分な人たちが集まっていると思ったからです。

パワポとエクセルとwikiだけしか触らなくなって数週間。
ゲームの企画じゃなかったら発狂してるかもしれません。

何年も前からこれからのゲームはオンライン必須だと言われてきたし、ゲーム好きな自分もそう思ってきました。

単なる流行のソーシャルゲームを作るという気持ちではなく、
「スマフォのゲーム = 最もプレイヤーの多いゲーム」
として、王道は守りつつもその最も理想的な姿を追い求めていきたいと思ってます。

考える仕事

最近気になる考えるお仕事。

私自身今まで専門じゃなかったので偉そうなことは言えない気はしますが、言います。

アプリの開発をしていて実際に画面を見ると、「イメージと違う」
なんてのはよくある話です。作り直すのも日常茶飯事。

これは良いものを作る上で必ず通る道だと思ってます。
作ったものを見るのが一番早いなんてのは誰でも同じことを思うし言うでしょう。


しかし、考える側にとって重要なのは「みなくてもわかる」ことがどれだけあるか。だと思います。

最近自分でもよく使う「これは作ってみてからですね」とかは敗北宣言と思ってます。…連日負け続けてます。

・企画書やイメージ図
・仕様、設計
・モックやワイヤー
・実際に作られたもの

それぞれの時点で機能毎に考えきったあとで次のステップへいけているか。

この事が作る側の作業を減らし、結果的にはよりよいものを作る時間の確保になります。

スピード感というのは、目先のものを追うだけで出るものではありません。
仮にスピード感は出たように見えても実際のスピードは出ないでしょう。

作る側も考える側も、チームとして一体になった時に大きな成果がでるものです。

考える側が力不足や時間不足だとどうしてもとりあえず作るということが効率的にはなってしまうので、今正念場です。

考える仕事と作る仕事

アプリケーションの開発には考える仕事と作る仕事があります。
もちろんプログラミングも考えながら作る仕事ですが、ここでは
　「考える = 何を作るか」
　「作る = どうやって作るか～実際に作る」
という作業のことを指します。

とある人は「経験上作る側がなんとかすればなんとかなる」と言います。
逆に言うと「作る側がなんとかしないとなんともならない」ということ。

どちらが上で、どちらが指揮をとるべきか、など些末な問題です。

そのプロジェクトに対して一番時間と情熱を注いでいる人が指揮をとっているかということのほうがよっぽど重要。


今度のプロジェクトは特殊で、作り手主導というか作り手しかいません。だからうまくいくとかは断じてないです。むしろ不安。

企画のために動画やらモックやらを作ることはやりますが、とりあえず作っていく等という手法は論外で、毎日チームで企画MTGをしています。

そんなことをやっていると、考える側は誰が見ても「よく考えてるなぁ」と言わせる程じゃないと評価などされないことを実感しています。

作る側が「絵が巧い」「知識が豊富」「作業が速い」とかで評価されるのと一緒ですね。何か相手を関心させるものがないと駄目なわけです。


大切なのはそれぞれの役割と、自他ともにそれを「プロ」と認める仕事をしているか、ということ。

自分はやったことないから、とか初めてだから誰々頼りです。なんてのは己への甘えと言い訳でしかありません。

私自身言葉には出してない(はず)ですが、内にあるこの甘えと言い訳を克服しなければと思う今日この頃です。

宙に浮く仕事

今行っている開発は基本オンスケでそれなりにクオリティもあり、まずまずといった感じで進んでいます。

そんな中でも大きく浮き彫りになった問題点が「宙に浮いた仕事」です。

これは職種間にも起これば、デベロッパ間でも起きた大きな問題でした。

例えば役割分担を以下3つにした場合

・通信部
・共通部
・ゲーム固有部

とした場合にこの3つをつなぐ作業を誰がやるのか宙に浮いてしまいました。

これはゲーム固有部担当が手一杯であれば他の人がフォローするという感じで進めたかったのですが、「そこは自分の担当じゃない」という状態を産んでしまいした。(逆に担当内を勝手に改修されて…という場合も)

初期デバッグを誰がするかでも多少の抵抗が見受けられ、都度都度意識の訂正を促す必要がありました。

また、職種間でも誰が何を決めていくのか曖昧で、特にディレクションの役割が宙に浮く状態でした。

開発陣はディレクションしてたら開発工数がとられるし、プロデューサはディレクションに割く工数がない(結果主義なのでそんなトコに工数割くなら別案監督した方が…という体制の問題もあると思います)

役割分担をもう少ししっかり決めるのと、リソースを確保する以外に解決しなさそうな課題ですが、しっかり向きあっていかなければいけない問題です。

iPhoneからの投稿

XIBを使用したカスタムViewクラス

最近iPhoneアプリを作りながら、iOS関連の知識を広げることが
できていなかったのですが、多少やる時間と機会が増えてきたので、
ブログにメモる習慣を再開します。

今回はXIBでレイアウトしたviewを独自クラスとして使用する方法です。
初歩の初歩という気がしないでもないですが、意外と素直にいかないというかなんというか、なので書いておきます。

UIViewControllerを作る時はデフォルトで生成されるので問題ないと思います。
UIViewControllerは継承したくなくて、ただのviewとして作りたい場合です。

ちゃんとMVCで設計するとこんな感じ。
・xxxController.h
・xxxController.m
・xxxView.xib

「xxxView.xib」のFile's Ownerに「xxxController」クラスを設定して
「xxxController.m」のinitとかのどっかで読み込むだけ。

UINib *nib = [UINib nibWithNibName:@"xxxView" bundle:nil];
NSArray *array = [nib instantiateWithOwner:self options:nil];
self.view = [array objectAtIndex:0];

これとは別にクラス=viewみたいな形にしたい時が個人的には
結構あります。(MVCじゃないとか言われそうだけど…)

まあ、いくつかのviewを一つのControllerで制御する時は
こうなると思う。たぶんきっと。

・xxxView.h
・xxxView.m
・xxxView.xib

この場合はFile's Ownerではなくviewのクラスを「xxxView」
にしましょう。

この時に普通に感覚的にやるとinitとかの中で上記のコードを
書きたくなるのですが、xibから読み込んだviewはallocもinitも
完了しているわけです。(autorelease)

ということでクラスメソッドで生成するという所に落ち着きました。
alloc initでは生成できないので、オブジェクト保持したい場合は
生成元でretainを。

+(id)createFromNib
{
   UINib *nib = [UINib nibWithNibName:@"xxxView" bundle:nil];
   NSArray *array = [nib instantiateWithOwner:nil options:nil];
   UIView *view = [array objectAtIndex:0];
	
   if (view) {
       // Initialization code
       [view initializeNibObject];//何か初期化したい場合
   }
   return view;
}