概要

前回の続きです。

前回までのあらすじ

1. プロジェクトで使用する試作品が Vue.js で開発することが決まった。
2. Vue.js で協力会社の方が開発を行い試作品が完成した。
3. 前任者から受け継いだ試作品の Vue.js のプロジェクトを実行したら 20 個のエラーが残っていた。
4. 全部自分一人で修正した。
5. ついでに Eslint すら入ってない環境だったので、既存の環境に Eslint と Pritter などを導入する。( 全く使用していない Jquey のライブラリも js というフォルダ内に何故か存在していたので抹消した )
6. ついでに Nuxt と TypeScript の環境に構築し直して、ルーティングを行った。
7. 本格的に開発が始まったので、オフショアと共同開発が決定した。
8. オフショアは Vue.js の使用経験がなく、React の使用経験しかなかったので、オフショアに合わせて React で一から作り直すことが決まった。
9. 筆者の React 経験は独学で 1 か月程。サンプルにページを追加して Redux を弄った程度、だが、筆者がオフショアに指示を出すことが決まった。

本編

今回はオフショアとの共同開発を行う上で、どのような問題が発生したか、どのようなメリットがあったか、その時どのような方法で対処したか、またどのように対処すればより良い結果が残せたか、
という反省を込めた記事になっております。あまり技術的な要素はない記事なのでご了承下さい。

そもそもの問題

1. そもそも筆者がオフショアの方と仕事をするのが初めてであり、更に人に指示などを行って共同開発した経験が少なかった。
   • それまでは設計者から指示を貰って仕事をしたり、年の近い若手同士で協力して業務を行うことが多かった。
   • そのため、初対面の外国の方との共同開発が大変だった。
     • オフショアの方は 2 人いたが、一人は日本語を話せたがもう一人は日本語を話せなかった。( 英語で質問がきて、自分は英語で対応できなかった )
2. 筆者の React.js の開発経験が不足していた。

苦労した点と対処方法

1. お互い日本語で話しても発音などの問題でコミュニケーションが上手くいかなかった。

   • Slack などを使って文章による対話を行うことで対応。( オフショアも識字は得意だったのでお互い文通の方がコミュニケーションが上手くいった )
   • 日本語の敬語や丁寧語が伝わらなかったので、単語を強調し、友達のような話し方で話した。( 相手も年が近かったからできた方法でした。でもこれのお陰でその人と仲良くなれました。)
   • 同じ技術の用語でも違う言い方をすることがあったので、伝わらない場合、技術用語の言い方を変えた。( リポジトリ → Repository 　など、日本人がカタカナ用語で言っている言葉が通じないことがあった )
   • 同じく、なるべく技術の用語は英語で書くように注意した。( GitHub、VSCode、Repository、k8s など )
   • 無意識に.NET Framework で使う用語を使っていたので言い方を変えた。( Label → ReadOnlyText など )

2. 文通に慣れてくるともう一人の方が、英語で質問をしてきた。

   • Slack で英語を送るように頼み、自分はその文章を Google 翻訳で日本語に翻訳して、質問を理解し、回答を行った。

3. React について理解不足なので、どんなライブラリや環境構築を行えばいいかわからなかった。

   • 以前に React で開発する可能性があるから React について調査して欲しいと言われたので React で開発を行った場合、 Vue.js で使用していたライブラリと比較して何を使えばいいか調査してスプレッドシートにまとめておいた。
     • そのスプレッドシートを元に Vue.js で行っていたこの機能は React では何が対応する、などをオフショアの方とその場で話して合意を取り、環境構築で使用するライブラリを逐一スプレッドシートに追記するように合意を取った。( Vuex → Redux、TypeScript → Flow、vue-router → react-router-dom など )

4. オフショアの開発方法と、試作品での開発方法で意見が対立した。

   • WebPack を使うか否か、静的型付けを行うために TypeScript にするのか Flow を使用するのか。
     • それぞれのツールの良し悪しを調査し、打合せを重ねてよりプロジェクトに適したツールを使用した。

5. 画面のイメージが Excel のお絵かきでオフショアに納品された。更にその画面のイメージでは色合いや大きさなどが実際に作る予定の試作品とマッチしておらず、開発するのに必要な情報が不足していた。

   • 別の部署で Adobe XD を使用していると聞き覚えがあったので、その部署の方に使い方や利点などを教えて貰い、プロジェクト内に浸透させた。

よかった点

1. オフショアのフロントエンドに関する技術力が高かったこと。

   • 自分がオフショアの方に React について質問した時に、懇切丁寧に応えてくれた。
   • 自分も Vue.js をやっていたのでルーティングなど共通の概念は理解できたので、実装方法に関する話しなどは順調に進んだ。

2. オフショアが OSS に精通していたので GitHub などでのやり取りは社員よりも上手くいき ( 社内で GitHub 導入中であったため )、また GitHub Featerure Fllow など効率的な運用方法はオフショアから教えてもらい、プロジェクト内に浸透できた。

3. 一部のライブラリは Vue.js でも React でも使用可能だったので、ライブラリの選定にかかる時間を短縮できた。( Jest、StoryBook、JsDoc、husky )

4. オフショアも使用経験のなかった Jest、JsDoc、husky、StoryBook などに関しては自分がプロジェクト内で有用性をアピールし、導入することでチーム開発効率化がなされた。

5. オフショアの影響もあり、弊社のレガシーな技術でのプロジェクト開発が一部モダンな物に置き換わり、社内に浸透した。( SVN → GitHub 、VSCode、Excel の画面イメージ → Adobe XD )

6. 日頃から資料やメモなどは全て Markdown やスプレッドシートで作成しており、Gsuite の Google ドライブで管理していたため、オフショアとの情報のやり取りや管理方法で戸惑うことが少なかった。

反省点

1. 社内に自分以外の React の有識者がいなかったこと。(オフショア以外のメンバーからもフロントエンド、クラウド、GitHub などの質問が全て自分に集中して対処しきれなくなった。)
2. プロジェクト内でフロントエンド以外にもクラウドや GitHub の管理も担当していたので、フロントエンドに集中できなかったこと。
3. React を独学した経験を活かして、最初から Vue.js ではなく React.js を推奨して開発を行うことをしなかったこと。( 開発初期では、内製を目指していたので、多人数で開発する場合、JavaScript の経験者が少ないのであれば学習コストの低い Vue.js が最適だと判断してしまった )

まとめ

日頃から学習した内容を資料として残しておいてよかった。効率的な方法で情報をまとめておき、臨機応変に対応すれば不意の事態にもある程度対応できることがわかった。

参考記事

StoryBook が何故必要か？(Vue.js 編)

husky で git commit 時に npm test を走らせる

この頃流行りの Jest を導入して軽快に JS をテストしよう

JSDoc 使い方メモ