webアプリの開発の流れ
はじめに
カリキュラムの個人でwebアプリを開発するにあたってやることをまとめてみました。
tl:dr
- アイデア出し
- アイデア発散
- アイデア整理 - リーンキャンバス
- アイデアを検証する
- webアプリの種類
- 企画書（README）の作成
- サイトマップを作る
- カスタマージャーニーマップを作る
- 画面設計に落とし込む
- ユースケース図で行動を洗い出す
- ER図とテーブル定義に落とし込む
- Githubのタスク（ISSUE）管理
- 実装
- リリース
アイデア出し
「どんなアプリを作るのか？」から考えていきます。
なるべく自分が興味のあるものや詳しいものからアイデアを抽出していきます。
個人開発であればなるべるニッチなテーマに絞ります。
まずは日常生活の困りごと、趣味、仕事などの専門分野で思いつくものから箇条書きで書き出していきます。
例）：
国産ウイスキー
今期スタートのアニメ、なろう系アニメ
会社にいつも遅刻する
痛風で歩けない
書き出しが終わったら自分の関心が高い順に並べ替えてください。
一番上のテーマからアイデア検証を行っていきます、これではないと思ったら次のアイデアに移ります。
アイデア発散
アイデアをストレートに表現する（国産ウイスキーを検索・紹介、遅刻しないようにお知らせする等）といった形でもサービスの形にはなりますが、より特徴的なサービスにする為に一度アイデアを発散させ、可能性を探ります。
発散の方法としてはラテラルシンキングが有効です。ラテラルシンキングを行う為のフレームワークとして「オズボーンのチェックリスト」があります。
転用：他に使いみちはないか？
応用：似たものが他にないか？
変化：意味・色・形などを変えられないか？
拡大：より大きく・強く・長くなど、拡大できないか？
縮小：より小さく・軽く・短くなど、縮小できないか？
代用：材料・工程・場所などを他の何かに代用できないか？
再配置：要素・成分・部品などを変えられないか？
逆転：前後・上下・役割などを反対にできないか？
結合：材料・用途などを組み合わせられないか？
広告会社の創業者であるアレックス・オズボーン（Alex Osborn）によって提案されたもので、創造的な問題解決やアイデア生成のプロセスで利用されます。
アイデア整理 - リーンキャンバス
リーンキャンバス（Lean Canvas）は、スタートアップや新しいビジネスアイデアの概要を簡潔にまとめるためのツールです。リーンスタートアップの手法に基づいており、ビジネスモデルの要素を組み合わせてビジネスの構造や仮説を可視化します。
リーンキャンバスは、以下の9つの要素で構成されています：
- カスタマーセグメント（Customer Segments）: 顧客のセグメントやターゲット市場を特定します。
- 問題（Problem）: 顧客が抱えている問題やニーズを明確にします。
- ソリューション（Solution）: 問題解決のために提供する製品やサービスの概要を記述します。
- ユニークバリュープロポジション（Unique Value Proposition）: 競合他社との差別化や顧客への付加価値を明確にします。
- チャネル（Channels）: 顧客に対して製品やサービスを提供するための販売チャネルやマーケティング手法を記述します。
- 収益の仕組み（Revenue Streams）: 収益を生み出すためのビジネスモデルや収益源を明示します。
- コスト構造（Cost Structure）: ビジネス運営にかかるコストや投資を明確にします。
- キーメトリクス（Key Metrics）: 成功を評価するための重要な指標やメトリクスを設定します。
- ユーザーアクティビティ（User Activities）: 顧客が製品やサービスを利用する際の行動やアクティビティを特定します。
アイデアを検証する
インターネットを利用して調査、ターゲットユーザが存在してるコミュニティーに参加してインタビューする、Twitterなどでアイデアを発信してフィードバックをもらうなどアイデアを検証していきます。
検証手法例）：
1. 市場調査と競合分析: 類似または関連するサービスや製品が既に存在するかどうかを調査し、競合他社のビジネスモデルや提供される価値を分析します。市場の需要やトレンドに関する情報も収集しましょう。
2. ターゲットユーザーのインタビューやフィードバック: アイデアをターゲットとなるユーザーセグメントに対して共有し、彼らの意見やフィードバックを収集します。ユーザーが本当に必要としている問題を解決するかどうかを確認します。
3. MVP（Minimum Viable Product）の開発: 最小限の機能や機能を持つMVPを開発し、実際のユーザーに提供してフィードバックを収集します。ユーザーの反応や利用状況から、アイデアの有効性やビジネスの成長潜力を判断します。
webアプリの種類
Webアプリケーションは多様な種類があります。
目的や利用者のニーズに応じてwebアプリが属する種類と最低限の機能を定義します。
例）：
1. ソーシャルメディアプラットフォーム: ユーザーが情報やメッセージを共有し、他のユーザーと交流するためのプラットフォーム。例: Facebook、Twitter、Instagram。
2. オンデマンドサービス: 特定のサービスをユーザーがリクエストすると、必要なサービスを提供するプラットフォーム。例: Uber、Airbnb、Food delivery apps。
3. プロジェクト管理ツール: プロジェクトの計画、進捗管理、コラボレーションを支援するツール。例: Trello、Asana、Jira。
4. ブログやコンテンツ管理システム: ユーザーがコンテンツを作成、編集、公開するためのプラットフォーム。例: WordPress、Medium、Drupal。
企画書（README）の作成
READMEはプロジェクトの説明や使い方、セットアップ手順などを記述したドキュメントです。
READMEはプロジェクトの利用者や開発者にとって重要な情報源ですので、わかりやすく、具体的に書くことが大切です。また、READMEはプロジェクトの進化と共に更新し続けることも忘れずに行いましょう。
最低限これらの情報を固めていきます。
■ サービス概要
■ メインのターゲットユーザー
■ 解決方法
■ 機能調査
■ 実装予定の機能
■ なぜこのサービスを作りたいのか？
■ スケジュール
▼スケジュール例
企画〜技術調査：12/4〆切
README〜ER図作成：12/10 〆切
メイン機能実装：12/10 - 1/15
β版をRUNTEQ内リリース（MVP）：1/15〆切
本番リリース：1月末
サイトマップを作る
サイトマップで必要画面を洗い出します。
サイトマップは通常、ツリー構造や階層図として表示され、ウェブサイト全体のナビゲーションやコンテンツの構成を示す役割を果たします。
カスタマージャーニーマップを作る
カスタマージャーニーマップ（Customer Journey Map）は、顧客が製品やサービスを利用する過程を可視化し、理解するためのツールです。顧客が製品やサービスと関わるさまざまなステージやタッチポイントを示し、それぞれのステージでの顧客の感情や行動、意思決定の要因などを詳細に記述します。
画面設計に落とし込む
webアプリの各画面が決まったら簡易的に画面遷移や中に置くコンポーネントを中心に書き出していきます。
ユーザーがインターフェースを簡単に理解し、効果的に操作できるようにするためにシンプルで直感的な画面を意識して作りましょう。
ユーザーが必要な情報に迅速にアクセスできるようにするために、情報の整理と優先順位付けが重要です。画面上の情報やコンテンツを適切に階層化し、重要な情報を目立たせるようにしましょう。
Sketch, Adobe XD, Figmaなど画面設計にはさまざまなツールが利用できます。
お好みやアプリの要件に応じて、最適なツールを選んで利用してみてください。
ユースケース図で行動を洗い出す
画面設計が固まったらデータ設計を落とす前に、登場人物および登場人物の行動を洗い出しましょう。
登場人物は運営側も含めて全て洗い出します。また、外部システムなども登場人物として記載することがポイントとなります。
この登場人物と行動の洗い出しにはユースケース図が最適です。
ユースケース図（Use Case Diagram）は、ソフトウェアまたはシステムの機能や利用者（アクター）との関係を視覚的に表現するためのUML（Unified Modeling Language）図の一種です。
ユースケース図には以下の要素が含まれます：
- アクター（Actor）：
アクターは、システムとやり取りする外部のユーザーや他のシステムを表します。アクターは通常、人や他のシステムとして表現されます。例えば、ユーザー、管理者、外部システムなどがアクターとなります。 - ユースケース（Use Case）：
ユースケースは、システムが提供する機能やシステムの振る舞いを表します。ユースケースは通常、アクターとの間のやり取りやユーザーの目的を示します。例えば、ログイン、商品の検索、注文の処理などがユースケースとなります。 - 関連（Association）：
アクターとユースケースの関連性を示します。アクターとユースケースの間に矢印が引かれ、アクターがユースケースを使用することを示します。関連には、一方向の関係と双方向の関係があります。 - システム境界（System Boundary）：
システム境界は、ユースケース図の外側に描かれ、システムの境界を示します。システム境界内にある要素が、システムの一部として定義されます。
以下に、簡単なユースケース図の例になります：
+--------------+
| ユーザー |
+--------------+
|
+------+------+
| システム |
+------+------+
|
+------------+--------------+
| ユースケース |
+----------------------------+
| - ログイン |
| - 商品の検索 |
| - 注文の処理 |
+----------------------------+
ユーザーがシステムにログインしたり、商品を検索したり、注文を処理するといったユースケースが示されています。
ER図とテーブル定義に落とし込む
ER図、テーブル定義を行います。
データベースに定義するテーブル名やカラム名、カラムの型やサイズも記載しておきましょう。またhas_many や belongs_to などの関連性やインデックスや制約などについても記載しましょう。
Githubのタスク（ISSUE）管理
開発に関連するタスクを一つの場所で管理するようにしましょう。
各タスクに状態と優先度を持たせ、ラベル、マイルストーンなどの情報を追加します。これにより、いつかどのタスクに取り組んでいるかが明確になり、タスクの進捗状況を追跡できます。
実装
実装を進める際に気をつけつポイント：
- タスクを最小単位へ分割する
- タスクごとに期限をつけてスケジュール通りに実装を進める
- ユニットテスト、統合テスト、受け入れテストなどを実施する
- モジュール化、再利用性、拡張性などを考慮する
- コードの履歴と変更を管理し、ブランチの適切な使用とマージ戦略を確立する
- 自分以外の人が見ても分かりやすくコミットの粒度やコミットメッセージを意識する
- issueに作成したい機能を実現するには何を実装すれば良いのかイメージができるように記載する
リリース
サービスをリリースするに当たって最低限のTODOをやりましょう。
- 利用規約、プライパシーポリシーの設定
- 運営元、問い合わせ先の公開
- 独自ドメイン
- GoogleAnalyticsの導入
- GoogleSearchConsoleの登録
- OGPの設定
- メタタグの設定
- フィードバックにて継続的な開発と保守
- マーケティング
終わりに
不完全ですが、個人でwebアプリ開発に取り組む際にやるべきことでした。
参考記事
Discussion