  |
はてなキーワード:成果物とは
具体的にどう救うべきかが本人たちにもイメージできていない。要は具体的にどうしてほしいのか、というのが誰にもわからない。
そりゃ氷河期世代全員に100億円配布すれば解決なのだろうが、それは実現不能だ。実現可能ラインでどう具体的に救済すればいいのか。誰にもイメージできていない。
何が欲しいのかわからない人間たちにどう与えるのか、という話であり、それは構造を考えなければならない。
でも今なお、「支援」「再教育」「雇用拡大」なんて言葉が、彼らに向かって中途半端に投げつけられ続けている。
おかしいのは、彼らが本当に求めているものを、誰も真正面から拾ってこなかったことだ。
能力を発揮したい
他人に認められたい
それだけだ。生活保護がほしいんじゃない。
「かわいそうだね」じゃなくて、「すげえな」って言われたいだけだ。
ボランティア？ → 望んでないのにやらされても苦痛でしかない
「なんてノーバリューなんだ！」
下積みを積み続けた「柔軟性」
それを活かせる仕組みが社会側にないだけだ。
◆ じゃあ、制度をどうすればいいのか？
教育しなおすんじゃない。キャリアを一から積ませるんじゃない。
→「今の能力を即座に発揮できる場」と「成果に対する即金の報酬」をセットで用意しろ。
◆ 実際にありえる制度案（要約）
試験も履歴書もいらない実務評価採用（まず働いて成果を見てから登用）
クラウド公営プロジェクト型報酬制度（仕事ベースで成果物に報酬）
職歴の“再構成”を可能にするスキル証明システム（中立機関が評価）
国家レベルの成果表彰＋露出＋再チャレンジ支援（「やって良かった」と思える社会的フィードバック）
「自分で選んで動けること」
◆ 救済とは“許す”ことではなく、“再び価値を与える”こと
「もう一度ステージに上がっていいんだよ」と言えるかどうか。
かわいそうな人を助けるんじゃない。
◆最後に
“報われたい”んだ。
そしてそれがなされない限り、「なんてノーバリューなんだ！」という自嘲が、ずっとこの国を冷たく包み続けることになる。
全部読んだけど、めちゃくちゃどうでも良いなって思った
それで業務に支障をきたしているとかなら話はわかるが、成果物が問題なく出てるなら良いじゃんって思う
お前暇なのか？
俺はクリエイティブ界隈で働いてないので、立場としては完全に外野なんだが、掲題の疑問が浮かんで消えないんだよね。
AIなんか存在しなかった間に人類がコツコツ積み上げてきたコンテンツを異常な速度で学習用データとして食い尽くしつつある現状で「クリエイターの成果物を学習データとして使うのに碌な対価を払わない」という姿勢を貫いているわけだけど、それって将来の自分達に必要な畑を自ら破壊してるようなもんだって分かってないのかな？
近視眼的というか、そんな先の話より目先の食い扶持だ、って感じに見えるんだよな。目先の食い扶持を何とか確保したところでその先に待つのは自滅しかないと思うんだがなぁ。
まぁ、AIが持続可能かどうかなんて俺の残り少ない人生には大した影響ないから面白い見せ物って感じではあるが、影響受ける人たちは大変だね。
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
会社のOffice 365にCopilotが導入されて、俺の仕事は爆速化した。今まで半日かかっていた資料作成がものの数十分で終わる。情報漏洩の心配もないから、安心してAIに頼りきりだ。
最初は「最高かよ！」と喜んでいたが、ふと気づいてしまった。このスピードで仕事を終えて、すぐに上司に提出していいものだろうか。
「あいつ、AI使って楽してるな」と評価が下がるのも嫌だし、逆に「こいつは仕事が速い」と認められて、今の3倍くらいの業務量を振られるのも困る。
上司がAIにどのくらい理解があるのか全くわからない。みんな、AIで効率化したあと、どのくらいのさじ加減で成果物を提出してるんだろうか。なんだか、無駄な待ち時間が増えた気がする。
狂ったというか脳の病気だと思う
ある団体に命を狙われている、殺されるってpostしてる
彼の事は今までネットでしか見てなかったんだけどオフ会で会う機会があって話してみたらとても素敵な人で、しばらくときめいていた
自分は既婚だから、どうなるもんでもなく「ファン」という形に落ち着いた
Vtuberとか配信者ではないので成果物を購入するくらいなんだけど
彼はあまりXにいるわけではないけど、作ったもののpostを見て見守ってた
リプライはしないしされない
見てるだけ
そんな彼が突然不穏なpostをしだした
狙われてる、殺される、攻撃を受けている、みたいな感じ
異様だけど思いあたる節はある
これって統合失調症だよね？？
本人曰く精神病ではないらしい
悪化しないといいのだけど
こうなってしまったらどうすれば治るんだろう？
もちろんDMなんかは送らないし見守るだけだけど
なんだか心がザワザワする
自分は大卒で31歳の課長代理（実質課長ポジション）の女なんだけど、専門職なんですね、デザイン系の。
ただ会社はうちのチームだけややあって未経験可にしてて…だからか業界用語を知らないどころかソフトの勉強すらしてない、絵を授業以外で描いたことすらない人が「興味があったので」と応募してくるわけ。
で、うちの部長がそれを採用しちゃうんだけど、未経験・未勉強かつ定時出勤・退勤で「与えられた仕事」しかしないから本当に成長しないんだよ。
面接で「お絵描きソフトをプライベートでも使っています」（なおポートフォリオは無し）と言っておきながら入社後に「Windows標準搭載のペイントで数時間遊んだことがある」程度のものだと判明したり、「レイヤー」「トンボ」「RGB／CMYK」が何かすらわかってないのね。
自分は未就学児の頃から絵を描いてたし、中高美術部だったし、大学でも美術系サークルに2つ入ってたし、社会人になってからもプライベートで漫画を描いてたりするからそこらへんの知識はありながらポートフォリオも提出して中途入社したんだけど、部長が「増田さんレベルの未経験の人なかなか来ないね」とか言ってくる。そりゃ未経験可にしてるんだからそうなりますって。
あと自分は業界未経験で美大やデザイン学科を出たわけでもないから、入社後は3ヶ月くらいデザインとか広告とかの教本を読んだり、先輩たちの成果物を見て勉強したりしたんだよね。
でもそれってギリ平成時代の話で、令和のこの時代に「専門職に未経験で入ったんだから、与えられた仕事以外にも勉強して」って言っちゃうのはパワハラになるかな～と思って言ってない。
今も業界ニュースやプレスリリース情報を週1で検索してるけど、そんなことをしてる人は同じチームの中で1割いるかいないか。
未経験ばかりだから「別にできなくても部長や増田さんに聞けばいいや」っていう空気がはびこってる。怒らずにこやかに「聞く前に自分で調べましたか？」「どう思いますか？」って聞いても「調べてないです」「わからないです」ばっかりだし。
そもそも、入りたくて入ったならできるようになれよー！！と思っちゃう。
中学生のときから「勉強したいこと、仕事にしたいこと」ばかりを軸に動いてきたから、「やらなくてもいいや」と思っちゃう人の気持ちがガチでわからん。そんなことを発言したらパワハラになりかねないか？とも思うから言いはしないけど。
ちなみにパートナーとか周りの友人たちも割と仕事をしっかりやってる人間たちなので愚痴ったら、「1回くらい怒鳴ったら？」とか言われた。全然参考にならない。笑
多分転職したほうがよりよい環境には行けるんだろうけど、リモートワークでなんとか東京企業の会社員をやれてる田舎在住の人間なのと、今度子どもも生まれるので落ち着くまでは転職活動がしがたいんだよな。
というわけで現職のまま現状打破をしたいんだけど、部下の皆さんは9割あんな感じだし、昭和生まれの上の人は「皆もっと残業できるんじゃない？成果出して？」とか言ってくる。
「仕事なんてテキトーでいいんだよ」というTwitterの論調を現実に持ち込まないでほしい。できる人は言っていいけど、できない人はできるようになるまでは勉強しろよ。残業はしなくていいけど1時間だけソフトや業界の勉強をするとかね。
もちろん、未経験者を育て上げる研修期間がない＆研修材料がないのも問題なんだよね。
そんな制度誰も作りそうにないから、やるなら自分が作らないといけない…けど後輩さんの仕事のしわ寄せが連日降って湧いてくる現状でそれは厳しい！！
どうしたらいいんだよってずっと頭を抱えてる。分身したいなー。
合う合わないは人によるだろうけど工場系のゲームはアクションゲーム下手でも没頭できてめっちゃ自分は良かった。課題達成しなくても誰も怒んないし、プレイしてくとどんどん楽になるのが気持ちいい。めんどくさくなったらいつでもやめれる。
マイクラの整地とかが好きな人はたまらないと思う。プレイにも幅があって、余計なこと考えず、没頭できる。
・SHAPEZ2
神ゲー。丸とか四角の形を切った貼ったしたり色を塗ったり重ねたりして、目標の図形を自動精算するベルトを作ったらクリア。
良いところとして、工場系にありがちなお金や資源、敵などの概念がなく、マイクラのクリエイティブモードみたいに試行錯誤だけに集中できるようになっている。また、操作やUIが非常に洗練されていて、ツールの使い勝手なども同ジャンルのゲームの中でピカイチ。列車には感動した。
また、BGMやグラフィックも素晴らしく、大スケールの工場が宇宙に構築されていくさまは、見ているだけで癒される。
あと、ストーリーとかはない。
・OPUS MAGNUM
錬金術のビー玉を切った貼ったして目的の成果物を納品したらクリア。
これはグラフィックや雰囲気がかなり凝っていて、作ったからくりの動画をgifで出力できる機能が神。一生見てられる。
また、ストーリー形式で一話ごとプレイできるので、区切りがよく時間がなくても少しずつ進めやすい。
からくりの制限もあんまりないから、一見すると難しそうだけど、力技で頭使わないでできちゃう。（ただ、ハイスコア目指すと頭使わないといけない。）
あとから知ったけど、ザクトロニクスっていう有名なパズルゲーのインディーが作ったゲームみたい。（他のゲームはちょっと合わなかった…）
ゲーム内ミニゲームは難しくて飛ばしちゃったけど、いろんな人にオススメしたいマイナーゲーム。ちょっと古いゲームだけど完成度は目を見張る物があると感じる。
多分中国のあたりのメーカーが作った、factorioのフォロワーゲーム。ダイソン球という、「太陽の周りを太陽光発電で覆ったら、ずっと発電できて最強じゃね？」っていうSFのトンデモ発明を実際に作ることを目指すゲーム。
自分がこういうジャンルにハマったきっかけになったゲームで、オススメなのはそのスケールの大きさ。例を挙げれば、Factorioは湖の周りで石炭使って火力発電…とかが電気のメインになるけど、このゲームだと星の赤道を世界一周太陽光発電で一杯敷き詰めるとかが現実的になる。
また、フォロワーだけあって、徹底的にFactorioの不便・めんどうなところが改良されて、面白さだけがエッセンスとして洗練されている。（敵もいない。）
本家Factorioも本作に影響を（おそらく）受けて宇宙編のDLCを出したほど。
欠点は、3Dグラフィックでちょっとスペックが必要なのと、日本語化がちょっと面倒なこと。（Steamの記事見ながらやればできる）
このジャンルを語るなら外せない、元祖工場ゲーム。不時着した星で、ロケット生産基地を作るのを目指すゲーム。さすが、工場モノの始祖だけあって面白い。また、やることがたくさんあるので、没頭できる。
ただ、敵の概念があり、キモい虫が夜になると工場をぶっ壊しに来るのがマイナス。プレイヤーはタレットや戦車を作って、これに備え、武器を持って逆に惑星からこいつらを駆除しにいける。自分は一旦それが嫌で積んでて、ピースフルモードでやり直したら面白くてキャンペーンクリアまでやっちゃった。
マイクラのハードコアとかが好きならこっちのほうがおすすめかも。自分は敵の概念が合わなかった。
あと、対戦ゲームだけどTFTっていうゲームはマージャンを簡単にしたみたいなゲームで、頭使ったりしないでカジュアルに遊べるし奥は深いから、これもおすすめ。
会社の社風は社長が「こんな無様な営業を次やったら〇すぞ。わかった？」とか某チャットツールで「〇〇の部署のやつらのせいで業績が傾く。〇ねばいいのに」とか言う社風で、労基と税務署が来たら倒産するレベル
その下に居る部長もTHE 昭和みたいな感じのパワハラ上司。歳のせいか知らないけど言うことがコロコロ変わるので自分でやらなくていいって言ったのに「なんで〇〇してへんの？」とよく詰めてくる
前職はクソ上司のパワハラで吐き気だったり、「死にそうな顔色してる」って言われる程度にメンタルやられたので2年で退職した
辞める時もそんなんじゃどこに行ってもやっていけないと言われた。転職活動は難航したけどなんとか採用もらって別業界だけど経験と知識が使い回せる同じ職種だった
現職は聞いてた話と違っていて、まず自分と入れ替わりで経験者の2人が退職した
ロクに引継ぎもなければ資料も残ってない（あるけど本人にしか分からない）レベルで四苦八苦してたら部長にキレられた
直属の上司いわく部長は「あいつは成果の報告が無いし成果物も出さない」って言ってたらしいけど、しなかったんじゃなくて出せないが正解だった
あと入社したばかりなのに、会社の内部構造なんて知るわけがないので答えようがない質問も多かった。そして分からないと怒られる
そして上司は未経験者なので専門的な質問はほとんど俺に丸投げされてた
前任者がやってた仕事もかなり杜撰で「そうはならんやろ」みたいな感じのが多かった。突っ込みだすとキリがないので途中で諦めたけど、そのまま外部に見せたら即座にアウトなやつが多い
その割に部長は「そんなの知らん」とか「なんでお前が知らんねん」みたいな感じでこっちに怒ってくるか「そんなもん前のやつに電話して聞けや」と言ってくる。大体いつもこれ
1か月経ったあたりで、新しい人(Aさん)がまた入ってきたんだけど給与は俺より上で職位だけ同じだった。でも知識が無いので言えばやってくれるけど…みたいな感じだった
3か月経ったあたりで、また新しい人が入ってきた。この人も俺より給与は上で職位は同じだった。でもこの人は理解が早かったので俺より能力が高そうだった。ただ何かを察したのか3日で辞めた。正解
俺の給与が一番下で、同じ職位だけど最大で5万円の差があってこの段階で割とモチベーションだだ下がりしてた
4か月目あたりから俺の評価が地に落ちたんだろうなっていうのが分かる出来事があった
露骨にイレギュラー業務を全部取り上げられて、ルーティンだけやるように指示された。多分これは俺の能力が不足していて残業が多いのを上司に相談していたからだと思う。
1か月目は残業80時間、2か月目は70時間、3か月目は45時間(ホントは60時間)だったので、恐らくコイツ使えねえわって思われてた
ルーティン業務もロクに指示が無かったり、Aさんが担当してたやつを引き継いでみたら所々に漏れがあってダメじゃねこれ？と思って管理シートも全部手直しして一見さんでも出来るようにした
指示が無かったやつは適宜確認したりしてこなしていたけどAさんからちょくちょく「イレギュラー業務のここが分からなくて～」という質問が飛んで来てた
それの対応をしていたらルーティンが終わらなくなったり、他部署からの問い合わせに対応していたら今度は直属の上司から「お前は仕事が遅すぎるので何も任せられない」と言われた
個人的にまず伝えたかったのはルーティン業務は4か月目にして初めて触れる業務がほとんどだったという点と
ちゃんとした指示が無いので確認に時間を要した（上司指示なのに上司は時短で帰宅とか私用で半休がザラ）っていう点と
業務の効率化(入力シートの改善やCSVをそのまま貼るだけで計算できるようにする環境作り）を並行していたんですよっていうのが伝えたかった。だから個人的には1か月もすればかなり効率が良くなる自信があった
あとAさんは何も言ってないかもしれないけど、イレギュラー業務は俺の手を離れてもまだ俺に質問がガンガン飛んできてたっていうのを伝えたかった
ただ度重なる残業でメンタルが結構ズタボロだったのと、上司との面談の際に「お前は仕事が遅すぎるので何も任せられない」と言われ、追撃の「部長もお前には難しい仕事振るなと言ってた」っていうのでガチ泣きしてしまった
上司の顔を見て話そうとしても涙がボロボロ出てきてしまい、さすがに上司も気を遣って5分ぐらい離席してくれたけど嗚咽している程度にはガチ泣きして1時間ぐらいずっと泣いた
戻ってきた上司は「そんなんじゃお前は成長できない」とか「自分だって〇〇（大手企業）で大変だった」とか「今の環境が良くないのは分かってるがそれでも頑張るしかない」とか言ってたけど、ただハイハイ言いながら鼻をかんでた
いろいろ言いたかったけど本気で言葉が出なくて詰んでた。過呼吸にならないだけ偉いって褒めたいぐらいには感情がカオスになってた
本気で仕事できる精神状態じゃなくなってしまったのと、上司から「とりあえず病院でも行け」と言われたので早退して心療内科に行ってみたら適応障害だと言われた
個人的にはそういうのが好きじゃないので、でも休みの日は普通なんですよって抵抗してみたら「それも適応障害の典型ですね。あと検査結果を見ると鬱の傾向もあります」って一刀両断された
今後どうしていいのかよく分かんないけど、とりあえず働かないと金が無くなるので働かなきゃいけないなとは思う
ただ上司からLINEで連絡がきていたので返事していたら、返事をするだけでも涙がボロボロ出てきてベッドシーツがびちょびちょになった
とりあえず謝罪文と今後は出来るだけ早く出来るように生産性を上げますって伝えたけど、メンタル的に出来るかどうかは分からない
こういうことを書くと、たぶん反論が山ほど来るんだろうけど、少なくとも自分の中では結論が出てしまっている。いや、正確に言えば、大学に入ってからの数年間を経て、うっすらと確信に変わったという感じだ。
自分は理系の学部にいたけど、キャンパスの中では哲学科とか文学部の人たちともたまに話す機会があった。彼らの話は一見すると深そうだった。「言語は主体を構成する」とか「歴史は権力構造の再編だ」とか、なるほどと思う部分も最初はあった。でも、よくよく考えてみると、それって何かを解決しているわけじゃないんだよね。実際の問題を一歩でも進めているかというと、むしろ問題の存在を複雑にして見えにくくしているだけのように思えた。
「考えること自体に意味がある」とか、「答えが出ないことに向き合い続ける姿勢が重要」とか、そういう理念的な話も聞いたけど、それって結局、逃げの論理なんじゃないかと思ってしまう。何か成果物が出て、それが誰かの役に立つという形になればいい。でも人文系の論文の多くは、専門用語で固められていて、同じ専門分野の人しか読めない。つまり、社会との接点を自ら閉ざしているように見える。
もちろん、「意味があるかどうか」は短期的な視点では測れないという主張もあるだろう。でも、そういう理屈って何にでも当てはまるし、結局、何がしかの「役に立ってる感」が本人たち以外には伝わってこない以上、外から見るとただの趣味活動に見えてしまう。趣味に没頭すること自体は否定しない。むしろ楽しそうで羨ましいくらいだ。でも、それを「学問」として成り立たせて、税金や公費を突っ込む意義は本当にあるのかと問いたくなる。
たとえばAIの発展についても、人文系の人たちは「倫理が」とか「人間性が」とか言うけれど、じゃあ彼らの言葉が社会をどこまで動かしてるのかと考えると、ほとんど何の影響力もないように感じる。結局、技術の進歩は技術者たちの手で進み、現実の社会設計は経済や法の専門家たちが担っている。人文系がそこに対してできることは、せいぜい傍からコメントする程度。
たまに、文系こそが人間の根源を問う存在だ、みたいなノリで持ち上げる人がいるけど、それってもう宗教と変わらないんじゃないか。そういう「意味の権威化」に付き合わされるこちらとしては、むしろシンプルに「よくわからないし役に立たない」と言ってしまいたくなる。
ソシュールとかチョムスキーとかがいろいろやってきたかもしれないけど、ほとんどの人はこの最終文に辿り着く前にとっくにこの文章がAI生成だって気づいてただろうから、やっぱり人文系の学問って意味ないと思う。
