大河るり(Taiga Luri)この記事をシェア
今回から始まるのが「ToDoで学ぶ仕様書作成」シリーズです。ToDoアプリという身近な題材を使って、実際に仕様書を作成していきます。全部で十数回のシリーズになる予定ですが、最後まで見ていただければ、きっと皆さんの開発に役立つスキルが身につくはずです。
さて、配信ネタを作るためのToDoアプリを設計していますが、存外複雑ですね。Claudeにドキュメント書かせているのですが、なかなか膨大な量のドキュメントになりました。具体的には、機能仕様書が3000行を超えています。もう少しコンパクトになるかな、と思ったのですが、想定外でした。
エラーまで網羅させているので、それはそうな部分はあるのですが、それにしても少し詳細すぎるかな、という気もしています。もう少し省略できるか、悩ましいです。
プロジェクト憲章やユーザーストーリー、要求仕様、アーキテクチャ設計、データ設計、あたりまではまぁ納得のサイズではあったのですが、その後が膨大になりますね。API仕様とUI仕様、機能仕様、あたりです。テスト仕様書まで含めると、さらに増えるかもしれません。スクラムとかやる前提だと、このやり方は無理があるかなぁ。
ドキュメントは、今のところClaudeに初期版を書かせて、ぼくが適宜修正する、という方向で書いています。結構優秀なので、ある程度は満足がいくのですが、やはり細かいところはこちらの伝え方が悪いせいか、なかなか思い通りとはいきません。
今回ははじめて、契約プログラミングちっくに、事前条件と事後条件、不変条件を各機能に書かせてみたのですが、それらの条件が網羅されているかがわからないところも悩みどころです。ちゃんと契約プログラミングの本を読むべきでしょうか。完全にエアプなので現状はよろしくないです。
さて、今回の一連の動画を制作するにあたり、ソフトウェア開発プロジェクト 上流工程ドキュメントガイドを作成しました。今後はこれをベースに動画を作成していきます。書くべき項目について、簡単な説明は記載してあります。先取りしてドキュメントを作成していきたい場合は、これをご覧になってください。項目自体は以下に列挙してあります。
-
プロジェクト憲章
- プロジェクト名
- プロジェクト実行の背景
- プロジェクトの目的
- 提供価値
- プロジェクトスコープ
- スコープ内の項目
- スコープ外の項目(重要!)
- 成功基準
- スケジュール概要
- メンバー
- 利害関係者(ステークホルダー)
- 予算
- リスク
- 前提条件と制約条件
- 承認者
-
体制図
- 組織構造図
- 役割と責任
- 外部組織との関係
-
ユーザーストーリー
- 更新履歴
- ユーザーペルソナ
- ユーザージャーニー
- ユーザーストーリー
- 受け入れ基準(Acceptance Criteria)
-
要求仕様書
- 更新履歴
- 機能要件
- 非機能要件
- インターフェース要件
- 外部インターフェース(API等)
- ユーザーインターフェース(UI)
- データモデル
- 制約条件
- 品質要件
- トレーサビリティマトリクス
-
設計仕様書群
- アーキテクチャ設計書
- 更新履歴
- システム概要図
- アーキテクチャパターン
- アーキテクチャ決定記録(ADR)
- 設計指針
- 技術スタック
- 非同期・並行処理設計
- データ設計書
- 更新履歴
- 概念データモデル
- 論理データモデル
- 物理データモデル(データベース設計)
- アプリケーションデータ型仕様
- データ制約とバリデーション
- データマイグレーション
- API仕様書
- 更新履歴
- API概要
- エンドポイント定義
- 内部API仕様(関数/メソッド)
- UI仕様書
- 更新履歴
- UI全体方針
- 画面遷移図
- 画面仕様
- 共通UI コンポーネント
- 機能詳細仕様書
- 更新履歴
- 機能一覧
- 状態遷移図
- シーケンス図
- 機能詳細仕様
- ビジネスロジック
- データフロー図(DFD)
- アーキテクチャ設計書