はじめに
弊社プロダクトの開発スピードアップを見込んで、とある国のオフショア企業の力を借りることになり、その開発ディレクティングを行いました。
結果的に契約期間の半年で打ち切りとなりまして、それにいたった過程・所感などをここに残しておきたいと思います。
契約期間
半年
（※そのうち、BSEとPGは5ヵ月）
メンバー構成
- BSE（ブリッジシステムエンジニア）×１
- 現地のPG、テスターへの仕様伝達・メンバー管理・請負企業側とのコミュニケーションが主な業務。
- PG（プログラマー）×5
- 開発の実行部隊。皆日本語は未対応だが、英語は対応可能。
- テスター×4
- 各チケット単位でテスト仕様書の作成・テストを実施。
- コンター×１
- おそらく、コミュニケーターの略。現地語しか対応できないメンバーへの橋渡し役。こちらが作成したチケットの現地語翻訳や、テスターが作ったテスト仕様書の日本語翻訳の他、BSEが不在時の連絡役として対応。
メンバー背景
PGの採用条件として理系大学を卒業していることが必須。コンターは外語大出身、テスターは文系学部出身など、大学の出身学部により職位は別れているようで、PGはテストをしないし、テスターは開発をしないなど完全分業体制であった。
（蛇足ではあるが、WEB案件はPGが取り組むにあたって価値の高い案件ではなく、モチベーションとしては高いものではなかったらしい。）
メリットと感じた点
初回プルリクの作成が早い
平均的に、作業開始から１日でプルリクを作成していたので、スピードは早かった。
BSEはいつでもビデオチャットでチャットよりも早い仕様の伝達ができる
チャットで意思の疎通が完全にできていなかった分、こまめにビデオチャットで対応できたのはよかった。
テスターのテスト粒度が細かい
開発会社側のテスターだけでなく、弊社側でも仕様書の作成を行ったが、こちらはテスト専門にやっていた人間はいなかったため、どうしても、テストケースの粒度が粗くなってしまっていた。
その一方で、テスターは細かい粒度でテストケースを作成していてくれたため、テスト仕様書の品質向上に繋がった。
課題と感じた点
報告・連絡の意識が低い
日本ではありえないことだと思うが、BSEと連絡が全くできなくなる日が三ヶ月のうち二日あった。その理由は体調不良ではなく、私用の理由。BSE以外のチャットでのやりとりが皆無（おそらくPGはやりとりしないといったルールが開発会社側にあったようである。）であったため、その間はPGへの修正依頼が不可能となってしまった。
また、改善策としてBSEが不在時にCTOやコンターが代わりとなることを約束したものの、CTOやコンターも連絡が遅い・一切返信しないなどがあり、一気に信頼度が落ちた。
日本語の習熟度が低い
これは仕方がないこととはいえ、仕様をわかりやすく伝えるためにチケットやビデオチャットでのやり取りの際の文章量が多くなり、日本人PGと比較すると、明らかにコミュニケーションコストの差が大きかった。
また日本語非対応のテスターが作ったテスト仕様書をコンターが翻訳したものをチェックしたが、わかりにくい表現・日本語となっていない部分などが多く、その修正に2~3人で１０数日何時間と対応することになってしまった。
プルリク 後の戻りが最低2~3回生じる
こちらの仕様書の不備、開発会社側の仕様書の低い理解度、PGのテスト未実施、BSEのテスト品質の低さが原因かと思われるが、一つのチケットがマージされOKとなるまで最低２〜３週間かかってしまっていた。
Gitのフローを独自の運用方法以外受け入れない
githubの運用ルールを共有したものの、一切守ってもらえなかった。理由としては、他者で身につけた運用ルールの方が価値が高かったため、守る必要性を感じなかったというのがBSEの言い分であった。
こちらとしても、運用ルールの見直しをするべきであった。しかし開発会社としても、受注元の提示したルールには従う、もしくは新しい運用ルールを提案する姿勢を見せるべきだと思うが、ただこちらの意見を無視するだけだったので、正直ありえないと感じた。
PGがテストをできない
開発会社社内で完全分業としていたため、最初テスターとは契約していなかったため、PGの作業確認・テストはほぼこちらの作業となっていた。PG自らが全くテストをしないせいか、その戻りは確実に２〜3回発生していた。
とりわけ顕著だったのが、デザインラフの画像ファイルを元に修正するチケットで、期待する機能の色になっていないのに完了報告をしたこと。目視で修正点を確認できるにも関わらず、それに気づかず（もしくは無視して）報告するのは正直理解し難い部分であった。
BSEのテスト品質が低い
PGがテストできない分、BSEがテストを実施した上で報告しているということではあったものの、上記のデザインラフの件もあり、BSEの作業チェックはあまり機能していないようだった。
テスターがアカウント作成ルールを守らない
該当プロダクトにログインできるアカウント属性が十数種類にも及ぶため、アカウント名にはルールを儲け入力・登録するように他の関連会社ともルールを守るように伝達した。
しかし、12月末の契約最後までルールを守らず、テスターがテストアカウントを登録してしまったため、「aa」などのクズデータアカウントが今もテスト環境で残ってしまっている。
日本と休日が異なる
これは仕方がない点ではあるが、日本の国民の休日はオフショア側にとっては関係なく稼働日であったため、こちらが休日の際も、BSEからの相談・質問に対応しなければならなかった。（と書いたものの、私自身休日稼働することに抵抗はないので一番課題点は低い。ただし、こちらからの返信が遅くなってしまったのは申し訳なかった。）
インターン生を１人工のPGとして作業させていた
これはBSEが実際に契約完了前にこっそり教えてもらったことであるが、PG３人いたうち、1人はインターン生であり、全くの初心者であったらしい。これは契約開始時に伝達はなかったことである。
反省点
仕様書を用意していなかった
システム・機能が複雑になっているものの、これを外部の人に理解してもらうために十分なドキュメントを用意していなかった。また、作業フローに関しても契約後に用意したので、準備が遅く、これもコミュニケーションコストをあげる原因になっていた。
まとめ
結果的に、100件以上のバグ改修・新機能開発対応とテスト仕様書の作成など助けられた部分は決して小さくはない。しかし、その反面コミュニケーションの難しさに苦しむことが多く、自分で改修した方が早いと感じる部分も多々あった。
今回の開発会社特有の問題点もあったものの、次回またオフショア企業と連携して作業を行う際は、コミュニケーションの壁がどれほどあるかを選定の時点で考慮すべきであり、かつ仕様を全く理解していない外部の人にも理解を助けるようなドキュメントを残すことは必須。