FLINTERS Engineer's Blog

FLINTERSのエンジニアによる技術ブログ

オフショア開発の品質を上げるためのTips

オフショア PHP

f:id:k_chindamaikul:20150722151232p:plain

こんにちは！@kakeyangです。張り切って連投です！

前回の記事では、オフショア開発でこんなことやると失敗しますよー的なことを書いたんですが、今回はそれを踏まえて、オフショア開発をうまく回すためにSEPTENI TECHNOLOGY社でやっている取り組みをざっと挙げてみたいと思います。


やはりオフショアといえば品質が上がらないというイメージが常に付きまといますので、品質を上げるための施策にフォーカスしています。
まだまだ手探り段階で、体制や仕組みとしてもまだまだこれからなのですが、一定の効果は出てきてるんじゃないかと感じています。

ポイントは、早期フィードバックを促すということと単体テストの質を上げることだと思っています。



Scrumで小さく作って小さくデプロイ

f:id:k_chindamaikul:20150722151316j:plain

※一部画像を修正しています。

オフショアで一番怖いのは、コミュニケーションロスに依る認識相違、つまり、「全く分けのわからないものが出来上がってしまう」という状況です。こういう状況を作らないためにあらゆる成果物を細かく、そして泥臭くレビューするわけですが、それでも認識相違は起きます。テスト中に「あー、そう解釈されたか・・・」と悔しい思いをするわけです。

なので、逆に認識相違は起きるという前提で、むしろそれをいち早く検知して、直してもらうことができる体制が非常に重要になってきます。
スクラムそのものを今更ここで説明するつもりはありませんが、下記のような取り組みをしています。



  • 1スプリントは2週間。
  • スプリントのはじめにSprint planning meetingを開き、3時間程度であらゆるタスクを洗い出し、チケット化する。１チケットの想定工数は８時間以内になるように細分化する。
  • スプリントの終わりにReview meetingを開き、次のスプリントに活かすべきアクションを、具体的な実行プランとともに提案してもらう。
  • ホワイトボードでチームとしてのToDoがきちんと消化されたかをスクラムミーティングで共有する。
  • スクラムミーティングは朝会だけでなく夕方もやる。個人のタスクを本当に終えているかをメンバーの前で宣言させるため。
最初はオフショアでアジャイルなんで無理じゃね？って適当に考えていましたが、そんなことないです。むしろウォーターフォールのほうがリスクが大きいと感じ始めています。



SQAチームを手厚く

日本人の僕から見て、ベトナム人エンジニアの単体テストの質はやはり低いです。
感覚値ですが、「コーディング終了＝３０％」、「単体テスト終了＝５０％」程度の出来です。

結合テスト開始時に、テストすらできないレベルの品質であることはよくあります。

また経験上、ベトナム人エンジニアがテストケースを作成し実行することは決定的に向いていません。

上記の理由から、開発者が詳細設計し、コーディングしている間に、並行してテスト設計、テストケースを作成することと、テストの量で品質を穴埋めするためにSQAチームを設けることは必須です。ベトナムではSQAはほとんど女性（中途採用時の応募の９割５分が女性）なのですが、ベトナム人女性は全体的に非常に真面目で勤勉のため、品質向上にかなり貢献してくれます。



TDDを採用

しつこいですが、最大の課題は単体テストの質の低さです。なのでTDDでコードを書かせて、必ずテストスクリプトを成果物として上げるようにしています。

ただTDDを採用している理由はそれだけではなく、もうひとつ大きな理由が、デグレを防ぐためです。

オフショアでは外国人（日本人のこと）が書いたコードをメンテすることも多いので、現地のエンジニアからすれば謎な部分って結構あると思います。なので機能追加するたびに既存機能への影響をすべて把握しきれずにデグレする、というケースも結構、というかめちゃめちゃ多いです。

デグレは品質の低下を招く大きな原因の一つです。

ということで、ある機能の実装にはテストスクリプトもセットでついてくることを前提に、gitでpushするときにJenkinsで全テストスクリプトを実行することで、今回のソースコードの修正が既存に影響を及ぼしていないかを検知する仕組みを作るために、TDDを採用しています。まだあまりなじんでないですけど。



Jenkins先生でCI

一番やりたかったのはこれです。

継続的インテグレーションを実践することで、ビルドスクリプトでデグレの検出をしつつも、優秀なSQAがなるべく早くテストできる状況を作り出すことができるので、早くやりたいんです。
ソースコードの静的チェックも同時に行い、ソースコードの品質の担保も先生に任せようかなと思っています。

が、僕らの場合は今からCI環境を育てていこうかなぁ、という段階です。だからすごく楽しみなんです。

下記の資料は、僕が以前、現地メンバーに「継続的インテグレーションとはなんぞや」を伝えるために開いた勉強会のものです。なので上っ面しか書いていませんが、これからCIの導入を検討しているようなチームにはちょうどいい内容じゃないかなと思います。


ちなみに、上記資料は無駄にデザインに凝ってみました。デザインにあたっては、下記のページを参考にさせていただいています。どうもありがとうございました。