【2023年】オフショア開発成功事例：伴走支援型開発とは、成功事例とプロジェクト管理手法

【2023年】オフショア開発成功事例：伴走支援型開発とは、成功事例とプロジェクト管理手法

10年目を迎えるオフショア開発ONETECHの紹介

本日は伴走支援型オフショア開発についてご紹介いたします。 弊社は、オフショア開発を検討されている方や以前に上手くいかなかった方々に対し、オフショア企業を選ぶ際の観点としてご参考いただき、また日本の人材不足解消の一助になれればと考えております。 弊社は創業10年目を迎え、日本での創業は8年目になります。私自身も18年間、ベトナム人のエンジニアと共に日本向けのシステム開発に携わってまいりました。 ONETECHはプライム市場に上場している大企業からスタートアップのお客様まで、すでに100社近くの幅広い取引実績を持っております。 ただし、お客様にご迷惑をおかけしたことも多くあり、完全に改善されたわけではありませんが、改善には努めてまいりました。 現在、弊社では昨年ご取引いただいたお客様とのリピート率を重要なKPIとしており、直近では80％以上になっております。これは長年にわたる試行錯誤により、プロジェクト管理や最新技術のキャッチアップを実施してきたからだと考えております。 しかしながら、まだまだ不足していると感じております。プロジェクト管理や最新技術のキャッチアップを行っても、お客様に完全な満足を提供できていないという課題があります。  

第１部：伴走支援型オフショア開発とは

その解決策として、伴走支援型が登場しました。これは、顧客志向を重視する手法であり、お客様の要求やニーズに寄り添い、協力しサポートすることで共同でプロジェクトを成功に導くものです。弊社は、柔軟な対応と高品質なサービスの提供を目指し、顧客とのコミュニケーションを重視しております。  

セミナーの内容

まずは第１部で伴走支援型の考え方とその背景についてご説明いたします。 次に、私たちのエンジニアとして18年にわたりベトナムとのシステム開発に関わってきた和田が、成功事例をいくつかご紹介します。これらの成功の背景には、顧客志向の重要性があります。 その後、弊社の共同創業者であり技術責任者の下島グエンから、長年にわたり改善を重ねてきたプロジェクト管理についてと、伴走支援を実現するための取り組みについてご紹介します。 最後に、元々はエンジニアでしたが、3年前に日本に来て営業やプロジェクト管理に力を注いでいるギアから、技術視点からの顧客志向について紹介します。具体的には、弊社の実績のあるAWSの様々なサービスの一部をご紹介いたします。

オフショア開発の本質的な課題

オフショア開発の本質的課題 まずは第１部で、伴走支援型の考え方とその背景についてお話しします。 このスライドではオフショア開発における一般的な課題を図示しています。左側が日本の発注企業であり、右側がベトナムの受注企業です。 発注企業は人材不足やDXの急務、予算制約などの課題を抱えています。そのため、ベトナムのようにIT人材が豊富で、親日国家であるオフショア開発を選択します。また、近年は人件費高騰や円安などもありますが、現在でもコストの優位性も存在します。 オファーがありオフショア開発側が何を考えているかと言うと、③のような考え方です。当初は楽観的に捉え受注するのですが、ある時にベトナムではプロジェクト管理やビジネスの観点で知識や経験が不足していると気付かされます。始めたばかりのオフショア開発企業だと、この点に気づかないこともあります。ベトナムでは技術力はプログラミング言語の熟知や最新技術の知識などを指すことが一般的です。品質管理やプロジェクト管理には課題があります。 そのため、オフショア企業はリスクヘッジを目指した提案を行います。その代表的なものがラボ契約です。これは日本のSES業界にも類似しています。ラボ契約ではスキルセットを提示し、発注企業側に人材のスキルを確認してもらいます。ベトナムにはプログラマーの人材は豊富におり、日本語を話せる通訳者も多くいます。ただし、通訳者にはプロジェクト管理などのスキルが不足している場合が多いです。 次に、④に移りますが、日本側は予算制約からできるだけ低コストを求めます。また、日本語のコミュニケーションが円滑に行えるため、安心感を抱くこともあります。しかし、これによってうまくいくと考えるのは誤解です。 一方、⑤のオフショア側はより安い給与の人材をアサインしようとします。ベトナム市場には経験の浅い若手エンジニアが多数存在し、そのようなエンジニアを採用することは比較的容易です。日本側は人材不足と予算制約からラボ契約を選択します。また、日本語ができる人材がいるため、ドキュメントのやり取りを省いて口頭やチャットを利用したアジャイル開発を選択します。しかし、未経験のエンジニアがアジャイル開発を成功させることはできるのでしょうか。ビジネススキルや経験の不足するエンジニアがアジャイル開発を行うことは、この段階で矛盾していると言えます。 一方、⑤のオフショア受注企業はリスクヘッジの観点から、ラボ契約というプロダクトへのコミットメントがなく、長期契約が多いラボ契約を選択します。 このようなやり方では悲劇が起きるのは当然です。私たち自身も、ラボ契約を結んだ経験があります。ちなみに弊社はラボ契約よりも請負契約を提案しています。請負契約には本当の意味での技術力がつくと言う副次メリットがあると考えています。 そして、⑥の振り返りの際に、よくあるのはコミュニケーションの問題を単純化しようとしてしまうことです。そして、本質的な問題に言及せずに、プロジェクト管理などのプロセス管理の改善だけに重点を置いてしまいます。これにより改善は一部見られますが、本質的な改善は行われません。その結果、顧客のリピート率が低下するのは当然です。 オフショア開発において本質的な課題は、日本側の人材不足による丸投げや、チャットや口頭による曖昧な指示、そしてベトナム側のビジネスやプロジェクト管理の知識や経験の不足です。背景には大学教育などの教育環境の問題や成長段階の社会ということも考えられます。  

伴走支援型オフショア開発とは

伴走支援型開発とは

では課題解決に向けてですが、日本の人材不足は一朝一夕では解決するのは難しいので、私たち自身がどのように考え行動して課題を解決していくかが伴走支援型オフショア開発の考え方です。これはオフショア開発やベトナムのIT技術を発展させるためにも貢献できると考えます。

まずは日本では当たり前に聞くことなのですが、顧客志向です。お客様のいる環境であったりこのシステムやプロダクトを作る背景であったりをしっかりと理解します。弊社はできるだけ現場に赴いてお客様がなぜこのシステムを作りたいのかを理解します。

そして次に②番ですが、そのプロダクトの目的やゴールを理解します。システムの機能だけでなく、いわゆる非機能要件といわれているビジネスの要件から、そのシステムをどのように使うか将来的にどのように拡張してくのか、セキュリティはどうすべきか、最適な運用コストはどうしたら良いかなどを考えていきます。

 そして③④ですがビジネス観点、顧客観点からどのような技術がよいのかを提案します。ここは４部でギアの方からAWSを例にして解説します。

つぎに伴走支援を実現するプロジェクト管理の手法を提案します。こちらも３部で下島グエンから詳しく紹介します。

 伴走支援型のプロセスではお客様のビジネスとプロダクトの目的に認識違いがないのかを頻繁に確認します。

「なぜこのような技術を提案するのか」 「なぜこのような体制なのか」 「ビジネスの成功のために初期開発のスコープは最低限の機能でトライアルをしませんか」 などのコミュニケーションが実践的な例です。

これは初期開発だけでなく追加開発やシステム運用時にも適用されます。 「その機能は本当に必要ですか」 「運用で乗り切った方がコスト最適でないでしょうか」

また特にスタートアップの企業は、市場にサービスを投入すると初期のプロダクトの設計時点の目的とサービスローンチ後の目的が変わったりすることもよくあります。 ですので③④⑤⑥⑦⑧と行ったり来たりします。

 これらがあたかもお客様と一緒にマラソンを伴走するようなイメージです。

 伴走支援型オフショア開発とはお客様の観点でお客様と一緒にゴールをするという考え方です。

 私のパートは以上となります。

 それでは次に伴走支援型オフショア開発の成功例をいくつか紹介させていただきます。

第２部：伴走支援オフショア開発成功事例

オーケストラ　ライブ配信プラットフォームの成功事例

まずは、イベント企画、動画サイト運営を行っている企業様の事例です。 ライブ動画配信プラットフォームサイトのリニューアルを開発し、UIデザインと機能を拡張してサイトを一新しました。   導入の背景としてリニューアルする前の旧サイトでは、保守作業が十分にできていませんでした。 クライアント様の社内にはシステムエンジニアがおらず、不具合の緊急対応や機能拡張ができずサイトの運営がうまくできずにしました。  

 伴走支援型の開発の効果

お客様側にはシステムに精通している人材がいないため、伴走支援型開発のアプローチを利用し、サービスおよび業務理解から取り組みました。 業務理解をより深めるため、お客様の配信現場を見学するなど、お客様の視点に立った使い勝手の良いシステムを共同でコミュニケーションしながら進めることができました。 サービス要件をより深く理解し、システム提案が可能となり、プロジェクトは円滑に進行することができました。  成功の要因として顧客志向、目的ゴール、プロジェクト管理、技術・プログラミングの４つの観点で要因を説明いたします。 ビジネス顧客志向では、旧システムの業務フローの整理から始め、旧システムにおける課題をヒアリングすることで、より使い勝手の良いシステム提案が可能となりました。 また、伴走支援型の体制を整えることで仕様変更や機能追加などにビジネス観点と開発者側の視点からまとめ、定義し、柔軟な対応をご提案できて素早く継続的なリリースを実現できました。 プロダクトの目的ゴールでは、詳細な業務のヒアリングを継続することで、重要な機能について合意形成ができ、要件定義が収束せず要求が膨れ上がるという状況を防ぐことができました。 リリースまでの目標のすり合わせを円滑にできました。 プロジェクト管理は細やかな情報共有（ツール提案）と進捗管理（タスク管理）をキックオフ時に明確に定義し、計画を確定することができました。 技術では、開発サイクルを効率化するためにCI/CDによる自動運用を採用しました。  

印刷会社の卸売マーケットプレイスの成功事例

続きまして印刷会社様の事例です。 BtoB展示会見積もりプラットフォームの開発を行いました。 卸売業者と小売業者の間の取引をデジタル化し、業務効率化できました。   同じように導入の背景として、従来の印刷会社では、展示会などのイベントにおいて見積もり作業が煩雑で時間を要していました。 印刷業界における業務改善DXの一環として、プラットフォームシステムの導入が行われました。   効果は、企画から要件定義、UI/UXデザイン、設計、開発、テスト、保守運用まで、プロジェクトの全段階を担当しました。 クライアントからの課題ヒアリングや業務フローの作成をサポートして、 お客様と緊密に連携し、問題点を把握し、効果的な業務フローの作成に貢献しました。  

成功の要因

顧客志向は、企画から要件定義、UI/UXデザイン、設計、開発、テスト、保守運用まで、プロジェクトの全段階を担当しました。 クライアントからの課題ヒアリングや業務フローの作成をサポートしました。 お客様と緊密に連携し、問題点を把握し、効果的な業務フローの作成に貢献しました。   目的ゴールは、柔軟性と戦略性を持った開発と運営が行え、 プロジェクト管理は、開発の段階的なスコープの定義やタイムラインの設定、リソースの適切な割り当てできて、プロジェクトの進捗や品質管理が徹底することができました。 プログラミングは様々なAWSサービスを利用してシステム構築。セキュリティや高速表示などの機能を実現しました。  

デジタルギフト発行システムの成功事例

続きまして広告代理店の企業様の事例です。 来店促進デジタルギフト発行システム開発を対応しました。 店舗やイベントにて効果的なギフトシステムを導入できます。   導入の背景は、 効率的なギフト管理や迅速な発行を実現するため、より効果的なシステムの導入が求められました。 また、お客様先ではクラウドサービスの構築や保守に関する実績が不足しており、最適なシステム構成を提案できる信頼できる企業を必要としていました。   効果としてお客様との緊密な連携を重視し、お客様の業務フローを詳細にヒアリングして、ニーズや課題を的確に把握することで、システムの効率化に成功しました。 また、外部サービスとの連携開発においては、ビジネスファーストの観点から最適なサービスの提案から始め、新しいアイデアの構想もお手伝いしました。   顧客志向ではシステムの実現性に関する相談から始まり、お客様のニーズと要件を徹底的にヒアリングしました。 今後の展望を考慮して、拡張性の高いシステムの提案を行いました。   目的ゴールではお客様システムとの連携を希望のためのAPI設計・実装に取り組みました。システムが他のシステムとのシームレスなデータのやり取りを実現したシステムの構築するゴールが達成できました。   プロジェクト管理ではスケジュール管理やリソースの適切な配分を行い、プロジェクトの進捗を常に把握するため毎週の定例会議を実施しました。   技術観点ではセキュリティの重要性を認識し、ギフトデータへのセキュリティー対策としてAWS WAFおよびAWS Shieldを導入し、DDoS攻撃に対する防御を強化しました。  

伴走支援オフショア開発の成功のポイント

今までの3件の事例を見ると伴走支援型の成功のポイントはこちらの３つと考えています。 ・顧客のニーズを徹底的に理解する ・現場に足を運ぶなど顧客視点を考える ・現場に足を運ぶなど顧客視点を考える  

第３部：成功事例のポイント

第3部：成功実例のポイントを紹介させていただきます。 システム開発にあったて弊社側で最初クライアントの業務課題についてシステム開発から運用保守まで下記の３つのポイントがあります。 ・顧客志向　→　キックオフで業務理解状況を明確にして不明な点及び未定な要件に関してどのように取り扱いをすべきかクライアントと相談し、明確化して、業務要件をお互いに認識する。開発側でできる限り上流工程において明確するようにすることにより設計工程で安定なシステム設計を作成できます。 ・開発時の プロダクト ゴール　→　お互い担当を明確にする。希望納期の通り。リリースする　→　重要な機能、納期を合意します。 ・運用時の プロダクト ゴール　→　システム運用対象、運用作業など、保守工数などを明確にする　→　運用課題をクリアできます。  

キックオフのポイント

キックオフミーティングで実施する時は、主に３つの課題についてお互いに確認します。 ・要件定義があいまいという課題、クライアントの課題ではあるのですが、どのように解決するかヒヤリングしながら鮮明にしていきます。その時に弊社側でクライアントの業務を理解して提案書を作成し、業務理解と課題認識を確認します。弊社のテンプレートで要求から運用まで課題もヒアリングして明確な問題を洗い出します。 ・プロジェクト進行課題に関して弊社の８割のクライアントはエンドユーザーなので、プロジェクト進行なども分からないケースが多いです。キックオフで業務において重要な機能やリリース時期を確認します。円滑に進めるため、作業範囲、役割分担も明確にします。 ・システム運用課題に関してシステムリリース後にはクライアントはどのようにビジネス運用をして安定的にシステムを監視する必要があります。キックオフで運用までも検討することより設計工程で事前に工夫して安定なシステムを作成することができます。事前に運用課題もクリアできます。  

非機能要件のリスト化

下記の画像ですが、開発時も非機能一覧により業務安定のためにすべて項目を洗い出して確認を行います。  

キックオフ資料

キックオフで業務範囲、機能要件、非機能要件はそれぞれで確認を行います。  

顧客志向

プロジェクト進行課題で弊社側でPMI基準に基づいてプロジェクト管理を実施します。すべて開発体制、スケジュール、コミュニケーションなども確認を行います。

プロジェクト管理

弊社での品質基準に基づいて、進捗、詳細タスクをWBSへ追加して顧客へ共有します。  

システム運用保守

システムリリース後には、運用保守が不可欠なので、弊社での運用保守基準に基づいて運用設計も実施します。運用保守で監視する対象システムを洗い出して通知設定を行います。通知レベルより事前にアクション定義も行って手順書の作成を行います。運用保守管理は主に保守業務、保守契約、レポートで行います。  

運用保守の業務定義

運用保守業務の各項目に対してクライアントのビジネスに必要な項目を確認し詳細な設計も行います。セキュリティー関してセキュリティー基準に沿って設定を行います。  

運用保守管理

  運用保守ではすべてタスクは弊社のRedmineで管理します。各タスクは対応工数を内訳に報告します。対応工数などが運用保守工数より超過が発生する時にはクライアントに承認をとり対応します。

運用保守体制

運用保守体制も運用保守キックオフで確認します。  

第４部：技術からの顧客志向の提案

クライアントの満足度を更に向上させるため、伴走支援オフショア開発活用技術の提案を行っています。具体的には、AWSのWebサービスに特化した提案を行っています。AWSは200以上のサービスを展開しており、私たちは日々最新情報をキャッチアップして、お客様のプロジェクトに最適な提案を行っています。今回はいくつかをピックアップしてご紹介します。 以下、代表的な4つの提案事例をご紹介します。

1. リザーブドインスタンス

リザーブドインスタンスはサーバーのコスト削減に役立つサービスです。長期契約が求められますが、私たちはサービスリリースご6か月間の試運転を行い、最適な構成サーバーを提案します。これにより、カーテンコールさんの例では月額7万円、年間70万円のコスト削減に成功しました。 実際の運用の例：

2. サーバーレス

これは新しいサービスで特徴としてはサーバー管理が不要、規模の調整が簡単、ほぼ人手がかからないということです。 そしてコスト削減が期待できます。一方で経験が必要であったりですとか メモリと実装時間が制限があったりとかというリスクもあります。 ここでのポイントはサーバー費用の削減だけではなくて、 実はこの規模調整が簡単ということは監視業務が通常より比較的に少なくて進みます。 これによって運用コストの削減ができます。システム運用はサーバーコストだけではなくて人的な運用コストというのが非常にコストがかかってきます。冒頭でもあったように日本で人手不足が言われていますが 、人手不足解消も同時に削減することでトータルのコストが削減することができます 続いてEC2とサーバーレスの比較です ここではポイントだけお話するとサーバーレスは初期開発の時は経験値が必要で あったりとかコストが高いとか課題はあります。しかしながら運用時は先ほど説明したように自動拡張をしたりですとかメンテナンスが不要で あったりとかっていうことがありますのでオペレーティングコストの削減が期待されます

3. Terraform

Terraformを活用することで、お客様のサービスを世界展開しやすくなります。各地のサーバー設定を簡単に行い、展開時間の削減と運用コストの削減が見込まれます。

4. CI/CD

現在OneTechではアプリのデプロイメントは全ての段階で自動化を実現しています。 これによってヒューマンエラーを削減しリグレッションなどの手戻り、リワークを防止します もちろん展開時間も減らすことができますで各環境のソースコードは常に矛盾がなく一致しています これはどういう効果があるかと言うと運用時のコスト削減これもオペレーティングコストの削減につながります。 これらの技術提案は、顧客志向に基づいてお客様のプロダクトのゴールを把握し、初期の段階から運用までを見据えたものです。常に最新の技術にも目を向け、お客様と共に成長していく伴走支援型の開発を提供しています。  

まとめ

改善する余地はあるかもしれませんが、私たちはお客様に満足していただけるよう、努力を惜しまず技術提案を行っていきます。引き続きお客様のニーズに寄り添い、最高のサービスを提供できるよう努めてまいります。どうぞよろしくお願いいたします。   https://youtu.be/bdccrGoNy1k?list=PLl7ufmuKSTQ4fInKxlreWmZQar3bWNCCv https://youtu.be/bB4pcwox9aw?list=PLl7ufmuKSTQ4fInKxlreWmZQar3bWNCCv https://youtu.be/xMzv32dMDX0?list=PLl7ufmuKSTQ4fInKxlreWmZQar3bWNCCv https://youtu.be/3QD2iXKV8lQ