Web制作で後悔が生まれるプロジェクトに共通する3つの前提

ここで言う要件定義とは、仕様書を分厚く作ることや、細部まで決め切ることを指していない。

要件定義の本質は、「何を作るか」よりも、「何を作らないか」を決めることにある。
目的、範囲、優先順位、制約条件。
これらが定義されないままプロジェクトが始まると、制作は常に「判断待ち」の状態に置かれる。
その結果、後からの要望追加、認識のズレ、ゴールの移動が繰り返され、完成時には「どこで失敗したのか分からない」という後悔だけが残る。
要件定義がないプロジェクトは、自由度が高いように見えて、実際には後悔が生まれやすい構造を最初から抱えている。

この要件定義は、主にシステム開発といった文脈でより厳密に定義されるものだが、システム開発が少ないコーポレートサイトにおいても確実に生じる。
トップページには何を置くか、下層ページには何を持たせるか。
これは通常、制作会社では決められない。
制作会社は提案を行うことはできるが、その提案が発注者にとって本当に適しているかどうかは、別の問題である。
なぜなら、制作会社は発注者のことを何も知らないのだから。

つまるところ、Webサイトを作るというのは手段でしかない。
その手段とは別に目的が存在し、その目的が曖昧であれば、手段もまた曖昧になってしまう。
曖昧な道筋は、プロジェクトにおいて必ずと言っていいほど「判断待ち」に陥る。

前提を曖昧にする優しそうな言葉の落とし穴

柔軟に対応します、お客様と一緒に作り上げます。
これらの言葉は、前提となる要件を曖昧にする働きを持つ。
一見すると優しい言葉だが、その優しさは発注者にとって「考えなくていい」装置の代替となり得る。
その結果、損失を被る可能性があるのは、発注者自身である。

先に述べたように、制作会社は発注者のことを何も知らない。
コンビニで商品を買うときに、レジ係が購入者のことを何も知らないのと同様に、制作会社も同じ構造の中にある。
ここで制作会社が出す提案は、あくまで提案であり、それ自体がバイアスとなる可能性も含んでいる。

だが、人間の脳は短期的な報酬に弱く、できればエネルギーを消費したくない。
そのため、魅力的な言葉にどうしても引っかかってしまう。
しかし、もし制作会社の提案がそのまま発注者の要件に置き換わってしまうのであれば、それは「一緒に考える」ことではなく、金銭搾取のための誘導に近い。
そこには、倫理的な観点から見ても注意すべき点が含まれている。

Web制作では、「いい感じで」「ユーザー目線で」「今っぽく」といった言葉が頻繁に使われる。
だが、言語として明示されていない要望は、プロジェクト上では存在していないのと同じ扱いになる。

イメージ、感覚、期待。
それらを言語に変換しないまま進めることは、解釈を制作側へ委ねるという選択であり、同時に、後から異議を唱える余地を残す行為でもある。
言語による明示が行われないプロジェクトでは、完成後に「思っていたものと違う」という感情が生まれやすい。
それは齟齬ではなく、最初から共有されていなかっただけだ。

デザインにおける言語化の必要性

例えば、「青」という色を想像してほしい。
海の青と空の青は明度が異なり、信号機の青は緑に近い。
このように、「青」というワード一つ取っても非常に曖昧である。

「空の青」とした場合でも、その空がどのような状態なのかを明示する必要がある。
雲一つない快晴の青なのか、それとも空気遠近による白みを含んだ青なのか。
こうした前提を明示せずにプロジェクトが進行した場合、デザイナーが「そうである」と見做した青になる。

だが同時に、厳密に定義することで生じる危うさも理解してほしい。
例えば、特定の色や配置をピクセル単位で指定してしまうと、それは設計への介入となり、その設計責任は発注者に帰属することになる。
つまり、その設計において何らかの不備や不具合、修正が発生した場合、制作会社の範疇に当たらないケースもあり得る。

日本語の罠

日本語とは、場の前提を曖昧に共有した上で用いられる言語構造である。
この点を認識しておくことは重要だ。

日本語で「大きくしてほしい」という表現は、前提が共有されている場において成立するが、英語圏では事情が異なる。
義務教育で習う英語の比較級を思い出してほしい。
「a more than b（aはbよりも〜）」という構文において、日本語との違いは比較対象が明確である点にある。

前提が共有されていない場で「大きくしてほしい」と言われても、
何と比較して、どの程度、何を目的としているのかという前提が抜け落ちている。
これは日本語が悪い、あるいは英語が優れているという話ではない。
日本語には日本語の良さがあり、その結果として絵文字のような記号文化も生まれてきた。
多言語と比較して優劣を設ける必要はない。
ただし、前提をどこまで明示するかは、デザインを確定させる上で避けて通れない要素である。

最後の前提は、誰か一人がすべての責任を負う、という意味ではない。
重要なのは、判断に対して名前が付いているかどうかだ。

• ・この方針は誰が決めたのか
• ・なぜその選択をしたのか
• ・変更した場合、何が失われるのか

これらが明確になっていないプロジェクトでは、判断はその場しのぎになり、結果だけが後から評価される。
後悔という感情は、失敗そのものよりも、「誰も引き受けていない判断」が積み重なったときに生まれる。
責任を引き受けるとは、正解を当てることではなく、決めたという事実を、後からも引き受け続けることである。

責任を負わない場

よくある社会的な打ち合わせにおいて、「自由にアイデアを出してほしい」という議題のもと議論が行われることがある。
この議題における自由とは、「責任が伴う上での自由」である。

無責任かつ自由な発言を許してしまえば、その議論は無責任な発言の場になってしまう。
各々の発言には責任が生じ、発言しないこともまた、「発言しない」という選択をした責任が帰属する。
人間の行為に常に責任が生じるという考え方は、近代以降、繰り返し議論されてきた。

この構造において、発注者は発注における選択の責任を引き受ける必要があり、ディレクターやデザイナー、エンジニアにも発言の責任、設計の責任が生じる。
一方で、責任を回避するための方法も社会的に用意されている。
「一般的」「社会的」「慣習的」といった語彙を用いることで、責任を自己で引き受けず、社会的規範へ押し付けることが可能になる。

だが、現実にはそれで責任が消えるわけではない。

「一般的ならば〜である」といった言葉遊びは、論理的な検討を行うための前提としては不十分であり、その言葉を使ったからといって責任から回避できるものでもない。
だからこそ前述した「言語による明示」という形で、発言の一つ一つに責任を帰属させる必要が生じる。
一方で、個の責任よりも場の調和を重んじる日本の文化とは相性が悪い点も、考慮しなければならない。
だが、責任の分散と責任の帰属のどちらかを選ぶのであれば、後者を選んだ方が、あと腐れなく終われるだろう。
なぜなら、一つ一つの選択が重くなる分、その結果がどうであれ、自分としてどう生きたかを噛み締めることができるからだ。

本記事で述べた三つの前提は、制作会社の優劣を測るための指標ではない。
それらは、プロジェクトに関わるすべての人間が、どの立場を引き受けるかを選ぶための視点である。

これらの前提を置いた上で、それでも進めたいと判断できるなら、そのプロジェクトは、少なくとも「後悔」からは一歩距離を取れるのではないだろうか。