  |
はてなキーワード: 管理ツールとは
というのも、最近入社した会社はさ、いまテレワーク中心だけど「徐々に出社頻度を上げていこう」ってなっててさ。
「月2,3回程度の出社頻度」て話で入社したけど上司からは週2出社を命じられたのよ。
まあそれは全然良い。仕方ない。個人的に週3もテレワークできるなら十分だ。
ところがだ。同じチームの若手の子は以前と変わらず月2出社にしてるのよ。
上司は注意もしない。
この時点で「ハア？」なんだけど本題はそこじゃない。
SKYSEA Client Viewって皆さんご存知でしょ？藤原竜也さんのCMでお馴染みのIT資産管理ツール。
あれってさ、社内PCの一覧を出せるだけじゃなく、各PCでいまアクティブになってるウインドウがリアルタイムでわかるんだ。
とか
みたいに、前面にあるウィンドウのタイトルとソフト名が表示されるのね。
普通に仕事してたらパッパッパッとタイトルが切り替わるもんだけど、若手の子はぜーんぜん動きがない。
ずーーーっとOutlookの受信トレイを表示してたり、ずーーーっと社内ポータルを開いてたり。
デュアルディスプレイで片方のモニタにSKYSEA開きっぱにして仕事しながらチラチラ観察してたんだけど、
そいつ今日の午前中はずーーーっと勤怠管理システムの打刻画面だったよ。
きっと出勤の打刻だけして寝てたんだね。
適切な量の仕事を振れてないマネジメント側の問題でもあるとは思うんだけど、テレワークって人を駄目にするのかしら？
もしかしてテレワークしてる人たちってこんなサボってるやつばかりだったりする？
て一瞬思ったけどそいつと話してみたらやる気も主体性も能力も微塵も感じないクソみたいな人間だったのでそんなこたないな。
「今のこの部署は業務が非効率すぎるからDXとか言う前にデジタル化して効率化したい」
とのことだった
Windowsのファイル共有サーバを使って業務上のやりとりが行われてて
それ自体は別にいいんだけど明文化されたルールが無いしアクセス権とかも適当なのでめちゃくちゃになってた
定期的にフォルダが移動されるのでメール検索してもファイルが見つからないっていうことがかなり多い
まずはアクセス権の設定とルール決めをやろうとしたんだけど各チームごとにルールがバラバラ
それどころか個人間でもルールが決まってなくてこっちで勝手に決めたら反発がもの凄くて結局断念
いまだにメールでファイルパスが飛び交ってるし、2023年になったから「今年」フォルダの中身が移動されるらしい
とか言っても理解して貰えない
チーム毎にエクセル使ってるところはあるけれど
それもリーダーが頑張ってまとめてるだけで各人が何かまとめてるわけではない
みたいなことをやったけれどほとんど使われず
タスクごとにファイルを添付すればファイル共有サーバも必要ないよね？っていうのを目論んでいたんだけれど
そもそも「タスク」の概念が無い様子だったので導入できるわけがなかった
費用や予算に関して複数のエクセルシートを駆使して管理していた
予算担当者のみがExcelを編集可能なので、担当者が休みだと予算確保ができない
おまけにExcel使ってても一部は手計算（シートをまたがって参照できないと思ってたらしい）なので
年末には紙に印刷して電卓で検算大会が開催されるという意味不明なことが行われていた
選定までちゃんと行ったけれど「未来予算との差分計算ができない」みたいな理由で結局導入を断念
「その計算いります？報告してるだけで誰も気にしてないでしょ？」
という話をしたが、結局導入はされなかった
唯一成功したのが「Excelを印刷して、手書きサインをもらって、それをPDF化して共有フォルダに保存」の廃止
なぜ手書きの必要があるの？というのを確認しまくって手書きサイン不要な書類についてはデジタル保存で完了
どうしても手書きサインが必要と譲って貰えなかったものに関してもPDFのサイン機能で了解を得た
印刷することがないから、Excelで無理矢理A4用紙の見た目にする必要無いよね？というのが今年のステージなんだが、まぁ多分無理な気がしてる
そういや、外部企業で手書きサインを求めてくる会社には仕方なく手書きサインしてるけれど
「人事に関わることなので紙保存です」
なので人事部とだけは紙でやりとりしているし、なんならそのために出社することもある
「今の仕事が楽になる」「今の仕事がより正確になる」という予想ができない人に対して新しい方法を提案しても抵抗しかされない
仕事が楽になった経験よりも、何かしらの障害で失敗した経験の方が記憶には残っているようで
1％の確率で失敗して破滅的なことになるよりも、辛いけれどどうにかなっている現状で耐え忍ぶ、という彼らなりの処世術なんだろう、と思う
DMM版ウマ娘プリティーダービーを遊ぼうとしても、エラーダイアログを出さずに起動しなくなる現象に遭遇した。
Windowsのイベントビューアーを除くと、こんなログが吐かれていた（各IDは削除）。
=====
日付:
ユーザー:
説明:
障害が発生しているアプリケーション名: umamusume.exe、バージョン: 2020.3.24.51085、タイム スタンプ: 0x
障害が発生しているモジュール名: apphelp.dll、バージョン: 10.0.22621.963、タイム スタンプ: 0x
障害が発生しているアプリケーション パス: D:\DMMGames\Umamusume\umamusume.exe
障害が発生しているモジュール パス: C:\WINDOWS\SYSTEM32\apphelp.dll
結論から言うと、Windows本体のapphelp.dllが原因でウマ娘が起動できなくなっているという。
アプリケーションに罪は無いため、DMM Game Playerやウマ娘を何度再インストールしても直らない厄介な現象だ。
Windowsは数十万のファイルが存在するため、今回のようにWindows Updateやアプリケーションのインストール・アンインストールを繰り返すだけでシステムファイルが壊れる事がある。
Windowsでは、これを直すためのコマンドがコンソールUIのみに用意されている。
Windowsのスタートメニューを右クリックして、コマンドプロンプトまたはターミナルを管理者権限で起動する。
を実行する。これは、オンライン上にある正しいWindowsのシステムイメージを元に、壊れたファイルを修復する操作となる。
実行するとこう表示される。
[==========================100.0%==========================] 復元操作は正常に完了しました。
DISM.exeを実行すると、正しいWindowsのシステムイメージがPC内に保存された状態になる。
この状態で、
sfc /scannow
を実行すると、次のように表示される。
システム スキャンを開始しています。これにはしばらく時間がかかります。
Windows リソース保護により、破損したファイルが見つかりましたが、それらは正常に修復されました。
オンライン修復の場合、詳細は次の場所にある CBS ログ ファイルに含まれています
windir\ Logs\CBS\CBS.log (たとえば C:\Windows\Logs\CBS\CBS.log)。オフライン修復の場合、
これで、とりあえずWindows自体の修復コマンドによってシステムファイルが正しい状態に復元された状態となる。
実行してもまだメモリ上には古いシステムファイルが読み込まれて実行されている状態なので、終わったらPCを再起動する。
さて、準備は完了だ。ここまでの操作でWindowsを回復しDMM Game Playerで「ダウンロード版をプレイ」を押す事でウマ娘が起動し…ない！
イベントビューアーには今もウマ娘を起動しようとする度にアプリケーションクラッシュイベントが追加されている。救いは無いのですか？
結局、今回のケースではPCで常駐していたリモートデスクトップ用のSplashtop StreamerとVirtual Desktop Streamerをタスクキルする事でウマ娘が起動できるようになり、DMMブラックフライデーで得た有償石でおはガチャを回すことに23時成功した。
アラフォーにして500万円程度しか貯金が無かったことや、倒産した会社の後片付けをしたり、弱った心理に漬け込まれ立て続けに数人の詐欺師のような輩に騙され貯金も底をつき、少し借金もしてしまった。
人をすぐ信じてしまうわけではないが、人の信用を無くさないよう物事をやり切る根性だけはあったので、会社員時代は有利に働いていたそれも結果として悪い方向に動いてしまった。
コロナの悪い雰囲気の中だったこともあり、正直この世と人生を恨んだし結構キツかった・・
そんな中、子供もいるので自然と家計も含めた全負担が妻にかかる状況になっていたので流石に職探しをすることにした。妻は失敗を咎めずやりたいことをやれば良いと何も言わずに応援してくれた。感謝。
人は窮地に追い込まれたときと権力を得たときに本性が出るというが、妻は中々根性あるなと思う。
自分は受験に大失敗したFラン大学出身ということもあり学歴コンプが強く劣等感に苛まれた半生を送ってきたのだが、その負の感情を少しでも緩和してくれるのが専門知識を貯めること、つまり勉強だった。
社会人生活の中でも、要領も覚えも悪い頭に鞭打って勉強だけは続け、何であんなに頑張るの？等と言われながらも職場でアウトプットすることを心掛けていた。当然失敗も沢山ある。
ただ、その積み重ねとキャリアがこのタイミングで功を奏し年齢的にもキツいと思っていた転職活動は5社程度からオファーを貰うことが出来た。
最高で1500万円近いオファーもあったが、結局知り合いから何社か仕事を貰うことが出来たのでオファーを断り会社を作り経営している。感覚的に5年位は自分の市場価値は下がらないと踏んだので社長というキャリアにチャレンジした。
今のところ、まだ2期目の途中だが役員報酬とは別に3000万円以上の現金が貯まった。まだ口座の金額を見るたび怖くなる。
運の要素も大きいが、なけなしの資本金30万円で始めたので学歴底辺としては悪くはないだろう。
今回、貯金ほぼゼロからのスタートでもあまり不安にならなかったのだが、その背景にあるのは勉強を続けてアウトプットを続けたことと人の信用を大事に仕事をしてきたことだと思う。
金は無くとも自己資本力を積み重ねていれば自信になるし、ある程度のやり直しは効くということを身をもって学んだのだ。
難しい大学入試解けるような頭の良い輩は元々の自己資本力が高いのだろう。自分も同じスタートラインに立っていれば、もっと豊かな人生を歩めていたのだと思う。
しかし、筋肉が裏切らないのと同じくらいに知識も自分を裏切らないので、これからも現状に胡座をかかずに知識の習得とアウトプットを続けていこうと思う。知識も使わないとやせ細る。
勉強を続けられるのは才能という人もいるが、やり方次第ではそんなことはない。
単に失敗や出来ないこと、知らないことが恥ずかしいと思えれば人は自動的にその解決策となる知識を習得しようとする生き物なのだ。
まず自分の人生の恥部を思い出したりアドレナリンが出るような妄想をしてみよう。
とか
ふぉぉおーヤバい間に合わない、あと30分しかない！全然出来てない、だめだっ・・！
という気分になったら、今から勉強する知識がその救いになると自分を言い聞かせるだけ。簡単。
目標を持ってプラスを増やすために勉強する場合、常に意識する大きな期待値が無いと続かない。更に自分へのご褒美とかやってると雪だるま式にコストも増える。
これが危機感をトリガーにマイナスをゼロにするつもりで挑むと割と続く。必死になるからだ。
最近、会社経営も10年後の常識なんかを想像しながら自分の会社はまだこんなことも出来ていない、マズい！と妄想しながら事を進めるとあらゆることが早く進むことがわかったし、事業のタネも自然と出てくるようになった。
1passwordとかLastPassを使い始めると、新規登録の際に英数記号100文字パスワードなんかでホイホイ登録するようになる。
これも体感では、弾かれたうちの半分が文字数超過、1/4が記号を含むことを許可しない、1/4が含んでいい記号が制限されている、が原因。
記号については内部でエンコードやらエスケープやらがあることは分かるんだけど、なんでたかだが100文字の文字数上限があるんだよ。
歴史あるサービスならわかるけど、ここ数年でリリースされたサービスでそういうのあると技術力を疑うのでサービスを利用するのをためらってしまう。
これ
家庭にBacklogを導入してタスクを可視化しようとしたら大失敗した
https://anond.hatelabo.jp/20220607152713
会社でもよく見かける気がするんだけど、複合問題だと思うんだよな
やりたいこと：タスクをやってほしい
ここでずれてると思う
「タスクをやらせる」の解決策として「タスク管理ツールの導入」は間違いどころか逆効果かもしれない
元増田も気づいてるけど
会社では、予算や計画を立てて、リソースを確保し、それを実効するというのが基本サイクルだから
その全タスクが膨大だったとしても「やりたくないなあ」にはならない、仕事なんだから
じゃあ私生活でこれをやるとどうなるかというと
・可視化されたらやることが膨大でやる気を無くす
・リソースが限られている
・やっても金が稼げるわけでもない
から、当然やらない
これは家族間でやってもそうだし、自分でやってもそうだろうと思う
「タスクをやらせる」というのは、普通に親のようにガミガミ言ってやらせるか、もしくはゲーミフィケーションの導入が妥当だと思う
ものすごく平たく言うと「恐怖で支配する」か「褒めて伸ばす」か
つってもゲーミフィケーションも難しいし大変なんだけど
夫婦間？無理に決まってる
ところでこの
・可視化されたらやることが膨大でやる気を無くす
・リソースが限られている
・やっても金が稼げるわけでもない
から、当然やらない
という状況はベンチャー企業の状況に似ている
彼らがよく言うやり方は「タスクの取捨選択」「イテレーションを回す（スクラム、かんばん）」だ
タスクを洗い出す、1週間でできることだけやることリストに入れ、実施し、振り返る
このフローだとよりうまくいくかもしれないが
これだってやる気が無いやつのケツを叩くだけのパワーはないので
スクラムマスターのような、いわゆるマネージメントをする存在は不可欠であり
マネージメントでできるのは上で言った「怒る」「褒める」程度のものなんだろうと思う（ここらへんは専門外なので詳しくない）
ちなみにBacklogはこのようなかんばん方式もフォローしたらしいので使ってみるといい
https://backlog.com/ja/blog/backlog-update-2020-01-28-kanban-board/
長かったね
俺の記憶だとブームがredmine→Backlog→jiraと変遷したと思ってたけど着実に頑張ってたようだ
たまに使ってるよ
ーーー
確かそう言う本あったよね、詰んでるわ笑
毎年のように「ダメなパスワードランキング」とか、流出したパスワードでアカウント乗っ取られてヒドイ目に...とか話題になっていて、同一パスワードを使い回すのはもってのほか！パスワード管理ツール／アプリを使おう！みたいなことよく言われてるけど、そのツールのデータがどっかから流出／ハッキングされて暗号破られたりするとスゴイ嫌じゃん。攻撃者だって、そういうツールがインストールされてるってことは、そこにあるのが分かるんだから狙って来やすいじゃん。
紙に書いたりしてどっか保管しとくのもダサい。
ということで、
自分の名前とか、住所とか、飼ってる犬の名前とかをモジって、適度な長さの辞書に無いコトバを決める。辞書に載ってるか否かで、強度がそんなに変わるのかは定かでないが、まぁ気休めとしてw
太郎なら tarosanとか、品川ならshinagとか、花子ならhanachoとか適当に。
これは、毎度入力を求められるたびにタイプすることになるので、まぁまぁ変な文字列でも忘れない。心の中にだけしまっておいて、どこにも記録は残さない。
アカウント登録や、サイトによっては半年に一度くらい「パスワード変更しろ」とか言われて更新するときの日付をyymmdd形式とか、より安全に年を4桁とってyyyymmddとかにしてくっつける。
hanacho220524 みたいな感じだ。
同じ日に複数サイトのアカウント作る時がもしあったら、別に正確な日付が欲しいわけじゃ無いから、昨日の日付でも、1ヶ月先の日付でも構わないから違うモノにしろ。
そういうめんどくさいルールがあるサイトの場合は、先頭だけ大文字にするとか、末尾にハイフン’ｰ’付けるとか、自分なりのルールを決める。このルールも心の中だけにしまっておく。
PCでもスマホでも各自使いやすいカレンダーアプリが１つや２つインストールしてあるだろ。上の例で言えば、2022年5月24日のカレンダーイベントとして、たとえば「ますだ」みたいなWebサービスやサイトの名称から容易に思いつく検索しやすいタイトルで、イベントを書き込む。
アレンジが必要なサイトだったら、「大文字」とか「記号」とかをイベントの内容だか注釈だかのところに書いておく。
こうしておけば、あちこちのサイトでログインが必要になった時点で、カレンダーアプリを「ますだ」とかで検索すると、イベントの日付が分かるので、心の中にだけ持っている語幹と合わせてパスワード欄に入力すればオッケーってわけだ。
これなら、カレンダーアプリのデータが盗まれて、めっちゃ強力な暗号解析ソフトとかでハックしまくられても、パスワードがバレることは無いと思うw
Enjoy!
弊社ではその設立当初、というよりも創業者(＝私)が個人事業主だった頃から業務にFLOSSを多用しています。
今回その事例を情報共有するためにエントリを作成いたしました。
従業員50人ほど(学生アルバイト含む)の会社です。ちなみにかなりボカして書きます。
弊社では社内文書をSDGsの観点からペーパーレスに努めており……と表現すると些か格好付けすぎなので正直に言えば個人事業主時代に印刷機複合機のランニングコストがバカにならなかったので物理ペーパーへ出力するのを控えていた運用がそのまま法人化されても続いているだけです。
社内文書として用いられる文書フォーマットはODF形式で統一している……というかコレもまた個人事業主時代にOpenOfficeを活用しており、現在社内で使われている主なオフィススイートはLibreOfficeとなっています。
注意点としては弊社がルールとして定めているのはODFを用いることでありLibreOfficeの利用を強制しているわけではないという点です。
従業員の中にはLibreOfficeを常用せず、AbiWordやGnumericを普段使いしている者も居ます。
弊社は社外とオフィス文書ファイルをやり取りすることが一切なく、オフィス文書ファイルと表現するには正しくないですが社外とはPDFをやり取りするくらいなので何か問題が起きたことが今まで特にないです。
ただ1つ問題があり、弊社はこれまでLibreOfficeを無償で活用させて頂いており、これまでの感謝を示すためLibreOffice Enterpriseへの移行を考えているものの日本国内でLibreOffice Enterpriseを利用するための情報が一切なく困り果てています。
最悪、海外の企業を頼る方法もありますがサポート時間の都合などがあるため可能ならば国内で探したいと考えています。どうにかならないものですかね？
社内では「むしろウチがやったら？」なんて声もチラホラ聞こえますが……。
ちなみに社内デファクトスタンダードのフォントはNoto Sans Japaneseです。一部でTakao(IPA)が使われています。
弊社ではFLOSSを活用しているせいもあって特にOSの縛りを設けていません。何なら経理担当はChromebook使ってます。
社内のOSシェアはChromeOSを含めたLinuxディストリビューションが5割、macOSが2割、残りがWindowsとその他です。
気になるであろう開発環境についてですが、Dockerを用いて開発環境の統一化を計っており、その時々に応じてDockerコンテナを切り替えて開発しています。
Dockerを用いているせいもありLinuxディストリビューションの社内OSシェアが高くなっているのです。
プライベートで従業員は様々なOSを選択しているようです。ゲームとかVRが趣味であるならばWindowsしか選択肢ないでしょうしね。
ちなみに業務用のPCはBYODで購入補助あります。
結局は従業員の現物給与として課税されてしまうだけなので「いくらでも良いけど高すぎるの買うと年収増えすぎて痛い目みるよ？」とは助言してます。
会社はまとまったお金を出しているに過ぎないのでメリットとデメリットがありますよね。
いちいち申請出す方もチェックする方も面倒なのでGNUプロジェクト下ソフトウェアは無申請で利用可としています。
ただし制限は公式リポジトリまたは弊社が安全だと判断しているリポジトリで配布しているバイナリのみという条件が付きます。
どこの会社もそうでしょうけれどもAWSやAzure、GCPなどたいてい大手に置いてますね、予算の都合もあるけれど。
これは弊社が強制しているわけではなく、弊社デザイナーの第1号従業員がWindowsユーザであったので惰性のままWindowsとなっているだけであり、中にはMacで仕事している従業員も居ますし、状況によってLinuxディストリビューション(主にUbuntu)上で仕事しているときもあります。
Linux環境では苦手なIllustratorのAI形式などはSVGやラスター画像に落とし込んでもらって開発者が適用するという運用になっています。
社内では特定の環境へ依存するファイル形式はとことん嫌われる傾向にあります(妙な仕事が増えるから)。
開発者から経理、デザイナーに至るまで弊社従業員はみんなGitが使えます。
ただし使えると言っても全員がCLIからコマンドを打てるわけでなくGUIクライアント上からの操作しか出来ない者も居ます。
主に使われているGitのGUIクライアントはGitKrakenです。
入社時の受け入れ教育でLibreOfficeやGitの指導をすることになっており、全従業員が浅くともGitとは何ぞや？を理解している状態にあります。
ちなみにGitリポジトリは主にGitLabへ置いていてUltimateを契約させてもらってます。
社内にセルフホストしているGitLabサーバもありますが、こっちは従業員が個人開発しているものを投げているようですね。業務にあまり使われていません。緊急時のバックアップと思われるものがちょこちょこありますが。
プロジェクト管理ツールはいろいろと試したのですがOpenProjectへ落ち着きつつあります。
プロジェクト管理ツールの選定は各プロジェクトマネージャへ任せているのですが、旧来からあるRedmineと操作性が近い上にGitLabとの連携も容易でなかなか良いとのこと。
他社とのやり取りにSlackやTeamsやZoomが出てくることもありますが、社内だけで完結する際はたいていElementが使われています。
これは当時インターン生だった弊社の現従業員が若者の熱意と共に持ち込み、サーバを与えたら喜々として運用をはじめたので、それをきっかけに便利だったからそのまま使わせてもらってます。
ぶっちゃけて言えば私個人のこだわりはチャットにありません。従業員が楽しそうに使っていればそれで良いんじゃないかと。
IRCとか持ち出されたら「今どきそれはどうなの・・・まぁ良いけど」って言うかも知れませんが。
会計はFreeeです。特にこだわりはありません。たまたまWebブラウザから使えたのでFreeeとなってます。
残り5%は主に私が出社しているからｗ
社内にサーバがあるので私以外も出社してくることはありますが基本的にコロナ禍以降は全従業員がリモートワークです。
そもそもコロナ禍以前でもリモートワークしてた気がしなくもないのですが当時は3割4割くらいだったでしょうかね？週に何度か出社して来ないが自宅からdoneしてくる従業員が何名も居たので。
タイムカードもElementのbotへ投げると自動的に処理するようになってます……が、実際のところ最後の処理で私が大目に時間を付けてます。打刻を忘れることもあるしね。少ないより良いやろｗ
結局、郵送物(今ならコロナワクチン関連とか)を処理する必要があったりなど誰かしら会社に人が居なければならず、自分でも忘れがちですが創業者なので私が会社に居るよってことで私だけがほぼ出社するという状況になってます。
オフィスの処分も一時期考えたのですが、増員への教育とか考えるとやっぱりオフィスあったほうが良いよなぁなんて思ってそのままです。もしかしたら引っ越しするかも？
1つだけ申し訳ないことがあって、コロナ禍の状況下でどうやって増員したら良いのか教育したら良いのか私の能力を超えていまして現在は新規募集を停止中です。いやホント申し訳ない。
事業が軌道に乗った以降は毎年最低1人は取ろうねと古株と話していたんですが、こうなっては無理だよねと苦笑しあってます。
どうやって世間の同規模中小企業は新人教育やってるのか解らなすぎる。会社に誰も居ないじゃんと。
上場する気も更々ないし無借金なので、のん気にこのままゆっくりと会社を維持していきたいなぁと思ってます。
早くコロナ禍終わらんかなぁ……。
ストア出店だけどもうなんというか失望・落胆通り越してへぇ～って感じ。
→ヤフオクだけ出品は不可。ヤフーショッピング契約して併売という形式でのみヤフオク出品可能
（管理ツールも統合[お察しの通りUIゴミ]。死亡するショップ多数と思われ）
→yahooローカルルールのオーダーフォーム撤廃により、バックレ防止は唯一の利点だがそれを遥かにしのぐデメリット有
１．出品個数１個のみ → 複数点は買えません。ヤフーショッピングで買って下さい。 ※誰か解決方法あれば教えて
２．同梱不可 → 送料個別に払ってね。んで１つずつ決済してね。
３．競り出品はまだできないから定額出品で頑張って → オークションとはいったい。。。
経緯を調べたらヤフーショッピング、ぺーぺーもーるｗ が伸びててヤフオクの伸びが悪いからとかなんとか。
しかも手数料がヤフオク無料でっせ～てのが売りだったのに、しれっと８％前後まで増えてるしマジうけんですけどｗ
（楽天、アマゾン etc いずれも基本１０％前後なので大して変わらない。）
別にヤフオク依存してる訳ではないけどクソすぎるっしょ中の人。出品個数１とかお客さんに「複数個欲しいけどどうしたらいい？」って
言われたら 「無理です。ヤフーショッピングで買って下さい。」 って言えって事でしょ？そら問合せ爆増するから複数個落札前提の商品
出品停止するじゃん？売上落ちるじゃん？あたりまえじゃない？わかんない？これにゴーサイン出した人の神経疑うわ。。。
全店舗対象だから予想通りtwitter にて阿鼻叫喚。しかも恐ろしいのはヤフーショッピングのツール導入が難しく
やっとこさ出来たとしても上記の通り従来運用不可なとこ／(^o^)＼
システム統合によるコスト削減もあるとは思うけどこのままだったらヤフオクはないな。
こんなの
{2593F8B9-4EAF-457C-B68A-50F6B8EA6B54}
および APPID
{15C20B67-12E7-4BB6-92BB-7AFF07997402}
の COM サーバー アプリケーションに対するローカルアクティブ化のアクセス許可を、アプリケーション コンテナー 利用不可 SID (利用不可) で実行中のアドレス LocalHost (LRPC 使用) の
ユーザー Masuda\YourPC SID (S-*--**-******-******-******-****) に与えることはできません。このセキュリティ アクセス許可は、コンポーネント サービス管理ツールを使って変更できます。
結論としては
であり
These events can be safely ignored because they don't adversely affect functionality and are by design.
ということでこれはそういうものなので無視してよい、気になるならイベントビューアに記録されないようにフィルタを書け、警告の文面通りにセキュリティ許可をいじるのはどんな副作用が起きるかわからないのでお勧めできないだそうだ
お勧めできないってなんだそりゃ
まあいいや
まずは、日立のサーバーでの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側で統一することも期待したいところです。
まあ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の活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
