SaaSの拡大が意味するところ

 

インフラまわりに従事していると気になるのがSaaS領域が伸長していること。

 

cloud.watch.impress.co.jp

「オラクルはSaaSで勢いがあることをとらえて、一緒に仕事をしたいという人が増えている。ライバル会社の日本法人社長経験者が一緒にやりたいと言ってきたケースもある」などと述べ、外部からのタレント獲得が積極化していることを示した。

 

SaaSの一番いいのは、「サービスを使い続けることについて、ユーザーが、アプリケーション・ミドルウェア・OS・ハードウェア・基盤を一切考えないで良いこと」に尽きると思う。

ソフトウェアの分野はここ数年でかなり出来ることが増えたと思う。AIの進化とは関係なく、「順次進行」「条件分岐」「繰り返し」というプログラムの3つの基本構造。これらを人間の活動に置き換えることを、様々な領域で繰り広げ、人間が頭を使うことなく、コンピューターが代行可能となった。

ただし、ソフトウェアはミドルウェアやライブラリに依存する。それらはOSに依存するし、OSはハードウェアに依存する。ハードウェアもどの基盤に置くかで話が変わってくる。

ユーザーはソフトウェアを使いたいだけなのに、それを仕立て上げるためにたくさんのことを管理した上で、かつサポート切れを常に意識しなければいけない。

それらを全部考えなくて良くなるのが、SaaSの最大のメリットである。

逆に発生するリスクとしては、上記の面倒くさい管理コストがなくなったわけじゃなく、目の前から消えて、SaaS運営企業に移っただけということ。彼らが管理に失敗したりすると、思っても無い脅威にさらされることになる。例えばSaaS側にあったデータが漏えいしたり消失したりすること。ある日、突然利用できなくなり復旧に時間がかかること。諸般の事情で急激に利用料が上がり、しかし利用は止められないのでコストコントロールができなくなること。何しろ、リスクコントロールを全部SaaS運営側に移転してしまう。

それでもいい、という割り切りが必要だが、ポイントとしては経営を特定のSaaSに依存せず、代替手段を用意することが大事だろう。

メール・ビジネスチャット・プロジェクト管理などはSaaSの主戦場ではあるが、それが使えなくなったときに会社全体がフリーズするのはよろしくない。

かつ、SaaSの領域が基幹部分に染み出すに従い、運営企業の信頼度も重要になる。インフラから含めて実績のある大きな会社に頼みたくなるのは理にかなっている。扱うデータやプロセスが重要であればあるほど、それを扱う企業の責任が重たいのである。

一方、SaaSに任せる内容が、効率化のためであり無くなっても代替可能であれば、リスクを許容して、便利なものを選ぶのは理に適う。

 

結局のところ、ソフトウェアによる課題解決は各会社で膨張していて、SaaSを利用するケースが増えているということになる。ということは、今後SaaS運営企業で直面するのが、ユーザーに不便をかけず、サービスを継続する手段の確保が必要ということになる。OSやミドルウェアがサポート切れを起こすのを感じさせないこと。いわゆる運用保守のスキルが今後重要になって行く。新規構築時は最新を選べばよかったし、データも少ないが、リプレースは違う能力が必要とされる。リプレースが必要になるころにはデータは太り、利用していたソリューションは時代遅れのものも含まれるようになる。これを各社、未来に向けてちゃんとコントロールできるかどうか。

ユーザーとしてはかなり便利な一方で、SaaS運用側は拡大局面を考えると、まさにこれから直面する企業も多いと思う。ソーシャルゲームの分野では顕著だが、リプレースしないでサービスを終了してしまう判断も良く見られる。・・が、SaaSではきっとそうはいかないだろう。ゲームと違って、現実の会社活動の一部が依存しているのである。「ありがとうございました!」とは行かない。

たくさんのSaaS運営企業で、どう継続性を担保するか、たくさんのITエンジニアが試行錯誤していらっしゃると思う。したがってインフラ含め、仕事そのものの総量は減るどころか増えているが、SaaSの伸長によって働く場所が変わってくるんだろうな、と思う。

 

ITの内製化が進んでも、業界構造が変わらない理由

 

ここに、SES・多重請負の悪いところがたくさん書いてあるけれど。

 

anond.hatelabo.jp

 

私も15年前に、SESの自分の立場を呪い、元請に転職した人間だ。1度きりの転職だがここでエスケープして正解だったとは今でも思う。そのときに「どうせSESや多重請負の構造などジリ貧だ。いずれ滅びる。それなのにここに長居したら未来はない。」と決めつけて、出て行った。

その後はどうか。残念ながら、ちっとも無くなっていない。もう15年だ。

今「この業界は内製になるだろう、だからSESや多重請負が無くなる」という呪いをかけたところで、それはちっとも説得力がない。だって、後ろを振り返ってみても未だに、多重請負にしろSESにしろ、その世界観は崩れていないのだもの。

そもそもの話として、SESや多重請負の構造は小泉改革が作ったものではない。もっと昔、1990年代から根付いていた。パソコンがオフィスに入って来たのもその時代だ。1990年代はパソコン導入から始まり、社内LANを経てインターネットに終わったが、その当時の時代の変わり方を生で見られているのは大きい。そして、ITとはいつでもどの会社にとっても、「社外から買う道具」だった。むしろITとは言わず、OA(オフィスオートメーション)とも言っていた。ITという言葉が盛り上がったのは2000年のIT革命だ。

社外から買うという文化は1980年代のOAの普及が始まったころからなので、日本の会社が外部からITを買うのはごくごく自然だ。2000年ごろには基幹システムのオープン化ということで、社内にも情報システム部門を組織して、今のDXのようなことに取り組んだ。しかし結果を出せず、多くの情報システム部門が子会社化され、いつでも本社から切り離し可能な状態にするのが流行した。一部の子会社は既に外部のSIerに売却されたものもある。そのころのITはコストセンター扱いされたものである。

ところが、昨今のデジタル化によって、いやいや、いつまでも外にITを任せて置いたら、ビジネスモデルそのものがIT化する現代において、会社のアイデンティティーがなくなっちゃう、ってことでシステム子会社を本社に吸収したり、弱体化した社内IT部門に大量に中途採用を行い、イニシアティブを取り戻そうとしている。

というところまでは、ネットを見ていれば、わかること。

ただね、結局は内製化したところで、元請SIerがやってたことを社内で取り込むのが先で、その後の実装については、外注を頼まざるを得ない。年中開発やってるわけにはいかないので、元請SIerが人を必要としたことと同じ理由でユーザーが仕事を外注する。

この外注を受けられるところが、元の元請け経由であったり孫請けであったりして、きっと構造は全く変わらないと思ってる。内製が、社内で全部完結するっていう絵は厳しいのではないかしら。実装する人をずっと雇い続けるより、必要に応じて必要なスキルを持った人と契約してコーディングしてもらった方がいいよね、って話で。

で、この元請の機能を内製化して社内に持ったところで、これでさあ何を作るか、どうしたら経営に寄与するITができるか、みたいなところにコンサルが大量に入っていく。このコンサルというのが結局よくよく組織を見ると元請で、ああ、何も変わっとらんやん、ということになっている2022年なのである。

どうせ今後15年も構造は変わらないだろう。どの会社も、ITをコントロールしたいのであって、実装したいわけじゃないからだ。コントロールさえ失った丸投げ構造の反省に対して、コントロールできる丸投げに移っただけだ。そして丸投げされる側にいる人の仕事は切れない。なくならない。

だから、呪っても何も変わりはしないので、自分の立ち位置を変える努力のほうをした方が効率的ではないか、と私は思う。

 

それなら、ご発注いただかなくて結構です、という話

 

xtech.nikkei.com

Q.ユーザー企業の情報システム部門の責任者です。経理や人事業務はパッケージを利用しており、カスタマイズや追加プログラムの開発は大手IT企業のA社に発注しています。実際は、A社の下請けであるIT企業B社が対応します。今回新たに、サブシステムを追加することになりました。プロジェクト体制図から見るとプロジェクトリーダーはA社マネジャーですが、この人が顔を出すのは、定例会と費用提示のときぐらいです。付き合いの長いB社がいるので困ることはありません。開発費用の原価構造は分かっており、その点から見ても、丸投げにしてはプロジェクト管理費を含めて全体的に高いと思っています。

 

じゃあ、B社に直接、見積を依頼すればいいじゃないですか。

今後A社にお仕事を依頼しにくくなるからですよね。B社を連れてきたA社を飛ばすってことですから、道義上の問題とでもおっしゃりたいのでしょう。

そうじゃなかったら、A社に義理立てする意味はないんじゃないですか?。

で、多分B社はこういうんです。「直接はお請けできません。A社のプロジェクト管理があるからお請けしていますし、A社との契約だからこそ、弊社(B社)もリスク管理ができています。」。え、A社なんて何もしてないんじゃないの?、とようやくここでユーザーはA社のバリューに気が付くわけですね。

または、B社はA社からたくさんの顧客を紹介してもらっていて、A社を裏切ることになると今後、別の案件も含めて切られるかもしれません。A社にお伺いを立てることなく、直接ユーザーと契約するのは、営業費用を盗むのと同じですね。

そもそも、ユーザー側もA社に対して失礼なわけです。見積内容や前提条件に対して理解をするのは全く構いません。問題は、その金額に対して、原価構造まで教えなさいと、客が言うことの是非ですよね。これは下品です。見積内容に対してどのように作業を行ってどう満たすかは、ベンダー側の裁量です。その裁量をお金と交換するのですから、金額に客側が交渉するのって、大変に下品です。

例えば、レストランに行って客として注文するとします。Eセットが\5,000とします。そしてオーダー時に店員に向かって、「\5,000は高すぎない、だって前菜と魚と、ご飯、これらって原価いくらなの?。店員さんって時給いくら?。家賃は?。それでこの値段は高いよね・・」という客。私が店長なら、営業妨害で追い出しますけどね。

商品やサービスを生み出すことと、値付けは、ベンダー側のビジネスモデルそのものです。客側はその値段を見て、発注するかしないかを決められる自由があります。でも、その値付けに物言いする権利なんて、一つもないですよ。

これって、客側が偉いというバイアスですよね。お金を払う方が偉い。そんなこと全然ないですよ。だって、価値と、お金を等価交換しているわけですから、どちらが偉いもないんです。信頼関係の下で交換されるプロセスであり、それを壊すような行為は、ビジネス上下品そのものだな、と私はとても嫌な気持ちになります。

ですから、見積の時点でこういう行為をされるお客様とは、私は注文を断るポリシーです。人が何時間働くから、値段が決まるわけじゃないんですよ。じゃあ、Windowsって何人月かかって作ったから2万円なんですか?。iPhoneって何人月かかって作ったから15万円なんですか?。もう、おかしいんですよ、発想が。

高い、と思うのなら、他にできる会社にも相談して、見積を取ってみることぐらいですかね。でも、新しく会社を変えるリスクも背負うことにもなりますし、A社との関係もギスギスはすると思います。ただ、客にも選ぶ権利はあるので否定はできません。納得する価格で、正しい成果が得られるか自己責任でどうぞ。

もしくは、自社で内製するとか・・。ま、お金で解決したいんでしょうから、できないでしょうけれど。

見積には敬意を払いたいものです。予算と合わないなら、そういえばいいだけで、ね。

 

永遠に何もしなくてすむITインフラ基盤はない

 

インフラエンジニアとして、いつになったら気が休まるのかな・・・と思うがおそらく用意されていない。今後気になるマイルストーンを列記していく。

 

気になってる製品

VMware vSphere 6.5 / 6.7・・・サポート終了2022/10/15

これ今年なんだよなー。

たくさん使っている場所があると思うけど、皆さんもう7.0へ上げ切ったんだろうか。

ちなみに、7.0もサポート期限が2025/04/02で短めで、勘弁してーって感じ。

 

Ubuntu 18.04 LTS・・・サポート終了2023年4月

Ubuntuも無料だからって気軽に使っちゃうけど、18.04はもうすぐそこ。20.04 LTSが2025年4月、22.04 LTSも2027年4月。

UbuntuはLTSでも5年サイクルなので、結構早めに準備しないとずっと載せ替えで悩んでることになりそうね。

 

Windows Server 2012・・・サポート終了2023/10/10

もう随分、リプレースは進んでると思うけど、まだたくさん動いてるんだろうなというWindows Server 2012。ベースはWindows 8ですから、ずいぶん古いOSだなと思う。

今から上げるならWindows Server 2022で、2031/10/14まで使えるので上げちゃえばそのころのことなど知らんとも思う。

また、Windows Server 2016が、2027/01/12ってのもちょっと気になっていて、まあもうしばらくは記憶の外だけどあと2年くらいしたら考えていかないとななんて思ってる。

 

CentOS 7・・・サポート終了2024/6/30

世の中にたくさんあると思うCentOS 7。これらをリプレースするとしたら、来年にはもう動かないといけない。でも代替はどうするんだろう。RockyとかAlmaとか、CentOS Streamもあるけど、今からならバージョン9になるのか。パッケージの中身も随分変わるので気が重い。とにかくアプリはそのままでは動かないだろう。ちなみにバージョン9のサポート期限はRHELにあわせるなら2032/5/31になると思う。

 

RHEL 7・・・サポート終了2024/6/30

これもCentOS 7と同じ話題。なお、RHEL 8は2029/5までのサポートなので、せっかく載せ替えてもあんまり心は休まらない。RHEL9なら2032/5/31。

2030年代と聞くと、何だか心が休まる気がする。

 

Windows 10・・・サポート期限2025/10/14

私はサーバーサイドの仕事なのであんまり気にしてはないけど、情シスはそろそろドキドキし始めるよね。以前はWindows 7から10への入れ替えがお祭りになって、PCが売れまくった。

もう次ですよ・・、ということですんなり11に行くのか。それとも直前に12が出るという噂もあって、様子見にしている会社がたくさんあると思う。

 

考察

よく関わるJava 8が、2030/12までサポートを延長してくれたおかげで、ミドルウェア系はずいぶん楽になった。

一方で、OSかいわいが随分ここ数年でにイベントがたくさんあるので、もう最近、リプレースのことを考えることが多くなった。

いやいやサポート切れても動くだろ何も変わらないし、と昔の感覚で思っている人がいたらまずい。インフラ感覚だと、ハードウェアの方が先に古くなり壊れ、新しいハードウェアに載せ替えると古いOSが動かないということはとてもよくある。クラウドの話だと、サポート切れのOSは新規発注ができなくなったりバックアップが取れなったりリストアができなくなったりと、大変な制限が付く(もしくは使えない)。

あと、マネージドKubernetesなら、OSの制限ないでしょと思いきや、まずはKubernetes自体のバージョンアップが半年に1度あり、クラウドの種類にもよるが結構頻繁にアップグレードが強制される。また、クラスターの各ノードもOSで動いていて、私の経験だとUbuntu16.04で動いていたノードがアップグレードできなくなり、18.04で再度ノードを作り直ししないといけなくなった。

永遠に何もしなくてすむインフラ基盤はないな、と痛感している。どうせ今、がんばってリプレースしてもさ、また数年後に同じイベントが降りてくるのだろう。

 

KDDI障害報告、雑感

 

KDDIの大規模障害の報告内容を見て、思ったこと。

 

japan.zdnet.com

 KDDIは7月29日、同月2~4日に発生した通信障害の原因や再発防止策、顧客への補償などについて明らかにした。通信障害はコアルーターの経路設定ミスが発端となったことが分かった。

 

全方面に対策されていて、さすがだな、とは思った。

その反面、結局は人間による作業ミスがトリガーになっている。始めはハードウェアエラー基因みたいな話だっただが、突き詰めると結構そこに行きつくよね、という話は多い。ハードウェアがなかなか壊れることもなく、ソフトウェアのバグをつかまされることはあれど、そのバグですら人が作業したことをトリガーにすることが多い。

だから、できるだけ何もしないことが、障害を少なくすることの秘訣だということを知っている。

でも、作業はしなきゃいけないので、ここが技術者として腕を試されるところだ。できるだけやりたくない、は別にやる気がないわけじゃないのだ。何かやるから何かが起きる。作業を指示する方は、ここにあまり共感してくれないので、できるだけ問題が起きないようにするには現場で工夫するしかない。

さて、今回はヒューマンエラーが基因とは言うけど、現場の技術者としては、ちょっと作業を間違えたくらいで、こんな73億円の損害賠償にまで発展するような大事故になるような「設計」がおかしいよね、なんて思う。

人間が作業する以上は、失敗するのだ。失敗しても問題が大きくならないような設計が大事で、今回については「大規模化」という原因と対策がそれにあたる。問題がある輻輳をネットワーク全体に広げない。問題が起こった部分が問題を起こすのはこれはしようがない。技術者もベストは尽くすが、尽くしたところで必ず失敗しない保証はない。「徹底して撲滅して解消します!」というのが対策になったとしたら、報告書としてやり直しだが、KDDIの報告が優れているのはこの点だ。作業担当者が失敗しないようにするための工夫をしつつ、失敗しても大規模化しないための対策も着手している。

だから、今回は作業を失敗したこと自体も一つの要素であり、大規模化し、かつそれを収拾することに時間がかかったことの方が問題になっている点が、文脈として素晴らしいと思った。

ただし、結局は一か所の障害が全体障害につながるような設計について、インフラエンジニアとしては私は設計段階で、極力避ける。全体障害ということは、その下にぶら下がる顧客が同時にしびれる。でもこちらは一人なので、口は一個しかない。連絡に手間取り、問題解決をするリソースがなくなる。

マンションの建築などもそうだが、一つの家が火事を起こしても、建物全体が火事にならないような設計をしている。非常階段は、建物内部で火災が起きても火が移らないように工夫をしている。また、防火扉を適切に配置し、狭い箇所での被害に納まるように工夫されている。そういう意味では、火災と建物の関係と、システム障害への対策はすごく似ているような気もした。

初動から中間報告、そして対策まで、今回の件は教科書に載ってもいい模範的なプロセスだったと感じる。一方で、大規模システムの場合の、問題を大規模化させない設計については、大きな責任を負っていることを、設計観点から提起した。ぜひ、業界全体のためにも教材となってほしい一件である。

 

メモリー4GBに思う、人とコンピューターの関係

 

結構、世の中にメモリー4GBは使用に耐えないことが知り渡りましたよね。

 

pc.watch.impress.co.jp

 今でこそ、PCではメモリ8GBが最低限の容量となりつつあるが、数年前の低価格モデルでは4GBが標準的だった。PCの買い換えサイクルは一般的に3~5年と言われるほど長いため、今なお4GBの環境でストレスを感じつつPCを操作をしているという人は、それなりにいることだろう。

 

メモリー4GBが辛いことはこの記事が示す通りですが、ちょっと別の角度の話をします。インフラエンジニアをやっていて思うことは、もしサーバー用途ならば話が変わってくるということです。Linuxなら1GBでも動いているサーバーはたくさんあります。Windows Serverなら4GBでも動かないことはない、というレベルです。

Nintendo Switchって、メモリーはどれくらいで動いていると思います?。発売当初は32GBで今の有機ELモデルは64GB・・、違います、それは内部ストレージの話です。

 

support.nintendo.co.jp

本体保存メモリーの容量は下記のとおりです。データを保存できる容量は、ここからシステム領域を除いた容量になります。

Nintendo Switch
. . . 32GB
Nintendo Switch(有機ELモデル)
. . . 64GB
Nintendo Switch Lite
. . . 32GB

 

ここでメモリーという言葉を使うからややっこしい。

答えは下記の記事です。

 

www.itmedia.co.jp

 32GBのストレージは東芝製eMMC NANDフラッシュメモリ、CPUはNVIDIAのODNX02-A2、RAMはSamsung Electronicsの2GBのDRAMが2枚、Bluetooth 4.1のSoCはBroadcom製だ。ストレージは取り外し可能。

 

Nitendo Switchは4GBがメモリーなんですね。もし中身を改造できるならメモリーを一番に追加したいところ。メモリー不足だな、って動き、たまにしますからね。

きっと、Switchでゲーム作っている人は、メモリーの取り回しが大変だと思います。場面が切り替わる度にメモリー開放して、読み込んで、みたいな場面もSwitchの場合、たくさん見ました。それでもSwitchが売れ続けるものだから、最近はメモリーの中身をユーザーがプレーしている最中に賢く入れ替えて対応してるんだろうなとも思ってます。

また、PlayStation 5については、メモリーは16GBです。もう両者の製品としての立ち位置が全然違うのがわかりますね。

 

さて、サーバー側の話に戻りますが、パソコンではユーザー端末側は最低8GB、用途によっては16GBが必要です。でもサーバー側はたくさんの人が接続してデータや、計算を要求してくる割にはメモリーがそこまで要りません。この差は確実に「絵」「動画」を表示する必要がないからだと思います。極論言えば、ユーザー側のインターフェースがコマンドだけだったら、ユーザー端末にもこんなにメモリーが要らないということです。人間の脳のシステムって、思い切りグラフィカルに寄っていて、メモリー容量が必要なんじゃないかと思う次第です。

サーバー側を仕事で管理している人って、全人口の中でも結構少ないと思うんですけど、コマンドで仕事を済ませることが非常に多いです。サーバー側でもグラフィカルな処理はするのですが、実際にサーバーのコンソールで表示させることはあまりありません。対応するコマンドが用意されていて、それを実行したほうが、確実に再現させられます。

なぜ、システム構築という分野があったのに、RPAという、クライアントサイドの自動化のカテゴリーが生まれたかと言うと、人間の脳をシミュレートするにはサーバー側だけの自動化で追い付かなかったからです。システム化したあげく、結局クライアントのマウスやキーボード操作を必要とすることが多かったため、そちらの自動化にはRPAが必要になりました。

人工知能の分野ではパソコンのメモリーではなく、GPUというグラフィック専用のチップが必要となります。このGPUの上に、通常のメモリー以上に高性能なメモリーが搭載されていて、人工知能の分野で使うにはこれが8GBでも約不足で、16GBや24GBみたいな容量を搭載しています。

結局のところ、人の頭の中にも、16GBだか24GBだかの高性能メモリーが搭載されてるんじゃないかなと思うことがあります。人間が使うコンピューターなのに、人間より性能が低いのを使わせんじゃないよ、という一般大衆の叫びが、メモリー4GBへのバッシングにつながってるんじゃないかな、なんて思っています。

私は、パソコンのメモリーが64KBのころからの、パソコンとのお付き合いです。人間とパソコンの関係が不可欠になった時代に入ったからこそ、こんなに快適なメモリー容量に対する人々の思いが強くなっているんでしょうね。

ま、メモリー4GBは少ないって人々が思えば思うほど、私のサーバーのサイジングの仕事は、1GBや2GBで作った時に「そんなに少なくていいんだ~」って毎回感心されて、ラッキーなことも多いのですが。

 

人手不足で仕事を断ったよ

 

私のスタイルから言って、これまで「人手不足」で断るとか無かったよ。

 

この数年、何でも来いや、のスタイルで仕事してたけど計算が成り立たなくなった。明らかにここから新規の仕事を取ったらパンクする。

で、強硬に新規の仕事を止めようとしてるんだけど、営業はたまったもんじゃないよね、仕事取るのが営業の仕事だからね~。

こういう状況が全国で頻発してるんじゃないかな。今回の私の話は、新規顧客を断るって話だけど、既存顧客であっても「人がいないからリスケさせて」って話になってるって複数のチャネルから聞いてる。

既存顧客の仕事ってだいたいリプレースの話で、リプレースはソフトウェアの保守切れが絡むので、それすら遅延したらえらいことになるのでは。

クラウドサービスは特に、サポート切れが即使用停止まで発展するからね。

 

営業の気持ちを考えてみる。

目の前にはたくさん取れそうな案件があるはず。だって、どの業者も今人手不足で請けられないってことは、商談がたくさんあり、そしてよく進むってこと。で、これまでの勝ちパターンを引っ張ってくれば取れると思うじゃない。そしたら、身内から人手不足でムリと来る。「えー-」と。せっかく商談引っ張ってるんだから、頼んますよー、となる。

頼んますとか言われても、人手不足やっちゅうの。

ベンダーロックインもさ、いろいろ文句言われてるけど、こういうときにベンダーは既存顧客だけは何とかしたいと思うもの。だんだん人手不足が顕在化してくると、いかにベンダーを味方につけておくかみたいな競争になるんじゃないかな。普段、ベンダーに冷たくしている会社は要注意ね。そういうところから次々と切られていくよ、ベンダーに。

 

なんでこうも人手不足になっちゃったんだろうか。

大手企業が内製化を進めようとして、システムエンジニアを吸収しているって話があるけどあれが原因なんだろうか。また、DXやクラウド化が伸びて、案件がどんどん増えて、SIerも人の取り合いになってるんだろうか。

あとは、年々シニア層が引退して、本当にIT業界の人口が減っていってるのかもしれない。

で、私も最近気づいて、若い層を集めてるけど、これにはまた時間がかかるんだ。単に人手があれば済む問題じゃない。ちゃんと案件をこなせる人は、業界に長くいる人が相場だった。人数だけいてもダメなんだ。

この人手不足の状況ってかなりしばらく続くんじゃないかと思ってる。今から景気がどっちに向くかわからないけど、デジタル分野は切り離せないよね。昔のITバブル崩壊や、リーマンショックあたりは、まだITの予算って、縮小されやすかったけど。今はデジタルがないと会社まわらなくなってるもんね。

 

実際にさ、人手不足でほんとに仕事断った経験をしてしまうとさ、ついに来るべき時が来ているのかもって思っちゃう。お金で解決できた時代の終わり。どんなにお金があったって、すいません案件請けられません。まあそういう時代を予期して、大企業はIT人材の内製化に舵を取ったのかもしれないね。

 

その仕様、できません システム開発途中で気づくためには

 

この記事、身につまされる。

 

xtech.nikkei.com

システム開発の頓挫を巡る、文化シヤッターと日本IBMとの間の裁判で、東京地方裁判所は日本IBM側に19億8000万円の支払いを命じた。米セールスフォースのPaaSを用いた販売管理システムの構築を目指し、2015年に始めた開発プロジェクトだったが、2017年にストップしていた。東京地裁は開発失敗の原因をどう認定したのか。裁判記録をもとに読み解く。

 

そもそもの話として、RFPを作成したベンダーと、受注したベンダーが同じ時点で両社がかなり深い関係だったんだろうなと推察する。

システム入れ替えのタイミングで既存ベンダーがRFPを作成する。その時、できるだけ他社には受注させないような表現をするのは目に浮かぶ。

既存ベンダーはシステム開発にあたって、これまでの資産を流用する提案を書けるが、他社にはその情報がない。したがって既存ベンダーの提案が一番安くなり、リプレースも既存ベンダーが取っていく。まさにベンダーロックインの現象である。

それまでの信頼関係もあるので、よくある風景だが、この件については最後は損害賠償の係争にまでたどり着いている。

深い関係とは言え、受けてはいけない案件だってあるということをこの件は教えてくれる。ではどの段階で、断るべきだったのか。

 

この案件の流れは以下のように推察する

①ユーザーがシステムリプレースをすると決断

②ユーザーが、既存ベンダーにRFP作成を委託

③既存ベンダーがRFP作成を受注し、RFPを作成

④ユーザーがRFPに基づきコンペを実施

⑤コンペにおいて既存ベンダーが受注

⑥要件定義において、ユーザーが既存ベンダーに、大量の独自仕様を要求

⑦既存ベンダーが要件を飲み、下流工程へ強引に進める

⑧既存ベンダーがテストを行ったところ、品質が悪く本番運用できる状態ではないことを確認

⑨既存ベンダーがユーザーに、再度開発しなおすことを提案

⑩ユーザーにとって提案が受け入れがたく、ユーザーは既存ベンダーに開発失敗の損害賠償を提起

⑪既存ベンダーはそれまでにかかった開発費用を求めて、ユーザーに提訴

 

どこで失敗したのか。

本件はまだ裁判中の案件で、私が軽々に表現するのはまずいと思うが、業界の人間として他山の石としたい。時間を巻き戻せるならどこがポイントとなるのか。

直接の原因は、SalesForceが年3回バージョンアップするのに、大量のカスタム開発を実装してしまったため、本番運用できない実装になってしまったことにあるようだ。

つまり、システム開発をする前の要件定義時に、実装した後、運用が難しいことを判断できていれば、ここまでの損害にはならなかっただろう。つまり、⑥がポイントか。

要件がある程度明確化されたところで、「その仕様を、SalesForceで実装することはできません」と言えなかったのは、この時点で実装を知っている人が既存ベンダーにいなかったのか。実装は次のフェーズで考えることであり、要件定義は要求業務を整理することと割り切ってしまったのか。

ただ、実装のことを考えない要件定義などあり得るのか。こういう技術を使って、こういうインフラ基盤を使い、こうします。運用はこういうイメージです。次のフェーズに行く前に、実装担当やその後の運用担当まで巻き込んでレビューすべきではなかったか。

上記は、この記事を読んだら誰でも考えるとは思うが、そうならなかった背景があると推察する。RFP時までは、既存ベンダーの営業担当と、ユーザーの経営層の間で「これからはSalesForceでモダナイズしていかないと」みたいなフワッとした話が盛り込まれていたのではないか。そして、要件定義時は経営層ではなく現場担当が出て来て、いや、SalesForceでもなんでもいいが、これまでのユーザーインターフェースは維持してもらわないと困る、という意向が強硬に働いたのではないか。プロジェクトマネージャーは板挟みになり、SalesForceで大量のカスタム開発をする禁断の実装を選んでしまったのではないか・・と邪推してしまう。

 

1つ記事の中であれ、と思ったのが、

 

RFPでは標準部品を80%、セールスフォースのPaaS用プログラミング言語である「Apex」や「Visualforce」を使ったカスタム開発を20%とする予定だった。システム稼働は2016年7月、総開発費用は約12億3400万円を見込んでいた。

 

とあり、RFP時点でカスタム開発の割合が明記されていることだ。

であれば、要件定義時にこのまま実装を進めれば95%がカスタム開発になることを予想できなかったのか。

 

 ところが開発は見通しを大きく外れ頓挫する。東京地方裁判所の認定によれば、文化シヤッターが旧システムと同様の画面の見た目にこだわり、日本IBMも積極的に標準部品の活用へ誘導することなく2次要件定義フェーズや設計・開発フェーズを進めたため、カスタム開発の割合は95%に膨れ上がった。

 

とある。誰か止められなかったのか。

おそらく実装したタイミングでは、カスタム開発はすんなり動いたんだろうな、と思う。その後システムテストを行うまでに、SalesForceのバージョンアップが走り、大量のカスタム開発が動かなくなった、みたいな問題がテスト時に発覚したんだろうな、とこれも邪推。

 

この件、まだ係争中なので、記事に書かれた内容がそのまま最終認定されるとは限らない。記事の中に書かれていることに感想を述べたまでである。ただ、学べることが多い話だ。クラウドサービスにおいては頻繁にアップデートがかかる。これに合わせることができる開発物を作成しないと、アップデートのたびに全部テストをし直し、動かない場所を特定し修正する仕事が必須となる。開発時に実装できればいい、ではない。クラウドサービスの利用にあたっては、かなりクラウドベンダー側に主導権を取られるので、この点は要件定義の段階でかなり意識し臨む必要があることは間違いない。

アップデートが必ずあることを意識し、作りこみすればするほど維持不能に近づくことを関係者全員が意識しなければいけなかった。そうすれば、もっと早い段階で止まることができたのではないか。

クラウドサービスを使うリスクを、具体的に感じさせられた記事であった。

 

クラウドサービスがすっとぼけだと思うこと

 

クラウドサービスは、ソフトウェアの集合体をインターネット経由で利用することだと思う。

その上で、設定ミスにより情報漏洩が起こるなど、よからぬことが起こっていることは知っている。

 

www.itmedia.co.jp

 総務省は7月25日、クラウドサービスの設定ミスがもたらすリスクやその対策などをまとめたガイドラインの素案を公開した。クラウドサービスの設定ミスに起因する情報漏えいの多発を受けて作成したという。素案に対するパブリックコメントの募集も同時に開始。8月24日まで意見を募る。集まった声を踏まえ、今秋に正式版を公開する。

 

わかる。わかるんだけど、クラウドサービス事業者側、もっと言えばソフトウェア開発側にも物申したいことはある。

そりゃ、設定したらその通り動くことが一番大事なんだけど、どう考えてもその設定は情報漏洩するやろ、みたいなパターンは開発側も知っているはず。

なぜ、仕組みとして検知して、警告表示しないのだろうか。

危険な設定のすべてを網羅する必要はない。典型的なものだけでもいいから、「それ危ないよ、こういうことが起きるよ、いいの?」とユーザーインターフェース上目立つように表示できないものか。

また、危ない設定を簡単に実装できるのもいかがなものかと思う。危険な設定は、別メニューに外して、ユーザーの任意で実施させるようにはできないものか。

日本人のソフトウェアの作り方は結構、危険なことをさせない配慮があったのだが、特にアメリカ発のソフトウェアは、とにかく実装する。そしてどんどん機能を増やしていって、不具合があればアップデートで改善する。そんな作りが非常に多い。

危険かどうかより、とにかくリリースを急ぐ。アップデートでどんどん機能が増えていき、インターフェースも徐々に改善していく。

安全性より、できることを増やすことに優先度を置いているために、いろいろ設定していくうちにユーザー自ら穴を空けてしまい、実は全世界に機密情報が公開されてました、みたいなことがここ十年、たくさん起きてきた。

クラウドサービスは便利だけど、設定に気を付けないと、危険な目に遭うと言われるようになり冒頭の記事のようにユーザーが自衛する必要がある。だからこそクラウド分野にも専任のシステムエンジニアが必要になり、お仕事も事欠かないのだけれど、やってて思うのは、わざわざ穴の開くような仕組みをなぜ作るんだろうという、違和感である。

技術とは「できることを知ること」と思われがちだけど、「できるけどやったらいけないこと」を知ることはもっと大事だ。実装経験が無くていきなり設計すると、便利な機能に飛びつきがちだけど、便利な機能ほど危ない仕様が隠れていたりもする。ベンダーの資格試験の知識ではなかなか見抜けない。ソフトウェア開発側も気づいていないような、危ない仕様だってあるのだ。

この業界で長く仕事をしているので、こうしたら危険だ、という感覚はたくさんついた。それは財産なんだけど、そろそろソフトウェア側で実装してくれないかなーと言う感覚もある。おかげで、新しい機能を試すことはあるけど、実装するときは枯れた技術で組むことが多い。本番運用の世界で、新しい機能かどうかなんてどうでもいいので。安定して安全で、長く使えることが最も大事だから。

ユーザー側が自衛しないと、なんて言われないように、クラウドベンダーにはソフトウェア開発してほしいものである。

 

非機能要件ということばのワナ

 

インフラエンジニアとして、特に構築まわりの仕事をし出したときに、「非機能要件」という言葉を初めて聞きました。ある打ち合わせで、開発エンジニアから「非機能要件の話です」「そうですか」という会話を聞いて、へえ、なんだろうそれって、という思いでがあります。

ただ、インフラの仕事をする限り「非機能要件の仕事をしなきゃ!」という気持ちではありません。どんなインフラ基盤を使って、障害に強い設計をし、運用時に監視やバックアップを漏らさず、そして性能が劣化しないように・・と一つ一つ考えているわけです。

非機能要件の内容について、まとめた記事が下記です。

 

thinkit.co.jp

本連載も、今回で最終回となります。これまでは機能設計書を中心に解説してきましたが、最終回は非機能要件について解説します。非機能要件という言葉を聞いたことはあるかも知れませんが、カバー範囲が広いためどのようなことなのか説明するのがちょっと難しかったりします。でも、実は機能要件に引けを取らないほど重要なので、最後にきっちりお伝えしていきます。

 

システム構築を管轄するプロジェクトマネージャーにとっては、この部分はインフラの専門家に任せようとなるのが定番です。

ところが、ここで毎回ワナが起こります。「非」という言葉が現れていて、機能じゃないという言葉のために、ユーザー側も丸投げ衝動が起こります。

よくあります。ユーザーも開発エンジニアも、そこはインフラの範疇だから「よろしく」と。

「非」という枕詞が付いているせいで、あたかも主役ではない、傍流の、景色のような扱いをプロジェクトメンバー全体がしてしまうというワナです。

私も、何度も何度も丸投げされました。説明しようにも、ユーザーも大した関心もなく、流して聞いて「よろしくおねがいしますね」と言われて終わりです。

機能部分はユーザーがお願いしたかったコアの部分なので、ものすごく関心があります。業務に近いのでユーザー側のほうが専門家だからです。一方で非機能要件についてはユーザー側は知識もないので、「ちゃんと動いて問題が起こらなければいいよ」という態度です。これに「非機能要件」と言う言葉が火に油を注ぎます。

でも、面白いのがサービスイン後です。セキュリティーやら可用性やら、バックアップや監視のことやら、どうなってる?と興味しんしんです。それならサービスイン前にもっと相談していれば・・と思うこともよくありますが、構築中は機能要件で頭がいっぱいなんでしょうね。特に問題が発生すると、なぜ「そんな仕組みに?」と真顔でユーザーが聞いてくるのですが、それなら構築時にもっと話をしようよ・・とも思います。

ですから、インフラエンジニアとして、あんまり「非機能要件」と言うことはないですね。実は我々にとっては機能そのものです。どう設計するか。どう監視するか。どうバックアップするか。我々が「非」なんて言ったら何がコアなのかわからなくなります。

昨今のKubernetesなどの動きを見ると、これまで非機能要件と言われていたところをほんとに考えたくないんだろうな、というニーズはよくわかります。でも、どんな実装をしたところで、縦から切ろうが横から切ろうが、存在するものは存在し、対応しなければならず、そこにインフラエンジニアの意義が存在する気が、ほのかにします。

 

国産クラウドを育てるとは言うけれど

 

ここで言うクラウドはIaaSのことという前提を切っておきます。

クラウドを語る上で一番偉大なのはAWSです。AWSのビジョンが、日本のIT業界が考えていたインフラの常識を凌駕していたのは間違いないです。

AWS登場以前は、データセンターは独立したものでした。会社のサーバールームのすごい版、であり、こんな立派な施設でサーバーを預かっているんだから。ということでハウジングなりホスティングなりという市場がかなり伸びました。2000年代ですね。

AWSが公開されたのは2006年7月。業界はかなり冷ややかに見ていました。冷ややか過ぎてこのころはニュースにもなっていません。そもそも、うまくいくはずがないと思っていました。複数のデータセンター間で通信ができたり、使った分だけ課金できたり、オートスケールできたりと、当時からは夢のような仕様だったのですが。

「技術的にもビジネス的にも早晩、行き詰るだろう」

とみんな言ってました。

日本のITベンダーのバイアスとして、「既存のソフトウェア製品の組み合わせで実装する」「リプレースが定期的にあり、大型化すると大変」という思い込みがありました。

AWSの仕様を、既存製品で実装するのは現実的ではなかったのです。自分たちが設計できないものを、Amazonなど小売りの会社がどう実装するんだ、とみんな思ってました。

 

www.itmedia.co.jp

 「クラウドコンピューティングで興味深いのは、クラウドコンピューティングという言葉が再定義され、われわれが既に行っているあらゆることが含まれるようになったことである。どんな発表を見ても、クラウドコンピューティングを標榜していないものはない。コンピュータ業界は、女性ファッション業界よりも流行志向が強い唯一の業界だ。わたしがバカなのかもしれないが、みんなが何を言っているのか理解できない。いったい何のことなのか、まったくわけが分からない。このバカ騒ぎはいつ終わるのだろうか。当社もクラウドコンピューティングの発表を行うだろう。わたしはこういったことに抵抗するつもりはない。しかしクラウドコンピューティングという点について言えば、当社の宣伝文句のほかに何が変わるのか理解できない。以上がわたしの考えだ」

 

レガシーなIT業界は、クラウドをバズワードだと思っていました

しかし、そもそものビジョン自体が、IT業界が無理だと思っていた実装の先を行っていたということだと思っています。

日本のベンダーは、レガシーなIT業界の方が明らかに安定し利用に足ると長く思っていましたし、ベンダーが丸抱えしていた日本の内資企業もそれに追随していました。

流れが変わったのは2011年、東日本大震災です。

かなりのインターネットサービスが止まったとき、AWSの実装が大活躍しました。とりあえず使えるなら使え、といろんな企業が実装してみたところ、非常に合理的に利用できることがわかりました。

一度、本番実装できるとわかった基盤で、かつ合理的なことを理解した先進的な企業がどんどん利用しだし、そしてAWSがそれを大規模イベントで公表します。

そうやって、どんどん利用が広がり、それを見ていたMicrosoftやGoogle、そしてその後に続く企業も、AWSのビジョンを吸収し実装していきました。

 

日本のITベンダーはと言うと、そもそもAWSのビジョンを自社で実装できるだけの資本も無ければ、海外顧客もいませんから、ここらで心が折れることとなります。むしろ、メガクラウドに乗っかれということで、自社クラウドは「なんちゃってクラウド」のままとし、メガクラウドの技術者を増やす方向に転換します。

インフラは捨てて、ソリューションの方に舵を切り、インフラ基盤はメガクラウドでもOKですよ、というふうにしたのです。

 

で、この前の国産クラウドを育てるという話。

なんだかつじつまが合わないということです。AWSのビジョンを日本の内資企業が実装できるのでしょうか。

例えば、中国で言えばアリババクラウドなんて、AWSの焼き直しながらも、世界的にはシェアを伸ばしています。

同じことを日本がするの?。それだけの資本力が日本にあるの?。海外営業力は?。

 

となるわけですね。

国産クラウドを育てるとは言うけれど、単にデータの置き場としての、なんちゃってクラウドになるような気がするんだけれども。

日本のクラウド事情は、すでに夕暮れで、これから長い夜が始まりそうな様子だが、ここから日が昇ることってあるのかな。

 

国産クラウドが育たなかった理由

 

大昔、クラウドだって言い張った単なる仮想環境を作ったおぼえがあるけど、全然スケールするイメージが付かなかった。

一番の問題は、個別の顧客に対していろいろと要件を聴きすぎたということだった。顧客ごとにユニークに設定を入れ込んでいくと、どんどん設定が複雑になっていく。これ十社ならいいけど百社入ったらアウトかな、なんて感覚があった。

AWSなど、スケールするクラウドは個別の要件なんて聞かないで、どの顧客にも同じ機能を提供するという姿勢を貫いた。そもそも顧客と直接コミュニケーションをせず、Webサイトを通じたコミュニケーションが基本だった。スケールする前提を守るには必須だと思う。

これが、「地場のデータセンターは、直接お客様にお伺いし、Face to Faceをするのがバリューです」なんて言っちゃったものだから、クラウドではなくなる。

そうなると、顧客の声が強くなりすぎて、あれやこれや拡張しちゃうんだけど、それが次の顧客の足かせになる。

そのうち容量が足りなくなって別のクラスターを作ろうとすると、元のクラスターの仕様とずれちゃう。そうやって、ヘンテコでユニークな建物がどんどん増えて行って、収拾がつかなくなる。

そこに、「バージョンアップ」「保守切れ」なんてイベントが訪れる。どうせ、どこやらの有名メーカーのハードウェアやソフトウェアを買って、組み上げた構成を使うもんだから、どこかで保守切れが近づく。すんなり無停止でアップデートできればいいけど、そこでいろんな技術制約が出て来て、単に移し替えるだけなのに、ものすごく工数がかかることになる。

スケールアウトするにも、移行して最新にするにも、全然楽にならないのがクラウド構築で、実際にやってみて、こんなの全然楽じゃないよなという記憶がある。そしてAWSやAzureが出てきた時も、うまくいくはずないよな、なんて決めつけていた。

 

ところが、今やクラウド全盛だ。彼らはスケールできてしまった。今では世界中のデータセンターに基盤を立てまくって、そして、私が困難と感じたハードウェアやソフトウェアの入れ替えを日々できてしまっている。

なぜそれができるのか。基盤のハードウェアやソフトウェアまで、自社でコントロールできるような仕組みを取り入れているからだろうと思う。

どうしても日本国内で内製で作ろうとすると、マルチベンダーで機材を調達したプラモデルになってしまう。そしてベンダーごとに保守の事情が違う。国内クラウドはおそらくすべてそうだと思う。完全な内製などできはしない。

全ての海外クラウドの状況は知らないが、ハードウェア・仮想基盤・ネットワークなど、結構な自社専用のカスタマイズが入っているらしい。本当の内製が進んでいる。保守のコントロールが半端ない。

保守フェーズを大規模化に合わせてシンプルにし、世界で本番環境を無停止で動かし続けつつ、ハードウェアやソフトウェアを最新にするという離れ業をやってしまっている。

じゃあ、個人や日本企業がそこまで踏み込んでクラウドを設計できるのかというと、これには大変なお金を突っ込まないとそこまで実装するのは厳しすぎる。もはやハードウェアやソフトウェアも、輸入に頼りきりである。

もともと、政府は、国内ベンダーに仮想基盤を作らせ、それをデジタル基盤にしようとしていた。ところが余りの経済性の低さに、AWSなどメガクラウドにリソースを移しつつある。

ところがここにきて、「国内クラウドの育成」に舵を切ったというニュースがあった。

 

xtech.nikkei.com

 自由民主党と経済産業省が「国産クラウド」の育成に動いている。狙いは「国民データの安全な管理」と「クラウド技術の確保」という経済安全保障上の2点だが賛否両論がある。

 

正直、これまでの国産クラウドの挫折を身をもって知っているので、何を表しているのかわからない。昔に戻すと言っているようなものだ。

そもそも、何をもって国産なのか。何がクラウドなのか。昔の定義なら、もはや国内ベンダーは敗れたのではないか。

インフラエンジニアのはしくれとして、2022年から「日本でクラウドを作る」と言われたときに、何を示すのか興味がある。また、ベタベタなオンプレの仮想環境ができあがらなければいいのだが。

 

データセンターが熱くなるとこうなる

 

ロンドンが猛暑でえらいこっちゃ、らしいです。

 

www.itmedia.co.jp

 Google Cloudの欧州リージョンの一部(europe-west2)で障害が発生している。ロンドンにあるデータセンターの1つで、7月20日午前2時13分ごろ(日本時間、以下同)から、冷却関連のトラブルが起きているという。問題は一部改善しているものの、午前10時時点で解消はしていない。

 

サーバーがたくさんある部屋がサーバールーム。サーバールームがたくさんある建物がデータセンター。IT企業に働く人でも、最近はデータセンター内に立ち寄る人はごく一部となっています。クラウドを利用すれば、Webページからマウスをクリックしていくだけで、データセンター内のサーバーが利用できる時代です。

まるで利用者から見ると、雲の中にコンピューターがあるようなのでクラウドと呼ばれていますが、現実は、ちゃんと建物の中にあり、物理回線がつながっています。

あまり立ち入ることがないからこそ、熱でダウン、と言われても何がなんだかわからないかもしれません。

サーバールーム自体は、何らかの方法で、サーバーが出す熱を放出し、冷却するようになっています。いかなる季節であってもサーバールーム内の温度は一定、目安としては20度になるようになっています。

サーバールームの中で長時間作業する人は知っています。部屋の中に空調が回り続けるので、体感温度はもっと寒いです。真夏の暑いときでも、厚着をしてデータセンターに入館する人は現実をよくわかっています。真冬のコートを着て入る人もいます。その上、窓がないことが普通で電気を消せば、サーバーのLEDランプがちかちか光るだけです。ぼんやりしていると、今何時だかわからなくなってきます。私も、20時間くらいぶっつづけで仕事をしたときがありますが、昼に入って外に出たら昼で、どっと疲れが降りてきたのを思い出しました。

 

さて、そんな人間に優しくないデータセンターですが、この温度調整が何らかの理由で異常となった場合どうなるか。サーバールーム自体が熱地獄になります。サウナのようなものです。

サーバーですが、熱がどんどん上がるとどうなるかご存じでしょうか。燃えるまで処理を続けるのでしょうか。違います。サーバーの基盤にて温度を測っており、異常な温度となった場合は電源ごと落とします。

したがって、クラウドサービスの場合は、たくさんのサーバーが関わり合って動作していますので、無差別にサーバーがストンストン停止していって、リモートで監視している人は何事じゃ、となります。

で、サーバールームに行こうとした人が異常に気が付きます。サーバールームに付いたときに気が付くのではなく、もう、通路の時点でおかしいです。変なにおいがします。こげたような、人間が吸ってはいけないような。そして、扉からもう熱い場合がほとんどです。

前述の通りサーバーはどんどん無差別に停止しているので、人間が近づけないほどではないですが、それでも熱が充満していて、そのまま電源を復旧することは無理です。故障の規模にもよりますが、応急手当として扇風機を持ってくることがあります。とりあえず風で逃がすのです。

ユーザーは、「何やってるんだ復旧はまだか」と騒くのですが、データセンターがこんな様子であることを、クラウドベンダーが知らされるのにもタイムラグがあります。こうなると冗長化も何もあったものではありません。何せ無差別に電源が落ちていますから。まずは、空調周りの復旧と、サーバールームの温度が下がることが重要です。その後電源をオンにしますが、次は、無影響確認。だいたい熱が上がるときに機械は壊れますし、電源の停止のされ方も乱暴なので、このあたりはサービス復旧時間とのせめぎ合いになります。ハードウェアがオンになったところで、今度はソフトウェア上で、サービスを起動したりなんだりと、まぁ、大変です。

ということが、きっとロンドンで起きているんだろうな・・と。

なんでしょう、気象変動の影響なんでしょうか。想像できるだけにしんどい話です。

 

あれ?いつまでプレーヤーやるんだろ、と思った瞬間

 

大昔・・と言ってももう30年前くらいに未経験でIT業界に入った時は、先輩たちも未経験からみたいな人も多くて、けっこう下剋上し放題だった記憶。業界の規模も小さかったし、パソコンやサーバーの機能も低かった。そういう頃って、業界が今後どうなるかってリスクも大きかった一方で、若いうちからいれば業界の成長と一緒に成長できるっていうのもあって、悪いことばかりじゃなかったかなと思う。

で、そういう人たちの中でも生き残ってきた人たちが40代、50代にいて、若手にのってはなかなかの分厚い壁になってるんじゃないかと思う。彼らは若いころ、長時間残業だの休日出勤だの、「働き放題」世代だった。おかげで心を病む人も続出したわけだけど、そこを生き抜いてきているから、猛者ばかりなのは当然だと思う。

でも大事なのはここから。40代50代はあと10年20年で退出する。そのとき、この業界を背負うのは20代、30代ということ。きっともう数年したら、わらわらと引退しだすと思ってる。引退されちゃ困るので、きっと75くらいまで定年を伸ばすような画策を政府がし出すと思うけど、最近思うのは、それって不自然じゃないかって感じるんだよね。すでに今達人の域の人たちが、20年後まで同じことしてるって、どうなの。そして、下の世代は伝承できるの?。

今は、手順書だのレビューだの構成資料だの、いろいろと情報を整理する手段はできたけど、結局想定外のときに役に立つのは、トラブルシューティングの経験だし、その経験って事前に書き出せない。とりあえず見ておいて、の世界なんだけど、ここから20年、下の世代に見学だけさせておくの?。やっぱり変。

もっと、若手に丸っと任せちゃって、自分たちで悩むチャンスをあげないといけないんじゃないかな。しかも、もう今から始めないと時間切れになってしまうような。

今から20年計画なんて立ててる時点で、のんきな話じゃないかなと。

どうせ、40代50代の人たちも、上に聞く人がなくて絶体絶命になり、いろいろあがきながら、トラブルシューティングの感覚を磨いてきたわけでしょ。それを定型化してマニュアルに落とし込み、いくら暗記させようとしてもさ、それ、自身もそのプロセスで学習した人っているのかな。今は資格試験がたくさんあるけど、資格試験ベースで仕事で来てる人いるのかな。いないと思うんだけど。

・・・って、今日もトラブルシューティングしながらそう思ったんだ。自分がいれば、時間の経過に従い想定外の事象もどんどん減っていって、想定外が少なくなり現場も安定し、そんなにトラブルシュートする場面もなくなるのかな。そう思いたかったけど、やった先から想定外。想定外って、想定していないんだから、若手に教えられるわけないな。未来の想定外、いつまで自分がやるんだろ、って。

いやぁ10年経ったら・・と思ってたけど、10年前にも同じようなことを思った記憶もあり。全然状況が進歩してないというか、進歩したのは自分だけな気がして。

バトンを渡すのはまだ早いけど、バトンの渡し方を勉強しないとまずいな。バトン握ったまま、突っ走って若手置き去りじゃ、何のために仕事をしているかわからなくなりそう。先々のことを考えて、若手にうまく、苦労させてやらないと、ね。あとは、地道に情報発信していくことで、何らかの知見が誰かに届けばこれ幸い。

 

ITと忘れられる権利のバランス

 

代表的なチャットサービス、Slackのフリープランについて、仕様が変わるらしい。

 

www.itmedia.co.jp

 月額料金がかからないフリープランでは一部仕様を変更。保存できるメッセージ数は1万件、利用できるストレージ容量は5GBだったが、9月1日以降は件数上限を撤廃し90日間のメッセージを保存、ストレージ容量は無制限に利用できるようになる。

 

有料プランの値上げはともかく、フリープランについては結構な話題となっている。10000メッセージ保管から、90日無制限保管となるが、私の使い方で言えばこれで問題ない。メッセージは後ろに流れるだけでよく、そして履歴を見るような使い方はしない。ただ「ピン留めアイテム」を使っている場合、90日前より昔のメッセージは問答無用で消えてしまう。これは要注意かもしれない。

 

今回の変更はかなりのフリーでSlackを使っているユーザーを同様させたようで、思いのほかSlackを「記憶のツボ」として使っていらっしゃる方が多いことに気づかされた。

会社でも、各個人がメールボックスを持っていると思うが、退職してメールアドレスを消すとその人しかもっていなかった情報が消え去るということがあると思う。

有料版のチャットサービスでは、無制限に保管しているところが多いと思うが、このデータはいったいなんだろう。100年経っても保持する気なんだろうか。Twitterでも同じ疑問を感じる。

知恵を貯めておくデータベースがどうあるべきか、という議論はあると思うが、全部保管しておくのは無駄が多すぎるのではないか、と。課題管理ツールは、課題が未解決の間は保管しておくべきだと思うが、解決した後3年ほどしたら誰も見ないのではないか。また、その間にもっと知恵を整理して、別の場所にまとめておくなどで十分だと思う。メールも、1年経ったらもういらない。チャットも話したことがいつまでも残っているのもどうかと思う。

人間の性質として、何でも残したいという欲求が今回明らかになるにつれ、デジタル分野における莫大なデジタルのゴミのような情報は、どうなってしまうのだろうか。

テキスト情報ですらそうなのに、昨今は写真や動画があり、これがまた問題をややっこしくしている。

まだ、YouTubeは、古い動画について、削除ポリシーを発表していないので、永遠に残るんだと思うけど、Googleのテクノロジーで永遠保管を可能にしてしまうのだろうか。それとも、どこかで打算するのか。

もし、全人類が「データは原則、一定期間後削除していい」と言う妥結をしたら、ずいぶん無駄な資源が減ると思うんだけれど。そして私個人はそれを望んでいる。全てのアウトプットを永遠に保管されるなんて耐えがたい。忘れられたい。