私の仕事には、GoogleAppsにおけるシステムの構築や、
マニュアルの作成などもあります。

この２つの仕事は、全くの別物のようにも思えますが、
じつは大きく共通する点があります。
それは、想定して作る事です。

システム構築において想定する事は、
お客さんがどのような使い方をするのか、
そのシステムを見て、どのように感じるのかを考える事が重要です。

単純に仕様書通りに作業をし、
仕様書通りに動くだけのシステムを作るだけでは、
それで便利なシステムが出来上がるわけではありません。
そのシステムで、どのような仕事をお客さんが行うのか、
私はそれも頭で想像して、作業を進めます。
そしてお客さんが、そのシステムを見てどう感じ、
どう操作すればいいのかを把握する様子も想像します。

マニュアルの作成の際もそうですね。
その文章を見たお客さんが、どのように情報を捉えるのか、
それを想像しながら書いています。

マニュアルは単に、システムの概要や操作方法、
動作の結果を書けばいいというものではありません。
たとえそれを書いたとしても、お客さんがそれを読み解くのに、
頭の中にコーデックや解凍ソフトをインストールしていなければ
理解が難解なマニュアルでは、
さらにそのマニュアルのマニュアルが必要な状況ともなりえます。

ちょっと冗談交じりの例えで示してみましたが、
つまりは、お客さんの理解力に委ねる説明は、
説明する側の逃げであるという意識を持って、私は文章を作成しています。
理解が難しい説明書では、むしろそんな説明書は捨ててしまって、
総当りで操作したほうがマシだと思われるでしょう。

最も注意するべき事は、相手が勘違いしないようにする事です。
勘違いはたしかに間違いなのですが、
本人は間違いであるとは気がつかず、それが正しいものと認識しています。
それが勘違いというものです。

正しいと思っている限りは、当然訂正の必要はなく、
それをそのまま実行すればいいものだと誰もが思います。
それを間違いだと気付くのは、実践して失敗したときや途中で矛盾を発見したとき、
そして、他から新しい情報を得たときでしょう。
勘違いは自分自身で気がつくのが難しいことです。

なので、その勘違いをする事も想定に入れて、私は物づくりをしています。
勘違いを誘発しないように、間違えたお客さんが悪者にならないようにと、
それに気を配って物づくりをしたいと思っています。

文章を作成したら、まずは極小の声で口に出してもいいので、
まずは自分で読み解いてみることです。
人は自分とは違うことは当然であり、人の捉え方は人それぞれです。
なので私は、他人がそれを読むのに苦労しないか、
他の捉え方をする可能性はないかどうかを配慮しています。
情報は川の流れと同じく、上流次第で変わっていくものです。
その上流となるのが、情報を伝える側です。

お客さんがそれを手にすれば、どのように仕事が出来るのか、
それはマニュアルもシステムも同じことだと思います。
そのお客さんが仕事をする様子を想定しながら、物づくりを行っています。

Tweet