  |
はてなキーワード:管理ツールとは
GeminiDeep Researchで本当の話なのか調査させ、はてな匿名ダイアリーへ投稿出来るように要約させた
はてな匿名ダイアリーを指定したら口調が勝手に変わって吹いたｗ
2025年末、「娘のはじめてPCにLinux」という議論がネット上で波紋を呼んだ。これは単なるOSオタクの戯言ではない。 「エリート層は子供にRaspberry Pi（ラズベリーパイ）を与えて"支配側"へ育て、一般家庭や公教育はiPadを与えて"消費側"に留め置く」という、現代の身分制度（デジタル階級社会）への警告だ。
本稿は、英国王立協会やGIGAスクール構想の実態、労働市場データを分析した「公教育の機能不全と家庭内資源動員に関する調査報告書」の要約である。結論から言えば、「中流以下の家庭こそ、なけなしの金を払ってでも子供にLinuxを触らせろ」ということになる。
かつてのデジタルデバイドは「ネットに繋がるか否か」だった。スマホ普及後の現代における格差は、「コンピュータの制御権（Root権限）を持っているか否か」である。
英国王立協会はすでに2012年の段階で「学校のICT教育はオフィスソフトの使い方しか教えていない」と酷評している。 その結果、富裕層の私立校では専門家を雇ってRaspberry PiやAI活用を教え、貧困地域の公立校では管理が楽なiPadを配って終わり、という絶望的な「質の乖離」が起きている。米国でも同様に、富裕層の子供ほど「消費的なスクリーン（TikTokやYouTube）」から離れ、ChromeOSやRaspberry PiやUbuntuなどを導入し創造的なプログラミング教育を受けている。
日本の金のある自治体の公立小中学校で配られたiPadは、MDM（管理ツール）によってガチガチに制限されている。 逆に、ChromeOSはLinuxベースであり開発環境として優秀なのだが、教育委員会は「セキュリティ」と「管理コスト」を理由にその扉（ChromeOSやLinuxでの創造的な授業）を諦めた。 結果、公立校の生徒はiPadで「Web閲覧」と「ドリルアプリ」しかできない。
一方で、開成や筑駒といったエリート校の生徒は、制限のない環境でサーバーを構築し、Unityでゲームを作り、競技プログラミングに没頭している。iPadの 「サンドボックス（砂場）」の中で遊ばされている公立校生と、システムの内側に触れているエリート校生。このスタート地点の差は、10年後に致命的な「年収の差」となって現れる。
「社会に出ればWindowsだろ？」というのは20年前の常識だ。現代の高付加価値インフラ（AWS、Google Cloud、AI開発、IoT）は、ほぼ全てLinuxで動いている。
GUI（マウス操作）はAIにとってコストが高いが、CLI（コマンド操作）はAIへの命令（プロンプト）そのものであるため、相性が抜群に良い。Linuxを学ぶことは、「AI時代におけるコンピュータへの正しい命令作法」を学ぶことと同義だ。
「MOS(Microsoft Office Specialist)」というフィルター機能は低下し、GithubやPixiv、Youtubeなどでのクリエイティブな活動履歴（何を作れるか）がパスポートになる。貧困・中流層がこの壁を越える唯一の武器が「技術力（ポートフォリオ）」だ。
中流以下の公教育が頼りにならない以上、家庭で動くしかない。幸い、Linuxの世界は「金はかからないが、知恵と時間はかかる」。これは資金力のない家庭にとって最大の勝機だ。
30万円のMacBookは不要。企業落ちの中古ビジネスPC（ThinkPad X250/X260等）なら、秋葉原や通販で1.5万〜3万円で買える。Windows11が入らない型落ちこそ、軽量なLinuxには最高の機体だ。Raspberry Pi 4や400の中古も良い選択肢となる。
親が教えられないなら、CoderDojo（無料のプログラミング道場）のようなコミュニティに子供を連れて行けばいい。そこには「技術を楽しんでいる変な大人」がいる。その出会いが重要だ。
「壊れるから触るな」ではなく、「壊してもOSを入れ直せば直るから、好きにいじれ」と言って管理者権限（Sudo）を与えること。YouTubeを見る端末を、YouTubeを作る端末に変えること。
高価なiPadを買い与えて安心するのではなく、1万円の中古PCを与えて「黒い画面」に向かう子供を応援すること。 その小さな投資が、子供を「デジタル小作人」から救う唯一の手段になるかもしれない。
管理ツールで管理できるように論理的に計画しなきゃいけないのであって、適当行き当たりばったりで見た目だけ猿真似したデータを突っ込めば素晴らしい管理が実現できるわけじゃない。
どこぞのSIerから転職してきたPMが、「プロジェクトの8割は完了状態なので、オンスケです」とか言ってるのを聞いて仰天したことがある。
「どんな管理してんの？」
「8割完了って？」
「タスク数です」
ガント作ってるとは聞かされてなくて、管理者内でしか共有してないって言うから、見てみれば、確かにぱっと見、よく見る感じの情景が広がっていたのだが、
「このタスクとこのタスク、難易度天と地なんだけど、なんで人日同じなん？」
「詳しいこと読みきれないので、仮置きです」
「このタスク、これが完成しないと進められないんだけど、どうして平行してんの？」
「依存関係が、これを作ったときわからなかったので。依存関係があったとしても、影響しない部分は実装できるでしょう？」
「このタスク、外部とのにぎりが必要なんだけど、調整タスクとかは？」
「いるんですか？」
「タスクとして書き入れないとしても、前提条件だからそう言う条件があることの明記は必要だし、状態や見込みの管理は必須だろ？」
ってな感じで、簡単なタスクを8割、先にこなして、別部署との調整、技術的決定等々、管理ツールに書き込まれてない要素で週明けからラインが軒並み空き状態になるのにオンスケとか……。
OJTで雰囲気でやってきたから、肝腎要の部分はこれっぽっちも知らんのだな……。
「プロジェクトって、後になればなるほど進度が遅くなるもんですから」
いや違う。
いっぱしぶった口振りしても、口だけで中身がねぇ。
「そこはアジャイルで……」
コアな不動部分をドメイン分析で明らかにして、そこは確定するのがアジャイルだ。
それをしないから、アジャイルはいい加減で行き当たりばったりだ、ってクソ評価下されるんだ。
クソ評価を下されるべきはPM たちであって、アジャイルという手法じゃねぇってのに。
そもそも部分像の把握ですら怪しい。
こんなんでよく給料もらってるな。
マジかよ。
「今最先端の生成AIを導入して、遅れを一気に取り戻します！」
うん。
中堅以上のエンジニアからはアラートが上がっていたんだが、マネージャクラスは誰も理解できないどころか、反対しかしない消極的な人間とか悪しざまに罵り、圧力をかけてきやがった。
その後どうなったか？
知らん w
SBI証券の新ログイン方式は、単なる「不便」や「ユーザビリティの欠如」では片付けられない。ここには金融機関としての役割と責任を根本的に誤解した設計思想がある。
長年かけて「メールURLは踏むな」「急かすな」という啓蒙が積み上げられてきた。その基本を金融機関が真っ向から裏切る行為は、個別の不便以上に社会的なダメージが大きい。詐欺対策の文化資本を自ら崩している。これは一企業のミスではなく、セキュリティリテラシー全体を毀損する公共害だ。
40秒カウントダウンでURLを踏ませ、同意チェックをさせ、コード入力を急がせる。これはセキュリティ向上どころか「詐欺的UX」を制度化したものだ。人間心理を逆手に取る詐欺の手口を、大手が正規プロセスとして定着させれば、本物と偽物の区別は不可能になる。ユーザーは「考えるな、急げ」と刷り込まれる。
SBIは「パスキー導入までの一時的措置」と弁解するが、数カ月でもユーザー行動に影響するのは明白。セキュリティ体制の穴を埋める責任を「急ごしらえのUX実験」で代用している。この姿勢は「公共インフラの担い手」という金融機関の前提を忘れ、「ただのITサービス企業」感覚に堕している証拠だ。
指摘されている通り、真に必要なのは「URL目視確認」ではなく「パスワード管理ツールやパスキーの普及」である。人間の注意力や記憶力に依存する設計は限界であり、技術的解決が既に存在するのに、それを啓蒙せず逆行するUXを押し付けるのは怠慢としか言いようがない。
結論を言えば、SBIの新ログイン方式は「セキュリティ対策を装ったリスク増幅装置」だ。利用者は混乱し、詐欺師は笑う。セキュリティは利便性とのトレードオフだとよく言われるが、今回の方式は利便性を捨て、セキュリティも削るという最悪の選択になっている。
撤退以外に選択肢はない。今すぐ旧方式に戻すべきだし、その上でパスワード管理ツールやパスキーの導入こそを大々的に推進すべきである。
SBI証券は数日前にログイン方法（端末認証手順）を変更しましたが、とてもひどいものでした。
新しいSBI証券のwebサイトでID/パスワードを入力してログインボタンを押すと、突然40秒のカウントダウンタイマーと毎秒短くなっていく進捗バーが表示され、タイムアタックが開始されます。制限時間内に受信メールにかかれているURLをクリックし、難しい確認同意をした上で、確認コードの入力をして２回ボタンを押す事が強要されます。
新しい端末での初回ログインでは、必ずこの複雑な端末認証が必要となりました。
端末認証方法の詳細は後半に記載します。正しい制限時間は40秒x5回となりますが、40秒と誤認する方が多いと思います。またメール受信にかかる時間を考慮すると数分では全く足りないでしょう。
この端末認証方法では、してはダメとされている事を２つもユーザーに強要しています。SBI証券は急いでこの方法を中止して元に戻してください。対応が遅くなればなるほど、多くのユーザに誤った知識を学ばせる事になります。
１つは、「メールのURLをクリックしてはだめ。もしもクリックしても、その先の画面で重要情報の入力をするのは絶対だめ」なのにメール内URLをクリックさせて認証コードを入力させる行為。
もう１つは、「急かしてくるような行為は詐欺が多いので、ゆっくり考えて判断しましょう」が一般常識なのに、ユーザーをカウントタイマーで急かしながら複雑な操作を要求する行為。
この２つはフィッシングや詐欺被害を減らすために、様々な方たちが努力してユーザに啓蒙してきた事です。そのおかげで詐欺の件数もある程度抑えられていたと想定できます。なのにSBI証券のような大手金融機関が率先してルール違反を強要するのはありえません。せっかくのこれまでの努力が水の泡です。
セキュリティの啓蒙活動のおかげで意識が高まって詐欺を防げていた事例ってたくさんあると思います。例えば、30分以内に申し込まないといけない高額投資案件ってちょっと変だからやめておこうとか。クレジットカードの期限切れ警告メールは気になるけど、メールのURLではなくクレジットカード会社のトップページからアクセスして確認しようとか。
今後は、「証券会社でもカウントダウンタイマーに急かされながらURLクリックさせられたし、この奇妙なWEB申込み画面も問題なさそう」と油断して騙されるユーザーが出てきてもおかしくありません。
SBI証券としては、パスキーなどを導入するまでの一時的なつなぎのつもりらしいですが、数カ月間だとしても大手金融機関が不適切な手法を強要する悪影響は計り知れません。自社の影響力をもっと考えてください。
自社の利益を追求するのも結構ですが、それは公共の利益が損なわれない範囲でお願いします。
今回ユーザーから批判が出たためSBI証券ではカウントダウンタイマーを40秒から60秒に延長する改善をしたようですが、本質的な問題は解決していません。
緊急で端末認証方法を以前の方法に戻して、その上で今後の方針を再検討してください。今回の方法以外に許容できる選択肢がなかったのか甚だ疑問です。
---------------------------------------------
これは端末を事前登録してセキュリティを高めるためのシステムで、この事自体は全く問題ありません。
40,39,38,37という数字のカウントダウンと共に、横長の進捗バーがどんどん短くなっていき、あせらされます。
届いたメールを見ると長いURLが書かれていてそれをクリックして開くことを求められます。
ちなみに、SBI証券からは、以前にール内のURLをクリックしてIDやパスワードを入力してはいけないと通知が来ていました。
でもクリックしてみるしかありません。カウントダウンが継続していて急がされているので、ユーザーにはゆっくり考えている暇は与えられません。
URLをクリックした画面には「ユーザーネームやログインパスワードを入力したログイン画面は、メールやSMSなどから開いていませんか？」という赤字の画面が出ます。
そこで「ログイン画面はメールやSMSからは開いていません」を選択すると、認証コードを入力できるようになります。
カウントダウンが進んでいるので焦りながら、最初のパスワードを入力した画面はブックマークから開いていて、今は確認コードを入力する画面なので違うよなと判断する必要があります。
そして、このメールから開いた画面に確認コードを入力する必要があります。
メールの送信から、この確認コード入力完了までが40秒です。メール受信ラグまで考えると運が良くないと40秒では無理です。
多くの場合、一度は確認コードが時間切れとなり、新しく発行されたコードを入力してやっと認証ボタンを押すこととなります。認証ボタンを無事押せてとなるでしょう。
最初のログイン画面で「認証コードを入力し、認証が完了したことを確認しました。」にチェックを入れて「デバイスを登録する」ボタンを押して完了です。
ここまでに160秒以内に完了できなければ最初からやりなおしです。
（認証コード5回まで表示可能なので40秒x5回で200秒の猶予しかありません）
批判が出た事もあってか、8月15日に制限時間が40秒から60秒に延長されました。全体猶予はその5回分で200秒から300秒に延びました。
メール受信の時間や様々な操作を含めて、この制限時間です。5分では間に合わない事も多々あるんじゃないかなと想定されます。
---------
最後に、フィッシングへの対応について個人的な意見を1つだけ書かせてください
サイトが正しい事をユーザーの目視で確認しましょうってなっていますが、現実的に無理です。正しいURLもややこしくて、SBI銀行がnetbk.co.jpで、ゆうちょがjapanpost.jpなどなど、そんなの面倒で覚えていられません。URLを目視で正確に判定するのは不可能です。似たようなドメインにユーザーが騙されるのは仕方ないと思います、
ドメイン確認を自動でしてくれて、パスワードを安全に管理して自動入力してくれるパスワード管理ツールなしで日々安全にサイトを利用するのは不可能だと思います。
それなのに、金融機関もマスコミもパスワード管理ツールの案内を全くしないのが不思議です。
下記のような条件を満たしたパスワード管理ツールをみんなが使うべきだと思います。現実的には無料ならbitwarden有料なら1passwordが第一選択になります。
Permalink |記事への反応(14) | 15:56
2025年向けのWindows関連アプリケーションは、主にWindows Server 2025やWindows11の最新アップデートにおいて、多くの新機能や改善点が追加されています。
Windows Server 2025は2024年に発表され、セキュリティの強化、クラウドやハイブリッド環境との統合、パフォーマンス向上が特徴です。新しいホットパッチ機能によりシステムの無停止アップデートが可能になり、次世代のActive DirectoryやSMB共有の刷新も行われています。さらに、AIワークロードのサポート拡充、仮想マシン性能向上なども含まれます。管理ツールが刷新され、リアルタイムのシステム状態を可視化可能なダッシュボードや高度なオートメーションによる運用効率化が実現されています。また、最新APIやSDK、コンテナ技術との連携強化により、高性能でスケーラブルなアプリケーション開発が支援されます。
https://ja.taiwebs.com/windows/download-adobe-photoshop-01ja-737.html
個別のWindows用アプリケーションについては、Microsoft 365 Copilotのスマホ版展開や新機能追加もあり、生産性アプリやエンタープライズ検索、AIチャットなどを統合したユーザー体験が強化されています。
全体的に、2025年のWindowsプラットフォーム向けアプリケーションはAIとの連携強化、クラウドベースでの管理と運用の効率化、セキュリティの高度化が大きなトレンドであり、エンドユーザーから開発者まで幅広い利便性と機能向上が期待されています。
まぁ実際Googleのアカウント管理は厄介ですよ。個人的にはとっととマイナンバーカードで認証できるようにして欲しい
…と、言っていてもしょうがないし、
Googleからしたら、アカウント乗っ取りから利用者を守る必要があるわけで
未登録の情報でリカバリできるとしたら、それは他人がアカウント乗っ取れることとほぼ同義ですから
銀行口座のように事前の本人確認をちゃんとしてるわけでもないし
自分で自分の情報を登録して自分で最新化していくしかないんですよ。自衛のために
本当にリカバリしたい利用者だって星の数ほどいるわけで、個々のリクエストに人間が対応するわけにもいかない
とはいえ、たかがアカウント管理にそんなにコストもかけてられないし
Googleが完璧な案内をしてくれれば…と理想論をいったところで、期待できません
大本の増田にも書いてありますが、紙に印刷して安全な場所に保存しておくのが結局一番コスパがよさそうだというのが現状の私の考え方です
パスキー等は印刷できませんから、パスワードとバックアップコードが対象です(2FAを有効化していなければパスワードだけ)
これでリカバリ(というか普通にログイン)できるので、パスキーはいくら失っても構いません。再発行すればよいだけです
パスキーが使いにくいと感じる人が多くいるのは否定しませんが、フィッシング対策としてはかなりの効果が期待できます。使い勝手との兼ね合いでご自由に
なお、リカバリ用の連絡先は、電話もメアドも気付かないうちに使えなくなる可能性があるのでそこまで信用できません(と、あなたには言うまでもありませんね)
無論、全てのアカウントをそうする必要などありません(そんなことできません)
Google、Apple、MS、1Passwordなどの『PW管理ツール自体のパスワード』あたりの絶対に失いたくないアカウントだけは少し手間がかかることを受け入れざるを得ないでしょう。急がば回れ、転ばぬ先の杖です
(理屈で言えば『PW管理ツール自体のパスワード』だけがそうなっていれば事足りるのですが、リスクヘッジしておいたほうがいいでしょう)
余談ですが、
私はGoogleやMSの締め出されたくないアカウントには認証方法(≒本人確認手段)を10以上設定しています
いま確認したら、Googleのパスキーは7つもありました(Android端末数台、PC数台、iCloudキーチェーン、…etc)
もちろん、これは万人にお勧めできるやり方ではありません
タイトルがヘタすぎました。すみません。垢BANについては書いてないです(それは自分も知りたい)
改めてタイトルつけるなら 【2段階認証を安全に運用する方法(Google版)】 とかかなぁ
ちょっと勘違いしている人がちらほらいる(トラバ参照)ので追記しておきます
↑ということです
パスキーは『不正ログインのリスク』への対策の意味が大きいです
一部の人が感じている『パスキーを有効化すると詰みそう』というのは、少なくともGoogleには当てはまらないと思ってます(認証方法が*追加*されるだけだから)
2段階認証の認証方法を適切に管理するのが難しいなら、(『不正ログインのリスク』とのトレードオフを認識した上で)『2段階認証をOffにする』べきであり、パスキーとは直接的には関係ないです
2段階認証の設定を最新化できていないとか、電話番号だけにしているとかだと、パスキーを使っていなくても詰みます
自分が書き始めたきっかけがパスキーの話題だったので、わかりにくくて申し訳ない
できるだけ楽に以下のリスクからGoogleアカウントを守る方法を考えてみたよ
最低限、以下があればいい
| アカウント名 | 忘れないようにしましょう |
| パスワード | セキュアに生成し絶対に使い回さない。安全な場所に保管しておく(PW管理ツールを使う) |
| 2段階認証 | 有効化しておく |
| バックアップコード | 2段階認証を設定すると生成できる。安全な場所に保管しておく |
| パスキー | 普段使うデバイスで使えるようにしておく(複数登録できる) |
Googleのアカウント管理がやっかいなのは、Gmailやパスキーを使うのに必要となること
Googleにログインできなくなると、Googleに保存していたGmailもパスキーも使えなくなってしまう
なので、Googleだけは多少手間をかけてでも、リカバリ手段を確立しておく必要がある
その他の一般的なサービスは、登録したメアドさえ生きてればまぁなんとかなるでしょ(それはそれでどうかと思うけど)
いずれにせよ、どんな認証手段であれリカバリ手段はちゃんと確保しておきましょう
例えば、朝一で仕事を振って午後に状況確認すると、序盤で詰まってて作業自体一切進んでないみたいな人。
詰まったら連絡してと事前に言っていても連絡してくれない。
問題を共有しない人に対しては、タスクを割り当てる際に曖昧さを排除し、具体的な指示を出すことが重要です。
タスクと期限の明確化: 「これをやって」とだけ伝えるのではなく、具体的なタスク内容と期限を明示します。
例: 「このタスクは午前中に終わらせて、午後1時に進捗を報告してください。」
報告のタイミングを指定:自発的な報告を待つのではなく、報告のタイミングを事前に決めてしまいます。
これにより、相手が自分で判断する負担を減らし、報告が習慣化しやすくなります。
相手が自ら連絡しない場合、こちらから進捗を確認する仕組みを入れるのが効果的です。
短い間隔での確認:タスクを振った後、1時間ごとや作業の節目ごとに進捗をチェックします。これで問題を早期発見できます。
例: 「10時に進捗を教えてください」と事前に伝える。
自然な声かけ:確認を負担に感じさせないよう、「順調に進んでる？」「何か困ってることある？」と軽いトーンで聞くとよいでしょう。
問題が発覚した際の対応を通じて、報告の重要性を伝え、行動を改善してもらいます。
具体的な指摘: 責めるのではなく、次にどうしてほしいかを明確に伝えます。
例: 「午後に確認したら作業が進んでなかったね。次からは詰まった時点で連絡してほしいな。」
ポジティブな強化: もし報告があった場合は、その行動を褒めて習慣化を促します。
例: 「早めに連絡してくれて助かったよ。これで対応が早くなった。」
詰まったときに連絡しづらいと感じている可能性があるため、サポートを身近に感じられる環境を作ります。
連絡先やリソースの提供: 誰に聞けばいいか、どうすれば解決できるかを事前に伝えます。
例: 「何か問題があればすぐに私に連絡してね。あるいは、このマニュアルを見てみて。」
オープンな雰囲気作り:問題を報告することへの心理的ハードルを下げます。
例: 「困ったことがあったら遠慮なく言ってね。問題を共有するのはチームのためだから。」
自発性が低い場合、タスク管理のスキルが不足している可能性があります。
タスク管理ツールの活用:ToDoリストやアプリ（例: Trello）の使用を提案します。
例: 「タスクをリストにして進捗を見えるようにするとやりやすいよ。」
細分化のアドバイス: 大きなタスクを小さなステップに分け、それぞれに期限を設定するよう促します。
長期的な改善を目指すなら、スキルを伸ばすサポートも有効です。
ワークショップの提案:タスク管理や問題解決のトレーニングを用意します。
例: 「タスク管理のワークショップがあるから参加してみて。」
メンターの設定:相談しやすい先輩やメンターをつけるのも一案です。
まとめ
このような状況では、期待を明確に伝えること、定期的にこちらから確認すること、具体的なフィードバックで報告の重要性を認識させること、そしてサポート体制を整えることが鍵です。さらに、相手の自己管理能力を高めるサポートをすることで、自発的に動けるようになる可能性が上がります。まずは小さなステップから始め、徐々に習慣化させていくのが現実的です。例えば、「今日のタスクは10時と12時に進捗を教えてね」と具体的に伝え、こちらからもフォローしてみてください。これで作業の停滞が減り、コミュニケーションも改善していくはずです。
いいから何かプレイヤー数の多い運営型ゲームを手当たり次第やってみればいい
ゲームとしてのクオリティ重視ならHoYoverse系は鉄板だな
PSストアでもいつも上位にいるしキャラ予告のたびにトレンドにも入る
その中で閲覧されやすい話題で作品にポジティブな言及をするか関連の写真や動画などを上げれば
好印象を持ってくれて勝手に♡とかつけてくれるXユーザーがいるだろう
例えば原神なら#原神写真部みたいなタグとかだな、まーここはすごい人ばかりなので敷居は高いが
エンドコンテンツの無課金プレイヤー向け攻略だとか、イベントミニゲームのスーパープレイだとか
公式PV動画の見逃しやすい考察ポイントだとか、切り口は無数にある
自分が主張したいことを言うんじゃなく、自分の発信で他人に楽しんでもらうことを考えろ
物議を醸すようなことには一切口を出すな
Xは各種コンテンツの公式アカウントや作品投下してくれるクリエイターみたいな、純粋に餌を投下してくれるアカウントだけをフォローして
というか一般人ならそういう使い方に徹したほうがいいはずだ
楽しませるための投稿をしないのなら、ライフログというか趣味関係の活動ログみたいなものとしてたまに知見を共有するくらいでいい
俺も10年以上前、経済や思想やテクノロジーニュース系のことにイッチョ噛みするアカウントを持っていた頃は、ゴミみたいなアカウントと相互を結び続けるスパム互助みたいなフォロワー管理ツールを使うことで、フォロワー数なんていくらでも稼げることに気づいた
あれは何年前の事だっただろう。
はるか昔の事のようにも思えるし、つい昨日の出来事だったようにも思える。
当時、俺はとあるIPを原作としたオンラインゲームの開発と運営に携わっていた。
幸い、バージョン管理ツールとオンラインドキュメントツール、それとSlackのおかげで、
俺はただの作業員からプロジェクトマネージャーへ役職が変わった。
運営中のある時、ゲームの原作であるIPの映画が金曜ロードショーで放送される事になった。
1週目と2週目は問題なく、普通にただのIPファンとして酒を飲みながら金ローを楽しく観ていた。
3週目も勤怠を切り、酒を飲みながらそれまでと同じように金ローを観ていた。
酒が随分まわってきて、映画も面白くなるタイミングに差し掛かっていた。
そんな時に事件は起きた。
そんな感じのメッセージだった。
SNS担当者には緊急メンテの告知の依頼、文面の確認、それらを酔っ払った状態でやっていた。
サーバーチームから作業完了の報告を受け、QAを通して問題なければメンテを開ける旨をチームに周知した。
ずっとSlackでメンションを飛ばし続けているが、スタンプすら反応はなし。
何度も何度もかけまくった。
そりゃそうだ、今日は金曜の夜だ。
仕方なくサーバーチームと協力し、一通りの動作確認を終えると、メンテを開けた。
その後しばらく状況を監視し、結局金ロー鑑賞どころではなかった。
その晩の事だけではない。
何か問題が起きていないか？誰かがメッセージを送って来ないか？
日曜の夜突然上司から重要なメッセージが来ることも度々あった。
怯えていた。明らかに今思えば当時の俺はいつどのタイミングで来るかわからないSlackに怯えていた。
…そうやって怯え続ける日はあっという間に終わった。
サービス終了と共に契約を終了した当時のインフラリーダーと久しぶりに飲む機会があった。
あの時俺は酔っ払っていた、支離滅裂な内容の文章を送っていたかもしれない、
的確な判断と行動が出来ていなかった、それなのに事態を収束させてくれた事に今でも心から感謝している、と。
「え、俺さん酔ってたんですか？全然気づかなかったですよ。」
…まあいい、まあなんでもいいだろう。
さて、サービス終了後、俺は燃え尽き症候群を回避する為に2週間くらいまとめて有給を取得した。
既に別プロジェクトに配属されていたが、今なら取得しても問題ないと思ったタイミングだったから取得した。
そこでゆったりと時間を過ごせば燃え尽き症候群は回避出来るはずだと俺は思っていた。
俺宛のメッセージではない。
開発からサ終まで約4〜5年、早朝も夜間も休日も全て注ぎ込んでいたプロジェクトが終った後に取得したたった2週間の休暇。
それさえも許されなかったのか。
俺の知らない所で、俺になんの相談もなく。
メンタルクリニックで処方された薬が原因なのか、単に疲れていただけなのか、
毎日が眠くてずっと居眠りをしていた。
重要な会議中でも、重要な取引先との会議中でも、俺はずっと寝ていた。
追い出し部屋と言っても、その頃仕事がなかった俺の追い出し部屋は自宅の6畳一間のマンションの部屋だった。
ある日俺は何を思ったのか、いや、何も思えなかったからなのか、
眠気を回避する為に飲まずに貯めていた処方薬を酒と共に大量に飲んだ。
身体が全く動かず、救急車を呼びたくてiPhoneを操作したが119が打てなかった。
意識も朦朧としていたので、救急車の番号が119なのかさえよく、わからなかった。
なぜか声も出なかった。喋りたいのに喋ることが出来なかった。
到着までの間ずっと俺に話しかけて来たが、あれは意識を保たせる為だったのだろう。
部屋の鍵を誰がどうやって開けたのかわからないが、
意識が戻りSlackを確認すると、その日は東京ゲームショウの日だった。
俺は自社ブースの案内スタッフとして早朝から幕張メッセに行かなければならなかった。
Slackには「俺さん今どこですか？」というSlackが届いていた。
俺は「事故に遭い病院に居ます、TGSには参加出来ません」とだけ返信した。
そんな感じで、もう潮時だったのか、会社からの退職勧奨に応じ俺は無職になった。
先日、前職を退職済みの元同僚と久しぶりに会う機会があった。
なぜかその日はお茶を飲みながら話をした。
彼女も同じような事を言っていた。
「退勤した後も、退職した後も、ずっとチャットツールばかり気になっちゃうんですよね。」
と。
アルコールやドラッグのような、一時的な快楽を求めるものによる依存症じゃない。
そうだ。
一命を取り留めた直後に、一番最初に取った行動が「Slackを見る」
だったんだよ。
本当は、もっと他にやるべき事があったんじゃないのか？
人間として…
さて、昨今ではコロナも落ち着いたのか、職場回帰が進んでいると聞く。
そういった時間をビジネスチャットツールに割いている人はどのくらいいるのか。
24時間365日運営しているゲーム、アプリ、システム、サービス、それらの類の担当者は大勢いるが、
彼ら彼女らは「ビジネスチャットツール依存」状態になっていないのか？
今なっていないとしても、この先罹患しないと言えるのか？言い切れるのか？
もし、これを読んでくれた人の中で、ビジネスチャットツールを常用している人が居たら、
どうか俺のようにならないで欲しい。
しかし依存症として定義も認識もされていない上に医学的根拠も何もないこの「依存症のようなもの」
わからないんだ。
申し訳ない。
だがどうしても俺のような末路には行き着いて欲しくない。
もし偉い人、精神科医、そういう立場の人がこれを読んでくれたのであれば、
今から防止策を考えてくれないだろうか。
どうしても俺のような廃人を増やしたく無いんだ。
うちはなんでもオープンにすんで
例えば業務日報。マークダウンで毎日書かせて、GitHubでオープンにすんで
例えば社内風景。音声付きカメラで社内中を監視して、リアルタイムで全世界にオープンにすんで
例えば会議の内容。全ての会議を録画して、Youtubeでオープンにすんで
例えばプロジェクトの進捗。タスク管理ツールを使って、誰でもアクセスできるようにオープンにすんで
例えば社員のアイデア。アイデアボックスを設置して、全人類が自由に提案できるようにオープンにすんで
例えばフィードバック。定期的にアンケートを実施し、その結果を全世界に公開してオープンにすんで
最近のフロントエンド開発界隈で持て囃されるReact.jsだが、正直言って、その過剰な複雑さと必要以上に手間ばかり増やす構造には嫌気が差す。ごくシンプルなタスク――たとえばAPIからデータをfetchして表示する程度のことが、なぜこれほどまでに意味不明なコンポーネントや状態管理ツール、無駄なベストプラクティスの学習コストにつながるのか？
jQueryなら数行で済むところを、Reactでは「Hooksがどうの、カスタムフックがどうの、Routerはどれ使うか、ReduxかRecoilかZustandか」と、次々に沼へ引きずり込む。現場のエンジニアが「これは本当に生産的なのか？」と疑問を抱くのも当然だろう。Reactの複雑さを「モダンなフロントエンド開発の必然」などと擁護する声もあるが、実際は一部のフロントエンドオタクが自己満足に浸るための余興でしかない場合も多い。
本来、フロントエンドは「エンドユーザーにとって使いやすいUIを短期間で組み上げる」ことが重要なはずだ。しかしReact導入後は、下手をすると新人エンジニアがReact＋周辺ライブラリの難解な世界に消耗し、基本的な機能実装に時間を奪われる。挙句の果てに、保守運用でも「なぜこんな遠回りな実装を？」と後悔したくなるコードが山のように残る。
一部の巨大プロジェクトや複雑な状態管理が要求されるケースではReactの恩恵もあるだろう。しかし、その「本当にReactが必要な場面」以外で、このツールキットを無批判に使い続けることは、多くの場合オーバーエンジニアリングの極みだ。Reactを「絶対正義」のように祭り上げる風潮こそ、現実的な業務効率を蔑ろにした妄信に他ならない。
React信者たちが喜々として新しい手法を生み出し、複雑さを自己正当化する姿は、もはやエンジニアリングではなく一種の祭りに近い。合理的な判断を放棄し、ツールに踊らされる人々が多い限り、Reactの過剰な複雑さと生産性の低下は続くだろう。もう少しシンプルに物事を進められないのか？ React中心主義に染まった業界は、その問いに真摯に向き合うべきだ。
10月から現場チームにIT側が参加してプロジェクト進めることになり、私に白羽の矢がぶっささった。
以前からプロジェクトを進めていたと聞いていたけど、実際参加してみるとExcelレベルでもタスク管理が無いし、デイリーで各メンバー適当な進捗報告をするだけ・・・。
私としてはくっそ楽な作業で特に管理せずともうまく行っているので問題ないけど、メンバーの中にはちらほら遅延（そもそもタスク列挙に伴うスケジュールを引いてないのだから遅延もクソもない）して苦しんでいる人もでてきたし、そこもカバーしてあげたい。
2ヶ月経ってある程度チームについて分かってきたし、「どんどんやってくれ」とも言われているものだから、適当にプロジェクト管理ツールを見繕って導入提案さくっとしてみた。
いやいやいやいや元々プロジェクト管理もずさんな状態で何も管理なんてわかってないんだからさ！！！！！！
とりあえず管理ツール内のフレームワークに押し込めればいいでしょ！！！！！！！
理由なんてツラツラと語らなくてもこんなツール脳死で使って当たり前でしょ！！！！！
チーム人数少ないし予算も余ってるんだからもう何も考えずに速攻導入してくださいよ！！！！！！！！
という怒りを胸に資料をシコシコ作っている。
