  |
はてなキーワード:enterpriseとは
AIバブルに胸を躍らせている若い方々を見ると、どうしても二十数年前のドットコムバブルを思い出します。
当時の空気は、いまのAIブームとよく似ています。「この技術が世界を変える」という熱狂の中で、株価も評価も天井知らずに上がっていきました。しかし、バブルの裏側では、いまでは信じられないような出来事がいくつも起きていました。
ドットコムバブルで最も大規模な破綻を起こしたのは、インターネット企業ではなく通信会社でした。
日本ではNTTが当時すでに大量の光ファイバーを敷設していたため、同じような「過剰投資による事業崩壊」を肌で実感しにくかったかもしれません。しかし、設備投資が巨額になる業種がバブル期に過熱すると、崩壊した際の痛手は極めて大きいということは、ドットコム期の重要な教訓です。
当時、ISP（インターネット接続事業）は金鉱脈と認識されていました。
通信会社はもちろん、総合電機メーカー、ダイヤルQ2サービスの運営者、さらには互助会、個人レベルまで――「うちもISPをやれば儲かる」という空気がありました。
しかし、結果はご存じの通りで、
と、最終的には参入過多 →価格競争 →事業撤退の典型的な業界となりました。
当時、技術者の憧れはSun Microsystems のEnterprise Server でした。SPARC/Solaris は最先端で、「Sunの箱が置いてあるだけで先進企業」と言われたほどです。
最終的に2010 年、Sun はOracle に買収され、企業としての歴史に幕を下ろしました。
技術としての価値があっても、時代の波とビジネスモデルの変化には勝てないことがある、という象徴的な例です。
Ciscoはバブル期の「象徴企業」の一つで、当時の言葉で言えば “Ciscoが使えたら一生食いっぱぐれない” と真剣に言われていました。
実際、倒産はしませんでしたし、いまでもネットワーク技術において極めて重要な存在です。しかし、
余談ですが、今日でも外資系企業の40代・50代には、「元Cisco」「元Oracle」という人材が大量にいます。
彼らは、当時どれだけこれらの企業が“勝ち組企業”に見えていたかが分かります。
バブル期にはいま振り返ると不思議なブームが多いものですが、象徴的なのが プッシュ技術 です。
ブラウザはユーザーが能動的に情報にアクセスする方式でしたが、プッシュ式で情報を送る技術が提案されました。
具体的には Marimba とか PointCast ですね。
一瞬だけ「次世代の主役」と持ち上げられたものの、課題が多く短命に終わりました。
短命の流行はいつの時代にもありますが、バブル期にはこれが増幅されやすい、という好例です。
バブルは弾けましたが、インターネットそのものは多少の停滞はあったかもしれませんが、消滅するどころか大きく発展しています。
AmazonやGoogleといった会社のようにドットコム企業とみなされていた会社も社会に定着しています。
インターネットはその後20年以上かけて、社会のインフラそのものに進化しました。
当時の一般的な回線速度の1000倍以上の速度で通信できる端末を、誰もがポケットに入れて持ち歩いています。
“バブル期の期待”をはるかに超える形で、インターネットは世界を変えました。
AGI（汎用人工知能）が本当に実現するかは分かりません。しかし、
といったドットコム期の教訓を踏まえれば、AIもまた“社会を便利にする技術として定着する可能性は極めて高い” と感じています。
テスラの「Sr.Software Engineer, Full Stack - Tesla Cloud Platform（TCP）」の求人（https://www.tesla.com/careers/search/job/sr-software-engineer-full-stack-tesla-cloud-platform-249132）を起点に、自動車各社が同種人材を採用する“目的”の違いを整理した。日本勢はIT基盤やSRE運用の比重が高い一方、テスラは社内クラウド自体をプロダクトとして内製し、中国勢のNIOやXPengはAIインフラ（自動運転やロボティクス、エネルギー連携）に特化、ECARXはOEM向けの外販プラットフォームという立て付けである。
| 会社 | 主要目的 | What to Expect | WhatYou’ll Do | WhatYou’ll Bring | Compensation and Benefits |
|---|---|---|---|---|---|
| Tesla | 社内クラウド（TCP）を“製品として”内製し、全社サービスの速度と統制を握る | TCPはテスラの内製クラウドであり、複数DCにまたがる計算・ストレージ・ネットワーク・IDを提供し、開発者がセルフサービスで使える基盤をつくるチームである | コアAPIやサービスの設計実装、セルフプロビジョニングの自動化、可観測性、ReactやNextやTypeScriptによるダッシュボード | GoやReactやNextやTypeScript、Kubernetesや仮想化、CI/CD、分散システムの知見 | 年収133,440〜292,800USDに加え、現金賞与と株式付与および福利厚生。提示額は勤務地、市場水準、職務関連の知識、スキル、経験など個別要因により異なる。本職の総合的な報酬パッケージには、提示される職位に応じて他の要素が含まれる場合がある。各種福利厚生制度の詳細は、内定時に案内される。 |
| WovenbyToyota | 製品直結サービスを“止めない”SRE運用（AreneやEnterpriseAIやCity Platform） | ミッションクリティカル運用の信頼性最適化を担う | 監視や可観測性やインシデント対応や運用自動化、マルチクラウド横断 | SRE実務、Kubernetes、Terraformなどの基盤スキル | 給与は多くが非公開。米拠点の類似シニアは$169K–$200Kの例あり。 |
| Nissan | 全社ITや開発のモダナイズと標準化（Platform EngineeringやDevEx） | 社内開発者のクラウド活用を底上げする基盤を整える | CI/CD、セキュア環境の供給、教育や展開、オンプレとクラウドの統合運用 | クラウドやコンテナ、CI/CD、セキュリティ設計 | 多くがレンジ非公開（地域により待遇差） |
| Honda（Drivemode含む） | 製品直結のAWS基盤と開発者体験の高速化（DevEx） | モバイルやIVIやバックエンドの横断基盤を整える | AWS設計運用、GitOps型プロビジョニング、CI/CD、観測やセキュリティの自動化 | AWS、TerraformやCDK、Kubernetesなど | 本体US求人はレンジ非開示が多い。Drivemodeはホンダ完全子会社（前提関係） |
| NIO | AI学習や推論インフラの内製強化とエネルギー運用統合 | 自動運転やVLMやLLMなどのAI基盤を構築する | GPU最適化、分散学習、データパイプライン整備 | 深層学習や分散処理、クラウド、最適化 | 米SJ拠点で$163.5K–$212.4Kのレンジ例。 |
| XPeng | FuyaoAI PlatformによるADやロボやコックピット向けAI基盤 | 社内共通のMLプラットフォームを提供 | データローダやデータセット管理、学習や推論スループット最適化 | 分散処理、MLプラットフォーム運用 | クラウド 米サンタクララ拠点の公募多数（給与は媒体や募集による） |
| ECARX（Geely系） | OEM向けに外販するクラウドやソフト製品（Cloudpeakなど） | 車載SoCからクラウドまでを束ねる外販スタック | 製品機能開発や統合、導入支援、機能安全準拠 | 車載とクラウド統合、機能安全、顧客導入 | ハイパーバイザなど 直近レンジ情報は公開少なめ（事業広報は多数） |
なお、関連するポストとして、SETI Park氏のポストを挙げる。
https://x.com/seti_park/status/1961629836054859810
「自動車メーカーがなぜクラウド専門人材を探すのか」に答える文脈で、2024/07公開のテスラ特許（US2024249571A1）を手がかりに、ロボタクシーやフリート運用の中核となるクラウド基盤が競争優位になり得る点を示唆している。
単なるストレージではなく、フリート運行やデータ連携を統合管理する“中核プラットフォーム”としての重要性が強調される。
上記はテスラのTCP求人（セルフサービスIaaSやダッシュボード、プロビジョニング自動化の開発）という具体の採用と整合的である。
一度投稿したうえで別タブを開いてプログラム的(fetch)に送信してその別タブが閉じられる仕組み。
// ==UserScript== // @namePGP未署名検出と別タブ自動編集 // @namespacehttp://tampermonkey.net/ // @version 1.0 // @descriptionPGP署名がない投稿を自動編集ページへ誘導 // @matchhttps://anond.hatelabo.jp/* // @grantGM_setValue // @grantGM_getValue // @grantGM.openInTab // ==/UserScript== (function () { 'use strict';constbody = document.getElementById('entry-page'); if (!body) return;consttitleText = document.title; if (!titleText.includes('dorawii')) return;constpgpRegex = /BEGIN.*PGP(?: SIGNEDMESSAGE| SIGNATURE)?/;const preElements = document.querySelectorAll('div.body pre'); let hasPgpSignature =false; for (const pre of preElements) { if (pgpRegex.test(pre.textContent)) { hasPgpSignature =true; break; } } if (hasPgpSignature) return;const editLink = document.querySelector('a.edit');const childTab =GM.openInTab(editLink.href, {active:false, insert:true,setParent:true }); })();
// ==UserScript== // @name編集ページ処理と自動送信・閉じ // @namespacehttp://tampermonkey.net/ // @version 1.0 // @description編集ページで署名処理と送信、タブ自動閉じ // @matchhttps://anond.hatelabo.jp/dorawii_31/edit?id=* // @grantGM_getValue // @grantGM_xmlhttpRequest // @grantGM_setClipboard // @grantGM_notification // @connectlocalhost // ==/UserScript== (async function () { 'use strict';const shouldRun = awaitGM_getValue('open-tab-for-edit', '0');consttextareaId = 'text-body';consttextarea = document.getElementById(textareaId); if (!textarea) return;const content =textarea.value;constpgpSignatureRegex = /-----BEGINPGP SIGNEDMESSAGE-----[\s\S]+?-----BEGINPGP SIGNATURE-----[\s\S]+?-----ENDPGP SIGNATURE-----/; if (pgpSignatureRegex.test(content)) {console.log('[PGPスクリプト]署名が検出されたためそのまま送信します'); return; }consthttpRequest = (url, data) => { return newPromise((resolve,reject) => {GM_xmlhttpRequest({ method: 'POST',url:url, headers: { 'Content-Type': 'application/x-www-form-urlencoded' }, data: `value=${encodeURIComponent(data)}`,onload: function (response) { resolve(response.responseText); },onerror: function (error) {reject(error); } }); }); }; //textarea の値を取得 // 1.現在のページのURLからURLオブジェクトを作成const currentUrl = newURL(window.location.href); // 2.ベースとなる部分 (例: "https://anond.hatelabo.jp") を取得constorigin = currentUrl.origin; // 3. 'id'パラメータの値 (例: "20250610184705") を取得constidValue = currentUrl.searchParams.get('id'); // 4.ベース部分とIDを結合して、目的のURL文字列を生成 //idValueが取得できた場合のみ実行する let newUrl = null; if (idValue) { newUrl = `${origin}/${idValue}`; } // 5. 生成されたURLを変数に代入し、コンソールに出力して確認console.log(newUrl);constvalueToSend = newUrl;try {const signatureText = awaithttpRequest('http://localhost:12345/run-batch',valueToSend);console.log('バッチ応答:', signatureText); if (!signatureText.includes('BEGINPGP SIGNEDMESSAGE')) { alert('PGP署名がクリップボードに見つかりませんでした。'); return; }const newText = content.replace(/\s*$/, '') + '\n' + signatureText + '\n';textarea.value = newText;console.log('[PGPスクリプト]署名を貼り付けました。送信を再開します。');const form = document.forms.edit;const newForm = form.cloneNode(true); form.replaceWith(newForm); newForm.addEventListener('submit', async (e) => { e.preventDefault(); //HTML標準のsubmitをキャンセルconstbodyText =textarea?.value || ''; //reCAPTCHAトークンの取得constrecaptchaToken = await newPromise((resolve) => { grecaptcha.enterprise.ready(() => { grecaptcha.enterprise.execute('hoge', {action: 'EDIT' }) .then(resolve); }); }); // POSTするデータの構築const formData = new FormData(newForm); formData.set('body',bodyText); formData.set('recaptcha_token',recaptchaToken); formData.set('edit', '1');try {constresponse = await fetch(newForm.action, { method: 'POST',body: formData, credentials: 'same-origin' }); if (response.ok) {console.log('送信成功'); window.close(); } else {console.error('送信失敗',response.status); } }catch (err) {console.error('送信中にエラーが発生', err); } }); //プログラム的に送信トリガー newForm.dispatchEvent(new Event('submit', { bubbles:true })); }catch (e) {console.error('バッチ呼び出し失敗:', e); } })();
consthttp =require('http');const { exec } =require('child_process');const querystring =require('querystring');const server =http.createServer((req, res) => { if (req.method === 'GET' && req.url === '/ping') { res.writeHead(200); res.end('pong'); } else if (req.method === 'POST' && req.url === '/run-batch') { letbody = ''; req.on('data', chunk => {body += chunk.toString(); }); req.on('end', () => {constparsed = querystring.parse(body);constvalue =parsed.value || 'default'; // 値を引数としてバッチに渡す exec(`C:\\Users\\hoge\\Desktop\\makesign.bat "${value}"`, { encoding: 'utf8' }, (err, stdout, stderr) => { if (err) { res.writeHead(500); res.end('Error executing batch: ' + stderr); } else { res.writeHead(200, { 'Content-Type': 'text/plain; charset=utf-8' }); res.end(stdout.trim()); } }); }); } else { res.writeHead(404); res.end('Not found'); }});server.listen(12345, () => {console.log('Batch serverrunningathttp://localhost:12345/');});
@echo offsetlocal enabledelayedexpansion::署名するファイル名set "infile=%~1"set outfile=%TEMP%\pgp_output.asc:: 以前の出力があれば削除if exist "%outfile%" del "%outfile%":signloop::AutoHotkeyでパスフレーズ入力（gpgがパスワード要求するダイアログが出た場合に備える）start "" /b "C:\Users\hoge\Documents\AutoHotkey\autopass.ahk"::PGPクリア署名を作成echo %infile% | gpg --yes --clearsign --output "%outfile%"::署名が成功していればループを抜けるif exist "%outfile%" (goto postprocess) else ( timeout /t 1> nulgoto signloop):postprocesspowershell -nologo -command ^ "$header = '>|'; $footer = '|<'; $body =Get-Content '%outfile%' -Raw;Write-Output ($header + \"`r`n\" + $body + $footer)"powershell -nologo -command ^ "$header = '>|'; $footer = '|<'; $body =Get-Content 'signed.asc' -Raw;Set-Clipboard -Value ($header + \"`r`n\" + $body + $footer)"endlocalexit /b
#Persistent#SingleInstance ignoreSetTitleMatchMode, 2WinWaitActive, pinentrySendInputpasswordSleep 100SendInput {Enter}ExitApp
動けばいいという考えで作っているので余分なコードも含んでいるかもしれない。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250613185036 -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaEv1FQAKCRBwMdsubs4+SHHkAQDUOLgBcdji2T6MJ7h/vlMdFfGlWAzNdXijjE1gIuEPywEAiMNMZqhrMmtlc7UqRuggNJ/UTa5xTIcKp622+7jJQQg==Lgkl-----ENDPGP SIGNATURE-----
でも、アメリカでは別の戦略で業績を伸ばしているみたいだよ。英語版Wikipedia（https://en.wikipedia.org/wiki/Nissan）によると、日産はレンタカー会社への販売を増やして売上を伸ばしているらしい。
Inthe United States,Nissanhas been increasingits relianceon sales to daily-rental companieslikeEnterpriseRent-A-Car orHertz. In 2016,Nissan'srental sales jumped 37% and in 2017Nissan became theonlymajor automaker toboostrental sales when the Detroit Three cut back less profitable deliveries to daily-rental companies, which traditionally are the biggest customers ofdomestic automakers.
つまり、レンタカー市場を積極的に活用しているってことだね。これ、同じようなことができないかな。例えば、カーシェアリングやサブスクリプションサービスに力を入れてみるとか。
SUV人気に乗れないなら、逆にEVのラインナップを充実させて新しい市場を開拓するのもアリかも。コンパクトカーがズレてるっていうけど、思い切って超小型モビリティに挑戦してみるのも面白いかもね。
まあ、日産がこのままじゃマズいのは間違いないけど、まだ手はあると思うよ。
reCAPTCHAは一応基本無料でEnterpriseのほうもそんなに高くなかったような
月100万回以上呼び出すならEnterprise使えってだけ
それよりCloudflareのTurnstile使うほうがいい
なるほどお得意様プログラムか。
https://www.microsoft.com/ja-jp/workplace-discount-program/employer-resources
従業員が法人顧客向け職場割引プログラムの割引価格で購入するには、有効な会社のメールアドレスおよび有効なMicrosoft アカウントを保有しており、所属組織が次の条件のうち 1 つを満たしている必要があります。
適格な Officeアプリケーションに対する有効なソフトウェア アシュアランス契約を締結していること。
Microsoft 365、Microsoft 365E3 または E5 をソフトウェア アシュアランスで使用していること。
Microsoft 365E3 か E5 のどちらかまたは両方のライセンスを 2,000 以上購入している、法人および政府機関。
対象となるPower BI、Office、Surfaceデバイスやアクセサリ、Windows、Enterprise Mobility に対して、過去12 か月間に $250,000USD 以上支払っている、法人および政府機関。
する方法について
https://www.youtube.com/watch?v=7TikBCboSQ8 この陰気な動画を見ろ。
この動画しか方法を解説しているものが見つからなかったのだが本当にあまりにも陰気だし、日本語では一切みつからないのでここに書いておく。
Google Workspace のアカウントでChromebook にログインするとデフォルトではいくつかの機能が利用不可能に設定されている。PIN でのログインやAndroidアプリのインストールなどである。これは通常MDM機能で有効化したり無効化したりするようだ。このようにGoogle Workspace およびChromebook には高度なMDM の仕組みがあるのだが、個人で普通のGoogleアカウントがわりにGoogle Workspace を使っている場合、そこまでのものは不要(というか邪魔)だし、そもそもこの機能は有料だし、Chromebook もMDM が有効なライセンスのものを使う必要があるようだ(ようだ、というのはこれを書いてる俺がよく分かってないから)。適当に中古で買ってきたマシンを登録できるのかよくわかってない。コンソールからEnterprise ウンタラみたいの買えるけどそれからさらにデバイスのライセンスも必要なのか、それともコンソールのだけでいいのか、デバイスにライセンスついてたらコンソールから買わなくていいのかとかドキュメントみてもよくわからん、これキッティングしてる人は神通力とかがあると思う。とにかくこれは金がかかるし難しい。
だがMDM機能を有効にしなくても、Chromebook にAndroidアプリのインストールを開放することだけはとりあえずできる。
管理コンソールの "アプリ → その他のGoogleサービス" (https://admin.google.com/ac/appslist/additional )から "managedGoogle Play" を全ユーザーにむけて有効化する。これをやらないと次にやる Play ストア の許可の設定メニューがでてこない。
"デバイス →Chrome →アプリと設定機能 →ユーザーとブラウザ → 追加の設定(右上にあるボタン)" (https://admin.google.com/ac/chrome/apps/user/settings )から Play ストアを許可する。
こうするだけでGoogle Workspace でログインしたChromebook 側から Play ストアを起動し、Androidアプリをインストールできるようになるだろう。
また管理コンソールからの "デバイス →Chrome →アプリと設定機能 →ユーザーとブラウザ" の画面からChromebook にデフォルトでインストールするアプリを設定することもできる。これを設定しておけば、Chromebook を機種変してもAndroidアプリを含めてすぐに同じ環境が用意できるようになる。簡易的だがMDM 的なことができて便利。
弊社ではその設立当初、というよりも創業者(＝私)が個人事業主だった頃から業務にFLOSSを多用しています。
今回その事例を情報共有するためにエントリを作成いたしました。
従業員50人ほど(学生アルバイト含む)の会社です。ちなみにかなりボカして書きます。
弊社では社内文書をSDGsの観点からペーパーレスに努めており……と表現すると些か格好付けすぎなので正直に言えば個人事業主時代に印刷機複合機のランニングコストがバカにならなかったので物理ペーパーへ出力するのを控えていた運用がそのまま法人化されても続いているだけです。
社内文書として用いられる文書フォーマットはODF形式で統一している……というかコレもまた個人事業主時代にOpenOfficeを活用しており、現在社内で使われている主なオフィススイートはLibreOfficeとなっています。
注意点としては弊社がルールとして定めているのはODFを用いることでありLibreOfficeの利用を強制しているわけではないという点です。
従業員の中にはLibreOfficeを常用せず、AbiWordやGnumericを普段使いしている者も居ます。
弊社は社外とオフィス文書ファイルをやり取りすることが一切なく、オフィス文書ファイルと表現するには正しくないですが社外とはPDFをやり取りするくらいなので何か問題が起きたことが今まで特にないです。
ただ1つ問題があり、弊社はこれまでLibreOfficeを無償で活用させて頂いており、これまでの感謝を示すためLibreOfficeEnterpriseへの移行を考えているものの日本国内でLibreOfficeEnterpriseを利用するための情報が一切なく困り果てています。
最悪、海外の企業を頼る方法もありますがサポート時間の都合などがあるため可能ならば国内で探したいと考えています。どうにかならないものですかね？
社内では「むしろウチがやったら？」なんて声もチラホラ聞こえますが……。
ちなみに社内デファクトスタンダードのフォントはNoto SansJapaneseです。一部で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人は取ろうねと古株と話していたんですが、こうなっては無理だよねと苦笑しあってます。
どうやって世間の同規模中小企業は新人教育やってるのか解らなすぎる。会社に誰も居ないじゃんと。
上場する気も更々ないし無借金なので、のん気にこのままゆっくりと会社を維持していきたいなぁと思ってます。
早くコロナ禍終わらんかなぁ……。
クロームブックだとマクロ使えないけど、マクラーとして20年飯を食ってきたおっさんどうすん？
ChromebookではExcelのWeb版しか使えなくてマクロ使えないんだけど。
ChromebookでM365はどこまで使い込めるのか
Microsoft 365は快適に使えるのか？
Chromebookとの親和性を探る
ニューノーマルを見据えた働き方のデバイスとして、国内でも導入が加速しているChromebookだが、Windows 10が動作するPCと比較したときに、ハードウェアの性能よりもMicrosoft 365に代表されるWordやExcel、PowerPointといったOfficeアプリが使えるかどうかが、重要な判断基準となっている。そこで、今回は国内で数多くのChromebook導入実績がある電算システムに、ChromebookでMicrosoft 365はどこまで使い込めるのか聞いた。
Chromebookを導入する動機については、これまでの連載でも端末コストの安さや運用管理のシンプルさ、セキュリティの強化など、数多くのメリットを伝えてきた。それに加えて、電算システムでは「ライセンスコストの低減」という導入効果を訴求する。ライセンスコストとは、Windows 10と旧Office 365に代表されるソフトウェアの利用契約にかかる料金だ。現在は、Microsoft 365に統合されているOffice 365だが、社員数の多い企業にとってライセンスコストは多大な経費となっている。例えば、1,000名の社員が全てWindows 10と旧Office 365を使うとすれば、かなりの価格だ。ところが、電算システムでは「仮に社員が1,000名だとしても、日報の作成にしか使わないといったライトな使い方が多く、WordやExcelなどを使い込んでいる社員の割合は少ない」と指摘する。
こうしたケースに対し、電算システムは「全社員がMicrosoft 365のライセンスを契約する必要があるのか」と疑問を投げかける。このような理由から、実際にWindowsPCからChromebookへと乗り換えた企業もある。具体的に、どのくらいのコスト削減になるのかは、ケースバイケースなので平均的な値を出すのは難しいが、仮に300名以下の企業で、WindowsPCやMacで使えるデスクトップ版のOfficeアプリ「Microsoft 365 Business Standard」を利用するとしたら、月額のユーザー当たりのライセンス料は1,360円となる。このライセンスコストを下げるために、Web版のOffice 365しか使えない「Microsoft 365 BusinessBasic」に変更すると、1ユーザーの月額は540円に下げられる。ただし、これは300名以下の企業に提供されているライセンス料なので、1,000名や1万名規模になると、事情は変わってくる。
大企業向けのMicrosoft 365となると、E3／E5／F3がラインアップされている。この中で、F3は1ユーザー当たり870円と安価だが、利用できるOfficeアプリはWeb版に限定される。フルセットのOfficeクライアントアプリを使えるのは、最低でも1ユーザー当たり3,480円のE3ライセンスからになる。この3,480円と比較すると、価格が公開されていない「Google WorkspaceEnterprise」の方が、安価になるのかもしれない。
先の試算からも分かるように、導入規模の大きな企業であれば、Microsoft 365E3やE5からGoogle WorkspaceEnterpriseに移行するためにChromebookを大規模に導入するのは、かなりのコスト削減が期待できる。加えて、端末の管理コストも劇的に低減するだろう。Chromebookは、基本的にはシンクライアントに類似した設計コンセプトになっているので、端末をネットワークにつないで登録されているアカウントでログインすれば、すぐにその端末がユーザー専用の環境になる。管理者は、端末ごとのアクセスを厳密に管理するだけではなく、その端末の状況をクラウド経由で監視できる。最新のセキュリティ対策は適用されているか、危険なアプリはインストールされていないかなどの把握に役立てられるだろう。
加えて、Chromebookではウイルス対策ソフトが不要となる。Chromeブラウザーが強力なセキュリティ対策を備えている上に、OSが高度に保護されているので、これまでに何らかのウイルスやランサムウェアなどに感染した事例がない。それだけでもウイルス対策にかかるコストを削減できるので、Officeアプリをヘビーに使い込む社員ばかりの企業でない限り、どんな企業でもChromebookへの移行は可能になる。電算システムの事例では、総合不動産のオープンハウスグループがChromebookを導入し、3年間で約32％の端末の導入コスト削減を実現させている。
そうなると、最も気になるのはアプリとデータの「互換性」だ。結論から先に書くならば、「できるWord」などの著作がある筆者が、Word2021とGoogle Workspaceのドキュメントを使い分けてきた感覚として、双方に100％の互換性はない。Wordだけではなく、ExcelやPowerPointに関しても、高度なマクロや複雑なアニメーションに凝ったレイアウトなどのいわゆる“作り込まれた”OfficeドキュメントをGoogle Workspaceのスプレッドシートやスライドで受け止めるのは無理だ。電算システムでも、「互換性は100％ではなく、8割くらいの感覚」と分析している。そう考えると、ライトに使っている人たちの多くは、Google Workspaceに移行しても困るケースは少ないだろう。
8割の互換性では困るというケースであれば、今回のテーマとなるChromebook＋Microsoft 365（Web版Office）の利用が考えられる。こちらも、結論から書くと「ほぼ100％の互換性が保持」できる。マイクロソフトの提供するクラウドサービスなので、WordやExcelで作成したファイルをWeb版Officeで利用できるOneDriveに保存しても、オリジナルのデータが棄損する心配はない。そもそもOneDrive上のOfficeデータは、Windows 10PCのクライアント版Office2021やMicrosoft 365からダイレクトに編集できるので、データの互換性は確実だ。したがって、ChromebookのChromeブラウザーからMicrosoft 365のクラウドサービスを開いて、Web版Officeを使えば、データを壊すことなく編集できる。
ただし、この方法には一つだけ落とし穴がある。Web版Officeの編集機能が制限されているのだ。それでも、日常的に使う文書／表／スライドの閲覧とコメントの書き込みなどであれば、十分に対応できる。Web版Officeを使うだけであれば、Microsoft 365のライセンスコストも安い。Google Workspaceとの二重投資にはなるが、それでもOfficeとの互換性は維持できる。
ちなみに、電算システムからChromebookを導入した企業の多くは、Microsoft 365をつなぎのように使うことなく、Google Workspaceへ移行するケースが多いという。過去のデータの互換性よりも、共同編集やクラウドファーストを志向した真のワークスタイルへの進化を最優先しているようだ。
ごめん5年サポートになったみたい 知らんかったわ
https://asohiroblog.net/windows-10-ltsc-2022-when-coming/
Windows 10EnterpriseLTSCは、大体の環境がクラウドに接続できないような環境で運用されており、一般的な企業の利用とはかけ離れた特殊なシナリオに利用されます。
たとえば、何年も機能アップデートを適用できないようなデバイスや、インターネットに接続しない製造現場のプロセス制御デバイスなど、長期的なサポートを必要とする特殊なシステムなどです。
Microsoft社は、LTSC を利用している企業に対して調査したところ、LTSC版導入企業の多くが、10年間のライフサイクルを必要としていないことが判明したとのことです。
理由としては、IT技術の変化スピードが速くなっている中、10年前の製品を使用する企業が新たな試みや事業を開拓することはできないという意見があるとのことです。
【和訳】コロナワクチンでADEが問題にならなかった理由(MedPageToday)
〜新種のワクチンであっても、抗体依存性増強が問題となる可能性は低い〜
by Veronica Hackethal,MD,MSc,Enterprise & InvestigativeWriter, MedPageToday
（原文記事）
Why ADE Hasn't Been a Problem WithCOVID Vaccines(MedPageToday)
https://www.medpagetoday.com/special-reports/exclusives/91648
パンデミックの初期に、科学者たちはCOVID-19ワクチンの有効性と安全性を確保するための最良の構築方法について、さまざまな議論を行いました。その中には、他のウイルス感染症やワクチンで見られる、死に至る可能性のある免疫現象である「抗体依存性免疫増強（ADE）」に関する議論もありました。
これまでのところ、COVID-19ワクチンによるADEの報告はありません。しかし、COVID-19ワクチンのADEに関する懸念は、ウイルスの亜種が緊急に発生したことで再び浮上してきました。ADEとは一体何でしょうか？過去の経験から何がわかっているのでしょうか？また、なぜ専門家はCOVID-19ワクチンでは問題ないと言っているのでしょうか？
◇ADEの特徴
ADEはさまざまな経路で発生しますが、おそらく最もよく知られているのは、いわゆる「トロイの木馬」経路です。これは、過去の感染やワクチン接種によって生じた非中和抗体が、再び病原体にさらされたときに、その病原体をシャットダウンできない場合に起こります。
トロイの木馬」経路とは、過去の感染やワクチン接種によって生じた非中和抗体が、再感染時に病原体をシャットダウンできず、かえってウイルスの侵入を許し、通常は侵入できない細胞（一般的にはマクロファージなどの免疫細胞）で増殖してしまうというものです。ハーバード大学T.H.チャン公衆衛生大学院のバリー・ブルーム医学博士は、MedPageTodayの取材に対して次のように述べています。
「ADEの原因は、ウイルスに対する抗体が中和されないことです。ウイルスに対する抗体が中和されず、抗体の受容体を持つ細胞にウイルスが取り込まれてしまうことにあります。これが、通常は感染しないような細胞にウイルスを取り込む方法です」とブルーム氏は言う。
ADEは、中和抗体（ウイルスと結合して感染を阻止する抗体）の存在量が十分に少なく、感染を防ぐことができない場合にも起こります。中和抗体は、ウイルス粒子と免疫複合体を形成するため、かえって病気を悪化させることがあります。
トロイの木馬型ADEの典型的な例は、デング熱です。デング熱には4種類のウイルスが存在します。それぞれのウイルスには違いがあり、過去に1つのウイルスに感染したからといって、別のウイルスから守るのに十分な抗体ができるとは限りません。
ADEはデング熱のワクチン接種後にも発生しています。例えば、2016年に4つの血清型すべてを防御するデングワクチンが開発され、フィリピンで80万人の子どもたちに接種されました。ワクチンを接種し、その後、野生型デングにさらされた子どものうち、14人が死亡しましたが、これはより重症化したためと考えられます。それ以来、このワクチンは、すでにデング熱に感染したことのある9歳以上の子どもにのみ推奨されています。
もう一つの典型的な例は、米国で行われた呼吸器合胞体ウイルス（RSV）の不活化ワクチンの臨床試験中にADEが発生したことです。1967年、臨床試験に参加してワクチンを接種した子どもたちが、その後、社会でウイルスに遭遇した際に、より重篤なRSV疾患を発症しました。2人の幼児が死亡しました。このワクチンは、肺閉塞や呼吸器疾患を引き起こす免疫複合体形成と関連しており、RSVワクチンの開発はかなり停滞しました。
同様に、1960年代に米国で開発されていた不活化麻疹ワクチンでもADEの事例が発生しました。ワクチンを接種した子どもが重症化したため、ワクチンは中止されました。現在、米国で使用されている弱毒化した麻疹生ワクチンでは、ADEは発生していません。
科学者たちは、COVID-19ワクチンではADEはほとんど問題にならないと言っていますが、これは何を根拠にしているのでしょうか？
COVID-19ワクチン開発の初期段階から、科学者たちはADEを引き起こす可能性が最も低いSARS-CoV-2のタンパク質をターゲットにすることを目指していた。例えば、SARS-CoV-2の核タンパク質を標的にすると、ADEを引き起こす可能性があることがわかったとき、彼らはすぐにそのアプローチをやめた。最も安全な方法はスパイクタンパクのS2サブユニットを標的とすることであると考え、それを実行したと、Derek Lowe博士はScience Translational Medicineのブログ「In the Pipeline」で書いています。
科学者たちは、ADEを探すために動物実験を計画しました。そして、緊急使用許可を得たCOVID-19ワクチンの実世界でのデータでもADEを探しています。今のところ、その兆候は見られません。実際には、その逆のことが起こっているとLowe氏は指摘しています。
「疑いの余地がないと思われるのは、ワクチンを接種した被験者からは重篤なコロナウイルス感染者が出ず、入院もしていないということです。これは、ADEが起こっている場合に予期されることとは正反対の現象です」と彼は書いている。
さらに、ADEは緊急の問題であり、非常に劇的なものになります。トロントにあるマクマスター大学の病理学・分子医学の准教授であるブライアン・リヒティ博士は、「もしこれらのワクチンに問題があるとしたら、今頃は発見されているでしょう」。
「（ADEが発生したら）すぐに死んでしまいますよ。私が知っているADEは、すべてのケースで、それは急性で、ほとんどがサイトカインに起因する事象です」と彼はMedPageTodayに語っています。
唯一の例外は、中国で開発された不活性化された全細胞ワクチン、つまり「殺した」ワクチンかもしれません。このワクチンには、1960年代にADEの原因となった麻疹ワクチンやRSVワクチンに使用されたのと同じアジュバントであるミョウバンが使用されています。ブルーム氏によると、中国の不活化全細胞ワクチンは、これらの古いワクチンと同様にADEを引き起こす可能性が「考えられる」とのことです。
「このワクチンが米国で日の目を見ることはないでしょうし、言及する価値もないかもしれません。中国製の全球殺虫ワクチンで実際にADEが発生した例はありませんし、あったとしても報告されていません」と述べています。
現在のCOVID-19ワクチンは、世界的に流行したSARS-CoV-2の原型を防ぐために開発されたものである。亜種（変異株）が増えるにつれ、科学者たちは、これらの亜種の1つがADEを引き起こすほどの違いを持つようになるのではないかという疑問を提起してきた。Lichty氏によると、今のところ、この懸念は仮説に過ぎないようです。
「これまでのところ、COVID-19ワクチンでADEが発生したという証拠はありません。すべて理論的なものです」と述べています。「これまでのところ、ADEは既存のワクチンやウイルスの変異体では問題にならないという証拠があると思います」。
その理由の1つは、SARS-CoV-2が、ADEを引き起こすような形でマクロファージに影響を与えていないだけかもしれないが、科学者たちはまだ詳細を調べているところである。ADEは、HIV、エボラ出血熱、コクサッキーウイルス、SARSやMERSなどのコロナウイルスなど、他のウイルスに自然感染した場合にも報告されている。
「今回のパンデミックを通じて、科学者たちはSARS-CoV-2に関連するADEを探してきましたが、これまでのところ、その事例は見つかっていません」、とLichty氏は指摘します。
「このコロナウイルスは、すでに人間に十分に適応しているので、中和しない抗体との相互作用でマクロファージに侵入したとしても、マクロファージが明らかな病態を引き起こすのに十分なサイトカインを産生できないのかもしれません」と述べています。
mRNAワクチンやアデノウイルス・ベクター・ワクチンは比較的新しいワクチンであるため、躊躇してしまうかもしれませんが、ブルーム氏によれば、これらのワクチンは、ADEの観点から見ると、古いタイプのワクチンよりも安全性プロファイルが優れています。
「肝心なのは、新しい技術は新しいウイルスのパンデミックへの対応が早いだけでなく、より安全で、より明確に科学的に設計されているということです」と彼は言います。「Sタンパク質ワクチンは、よりクリーンで、より慎重に定義されており、より低リスクです。Sタンパク質ワクチンは、よりクリーンで、より慎重に定義されています。そのため、ADEの可能性は、以前のウイルスワクチンの製造方法よりもはるかに低いのです」と述べています。
Veronica HackethalはMedPageTodayのEnterprise and Investigative journalismチームのレポートを担当しています。
