個人開発で間違えやすい3つのポイント

#個人開発で間違えやすい3つのポイント
##まえがき
[個人開発 Advent Calendar 2017 - Qiita](https://qiita.com/advent-calendar/2017/private-development)

「個人開発 Advent Calendar 2017」（上記参照）に参加させて頂いております。

本記事は、**個人開発**で**間違えやすい点**を、**3つ**にまとめました。考え方の違いなどあるかもしれませんが、ひとつの考え方として参考までに。


##開発者より利用者の視点
###プログラムとソフトウェアの違い
[Lisp竹内氏「プログラミングには地を這うような努力が必要」 (1/2) - ＠IT](http://www.atmarkit.co.jp/ait/articles/1108/29/news116.html)

> 「ソフトウェアとプログラムって、どう違うか知っていますか？」
「他人に使ってもらうのがソフトウェアで、自分が使うだけでよいものがプログラム」

上記記事で竹内郁雄氏の発言にあるように、**ソフトウェア**には**利用者**がいます。
プログラムとソフトウェアの差に、**開発者と利用者の差**があるわけです。

プログラミングできることは前提として、その上でさらに、
使いやすいソフトウェアを開発するためには、**ユーザ視点**に立つ必要があります。

###あの大企業も小規模開発からスタートした
たとえばなぜ、AppleやMicrosoftが大企業になれたかといえば、GUI（OS）のパソコンが、ユーザに使いやすかったからでしょう。CLIのパソコンなら、それ以前からあったわけです。

「個人開発」というテーマで、この例には違和感があるかもしれません。が、BASICインタプリタなど、MS最初期の製品は、ビルゲイツ氏が自らプログラミングしていました。つまり、ゲイツやジョブズも、**最初は小規模開発からスタート**したのです。

プログラミングが上手い人間はたくさんいるのに、なぜ彼らが大成功したかといえば、それだけユーザに**価値**を提供したからです。XP提唱者のケント・ベック氏も、ユーザにとっての価値は重視しています。


###個人開発ほどユーザ視点が重要
ここは間違えやすいところですが、**個人開発のような小規模開発ほど、ユーザを意識する必要**があります。逆に、大企業の大規模開発だと、分業化が進んでいるので、コーディングに専念するだけで済んでしまう場合もあるでしょう。

だから、個人開発では、プログラミングするだけではなく、営業や広報の役割もこなさなくてはなりません。ユーザに**知られなければ、ないも同然**だからです。


##汎用より特化した分野
しかし、次のような感想を持たれるかもしれません。

「ひとりで色々こなすには、時間が足りない」

これは、**みんなそう**だと思います。人間全員が一日24時間なのだから、割ける時間に合わせて、ソフトを**特化**することが重要になります。「ランチェスターの戦略」にも沿っています。

端的に言って、100人で開発したソフトと、1人で開発したソフトでは、どうがんばっても大差が出てしまいます。ExcelやPhotoshopのマネをしても仕様がない。だから、大規模開発では採算が取れないからやらないような、**ニッチな需要**を探していくことになります。

この需要が大きすぎると、たいていすでに競合がいるし、あまりに小さすぎると個人開発でも割に合わない、ということになります。だから、**需要の粒度**を見極める必要があります。


##完全より完成を目指す計画
###完全より完成

> Done is better than perfect.
（実行は完全に勝る）

上記引用（訳は筆者）は、Facebook社のマーク・ザッカーバーグ氏の座右の銘らしいです。不完全でも動くアプリの方がマシである、という場合は実際多いと思います。

しかしここで、「ユーザ視点」や「特化しろ」、「完成させろ」といった言葉は、読者のみなさんも何回も聞いていて、「とっくにもう分かってる」、「聞き飽きている」と思うかもしれません。それでは、これはどうでしょう。


###汎化より特化
「**完成するまで特化せよ**」

これは私が考えた言葉です。完成できないようなら、完成するところまで特化していき、作業量を減らすことで完成できるようにしろ、ということです。

ここで、完成するまで特化するにも、「ユーザ視点」が必要です。なぜなら、機能を増やそうとするときには、作ろうとする分野の他のソフトを見れば、増やす項目自体はかんたんに見つかります。

しかし、減らす方向だと、**ユーザの利用目的を深く理解していないと、捨てられる機能を選ぶのが難しい**。

そして、しがらみのない**個人開発だと、計画を縮小できることがメリット**なんです。受託なら契約があるでしょうし、大規模開発だと勝手に縮小できないことが多いでしょう。家電のリモコンのボタンが増えていくみたいなことでしょうか。

もしかすると姑息な印象を持たれるかもしれませんが、「**計画を縮小して完成させる**」のは、非常に実践的な開発のテクニックだと思います。


###ドメインを絞る具体例
イメージしやすいように、具体的な例を出しましょう。たとえば、将棋ソフトで最新のAIに勝つのは非常に難しい。しかし、詰め将棋に特化したような、別の角度から見たソフトもありえるわけです。麻雀なら「何を切る？」とか。あるいは、RPGからADVゲームを抽出してもいいわけです。

ここでは話を分かりやすくするために、将棋や麻雀やRPGといったメジャーな分野の例を出しましたが、実際の開発では、**専門外の人間にはまるで意味が分からない**ようなソフトになるかもしれません。しかし、**個人開発ではそれで良い**のです。ドメインを絞るというのは、まさにそういうことです。

ちなみに、私が開発しているソフトも、非常にマニアックなものです。同様のソフトを開発している人間が少ないだろう、と予測できるものです。こういう物を作ろうと**発想できない時点で競合が減る**から、都合が良いのです。逆に、**みんなが思いつくような分野は、必ずレッドオーシャン**になります。

みんなが集まる分野で開発速度を競う、**鬼ごっこ型の開発**をすると苦しいです。うかうかしてるとすぐレッドオーシャンになり、手が早くないと競合に埋もれてしまいます。とくに、大企業が参入してくる分野だと、もう個人開発では割に合わなくなりがちです。

一方、競合に見つからないように特化する、**かくれんぼ型の開発**だと、追われて急ぐ必要がなく、マイペースに開発を進められます。かくれんぼ型の方が、個人開発には向いてると思います。


##結論
- 開発者より利用者の視点
- 汎用より特化した分野
- 完全より完成を目指す計画

最後に、改めてまとめると、上記の3つが個人開発で重要なポイントです。

**利用者の視点で、完成するまで特化する**。
言葉にしてしまうと簡単ですが、これを実行するのは難しいです。

なぜなら、「**誰もが認めるような、汎用的で完全なもの**」をみんな作りたいからです。
しかしまさに、それこそが**個人開発の典型的な失敗要因**なのです。

**特化するほど実現確率が上がる**ので、
**ドメインが何か**、**もっと特化できないか**、というのは、
とくに開発が困難に思えたときには、何度も問い直す必要があります。