tanakajiroの日記

どうすれば明日はもっと面白くなるのか

【完結編】すでに知的生産物に国境はない。 海外クラウドソーシングで作るiphoneアプリ<part Ⅲ >

「失敗するかもしれないね」
「でも、失っても数十万円ならやる価値あるよね」
「やってみるか」
そんな会話で始めた海外クラウドソーシングで作るiphoneアプリの最終章になります。(PartⅡ:http://tanakajiro.hatenablog.com/entry/2014/12/12/185237)

f:id:tanakajiro:20141222014539p:plain

 

■開発■

パキスタンのデザイナーHafizのデザインも終わり、

ここからはインド人開発者Mukeshがバリューを発揮します。

 

<Q1>開発を着手するのに何が必要か?

必要最小限なドキュメントは仕様書とUI遷移がわかるものです。

たぶんいろんな仕様書の書き方とか本があると思いますが、
開発者が困りそうなところを明確にするというのが目的で、
細かすぎて読むのダリーよってなってもいかんし、
粗すぎて考える余地を与えすぎちゃうのもよくないという思想で書いてます。
なので、こだわりがあるポイントの深度は深く、
一般的な機能の部分はさらっと書いておけばOKだと思います。

(1)仕様書
-ユースケース
ユーザー視点に加え、システム視点とスタッフ視点のものも用意しました。
結局何が出来ればいいの?ということを網羅的に見れるメリットがあります。

f:id:tanakajiro:20141222013604p:plain

 

-機能一覧
どんな機能が必要なんだっけ?というものの一覧になります。

f:id:tanakajiro:20141222013648p:plain

 

-機能毎のシーケンス図
その機能を実行する時にユーザー、クライアント、サーバーがどんな順番で
どんな情報をやりとりするのかを表現した図になります。

f:id:tanakajiro:20141222013757p:plain

 

-機能毎のフローチャート
その機能が条件分岐する場合や何かアクションをして欲しいことを
表現した図になります。

f:id:tanakajiro:20141222013930p:plain

 

-機能毎の詳細条件
例えばユーザーネームは何文字以内とか、時間はローカルタイムで表示とか、
そういった細かい設定を思いつく限り書いておきます。
ここで細かく書いておかないと、書いてないじゃんと言われちゃいます。

※セキュリティの関係でUPはやめておきます。 

 

(2)UI遷移を表現するもの。
Prottにデザイナーが作ってくれたものをアップロードすればできます。
※こだわりのある動きはこのツールでは表現できないので、
 このタイミングで文章で具体的に伝えておいた方がよかったです。

f:id:tanakajiro:20141222014035p:plain

 

<Q2>DBとかAPIの設計とかいらないの?

本来的には設計して渡すのが親切だと思います。
でも、今回はデッドラインがあったので、エンジニアに設計をお任せしました。
ちょっとしたジョークなんですが彼の最初の設計書は手書きのノートをPDFにしたものでした。
これにはN氏と一緒に爆笑してしまいました。
でも、内容はしっかりしてたし、ちゃんと伝わりました。
相手にきちんと伝われば方法は何でもありだな、としみじみと感じさせる出来事でした。
※後にちゃんとテキストデータに落としましたが。

パートナーのN氏からは「いい仕様書インターフェイスについて記載している」
=「サーバーとクライアントがどんな情報をやりとりするのか明記している」
との助言を頂きました。
が、そこまではイメージが湧かず今回は出来なかったです。

 

APIってなに?
よくよく出てくるこの単語、わかるようでわからないですよね。
APIドラクエの村人みたいなものと理解してます。
主人公「アリアハンに行くにはどうすればいいですか?」
村人(API)「あの街に行くには、北にある洞窟へ行けばいい」
という感じで、答えを返してくれます。

知らない質問や異常な質問をすると
村人(API)「そんな街はありません」とか
村人(API)「4文字以上で聞いて下さい。」
という感じで回答を返すこともできます。

要するにクライアント(アプリ)が尋ねるべき村人が
インターネットの中にいて、クライアント(アプリ)が
尋ねると適切な答えを返してくれるイメージです。
※村人の場所はURLで特定されます。

 

<Q2>開発中のプロジェクトマネージャの役割は何か?

私はその道のプロではありませんので、
仕様バグと言われる「そのまま実装しちゃうとユーザーが困ってしまう仕様」が点在していました。
予め自覚と覚悟があったので以下の原則で動きました。

 

(1)質問には即レス
エンジニアの手をできるだけ止めてはダメですし、
彼らにとってストレスになってしまいます。
プロマネからの回答が遅いのに納期を守れなんて横暴だ。
 もう知らん!言われたとおりに実装したれ!」となりかねません。
些細な質問にも丁寧に即レスを心がけました。
※とはいえ時差が4.5時間もあるとタイムリーに回答できないこともあります。
 なので、googleドキュメントでQ&Aを内部で回していきました。 

(2)回答には背景を添えて回答する
背景に納得してもらえれば、
周辺の疑問を一気に片付けることに繋がります。
これをきちんと説明するのは企画者の務めですし、
結果的に時間短縮につながると考えて時間をさきました。

(3)仕様バグは謝る
素直になりましょう。
そして、少しだけ時間をもらって考えてから回答しましょう。
指摘してくれたことには当然感謝します。

(4)前進と提案は賞賛する
正直、進捗を見せることは彼らにとって本質的なミッションではありません。
なので、見せてくれたら喜ぶべきだし、
モノができてくる喜びはチームで共有すべきだと思います。
ここで、細かくつついてもいいことないので、
向こうがレビューしたいというタイミングまで待ちましょう。

(5)不安なところは専門家に頼る。
ググっても出てこない個別事象やキメの問題はやっぱり経験が必要です。
ここはそう簡単に埋まらない壁があると思います。
私の場合はデザインや見せ方で困ったらDesign Directorの山本氏、
仕様や仕組みの部分で困ったらTech DirectorのN氏に相談して決めました。
予め自分のスタンスを決めて、相談すれば5秒で回答をくれます。
やはり餅は餅屋ですね。

 

<Q3>テストってどうやればいいの?

テストフライト(自分のiphoneにインストール)してテストします。
oDeskにはテスト専門で飯を食べている人もいるぐらい、
実はこのフェーズは奥が深いです。
でも、そんなお金がなければ自分で試すしかないです。
ただ闇雲にテストしても、モレがどうしても発生してしまうので
「機能軸」×「デザイン,動き,機能,その他」というマトリックスで、
それぞれの項目を網羅的にチェックしていきました。

f:id:tanakajiro:20141222014321p:plain

(1)ver.Xをテスト
(2)不具合をエクセルに記載
(3)ver.X+1をリリース
これを10回以上まわしました。結果として20日ぐらいかかりました。
開発のMukesh氏には「ヘイ、田中、これはいつ終わるんだい?」と言われてしまいました。この部分はかなり経験が必要なんだろうなと思われます。

今回、大失敗したポイントがあります。
時間軸でチェックするのが漏れていました。
結果として、「2日目に使おうとするとフリーズする」
という目ん玉が飛び出るくらい重大なバグを見逃してしまいました。
反省です。※ver1.1で解消させました。

 

<Q4>開発が終わったら、何をすればいいのか?

apple developerのitunes connectでアプリ名とか説明文とかを掲載して、
作ったアプリをアップロードすれば完了です。
申請ボタンをおしてappleのレビューを待ちます。
今回はなんと奇跡的にappleから申請拒否を受けることなく通過しました。
でも結局10日ぐらいかかっちゃいました。

申請準備物は競合調査とか、画面キャプチャどうするとか以外に時間がかかってしまうので、テスト段階ぐらいから準備をはじめておくのがベターだと思います。

※法人化していないと、複数人apple developerを使うことはできません。
 派生する問題としてCertificatesをうにゅうにょ調整したり、
 開発者とappleアカウントを共有しなければならない問題が発生します。
 ここらへんは覚悟が必要です。

※後にpalmie(https://appsto.re/jp/rKmx3.i)の伊藤さんからDL数を伸ばすコツとして、
 アプリ名とキーワードの設定が極めて重要だという話をお伺いしました。
 乱暴にまとめると、ターゲットが検索しそうなワードをアプリ名とキーワードに
 詰め込みまくるそうです。※ver1.1で対応しました。


■総括■

一度も顔を合わせたことのない、
しかも異国の人と仕事するわけですが、
一緒にやって感じたのは「直接合わなくても信頼関係は築ける」ということです。

これはプロジェクト始動時の会話の一場面なんですが、

 

「it will happen many problems, but I hope we can coopolate with well.」

 

Mukesh

「We will manage it together Tanaka.. that's why it's always called team effort.」

 

この一言ですっかり、私は彼のことを信頼しようと思いましたし、
何よりも彼と一緒に仕事がしたいと思いました。

「こんな言葉、アニメでしか見たことねぇよ」とか、
青臭くて小っ恥ずかしいと日本人なら思ってしまいますが、
シンプルにそう思うなら言うべきだし、言われた方は意外にその気になるものです。 

以上、

まずはやってみるから始めるクラウドアウトソーシングによるアプリ開発でした。

 

最後にはなりますが、
本プロジェクトを一緒に推進してくれた山本氏、N氏がいなければ
100%実行されなかったことをここに添えておきます。

 

ご拝読ありがとうございました。【完】

 

=======================

「今日やることを一つだけ宣言するTodo管理アプリ」
apple store:http://urx2.nu/eQyU

※ご質問/ご意見等あればお気軽にお問い合わせください。
tanaka.j.tomohiro@gmail.com

=======================