はじめに：事前準備なしで開発を始めた失敗 #
本郷工業の HP リニューアルプロジェクトは、事前準備をほぼゼロの状態で開始しました。
「とりあえず始めよう」という判断でした。
その結果、プロジェクトの進行過程で、次々と問題が浮上することになりました。この記事では、その失敗と、そこから学んだプロジェクト管理の重要性を記録します。
第1章：事前準備の欠落 — 「決まっていないこと」が次々と浮上 #
1-1. 開発開始時点で決まっていなかったこと #
開発を始める前に、本来は決めておくべきことが、数多くありました。
HP のフォルダ構成
- 画像はどのフォルダに置くか？
- CSS やスクリプトはどこに配置するか？
- このプロジェクト独自のルールはあるか？
ファイル名のルール
- HTML ファイル名は大文字？小文字？
- 日本語を使うか、英語に統一するか？
- ハイフンかアンダースコアか？
古い HP からの引き継ぎ項目と新規構成の区分け
- どの内容は古い HP から持ってくるのか？
- どの内容は新しく作り直すのか？
- どの内容は削除するのか？ これらが明確に決まっていませんでした。
使用する画像のリストアップ
- どんな画像が必要なのか？
- 各セクションで何枚の画像を使うのか？
- 誰が用意するのか？ このリストがなかったため、開発中に「あ、この画像必要だ」と気づくことが繰り返されました。
HP の雰囲気・デザイン方向性
- モダンなのか、保守的なのか？
- 色選びはどうするのか？
- レイアウトのスタイルはどう統一するのか？
HP に載せる項目と順序
- トップページに何を表示するのか？
- スクロール時の読者の導線はどうするのか？
- どのセクションを優先するのか？
1-2. 「決まっていないこと」に気づくプロセス #
これらのことが「決まっていない」と気づいたのは、開発を進める過程での Claude との対話 を通じてでした。
「こういう機能が必要」と Claude に指示する際に、詳細を詰める質問が返ってきます。その質問に答える過程で、初めて「あ、これ決まっていなかった」と気づくのです。
例えば：
Claude: 「お問い合わせフォームをどのセクションに配置しますか？」
自分: 「え、どこに配置するか決まっていなかった」
↓
「では、ページ全体の構成を決めましょう」
↓
ページ全体の構成が決まっていないことに気づく
↓
さらにその前に、「ページに何を載せるのか」が決まっていないことに気づく
1-3. 未決定項目による混乱と非効率 #
これまでの経験から、開発を進める際に何度も「あ、これ以前も決めた気がするけど、もう一度確認しないと…」という状況に陥りました。
テキストファイルやチャットログを読み戻って「ああ、ここで決定していたんだ」と思い出す。
その繰り返しが、開発を遅延させていました。
決定したことが 一箇所に集約されていない ために、同じ事柄について何度も議論する羽目になるのです。
第2章：Git コマンドで管理し始める #
2-1. バージョン管理とプロジェクト管理は別の問題 #
前編（Issue #7）で、Git とコミットメッセージの重要性を学びました。
Git により、以下が可能になりました：
- ファイルの変更履歴が記録される
- 「誰がいつ何を変えたのか」が明確になる
- 必要に応じてロールバックできる
これは、バージョン管理として非常に有用です。
ところが、Git にできることと、できないことがあります。
2-2. Git が解決するもの、解決しないもの #
Git が解決するもの
- ファイルの変更履歴
- 複数環境でのコード同期
- バージョン番号の管理
Git が解決しないもの
- 「このタスクは誰がいつまでに終わらせるのか」
- 「全体で何のタスクが残っているのか」
- 「このタスクは完了したのか、それとも進行中なのか」
- 「複数人で開発する時に、誰が何をしているのか」
つまり、プロジェクト全体の進捗管理 は、Git では不可能なのです。
2-3. コマンドラインでのバージョン管理の限界 #
開発初期は、Git コマンドラインでコミット・プッシュを繰り返していました。
git add .
git commit -m "fix: フォーム検証の修正"
git push
これでバージョン管理はできます。
しかし、「このプロジェクト全体で何をしているのか」が可視化されません。
複数のコミットログを見ても、それが「全体の進捗のどこに位置しているのか」が分かりづらいのです。
第3章：Git だけの限界を体験する #
3-1. 迷路の中を探検している感覚 #
開発が進むにつれて、やるべきことが次々と浮上してきました。
- フォーム機能の実装
- モバイル対応
- スパム対策
- デザイン調整
- セキュリティ対応
- …
しかし、全体でどのくらい進んだのか、何が残っているのか、が見えません。
迷路の中を探検しながら、同時に地図を書いている そんな感覚でした。
やるべきことを見つけては実装し、実装途中で新しい課題を見つけて対応する。その繰り返しです。
3-2. 「課題が何か見えない」という不安感 #
この状態が続くと、精神的な疲労が蓄積されます。
「今、自分たちは正しい方向に進んでいるのか？」 「どのくらい進行したのか？」 「何が残っているのか？」
これらが見えないため、常に不安な状態で開発を続けることになります。
3-3. 混乱は一気に破綻へ #
こうした見えない状態が続くと、ある時点で混乱が一気に破綻する危機感に襲われます。
「この複数の課題、どれから手をつけるべき？」 「優先度はどう判断するのか？」 「進捗状況はどうなっているのか？」
こうした基本的な質問に、すぐに答えられない状態になってしまいました。
第4章：GitHub Issues の存在に気づく #
4-1. HP リニューアル時は気が付かなかった #
実は、GitHub Issues というツールの存在を知りませんでした。
HP リニューアルを進めていた時点では、「とにかく実装を進める」ことに精一杯で、プロジェクト管理ツールの存在すら認識していなかったのです。
4-2. 体験をまとめる過程で発見 #
このプロジェクトの経験を「技術ブログ」として記事化する作業を始めました。
その過程で、以下のことに気づきました：
- ネタとしてまとめるには、何がどこにあるのかを整理する必要がある
- Issue という形式でネタを管理すると、全体像が見えやすい
- Issue のコメント機能で、詳細な議論を記録できる
- ラベルで分類すると、カテゴリごとの進捗が把握できる
4-3. Issue による進行管理の効果を実感 #
実際に GitHub Issues を使い始めると、以下が実現できました：
全体像の可視化
Issue 一覧を見れば：
- 全体でいくつのタスクがあるのか
- 各タスクの進捗状況（ドラフト、準備中、完成）
が一目瞭然
詳細情報の集約
各 Issue に：
- タスクの説明
- 関連リンク
- @claude コメントでの具体的な指示
が全て記録される
優先度管理
ラベルで分類することで：
- 優先度が高いタスク
- 各月の予定
- カテゴリごとの内容
が把握しやすくなる
4-4. 現状：まだ活用の途中 #
ただし、正直に言えば、GitHub Issues の機能を完全に活用しているわけではありません。
- ラベルの有効活用：進行中
- プロジェクトボード：存在すら知らなかった（これからの活用候補）
- Milestone（マイルストーン）：使用していない
ですが、Issue という形式でネタを管理するだけで、プロジェクト全体の見通しが格段に改善されたのは事実です。
第5章：Git とプロジェクト管理は別物 #
5-1. 両者の役割の違い #
ここで重要なのは、Git とプロジェクト管理ツールは 別の問題を解決している ということです。
Git の役割
- ファイルの変更履歴を管理
- バージョンコントロール
- コード品質の追跡
プロジェクト管理ツール（GitHub Issues）の役割
- タスクの管理
- 進捗状況の可視化
- チーム間でのコミュニケーション
5-2. 両者は補完関係 #
実際には、この 2 つは補完関係にあります。
GitHub Issues でタスク管理
Issue #12: 日本語処理の対応
↓
Claude に脚本化指示
↓
コード実装
↓
Git でコミット・プッシュ
↓
Issue にコメントで完了報告
このように、Issue でタスク管理を行い、Git で実装の履歴を記録する。
両者が合わさることで、初めて「プロジェクト管理 + バージョン管理」が完成するのです。
おわりに：開発を始める前に整える 3 つのこと #
HP リニューアルプロジェクトの失敗を通じて、「開発を始める前に整えるべきこと」が見えました。
① 今までのプロジェクトに対するまとめ #
新しいプロジェクトを始める際、まず前のプロジェクトの知見をまとめることが重要です。
「あの時、何が課題だったのか」 「次はどう改善するのか」
これを言語化し、文書化することで、同じ失敗を繰り返さないようにできます。
本郷工業の場合、HP リニューアルの経験を「技術ブログ記事」という形で記録することで、次のプロジェクトへの指針が得られました。
② 新しく作る HP の詳細な仕様 #
開発を始める前に、以下を決定することが重要です：
- ページ構成とセクションの順序
- ファイル・フォルダの命名ルール
- デザイン方向性（色、レイアウト）
- 使用する画像のリスト
- 引き継ぎと新規構成の分け方
ただし、「詳細な仕様 = 変更不可」ではありません。
開発を進める過程で、新しい気づきや環境の変化に応じて、仕様は十分に変更できます。
重要なのは、開発開始時点で、ある程度の決定が存在すること です。
③ パソコン作業環境の確認 #
開発環境の整備も重要です：
- 使用する開発エディタの選定
- Git のセットアップ
- 開発サーバーの環境確認
- 必要なツールのインストール
これらが事前に整っていると、開発開始直後の「環境トラブル」で時間を浪費することが減ります。
さいごに #
プロジェクト管理は、「専門的なツール」が必要な高度な話ではありません。
GitHub Issues のような、シンプルなタスク管理機能でも、十分に効果があります。
大切なのは、以下の 2 つです：
- 開発前の準備 — 最低限の決定を行う
- 進行中の可視化 — タスク管理ツールで全体像を把握する
この 2 つを組み合わせることで、「迷路の中を探検する感覚」から脱出でき、より効率的で、心理的な負担の少ないプロジェクト進行が可能になります。
開発初期では「準備に時間をかけるより、とりあえず始めた方が早い」と思うかもしれません。
ですが、実装経験に基づいて言えば、最初の 1〜2 時間の準備が、その後の開発を数倍効率化させるのです。
このプロジェクト管理の重要性が、次のチーム、次の企業の役に立つことを願っています。