みんなの「作ってみた」

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

2017/12/10

lldev2
lldev2
LL言語の開発に関する話題を紹介していく予定です。 特にオブジェクト指向に関する連載を予定しています。 予備知識がなくてもある程度は文脈で分かるように、 (詳しさよりも)分かりやすい文章を意識しています。 文章の割合が高いものははてなブログで、 コードの割合が高いものはQiita、質問と回答はTeratail、 とサービスを使い分けたいと思います。

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

まえがき

個人開発 Advent Calendar 2017 - Qiita

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

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

開発者より利用者の視点

プログラムとソフトウェアの違い

Lisp竹内氏「プログラミングには地を這うような努力が必要」 (1/2) - @IT

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

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

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

あの大企業も小規模開発からスタートした

たとえばなぜ、AppleやMicrosoftが大企業になれたかといえば、GUI(OS)のパソコンが、ユーザに使いやすかったからでしょう。CLIのパソコンなら、それ以前からあったわけです。

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

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

個人開発ほどユーザ視点が重要

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

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

汎用より特化した分野

しかし、次のような感想を持たれるかもしれません。

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

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

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

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

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

完全より完成

Done is better than perfect.
(実行は完全に勝る)

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

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

汎化より特化

完成するまで特化せよ

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

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

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

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

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

ドメインを絞る具体例

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

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

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

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

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

結論

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

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

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

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

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