  |
はてなキーワード:オンプレミスとは
https://qiita.com/h_horiguchi/items/b22b2482ab1506d27664
これが、ちょっとやばい。どれくらいやばいのか、エンジニアじゃない人にもわかるように説明してみる。
まず、富士通は「社内システム開発」や「自治体システム」を担ってきた。
大企業や自治体がシステム（在庫管理、職員データベースなど）を作るときは、富士通のような大手SIer（システムインテグレーター）に外注する。
マイナンバーカード関連のシステムも、富士通が関わっている。こうした案件は、数年で数億円規模の予算が動く大事業であり、富士通の主要ビジネスの一つだ。
富士通のクソ高いサーバーやネットワーク機器を購入し、開発から保守まで富士通のエンジニアが担当する。
完全に「富士通の中で完結」する仕組みだ。
アマゾンが提供するクソ高いクラウドサービスだ。富士通のサーバーやネットワーク機器を買う必要がない。
富士通がアマゾンのクラウドを“借りて”システムを運用する形になる。
ここでお金の流れを見てみる。オンプレとAWSでは、お金の流れが根本的に違う。
そして問題の記事では、富士通の社員が自社のオンプレからAWSへの移行方法を丁寧に解説している。
つまり、「富士通を通さなくてもいい時代」の到来を、自ら説明してしまっているわけだ。
まとめると、富士通はこれまでオンプレで利益を上げてきた。しかしAWSの普及で、アマゾンにお金が流れる構造に変わっている。
そして富士通のエンジニア自身が、その変化を促すような記事を書いている。
自社のビジネスモデルを自ら否定する記事を、堂々と公開している会社。
この文章が指しているのは、おそらく「AWS」や「クラウドインフラ」関連の技術ではなく、もう少し狭い領域の技術、特に「コンテナオーケストレーション技術（Kubernetesではない方）」、あるいは「仮想化技術（VMwareなど）」、さらに絞ると「OpenStack」や「オンプレミスのプライベートクラウド技術」を指している可能性が高いです。
理由は以下の通りです：
• 「数年前までは結構勢いがあった」 という記述は、例えばOpenStack などが一時的に注目されていた時期（2010年代前半〜中盤）を示唆しているように読めます。
• 「上位互換の技術の台頭」 は、Kubernetesやパブリッククラウド（AWS、Azure、GCP）の進化を指している可能性が高いです。
• 「プロジェクト終了」 という流れは、企業がオンプレや自社構築のクラウドから、よりコスト効率が良く運用負担が少ないパブリッククラウドに移行していく傾向を表しています。
• 「小手先の技やTipsばかりがうまくなった」 という言葉は、例えばOpenStackや特定のミドルウェアの細かい設定やトラブルシューティングに強かったが、根本的なOSやネットワークの理解が浅かったことを示唆しています。
もしこの仮説が正しければ、この技術は「OpenStack」や「VMware vSphere」といった、かつて企業のデータセンターやプライベートクラウド構築の主役だったものの、クラウドの台頭により徐々にシェアを失っている領域を指していると考えられます。
さらに深読みすると、この「上位互換の技術」とはKubernetes であり、より広く言えばパブリッククラウドサービス（AWS,Azure,GCP） のことを指しているのでしょう。
この技術の死に直面している筆者の無念さや、自らのキャリアの喪失感、そして基礎的なCS（Computer Science）の重要性を痛感する気持ちは非常に共感できますね。
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 1110 | 【2025年版】旅行中に着る服の考察と実践 -メンズ編 - SANOGRAPHIXBlog | text.sanographix.net |
| 1019 | 「給料をもらって仕事をしている自覚がないのか」 ：南場連載 ｜株式会社ディー・エヌ・エー ｜DeNA | dena.com |
| 1018 | 描く人へ -こうの史代 / 読切 描く人へ ｜ゼノン編集部 | comic-zenon.com |
| 1003 | 好きなことで生きていく - megamouthの葬列 | www.megamouth.info |
| 910 | 嘘から始まった「スウェーデンの任天堂」奇跡の物語 ～北欧ゲーム市場を開拓した一介の電気店～ | famicoms.net |
| 727 | 彬子女王のオールナイトニッポンPremium ｜ニッポン放送PODCASTSTATION -ポッドキャストステーション- | podcast.1242.com |
| 632 | 自宅サーバの使いみち (2025-Q1) | waf.nopth.ink |
| 625 | 財務省、介護職の賃上げに難色 処遇改善より“選ばれる職場”を強調 財政審 ｜介護ニュースJoint | www.joint-kaigo.com |
| 616 | 余った液晶を情報端末にする ｜ OKUTSU | henjinkutsu.com |
| 579 | 「スクショ」の商標登録について｜GMO MEDIA | www.gmo.media |
| 543 | ChatGPTと1週間本気で語りあったら、いつか来てほしい未来が見えた - kondoyukoの踊る編集室 | blog.kondoyuko.com |
| 539 | 材料3つで簡単！ちょっぴりレトロな「ほろ苦キャラメルプリン」の作り方 ｜ フーディストノート | foodistnote.recipe-blog.jp |
| 526 | 警察官をかたる詐欺 警視庁 | www.keishicho.metro.tokyo.lg.jp |
| 500 | ロシア・ウクライナ戦争から3年。これまでとこれからを考える。東野篤子氏インタビュー。｜LessisMore.by Infomart Corporation | note-infomart.jp |
| 486 | 画面仕様書への静的検査器を実装したらたくさんの欠陥を発見できた話 -DeNA TestingBlog | swet.dena.com |
| 466 | Travelキャンセル保険｜Mysurance【公式】 | www.mysurance.co.jp |
| 465 | 【C#】何故C# を好むのか。～他の言語と比較しながら～ - ねののお庭。 | blog.neno.dev |
| 435 | 神田裕子著『職場の「困った人」をうまく動かす心理術』について ｜三笠書房 | www.mikasashobo.co.jp |
| 422 | 店主「本日予約で貸切です」貼り紙ガン無視で“開店10分前”に2名来店！？客の行為に波紋「残念です」 ｜TRILL【トリル】 | trilltrill.jp |
| 399 | 『ブクマカレンダー』自分のブックマークをカレンダーで見れます - kakeiF451の日記 | kakeif451.hatenablog.jp |
| 389 | 政治資金収支報告書データベース | political-finance-database.com |
| 371 | #AppleNotesの「ノートリンク」機能が便利すぎて、使い方を見直した | kaden-box.jp |
| 367 | GPT-4.1 Prompting Guide ｜ OpenAI Cookbook | cookbook.openai.com |
| 360 | 👨🔧人間をMCPツールとして利用する | times.serizawa.me |
| 356 | 金曜ロードショー｜グッドスマイルカンパニー公式ショップ | www.goodsmile.com |
| 348 | 【謎】日本の高齢者がAdoやtukiのように顔出ししない歌手に厳しい理由ｗｗｗｗｗ | visual-matome.com |
| 345 | オンプレミスとAWSの通信の仕組みの違いを徹底的に解説 ｜コラム ｜クラウドソリューション｜サービス｜法人のお客さま｜NTT東日本 | business.ntt-east.co.jp |
| 338 | NHK総合「激突メシあがれ」に登場したうどんと佐渡の食材について -趣味の製麺 | www.seimen.club |
| 331 | 当公園に「大阪・関西万博」会場と間違えて来られるお客様が大変多くなっています（2025年4月30日） ｜万博記念公園 | www.expo70-park.jp |
| 325 | ドラえもん最終回 巷で有名になった同人誌です。 - ☆クロスファイア（ＣＦ）☆Ｒ４☆：楽天ブログ | plaza.rakuten.co.jp |
他社からの移行案件でインフラを見ていると、特に大手のSIer が絡んでいる案件で感じる。
何か月も何年も、CPU使用率は10 % 程度、メモリ使用率も 30 % 行かず、ストレージもほぼ使われていないのに、めちゃくちゃなコア数のCPU やメモリを積んで
オンプレミスで最初にキッティングしたリソースから変更が難しいのなら分かるが、パブリッククラウドの強みはスケーラビリティじゃなかったのか。
今まで顧客が垂れ流したコストを考えてみて欲しい。大手の関わる規模だと、下手すると数億のムダ金を垂れ流しているじゃないか。それは、君たちの出しているコストではない。顧客の出しているコストだ。
それは全部顧客が支払っているから、運用しているシステム屋には関係無いじゃないんだよ。
そんなの不誠実ではないか。
移行してくる顧客は口をそろえて、以前のところは高すぎると言うが、ふたを開けるとムダ金を垂れ流している状態ということがほとんどだ。
それでいてがっつり運用費は取るわけで、君たちは何を運用しているんだ。
もしかして、インフラ費用を間に入って支払っているから、無駄なコストの上に数パーセント上乗せして儲けられるとか考えているのか？
それでいて、リソースがひっ迫し始めたら、コードのチューニングは無視してまたインフラを増強するんだろう。
技術者として恥ずかしい振る舞いをするのはもうやめて欲しい。
これはオンプレミス回帰を謳っていたり、パブリッククラウドを否定するものでは無いです
2025年現在、サーバを準備するってなると、初手でAWS だのGCP だのってのをSNS ではよく目にするけど、
世の中の大半のシステムって、レンサバで十分だし、もっと言うなら事務所の片隅に置いたラップトップに「絶対シャットダウンしないでください」って付箋貼って置いておけば十分なモノばっかりじゃない？
オートスケールが云々とか、スペックの拡張が容易だとかクラウドのメリットはたくさんあるけど、実運用でそんなに使わなくない？
VM のスペックが足りなくなってきたから拡張しますっって、そんな場当たり的な対応よりも、コードのチューニングした方が良くない？
テレビで特集されたとかでアクセスが増えたときに捌けないと困るとか、そんなのサーバが落ちた方が流行ってる感出るじゃん
機会損失とか言うけど、そんなテレビの特集で最終的に購入までしてくれるユーザなんてほんの一握りなわけで、そこに大した機会なんてないんですよ
確かに超有名なサービスとかなら、そういうのがあった方が良いと思うけど、世の中の大半って管理者用の管理サイトとか、大したアクセスもないコーポレートサイトとか
そんなのばっかりでしょ
月額のコストを見ても、クラウドは過剰なコストが掛かりすぎてる場合が大半じゃない？
今一度本質を見つめなおして欲しい
https://president.jp/articles/-/87827
このままでは国民皆保険が壊れていく…金子勝｢マイナ保険証は政治献金企業が儲かる究極の寄生システム｣
敬称略です。
政治献金と技術的に遅れた日本の情報産業のための救済事業との結びつきは非常に強い。
ほぼ10年間でマイナンバー関連事業を少なくとも3000億円近く発注していると見られるが、大企業8社が共同受注などで独占的に契約している。
そんなことはありません。むしろ、大手IT企業はこの手の自治体公共事業が薄利すぎて足を洗いたがっているというのがほぼほぼ現在の状況です。最近では大手の撤退が激しく、元々大手が担っていた部分を別の中堅SIerが無理して受注したものの、ノウハウもなく薄利過ぎて対応出来ず納期通りに納品できない案件が続発しています。そこで、入札参加条件が上げられた結果、入札が予定価格を上回り、随意契約になると言うケースが多発しています。
見る人が見れば、NTT系が基本を抑えつつ、周辺の企業が参画しているというのがわかると思います。大手5社のコンソーシアムで、NTTコムがメイン、NTTデータ、NEC、日立、富士通の合わせて5社で共同受注しています。そして、他に手を上げた企業はありません。
NEC・日立・富士通は関連公共システム（住基や戸籍、税務システムなど）が関わりそれらとのつなぎ込みが必要になるからですね。
他に手を上げた企業がない上、入札では予定価格を上回ってしまった結果、随意契約と言うケースです。報道によれば、いずれも随意契約にするにあたって、調整の結果入札価格よりも低い価格で受注させているようです。
他、凸版とDNPは物理的なカードの発行業務をやっており、合わせて800億円ぐらいの受注額です。そしてマイナカードは1億枚発行していますので、1枚辺り800円。カードは物理的に1枚300円はしますし、送付事務に使う簡易書留は350円しますので。単純に残りの取り分は150円です。全然高くありませんね。ここで事務手続きなどをやる事になります。数が多いので最大限コストは低く抑えていると思いますし、全てが郵送交付ではないとか細かい話はあるでしょうけれども。
JECCはリース会社です。国の予算の関係でいったんファイナンスを引き受る。大手IT企業がごそっと出資している特殊な会社です。金額はでかいですがこの会社が入るのは主に行政の硬直性の問題です。
何故か突然旧ソ連・ロシア方面の用語が出てきて面食らった人もいると思いますが、オリガルヒとは、官製の新興財閥だそうで、その方面の人たちからは社会主義国家ソビエト連邦が崩壊したどさくさに紛れて、民間にいくときに出来た悪しき存在という事で、よく批判に出てくる用語です。
さて、彼らはオリガルヒなのでしょうか？
そんなわけないんですね。
一般的にIT企業が求める水準の利益率とは30%と言われる中、政府系の仕事は利益率が1割を切る事があたりまえです。エンジニア不足の中でやりたくない仕事です。
NTT系が1300億円程度の受注をし、物理的発行やリース会社を合わせて8割以上で、残りとは大きな差があります。ここで金子らなぜNEC日立富士通を入れたのか。それは5社が献金していると言いたいが為に3社を水増しした感じがしますね。
まずは、利便性について検討しましょう。金子はこの一文のみ、内容も根拠も全く触れず、まるで自明のような扱いですが事実とは異なります。
政府は、マイナンバーカードの調査を定期的に行っており、最新の結果はこちらです。
少なくとも、利便性が「まったくない」と言う事は「まったくない」ことがわかります。
やたら多くの紐付けをするために、なくしたり盗まれたりすると、すべての個人情報が漏れてしまう。
ここでは逆に、全ての情報が漏れるにはどのような条件が揃う必要があるかを並べてみると
と言う事が必要。
と言う事が必要です。
さてこれを「セキュリティがまったくない」と表現するのが適切でしょうか？
現状、これよりも固いセキュリティを強いているシステムは本当にわずかです。
暗証番号のない顔認証マイナ保険証、スマホのマイナ保険証（これもマイナ保険証をスマホに接触させないと使えない無意味なもの）など、数種類のカードが発行される極めて非効率なもの
これは明確に誤りです。何故ならば、1人に発行されるマイナカードは1枚しかないからです。受け取る側のシステムも一つ。
「マイナ保険証をスマホに接触させないと使えない無意味なもの」も誤りです。最初の1回だけ行えばよく、使う時にマイナカードは必要ありません。
初回のそれはマイナカードで認証する為に必要というだけの話です。
さて、金子はこの状況を「数種類のカードが発行される極めて非効率なもの」とする一方で、「多数数の紐付けを止め、一つひとつ独自のOS（オペレーティング・システム）で」を提言しているのですが、整合性がありません。
マイナンバーシステムが設計されたのは今から10年前の2014年ですが、当時はまだスマートフォンに安全に電子証明書を持たせる仕組みがありませんでした。
現在できる様になったのは、日本政府や担う企業なども参画し国際標準規格を作ったからです。ISO18013-5が正式に出来たのは2021年です。最初からできた所は存在しないでしょう。そしてこの規格を世界が利用しようとしています。
これも誤りです。いまでもICカードが最も堅いセキュリティ確保の手段の一つです。
それは何故かと言うと、ICカードに入れた鍵は、現実的な手段では取り出す事も複製もできないからです。これはパスワードが漏れていても完全に中身を出せないと言う意味でもあります。
こういったことを言っている人は、大抵プラスチックカードといえば磁気カードの時代で認識が止まっている事が多いです。
ICカードは、単に定型の情報を返すものではなく、このカード自体がコンピュータです。マイナカードを利用する時にパスワードを入れますが、このパスワードはオンラインではなく、カードの中で処理されます。そして複数回数間違えると、カードの中の最も重要な鍵、電子証明書が消されアクセス出来なくなります。また、電子証明書も、このICカードが演算して帰す事で行われます。こういったことを理解しているのでしょうか。
また、顔認証が不安定という詳細が明らかにされていませんが、事実として顔認証は99%の精度があります。たまに「マスクをしていたのに顔認証が通った」という人もいますが、これはマスクをしていても顔認証ができる技術を使っているからです。他人のマイナカードで認証ができてしまったと言った話が出回っていますが、反マイナカード保険証団体の調査した結果2件だそうです。日本の保険医療の件数は数億件ありますが、そのうち2件です。
その理由をオンプレミス方式で、クラウドプラットフォームにしてないからだと説くのですが、今回出てきたトラブルはシステム的なトラブルはほんのわずかであり、ほとんどはインプットするデータの問題でした。
これは、仮にアメリや中国の巨大IT企業に依頼しても同じ事が起きていたでしょう。
金子は「マイナ保険証のひどい醜態」を自明のごとく上げていますが、その具体的な中身について一切論じていませんが、これが事実だと言う客観的な証拠がありません。全国民が使用しているシステムであると言う事を考えたとき、例外でマイナーなトラブルしか起きていませんが、これはむしろ過剰品質とさえ言える状態です。
オードリー・タン氏は、マイナンバーシステムの普及が必要不可欠だと言う事を自明のものとして扱った上で、普及を進めるにはどのようにしたら良いかと言う点で多くの提言を行っています。
また、台湾は日本以上に全ての情報が「中華民國統一證號」に統一されており、身分証の携帯が義務づけられているなど、日本より遙か前から「国民総背番号制です。前からあるが故にシステムが古い所があって運用に苦労をしているようですが、その全てを捨てて失敗だなという暴論が出ているとは聞いたことがありません。
ちょっとこれの意味が分かりません。金子は、オードリー・タン氏の名前を出した直後にこれを言っているのですが。その段落を全部抜き出すとこうです。
マイナ保険証については、通常の健康保険証廃止を止め、一からやり直して、クラウド上でスマホのアプリにする。多数の紐付けを止め、一つひとつ独自のOS（オペレーティング・システム）で丁寧にプログラムを組んでいくことが必要である。
もっと意味が分かりませんが、ここから頑張ってエスパーしてみます。
これについては全く逆です。マイナンバーシステムを通じてデータを関連づけすることによって、システム間で生の個人情報を槍と知りなくて良くなると言うメリットがあります。
共通IDがない場合、一貫した行政処理を行う時には、住所氏名生年月日といった従来からの本人の個人情報で判別するしかなくなります。
一方で統一つぃたIDで管理されている場合は、その結びつけの情報だけでデータのやりとりが出来ます。また、結びつけの情報は中央に存在するシステムが管理するのみで、接続されているそれぞれのシステムではユーザを識別する情報は別々です。中心に存在するシステムを通さないと結びつけが出来ない仕組みになっています。
また、中央のシステムで結びつけの情報を捨てるだけで容易に結びつけが出来なくすることが簡単にできます。
しかし、リアル情報を使ってしまうとそのような事はできません。
既にマイナポータルはスマホで動いていますし、一からやり直す必要はありません。
また、既に述べたようにICカードは現時点で全国民規模で動作させるセキュリティとしては最も固いものの一つです。スマホのアプリ専用にするのはセキュリティ（これは情報保護・不正アクセス回避という他に、可用性という意味も含みます）の問題があります。
現在、スマートフォンに入れることが出来る環境が揃ってきましたので、スマートフォンに入れた証明書を普段は使用して、マイナカード本体は家に置いておく、と言うスタイルが可能になります。
また、マイナカードのアプリケーションはいわゆる「クラウド」と呼ばれるシステムで多数動いており、既にクラウド上であると言えます。
既にOSレベルで独自に作成する意味はありません。それも一つ一つ別のシステムに刷るなどと言う意味はありません。
これは、交通安全のために、全ての自動車の運転方法をバラバラにするべきだ、と言っているようなものです。
また、問題になっているのはその上に乗っているサービスであるため、これによって何かが良くなることはありません。
一概には言えませんが、金子が成功例としてあげるGAFAMなどでは「Agile開発」と言われる手法が一般的になっていますが、これは「丁寧にプログラムを組んでいく」から連想されるものとは大きく異なるものです。
政府や厚生労働省が描いている医療の姿はまさにこれそのもの（もう少し具体化され、洗練されていますが）だと思いますが、何故これが「完全に間違っている」のでしょうか。
また既に実現している部分があります。
一方で実現されていない部分もあり、それを補うためにマイナンバーシステムを共通IDとして活用しようと言う事になっています。
昨年、一念発起して100kgの大台から70kgまで、30kgの減量に成功した。
やたらと知見を共有したがるのはエンジニアの美点の一つだが、私もその例にならい、ここにダイエット中に学んだことを共有しようと筆を執っている。
ダイエットとはそもそも、日常の食事のことを指し、それが転じて食習慣の適正化を意味するようになった。
減量の本質もそこにある。
人は食べたものからできている。食習慣を適正化すれば、自然と健康的になる。
30kgもの減量に成功した最大の要因は、自分がエンジニアであったことだと思う。
そもそもプログラミングとは、入力されたデータに対して任意の出力データを得るために加工する、その計算方法を設計し、実装することを指す。
料理もまた同じで、食材という入力に対して、調理を実施し、料理という出力を得る。
そのため、体重と食習慣の適正化というプロジェクトに対して、プロジェクトのマネジメント手法が応用可能なのだ。
メモリ4GBのオンボロPC抱えてパイプ椅子で開発すすめても、ろくに進捗しないのと同じだ。
ただし、闇雲に金をかければよいというものでもない。投資すべきものというのは、だいたい決まっている。
どれも無くても減量自体は可能なものばかりだが、あったほうが効率が良い。
そもそも減量はモチベーション管理のゲームなので、自動化、簡易化できるところはやったほうがいい。
金を払って健康を買っていると考えればよい。
まったくアーキテクチャを考えず、行き当たりばったりでファイルごとに違う設計のプロジェクトは悲惨な結果を招く。
最初にこのアーキテクチャで行くと決め、ひとまずはそれを続けることが大事だ。
減量で言えば、ローファットでいくかローカーボでいくかということだ。
日によって低脂質でいったり低糖質でいったりするのは全く良くない。
自分は低脂質でいくことにした。そのほうが筋肉量の減少を抑えられるし、コレステロール値の改善にも効果的だからだ。
金融系プロジェクトにありがちな細かすぎるコード規約は有害無益で時間と金の無駄だが、余りにフリーダムなのも混乱のもとである。
減量でいえば、目標カロリー量とPFCバランスだ。ここがいい加減だと、到底うまくいかない。
カロリー量はハリス・ベネディクト方程式から出される基礎代謝の1.5倍とかに設定すればよいだろう
そのうえで、低脂質ならP:30%, F:20%, C:50%のように割り振ろう。
たとえば1600kcal目標なら、P: 480kcal = 120g, F: 320kcal = 35g, C: 800kcal =200g、といった感じだ。
この規約を守るためにも、あすげん/カロミルがあれば、計算が楽だったというわけだ。
プログラミングでは、実行時に行うと重すぎる計算はビルド時など事前に行ったりすることがある。
初代スーパーマリオブラザーズのジャンプは、1フレームごとに重力係数をかけて計算しているわけではなく、加速度がハードコードされている。
ブロック崩しでさえ物理演算するような現代においても、似たようなことをすることはある。
ダイエットで言えば、時間的余裕のあるタイミングで、できることをしておけということになる。
キャベツを千切りにしたり、きゅうりやトマトを切ったり、オートミールに材料混ぜておくことは事前にできることなのだ。
夜寝る前などにやっておき、明日の調理工数を最低限にしておくことが大事だ。
処理したものはジップロックコンテナにでも入れて、冷蔵庫にしまっておこう。
よく食べる鶏むね肉や牛もも肉なんかもキロ単位で大量買いして、1食量ごとに切り分け、ジップロックバッグに入れて冷凍庫に入れておこう。
適切なキャッシュがもたらす実行速度の向上効果は非常に大きい。
これは料理についても言える。
毎食ごとに献立を考え、材料を揃え、包丁で切ったり、コンロで焼いたり…などの調理を行うのは非常に非効率である。
いわば冷蔵庫はメモリキャッシュであり、冷凍庫はディスクキャッシュのようなものである。
よく1人分作るのも3人分作るのも変わらないよ〜などと言うが、同じ理屈で1食分作るのも、3食分作るのも、手間としてはたいして変わらない。
すでに広く使われ、実績のあるライブラリがあるのに、なぜ一から作らなければならないのか。
これはダイエットについても言える。
安価で大量に手に入るカット野菜などは、買ってしまえばいいのだ。
たとえばきんぴらごぼう。作ると面倒なきんぴらごぼうだけど、その面倒さの9割はごぼうを千切りするところにある。
千切りして水にさらし終わったら、きんぴらごぼうの調理工程の9割は終わっている。
しかもこの部分は、工数が量に依存しているため、大量作成の恩恵を受けづらい部分だ。O(n)である。
一方でカットごぼうを大量買いすれば、あとは炒めるだけなので量に依存せず、大量作成が容易になる。O(1)にすることができる。
他にも、オイコスヨーグルトとか、サラダチキンとか、Baseブレッドなどの外部サービスを使うのも良い。
プロジェクトの初期段階、リードエンジニアが重要なクラス群とサンプルとなるクラスをいくつか作った後は、それをひらすらに横展開していくことになる。
この段階では天才エンジニアなど必要なく、コピペマンでじゅうぶんになる。むしろ下手に独自の考えを持たず従順に開発してくれるぶん、そのほうが良いことさえある。
ダイエットについても同じことが言える。
なぜ毎食毎食、独自の健康メニューを考え出さないといけないのか。食事の都度、栄養成分を計算し、調整しなければならないのか。
あすけんで一度100点をとったらあとは、ひたすらそれをこすり続ければいいだろう。
朝
蒸しかぼちゃ
昼
ふかしたさつまいも
蒸しかぼちゃ
夜
りんご（皮ごと）
蒸しかぼちゃ
毎食似たようなものを食べていることがわかるだろう。
これは日単位でも同じで、別の日は牛もも肉が刺し身になったり、さつまいもが蕎麦になったりはするが、その程度の差だ。
どうしても違うものが食べたくなったら、そのときに改めて計算すれば良いのだ。
そうすれば手持ちのカードが増えていく。
インシデントが発生したとき、必要なのはリカバリーであって、そんな時に人を責めても何の役にも立たない。時間の無駄だし、士気も下がるだけだ
こうしたとき、自分を責めても仕方がない。自分をクビにはできないし、ダイエットは長期戦なのだ。
ある日に食べすぎたからと言って、次の日にその分を減らすと、必要な糖質や脂質が不足して代謝が落ちてしまったり、だるさが抜けなくなったりするため、そういう方向でのリカバリーはやめよう。
しっかりと痩せる食事スタイルが確立しているなら、それを続ければ良いだけだ。
どうせ1食程度ではそんなに太ることはできない。
計測は減量期間中だけでなく、むしろ減量終了後にこそ必要になる。
そもそも、減量前の食事が減量前の体重を作り上げてきたのだから、減量前の食事に戻せば、体重も戻るのは当然のこと。
もとの体重に戻りたくないなら、新たな食習慣を作り上げる必要がある。
プロダクトリリース後、つまり減量後の運用フェーズにうつったら、減量飯でもデブ飯でもない、心にも体にも良い食習慣へと移っていこう。
急激なUI変更がユーザーの反発を招くように、急激な食事変更は体重の反発（リバウンド）を招く。
そこで、オートミールだったところを玄米ごはんにするとか、ささみだったところを蒸し鶏にするとか、ちょっとずつ維持するためのご飯へと変えていき、どのくらいの量なら大丈夫なのかを見つつ、ソフトランディングしていこう。
要件満たすため・社内政治的な理由でピンポイントで別のところ使う＋併用はあっても、
ゼロトラストセキュリティは、「信頼せず、常に検証する」という原則に基づいています。主な特徴として、常時の認証と承認、最小権限アクセス、アクセスの継続的な監視があります。以下の技術やソリューションを組み合わせることで、包括的なゼロトラストセキュリティモデルを構築できます。
1.Microsoft EntraID（旧AzureAD）：
3. 多要素認証（MFA）：
1.暗号化：
私はプロではないのでわからないので、間違っているのは当たり前だと思って読んでください。
個々人のエンジニアの能力がとかクレジットカードがとかは基本関係ないという話です。
（関係なくてもパスワードを使い回している場合は、同じパスワードを使っているサービスのパスワードはすぐ変えるの推奨）
私は長年社内システムの奴隷をやって参りました。現在のクラウドになる前のサーバも触って参りましたので、その辺りからお話しをさせてください。
サーバーというのは、簡単に言うとシステムを提供しているコンピュータです。
貴方が触っているコンピュータシステムのネットワークの向こう側にいます。この増田も増田のサーバーというのがいて、私たちにサービスを提供してくれています。
しかし、このサーバ、どんなイメージを持っていますか？ でっかい黒い冷蔵庫？ちかちか光るロッカー？ それともバーチャルのネットワークで画面上に写されるものでしょうか。
サーバーといっても、実４形態ぐらいあるのです。私もチョットワカルぐらいなので間違っていると思いますが、まずは理解する為に簡単に説明させてください。
と言う段階があります。
ニコニコ動画のサービスはどうかというと、色々な情報を得ると、④を使いながら③にする途中で、まだ②が残っている、ということのようですね。
これらの使い分けについてですが、最近は自社でサーバを持っていると自分たちで管理しなければならなかったりして大変なので、できるだけ②から③、できたら④に持っていきたいと言うのが世の中の流れです。それでも②はのこりますが、最小限にしていく方向。
現在は、②のシステムがだけがやられたように、セキュリティ的にも預けた方が望ましいと言われています。
今回も、自社で管理している部分が攻撃されました。特にクレジットカード情報が漏れていないと何度も言われているのは、そこを自社で管理せずに専門業者に任せていたことが大きいわけです。
この流れをまずは頭に入れましょう。
さて、メールを扱ってるサーバーと、売れた商品をバーコードでピッとして管理するシステムは全く別でどちらかがハッキングされたからといってもう一つもされるこことはありません。これは何故かと言うと、それぞれを細かくたくさんのシステムや仮想サーバに別けた独立なシステムになっているからです。
さらにKADOKAWAのようにサービスを外部に展開してる会社の場合、外部向けのシステムと内部向けのもの（バックオフィス）で必要な機能が異なるので、部署が異なるのと同じように違う仕組みになっているはずです。ただし、物理的にどこにサーバがあるかなどはあまり関係がありません。
しかし、こうなると小さなサーバがたくさんたくさんあると言う状態になって管理が大変です。
利用者の視点にしても、システムごとにログインするための情報が別々だと非常に使いづらいですよね。会社で部屋ごとに別々の鍵がついていて、じゃらじゃら鍵束を持って歩くような状態は面倒です。
すると、どうするかというと、これらをまとめて管理するシステムというものが作られます。
これを「システム管理ソフト」と「認証システム」といいます。これらが全体に対してユーザ認証や、サーバが正常に動いているかどうかの管理を提供する事で、たくさんのシステムの管理を効率化するのです。
企業の警備室に機能を集約するようなものです。ですが、ここが要になっていて、破られると全ての鍵が流出してしまうということになるわけです。
出てきた情報から見ると、この管理するシステムと認証するシステムがやられたと思われます。
また、その前の前段はVPNと言う仕組み（ネットワークを暗号化して安全に隔離するもの）が攻撃されて破られたのではないかと推測しています。
これは近頃猛威を振るっている攻撃で、業務用で多く使われているVPN装置の脆弱性（弱点）が狙われて、多数の問題が起きています。当然脆弱性を修正したプログラムは適用されていると思いますが、次から次へと新たなセキュリティホールが見つかる状況であり、匿名のアングラネットでは脆弱性情報が取引されているため、訂正版のプログラムが出る前の攻撃情報が用いられた可能性があります。（これをゼロデイ攻撃といいます） あくまでも推測ではありますが。
個々のシステムは独立しています。ですが、こうなってくると、今回はシステム全体が影響を受け、さらにどこまで影響が及んでいるかの分析が困難なレベルだと言われています。
ここまで広範囲に影響するとすると、管理と認証とVPNが攻撃を受けてやられたとみるべきでしょう。
また、ここが破られていると、クラウドシステムにも影響が及ぶケースがあります。
一時期「クラウド」というとストレージの事を言うぐらい、クラウドストレージが当たり前になって、自社運用ファイルサーバは減りました。これは今では危険と認識されているほかに、こちらの方が安く利便性も高いからです。
それ故に、クラウドストレージ、たとえばSharePoint OnlineやGoogleDrive、Boxなど外部のシステムに置くようになっています。
オンプレミスの認証サーバが破られているので、その認証情報を利用してクラウドにアクセスできてしまったものだと思われます。言わば、鍵を集めて保管してあった金庫がやぶられるようなもの。
通常、クラウドシステムはそんなに甘い認証にはなっていません。例えば多要素認証といってスマホなどから追加で認証すると言うような仕組みがあります。貸金庫に入るとき、自称するだけでは入れず、身分証明書とパスワードの両方が必要なうなものです。
また、日本企業なのに突然ロシアからアクセスされたりすると警報をだして遮断する仕組みがあります。
とはいえ、いちいちクラウドにアクセスする度に追加認証をしていると大変で、面倒クサいと言う声が上がりがちです。
そんなときに行われてしまうのは、自社のネットワークからアクセスするときは、認証を甘くすると言う仕組みです。
つまり、ネットワークは安全だという仮定の下においてしまうわけですね。自社の作業着を着ている人なら合い言葉だけで、本人確認なしで出入り自由としてしまうようなものです。
ところが今回は、ここが破られてしまって被害を受けている可能性があります。自社の作業着が盗まれているので、それを着られてしまったので簡単に入れてしまったようなもの。
また、社内システムからデータを窃盗するには、どのシステムが重要かを判断しなければなりませんが、クラウドサービスだと世界共通であるため、一度入られてしまうと慣れ親しんだ様子で好きなようにデータを窃盗されてしまうわけです。
上記のことを踏まえて、KADOKAWAの展開してるサービス自体や、そこに登録しているクレジットカードは「おそらく」大丈夫です。パスワードも「ハッシュ化」という処置を経て通常は記録されていません。
ただ、パスワードを使い回している方は、その事実とは別にそもそも危険です。パスワード変更をおすすめします。さらに、ハッシュ化をされていても、時間をかければ色々な方法でパスワードを抜き出す事も不可能では無いことも忘れずに覚えておきましょう。
しかし、単なるユーザー、お客さんではなく、KADOKAWAと会社として関わってる人や従業員、取引先で色々な書類等出した人は、既に情報が窃盗されていて、そこから今後も追加で情報が出回る可能性があります。
一方で、分かりやすい場所に保存されていたわけではない情報（システムのデータベース上にだけ入っていたものなど）は、センセーショナルな形で流出したりはしないのではないかと予想しています。
犯人が本当に金が理由だとするならば、データを分析するような無駄な事に労力を割かないためです。
腹いせで全てのデータを流して、暇人が解析する可能性はあります。
ありますが、犯人はコストを回収しようとするので、これらの情報を販売しようとします。売り物になる可能性のものをただ単に流したりもしづらいのではないかと思っています。
もちろん、油断はするべきではありませんし、購入者が現れるとすると購入者は具体的な利用目的で購入するため、より深刻な被害に繋がる可能性も残されています。
犯人が悪いからやられたのです。レベルが低いからとか関係ありません。
また、周到にソーシャルハッキング（オレオレ詐欺のようになりすまして情報を搾取するなどの方法）や、このために温存したゼロデイ攻撃（まだ誰も報告していない不具合を利用した攻撃）を駆使され、標的型攻撃（不特定多数ではなく、名指して攻撃すること）をされると、全くの無傷でいられる企業や団体は、恐らく世界中どこにも存在しません。
それは大前提とした上で、敢えて言うならば、どちらかというと、経営判断が大きいと思われます。
ニコニコ系のサービスと、KADOKAWAの業務システムと2つに別けて話しをしましょう。
ニコニコ系のサービスは、現在、クラウドにシステムをリフトアップしている最中だったと思われます。先日のAWS（クラウドサービスの大手企業）の講演会で発表があったようにです。
ですが、この動きは、ニコニコのようにITサービスを専門にする企業としては少し遅めであると言わざるを得ません。
これは何故かと言うと、ニコニコ動画というサービスが、日本国内でも有数の巨大なサービスだったからだと思われます。特殊すぎてそれを受け入れられるクラウドサービスが育つまで待つ必要があったと思われます。
それが可能になったのはようやく最近で、動画配信系はクラウドに揚げて、残りを開発している最中だったわですが、そこを狙われたという状態ですね。
ただ、厳しい見方をするのであれば、その前に、クラウドに移行する前に自社オンプレのセキュリティ対策を行っておくべきだったと思います。結果論ですが。
それをせずに一足飛びでクラウドに移行しようとしたというのだとは思います。確かに一気に行けてしまえば、自社オンプレに施した対策は無駄になります。コストを考えると、私が経営者でもそう言う判断をしたかも知れません。
KADOKAWAの業務システムですが、これはITを専門としない企業であれば、オンプレミス運用（②番）が多く残るのは普通です。
何故かと言うとシステムとは投資と費用なので、一度購入したら4年間は使わないといけないからです。そして自社向けであればそれぐらいのサイクルで動かしても問題はありません。
しかし、それ故に内部的なセキュリテ対策の投資はしておくべきだったと思います。
以上の様にエンジニアのレベルととかは関係ありません。基本的には経営者の経営判断の問題です。エンジニアに責任があるとすれば、経営者に対して問題点を説明し、セキュリティを確保させる事ができなかったと言う所にあるでしょう。
ですが、パソコンのことﾁｮｯﾄﾜｶﾙ私として、想像するのです。彼らの立場だったら…自社グループに経験豊富なエンジニアがいて、一足飛びにクラウドへリフトアップができそうなら、既存の自社サービスのセキュリティ変更に投資はしないと思います。
逆に、パソコンに詳しくなく、自社部門だけでは対応が難しく、SIerの支援を受けつつやらなければならないと言うのならば、SIerは固いセキュリティの仕組みを付けるでしょうし、システムごとにSIerが異なることから自然とシステムは分離されていたでしょう。
そして減価償却が終わった者から徐々にになるので時間がかかることから、昨今の事情により、セキュリティ変更に投資をしてからスタートしたかも知れません。
ただし、繰り返しになりますが、犯人が悪いからやられたのです。レベルが低いからとか関係ありません。
（おそらくは）社内のシステム管理を、自社でできるからと言って一本化して弱点を作ってしまったのは不味かったと思います。
先ほど述べたように、高度化していく手口でシステムへの侵入は防ぐことが出来ません。
なので、システムは必ず破られると考えて、それ以上被害を広げないこと、一つのシステムが破られたからと言って他のシステムに波及しないようにすることなどを意識する必要がありました。
これは物理的な話しではなくて、論理的な話です。例えば物理的に集約されていてもちゃんと別けていれば問題ないし、物理的に分散していても理論的に繋がっていたら同じです。
すごく簡単に言えば、管理するグループを何個かに分けておけば、どれか一つが破られても残りは無事だった可能性があります。
とりあえず今まで出てきた内容からするとニコニコとかその他のKADOKAWAの外部的なサービスは人員的にも予算的にも全然関係ない感じ
結局社内のITシステムに十分な投資（経営陣のトレーニングまでを含めた）をしなかったという月並みの話なんですかね
Permalink |記事への反応(12) | 21:43
インパラ・・・ウシ科に分類される偶蹄類。本種のみでインパラ属を構成する。
インパラ・・・ゼネラルモーターズ (GM) がシボレーブランドで販売している大型乗用車
インペラ・・・液体・気体用の遠心力ポンプや発電機等に使用される羽根車
インペラトル・・・ローマにおける軍指揮者、凱旋将軍・大将軍、元首・皇帝
オンプレ・・・オンプレミス（自社サーバーでシステムを運用する形態）
（追記）
現代分類学の秘孔を突く新機軸エントリに思いのほかトラバブクマ集まったな。みんなサンキュー。
みんな知ってるか？インパラってめちゃ育てるのが難しくてどうもたぶんおそらくだけど日本の動物園にはいないっぽいぞ！？
「あーインパラねハイハイ見たことあるある」みたいに思ってるあなたのそのインパラっぽいイメージのやつ！、それ、「オリックス」ですから！！「アラビアオリックス」ですから！！「シロオリックス」ですから！！！「エランド」ですから！！！！
どうせ想像の中では雑魚モンス扱いなんだろ？ライオンチーターゴリラゴリラゴリラに見劣りするからな。でもな、敢えて言う実物を見てみろ！もも肉の感じとかサア！マジで生命感ハンパないぞ！見たことないが。
そもそもオンプレミスのシステムをクラウドに載せ替えてコストダウンできるという発想が間抜けだ。頭が悪い。クラウドはオンプレミスよりも高コストだと、ガートナーすら指摘している。クラウドにするのであれば、クラウドに適応したシステムに再構築すべきだ。例えば、静的ファイルは S3 +Cloudfront にして配信サーバーを少なくするとか、アプリケーションサーバーは需要に応じてインスタンスをスケールするようにして省力化するとか、データベースサーバーをAurora か RDS にしてバックアップの手間暇をなくしたりするとか、でもしないとクラウド化で高コスト化しちゃうよ。
ちょっと前なら400万欲しいなら、
Windows Server (Active Directory) のMCP 取って、CCNA 取って、LPIC1 取っておけばいいぞだったが
Windows Server のMCP 無くなった・・・(？)んだよな(追記：新設されました →Windows Server HybridAdministrator Associate(AZ-800、AZ-801))
割とまだオンプレミスAD (Active Directory)しかない環境やハイブリッド環境多いと思うがMS はAzureAD と Intune だけ使って！！😡ってやってる
いまは、CCNA とLPIC、それとAWS とAzure の資格ですかね
イメージとしては、クラウド保守ベンダーで働くとか、Microsoft365 のサポートやるとか、社内SE(インフラメイン)とかそういう感じです
ただインフラメインだとなんだかんだ場所に縛られる傾向が強いので(在宅可でも研修時は出社しろとかクライアントのセキュリティ規定が云々とか)
地方だとギリ400万に届かず月収換算32万くらいの可能性もあります
フルリーモートの社内SEやクラウドベンダーの案件は多少なりとも開発経験があることが要件になってたりすることがあるので
プログラムもできるにこしたことはないけど、アラサー以上でこれからエンジニアやるぞーの人はプログラム知識は優先度低いです
まずは、日立のサーバーでのWindows Server 2022への対応からお聞きした。
木村：サーバーにはHA8000VとRV3000の2ラインアップがあります。HA8000VがPCサーバーで、汎用的なサーバーとして、エントリー向けや、HCI、VDIのソリューションなど、いろいろな用途で使われています。RV3000はミッションクリティカル向けです。Windows Server 2022のプレインストール対応は、HA8000Vの全機種で2022年5月を予定しています。
Windowsサーバー市場における日立の強みとして、木村氏は、サポート力を挙げる。
木村：日立は長年に渡ってプラットフォーム製品の開発を行ってきました。作ってきたからこそ、中身がわかっている技術力があります。できることとできないことを技術者がわかっているので、障害が起きたときや問い合わせのときに、お客様に事実を真摯に伝え、重大な不具合があっても技術力で解決に向けていきます。何かあったときに問題をたらい回しにせず、技術力をコアにしてしっかり対応するサポート力が強みです。
こうした日立のDNAを結実させたサポート商品が「日立サポート360」だ。通常はサーバーのハードウェアからOS、ソフトウェアなどは、それぞれと契約し、サポートを受けることになる。日立サポート360ではこれらをワンストップで受け付け、支援することができる。
広瀬： 窓口が1つになるというのは他社でもありますが、そういう表面的な話だけではなく、複合的な力で問題解決支援にあたれるのが真の価値です。内部で、サーバーからOS、日立ミドルウェア、導入ミドルウェアなど、いろいろな製品の部門の連携がすごく濃密にされているからこそ、複合的な力で問題解決にあたれます。これが本当のワンストップの意味です。
この日立サポート360でWindows Server 2022のサポートにも対応する。日立では、長年のサポート実績により蓄積された技術力により高い自社解決率を誇るという。自社解決率が高ければ、それだけパートナーへのエスカレーションが減るわけで、短期間でのトラブル解決が期待できることになる。
日立のハイブリッドクラウドのソリューション「EverFlex fromHitachi」
木村氏は、日立のハイブリッドクラウド戦略としてEverFlex fromHitachi (以下、EverFlex)ソリューションを説明した。EverFlexは2021年10月にクラウドとのデータ連携ソリューションとして始まり、2022年2月にハイブリッドクラウドのソリューションとして強化された。
木村：お客様がオンプレミスとパブリッククラウドを使うときに、最適なシステム設計にして、コストも最適化していきます。ハイブリッドクラウドの導入には事前にアセスメントやコンサルティングを行うことが大切です。なぜなら、パブリッククラウドを導入することで負担が減るかと思われがちなのですが、ハイブリッド化されることで負担が増えることがあるからです。
EverFlexの特徴の中でも特に「クラウドライクなサービス提供」について木村氏は紹介した。
木村：ハイブリッドクラウドになると保守や運用が煩雑になります。パブリッククラウドとオンプレミスの両方を管理しなくてはならないため、システム管理において両方のノウハウが必要になります。このため保守・運用フェーズにおいて簡単化されずコスト最適化が課題となってきます。それを避けるために、共通化するニーズに応えるようにいろいろと工夫しています。
ハイブリッドクラウドソリューションEverFlex fromHitachi
まず、問い合わせをワンストップ化したり、運用管理を1つのツールで一元化したりすることで、顧客の負担を軽減する。
プラットフォームにおいては、オンプレミスからクラウド接続を可能にしてシームレスにお互いやりとりできるOSが各社ある。Windows Server 2022はまさにそれを特徴としており、同じくAzure Stack HCIも選択肢に入る。
さらに、支払い／利用形態についても、オンプレミスでも売り切りだけでなくフィー型も採用する。こうしたEverFlexの中でWindows Server 2022のユースケースを木村氏は2つ挙げた。
1つめは、運用管理の簡単化の部分で、AzurePortalからオンプレミスを管理できる機能の強化だ。
木村：オンプレミスにエージェントを入れておけば、管理者がAzurePortalだけをさわって、オンプレミスのリソースやイベントの管理も全て一元化できます。これに期待しています。
もう1つはセキュリティの強化だ。
木村：ハイブリッド化が進むと、両方の基盤をネットワークで接続することになります。従来には存在していなかった接続となるため、その部分でセキュリティの強化も進めなければなりません。そこでWindows Server 2022では、Secured-core ServerによってOSそのもののセキュリティレベルが上がっています。TPMと連動する機能によってハードからOSのレイヤーを守り、マルチレイヤーでセキュリティを強化しています。
そのほかにもクラウドライクの取り組みとして2つを木村氏は紹介した。
1つめは「サーバ予備リソース提供サービス」。サーバーを余分に設置し、支払いは電源を入れて使った月だけ発生するというサービスだ。
木村： 迅速でタイムリーにリソースを増強したいときに、クラウドなら自由に構成を変えられます。それをオンプレミスでもできるようにします。クラウドではインスタンス単位となり、ハードウェアの構成はメニューの中から選択することになりますが、オンプレミスでは構成を自由に組む事ができます。まずHCIソリューションから開始しましたが、2022年4月からはそれ以外にも拡大する予定です。
もう1つが「ハードウェア安定稼働支援サービス」。オンプレミス環境のサーバー運用管理を省力化するものだ。
木村： 旧来の保守では、ファームウェアのバージョンアップがあると、技術的にどういう影響があるかを確認して、その都度適用するかどうかを判断する必要がありました。それを提供元が判断するのがこのサービスです。お客様の機器を弊社で管理して、ファームウェアの推奨バージョンの選定や、更新作業などを一括でやります。
サブスクリプションに力を入れる
日立のこれからの注力分野について木村氏は、サブスクリプションに力を入れていくと語った。
木村： 全社的な方針で、サブスクリプションに力を入れていきます。クラウド化で初期投資をおさえるニーズと同時に、オンプレミスも求められています。そうしたお客様のニーズにアラインしていきます。
サブスクリプションやクラウドライクなサービスで管理を簡単にして顧客企業がコストを抑えることで、究極的な目的はその先のDXだと木村氏は語る。
木村：既存のプラットフォームのコストを最適化させ、浮かせた費用を新たな投資先として、AIやEdgeを活用する新たなデジタルソリューションの領域に向けていくことを支援していきたいと考えています。
そのために木村氏は、よりハイブリッドで使いやすいようなライセンス体系をマイクロソフトに期待している。
木村： 今後ハイブリッド化が進むと、繁忙期にリソースを拡張するといったこともあります。そのときにライセンスが、オンプレミスはオンプレミスで買って、AzureはAzureで課金してと、ハイブリッドで使いづらい体系になっています。将来的にライセンス体系を統一するなど、両方の基盤で使えるような体系になることを期待しています。
また、AzurePortalからオンプレミスを管理できる機能についても、さらなる強化を木村氏は期待する。
木村：AzurePortalからは管理できる範囲に限りがあります。OSから上のリソースやイベントは監視できるのですが、ハードウェアの死活監視や電源管理などは対応していないため、JP1やその他のツールなど、複数のツールを使いこなす必要があります。それらの管理ツールが乱立してしまうと、また管理の手間が増えてしまう。こういったことをオンプレのツールか、Portal側で統一することも期待したいところです。
https://www.sofia-inc.com/blog/7233.html
情シス（情報システム部）はもういらない？これからの情シスに求められる、あるべき姿とは？
皆さんは情シス（情報システム部）が果たす役割・機能を何だと考えますか？ 全社のIT戦略策定・システム企画、社内インフラやアプリの保守・運用、ユーザーサポートやトラブル対応といったことを思い浮かべる方が多いのではないでしょうか。
しかし昨今、情シスにそのような役割が求められていない、もしくは情シスの業務自体がなくなりつつあることをご存知でしょうか？
今回の記事では、これからの時代の情シスに求められる役割、あるべき姿について説明します。
近年MicrosoftAzureやAmazonWeb Serviceといったクラウドサービスの台頭により、オンプレミスからクラウドへの流れが起きています。社内に物理サーバーを置いて保守・運用するといった必要がなくなり、ソフトウェアもPaaS・SaaSといったクラウド上で提供されるサービスに代替されるようになってきています。それに伴い、膨大な設備投資費や社内SE（システムエンジニア）の人件費を削減できるようになりました。今後すべてのITリソースの保守が必要なくなるという可能性もあります。
デジタルトランスフォーメーション（DX）が多くの企業で重要課題となっている現代において、企業がIT活用で目指すべきことは、単純にITインフラ・ツールを変革させるということではありません。業務変革・組織変革を伴うような、より大きな次元での変革です。経済産業省も、ITを変えるだけがDXではないと説明しています。
「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」
このデジタルトランスフォーメーションの実現を企業が目指すにあたって、情シスの仕事も大きく転換しようとしているのです。次章では、まず従来の情シスの役割について整理・紹介していきます。
DX（デジタルトランスフォーメーション）を推進する上で押さえておきたい3つのステップ
昨今ビジネスの場において、DX（デジタルトランスフォーメーション）という概念が頻繁に取り上げられるようになりま…
これまでの情シスに求められていた役割は主に以下の４つでした。
会社の経営戦略や事業戦略に基づき、システムの企画立案・要件定義をする役割です。社外ベンダーの見積もり検討・選定、およびその後のプロジェクトマネジメントを遂行し、ユーザー部門に対して新しいシステムを開発・提供します。
社内ユーザー部門からのリクエストや業務プロセスの変更に応え、既存システムのカスタマイズなどを実施します。運用・保守によってシステムを安定稼働させ、会社の事業活動を下支えする役割を担います。
自社サーバーやネットワークの構築・運用・保守を行いつつ、セキュリティ対策やデータ保全を実施することで、万が一の事態に備えます。また新技術・製品の導入検討や評価を行って、常に社内環境のサービス向上に努める役割です。
社内ユーザーからの問い合わせ対応・トラブルシューティングを行います。ツールやシステムの導入サポートの他、新卒や転職者へ社内システムの教育を実施することで、社員１人1人の円滑な業務遂行を支援します。
以上が従来情シスに求められてきた役割ですが、現在のクラウド時代において運用・保守業務はその必要性を失っています。また業務システムについても、SaaSなどのクラウド上で提供されるアプリケーションを利用できるようになっており、企業独自でシステムを構築するということは少なくなっているのです。
このような中で、今後情シスには一体どんな役割が求められてくるのでしょうか。次章で詳しく解説していきます。
クラウドで提供される業務システムは、往々にして業務の生産性に関する考え方が先進的であり、しかも随時バージョンアップしていきます。従って「自分の行動にシステムを合わせる」のではなく「システムに自分の行動を合わせる」というのが日常的に求められるのです。
しかし事業部門をはじめとする多くの社内ユーザーは、旧来の業務のやり方に慣れ親しんでいるために、「システムに自分の行動を合わせる」ということに自力で順応するのが容易ではありません。システムを使いこなせないばかりか、新しいテクノロジーに対して抵抗感を覚えてしまうケースもあります。
そこで必要となるのが、自社の業界・事業・業務においてITツールをどうやって活用するかを考え、そのための情報を関係各所へ提供する存在です。これからの情シスには、システムの機能や技術面だけでなく現場の業務プロセスにまで入り込み、具体的なユースケースを提案・サポートすることで、全社的なIT活用を推進する役割が求められています。
また、会社としてDXを推進するうえでは、単にITツールを組織的に活用することだけでなく、同時にチェンジマネジメント（組織変革）を進めていくことが必要です。新しいワークスタイルを実現するためには、職場の文化・風土も変革していかなければなりません。次章ではDXを促進する立場としての情シスの役割について紹介します。
クラウドサービスの台頭でIT部門の仕事がなくなる企業のIT部門の仕事、と聞いて何を思い浮かべるだろうか。自社の…
DXを促進する情シス（情報システム部）の役割と専門家との協働
デジタルトランスフォーメーションにおいて最も上手くいかないことの１つとして、先進的なITツールに対して個人個人の理解度・受容度が追い付いていけず、会社として変化を受け容れられないことが挙げられます。ツールの機能、業務プロセスへの適用法が分からないことで現場が混乱し、これまでの業務のやり方やワークスタイルから脱却できないといったことがそれにあたります。
これを解決するために必要となる活動が会社のカルチャーチェンジ、社員一人一人のマインドチェンジです。単にITツールの活用法をナビゲートするのみならず、業務プロセスや職場の文化・風土というところまで踏み込んで、ユーザー部門に対して新しいワークスタイルの実現に向けた啓蒙活動を展開していったり、全社的な意識改革に向けたコミュニケーションを展開していったりといった役割がDX推進には不可欠なのです。
しかしこの役割は、専任のDX部門が担おうとしても失敗するケースがあるほど難しいものであり、そもそも経営層が事業戦略におけるITの重要性を十分に認識していなければ到底実現できるものではありません。では、情シスがDXを推進する役割を担っていくためにはどのようなアプローチをしたら良いのでしょうか。
それは情シスが持つIT知識や社内システムへの知見を最大限利用し、経営層を巻き込んで企業を変革する旗振りをしていくことです。ただし限られたリソースの中で上層部や会社全体に働きかけるというのは非常に負担が大きく、失敗に終わる可能性も大いにありえます。そこで１つの解決策となるのが、そういった業務改革・組織改革の支援を行うITベンダーと協働することです。高い技術力と豊富な支援実績を持ったITベンダーが上層部への答申からITツールの全社展開まで幅広く支援してくれます。そして、組織風土変革や社内へのコミュケーションは、自社の人事部門や広報部門が実務として実施していきます。現場部門との協働はもちろんですが、変革を企画する部門と協働することで、より全社的なムーブメントをつながります。
まとめ
以上のように、近年情シス（情報システム部）に求められる役割は大きく転換してきています。従来担ってきたITインフラやシステムの構築・保守・運用業務は不要となり、今後はデジタルトランスフォーメーション（DX）実現へ向けた社内ユーザーへの情報提供・啓蒙活動を行っていくことがその使命となっていきます。
もしあなたが情シスのメンバーであり、従来の役割を脱却できずにいるのであれば、業務改革・組織改革支援を行うITベンダーの活用を検討してみてはいかがでしょうか。
まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ
お疲れさん
～VMwareが提案する、DRにも対応するマルチクラウドソリューション～
昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用に効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数のクラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題を解決するVMwareのソリューションを紹介する。
COVID-19流行への対応やDX（デジタルトランスフォーメーション）のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。
多くの企業が、「ビジネスのスピードに対応できるモダンアプリケーション」や、「あらゆるクラウド、データセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスのレジリエンス、セキュリティ、運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境の活用が前提になってきている。
具体的には、Amazon Web Services(AWS)、MicrosoftAzure(Azure)、Google Cloud Platform(GCP)といった複数のパブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決が必要な課題が存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理の簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想と現実のギャップとなっており、これらを意識して進めていく必要がある。
特にマルチクラウド環境を適材適所で使う場合、クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキルが重要になる。
こうしたマルチクラウド環境における課題を解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービスが重要なポイントとなる。例えばVMwareは、複数のパブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理や運用を一元化している。
VMware CloudonAWSは、VMwareとAWSが共同で開発したもので、AWSのベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。
その特長は3つある。1点目は「VMware製品をベースとしたクラウド」であること。VMware製品で仮想化されているため、AWSの世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキルを習得する必要がない。
2点目は「シームレスにクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間やコスト、リスクを大幅に削減することが可能だ。
3点目は「VMwareが管理を行う」こと。ハードウェアやソフトウェアのトラブル対応や運用管理、メンテナンス対応など、すべてサービスの中でVMwareが実施する。3カ月に一回の頻度で新しいリリースを提供しており、ユーザーの要件を反映しながら新たな機能を追加している。
最近のアップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区でデータセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症の流行や地震の発生などによってBCPを見直すユーザーが増え、VMware CloudonAWSをリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョンは活用度が高いといえる。
VMware CloudonAWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存のノウハウや運用管理手法をそのまま踏襲できるという点。VMware製品をベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキルや運用ノウハウなど、既存の資産をそのままクラウド上でも活用でき、新たなスキルの習得や、運用管理手法の大きな変更の必要もない。クラウドとオンプレミス環境をvCenterから一元管理できる。
2点目が、規模に依存しないシンプルなクラウド移行を実現できる点。ワークロードをそのままクラウドへ簡単に移行することが可能だ。VMware CloudonAWSには標準でVMware HCXが含まれ、これはオンプレミスのデータセンターとクラウド間のネットワークをL2延伸する。ネットワークがつながった環境で仮想化環境、VMをそのままマイグレーションできる。アプリケーションやIPアドレスを変更することなく、無停止でワークロードを移行することができる。
3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。
また、リソースを最適化する機能も提供される。ユーザーのリソースの使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWSが提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSのサービスとシームレスに連携することができる。この面も同サービスの大きな強みとなっている。
最近では、VMwareが提供するKubernetesディストリビューションであるVMware TanzuをVMware CloudonAWS上で稼働させることが可能になった。これにより、短時間でコンテナ、Kubernetes環境が導入できるようになる一方で、ハードウェア、ソフトウェアの管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。
VMware CloudonAWSのユースケースには、主に「オンプレミス環境のクラウド移行」、「データセンターの拡張」、「災害対策サイト」、「次世代アプリケーションのプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware CloudonAWSをリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。
VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトのデータをクラウド上のストレージ領域にレプリケーションしておき、万一DRイベントが発生した際に初めてVMware CloudonAWS上にホストを展開し、保護していた仮想化環境をフェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資が不要となる。
VMware Cloud Disaster Recoveryの特長
このタイプはオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングでリカバリサイトに対する課金が開始される。復旧後に仮想化環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトのリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される
また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境のデータをバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。
マルチクラウド環境を可視化するVMware vRealize Cloud
マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしまう可能性がある。クラウドごとに管理ツールや必要とされるスキル、ノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクやコストが増加してしまう。そこで有効な解決策となるのが、クラウド環境をまたがって一貫性のある運用・管理を実現できるVMware vRealize Cloudである。
まず、VMware vRealize Operations Cloudは、VMware CloudonAWSのリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウドの環境にまたがってデータを収集、分析評価を行うことで、例えば常にパワーオフ状態の仮想化環境や、実体がない状態のディスクなどを検知された場合に最適化していくことが可能。これにより、最終的にコストの最適化も図ることができる。
コストや運用を最適化できるVMware vRealize Cloud
また、VMware vRealizeLog Insight Cloudによって、複数のクラウドを横断してログを管理できる。例えば、監視対象のイベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査と対応を行うことができる。セキュリティやコンプライアンスの強化にも有効だ。
さらに、クラウド間のネットワークの可視化は、VMware vRealizeNetwork Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審な通信を洗い出すこともできる。また、アプリケーションの通信も把握できるため、アプリケーションの移行計画にも活用できる。
今後、DXの推進を加速していく上で、必ずしもひとつの環境、ひとつのクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware CloudonAWSそしてVMware vRealize Cloudの活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
