みなさん、こんにちは。パーソルプロセス＆テクノロジー（以下パーソルP&T）の属です。

私が所属するエンタープライズソリューション統括部 Global Bridge部では、プライムSIerとして顧客システムの提案や開発を行う際、社内海外拠点（主にベトナム）のエンジニアと協働して進めています。

文化の異なる海外のエンジニアとの開発は日々学びの連続なのですが、今回は特に、昨年より私が現場で実施している【オフショア×スクラム開発導入】についてお話しできればと思います。

導入に際しては、言語の違い・雇用契約の違い等、オフショアならではの難しさも感じていたので、近い環境にいらっしゃるエンジニアの皆さんにとって少しでも参考になれば幸いです。

▼自己紹介

◆アジャイル開発とは？

アジャイルとは、直訳すると「素早い」という意味です。アジャイル開発は、従来のウォーターフォール開発に比べて、要件変更に柔軟に対応できるという特徴があります。

一番の特徴は、短い期間で「計画→設計→実装→テスト→運用の流れ」をイテレーション（反復）する点にあります。そのため、開発単位を小さく分割することができ、都度システムの目的やユーザーの要望を見直しながらシステム開発を進めることができます。私のチームでは1スプリント（イテレーションの期間）を2週間としています。

＜スクラム開発スタイル＞

アジャイル開発の中にもいくつかの手法がありますが、今回私が現場で使用した開発手法は「スクラム」です。

◆スクラムとは？

スクラムとはチーム全員で開発を進める手法であり、チーム間のコミュニケーションを重要視する開発手法です。スクラムでは固定的なメンバーで開発が進められ、プロダクトオーナー、スクラムマスター、開発者に役割がわかれます。今回私が担当したのは、スクラムマスターです。

＜スクラム開発の役割分担について＞
・プロダクトオーナー：プロダクトの方向性などを意思決定し、スプリントごとの評価を行う。
・スクラムマスター：全体の調整役としてプロダクトオーナーや開発チームが抱える課題の解決に取り組む。
・開発チーム：実際に開発を行う。プロダクトオーナーの移行に沿って開発を進め、スプリントへの責任を持つ。

◆オフショア×スクラムの開始

もともとGlobal Bridge部で私が担当していたプロジェクトはウォーターフォール開発を実施していましたが、開発体制が変わったタイミングでアジャイル・スクラム開発へと変更となりました。これには下記のような理由がありました。

【アジャイル開発に変更した理由】

１）プロダクト開発プロジェクトであるため、頻度の高い変化への対応が求められる。
プロダクトが発展していくためには、競合や会社の状況の変化に合わせてリリースすべきものを変え、変化に対応する必要があり、それができないとプロダクトとしての価値を出せなくなってしまいます。

２）効率性が求められる。
全員が開発全般に携わっていた環境で、ウォーターフォール開発時には必要なドキュメントコミュニケーション（設計書等）はあまり必要とされておらず、その分のリソースをプロダクト開発につぎ込む方がメリットが大きいと判断しました。

３）顧客への価値提供の頻度を上げたい。
「 １）」に関連し、開発したものをできたものを早く顧客に届けたい、デリバリーせず在庫として抱えているのはもったいない、という事情もありました。

【スクラム手法を取り入れた理由】

・アレンジしやすい
スクラムはプロセスではなくフレームワークであり、チームに合わせてプロセスをアレンジしやすいため、取り入れようと考えました。

しかし、スクラム手法を取り入れる際にはいくつかの困難に直面しました。

まず、私含め開発メンバーはウォーターフォールで実施してきたメンバーであったため、当初はスムーズにスクラム開発を進めることができなかった、ということ。

これだけであれば、皆が学び、経験を積むことで解決できるのですが、さらにもう一点、私のチームの開発メンバーがグローバルな構成であったということです。

具体的には、日本側は私含め２名がスクラムマスター兼ブリッジSE、ベトナム側のメンバーはフロント２名、バックエンド２名（１名リーダー兼任）、テスター１名の合計５名という構成だったのですが、それにより下記のような固有の課題（壁）が発生しました。

◆壁①：言葉

一番の壁は、言語の壁です。ウォーターフォールの際の言語は英語を用いて開発を進めていました。しかし、ベトナム側のメンバーも日本側も、英語を流暢に扱えるかというとメンバーごとにレベルの差異がありました。

ウォーターフォールの場合は、ドキュメントに対して翻訳ツール等を使用することで仕様確認を行うことができます。しかし、スクラム開発はコミュニケーションに重きを置きスピード感が求められる開発方法です。そのため、これまでのやり方を変更する必要がありました。

大きく変更したのは、現地語の採用です。例えば、スプリントの振り返り時には、開発メンバーで自由に振り返ってもらいたかったため、何を議論したいかだけを伝え、結論が出るまでは、ベトナム側で議論して頂くように進めました。結論だけ英語でまとめてもらい、スクラムマスターである私に共有してもらうイメージです。

当初は、全てを英語で実施しようと思っていたのですが、これでは英語が得意ではないメンバーの発言数が少なくなってしまい、これではスクラム開発とは呼べないと思ったことが現地語を採用した大きな理由です。この結果、メンバー全員の発言数が増え、意義のある振り返りを行うことができました。

＜実際の振り返りのKPTボード＞

◆壁②：雇用契約

パートナーを組んでいるベトナム側の企業は「ジョブ型採用」をしていました。メンバーそれぞれに担当業務が決められており、「フロントエンド」「バックエンド」「テスター」といった役割それぞれで採用されていた、ということです。（反対に、役割を限定せずに採用することを「メンバーシップ型」採用と言います）。

スクラムにおいては、開発メンバーは設計から開発・テスト・運用までの一通りのスキルを持っていることが求められます。しかし、ジョブ型採用で「フロントエンド」として入社した社員の場合は、基本的にバックエンドを実装することはせず、当然その経験もほぼありません。（実際には、メンバーの向上心により、自主的にチャレンジしてくれるメンバーはいますが。）そのため、本来のスクラムの手法を前提にプロジェクトを進めることは困難でした。

そこで私は、フロントエンド側とバックエンド側でコミュニケーションが円滑になるように「ペアプロ（2人のエンジニアが一つのプログラムを共同で開発する方法）」を取り入れました。また合わせて、ベトナム側のリーダーポジションにはフロントエンド、バックエンド双方の品質レベルが保てているかを確認してもらうようにしました。

これら手法が一番効果的に作用したのはメンバー間のコミュニケーションです。このときメンバー全員がリモートワークだったのにも関わらず、ペアプロや現地語を採用したことによりチーム内でのコミュニケーションが活性化し、メンバーそれぞれが家族と思えるほど仲良くなりました。その結果、メンバー間でそれぞれを補う動きが活発化し、結果としてスクラムを組むことができました。

◆まとめ

正直、今回我々が取り入れた開発のやり方が、スクラム開発と呼べるものかはわかりませんが、スクラム開発とはあくまでフレームワークであり、あとは利用する側がカスタマイズしてよいものだと私は考えており、そこに所属するメンバーによって適切な形態に変化させ、柔軟に開発を行っていくことが大切だと思っています。

その点では、現状我々は順調にスプリントを回せており、高いパフォーマンスを出せております。ベトナムのエンジニアメンバーからも「当初はアジャイル開発に戸惑ったが、今ではメンバーごとの成長が確認しやすく、よい手法だ」とフィードバックを頂きました。

今後の課題は、”慣れ”です。これはアジャイル開発に言えることですが、短いスプリントを数多く回すということは、悪く言えば、同じようなことを繰り返すということです。言語の壁や雇用形態の壁を乗り越えた我々は、次なる挑戦を掲げ、それに向かい向上する必要があります。次なる挑戦は「ベトナム側のリーダーをスクラムマスターに育てる」ということです。それを達成すべく、今後もチームを成長させていこうと思います。

～　～　～

以上、Global Bridge部 属さんより、部内の取り組みに関するご紹介でした！みなさんがグローバルなチームで開発をされる際、是非参考にしていただければ幸いです。是非次回の記事もお楽しみに★

～　～　～

弊社のTechコミュニティにご登録頂いた方には、今後もこのようなエンジニアブログの情報や、イベント開催情報をいち早くお届けいたします。SNSをフォローする感覚でお気軽にご参加ください。