UIはあるのに機能しない？仕様が整理されていないプロジェクトで起きること

Web制作の現場では、見た目上は問題がなさそうでも、実際に触ってみると「思った通りに動かない」機能に出会うことがあります。

今回は、実際のプロジェクトで経験した小さな出来事をきっかけに、仕様整理とドキュメント化の重要性について考えてみたいと思います。

起きていたこと

とあるWebサイトで、TOPページと共通のヘッダーを下層ページでも使用していました。

そのヘッダーには「エリア切り替え」のUIがあり、ユーザーは北海道・東京・名古屋などのエリアを選択できるようになっています。見た目としては、すべてのページで同じヘッダーが表示されています。

しかし実際に挙動を確認してみると、次のような状態でした。

• TOPページ：エリア切り替えが正常に機能する
• 下層ページ：エリアを切り替えても表示内容は変わらない

つまり、UIは存在しているのに機能していない状態になっていました。

なぜこの状態が起きていたのか

調査してみると、サイトの構成は次のようになっていました。

• TOPページ：静的ページ + PHPで実装
• 下層ページ：CMS（Movable Type）テンプレート

同じヘッダーUIを使用しているものの、実装基盤が異なっていたのです。

結果として

• TOPではPHP側の処理によってエリア切り替えが動作
• MTテンプレート側ではその処理が存在しない

という状態になっていました。

つまり

UIの共通化はされているが、機能の共通化はされていない

という構造です。

こうした問題は、そもそも要件が整理されていないことから起きることがあります。
小規模なコーポレートサイトでも要件定義は必要？「要件」とは何かを考える

仕様を確認してみた

この挙動が「想定された仕様」なのかを確認するため、過去のチケットやBacklogを調査しました。

しかし、見つかったのは別の機能での分岐のログのみで、

• エリア切り替え機能の仕様
• どのページで機能するのか
• CMS側での扱い

といった内容については、仕様として整理された記録を見つけることができませんでした。

その結果、次のような判断ができない状態に陥りました。

• そもそも下層ページでも動作する想定だったのか
• TOPページ専用機能として実装されたのか
• 技術的な制約で下層では動かないのか

仕様が存在しないため、挙動の正誤を判断する基準がないのです。

UIがあることと、仕様があることは別

このケースで改めて感じたのは、次のことです。

UIが存在することと、その機能が仕様として定義されていることはまったく別の話

見た目上は同じUIが配置されていると、ユーザーは当然「どのページでも使える」と考えます。

しかし、開発側では

• 実装基盤が違う
• 処理が存在しない
• 技術的制約がある

といった理由で機能していない場合があります。

そして、それが仕様として整理されていない場合、次のような問題が起きます。

• 不具合なのか仕様なのか判断できない
• 修正範囲が決められない
• 調査に時間がかかる

仕様として整理しておくべきこと

今回のようなケースでは、最低限次の内容が整理されていると判断が容易になると思っています。

1. UIの目的

その機能は何のために存在しているのか。

2. どのページで機能するのか

サイト全体なのか、特定ページのみなのか。

3. 技術的制約

CMSやシステム構成の都合で、機能しない場所があるのか。

これらがBacklogや設計ドキュメントに残っているだけで、後から関わるメンバーの理解度は大きく変わります。

仕様は「開発のため」ではなく「判断のため」にある

仕様書というと、開発者のためのドキュメントだと思われがちです。

しかし実際には、次のような場面で重要になります。

• 挙動が正しいのか判断するとき
• 改修範囲を決めるとき
• 新しいメンバーが参加したとき

つまり、仕様は

後から判断するための基準

として存在しています。

今回のケースでも、もし仕様が整理されていれば、調査に時間をかける必要はありませんでした。

小さな出来事から見えること

今回の出来事自体は、サイト全体から見れば小さな問題です。

しかし、こうした事例は多くのプロジェクトで起きています。

• UIだけ共通化される
• 実装はページごとに異なる
• 仕様が整理されていない

そしてその結果、現場では「これは仕様？それとも不具合？」という議論が生まれます。

制作をスムーズに進めるためにも、

• UIの目的
• 機能する範囲
• 技術的制約

といった情報を仕様として整理しておくことは、とても重要だと改めて感じました。

まとめ

UIが存在していることと、その機能が仕様として定義されていることは別です。

見た目だけでは判断できないからこそ、

• どこで動く機能なのか
• なぜその設計になっているのか

をドキュメントとして残しておくことが、プロジェクトの理解と判断を助けてくれます。

日々の制作の中で、仕様整理の重要性を改めて考えるきっかけになれば幸いです。