EC/CRM/DX/経営コンサル　Boofee Inc.

昨日、JR系のクレジットカードシステムに障害が出て、何十万件の取引ができなかったとニュースになっていました。

便利のために作られたシステムにより、不便になっているという本末転倒が、このシステム障害になる。そもそも、作り手は不具合なんかは、想定していない。極端かもしれませんが、便利になることしか、考えていません。トラブルになり、不便になることもあるということを想定して、設計をしていることはほとんどありません。

なぜなら、どのシステムも障害を出し、大きな信頼を失っています。たとえば、不具合が出たときに、数秒で、バックアップサーバーとミラーリングサーバーでの連携により、この不具合がカバーできたというニュースは見たことがない。つまり、不具合がでましたというニュースは、障害や不具合を設計し、フォローできていないという報告になります。

以前からシステム障害のリスクはインターフェースにあると申し上げてきました。
たとえば、トラック競技のリレーで例えます。リレーで問題になる箇所は、バトンタッチです。バトンタッチは、インターフェースの最たるものです。逆にいえば、１人ですべて走ってもよい、バトンタッチがなければトラブルはほぼ極端に少なくなります。それは、バトンタッチのリスクだけではなく、４人で走る（つくる）となれば、４人の能力差　これがリスクとなります。いくらディレクターがディレクションをしても、この能力差のリスクは吸収しきれません。国家の威信をかけた　あのマイナンバーでも不具合だらけです。
たしか、ニュースでは、富士通が作った部分に出ているとなっていましたが、あの大手の富士通が作ってもそんなレベルです。

不具合について、出さない　と　いうより、必ず出るのでリカバリーやフォローができるようにしたいが正解のような気がします。しかし、お客様は、そのお金は出しません。なぜなら何もなければ何もないのでしょ、何もないようにおたくが作ればよいのでは、となるからです。つまり、自腹でも最低限は、稼働監視ツール、不具合報告ツールくらいは作っておくべきです。リカバリーができるという環境は同環境が、平行して稼働しているとなるため一見難しそうに思えますが、結局のところ、バックアップという考え方もできるため、同環境が平行して稼働し、バックアップにもなっているという設計がされていれば、すぐにバックアップを使って動かせるという論理になります。

また、その同環境が、混雑時のフォローやストレージ不測のフォローをするなんかは、とても賢いシステムになります。しかしながら、同環境＝本番のコピーです。不具合やウィルスも同環境です。リカバリーするたびにそれを世襲して、いつまでも治らないという経験をしたこと結構あるはずです。その場合は、原因をまずは取り除かないといけません。

不具合を出さない　は神様の領域です。人は、不完全なものです。だから人なのですが、これをミスを起さないものを作るということは、システムが大きくなればなるほど難しいということになりますが、それをあきらめては、成長や後学もありません。エンジニアはそれでもミスは許さないという気持ちで能力を高めてもらいたいです。

回りくどかったですが、楽天モバイルの仮想サーバでの運用について、本題にはいります。

仮想サーバーアプリケーションとそのエンジニアがリスクのインターフェースになります。

私は、ユーザーが１０００万人超える当りから、不具合が連発し、ニッチもサッチもいかなくなるのではと懸念しています。

楽天をつぶしたい人、いたずらな人、そもそもの不具合、サーバーアプリケーションの不具合、が重なり相乗効果を生んで不具合の大爆発を起こすのではないかという懸念です。

仮想サーバーは、まだまだ歴史が浅く安定していない、セキュリティに関しても同じことがいえると考えています。それを運用するエンジニアも同じく歴史が浅く、新参者というイメージが強く、結局サーバーセキュリティに関して、未熟な人間が運用し、気づけるものも気づかない、直せるものも直せないという状態が続くような気がします。

仮想マシーンは、ある日ログインさえできなくなる　という報告も上がってきています。
また、不安定な状態になり、リブートを繰り返しているイメージも非常に強いです。

現時点では、開発環境やテスト環境を作るために用意されているくらいのものにしか私は仮想サーバーでの運用がよいとは思いません。ユーザーは安物買いの銭失いになりかねません。

仮想化で、サーバーの台数を減らして、無駄な領域を余すことなく使うということが、仮想化、つまり、効率化、合理化の考えであるなら、その無駄と言われる部分が、本来、安定・安全のために必要な　無駄　ではないかは、今後の楽天モバイルの運用で証明されるであろうことだが、私はなんでもかんでもハイテクなもの、合理的なもの、いわゆる便利というものは一方から見たら怠慢であり、その怠慢は本来組織として苦労すべく必要苦であるならば、その組織に必ずや怠慢で肥満化・弱体化し、しっぺ返しのような形で自分達に帰ってくるようで私はそう思ってなりません。

先ほど、孫さんが語る１０年以内にAGIについて実現するAGIについて少し語りたいと思います。

改めて孫さんはさすがの投資家、いやここまでくるとすごいね、夢を語るのが投資家・事業家の仕事だと思いますが、具体的にどこまでのことを知って言っているのか、コンピューターがいよいよ人間を超える、我々とチンパンジーは１０倍くらいの知能の開きがあるが、今度は我々とコンピューターが１０倍くらいの開きで我々を超えると映画のような話をされていました。

以前も投稿をしましたが、AIとは、あらゆるシミュレーションをマスタ化し、その状況を判断するセンサーやフラグを感知し、マスターから最適なものを取り出し処理をするという技術だと申しましたが、人間を超えるというのは、どこまでのことを言っているのか知りませんが、金魚が鉢に入っていて、ＡＢＣという単語を覚えるという絵を見せていたが、コンピューターが自ら成長する・勉強するというレベルを言っているのであれば、それはとんでもないことだと思いました。ペッパー君をつくっている会社の社長がよくいいますね。ペッパー君は、まだAIBOレベルではないか？一時はソフトバンクのキャリアショップにあったが最近は、接したことがなくわからないが、そんなに大したロボットではなかったような気がする。

私が考えるにAGIを実現するには、課題は、３つ
すべての人間の行動パターンをマスタ化する
すべての人間の行動パターンを判断するセンサーや解析アプリを用意する
成長のロジックを　チャレンジ　正誤判断　正解ならマスタ化してゆく　失敗なら反省・総括し最適なものに修正する　という論理なら　その正誤判断はどうするのか、ネット上のマーケティングによるものになろうかと思うが、有識者の意見を重点を置くのか、たんなる客観によるものなのか、一方、主観的な判断は危険なのか、どうもこのへんがよくわからないアルゴニズムになるのか想像もつかない。

つまり、ＡＧＩとは、人間の脳をアプリケーション化するという意味でいえば、正直、まだまだ先の話になろうかと思う。ＡＧＩは、例外を吸収することができないため、変な空気の読めないロボが仕上がるような気がする。世の中には、但し書きという例外がたくさんあり、その例外を例外フラグとして、判断するところがかなり難しいような気がする。
そういったセンサーを作るのも難しい、なぜなら、技術者こそが例外の読めない人種であり、また、侘び寂び　や　道義や義理人情　や　いやらしい　粋な行動　など
そういった高級な人間の行動パターンは、マスタ化できるのだろうか。
いずれ、〇〇バージョン　〇〇バージョンなどの　キャラ変も簡単にできる時代になろうかと思うが、　宮内庁監修　公家AGIなどもできる時代になるのかもしれない。

コロナであっという間におっさんになったように、時間が経つのは早い。
まぁ、あと１００年はかかりそうな気がするのは私だけでしょうか。

当社のシステムは、PHPで書かれています。
PHPは、バージョン５以降、革新的な進化を遂げ、オブジェクト指向やテンプレートシステムに始まり、フレームワークによる開発が始まりました。
この時期に多くのシステムが、革新についていけず、また、いったりいかなかったりで合いの子のようなシステムができたりと混乱があったのだと予想します。
当社も、設計者の私が、ついていけずに、また、技術責任者のリーダーシップがなく、また、アジャイル開発の全盛期でとにかく書くという時期だったため、とても滑稽なシステムになってしまったような気がします。

設計が一番大事、つまり設計者の人事が一番大事ということは、前回も散々話しましたが、現場を仕切る設計者やディレクターが、オブジェクト指向を知らない、フレームワークを知らないということが多々あったかと思います。それにより、フレームワークの開発環境により開発を進められているにも関わらず、違うディレクトリには、ベタベタと一から書かれたソースがあったりとディレクトリ構成がとても複雑なシステムになっていることが多々あったに違いないと思われます。

そうです、システムは、できればOK、お客様は中身なんか知りませんということで、多くのシステムがつぎはぎだらけのものになっていたのではないだろうかと予想されます。

私も、当初は、フレームワークやオフジェクト指向を知らず、ベタベタな開発しか経験をしておらず多くのPGをベタベタなコーディングを放置していたり、フレームワークを強制し、フレームワークで開発したシステムを破壊させてしまったりと、ハチャメチャなディレクションをしてしまった記憶が後悔先に立たずといった気持ちと共に蘇ってきます。

オープン系の進化は、めまぐるしく、著しく、日進月歩です。
流行りものがよいということではなく、開発者たちが、しっかり打ち合わせをし、吟味したうえでどのような開発を進めるかということの重要さを今一度再確認をしたほしいと思います。それぞれがバラバラに自由に開発をすすめることは、スピードにとっては、また、一朝一夕につくって使わなくなるシステムに関しては、それでよいかもしれませんが、業務用システムのように、末永く使用するようなものに関しては、メンテナンスということ、セキュリティということを検討しなければいけません。

誰が引き継いでもメンテナンスができる
オペレーションレベルで設定や修正ができる
監視ツール・報告ツールが２４時間稼働し、報告をしてくれる
ような素人でも、何がどう動いているか、正常か？問題か？を把握できるようなシステムでなければ、システムが２次被害を生むようなことになり、設備投資の意味がマイナスになり本末転倒になりかねない。それは、できればよい、金をすぐにもらいたいというPGたちの怠慢であり、設計者たちの勉強不足による産物であることは間違いない。

それからのメンテナンスは、さんざんだということは言うまでもない。つづく。