永橋 洋明 の記事一覧

この記事は GMOインターネットグループ Advent Calendar 2024 18日目の記事です。 1. はじめに GMO ReTechの永橋です。サービスをローンチしてから4年が経ちましたが、4年間のほとんどがオフショア開発とともにありました。記事のタイトルには「支える技術」とありますが、ここでは技術（テクノロジー）面ではなく、オフショア開発におけるチームマネジメントの工夫（スキル）に焦点を当てたいと思います。 2. 開発チームの現状 2.1 チーム体制 現在のチーム体制は以下の通りです。 日本：3名 ・プロダクトマネージャー：1名・プロダクトアーキテクト：1名・デザイナー：1名 オフショア：23名 ・プロジェクトマネージャー：1名・BrSE（ブリッジSE）：3名・フロントエンドエンジニア：7名・バックエンドエンジニア：3名・アプリエンジニア：3名・品質管理：6名 GMO ReTechに所属し、賃貸DXの開発に携わるメンバーは私を含め3名で、開発の多くはGMOインターネットグループのオフショア開発チームの協力のもと行っています。現在はベトナムから23名がプロジェクトに参画しています。つまり、チーム全体では26名で賃貸DXの開発を行っています。 2.2 プロダクトアーキテクトの役割 私の立ち位置はプロダクトアーキテクトで、普段は賃貸DXの設計、開発、運用を担当しているエンジニアです。オフショア開発に関しては、技術的な仕様や課題に関するサポートを行っています。また、プロダクトマネージャーはオフショア開発を管理しており、日本とベトナムのコミュニケーションを円滑にする役割を担っています。 2.3 ブリッジSEの存在 オフショアチームにはブリッジSEというポジションのメンバーがおり、このメンバーが日本語で伝えた要件や仕様をベトナム語に翻訳し、開発工程に落とし込みます。このブリッジSEのメンバーはとても日本語が堪能でスラングもバリバリ使いこなします。非常にありがたい存在で、私たち日本のメンバーは言語の壁を感じることなくコミュニケーションが取れています。 3. オフショア開発で直面した課題と解決のための取り組み ここでは、オフショア開発で直面した課題を大きく3つご紹介します。 3.1 スケジュール管理の難しさ 3.1.1 祝日のズレと稼働日の可視化 まずは祝日による休みのズレです。例えば正月で言うと、ベトナムは旧正月なので、年末年始はベトナムが稼働している代わりに日本がお休み、旧暦1月1日の旧正月はベトナムがお休みで日本が稼働している…というように、休みのズレが生じます。そのため、リリースを終えてから次のリリースまで実質10日程しかない、ということもあります。 スプレッドシートで管理されているWBSに日本とベトナムの休日・祝日も記載し、休みをスケジュールに可視化しました。こちらが実際のスケジュール管理シートです 実際に2024年の1月リリースから2月のリリースまでの間は、フル稼働しているのは10日しかありませんでした…。濃い赤は祝日、薄い赤は祝日に合わせて休暇を取るメンバーが多く、稼働率が低い日であることを表しています。 とても初歩的ですが、WBSを見た瞬間に営業日がどれほどあるかわかるのは、期日を確認するうえでとても重要です。 3.2 UI・UXに対する認識の違い 3.2.1 感性・文化の壁と伝わらない例示 次に、感性や文化の壁です。オフショアチームのブリッジSEメンバーは非常に日本語が堪能なのですが、細かい部分でニュアンスが伝わらないことは避けられません。また、良かれと思って出した例が伝わらないことも多々あります。例えば日本で使われているメッセージングやSNSアプリに実装されている機能を参考に伝えても、ベトナムで使われているとは限りません。ゲームや娯楽も共通のものがなかなか無いため、うまく伝えるためには言葉だけでも画像だけでもなく、動画での動作イメージ共有が非常に大切です。（例えば、ボタンを押したときのアニメーションを◯◯のアプリのようにしたい、とした場合、スクリーンショットだけだと不十分ですよね） ここで重要になるのが「ノンバーバルコミュニケーション」の活用です。言語情報だけでなく、画面共有や動画、アニメーションを用いて非言語的な情報を伝えることで、細かいニュアンスまで共有しやすくなります。 3.2.2 具体的な要件伝達の重要性 コーディングやデザインについても同じことが言えます。具体的にどこまで伝えるかは難易度や規模によって変わりますが、・テーブル構成・ビジネスロジック・利用するメソッドやライブラリの選定・画面イメージはできる限り具体的に伝えたほうが、結果的に相違を抑えて進められます。 3.2.3 コミュニケーション頻度・密度の向上 これらの認識の違いの差は、コミュニケーションの頻度と密度を高めることで埋めることにしました。まず、毎日ブリッジSEのメンバーとZoomでの朝会を実施し、疑問や課題の共有の場を作ることで迅速に問題を察知できるようにしました。 Zoomで定例を実施するにあたって注意すべきは会議時間です。最近までは1時間実施していましたが、時間オーバーしてしまうことが多いので30分に減らし、会議時間を意識するようにしました。結果として、議題が選別されたり会話の応答速度が上がり、8割以上時間内に終わるようになりました。また、Zoomによる朝会を実施することにより、テキストによるコミュニケーションでは伝わりにくい事柄は画面共有を交えて伝わるようになり、細かいニュアンスが伝わりやすくなりました。不具合が生じた際は、朝会とは別にすぐにZoomで会話をします。ときにはオフショアのエンジニアもZoomに参加することで、リアルタイムに通訳してもらいながら解決を図ります。 デザイナーはFigmaを利用することで画面イメージを明確に伝えています。 スケジュールの都合上デザイン無しで開発を依頼することもありますが、やはりアウトプットに明確な違いが出ます。細かく伝えることはオフショアに限らず手戻りを増やさないために重要です。さらに言えば伝えるための手法も工夫しないと結局意図していたものと違う成果物があがってくる、ということです。 3.3 コード品質の担保 3.3.1 言語の壁とレビューラグ 成果物を確認する際はもちろんコードレビューを行いますが、言語による壁が発生します。日本語でレビューコメントを書き込んだ場合、それをブリッジSEのメンバーが翻訳したうえでオフショアのエンジニアに伝えるわけなので、当然伝達までにラグが発生します。また、ブリッジSEを介することで、エンジニア間では伝わる会話が正しく伝わらないことも多々あります。 3.3.2 AIコードレビューの活用 解決方法として、CodeRabbitというAIコードレビューツールを使用しています。 https://www.coderabbit.ai 製品仕様に関わるロジックの齟齬などはなかなか検出できませんが、細かいtypoやコードの改善提案などは十分に機能します。ベトナム語を指定することでコメントを直接ベトナム語にしたり、中間言語として英語を利用することも可能です。 4. その他ツールを利用した取り組み 4.1 CircleCIによる自動化 前述のZoom、スプレッドシート、CodeRabbitといったツールのほか、CircleCIを利用しています。 CircleCIでは通常のテストに加え、アプリのビルドを自動化しています。TestFlightやFirebase App Distributionへ自動で展開するため、開発内のテストやリリース前テストにおいてスムーズなテストを実現しています。 4.2 タスク管理ツールの試行錯誤 また、過去にはタスク管理としてTrelloを利用してKPT管理を行っていましたが、これについては失敗でした。Zoomでカンバンの整理をしながら話していると会議の時間が2時間と長時間になってしまったのが原因です。自前でスプレッドシートにまとめて簡易的に課題管理することで落ち着きました。 5. コード品質と設計思想 5.1 製品仕様に関わる指摘の難しさ コード品質の担保にAIコードレビューを使用していることは書きましたが、これでは製品仕様に関わる指摘はできません。そのため、別の方法で担保する必要があります。 5.2 設計段階での詳細化の重要性 オフショア開発に限らず、外部に開発を依頼する場合はどの程度自社で設計を行うかによって、最終的なアウトプットの品質が大きく変わってきます。つまり、機能の設計を細かくやればやるほど、成果物が想定したものから乖離することを抑えられるということです。 前述しましたが、オフショア開発の場合感性や文化の違いもあります。「こんな機能を作りたいんだ、よろしく」と丸投げすると、私たちの想像した機能とは似ても似つかないものが出来上がるのです。絶対にイメージしたものは出来上がらない、と断言できます。 5.3 将来連携や拡張性を考慮した設計 例えば機能Aに対して、将来的に機能Bと連携できるようにしたいと考えていたとしても、将来の連携を見越してを機能設計に正しく落とし込めなければ負債となり、機能Bとの連携を実装する際には大改修が必要になります。まさに、オフショアチームに設計の多くを丸投げしていた状況が2年ほど前の賃貸DXであり、現在は機能アップデートのたびに既存機能の設計変更を余儀なくされています。 現在では新規機能などテーブル変更や大きな仕様変更を伴う改修には、プロダクトアーキテクトを交えて日本側の設計思想を細かく伝えるようにしました。特に意識しなければならないのはパフォーマンスに対する考慮と機能に対する将来予測です。100レコード程度なら軽快に動く機能も、設計が悪ければ100万件、1億件のデータが入ったら目も当てられません。 また、将来的に機能をどのように発展させていきたいか、という展望はオフショア開発チームは持っておらず、あくまでも依頼されたものを作っています。将来的なことも踏まえた設計というのは自社で設計するからこそできることなので、その点も盛り込んで設計する必要があります。 簡単にまとめると、外出しするべきは「開発」であって、サービスの形を担う「設計」は自社で全て行うべき、ということです。当社のように自社のエンジニアが少ないとどうしてもオフショアチームに頼ってしまいがちですが、良いものを作るためには自社での設計を死守しなければなりません。開発を外部に委託する場合であっても、フレームワークの選定や既存機能の仕様、テーブル設計など、サービス全体を把握している人間が成果物を監督できれば品質が格段に向上します。 6. チームと個人のマインドセット 6.1 チームとしての優先順位 設計の重要性について書きましたが、チームとしては「期限＞品質」が重視されています。品質は後から改善できますが、期限は戻ってきません。まずは完成させ、機能を確実にお客様に提供することを第一に開発をしています。もちろん品質は重要ですが、いつまでに提供すると言った期限は必ず守るように動いています。 6.2 個人レベルでのスケジュール管理工夫 また、個人としては、 ・オフショアチームに伝える期限を実際の期限よりも短く設定し、・重要なタスクを優先的に渡し、・作業量が多くなりそうな場合は、タスクを細分化して調整する を徹底することで、スケジュール管理にある程度の柔軟性を持たせることができます。 7. 課題と今後の展望 7.1 感性・文化の違いとコミュニケーション課題の現状 オフショア開発においては、大きく感性や文化の違いによる課題と依頼・被依頼の立場による設計の課題があります感性や文化の違いはコミュニケーション頻度やツールの工夫によりそれほど意識することなく進めることができるようになっています。 7.2 設計上の課題と依存度低減への展望 設計に関してはサービスに精通しているプロダクトアーキテクトを交えることで、以前よりも細かく開発のハンドリングを行うことができるようになっています。 日本チームは現在少人数で開発にあたっており、スケジュール管理や設計は様々な工夫をすることで成り立っています。しかし、まだまだ改善しなければならないことは山ほどあり、理想を言えば細かい改修についてもすべて日本チームで設計を行った上で開発を依頼するのが望ましいです。しかし、程度はどうあれ、まだまだオフショアチームへの依存度が高いというのが実情です。今後更に品質の高いサービスにしていくことを目指し、この依存度を下げていくよう更に工夫をしていきたいと思います。