1.HTMLの書き方
HTMLを書くには、
それなりの準備が
ある方が良いです。
HTMLを書くには、記述の規則を知れば書けます。 ただ、それなりの準備があれば、楽に良いものが出来ると思います。
以下は、一般的な開発工程と対応する文書一覧という事で、『「Webサイトの作成環境」の作成』と仮定して作成したものです。
| 工程フェーズ | 主な作業内容 | 作成・使用する文書 | 備考 |
|---|---|---|---|
| 0. 企画／構想 | 目的・ターゲット・制約の洗い出し | 企画書, プロジェクト憲章（必要に応じて） | 誰のために何の目的で作るのか |
| 1. 要求定義 | 発注側の希望・目的の明確化 | 要求定義書, ヒアリングシート, インタビュー記録 | 「〜がしたい」「〜を伝えたい」など、主観を含む内容 |
| 2. 要件定義 | 実現に必要な具体的条件の整理 | 要件定義書, 機能一覧表（画面×目的）, サイトマップ | 要求を実現する「要素・仕組み」に落とし込む |
| 3. 情報設計 |
構成・導線の設計 | ワイヤーフレーム, ページ遷移図, 機能マップ | 情報構造とユーザー導線を設計する段階 |
| 4. コンテンツ設計 | 原稿・画像・構成要素の設計 | コンテンツ構成表, 各ページの内容仕様書 | 実装前の素材・情報の準備段階 |
| 5. UI設計／ |
見た目・トーン・モックアップ | デザインカンプ, UIガイドライン（必要に応じて） | 見た目を確定させる段階 |
| 6. 技術設計 | 実装方針・構造設計 | 技術仕様書, ディレクトリ構成図, コーディング規約 | コーディングの前提ルールや設計方針 |
| 7. 実装 | HTML/CSS/JS等の制作 | コード本体, 実装メモ・TODO, テスト仕様書 | 実作業フェーズ（下流） |
| 8. テスト | 動作・表示・仕様との一致確認 | テストケース表, バグ報告表 | 仕様との整合性確認 |
| 9. 公開／運用 | 公開準備・公開・保守の対応 | 公開チェックリスト, 運用ガイド, 更新履歴 | 実運用の継続を意識 |
2.上流工程
「何が目的か」
設計, 製造の前の工程です。
「要求」というと、外部からの発注でなければ関係ないと思ってしましますが、 個人が自作する場合でも、「何を作りたいのか」が「要求」にあたります。
- 「要求定義書」はクライアントの意図や目的を記録します（＝なぜ・何のため）。
- 「要件定義書」は、その意図を開発側がどう実現するかを整理したものです（＝何を・どこまで・どうやって）。
- 多くの場合、ワイヤーフレームやサイトマップは、要件定義と並行またはその後に生まれます。
参考：上流工程での視点の切り替え
| 視点 | 対象 | 主に扱う文書 | 内容の性質 |
|---|---|---|---|
| 発注者視点 | 目的・ターゲット・課題 | 企画書・要求定義書 | ビジネス・目的重視 |
| 受注者視点 | 実現手段・構成 | 要件定義書・構成図・WF | 技術と情報設計 |
| 利用者視点 | 行動・導線・理解 | ペルソナ・ユーザーストーリー | UX／体験の視点 |
個人の自作だと、この発注者と利用者の分離が難しくて、作っているうちに「この方が便利」と積み重ねて、結果「目的何だったっけ」となる失敗が見えます。
ちょうどよい例がここにあり、一般的に分かりやすいだろうと上の表をつくってそのまま載せています。 しかし私は、ペルソナ・ユーザーストーリーを分かりません。 一般的に分かりやすい資料と言うことでは正解なのですが、そもそも筆者が後で見てわかるための資料としては、「作成時点ですらわかっていないのにどうなの」という「目的」からしては不正解のものです。 このように、「視点」の問題は大事です。
- 「ペルソナ」は、プロダクトのターゲットとなる具体的なユーザー像を作り出すもの。
- 「ユーザーストーリー」は、そのペルソナがプロダクトを使用する際のシナリオやニーズを文章化するもの。
「上流工程」で、改めてこの上流工程について説明しています。
3.基本原則
基本原則は、
判断や行動の基盤となる
「考え方の土台」です。
基本原則とは、判断や行動の基盤となる「考え方の土台」です。この文書では、コードの書き方や設計判断の背景にある方針を指します。
原則とは、本来、物事を進める上で必ず守るべき根本的な決まりを指します。ここでは、「その決まりをどう定めるか」の拠り所となる基本原則を記述します。
「基本原則」で、このサイトを開発する上で用意した文書を開示しています。
グループ
グループ
「基本原則」は、「要求定義」に基づいて作成されます。
「基本原則」に基づいて、「命名規則グループ」, 「構造設計グループ」の各文書は作成されます。
4.命名規則
命名規則は、
変数名, 関数名などに対して、
名前を付けるための
一貫したルールです。
命名規則とは、変数名、関数名、クラス名などに対して、一貫したルールにしたがって名前を付けることです。
命名規則は、運用上の規則に分類され、この一般的な「規則」の枠組みを コードベースの開発作業の命名に特化して適用したものです。 それは、次のような開発現場のニーズに応えるために存在します：
- 誰が命名しても構造や意味が読み取れる（判断の一貫性）
- ビルドやCI/CD、静的解析などの自動処理と整合性がある
- 命名に個人差が出ず、他者や未来の自分が理解しやすい
- 柔軟な運用が必要な場面でも、明示された例外のもとでのみ運用できる
たとえば、すべての変数をキャメルケースで書く、クラス名の先頭は大文字にする、などの決まりがそれにあたります。
このような命名のルールは、構造設計やコーディングルールと並んで、コード全体のわかりやすさや保守性を高めるために使われます。
この文書の命名規則は、基本原則に基づいて設計されています。
「命名規則」で、何を決めると良いかなどを記述しています。
グループ
「命名規則グループ」の各文書は、「基本原則」に基づいて作成されます。
「命名規則グループ」の各文書に基づいて、「実装」のHTML/CSS/JS等は作成されます。
「命名規則グループ」の各文書には、「フォルダ・ファイル命名規則」, 「メンバの命名規則」, 「セレクタの命名規則」などがあります。
5.データ設計
HTMLは、
データ記述言語です。
そのデータの構造を
設計する事は、
HTML文書の構造を
設計する事です。
使い捨ての文書だとしても、やはり簡易でも良いから設計はするべきでしょう。
「データ設計」で、どの様に決めると良いかなどを記述しています。
6.テンプレートエンジン
テンプレートエンジンは、
テンプレートと呼ばれる雛形と、
あるデータモデルで表現される
入力データを合成し、
成果ドキュメントを出力する
ソフトウェアまたは
ソフトウェアコンポーネントです。
HTMLに於いてテンプレートエンジンというと、
「テンプレートエンジン」で、何を学ぶと良いかなどを記述しています。
7.テスト仕様
検証の手順書というか
チェックシートの様な物というか
文書などで明確にしておくことは
大事です。
なにより検証が大事です。
検証は大事です。その検証を確実に, 有効な物にする為にも、それについての仕様を作成したり, 設計する事は良い事だと思います。 当然それに凝りすぎて、作業が大変になってミスが発生しやすくなれば、返って問題です。 それ故に、検証も事前に文書化する事で、作成側も分かり易くなるのではと思います。
「テスト仕様」で、改めて記述しています。