top of page
Search

モダンオフショアでスクラム開発⑤ オフショアで成功するための条件

私は、ベトナム🇻🇳のオフショア会社でおおよそ4年働いていますが、様々な日本のお客様と仕事をさせていただきました。成果を出せた案件、残念ながら成果を出せなかった案件・・・。　都度振り返りを行っていますが、分析すると成功パターンは見えてきます。

今回は、オフショアに興味を思っている方・検討されている方に向けて、オフショアで成功するための条件について、ご紹介させていただきます。

ここでの話はベトナムに限らず、どの国でも、また、スクラム開発、ウォーターフォウール開発どちらにも通用すると思っています。


1.最初の入口

まず、スタート時における発注する側のオフショアに対する意識で成功するか・失敗するかが決まります。

成功パターン

  • コストカットを目的としないこと

    • コストカットに比例して品質低下を招くことになり、リリースした後に結局保守でコスト増を招く結果が多くあります。

    • 日本人エンジニアの確保が難しい状況において、選択肢の一つとしてオフショアを検討することが効果的です。

  • 短期で成果を求めないこと

    • お客様がオフショアに慣れていない状況やオフショア開発メンバーがチームとして成熟していない状況においては、短期で成果を出すには至難の技です。。

    • 長期的な視点であれば、間違いなく開発チームは成果を出してくれます。そのためには半年以上のプロジェクトが望ましいでしょう。

  • 日本人エンジニアと同様に、平等な目線であること

    • 国籍・年齢・職種に限らず、平等で尊敬の念を持って接しているお客様は、すぐに開発メンバーと信頼関係を構築することができるでしょう。

  • 保守的ではないこと

    • オフショアを利用すると、お客様にとって、これまでに経験していなった課題が出てくるでしょう。そうした課題に対して、だからオフショアを辞めておけばよかったと思うのではなく、お客様自身が積極的に開発メンバーと一緒になって問題解決に取り組んでくれる姿勢や行動がとても重要になります。


2.開発メンバー

下記2名の存在で成功するか・失敗するかが決まります。


成功パターン

  • 優秀なブリッジSE(BrSE)の存在

    • 成功しているプロジェクトには、そこには必ず優秀なBrSEが存在します。どんなに優秀な開発メンバーを揃えても、BrSEによって大きく成果が左右されます。

    • 優秀なBrSEの資質ですが、たくさんあります。

      • 仕様を理解するだけではなく、Whyをきちんと理解できるまでお客様ととことん話し合えていること。BrSEが納得して初めて開発チームに伝える。

      • 開発チーム全体の状況を常に把握していて、開発チームが何か課題があったときに、必要に応じてすぐにお客様に確認してくれる。

      • 通訳の能力が高い。

        • N1の資格や翻訳能力はそれほど重要視しなくてよい。今どき、翻訳しなくても開発者でも翻訳機を使えば、仕様はある程度理解できます。不明な点はBrSEから支援を受ければいいケースもあります。

      • 笑顔であり人間味のある。とても重要☺️

    • スクラム開発においては、BrSEというポジションがありませんが、このポジションは代理POもしくは、開発チームのメンバーの一員と捉えています。

  • 優秀なテックリードの存在

    • 開発チーム全員がフルスタックで自律性の高い経験豊富なエンジニア集団が集まることが理想ですが、現実的には難しいです。

    • 優秀なテックリードは、開発の部品毎ではなく、システム全体を見渡して、仕様に対する最適解を導き出すことができる人材です。

    • また、開発メンバーから信頼され、技術的な相談やコードレビューをよく受けます。開発チームはテックリードの存在によって、高いモチベーションで開発することができ、その結果成長スピードがあがります。また目標となる存在で、将来のテックリードへとつながっていきます。

    • もし、オフショアの開発メンバーに優秀なテックリードがいない場合には、日本から支援できる形でも成立します。

開発チームが日本人とオフショア開発のメンバーで構成されている場合、コミュニケーションのコスト増が課題になります。日本人がテックリードという形の支援であればよいですが、一緒に開発する場合には事前対策が必要になります。

3.開発手法

最近はパッケージ販売のような大きな開発の需要は減り、リリースしながらアップデートしていくスタイルが流行りであり、そのためアジャイル開発がとても効果的です。

成功パターン

  • オフショア開発は、アジャイル開発との相性がよい

    • オフショア開発は、開発後、仕様変更によって後戻りするような状況はとても苦手です。特に納期が決まっている場合、これを繰り返すと品質がミルミルうちに低下していきます。なぜかと言うと、コミュニケーションコストが高くなり、待ち時間が多く発生し、開発にかける時間がなくなっていきます。ウォーターフォール開発の案件でも、実際には、仕様が後から変更されるケースは多く見受けられます。

    • アジャイル開発のようにMVPを絞り込み、決まった仕様から開発していく手法のほうが、無駄な時間は圧倒的に減ります。ウォーターフォール開発とアジャイル開発を組み合わせた手法だったり、なんちゃってアジャイル開発だと、成功することは難しいです。。

    • ウォーターフォール開発の場合、ベトナムでは開発者とテスターという分業が一般的です。アジャイル開発の場合、開発チームが基本的にテストを行ってもらいます。そのほうが圧倒的に速い段階でバグを発見することができ、人員・開発コストが減ります。

4.仕様

開発チームにとっては、仕様に書かれているものが全てです。ここを手を抜くと、これまでの準備が全て水の泡です。

成功パターン

  • 明確な仕様

  • 開発チームと一緒に仕様を完成させる

    • 最初から漏れのない価値を提供できる仕様を書くことが理想ですが、実際には難しいです。

    • 発注側が仕様を書く場合、開発スタート前に開発チームと議論し、全員が納得する状態になると、開発はスムーズに進みます。アジャイル開発の場合、バックログリファインメントで対策できます。


さいごに

他にも成功パターンは多く存在しますが、個人的には、この4つの項目を抑えておけば、間違いなくお客様は期待する、またはそれ以上の結果を得られると確信しています。

また、オフショアを使うということは、日本人エンジニアと一緒に仕事をすることでは得られない体験をプラスαとして得ることができます。日本以外の文化や考え方を知ることができ、よりグローバルな視点を持つことができます。聞くだけはやはり感じることはできず、実際に経験することが必要になります。ときどきオフショアをされている国に足を運び、メンバーと交流することも素晴らしい経験となります。また休みの日には観光もできますね😄。　

私はスクラム開発のPOとして活動していますが、もはやオフショアを使っているという感覚は一切なく、成果を出し続ける優秀なスクラムチームとして、毎日彼らと一緒に楽しく仕事をさせてもらっています!


40 views0 comments
bottom of page