職業プログラマの休日出勤

職業プログラマによる日曜自宅プログラミングや思考実験の成果たち。リアル休日出勤が発生すると更新が滞りがちになる。記事の内容は個人の意見であり、所属している(いた)組織の意見ではない。

なぜ入力しにくいformが蔓延するのか?

先日のhotentryにこんなスライドが登場していました。
ふつうのformをつかいたい - はまちや2 - ニコニコ超会議2012
ここで述べられていることの多くは、入力し易いformを作る為に非常に有益なものだと思います。技術的にもそれほど難しい話ではないです。こういう理想を掲げている技術者やマネージャもこの世には多数存在します。それではなぜ、こういう簡単なことすら実装できていないformが蔓延してしまっているのでしょうか。その原因(の推測)をいくつか列挙してみました。

本当に技術力が無い

冒頭に紹介したスライドに出て来る話題の多くを、自分の得意とするプラットフォームですら実装できないような技術者がこの世に居ることは確かです。そんな方々の手にかかれば、どのようなformが出来上がるかは容易に想像できます。まあ、可能性としてはそんなに高くはないと思います。

仕様化が難しい

一般的に、ある組織からある組織へシステム開発を発注するとなると、まず最初に仕様の策定をすることになります。受注する側はその仕様に従って開発を進めていくことになるのですが、その仕様の中にformの入力し易さに関する話が盛り込まれていない場合は実際には開発されません。良心的な技術者であれば開発したいと思うことはありますが、それを開発してしまうと「契約違反」となり、上司から怒られたり監査で引っ掛かったりして悲しい結末を迎えるばかりです。
それできちんと仕様として盛り込もう!ということになったとしても、こういった使い勝手に関する話を正式な文書にするには高度な知識が必要です。多くの技術者は、目の前に入力しにくいformがあればそれを改善するアイデアや技術を多く発揮しますが、何も無い状態から文書を起こしていくというのは非常に難しいでしょう。

予算が足らない/時間が無い

よくあることです。熱意だけでどうにか実装だけやってしまうこともありますが、そんなものは長続きしません。

過度な前方互換

数年前だと「JavaScriptオフでも動作するものを作れ」といった話がよくありました。「JavaScript禁止令」ですね。こういった技術的な制約下において入力し易いformを作るのはなかなか難しいものです。1990年代とか2000年代前半とかだとこれらは妥当な話だったのですが、その時代に身に付いた風習を改めることなく現代に来てしまうと残念な結果を生み出します。
もしJavaScriptが禁止されていなかったとしても「JavaScriptオンな環境でも、オフの環境と同じように動作するようにしなさい」といった話が舞い込んでくることがあります。いや、それって禁止してるのと一緒やん(笑)というツッコミが関係各所から…飛んできません。例えユーザの99%がJavaScriptオンであったとしても、これでは入力し易いformなど生まれません。

プロトタイプのまま放置

プロトタイプの開発時点では「とりあえずのform」だけさっさと実装してしまった後、主要な機能の実装が完了してから再度formに手を入れるべきところ、それをやらないパターンです。

解決策

それでは、こういった問題点を解決するにはどのようにすれば良いのでしょうか?
もちろん以下に挙げるものだけでは解決には至らないでしょうけれども、少しくらいは改善できるかと思います。

使い勝手の仕様の明文化…AppleのHIGに学ぶ

Appleは1980年代の時点で既に使い勝手に対する強いこだわりを持っていました。その成果の一つが HIG (Human Interface Guideline) です。このHIGは実際に書籍としても出版されており、Macintoshのソフトウェア開発者に対して統一された指針が示されました。その結果、Macintosh全体の使い勝手を向上させることになりました。現在でもiPhoneMacOSX向けの HIG は存在しており、各デバイスの使い勝手向上に重大な役割を果たしています。もちろんApple以外にも多くのプラットフォームでHIGは存在します。
言葉で表現するのが極めて難しい「使い勝手」(formの入力し易さ)ですが、これらのHIGを参考にしながら仕様として明文化していくのは非常に高い価値のあることだと思います。特に、どれくらい詳細なところまで仕様として言及すれば良いのか、という点で参考になるかと思います。もちろん、こういった文書を作成するには専門的な知識が必要となりますので、安くはつきません。

明示的な費用の投入

実装するのが技術的に難しくなかったとしても、formの入力し易さを向上させる活動にかかる費用や時間はゼロではありません。独自のHIGを作成するとなると尚更です。

合法な後出しジャンケン…Agile

技術者であるかそうでないかに関わらず、多くの人は入力しにくいformを目の当たりにすることによって、改善すべき点というのを容易に考え出すことができます。最初に仕様を全て定義するよりも、後から仕様を柔軟に変更していくことのできる体制、アジャイルな開発は一つの解決策です。アジャイルな開発でも仕様の文書化は必要であることが多いですが、何も無い状態から文書を起こすことに比べれば、いま目の前にある程度出来上がっているものについて文書を書くのは随分と楽なものです。

権限の移譲

使い勝手に関する仕様の決定権を実装者に委ねてしまうのも一つの手でしょう。途中で邪魔さえ入らなければ、それほど高いコストをかけずに入力し易いformを作ることができるでしょう。もちろん、その実装者がスキル溢れる人であることが必要ですけれども。

ターゲットの選定をしっかりと

僕自身は1990年代後半には「Webサイトたるもの、白黒の2色のみで構成し、画像は使ってはならないものだ」といった運動に参画したりしていましたし、IE7がリリースされた直後には「誰が使うんだよ…。IE6でいいじゃん。」と発言したことを覚えています。こういった具合で僕は古いものを使うのが好きな人間ではありますが、そんなことを言い「続ける」人間は極々少数ですので、僕らをサポートし続けることよりも世の中の大多数の人々に上質のユーザ体験を味わってもらうことの方が重要だと思います。
勇気を持って、異常に古いプラットフォームを見捨てていきましょう。
これによってformの入力し易さ向上を妨げる技術的・時間的・予算的要因が少しは減るはずです。

個人開発者だったら

技術力のある個人開発者であれば、問題になるのは「プロトタイプのまま放置」してしまうことくらいでしょう。これをやらないように気を付けておけば良いかと思います。「怠けない」という程度の対策で十分かと。