Webサイト発注虎の巻ダウンロード
Webサイト発注虎の巻ダウンロード

オフショア開発の失敗パターンと成功するための6つのポイント

くま

LIGのくまこと久松です。BiTT開発事業でマネージャーを担当しています。

新規のお客様とお話ししていると「オフショアってどうなんですか?」という話によくなります。ふと自分自身の経験を振り返ってみると、都合6プロジェクトほど、さまざまなオフショア会社さんからの製造物を受け入れてきたことに気づきました。依頼先の国も香港、フィリピン、ベトナムと多岐にわたっていました。

今回は、私が経験してきたオフショア開発の失敗談と、どのようにすれば成功したのかというお話をしたいと思います。

オフショア開発を選んだ理由

これまでオフショアに依頼していたシステムは、広告システム、基幹システム、営業管理システム、勤怠システムといったBtoBシステムから、リワードのようなBtoC向けサービスまで多岐に渡っていました。当時の所属組織では正社員エンジニアによる内製化も進めていましたが、以下の理由でオフショアへの発注を行っていました。

オフショア開発とは?

安くて流行っていた

2010年代、オフショアが非常に盛り上がった時代があります。大手企業がオフショア拠点を構築するだけでなく、旅行代理店や英会話留学など海外に接点のある異業種の方々が手探りでオフショア拠点を構築したりしていました。日本の少子化や人件費のグラフを前に「これからはオフショアです。始めるなら今でしょ!」と多くの営業がありました。

採用難

私が所属していたある企業は営業職中心の会社だったので、エンジニア職が少なく開発リソースが限定的でした。エンジニアが少ないということはエンジニア組織をスケールするノウハウもないということです。採用ノウハウもなければ教育ノウハウもない。これらのノウハウを貯めている途中であっても事業は進み続けます。限られたエンジニア正社員を、主力事業にも新規事業にも割り当てるというのは現実的ではありません。

当座の開発を実施するためにも、外部のリソースを頼る選択肢としてオフショア開発がありました。

フリーランスの高騰

2010年代前半は日本はソーシャルバブル真っ只中。LAMPエンジニアの採用も一筋縄ではいきませんでした。LAMPフリーランスの単価が1~2年程度の間に相場が20万円/月ほど跳ね上がり、何人も入場していただくという判断が難しい状況でした。

同じ開発を進めるなら圧倒的にコストメリットのあるオフショア開発のほうが稟議が通りやすかったご時世だったのです。

正社員採用ではなく投資として位置づけたい

新規事業に正社員エンジニアを配属すると、当の本人たちは0-1ができると喜ぶのですが、事業が転けた場合に2つの問題に当たります。1つ目は再配属をどうするかということ。再配属先が存在しない場合、あるいは技術セットが再配属先に合致しないような場合は悲劇的です。2つ目は新規事業に集中した正社員に事業継続断念を申し入れた場合、かなりの割合で退職してしまうという傾向です。

これらを鑑みると、当たるかどうかわからない新規事業に対し、最初から正社員エンジニアをアサインせずに外注するという選択肢には合理性があります。経理上も投資として扱えますしね。

オフショア開発の失敗経験を紹介

私自身これまでオフショア開発において複数のプロジェクトを発注しており、いろいろな失敗を経験してきました。その一例をお話しします。

品質がよくない

想定通り動かないプログラム、可読性の低いソースコード……。よくあるオフショア失敗談ですが私も遭遇しました。

品質がよくないと納品後や内製化したときにも引きずります。単に受け入れが大変というだけではありません。オフショアという「遠くの顔も知らない誰かが作った出来の良くないソースコード」を見たとき、ほとんどの内製化担当エンジニアは他責の姿勢になります。バグが出れば「オフショアが悪い」、作業が遅くなれば「オフショアが悪い」、複雑な仕様を投げれば「オフショアのせいでできない」と主張します。経験上、リプレイスなどで完全にソースコードが入れ替わるまで他責の傾向は続きます。反対に顔が見える古株社員が書いたソースコードだとそこまでボロクソには言いません。

品質の中でソースコード以上に苦悩していたものがあります。それは日本語管理画面です。画面イメージを提供しても意味が通じないので、細かく指示をする必要があります。こんなとき、個人的には「日本語というのはマイノリティ言語なのだな」としんみりとした気持ちになっていました。

ブリッジSEの当たり外れが大きい

オフショア拠点と顧客の橋渡しであるブリッジSEですが、日本人が担当するケースと、オフショア拠点先の国籍の人が担当するケースとがあります。このブリッジSEについても2パターンの失敗がありました。

1つ目はブリッジSEの日本語能力の失敗。細かなニュアンスが伝わっていなくて違うものができたりしていました。

2つ目はオフショア拠点の技術力不足をブリッジSEが被っているケース。こちらはかなり根深く、顧客としては「安くて品質が高い」と思って満足していても、台所事情は問題大アリなことも。1人の優秀なエンジニアが依頼された人月分のフリをしながらアウトプットを出していたりするとかなり悲惨な構図となります。とあるオフショア企業様ではHTML/CSSのみ書ける人材が集まっていて、他はすべて1人の担当ブリッジSEが書いていたというところもありました。この方のアサイン割合が先方都合で変わり、品質がみるみる落ちていったので渋々別の拠点を探したことがありました。

「よしなに」が通じず、違うものができる

「ここはよしなに」「いい感じにしておいて」「いつもみたいな感じで」

そこまで優先順位が高くない機能の場合、このように伝えてしまうことはあるのではないでしょうか。ただこれはあくまでも温度感が共有できている場合のみです。細かいところまで詰めておかないと、「どうしてこうなった」というものができあがります。

メンバーが流動的で知見が残らない

ある時点まで問題のなかったアウトプットについて、急に可読性が落ちたり、納品が遅くなったりするケースがありました。よくよくヒアリングをすると、実装を担当するメンバーがオフショア会社都合や急な退職でしれっと変わっていたというものでした。

ある程度ボリュームのある実装物の場合、どうしても慣れが必要です。また、ソースコードにしてもそのプロジェクトのお作法が多かれ少なかれ存在します。

人件費の高騰、為替の変動

発展国の場合、急に経済が発展して人件費が上昇するケースがあります。また、急な円安など為替の影響も馬鹿にはできません。「品質への満足度がそれなりで日本で自社で手直しすることを加味しても安い」くらいの温度感で発注していたプロジェクトがあったのですが、数年前にこの両方が起きたことがあります。「それなら採用コストを割いてでも自社でやろう」という判断をし、オフショアから撤退しました。

オフショア開発を成功させるための6つのポイント

次に、成功したプロジェクトの例からわかる、オフショア開発で失敗しないポイントを見ていきます。

企業選定時に実績を確認する

オフショア開発を依頼する企業の選定方法も成功に繋がるポイントです。私の場合、選定時には見せても問題のないソースコードを提出してもらい、選定の参考にしていました。また、現在進行系の実績について具体的にどの工程から、どの部分を、どのくらいの期間で担当したのか教えてもらうようにしましょう。自ずと任せられそうなスキル感が見えてきます。

下請け扱いせず、自社の開発チームの一員に加わってもらう

オフショアに失敗するプロジェクトの場合、開発難易度の低い末端の作業をちょろっと投げるという下請け扱いをしている傾向にあります。軽作業の下請けではなく、開発チームの輪の中に入ってもらいましょう。ここを線引してくるオフショア企業は体制に難があるのかもしれません。アジャイル開発を採用している場合は尚更です。

パートナーシップを結ぶ、同じ開発チームだと思って開発の輪に巻き込むのが重要です。コーディング規約を提供する、ブリッジSEとともにコードレビューをして品質に共通認識を持つ。投げっぱなしにしないことが第一歩だと考えています。

ドキュメント化と共有を徹底する

プロジェクト管理ツール、ドキュメント管理ツールの類はオフショア先に共有しましょう。社内にある知見は出しましょう。そのうえで、ツールを共有し随時確認できるような環境にしましょう。失敗するプロジェクトは(オフショアに限ったものではありませんが)納品前の確認スパンが短く、後戻りできないほど時間が経ったときにレビューしたら違うものができていた、という「あるある」があります。

詳細設計まで日本で実施する

「よしなに」の言語化は必須です。「よしなに」が通じる期間、概ねプロジェクト開始から1年くらい経過し円滑にコミュニケーションが取れるまでは、日本で詳細設計まで詰めてからブリッジSEに依頼するというやり方が事故が少ないです。

これは何も言語や文化に関係するものばかりとも限りません。たとえば開発者と利用者でディスプレイサイズが違う場合、同じ管理画面を見ている場合であっても片方には十分に見えても、もう片方には小さすぎたり大きすぎたり使いにくく感じるケースがあります。対象ブラウザ、ディスプレイ解像度の指定、スマートフォンのバージョン、iPadの画面の大きさなど、非機能要件も序盤に調整しましょう。

担当メンバーを固定してもらう

体制や人員はできる限り固定、やむを得ない場合は事前告知の上でしっかりと引き継ぎをしてくれる、こうした企業をパートナーとして選びたいものです。直接話すことはなくてもビデオ会議などで挨拶をするだけでも「この人が担当してくれるのか」と安心感に繋がります。

プロジェクトに関する知識の蓄積は財産です。半年以上継続していくと開発者も慣れてきてスピードアップに繋がり、コストメリットを感じられます。

コスト計算を継続して実施する

昨今流行している「DX」の中には「内製化」というキーワードがあります。しかし少子化や、転職し放題のエンジニア経験者市場を鑑みるとなんでもかんでも内製化するというのは無理があります。何を内製し、何を外に出すかを踏まえ、内製をする場合と外注をする場合のコストを絶えずモニタリングする必要があります。

まとめ

私自身のオフショア開発の失敗談と、そこから学んだ成功のポイントをご紹介いたしました。

とくに大切なのは以下の3つです。

  • 現在進行系の実績を教えてもらう
  • 自社の開発チームの一員に加わってもらう
  • 体制を確認する

皆様のオフショア開発が成功に繋がる参考になれば幸いです。

 

新しいオフショアのかたち「BiTT開発」

LIGでは、新しいオフショアサービス「BiTT開発」を提供しています。

▼BiTT開発の特徴

  • クライアントとLIGがチームとなり開発を進める手法
  • プロジェクトの上流工程は日本のLIGスタッフが担当
  • 戦略が不明確な状況からでもプロジェクトをスタートできる
  • 高品質・低単価を両立

詳細は下記の記事をご覧ください。

サービス紹介資料ダウンロード

「BiTT開発」導入事例

オフショア開発に関する記事

M o n g o