個人開発のロードマップを一枚にする
個人開発では、企画、デザイン、実装、公開、販売、運用の知識が一度に目へ入ります。すべてを学んでから始めようとすると、最初に何をすればよいか分からなくなります。
ロードマップは、作業日を細かく決める予定表ではありません。「今はどの段階か」「次に何を確かめるか」「何ができたら先へ進むか」を一枚にした案内図です。
この記事では、初めて作る小さなWebサイトやアプリを、困りごとの発見から公開後の改善まで八段階に分けます。すでに途中まで作っている場合は、最初からやり直さず、現在地に近い段階から確認できます。
ロードマップは八段階で考える
個人開発の進め方を、次の八段階に分けます。
困りごとを見つける
最初の完成条件を決める
作る方法を選ぶ
画面と状態を設計する
実装して一周を確認する
公開の準備をする
必要な人へ届ける
運用して次の改善を決める
これは全員が同じ順番と日数で進むという意味ではありません。利用者へ話を聞いてから完成条件を直したり、公開確認で問題が見つかって実装へ戻ったりします。大切なのは、戻ることを失敗と考えず、何を確かめるために戻るのかを明確にすることです。
1. 困りごとを見つける
最初に決めるのは機能ではなく、誰が、どの場面で、何に困っているかです。自分のために作る場合は、自分が繰り返している面倒な作業を探します。他の人のために作る場合は、想像だけで決めず、実際の出来事を聞きます。
この段階で残すものは、次の一文です。
誰が、どんな場面で、何ができずに困っているか。
個人開発を始める前に決める3つのことでは、身近な困りごとを一つに絞る方法を説明しています。他の人の問題を確かめる場合は、最初のユーザーに話を聞くへ進みます。
困りごとを説明できないまま、ログイン、通知、グラフなどの機能だけを並べないようにします。必要な機能は、解決したい場面が決まってから選べます。
2. 最初の完成条件を決める
次に、最初の版で利用者がどこまでできればよいかを決めます。機能数ではなく、入口から結果までの一周で書きます。
読書記録なら、「本の題名を入力し、保存し、あとで一覧から確認できる」が一周です。表紙画像、共有、ランキングは、最初の一周に必要でなければ後へ回せます。
完成条件は、実際に確認できる文章にします。
入力する場所がある
操作すると結果が変わる
間違った入力でも壊れない
必要なら画面を閉じたあとも結果が残る
この段階の終了条件は、「できたか、できていないか」を自分で試せることです。作業に必要な道具がまだない場合は、個人開発を始めるために必要なもので準備を確認します。
3. 作る方法を選ぶ
完成条件が決まったら、その一周に必要な技術を選びます。先に流行している技術を集めるのではなく、画面、処理、保存、外部サービスなど、必要な能力から候補を出します。
個人開発の技術選定を小さく始めるでは、未経験の要素を一度に増やさず、同じ条件で候補を比較する方法を説明しています。
AIへ制作を依頼する場合も、サービス全体を一度に作らせません。AIに作りたいアプリを伝える方法を使い、対象者、困りごと、必要な操作、今回は作らないものを伝えます。
この段階の終了条件は、採用した方法だけでなく、選ばなかった方法と見直す条件も一枚に残っていることです。
4. 画面と状態を設計する
画面設計では、正常に動いている完成画面だけを描かないようにします。利用者が初めて開いた状態、読み込み中、入力エラー、処理失敗、完了も同じ機能の一部です。
小さなプロダクトの画面を迷わず設計するでは、中心となる一周を画面へ分け、必要な状態と操作部品を決めます。入力エラーを利用者が直せる文章にするでは、問題の場所、起きたこと、直し方をそろえます。
この段階の終了条件は、利用者がどこから始め、何を操作し、成功と失敗をどう知るかを説明できることです。色や装飾は、その順序が分かる状態になってから整えます。
5. 実装して一周を確認する
実装は、画面を全部作ってから確認するのではなく、一つの操作ごとに動かします。入力欄を作ったら入力し、保存処理を作ったら保存し、読み出しを作ったら画面を開き直します。
初めて作ったアプリを自分で確認する方法では、正常な入力だけでなく、空の入力、長い入力、連続操作、再読み込みなどを試します。外部サービスの鍵や本番用の資格情報を扱う場合は、個人開発の秘密情報を安全に管理するも同時に確認します。
この段階の終了条件は、中心となる一周を自分で再現でき、失敗した場合にどこで止まったか記録できることです。
6. 公開の準備をする
自分のパソコンで動くことと、他の人が安全に使えることは同じではありません。公開前には、正式なURL、秘密情報、利用者データ、表示速度、エラー時の復旧方法を確認します。
個人開発を公開する前のチェックリストで、中心操作、認証、課金表示、法務・権利、ロールバックなどを一周します。独自ドメインを使う場合は、独自ドメインとDNSを安全に切り替えるで、変更前の記録と切り戻し方法を準備します。
公開前の終了条件は、公開を進める条件だけでなく、止める条件と元へ戻す手順が決まっていることです。公開後に見る場所と時刻も、この段階で予定へ入れます。
7. 必要な人へ届ける
公開しただけでは、必要な人へ自動的に届くとは限りません。最初は案内する経路を一つ選び、訪問数だけでなく、利用開始から中心操作の完了までを見ます。
公開直後のマーケティングを小さく始めるでは、誰の何を変えるサービスかを一文にし、一つの経路を十四日間確認します。
販売する場合は、先に約束を明確にします。個人開発の最初の価格を決めると無料と有料の境界を決めるを使い、何に対して支払うのか、無料で得られる成果、有料になる条件、購入後の扱いを説明します。
この段階の終了条件は、案内を見た人が「自分向けか」「何ができるか」「費用や条件は何か」を判断できることです。
8. 運用して次の改善を決める
公開後は、すべての数字を常に見る必要はありません。利用者が中心操作を完了できているか、重大な失敗がないか、問い合わせと費用が無理なく扱えるかを決めた時刻に確認します。
公開後30日を無理なく運用するでは、公開直後、最初の一週間、二週目以降、三十日目に見るものを分けています。要望や不具合が届いたら、利用者の声を改善バックログに変えるで、事実、影響、次の行動を分けます。
この段階の終了条件は、次の一変更を選ぶか、現在のまま続けるか、範囲を縮めるか、終了するかを決められることです。
現在地と次の一歩を一枚に書く
ロードマップは、次の形式で作業メモへ書けます。
作っているもの：
解決したい困りごと：
現在の段階：八段階のうちどこか
確認できたこと：
現在止まっていること：
次に確認する一つ：
その段階の終了条件：
後へ回すもの：
作業が増えたら、この一枚へ戻ります。GitHubを利用している場合は、GitHub Issuesなどで、現在の作業と後で行う案を分けて記録できます。
一枚の目的は、すべての予定を固定することではありません。今日行う一つと、今は行わないものを区別することです。
前の段階へ戻ってもよい
ロードマップは一方向の作業表ではありません。利用者の反応から困りごとの捉え方を直したり、運用費用から技術構成を見直したりします。
戻るときは、次の三つを記録します。
何が分かったか
どの判断を変えるか
変更後に何を確認するか
ユーザー調査も、最初に一度行って終わるものではありません。GOV.UK Service Manualでは、開発の各段階で調査を計画し、利用者について学んだ内容に応じて計画を更新する考え方が示されています。
初めての一周では、すべてを詳しく完成させる必要はありません。MDNの初心者向け教材も、最初から大規模なサイトを目指さず、小さなWebサイトを計画し、作り、公開する順序で説明しています。
現在地を選び、その段階の終了条件を一つ書きます。次に読む記事と、今日確認する一つが決まれば、ロードマップは役割を果たしています。