「これ、ちょっと作れない？」
技術に詳しい人、AIツールを触れる人、個人開発をしている人なら、一度はこういうお願いをされたことがあると思います。
表面上は、ただの軽い相談に見えます。
たとえば、
- CSVを読み込めるようにしたい
- 検索できるようにしたい
- クリックしたらコピーできるようにしたい
- 既存のGitHubのツールを少し改造したい
- 日本語でも動くようにしたい
頼む側から見ると、「ちょっと便利なものを作ってほしい」くらいの感覚かもしれません。
しかし、作る側から見ると全然違います。
それはもう、ただの「ちょっと」ではありません。
調査、要件定義、設計、実装、デバッグ、バグチェック、動作確認、修正ループ、保守メンテまで含む小さな開発案件です。
そして、ここを断ると「冷たい」と言われることがあります。
でも本当に冷たいのは、断る側なのでしょうか。
むしろ、何も努力せず、相手の時間・集中力・AIツールの使用制限・保守責任まで使おうとする方が冷たいのではないでしょうか。
「CSV検索だけでしょ？」では終わらない
たとえば、プロンプトをCSVで保存して検索できるツールが欲しい、という依頼があったとします。
使う側から見ると、やりたいことは単純です。
- CSVを読み込む
- タイトルで検索する
- キーワードで検索する
- 見つけたものをクリックしてコピーする
- 必要なら新しい行を追加する
一見、簡単そうに見えます。
でも、作る側は次のようなことを考えます。
- CSVの列名はどうするのか
- idは必要なのか
- title, positive, negative のような列で固定するのか
- 既存ツールを使うのか、新しく作るのか
- 日本語CSVは文字化けしないか
- Excelで開いたときに壊れないか
- カンマ入りのプロンプトで列がズレないか
- 改行入りのプロンプトを1セルとして扱えるか
- 既存行の編集は必要か
- 削除は必要か
- 保存時に元データを壊さないか
- idが重複しないか
- 検索対象はタイトルだけか、本文も含めるのか
- コピーするのはpositiveだけか、negativeだけか、両方か
- エラーが出たときにどう表示するのか
- ツール本体のアップデートで壊れたらどうするのか
これを見ても、まだ「CSV検索だけ」と言えるでしょうか。
実際には、かなり地味で面倒な設計が必要です。
そして、この地味な設計こそ、頼む側からは見えにくい工数です。
特に重いのは、要件定義とバグチェック
技術系のお願いで本当に重いのは、コードを書くところだけではありません。
むしろ重いのは、要件定義とバグチェックです。
「何を作るか」が最初から明確なら、まだ話は早いです。
しかし実際には、次のような部分が未定義のまま投げられることがあります。
- 何のために使うのか
- 誰が使うのか
- どの画面で使うのか
- どの頻度で使うのか
- CSVを手で編集するのか、ツール側で編集するのか
- 保存だけでいいのか、編集も必要なのか
- 削除も必要なのか
- コピーはどの項目をコピーするのか
- 検索対象はタイトルだけか、本文も含むのか
- 既存ツールを改造するのか、新規で作るのか
- 壊れたときに誰が直すのか
- 後から要望が出たら誰が対応するのか
これが共有されていないと、作る側が全部想像することになります。
つまり、相手の「なんとなく欲しい」を、作る側が勝手に分解して、仕様にして、バグを予測して、壊れないように設計することになる。
これはかなり重い作業です。
要件定義とは、単に「何が欲しいかを書くこと」ではありません。
- 目的を決める
- 使い方を決める
- 入力を決める
- 出力を決める
- 例外を決める
- 失敗時の挙動を決める
- どこまで対応するかを決める
- どこから対応しないかを決める
こういう作業です。
そしてバグチェックも同じです。
「動いた」だけでは終わりません。
- 日本語で壊れないか
- カンマ入りデータで壊れないか
- 改行入りデータで壊れないか
- 空欄があっても壊れないか
- 同じidが出ても壊れないか
- 存在しないファイルで壊れないか
- 保存中に失敗しても元データを消さないか
- 既存データを上書きしないか
- 環境差で壊れないか
- アップデートで壊れたときにどうするか
ここまで見る必要があります。
頼む側が「どう使うか」を共有しないまま依頼すると、これらの想定を全部作る側が背負うことになります。
これが重い。
作業そのものより、未定義を埋めることが重いのです。
修正ループに入ると、終わりがなくなる
もう一つ重いのが、修正ループです。
最初は「最低限でいい」と言われます。
でも、動くものが見えた瞬間に、要望が増えることがあります。
- やっぱりここも変えたい
- やっぱりこの表示にしたい
- やっぱり編集機能もほしい
- やっぱり削除機能もほしい
- やっぱり検索条件を増やしたい
- やっぱり別ファイルにも対応したい
- やっぱり日本語の並び替えもしたい
- やっぱりUIをもう少しわかりやすくしたい
これは悪気があるとは限りません。
使ってみて初めて、欲しいものが見えてくることはあります。
でも、無料で受けた側からすると、この「やっぱり」が非常に重い。
なぜなら、最初の時点で範囲が決まっていないからです。
範囲が決まっていない依頼は、あとからいくらでも広がります。
「これもできる？」
「ここだけ直せる？」
「前作ってくれたやつなんだけど」
「壊れたから見て」
こうなると、作った人がずっと呼ばれます。
これは、ただの修正ではありません。
無料の修正ループです。
そして、修正ループは時間だけでなく、頭の切り替えコストも大きいです。
自分の開発をしている途中で、友達のツールのエラー対応に戻る。
自分のアプリを直したいのに、別の人の個人最適ツールの要望を読む。
自分のCodex枠を使いたいのに、友達用の修正で消費する。
これは普通に赤字です。
いちばん重いのは「作ること」ではなく「終わらないこと」
技術系のお願いで怖いのは、最初の作業だけではありません。
本当に重いのは、その後です。
最初はこう言われます。
「簡単でいいから」
「最低限でいいから」
「とりあえず動けばいいから」
しかし、実際にはこうなりがちです。
- エラー出た
- 動かない
- 日本語が文字化けした
- 保存できない
- やっぱり編集もしたい
- やっぱり削除もしたい
- やっぱりタイトルで並び替えたい
- やっぱり別のCSVにも対応したい
- ツールをアップデートしたら壊れた
- 前に作ってくれたやつ、また直して
つまり、一度触った瞬間に「この人が見てくれるもの」と認識される可能性があります。
これは、作業そのものよりも、責任の紐づきが重い。
作ったら終わりではなく、壊れたら呼ばれる。
直したら、また次の要望が来る。
一度無料で見たら、次も無料で見てもらえると思われる。
ここで発生しているのは、ただの友達相談ではありません。
無料保守契約の入口です。
「冷たい」は人格攻撃で、論点がずれる
断ると、「冷たい」と言われることがあります。
でも、これはかなり危ない言葉です。
なぜなら、「冷たい」という言葉は、作業負荷の話を人格の話にすり替えるからです。
本来の論点は、次のようなものです。
- 誰が調査するのか
- 誰が要件定義するのか
- 誰が設計するのか
- 誰が実装するのか
- 誰がデバッグするのか
- 誰がバグチェックするのか
- 誰が修正ループを止めるのか
- 誰が保守メンテするのか
- その時間とツール使用枠は誰の負担なのか
ところが、「冷たい」と言われると、話がこう変わります。
- 優しいか
- 冷たいか
- 友達思いか
- 薄情か
これは論点が違います。
問題は性格ではありません。
問題は、無料でどこまで背負わせるのかです。
技術系のお願いに対して「無理」と言うのは、人格の問題ではありません。
作業範囲と責任範囲の問題です。
「冷たい」と言われたからといって、相手の未定義・未調査・未実装・未デバッグを背負う必要はありません。
「Codex高い」と言うなら、他人のCodex枠を無料で使わせるな
さらに矛盾しやすいのが、AIツールやコーディング支援ツールの話です。
たとえば、相手がこう言うとします。
「Codex高いな」
「課金は考え直した方がいいよ」
「自分はこれしか使わないから課金したくない」
それ自体は、個人の判断なので別にいいです。
でも、そのうえで他人に「じゃあ作って」と頼むなら話が変わります。
自分では高いから使いたくない。
自分では課金したくない。
自分では調べたくない。
でも、相手のCodex枠や時間は使いたい。
これはかなり都合がいい話です。
AIツールには使用制限があります。
コーディング支援ツールにも、時間・回数・処理量の制限があります。
そして何より、使う人の集中力にも限界があります。
その枠は、相手が自分の開発、自分のアプリ、自分の仕事、自分の収益化のために使うものです。
それを、個人最適化された友達用ツールに無料で使わせようとするなら、少なくとも相手のコストを想像するべきです。
「高いから自分は使わない」
「でも相手には使わせる」
「断られたら冷たい」
これは、さすがに筋が悪いです。
「断るのが冷たい」のではなく、相手の負荷を想像しない方が冷たい
断られた側は「冷たい」と感じるかもしれません。
しかし、よく考える必要があります。
自分は調べない。
自分は課金しない。
自分は仕様を決めない。
自分はどう使うかも共有しない。
自分は実装しない。
自分はデバッグしない。
でも相手には、調査・要件定義・設計・作成・修正・保守まで求める。
この状態で、断られたら「冷たい」と言う。
それは本当にフェアでしょうか。
むしろ、友達なら相手の負荷を想像するべきです。
技術に詳しい友達にも、自分のやりたいことがあります。
自分の開発があります。
自分のアプリがあります。
自分の収益化があります。
自分の学習があります。
自分のAIツールの使用制限があります。
相手に頼むということは、単に「少し時間をもらう」だけではありません。
相手の集中力、判断力、ツール制限、将来の資産化時間まで使うことになります。
そこを想像せずに「友達なのに冷たい」と言う方が、むしろ冷たいのではないでしょうか。
「自分でやって詰まった1点なら見る」と「最初から丸投げ」は違う
大事なのは、頼み方の違いです。
たとえば、次のような相談ならまだわかります。
「自分でここまでやった」
「このGitHubの手順でインストールした」
「このエラーが出た」
「この部分だけ意味がわからない」
「試したことはこれ」
「この1点だけ見てほしい」
これは、助けやすい相談です。
一方で、次のような相談は重いです。
「何を作ればいいか整理して」
「GitHubを読んで」
「仕様を考えて」
「どう使うかはそっちで汲み取って」
「バグも先に見て」
「動くようにして」
「エラーが出たら直して」
「後から変更も見て」
「でも無料で」
これはもう、相談ではなく丸投げです。
この2つを同じ「友達へのお願い」として扱ってはいけません。
「自分でやったけど、この1点がわからない」なら助けやすい。
「何もやってないけど、全部作って」は重い。
この違いを見ないまま「断るなんて冷たい」と言うのは、相手の工数を見ていないということです。
技術に詳しい人の時間は無料ではない
技術に詳しい人は、簡単そうに答えることがあります。
だから、頼む側は勘違いしやすい。
「すぐわかるんでしょ？」
「詳しいから簡単でしょ？」
「AI使えばすぐでしょ？」
でも、早く見えるのは、その人が今まで積み上げてきた知識や経験があるからです。
見えないところで、次のような能力を使っています。
- 問題を分解する力
- 仕様を整理する力
- バグを予測する力
- 既存コードを読む力
- ツールの制約を理解する力
- 事故りそうな部分を先回りする力
- 使う人の行動を想像する力
- 後から保守が発生するかを見積もる力
- 修正ループになりそうな部分を先に警戒する力
これは全部、コストです。
時間だけでなく、集中力も使います。
そして個人開発者なら、その時間は自分のアプリ、記事、サービス、収益化、学習に使える時間でもあります。
相手の時間を使うということは、相手の未来の資産化時間を削ることでもあります。
友達なら無料で何でも頼んでいいわけではない
もちろん、友達を助けること自体が悪いわけではありません。
困っている友達にアドバイスする。
エラーを一緒に見る。
調べ方を教える。
方向性だけ示す。
これは普通にありです。
でも、友達なら何でも無料で頼んでいいわけではありません。
むしろ友達だからこそ、相手の負荷を想像する必要があります。
頼む側がやるべきことは、最低限あります。
- 自分で調べる
- 自分で試す
- どこで詰まったか説明する
- エラー文を出す
- 何を作りたいかを言語化する
- どう使うのか共有する
- どこまで頼みたいのか明確にする
- 相手の時間や集中力にコストがあると理解する
- 作業が大きいなら、お金を払う意思を持つ
ここを全部飛ばして、
「よくわからないから作って」
「自分は課金したくない」
「これしか使わないから自分ではやりたくない」
「どう使うかはなんとなく汲み取って」
「でも欲しい」
「断るなら冷たい」
となると、それはさすがに違います。
自分のコストは払いたくない。
でも相手のコストは使いたい。
それは、友達へのお願いではなく、相手の時間と能力を無料で使う行為です。
断り方の例
角を立てすぎずに断るなら、次のように言えば十分です。
冷たく感じたならごめん。
でもこれは軽く見る範囲を超えてる。
調査、要件定義、実装、デバッグ、バグチェック、修正ループ、保守メンテまで入りそうだから、
無料で丸ごと背負うのは無理。
自分でやって、具体的に詰まった1点なら見る。
でも、最初から作るところ全部は自分でやってほしい。
もっと短く言うなら、これです。
自分でやって詰まった1点なら見る。
でも、調査・設計・デバッグ・バグチェック・修正ループ・保守まで丸投げは無理。
友達ノリなら、これくらいでもいいでしょう。
それは自分で作ってくれー。
無料保守メンテ担当には就任しません。
詰まった1点だけなら見る。
頼む側がやるべき最低限
技術に詳しい友達へ相談したいなら、最低限これを用意した方がいいです。
1. 何をしたいのか
2. どう使うのか
3. どこまで自分でやったのか
4. どこで詰まったのか
5. エラー文やスクショ
6. 試したこと
7. どの1点を見てほしいのか
8. 作業量が大きいなら、お金を払う意思があるか
これがあるだけで、相談の重さはかなり変わります。
逆に、これがない状態で「作って」と言われると、相手はあなたの未整理な頭の中まで整理することになります。
それはもう、友達相談ではなく、無料要件定義です。
まとめ：友達なら、相手のコストを想像する
友達だから助ける。
これはわかります。
でも、友達だから無料で何でも頼んでいい。
これは違います。
特に技術系のお願いは、外から見えるよりずっと重いです。
「ちょっと作って」の中には、調査、要件定義、実装、デバッグ、バグチェック、修正ループ、保守メンテが隠れていることがあります。
特に重いのは、要件定義とバグチェックです。
どう使うのかも共有されないまま、未定義部分を全部相手に埋めさせるのは、かなり重い負荷になります。
さらに、完成後は「やっぱこうして」「壊れた」「ここも直して」の修正ループになりがちです。
頼む側は、相手の負荷を想像する。
断る側は、自分の時間と集中力を守る。
そして、助けるなら「詰まった1点だけ」にする。
これくらいの境界線がないと、友達関係はすぐに無料外注レーンへ落ちます。
断る側が冷たいのではありません。
何も努力せず、相手のコストを見ず、断られたら「冷たい」と言う方が冷たい。
「Codex高い」と言いながら、他人のCodex枠や時間を無料で使おうとするのも筋が悪い。
友達なら、なおさら相手の負荷を想像するべきです。
