第48回　動きを仕様書に記す難しさ

　Webがインタラクティブになるほど，部品や画面(View)の動きの重要性が増してきています。しかし，そうした重要な「動き」の「設計図」の描き方は，まだまだ未成熟な部分が残されています。画面設計書にあたる仕様書を見るだけで，その動きを的確にとらえることは，かなり難しいと言わざるを得ません。画面設計は，未だに汎用機端末の頃の体裁を基本にしている場合が多く，書く側も読む側も，インタラクティブな画面要素の設計図としては無理を強いられている部分があります。

例えば，ボールの動きを考えてみる

　例えば，ボールをA地点からB地点に移動させる，ということを考えるとします。沢山の動かし方がある訳ですが，クライアント/エンジニア/デザイナという少なくとも三者の頭の中で，その動きについての意思統一がなされていないと，大変なことが起こります。「俺はこう動くとものだと思っていたよ」という相互不理解が，開発末期に発覚した場合などです。

　このボールの動きを仕様書に書く(紙の上で表現する)場合に，どのようなことが想定できるのかを考えてみましょう。上図の「減速移動」の場合を例にして解説していきます。

一般的な仕様書上の表現

　仕様書に，単なるボールの移動として記載するケースです。一番単純ですし，書きやすいものです。しかし，上記のサンプルの動きを伝えていることにはなりません。この仕様書だけが一人歩きして，複数の開発者の間で実装されるとしたら，どこかで「誤解」が生じる可能性があります。

　勿論，矢印の近辺に，速度に関する情報を書くことは，情報を正確に伝えるために，よく用いられる方法です。しかし，正しく読まれない場合や，ニュアンスが伝えられないなどの問題を抱えているのは事実でしょう。

速度情報を記そうとした例

　下図は，ボールの速度について，何かしらのルールを決めて伝えていくケースです。矢印が曲がっていたり，破線の線分の間隔が変化していることで，その仕様書を読む人に，少なくとも何かしらの注意を与えることができます。この表記方法を用いたうえで，数式などの正確な情報を併記するという方法も有効でしょう。

アニメーション的な動きの表現

　もう少し，アニメーション的というか，直感的に記述する方法もあります。こうした表現は，例えば技術に明るくないクライアントの方に見せても，何となくイメージが伝わるという利点があります。

　また，転がっているボールの「回転」を伝えたいといった，ディテールにこだわるような場合にも，記述しやすくなります。もちろん，それは，こうした表現を記述できるツールがあるという前提です。例えば，Microsoft Wordしかない状況で，こうした表現を目指すべきかは，労多くして…となりかねないので，仕様書を書く部隊のスキルにもよります。ドキュメントは作るまでも大変ですが，作ってしまえばメンテナンスという要素を持たざるを得ないので，その意味でも注意が必要です。

仕様書上に書かれる文言

　こうした様々な表記法があることを前提として，実際の仕様書にはどのように書かれることが多いのかを考えてみたいと思います。仕様書は基本的に，部外者に公開されることはないので，全体傾向をつかみにくいものです。でも，Webアプリケーションとして考えるならば，「(エンジニアリング的)画面設計書」的な大方の雛形になっているのではないかと予想できます。

　そうだとしたら，例えば上記の例で，「[play]ボタンをクリックしたら，ボールが動き出す」という部分は，「[play]ボタンを押下すると，その下にあるボールが移動する」のような表現で書かれる場合が多いように思います。実際はクリックであるのもかかわらず，「押下する」と書いたりするのは，「しきたり」にとらわれた考え方と言えなくもありません。

　上記の例では，ボールの動きだけしか書いていませんから，まだわかりやすいかもしれません。しかし，実際の仕様書では，画面全体が記され，そこに様々な部品が乗り，それらが場面転換と一緒に動いたり，変化したりもします。それらの複雑な動きを，言葉で的確に書き記すことは非常に高いスキルが要求されます。そして，同時に読む側にも同じレベルのスキルが要求されます。それは現実的ではないのは明白で，そのために様々な「省略」がなされ，その結果，様々な「誤解」が生まれていくのだと思われます。

仕様書は誰が見るのか

　こうした書き方に注意することの必要性すら感じないという方も，実際は多いかもしれません。しかし，RIAシステムと呼ばれる，インタラクションの多いシステムの場合には特に，こうした「動き」そのものをどう実装するかが大きな価値となり，さらにその「仕様書」が「テスト仕様書」に転化・再編集する場合が多いものです。

　ボールが動いているときに，その軌跡やボール自体をクリックしたらどうなるのか，他のボタンをクリックしたらどうなるかなど，特にB2C(コンシューマ向けサイト)では，そうした細かなチェックが必要となります。そうしたチェックの際にも，誰にでも直感的にわかる仕様書があれば，システムの高品質化につながります。

　データ処理の流れを見せただけで，プログラム的な組み方が浮かぶエンジニアも，アニメーション(タイムライン)的な作り方が浮かぶデザイナも，徐々に生まれてきています。そうした人材が育ちつつある中，擬音を中心としたニュアンスの伝え方も，開発の現場ではしばしば見受けられます。何かが高速で移動するさまであれば，「ビューン」「シューン」「キーン」など様々な擬音が議論が進められ，手振りを交えた結論(例えば「ビューン」と言いながら，手を飛行機のように動かす，など)を，デザイナやエンジニアが反芻しながら，こんな感じかなぁ等と試作を重ねるのです。

　そうした会議は，ある意味恥ずかしいものにも見えますが(いい大人が「ビューン」とか言い合っている訳ですから)，それが一番確実にチーム内でのコンセンサスを得る方法だとしたら，優れているのです。しかし，「仕様書」という形にする際には，そうしたニュアンス部分をそぎ落として，「押下すると，最初早く，目的地に近づくにつれ遅くなるように移動する」などと表記してしまいます。

　次世代のシステム開発を，古いしきたりの中に押し込めて行っているという，窮屈な好例なのかもしれません。あと数年もすれば，ビデオ映像や音声付の「仕様書」が開発現場で手軽に作れ，読め，更新できる時代になるのかもしれません。今の窮屈さは，その過渡期を示すサインであってほしいとさえ思っています。

• 参考）RIAシステム 構築ガイド Essential2007

三井 英樹＠ ビジネス・アーキテクツ / 日刊デジタルクリエイターズ
Webデザイン エンジニアリング目次