プロジェクト概要 作成レシピ

Project Overview Writing Recipe

本ドキュメントは、プロジェクト概要を「読み手が短時間で立ち上げ判断の前提を理解できる内容」に仕上げるための作り方です。 本書では問い、深掘り手順、具体化のコツ、レビュー観点を扱います。

1. このレシピの使い方

• 最初に、プロジェクトの仮説を粗く書き出す。
• 次に、各章の問いに答えながら、背景、必要性、基本的な考え方、実現したいこと、期待効果、前提条件を具体化する。
• 最後に、レビュー観点で「曖昧すぎないか」「後続文書に委譲すべき詳細を書きすぎていないか」を確認する。
• 利用者の困りごと・放置リスク・目指す価値（Why）、実現したい状態と期待効果（What）、中心仮説と判断軸（How）を整理し、背景から必要性、実現したいこと、期待効果への対応を追跡できるようにする（Trace）。詳細スコープ、受入条件、設計は後続文書へ委譲する。

2. 作成前に集める情報

最初から正確に書こうとせず、以下を短いメモで集める。

項目	集める情報
プロジェクト名	読み手が対象を識別できる名称
対象領域	どの活動、業務、サービス、システムを扱うか
現状	いま何が起きているか
困りごと	誰が、何に困っているか
放置リスク	取り組まない場合に悪化すること
中心仮説	誰の課題に何を働きかけると、どの変化が生じるか
実現したい状態	何ができるようになれば前進と言えるか
判断軸	進め方で重視する原則、譲れない考え方
初期公開効果	提供開始前に代表利用者の試行等で確認できる効果
短期効果	提供後の利用、定着、再利用、直接的な課題改善
中長期効果	事業・活動の継続や社会的な波及として目指す効果
前提・制約	変えないこと、依存すること、まだ決まっていないこと

3. 全体の作成手順

1. H1 と導入文で「何のプロジェクトか」を一文で定義する。
2. 背景で、現状と困りごとを分けて書く。
3. 必要性で、なぜ今取り組む必要があるかを書き、必要なら中心仮説を一文にする。
4. 基本的な考え方で、判断軸を 2〜5 件に絞る。
5. 実現したいことで、成果の方向性を箇条書きにする。
6. 期待効果で、初期公開、短期、中長期の効果を分け、測定方法を置く。
7. 前提条件で、適用範囲、責任分担、制約、未決事項を明示する。
8. 最後に、詳細化すべき内容を後続文書へ委譲できているか確認する。

4. 各章の書き方

4.1. 導入文

導入文は、H1 の直下に 1 文で置く。

問い:

• このプロジェクトは何を支援するものか。
• 誰が使う、または誰に影響するものか。
• 何を通じて、どの状態を実現するのか。

書き方:

• 「A は、B を通じて、C を支援する D である」の形にすると書きやすい。
• 効果、指標、実装方式を盛り込みすぎない。
• 読み手が冒頭 10 秒で対象をつかめる粒度にする。

良い例:

駄菓子屋きぬや 販売管理システムは、店頭販売、在庫、常連顧客のつけを一元管理し、店主一人でも日々の運用を続けやすくするための小規模店舗向け業務支援システムである。

悪い例:

店舗運営を適切に改善するための便利なシステムである。

4.2. 背景

背景では、現状と困りごとを混ぜずに書く。

問い:

• いま、どのような状況か。
• 誰が、どの作業で困っているか。
• その困りごとは、どの程度繰り返し起きているか。
• すでに見えている影響は何か。

具体化のコツ:

• まず 1〜2 段落で文脈を説明する。
• その後に、顕在化している問題を箇条書きで並べる。
• 事実と推測が混ざる場合は、推測側を「仮説」として扱う。

良い例:

• 人気商品の欠品が増えている。
• 仕入れのタイミングや数量が勘頼りで、在庫のムラが大きい。
• 店主以外が店番をした際に、販売・在庫・つけの状況をすぐに確認できない。

悪い例:

• 現状いろいろ大変で、業務改善が必要である。

4.3. 必要性

必要性では、背景で示した課題に対して「なぜ取り組む必要があるか」を説明する。

問い:

• 放置すると何が悪化するか。
• 今取り組まないと失われる機会は何か。
• 誰の負担、リスク、判断コストが増えるか。
• 初期対応として、何を先に安定させる必要があるか。
• 誰のどの課題へ何を働きかけると、どの価値が生じると考えるか。

書き方:

• 背景の繰り返しではなく、放置リスクや着手理由を書く。
• 期限や繁忙期など、時間的な理由があれば書く。
• 「必要だから必要」ではなく、取り組まない場合の影響を示す。
• 複数の価値を同時に成立させることが重要な場合は、中心仮説を一文で置き、その構成要素を価値仮説として読み取れるようにする。

4.4. 基本的な考え方

基本的な考え方では、プロジェクトの判断軸を短く定義する。

問い:

• 迷ったときに何を優先するか。
• 何をやりすぎないようにするか。
• どの価値を守るために、その進め方を選ぶのか。
• 後続のスコープ、設計、受入条件に効く原則は何か。

書き方:

• 原則は 2〜5 件に絞る。
• 各原則は「名称 + 一文説明」にする。
• 原則名は日本語だけでもよい。英語名を付ける場合は、読み手に意味が伝わる訳を添える。

例:

1. まず記録する: 高度な分析よりも、日々の記録が続くことを優先する。
2. 迷わず操作できる: 画面数と入力項目を最小限にする。
3. 小さく始めて改善する: 初期リリースでは単一店舗の店頭運用に絞る。

4.5. 実現したいこと

実現したいことでは、プロジェクトが提供したい成果の方向性を書く。

問い:

• 何ができるようになれば、プロジェクトを進める意味があるか。
• どの利用者、現場、活動が楽になるか。
• どこまでを初期対象として考えるか。
• 後続文書で詳細化すべき内容は何か。

書き方:

• 具体的な機能名だけに寄せず、実現したい状態で書く。
• 詳細な対象範囲や対象外は prj-scope に委譲する。
• 4〜6 件程度の箇条書きにすると読みやすい。

良い例:

• 駄菓子の販売、在庫、常連顧客のつけをシンプルな仕組みで一元管理する。
• 家族が店番をする場合でも、在庫状況とつけ残高を同じ手順で確認できるようにする。

悪い例:

• 商品マスタ画面、販売登録画面、在庫一覧画面、顧客検索画面、月次集計画面を作る。

4.6. 期待効果

期待効果では、初期公開前に確認する価値、提供後の短期的な利用成果、中長期で目指す事業・社会的成果を分ける。

問い:

• 初期公開または初期リリース時点で判定できることは何か。
• 対象利用者は、説明や特別な支援なしに主要な利用場面を完遂できるか。
• 公開・運用開始後の短期に、実際の利用、定着、再利用、直接的な改善をどう確認するか。
• 中長期に、事業・業務・社会へどのような成果をもたらしたいか。
• 当該プロジェクトだけに帰属できない成果を、寄与としてどのように確認するか。
• 数値目標は初期仮説か、確定したコミット値か。
• 測定方法は再現できるか。

初期公開指標の考え方:

• 代表利用者が主要な利用場面を完遂できるかを、タスク完了、重大な行き詰まり、所要時間、必要な支援から確認する。
• 成果物や機能がそろったことは受入条件であり、それだけを利用者価値の指標にしない。
• QCD を扱う場合も、利用者の作業完遂や業務上の効果との関係を示す。

短期指標の考え方:

• 公開・運用開始後の利用件数、利用継続、再利用、利用者が認識する直接的な改善を置く。
• 公開直後や運用直後は母数が小さいため、累積件数と具体的な利用事例から始める。

中長期指標の考え方:

• 売上、欠品、負担、事業継続、社会課題への寄与、参加機会、透明性など、プロジェクトの最終目的に近い成果を置く。
• 外部要因の影響を受ける場合は、単独の因果を断定せず、利用前後の変化と当該プロジェクトの寄与を確認する。

推奨表（観点・指標・目標・測定方法を 1 行ずつ書く。下記は三つの時間軸の記入例）:

時間軸	観点	指標	目標	測定方法
初期公開	作業完遂	店主代表が販売・在庫・つけ確認を完了できる	必須タスク完了率100%	代表シナリオの操作結果と必要な支援を記録
短期	運用定着	販売・在庫・つけの記録が残っている営業日の割合	営業日の90%以上	初期運用期間の記録有無を日次で集計
中長期	欠品削減	人気商品の欠品回数	ベースライン比50%削減	対象商品を固定し、利用前後の欠品回数を比較

レビューのコツ:

• 「何を数えるか」が分からない指標は修正する。
• 「50%削減」などの相対目標には、比較対象を置く。
• 測定できない場合は「未確定」ではなく、何を記録して後で判定するかを書く。

4.7. 前提条件

前提条件では、プロジェクト概要を読む人が誤解しやすい境界を明示する。

問い:

• 初期対象に含めるものは何か。
• 初期対象に含めないものは何か。
• 誰が最終判断を行うか。
• AI Agent やシステムは、どこまで支援する位置づけか。
• 未決事項は何で、どの文書またはタイミングで決めるか。

書き方:

• 「対象」「対象外」「判断責任」「未決事項」を分けて考える。
• 個人情報や非公開情報は書かない。
• 未決事項は UNDECIDED: を使い、決定タイミングを添える。

5. 深掘り手順

内容が浅いと感じる場合は、次の順で深掘りする。

1. 誰が困っているか を具体化する。
2. 何が繰り返し起きているか を事実として書く。
3. 放置した場合の悪化 を書く。
4. 初期に成立させる最小状態 を決める。
5. 中心仮説と価値仮説 を、課題、働きかけ、期待する変化の関係で確認する。
6. 迷ったときの判断軸 を 2〜5 件に絞る。
7. 初期公開前に試行する指標、提供後の短期指標、中長期で追跡する指標 を分ける。
8. 後続文書へ委譲する詳細 を切り出す。

6. 良い例 / 悪い例

観点	良い例	悪い例
導入文	店頭販売、在庫、つけを一元管理する小規模店舗向け業務支援システム	店舗運営を便利にするシステム
背景	欠品、在庫ムラ、つけ管理漏れが起きている	現場が困っている
必要性	紙運用を続けると店舗継続リスクが高まる	早く作った方がよい
基本方針	高度な分析より日々の記録継続を優先する	使いやすく高機能にする
実現したいこと	家族が店番する場合でも在庫とつけを同じ手順で確認できる	在庫画面を作る
期待効果	初期公開では主要操作の完遂、短期では記録定着、中長期では欠品削減を確認する	機能を完成させて便利にする
前提条件	初期リリースでは EC 連携、複数店舗管理、本格会計連携は対象外とする	必要に応じていろいろ対応する

7. レビュー観点

作成後は、次の観点で確認する。

観点	確認内容
一読性	H1 と導入文だけで対象プロジェクトの概要が分かるか
背景の具体性	現状、困りごと、影響が具体的に書かれているか
必要性の明確さ	放置リスクや今取り組む理由が背景と接続しているか
仮説の一貫性	中心仮説を置いた場合、価値仮説、原則、期待効果へつながるか
判断軸	基本的な考え方が後続のスコープや設計判断に使える粒度か
成果の粒度	実現したいことが機能列挙だけになっていないか
指標の測定性	指標、目標、測定方法、判定時期が分かるか
時間軸	初期公開、短期、中長期の効果が混在または欠落していないか
利用者価値	成果物完成率だけでなく、利用・事業・社会の変化を示しているか
責務分担	認可、受入条件、詳細スコープを本書に書きすぎていないか
前提条件	対象外、判断責任、未決事項が明示されているか
公開適性	個人情報、非公開情報、機密情報が含まれていないか

8. 仕上げチェック

• 「全体の作成手順」で示した章立てがそろっている。
• 章ごとに「なぜその情報が必要か」が読み取れる。
• 数値目標には測定方法と判定タイミングがある。
• 初期公開、短期、中長期の指標が、利用者価値から波及効果へつながっている。
• 初期仮説、未決事項、後続文書へ委譲する内容が混ざっていない。
• 詳細なスコープ、受入条件、認可情報、設計詳細を書きすぎていない。
• 中心仮説を置いた場合、対象者・課題・働きかけ・期待する変化が、実現したいこと、判断軸、期待効果へ一貫して対応している。