プログラムは手段だけど、せっかく作るなら儲かって綺麗にこしたことはない。

コードは綺麗だけど儲からないプロジェクトと、
コードは糞汚いけど儲かるプロジェクトのどっちがいいですか？

もちろん、コードは綺麗で儲かるプロジェクトがいいのは理想ですが、今回は、この2つです。

コードは糞汚いけど儲かるプロジェクトの場合、次期バージョンとかの予算を確保することができます。
そこで、汚い部分を捨てて書きなおすことだって出来ます。

コードは綺麗だけど儲からないプロジェクトは、次のバージョンの改修費用もでずにゴミ箱に送られる運命です。
プロジェクト解散、メンバーは散り散りです。

フリーソフトの場合は、儲かるをユーザに使ってもらえるソフトとか支持されるソフト、
ゲームの場合は、儲かるを面白いゲーム、支持されるゲームとかと適当に読み替えてください。

コードは綺麗に越したことはないです。
だけど、プロジェクトとして成立しないことには意味がありません。

コードは綺麗だけど、誰も遊んでくれないゲームとか、
文法は綺麗だけど、誰も読んでくれない小説とか、
綺麗な絵だけど誰も見てくれない絵とか、そんな感じです。たぶん。

儲かるプロジェクトってどう作るの？

では、どうやったら、儲かるプロジェクトができるんでしょうか？
それは神のみぞ知るです。(私も知りたいです。)

何が儲かるかわからないです。
どっかでみたプロジェクトの焼き直しでも、伝え方やユーザへの提供の仕方、時期、値段、時の運で勝敗は変わります。

ただ、１つだけあるとすれば、バットを振ってみないことにはボールには当たらないということです。

とにかくプロジェクトを出してみて、ユーザにこれどうすか？と聞いてみないことには、売れるかどうかわからないです。
売れるとわかったら、それを走りながら増強して行く感じだと思います。
売れないとわかったら売れる路線に変更していくしかないと思います。

だから、早くプロジェクトを作って、ユーザに聞いてみないといけません。
そのためには、迅速に動けないとダメです。
だから、クソみたいなコピペコードでも、綺麗なコードでも、とにかく動かなければいけません。
ちゃんと動作して、ユーザの役に立つコードでなければいけません。

この段階では、プログラムはただの手段です。

技術的負債

コードはいつかは行き詰まります。
どんなに綺麗に作られたソフトウェアでも、数年間修正を繰り返すと、制度疲労がでてきます。
クソコードだと、もっと早く行き詰まりが出てくると思います。
スパゲティすぎて意味不明になります。

技術的負債というやつです。
僕は保守の魔物と呼んでいます。保守の魔物が足に絡みついてだんだん動けなくなります。
ちょっとした修正に膨大な工数がかかるようになります。
そうなった時、プロジェクトが儲かっていれば、技術的負債を返すチャンスがでてきます。

より綺麗で保守しやすいコードに書き直すチャンスがでてきます。
もっと高く跳ぶために、一度力を蓄えることができます。

この技術的負債を返す時には、プログラムはある程度目的になります。
より綺麗で保守しやすいコードに変化します。(ただ、もちろん、現実的な予算と期間がありますけど。)
そうやって、プロジェクトは進んでいくんだと思います。

技術的負債(保守の魔物)をどう考えるかは、経営判断 (CTOとか)の仕事になると思います。
どこで、ジャンプの力を蓄えるかです。
力を蓄える間は、新しいものを作るリソースも予算も少なくなりますしね。
その間に競合に出し抜かれてしまうかもしれないし、動きの早いベンチャーに足をすくわれるかもしれないし、不況に成るかもしれないです。

ようするに、クソコード == 賞味期限の短いコードです。
そこをどうコントロールするか、それが開発者(や経営層)の戦略になるかと思います。

これは、関数やクラスの使い回し戦略と同じですね。
どれだけ複数のプロジェクトで、再利用するか？っていう戦略があったかと思いますが、それととても似ていると思います。
この部分は使いまわして、ここはビジネスロジックだからプロジェクトごとに総取替えにして・・・とかをきめるアレです。
戦略のカジをどう切るか、腕の見せ所です。

私が思うに、
使い回しをして長く使う可能性が高いライブラリとかは、注意して綺麗に書いて、
ビジネスロジックは捨てることを前提で速度重視でクソコードでお手軽に生産するが合理的だと思います。

ま、各社の戦略次第ですけどなw

で、プログラムは目的じゃいけないの？

それでもいいんじゃない？
美味しく食べるために料理する人もいれば、料理の過程を楽しむ人もいます。
いろいろな考えがあっていいと思います。

ただ、最初に書いた、クソコードだけど儲かるプロジェクトの話しと、ソースコードの賞味期限の話しから、結局は費用対効果になると思います。

幸せなコードとともにあらんことを。

捕捉

汚いコードであればそもそも完成しないのでは？

ユーザにとって価値のあるものを早く提供するのが目的です。
その目的を達成できなければ、意味がありません。
目的を達成できる範囲であることは大前提です。

汚いコードは早く作れて、綺麗なコードは遅くしか作れないのか？

綺麗なコードで早く作れればそれでもいいです。
乱暴な言い方をすると、目的を達成できれば手段はどうでもいいのです。

うちのコードは汚くて、改善するための予算が取れません。

こっそりと少しずつ直していくというのも手です。
ゆっくりと古いコードを少しずつ安楽死させていきます。
ただ、それすらもできない、改修もできないのであれば、
保守の魔物が利益を侵食しますので、近々財務状況にもそれが現れてくるのではないのでしょうか？
転職を検討されることをおすすめします :p)

保守の魔物の度合いを見る方法はあるか？

保守の魔物とその解決についての、私の中でのサンプル数がまだ少ないので手法が確立できていません。
修正するのにめっちゃ時間とカネがかかりはじめた時には、保守の魔物がやってきている感じでしょうか。
プログラム資産も監査できるようになれればいいですね。