現在趣味で Web サービスを作っています。今年の 4 月末くらいから準備をし始めていたので、かれこれ 4 ヶ月くらい開発を進めています。一人きりの開発+完成したとしても実際に使ってくれる人がどのくらいいるか分からないという状況ですが、なんだかんだ楽しみながら作業できています。

まだ完成もしていないので、こんな事を書くのは的外れのような気がしますが、やる気の枯渇を防ぐために自分なりに気をつけていること+やっていることを書き出しました。既に色々な方が書いているような内容なのであまり目新しいものでは無いかもしれません、あくまでも僕なりの内容となっています。

自分が使いたいものを作る

凄い基本的なことですが、凄く大事なことのように思います。今作っているのが、主に Web サイトのデザインをアーカイブしておくための(Pinterest みたいな)サービスなのですが、少し前から欲しい欲しいと思っていたものでした。

自分がよくやりがちなのが、使いたい技術が先に来てそこから作るものを決めるパターンです。最初は触ったことの無い技術に興奮して楽しいのですが、2 週間位で目新しさも無くなってきて飽きてしまいます。

個人的な開発となると、仕事のように毎日何時間も作業時間を取ることが難しいので、内容はどうあれ開発期間が月単位と長期的なものになってきます。「他の人がどうかは知らないけど、自分が欲しいから作る」みたいなお気持ちが無いと長続きしなそうです。

完成までのタスクをわりと細かく作っておく

仕事であれば実際の作業に入る前に作業工数を見積もります。ここは仕事同様、個人開発だろうと関係なく、完成(リリース)までにどのくらいの工数が必要で、どんな作業が必要か把握するためにもやっておきました。

具体的には Gist に適当なメモを作成して、その中にタスクリストを作りました。勿論該当リポジトリの Issues で管理しても良いかなと思います。

この時、ざっくりとしたものよりもある程度細かい粒度で作成しておき、チェックを付ける頻度を上げる事で進捗が感じられてハッピーです。

例えば、以下の様に何らかのアイテムを削除するという処理でもいくつか必要な実装があると思います。

## Good

- [ ] アイテム本体の削除
- [ ] アイテムの関連データを削除
  - [ ] タグ情報
  - [ ] 画像データ
- [ ] アイテム削除時のエラーメッセージ設定

## Bad

- [ ] アイテムの削除

ここをざっくりとしてしまうと、いつまで経っても進んでいる感じがせず嫌気が差してきてしまうので、少しでも細かく作っておくと良いかなと思います。

技術的な懸念は先に潰す

タスクを作る、というものと関連します。自分の持つ技術では実装が難しそうだなという箇所は予め挙げておきます。

一通り挙がったら、作業に入る前に簡単なサンプルを作ったり、ライブラリを選定します。こうすることで実装前の不安を減らし、スムーズに作業を進められるようにするのと同時に、最初に出した作業工数のブレを最小限に出来ると思います。

ちゃんとデザインを作ってから実装に入る

デザインイメージ

個人的に一番重要かなと思うのがこれです。いきなり実装に入ってしまうと、実現するための工数が少なく、楽な方に逃げやすくなりがちです。細かい箇所で妥協点が増えてしまうと、結果的に満足いくものにすることが難しいです。一つ一つの細かい妥協から全体のクオリティがどんどん下がっていくからです。

これらを避けるために最初にデザインを作ります。また、必要になる画面や操作感への考慮、作成するコンポーネントの割り出しなどもここで行えます。

何より、作っていく過程で見栄えがある程度整っていることがモチベーションに直結します。(少なくとも僕は)

一人きりの作業だと、実装+デザイン+インフラまで一通りやる必要があります。(インフラは開発内容による)それぞれの作業を行き来するのは、僕みたいに脳内メモリが圧倒的に少ない人だと一苦労です。

一つの作業に集中できるように、自分でコントロールしていく必要があります。

あと、404 とかデータが無い時のデザインも作っておくと、いざ実装に入った際に楽できるので忘れずに作っておくと良いです。(自戒…)

ロゴに手を抜かない

デザインと同様にロゴも初期段階で作っておくと、ちゃんとしてる(っぽい)感が出てきてモチベーションに繋がります。今回はデザイナーさんが作ってくれたので、自分で作るよりも断然かっちょいい感じになりました。

ロゴ

デザイナーさんに作ってもらったのは格好良いデザインにしたかったという事の他に、後述する第三者に作っていることを知ってもらう、ということとも関係します。

“楽しさ”を優先する

僕はコードを書いている時間が何より楽しいので、事前に考える事が沢山あると結構辛いです…(特にデザイン)。さっきはデザインを先に作る、というように書きましたが、ある程度デザインの方向性が決まってきたら、デザインの作業と平行してボタンなど、最小単位となるコンポーネントあたりから実装を進めちゃいました。

タスクリストを作ってしまっていても、仕事では無いし無理に順番に進めようとせず、自分が楽しいと思うことを優先させて、自分自身を飽きさせないにように工夫しています。

第三者に”作っている”を知らせる

先程書いたように、ロゴはデザイナーさんにお願いしました。自分以外の誰かを無理やり巻き込むことで意見がもらえたり、「知られてしまったからには作りきらないと！」みたいな推進力とすることができます。

こんなポエム記事を書いているのも、ブログにこんな風に書いちゃったしやりきらないとなぁ…と自分自身へプレッシャーを掛けるためだったりします。

週に 6~7 日、最低でも 1 コミットする

@t_wadaさんのOSS についてあれこれというスライド中に以下 4 つのルールが出されています。

  1. 毎日コードを書くこと。ブログ、ドキュメント、その他はコードを書いたらやってよい。
  2. 意味のあるコードを書くこと。インデントやフォーマットの修正、可能ならばリファクタリングもコード下記にはカウントしない。
  3. 深夜 24 時前に終わらせること。
  4. 書いたコードを GitHub で全て OSS にすること。

正直実現できないことが多々ですが、可能な限り毎日少しでもプロジェクトに対するコミットを行っています。スライド中にも書かれていますが、毎日プロジェクトに手を加えることで以下の問題が解決できます。

  1. 週末だけ開発、となると頭の切り替えに時間がかかる
  2. 週末の自分に期待しても思った程の進捗は期待できない
  3. プロジェクトに対する熱量を低下させない

特に 2 番目、過信は禁物ですね…。

GitHub の草の様子を眺めてニヤニヤする

GitHub,草の様子

毎日コードを書くための題材があるだけで幸せですが、それが目に見える形で残るので積極的に活用(ニヤニヤ)します。何にせよ、やる気の枯渇を避けるためならあの手この手で気持ちを高めていきます。ただし、先ほどのスライドの内容と被りますが草を生やすためだけにコミットを行うのは絶対に NG。

使ったことの無い技術も積極的に検討

よく「開発時新しく触れる技術は最低限にしておくと良い」と言われていますが、僕はあまりそう思わず、やりたいことであれば積極的に試していきたいなと考えています。慣れていない分野だと覚えるのが大変かもしれないし、リリースまでの時間が長引いてしまうかもですが、先程書いたように”楽しさ”を何よりも優先したいため問題にはしません。

ただ、「これも良いあれも良い」みたいに進まなくなることは注意してある程度進捗を出すこととのバランスは上手く取っていかないとなと思います。

作業/情報収集のバランスが難しい…

やっていることや気をつけていることとは違いますが、悩んでいる箇所です。
デザインと準備が終わり本実装に入ったあたりから、少しでも作業時間を確保するために Twitter やはてブ、Feedly の消化など、情報収集にかける時間が極端に減りました。会社へは歩いて 10 分だし、移動中にチェックするというような事は出来ず、空き時間にちらっと見るくらいになりました。

決して悪いことでは無いかなと思うのですが、情報収集ができていないことがストレスに感じることが出てきたので、ここらへんのバランスはもう少し考えていこうと思います。

無理しない

最後の悩み以外、今のところ問題になっているようなことはありませんが、これらのルールを守ろうとするあまりストレスになるようなら、無理せずやれる時にやる位のスタンスで構えています。

リリースまでまだ時間が掛かりそうなので、何よりも途中でやる気が枯渇し心が折れることを上手に避けつつ引き続き作業を進めたいなと思います。