100%保証ではありません

ここのところ、大手クラウドサービス事業者のシステム障害が時々話題に上がっています。
それぞれ個別の事業者のはずなのですが・・・偶然でしょうか?

今日は、クラウドサービスを使用するにあたって案外誤解されがちな「稼働率」と、その周辺事情について記したいと思います。

99.5%保証の中身

大手のクラウドサービス事業者の保証内容を見ると、概ね以下のような内容になっています。
・稼働率は月間で99.5%保証です。
・これよりも稼働率が下回った場合、利用料の幾らかを返金します。
※ちなみに、データの保持については別で、この確率で消えたりはしません。

これだけ見るとあまり問題ないように思えますが、
・1ヶ月は31日の月で744時間あります。
　保証していない0.5%は、3.72時間になります。
・基準を下回った場合は、あくまで「利用料の返金」です。
　止まったことによって生じた損害は補償してくれません。

こう表現すると、ちょっと不安になりますね。
ただ、実際のところは、あまり問題にはなりません。

24時間働いてますか?

バブル時代を彷彿とさせる表現ですが･･･
さすがに24時間働いている方はいらっしゃらないと思います。
結構ハードワークな方でも、半日ではないでしょうか。
少なくとも、そう考えると、仕事中に事故に出くわす確率は、半分の時間になります。
休憩時間や休日なども加味すると、もっと事故率は減ります。

クラウド事業者自体も困る

今、クラウド事業者の2トップといえば、ネット通販世界最大手のa社と、検索エンジン世界最大手のg社です。

これらの業者は、自分たちの事業を自分たちのクラウドサービスを使って展開しており、その事業が止まってしまったら、当然困ります。
そのため、世界トップレベルの技術者を招き入れ、必死になってサービスが止まらないようにしています。

0.5%は止まるかもしれないという書き方ですが、実際のところは、半年に一回、15分くらいの間
「あれ、動かないな・・・」
という状況に出くわす程度で、そのときは昼休みだったから気づかなかった、ということも多々あります。

近年は「日本の大手企業」レベルでも、自前で機材を持っていても彼らと同じレベル・同じ経費で維持できないと判断し、続々とクラウドサービスに切り替えています。
現実的には、それくらい安定しています。

マルチクラウド

いや、それでも困る! という場合は、a社とg社の両方で同じ機能を動かす
マルチクラウド
という手法を使っています。
そうすれば、ほぼ停止することのないシステムが構築できます。

しかし、マルチクラウドの最大の難点は
「a社とg社の説明書を両方読む必要がある」
ことでしょうか。
企業に勤めてシステムを作っている場合だと、単純に人件費が2倍、あるいはそれ以上になるので、やはり資金力がある企業くらいしか手を出しません。

まあ、私はマルチクラウドにチャレンジしてみるつもりです。
会社員としてのしがらみも無いですし、説明書2つ読むことよりも、その先で安定して動作してくれるほうがメリットが大きいので、やってみる価値はあるかなと思っています。

こだわらないなら、更にお得に

今日は、クラウド上のサーバをお得に借りる方法を記します。

それぞれ条件はあるのですが、うまく使えばとても安上がりに高機能なサービスを使うことができます。

※今日はどちらかというと、クリエイターの方向けな内容です。
　もちろん、店舗の支援だけでなく、クリエイターさんも応援しています!
　また、その内容を店舗運営に応用できるなら、それも良いと思います!

ずっと使い続ける?

クラウドサービスの一番基本的なサービスは、「コンピュータを借りること」です。
この性能のコンピュータ1台を1時間動かすといくら、という料金体系になっています。

その時間コンピュータを借りて、それに見合う結果が得られるのであればよいのですが、場合によっては「ずっと使い続ける必要はない」ケースもあります。

借りる前にもう一度、使いたい状況や折れてもいい条件を見直してみてください。
案外、お得なパターンが見つかるかもしれません。

例1:「依頼が来たら処理して」方式

例えば、新しいゲームを作った方がいらっしゃるとします。
今時のゲームは単にゲーム機やスマホで遊べるだけでなく、何らかの形でインターネットにつながり、キャラクターの育成状況などが保存されています。

さて、ゲームをリリースしたはいいのですが、大々的な宣伝でもしない限り、すぐにユーザが増えるわけではありません。
そうなると、コンピュータを1台借りてしまうと、殆どの時間が空き時間になってしまい、無駄になってしまいます。

このような場合、「依頼が来たら処理する」方式のクラウドサービスを使うと、だいぶ安上がりにできます。
もちろん処理の複雑度などにも依存するのですが、「依頼100万件あたり百数十円」くらいまで節約することも可能です。

コンピュータ1台借りると、一番安いタイプでも月だいたい3000円強の料金になるので、だいぶお得です。

例2:「暇ならやっておいて」方式

例えば、頑張って自分で長編アニメを制作された方がいらっしゃるとします。
編集の仕上げ処理を何度か繰り返したいのですが、まだ売れているわけでもないので、専門のアニメ制作会社や有名ユーチューバーのように、高い機材を買うわけにもいきません。

そのようなケースでクラウド上の高性能サーバを借りる方法は非常に良い選択肢になるのですが、
「暇ならやっておいてスイッチ」(実際には業者ごとに横文字な名前が付いています)
をONにして借りると、更に安く借りることができます。
借りるコンピュータの種類や時期により変動するのですが、概ね半値〜最大9割引くらいになるようです。

一つだけ注意いただきたい点は、「暇ならやっといて」の裏返しで、暇でなければ
「今忙しいから動けない!」
と処理が一時停止してしまうことです。
最初は動いていたけど、しばらくすると一時停止することもあるらしいので、一時停止からの再開処理も予め考えておく必要があります。

とあるクラウド業者の場合、8割方はその場で動作するそうですが、平日の日中は一時停止する可能性が高いそうです。

クラウド事業者としても、お得

なぜこのように安くなるか、ですが、おそらくクラウド事業者としてもコンピュータが空いていると無駄なので、一定の条件付きで隙間時間を埋められるようにして、稼働率を上げたいのだろうと思われます。

お互いの利益になるなら、ぜひ上手く使いたいものです。

とにかく電子化してみよう

 ここのところ、会計の電子化について、あまり大げさなものを取り入れずに処理できるようにするにはどうしようか? ということを、よく考えています。

単純に自分が税務処理で楽したいからという面もあるのですが、おそらくこのジャンルについては「領収書の入力が面倒!」と思っておられる方も多いと思いますので、最初の活動としては手頃なのかなという感もあります。

その関連で調べていくうちに幾つか気づいたことがありますので、今日はその話題について記したいと思います。

領収書を「捨ててしまってよい」条件

私も今日初めて知ったのですが、数年前から何度か税金の処理に関連した領収書(正確には領収書に限らず「証憑」全般)の保存を電子化してもよいことになり、条件さえ守れば「その後捨ててしまっていい」ようです。

その条件とは
1. 200dpi以上,　24bitフルカラーで取り込むこと
2. 取り込みは3日以内に済ませること
3. 取り込んだときに認可を受けた業者のタイムスタンプを付けて、以後書き換えていないことを証明すること
4. 取り込んだ人と確認する人を分けること(確認者は税理士でもOK)
だそうです。

1.は、最近のスキャナやスマホカメラなら間違いなくクリアできます。
2.は、あまり面倒がらずに小まめに処理すれば問題ないでしょう。
　(年末まで溜め込んでしまっている人は要注意!)
3.は、さすがに個人での対応は無理ですが、最近の会計ソフトの多くは対応済みのようです。
4.は、正直今の自分には頭の痛いところで、一人で仕事している上に、利益も出るか分からない状態で税理士とか雇いたくないので、クリアできないかなぁと思っています。

電子化するだけでもメリットが

とはいえ、1.2だけでも済ませておくだけでも、メリットはあります。

それは「書類が扱いやすくなる」ということです。

ファイル名に日付を入れておくだけでも、後で検索機能を使えば簡単に探すことができます。
また、伝票の入力が面倒となった場合、誰かにデータ入力を依頼することも簡単になります。

実際私は、自動認識できない領収書があり、かつ処理が追いつかない部分については、少し離れた場所に住んでいる甥っ子にアルバイトで入力してもらうのも有りかなと思っています。
このように誰かに依頼する場合も、デジタル化していれば瞬時に情報を転送することができます。

また、書類の自動読み取りAIの研究が今現在活発に行われているのですが、それらが「使える」タイミングになったら、一気に面倒な作業から解放されるチャンスもあります。

今のうちから始めておいても損の無い作業だと思います。

「捨てなければ」制約も緩い

更に、3.4.のようにシステム導入や体制作りが必要な箇所についても、別に「領収書を捨てなければ」対応しなくても問題ありません。

一度入力した領収書の原本を再度見なくてはならない時など、データ自体が破損してしまった時か、税務署の調査が来た時くらいしか無いはずです。

それであれば、袋に入れてしまっておけばいいのではないでしょうか。

これはITではなく生活の知恵のような話になってしまいますが、私はよく、厚めのビニール袋に乾燥剤と共に保存したい紙類を入れ、封をした後に軒下や屋根裏に放り込んでおきます。

一応注意点としては、
・軒下は虫が入ってくることもあるので、袋だけでなく、更にプラスチックの箱などに入れたほうがよいでしょう。
・屋根裏は、壁際に10cmほどの隙間があり、そこに落としてしまうと取れなくなるので、落ちない幅のある箱に入れるか、壁際を避けて置くほうがいいです。
・同じく屋根裏は、あまり重いものを置くと天井が割れて落ちてくるので、ほどほどの分量に。
・特にお引っ越しの時には、そこに収納したことを忘れないようにしてください･･･
といったところでしょうか。

もっと量が多いのであれば、宅配便送付だけで対応してくれるレンタルボックスを活用するのも良いと思います。

簡単なことからでも、やってみてください!

これは私の実感なのですが、本当に紙の書類があるというだけで、取り扱いが非常に煩雑になります。
今はデジタルデータの記憶単価が劇的に下がっているので、ただスキャンした程度では殆ど容量は必要ありません。

本当に楽になるので、紙のままで作業されている方は、少しずつでもいいので、是非試してみてください。

課題、いろいろ。

まだまだ準備段階の状況ではありますが、ミツユビ工房の活動について知り合いの方にお話すると、興味を持っていただけることが多々あり、ありがたく感じております。

しかし、その思いも、翌日になると

「これは解決しなくてはならない課題が多いな」

という思いに変容しています。

今日は、その課題について、幾つか記したいと思います。

曖昧すぎてイメージがわかない

やはり、

IT化というけど、実際にどう変わるの?

どんな仕組みが手に入るの?

という点については多くの方から質問いただきます。

私は1990年代後半から2000年代初頭にかけての

ITバブル　→　バブル崩壊

の過程を、業界内で間近に見てきた世代のため、その時代の

「ITという言葉が目的化してしまった状態」

は本当に避けなければならないと痛感しています。

ただ、それに対する答えは未だ見つかっていません。

今から見つけていくしかないのかもしれません。

入力自体が困難

以前のブログ記事にも書きましたが、IT化するには先ず「何かを入力」しなくてはなりません。

しかし、IT化がなかなかできない状況を観察していると、

・こんなところにパソコンやスマホ端末置いてたら壊れるな

・壊れる以外にも、衛生面など別の理由で端末を置いておけないな

・スマホやタブレット端末に至っては、反応しない/誤反応起こすよな

という現場が沢山あるように思います。

一言で表現すれば、市販のIT機器は、物理的な意味で、まだまだ軟弱です。

そのような状況にどう対応するか?

「やはり機材そのものを作る必要がある」

という思いが強くなってきています。

幸いにして今の時代、クラウドサービスに留まらず、

電子部品や素材系もネットで簡単に手に入る

時代になってきています。

(ただし、名前や型番が分かれば、ですが)

先日、本当に趣味かつ気まぐれで「レーザー加工機」というものを買ってしまい、プラスチックの板を切断したりしていたのですが、これは想定外の先行投資になりそうな予感がしています。

地域密着型で売上をどう伸ばすか

これも多くお寄せいただいている疑問で

IT化でどうやって売上を伸ばすことができるのか?

という課題があります。

おそらくは、いわゆる「デジタルマーケティング」の領域かと思います。

もちろん、広告費を湯水のごとく使えば、認知度は簡単に上げることができます。

ただ、その費用に見合った売上が出るのか? というと、それは別の問題で、特に地域に根ざした商いの場合、全く効果は出ないでしょう。

また、あまりデジタル機器がお好みでない層の方の買い物についても、IT化を上手く適用していく必要があるようにも思われます。

更には、小規模な店舗の場合、仕入れ・在庫にムラが出てしまうようでは、かえって経営面で逆効果になってしまいます。

そこをどう上手くバランス取りしていくか、研究すべき点は多いように感じています。

まだまだ課題は沢山ありますが、裏を返せば

「掘り起こせていない需要が、そこにある」

とも取れます。

新たなチャレンジは疲れるかもしれないですが、やってみる価値はありそうだと思う所存です。

思わぬ反響に感謝しております!

本日はブログの書き込みは小休止ですが･･･

とある場所で、私の今後の活動について思わぬ反響をいただき、感無量です!
これだけ反響いただくと、とにかく何か形にしないとならないですね。

本当に励みになりました。
ありがとうございます!

助っ人を呼ぶには、備えが必要(その2)

昨日の続きで、
「厳密な処理」を適用しすぎた

について記します。

とにかく真面目なRDB

おそらく世の中の殆どのシステムで、RDB(リレーショナルデータベース)と呼ばれる記憶手段を使っています。

RDBには幾つかの特徴があるのですが、それらの一つに「とにかく持っているデータ全体で矛盾が生じないように頑張る」性質があります。

確かに素晴らしいことなのですが、その性質を保つために、必ず1台のコンピュータのみで情報を操作する仕組みになっています。

とりあえず1台のコンピュータで賄えているうちはいいのですが、システム設計者やプログラマーが手を抜いて(というか何も考えず)何でもこの場所に放り込む作り方をしてしまうと、やがて追加や更新の依頼が捌ききれなくなり、あるとき急に音を上げます。

音を上げた時に慌てても、もともと手を抜いていたところに「全体で矛盾してはいけないもの」と「別にそうでもないもの」の区別はできようもなく、今度はシステム担当者が音を上げてしまう、といった惨事が、世の中のどこかで、しばしば発生しています。

「真面目さ」の範囲を限定する

この問題に対する解決策ですが、システムの導入以前に「考え方の整理」が必要です。

例えば、オンラインショップのシステムを考えた時、

1.「買い物かご」の中身　→　各お客様に対して矛盾が無ければ、問題ないはず。

2.「実際の商品在庫」　→　倉庫の内部で整合性が取れていれば問題ないはず。

3.「購入するボタンを押した瞬間」

　　→商品在庫から買い物かごの中身をお客様に対して割り振る、というタイミングだけは、やはり厳密な整合性が必要そう。

と3段階に分けて考えれば、少なくとも1.は助っ人に分業できそうです。

実際のところ、オンラインショップで3.が発生するタイミングは、買い物かごに追加したりショップ内を見て回ったりといった操作に比べて発生頻度は非常に少ないので、この一工夫だけでも「音を上げる限界点」は相当変わるはずです。

ちょっと嫌味な話題になってしまいますが、「予約販売の受付」というケースであれば、3.自体を予約受付終了後に処理すればいいので、そもそもあまり考えなくても「御用聞き特化型の助っ人」を沢山呼べば解決するはずです。

つい最近も、そこそこ大手の企業で「予約販売システムダウン」が起きたみたいですが、何も考えていなかったのでしょうか･･･

クラウドサービスで解決する荒技も

さてここで、

「あの世界的超巨大通販サイトだと、これでも対応できないのでは?」

と思われた方は鋭いです。

多分、その昔、対応できなくて困ったのだと思います。

でも彼らは、どこかのタイミングで、それですら克服してしまったのだと思います。

そして今の時代･･･

彼らはその解決策ですら、クラウドサービスとして販売しています。

少なくともその仕組みを上手く組み込めれば、あの通販サイトが音を上げるレベルくらいまでは耐えることができます。

つまり、大方の人にとっては、ほぼ気にしなくてもよい状況になります。

新しくするなら、是非検討してください!

昔作ってしまったシステムは、半ばどうしようもありません。

担当者が入れ替わってしまって、手が付けられないケースもあります。

ただ、これから作るシステムについては、もう失敗の知見も世に出回っているので、今の時代に合わせた作り方ができます。

新しいシステムを導入する際には、
「バズったらどうする?」

を是非頭の片隅に置いた上で見渡してみてください。

助っ人を呼ぶには、備えが必要(その1)

以前「バズったらどうする?」の記事に、自動スケーリングは過去のしがらみでできないことが多いことを書きましたが、ではどうやって解決するのかについて、代表的な方法を記したいと思います。

問題になるバターンは概ね決まっている

アクセスが増えたのでサーバを増やそうとして失敗するケースは、ほぼ下に挙げるパターンによって問題が発生します。

・どこか一カ所に頼った作りになっていた

・「厳密な処理」を適用しすぎた

これらが複合している状況もあります。

「結局○○さんに頼るしかない状況なので、受注を増やせない」

「とにかく正確さを求めすぎて、一向に仕事が進まない」

と置き換えると、現実世界でもありそうな話ではないでしょうか?

インターネット上のシステムでは、アクセス集中でパンクしているところもあれば、それを平然と乗り切っているところもあります。

では、「乗り切っている」側はどうやって解決しているのか、代表的な考え方をご紹介します。

ライブ会場の例

例えば、大きなライブ会場があり、入場券が大量に発行されたとします。

もちろん高額な席もあれば、安い席もあります。

席のランク(S席・A席など)ごとに入り口があり、チケットの確認係の人も多く働いています。

しかし会場は広いので都度本部に問い合わせることはできません。

入場者が多すぎて、携帯電話での通信に頼ることも困難です。

この時、チケットに

・お名前　○○様

・S席　1列目

という情報だけ書いていて、それを確認するだけだと、

「一番安いC席を買って、Cのところを書き換えてSにしてやろう」

と考える悪い人に対して対抗ができなくなります。

「確認番号」を使う方法

そうなると困るので、以下のように情報を追加します。

・チケット番号　123番

・お名前　○○様

・S席　1列目

・確認番号　A2B4521JL

情報を追加した上で更に、確認係の人たちだけに

「チケットに書いてある情報だけで、この確認番号が本当に正しいかを、自分だけで確かめられる方法」

を教えます。

こうすれば、本部に問い合わせることなく、通信回線を使うこともなく、確認係の人たちは自分たちだけで「この人を通してもいいのか?」を判断することができます。

実際のシステムでは、この確認番号にあたる部分は「電子署名」と呼ばれるものを使っており、解析されないよう相当長い暗号になっている上、更に有効期限を付ける方法で不正利用されない仕組みになっています。

一つだけ、「確認番号が本当に正しいかを確かめる方法」が部外者に知られてはいけないという制約があり、それは別の方法で管理する必要があるのですが、この考え方に基づいてシステムを作れば、アクセス集中時にサーバを大量に増設しても、それぞれが自律して同じように操作を受け付けられるようになります。

「厳密な処理」を適用しすぎた

の例については、次回記したいと思います。