1語1ページにしなかった理由
用語集を作ることになりました。記事に出てくる専門用語を、初学者向けに解説するページです。
問題は入れ物の選び方でした。1語につき1ページか、まとめて1ページか。この判断に、思ったより多くの要素が絡んでいました。
同じ内容でも置き方で使いやすさが変わるという話と、途中で前提が変わったときにどう判断を修正したか。そして「正攻法が使えないと分かったとき」の落としどころの決め方です。
最初の判断は「1枚にまとめる」だった
理由は運用でした。用語は50個、100個と増えていくものです。1語ずつ投稿画面を開いて登録する形にすると、そのうち止まります。
1枚のページに追記していく形なら、思いついたときに1行足すだけで済みます。続けられる形を優先するという判断でした。
要望が1つ増えて、前提が変わった
次に出てきたのが「初学者にもわかる解説を加えてほしい」という要望です。
これを入れると、1語あたりの分量が変わります。定義1行では足りず、なぜそれが存在するのか、具体例、つまずきやすい点まで書くことになります。1語400〜800字といったところです。
102語 × 600字 ≒ 61,000字1枚にまとめると6万字を超えます。目当ての語にたどり着くまでスクロールし続けることになり、用語集として使えません。
「1枚がいい」という判断は、1語が短いという前提の上に立っていました。深く書くほど、その前提は崩れます。最初の結論に固執せず、条件が変わった時点で見直す必要がありました。
1語1ページを検討した
用語ごとにURLを持たせる案には、はっきりした利点があります。
「WAF とは」で検索した人に、その1語のページを届けられます。1枚にまとめると、ページ全体で1つのURLなので、個々の語では上位に出にくくなります。
記事から特定の語へ直接リンクすることもできます。
ところが、逆効果になる可能性があった
調べていて引っかかったのが、内容の薄いページを大量に作ることのリスクです。
1語400字のページが100枚あるサイトは、検索エンジンから「中身の薄いページが多いサイト」と見なされる可能性があります。個々の語で上位を狙うつもりが、サイト全体の評価を下げかねません。
| 1ページあたりの分量 | 評価 | |
|---|---|---|
| 1語1ページ | 約400〜800字 | 薄いと判断される可能性 |
| 分野別にまとめる | 約7,000〜9,000字 | 読み物として成立する |
「個別ページのほうが検索に強い」という一般論が、この規模では当てはまらないことが分かりました。
もうひとつ、実装上の壁があった
1語1ページにするには、WordPressに専用の投稿タイプを追加する必要があります。ところが調べると、既存の「実績」「スキル」はサーバー上のテーマファイルに直接書かれていました。
つまり追加するには、本番のPHPファイルを編集することになります。
PHPは文法エラーが1文字あるだけで動かなくなります。そしてWordPressの管理画面にも入れなくなります。その状態から戻すにはFTPが必要です。
「たぶん大丈夫」で触る場所ではありません。復旧手段を確保してから行うべき作業です。
分野別に8ページ、という落としどころ
結果として選んだのは、分野ごとに1ページ、全8ページという形です。
/glossary/ 分野の一覧
/glossary/infra/ インフラ・ネットワーク 14語
/glossary/security/ サーバー・セキュリティ 12語
...
各ページの先頭に語の索引を置き、それぞれの語には id を振りました。/glossary/security/#waf のように、外部から特定の語を直接指せます。
1語1ページの利点である「直接リンクできる」は、これでほぼ回収できます。失うのは「その1語だけで検索結果に出る」ことですが、前述の通り、この規模では狙わないほうが安全でした。
索引を置いたことで、ページを開いてすぐ全体を見渡せます。1枚にまとめる案の良さだった「一望できる」は、分野ごとに残っています。
実装で、新しいものを作らずに済んだ
もうひとつ判断があります。用語集のページをどう取得するか、です。
新しい問い合わせを追加すると、このプロジェクトでは型を作り直す必要があります。作り直しにはCMSへの接続が要るので、作業できる環境が限られます。
ところが既存の問い合わせを見ると、こう書かれていました。
getProfilePage(uri: string = "/profile/")URIを引数に取る作りになっていました。プロフィール専用に見えて、実際には「URIから固定ページを引く」という汎用の処理です。
名前だけを分けて公開し、用語集のURIを渡すことで、問い合わせを1つも増やさずに実装できました。
getProfilePage という名前のせいで、プロフィール専用のものに見えていました。中身は汎用なのに、名前が可能性を隠していたわけです。
新しく作る前に、既にあるものが本当に使えないかを見る価値はあります。特に、名前が具体的すぎるものほど確認する意味があります。
今回の学び
まず、前提が変わったら結論を見直すこと。「1枚にまとめる」は、1語が短いという前提の上での正解でした。解説を厚くすると決めた時点で、その前提は崩れています。最初の判断を守ることが目的ではありません。
次に、一般論が自分の規模で成立するかを確かめること。「個別ページのほうが検索に強い」は間違いではありませんが、1ページあたりの中身が薄ければ逆に働きます。条件付きの正解を、無条件の正解として受け取らないことです。
そして、正攻法が使えないときの落としどころを、妥協と考えないこと。今回は本番のPHPを触れないという制約がありましたが、その制約が無くても分野別を選んだと思います。制約から入って、結果的により良い形にたどり着くことはあります。
最後に、新しく作る前に、既にあるものを見ること。名前が具体的すぎるだけで、中身は汎用ということがあります。1つ増やさずに済むなら、それだけ壊れる場所が減ります。
関連記事
読む邪魔をしない
貼り付いたヘッダーと目次が、読んでいるあいだずっと画面を占めていた。下へ読むときは引っ込むヘッダー、スクロール中だけ薄くなる目次、先頭へ戻るボタン。3つの判断の記録。
使っていないものは、書かない
広告を検討して手が止まったのは、広告ではなくプライバシーポリシーが無かったこと。テンプレートを貼らなかった理由と、置き場所・管理の仕方をどう決めたか。
届かない問い合わせ
問い合わせフォームで決めることは3つあった。メールアドレスを載せるか、送信先が未設定のときフォームを出すか、失敗をどう伝えるか。共通していたのは「うまくいったように見えて、実は何も起きていない」状態をどう避けるかだった。