1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

誰からも頼まれていないのにコードを書く機会を作り続ける秘訣

Posted at

2020年のゴールデンウィークを、黙々とコードを書いて過ごした。仕事でコードを書く必要性が皆無な職種だが、それでもコードを書き続けることで仕事での重大な局面を何度も切り抜けてきたし、色々と得してるんじゃないかと思ってる。

ふと、現場での経験に恵まれず、才能を発揮できていないプログラマがいたら、この「誰からも頼まれていないのにコードを書く機会を作り続ける秘訣」は役に立つんじゃないかと思ったので、ちょっと書いてみようと思う。

#1.自分が使うものを作る

10年ぐらい前にプログラムのコンテストに出てトイレを探すサービスを作ったことがあった。当時に一緒になったメンバーが街でトイレを探す機会が多いからと考えたサービスだ。このサービスを作ったことで、賞もいただけたし、手を出さなかったけど、アプリへの広告掲載などの話もあった。ただ、機能追加を続けるのは2年が限界だった。どうも自分にはトイレを探す才能が備わっていて、自分でアプリを使ってトイレを探すことがなかったのだ。

アプリを書くキッカケとして、誰かのニーズを汲むことは否定しない。ただ、コードを書き続けたいのであれば、自分自身のニーズと向き合うことが重要だ。世界中で何万人が困っている問題に目を向けたがる人もいるが、その何万人に自分が含まれていないアプリに、どれだけ時間をかけられるのだろう。

#2.作る前に市場調査をしない

自分が使いたいものを思いついたとする。そうしたら、その瞬間からインターネットで検索するのをやめ、プロトタイプを作り始める。検索すれば便利なソリューションに出会えるかもしれない。でも便利なソリューションに出会っても、コードを書くモチベーションを保ち続けられるだろうか。

報酬のために働いているのであれば、じっくりと競合を研究し、クオリティを高めるべきだ。ただ、報酬とは関係なく「自分のためにコードを書く」ということを優先させるのであれば、貴重なモチベーションを無駄にしてはいけない。

#3.まずExcelで作ってみる

あまり世間で見かけることがないアドバイスかもしれないが、もし自分自身のニーズを満たせるサービスを思いついたら、ワイヤフレーム(画面のモック)を考えるより先に、Excelなどの表計算ソフトで入力データと出力データをシミュレーションしたほうがよい。APIなどで何か役に立つ情報が得られるとして、そこから自分が欲しい情報に加工できるか。もしくは手入力するとして、現実的なインプットで意味のあるアウトプットが得られるか。ここを見誤ったままデータベースを作ってしまうと取り返しがつかない。

簡単に入手できるデータでは容易に価値のあるアウトプットを提供できないことが露骨にわかってしまうので、何も作れなくなるというジレンマに陥る可能性もある。でも、ここをクリアできないと継続できるサービスになりえない。というか、いきなりワイヤフレームを書かせるメンターって、どれだけ騙された回数が少ないんだろうかと。

#4.宣言とか公開とかしない

SNSなどで「連休中に、こういうサービスを作る」みたいな宣言を見かけることがあるが、これも逆効果だ。せっかくコードを書く気になったのに「このアプリで十分じゃね」という親切で迷惑なツイートを見てしまうかもしれない。また、逆に期待されてしまっても、自分の中でイマイチだと思っても方向転換しにくくなり、イマイチなものを作るために貴重なモチベーションが浪費する。

制作過程をツイートで残すのもやめたほうがいい。もし誰かに応援してもらいながら作りたいなら、何を作って、どんな問題を解決するのかは我慢して、技術要素だけ喋ればいいと思う。

#5.テーマにお金を使う

経験豊富でないので的はずれなことを書いてしまうかもしれないが、一般的にフロントエンドと呼ばれる領域は学習コストが高いと言われている。料理に例えると、調味料の微妙な加減を見極めるようなものだ。しかも、その調味料のトレンドが2〜3年で入れ替わる。

個人でサービスを開発・運営してる人と情報交換しても話題になることが少ないが、Bootstrapなどメジャーなフレームワークは有料のテーマがあって、高品質なデザインを買うことができる。もちろん無料でクオリティの高いテーマもあるが、どこかの誰かが使ってる可能性が高い。

#6.別の言語に置き換えてみる

基本的に、個人開発なのだからアーキテクチャも自由に選べる。かつて集まったメンバーの共通言語(例えばRuby)でサービスを作ったが、あまりにメンバーが役に立たないから自分が使いやすいPythonで書き直し、さらにFacebookのSDKを使いたくなってPHPで書き直したことがあるが、こんな感じで自分の興味の赴くままに過去のリソースを捨てられるのは個人サービスの醍醐味だ。

アイデアに出会う頻度と、技術に出会う頻度は人それぞれだ。もしアイデアに出会えなくて、でも技術を試したくてしょうがなかったら過去に自分が書いたものを別の言語で書き直せばいい。自分は最近では、Pythonで書いたものをRustに置き換えているが、適当なチュートリアルより達成したときの満足度が高い。

#7.コンテストは締切にはなるが・・・

自分はMaker FaireやMashup Awardなどの締切をひとつのターゲットとして設定していた時期があった。他の参加者の作ったものをじっくりと見て刺激を得られるし、勝ち残れば参加者同士の交流を深める場にもなる。あえて言うなら、コンテストが求める領域と自分がやりたい領域が重なることは稀なので、そこにこだわるのではなく、割り切った付き合いがいいと思う。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?