プロジェクトを進めるために、中間成果物として各種のドキュメントが発生する。仕様書、要件定義書、ワイヤーフレームといったものである。いきなり最終成果物（デザインやHTMLなど）まで落とし込むと軌道修正しにくくなる。そのため、要件を段階的に確認し、認識を合わせながらプロジェクトを進めていくのに、ドキュメントは非常に重宝する。
最終成果物を作り上げるデザイナーやエンジニアは、基本的にこれらのドキュメントを手掛かりに自分たちに与えられた役割を果たしていくことになる。しかし一つ注意しておかないといけないのは、仕様書やワイヤーフレームに、必要なことがすべてが書かれているわけではない、ということである。
それは、ドキュメントの精度の問題ではない。もしも、すべての仕様が明確に決まっていたとしても、それを言語化することは極めて難しい。例えば、既に公開されているTwitterを見ながら、完璧な仕様書を作れと言われて、全ての要件を網羅した仕様書を作れるだろうか？
システムの完成像が見えていたとしても、それを網羅し、言語化・文書化していくことは、非常に難しいことなのである。ましてそれが、まだこの世に存在しないシステムであるならば、なおさらである。どんなに優秀な人であっても、そのすべてを定義することは不可能である。未来を見通し、超人的な言語化能力があるエスパーでなければ、そんなことはできない。
つまり、ドキュメントには必ず漏れてる部分があり、あるいは、やってみたら違うことが多く含まれている、ということである。だから、デザイナーやプログラマーは、自分が作っていくアウトプットが、仕様書通りにできているか、ワイヤーフレーム通りにできているかではなく、実際に触れてみて、これで本来の目的が達成されるのか、という視点でチェックをかけていかなくてはならない。
実はこれはドキュメントの話だけではない。クライアントの要望や、ディレクターの指示も同様である。クライアントもディレクターも、完成像がない状態で、未来を頭の中で想像した上で、「こうした方がいいと思う」と言っているだけである。しかしそれは、本来のビジネスの目的に対して正しいという保証もないし、クライアントが本当にしたいことが、それで実現できるとは限らない。
だから、作り手は、そういった要望や指示を鵜呑みにして実装するのではなく、相手が本当にしたいこと、かなえたいことに目を向けて、それを実現できるかどうかを意識して、自分が作るものにチェックをかけていかないといけない。
もちろん、クライアントやディレクターの要望や指示が正しいのなら、その通りにすればいい。しかし、何かが不足しているのなら、その何かを足さないといけないし、それが良くない方法だったら、もっと良い別の方法を提示しなければならない。
例えばフロントエンドエンジニアであれば、仕様書通り、ワイヤーフレーム通り、デザイン通りに実装できたとしても、改めて使ってみて、使いにくいかったりCTAをクリックしにくい作りであったなら、仕様書を無視し、デザイン、設計にまで遡って、改善しなければならない。（遡るというのは、一人で解決するという意味ではなく、IAやデザイナーと協議する、という意味である）
このように、本当に解決しなければならない課題に向き合って発想・行動するか、あるいは相手が言っている範囲内で発想・行動をするかは、できるクリエイターとできないクリエイターを大きく分けるポイントではないだろうか。
仕事をしていて、仕様書通り、指示通りにやったのに、OKがもらえなかったとすれば、それは、指示通りには対応していたとしても、本来の目的には正しく対応していなかった可能性が高い。つまり、自分が与えられた役割のことしか考えず、本来の目的、相手が本当に満たしたいことに目を向けずに作業をしていた可能性が高い。これを「相手の指示が悪い」と捉えていては、クリエイターとしての成長は期待できなくなるだろう。
仕事をするときは、制作者の視点から一歩遠ざかり、この仕事で、クライアントが本当に解決したいことはなんなのだろう、ユーザが本当に喜ぶことはなんなのだろう、という視点で状況を客観的に見つめることができなくてはならない。
