個人開発でも、ドキュメントはかなりちゃんと作っている
1. はじめに
月商1000万円を目指して、新規プロジェクトを進めている。
このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、プロジェクトをどう進めているか、どのように計画しているか、どんな課題に向き合っているかは記録していく。
今回は、ドキュメント管理について書く。
個人開発というと、思いついた機能をすぐ実装して、動いたら次に進む、というイメージがあるかもしれない。
もちろん、それも悪くない。
小さなアプリや試作品なら、その方が早いこともある。
ただ、今回のプロジェクトは、月商1000万円を目指している。
単なる思いつきの実験ではなく、最終的には継続運営できるサービスにしたい。
そのため、かなり早い段階からドキュメントを作っている。
2. なぜドキュメントを作るのか
ドキュメントを作る理由は、きれいな資料を残したいからではない。
目的は、主に以下である。
仕様のブレを防ぐため
後から判断理由を思い出せるようにするため
AIに正しく実装してもらうため
要件変更の影響範囲を把握するため
後回し機能を忘れないため
テスト観点を整理するため
サービスインに必要な条件を明確にするため
将来、人に引き継げる状態にするため
特に大きいのは、AIに正しく作業してもらうためである。
今の開発では、ChatGPTやCursorのようなAIツールをかなり使っている。
AIは強力だが、前提が曖昧だと、こちらの意図と違う方向に進むことがある。
そのため、プロジェクトの方針、仕様、優先度、残課題、実装ルールをドキュメント化しておくことが重要になる。
AIに任せるためには、AIに渡せる文脈が必要である。
3. 作っているドキュメントの種類
現時点では、かなり多くのドキュメントを作っている。
具体的な企画内容は伏せるが、種類としては以下のようなものがある。
| ドキュメント | 目的 |
|---|---|
| 企画概要 | プロジェクトの目的・コンセプト・方向性を整理する |
| 要件定義書 | 必要な機能・前提条件・制約を整理する |
| 機能仕様書 | 各機能の内容、入力、表示、操作を整理する |
| 画面仕様書 | 画面構成、ボタン、リンク、導線を整理する |
| データ設計書 | 扱うデータ、項目、関連性を整理する |
| ロジック設計書 | 内部処理や判定ルールを整理する |
| API設計書 | 画面とデータ処理の接続部分を整理する |
| 管理者機能仕様 | 運営側が操作する画面や管理項目を整理する |
| ユーザーマニュアル | 将来ユーザーに説明する内容を整理する |
| 管理者マニュアル | 運営時の手順を整理する |
| テスト観点一覧 | 何を確認すべきかを整理する |
| リリース判定チェックリスト | 公開前に満たすべき条件を整理する |
| 残課題一覧 | 未対応事項、判断待ち事項を管理する |
| 後回し機能一覧 | 今はやらないが、将来必要な機能を管理する |
| 開発ルール | 実装・ドキュメント更新・確認のルールを整理する |
こうして並べると、個人開発としてはかなり重い。
ただ、今回のプロジェクトは途中で要件がかなり増えている。
そのため、頭の中だけで管理するのは難しい。
ドキュメントを作っていないと、後で確実に混乱する。
4. 特に重視しているドキュメント
すべてのドキュメントが同じ重要度ではない。
現時点で特に重視しているのは、以下である。
4.1 要件定義書
まず重要なのは、要件定義書である。
何を作るのか。
何を必須とするのか。
何を後回しにするのか。
どのような前提でサービスを作るのか。
ここが曖昧だと、開発がどんどんズレていく。
今回のプロジェクトでは、途中でアイデアが増え続けている。
だからこそ、要件定義書に残しておかないと、何が正式な方針なのか分からなくなる。
4.2 残課題一覧
次に重要なのが、残課題一覧である。
新しいアイデア、未解決の仕様、あとで対応する不具合、判断待ちの項目などを、残課題として管理している。
これがないと、頭の中にタスクが溜まり続ける。
残課題一覧があることで、以下ができる。
今やることと後でやることを分けられる
重要なアイデアを忘れない
AIに次の作業を依頼しやすい
後回しにした理由を残せる
進捗確認がしやすい
個人的には、残課題一覧はかなり重要だと思っている。
4.3 後回し機能一覧
後回し機能一覧も作っている。
ただし、最近はこの扱いが難しくなってきた。
最初は、後回し機能は単純に「今は作らないもの」として整理していた。
しかし、進めていくうちに、後回しにしすぎると逆に開発効率が悪くなるケースがあると分かってきた。
本当は先に作った方が、後工程が楽になる機能もある。
そのため、後回し機能一覧は、単なる保留リストではなく、定期的に棚卸しする対象にしている。
後回しにしたものでも、以下に当てはまる場合は前倒しする。
実装が軽い
ユーザー体験に大きく効く
後から作ると手戻りが大きい
他の機能の前提になる
サービスイン判断に関わる
「後回し」と書いたからといって、永久に後回しにするわけではない。
4.4 テスト観点一覧
テスト観点一覧も重要である。
個人開発では、テストが後回しになりやすい。
ただ、サービスとして公開するなら、最低限確認すべきことは整理しておく必要がある。
今後確認すべき観点としては、以下のようなものがある。
新規登録後の流れ
初回説明の表示
主要画面への遷移
データ登録・更新・削除
エラー時の表示
スマホでの見え方
管理者操作
通知
履歴
ランキング
自動処理
権限チェック
不正操作防止
特に、一人用確認版、限定公開版、正式公開版では、必要なテスト水準が異なる。
そのため、今後はテスト観点もフェーズごとに分けて整理していきたい。
5. ドキュメントを作るメリット
実際にドキュメントを作っていて、メリットはかなり大きい。
5.1 判断が残る
新規プロジェクトでは、毎日のように判断が発生する。
この機能は今作るのか
後回しにするのか
どの画面を優先するのか
どの課金ツールを使うのか
どの仕様を採用するのか
どこまでを初期リリースに入れるのか
判断を記録していないと、数日後には理由を忘れる。
ドキュメントに残しておけば、後から見返せる。
これはかなり大きい。
5.2 AIへの指示が正確になる
AIに実装を依頼するとき、前提が曖昧だと期待通りにならない。
しかし、ドキュメントがあれば、AIに対して以下のような指示ができる。
この要件定義書に従って実装してほしい
残課題一覧を更新してほしい
後回し機能一覧と照合してほしい
画面仕様書に沿ってボタンを配置してほしい
データ設計書と矛盾がないか確認してほしい
テスト観点に沿って確認してほしい
これはかなり便利である。
AIを使う開発では、ドキュメントは単なる記録ではなく、AIに作業を引き継ぐための入力情報になる。
5.3 要件変更に強くなる
今回のプロジェクトでは、要件変更がかなり多い。
ただ、ドキュメントがあることで、要件変更の影響を確認しやすくなる。
たとえば、新しい機能を追加したいと思ったときに、
要件定義書に追記が必要か
画面仕様に影響するか
データ設計に影響するか
管理者機能が必要か
テスト観点が増えるか
リリース範囲に入れるか
を確認できる。
これを頭の中だけでやると、ほぼ確実に漏れる。
5.4 リリース判断がしやすくなる
サービスを公開するタイミングでは、何をもって「公開可能」とするかが重要になる。
そのために、リリース判定チェックリストを作っている。
ここには、たとえば以下のような観点を入れる。
主要導線が通っているか
致命的なエラーがないか
ユーザーが迷わないか
スマホで最低限使えるか
データが破損しないか
不具合報告導線があるか
管理者が最低限対応できるか
利用規約や注意事項が整っているか
リリース判断は感覚だけでやると危険である。
チェックリストがあることで、公開前に冷静に確認できる。
6. ドキュメント作りの問題点
ただし、ドキュメントを作ることには問題もある。
一番の問題は、作りすぎると実装が進まないことである。
実際、最近はドキュメント整理が増えすぎて、開発のスピードが落ちる懸念も出てきた。
ドキュメントは大事。
しかし、ドキュメントを書くだけではサービスは完成しない。
そのため、最近は以下のルールを意識している。
ドキュメント更新だけで作業を終わらせない
実装に直結しない細かい表現修正は後回しにする
同じ内容を複数ファイルに書きすぎない
残課題は一箇所に集約する
重要な判断だけを確実に残す
実装完了後に必要最小限の更新をする
ドキュメントは必要だが、ドキュメント作成が目的化してはいけない。
7. 個人開発なのに、ここまでやる理由
正直、ここまでドキュメントを作る個人開発は少ないかもしれない。
ただ、自分としては必要だと感じている。
理由は、今回のプロジェクトが単純な小規模アプリではないからである。
機能が多く、運用もあり、ユーザー体験も重要で、将来的には収益化も考えている。
さらに、AIを使って開発を進めているため、AIに渡す前提情報も必要になる。
そして何より、月商1000万円を目指している。
月商1000万円を目指すなら、思いつきだけで進めるのは危険である。
もちろん、計画しすぎても動けなくなる。
だから、理想は以下である。
作りながら書く。書きながら作る。
計画だけでもダメ。
実装だけでもダメ。
両方を回しながら、サービスインに近づけていく。
8. 今後のドキュメント運用
今後は、ドキュメント運用も改善していく。
特に意識したいのは、以下である。
ドキュメントの役割を明確にする
重複記載を減らす
残課題一覧を常に最新にする
後回し機能を定期的に棚卸しする
リリース判定チェックリストを強化する
テスト観点をフェーズ別に整理する
AIに渡しやすい形式で書く
実装後の更新漏れを減らす
ドキュメント更新だけで満足しない
最終的には運用・引き継ぎにも使える状態にする
特に、AIに渡しやすい形式にすることは、今後さらに重要になる。
AIを活用する開発では、ドキュメントの品質がそのまま開発効率に影響する。
9. 今回の結論
今回のプロジェクトでは、個人開発としてはかなりしっかりドキュメントを作っている。
企画概要、要件定義、機能仕様、画面仕様、データ設計、ロジック設計、API設計、管理者仕様、マニュアル、テスト観点、リリース判定、残課題、後回し機能、開発ルール。
こうしたドキュメントを整備しながら進めている。
これは遠回りに見えるかもしれない。
しかし、プロジェクトが大きくなるほど、ドキュメントがないことによる手戻りは大きくなる。
特に今回は、AIツールを活用している。
AIに正しく働いてもらうためにも、仕様や方針を残しておくことはかなり重要である。
ただし、ドキュメントだけで満足してはいけない。
最終的に必要なのは、動くサービスである。
だから今後も、
ドキュメントで整理し、実装で前に進める。
このバランスを取りながら進めていきたい。
月商1000万円までの道のりは、派手な機能や売上だけでなく、こうした地味な土台作りの積み重ねでもある。
0 件のコメント:
コメントを投稿