他の人が使うソフトウェアを作ること
t_wada Vibe Coding は「自分だけが使う、自分がいちばん欲しいソフトウェアをだれでも作れるようになった」ことが革命的かつ真骨頂なのであって、他の人が使うソフトウェアを作ることには（少なくともまだ）向いてないと思います t_wada Vibe Coding はソフトウェアエンジニアではない人たち（つまり世界中の多くの人たち）にとっての革命なのだという話をした これはこれはいい指摘だが、「向いているか向いていないか」の議論はあんまり生産的じゃなくて、重要なのは「ソフトウェアを作ること」を暗黙に「他の人が使うソフトウェアを作ること」だと思い込んでいる人が割と多いのではないか、その解釈は今までの需要と慣習が作ったものであって普遍的事実ではないのでは、と言うところだと思います
生産様式は色々あるし、今までできなかったこともできるようになっていく kt2d Vibe Coding に限らず、実現手段の敷居が大幅に下がる進歩があった時に人の新規流入があってアウトプットの民主化ブームが起きてきたけど、それが久しくなっていたということかな 今でこそ OSS なんてたいそうな名前がついたけど、昔のフリーソフトとかまさに自分専用みたいな世界観が多かったし、
>nishio: これはいい指摘で、重要なのは「ソフトウェアを作ること」を暗黙に「他の人が使うソフトウェアを作ること」だとkt2d 新しい世代によって、ぼくの考えた最強のアプリケーションなり UI なりがどんどん作られていって、それらに共鳴する「ぼく」が増えていく世界観はこの先のソフトウェアの発展にとってとても健全だと思うので、この指摘はすごく良い気づきになる pewo31 属人化まっしぐらのような気がするような気がするんですが、大丈夫なんでしょうか？ GPT5.icon
“大丈夫にする”設計（属人化＝悪ではなく、設計の論点）
スコープ別に共有の最小単位を変えると、懸念はかなり解けます。
A. 完全に個人用途
それで完結するなら属人化は“仕様”でOK。
ただし最低限の再現キットだけ残す（目的／前提／入出力例／要点メモ）。
B. チーム内での再利用（小規模共有）
配布物にせずにレシピを共有：
目的（何を達成するか）
前提（必要データ/権限/前処理）
実行手順（人間語で十分。必要ならプロンプト/ワークフロー）
サンプル入出力と失敗時の観察ポイント
個人の実装は各自の環境で再生成する（＝環境依存を吸収）。
変更点は**履歴（Changelog）**として自然言語で残す。
C. 組織配布（多数向け）
ここで初めて配布物化（ハードニング）：
テスト、権限分離、ログ、監査、更新チャネル、責任分界。
重要：A/BからCへ“昇格”する判断基準を定める（利用者数、事故コスト、法令等）。
まとめると、属人化は手前の段階の高速性の源泉。
問題は“どの段階まで属人のままでよいか”と“昇格の合図と手順”。
関連