ドキュメントの絵の適材適所

情報システムの設計書を書いていると多くの絵を描く機会があります。

業務フロー等はだいたい書き方が決まっていて、お客様に向けて説明をするときはわかりやすさを一番にします。お客様がシステムに詳しかったり、自分達に向けた資料を作ったりする場合は、DFDの要素を取り入れたり、部分的にフローチャート用の部品を取り入れたりします。

これまでの経験で、画面設計において私が書いた画面イメージがまずくお客様との打ち合わせがうまくいかなかった事があります。

WindowsアプリでもWebアプリでも、サードパーティから製品が供給されるなどしてコントロール用の部品が豊富となり、細かく色の変更なども行うことができるようになっています。そのことで画面が複雑になってドキュメントでの説明が難しくなっているように感じます。

以前であればWebの画面はそうぐりぐりと変わるものではありませんでしたが、JavascriptとCSSの組み合わせ等により、リクエストの発行なし、同じ画面内でぐりぐりとデザインが変わったりということも珍しくありません。Windowsアプリにおいては言わずもがなです。

動く部分については矢印で欄外に「ここを押すとこうなります」という図を描いたり、苦労して日本語で説明したりということをします。もちろん設計書と一緒にデモ画面を作成し、そちらを確認していただくのですが、デモ画面を使用すると必ずといっていいほど「ここはもう少しだけ文字を大きく」といったかなり具体的なご指摘が始まってしまうことがあります。

もちろんそういった指摘が必要なフェーズもありますが、どんなボタン、入力欄、表示欄が必要か、だけをまず決めておきたい段階で微に入り細を穿った話が始まると議論が発散してしまって打ち合わせが失敗してしまうことさえあります。今日はまず何々を決めましょう、というゴールを設定しておかないと失敗しやすいようです。

せっかく詳細にデザインを決めたのにボタンが足りないとなると結局ゼロからやり直しになってしまいますので、そうならないように工夫しなくてはなりません。まずは最初に持っていく設計書はドローイングソフトやWord、Excelのオートシェイプで簡素な”絵”を作成し、あまり細かなデザインを決めないで部品の必要・不要だけを決定します。その後にデモプログラムを作成するなどして、ようやく生々しい画面イメージを確定するという二段構えで行くとうまく進めやすいように感じます。

なお、あるセミナーで聞いた話では男性と女性ではこういった「画面設計」のような作業での頭の使い方が異なるらしく、うまく仕切らないと議論が失敗しやすいそうです。詳しくは説明し切れませんが、女性は具体的な使用場面を想定するのに対し、男性はもう少し全体的なところから物事を考え始め、具体的な部分については後回しにしがちだとか。

色々な人が使用する画面の設計では、多少議論が長引こうとも異なる意見を広く集めたほうが良い画面ができやすい傾向にあると言えます。となると男性女性の考え方の相違を認識し、議論が空中分解してしまわないようにフォローしていく技術が必要になると言えそうです。