アプリのデザインを依頼するときに重要なこと

はじめに

本日（2012年1月16日）、個人で企画・開発したアプリをリリースしました。（アプリ開発自体の記事はまた別に書きます。）

パズルの国のアリス

デザインに関しては僕はあまりできないので周りのデザインのできる人にお願いしたのですが、自分の開発や外部委託を含めてAndroid開発で感じたこと、大切だと思われることを書いていきたいと思います。

勢い重要

以前読んだ「小飼弾のアルファギークに逢ってきた」という本の中で出てきた「勢い重要」という言葉が印象に残っています。思いついたらその日のうちにプロトタイプを作るくらいの勢いが重要だというような文脈で使われていたと思います。他にも「70%のものを早く作ることが重要」という人もいます。今回この言葉の重要性を体感しました。

最初自分ひとりで企画し開発を進めていましたが、どうにもクオリティの高いグラフィックを描くことができない。思えばシステムとして形にはなっているものの見栄えが悪く世に出せなかったものも過去にいくつかあったように思います。それを理解していたので今回はデザインを誰かにお願いする前提にして、自分はシステム部分に注力することで比較的早い段階で基本的な動きはできました。

とりあえず見せられるものを作ったことで、デザインのイメージを伝えて依頼することができ、デザインとシステムの完成度を高める作業は並行して行うことができました。時間をかけて完璧なものを作ってからと考えていたならもっとリリースは遅れたと思います。

ダメ出しはしよう

使い物にならないものにダメ出ししたり、ダメ出しする必要もなく完璧なものを使ったりというのは良いとして、問題なのは「NO BAD」のとき。使えなくはないが納得できないというときは早い段階でダメ出しした方が最終的に良いものができると思いました。納得できないものを使ってもクオリティは低いし、後から悩むくらいなら早いうちにダメ出ししたほうがいいです。

チームで意思疎通しよう

会社とかだとプロジェクトの開始時には、チームを編成した後スタート会議などをすると思いますが、今回は最初僕が一人でプロジェクトを開始し、周りの人をどんどん巻き込みながら最終的に関わったのが４人になりました。当然プロジェクトに対する理解度やモチベーションは各々違い、全員が全てを把握できるわけではありません。

それが顕著に現れたのが表紙のグラフィックとゲーム中のグラフィックの色の違い。はじめ表紙のキャラクターデザインをラフスケッチで出してもらい、それを元に別の人にゲームグラフィックを依頼しました。そしてあがって来た表紙デザインとラフのデザインの色が違っていたため結果的にゲームグラフィックと表紙グラフィックの色が違ってしまいました。これはデザインを一任し、僕自身が管理を怠っていたことに原因があります。結局ゲームグラフィックの色を変更してもらいました。

明日までとはいつまでか

「何日まで」と指定して依頼するならば必ず「何日の何時まで」と依頼する必要があると思います。たとえば明日までとは今日の23:59までなのか、18:00までなのか、明日の9:00までなのか…を指定していなければお互いの時間を無駄にしてしまいます。

「何日まで」と指定した日にデザインがあがってこなかったので、深夜確認のために起きていたほうがいいのか、それとも向こうが9:00までにあげる予定だから寝てもいいのかなどがわからず、結局その日はほぼ徹夜になってしまいました。「何日の何時まで」と必ず指定しましょう。

不可能な場合は「不可能」と言わせる

クオリティは下げられない。かといって完成を遅くすることもできない。こういうとき「アジャイルサムライ−達人開発者への道−」ではスコープを狭くするといっていますが、今回は使えるリソース的にもその必要もないと思っていました。ただ人に依頼する場合、どこまでお願いしていいのかがわからない。その人で不可能なら別の人に早めにお願いしたい。おそらく依頼される側も自分がどこまでできるのかわからないと思います。はじめできると思ってもやっているうちに不可能となる場合もあるかもしれません。そうした場合に相手としては言い出しにくいと思うので、こちらから本当に可能であるか、現状どうなっているのかということは手遅れになる前に途中の段階で聞く必要があると思います。

納期は近くても遠くても、納品はぎりぎりになるもの

今回依頼したときも、また自分を省みたときもそうですが、納期には常にぎりぎりに納品されます。それぞれ個人にはやることがあり、期日や重要度で優先順位をつけます。当然遠い納期のものは優先度が低く、近くなってようやくあがってくるので常に納品はぎりぎりになります。こちらとしてはそれは当然のことと理解し、自分の作業を早めに終わらせておく必要があります。

状況確認はこまめに

納期直前になってあがってきたものが自分の考えているものと違っていてはプロジェクトが崩壊しかねません。だから途中段階でも、どういう考えでつくっているのかなど状況をこまめに確認することが必要だと思います。

マネージャーを馬鹿にしてはいけない

自分の関わっていない仕事に関して人は簡単な仕事だと考えてしまいます。生粋のギークであればJavaもpythonもC++も知らないマネージャーに対して馬鹿にした気持ちを持つかもしれませんが、実際管理側にたつと大変さはわかります。作っているだけならば納期のぎりぎりに物をあげればいいと思ってしまいますが、管理する側となれば物が出来上がってこないときのフラストレーションはなかなか大変なものです。経営者は無駄に高い給料をもらっているわけではありません。

アプリケーションの5割はグラフィック

いくらシステムがつくれても、グラフィックがしょぼいとなかなか魅力的なものは作れませんね。見栄えというのはやはり重要で、アプリケーションの5割くらいはグラフィックが握っているような気がします。15パズルのフレームワークとかがあればデザイナーだけで魅力的なアプリケーションがいくつも作れてしまいますからね。

巻き込め

有名な電通の鬼十則に「周囲を引きずり回せ、引きずるのと引きずられるのとでは、永い間に天地のひらきができる。」というのがありますが、何か作りたいと思ったらこのことは結構必要ですね。当然相手にもメリットがあるように。

まとめ

管理側にたつというのはあまり経験もない（部活動くらい？）ので今回はかなり勉強になりました。経験を続けていくとまた違った大変さも見えてくるんでしょうね。技術だけでなくこういう経験もどんどんしていきたいと思いました。