こんにちは。LIGフィリピン支社代表のせいと(@seito_horiguchi)です。
フィリピン・セブ島に来て1年半が経ちました。なんだかあっという間です……。
これまでセブ島でエンジニアさんを雇い、教育し、日本との仕事を受ける体制を作ることに注力してきました。初めは、急にエンジニアがいなくなったり、クオリティが低かったりと、失敗が続き大変でしたが、最近はいい感じに回るようになってきたと思います。
そこで今回はオフショア開発でアジア圏のエンジニアとプロジェクトを成功させるため、普段僕らが取り組んでいる開発フローについてご紹介します。他の地域でも使えると思うので参考になれば幸いです。
もくじ
1. コミュニケーション
指示書はなるべくシンプルな英単語＋記号を用いる
LIGのサイト制作では、とくにアニメーションの実装がよくありますが、これを説明するのはなかなか難しかったりします。加えて、日本の社員は全員が英語で喋れるわけでもないため、英語で指示内容を書くとなるとさらに大変です。
そこでアニメーションの指示書には、なるべくシンプルな英単語と記号を使って表記しています。また、ソースコードへのレビューやコーディングルールを指示する場合は、NG例、OK例を用いています。こうしておくと、ある程度コーディングができるエンジニアなら説明文がなくとも理解してもらえるようになるんです。
ある程度分量のある指示の場合は、Google translateなどで翻訳した際に変換されやすくなるよう、きっちりした文章でかつコピペ可能な状態にしておく（画像にしたりしない）といいでしょう。
チケット管理はマストで
そのプロジェクトにおいて、エンジニアが行うべきタスクは洗い出してチケットで管理します。○○機能の実装、バグ修正対応、デザイン調整、デバッグなど、タスクになりうるものすべてを管理します。こうしておくとToDoリスト代わりにもなるので、タスクの抜け漏れを防ぎやすくもできます。ちなみにLIGでは、チケット管理はRedmineをカスタマイズして使うか、Bitbucketで行っています。
※フィリピン支社でのプロジェクトでは公にお見せできるものがなかったため、上の画像は日本本社での実際の仕様例です。
作業内容は口頭で依頼＋チャット上で記録
ある程度まとまったタスクを依頼する場合はチケット管理が有効ですが、ちょっとした作業を依頼するのにチケットをいちいち発行するのは面倒です。その場合は口頭で依頼した上で、必ずチャット上で作業内容を送ります。
依頼内容が記録に残っていることに加え、合計2回も言われたら記憶にも残りやすいですし、言った言わない論争に発展することもないので平和にことが進みやすいです。
毎日2回の進捗報告
僕らは毎日2回MTGを行っています。まず朝に全員出社したら「その日取り組むタスクとどこまで進めるかの目標」を確認しあいます。もしエンジニアがその日何もタスクがない or 優先すべきタスクがわからないなどあれば、このタイミングでそれらの問題は解消します。また、夜には「その日取り組んだタスクとどこまで進んだかの進捗」の確認です。ここでもし進捗が悪い場合には残業の必要性があるかも判断します。
報連相を行うため、進捗確認のため、コミュニケーションをとるためなど色々理由はありますが、MTGを頻繁に行う一番の理由はメリハリをつけるためです。各々のタスクをはっきりさせ、ダラダラと仕事しないようにしています。
2. 品質管理
チェックリストの活用
LIG Philippines Inc.では納品前に必ずクリアにしておくべき項目を洗い出し、リスト化しています。エンジニアは、納品前にリストを必ず埋めてもらうことで、タスクの抜け漏れ回避＆クオリティ向上に努めてもらっています。リストには以下のような項目があります。
品質アップのリスト
- バリデートエラーは通したか
- CSS, JSは結合＆圧縮されているか
- OGPは設定されているか
- console errorはないか
- Mac Safariでのデバッグは済んでいるか
- Windows Edgeでのデバッグは済んでいるか
- Windows IE 11でのデバッグは済んでいるか … etc
プルリクチェック
エンジニアがコーディングを行う際、Git及びGit-flowを用いています。また、ブランチを終了させるときは自分でマージはせず、必ずリーダーを含む他のエンジニアにプルリクエストを送り、2票獲得するまでマージできないというルールで進めています。他のエンジニアがレビューを行い、もしソースコードや実装方法に問題が合った場合は都度コメントしてチェックしてあげる体制です。こうしておくことで、ソースコードの品質を担保しています。
デザインチェック
LIGではデザインをこだわって作っているため、再現性を重要視しています。そのため、デバッグに加えその部分も細かくチェックを行います。いわゆる「Px perfect」です。
最終的にはデザイナーによるクオリティチェックが入ります。しかし、その前になるべくissueは潰せるよう、エンジニアにはプルリク送信時にPSDとHTMLのキャプチャを重ねた画像も同時に送信してもらい、デザインの再現性を確認しています。コーディングデータをサーバーにアップしてもらってもいいですが、それだけでは第三者の確認の手間が増える＆セルフチェックを怠ってしまう可能性があるため、このようにしています。
※ちなみに上のキャプチャ画像はちょっと揃え方が甘いダメな例です。笑
3. 開発環境
テンプレート
LIGでは日本、フィリピン問わずフロントの開発環境にはfrontplate-cliというツールを使っています。元CTOの林が開発したもので、SassやBabelによるコンパイル、バリデーション、Webpackなど盛り沢山な内容になっております。オープンソースなのでご興味ある方はぜひ。
また、LIGではWordPressを用いた案件が多いため、バックエンドエンジニアによって開発されているWordPress用のテンプレートも用意して使っています。（こちらはオープンソースではないのであしからず……）
社内用CSS&JSフレームワーク
LIG Philippines Inc.では大体のプロジェクトで汎用的に使えるよう、社内フレームワークを用いてます。いわゆるBootstrapのようなものですが、一般的なそれと違う点は、社内のコーディングルールや開発環境に則した作りになっている点です。
受託案件では、主に「メディアサイト」「コーポレートサイト」をよく作るので、それに合わせてよくありがちなコンポーネントや機能を取り込んでいます。これによって開発効率の向上、また新入社員にはこれのコードを熟読してもらうことで社内のコーディングルールや設計思想に慣れてもらっています。
コーディングルール
コーディングルールも独自に用意しています。といっても、大体「Googleのコーディングルール」と「SMACSS」をかけ合わせたような内容です。
あまり独特なルールを足しても覚えきれない＆共有が大変なので、プロジェクト特有のオーダーがない限りは、シンプルに済ませています。ここでもやはり、NG例、OK例を用いて表記することで、言語の壁を超えて理解しやすくできるよう心がけています。
まとめ
僕は始めた当初、国や文化が違う人間同士で開発するのはなかなか大変なことだと思っていたのですが、きちんとした環境と土台が用意できたので今は何とかなっています。笑
また、弊社では現在、通常の「受託開発」と「ラボ型開発」の２パターンでお仕事のご依頼をお待ちしております。
もし何かあれば、下記より気軽にご連絡ください！
エンジニア不足を解決するLIGのサービス「ギルド開発」って？そのメリットと中身をご紹介します。
セイト
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
