Jinsei Labを公開する前に決めたこと

Jinsei Labは、暮らしや仕事、技術、学び、ものづくりなどについて、調べ、考え、試したことを、あとから使える形で残していくためにつくったサイトです。
最初の記事では、このサイトをつくった過程を記録します。

サイトづくりでは、構想から設計、構築、運用、改善までを一連の流れとして捉える、システムやソフトウェア開発のライフサイクルを参考にしました。
まず目的と前提を整理し、必要なものを決め、構造を考えてから実装し、その後、実際の表示や動作を確認し、公開してよい状態かを判断する。
規模は小さくても、この基本的な流れは残すことにしました。

今回の初期構築では、目的や要件を整理してから設計・構築・検証を行い、公開後の運用や改善までを一連の工程として考えました。全体の流れは「02. サイトづくりの全体工程」で整理します。
この記事では、Jinsei Labを構想してから最初の記事を公開できる状態にするまでの過程と、公開後の運用・改善、将来の移行・終了について、公開前に決めた方針を扱います。

このサイトの構築と記事管理には、Webサイトをつくり、記事やページを管理できる仕組みであるWordPressを使っています。ただし、この記事はWordPressの操作手順を網羅するものではありません。
何を、どの段階で、なぜ決めたのか。
最初の「つくる」の記録として、この設計過程を残します。

01. 目的と目標と方針

Jinsei Labは、暮らしや仕事の中で生まれた問いについて、調べ、考え、試し、必要ならつくり、その過程と結果を残すための場所です。
学んだことやうまくいったことだけでなく、迷ったこと、失敗したこと、判断を変えたことも含めて記録します。

その理由は、誰かの経験や結論をそのまま正解として受け取るのではなく、前提や条件まで含めて確認できる記録があれば、読む人が自分の場合に置き換えて考える材料になると考えたからです。

同じ方法でも、生活環境、仕事、使える時間、予算、知識、目的が違えば、適切な選択は変わります

そのためJinsei Labでは、「これが正解」と結論だけを示すのではなく、

• 何を問題として考えたのか
• どのような前提や条件があったのか
• 何を調べ、比較したのか
• 実際に試してどうだったのか
• うまくいかなかったことは何か
• どのような条件なら向くのか、向かないのか
• 現時点でどのように判断したのか

まで、必要に応じて残します。

扱う対象は、暮らし、仕事、技術、お金、学び、ものづくり、整理などです。

特定のテーマだけを扱う専門サイトではなく、人生の中で生まれるさまざまな問いを、調べ、試し、必要なら形にする研究と編集の場として運営します。

運営上の目標

サイトを継続するには、サーバーやドメインなどの維持費用がかかります。
最初の運営目標は、こうした維持に必要な費用を、サイトから得られる収益でまかなえる状態にすることです。
その先についても、読者への価値や編集方針を損なわずに継続できる範囲で、収益化の方法を検討します。
広告やアフィリエイトなどによる報酬の有無を理由に、記事の結論や推奨順位を変えることはしません。

編集の方針

Jinsei Labでは、、完成した答えだけでなく、そこに至るまでの調査、比較、試行錯誤、失敗、判断の変更も記録することを基本方針とします。

情報や前提が変われば、過去の判断を見直すこともあります。

その場合は、以前の判断を無理に正当化するのではなく、何が変わり、なぜ判断を変更したのかを残します。

こうした目的・目標・方針を先に整理した上で、次に「そのためには、どのようなサイトが必要か」を要件として考えました。

02. サイトづくりの全体工程

今回のサイトづくりは、次の10工程として整理しました。

図は工程全体の流れを示しています。
各工程でJinsei Labが検討した内容は、次のとおりです。

実際の作業は、この順番を一方向に進んだわけではありません。
途中で前の工程へ戻り、考え直したこともあります。
それでも、いま何の問題を考えているのかを分けておくだけで、作業は整理しやすくなりました。

たとえば、
「ロゴをどうするか」
と、
「このサイトは何のためにあるのか」
は、同じサイトづくりの話でも階層が違います。

小さなサイトであっても、この区別は必要でした。

03. 要件

Jinsei Labをつくるにあたって、サイトに求める条件を先に整理しました。

扱うテーマが変わっても使い続けられること

Jinsei Labで扱うテーマは、今後変わったり増えたりする可能性があります。
そのたびにサイト全体を作り直すのではなく、扱う内容が変わっても使い続けられることを要件にしました。
具体的な分類は、「04. 情報の分類」で扱います。

公開上の個人情報を必要以上に出さないこと

Jinsei Labは、公開上は個人を必要以上に特定できる情報を出さずに運営する方針です。
具体的な設定や運用方法は、後の「06. 情報・運用・品質の基準を決める」で扱います。

記事の蓄積と更新ができること

記事は一度書いて終わりではなく、情報や判断が変われば更新できることを要件にしました。
過去の判断と現在の判断が違う場合には、必要に応じて変更した理由も残します。

04. 情報の分類

前の章で決めた「扱うテーマが変わっても使い続けられること」を実現するために、次に記事をどう分類するかを考えました。
Webサイトでは、記事を大きなまとまりに分ける方法の一つとして「カテゴリー」があります。
たとえば、

AI、Python、VBA、投資、旅行

のように、扱うテーマごとにカテゴリーを作る方法もあります。

この方法は、その時点で何について書いているのかが分かりやすい一方、扱うテーマが増えたり変わったりするたびに、サイトの大きな分類も増えていきます。
そこでJinsei Labでは、「何について書くか」ではなく「そこで何をするか」で、大きく分けることにしました。

Explore — 考える・調べる

問いを立て、そもそも何なのか、なぜそうなるのかを調べる。

Create — つくる

必要なものがなければ、プログラム、ツール、仕組み、文章などを実際につくって試す。

Simplify — 整える

増やすだけではなく、減らす、やめる、整理する、続けやすくすることまで考える。
AIやPython、投資、旅行などの個別テーマは、必要に応じてタグやシリーズなどで扱います。
この分類が将来も最適とは限りません。

現時点では、扱う題材が変わっても比較的維持しやすい構造だと判断しています。

05. ページと導線

現在、サイトの主な入口は次のようにしています。

• Home — ホーム
• Explore — 考える・調べる
• Create — つくる
• Simplify — 整える
• Tools — ツール・再利用できるもの (準備中)
• About — Jinsei Labについて

Explore、Create、Simplifyは、前の章で決めた記事の大きな分類です。
Toolsは、実際に作ったものや再利用できるものをまとめる場所。
Aboutは、Jinsei Labが何をするサイトなのかを確認するための場所です。

一方、Contact、Privacy Policyなどは、記事を探すための入口とは役割が異なります。

• Contact — 問い合わせ (準備中)
• Privacy Policy — 個人情報などの取り扱い方針

Privacy Policyなど、公開済みの補助ページはフッターから確認できるようにしています。
Contactは現在準備中です。

06. 情報・運用・品質の基準を決める

サイトの構成を決めるだけでは、運営を始めた後の判断までは揃いません。

• 何を公開するのか。
• どこまで確認してから記事を出すのか。
• 情報が変わったときにどう更新するのか。

こうした運用上の基準も、公開前に決めておくことにしました。

公開する情報と、管理に必要な情報を分ける

Jinsei Labでは、公開上の個人情報を必要以上に出さない方針で運営します。
一方で、サーバーやドメインなどの契約には、公開しない管理情報も必要です。
そのため、

• 公開する情報
• 運営・管理に使う情報
• 外部へ出さない情報

を同じものとして扱わないことにしました。
記事本文だけでなく、投稿者名、プロフィール、画像、リンク、各種設定から意図しない情報が出ないかも確認します。

記事の品質基準を決める

記事についても、書き終わってから「これでよいか」を感覚だけで判断しないようにしました。
そのために、Jinsei Lab 記事編集基準を定めました。
たとえば、

• 事実、経験、推測、提案を混同しない
• 重要な情報は、できるだけ一次情報まで確認する
• 専門用語を知っていることを前提にしない
• 失敗や判断変更も、必要なら残す
• 根拠より強い表現を使わない

といった基準です。
専門的な内容を避けるのではなく、初めて読む人でも意味を追えることと、内容の正確さを両立することを目指します。

更新できることを前提にする

公開した記事を、完成したものとして固定することもしません。
情報が変わった場合や、実際に使ってみて判断が変わった場合には更新します。
必要な場合は、結果だけを書き換えるのではなく、

• 何が変わったのか
• なぜ判断を変えたのか

も残します。

見た目にも基準を持つ

文章だけでなく、画像、色、文字、余白などについても、サイト全体で大きくばらつかないように基準を決めました。
見た目を整えること自体が目的ではありません。
読みやすさを損なわず、Jinsei Labとして同じ場所に見えることを重視します。
こうした基準を先に決めておくことで、記事やページを作るたびにゼロから判断するのではなく、「Jinsei Labではどう扱うか」を基準に考えられるようにしました。

07. 実装方式・サービスを選ぶ

目的、要件、サイトの構成、運用や品質の基準が決まったところで、それらをどのような仕組みやサービスで実現するかを検討しました。
主に決めたのは、

• サイトを置くためのレンタルサーバー
• サイト専用のURLとなる独自ドメイン
• 記事やページを管理する仕組み
• サイトの見た目や機能を担うテーマ

です。
特定のサービスを先に決めるのではなく、これまでに整理した要件を満たせるかを基準に選びました。

レンタルサーバーを選ぶ

Webサイトを公開するには、サイトのデータを置く場所が必要です。
今回は、自分でサーバーを構築するのではなく、必要な環境を借りて利用できるレンタルサーバーを使うことにしました。
選定では料金だけでなく、

WordPressを利用できるか、運用を続けやすいか、バックアップや復旧の仕組みがあるか、セキュリティ面で管理しやすいか、将来サイトを移す必要が生じた場合に対応できるか

といった点も確認しました。
最安であることより、長く自分で管理を続けられることを重視しました。

独自ドメインを使う

サイトには、Jinsei Lab専用の独自ドメインを用意することにしました。
独自ドメインは、たとえば jinseilab.com のような、そのサイトのURLに使う固有の名前です。
特定の投稿サービスのURLにサイト全体を依存させず、適切に更新・管理を続ける限り、同じURLを維持しやすいことを重視しました。

記事管理にはWordPressを選ぶ

記事やページを管理する仕組みには、WordPressを採用しました。
WordPressは、Webサイトの記事やページを作成・管理できるCMS（Content Management System）と呼ばれる仕組みの一つです。
今回必要としていた、

• 記事が蓄積できること
• 後から更新できること
• 記事を分類できること
• 固定ページを作れること
• 将来必要になったときに機能を追加できること

といった条件との相性を見て選びました。

テーマにはCocoonを使う

WordPressでは、サイトの見た目や一部の機能をまとめたものを「テーマ」と呼びます。
Jinsei Labでは、テーマとしてCocoonを使うことにしました。
さらに、Cocoon本体を直接変更せずに独自の設定や調整を管理できるよう、子テーマであるCocoon Childを利用します。
ここでも、「有名だから」「よく使われているから」だけで決めるのではなく、今回必要としている機能や、今後自分で管理を続けられるかを見て判断しました。
この段階で決めたのは、あくまで何を使うかです。
実際の申し込みやアカウント作成、ドメイン取得などは、次の「契約・環境準備」で行います。

08. 契約と環境を準備する

使うサービスを決めた後は、実際にサイトを構築できる状態を整えました。
この段階では、サーバーの申し込みやドメインの取得、各サービスのアカウント作成などを行いました。

サーバーを契約する

要件と照らして選んだレンタルサーバーに申し込み、サイトを置くための環境を用意しました。
ここでは料金や契約期間だけでなく、管理画面へのログイン方法や、バックアップ機能、セキュリティに関する設定項目も確認しました。
契約に使用する情報と、Webサイト上で公開する情報は別に管理します。

独自ドメインを取得する

Jinsei Labのサイトで使用する独自ドメインを取得しました。
ドメインは一度決めると、記事URLや外部からのリンクなどにも関係します。
そのため、サイト名との整合だけでなく、長く使えるか、将来変更する可能性が低いかも考えて決めました。

管理用のアカウントを準備する

サーバーやドメインなど、サイトの運営には複数の管理画面やアカウントが必要になります。
この段階で、どのサービスを何のために使っているのかを整理しました。

構築を始められる状態まで確認する

契約やアカウント作成が終わったら、実際にサイトの構築へ進める状態になっているかを確認しました。
この段階では、まだサイトの細かな見た目や記事内容を作り込むのではなく、

• 必要なサービスが利用できること
• 独自ドメインを使えること
• 管理画面へアクセスできること
• 次の構築作業へ進めること

までを確認しました。

ここまで整えて、ようやくWordPressの導入やサイト設定といった実際の構築へ進みました。

09. 構築・設定する

契約と環境の準備ができたら、実際の構築へ進みました。
この段階では、WordPressを導入し、テーマやURL、表示、検索、外部共有などの設定を行いました。

WordPressとテーマを導入する

まず、記事やページを管理するためのWordPressを利用できる状態にしました。
サイトの見た目や一部の機能を担うテーマにはCocoonを使い、親テーマと子テーマの両方を導入した上で、子テーマであるCocoon Childを有効にしました。
子テーマを使うことで、Cocoon本体の更新と、Jinsei Lab独自の調整を分けて管理しやすくします。

後から変えにくい設定を先に決める

設定の中には、後から変更しても影響が小さいものと、変更すると既存の記事や外部からのリンクに影響するものがあります。
その一つが、記事やページごとのURLです。
WordPressでは、このURLの形式をパーマリンクと呼びます。
Jinsei Labでは、パーマリンク構造に「投稿名」を採用しました。
今後カテゴリーの構成を変更する可能性があるため、カテゴリー名を記事URLに含めず、記事そのもののURLと分類方法を分けることにしました。
これは「投稿名」がすべてのサイトに適しているという意味ではなく、今回の要件と今後変更する可能性を考えて決めたものです。

公開される情報を確認する

公開上の個人情報を必要以上に出さないため、記事本文だけでなく、WordPressやテーマによって自動的に表示される情報も確認しました。
たとえば、

• 投稿者名
• 著者ページ
• 投稿日・更新日
• プロフィール
• SNSに関する情報

などです。

公開上の名義は「Jinsei Lab 編集者」としました。
固定ページでは、その役割から投稿日や投稿者名を表示する必要性が低いと判断し、非表示にしています。
一方、記事については「いつの情報か」が判断できるよう、投稿日や更新日は残します。

検索への表示と、ページの公開状態を分ける

検索エンジンがWebページを検索対象として登録することを、インデックスと呼びます。
構築中は、検索エンジンにサイトをインデックスしないよう求めるWordPressの設定を利用しました。
ただし、この設定はサイトそのものを非公開にするものではありません。

サイトの外でどう表示されるかも設定する

Webサイトの記事は、サイトの中だけで見られるとは限りません。
検索結果やSNS、メッセージアプリなどで、リンクだけが先に見られることもあります。
そのため、

• 検索結果に使われる可能性のあるタイトルや説明文
• 検索エンジンに、正規URLとして扱ってほしいURLを示す設定
• SNSなどで共有されたときのタイトルや画像
• 著者として表示される情報

なども確認しました。
SNSなどで共有された際のタイトルや画像などを指定するメタデータの仕様の一つが、OGP（Open Graph Protocol）です。
Jinsei Labでは、Cocoonの初期画像をそのまま使わず、正式シンボルとサイト名を使った共通画像を用意しました。

ここまでで、サイトを実際に表示できる状態は整いました。
次は、設定画面の値だけでは分からない部分を、実際のページを使って確認します。

10. 検証・公開前確認

設定が終わったら、実際のページを使って、意図した状態になっているかを確認しました。
設定画面の値が正しくても、実際の表示では想定と違うことがあります。
そのため、本番の記事を公開する前にテスト用の投稿を作り、実際の画面で確認しました。

表示を確認する

まず、PCとスマートフォンの両方で、主要なページや投稿の表示を確認しました。
見たのは、

• タイトル
• 投稿日・更新日
• 著者表示
• カテゴリー
• 目次
• 関連記事
• アイキャッチ画像
• ナビゲーション
• リンク

などです。
画面が崩れていないかだけでなく、読者が迷わず情報をたどれるかも確認しました。

公開される情報を確認する

公開上の個人情報を必要以上に出さないため、本文だけでなく、設定から意図しない情報が出ていないかも確認する必要があります。
投稿者名、プロフィール、著者ページ、画像、リンク、SNS共有用に設定される情報などを見直しました。
公開する必要のない情報が含まれていないかを確認します。

サイトの外に出る情報を確認する

Webサイトの情報は、検索結果やSNSなど、サイトの外側にも表示されることがあります。
公開前には、検索結果向けに設定したタイトルや説明文、SNSなどで共有されたときに使われる画像などが、意図した内容になるよう設定されているかを確認しました。
ただし、構築中は検索エンジンへの登録を抑制していたため、実際の検索結果でどのように表示されるかは、公開後に確認する項目としました。

記事そのものの品質を確認する

表示や設定だけでなく、記事の内容も公開前に確認します。
Jinsei Labでは、あらかじめ決めた記事編集基準に沿って、

• 事実と経験を混同していないか
• 根拠が必要な箇所を確認しているか
• 専門用語を知らない読者を置き去りにしていないか
• 個人情報や公開すべきでない情報が含まれていないか
• 出典、日付、リンクに誤りがないか

などを見直します。
文章を書き終えたことを、そのまま公開できる状態とは考えないことにしました。

デザインにも終了条件を置く

デザインは、直そうと思えば際限なく変更できます。
そのため、初期構築では、

• 全体として大きな矛盾がない
• 読みにくくない
• 主要な画面で崩れない
• 把握している範囲で、公開上の重大な問題が見当たらない

ことを、いったんの終了条件としました。
細かな改善は、実際に運用してから必要に応じて行います。

ここまで確認して、次に「公開してよい状態か」を判断します。

11. 公開判定・公開

検証が終わったら、最後に「公開してよい状態か」を判断しました。
ここでは、設定が完了しているかだけではなく、内容、表示、権利、匿名性、運用上の問題を含めて、公開して問題がないかを確認します。

公開できる状態かを判断する

Jinsei Labでは、公開前の確認結果を大きく3段階で考えます。

〇 公開可
　　確認した範囲で、公開を妨げる重大な問題が見当たらない状態。

△ 要修正・要確認
　　追加確認や修正をしてから公開する状態。

× 公開不可
　　そのままでは公開しない状態。

たとえば、

• 公開する必要のない個人情報や、必要以上に個人を特定し得る情報が含まれていないか
• 公開してはいけない管理情報が出ていないか
• 著作権や商標などについて、権利侵害のおそれや追加確認が必要な点がないか
• 根拠のない断定をしていないか
• リンクや出典に問題がないか
• 表示や操作に重大な不具合がないか

などを確認します。
問題があれば、公開を急がず前の工程へ戻って修正します。

公開前に確認を重ねても、誤りや見落としを完全になくせるとは考えていません。
自分で確認した内容でも、前提を取り違えたり、情報の変化に気づかなかったりすることはあります。
誤りや不足に気づいた場合は修正し、判断そのものが変わった場合には、必要に応じて変更理由も残します。

「完成」と「公開できる」は分けて考える

すべてを理想的な状態まで仕上げなければ公開できない、とすると、いつまでも公開できません。
一方で、未確認の情報や公開上の問題を残したまま出すのも違います。

12. 運用・保守・改善

公開を完成ではなく、運用の始まりと考えています。
実際に記事を公開すると、構築中には気づかなかった問題が見つかることもあります。その場合は修正し、判断が変わったときには、必要に応じてその理由も残します。

公開後は、記事内容の更新だけでなく、WordPressやテーマの更新、バックアップの確認、リンクや表示の不具合、アクセス状況なども確認します。

運用の中で問題や新しい知見が見つかった場合は、個別の設定だけでなく、必要であれば設計判断そのものも見直します。

今回の公開判定を終えたところで、Jinsei Labは初期構築から運用・保守・改善の段階へ移ります。

13. 必要に応じて移行・終了

サイトは、始めたときの環境を永久に使い続けるとは限りません。
利用しているサービスの条件が変わったり、別の仕組みの方が適するようになったり、運営そのものを終了する判断をする可能性もあります。
そのためJinsei Labでは、構築や運用だけでなく、必要になったときに移行したり、終了したりできることも考えておくことにしました。
たとえば、将来別のサービスへ移る場合には、

• 記事や画像などのデータを引き継げるか
• URLをできるだけ維持できるか
• 必要なバックアップを残せるか
• 外部からのリンクや検索からの流入にどう対応するか
• 契約やアカウントをどの順番で整理するか

といったことを確認する必要があります。
また、サイトを終了する場合でも、単にサーバーを解約すれば終わりとは考えません。
残しておく価値のある記録があれば保存方法を考え、公開を終了する情報や、削除すべき管理情報・個人情報などを整理した上で、必要な手続きを行います。
現時点でJinsei Labを移行・終了する予定があるわけではありません。

ただ、「始める方法」だけでなく「やめるときにどうするか」まで考えておくことも、長く運営するための設計の一部だと考えています。

14. 現時点の設計判断

ここまでに決めた主な内容を、現時点の設計判断としてまとめます。

これは、一般的なWebサイトの「おすすめ設定」をまとめたものではありません。
Jinsei Labの目的、要件、現在の運用規模を前提に選んだ結果です。

今後、記事が増えたり、実際の運用で問題が見つかったりすれば、判断を変更することもあります。
その場合は、現在の設定に固執するのではなく、なぜ変更したのかまで残すことにします。

15. 小さなサイトでも、工程をなくさない

Jinsei Labは必要以上に運用を複雑にしない小さなサイトとしてはじめました。
そのため、大規模なシステム開発と同じ量の設計書を作ったり、複雑な承認手続きを設けたりする必要はありません。
一方で、今回のような小さなサイトでも、目的や公開前確認などの基本的な工程は省かないことにしました。

• 目的を決める
• 必要な条件を整理する
• 選択肢を比較する
• 公開前に確認する

今回、省略する対象にしたのは、規模に対して必要以上の文書や手続きです。

何のためにつくるのか、何が必要なのか、どうつくるのか、意図した状態になっているかを確認するという工程そのものは残す。

今回も、実際には工程を順番どおり一直線に進めたわけではありません。
サイトをつくりながら前の判断に戻ったり、実際の画面を見て設計を変えたりしたこともあります。
それでも全体の工程を持っていたことで、

今は何を決めているのか。
これは今決めることなのか。
次に何を確認する必要があるのか。

を整理しやすくなりました。

確認、比較、記録、見直しには手間がかかります。
効率化できる作業は効率化しますが、判断の根拠を確かめるために必要な工程まで省くと、後からその判断を確かめたり、やり直したりすることが難しくなります。
手間を減らすことと、必要な工程を飛ばすことは分けて考えます。

小さく始めることと、考える工程を飛ばすことは同じではありません。
Jinsei Labでは今後も、必要以上に仕組みを重くしない一方で、判断に必要な工程は残す方針で運営していきます。

16. 現時点の結論

今回の初期構築では、WordPressの設定から始めるのではなく、目的、要件、設計、選定、構築、検証、公開判断に加え、公開後の運用・保守・改善と、必要に応じた移行・終了までを一連の流れとして考えました。

今回のような小さなサイトでも、私の場合は、工程を分けることで整理しやすくなりました。
しかし、これでJinsei Labが完成したわけではありません。
実際に運営すれば、今の設計が合わなくなることもあるはずです。
そのときは変更し、何を変えたかだけでなく、なぜ変えたのかも残します。

ここからは、運用・保守・改善の段階です。
Jinsei Labそのものも、これから調べ、試し、つくり、整えていく対象の一つです。