1.上流工程
「何が目的か」
設計, 製造の前の工程です。
「要求」というと、外部からの発注でなければ関係ないと思ってしましますが、 個人が自作する場合でも、「何を作りたいのか」が「要求」にあたります。
- 「要求定義書」はクライアントの意図や目的を記録します（＝なぜ・何のため）。
- 「要件定義書」は、その意図を開発側がどう実現するかを整理したものです（＝何を・どこまで・どうやって）。
- 多くの場合、ワイヤーフレームやサイトマップは、要件定義と並行またはその後に生まれます。
参考：上流工程での視点の切り替え
| 視点 | 対象 | 主に扱う文書 | 内容の性質 |
|---|---|---|---|
| 発注者視点 | 目的・ターゲット・課題 | 企画書・要求定義書 | ビジネス・目的重視 |
| 受注者視点 | 実現手段・構成 | 要件定義書・構成図・WF | 技術と情報設計 |
| 利用者視点 | 行動・導線・理解 | ペルソナ・ユーザーストーリー | UX／体験の視点 |
個人の自作だと、この発注者と利用者の分離が難しくて、作っているうちに「この方が便利」と積み重ねて、結果「目的何だったっけ」となる失敗が見えます。
ちょうどよい例がここにあり、一般的に分かりやすいだろうと上の表をつくってそのまま載せています。 しかし私は、ペルソナ・ユーザーストーリーを分かりません。 一般的に分かりやすい資料と言うことでは正解なのですが、そもそも筆者が後で見てわかるための資料としては、「作成時点ですらわかっていないのにどうなの」という「目的」からしては不正解のものです。 このように、「視点」の問題は大事です。
- 「ペルソナ」は、プロダクトのターゲットとなる具体的なユーザー像を作り出すもの。
- 「ユーザーストーリー」は、そのペルソナがプロダクトを使用する際のシナリオやニーズを文章化するもの。
2.企画書
開発の上流資料として、
一般的な「企画書」を
サンプルとして用意しました。
「企画書」をWebページの記事の一部として埋め込んだので、デザインがHTML文書ですが、ご了承ください。
仮定として、「Webサイト制作のための学習支援サイト」としています。 実際は、初心者でもわかるように書けば、１年後に忘れた自分でも読んで分かるであろう「備忘録」です。
プロジェクト名
「Webサイト制作のための学習支援サイト」
背景と目的
Webサイト制作に関心のある初学者や、実務を経験しながら設計を見直したい開発者を対象に、「Webサイトの作り方」自体をWebサイトとして表現するプロジェクト。
企画の狙い
HTML/CSS/JavaScriptを用いたサイト制作の工程を明示する。
一般的な設計手法（例：FLOCSS）や開発プロセスを反映することで、学習用にも参考にできる構成とする。
実際に動くWebサイトを成果物とし、そこに含まれる文書や構成を通じて、作り方自体が理解できる構造とする。
想定読者
HTML/CSSの基礎が分かる初心者〜中級者。
設計・開発の工程や手法を知りたい学習者。
成果物
Webサイト（静的HTML/CSS/JS）
開発工程の記録を兼ねたMarkdown文書
FLOCSSを活用した実装例
3.要求定義書
開発の上流資料として、
一般的な「要求定義書」を
サンプルとして用意しました。
「要求定義書」をWebページの記事の一部として埋め込んだので、デザインがHTML文書ですが、ご了承ください。
仮定として、「Webサイト制作のための学習支援サイト」としています。 実際は、初心者でもわかるように書けば、１年後に忘れた自分でも読んで分かるであろう「備忘録」です。
システム利用者の視点（Who & What）
利用者層：PC・スマートフォン両対応。ただし操作性より視認性を重視。
閲覧環境：Windows + Chromeを中心としつつ、汎用ブラウザでも閲覧可能にする。
利用上の要求
PC／スマートフォンいずれからも閲覧可能であること。
スマホでは多少の操作の不便さは許容するが、視認性を損なわない。
設計思想や開発工程が学べる内容とすること。
具体的な制作例（HTML/CSS/JS）を含むことで、理論と実践を接続する。
Node.jsやGulpを前提とした実装例を含むこと。
非機能的要求
モダンなWeb標準に準拠。
構造と設計意図を分かりやすくするための文書群が整備されていること。
権利関係として、商用利用は禁止する。なので、商用利用を禁止したものも使用可。
4.要件定義書
開発の上流資料として、
一般的な「要件定義書」を
サンプルとして用意しました。
「要件定義書」をWebページの記事の一部として埋め込んだので、デザインがHTML文書ですが、ご了承ください。
仮定として、「Webサイト制作のための学習支援サイト」としています。 実際は、初心者でもわかるように書けば、１年後に忘れた自分でも読んで分かるであろう「備忘録」です。
対応技術・前提環境
HTML：HTML Living Standard
CSS：FLOCSSを設計手法として使用
JavaScript：動的表示に使用（一部を除き、HTML生成フェーズで処理）
開発支援：Node.js + Gulp によるビルド・管理
文書化：Markdownで記述し、後にHTML化
機能的要件
- ページ構成は静的HTML文書とし、スタイルは外部CSSで適用。
- スマホ向け表示にも対応するレスポンシブ設計。
- JavaScript に関する要件 :
- HTMLページ内で動的なインタラクションが必要な一部要素（例：ドロップダウンメニューの開閉、スムーズスクロール等）は、クライアントサイドのJavaScriptで制御する。
- ただし、ナビゲーション構造やHTMLの主要構成要素は、開発時にNode.js上でJSONデータをもとに生成され、Pugにより静的にHTML化される。このため、JavaScriptはあくまで「表示後の補助的な動作」に限定される。
- 外部スクリプトファイルとして提供されるJavaScriptは最小限とし、動作の分離性と管理のしやすさを確保する。
- サイト構造情報（ナビゲーションの階層構造やパンくずリスト等）は、Node.jsスクリプトで自動生成され、Pugで処理されてHTML文書に含まれる。
- 必要に応じて、構造データは <script type="application/ld+json"> タグとして自動出力され、検索エンジン向けの構造化データにも対応する。
- ビルドツールとしてGulpを利用し、以下を自動化 :
- Sassのコンパイル
- HTMLテンプレートの展開
- ファイル構造の整理
非機能的要件
実装内に学習・設計の意図が明示されていること。
Markdown文書は工程別に整理され、最終的にWebページとして出力可能。
コードや文書が再利用可能な構造になっていること。
使用するものは、必ず使用条件を満たす事。成果物の商用利用はしないし禁止するので、商用利用禁止のものは使える。
中下流文書との関係
この要件定義に基づき、以下の中下流文書が連動して作成される：
- 構造設計書（HTML/CSSの階層やルール）
- 基本原則（設計・命名・管理方針）
- 実装規約（FLOCSSの運用規則など）
- 作業工程記録（プロセスの実践ログ）