ごめんそれダメな例
1.（個別のソリューションに対応したソフトウェアを）より低コストで開発する
プログラマの単価を上げるには - firewood's diary
2.（個別のソリューションに対応したソフトウェアを）より高機能化して対価を増やす
3.（汎用のソリューションに対応したソフトウェアを）製品化して複数の顧客に売る
これでプログラマの給料が上がった例を私は聞いたことが無い。
上がるのは営業か元請けの誰かだ。
はっきりいってプログラミングで「単価」だのとちっちゃい事言われてる時点ですでに負け犬。
できることはせいぜい５人月で出した見積もりを４人月で作る程度。
良い客を捕まえないことには元請けだろうがダメなものはダメ。*1
それにあたってはまず
プログラマがコストをかけながら書いている。コストがかかるから対価も生じる。
プログラマの単価を上げるには - firewood's diary
この考えだけは絶対に捨てた方が良い。
がんばったんだからお金ください ってか？ なんかもう負け犬すぎて悲しくなる。
あるソフトウェアの価値＝ユーザーの満足度の総量
プログラマの単価を上げるには - firewood's diary
満足に対価を払うなんてあたりまえのこと。 じゃ、どうしたら満足なのよ？ってのがプログラマと客でずれているのが問題。
客の問題が解決された状況を「満足度」だなんて漠然としか認識できないのであれば、客を満足させられようも無い。
だからこそ、そもそも客自身が「自分たちはどうなれば満足なのか」を具体的に理解できていなければ「エンジニア*2」として乗り込むのは非常にリスキーな事になる。 そこにはコンサルタントでも突っ込んどけば良いんだ。
じゃあどうやってプログラマの報酬を上げればよいのか？
それは「作らない事」「プログラムを書かない事」*3。 そのうえで「作らない事」に価値があると考えている客を捕まえる事。
作らないのだからドキュメントも分担も伝達ロスも関係ない。
それを突き詰めれば突き詰めるほどソースコードに集積される価値は膨大な額になり、働いた時間ではなく、出したアイデアに対価を払ってもらえるようになる。
