  |
はてなキーワード: 製品とは
まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ
お疲れさん
～VMwareが提案する、DRにも対応するマルチクラウドソリューション～
昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用に効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数のクラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題を解決するVMwareのソリューションを紹介する。
COVID-19流行への対応やDX（デジタルトランスフォーメーション）のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。
多くの企業が、「ビジネスのスピードに対応できるモダンアプリケーション」や、「あらゆるクラウド、データセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスのレジリエンス、セキュリティ、運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境の活用が前提になってきている。
具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数のパブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決が必要な課題が存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理の簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想と現実のギャップとなっており、これらを意識して進めていく必要がある。
特にマルチクラウド環境を適材適所で使う場合、クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキルが重要になる。
こうしたマルチクラウド環境における課題を解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービスが重要なポイントとなる。例えばVMwareは、複数のパブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理や運用を一元化している。
VMware Cloud on AWSは、VMwareとAWSが共同で開発したもので、AWSのベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。
その特長は3つある。1点目は「VMware製品をベースとしたクラウド」であること。VMware製品で仮想化されているため、AWSの世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキルを習得する必要がない。
2点目は「シームレスにクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間やコスト、リスクを大幅に削減することが可能だ。
3点目は「VMwareが管理を行う」こと。ハードウェアやソフトウェアのトラブル対応や運用管理、メンテナンス対応など、すべてサービスの中でVMwareが実施する。3カ月に一回の頻度で新しいリリースを提供しており、ユーザーの要件を反映しながら新たな機能を追加している。
最近のアップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区でデータセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症の流行や地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSをリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョンは活用度が高いといえる。
VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存のノウハウや運用管理手法をそのまま踏襲できるという点。VMware製品をベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキルや運用ノウハウなど、既存の資産をそのままクラウド上でも活用でき、新たなスキルの習得や、運用管理手法の大きな変更の必要もない。クラウドとオンプレミス環境をvCenterから一元管理できる。
2点目が、規模に依存しないシンプルなクラウド移行を実現できる点。ワークロードをそのままクラウドへ簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスのデータセンターとクラウド間のネットワークをL2延伸する。ネットワークがつながった環境で仮想化環境、VMをそのままマイグレーションできる。アプリケーションやIPアドレスを変更することなく、無停止でワークロードを移行することができる。
3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。
また、リソースを最適化する機能も提供される。ユーザーのリソースの使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWSが提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSのサービスとシームレスに連携することができる。この面も同サービスの大きな強みとなっている。
最近では、VMwareが提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間でコンテナ、Kubernetes環境が導入できるようになる一方で、ハードウェア、ソフトウェアの管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。
VMware Cloud on AWSのユースケースには、主に「オンプレミス環境のクラウド移行」、「データセンターの拡張」、「災害対策サイト」、「次世代アプリケーションのプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSをリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。
VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトのデータをクラウド上のストレージ領域にレプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想化環境をフェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資が不要となる。
VMware Cloud Disaster Recoveryの特長
このタイプはオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングでリカバリサイトに対する課金が開始される。復旧後に仮想化環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトのリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される
また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境のデータをバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。
マルチクラウド環境を可視化するVMware vRealize Cloud
マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしまう可能性がある。クラウドごとに管理ツールや必要とされるスキル、ノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクやコストが増加してしまう。そこで有効な解決策となるのが、クラウド環境をまたがって一貫性のある運用・管理を実現できるVMware vRealize Cloudである。
まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSのリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウドの環境にまたがってデータを収集、分析評価を行うことで、例えば常にパワーオフ状態の仮想化環境や、実体がない状態のディスクなどを検知された場合に最適化していくことが可能。これにより、最終的にコストの最適化も図ることができる。
コストや運用を最適化できるVMware vRealize Cloud
また、VMware vRealize Log Insight Cloudによって、複数のクラウドを横断してログを管理できる。例えば、監視対象のイベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査と対応を行うことができる。セキュリティやコンプライアンスの強化にも有効だ。
さらに、クラウド間のネットワークの可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審な通信を洗い出すこともできる。また、アプリケーションの通信も把握できるため、アプリケーションの移行計画にも活用できる。
今後、DXの推進を加速していく上で、必ずしもひとつの環境、ひとつのクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
外貨を獲得すると経済成長するってのは論理としてわかりやすい。
というのが、主な所だろう。
といった方法でしのいだ。
結果、どうなっているかというと、
輸出出来るだけの規模を持っている企業の利益は大きいが、稼いでいるのは外貨であり、稼いだ利益を日本に投資（設備投資・人件費）する理由がなく、更に海外への投資に回っている。
もしくは自前で核心となる技術を育てることができずに振り回される、米国法で貿易関係に不自由が生じる、といったことで上手く回ってない。
観光立国を国が目指したのは、個々人が訪日してお金を使うのは制限されんだろう、と理屈だっただろうが、
日本は成長していない、海外は成長しているというが、成長している国は中国の成長に引っ張られている。
日本が停滞している間に米国は成長したが、その成長は中国の成長に助けられている。
日本は中国と近すぎてギクシャクがあり波に全力で乗れなかった。
日本は内需の割合が多いし、必要に迫られて内需中心になっているが、人口減、高齢化で内需は先細りすると普通は想像する。
理屈上は、人口減でも一人あたりの消費が増えれば経済成長するのだろうが、できるんだったらやっているわけで。
個人資産も米国株に投資だということで電子データ上は増えていくのだろうが、日本じゃ欲しい物・サービスがない、ないから株に投資するかになっていく。
PCはWindowsだしスマホもずっとAndroidなので人生初のApple製品。
多少の不安はあったが購入を決める前からガジェット系YouTuberの動画や各サイトなどを見てiPadの使い心地がどんなものかを調べてもいたから、
PCやAndroidと比較して各種アプリの使い心地の多少の差異については想定の範囲内で強くガッカリとか憤りを覚えることはなかった。
WindowsやAndroidだとネットで画像を保存すると自分で保存フォルダを選んだり、名前を自分でつけて保存ができる。
自分で名前をつけなくても、そのまま保存すれば勝手にネットのオリジナル仕様の名前で保存してくれる。
例えば「ドラえもん.jpg」という画像ならほっとけば「ドラえもん」という名前で保存されるし、
エロ画像じゃなくてもエロ画像フォルダに保存できるし、画像なのに書類フォルダにも動画フォルダにも保存できる。
しかし、iPad(iOS)だと画像ファイルを保存しようとすると、勝手にファイル名がつけられる上、全て「写真」という括りで保存される。
少なくとも保存する際には保存の名前もフォルダや形式なども操作できない。ただ「写真に追加」を選ぶことしかできない。
だから「ドラえもん.jpg」を写真に追加すると「IMG0001」とかそんな名前にされてしまう。
「のび太.jpg」も「プリキュア.jpg」も全部「IMG0002」「IMG0003」みたいな名前に勝手になってしまう。
一応写真の括りから外してファイルに保存すれば名前やフォルダを変えることはできる。
しかし結局一度写真に追加した後でないとできないし、もともとネットにあった形の名前にするには手間がかかってしまう。
これでは過去に保存した画像と同じものを忘れてて保存しても勝手に連番になるから重複が分からない。
また、ネットの消えるかもしれない画像を保存しといて後でPCに移そうと思っても、
ファイル名がオリジナルの名前じゃないからPCでのファイル管理が面倒臭くなる。
後からファイル名を見ればpixivで保存した画像かネットのどこで拾った画像かを見分けられたり、ファイル名でキャラ名などが分かったりする場合があるが、
iOSだと全て「IMG〜」という名前になるのでファイル名からは全く推測できない。
これこそ、iOS購入を検討するiOS未経験者に最も注意をさせておくべき仕様だと思うが、もう常識だからなのかわからないが言及してる人を見なかった。
iPadは画像や動画についてはPCで保存した画像や動画をiPadに移して見るためのデバイスと考えた方がいいと思った。
自ら撮影や編集した写真や動画ならともかく、iPadで保存した既存の画像や動画をPCに移すという使い方には向かない。
他にもファイル管理の仕様が面倒臭い仕様で基本的にアプリの下にそのアプリ用のファイルを保存する仕様も面倒臭い。
そこはまあ割り切ってiPadではそういうものと思っておけば我慢できなくはないし、
あまり整理整頓とか区分けとか好きじゃない人には勝手にやってくれるようなもんだから便利とも言えるのだろうが。
上述の独特のファイル管理の仕様のせいもあるのか、AndroidならUSBケーブルでPCと繋げば自由にファイルを移動できるが、
iOSだとケーブルで接続してもアプリを用いないとファイルを移動できない。これが令和の時代のガジェットの仕様かとビビった。
半導体不足というと、CPUやGPUを想像するか、iPhoneなどのスマホを想像すると思うので、
それほど種類がないと思われがちだが、今、半導体がなくて作れないといってる類のものは種類が多い。
少量多品種で成り立っていて、その中で数種類だけバカ売れした製品に使われている物だけは桁で数が違う。
工場というのは同じものを大量に作るのは向いているが、多品種を作るのには向いていない。
似ているけど違う物を作っても使われない。
また工場は稼働率を高く維持しないと利益が出ないというのがあり、余裕が殆どない。
そうすると需要が乱高下すると、工場のマージンがないのでキャパオーバーする。
そして数が売れないような種類は後回しになる。
犯罪者「写真とられて実害あったんか？おーん？魂でも抜かれるんかヘラヘラ」
→ 深センに電話「あ、工場長？例の写真からモデリングして製品化してくれ」
これが中国人だ
まだSONYやマイクロソフトのほうが後方互換持たせてくれてるからマシだろうか？
同じレトロゲームやるためにハード変わるごとに課金とかアホみたい
任天堂は2月16日、ニンテンドー3DSシリーズとWii U向けの「ニンテンドーeショップ」でのダウンロードコンテンツの販売を2023年3月下旬で終了すると発表した。ダウンロード版のゲームソフトや追加コンテンツ、利用券、ゲーム内アイテムの購入ができなくなる。
更新データのダウンロードや購入済みのソフト、追加コンテンツの再ダウンロードは引き続き利用可能。再ダウンロードも将来的に終了する予定としており、具体的な日程が決まり次第案内するという。ニンテンドーeショップへの残高の追加は22年8月30日まで可能。
ニンテンドー3DSシリーズは2011年に発売した携帯ゲーム機。Wii Uは2012年に発売した家庭用ゲーム機で、Nintendo Switchの1つ前の世代に当たる。23年3月以降、任天堂製品でダウンロードコンテンツを購入できる家庭用ゲーム機はSwitchシリーズに一本化されることになりそうだ。
スマートスピーカが家に無くて、もちろんスマートスピーカーと繋げるIoT製品・IoT家電（家電の遠隔操作程度でも）無くて、
さらにSuicaやタッチレス決済でRFID使ってないとかもう単なる老人だろ。
上記は例だけど、記載したもの全部そこそこ進展してるものばかりだし、キャズム越えた物も多い。
ただ単に、老化して時代に追いつけなくなっただけだよ。
転売されたときの利益が製造会社にも行く、というのはいい仕組みかもしれない。
それが実現した場合、長寿命の製品を作るのに長けている日本企業は優位になる可能性がある。
短寿命製品を発売し、故障による買い替えで購入サイクルを上げる、というやり方よりも、長寿命の製品を作ることで利益を得られる仕組みの方が日本企業はやりやすいだろう。
SDGs的にもグットだ。
ワイ、技術営業。増田の気持ちよく分かるし、増田の奥さんの気持ちもよく分かる。
技術目線から言えば増田の言うとおり。コードネームなんて、製品の何がしかに因んだちょっとシャレたものなら何だっていい。所詮はコードネーム。
製品にかける私の思い？ そんなもん「いっぱい売れるといいな」だよ。それが社の総意であって、お前個人の思いなんて知らん。
一方で、人に好かれて受注する、みたいな奥さんの話も身に染みてるんよね。
自分で言うのもなんだけど、誠意あるような演技得意なんやわ。演技っつーと、人をだまくらかして、腹の底では舌出してるみたいに思われるかもしれんけど、
演技っつーかなんて言うか、振る舞い？ 神妙な顔して、か細い声出して「はい… はい… ええ、それはもう… おっしゃる通りで… ごもっとです…」まずはこれ。
炎上仕切り直しの最初は、徹底的に低姿勢からの傾聴。相手の溜飲が下がるまで傾聴。そこからの寄り添い。
顧客の要件を改めて引き直し、最速かつ希望の要件に近い完成案のご提示。もちろん、時間・予算と要件が折り合わない時もある。
そう言うときは「そこまではできないが、ここまでならできる」「それはできないが、代わりにこう言うやり方がある」「今回は間に合わないが次のフェーズで」とか、とにかく落とし所を探しまくる。
そんなん当たり前やんって思われるかもしれないけど、それできない奴が多いから、炎上もまた無くならない。
こういう愚直な行動を続けていくと、炎上して怒り狂ってた顧客の担当者や担当役員が、徐々に柔和になっていって、最後は目がハートマークになる（もちろん、ワイにやで！）
ここまで自分で言うと流石に嫌らしいが、こう言うことを繰り返すうちに、人心を掴むってどう言うことか、なんとなくわかってきたわ。
最初が炎上（マイナス）からのスタートなんで、ギャップがでかい、ってのもあるかもしれん…
でも、結局はその人の「姿勢」なんよ。その姿勢から垣間見える本気度とか、そういうのな。
まあ、toBとtoCでも違うやろし、モノ売るんかソリューション売るんかでも違うし。人の心の掴み方もそれぞれあると思う。
でも、本当はそいつの姿勢が顧客の目にどう映ってるかが大事で、そういうところを、おざなりにやってる奴ほど、信用得られずに、受注や売上もぱっとせえへんのやろ。
増田の話には顧客との関係性は出てこなかったけど、増田がマーケの人らに感じたのも同じで、結局マーケの人らの姿勢から本気度とか真摯さみたいなんが感じられへんかったんとちゃうかな。
工業デザインっていってるし、経験価値マーケミーティングとか言ってるから、
工業デザイナーの製品イメージがあって、筐体サイズや電力の制約があって、納期やコスト、開発リソースから実現可能性を考えてという具合に、製品の要素を実装可能な状態に落とし込むために要件を絞り込んでいく的な感じ。
あるメーカーで技術職をしてるオッサンなんだけどけど聞いてくれ。
先日会社のマーケティング主導の製品企画のキックオフミーティングに呼ばれたんだけど、非エンジニアの文化にはじめて接していろいろ面食らっている。
なんていうか、普段馴染みのあるエンジニアだけで動いている会議って論点が割と明確なのよ。工業デザイナーの製品イメージがあって、筐体サイズや電力の制約があって、納期やコスト、開発リソースから実現可能性を考えてという具合に、製品の要素を実装可能な状態に落とし込むために要件を絞り込んでいく的な感じ。
一方、この前初めて参加したマーケ主体のミーティングはソフトバンクの決算で孫正義がやってるような感じのポエミーなプレゼン資料がポンポン飛んできて頭がくらくらした。「プロジェクトに対する私の思い」だとか、「製品のコードネームを決めよう！(提案者は製品コンセプトが抽象画なのでピカソ推し)」とかエンジニア目線で見るとマジでどうでもいい話ばかりで会議に出てる時間が無駄に思えてとてもストレスフルだった。
で、そんな経験がすごく苦痛だったという愚痴を昔営業の仕事をしていた嫁に話したところ、自分にとってはへーと思う答えが返ってきた。
「マーケティングや営業といったコミュ力を要求される仕事って興味の対象が人間なのよ。だから製品の良し悪しより、思いやイメージといった感情に働きかける要素を重視しているわけ。私だって、商品はクソなのに取引先のおっさんに人間性を好かれて商談まとめた経験あるし、そんな環境に何年もいる人たちが集まった会議があなた達エンジニアの世界と文化が違うのは普通じゃない？」
そうなのかとハッとした。なんていうかエンジニアはいかに良いモノを作るか、いかに技術的に面白いことができるかに神経注ぐ。だけど非エンジニアはいかに人を動かすかに注力してるのかと。
そんな目線で会議に参加したらいろいろ発見があった。非エンジニアの人はオンライン会議でも顔出ししたがるけど、理由が表情が分からないと感情の変化が読めなくて、彼らの仕事スタイルからするとやりづらいということなんだなと思ったし、面識ない人の発言でも声の感情のこもり具合だけでエンジニアか非エンジニアか判断できるようになった。
だけどだ、違和感の理由がわかったところでこの手の会議が不快なのは変わらないわけで、マーケや営業のコミュ力重視コミュニティとエンジニアの見てる世界の差は簡単には埋まらないよなと思ってしまった。なにせ会議が退屈すぎるのでサボって増田に愚痴を書いているくらいだし。溝は深い。
