個人開発の記録:作りながら設計が変わっていく話

この記事について

個人開発をしていると、最初に考えた設計のまま最後まで進むことはほとんどありません。

作る前は「これでいける」と思っていても、実際に手を動かすと、画面が見づらい、管理が面倒、セキュリティが不安、公開方法が合わない、あとから記事を増やしにくい、という問題が出てきます。

この記事では、このサイトを作りながら感じた 設計が変わっていく流れ を記録します。

完成品のきれいな解説ではなく、作りながら迷ったこと、やめたこと、変えたことを含めた開発ログです。

最初に考えていたこと

最初は、かなり単純な個人サイトを想定していました。

  • プロフィールを置く
  • 作ったものを置く
  • 記事を少し書く
  • 問い合わせフォームを置く
  • テトリスなどの実験ページを置く

要するに、「自分の作ったものをまとめて置ける場所」があればいい、くらいの考えでした。

この段階では、記事の増え方、SEO、公開後の運用、スマホ表示、サイトマップ、SNSリンク、アイコン、画像管理まではあまり深く考えていませんでした。

でも、実際に作り始めると、個人サイトでも意外と考えることが多いとわかりました。

静的HTMLだけでは管理しづらくなった

最初は、HTMLファイルを1枚ずつ作れば十分だと思っていました。

ページ数が少ないうちは、それでも問題ありません。
プロフィールページ、テトリスページ、100ます計算ページのように、それぞれを個別のHTMLで作れば表示できます。

ただ、記事が増えてくると、次のような問題が出てきました。

  • 各ページに同じヘッダーやSEOタグを書く必要がある
  • タイトルや説明文の管理がばらける
  • 記事一覧を手作業で更新しないといけない
  • サイトマップも手作業だと抜けやすい
  • カテゴリページを作るたびにHTMLを編集する必要がある

そこで、記事は Markdown で書き、Node.js 側で読み込んで表示する形に変えました。

この変更で、記事を追加するときは public/articles に Markdown ファイルを置くだけで済むようになりました。
記事一覧やカテゴリページにも反映しやすくなり、サイトマップにも載せやすくなります。

ここで学んだのは、最初から大きなCMSを作る必要はないけれど、増えるものはデータとして扱ったほうが楽になるということです。

「全部自作する」は思ったより重い

個人開発を始めると、つい全部自作したくなります。

自分で作ったほうが勉強になりますし、動いたときの達成感もあります。
ただ、公開するサイトでは「作れるか」だけでなく「安全に持ち続けられるか」も考える必要があります。

その代表が問い合わせ機能でした。

最初は、Node.js で問い合わせフォームを作り、メール送信まで自分で処理することも考えていました。
でも、実際には次のような不安があります。

  • メール送信の設定が面倒
  • 迷惑メール対策が必要
  • 入力内容の検証が必要
  • 悪用されないように制限が必要
  • 秘密情報の管理が必要
  • エラー時の対応が必要

問い合わせフォームは、作ること自体はできます。
でも、個人サイトの本質が「問い合わせシステムを運用すること」ではないなら、無理に自作しない選択もあります。

このあたりから、「自作できるもの」と「自作して持つべきもの」は別だと考えるようになりました。

サイト公開の設計も途中で変わった

ローカルで動いている間は、公開方法をあまり意識しなくても開発できます。

しかし、実際に外へ公開するとなると、考えることが一気に増えます。

  • どこでサーバーを動かすか
  • ドメインをどう向けるか
  • HTTPSをどうするか
  • 自宅PCで動かすなら電源やスリープをどうするか
  • サーバーを止めたらサイトが落ちることをどう考えるか
  • .env や秘密情報を公開しないようにするにはどうするか

最初は、VPSやRenderのような外部サーバーに置く選択肢もありました。
でも今は、自宅環境から Cloudflare Tunnel を使って公開する形を試しています。

この設計は、個人開発の実験としてはかなり面白いです。
自宅PCで動いているローカルサーバーを、Cloudflare Tunnel 経由で外部に公開できます。

ただし、メリットだけではありません。

  • PCが落ちるとサイトも落ちる
  • npm start などでサーバーを起動しておく必要がある
  • MacやWindowsのスリープ設定に影響される
  • 本格運用なら監視や自動起動も考えたくなる

公開方法は、あとからでも変えられます。
だから最初は「今の自分が理解できて、管理できる方法」を選ぶのが大事だと思いました。

SEOはあと付けだと抜けやすい

サイトを作り始めた段階では、SEOはそこまで意識していませんでした。

でも記事ページを増やしていくと、検索に出したいなら最低限の整備が必要になります。

具体的には、次のようなものです。

  • ページごとのタイトル
  • description
  • canonical
  • OGP
  • Twitterカード
  • 構造化データ
  • sitemap.xml
  • robots.txt
  • 適切な見出し構造
  • 画像の代替情報

これらをHTMLに手作業で書いていくと、必ずどこかで抜けます。

そのため、記事の front matter にタイトル、説明文、カテゴリ、サムネイル、キーワードを置き、サーバー側でSEOタグを組み立てる形にしました。

これも、作りながら設計が変わった部分です。

最初は「ページが表示されればいい」と思っていました。
でも公開するなら、「検索エンジンやSNSからどう見えるか」もページの一部です。

トップページの役割も変わった

最初のトップページは、ただの入口に近いものでした。

しかし、記事や制作物が増えてくると、トップページの役割が変わります。

ただプロフィールへ誘導するだけではなく、次のような役割を持たせたくなりました。

  • 新着記事を見せる
  • 注目記事の一部を見せる
  • 制作物へ移動できるようにする
  • このサイトが何のサイトかすぐ伝える
  • スマホでも読みやすくする

そこで、フルスクリーン時は左側に記事の一部、右側に新着記事を出す構成に変更しました。

この変更で、トップページが「ただの表紙」ではなく、「今あるコンテンツへの入口」になりました。

個人サイトは、作ったものが増えるほどトップページの意味も変わります。
最初に作ったトップページにこだわりすぎず、コンテンツの増え方に合わせて変えるのが自然だと思います。

ゲームページを入れたことで設計が広がった

このサイトには、記事だけでなく、テトリスや100ます計算のようなHTMLページも置いています。

最初は「おまけの実験ページ」くらいの扱いでした。
でも、実際にはサイトの大事なコンテンツになりました。

記事だけなら、Markdownを読み込んで表示するだけで済みます。
しかしゲームページが入ると、次のようなことを考える必要があります。

  • Canvasを使うページをどう見せるか
  • スマホ操作に対応するか
  • 通信が必要なページをどう扱うか
  • 記事一覧とは別に制作物として見せるか
  • サムネイル画像をどう用意するか
  • カテゴリを「programming」ではなく「プログラミング」として見せるか

つまり、サイトは記事ブログだけではなく、作品置き場としての性格も持つようになりました。

この時点で、カテゴリ設計や一覧ページの見せ方も変える必要が出てきました。

設計変更は失敗ではない

作っている途中で設計が変わると、最初は「ブレている」と感じます。

でも今は、設計変更は失敗ではないと思っています。

むしろ、実際に作ったからこそ、最初には見えていなかった問題が見えるようになります。

例えば、次のような変化は自然なものです。

  • ページが増えたから記事管理を変える
  • 公開したいからSEOを整える
  • 自宅公開するから起動方法を見直す
  • ゲームを置くからカテゴリ設計を変える
  • SNSで見せたいからOGP画像を考える
  • スマホで見たら使いづらいからレイアウトを変える

設計は最初に決めて終わりではなく、作りながら現実に合わせて更新していくものだと感じています。

ただし、何でも変えればいいわけではない

設計を変えることは大事ですが、思いつきで何でも変えると逆に散らかります。

自分の中では、変更する前に次のようなことを考えるようにしています。

  • 今困っている問題は本当にあるか
  • その変更で管理が楽になるか
  • 逆に複雑になりすぎないか
  • あとから戻せるか
  • 公開中のページに悪影響がないか
  • SEOやURLが壊れないか
  • 自分が継続して扱えるか

特に個人開発では、「高機能だけど自分が管理できない設計」よりも、「少し単純でも続けられる設計」のほうが強いです。

作り続けられない仕組みは、どれだけきれいでも途中で止まります。

今の設計

現時点では、このサイトは次のような考え方に落ち着いています。

  • サイト本体は Node.js と Express で配信する
  • 記事は Markdown で管理する
  • 記事のメタ情報は front matter に書く
  • カテゴリページや記事ページはサーバー側で生成する
  • 静的な制作物ページは public に置く
  • sitemap.xml はサーバー側で生成する
  • 公開URLは https://tap-code.jp を基準にする
  • ローカル確認は http://127.0.0.1:8000 で行う

この形なら、記事も増やせますし、HTMLで作った実験ページも置けます。
個人サイトとしては、今の自分にちょうどいい複雑さだと思っています。

もちろん、今後また変わる可能性はあります。

記事がもっと増えたら検索機能が欲しくなるかもしれません。
制作物が増えたら作品一覧ページを強化したくなるかもしれません。
アクセスが増えたら、自宅公開ではなくVPSやクラウドに移すかもしれません。

でも、それでいいと思っています。
必要になったときに変えればいいからです。

個人開発で大事だと思ったこと

個人開発で大事なのは、最初から完璧な設計を当てることではありません。

大事なのは、作って、確認して、違和感に気づいて、直していくことです。

特に、次の3つは意識したいと思っています。

  1. 小さく作って動かす
  2. 使いながら設計を見直す
  3. 続けられる形にする

最初から大きく作ると、完成前に疲れます。
逆に、小さく動くものがあると、そこから少しずつ改善できます。

このサイトも、最初から今の形だったわけではありません。
作りながら、記事管理、SEO、カテゴリ、公開方法、アイコン、画像、トップページの見せ方を少しずつ変えてきました。

まとめ

個人開発では、設計が変わっていくのは自然なことです。

むしろ、作っている途中で設計が変わらないなら、まだ現実の問題にぶつかっていないだけかもしれません。

最初に考えた形にこだわりすぎず、実際に作ったものを見ながら、必要なところを少しずつ直していく。
そのほうが、個人開発は続けやすいです。

このサイトもまだ完成ではありません。
でも、変えながら育てていける形になってきました。

これからも、作ったもの、詰まったこと、直したことを残しながら、少しずつ改善していこうと思います。