1 叩き台を作る昔ながらの手法
前回、大手自動車メーカーの製品マニュアル作成について書きました[操作マニュアル作成の基本]。その中で、プロトタイプアプローチについてふれました。私がテキストを作ったり、マニュアルを作ったりするときには、当然この手法を使います。
叩き台を作ってチェックしていくことは、昔ながらの手法です。プロトタイプアプローチという言い方はなかったと思います。システムの作り方に、ウォーターフォール型とプロトタイプアプローチ型があることを聞いて、後者と同じだと思いました。
まず全体の構想を作ります。その後、各項目の一部だけでも具体的な叩き台を作って、それがイメージと合うかどうか、検討することになります。全体の構想が、完璧に出来上がってから作り出すのではありません。作りながら、変わっていきます。
2 プロトタイプアプローチとウォーターフォール型
中島聡の仕事の仕方も、杉浦和史の仕事の仕方も同様です。
【中島聡】 プログラムを書き始める前に大まかな設計をするのだが、十分な経験を積んだエンジニアは、その段階でのものが「仮設計」でしかないことを良く知っている。だから、その段階で詳細設計書を書くような時間の無駄使いはせず、すぐにプログラム(もしくはプロトタイプ)の作成にかかるのである。
【杉浦和史】 プロトタイプアプローチでは、開発期間内に、いかに頻回にプロトタイプ作成→テスト→反映を繰り返すことができるかがポイントです。それには、“できるだけ早くプロトタイプを作る”ことが求められます。
一方、操作マニュアルの標準的な作り方の手順は、だいたい「企画→構成→表現設計→執筆→作図→レイアウト・デザイン→査読」になっているようです。こちらは、ウォーターフォール型の作り方に類似しているように思います。
3 「ウォーターフォール型」の作り方は不安定
前回ふれた製品マニュアルのケースでは、ウォーターフォール型の作り方の中に、評価の過程を取り入れた感じがあって、違和感をもちました。もちろん、評価をすること自体、必須のことです。しかし、もっと早い段階で評価をしないと、ムダが生じます。
操作には、正解があります。この点、正解のない業務とは違います。両者に作り方の違いがあるのは、そのためです[操作マニュアルと業務マニュアルの一番の違い]。操作に正解があるためなのか、最初に構成して、順次、執筆していくことがよくあります。
しかし、「ウォーターフォール型」風の作り方は、一発勝負のように見えて、不安定な作り方に思えるのです。ユーザーがこれでわかるのか、具体的に確認しながら、使いやすいものに工夫していくことが、使い勝手のよいマニュアル作成につながると思います。
私たちは、具体的な「わかりやすい・わかりにくい」の事例をヒントに、操作の説明の仕方を学んでいく必要があります。個別具体的な事例と向き合うことが重要です。部分を確認することによって、当初の全体構想を見直し、再構築することが可能になります。