ワンダーロボとオフショア開発、SESでの違いを紹介しています。
オフショア開発やSESに比べて、様々なメリットがございます。
ワンダーロボ開発ソリューションを適用すると、オフショア開発と比較して、多数の領域で優位な点を持ちます。
ワンダーロボ開発センター | オフショア開発 | スクラッチ開発 | |
---|---|---|---|
業務自由度 | ◎ 業務ロジックも自由 |
〇 仕様の伝達等に難あり |
◎ 業務ロジックも自由 |
品質 | ◎ RPAにより、プログラム品質が一定 |
△ 作業スキルに依存 |
△ 作業者スキルに依存 |
他システムとの連携 | ◎ 設計によりバッチ連携なども自由 |
〇 仕様の伝達に難あり |
◎ 設計によりバッチ連携なども自由 |
スケジュール | ◎ RPAでコーディング+オンサイトでの進捗確認も可能 |
△ 時差などもあり確認が難しい |
△ プログラムの確認まで時間がかかり品質担保時間が圧縮される |
開発コスト | ◎ RPAを利用することで低コスト |
△ 品質による手戻りリスク対応費+近年の海外技術者の単価上昇 |
△ 開発人員の工数によりコスト増 |
運用保守コスト | 〇 RPAと保守サービスで低コスト |
△ リモートでは完結しない業務もある |
△ 開発コストに比例して高コストになる |
業務自由度
会社特有の業務部分などでパッケージ適応が困難な場合は、スクラッチ開発が最初に考えられます。
オフショア開発でも業務自由度を確保することはできますが、細かなニュアンスを伝えることができ、言語や文化の差を埋められる優れたブリッジSEが必要になります。
ワンダーロボの場合は、会社特有の業務部分を自然言語で表現することで、設計工程以降をAIによる自動開発で対応することができるうえ、言語の壁はありません。
品質
スクラッチ開発を実施する場合は、一般的にはテストでの品質確保が難しくなります。
オフショア開発の場合は時差などもあり、品質確認に時間がかかり、気づいたら期限を守るのが困難な状態になっていることもあります。
ワンダーロボでは、RPA環境を利用したスピードコーディングで、プログラム実装が可能なため、設計と実装との差異を抑えながら開発を進めることができます。
さらに、RPA環境内でロボットが開発するため、作成されるプログラム品質にばらつきがでることもありません。
他システムとの連携
会社特有の業務部分などでパッケージ適応が困難な場合は、スクラッチ開発が最初に考えられます。
オフショア開発でも業務自由度を確保することはできますが、細かなニュアンスを伝えることができ、言語や文化の差を埋められる優れたブリッジSEが必要になります。
ワンダーロボの場合は、会社特有の業務部分を自然言語で表現することで、設計工程以降をAIによる自動開発で対応することができるうえ、言語の壁はありません。
スケジュール
スクラッチ開発は、開発手法により差はありますが、システムで表示する実際の画面やファイルの確認ができるようになるには時間がかかってきます。
オフショア開発だとさらなる要因として時差などが入るため、打合せの実施をしながらの進捗確認もうまくいきにくいといった問題が発生しえます。
文化の違いもあるので納期に対しての姿勢が、求めているものに届かないと感じる場面も多く出てくることもあります。
ワンダーロボ開発ソリューションだと、設計後のコーディング部分はRPA機能をフルにいかして、スピーディに結果をご提供できます。また、サービス提供の形として一緒の現場で作業をすることもできますので、進捗管理も現場でリアルタイムに可能となっています。
開発コスト
スクラッチ開発の場合はどうしても開発コストがかかるもの、さらに開発後の保守工程においても設計書の修正からコーディングとコスト増が続きます。
オフショア開発の一番のメリットといえる開発コストについても、近年の情勢としてはオフショア先の経済発展が早いこともあり、人件費の上昇が進み思ったほどコストメリットがでなかったという話もあります。
運用保守コスト
ワンダーロボ開発ソリューションの場合は、開発工程のうちコーディング部分をロボットが実施することで人の時間を確保し、その結果としてコストメリットを生み出しています。
また、保守運用費は開発費に対して比例して大きくなるもの。ワンダーロボ開発ソリューションでは初期の開発コストも小さく抑えられるので保守運用費も抑えることが可能です。
オフショア | ワンダーロボ開発センター | |
---|---|---|
作業内容 | 同じ 設計・開発・テスト |
同じ 設計・開発・テスト |
成果物 | 同じ 設計書・ソースコード・テスト成果物 |
同じ 設計書・ソースコード・テスト成果物 |
作業流れ | ①仕事をオフショア窓口に依頼 ②担当者が基本設計を確認し、詳細設計からコーディング、単体テストまで実施 ③発注側が詳細設計、ソース、テスト結果を確認、結合テストを実施 |
仕事を開発センター窓口に依頼して、 担当者が基本設計を確認し、詳細設計書を作成、コーディングロボットが自動的にコーディング、単体・結合テストを実施、発注側が詳細設計、ソース、テスト結果を確認、結合テストを実施 ※開発センター側が結合テストの実施を行ったため、発注側の結合テスト負荷を軽減できる |
仕様変更対応 | 発注側からオフショア窓口に連絡、影響調査、 設計書修正、コーティング、単体テスト |
発注側からオフショア窓口に連絡、影響調査、 設計書修正、コーディングロボットが自動的にコーディング、単体・結合テスト |
コスト | 詳細設計、コーティング、単体テストの工数 ×技術者単価 |
詳細設計、単体・結合テストの工数 ×技術者単価 +ロボットに利用料 ※オフショアより50%削減可能 |
コミュニケーション コスト |
基本技術なしBSE+複数技術者の体制 仕様連絡はBSEに依存し、BSEは開発できないため、正しい通訳が心配、認識相違が発生しやすい |
日本国内の開発センターで実施し、日本人技術者又は日本語精通の技術者と会話するので、コミュニケーションコストのロスが発生しない |
資料作成コスト | 英語など翻訳が必要のため、資料翻訳コストがかかり、 資料メール往来は全部翻訳が必要なので、担当者の負荷と時間ロスが大きい |
全部日本語資料でのやり取りのため、外国語による担当者の負荷と時間のロスが発生しない |
期間 | 詳細設計+コーティング+単体テストの工数 | 詳細設計+単体・結合テストの工数 ※ロボットでの自動開発のためコーティング工数省略 |
複雑・難易度高い ロジック |
同じ スキルの高い技術者を活用、既存のライブラリの利用も可能 |
同じ スキルの高い技術者を活用、既存のライブラリの利用も可能 |
コード品質 | 国の文化が違うため、コメント漏れ、try catchなど、 コーティング規約を遵守しないことが発生 |
コーティング規約に沿って自動開発 設計書内容をコメントとして出力 要望によって新しい仕様対応が可能 |
開発品質 | 言葉の問題で、仕様設計の開発漏れ、誤認識による開発ミスが発生しやすい | 必ず日本語の設計書を準じて開発するため、 開発漏れ、誤りが発生しにくい |
バグ摘出 タイミング |
発注側の確認段階 ※遅れる恐れがある |
設計バグはロボット自動コーティング中 開発バグはテスト中 ※設計ミスは早期発見可能、開発バグは高いコーティング品質のため、人の開発よりバグ数がはるかに少ない 国内開発のため、随時仕様の確認が可能 |
納期切迫 プロジェクト |
人海戦術してもコントロールできないため 赤字プロジェクト |
国内且つスピーディー開発 赤字プロジェクトは発生しない |
PM | 海外オフショアのため、プロジェクトの規模に関係なく、開発品質、スケジュールが不安 | コーティングの不安が解消したため、 一番不安な要素が払拭できる 国内開発するため、進捗は随時に確認が可能 |
技術拡張・改善 | 海外オフショアの技術者は特定のスキルしかもたないため、対応が難しい | ロボットが開発を実施するため、 プロジェクト期間に余裕ができ、 プロジェクト開始前・実施中にロボットに対してカスタマイズや 新しい技術の利用が可能となる |
メンテナンス性 | 設計書のメンテが遅れる場合、設計書とソースの乖離が大きくなり、ソースを確認しても、技術者のコーティングスタイルがばらばら、保守対応の工数、バグ発生リスクが大きい | 設計書を基にロボットがコーティングするため、設計書は最新の状態にメンテできる。ロボットが開発したソースは命名規則、コーティング規約を準じるため、ソースも確認しやすい。保守対応の工数とバグのリスクを軽減できる |
SES/派遣 | コーティングロボット派遣 | |
---|---|---|
作業内容 | 同じ 設計・開発・テスト |
同じ 設計・開発・テスト |
成果物 | 同じ 設計書・ソースコード・テスト成果物 |
同じ 設計書・ソースコード・テスト成果物 |
作業流れ | 仕事が依頼されて、 担当者が基本設計を確認し、詳細設計からコーディング、単体テストまで実施、SEが結合テストを実施 |
仕事が依頼されて、 担当者が基本設計を確認し、詳細設計書を作成、コーディングロボットが自動的にコーディング、単体・結合テストを実施してからSEに引き渡し |
仕様変更対応 | SEからPG担当者に連絡、影響調査、 設計書修正、コーティング、単体テスト |
SEからPG担当者に連絡、影響調査、 設計書修正、コーディングロボットが自動的にコーディング、単体・結合テスト |
既存システムに 機能追加・改善 |
可 技術者が詳細設計書を確認、 既存ソースを調査、コードを修正、ソースをマージ・テスト |
可 技術者が個別機能の設計書を確認・修正、 ロボットが個別機能に対してコーティング 技術者がソースをマージ・テスト ※開発範囲が指定可能ため、保守対応可能 |
コスト | 詳細設計、コーティング、単体テストの工数 ×技術者単価 |
詳細設計、単体・結合テストの工数 ×技術者単価 +ロボットの利用料 ※SES/派遣より65%削減可能 |
コーティング工数 | JAVA技術者の一日最大ステップ数は200ステップ ※例:60機能10万ステップの場合25人月 |
ロボット自動コーティングのため、 分単位で計算するので、工数は省略可 |
期間 | 詳細設計+コーティング+単体テストの工数 | 詳細設計+単体・結合テストの工数 ※ロボットにより自動開発のためコーティング工数省略 |
複雑・難易度高い ロジック |
同じ スキルの高い技術者を活用、既存のライブラリの利用も可能 |
同じ スキルの高い技術者を活用、既存のライブラリの利用も可能 |
コード品質 | 人によってスタイルがばらばら、コメント漏れ、 try catchなどコーティング規約を遵守しないことが発生 |
コーティング規約に沿って自動開発 設計書内容をコメントとして出力 要望によって新しい仕様対応が可能 |
開発品質 | 要件を設計通りに開発せず、 間違った認識で開発してしまい、 開発漏れの可能性がある |
必ず設計書を準じて開発するため、 開発漏れ、誤りが発生しにくい |
バグ摘出 タイミング |
開発バグは単体テスト中 設計バグは結合テスト中 |
設計バグはロボット自動コーティング中 開発バグはテスト中 ※設計ミスは早期発見可能、開発バグは高いコーティング品質のため、人の開発よりバグ数がはるかに少ない |
納期切迫 プロジェクト |
人海戦術 赤字プロジェクト |
スピーディー開発 赤字プロジェクトは発生しない |
現場管理者 | 技術者の管理難しい スキルばらばら 進捗確認管理大変 |
弊社の社員はロボット活用を熟知し、 ロボット365日24時間稼働可能 進捗は一目瞭然 |
PM | プロジェクト規模が大きくなるにつれ不安が増す | コーティングの不安が解消したため、 一番不安な要素が払拭できる |
技術拡張・改善 | 開発は技術者依存が大きく、 新しい技術の適用は躊躇する傾向 |
ロボットが開発を実施するため、 プロジェクト期間に余裕ができ、 プロジェクト開始前・実施中にロボットに対してカスタマイズや 新しい技術の利用が可能となる |
メンテナンス性 | 設計書のメンテが遅れる場合、設計書とソースの乖離が大きくなり、ソースを確認しても、技術者のコーティングスタイルがばらばら、保守対応の工数、バグ発生リスクが大きい | 設計書を基にロボットがコーティングするため、設計書は最新の状態にメンテできる。ロボットが開発したソースは命名規則、コーティング規約を準じるため、ソースも確認しやすい。保守対応の工数とバグのリスクを軽減できる |
さらに詳しい情報が知りたい、ワンダーロボについて一度お話を聞きたいなどございましたら、下記のお問い合わせ、またはメールにてご連絡ください。
専任のコンサルタントよりご連絡させていただきます。
メールの場合はこちらから
フォームはこちらから