オフショア開発の活用をあきらめた背景は？
オフショア開発は、うまく進まずに失敗する例も多いです。
ここで、オフショア開発の失敗原因を解説します。
オフショア開発の利点は、コスト競争力と人材確保です。
IT業界において、オフショア開発ベンダーの役割は、不具合修正、ネットワークサービス、ソフトウェア開発、QAテストなど、個別作業からIT機能全体に至るまで様々なレベルがあります。
オフショア開発は、ラボ型開発と請負型開発と分けられています。
請負型、ラボ型問わず、優れた成果を出し、成功しているケースもあれば、
コストが膨大にかさみ、納品期限の遅延、粗悪な品質で失敗するケースも
ないとは言えません。なぜそのような問題が起きるのでしょうか。
■人月・人日・人時間の迷路
一般的な開発の進め方は、ビジョンとコンセプトをもつ担当者が、オフショア開発ベンダーとミーティングを設定します。
担当者は、何をしたいのかを詳しく説明し、見積もり依頼をします。
そして技術チームとのQ＆Aディスカッションで、次のような回答を受けます。
「全部で約〇〇人月程度です。弊社の単価は〇〇円/人月となります。」
「どういう意味だろう？」と疑問に思う人は少なくないでしょう。
簡単に説明すれば、「1人月」とは、1か月の1人の労働時間、又はそれに相当する仕事量を意味します。タスクを実行するために必要な時間で、仕事量の尺度として使用されます。「人日」と「人時間」もほぼ同じです。
そこから、次の質問が浮かびます。
「20人月であれば、受取るまでに20ヵ月待たなければならないということ？」
もちろんそういうことはありません。
開発チームには通常、1人のプロジェクトマネージャー、1人のビジネスアナリスト、複数の開発者、及び複数のテスターで構築されます。一人でプロジェクトを完了させるわけではありません。 チームの人数が多いほど、プロジェクトの実施期間は縮小します。
「それなら、20人で実施すれば、たった1か月でアプリ完了ができますね？」
そういうことではありません！同時進行できる工程があるはずですが、すべて同時進行ができません。正確な開発期間は提案書に書かれます。例えば、20人月の案件は通常3~6か月ぐらいで実現されることが多いです。
オフショア開発に関する基本的な知識を把握して、これから、オフショア開発の失敗原因を解説します。
■原因1：仕様要件が不充分・不明確
例えば、貴社は素晴らしいアプリのアイディアを持っています。
例えば、中古車オークションアプリ。このアプリに車両情報のデータベースがあります。アプリ会員は無料で参加、車両が正常にオークションにかけられた場合にのみ手数料を支払います。
そのアイデアはビジネス言語で説明すると、とても簡単で分かりやすいですよね。しかし、どのように技術的な言語に翻訳するのでしょうか？
そこで、ビジネスアナリスト（BA）の役割が必要となります。
この人は、ビジネス言語と技術言語の両方を話すことができる翻訳者です。
お客様の要望・アイディアをヒアリングの上、BAは機能・画面・作業範囲を明確に定義します。
「なぜそんなに複雑なのですか？ とても簡単なんじゃないの？」
バツです！ 最初から正確に何を構築したいかを知ることは非常に重要です。
設計図なしで家を建てられないのと同じです。開発プロセス中に要件を頻繁に変更すると、受託先（オフショア開発側）の頭痛の種になります。
受託先（オフショア開発側）は、作業のやり直をしないといけないからです。結局最後には、変更の連続は委託先に返ってきます。コストが膨れ上がり
期限が守れなくなるからです。
最初から何を構築したいかわからずにアイデアを思いついた場合だと、最終的なアウトプットは以下となります。
■原因2：不充分コミュニケーションと良くないコミュニケーション
要件が充分でなく不明確なのに、受託先が何を求められているかを熟知しているならば、よいスタートが切れます。
やることは、オフショア開発側のがしっかり仕事をし納期を守るように
監督だけです。
しかし、認識合わせをするには、長い道のりがかかります。
自分が望んでいることを相手に理解してもらえるように説明がなかなかできません。たまには、オフショア開発側が発言した内容と意図を一つも理解できないことがあります。
まるで宇宙人と話しているかのように、コミュニケーションが取れません。
しかし、あきらめないでください！「理解すること」と「理解される」ことは、元々簡単ではありません。ゆっくり落ち着いて時間をかけて、違った表現で、説明を試みてください。問題がシンプルに解決できることが多いです。
■原因3:非現実的な期待
ユーザーが、アプリの料金を支払う時は、常に完璧でバグのないアウトプットを期待します。当然、期待しますよね。しかし不完全な世界で完璧なものを得るのは、困難で不可能。それがリアルな現状です。ユーザー受け入れテストの後、アプリにブロッカー・クリティカル・大きなバグがないことはありますが、マイナーバグや低レベルバグは、ある程度発生してしまいます。それはアプリの正しい機能や効果には影響しません。これら小規模は、保証期間中にすぐに修正できます。
さらに、どんなテクノロジーにも限界があります。テクノロジーとは進化し続けるものだからです。その時その時のベストを目指して開発されている為、期待どおりに動作しない場合もあります。そんな時、オフショア開発側にまず相談を持ちかけてみて下さい。
■その他の原因
株式会社Resorzは、プロジェクト失敗の一般的な理由をリストしています。
引用元:https://www.dreamnews.jp/press/0000106867/
■結論
要約すると、どんな要因、原因でも解決方法が必ずあります。オフショア開発を検討されている方のみならず、オフショア開発で問題が発生し、現在悩んでいる方も
これら要因、原因を理解すれば、対策は、見つかるはずです。
さらに別の悩みを抱えていらっしゃる方は、いつでも遠慮なく、悩みを聞かせていただければと思います。
「お問い合わせ」ページ
