司馬紅太郎（しば こうたろう）
大手IT会社に所属するPM兼SE兼何でも屋。趣味で執筆も行う。
代表作は「空想プロジェクトマネジメント読本」（技術評論社、2005年）、「ニッポンエンジニア転職図鑑』（幻冬舎メディアコンサルティング、2009年）など。2019年発売した「ＩＴ業界の病理学」（技術評論社）は2019年11月にAmazonでカテゴリー別ランキング3部門1位、総合150位まで獲得した迷書。
サービス終了(サ終)について話しましょう
「サービス終了」、嫌なひびきの言葉です。でも、それがないと新しいサービスのための要員が足りなくなります。そして、日常的に「サービス終了」は存在しています。みんなが所持している（いた）携帯電話の3G回線のサービス終了、スマホで楽しんでいたゲームのサービス終了、近くの銀行の一部サービス終了など。いつのまにか消えてしまって、「サ終か？」と騒がれ、また復活した某ファストフードのスマイル0円サービス(*1)。
<図表19-1 auの3Gサービス終了案内>
このように「サービス終了（サ終）」は日常にあります。しかし、IT業界にとっては、かなり重要なターニングポイントとなることが多いです。
ゲーム界でのサービス終了は日常です
「サービス終了」で検索してみると、まずスマホのゲーム終了がヒットします。それくらい、ソーシャルゲームやオンラインゲーム、アプリでのサービス終了が多いということなのですが。ソーシャルゲームの特性(*2)上、確実にサービス終了はあります。というより、長く続くゲームはほんの一握り。ゲームを開始したタイミングから、カウントダウンが始まっているのです。
しかし、自称コアなユーザーやゲーム依存症なユーザーには納得できないことみたいです。
「なんでやっていないんだ？」「終わって悲しい。ロスです」「運営は無能。継続に努力しろ」などの悲鳴や怒号が、ほんの一部だけ上がってきます。
ゲーム系であれば、どこかに「状況によりサービスを終了することがございます」的な文言は確実に書いてありますし、「ユーザ満足を考えろ」っていっても、一杯100円のコーヒーで粘る客みたいなユーザーは、ロイヤル顧客(*3)ではありません。場所を取っていて邪魔なだけです。熱意とサービス継続のためのコストは、決して比例しないんですよ。さっさと新しいゲームに投資しましょう。
システム保守・運用にとってのサービス終了
さて、次にエンタープライズ系、つまり企業システムです。システムを保守・運用する立場、システムを開発する立場にとってよくあるサービス終了といえば、EOS(End Of Sales, End Of Support)とかEOL(End Of Life)です。「製品がEOSだから、システム更改したい」と顧客に言われるケースが多々あります。特に、ハードウェアやパッケージが多い(*4)でしょうか。
<図表19-2 EOXの種類>
販売終了し、そのあとサービス（保守や修理交換）も終了という流れです。
ふと考えると、システムに使っているパッケージやソリューションも、ゲームと同様に完成したタイミングから、時代遅れになる可能性が高いといえるかもしれません。トランザクション量の増加、トランザクション自体のサイズ重化、厳しくなるレスポンスタイム要求、ヘビーになっていくUI、度重なる機能追加に、絶対対応しなくてはいけない法制度の変更対応(*5)など。これらに対応するために、ガンガン修正やらメモリ追加やらをかけていきます。でも、本体自体がその改造に耐えきれるかどうかはわかりません。「拡張性高いですよ～」と言われても限界があります。
また、メーカーでも何年も同じスペックの製品を売っていたら、売上げは右下がりになります。常に新製品を販売し続けることが必要です。やはりソシャゲーと同じですね。新製品発売と同時にカウントダウンかもしれません。
さて、このような契機で発生するEOSに対する対策ですが、販売終了前にその製品を別の製品に切り替えるのがベストです。でも実際には、切り替えるだけでは済まず、載っているシステムにも手を入れる必要があります。実例として、EOS対策としてシステム更改を行ったが、保守終了までに間に合わず、ベンダーに個別延長をお願いする、というケースも本当に多くみられます。なぜか、ユーザーって、ギリギリまで切り替えずになんとかしようとあがきますから、無駄なんですが。
激震、富士通のメインフレーム撤退
2022年2月に報道されたニュース、富士通が2030年度（2031年3月期）末にメインフレームの製造・販売から撤退。さらに、UNIXサーバーも2029年度下期に製造・販売を終了。
【参考】日経XTECHの記事 富士通がメインフレーム製造・販売から2030年度に完全撤退へ、66年の歴史に幕
（https://xtech.nikkei.com/atcl/nxt/column/18/00001/06546/）
この報道は、富士通製品を使用している企業にとって大事件。いままでメインフレームでしっかり稼働させてきた基幹なシステム。時には、メインフレーム上の古いOSを新しいOSにしたり、部分的に外部システムに出したりなどの手を使い、レガシーな資産をだましだましつかってきました。それが、ハコ自体が販売終了。
富士通のメインフレームは、2021年の国内出荷台数1位です。46.7%です。約半分です。メインフレームの主な納入先は、有名なところですと、銀行を中心とする金融業界です。まさか、Mの悲劇(*6)が始まるのでしょうか？
＜図表19-3 国内メインフレーム2021年出荷台数シェア 富士通HPから＞
(https://www.fujitsu.com/jp/products/computing/servers/mainframe/gs21/topics/achievements.html)
完全撤退は2030年期末ですから、まだ10年弱あります。勝手な予想なのですが、たぶんクラウドの上に旧レガシー資産が動くミドルウェアが発売されます。そもそも、古いレガシーなコードを切り捨てて新しく組みなおしなんて、まずコストと時間、さらに旧システムのノウハウが、かなりかかります。そんなに、金も時間も、優秀なエンジニアもいません。なので、そっちの方向に舵を切る動き(*7)が確実に発生します。「メインフレーム疑似な環境 on クラウド」は発売されるでしょうが、その試みが成功するかどうかは未定であり、もし導入したとしても、現行機との並行運転(*8)や試行期間もそれなりに必要です。
あ、でも2016年4月頃話題になった例の富士通を退職した意識高い系学生(*9)のようなパターンはなくなるのが富士通にとってメリットでしょうか。
サービス終了のための段取り
このような「サービス終了」アクションを行うにあたって、そのサービス提供側では、どんな準備をしなくてはいけないのでしょうか？
- ・サービス終了の告知
- ・必要な場合は、お役所系への届け出
- ・上記の問い合わせ対応
- ・並行して、サ終のための各種準備
- ・・止める/無くす作業の洗い出し
- ・・残す必要なタスクの切り替え
- ・・要員異動準備や引継ぎ
- ・・ノウハウやログの記録
- ・・念のため各種のバックアップ
- ・サービス終了のリハーサル
- ・サービス終了実施
- ・収支の予実策定（アフター対応の見込み含）
- ・アフター対応（主に問い合わせ対応）
のような感じでしょうか？ さくっと電源落として終了とならないところが面倒です。サービスというものを終了するアクションですから、面倒でも仕方ないといえます。でも、だらだらと続く維持作業と維持費を考えると、サービス終了は必要なものでもあります。始まりがあれば、終わりがある。諸行無常なIT業界です。
では良き眠りを（合掌）。
「朝寝は時間の出費である。しかも、これほど高価な出費は他にない」 by アンドリュー・カーネギー
商標について
本コラムに記載されている商品やサービスの名称は、関係各社の商標または商標登録です。文中では、(TM)や(R)を省略しているものもあります。
引用・参照について
本コラムで引用・参照した図表や文章については、明示して引用元・参照元を記載しております。
著作権・免責について
本コラムの著作権は、著作者に帰属します。本コラムは著者の主観に基づく情報の提供のみを目的としており、本コラムに記載された内容を用いた運用などは、読者の責任と判断においておこなってください。また、記載内容は、執筆時のものを使用しております。
*1 McDonald’s Corporation及びその関係会社の登録商標として、スマイル0円は登録されています。
*2 ソーシャルゲームの特性、始まったと同時に終了へのカウントダウンが始まります。ユーザー数が減り始め、いろいろなキャンペーンで微増するが、また減り始める。そこをうまくごまかしつつ、初期投資を回収できれば、さっさと撤退というビジネスモデルです。最初の企画の段階から、初期投資、維持費、想定ユーザー数、ユーザー減少割合、撤退時期などは見込んでいます。これが、上振れすればラッキー、下振れすれば最低限のテコ入れ(*10)をして、場合によっては損切りするしかありません。維持費 ＞ 収入は相当まずいですから。
*3 ロイヤル顧客（カスタマー）とは、以下の3点を持つ顧客という説があります。
・繰り返し製品やサービスを購入してくれる（無課金ではない）
・競合製品に流れない（浮気はダメ）
・第三者に製品やサービスをすすめてくれる（ユーザー増加効果持ち）
さて、あなたはロイヤル顧客なのかな？
*4 SAPの2025年問題もEOSが起因です。2025年問題というのは、「SAP ERP」の保守期限が2025年に切れること。2020年2月4日、欧州SAPが「SAP ERP」の保守期限を「2025年末から2027年末へ変更する」と発表し、実質2年間の延長になりましたが、問題自体は変わりません。2027年までに、切り替えるかどうかの判断、ではなく切り替えないとかなり困ったことになります。「第五夜 DXレポートで悩む管理者の夜」でもこの問題を記載しています。
*5 法制度対応。例えば、消費税とか所得税などの税制変更や個人情報保護法、電子帳簿保存法も改正されました。計算方法などが変われば、対応するパッケージに修正を入れなくては、業務が廻りません。各種帳票なども追加する必要があります。和暦年号が変わるのは、一番面倒です。
*6 みずほ（MIZUHO）とメインフレーム(Mainframe)をかけました。みずほについては「第七夜 みずほ障害で悩む管理者の夜」をお読みください。
*7 過去にもレガシーなCOBOLをCやJavaに切り替えようとしたり、メインフレームからのダウンサイジングという動きはありましたが、結局、Visual COBOL（要するにCOBOL資産エンジニアを切り替えられなかった）とかメインフレーム上で動くUNIXとかの方向に動きました。
*8 現行システムを切り替えたり、マシンの載せ替えの場合、まず新旧システムの並行運転・稼働が行われることが多いです。そして、数字や帳票などが、旧と新で正しいかを突合します。
*9 「IT業界の病理学」のCASE5-5 学生のキャリアアンマッチ病に書いてあります。大手に入社した場合のあるあるネタなのですがね。
*10 ソシャゲーのテコ入れ策として、以下がよく見られます。
連載一覧
筆者紹介
コメント
投稿にはログインしてください