経済産業省の「2025年の崖」って?問題と対策を解説!

投稿日:2022.07.22更新日:2023.09.20

「2025年の崖」って?

「2025年の崖」とは、経済産業省が2018年に発表した「DXレポート」という資料で使われた言葉です。資料の内容は日本国内の企業におけるDX推進の必要性で、このままDXが推進されなければ2025年以降は最大で12兆円もの経済損失が生じる可能性があると言われています。この状況を、「2025年の崖」という言葉で表現しています。

DXの推進が滞ることで、業務効率や競争力の低下は免れません。また、ITシステムを利用するユーザーやITシステムを開発するベンダー双方にも以下のようなリスクが伴うとも言われています。

【ユーザー】

・急速に増加するデータ量を十分に活用できず、デジタル競争に勝てない
・多くの技術的負債を抱え、老朽化した既存の業務システムを維持することが困難になる
・災害やセキュリティ事故などによるデータ損失・情報漏洩のリスクが高まる

【ベンダー】

・老朽化した既存システム(レガシーシステム)の運用や保守に労力がかかる
・レガシーシステムのサポートに伴う人月商売の受託型業務から脱却できなくなる
・最新のデジタル技術に精通した人材が確保できず市場から取り残される

 

 

出典:https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_01.pdf

IT技術は日々進化しており、その進化に合わせて企業のあり方もアップデートが必要です。既存システムの運用・保守から脱却できなければ、企業の競争力低下につながります。

一企業・単一の産業だけに留まらず、国内企業の全体がDXを推進しなければ2025年以降は国益の大きな損失まで引き起こしかねません。

「2025年の崖」に対する現状

結論から述べると、日本は未だ「2025年の崖」への歩みを止められていないのが現状です。

そもそも、DXレポートにて言及されている年間12兆円もの経済損失は、何が原因で起こり得るのでしょうか。

DXが進まないということは、2025年以降のレガシーシステムが残り続けることになります。レガシーシステムを抱え続けることでシステムリスクが発生する可能性が高まり、それに起因するシステム障害が経済損失の大きな理由と考えられています。

2014年の時点ではすでに「データ損失やシステムダウンなどのシステム障害による損失」が国内全体で約4.96兆円に達したとの調査結果を参考に、別の調査では「レガシーシステムに起因して発生するシステムトラブル」が全体の8割を占めるとのデータが出ています。それを踏まえて企業の基幹系システムの稼働年数を調査した報告書の内容から、2025年の時点で21年以上稼働しているシステムを抱える企業が全体の6割になると予測されています。

上記のデータを参考に、レガシーシステムによるシステムリスクも最大で3倍にまで上昇すると見積もり、2025年以降の経済損失額を年間約12兆円と予測したということです。

2014年の時点ですでにシステム障害による損失が4兆円を超えていることに加え、未だレガシーシステムから脱却できていない企業が大幅に減っていないこと、 IT人材の不足が改善できていないことといった現状を踏まえると、「12兆円の経済損失」も一概に大げさな数字とは断言できません。

2025年が間近に迫る中、なぜ日本企業は上記の課題を改善できずDX推進を滞らせているのでしょうか。「レガシーシステム」「IT人材の不足」「日本のIT費用の事情」という、DX推進を妨げる3つの大きな原因ごとに次項より詳しく解説していきます。

日本のDXが進んでいない理由

 

レガシーシステムが存在している

レガシーシステムとは、長期間にわたり使い続けたことで老朽化・肥大化・複雑化したシステムや、そのシステムに精通した人材がおらずブラックボックス化したシステムのことを指します。先述の通り、DXレポートが発表された時点でレガシーシステムを抱えている日本企業は全体の8割という状態で、現在もその状態が著しく改善されているとは言えません。

レガシーシステムは運用・維持に多大なコストがかかる他、「システム障害に起因する損失」のリスクを高めます。一方で、レガシーシステムの刷新にも大きなコストがかかるものです。また、複雑化・ブラックボックス化したシステムを把握したうえで新たなシステムに切り替えること、既存とは使い勝手が異なるシステムに慣れる必要があることなど、様々なハードルが立ちふさがります。

リスクがあると分かっていても、企業経営の現状を維持するためにはレガシーシステムに頼らざるを得ないという問題があります。

IT人材不足

企業がレガシーシステムを抱え続ける原因のひとつとして、「IT人材の不足」が挙げられます。

レガシーシステムの稼働期間が長いと、それに使われている古いプログラミング言語を理解する人材が退職や定年を迎えて不足に陥ります。しかし最新システムを導入しようにも、IT人材そのものが慢性的に不足している日本では、最新技術を習得した新しい人材を確保することが困難な状態です。現に経済産業省が平成28年に発表した資料では、2015年の時点で17万人不足していたIT人材が2025年には43万人の不足にまで拡大すると予測されています。

上記のような事情からIT人材を自社内で育成・採用することが困難であるため、ITシステムの開発・改修・保守・運用を海外のベンダー企業に委託する企業が多いです。その結果、自社内にIT技術のノウハウを蓄積されずシステムの再構築に向けて積極的に取り組むことができなくなります。

新たな人材を確保できず、自社内の人材を再教育することもできないといった状況が人材不足を悪化させ、DX推進が実現できないという問題を生み出します。

日本のIT費用の大半が運用・保守

海外では Google・Apple・FaceBook・Amazon(GAFA)をはじめ、多くの企業がDXを中心とした新しいビジネスを展開しています。

一方、日本企業はIT費用の90%を既存システムの運用・保守に回しているのが現状です。情報サービスを提供するベンダー側としても、「システム開発・保守・運用の受託事業」が主なビジネスモデルとなります。

上記のようなビジネスモデルではただクライアントが提示した仕様に合わせて開発を行うことの繰り返しになり、IT技術の進化も見込めません。その結果、日本のIT技術は海外に後れを取り国際競争力も失われる可能性があります。

「2025年の崖」によって影響を受ける企業

「2025年の崖」により影響を受ける企業は、大企業に限った話ではありません。中小企業から個人事業主、ひいては経営者に留まらず現場で働く従業員の働き方も変化する可能性があります。また、ビジネスの恩恵を受けている人や消費者も例外とは言えません。

先述の通り、2025年の時点で21年以上稼働を続けるレガシーシステムを抱えた国内企業は全体の6割を占めると予測されています。創業から日が浅い企業よりもレガシーシステムを長年使い続けた企業の方が「2025年の崖」を大きく受けることが考えられます。

「2025年の崖」を乗り越えるには、創業年数の長い企業ほどある程度大きなコストをかけてでもDXを推進することが必要不可欠です。

コスト・費用をかけてでも「2025年の崖」を超える意義

上記にて挙げた3つのポイントだけでなく、システムの刷新に伴う高いコスト・費用もDX推進を滞らせる原因のひとつと言えます。

DXレポートでは、システム刷新にかかるコストについて業界ごとで以下の通り例を挙げています。

事例①(運輸業):7年間で約 800 億円をかけて、50 年ぶりに基幹システムを刷新し、
運用コストの効率化・生産性の向上につなげる。
事例②(食品業):8年間で約 300 億円をかけて、30 年以上利用していたシステムを
刷新し、共通システム基盤を構築。
事例③(保険業):約 25 年経過した基幹系システムを、経営陣のプロジェクトのもとで、
4〜5年で約 700 億円をかけて、IT システム刷新を断行。

引用: https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_03.pdf

あくまで例ではありますが、システムの刷新は中長期的な年数と数百億円単位の費用がかかる見込みとされています。数年単位で経営者が変わる企業においては、その任期にシステム刷新のメリットを受けにくいという事情もあります。このような事情から、中長期的な期間を見据えてのシステム刷新を経営判断することが難しい状況です。

とはいえ、先述の通りレガシーシステムを抱えている企業はその運用・保守にリソースの大半を消費していることも事実です。このまま技術的負債を抱えたまま放置しては、ビジネスにおける新たな付加価値を生み出すための投資に資金や人材を振り分けることができなくなり、ビジネスの創造効率が低下します。これにより、世界はおろか国内における競争優位性の低下も免れません。

多大なコストを費やすことよりも、コストに対する恐れから現状を維持し続ける守りの姿勢によって被るデメリットの方が深刻と言えます。そのため、人・モノ・お金というリソースを惜しまず投下してシステムの刷新に取り組む攻めの姿勢が重要です。

なお、経済産業省はDXレポート上にて「2025年までに既存のITシステムを廃棄や塩漬けにするなどの仕分けをしながら、必要なものを刷新しつつDXを実現する」というシナリオを描いています。

ユーザー企業は2020年までにシステム経営の判断を行ったうえで、DXのプランニングや体制構築などを進めること。そして2021〜2025年を「システム刷新集中期間」と称し、経営戦略を踏まえたシステム刷新を最優先課題として取り組むよう提案しています。

「2025年の崖」問題解消への課題

 

ビジョンや経営戦略の欠如

DXレポートでは、「2025年の崖」問題を深刻化させる要因としてビジョンや経営戦略の欠如を挙げています。

DX推進の必要性を理解し、推進に向けて取り組む意欲があっても具体的な方向性が定まっていない企業が多いといいます。DX推進の先に見据える目標が曖昧なままやみくもに取り組んでも、DX推進そのものが目的となりビジネスの変革へと繋げることは不可能です。

最初に「DXによりビジネスや自社商品・サービスにどのような変革をもたらしたいのか」といったビジョンを明確に定めてから、経営層と現場が一丸となって推進に取り組む必要があります。

既存ITシステムの老朽化・肥大化

先述の通り、日本企業の大半は長期間にわたり稼働を続けるITシステムの運用・保守に多くのリソースを割く現状から脱却できずにいます。

長きにわたって稼働し続けたシステムは老朽化・肥大化が進行しており、改修が難しいためにDXが進まない企業が相応に多いということです。改修が困難になる例としては、技術的に古く蓄積可能なデータ量がきわめて小さかったり、その場しのぎともいえる改修を重ねてプログラムのロジックが複雑であったりするなどが挙げられます。

老朽化・肥大化したシステムは改修が困難なだけでなく、失敗した際の業務的リスクも決して小さなものではありません。そうした懸念の解消に取り組むこともまた、DX推進に必要な取り組みです。

DX推進人材の枯渇

DXを推進するにあたって必要なことが、「レガシーシステムからの脱却」です。それには最新のIT事情だけでなく、既存システムの仕様も理解した人材が揃わずに成せるものではありません。

しかし既存システムの稼働期間が長いほど、その仕様について理解する人材は退職や異動などの事情により減り続けます。少子高齢化による労働人口の減少が深刻化する現代では、新しい人材を採用することもままならないものです。

その場合はベンダー企業に力を借りてDX推進を目指すという手がありますが、ただビジョンが不明瞭なまま取り組みを丸投げすることは避ける必要があります。

ユーザー企業とベンダー企業の関係性

人材の枯渇や自社に十分なノウハウが蓄積されていないことから、既存システムの保守・運用についてベンダー企業に任せている企業は多いです。だからといって、DX推進を目的としたシステムの刷新もベンダー企業に一任すれば良いという訳ではありません。

ベンダー企業におけるビジネスモデルの傾向として、利益の見通しを立てやすい既存システムの保守・運用がメインとなっているのが現状です。一方で DX推進に向けたシステムの刷新は失敗のリスクが大きく収益性が不透明であるため、主体的に提案することが難しいとされています。

ビジネスモデルの転換

先述の通り、日本企業のIT費用の約8割は現行ビジネスの維持に充てられています。このような事情から、現在のベンダー企業は既存システムの保守・運用を主なビジネスモデルとしています。

情報サービス産業におけるビジネスモデルが現状のまま留まっていては、陳腐化によるビジネス規模の縮小は免れず競争力も失われていくとDXレポートにて言及されています。「2025年の崖」を超えるには、このビジネスモデルも転換させることが重要です。つまり、単にユーザー企業が提示する仕様に従って開発を行うだけのビジネスモデルを続けている場合ではありません。

もはや一企業の取り組みというレベルを超え、情報サービス産業全体の改革につながる問題が「2025年の崖」と言えます。

2025年の崖を克服するには?

既存のITシステムをしっかり把握する

DX推進に向けた取り組みを実施する前に、まずは既存のITシステムにおける現状を明確に把握する必要があります。ただしこれを現場に丸投げするのではなく、経営者自身がDXの必要性を認識したうえで既存システムの全体像を把握することが大切です。

経済産業省が「DX推進システムガイドライン」や「DX評価指標」を策定・提供しているため、これらを活用して自社のIT資産を分析・評価します。分析する中で、不要な機能は廃棄したり変更が必要な機能や新規機能は適宜クラウドへ追加するなど、機能別で刷新を進めていくことを検討しましょう。

なお、「DX推進システムガイドライン」では既存システムの分析・評価について以下のような例を挙げています。

・ IT 資産の現状を分析した結果、半分以上が業務上止めても問題のない利用されていないITシステムであり、これらについて廃棄する決断をした

・費用対効果等を考慮し、今後、更新があまり発生しないと見込まれる機能はその範囲を明らかにした上で、現状維持とすることもあるが、その場合でもデータ活用を阻害しないよう、他のシステムとの連携等に留意している

引用: https://www.meti.go.jp/policy/it_policy/dx/dx_guideline.pdf

明確な目標設定・経営ビジョンの策定

既存システムの分析結果を考慮しつつ、自社のDX推進状況を確認して目標や経営ビジョンを明確化させます。

DX推進は一部の部門だけでなく、全社で協力しながら進めていくことが必要になります。単に新しい技術を取り入れるのではなく、この技術を利用して既存のビジネスモデルや自社商品・サービスに変革をもたらすことがDX推進における真の目的です。それを踏まえると、経営者・従業員全体を巻き込んだ体制の構築が欠かせません。

全社的な取り組みを円滑に進めるには、「何のためにDXを推進するのか」「DX推進の先に見据えるビジョンとは」といったポイントを明確にしたうえで共有することが大切です。目標やビジョンが曖昧でシステムの刷新そのものが目的になると、DXにつながらない結果となり再レガシー化する恐れがあります。

ユーザー企業とベンダー企業の関係を改善する

既存システムの開発・運用・保守をメインに請け負ってきたベンダー企業にとって、DX推進を見据えた大規模なシステム刷新は大きなリスクを伴います。そのような事情の中、ただ丸投げするだけでは主体的な提案を受けることはできません。一度、契約関係のあり方を見直してベンダー企業側のリスクが軽減するよう取り組む必要もあります。

例えば「システム連携基盤の企画・要件定義はユーザー企業も率先して行う」、「プロフィットシェア(開発されたシステムによる利益の一部をベンダー企業へ還元する)が成立するような規定を設ける」、「トラブルの迅速な解決の実現や非公開性の担保を目的とした ADR(裁判外紛争解決手続)を活用する」などの取り組みです。

開発経験が豊富な業者とタッグを組んで開発を進める

DX推進は、ベンダー企業と二人三脚で取り組まなければ成し得ることはできません。自社の目標・ビジョンを実現するために足りない部分を依頼し、共に開発を行っていくことがベンダー企業との適切な付き合い方です。

しかし、ユーザー企業に対して現状までの経緯や社内事情といった領域へ踏み込むことにベンダー企業が躊躇するケースは失敗事例としてよくあります。この場合、発展性のある提案をすることに消極的となったベンダー企業は自社の意向に沿ったソリューション導入を推進しがちです。結果的に、DX推進を阻む問題解消において的を射ない取り組みが進んでしまい、ユーザー企業の描いた目標へ至る変革がもたらされない結果が予想できます。

「クライアントとベンダー」という域を超えた二人三脚の取り組みを実現するためにも、ユーザー企業は開発実績が豊富なパートナーを選ぶことが大切です。専門性の高さはもちろん、ユーザー企業が抱える問題の真意を理解し汲み取る姿勢のあるパートナーの力を借りることもDX推進への近道と言えます。

ハイブリッドテクノロジーズの提供サービス

ハイブリッドテクノロジーズは、高い品質管理のもと、アプリケーション開発、システム開発の設計、デザインなどの上流工程から開発、運用、保守に至る全ての工程をトータルでご提供することで、クライアント企業のデジタルトランスフォーメーション(DX)推進をサポートいたします。

お客様の要望に合わせて、アジャイル開発やウォーターフォール開発等の開発手法やラボ(ストック)型サービスや受託(フロー)型サービスを柔軟に組み合わせて対応させていただきます。

【アジャイル開発ご希望のお客様】
・アジャイル開発についてはこちら

【ウォーターフォール開発ご希望のお客様】
・ウォーターフォール開発についてはこちら

【ラボ(ストック)型開発サービスご希望のお客様】
・ラボ(ストック)型開発サービスについてはこちら

【受託(フロー)型開発サービスご希望のお客様】
・受託(フロー)型開発サービスについてはこちら

ハイブリッドテクノロジーズが選ばれる理由

01 ビジネス設計〜実装・保守までワンストップで提供できるサービス体制
既存サービスの変革や新規サービスを成功を導くための顧客体験発想による設計からプロジェクトをスタートし、MVP開発を通して顧客のビジネスグロースを一緒に共創していくサービスを提供します。

02 UCS(ユーザー中心設計)によるUI/UXデザイン
実際にそのサービスを使うユーザーを調査、分析しながら、人間中心設計を元にデザインを行なっていきます。

03 スピード感をもった開発体制の構築
要件定義で定めた機能の中から優先度の高い重要なものから、アジャイル・スクラム開発を用いて開発することでサービスインまでの期間を短縮。素早いリリースを実現し、機能の追加などのブラッシュアップを行います。
ベトナムにおける日系No1*1という知名度の高さと20,000人以上*2の候補者リスト*2を元に必要な人員リソースの確保が可能なため、スピード感をもった開発の実行が可能です。

04 累計290社の顧客のプロダクト開発実績
当社が創業以来、豊富なシステム開発・アプリ制作の実績があり、それらを通じて蓄積した知見やノウハウを持ち合わせています。企画段階から要件定義・デザイン・開発まで担当し、プロジェクトを成功に導きます。

05 低コストかつ自由度の高い開発
フルスクラッチ開発とパッケージ開発のいいところどりを実現。 フルスクラッチ開発だとコストが上がる傾向にありますが、当社はベトナムのリソースを活用することでコストを抑えられます。
また、パッケージ開発だと自由度が失われる傾向がありますが、当社はスクラッチ開発で顧客予算に合わせて、スコープを見定めながら、進めることができるので、低コストで自由度の高い開発が実現できます。

06 国際標準規格に則った品質管理体制
情報セキュリティマネジメントシステムの国際規格「ISO9001」、「ISMS(ISO/IEC270001)」、ソフトウェア・テストの国際規「ISTQB Platinum Partner」の認証を取得しており、国際標準規格に則った品質管理体制を提供しています。

  1. 株式会社マイナビが運営するベトナムITエンジニア専門の求人サイトITviecは、給与・教育・マネージメント・企業文化・オフィス環境の観点から、Best Companyを選定。Hbrid technologies Vietnam Co., Ltdは、2019年と2020年に、日系企業で最高位に選出されました。
  2. 過去の当社へ応募頂いた開発候補者のリストです。応募のタイミングでリクルートシステムに登録し、常にそのリストから候補者へのリサーチできる体制を持っています。

システム開発の成功事例

システム開発での成功事例をご紹介します。

見守りサービス (株式会社otta)

詳しい情報は開発実績ページへ

サービス内容

位置情報履歴を、無料スマホアプリやメールを通じて保護者様に伝えるサービス

サービス上の課題/目指したいサービス

課題
共働き世帯や高齢者の増加など、社会構造の変化により、子どもや高齢者の見守りへのニーズが急速に高まっている。一方で、見守る方々の高齢化や地域コミュニティの変化により担い手は減少方向にあり、この需給ギャップを埋めるには、見守りの仕組みの生産性を大幅に向上させなければならない。

目指したいサービス
IoTを活用した見守りサービスのパイオニア企業として、見守り活動の生産性の飛躍的な向上に貢献するとともに、従来のサービスでは困難であった、多くの方々にご利用いただける料金体系を目指すこと。

クライアントの課題/要望

・追加開発体制のリソースが不足している
・既存ベンダーの開発チームと組み合わせながら、チームを構築したい
・事業状況に応じて柔軟にリソースを調整したい

当社を選択していただいた理由

キャピタル案件であり、HTからの投資次第で開発も頼みたいという理由から

当社ご提案内容

業界ラボ型(ストック)開発+保守にて提案
toB向け見守り管理システム開発
・今後の基盤変更も意識しながら登園バス管理システムの管理画面を作成し、サービス展開をしていきたい
・今後の開発体制構築も視野に入れつつまずはスモールに体制を構築しつつ今後の足掛かりとしたい
リソース活用し柔軟に対応できることと、javaを中心に進めていたが、よりモダンな言語を基盤に開発を進めたいという要望に対し、得意分野であった。

学習履歴データの可視化システム(放送大学学園)

詳しい情報は開発実績ページへ

サービス内容

学習履歴データ可視化システムの開発

サービス上の課題/目指したいサービス

課題
オンライン授業システムのデータベースには多量の学習履歴データが蓄積されており、このデータを学内の担当者が活用できるよう整備し、学生指導のためのヒントとして、あるいは学生に受講を促すための情報源として活用したいという意向があった。

目指したいサービス
・学外に開示する「サービス」ではなく、学内担当者用の「ツール」であること
・コマンドラインで操作可能なツールであること
・追加機能の実装をできるようにすること

クライアントの課題/要望

・社内で開発体制を保持していないこと
・金額をミニマムに抑えながら安定的な運用を実現したい

当社を選択していただいた理由

充分に仕様を満たす提案内容と他社と比較して最も安価な金額で入札提示したため。

当社ご提案内容

学習履歴データベースとBIツールの開発
オンライン授業システムのデータベースに蓄積された学習履歴データを活用するにあたって、実運用されているDBの処理とバッティングしないように、MongoDBに格納する処理にて開発を進めました。またMongoDBにデータを格納する際、他データとの連携も考慮し、汎用的なExperienceAPIに準拠したデータ形式を採用しました。
個人情報の扱いにおいては、開発人員含め、学生の個人情報の漏洩を防ぐため、学生の識別子を匿名化しての実装を実施しました。

DocIT (株式会社ドキットメディカルサービス)

詳しい情報は開発実績ページへ

サービス内容

働き口を探す医療従事者と、働き手を求める病院をつなぐマッチングプラットフォーム

サービス上の課題/目指したいサービス

課題
高額な紹介料がネックとなりスポットで人が必要な際に苦心をする病院の課題解決

目指したいサービス
休日や長期出張の空き時間を有効活用したい医師と、長期連休などで一時的に人手が必要となる病院をマッチングすることで医師の働き方の多様化を実現するサービス

クライアントの課題/要望

・サービス構想はあるが、実現させる開発パートナーが必要
・上流工程からの開発サポートが必要

当社を選択していただいた理由

開発にあたってサービス設計から本開発まで、一緒に伴走し考えながら開発してくれるパートナーとして安心感を感じて頂き、当社を選ばれました。

当社ご提案内容

ラボ型(ストック)開発にて提案
1.医療求人の性質を鑑みた機能提案、システム設計・開発

本サービスでは失敗の許されない医療系求人を取り扱うため、求人マッチングをする前に信頼のできる医師・病院であることを確認できることが重要となります。 そこで、実際に求人マッチングした医師・病院による相互レビュー機能を実装することで、信憑性の高いレビュー情報を蓄積することを提案・実現しました。 また、求人マッチング前に病院担当者と直接チャット出来る機能も実装することでレビューでは分からない定性的な情報確認も可能としました。 アジャイルスクラム手法の開発を取り入れることにより、システム開発の進捗報告を実際に動くシステム画面をお見せしながらデモンストレーション形式で毎週行いました。

2.定期的なスプリントを繰り返し、顧客と一緒に品質を高めるプロセスにて進行

実際に動くシステムを毎週見ていただくことで、開発進捗についての安心感やお客様も気がついていなかった新たな改善点がを発見でき、それを修正して再度デモンストレーションを行いました。この一連の流れを回すことで、お客様の求めるものを高い品質でご提供しました。

3.デザインを用いた視覚的なアウトプットで、具体的なシステムイメージを共有

Webサービス開発に初めて挑戦するお客様のため、お客様が思い描くビジネスを実現するためのシステムイメージを具体化していくデザインサポートも担当。求人情報サービスという特性上、さまざまな情報要素が混在する中で、目に見える形でデザインを整理・提案し、お客様からのフィードバックを受け、再提案を繰り返すことで、よりユーザーにとっての最適なWebサービスのための設計・提案・実現を行いました。

THINK, Reviewers (株式会社スパイス ボックス)

https://www.spicebox.co.jp/

詳しい情報は開発実績ページへ

サービス内容

独自の「ソーシャルリスニング」手法をもって、企業と生活者の 間に生きたコミュニケーションを構築するサービス

サービス上の課題/目指したいサービス

課題
インフルエンサーの評価指標としてフォロワー数とエンゲージメント数が重要視されているケースが多いが、商品販売施策においては保存数が重視される。保存数を把握した上でインフルエンサーと企業のマッチングを行うプラットフォームが存在していなかったため、新たなサービスとしてスピード感を持ってサービス開発を行いたい。

目指したいサービス
・サービス名「THINK」:Twitter調査における既存システムの安定的かつ継続的な運用を維持しつつ、インフラコストを削減すること。
・サービス名「Reviewers」:インフルエンサーマーケティングで投稿保存数という指標を重要視するインフルエンサーマッチングプラットフォームの新規立ち上げをすること。

クライアントの課題/要望

・開発が発生した際に、都度RubyonRailsの対応人員を増やすのが難しい
・インフラ周りに強いメンバーがいない
・金額をミニマムに抑えながら安定的な運用を実現したい
・追加開発が発生した場合には、知見を維持した状態で取り組める体制がほしい

当社を選択していただいた理由

・開発リソースの柔軟性とインフラなど対応範囲の幅広さが先方ニーズにマッチしていたこと
・定常運用の際にもコストを抑えて対応できること

当社ご提案内容

受託型開発(フロー)にて提案
インフラ知見を持つディレクション人材をアサインメントすることで、インフラ周りの調整や業務対応にスピード感を持って対応できる体制を構築
インフラ/保守/開発を幅広く対応可能、かつ、コストミニマイズなオフショア体制をご提案しました。
ディレクション人材がインフラの知見を持ち、定常作業はベトナム側で行えるようにマニュアル化を行い、コストミニマイズしながらも幅広い知見を活かせる体制提案を行いました。 新規の開発が発生した際に、既存チームの知見を活かしながら適宜開発者を追加して、素早く開発を実行できる体制を実現しました。

その他のアプリ開発事例

ハイブリッドテクノロジーズでは、その他にもモバイルアプリや業務用アプリケーションまで、多種多様な290社以上の制作実績がございます。
アプリ開発をご検討の方はぜひ一度お問い合わせください。

まとめ

「2025年の崖」とは、経済産業省がDXの必要性について訴える「DXレポート」内で使われた言葉です。日本企業のDX推進状況は世界と比べて未だ後れを取っている状況であり、このままでは2025年より莫大な経済損失が発生すると問題視されています。DX推進を阻む大きな要因「レガシーシステム」から脱却できずにいる場合は、明確なビジョンをもって現状を把握することから始め、必要な工程に着実に取り組んでいきましょう。自社の目標・ビジョンの実現をより確実なものとするため、豊富な開発実績と高い専門性を備えたベンダー企業の力を借りることも大切です。

FacebookTwitter

キーワード

開発 Ed-tech クライアント AI DX推進 オフショア アプリ開発 システム開発 スクラム開発 アジャイル開発 オフショア開発 イテレーション アジャイル スプリント 受託開発 オフショア 実績 デジタルリテラシー DX レポート ハイブリッド開発 Intern 企画書 仕様書 スクラッチ開発 uiデザイン UXデザイン 構築違い AI開発 AWS開発 スパイラル開発 ECサイト構築 プロトタイプ MVP開発 採用コスト エンジニア サプライチェーン開発 リプレイス DX ウォーターフォール開発 受託開発 UX・UI 資金調達 CVC ソフトウェア Android 予約システム 依頼 IOS開発 スマホアプリ開発 投資 投資実績 WMS 開発事例 メタバース アバター 暗号資産開発 プログラム devops データ分析 ビッグデータ 新規事業開発 ヘルスケアテック セキュリティ IoT メディカルテック 薬局DX SaaS レセコン 業務改善 ビジネスモデルキャンバス PWA 防犯DX アノテーション 画像認識 スマートシティ BLE flutterとは 内製化とは サービスデザイン Rails CtoCプラットフォーム ラボ 脆弱性診断 プロトタイピング 機械学習 新規事業開発支援 UX/UI 大学初ベンチャー クラウドファンディング アバター #新規事業開発支援 Web3.0 レジャーサブスク トラベル 生成AI 画像生成 映像生成 Generative AI フィンテック 債権保証

人気記事

ノウハウ 開発事例 開発形態(エリア・契約)
2022.03.29

受託とは?委託や請負との違いについて解説

受託とは?委託や請負との違いについて解説

#開発 #アプリ開発 #システム開発 #受託開発

アプリ・システム開発 ノウハウ
2023.01.12

アプリ開発における仕様書の概要と種類とは?要求書を書くときのポイントを解説

アプリ開発における仕様書の概要と種類とは?要求書を書くときのポイントを解説

#アプリ開発 #システム開発 #仕様書 #ウォーターフォール開発

アプリ・システム開発 ノウハウ
2022.12.21

システム開発を担当するベンダーとは?ベンダーの種類とシステム開発を依頼するときのポイントを徹底解説

システム開発を担当するベンダーとは?ベンダーの種類とシステム開発を依頼するときのポイントを徹底解説

#システム開発

アプリ・システム開発 ノウハウ
2022.08.30

ソフトウェア・システムの「開発」「運用」「保守」の3つの仕事内容とは

ソフトウェア・システムの「開発」「運用」「保守」の3つの仕事内容とは

#システム開発

ノウハウ 資金調達
2022.08.30

VC(ベンチャーキャピタル)ファンドとは?ファンドとの違いも解説

VC(ベンチャーキャピタル)ファンドとは?ファンドとの違いも解説

#仕様書 #資金調達 #CVC

ノウハウ 資金調達
2022.08.04

CVCとVCの違いとは?成果の違いや現状と課題について解説!

CVCとVCの違いとは?成果の違いや現状と課題について解説!

#資金調達 #CVC

ノウハウ 資金調達
2022.08.19

CVC(コーポレート・ベンチャー・キャピタル)とは?メリット・デメリットを解説

CVC(コーポレート・ベンチャー・キャピタル)とは?メリット・デメリットを解説

#資金調達 #CVC

ノウハウ
2023.03.19

ビジネスモデルキャンバスとは?基本の構成要素、作成のポイントを解説

ビジネスモデルキャンバスとは?基本の構成要素、作成のポイントを解説

#ビジネスモデルキャンバス

ノウハウ 開発事例 開発手法
2022.03.02

アジャイル開発におけるスプリントとは?メリット・デメリット・実行フローを徹底解説

アジャイル開発におけるスプリントとは?メリット・デメリット・実行フローを徹底解説

#アジャイル開発 #アジャイル スプリント

アプリ・システム開発 ノウハウ
2022.12.21

システム開発における請負契約とは?準委任契約との違いとメリット・デメリットを解説

システム開発における請負契約とは?準委任契約との違いとメリット・デメリットを解説

#システム開発

新着記事

ノウハウ 投資実績 資金調達 開発事例
2023.09.11

Hybrid Technologies Capital 実績:H.I.F.様

Hybrid Technologies Capital 実績:H.I.F.様

#クライアント #資金調達 #CVC #開発事例 #新規事業開発支援 #UX/UI #フィンテック #債権保証

ノウハウ 投資実績 資金調達 開発事例
2023.09.05

Hybrid Technologies Capital 実績: EmbodyMe様

Hybrid Technologies Capital 実績: EmbodyMe様

#クライアント #資金調達 #CVC #開発事例 #生成AI #画像生成 #映像生成 #Generative AI

ノウハウ 投資実績 資金調達 開発事例
2023.07.06

Hybrid Technologies Capital 実績: ORIGRESS PARKS様

Hybrid Technologies Capital 実績: ORIGRESS PARKS様

#クライアント #資金調達 #CVC #開発事例 #新規事業開発支援 #UX/UI #レジャーサブスク #トラベル

ノウハウ 投資実績 資金調達 開発事例
2023.06.21

Hybrid Technologies Capital 実績: ビジュアライズ様

Hybrid Technologies Capital 実績: ビジュアライズ様

#クライアント #資金調達 #CVC #開発事例 #メタバース #UX/UI #クラウドファンディング #アバター #新規事業開発支援 #Web3.0

ノウハウ 投資実績 資金調達 開発事例
2023.04.28

Hybrid Technologies Capital 実績:Blue Practice様

Hybrid Technologies Capital 実績:Blue Practice様

#クライアント #AI #資金調達 #CVC #開発事例 #メディカルテック #機械学習 #新規事業開発支援 #UX/UI #大学初ベンチャー

ノウハウ
2023.04.26

プロトタイピングとは?重要性や具体的な手法、注意点を解説

プロトタイピングとは?重要性や具体的な手法、注意点を解説

#プロトタイピング

ノウハウ
2023.04.25

脆弱性診断(セキュリティ診断)とは?必要性、種類、進め方を徹底解説

脆弱性診断(セキュリティ診断)とは?必要性、種類、進め方を徹底解説

#セキュリティ #脆弱性診断

ノウハウ 投資実績 資金調達 開発事例
2023.04.14

Hybrid Technologies Capital 実績: アジアンブリッジ様

Hybrid Technologies Capital 実績: アジアンブリッジ様

#クライアント #資金調達 #CVC #開発事例 #ラボ

ノウハウ 投資実績 資金調達 開発事例
2023.04.12

Hybrid Technologies Capital 実績: ジラフ様

Hybrid Technologies Capital 実績: ジラフ様

#クライアント #資金調達 #CVC #開発事例 #Rails #CtoCプラットフォーム #ラボ

ノウハウ
2023.04.10

アジャイル開発とは?概要やメリット・デメリット、進め方を解説

アジャイル開発とは?概要やメリット・デメリット、進め方を解説

#アジャイル開発
Scroll top page