サムネイル0702

ビジュアルシンキングについて

考えを整理したり、第三者に伝える時には、図を使うと良いという話。
書籍だと、櫻田潤さんの『図で考える。シンプルになる。』が有名です。

フローチャートなんかもこれに近いと思います。
派生して、LINEのスタンプが流行った理由にも繋がりそう。
特に人の気持ちを表す感情形容詞は、文字にするよりもスタンプの方が表現しやすかったりします。

ゲームの仕様書を作る時も、ビジュアルで説明できる人はうまく伝わりやすいです。
特に仕様書は文字ばかりだととにかく読むのが大変。

ゲームの仕様書の書き方ってたくさん本が出てるのですが、色々な方法がある中で、あえて、かっちり書きすぎないことを提唱してます。
(※あくまでもゲームの話なので他の職種の方からすると異常かもしれないですが)


私は最初、仕様書というのはとにかく細かく書くものだ、と考えていて、文字をズラっと並べていたのですが、すぐにエンジニアさんから読むのがめんどくさいと言われました。

書く方も大変だし、読む方も大変な訳です。

ゲームとして実装される時に間違いがなければよいわけで、私はすぐに文字でかっちり書くのではなく、できる限り図を添えて書くようスタンスを変えました。

ちなみに図といってもデザイナーさんが作るような整理整頓されたものでなくても全然よく、パワポで図形を切ったり貼ったりするだけです。
要は作り手が何を作ればいいかがわかればOKです。
(↑ここがポイントで、ゲームの仕様書は「どう作るか」を書くのではなく「何を作るか」を書く)


非常に残念な話なのですが、かっちり文字で書いても実際はほとんど伝わってません。
実装時にエンジニアさんから質問が来た時に、丁寧な仕様書を書く方からすると、「仕様書のここに書いてあるじゃん!」と文字ばかりの中の一部を指差したりするものですが、「読んでない方が悪い」などといった論争は正直不毛です。

ゲーム作りは速度勝負だったりもするので、

1. 抜け漏れがないよう網羅的に書くことは大事だが
2. どう作ればいいかの指定はいらない、何を作ればいいかを直感的にわかるようにする
3. 特に気を付けてほしい場所(誤解を招きそうな箇所)に文字で補足するくらいでよい
4. それでも作っていると意外と考慮漏れは見つかるもの
5. ↑だからといって、一つも抜け漏れしないようかっちり書こうじゃなく、チームで働いているのだからそれは都度のコミュニケーションでフォローすればいい

と、考えてたりします。


繰り返しですが、これはゲームの現場だから言えることなのかもしれないとは思ってます。
おそらくゲーム業界以外の方からすると、仕様書読むのめんどくさいっていうエンジニアはどうなのよってなるかもです。

何百人もの人員を動員して開発するシステム設計では、ものすごい分厚いマニュアルや手順書や定義書があり、それを何重にもチェックをするフローがあって、1つのミスも起こらないようにしているので、品質管理という観点ではゲーム業界は不具合も多いしまだまだ未成熟です。

今回述べたかったこととしては、
文字ばかりの資料が世の中にはたくさんありますが、

それってもっと読みやすくならないのかな。
図解してくれるだけでも読みやすくなるのにな。
何なら漫画にして動きがあるとさらにわかりやすいのにな。

と感じる場面はあるかと思いまして、裏を返せば、

読みやすくすると多くの人は喜んでくれるので、ビジュアル化するという方法は有効。

というところでした。


以上、最後まで読んでいただきありがとうございました!


過去の記事をマガジン化しておりますので、よければぜひお越しください。


この記事が参加している募集

推薦図書

この記事が気に入ったらサポートをしてみませんか?