プログラマーのアイデンティティ危機
(hojberg.xyz)- プログラマーのアイデンティティは、近年のAIとLLMツールの登場によって脅かされている
- プログラミング文化は1950年代のMITのハッカー倫理に始まり、コードを書くことそのものを奥深い技芸（craft）と見なし、精密な論理と問題解決への没入を中核的な価値としてきた
- しかし現在のAI産業とLLMツールは、開発者を単なる仕様記述者やオペレーターへと変えようとしており、直接コードを書く代わりに自然言語で指示するだけの「vibe-coding」方式を押しつけている
- LLMが生成するコードは非決定的で不正確であり、開発者が自らコードを読み書きする過程で得られる深い理解と没入を取り除き、コードベースとのつながりを断ってしまう
- 企業は生産性向上を名目にツール利用を強制し、チーム内の協業やメンタリング文化をAIとの相互作用に置き換えることで、開発者同士の人間的なつながりを弱めている
- プログラミングを単なる成果物ではなく思考と理解のプロセスとして見る本質的価値が失われつつあり、開発者は自らの技能と楽しさ、そして職業的アイデンティティを守るためにこの変化に抵抗しなければならない
プログラマーの本質と伝統
-
コードを書くことは単なる業務ではなく開発者のアイデンティティそのものであり、エディタは仕事場であると同時に聖域でもあって、技術を磨きフロー状態に入るための空間である
- Vimのようなツールを通じて、思考とコードのあいだに障壁なく作業し、現実世界に影響を与える非物質的な世界を創り出す
- パズルを解く過程そのものが完成図より重要であり、指先からバッファへとつながる技術の流れの中で時間は消えていく
-
1950年代後半のMITで新しいプログラミング文化が誕生し、実験的で反体制的な気質を持つハッカーたちがFlexowriterとTX-0コンピュータを使いながら完璧なプログラムを追求した
- 「The Right Thing」という概念を軸に、優雅で簡潔なコードを書くことを目標にした
- Tech Model Railroad Clubのメンバーは機械語に没頭してデジタルの魔法を身につけ、見つけた知識を他の学生と共有する文化を築いた
-
Building 26というコンピューティングのるつぼでコーディング技術は鍛えられ、およそ70年前に確立されたこの文化は現在まで続き、今なお開発者の心と機械の中に生きている
- 古代のハッカーたちの遺産は深く身体化された技術として残り、それを土台に情熱的な産業が築かれた
- 開発者たちは今もなお、同じ驚きや達成感、そしてパズル解決の優雅さによって動機づけられている
-
しかし、プログラマーのアイデンティティを構成するこうした中核的価値が脅かされており、かつて明るく明瞭だったプログラミングの未来は、いまや不吉な暗さと欺瞞、不確実性に覆われている
AI産業による新たなアイデンティティの強要
-
何十億ドル規模のAI産業、Hacker Newsコミュニティ、LinkedInのLLM支持者たちは、ソフトウェア開発の未来はプログラミングとほとんど似ていないと主張しており、1年前にはミームのように見えた「vibe-coding」が主流になりつつある
- 開発者はコードの代わりにMarkdownで仕様を書くことを求められ、コードベースの隅々を探索し、パズルを解き、秘密を発見するような深い没入と技術的深みは失われる
- その代わり、エージェントが思考するあいだ開発者は注意散漫な認知とコンテキストスイッチを受け入れなければならず、創造的な問題解決は機械に委ねられ、開発者は単なるオペレーターになる
-
一部の開発者はこの変化と**「Specification Engineering」という新しいアイデンティティ**を歓迎し、オペレーターとなってSteve Jobsのように「オーケストラを指揮する」ことに興奮している
- コーディングに関心がないように見えるのに、なぜプログラマーになったのか疑問であり、WozとJobsを取り違えているのではないかと思える
- Prompt、Context、Specificationの「Engineering」が、プログラマーに明るく繁栄した職業人生をもたらすようには見えない
-
これは技能、熟練、労働価値の低下を意味しており、開発者固有の抽象的思考能力が、もはや必要とされない領域へ移され、すでにプロダクトマネージャーやデザイナーが占めている空間へ押し込まれることになる
企業内のパワーダイナミクスの変化
-
企業内でこの新しいアイデンティティが強要されることでパワーダイナミクスが変化しており、誤った場所で生産性を高めようとする狂信的な試みによって、開発者はますます具体的な形でLLMを使うよう強制されている
- 従わなければ追い出され、自分の無用さを知らせる製品を使うか、退職するしかない
- これほど具体的に経営陣が開発者のツールを指図することは、以前はほとんどなかった
-
開発者はシェフや大工のように、自分の道具をキュレーションし磨き上げることに大きな誇りを持ってきた。エディタの細かな設定、dotfilesの調整、開発環境の構成などを通じて、自分の思考様式に合うよう道具を個人化してきた
- 技術の一部としてツールセットの個人化に献身してきたのに、日常業務とほとんどつながっていない経営陣がそれを命令するのは侵害のように感じられる
- 何十年ものあいだ企業内で優遇されてきたプログラマーにとって、このナラティブは経営陣に有利な形で再び均衡を傾ける新たな手段を与えている
LLMとプログラミング言語の本質的な違い
-
一部ではLLMの影響を低級言語から高級言語への移行（AssemblyからFortranへ）になぞらえるが、これは多くの点で誤った比喩である
- Fortranはプログラミングに根ざしており、技能を取り除こうとするのではなくその上に築かれ、プログラミングの精密さや表現力を奪うのではなく拡張した
- Fortranは入力に対して常に正しい結果をうまく生成したが、LLMの世界ではそのどちらも成り立たない
-
コンピュータとプログラミングは非常に苛立たしいこともあるが、少なくとも精密さについては常に信頼でき、プログラミングによって命じたとおり正確に実行してくれた
- コンピュータの精密さへの依存と信頼があるため、チャットボットに頼んだ作業ができたとガスライティングされると、それを信じやすい
-
LLMとその仕事は本質的に不正確であり、大規模言語モデルの性質そのものにも、自然言語で指示する方式にも誤解の余地がある
- 非決定性を嫌うプログラマーたちがこうしたアプローチを選んだのは興味深く、彼らは本来、予測可能性、合成可能性、冪等性、不安定でない統合テストを好む
- LLMコードはその逆、すなわち一貫性のない混沌を示している
-
Dijkstraは「自然言語プログラミングの愚かさについて」において、自然言語が作業を単純化するという前提に異議を唱えるべきだと指摘し、形式的テキストの利点は、正当であるためにいくつかの単純な規則を満たせばよい点にあると強調した
深い理解と没入の喪失
-
AI支援開発を厳格さや官僚性によってvibe-codingと区別しようとする動きもあるが、それは根本的な本質を見落としている
- LLMが生成したコードは、自分で書いたコードやPRでレビューしたコードほど注意深く読まなくなりがちで、LLMコーディングには目をうつろにさせる本質的な何かがある
- ざっと流し見して、圧倒され、退屈し、CIが通りプログラムがコンパイルされれば危険な落とし穴を盲目的に受け入れてしまう
- テストが実行されるよう設定されているか、存在しないライブラリをimportしていないか、ライブラリ全体を勝手に実装していないかを確認しなくなる
-
本のレビューや要約は、実際に読む体験の代わりにはならず、何百ページにもわたって各文を注意深く味わいながら考え抜く過程が必要である
- 同様に、AIが終えた作業の要約をざっと見るだけでは、ドメイン、問題、可能な解決策への深い理解を形成する機会を奪い、コードベースとのつながりを断つ
- 無知の深淵へ飛び込み、主題とその含意を明らかにし、学び、理解することは満足感をもたらし、良いソフトウェアに不可欠である
- オーナーシップ、主体性、深く満足のいく仕事は、エージェントのタブを行き来する気の散った注意に置き換えられる
-
Joan Didionは「私は、自分が何を考えているのか、何を見ているのか、そしてそれを見て何を意味するのかを知るために書く」と述べ、Peter Naurは「Theory Buildingとしてのプログラミング」で同じ概念を探究した
- Naurの「Theory」はコードベースの理解を具現化したものであり、その動作、形式主義、現実世界の表現を含む
- このような文脈と洞察は没入を通じてのみ得られ、Naurは「Theory」をソフトウェア以上にプログラミングの主要な成果物であり、実際のプロダクトだと説明した
- **十分に発達した「Theory」**があってこそ、コードベースへの拡張やバグ修正を効果的に適用できる
-
良い設計は没入から生まれ、テキストバッファ上で行き来する作業や、しばしばキーボードから離れた場所での作業を通じて現れる
- コードベース全体を頭の中に収めることはできないため、モジュール、クラス、関数に飛び込み、ぼやけたメンタルモデルを鮮明にしていかなければならない
- コードを読み書きすることで認知を拡張し、親しみと問題領域への理解を取り戻す必要がある
-
文脈の一部が築かれ、多くの不十分な試行を経て、ようやく解決策を見つけられるようになり、悪い設計の不協和音を感じる必要がある
- うんざりする反復的なコードを書いて初めて、より良く、より簡潔で、より優雅で、より合成可能で、より再利用可能な方法があると気づく
- それによって問題について深く考えるために立ち止まり、一歩引いて最初からやり直すことになる
- 逆にAIエージェントの作業は摩擦がなさすぎるため、別の解決策を避けてしまい、受け入れたものが完璧なのか、凡庸なのか、ひどいのか、あるいは有害ですらあるのか判断できない
チーム協業と人間的つながりの崩壊
-
LLM中心コーディングの認知的負債は技能の劣化を超えて広がり、注意力の短い「slop-jockey」たちがプルリクエストやデザイン文書に自分の成果物を投げ込み、協業を妨げチームを混乱させている
- コードレビューをする同僚たちは、自分がもはや最後の品質管理レイヤーではなく、最初のレイヤーになってしまったという衝撃的な気づきに消耗している
- 新たに追加されたのに呼び出されていない関数、幻覚によって追加されたライブラリ、明白な実行時エラーやコンパイルエラーを指摘しなければならない
- 自分のコードを明らかに流し見しただけの作者は責任を負わず、「Claudeがそう書いたんですよ。間抜けなAIですね、はは」と言う
-
干渉的な管理職とコスト削減を狙う経営陣は、チーム内の人間同士の相互作用を減らすよう（おそらく無自覚に）圧力をかけている
- 孤立し、つながりを奪われた状態で、今や自分の仕事体験の周囲に壁を築くことが許され、むしろ奨励されている
- ペアプログラマーが必要なとき、解決策をやり取りしながら議論したいとき、プロトタイプを作りたいとき、アーキテクチャをスケッチしたいとき、あるいはコードベースの難解な部分について専門家に尋ねたいときにも、人ではなくLLMに頼る
- もはやオンボーディングのバディも、メンターも、同僚も必要なく、代わりに機械と会話すればいいことになる
- LLMによって人との接触を避けることがあまりにも容易になり、それが標準になりかねない
プログラマーのアイデンティティを守る
-
私たちがAI誇大宣伝のナラティブにどれほど従順で、技術の計画的な削除に積極的に加担し、思考の手段を喜んで手放しているかは衝撃的である
- 趣味で生計を立てられていた幸運な側だったのに、slopに対処するため厳格で細心なプロセスを作ったとしても、なお仕事の楽しい部分を外注し、それを命令的で退屈な作業に置き換えてしまっている
-
LLMはソフトウェアの複雑さに対する軌道上からの核爆弾的ソリューションのように見え、実際の問題を解決する代わりに症状を治療するため、さらに複雑で曖昧なものへ手を伸ばしている
sedをClaudeで置き換えたり、何時間もドキュメントを探しても明確にならないライブラリやフレームワークについて答えを求めたりするのは構わない- しかし単なるオペレーターやコードレビュアーとなって、楽しく興味深い仕事から後ろへ退くことは望まない
-
私は反復作業を助け、コードベースを理解し、正しいプログラムを書く助けになるツールを好み、自分の代わりに考えるよう設計された製品には不快感を覚える
- 自分が生み出すソフトウェアへの理解における主体性を奪い、同僚とのつながりを断つ製品は拒絶する
- LLMが誇大宣伝どおりだったとしても、私たちはなおこれらすべてと技能を失うことになる
- 人間は機械とそれを支える企業より重要であり、残りの私たちが彼らの売る新しいアメリカン・ドリームを追っているあいだに、彼らは利益を得ている
- その代償として私たちは、批判的思考力、楽しさ、技能、プライバシー、そしておそらく地球まで差し出している
3件のコメント
おおむね共感です
特にコンテキストスイッチングでしょうか。プロンプトを依頼して待っている間に集中が途切れ、生産性が落ちる原因になります。LLMの速度が上がって即時に反応が返ってくるなら、解決するかもしれません
文章自体が、最初から結論ありきで書かれているように強く感じますね。開発者からオーナーシップが取り除かれる問題は、LLMとは関係なく、**「職人気質の時代 vs 産業化の時代」**についての話として読めます。
Hacker News の意見
私にとって最も印象的だったのは、コードレビューアーたちが、もはや品質管理の最終段階ではなく最初の防衛線になってしまったと気づいて、だんだん精神的に参っていく様子だ。レビュー依頼は来るが、今では新たに追加された未使用関数、突然追加されたライブラリ、明白なランタイムやコンパイルエラーなどを一つひとつ拾わなければならない。コード作成者は責任を回避し、「Claude が書いたので、AI がミスしたんです、はは」といった感じで済ませてしまう。LLM 導入後は、ブランドリーニの法則（でたらめを反駁するためのエネルギーは、それを生み出すよりはるかに大きいという法則）をいっそう強く実感する状況になっている。経験が浅い、あるいは技術力の低い開発者が数分で数千行のコードを吐き出せるようになると、実際にシステムの健全性を保証する責任はコードレビューアーへと転嫁される。PR のコード増減量（added/removed LoC delta）を見ると、LLM が書いた PR はほぼ追加ばかりが続き、熟練したシニアエンジニアは新しいコードを書くのと同じくらい既存コードを削ることが多い
私は、これは技術の問題ではなく人の問題だと思う。一度こういうことが起きたら厳重に警告すべきで、二度繰り返したらマネージャーに回して却下すべきだと思う。誰が PR を書いたにせよ、最終的にその成果物に自分の名前を載せるのだから、コードがひどければその責任も本人が負うべきだ
もう大規模チームでコードレビューはしていないが、もし自分がそういう状況に置かれたら、こうした責任逃れは一度くらいは見逃すかもしれないが、繰り返されるならその人を外そうとすると思う。それが無理なら自分が辞める。そのくらいひどい環境だ
最近、自分の生産性が落ちたと感じるのもこれと関係があると思う。より多くのコードをより速く生み出せという圧力と、エージェントのようなものを使うと自分が書いたコードの全体文脈をきちんと把握できないという点のせいだ。自分が行単位で丁寧にレビューできる範囲でしか品質を保証できないが、そこに限界がある。だから最近は、よりゆっくり、より保守的に AI を使い、手で書く比重を増やしている。明確な型定義や仕様を複数の属性に繰り返し適用するときには AI が少し役に立つが、そういう場合でさえ成果物が常に確実とは限らない
キャリアの長いシニアエンジニアほど、追加するコードと同じくらい既存コードを削ることが多い。Negative 2,000 Lines Of Code も参考になる
LLM が介在した瞬間に、私たちが誰に責任を転嫁するのかという見方は、より広い社会的問題だと思う。人は結果が良ければ自分の手柄にし、悪ければ簡単に AI のせいにする。適切な訴訟事例がいくつか出れば、この文化は大きく変わると思う
昔から業界に入ってくる人たちは、コードを職人芸として見るというより、手っ取り早く金を稼ぐ手段として見ていると感じる。オープンソースのインフラ開発者が生計維持に苦労しているという文章を読んだときから、カフェでコーディングする開発者、ブートキャンプや「コードさえ学べばいい」という運動、Leetcode grinder、サンフランシスコで家賃が高すぎて車で暮らす開発者に至るまで、今では AI で自分自身を自動化して職を失うことまでが話題になっている。開発者は本当のプロフェッショナルではないという認識が問題だ。基準も緩く、倫理規定や一貫したスキルセット、代表性もない。しかも業界の構成員自身が自分たちの利益に敵対的なほど主体性がない。弁護士には弁護士会があり、医師には医師会があるが、開発者には存在論的不安しかない。今では上司が「AI で自動化して君の仕事をなくすぞ」と脅してくる。他の専門職はここまで自分たちの利益に敵対的ではないのに、なぜこの業界だけこうなのか自問してしまう
「コーダー」とソフトウェアエンジニアは違うと思う。ブートキャンプを終えて Python で簡単なプログラムが書けるからといって、ソフトウェアエンジニアとは言えない。自分に学位があると言うとエリート主義だと言われ、コンピュータサイエンスで学ぶことは実務では役に立たないものばかりだと言われることもある。しかし、学位がなくても独力で優れたエンジニアに成長した例があるのも確かだ。それでも、何らかの形で基準は必要だという点には同意する。最新のバズワード系ユニコーンスタートアップに加わるブートキャンパーはただ祝福すればいいが、Therac-25 のような事故につながりうるセンシティブなシステムは、きちんと訓練を受けた人が担当すべきだと思う
上司が「自動化しなければ君の仕事はなくなる」と言うこと？ それこそが私たちの仕事だ。労働を自動化するのは私たちの仕事の本質であり、自分たちの職場を自ら自動化する機会と理解を最も多く持っている職種でもある
教職にも開発者と似たところがあると思う。優れた教師もいれば、ひどい教師もいて、その中間も多い。科目をよく知っているからといって教える能力が高いわけではない。もしかすると開発者は機械を教える教師だと言えるのかもしれない。一文字ずつ、一つの考えずつマーチャンキャラクターを教えるやり方もあれば、全体的な雰囲気で教えるやり方もある
LLM はひとまず脇に置くとして、自分でも誇れるほど完成度高く書けたコードがたまにある。構造から各行に至るまで理由のない決定がなく、このコードについては自分が専門家で完全に把握している状態だ。しかし、たいていのコードはそこまで完璧には書かない。多くは「仕事が終わればいい」という感じで、自分に少し低い基準を許している。それでも、たまにしっかり没頭して仕上げたコードは本当にやりがいがあり、自分の人生でも最高のコード体験になる。LLM まで考えると、むしろ高い完成度でコーディングすることは楽になった一方で、その分むずかしくなった面もある。心理的に深く没入できれば、LLM をうまく活用してより速く、より高い基準の結果を出せる。LLM が書いたコードよりはるかに良いものを書けるが、LLM の助けでもっと優れたコードを書くこともできる。しかし、この没入状態を維持するのがますます難しくなっている。LLM が作ったコードをざっと眺め、見た目も良く動作もしているので、そのまま通してしまう。だが、そうして雑に流したコードは少しずつひどくなり、その鈍った感覚のまま通し続けると、気づいたときにはもう手遅れだ。結局、自分自身がそのコードの専門家になれず、雑なコードだけが積み上がる
このエッセイは本当に自分の考えにぴったりで、楽しく読めた。会社で AI を使おうとしたが、ほとんどの場合は成果物がいまひとつで、結局ほぼ全部自分で書き直した。考える時間や問題解決を不必要に AI に任せるのは、自分のキャリアにとって最悪の選択だという確信がある。AI はただのミディアムクオリティのテキスト生成器にすぎない
「いったいあの人たちはなぜプログラマーになろうとしたのか。コードそのものに興味があるようにも見えないのに」という疑問に対して、私は「目的は問題解決だ」という点を強調したい。コーディングは手段であって、目的そのものではない。「エディタ設定、dotfiles、開発環境をいじること」が楽しいのはわかるが、自分にはそれは無駄な複雑さに見えるので、喜んで委任する
エディタ、dotfiles、開発環境を自分でセットアップすることは、結局のところ自分の作業環境への親和性を高め、ツールの習熟度を上げ、より生産的な環境を作ることでもある。ビルドスクリプトを触る必要が出たときに「呼ばれる人」になるのは、そういう管理をしているからだ。10 年、20 年と Git を使っていても、マージコンフリクトや基本的な使い方さえわからない人があまりに多く、その結果、ちゃんとツールを身につけた人に面倒ごとが全部集まってしまうという問題がある
「これは価値がない」という主張は、論理を最後まで押し進めると「そもそも存在自体に何の価値があるのか」にまで行き着きかねない
世の中のほとんどすべての職業の目的は問題解決だが、その中でなぜソフトウェアを選んだのかが気になる
「目的は問題解決で、コーディングはその手段にすぎない」という主張には 100% 同意する。AI がコーディングを代行して悲しむ人たちは、「コードの芸術家」のような類で、何を作るかよりも、その“形式”そのものに執着している。自分は問題そのものに集中するタイプなので、AI がコーディングを代わってくれても何一つ惜しくない
「コーディングは目的ではなく手段だ」という主張も、「エディタをいじるのは楽しいが価値はない」という話も、どちらも極めて主観的だ。問題解決がなくなっても、純粋にコーディングそのものが好きな人はいるし、もし世界に問題が一つもなくてもコーディングを楽しむ人は大勢いるだろう
この記事は本当に興味深く読んだ。LLM プログラミングについて自分が感じていることとほぼ一致している。自分は単純にコーディングが好きでやってきたし、職業としてもそれを楽しんできた。だが今は、仕事の中で自分が好きだった趣味を生かせなくなってしまって残念だ。完全に別の作業になってしまった
私はもうそれなりの年齢だ。1995 年ごろは、今とはまったく違う環境でプログラミングしていた。当時はエンジニアが対象顧客も技術スタックも業界動向も全部把握していて、本当に主導権を握っていた。自分のコードは自分の遊び場で、好きなように作り変えられたし、インデントや括弧のスタイルも自分で決めていた（壊れたら自分で直す）。ユニットテストのようなものもなく（当時はパラメータ確認程度だった）、正式なコードレビューもほとんどなく、同僚とオフィスで雑談したりホワイトボードを叩いたりしていた時代だった。バグがあればその場で直す文化だった。結局、マネジメントが勝ち、こうした「カウボーイコーディング」の時代はもう戻ってこない気がする。90 年代の Apple を懐かしむことはあっても、もうあの頃には戻れない。あれは本当に楽しかった
私も似たような時期に始めたが、うちは ISO 9001 のために定期的にコードレビューをしていた。成果物をプリンタで印刷し、3 人が同じ部屋に集まって全行を確認し、署名しなければならなかった。これを産業制御 RTOS でやっていた。プロジェクト管理は 40 フィートのガントチャートを印刷して壁に貼っていた。完全にウォーターフォール時代だ
私は 2000 年代後半に始めたが、その頃はキャリアパスや専門分野の境界がずっと明確だった。システム管理者と開発者ははっきり分かれていたのに、今ではシステム運用者の役割まで自分に期待され、かえって仕事の範囲が広がった。自分はシステム系のスキルを趣味として身につけただけで、実際に仕事として任されると、現場のベンダー文書やトレーニングがあまりにお粗末で目を背けたくなった
業界全体が再びカウボーイコーディングに戻ることはないだろうが、一部の環境では今でもこういうスタイルが残っていると思う。WhatsApp では 2011〜2019 年の間、かなり自由な環境だった。環境ごとに、エラーを事前に見つけるコストと本番後に見つけるコストによって、何が適切かは変わる。自分は個人的にはエラー修正コストを下げるアプローチの方が好みだ。その代わり、もちろん恥ずかしいミスはしないように努めるし、必要なテストは必ずやる
今はビジネスマインドや vibe coder、script kiddie が入り込みすぎて、すべてが駄目になったと感じる
カウボーイコーディングの問題は、一人の信頼できないメンバーがチーム全体を壊しかねないことだ。組織が大きくなるほど質の悪いメンバーも避けられず増え、問題の爆発を防ぐにはどんどん大きな仕組みが必要になる。信頼ベースの少数精鋭チームではカウボーイコーディングは最高効率だが、採用時に候補者の実力を見極めるのは難しいので、大規模組織にはまったく向いていない。今後も小規模企業や大企業内の小規模チームなどでのみ、このやり方が生き残るのかもしれない
「<i>LLM はソフトウェア複雑性を狙った最後の核兵器のようなソリューションだ。本当の問題を解決するのではなく、より巨大な複雑性を持ち込んで症状を和らげようとしている</i>」という著者の言葉には賛同しづらい。AI 導入の核心的な目的は、「創造的で高価な高技能人材」を AI を設計するごく少数の企業へ中央集権化し、それ以外のすべての企業ではクリエイティブワーカーを解雇して単純な人員だけを残すことだ。つまり、あらゆるビジネスの複雑性を AI によって単純化することが目的だ。『オズの魔法使い』を例にすると、誰もカーテンの裏側を見たがらず、自分の仕事が楽になることだけを望んでいる。長い目で見たリスクはすべて無視し、短期的な利益だけを取るから起きる現象だ
この記事が本当に気に入った。問題解決がコードより重要だという一部の意見にも同意する。だが、自分の考えでは、AI に深い思考を要する問題まで任せ始めると、そうした深い問題解決能力そのものが時間とともに衰えるかもしれない。単に「何かを作ってくれ」と指示するのは、本当の問題解決ではないと思う