会社が無くなったらどうなる?サービスが終了したらどうなる?

>

いくつのアプリやサービスを併用しているか。

皆さんは、現在いくつのアプリを利用していますか。

複数のアプリを使っていることでしょう。

先日、GoogleからGoogleMusicというアプリをサービス終了する告知がありました。

GAFAのうちの1つである巨大企業Googleでもサービスを終了することはあります。

(Googleとしては、YouTube Musicがあるので、同じようなアプリを開発する必要はないという事かもしれませんが、ここではサービス終了について考えます。)

個人的に利用しているアプリであれば代わりのアプリを探せばよいかもしれません。

では、個人的にではなく、仕事で使っているアプリやサービスが終了した場合、どうなるのでしょうか。

どこまで業務効率が落ちるのでしょうか。

現在、複数のビジネスツール(SaaSなどのクラウドサービス)を併用しているユーザーが多いという事実があります。

あなたは、いくつのビジネスツールを使っていますか。

サービス終了したらどうなる?

利用しているアプリやサービスが終了すると予告された場合にどうするかってことについて考えてみます。

アプリなどのサービスが終了する場合には、一般的には数ヶ月から1年前にサービスを終了する告知があります。

個人的に使うアプリであれば、サービス終了の時期に合わせて別のアプリを使えば解決するかもしれませんし、そもそもアプリを使わなくなってもそれほど大きなリスクが無いケースもあるでしょう。

しかし、企業が組織的にサービスを利用しており、そのサービスによって売り上げに影響がある場合、代替案を考える必要があります。

似たようなサービスが、ほぼ同じくらいのコストで利用できるのであれば移行できそうですが、似たようなサービスがなく(パッケージソフトでは対応できず)新たにシステム開発を行わなければならない場合、それにかかるコストと期間が心配ですよね。

そのような状況の対策として、4つの案をまとめてみました。

それでは行ってみましょう。

サービスが終了した場合を想定した4つの対策案

システム開発会社に新規開発を依頼する
同じようなパッケージソフトを探す
とりあえずExcelでできることを準備する
システムを内製化しておく

1.システム開発会社に新規開発を依頼する

現状のシステムと同じようなシステムをシステム開発会社に開発依頼する方法です。

この方法には、時間とコストがかかるわけですが、それ以外にも考えることがあります。

そもそもそれをどう伝えるかです。

口頭で仕組みを伝えますか。資料を作成しますか。

エンジニアは、もともと使っていたシステム画面を見れば、業務内容を理解し、リバースエンジニアリングすることができます。

リバースエンジニアリングとは、システムがどのように作られているのか構造を解析することです。

プログラムコードを見て解析することもありますが、他の人が作ったシステムの場合、ソースコードはオープンでないケースがほとんどです。

その場合は、システム画面や管理資料を見て解析します。

解析することができれば、同じようなシステムを作ることができます。

(ここでは、特許や著作権についての話は省きます。)

このようにサービスが終了した場合でも、エンジニアに利用していたシステムを見せれば、それに代わるシステムを開発依頼することができます。

使っていたツールのボリュームにもよりますが、解析し、設計し、初めから作り直すことを考えると比較的コストがかかる方法といえるでしょう。

弊社のシステムは、引継ぎが起こることも想定し、提供しているパッケージソフトと受託開発したシステムのどちらもデータテーブルをオープンにし、ユーザー数の多い開発ツールを使って作られています。

つまり、解析できるエンジニアが多い点は安心できるということです。※ソースコードはオープンではありません。

開発コストと開発期間はエンジニアによりますが、できるだけ引継ぎができるようにと考えられています。

開発を行う上でもあらゆる工数を削減し、コストを抑えて成果を維持するシステムを提供するよう努めています。

2.同じようなパッケージソフトを探す

使っているサービスと同じことができそうなパッケージソフトを探しておくことです。

パッケージソフトは、仕様が決まっている点とユーザー数が多い点から比較的コストを抑えることができます。

ただし、業務では常に改善を求め、業務効率を上げていこうとするため、どこまでカスタマイズができるのかを確認することをおすすめします。

またカスタマイズの費用感も想定しておくと良いでしょう。

パッケージソフトを使うんだから、カスタマイズは行わない。ユーザーが業務を仕様に合わせるんだと決めてしまうのもアリです。

業務効率が上がっていくことをあきらめる代わりに低コストを見込めます。

これについては、日頃から準備をしておくことができます。

現在使っているシステムの機能をカバーしているかを確認しておくと良いでしょう。

ただし、全く同じ仕様のパッケージソフトは無いです。

また、違うツールであれば操作性も変わります。

移行はそう簡単ではないかもしれません。

移行に時間がかかれば、業務がストップしてしまうリスクや経費など様々な損失を想定できます。

せめて、システム引越し(データ移設)の際に、エクスポート・インポートができるかを確認しておくとよいでしょう。

最低限データをエクスポートすることができていれば、それを活用し、別のツールにインポートできることが多いです。

構造化データを構築できる技術的な知識が必要になるので、エンジニアに移行を依頼するのも良いでしょう。

弊社のシステムは、データエクスポートできます。

3.とりあえずExcelでできることを準備する

これはコストを抑えた方法です。

Excelであれば、まず環境が整っていることが多く、それを扱えるユーザーも比較的多いです。

しかし、システムを利用していた頃より、業務効率は落ちると思います。

そもそも、管理できないケースもあるでしょう。

業務がストップしないような方法を事前に確認しておけば、最低限その場をしのげるでしょう。

その間に移行について考えることができます。

弊社のシステムは、もともとExcelで開発されていたり、Excelと連携しているのでExcelと相性が良いです。

4.システムを内製化しておく

そもそもシステムを社内で開発していれば、会社が無くなった場合の事を考える必要はありません。

その時にはシステムを利用する必要もないはずです。

ただし、社内でシステムを作った場合は、システム開発の担当者がいなくなった時の事を考えておく必要があります。

別のエンジニアをすぐに雇えるのか。システムを把握しているメンバーを常時何人確保しておくのか。

外部のエンジニアに依頼するとしたら、開発費の予算はどれくらいなのか。

どうやって伝えるのか、開発期間はどれくらいかを想定しておく方が良いでしょう。

システムには寿命が無いので、現状の機能であれば永遠に動作すると考えるのは間違いです。

数ヶ月~数年単位で、OSのアップデートなどの環境変化によるエラーやバグの発生が考えられます。つまり、メンテナンスが必要になります。

社内のエンジニア(その役割をする人)は、引継ぎの事を考えてコードの整理など伝わり易いように作っているでしょうか。

解析しにくい状態で作られている場合、引継ぎのエンジニアは初めから作り直すという方法を選択することが多いでしょう。

絵を描くときに他人の絵を真似て描くことはあっても、その絵に付け加えないですよね?それと同じです。真似るにしてもまっさらなキャンパスから書き始める方がやり易いはずです。

エンジニアは、自分が得意なツールを使います。他人が書いたコードは整理しづらいです。
(オープンソースが前提のシステムの場合は加工しやすいかもしれませんが、それはまた別の話としてここでは省きます。)

初めから作り直すことは、工数に影響しそのままコストに繋がります。

弊社サービスの「不安な要素」と「安心できる要素」

上にまとめた4つの案のようにサービス終了時の対策として、いくつかの方法があるわけですが、弊社サービスは引き継ぎの事を想定し設計されています。

とはいえ、全てのサービスが100%安心できるとは言い切れません。

そこで、弊社サービスの不安な要素と安心できる要素を考えてみます。

■不安要素
Excelがサービス終了した際は、対応不能。

弊社サービスは、Excelと関わっているアプリがほとんどですので、Excelが無くなった時には弊社サービスも終了します。

MicrosoftのExcelがサービス終了することまではカバ―できませんし、想定しません。ごめんなさい。

ただ、その頃には今では想像できないくらい便利になっているか、それに代わる便利なサービスがあると思います。

それに、データを別の形式、例えばCSVなどで保存できれば、移設できるはずです。

そんなことがあったとしても、かなり先の話だと思いますのでこれ以上想定しません。

■安心要素
Microsoftのツールを使って開発することにより、技術者が豊富、情報量が豊富というメリットがあります。

同じ状況でも比較的引継ぎができるエンジニアを探しやすいでしょう。
もちろん、冒頭のようにリバースエンジニアリングを行えば、他の言語やツールでも同じような構造のシステムは再現できるはずです。

たとえサービスが終了しても、プログラムは死にません。動作環境が同じであれば、永遠に動作します。
※プログラムに命はないので、現状と同じ仕様と環境であれば永続的に動作するという意味です。

ただし、問題はあります。

環境の自動アップデートです。OSであれば、WindowsOSの更新やOfficeの自動更新です。

更新自体は、環境を改善するためのものです。更新を止めることは、セキュリティ面などから本末転倒です。
(ここでは、サービスが終了した場合の話をしています。)

数ヶ月~数年単位で、OS環境のアップデートなど環境の変化によるメンテナンスが必要になります。

ExcelなどOffice製品は、自動アップデートによる不具合が発生する話もありますが、WindowsOS、iOS、ブラウザなどあらゆる環境にもアップデートがあります。

自動更新がONになっていれば、予期しないタイミングで更新されます。

環境のアップデートによるアプリのエラーは、どんなアプリでも起こりうる問題です。

アプリが動作するのはそれに合わせて迅速にアプリが更新されているからです。

そのようなことを考慮した時、むしろExcelはWindowsOSもOfficeも同じMicrosoftにより提供されているツールなので、環境の変化によるエラーやバグが起こりにくい方です。

万が一、サービスが終了し、アプリのアップデートが行われないことが確定したら、

更新をオフにし環境を変えない。
動作する環境をPC1台でもキープする。
引き継げるエンジニアを探す。
データをエクスポートしておく。(CSVなど)

というように、引継ぎの期間を延長できるよう対応することをおすすめします。

万が一の時の対策

どんなサービスもサービス終了の可能性は0ではありません。

全てのツールで同じ問題を抱えています。

もちろんか組織の規模により、サービス終了するリスクには差はありますが、

そのような状況に直面した場合に、どうやって別のサービスに移行するかが問題であり、それについては常に考えておく方が良いです。

一般的には、別のシステム開発会社や技術者に相談する方法で問題ないと思いますが、それにはコストがかかります。

最も優先すべきは、業務が止まらないことです。
移行期間に業務が止まってしまうことは、移行するコストよりも大きな問題です。

つまり、システムが現状維持で動作している期間に次の技術者やサービスを探すことです。
資金を蓄えておけば、コストをかければ必ず方法はあるのでそれが最も安心です。

問題は、移設するための開発資金がない場合です。
それはそもそも利用側の問題であり、サービス提供側の問題ではない気がしますが、弊社はその場合についても考慮しておきます。

■弊社都合により、サービスが終了する場合
現在ご利用いただいている弊社のパッケージソフトやシステムで終了する予定のサービスはございませんが、ここでのテーマですので、2つの安心保障について記載します。

◎弊社都合によるサービス終了を告知する場合、1年分の価格で永続ライセンスを販売します。
※ただし、サービス終了後のサポートはありません。動作するのは、サービス終了前のPC環境です。環境の変化による動作は保証しません。

◎データファイルオープン。データファイルは、ExcelファイルかAccessファイルであり、そのデータはオープンです。技術者であれば、そのファイルを見れば移行する案を提示できるはずです。
※ソースオープンではありません。データをエクスポートできるという意味です。

まとめ

どんなシステムでも引継ぎを想定した方が良い。

新規開発できる予算を蓄えておくか、引き継げるサービスを探しておくと良い。

弊社ツールは万が一サービスが終了するケースを想定し設計されている。

紹介

最後にこのサイトにあるツールを一つ紹介させていただきます。

「セールスAppKATA」は進捗管理から販売管理までを行えるシンプルなオールインワンのソフトです。

見込み案件から請求管理までを行えます。

業務に必要最低限の機能に絞り、わかりやすく、ユーザーのカスタマイズ性を追求して開発されており、実務での改善意見を取り入れつつバージョンアップしています。

ユーザー数の多いExcelと技術者の多いAccessを利用して開発されています。

By