日本がもし100人の村だったら、ひとり情シスになる理由

十年前ほど大流行しましたよね。「世界がもし100人の村だったら」。世界に100人しかいないと仮定するといろいろわかりやすくなる、というのが話題を席巻しました。

世界がもし100人の村だったら

この本も2021年版にアップデートして再度出したらいいのになんて思うのですが、この本の考え方は今でも通用すると思います。

さて、今回の話題をする前に、日本のITエンジニアはどれぐらいいると思いますか？。

hrzine.jp

　各国のIT技術者数を国・地域別で見ると、米国がトップの477.6万人、ついで中国の227.2万人、インドの212万人と続く。この3か国で世界のIT技術者の約43％を占めており、IT大国として大きな存在であることが分かる。

　なお、日本は109万人で世界第4位。しかし、トップの米国の2割強、3位のインドと比較しても約半数に留まった。

ということで、100万人強ということは、100倍すると1億人。

つまり、日本がもし100人の村だったら、ITエンジニアは一人しかいないということですね。ざっくり言えば。

私の体感的にも、100人未満の情報システム担当って一人のところが結構多い印象です。会社が少人数の時は専任の担当者すらいない、「ゼロ情シス」から始まり、社員が増え始めて仕事が増えてやっと「ひとり情シス」（専任担当）が誕生する。100名程度ではひとり情シスなのは当然で、そこから二人以上になるのはもっと先。

こういった各社の情シス担当の状況調査をご紹介します。

japan.zdnet.com

　ひとり情シス・ワーキンググループが2020年12月に実施した「ひとり情シス実態調査」と「中堅企業IT投資動向調査」によると、従業員100～500人の中堅企業におけるひとり情シスの割合は32.6％と微増していました。増減の変化を調べたところ、ここ数年では大きな変動は見られませんでした。しかし、この内訳を詳細に調べると、新しい傾向が見えてきました。

　さまざまな調査によると従業員100人以下の中小企業におけるひとり情シスの割合は5％未満です。平均すると、従業員が80人を超えた辺りからひとり情シスを配置する傾向です。ただし、この傾向は業種やビジネスモデルによって異なります。今でもITに重きを感じていない中堅企業では、従業員が100人を超えても情シス担当者が存在しないこともあります。

www.atpress.ne.jp

ひとり情シス・ワーキンググループは、従業員100名から500名までの独立系、大手企業グループ会社系の日本国内全ての中堅企業を対象に、「ひとり情シス実態調査」と「中堅企業IT投資動向調査」を実施しました。約半数の中堅企業が、来年度の景気状況を不安視しているものの、IT予算を増加する企業は38.2％であり、減少する企業の26.3％を上回っています。同時に、「ひとり情シス」を取り巻く環境にも新しい変化が見られます。その速報値を報告いたします。

日本全体で1%しかITエンジニアがいないのだから、100人の会社であれば一人専任を置ければそれは心地よい割合です。

しかし、世の中の会社が往々にしてDXで慌て始めたり、政治家がデジタルを連呼し始めている状況にて、結局はITエンジニアが少なすぎるというのが現在の状況にあると思います。

しかも、日本の場合は状況が特殊で、ITエンジニアはSIerや、SaaS/PaaS/IaaSサービス企業など、独立した会社に集まっています。

だから、ユーザー企業側に著しく人材が不足し、情シスを設定できないということが言えると思います。上記調査にもありましたが、ユーザー企業の情シス担当者の半分がITベンダー出身とのことです。

結論としてはですね、明らかに日本にはITエンジニアが少なすぎる、ということです。

これも、学校教育において「国語・数学・理科・社会・英語」の5教科から長い間逃れられないところの悪影響です。「情報」という教科ができたり、プログラミングが学習に組み入れられたりと変化はあるものの、まだまだ日本ではニッチな分野だと思います（ここ最近は人気職業になりつつありますが・・）。

日本がもし100人の村だったら、理想は30人くらいはデジタルがわかっていないとまずいんじゃないかな、と言う実感はあるのですが、残念ながら、お一人と言った状況です。

だから、ノーコードやローコードなんて概念が今流行し始めているんです。残りの99人でもデジタルが扱えるように、と。

ただ、それは本質じゃないですよね。教育分野からどんどんデジタルシフトして、せめてふたり情シスぐらいにはなりたいですね、日本も。

コロナ禍終わったらどうなるかっていう話

コロナ禍が終わるとするじゃないですか。まだ終わってませんが。

そしたら、大量のテレワーク人がオフィスに帰りますよね。

週５フルに急に戻るとは思えませんが、それでもたくさんの人々がオフィス通いを再開するようになる。

なぜかというと、他の会社、つまりお客さんもオフィスに戻るからです。そうするとこっちもオフィスにいた方が何かと便利ですよね。呼べるし行けるし。

Web会議？、いや面倒でしょ。とにかく会いに行きますよね。もうしばらくWeb会議でしかお会いできなかったから、まあ話に花が咲きますよね。遠距離恋愛かっつーの。

そしたら今度飲みに行きますか、なんて話になって、歓楽街も連夜の大フィーバーになるんでしょうね。忘年会シーズンが半年ぐらい続くみたいな。

で、社内は社内で、みんな集まって、コロナ禍での反省会みたいなものもたくさん開かれるでしょう。ウチの会社、こういうところイケてなかったよね、から始まり、こうしませんああしませんの大検討会議が自然発生的に起こるでしょう。

やっぱり直接会ってないと言えないことってたくさんありますから。会話の間とか雰囲気とか、直接会っているときってたくさんの情報がそこにあるんだなと感心するものですよ。

で、ITの世界ですが、もうみんな忘れかけていると思いますが、「2025年の崖」っていう課題があって、ここまでにいろいろデジタル的な課題を解決しておかないと、崖から真っ逆さまに落ちるよっていうことを経産省が主張してたわけです。

で、主張しはじめたのは2019年ごろだったんですが、ちょうどコロナ禍が起こって、みんなそれどころじゃなくなったよね、と。

もう2022年にワープなんです。だからもう2025年まで後3年みたいな話になっちゃってる。

2025年の崖って、SAP ERPの保守切ればかりが言われますけど、Windows 2012やら、Redhat 7やら、Java 8やら、今度はWindows 10までが加わってきました。

※ほとんどは拡張サポートを契約すれば2025年から先もサポートされるのですが、余分にお金払います？って話です。

みんな今を凌ぎ切ることに勢力を使ってきたけど、もしコロナ禍終わったら、急に新しい現実と向かい合うことになるのですよ。しかもパンデミック対応の反省という大きな課題を抱えて。

もうね、皆がDXとは何かということを意識しなくても、しゃべってることはDXの話ばかりになると思いますよ。だって、テレワークしていた人たち、普段Twitterやらネットニュースやらを見て、自分の会社がいかに遅れてたかをかなり学習してますから。

きっと、オフィスに集まった時に、なんでウチにはこれがないんや！ってなりますよ。で大商談会の開始ですよ。きっとどこの営業もひっぱりだこになって、むしろ外回りする時間がないと言って「Web会議でおねがいしゃす！」ってなりますよ。そしたら営業効率爆上がりですね。多分コロナ禍で、どこの営業部員も営業ツールの使いこなし、相当ウデを上げていると思います。

商談決まりそうなら行けばいいですし。それまではWeb会議連チャンで十分です。

このコロナ禍、まだ緩和に浮かれるにはもう少し早くて、どういう風に新型コロナとつきあっていくか、新しい内閣や衆議院議員選挙を経る必要があります。また、アメリカもどうも今年中はオフィス回帰は様子見にするようです。

www.bloomberg.co.jp

米マイクロソフトは10月４日までに米国オフィスを完全再開するとしていた計画を取り下げた。新型コロナウイルスの今後の感染状況は予測不可能だとして、オフィス再開の新たな予定は提示できないとした。

一方で、ワクチン義務化までバイデン大統領は踏み込んできています。

www.cnn.co.jp

バイデン米大統領は９日、連邦政府職員や一部の医療従事者に新型コロナウイルスワクチンの接種を義務付けるとともに、大規模雇用主に対して従業員のワクチン接種か週１回の検査を確認するよう要請する方針を明らかにした。

2022年は、きっとDX一色になると思います。そこまで想像力を働かせて、2021年の残りを過ごしていけば良いのではないかと思います。

報告書に書いてはいけないNGワード

最近、世の中はすごくシステム障害に厳しくなっていて、一般のテレビのニュースを見ていてもシステム障害の話をするようになりました。

システム運用を仕事にしている私にとってはとても胃の痛くなるような時代が到来しましたが、社会的責任がいよいよ高まって来たと考え、誇りをもって仕事をしていきたいと思います。

さて、このシステム障害と一体となる報告書。仕事柄よく読むのですが、NGワードが存在します。このワードが書いていあると大抵報告書としては落第点だと思っています。そんなNGワードをいくつか紹介します。

総点検

総点検って、多分、大掃除、くらいの意味しかないです。

全部とは何かを決めるのは難しくて、必要な要素を全て挙げていくこと自体が本来は作業なのですが、「もー、全部！」みたいに短気を起こして、目につくところを片っ端から対応していく様を言います。

こういうことをすると、十中八九漏れます。なぜなら、優先順位をつけていないから、重要・緊急であるものが後ろ廻しにされる確率が上がるからです。

それより、重要・緊急なものをリストアップし、それだけは絶対に漏れないようにするほうが、コストが限られている中では最善策です。

徹底

徹底って、すごく前向きさにあふれている言葉なんですが、よくよく意味を考えると、お気持ちなんですよね。この対応策を徹底します！、何て言いますが明日には徹底しても、一年後に徹底しているかまではこの言葉は何も保証しません。

対策に「徹底」と書かれていたら、即、私は書き直させますね。どう徹底するかの仕組みを書き出し、徹底と言う言葉は外すように、と。

そうすると、全然徹底する方法論は考えていなかったりして、便利な言葉である一方、何の意味も持たない言葉でもあります。

丁寧に

今後、丁寧に対応・・なんて言う時のその丁寧って、何を示すのでしょうか。

これもお気持ちです。

失敗するときは、丁寧にやってもダメです。むしろ丁寧にやらなくても失敗しない方法を考えるのが対応策です。

気持ちが丁寧なのではなく、具体的なプロセスが細かく気が配られていれば、別にわざわざ言う言葉でもありません。

強化する

この、強化という言葉にはウソが多いです。

現状どうで、未来はどうなのか。これを誰でも理解可能な表現で示すことができれば、それ自体が強化であり、中身を示さず「強化します」なんて報告書はボツです。

例えば、「監視を強化いたします。」という文において、じゃあどういう風に監視を強化するの？、と聴くとします。それは・・、と、そこから先のことを知りたいのであって強化するキリッじゃないんだよ、と思うことしばしばです。

整備する

整っているのか、備わっているのかは、読み手が判断することであり、整備しますで片づけられても訳が分かりません。

これも、報告書を書く側のお気持ちであって、中身を表現することで、「おお、整備したんだね」と言わせてほしいですね。

顧客目線

顧客目線でオペレーションを見直します、みたいな使われ方をします。

この言葉を使われると、今まで顧客目線じゃなかったんかい・・と思ってしまいますね。

これは、改善策ではなく、むしろ今まで欠けていたことを恥じるべきで、顧客の前で堂々と言うことではないと思います。

とりあえず考え付くまま6つを例に挙げました。

結局は全て、言葉や精神論でごまかして、具体的なTo Do、プロセスを明らかにしない態度が裏にあると思います。なぜそうなるかというと、そこまで深掘りできていないからというのと、そもそも報告書を書く人が無知、ということの２つあります。

もう、謝る方も謝られる方も両方やったのでわかりますが、顧客は別に、誠心誠意謝って欲しいなんてほとんど思っていなくて、それより原因究明、対策の立案、そして実施を、スケジュール感を持ってやってほしいと思っています。

いくら土下座したって、システムや運用保守のプロセスが良くなるわけじゃないですからね。

ところが報告書では、それをぼかしてくる。

意外と、大会社の報告書すら、ちゃんと書かれていないことが多いので最近いつも読むようにしています。具体的な例はあえて出しませんがここ最近の案件を見ていくといろいろありますので、興味があれば調べてみてくださいね。

フリーランスが2023年10月1日に導入されるインボイス制度で窮地な件

二日くらい前のTwitterで、「インボイス制度がヤバい」と聴いていたので、少し勉強してみた。ほとんどのフリーランスを潰しにかかっていると。いやあ、そりゃあ言い過ぎでしょう、またまたネットはいつも大げさだねぇと思ってたかをくくっていたのですが、情報収集すればするほど、これは確かにヤバいですよ。

何がヤバいって、おそらくほとんどのフリーランスに発注していた担当者は、これはインボイス制度実施後は企業に頼んだ方が絶対いいな、と思うはずです。もしくはフリーランスを契約社員にするなど、給与で支払った方が良いと言う判断もあろうと思います。

インボイス制度の専門的なことをここで話すと少し難しい数字の話になるので、この記事ではできるだけわかりやすく順番に話します。だいたいの概要をつかんだ後に、専門的な記事を読めばより正体がわかるでしょう。

で、なんで冒頭のようにフリーランスに頼みたくなくなるのか。これは、フリーランスは今までは年間の売上が1,000万円未満なら消費税を支払う必要が無い、ということが重要なポイントになります。

でも企業のシステム開発などで考えればわかると思いますが、ユーザーが10億円のシステム構築をSIerに頼んだとすると、最終的に国はその10%の1億円を消費税として徴収したいと思いますよね。だから、ユーザーは11億円をSIerに支払います。

これで、SIerが1億円を消費税として国に納めるかというと違っていて、10億円のシステムを作るのに年収900万のフリーランスを100人集め1年稼働させたたとします。そうすると9億円をフリーランスに支払ったので、1億円がSIerの手元に残りますよね。で、1億円のうち10%を消費税としておさめますから、1,000万しか消費税を支払わないことになります。

お、それは国はお困りになりますよね。だってユーザーは1億円分消費税を払っているんだから。残り9,000万円はどこにいった、と。ここで本来ならば、年収900万のフリーランスたちには実は990万支払わないとおかしいんです。増えた90万は消費税です。そして、本来はフリーランスは90万を消費税として納めたら、90万x100人、つまり9000万円がここで国に消費税として合計徴収されるはず、でしょ？。

しかしここで邪魔になるのが「年間の売上が1,000万円未満なら消費税を支払う必要が無い」っていうルールです。フリーランスたちは消費税免税だー！って支払わないものですから、ユーザーが消費税を1億円支払っても、国には1億円どころか1,000万円しか入らない現象ってのが起きてしまっていたわけです。

そこで「インボイス制度」ですよ。

SIerが消費税を計算するときに、売上から仕入れに使ったお金を引くというのは、上に書いた通りです。ここではフリーランスに支払った金額を引いてましたよね。

インボイス制度施行後は、ここでのSIerは消費税を計算するとき、免税対象のフリーランスに使った金額を、売上から引けなくなってしまうのです。

つまり、消費税が免税のフリーランスの消えた消費税分は、SIerが支払えよ、というそんな制度です。免税対象者を抜け道にした消費税節減ができなくなる、ということです。

インボイス制度施行後、SIerの立場だったらどうするか。

①フリーランスに支払っていた分にかかるだろう消費税をSIerが払ってあげる

これしかなくなるんですが、SIerからすれば実質10%値上げと同じになるんですね。でもフリーランスの懐に入るのはこれまでと同じ金額。

で、SIerの予算は決まっているでしょう？。そしたらおそらく10%程度の値切った金額で発注をかけてくるようになるはずです。

年間の売上が1,000万未満のフリーランスで、しかも10%値切るって結構な金額。その上そこから所得税や社会保険料も支払わなければいけないですからね。

もしくは、

②フリーランス側もちゃんと消費税を支払うか

です。そしたら企業は売上から今まで通り引けるので、今まで通りの金額で発注してくれると思いますが、今度はフリーランス側が受け取る金額から消費税を払わなくてはいけなくなる。つまり、フリーランスが消費税を乗せて契約しないと割に合わなくなる。

これ、どこからどう見ても、1,000万円未満のフリーランスの人にはインボイス制度って何のメリットもないのは必然ですね。ちなみにこれまで1,000万円以上稼いでて消費税を支払ってきた人には何の変化もありません。

・・・と、ここまでの概要は、以下のページで勉強しました。

wezz-y.com

繰り返しますが、2023年10月から施行です。

実質、売上1,000万円未満の消費税免税が無くなるのと同じ意味を持つよな・・。と思っています。フリーランスより、企業で稼ぐ方が全然いいように思いますし、1,000万円以上のフリーランスが成り立つなら起業して会社にしたほうがこちらもメリットが多いように思います。

いつの間にこんなことに・・、と勉強になった件でした。

AWS、Direct Connect障害の報告書を意訳してみた

はじめに

2021年9月2日に話題となったAWSのDirect Connect障害について、詳細なレポートがAWSから発行されています。

aws.amazon.com

ただ、日本語がちょっと読みにくいと感じたので、わかりやすく意訳してみました。

内容についてはうのみにせず、原文をお読みください。

・

・

・

以下、意訳

--------------------------

日本時間2021年9月2日に東京リージョン（AP-NORTHEAST-1）で発生した AWS Direct Connect サービスの中断に関する追加情報を提供いたします。

（事象）

日本時間2021年9月2日午前7時30分以降、Direct Connect をご利用中のお客様が、東京リージョンに向かうトラフィックについて、断続的な接続の問題とパケットロスの増加が発生しました。

この事象は、「Direct Connect ロケーション」から、「顧客のVirtual Private Cloud（VPC）が存在する東京リージョンに属するデータセンターネットワーク」へのパスの中にある一部のネットワークレイヤーで、あるネットワークデバイスに障害が発生したことが原因です。

お客様は午後12時30分に復旧を観測しはじめ、午後1時42分に接続の問題は完全に解決されました。

AZ間のトラフィック、リージョンへのインターネット接続、AWS Virtual Private Network (VPN) 接続 (一部のお客様が Direct Connect へのバックアップとして使用) など、他のすべてのネットワーク接続は影響を受けませんでした。

他の AWS リージョンへの Direct Connect トラフィックも影響を受けませんでした。

（経緯と暫定対応）

2021年9月2日午前7時30分に、AWSのエンジニアは、お客様が東京リージョンに接続する Direct Connect のパケットロスの増加について内部アラームを検知しました。

このアラームにより、Direct Connect ネットワークの単一レイヤー内にあるいくつかのデバイスの障害によって、事象が引き起こされたことを特定しました。

これらのデバイスはトラフィックを正しく転送していませんでした。

ですが、障害が発生したネットワークデバイスは、機器障害時に自動削除を行う通常のプロセスを通じてネットワークから除外されませんでした。

その代わりにこの自動プロセスは、通常よりもデバイスの故障率が高いことを検知し、エンジニアに調査し修復措置を講じるよう警告しました。

AWSのエンジニアは、この警告を受けたとき、このレイヤに十分な冗長性があると判断しました。正常なデバイスでトラフィックを処理できるようにするために、問題のあるデバイスを手動でサービスから除外しました。

並行して、チームは故障の原因を調査していました。

問題のあるデバイスを除外することで一時的に修復しましたが、その後いくつかの他のネットワークデバイスでも同じ障害が発生しました。

その結果、Direct Connectを利用中のお客様のネットワークに輻輳、接続障害、またはパケットロスの増加が発生しました。

AWSのエンジニアは、故障したデバイスをリセットして徐々にサービスに戻すなど、いくつかの緩和を試みました。

しかし、障害は継続しました。

AWSのエンジニアは適切な機器能力を維持し、顧客への影響を完全に軽減することができませんでした。

AWSのエンジニアは障害を引き起こした可能性のある最近の変更対応を確認しました。

午後12時までに、AWSのエンジニアはこの障害の原因は以下の２つが起因しているのではないかと考えました。

①頻度の低いネットワークコンバージェンスイベント（経路情報の交換イベント）

②ファイバー切断に対するネットワークの反応時間を最適化するために導入された、新しいプロトコル

この新しいプロトコルは何ヶ月も前に導入されそれ以来問題なく運用されていました。

AWSのエンジニアは、結論として、今回の障害がDirect Connectネットワークのあるレイヤーを構成するネットワークデバイス上において、新しいプロトコルと新しいトラフィックパターンが相互作用して発生したと考えました。

AWSのエンジニアは、問題が発生している単一のAZでこの新しいプロトコルを無効化しました。

結果として障害の状況は解消し、持続的なリカバリーが確立したことを確認しました。

並行して、東京リージョン全体に展開するための変更対応を準備し、実施しました。

お客様は午後12時30分よりアプリケーションの復旧を確認し始めました。

そして、午後1時42 分に影響を受けたネットワークデバイスが安定した動作状態に復元され、Direct Connect サービスが通常の動作に戻りました。

（根本原因と対応）

新しいプロトコルを無効にすることでこの事象は解決しましたが、エンジニアリングチームは根本原因を特定するために引き続き取り組んできました。

この事象は、ネットワークデバイスのオペレーティングシステム内の潜在的な問題によって引き起こされたことを確認しました。

このバージョンのオペレーティングシステムでは、ネットワークのフェールオーバー時間を改善するために使用される新しいプロトコルが有効になります。

新しいオペレーティングシステムとプロトコルは、以前から実稼働環境で正常に実行されています。

AWSは、オペレーティングシステムを変更し新しいプロトコルを AWSネットワークに導入するときには、制御され、自動化され、試験され、計測された一連の手順を実施しています。

この手順は、専用の試験環境での一連のストレステストから始まり、ネットワークデバイスの有効パケットと無効パケット(不正な形式のパケットなど)の両方に対する回復力を検証します。

試験環境でのテストで特定された異常は、新しいコードが本番環境にリリースされる前に調査し根本原因を特定し修復します。

しかし、この包括的なテストでも試験環境ですべてのトラフィックとパケットの順列をテストすることはできません。

したがって、AWS はネットワークデバイスのオペレーティングシステムの変更を、段階的かつ制御された方法で本番環境にリリースするデプロイ手順を使用します。

このデプロイ手順では、アップグレードされたデバイスが実稼働トラフィックを処理を行い始めたとしても、アップグレードされていないデバイスに容易に切り戻すことができるようにします。これを前提に、個々のデバイスをアップグレードしていきます。

段階的に本番環境にデプロイしていく際は、アップグレードされたデバイスは、パフォーマンスの問題や機能エラーについて、広範囲に監視されます。

この段階的にアップグレードしていくデプロイ手順は何度も正常に使用されており、今回の最新のデバイスオペレーティングシステムのアップグレードでも遵守されました。

新しいプロトコルとオペレーティングシステムは、2021年1 月に初めて実稼働環境に導入されました。

過去8か月間にわたって、この新しいプロトコルとオペレーティングシステムは、すべての AWS リージョンで徐々に実稼働環境にリリースされ、潜在的な問題を示すことなく Direct Connect のサービスを提供してきました。

そして、過去数日間で、AWSのエンジニアはネットワークオペレーティングシステムの欠陥を特定し、問題を引き起こす非常に特殊なパケット属性とコンテンツのセットが必要であると判断しました。

これらの条件は非常に特殊で稀であるものの、このシグニチャに一致するある顧客のトラフィックによってこのイベントが発生しました。

悪意のある振る舞いがあったとは考えておりません。

我々は、AWS 東京リージョンでこの問題が発生した新しいプロトコルを無効にしました。

また、この変更を他のすべての AWS リージョンに慎重に適用するために、お客様に影響が出る前にこの問題を検出して修復するための拡張方法も開発しました。

この問題によるお客様へのさらなる影響はないと確信しています。

（最後に）

AWS のサービスが日本のお客様と多くのビジネスにとって重要であるかを理解しており、今回の事象による影響を心からお詫び申し上げます。

AWS は、高い可用性でサービスを運営してきた長年の実績があり、お客様の信頼を維持し、お客様とビジネスに必要な可用性を達成するために全力を尽くします。

※意訳は以上です

--------------------------

・

・

・

ちょっと、感想

よく「ハードウェアの問題」と言いますけど、この文書のとおり完全にソフトウェアの問題ですよね。

ハードウェアの問題と言って、ばっちりハードウェアの問題なんて最近だとなかなか起きません。昔は、熱の問題で電源が停止したり、ネットワーク機器であればポートが使えなくなったりといろいろ体験したことはありますが、最近のハードウェアはいたって優秀な印象です。

一方で、ハードウェアが高機能化しました。高機能化の理由は、その中にあるソフトウェアが進化したことに尽きます。

ソフトウェアですから、不具合の一つや二つ抱えていても不思議ではなく、かつ、冗長構成にしていても、両方の機器に同じソフトウェアを入れるので、両方等も問題が起きちゃう、そんなロジックです。

もし神経質に設計するなら、違うベンダーで別ルートを作るという方法もありますが、それだと管理も2倍大変になります。

悩ましい話だな、と今回の話を見ても思いました。一方で、よくこんな短時間で原因までたどり着き切り戻したもんだな、と思いました。

「性能問題」ハードウェアの問題だけど単純に交換しても治らないケースのお話

今日（2021/9/1）は、AWSで障害が起き、かなりの会社が巻き込まれて話題になっていました。

www.nikkei.com

米アマゾン・ドット・コムのクラウドサービス「アマゾン・ウェブ・サービス」（AWS）で2日、障害が発生した。複数の証券会社や大手銀行のアプリなどで接続しにくくなったほか、NTTドコモで一部サービスが利用しづらい事象が起きた。全日本空輸（ANA）や日本航空（JAL）でも不具合が生じ、影響が広がった。

この前のみずほの件と言い、システム基盤の問題が国民生活に影響を与えることが顕在化し、問題意識も高まっていますね。

今回の問題は「コアネットワークデバイスに問題が発生」という表現で語られているのですが、一般の人々や、インフラに関わったことのないIT業界の方は、こう思うのではないでしょうか。

「壊れたのなら、新しいハードウェアを持ってきて交換すれば、動くでしょ。それができないっていうのは、保守体制がおかしいんじゃないの？。交換部品を用意していないとか、交換する人員が不足しているとか。気が緩んでるんじゃないの？。」

この手の種類の不満はよく聴きました。保守担当者側としては、

「ま、コンピューターなんで、新しい部品を交換するだけじゃ動かないんですよね。複雑な設定も中に入っているし、交換する機器にはそれを移し替えなきゃいけないし、配線も元に戻さなければいけないし、復旧作業も手順があるのですぐにはできないんですよ。もちろん、すぐに作業は始めてるんですが、時間はかかるのでご承知ください。」

打ち返しとしてこれでいいとしても、それなら・・というので数時間は待ってくれるのですが、実際はもっと復旧に時間がかかる場合があります。

なぜ時間がかかるのか。みずほ銀行の場合も前日の夜に発生したので、翌朝の開局には間に合うと思っていたけど間に合わなかった、ですよね。

ここは、直接今回のAWSやみずほとは関係なく、時間がかかる障害対応のケースが１つあるので紹介しておきます。

「性能問題」です。

機器の性能限界を超えた要求を、システムが要求した時に起こります。

システムを構成するネットワークの中に、ある機器があったとします。システムが正常に動くためにはこの機器を通ることが条件だとします。とすれば、この機器、必ず何らかの方法で冗長化しますよね。例えば2台構成にする。そうすれば1台が停止したとしてももう1台が処理してくれる。

単純なハードウェア故障ならそれでもいいのですが、性能問題の場合はそうはいきません。動いている方（アクティブ機）と、待機している方（スタンバイ機）、両方の機器は性能が同じだからです。

アクティブ- スタンバイの関係の場合、アクティブが性能上限のため停止します。そうするとスタンバイに動作が切り替わります。しかし同じく性能上限で停止します。そしてもともとアクティブだった方に切り戻るのですが、全く同じことが起こり、シーソーのようにギッタンバッタンするのです。

この場合、機器自体は壊れていません。だから交換しても無駄なのです。

この話を顧客にすると、必ずこう言います。

「もっと性能の上の機器に交換できないの？」

しかし、保守というのは、壊れたら新しい機器に交換するというのが原則です。家電だって壊れて保守期間内だからってお店に持って行っても、グレードアップはしませんよね。

どうするかというと、ベンダーに、至急性能の上の機器を購入できませんか？、と緊急に相談します。もし在庫があればいいのですが、この機器の購入費用は当然かかってきますので、コストを払ってでも障害対応を優先するかどうか、ここでビジネス上の判断が必要になってきます。

昔私もそういう目にあったんですが、「上位のモデルはあるにはあるんですが・・・、今イスラエルにしかモノがないんですよ・・。空輸したとして・・。」みたいな話をされて驚愕したことはあります。だって、すぐに対応したいのにイスラエルとは！！？。

さて、性能問題を機器のグレードアップで回避できない場合や、すぐにでも復旧させなければいけない場合どうするでしょう。それは、システムの構成見直しです。性能上限を迎えるということは、何かの処理で高い負荷がかかっているのかもしれません。システム全体のトランザクションを見直し、ソフトウェア側の設計変更で逃げられないか考えます。インフラ担当もアプリケーション担当も、ここで頭をひねります。例えば、ある処理だけその機器を通さずに、同じ性能の別の機器を取り寄せて、そちらを通せないか。負荷分散で性能問題を一時的に解決するというのはよく使う手です。

でも、障害対応の途中でシステムの設計全体に手を付けるというのは、実は究極の選択だったりします。構築中はちゃんと設計図を書いて、実装して、テストをして、ようやく本番リリースします。しかし本番運用中のシステムにおいては、スピード重視のため準備に時間が欠けられません。いわゆる「火消し」と言われる人は、このあたりの判断を天才的に切り抜け、鎮火したときに崇められます。

ということで、性能問題による障害対応の難しさを話してみました。これ、じゃあ性能問題が起こらないために、性能試験はやらないの？と言う話は必ず出ます。いや、やります、性能試験。しかし、構築時の性能試験はあくまでも、机上の数字であり、データも本番データとは違います。本番時にどんなデータがどのように流れるかは、時間とともに変わっていくので、試験は通っていたけれども想定していない形で機器の性能上限を超えてしまった、というのはよくある話です。

この手の問題は、「過去安定していて実績のあるシステム」に実は起こりがちです。安定しているからこそどんどんシステムは肥大化していく。肥大化していった先に、ある場所に偏って負荷がかかっていって、ある日顕在化します。しかしもう増やしてしまったシステムはおいそれと取り除けない。

だんだんと大きくなっていくシステムは、ぜひどこかにシングルポイントとなる場所がないかどうか点検すべきでしょう。そこが冗長化されたとしても、両系が性能超過してしまったら手が付けられません。性能を超えないように、システムを分割して使うようなことを初めから考えるべきでしょう。

インフラ基盤の問題は、ハードウェア交換すれば治る障害ばかりじゃない、というお話でした。

企業のDocker Desktop商用利用は一部を除き有償化されるというニュース

コンテナ開発環境の代名詞、Docker Desktopですが、本日、トップ画面に気になる内容が書かれています。

Dockerサブスクリプションサービス契約が更新されました。

私たちのドッカーサブスクリプションサービス契約は、Docker Desktopのための条件への変更を含んでいます

・中小企業（250人未満の従業員　かつ　年間売上高$1000万ドル以下）、個人的な使用、教育、非商用のオープンソースプロジェクトの利用の場合は、無料のままです。

・大企業でのプロフェッショナルな使用には、ユーザーあたり月額わずか5ドルの有料サブスクリプション（Pro、Team、またはBusiness）が必要です。

・これらの条件の発効日は2021年8月31日です。Dockerデスクトップを使用するために有料サブスクリプションが必要な場合は、2022年1月31日までの猶予期間があります。

・Docker Pro、Docker Team、およびDocker Businessのサブスクリプションには、 DockerDesktopの商用利用が含まれるようになりました。

・詳細については、よくある質問をご覧ください。または、最新のブログをお読みください。

つまり、もしあなたが、会社でDocker Desktopを商用開発の中で使っていて、中小企業に当てはまらないのであれば、2022年1月31日までに有料サブスクリプションに契約しないと、契約違反になってしまう、ということですね。

年間売上高$1000万ドルって、11億円くらいですので、結構際どい金額をついてきたなという感想です。

公式ブログにはもっと詳しい情報が書いてあります。

www.docker.com

FAQも公開されています。

www.docker.com

無料サブスクリプションは、Docker Personalという契約だそうです。

有料サブスクリプションは、Docker Pro、Docker Team、Docker Businessという3つに分かれます。

・Docker Proサブスクリプションには、生産性を向上させたい個々の開発者向けのツールが含まれています。月額サブスクリプションは、ユーザーあたり5ドルから始まります。

・Docker Teamは、ワークグループや小規模な開発チーム向けに設計されており、コラボレーション、生産性、セキュリティを強化する機能が含まれています。月額サブスクリプションは、ユーザーあたり7ドルから始まります。

・Docker Businessは、集中管理と高度なセキュリティ機能を必要とする中規模および大規模企業のニーズに合わせて設計されています。月額サブスクリプションは、ユーザーあたり21ドルから始まります。

下記のページに、プランごとの機能の差が紹介されています。

www.docker.com

さて、「もし有償サブスクリプションの範囲なのに、黙って無料で使い続けたら」どうなるのでしょうか。きっと誰もが知りたいところだと思います。

以下が、更新された契約書のページです。

www.docker.com

この文が全てかな、と思います。

BY INSTALLING, DOWNLOADING, OR OTHERWISE ACCESSING THE SERVICE YOU EXPRESSLY ACCEPT AND AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE AN INDIVIDUAL AGREEING TO THE TERMS OF THIS AGREEMENT ON BEHALF OF AN ENTITY, SUCH AS YOUR EMPLOYER, YOU REPRESENT THAT YOU HAVE THE LEGAL AUTHORITY TO BIND THAT ENTITY. IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT AGREE WITH THE TERMS OF THIS AGREEMENT, YOU MAY NOT USE THE SERVICE EITHER YOURSELF OR ON BEHALF OF THE ENTITY.

サービスをインストール、ダウンロード、またはその他の方法でアクセスすることにより、お客様は本契約の条件に明示的に同意し、同意するものとします。雇用主など、事業体を代表して本契約の条件に個人が同意する場合は、その事業体を拘束する法的権限があることを表明します。そのような権限を持っていない場合、または本契約の条件に同意しない場合は、自分自身またはエンティティの代わりにサービスを使用することはできません。

他の企業でもやっていますが、あくまでも紳士協定であり、インストールやダウンロードは今も、誰でもできるようになっています。

ただ使う場合はこの契約に基づく必要があり、仮にとある企業が契約違反して利用していたら、過去利用分の積算と、損害賠償的な請求をされるのは間違いないかなと思います。

なお、FAQを見ると、政府など公共機関向けプロジェクトで利用している場合は、必ず有償になるようですのでお気を付けください。

私は政府機関で働いていますが、開発者に有料のDockerサブスクリプションが必要ですか？

はい。2022年1月31日以降、Docker Desktopを使用する代理店の各開発者は、Docker Pro、Team、またはBusinessのサブスクリプションが必要になります。猶予期間が終了した後もDockerDesktopを引き続き使用できるように、2022年1月31日より前に有料サブスクリプションへのアップグレードの計画を開始することをお勧めします。

「2022年1月31日までの猶予期間」を意識して、自社が契約違反となっていないか、よく把握して利用しましょうね。

Chatworkの新しいブランドムービーが良くできていたので感想を書いてみた

国産ビジネスチャットの代表格Chatworkが先ほど公開したブランドムービーが良くできていました。

lp.chatwork.com

コミュニケーションが活性化すると会話がはずむように、
中小企業の現場を活性化させていくことで、
仕事をもっとワクワク、心がはずむものに変えていきたい。

ユーザーの働き方を深く理解し、
時間や場所に縛られない働き方の提供を通して、
ビジネスを活性化させる存在でありたい。

そんな想いをムービーで表現しました。

せっかくなのでフルバージョンを貼り付けておきます。

www.youtube.com

このムービーではChatWorkだけでコラボレーションが成立していますが、他のアプリも使いながら、こういった、プロジェクトメンバーが物理的にも離れていても仕事がつながり、時間の制約からある程度自由になりながら仕事をするというのは、私個人はとても普通のことになっています。

もともとは、私の仕事がシステム運用で、コンピューターは24時間365日動くのに、人間の方は勤務時間もあるし通勤も、そして休みもある。

この矛盾を解決するために、家でもシステムにアクセスできるようにしようと、ここ10年くらいは、メール、VPN、リモートデスクトップに始まり、そこからこのビジネスチャットや、課題管理ツールなど、いろんな試行錯誤を繰り返し今にあります。だから、このコロナ禍のテレワーク対応などはすごく簡単に移行できました。変わったことと言えば、Web会議を頻繁に使うようになったことでしょうか。相手の表情を見られるというのは実は重要な情報ですから。でも、いつもWeb会議を立ち上げておくなんて、仕事の邪魔で集中力を妨げますから、普段はビジネスチャット中心です。このムービーの世界観ですね。

でも多分、大多数の仕事場においてこのムービーのようにはなっていないと思います。まだ電話中心あとはメール、という場所もあるでしょう。

そういう職場に、いくらITのキラキラしたツールをいっぺんに導入しようとしても、うまく行かないと思います。

それよりも、導入したらどうなるか、どんな仕事になるかを、現場の人々が想像できる必要がある。使ってみたら仕事が便利になり、何か大変だったことが楽になった、という実感を積み上げていく必要があるでしょう。

今の時代、電話がなぜ便利か、ということを考える人は誰もいません。

でも、ビジネスチャットであったりWeb会議であったり課題管理ツールと言ったものが、なぜ便利かというのは、実は多くの人々が、想像すらしていないという現実です。

だから、このようなムービーにしろ、もしくはドラマの一場面にしたりと、労働文化として定着させていくことについては、実はまだまだ、西暦2021年なのに、まだまだ原始的な時代に滞在しているのではないか、と思います。

IT業界が今、成長していることの一つの理由に、こういったITツールを使った新しい働き方を独占しているから、という考え方もできます。我々は便利に使っていますが、大多数の非ITの人々は、まだそのメリットもわかっていなければ、誰かがそれを使っている映像も見たこともない、そう考える必要があります。

個々の会社の情シスが、非ITの人々にどう使ってもらうか頭を抱える、そんなストーリーをよく聞きます。局地戦ではなく、もっと成長したIT関連の企業群が新しい働き方を文化として根付くように、単なる営業活動ではなく文化活動をするべきなのかもしれません。

本来は、どこか一か所に複数の会社同士で集まり、理解を深めていく場が必要なのですが、このコロナ禍でそういったことができません。ですからこういったChatworkのブランドムービーのような作品が非ITの人々に届き、たくさんの人々の理解が加速することを本当に希望します。

「こんなに便利なんですよ！」ってどの会社でも苦労しているの、無駄じゃないですか？。

IT業界に25年いて思うけど結局、基本が大事。

大学を卒業し、新卒のころからIT業界に入り、およそ25年経つ。

長い時間いないとわからないことはたくさんある。

結局、ディスプレイとキーボード、そしてマウスというこの入出力3点セットは何もかわっていない。ブラウン管から液晶になった上に解像度が上がりたくさんの情報が表示されるようにはなったけど、キーボードやマウスはちっとも形を変えていない。これは面白いことだよね。だって先進技術！とか言ってても外形はほとんど変わっていないんだから。VRとかスマホとかあるけど、仕事としてはパソコン一択だ。そしてそのパソコンの形は変わっていない。それぐらいこの3点セットが洗練されていたということだと思う。パソコンの処理能力はどんどん上がったけど、人間の処理能力は全く変わっていないので、人間のインターフェースがそこまで変わることはないんだよねという思考に行きつく。

昔と今とで大きく変わったのは、労働環境だと思う。昔は人間は人間扱いされなかった。仕事が終わらないんだったら会社に泊まってでも仕上げろという指示がパワハラ扱いされなかった。時計が24時を回るころ、終電も近いというときに会社を出るのが、社会人、というのも当たり前だった。そこで発生する残業代をちゃんと払えるか払えないかで、いい会社と悪い会社が分けられた。あの会社は残業代ちゃんと出るんだ、いい会社だね、と言われる時代だった。

特に開発部門がそういう傾向にあったように思う。納期があってそこまでに作る。それなのに間に合わない。業界がまだ未成熟で、プロジェクト管理方法も無ければ、開発環境も貧弱だった。どんなに優秀な人でもスケジュール通り進めるのは至難の業だった。労務管理も適当だったので、そこはもう気力体力時の運の世界になっていた。私は何を思ったか、新卒の段階で開発部門の組織を希望せずITサポートの組織の方を希望していた。結果的に大手のサポート部門に潜り込めることになった。

大手のサポート部門は超絶ホワイトで、残業をほとんど行わず働くことができた。私の二十代は残業がほとんどない。多分あの時代のIT業界でそういう環境で過ごせたことが私のラッキーの一つになっている。もし、残業上等休日出勤上等の世界で二十代を過ごしてたら今の私にはたどり着いていないだろう（どうなっていたのか興味はあるが）。

三十代になってサポートからインフラ運用の仕事に変わったのだが、そこは大変だった。二年ほどは残業時間が膨らむ仕事場にいたのだが、これはこれで経験になっている。この二年間で現場の運用を立て直し、残業があまり発生しない世界に改善することはできたが、リーマンショックのおかげで急に職場を去ることになり、世の中の厳しさを教えられた。大変な職場だったが二十代に身に着けた知識が活かせたり、システム運用の厳しさを知ったことで、その後のキャリアの基礎となっている。

こうやって自分のキャリアと25年の前半部分をふまえ、そして今を考えると普遍的な原則のようなものが見えてくる。

・基本的な情報処理技術はほとんど変化がない。

・ハードウェアの仕組みはほどんど変わっていない反面機能は恐ろしく向上したため、昔アイデア倒れで終わったことが、今そのまま実現できている事例が多い（AIやビッグデータ、インターネットでのソフトウェア配信など）。

・WEBアプリケーションサーバーや、データベースの仕組みは、基本については登場時からほとんどかわっていない。

・一方で、実装方法はどんどん変わっている。同じ言語でも登場時と今では全然使い方が違う。

・違う言語であっても一つの言語をマスターしていれば比較的短時間で使えるようになる。そうじゃない言語はすぐ廃れる。

・昔は構築したら何も変えないでそのまま使い続けるのが主流だった。今は、どんどん改善・改築してアップデートしていくようになっている。

昔は結構職域のようなものがはっきりしていて、プログラマー・システムエンジニア・サーバーエンジニア・ネットワークエンジニア、みたいな分業体制だった。かつその中でどんなスキルを持っているかを明記し仕事するようなスタイルだった。ところが最近は、クラウドも現れてその境目が溶けだして、開発の上流・下流、そしてインフラぐらいしか区別はないと思う。これは実装方法が流動化していて、せっかく何か特定の技術をおぼえても来年にはまた新しい方法がでてきているかもしれないし、一生食べていくような保障が何もないところから来ていると思う。

古い技術にしがみつく、ということがどんどんできにくくなっている。

ただ、基本さえできていれば、技術はすぐに使える方向に進化していっている。クラウドも、ノーコード・ローコードも、そして最近の開発技術もどんどん、「すぐ使える」がコンセプトとなってきている。

この「すぐ使える」というところだけを切り取って、「未経験でもすぐ戦力なれる／高収入」みたいな宣伝文句が巷で流行しているようだが、俯瞰的に考えると、基本がない人は、技術がどんどん変わっていく様子に追随できなくなるだろう。それこそ、そのツールしか使えない技術者の出来上がりだ。それでは短い期間でIT業界をすぐに退場させられてしまうことになりかねない。

だから、今こそ基本が大事になっていると強く思う。以前こういう記事を書いた。

www.orangeitems.com

最近は、基本情報処理技術者試験もCBT方式と言って、パソコンに回答する方式に変わって来たようなので、ますますお勧めだ。

基本さえ身に着けておけば、業界がどんどん様変わりしても、どんどん追随していける。昔と違って、人間もアップデートを頻繁にしていく時代に変わっているのだ。そのためには基本が必要となる。

※興味を持った方のために良さそうな本を置いてみる。はじめは「やさしそうな」本から入るのがお勧め。

キタミ式イラストIT塾 基本情報技術者 令和03年

以上は私の経験を踏まえたIT業界イメージで、私にとっては当たり前のことだけれど、他人にとっては別世界なのかもしれないので、誰かの役に立つかも知れず書き留めておきたいと思う。

システムエンジニアは今こそ、顧客の業務知識を勉強するべきと考える理由

IT業界にいる人って、自分の業界って何ですかって言われると困ることがあるんですよね。アンケートなどであなたの業界に〇をつけてください、っていう質問で、IT業界っていう選択肢はないことが多いです。どこにつけるかといいえば「サービス業」です。IT業界イコールサービス業っておかしくないですか。

www.manpowergroup.jp

サービス業とは、顧客の「◯◯したい」「〇〇してほしい」といった様々な要求にこたえることが仕事です。専門的な技術や知識、体験など、提供しているものに形はありません。生産と消費が同時に起こり、その場に応じて臨機応変に対応しなければならないという特徴があります。

すごくぼかして言えば、ユーザーが「◯◯したい」「〇〇してほしい」といった様々な要求にこたえるって、SIerがやっているSIの仕事にすごくにてますから、サービス業かなーって選ぶようになったんですかね。

でも、上記の文でもありますが、医療とか教育とか不動産とか、もう一緒にしすぎなんじゃないでしょうか。もう、業種はなんですかっていう質問自体をやめた方が良いと思います。もしくは、IT業という業種を誕生させるべき時なんじゃないでしょうか。

さて、このIT業界ですが、日本はアメリカや諸外国に比べて劣っているとメディアから酷評されがちですが、これはなぜなのか、考えたことがありますでしょうか。

Twitterでは各種の情報技術に対して資格試験を勉強しているとかこんな研究をしているとか、結構勉強熱心な方が多いです。経産省も50年近く情報処理技術者試験を継続していて合格された方もたくさんいます。技術者は結構育ったと思うんです。でも実装段階でどうも日本はやらかすことが多い。IT投資をしても満足な結果が出ない。そんな話をずっと聞いています。

この原因、心当たりはあるんです。

「どう実装するか」について、IT業界に所属している人が少なすぎるということです。システムを構築するときに要件をまとめますが、この部分に関わっている人より、どう設計するか。どう実装するか。どうテストするか。どう運用するか。要件定義後のフェーズに関わっている人の数の方がえらく多いのです。

大手SIerは最近、共創、DX、と言う言葉で顧客とともに要件を作り上げることを掲げていますが実際現場レベルにいる人々は昔と変わりありませんから、プロセスとしてはやはり要件定義から始めるのは変わりません。

要件定義においては、IT業界の純粋なテクニカルスキルだけでは仕事にはなりません。顧客が何に困っていて何を解決するかについて、言語化できることが最低条件です。だから要件定義をたくさんやっている人は、顧客の業務内容まで把握できるようになるんですね。それってITではないんです。むしろ顧客の業界のことを知ることになりますから、この経験を活かしてコンサルタントに肩書きを変える人も出てきます。

一方で、プログラミングの勉強、プロジェクトマネジメントの勉強、クラウドの勉強、ネットワークの勉強など、ITにもいろいろな幅広い技術知識があり専門的ですが、これら、さっぱり顧客の業務内容とは独立しています。

日本の抱えるITの問題は、まさに、業務とITの間のギャップにあります。IT業界にいる人は実装技術ばっかり勉強するので、顧客から降って来た要件を実装することにしか執着せず、その結果、「使われないシステム」ができあがってしまう。

それを見て一般人は、「なぜ日本のSIerは使われないシステムを量産するんだ」みたいな話を斜め読みし、SIerに対して悪いコメントを言うというのをよくSNSなどで見かけます。

それは、顧客がSIerにちゃんと要件を伝えないからだ、とか、顧客がシステムエンジニアを雇って内製すればいい、という意見も見ます。私はこれらも的外れだと思っています。顧客はITの専門じゃないので、ITで何を作れば問題解決できるかについて知識がありません。また、システムエンジニアを社内に囲って内製化しようとしても、そのシステムエンジニアが技術のことばかり勉強し、社内の業務に関心を示さなければ、SIerに投げるのと同じです。情報システム部門を子会社化して失敗するのは、子会社にしたことで業務と切り離されるので、降りて来たことしか実装しない受け身の会社になるからです。

結論として、IT業界の人々はもっと顧客業務のことを知るべきです。ベンダー資格等々ばかりに手を付けて専門家ぶる人のほうが私は過剰ではないかと思っています。それより特定業種に精通した標準的なITスキルを保持した人の方が今後重宝されるのではないかと思っています。

ITのスキルって、結構身に着けるのってコツというか経験が必要だと思います。だからこそ、顧客側にいて最先端のITスキルを身に着けるのは結構難しく、だから最近ローコードやノーコードなるものが流行し始めているんです。でも、システムを知っている人はわかると思いますが、ちゃんと業務に対して責任を持つシステムを構築するなら、伝統的なウォーターフォールで、プロジェクトマネジメントして対応したほうがリスクは少ないし、基幹システムは今でもそうでしょう。だから、私はIT業界のほうから、顧客の業務知識を勉強する方向に進んだ方が、より効率的に顧客のITに寄与できるはずだと思っています。内製ではなくて、です。

ま、その理屈で、業務知識が付いたシステムエンジニアが、顧客の情報システム部門に部長待遇で迎え入れられるケースが多いのも存じていますが。でも、IT業界側だって業務知識を身に付けて行くべきだと思います。