あらゆる状況を想定した物づくり
JavaScriptにおけるホームページのコンテンツ、
GoogleAppsにおけるワークフローの開発などに、着手しております。
しかし、これらは単に作って動けばいいというものではありません。
お客さんが、それらを操作する要素がある限り、
たぶん行われるであろうと思われる操作を想定し、
その対策も必要だと思います。
まずは、ホームページコンテンツのひとつで、
サムネイルをクリックすると切り替わるスライドショーを作る場合、
お客さんの中には、そのサムネイルを連打したり、
高速でサムネイルをクリックしたりするかもしれない。
ひとまずは完成して、とりあえずクリックすれば
切り替わるという要素だけを作った場合、
もしお客さんが、先述のような操作をした場合、
画像の切り替わりが、おかしくなってしまいます。
単に待ち時間なしで切り替わるのであれば、
その心配は、ほとんどないとは思いますが、
スライドショーに、フェードアウトなどのエフェクトを入れ、
完了までに待ち時間を導入すると、
その間に行われたクリックの動作が蓄積され、
あらぬ動きをしてしまう可能性があります。
それを防ぐためには、
スライドショーで動いている部分のキュー
（蓄積され待っている動作命令）の数を取得し、
それが１つでもあるようならば動作しないというように制御しています。
とりあえず完成し、自分で動かしてみようと思うと、
自分で行うテストプレイの場合は、
自分が想定した動きしか調べることができないため、
乱暴な操作に対する対策も、意外にも抜けている場合もあります。
こういうのは、テストプレイ抜きで自然に触ってみなければ、
わかりにくい要素でもあります。
なので一度自分が作ったものを、
遊ぶつもりで乱暴に触ってみるのがいいかもしれませんね。
GoogleAppsのワークフローに関しても、
主にスプレッドシートをスクリプト制御しているものですが、
これも単に座標を指定し、取得・更新するだけでも動作はします。
しかし、直接座標を指定する方法では、
もし列を変更した場合は、正常に動かなくなる場合もあります。
その対策として、１行目の文字列だけは維持してもらうことにして、
列の配置を変更しても動作するようにしています。
つまり、各列のタイトルとなる１行目の文字列の列番を取得する過程を別に作成し、
どのタイトルがどの列に移動しようが、その列の走査を可能にしています。
お客さんは、見やすいように列の順番を変更する可能性もあるので、
そういった工夫をする事で、少しでも柔軟な使い心地を実現できるかと思います。
もうひとつ想定しているのが、全角英数字を使われる事です。
人によっては、全角数字のほうが大きくて見やすいと思う人もいますが、
システム上では、それらは別物の文字として扱われる事を知らないという場合もあります。
とくにテンキーの使用に外付けか「Fn」キーの併用が必要なノートパソコンの場合は、
数字は全角で入りやすいです。
文字種として異なるだけでなく、より便利にするという意味でも、
私の場合は、内部で半角に変換し、計算もできる状態にしています。
たとえば「2０１3」のように、全角まじりの数字でも、すべて半角に修正して扱います。
さすがに漢数字を変換するというような極端な事は、勘弁していただきたいところですが・・・
GoogleAppsにおいては、
お客さん側でも見える部分のほぼ全ての部分を変更できるため、
あらぬ部分を変更してしまう可能性も想定できます。
その対策としては、変更してはいけない部分を警告したり
変更できないようにするという手もありますが、
それが難しい、または不可能な場合もあります。
そういう場合には、お客さんが操作する部分を極力減らせばいいと思うのです。
あちらこちらと色々操作や設定をする部分を増やすよりも、
それを１箇所にまとめて、数を減らしていったほうが、
お客さん側でも触っても安心な部分がわかり、
システムを壊してしまう恐れも格段に減るはずです。
つまりは、つまずいてしまう足元の物に毎回気をつけるよりも、
つまずかない場所に置いておくほうが、より合理的でしょう。
また、お客さんがどんな操作をするのかを想定する事で、
新しい便利なシステムへのアイデアにつながる場合もあります。
システムの維持のために、ここを改変してほしくないと思ったら、
改変しないようにお願いするよりも、改変の必要がない仕組みにする事で、
先ほどの通りにお客さんにとって便利なシステムを考え出す事ができます。
たとえば複数のファイルを規定のフォルダに置くように指示するのではなく、
ファイル名に特定の文字列を入れる事だけを守ってもらい、
それらを、ひとつのフォルダに入れてもらうだけで、
ファイル名に従って仕分けする仕組みも思いつきました。
作ったものを扱うお客さんの行動を想定することにより、
より確実な動作の実現と、より便利なアイデアの構築につながると思います。
物を作るには、とりあえず想定内の動作ができることに満足するよりも、
一手間かけてでも柔軟に作ったほうが、納品後のデバッグという問題も減り、
より扱いやすく拡張性の高いシステムに仕上がると思います。
