個人開発 Advent Calendar 1日目の記事です。

こんにちは、@himatani です。今日の記事では僕が個人開発で行なっている開発プロセスであったり、気をつけていることであったりをゆるく紹介していこうと思います。もっと、こう、いい感じのやり方があるよ！という方はぜひぜひコメント欄などで教えてください！

はじめに、概要

この記事は以下の方を想定して書いています。

すでに、個人で何かつくっている方
つくりたいものがあって、これから開発していこうとしている方
つくりたいものはあるが、何からはじめていいのかわからない方
とにかく、つくることが好きなすべての方

なお、この記事で書くことのほとんどは僕の主観です。なるほど、そういう感じでやっているんですね〜。くらいのお気持ちで読んでいただければとても嬉しいです。自分の開発にも取り入れたい！と思っていただけるともっと嬉しいです。

これまでウェブのサービス開発が多かったのでウェブ寄りの内容になってしまいました。書いてから気がつきましたすいません！

開発の流れ

0. 心構え

どの言語で開発するのか
使える"武器"を増やしていく
なぜそのサービスを開発するのか
どうやって開発の時間を確保しているのか
およその開発期間は

よく、どの言語で開発しているんですか？という質問をいただくことがあるのですが、言語はなんでもいいと思っています。強いて言うなれば「詰まったときに相談できる人がいるかどうか」や「普段の業務（お仕事でも開発をされる方は）で使っていない技術」でやるといいです。使っていない技術というのはまったくかけ離れた領域ではなくて、例えば、仕事ではReactを使っているけれど個人開発ではVue.jsでやってみようとかというレベルです。まったく使ったことがない言語や技術だけで構成された個人開発はうまくいかないことが多いです。技術調査に大半の時間をとられてしまって、開発が進まなくなりモチベーションを維持するのが難しいからです。

また時間の確保ですが、僕の場合は平日の早朝や帰宅後、あとは週末にがっつり時間が割けるように調整しています。まとまった時間が取れないという方は、常にPCを持ち歩いて時間ができたときにいつでもはじめられるようにしておくと良いのかもしれません。

つくりたいサービスの構想からリリースまでの期間は、僕の場合はサービスの規模にもよりますが、およそ１〜２ヶ月（平日の夜と土日をたまに使って）でリリースまでもっていくようにしています。長すぎるとモチベーションが続きませんし、２ヶ月以上かかるということは壮大なプロダクトをつくろうとしすぎていることがほとんどのため、一度冷静になって機能の削ぎ落としや簡略化を検討すべきだと思っています。

1. 構想・ドメイン選定

どんなサービスかを一言で説明できるようにする
SNSに拡散する時のお知らせ文言をあらかじめ決める
プレスリリースをあらかじめつくってしまう

さあ実際に開発です。とはいえ、つくってみたいプロダクトのアイデアがなけれははじめりません。どうやってアイデアを見つけているかというと、僕の場合は移動中にふと思いつくことが多いです。毎朝の通勤時間や帰省の新幹線の中など「他にすることがあまりないとき」によくこういうサービスあったらいいな、と思いつくことが多いです。その場でドメインだけ取っちゃう、みたいなこともよくあります。サービス名やドメイン名は割と早くに決まることもあればリリースぎりぎりまで悩むことがあるので、早い段階から考え始めるようにしています。

開発したいプロダクトが決まったら、まず「どんなサービスかを一言で説明」できるようにしています。一言というのはおよそ、１００文字〜１４０文字くらい。これは主にサイトの <meta description> で使ったり、SNSでサービスリリースのお知らせをするときに使う文言です。伝わるかどうか、サイトに訪れてみたいと思えるかどうか、を客観的にみるようにしています。またここで準備した文言はリリースまで大事にしています。これからサービスを開発していく中で、アイデアを削ぎ落として洗練させたり、どうしても追加したい機能があって迷った時に原点に立ち返るという観点からもはじめに定めておいた方が、結果としてうまくいくことが多かったです。また、この段階で勢いでプレスリリース（もうほとんど書くことはなくなったけれど）まで書いてしまうこともあります。

2. ラフスケッチ

どんなサービスをつくりたいかがざっくりと決まった段階で、僕は必ずラフスケッチをするようにしています。本当にざっくりとで大丈夫です。この段階のスケッチでは、殴り書きのようにあれもこれも思いついたものはどんどん描き加えていきます。ブレーンストーミングに近い形で思いついたアイデアや機能はどんどん描いていきます。付箋に書き出していくのがいい、という方はそちらでもよいです。僕はビジュアルに起こしたいのでラフスケッチからはじめています。

ラフスケッチに使用しているスケッチシートは、以下のようなサイトから無料でダウンロードして印刷しています。お気に入りのサイトを見つけておくと良いかと思います。自作していたこともありますが、ダウンロードしてしまった方が断然クオリティが高かったです。Prottのようなスケッチシートも使いやすくておすすめです。僕は使うのがもったいなくてほぼ清書用になってしまいました。

3. サービス設計

このサービス誰のどんな課題を解決するのかを明確にする
ユーザーのタッチポイント、ペルソナを想定する
ユーザーのインセンティブポイントを設計する
KSF（Key Success Factor）を明確にする

僕がつくるサービスでは、実際に困っている人がいてなおかつ自分も同じことを考えている課題を解決するものが多いです。以前は語学・留学情報のキュレーションメディアをつくっていましたが、これは「留学の情報がウェブ上に散乱しすぎていて、検索しても留学エージェントの公式サイトや古い個人ブログしかヒットしない」という問題と「留学先で困りそうなことは、困ったときでないと検索ができない（検索したいワードがないと検索ができない）」という課題を解決しようとしていました。

課題と目的が明確になっていることで、モチベーションの維持がしやすくなったり、ある機能が必要か不要かで迷った時、ユーザーになってくれそうな人に「こういうサービスをつくっていんだけれど、この機能はあった方がいいの？」と実際に聞きにいくことができます。もちろん、自身が同じ課題を抱えている場合には「自分だったら欲しいと思うだろうか」と客観的にみることができるので機能追加で迷った時にとても有効です。

タッチポイントとペルソナは明確にしておきましょう。タッチポイントとはこれから開発しようとしているプロダクトとユーザーがどう接点を持つか、ペルソナとは想定される利用ケースや利用のされ方です。マーケティングでよく用いられるような、SWOT分析やAIDMA、3C分析はやっていません。そんな時間があったら、1行でも多くコードを書く方が有意義です。ただ、時間に余裕があるのであれば、ロジックツリーは「課題解決」の観点から有効です。ロジックツリーでは「Why?」を深掘りしていくことで、本当に解決したい課題を絞り込み、その課題を分解し解決策を整理することができます。

4. サービス名決定

つくりたいサービスがおおよそ固まってきたら、次はサービス名を決めてドメインを取得していきます。このフェーズは実際の開発より時間がかかることが多いので、場合によってはもっと早くからはじめたり、リリースぎりぎりまで悩むこともあります。観点としてはおおよそ以下のようなことを考えています。

その名前はユーザーにとって覚えやすいか
サービスの内容に合った名前かどうか
４文字以上であり、１０文字未満であるか
アドレスバーに入った時に違和感がないか
大文字から小文字になったときに違和感がないか
.com と .jp でドメインが取得できるか
実際に使わなくても取得しておくことが多いです

僕が以前つくっていたサービスでは「Langwall」や「LAFY」があります。これはそれぞれ Language + Wall で言語の壁を越える語学のQ&Aサービスという意味、Language for Happy の文字を取って LAFY という名前（こちらはやや後付けでしたが）で語学のキュレーションメディアをリリースしました。

5. ドメイン取得

ドメインを購入する前には、以下のことを確認するようにしています。以下はそのほんの一部です。

すでに同じような名前のサービスやアプリが存在しないか
検索した時に、SEOの観点から強すぎるサイトがすでに存在しないか
検索した時に、問題のあるサイトがヒットしないか
ハッシュタグで検索した時に全然関係のない投稿で埋もれないか
Twitter, Instagram, Google, Slack や使用したい各ツールでアカウントが取得できるか

例えネイティヴアプリであってもドメイン名は取得するようにした方がよいと僕は思います。理由は主に２つあります。１つは利用規約やプライバシーポリシー、お問い合わせなどを掲載する個別ページはウェブで管理しておきたいことと、もう１つはダウンロード用のランディングページを将来つくりたくなるかもしれないからです。すぐに使わない、とわかっていても「とりあえず取得しておく」ようにしています。

もし、しっくりくるドメイン名が思いつかなかった場合は、焦って決めない方が良いことの方が多いです。決定に時間がかかりそうな場合、自分は開発プロジェクト名（リポジトリの名前やSlackのチーム名などに使用する）とドメイン名を別で管理するようにしています。サービスのリリースぎりぎりまでドメイン名に時間を割けるようにするためです。

6. 技術調査

つくりたいのものが頭の中でイメージできるようになってはじめて、技術調査をしています。なぜ、もっと早い段階で行わないのかというと、早い段階で技術のことを考えてしまうと「技術先行のサービス開発」になってしまったり、無意識のうちに「自分が実装できる範囲内」で開発しようとしてしまうためです。これでは、少しもったいないです。

このサービスに絶対必要なのはこれとこれ、と先に決めてしまった後で「じゃあ、どうやってそれを実現しようか」と考える方がサービスの妥協に繋がらず、自分の技術力も向上するのではないかと思っています。

7. 詳細スケッチ

つくりたいものがほぼ明確に決まってきたら、再度、スケッチをするようにしています。１回目のスケッチをもとに、「そのサービスを構成するのに必要な要素は何か」を意識して無駄なものを削ぎ落としていきます。この段階までくると、おおよそのUIやサービスに必要な要素はあらかた固まってしまっていることが多いため、ほぼ清書に近いスケッチになることが多いです。ここで気をつけているのは以下のようなポイントです。

機能を削ぎ落とし本当に必要な要素を決める
文書構造をはっきりと決める
このエリアが section でこのエリアが article で、といった具合に
SEO重視のサービスの場合はこの段階でいろいろ考えておく
どういう名前のCSSのclassを振るか
僕の場合は SMACSS を採用していてスケッチの段階でほぼ命名します
メイン、アクセントで使うカラーコードをおおよそ決める
font-site, padding, margin の値をおおよそ決める
余裕があればモデル設計も簡単にやってしまう

このスケッチは、人によってデザインツールやプロトライピングツールで代用してもよいかもしれません。僕の場合は、紙に書いてしまった方が結果的に速いスピードで実装までもっていけるということがわかったので、PhotoshopやSketchはほぼ使っていません。サイトの動線や、細かい動きなど、どうしても確かめたいときはマークアップを行いながら実際に画面で確認して詰めていくようにしています。

8. 本番環境構築・初デプロイ

実際に開発をしていく前に、まずは本番環境にリリースしてみます。ドメインをすでに取得している場合は公開用のエンドポイントに実際にアクセスするようにします（検索にヒットしないように meta robots を正しく設定し最低限、Basic認証はかけておきます）。自分の中ですでに確立されたデプロイ手順がある場合はそちらに沿ってもよいですし、ひとまず本番環境からGitでpullしてしまってもよいと思います。なぜいきなりデプロイなのかというと、細かくデプロイを繰り返すルーティンをつくるためです。本番環境でないとわからないことも多いので（リリース直前になって本番環境だけ動かない、とかだとすごくモチベーションが削がれるので）こまめにリリースを繰り返し、意識して実際の本番環境でさわってみるようにします。ここで行うのはその土台づくりと習慣づくりです。

9. タスク整理

マークアップに入っていく前にリリースまでのロードマップを敷き、タスクを整理します。以前は Evernote などで管理していましたが最近では付箋で行うように変えました。大きく、開発用のタスクとそれ以外の細々としたタスクに分類し、開発用タスクの中でさらに「フロント」「サーバサイド」「インフラ」「ネイティヴ」といった粒度で分類していきます。付箋は壁やテーブルの上に直にペタペタと貼っています。完了したタスクは剥がしたり移動したりせず、１日の終わりに赤ペンなどでチェックを付けていくようなフローでやっています。

10. マークアップ

ここにきてようやくコーディング開始です。個人プロジェクトでは、デザインもフロントもサーバサイドも基本的に１人でこなさないといけないため、どの順番で取り掛かるかはとても重要です。僕の場合は、先にロジックから実装してしまうと機能重視のプロダクトになってしまったり、あれもこれも後で使うかもしれないからとりあえず実装しておこう、となってしまうことがよくありました。これは、フロントに取り掛かる頃には機能実装で消耗してしまっていてUIやデザイン面で無意識に妥協してしまったりしないためという意味と、マークアップから取り掛かることで詳細スケッチのフェーズで考えていたUIの検証ができるという意味で有効でした。

11. モデル設計・実装

ようやく、ようやく実装です。詳細スケッチで軽く考えていたモデル設計をもとに構築していきます。先にフロントのUIが実装できているので、どの機能をどうつくっていくかに集中できます。テンプレートに対して命を吹き込んでいく感覚がして僕はこの作業がとても好きです。ある程度きりのいいところまで実装が完了したら定期的に本番環境にリリースしていきます。スパンとしては２〜３作業日に１回くらいのペースでリリースを繰り返すのがよいと思います。リファクタリングは気分転換にやったりします。

12. テストコード追加

個人開発とはいえ、最低限のテストは必須で書くようにします。正直なところ、あとでいいや、と思ってこれまで書かないことも多かったのですが、結局さいごまで書かないで終わることも多く意識して書くようにしました。ただし、テストコードの追加にリソースを奪われないように調整はしましょう。個人開発では特にリリースまでの時間を最小限にしたいため、僕の場合は、テストを書く暇があったら1行でも多くコードを書いて実機できちんと動作確認するように意識しています。

13. デプロイフロー確立

もうすでに、おおよそのデプロイフローもこのフェーズになると確立されていることが多いです。まだ本番環境からGitのpullでリリースを繰り返しているという場合は、CapistranoやChefでのデプロイに置き換えていきます。余裕があればCIも導入してもよいですが、僕の場合はリリースしてから落ち着いてやるか、そもそもやらないことも多いです。リリースすることが一番大事です。

14. ベータ版リリース準備

ここまでの実装が順調に進行していれば、いつでもリリースができる状態になっているはずです。定期的にリリースを繰り返し、本番環境でも動作確認ができている状態で実機からも正しく動作することが確認できているでしょう。プロダクトの規模によって全然変わってきますが、ここまでおよそ１〜２ヶ月で到達できていると理想です。

以下は僕がリリース前に最低限、実施しているチェックリストです。

付箋で整理したタスクが完了しているか
完了していない項目がある場合は、リリース後に見送って問題ないか
すべてのページが表示崩れなく正しく表示されているか
すべての機能にエラーなく動作しているか
すべてのフォームが適切にバリデーションされているか
すべての素材（JavascriptやStylesheet、Imageの類）が最適化されているか
すべてのテストが通っているか、Lint Checkが通っているか
ログが正しく所定の場所に出力されているか
サーバのログ、アプリケーションのログ、バッチの実行ログ、DBのログなど
Analytics用のコードが正しく挿入され動作しているか
自分のアクセスが集計されないように設定済みか
その他、最低限必要な設定が終わっているか
本番環境でのアラートの発生したときやサーバがダウンしたとき、それを知るすべはあるか
Slack やメールで通知が飛ぶように設定します
負荷が高まった時に冗長化する手段があるか、または、それを知るすべはあるか
httpsで問題なくアクセスができるか、wwwありなしが統一されているか

15. ベータ版リリース

リリース前チェックリストが完了すればいよいよベータ版としてリリースする準備が整いました。もちろん、プロダクトの規模によってはいきなり正式リリースとしてしまってもよいです。僕はいつもひっそりとベータ版としてリリースし、３ヶ月くらい保守運営しながら、正式リリースに持っていくことが多いです。

16. リリース後

リリース後もいただいたレビューやコメントはどんどんサービスに反映させ続けます。SNSのタイムラインい流れるコメントを追ったりユーザーへのヒアリングを定期的に行ったり、保守運営し続けるのはとても骨の折れる作業ですが、正しく努力していれば相応のフィードバックをいただけるはずです。リリースを繰り返すうちに、今回紹介した 1. 構想・ドメイン選定 から 14. ベータ版リリース までに要する時間もどんどん効率化できるようになってくるでしょう。

17. おまけ

最後に僕が個人開発でよくつかっているツールをまとめておきます。Macアプリが中心ですが、ぜひ参考にしてみてください（言われなくても知っているよ！というものは今回外しました）。

Macアプリ

Google Chrome Canary
言わずと知れた開発者向けのChrome、黄色でかっこいい
Bear
テキストエディタ・アプリ。思いついたアイデアを書き溜めている
iPhone版もあってありがたい
Ember
画像管理ツール。気になったUIやデザインなどをスクラップできる
ひととき開発がとまって利用できなくなっていたが、最近になってEmber 2として戻ってきた
iHosts
Hostsを簡単に切り替えることができる
いちいち sudo vi /etc/hosts ってやらなくてよくなる
メニューバーに常駐してくれるので便利
Sequel Pro
PHPMyAdminのすごい使いやすいやつ
データベースの内容をGUIで直感的に操作できる。Proといっているのに無料で利用できる
GIPHY
Gifアニメーションがすごい直感的につくれる。操作性もよくて言うことなし
Image Optim
画像最適化ツール。ドラッグ&ドロップで画像サイズを抑えられる

ブラウザアプリ

Favicon Generator
Faviconを高品質につくることができる
Sass Color Generator
Sassの色を lighten や darken をパーセント単位で指定し、色味を確認できる
ui Gradients
CSSのグラデーションをいい感じに生成、確認できる
Color Space
カラーコードを入力するといい感じのカラーパレットを教えてくれる
wordmark.it
Macにインストールされたフォントを一覧にできる
OGP画像シュミレータ
Facebookに投稿された時のOGPイメージをシュミレーションできる

Chrome 拡張機能

Postman
APIのデバックがすごい簡単にできる
Snappy Snippet
選択した箇所のCSSを見やすくする
What's font
選択されたフォントの名前を見やすくする
JSON Formatter
ブラウザに出力されるJSONを見やすくする

その他

anyenv
rbenv, phyenv, ndenvなどを集中管理できる
ngrok
開発中の画面をポートを通して手軽に共有できる

朝５時に起きてがんばって書きはじめましたが、全然終わらず、、仕事が終わってから気合でなんとか間に合わせました。。トップバッターなのでゆるく紹介しようと思っていたのですが、思ったよりも長くなってしまいました。ご紹介した開発プロセスは僕が普段実践しているものなので改善の余地はたくさんありそうです。もっと、いいやり方があるよ！という方、ご質問がある方はぜひぜひコメント欄などで教えてください！