オフショア開発をうまく行うために大切なこと（依頼する側目線Ver.）

こんにちはこんばんは。
オフショア開発をお願いして、依頼する側目線で記事を書こうと決めてからだいぶだいぶ時間が経ってしまいました。
覚えているかぎりで投稿します。随時更新予定。

アンチパターンとしてこれからオフショアをお願いする人の役に立てば良いなと思います！

提供するサービスの価値・定義

何より大事ですね。当事者はわかってるつもりであまり説明しなくなりがち。
私が携わった開発は、すでにWebサービスとして展開しているサービスをアプリ提供していく、というものだったので「アプリとして何を提供するか」はもちろんのこと、「Webサービスとどの程度連携させるか？」が肝でした。
例えば、会員登録タイプのECサイトをアプリ展開するとしましょう。
・会員情報
・購入履歴（Web/アプリ）
・会員特典
・閲覧履歴（Web/アプリ）
・お気に入り（Web/アプリ）
・割引（Web/アプリ）
...
やろうと思えばいくらでも連携させられるし、やりたくなければ連携させないこともできる。
サービスの価値という目線で、何が必要で何が不要かを考える必要があります。
ここら辺がグダると、「こんなこともできないの？」なサービスになっちゃうんですよね。
そしてこの言葉は携わってる人間に対して与えられるダメージが大きい…

でも、オフショアで関わっているブリッジやエンジニアからすると、提供するサービスの価値がどうということに関心はなく、「何をつくればいいのか？」がわかっていればよいわけで。ここら辺がきちんとしていなかったため今回関わったプロジェクトで私は３０回ほどHP0になりました。

設計書

開発する上で絶対大事になることですよね。
結構ありがちな、「設計書がない」「フォーマットがない」「誰かの脳内にしかドキュメントがない」
このないない尽くしはとても苦しいです。最低限のドキュメントは必要。
（でもドキュメント作るとその後の保守が面倒ですよねー、わかる。）
そして正しい日本語、もしくは英語で書くのが大事。
曖昧な書き方すると後でとんでもないことになる。
理由は、日本語ならブリッジが英語や現地の公用語に訳した状態でエンジニアに配布するから。そこで誤った解釈をされるとせっかく用意したドキュメントもただの文字列になってしまいます。
今だとスプレッドシート上で翻訳かませたりとかできるので、そういうのを駆使しても良いです。

画面設計書なら、
* 画面の役割
* オブジェクトの動き/役割
* 遷移先と戻り先
最低限これくらいは書いておきたい。

画面数増えれば増えるほど選択肢が広がって、どこに遷移するのが正しいのかわからなくなります。

ボール

これ特に重要。
例えばAPIならとりあえずモックでもプロトでもなんでもいいからなんかリクエストしたらなんか返してくれる状態にしておく。
並行開発になる場合もあると思いますが、依頼者側がボールを持っている状態をつくりだすとその途端にオフショア側の進捗が悪くなります。
相手に待ってもらう状態をつくるのは基本的にNGです。
手が空いてると別プロジェクトを手伝いだすエンジニアがいたり、帰ったり、すぐ帰る癖がついたり。。
お互いにとっていい結果につながらないので、事前準備はしっかりしておくことが大切です。