見出し画像

エアクロ流・オフショア開発のドライブ方法

この記事は airCloset Advent Calendar 2021 の 5日目です。

はじめに

こんにちは!
エアークローゼットでディレクター兼たまにエンジニアをしているRibery(Qiita)です!
Riberyは社内ニックネームで、外国人ではありません。。。!

この記事では、エアクロの開発を一部オフショアにお願いしているので、どのように運用しているのかを紹介していこうと思います。

エアクロの独特の開発体制と会社の文化をうまく融合した、エアクロ流のやり方ではありますが、ある程度の再現性はあると思います!

オフショア開発を検討していたり、お願いしているけど開発がうまくいかないな…など悩みを抱えている方に参考になればと思います!

結論

実際に開発をお願いしてから、一番問題になったのは、BSEを経由した作業・コミュニケーションのコストが大きいことでした。

そこをどのように解決していくか、の施策を実施していきました。

  1. 成長するチームの構築

  2. 仕様の解像度を高める

  3. 弊社エンジニアとOSEの協力関係の構築

  4. 開発におけるセキュリティを担保した権限の付与

これらの実施背景と、どのような効果があったのかをそれぞれ書いていきます!

登場人物

  • PL(弊社):案件を起案・リードするプロジェクトリーダー

  • TD(弊社):PLとエンジニアをつなぐ、開発ディレクター(弊社ではテクニカルディレクターと呼び、その略)

  • 弊社エンジニア

  • BSE(パートナー):オフショア開発メンバーと弊社プロパーをつなぐ、ブリッジエンジニア。日本語が堪能です。

  • OSE(パートナー):オフショア開発メンバー。実際にコーディングをしてもらいます。

1. 成長するチームの構築

課題

私達がパートナーにしたいと思うチームは、同じビジョンを描き、向上心を持っていて、僕らにも大きな影響を与えてくれるようなチームです。

オフショア開発チームにそれを求めているってのを私は聞いたこともなく、今回お願いしているパートナーも前例はありませんでした。

対策

課題を解決するためには、「“ワクワク”が空気のようにあたりまえになる世界へ」というビジョンに賛同してもらえるように取り組無必要がありました。

どうしたかというと、まずは弊社のビジョン、ミッションを共有し、なぜそれを描いているのか、そして、ビジョンを実現するためにどうしているのか、を説明しました。

それから、OSEひとりひとりの個人的な将来の夢や、エアクロの開発に参画したからには叶えたいこと、習得したい技術力など、あらゆる意見をZoomではありますが、直接、顔を見て話し合いました。

そして納得して参画する心構えになってもらってから、参画するにあたって、どういうチームになりたいかを「ミッションステートメント」という形で言語化してもらいました。

ミッションステートメント

これを開発現場にポスターのように飾ってもらってます。

結果

弊社のビジョンを受けて、各OSE、BSEが高い目標を自ら設定してもらいました。

そして、ビジョンを共有することで開発中にUXに関する意識を持ってもらい、提案をいただくこともあります。

さらに、後続の課題にもしっかり取り組んでいただいたり、コーディングのスキルもかなり上昇して、成長するチームのマインドに進化しました!

2. 仕様の解像度を高める

課題

今までの案件では以下のようなフロー図になっていました。

仕様伝達の流れ

ここで問題になったのが、仕様変更が起きたときに、ものすごくコミュニケーションコストが掛かることがわかりました。

実際に仕様確定から仕様変更が起きるときは、以下のフローになっていきます。

仕様変更伝達の流れ

弊社エンジニアであれば、そもそも1と3の工程をするだけで事足りるのですが、オフショア開発では、翻訳をした上で伝えなければいけません。

またPLからOSEまでにタイムラグがあるので、OSEの開発が無駄になってしまうケースもあります。

対策

仕様変更が起きにくい状況を作る必要があると考え、TD(テクニカルディレクター)というポジションを作りました。

TDはPLが考えた仕様を開発に落とし込むために設計をしたり、PLが作成する総合テストをレビューしたりして、細かい粒度で仕様を固めていくようにしました。

仕様伝達の流れ(TDあり)


結果

開発前に細かくチェックをすることで、認識齟齬がなくなり、仕様変更の回数が大きく減少して、開発も効率よく消化できるようになりました。

3. 弊社エンジニアとOSEの協力関係の構築

課題

パートナーに案件をアサインして開発を始めたときに問題が起きました。

弊社エンジニアであれば、仕様の質問、技術的な質問はがあれば基本オフィスに出社しているので、すぐPLに質問したり、横にいる先輩エンジニアに協力を仰ぐことができます。

しかし、OSEは仕様の質問、技術的な質問をするときは、基本的にBSEを経由して弊社エンジニア、PLに連絡していました。

改善前コミュニケーションライン


人数比率はOSE>BSEなので、質問がどっとBSEに入ってきたときに、そこでさばききれなくて開発がスタックしてしまうことが頻繁に発生しました。

今回は、技術的な質問にフォーカスをあてて対応することにしました。
方針としてはBSEを経由せずとも解決できるようにするコミュニケーションラインの整備をする対策です。

対策1

そもそも、同じような質問が弊社エンジニアに来ることが多々ありました。
なので、同じような質問はしないようにOSE間、OSEとBSE間で解決できる体制にしました。

具体的には、週1回で知識共有会を実施すること、質問があればまずは他OSEに聞くなどです。

知識共有

対策2

それでも技術的質問は出てくるので、BSEを経由せずにOSEから弊社エンジニアへダイレクトで連絡を取れるslackチャンネルを作りました。
その際には英語でコミュニケーションを取るようにしています!

改善後コミュニケーションライン

結果

これら2つの対策でBSEを経由するコミュニケーションルートを減らすことに成功しました!

そして、課題としていたBSEでスタックしてしまう部分が解決され、開発スピードが向上ました!

4. 開発におけるセキュリティを担保した権限の付与

課題

弊社では開発が完了すると、そのあとに結合テストを実施します。

その際にはステージング環境にデプロイをして、テストを実施することになっているのですが、はじめはBSEにのみデプロイできる権限とDBの編集権限を付与していました。

そこで起きていたのが、コミュニケーションラインと同様、BSEへのタスクが集中してしまい、結合テストがスタックしてしまう事象が発生しました。

改善前のデプロイフロー

対策

表題の通り、ここではセキュリティを担保しつつ権限を付与する対応をしました。そうすることで、OSEも自らデプロイできるようになりました。

改善後デプロイフロー

結果

スムーズな結合テストを実施することができるようになり、BSEのスタック問題を解決することができました!

まとめ

ここまで読んでいただきありがとうございます。

エアクロでは「チームづくり」と、「win winの関係を構築する」ことをすごく大事にする文化があります。

そのためにはビジョンに共感し、個人の目標を結びつけることで共鳴しあうことで築けるのではないかと考えています。

エンジニアに限らず、すべてのメンバーにそういった気持ちがあるのがエアークローゼットです!

もし興味があったらご連絡お願いします!!
リクルーティングサイト

明日のairCloset Advent Calendar 2021は「アプルビルド自動化」に関する記事を書いていただきます!

それでは!