ワイドテック プロダクト企画のYです。

またも「まん防」こと、新型コロナウイルス感染拡大対策の「まん延防止等重点措置」が発動され、好きな映画も見に行く気がいまいち起きない中、先頃興行収入100億円を突破したばかりの「劇場版 呪術廻戦0」だけは、と見てきました。
テレビアニメ化されて動画配信等でも人気を集めている少年誌連載漫画「呪術廻戦」の、本編ではなく前日譚として本編連載の前に発表された作品の映画化ですが、本編キャラの1年先輩にあたる本作の主人公・乙骨憂太（おっこつ・ゆうた）の声優が、昨年有終の美を飾った「エヴァンゲリオン」シリーズの主役・碇シンジと同じ、緒方恵美さんということでも話題になっています。
そもそも作者がエヴァのファンで、乙骨というキャラ自体、シンジ君をイメージして構想されたとのこと。発表直後や予告編が出始めた頃には賛否両論があったものですが、実際に見てみると、起用に納得してしまう出来の良さでした。

■フルクラウドで作る新XaaS。どうせなら最初から自動化で

さて、実は昨年2021年、自分ことYは、POLESTAR Automationにはこのコラム執筆とコンテンツの監修、あと若干の技術的支援以外で携わることは、ほとんどありませんでした。
では、1年を通して何をやっていたのかというと、社内で「Project C」というコードネームで呼ばれている、新しいサービスアイテムの企画と開発の準備です。
これが何であるかは、いわゆるXaaS（SaaSやIaaS、PaaSなど”as a Service”としてクラウドで提供されるものの総称）と呼ばれるクラウド型のサービスである、という以外、まだ明かせない状態なのですが、もちろん自分1人で何でもやっているわけではなく、コアとなるロジックやテスト用のプログラムは、社外の協力者を交えて開発しています。
あと、開発費用などについては、公的な補助金ももらうことになっているのですが、そのあたりの手続きはすべて、経験の豊富な総務にお願いしています。
年が明けてからは、専任の組織（自分もタスクフォースメンバー的な立場で参加しています）も立ち上がり、本格的な開発フェーズに入ったところです。
Project CはXaaSであり、オンプレミス主体のPOLESTAR AutomationだとかITインフラ運用とは全く違うジャンルであり、かつ自分にとっても未経験、未踏の分野でしたので、昨年はその方面の知識習得、テスト環境の構築やテスト実践などを通じた経験の蓄積に明け暮れてしまいました。
しかし、1から作る新しいXaaSということで、どうせなら「自動化」をテーマのひとつとして掲げようということになりました。
とりあえず、ユーザーとなる加入者が自分でサインアップし、設定もユーザー自身が行った上で日常的に利用し、請求処理なども自動的に行われる、という、できるだけ人の手が介在しない、セルフサービスによるXaaS提供を思い描いています。

■サインアップから設定、請求まで「セルフサービス」を目指して

セルフサービスというと、一昨年あたりから、携帯電話の新規契約（個人向け）で「オンライン専用」を謳うものが相次いで登場しています。
従来、携帯電話の契約というと、携帯電話ショップの店頭で、顔写真入り（または2種類以上）の書類による本人確認が厳重に行われていました。いわゆる特殊詐欺など、携帯電話が犯罪に利用されることを防ぐための「犯罪による収益の移転防止に関する法律（通称: 犯罪収益移転防止法、犯収法）」で規定されているからです。
かつて、プリペイド式携帯電話がコンビニなどの店頭で、最低限の本人確認だけで買えた時代がありましたが、「オレオレ詐欺」のような電話を用いた特殊詐欺の横行を機に、契約時の本人確認徹底が困難なプリペイド式は、サービス自体が事実上の廃止となり、携帯電話の契約は店頭かつ対面でないとできない時代が続いていました。
近年のオンライン契約では「eKYC（電子本人確認）」という仕組みが導入され、運転免許証やマイナンバーカードなどの本人確認書類を表裏だけでなく、書類を傾けて厚みまで撮影させます。書類が偽造やコピーされたものでないかどうかを確認するためです。
さらに、本人の「自撮り」による確認もあります。こちらも顔の正面だけでなく、横や左右、上下を向かせ、立体的に顔画像を取得します。
こうした数多くの手数の必要なeKYCの手順は、「面倒だ」という声も少なくないようですが、ここまで行うのは、本人確認を書類の内容ではなく、本人および書類の信憑性を証明するためにやや複雑な「過程」を踏ませることによって、確認の精度と速度を上げるためです。
実際、eKYCを導入している携帯電話サービスでは、対応する端末で物理SIMカードが不要の「eSIM」を選択することで、手続きが終わりさえすれば、早いものなら申し込み完了後数分で使えるようになるものもあります（物理SIMが必要な場合も、翌日や翌々日に届くことが多いです）。コロナ禍等で店に足を運びづらい状況もある中で、手続きがオンラインだけで完了し、しかも申し込みからすぐに使えるようになるというのは、メリットが大きいでしょう。
今回開発する新XaaSはBtoBであり、eKYCを入れるかどうかは未定ですが（ちなみに法人eKYCというものもあります）、eKYCの考え方は、セルフ契約型のクラウドサービスにおける、契約者確認のポリシー決定の参考になると思っています。
申し込み手順をクリアできたら、後は各種の設定、決済手段（運営側視点では請求方法）などが課題として残りますが、設定の自動化・簡素化については、ちょっとしたアイディアを思いついています。決済はクレジットカードを連携させれば簡単なのですが、法人の大半では「請求書払い」が求められると思います。顧客、運営双方にとって、できるだけ楽な手段を導入したいと考えています。

■「監視」と「障害復旧自動化」をどうするか

この新XaaS、クラウドでの提供ということで、サービスインフラもパブリッククラウドの上に構築することにしています。
必要なインスタンス（サーバー）だけでも、用途で大別して4種類か5種類、それにサービス規模の拡大につれて負荷分散や冗長化などが入ってくるので、かなりのインスタンス数になる可能性もあります。
さまざまな目的を持ったフロントエンド、ミドルウェア、バックエンド環境の稼働するインスタンスが絡み合い、連携し合いますので、安定して稼働できるようシステム構築を行うことはもちろんですが、各インスタンスの稼働状況の監視、いわゆる死活監視からプロセッサやメモリ、ネットワークなどの負荷の監視まで、リアルタイムでできるようになっていなければなりません。
あと、障害が発生してしまったら、ある程度は自動的に復旧できるような機能も必要でしょう。その実現には、構成管理が欠かせません。
この辺の構築や運用については、POLESTAR Automationに5年にわたり携わった経験が生きてくると考えています。
ただし、例えばAWSのように、1つのパブリッククラウドだけを利用するのであれば、Zabbixによる監視、POLESTAR Automationを用いた構成管理など、外部のツールに頼る必要は本来ありません。
AWSには、サービスにビルトインされた監視機能として「AWS CloudWatch」というものがあります。死活監視やパフォーマンスの監視はもちろん、メトリクス（CPU使用率やメモリ占有率、データトラフィックなどの数値）のしきい値を設定しておき、そのしきい値に応じてインスタンスを再起動するなど、自動復旧（オートリカバリー）の設定まで可能です。監視だけでなく、自動化の領域までをカバーする、非常に便利な機能です。
もちろん、CloudWatchもAWSのサービスのひとつですので、稼働時間や規模に応じた課金が発生するわけですが、もしAWSだけで完結する構成であれば、自分でもCloudWatchを利用する判断をしたことと思います。

■「マルチクラウド」に適応するには

が、しかし。
この新サービスを構築するにあたり、とある「絶対に譲れない条件」が出てきてしまいました。
その「条件」を満たすには、AWSではない、別のパブリッククラウドを利用しなければならないのです。
しかも、AzureだのGoogle Cloudだのという、運用ノウハウの蓄積されたメジャーなものではない、国内のクラウドです。そのクラウドを利用することで、新サービスは他にないアドバンテージを獲得することができるので、どうしても外せないのです。
期せずして、複数のパブリッククラウドが混在する「マルチクラウド構成」を選ぶことになってしまったわけですが、AWS CloudWatchでオンプレミスや、AWS以外のクラウドの面倒を見ることも、実は可能です。しかし、AWS外のインスタンスに対しては設定や管理が結構面倒な上、あくまでAWSに最適化されているので、やはりマルチクラウドなら第三者的立場のツールを使う方が都合がよいと判断しました。
あと、構成管理を行うには「AWS Config」というものがありますが、こちらは基本的に、AWS上のインフラだけが対象となるようです。
と、いうわけで、ここは弊社の取扱製品に頼ることにしました。監視はZabbixで、構成管理や障害復旧はPOLESTAR Automationで行います。どちらもクラウドに構築し、各サーバーにエージェントを導入して管理する方向です。

■後発ならではの強み発揮に向けて

Project Cは、弊社にとってゼロから手掛ける久々の大型新規事業であり、技術的、ビジネス的な未踏領域への、数多くのチャレンジをも含んでいます。
弊社では10年以上前から、電話転送サービス「転送録」や、電話による自動連絡サービス「急コール」などを通じ、SaaSの提供に関するノウハウを積み重ねてきてはいるのですが、これらは各々の分野における先駆者であり、参入当初は競合がいない状態でした。一方、いわゆるニッチ領域のサービスなので、市場規模は限られています。
Project Cで開発する新しいXaaSは、もう少し規模の大きな市場がターゲットながら、既に複数の先行コンペティターが存在するカテゴリになりますが、後発の強みを存分に発揮できるよう、さまざまな新機軸を打ち出して行きたいと考えています。 サービス全体にわたる「自動化」も、新XaaSのキーファクターのひとつとなります。

リリースはまだしばらく先になると思いますが、発表された暁には、ああ、あれがそうだったのか、と思い出していただければ幸いです。