ありがたいことに、最近はいろいろなプロジェクトについてご相談をいただくようになりました。
そしてそのうち半数ほどが、Webサイトのリニューアルに関するものです。
ところが、ご相談いただいたWebサイトを調査してみると、デザインや構成を考える前に解決すべき問題が見つかることがあります。
例えば各種契約情報が整理されていなかったり、CMSが長期間更新されていなかったり、構築した事業者にしか分からない領域が多々残っていたりなど、その状態はさまざまです。
なかには、以前の事業者さんが少しヤンチャをしてしまい、事業リスクが高い状態になっているケースもあります。
こうしたプロジェクトを安全に進めるには、すぐに「何をつくるか」を決めるのではなく、まず現在地を把握し、計画の土台を整えなければならないと思っています。
今回は、最近特に意識している「前提」と「制約条件」について考えてみたいと思います。
お客様の「たぶん大丈夫」をそのまま「前提」にせず、「正しい前提」を一緒に作る
お客様は、現在のWebサイトについて「まあ、すぐに壊れることはないだろうさ」「簡単にリニューアルできるんだろうよ」と考えていることもしばしば。
これはお客様が暗黙に持っている前提のひとつだと思っていますが、それをそのままプロジェクトの前提条件として採用するのはちょっと危険かもしれません。
お客様の多くは、Web制作の専門家ではありません。目に見える範囲ではWebサイトが動いているため「この先も当たり前に動くんでしょ」「デザインって簡単に直せるだろ」と考えるのは自然なことです。
怖いのは、それら前提が間違っていることよりも「プロジェクトに大きな影響を与える問題が前提条件としてすら認識されていないこと」だと思っています。
表面上は問題なく動いていても、内部ではCMSが長期間更新されていなかったり、プラグイン同士が複雑に依存していたり、サーバーやドメインの契約情報が分からなくなっていたりすることがすごく多くあります。
実際に調査してみるとやはりお客様の認識と大きく異なる場合も多々。「え、そんなことになってたの？」と驚かれるケースは非常に多いです。
誤った前提をもとに計画を立てれば、費用やスケジュール、品質にも影響が及んでしまいます。最悪事業が停止してしまうかもしれません。そうなると大変です。
だからこそ僕らは、お客様から伺った内容をそのまま前提にするのではなく、まず一緒に現在の状況を確認するところから始めたいと思っています。
「お問い合わせフォームが、現在使われていないメールアドレスに送信されていますよ」「テスト環境がないみたいですよ」「公開されているページの中に、現在は使われていない古い情報がいっぱい残っていますよ」などなど、実際にお伝えする内容はさまざまです。
こうした事実やリスクをお客様と共有し、文書として残すことで、何を確認し、どの問題から対応していくべきかがようやく見えるようになります。
お客様が持っている認識と、僕らが調査して分かった事実をすり合わせ、より妥当な前提へ整えていくという最初の段階が、プロジェクトを安全に進めるうえでとても大切なのだと思っています（なんならこれを行わないとプロジェクトにすらなりません）。
制約条件は、根拠まで確認したい
プロジェクトには、どうしても守らなければならない制約条件があります。
予算、公開日、使用するシステム、セキュリティの基準など、その内容はさまざまです。
たとえば仕様書に「Webアクセシビリティの適合レベルAAに対応すること」と記載されていれば、必要な作業や試験をスケジュールと見積もりに含めなければなりません。
制約条件はプロジェクトで選択できる方法や範囲を決めるため、最初に整理しておく必要があります。
ただし、提示された制約条件を確認せずに受け入れるのも危険だったりすると思っています。
例えば「なんでこのプロジェクトにWebアクセシビリティの適合レベルAAが必要なんですかね？ターゲット的にアクセシビリティには配慮をした上で視覚的表現を工夫するのもアリだと思うんですけども」など、ちょっと詳しく聞いてみることもあります。
そうすると「前年の仕様書をそのまま使っただけで、なぜアクセシビリティなるものが必要なのかは分からない。そもそもアクセシビリティってなんなの？」とお客様から言われることも頻繁にあります。
もちろん、契約や法令、組織の方針に基づく条件であれば守らなければなりません。一方で、根拠や目的が曖昧な条件まで必須として扱うと、必要以上に費用や期間が膨らむ可能性があります。
制約条件に関しては、「誰が、何を目的として決めたの？」「必要ないと判断された場合であっても変更できないの？」「どこまで満たせば対応したと判断できるの？」などを確認した方が安全そうです。
制約条件をただ守るのではなく、その根拠まで確認することで、必要な対応範囲とコストを正しく判断しやすくなると考えています。
「これを作って」に対してすぐ答えを出さないこと
お客様から「このサイト / ページを作ってほしい」「この機能を入れてほしい」と言われたとき、そのまま「分かりました！」と進めることもできます。
しかしながら、提示された要望は「解決したい課題に対するひとつの手段」であって、目的そのものではない場合があります。
言われたものをそのまま作っても、本来の課題が解決されなければ、お客様にとっても僕らにとっても良い結果にはなりません。
だから僕らは、ご要望を伺ったうえで「なぜ、そうしたいんですか？」「誰が、どのように使うんですか？」「ここはどうしましょう？」などと確認しながら進めたいと思っています。
背景を聞いてみると、別の方法の方が目的に合っていることもあれば、確認した結果、最初の要望が最も適していると分かることもあります。
要望を鵜呑みにしないというのは、お客様の考えを否定することではないです。何を作るかだけでなく、なぜ作るのかまで一緒に考え、より目的に合った方法を選ぶことも、制作会社の役割なのだと思っています。