Webサイトやシステム、増築か改築か

増築か改築か

WebサイトやWebシステムの改修を行う際に、どこまで立ち戻って設計や制作を進めていくか、既存データを引き継ぎながら修正するか、それとも更地の状態から組み立てていくか、判断の難しいケースがあります。

ここでは、どのような判断基準でどのように進行していくべきかを検討してみたいと思います。

ここでの「増築」「改築」の定義

“増築” ＝ “日々の運用更新”、“改築” ＝ “リニューアル” となることもありますが、必ずしもそうとは限りません。

リニューアルの場合でも、中身はほとんど既存のものを使い、テキストや装飾などのプレゼンテーション層だけの変更もあり得るからです。

言葉の境界線はプロジェクトや人によって異なるでしょう。
ここでは便宜上、主にデータベースに着目した下記の定義とします。

増築

WordPressなどのCMSで、引き続き同一のCMSを用いてデータベース情報も大きく変えず継続して利用する。必要に応じてデータの部分的な修正を行う。

改築

白紙の状態からDBを組み立てる。移行すべきデータが存在する場合は手作業で投入するか、仕組みを構築する必要がある。

増築が適しているケース

• 追加機能や改修が簡易な場合
  • ロジックや主なデータ構造に影響せず、表面上の変更が目的の場合
• 対応するリソース（人員・スケジュール）が十分でない場合
• 対象サイト・システムの残存期間が短い場合

改築が適しているケース

• 既存サイトやシステムで根の深い問題が生じている場合
  • 情報の分割や配置・ナビゲーションに矛盾がある
  • 全体的なパフォーマンスに問題が生じている
  • アーキテクチャの選定や実装方法が現状の課題に適合していない
• 既存サイトやシステムの目的や目指すものが変わった場合
• 運用フェーズで「かゆいところ」が生じており、簡易には解決が難しい場合

増築に限界が生じるタイミング

ビジネスサイドからの要望に合わせて、コストを抑えつつ俊敏に対応してきたサイトやシステムは、良くも悪くもダッチロールしながら進んできた履歴が地層として溜まって、コード上にも迷いや苦悩が見て取れるようになります。

• 実験的な機能がそのまま継続利用されることになり、実装が長期的な目線でできておらず、運用コストが高い作りになっている
• イレギュラーな対応のために、ほぼ同一のファイルが何パターンもあり修正する際の影響箇所の確認だけで時間がかかる
• 消して良い処理のはずだが、全体像がわからなくなっているので怖くて消せない
• 画像などのアセットが膨大になってきたが、必要なものと不要なものを取捨選択するのが困難
• 取り扱いが難しいくらいにデータベースが肥大化している

技術的負債という表現がありますが、状況にあわせて簡易な実装を重ねたり、外したりすること自体が悪いこととは限りません。

ソフトウェアの美学を追求するあまり、顧客や現場の要求に応えられない状況が続くより、少し泥臭い道程だったとしても目的を果たせた仕事のほうが価値の仕事でしょう。

大切なことは、定期的に現状の本質的な問題や課題に向き合い、解決することです。

これまでの歩みや地層を確認しながら、「過去はこういう要望があった、現状はどのようになるのが理想的か、今後はどうなるべきか」を関係者を含めしっかりと検討し、あるべき形を模索し、推進していく必要があります。

改築への道筋

ヒエラルキー構造・分類体系の整理

増築に限界を感じたら、設計フェーズなどに立ち返り、じっくりと向き合うべき時期になったということです。

しかし、肥大化したシステムやデータは人海戦術で取り組むのは困難で、細かな精査や取捨選択を放棄してそのまま大きな粒度でデータを移行したくなる誘惑に駆られます。

ここではその誘惑に負けず、しっかりと丁寧に情報の再設計を行うことが重要です。

• 情報のヒエラルキー構造を整理
  • ノードやリーフの過不足があれば、追加・削除を行う
• ナビゲーションやユーザー導線が破綻しない設計を目指す
• 想定しているカスタマージャーニーにコンテンツがマッピングできるように整理する

共通フォーマットの定義とエクスポート・インポート

As Is(いま)とTo Be(こらから)の整理ができれば、お互いの情報の橋渡しをするデータフォーマットを検討・策定し、エクスポートとインポートのツールを開発すると良いでしょう。¹

データに切り口やフィルタリングルールが変わることにより、分類体系が変わりマッピングルールの定義や変換が必要になるでしょう。
語彙の統一のためのテキスト置換やHTMLドキュメント構造の置換も必要になるかもしれません。

エクスポートツール実例

• 旧サイト（サービス）のエクスポート機能を用いて出力後、XMLやJSONデータを共通フォーマットにあわせて変換
• インポートツールが読み込めるRSSの出力
• XPathや正規表現置換で必要な情報のみを抽出・変換してファイル出力
• クローラーを作成し既存サイトの巡回し共通フォーマット形式へ保存

インポートツール実例

• 共通フォーマットを読み込み、新サイトへのデータ投入を自動化
• 必要に応じて、複数フォーマット（別途業務システムから出力した製品情報など）の読み込み対応

この考え方はWordPressなどの汎用CMSでも、巨大な静的HTMLサイトでも、大企業向けのCRMでも活用できます。

自動化ツールの副次効果

機械的なデータ移行ツールを整備すると、自身が取り組んでいた物事の情報構造や関連性について、理解がより深まります。
何がしたいか、どうあるべきか、どうやって成り立たせるかが曖昧なままだと機械的なアプローチが難しいからです。

また、データの投入先となるサイトやシステムは、よりマシンフレンドリーで堅牢な設計になるでしょう。

WordPressのような汎用的なCMSの場合、内部の理解、データの持ち方に深い知識を得る機会になるでしょう。

私達はどうあるべきか

先に述べた通り、ソフトウェアの美学を追い求め、顧客や現場のためにならないことは避けるべきですし、泥臭く人手をかけた仕事が求められるタイミングも多くあります。

一方で、どこかでしっかりと難しい課題、すぐに解決できない問題、設計フェーズに影響する課題にも向き合うタイミングもやってきます。

ビジネスの状況や関連する様々な要素にあわせて、適切な対応が求められます。
そのときのために多くの解決策を持つと良いでしょう。

add moreではこのような仕事を手掛けています

株式会社add moreではWebサイトの制作、WordPressなどの汎用CMSを用いたサイト制作、フルスクラッチのWebアプリケーション、静的サイト制作、PoC構築、SPAなど幅広い業務を手掛けています。

Webエンジニアを積極的に採用しておりますので、ご興味のある方はコーポレートサイトまたはWantedlyからご応募ください。

1. 引き継ぐデータ量が軽量な場合、人手で対応が妥当なケースもあるでしょう。 ↩