2周目のラップ：同じコンテンツを2回改善すると何が起きるのか
私は、毎晩計算機ページを改善する自動化プログラムを走らせています。このプログラムは、検証済みのベンチマーク、計算例、および内部リンクを追加します。これまでに43回のコミットを行いました。
今週、この自動化プログラムは「2周目のラップ」に入りました。すでに改善済みの3つのページを再度訪問したのです。
• P/E Ratio（株価収益率）計算機（2回改善、34日の間隔） • SaaS Valuation（SaaS企業価値評価）計算機（2回改善、35日の間隔） • Book Value（純資産価値）計算機（2回改善、37日の間隔）
2回目の改善によって状況に変化が起きるかどうかを確認したかったのですが、結果は厳しい現実を突きつけるものでした。
Google Search Consoleのデータが真実を示しています。
• P/E Ratio: 711インプレッション、2クリック • SaaS Valuation: 17インプレッション、0クリック • Book Value: 0インプレッション、0クリック
コンテンツは以前より良くなっています。具体的なメタディスクリプションや正確なベンチマークが備わっています。しかし、コンテンツを良くしたところで、Googleによるページの権威性（authority）の評価が変わることはありませんでした。
自動化プログラムはコンテンツを改善しますが、Googleがそのドメインの信頼レベルをどう判断するかを即座に変えることはできません。改善されたページは、依然として検索結果の下位に留まっています。
その一方で、自動化プログラムが一度も手を付けていないページが躍進しています。
注文書作成ジェネレーター（purchase order generator）は、1週間で順位が8位上がりました。クリック数は20回です。インプレッション計算機（impression calculator）は、1,041インプレッション、10クリックを獲得しています。どちらのページも、自動化のキューに入ったことは一度もありません。
これにより、巨大なギャップが生じています。最もパフォーマンスが良いのは、私が手を付けていないページです。逆に、私が最も注力しているページは、ほとんどトラフィックを得られていません。
なぜこのようなことが起きるのでしょうか？
- Authority（権威性）：金融メディアの巨人がP/EやSaaSの分野を独占している可能性があります。どれほどコンテンツを充実させても、彼らが確立したドメインの信頼性には勝てません。
- Intent（検索意図）：自動化プログラムが改善しているコンテンツが、実際のユーザーの検索方法と一致していない可能性があります。
- Competition（競合）：手を付けていないページは、競合の少ないクエリ領域をターゲットにしている可能性があります。
自動化を止めるつもりはありません。7月21日をチェックポイントとして設定しました。4週間後に再びデータを検証します。もし2回目の改善で順位が上がれば、その結果を報告します。もし上がらなければ、「同じことを2回繰り返しても、低い権威性の解決策にはならない」ということが分かったことになります。
あなたはプログラマティックSEO（programmatic SEO）に取り組んでいますか？「コンテンツは良いのに順位が上がらない」という壁にぶつかっていませんか？ぜひコメント欄で意見交換しましょう。
第2ラップ：3つの計算機が2度改善された理由 — 初回実装で残されたもの
前回の記事では、3つの異なる計算機（基本、科学、およびカスタム計算機）を構築するプロセスについてお話ししました。今回の記事では、これらの計算機の進化、具体的には「初回実装（ファースト・パス）」から「第2ラップ」への移行についてお話ししたいと思います。
初回実装（ファースト・パス）：動かすこと
最初のパスでは、とにかく「動くこと」が最優先事項でした。目標は、ユーザーが数式を入力し、計算機がそれに応じた結果を返すという基本的なサイクルを確立することでした。
この段階では、以下のようなことに集中していました：
- 機能の実現: 数式を解析し、計算を実行する。
- ハッピーパス: ユーザーが正しい入力を提供することを前提としたロジック。
- 迅速なプロトタイピング: アイデアを素早く形にする。
しかし、この「とにかく動かす」というアプローチには代償がありました。
第2ラップ：より良くすること
第2ラップでは、焦点が「機能」から「品質」へと移りました。単に動くだけでなく、堅牢で、予測可能で、メンテナンスしやすいコードを目指しました。
この段階で行った主な改善は以下の通りです：
- エッジケースの処理: ゼロ除算、不正な演算子、極端に大きな数値など、ユーザーが「正しい」入力を行わない場合に何が起こるかを考慮しました。
- エラーハンドリング: ユーザーに分かりやすいエラーメッセージを表示し、アプリケーションがクラッシュするのを防ぎました。
- リファクタリング: コードの重複を排除し、ロジックを整理して、将来の拡張を容易にしました。
初回実装で残されたもの
初回実装を振り返ると、いくつかの重要な「残り物」が見えてきました。これらは、開発プロセスにおいて避けては通れないものです。
1. 技術的負債
「とりあえず動く」コードを書くとき、技術的負債は必然的に蓄積されます。コードの重複、複雑すぎる関数、そして一貫性のない命名規則などがそれにあたります。第2ラップでは、これらの負債を返済することに多くの時間を費やしました。
2. 不完全なテスト
最初のパスでは、テストは最小限のものでした。主に「正常に動作するか」を確認するためのものであり、「壊れないか」を確認するためのものではありませんでした。第2ラップでは、ユニットテストを強化し、境界値テストを追加しました。
3. 拡張性の欠如
最初の設計では、新しい機能を追加することをあまり考慮していませんでした。例えば、新しい数学関数を追加しようとすると、既存のコードを大幅に書き換える必要がありました。
結論
このプロセスを通じて学んだ最も重要な教訓は、**「最初の実装は、完成形ではない」**ということです。
最初のパスは、概念を実証し、基盤を築くために不可欠です。しかし、真に価値のあるソフトウェアを作るには、第2ラップ（そしてそれ以降のラップ）が必要です。リファクタリング、テスト、そしてエッジケースへの対応を通じて、コードは初めて「製品」へと進化します。