  |
はてなキーワード: ユースケースとは
うちの会社もよく似たかんじの組織構造ぽいんだけど、デザイン部署側は年次が浅い要員には増田さんのいうような案件で経験積ませて次第に上流からデザイナ絡ませる（程度に予算のある）案件にシフトしてくみたいなキャリアパスになってるよ。増田さんとこもそんなかんじじゃないの？
ちなみに自分は設計サイドの人間なんだけど、予算ない案件はまさにこんなかんじでスコープ狭い仕事をデザイン部署へ投げてる。（css丸投げ請けてもらえるのほんと助かってます、ありがとう）
ただ予算ある案件やってるときだと、要件定義の段階からデザイナに入ってもらってユースケースがどうだって話から画面の設計あたりまで顧客含めてがっつりやってもらってるからね！
主にDXとかノーコード(ローコード)周りについてコンサル目線で書いておく
表でこんなことを書こうものなら会社クビになる可能性あるのでここに書いておく
（なんでこんな世の中になっちまったんだよｗ）
DXって別にIT化するだけの意味じゃないんだけど、それすらできてないからIT化って意味で以下注意点かいておく
というより、DXやりたいって言ってる人のほとんどがDXができる状態じゃない
床が見えないほど散らかってる部屋でルンバが使えないように、前提となる条件をクリアできてない
それがもう絶望的にできてない
体感としては8割以上できてない
多分自分たちのやってる仕事が良くわからないし、行き詰ってるからDXという魔法の言葉に救いを求めてるんじゃないかな
まず自分たちがやってる仕事に対して、「どんな仕事をしていますか？」「その仕事をやる理由は何ですか？」という質問に答えられるようにする
人が増えて、長くやってる会社は目的がわからないルール、意味のない仕事が増えていく
これを整理できないと何も前に進められないです
収入印紙を貼る理由なんて良くわからない人がばかりなのにルールだからと貼っている
程度問題ではあるけれども、なんでこの仕事やる必要あるんだ？この会議に出る意味はなんだ？
先にそっちなんとかしてください
次に問題になるのは誰がやるかってこと
「IT部門の若手にやってもらう!」とか気軽に言う人が多いんだけど
これできる人って
ウルトラスーパー超絶優秀な人です
いやマジで
1000人にひとり見つかれば良い方
この業界に20年以上いるけどこれちゃんと出来る人、今まで一人しか会ったことない(その人はさっさと起業してしまいました)
ある程度大きな会社だと一人じゃできないから、仕様策定、運用、試験だったりを分割して誰かに任せる必要があるんだけど
責任感を持ってやってくれて、業務をよく理解している人を選定して説得する必要があります
これすごい難しいです
対人スキルが全方位カンストしてるような人じゃないと務まらないです
IT界隈だとプログラミング能力に秀でた人が優秀な人とイメージされやすいですが、この手の仕事ができる人も同じくらい評価されても良いと思うんすけどね
間接部門だからと出世コースに乗れない閑職扱いになってませんか？
もしそういう認識ならはっきり言って無理です
現場で活躍できなくてもITで活躍出来る可能性もゼロではないかと思いますが、
現場でNG出された方は要領だったり対人スキルに難がある場合が多く、その人がITツールを導入しても混乱を生んで余計な費用がかかるだけです
業務整理が出来て、IT化に着手する場合（まあ実際は役員のメンツとかそういう理由で、業務把握もままならないまま突き進むんでしょうけど）
「やらなくても良い作業を止める」、「SaaSで出来ないか検討する」、「ノーコード開発で頑張る」の順で検討してください
当たり前ですが、やらなくても良い仕事を止めるのが開発もなく、運用費もかからない即効性があって一番良いです
無駄な会議や書類、これらを探して削るところから始めてください
どこもやってる勤怠管理や会計処理等は既存のサービスで充足するはずです
SaaSで実現できなくて、ノーコードで開発する必要がある場合(ほとんどないと思いますが)
ノーコード開発をやってみるとわかるんですが、結構細かいところは出来ない場合が多く100%カバーするようなシステムを作る場合は
すげー大変になることがあります
結局の所ノーコードとは言っても形を変えたプログラミングなので複雑にすればバグも多く発生します
テストしにくい分コードを書くよりも悪くなるケースもあると思います
なので70～80%くらいカバーできれば良い
エッジケースだったり発生頻度の低いオペレーションはバッサリ切る
そんな感じでシンプルになるように努めてください
ノーコードの想定するユースケースを無理やり捻じ曲げてプラグインだらけの独自システムは地獄です
(そうは言っても、こだわりが強いのか、冷蔵庫をエアコンとしても使えるようにしたいみたいな人が多いんだよなぁ・・・・)
ここまで言うと、ノーコードって微妙なの？流行らない？って思うかもしれないですけどノーコードは流行ります
プログラミング言語もセキュリティも覚えることが多すぎて、みんなノリでやってます
セキュリティ対策なんて意味わからんチェックシートを大して理解してない人がYES/NOつけてるだけで実装はボロボロ
たくさんのライブラリは毎日のようにアップデートされ、膨大な工数をかけてアップデートしてます
誰も触れなくなります
というわけでフルスクラッチ開発で内製化とか現実的じゃなさすぎます(金が有り余ってるならやってもいいですが)
ノーコードでも属人化して、ブラックボックス化するのは一緒ですが
セキュリティアップデートとか、セキュリティ対策は幾分楽になるので、まだマシです
ちなみに今SIerにシステム開発頼むのは悪手なので止めときましょう
プログラマーの腕に激しく依存していて、プロダクトの品質が同じ会社でも全然違うみたいな状況はいずれ改善されていくと思います
カンナとノコギリを使って家建てる大工が少なくなって、プレカットの建材を運んで組み立てる家ばかりになったように
(つーか実際もう、ID管理とかメール送信は外部サービス使うのが主流になってきていて、どんどんコード書かない方向にシフトしてる気はしてる)
前述の内容と少し被りますけど、半分くらい作ったらさっさとユーザーに使ってもらったほうが良いです
負荷テストとか、UIとか拘るのは良いんですけど、方針レベルで間違ってた場合は全部やりなおしになるので、
早い段階で使ってもらうようにしてください
多少バグがあっても良いので早めにイメージを擦り合わせたほうが結果的に早く終わります
バグってるものをユーザーに使わせたら怒られるとかいう人いるんですけど、
使う人と作る人が気兼ねなく話せるような関係じゃないと開発はうまく行かないので撤退しましょう
席を隣にして談笑できるくらいには仲良くしてください
いきなりbubble, outsystemsみたいなガチなやつから入らないほうが良いです
kintoneとかairtableみたいなやつから使ってみるのをオススメします
あと選ぶ際に、営業にいろいろ聞く前にまず自分で使ってみること
最初から営業に聞いちゃうと、「頑張ればできます」みたいな回答しか返ってこない
実際に使ってからセミナー行くとか、営業と話して聞いてみるの方が良いと思います
システム作ったあとに、効果があったのかきちんと検証してください
大学受験して合格発表を確認しないようなことあるのか？と思われるかもしれないですが、
ということなのか単にめんどくさいのか分からないですが、ちゃんとやりましょう
いい加減な検証もやめてください
コンコルド効果で捨てられなくなって負の存在として生き続けます
そうならないように作る前から、効果検証の方法と撤退ラインを決めておくと良いと思います
保守なんて誰もできないです
10年もすれば、担当者も業務も変わってドキュメントは不整合だらけ
20年に一度作り直す式年遷宮は技術継承の意味合いが強いと聞いたことがありますが、それと同じでシステムを10年以内に作り直す気持ちでいた方が良いです
最低限のドキュメント更新とかアップデートは必要ですが、維持に多大な工数がかかるとか、修正に時間がかかるようになったら作り直してください
色々書きましたけど、業務把握が一番大変でそれができれば割となんとかなります
自分たちの仕事を管理できないから、システムを作って解決しようとするからおかしいんです
それって業務整理とシステム開発という2つの大仕事を並行してやることになるので、そりゃ混乱もします
あと業務整理を自分たちで出来ないからコンサルにお願いしてやってもらうっていう事言う人いますけど止めたほうが良いです
コンサルからしてみれば他人事ですし、あなたの会社について世界で一番詳しいのはその会社に属している人です
その人たちがお手上げだと、外部の人間だって十中八九うまくできないです
仕様さえ明確に作ることが出来るなら、ツールの違いやら、プラットフォームの違いなんかは些細なことなんですよ
まあそれはそれで、大変ですけど仕様さえ決まってるなら何とかなります
というわけで各位頑張っていただければ
世の中の多くは洗濯機や洗剤に関することはいっても、意外と乾燥機とかは発言しない
数少ない乾燥機関係だと、乾太くんvs洗濯乾燥機、のようなバトルモノしかない
それらは異能力対決に終止しており、なんやかんやで過去回想を挟んで主人公側が勝利している
話戻すけど、洗濯って乾燥や取り込みっていう工程のほうが難しいんだよ
乱暴な意見だけど、洗濯機や洗剤は割と最新のものを導入すればなんとかなる
人数に合わせた容量を買っておけば今の洗濯機はほとんど問題なし
そこにCMバンバンだしている洗剤を打ち込めばほとんどの汚れは落ちる
一番ポピュラーなのは天日干しだけど、例えば1階に洗濯機があって2階にバルコニーがある典型的な家だと、家事動線が非常に辛いことになる。
また花粉や梅雨の時期はコインランドリーなどを頼らざるをえない。
もし子供がいるならば洗い物の頻度は増えるだろうから干すだけで結構な重労働だ。
洗濯の部分だけよくなっても天日のままの家庭はあまり恩恵を受けない。
最強枠の洗濯乾燥機は、とりあえず実用的なのが10万台からなのがネック。コスパがいいとは思うけど、割りと長持ちする洗濯機を買い替えるには躊躇するよね。
なら天日干しや室内干しでいいやって人は多い。でも家事動線を最小限に抑えられるという点は捨てがたい。
結構おすすめのは衣類乾燥機だけど、これはガス式なら賃貸はまず無理だし、電気式でも設置場所がないケースがある。殆どの場合で浴室に設置するんだけど、洗濯パンが壁にぴったりとくっついてると乾燥機を設置しづらい。
こうやって考えると乾燥の工程はユースケースによってマチマチだ。
中には衣類乾燥除湿機でいいという人もいるけど、これはこれで合わない人も多い。
洗濯から乾燥までを1工程で済ませたいという願いは洗濯乾燥機が最適で万人向けだけどね。
自分の場合、引越し先の賃貸に浴室乾燥機がなかったので電気式の衣類乾燥機を導入した。もし浴室乾燥機があればサーキュレーターと併用して結構ちゃんと乾かせられるんだがね。ただ、今後は衣類乾燥機の設置を含めて部屋や家を選ばないといけなくなった。
注文住宅を作った人の意見の多くに、キッチンと洗濯機周辺の家事動線の問題があげられていた。やはり家の中でも特に動線にシビアになる部分だからなんだけど、一人暮らしだったり洗濯に関心がないと気づかない人も多いと思う。
乾かすのは天日干しという概念で育っているならたぶんそれが一番楽だとは思う。なぜなら家事動線が一番多くて天候などに左右される代わりに、最後の砦になりうるから。下手に乾燥の工程を最適化してしまうと、天日干しに戻れなくなる。
洗濯って割りと難しい。
まずは、日立のサーバーでの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 from Hitachi」
木村氏は、日立のハイブリッドクラウド戦略としてEverFlex from Hitachi (以下、EverFlex)ソリューションを説明した。EverFlexは2021年10月にクラウドとのデータ連携ソリューションとして始まり、2022年2月にハイブリッドクラウドのソリューションとして強化された。
木村： お客様がオンプレミスとパブリッククラウドを使うときに、最適なシステム設計にして、コストも最適化していきます。ハイブリッドクラウドの導入には事前にアセスメントやコンサルティングを行うことが大切です。なぜなら、パブリッククラウドを導入することで負担が減るかと思われがちなのですが、ハイブリッド化されることで負担が増えることがあるからです。
EverFlexの特徴の中でも特に「クラウドライクなサービス提供」について木村氏は紹介した。
木村： ハイブリッドクラウドになると保守や運用が煩雑になります。パブリッククラウドとオンプレミスの両方を管理しなくてはならないため、システム管理において両方のノウハウが必要になります。このため保守・運用フェーズにおいて簡単化されずコスト最適化が課題となってきます。それを避けるために、共通化するニーズに応えるようにいろいろと工夫しています。
ハイブリッドクラウドソリューションEverFlex from Hitachi
まず、問い合わせをワンストップ化したり、運用管理を1つのツールで一元化したりすることで、顧客の負担を軽減する。
プラットフォームにおいては、オンプレミスからクラウド接続を可能にしてシームレスにお互いやりとりできるOSが各社ある。Windows Server 2022はまさにそれを特徴としており、同じくAzure Stack HCIも選択肢に入る。
さらに、支払い／利用形態についても、オンプレミスでも売り切りだけでなくフィー型も採用する。こうしたEverFlexの中でWindows Server 2022のユースケースを木村氏は2つ挙げた。
1つめは、運用管理の簡単化の部分で、Azure Portalからオンプレミスを管理できる機能の強化だ。
木村： オンプレミスにエージェントを入れておけば、管理者がAzure Portalだけをさわって、オンプレミスのリソースやイベントの管理も全て一元化できます。これに期待しています。
もう1つはセキュリティの強化だ。
木村： ハイブリッド化が進むと、両方の基盤をネットワークで接続することになります。従来には存在していなかった接続となるため、その部分でセキュリティの強化も進めなければなりません。そこでWindows Server 2022では、Secured-core ServerによってOSそのもののセキュリティレベルが上がっています。TPMと連動する機能によってハードからOSのレイヤーを守り、マルチレイヤーでセキュリティを強化しています。
そのほかにもクラウドライクの取り組みとして2つを木村氏は紹介した。
1つめは「サーバ予備リソース提供サービス」。サーバーを余分に設置し、支払いは電源を入れて使った月だけ発生するというサービスだ。
木村： 迅速でタイムリーにリソースを増強したいときに、クラウドなら自由に構成を変えられます。それをオンプレミスでもできるようにします。クラウドではインスタンス単位となり、ハードウェアの構成はメニューの中から選択することになりますが、オンプレミスでは構成を自由に組む事ができます。まずHCIソリューションから開始しましたが、2022年4月からはそれ以外にも拡大する予定です。
もう1つが「ハードウェア安定稼働支援サービス」。オンプレミス環境のサーバー運用管理を省力化するものだ。
木村： 旧来の保守では、ファームウェアのバージョンアップがあると、技術的にどういう影響があるかを確認して、その都度適用するかどうかを判断する必要がありました。それを提供元が判断するのがこのサービスです。お客様の機器を弊社で管理して、ファームウェアの推奨バージョンの選定や、更新作業などを一括でやります。
サブスクリプションに力を入れる
日立のこれからの注力分野について木村氏は、サブスクリプションに力を入れていくと語った。
木村： 全社的な方針で、サブスクリプションに力を入れていきます。クラウド化で初期投資をおさえるニーズと同時に、オンプレミスも求められています。そうしたお客様のニーズにアラインしていきます。
サブスクリプションやクラウドライクなサービスで管理を簡単にして顧客企業がコストを抑えることで、究極的な目的はその先のDXだと木村氏は語る。
木村： 既存のプラットフォームのコストを最適化させ、浮かせた費用を新たな投資先として、AIやEdgeを活用する新たなデジタルソリューションの領域に向けていくことを支援していきたいと考えています。
そのために木村氏は、よりハイブリッドで使いやすいようなライセンス体系をマイクロソフトに期待している。
木村： 今後ハイブリッド化が進むと、繁忙期にリソースを拡張するといったこともあります。そのときにライセンスが、オンプレミスはオンプレミスで買って、AzureはAzureで課金してと、ハイブリッドで使いづらい体系になっています。将来的にライセンス体系を統一するなど、両方の基盤で使えるような体系になることを期待しています。
また、Azure Portalからオンプレミスを管理できる機能についても、さらなる強化を木村氏は期待する。
木村： Azure Portalからは管理できる範囲に限りがあります。OSから上のリソースやイベントは監視できるのですが、ハードウェアの死活監視や電源管理などは対応していないため、JP1やその他のツールなど、複数のツールを使いこなす必要があります。それらの管理ツールが乱立してしまうと、また管理の手間が増えてしまう。こういったことをオンプレのツールか、Portal側で統一することも期待したいところです。
https://www.sofia-inc.com/blog/7233.html
情シス（情報システム部）はもういらない？これからの情シスに求められる、あるべき姿とは？
皆さんは情シス（情報システム部）が果たす役割・機能を何だと考えますか？ 全社のIT戦略策定・システム企画、社内インフラやアプリの保守・運用、ユーザーサポートやトラブル対応といったことを思い浮かべる方が多いのではないでしょうか。
しかし昨今、情シスにそのような役割が求められていない、もしくは情シスの業務自体がなくなりつつあることをご存知でしょうか？
今回の記事では、これからの時代の情シスに求められる役割、あるべき姿について説明します。
近年Microsoft AzureやAmazon Web 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)、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の活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
広義ではそうでも、FF14はあくまでもゲームでメタバースというカテゴリに入るプロダクトではないじゃん（まぁこれからメタバースです！とカテゴリ変えてくるかもしれないけど）
でもFacebookとかが作ろうとしてるメタバースはあくまでもプラットフォーム、空間で、マジで空間作ることしか考えてない
結果メタバース的になったゲームではなく、Facebookが作ろうとしているメタバースというプラットフォームは何をコンテンツにするつもりなのか全くわからんのよね
結果メタバースっぽくなったゲームはあくまでもゲームだし、ゲームという制約があり自由度が低い反面コンテンツが明確で、一方Facebookのメタバースは自由度は高いかもしれないけどユースケースが全く見えない
VRゴーグルに加え、メタセックスに向け新規開発された電動TE◯GAと触覚フィードバックグローブを用いた現実を超えたセックス体験！
第一弾
三上◯亜、河◯彩花
技術紹介
「実際の女優の"圧"を再現するために、アクチュエーターが128個必要でした」
TE◯GAのテクノロジーをフルに活かした電動TE◯GAは、各"ユースケース"毎に実測した膣圧をフルシミュレーションする緻密な制御を実現
もちろん、生で大丈夫だよ？
「ブラインドテストの結果、7割の被験者がホンモノのおっぱいと間違えました」
森◯原人「乳首の再現度がヤバイ！実は、僕も間違えちゃいました（笑）」
着けている感覚がない…っっ！
0.01mmの衝撃に君は耐えられるか？
必要なデバイス全て含まれたスターターキット、150000円〜！
皆さん買いますか？
これから、「GoogleやMicrosoftですら出社！」という文脈でテレワークdisが増えてくるんだろうけど、あれ逆にGoogleやMicrosoftに勤めるトップ人材だからこそリアルタイムのコミュニケーションが必要なんだろうね。
社会に変化を及ぼすような新規サービスのアイディアを出して、あっという間にプロトタイプを作って、あらゆるユースケースを議論して、サクッとリリース計画を策定して、とりあえずベータ版を出してみる。
それができるレベルの人たちには、今のテレワーク環境は「遅すぎる」んでしょう。逆に、そうでないレベルの我々が出社したって、別に生産性は上がらないと思うよ。チャットだって対面だって、どうせ上司はいないし、いても即座に的確な意思決定はしてくれないし、決まったことが実行されるのは半年後、とかなんだし。営業活動だって、その場で決まる案件なんてなくて、どうせ提案して、客がいちど持ち帰って検討して、あとで電話なりメールで可否を告げてくるわけじゃん。
自分たちの仕事に、本当に対面の情報量、スピードが必要なのか、というのを客観的に評価したうえで、テレワークか出社か決めて欲しいよね。
windowsユーザがwindowsPCを推す理由はなんとなくわかる。いろんなメーカーが出しているし、カスタマイズしやすいんだろう？
Macのよさは、windowsPCのようにメーカーごとにカスタマイズされていない、どのMacを買っても同じmacOSが入っている、という純粋さがある。また、iPhoneなどの関連プロダクトとの親和性も高い。プロダクトの価格も高いけど、価値に見合ったものだと僕は納得しているし、なによりも大変満足している。
PCというユースケースにどれだけのコストをかけれるのか、そして、何に価値を感じているかは人それぞれなので、優越なんかつけられないよ。エロゲーをやってPCゲームをやる人はwindowsを買うべき。僕はエロゲーやPCゲームはやらない。僕は、これからも進化していくMacを体験していきたいし、すごく期待しているからこれからもMacを買う。
「5万で買えるwindowsで十分なのに、Macを買うのはもったいない。」論があるけど、うまい棒を1000円分食べて満腹になるよりも、3000円の寿司を食べたいでしょ？僕は3000円の寿司を払うだけの経済力があるし、3000円分の価値を受け取りたい。それだけなんだ。
以上。
日本メーカーからはAIでその人に合った削り加減にする機種が出てたけど、いまいちユースケースが分からなかった。中国(たぶん)のメーカーから出てたのは面白かった。芯の入ってない木の棒を突っ込むと中心をくり抜いて芯をセットしてくれる。木の棒は専用のものを使い、一本80円するとのこと。コスパは悪いが夢がある。
いっぱい観たらお腹が空いてきたので、休憩コーナーでお弁当を食べた。休憩コーナーの壁には人工呼吸器のプラグがズラッと大量に設置されていた。有事の際はここで患者を受け入れるらしい。
そうこうしてるうちに辺りは暗くなっていて(ここの人達はなぜか頑なに電灯を使わない)、鉛筆削り機の説明員の顔が心なしか焦りだした。館内放送で「エレベーターエスカレーターはこの時間止まっているので階段を使ってください」とアナウンスがあり、仕方がないので階段を使おうとしたのだけど、運悪くこの階には階段がなかった。
マストドン。あとは、Dabel
Clubhouse が来るかも知れないし、来ないかも知れない
▼ Clubhouseとは？
Clubhouseは音声版Twitterと言われている音声SNS。さまざま人の「部屋」に入り、話を聞いたり、手を挙げて参加することが可能だ。部屋に入っていれば友達を呼べるが、その友達が承認しないと実際には入ってこない。オフラインのClubhouseっぽい感覚に近いサービスになっている。
テーマは参加している登壇者が決めるので、かなり自由なユースケースが生まれるのと、今現在はテック業界などの著名人が集まっている。例えば、D2CエキスパートのWeb Smith（ウェブ・スミス）氏がShopifyの話をしていたときに、ShopifyのCEOが自ら参加していた。
[TechCrunch Japan] 米国スタートアップ界で話題の次世代SNS「Clubhouse」になぜ100億円以上も時価総額がつくのか？
https://jp.techcrunch.com/2020/05/17/clubhouse/
本当に迷惑なんだ。
センスがない奴の何が問題かというと、技術がないとか、ベストプラクティスを知らないということではなく、根本的に「頭がおかしい」ことなんだ。
センスのない奴は、普通の人間が到底思い付かないことを平然と行う。所詮、本に書いてあるようなアンチパターンは、「経験のない人は典型的にこういうことをしがち」という例であるが、センスのない奴はそういう典型的なアンチパターンにすら当てはまらないほど意味不明なことをする。だから、「センスのない奴は典型的にこういうことをする」という具体例を挙げることが非常に難しいし、「ここがダメだから直せ」という指摘もできない。
普通の人なら、何も考えず以下のような実装をするだろう。フィールドの定義とデータが分かれているのは、ユースケースによってフィールドが可変だからだ。
[
{fieldName: "id", title: "id", type: "number"},
{fieldName: "name", title: "商品名", type: "text"},
{fieldName: "price", title: "値段", type: "number"}
]
[
{id: 1, name: "商品A", price: 100},
{id: 2, name: "商品B", price: 200},
{id: 3, name: "商品C", price: 300}
]
ところが、センスのない奴はたとえば以下みたいな意味不明な実装をナチュラルに行う。
[
{id: "0-0", val: "商品名", type: "text"},{id: "0-1", val: "値段", type: "text"},
{id: "1-0", val: "商品A", type: "text"},{id: "1-1", val: "100", type: "number"},
{id: "2-0", val: "商品B", type: "text"},{id: "2-1", val: "200", type: "number"},
{id: "3-0", val: "商品C", type: "text"},{id: "3-1", val: "300", type: "number"}
]
一応言っておくと、これは実例の一部を分かりやすいように切り取っただけであり、本物はもっとひどい。
センスのない奴っていうのは、スキル云々の問題ではなく、そもそも認識している世界が常人と異なるから、矯正は無理だし、チームにいると非常に迷惑なんだ。だから、プログラマにはならないでくれ。