19
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

はじめまして!
普段はAWSの設計構築や、Pythonでバックエンド開発をしている5年目エンジニアです。
今回は、今年1年で最も刺激的だった「オフショア企業1と共同開発した経験」から得た学びについて共有します :flag_in: :curry: :fire:
本記事はオフショア開発の経験に基づいていますが、国内案件にも役立つヒントがあると思います。
ぜひ最後までご覧ください!

プロジェクトの概要

本プロジェクトの目標は、旅行会社の既存会員基盤を廃止するため、1から新しい会員基盤を構築することでした。
以下に、プロジェクトの特徴をまとめます。

  • 開発期間: 要件定義から設計、実装まで約1年間
  • チーム構成: 日本人2名+インド人7名(※ブリッジエンジニア2は不在・・・)
  • 開発手法: アジャイル開発
  • コミュニケーション: 週1回のオンラインミーティング
  • 技術スタック: 詳細は割愛

ぶつかった壁

言語・文化の違い

英語が苦手な私には議論するだけでハードルが高いのですが、その上コミュニケーションスタイルの違いや、働き方の文化的な違いに戸惑いました。
YES/NOだけをとっても、ニュアンスの違いで認識の齟齬が発生することもありました。

正確なビジネスロジックの共有

日本人である私でも、なぜこうするのか?と思うような要件があったり、日本特有または旅行会社特有のビジネスモデルがあったりと、用語や概念を共有するのに苦労しました。

双方向コミュニケーションの不足

特にオンライン会議では一方的な情報共有になりがちで、現地チームの意見や疑問を引き出すのが難しかったです。

課題解決のために実施したこと

これらの課題を解消するため、インドに1週間滞在してワークショップを開催しました。
以下に、その具体的な内容を紹介します。

アイスブレイク

ワークショップの冒頭では、参加者の自己紹介に加えてクイズを出してもらうなど、リラックスできる雰囲気を作りました。
また、ランチやティータイム(日本にも欲しい!)では現地の料理を一緒に楽しみ、退勤後にはショッピングやディナー、スポーツを通じて交流を深めました。

ビジネスロジックと目標の共有

事前に準備したドキュメントを使い、ビジネスの背景や目標を重点的に説明しました。
使用した手法やドキュメントは以下の通りです。

インセプションデッキ

インセプションデッキとはThoughtWorks社のRobin Gibson氏が考案したものでアジャイル開発の現場でも多く取り入れられる「これからスタートするプロジェクトの全体像(目的・方向性・優先順位・開発環境など・コストや人材・背景)をプロジェクトメンバーが相違なく認識する為に作成するドキュメントです。

代替テキスト
上記の10個ある質問の中から下記の4つを作成しました。

  • 我々はなぜここにいるのか
  • エレベーターピッチ
  • やらないことリスト
  • トレードオフスライダー

カスタマージャーニーマップ

カスタマージャーニーは、顧客の日常生活から、購入の検討段階、実際の購買(利用)段階までに接触しうるさまざまなタッチポイントについて、包括的に捉えるものです。

上記の他にも、AWSのアーキテクチャ図、ER図、日本特有の用語や概念をまとめたドキュメントなどを作成していきました。

成果物の作成

:star: ここから先の内容は2チームに分かれて実施しました :star:
(私ともう一人の日本人メンバーも1人ずつチームに入ります。)

  • ユーザーストーリーマッピング
  • ユースケース図
  • 画面設計書
  • API仕様書
  • モックアップ

チーム間レビュー

作成した成果物をチーム間で共有し合い、相互レビューを実施しました。
担当外の部分に対する質問や意見交換を通じて、プロジェクト全体の理解を深めました。

効果的だったポイント

ワークショップを通じて得た成果を、私なりの解釈で説明していきます。

合意形成を効率化

リアルタイムの議論を通じて、その場で解釈の違いを修正しました。
また、ホワイトボードを活用してアイディアを視覚化しながら議論を進めることで、イメージを具体的に共有することができました。
結果、迅速な合意形成が可能となり、後工程への移行をスムーズに行うことができました。

双方向コミュニケーションの強化

シャイなメンバーからも意見が引き出され、活発な議論が行われました。

独創的なアイデアの引き出し

ブレインストーミングやディスカッションによって、現地チームならではの新しい視点やアイデアが生まれました。

信頼関係の構築

オフショアパートナーはトップダウン型の指示に従うことが多い一方、今回のワークショップでは、私たちもメンバーの一員として各チームに参加することで、同じ目線でディスカッションができました。
結果、現地チームのモチベーションアップにも繋がったと思います。

まとめ

様々な困難があるオフショア開発にワークショップを取り入れるのは効果的!

おわりに

今回の経験は、先輩社員のリードやチーム全体の協力があってこそのものでした。
帰国後、私自身もこの経験を活かして、社内でワークショップを開催してみました。

この記事を読んでくださった皆さんも、ぜひオフショアや国内チームで試してみてください!:sparkles:

  1. オフショアとは、コスト削減や効率化を目的に、海外の企業や拠点に業務を委託したり、開発を行ったりすること

  2. ブリッジエンジニアとは、海外企業と日本企業の橋渡しをする人、日本企業に代わって海外企業に指示を出し、管理するエンジニアのこと

19
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
19
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?