'Top-down vs Bottom-up' Or 'Top-down with Bottom-up'

プログラマーからの観点で作成されたソフトウェアを見ればよく思うのは機能は優れているかも知らないが使い勝手が悪いと言うことです。また、最近避けたいと思っているのは典型的な３つのペーンで構成されたUIです。
例えば、こんな感じ？



あまりにも典型的で飽きて来たと言いましょうかね？もちろん、このようなUIが一番効率的なアプリケーションもあります。ただ若干考えればよりユニークなUIを提供する事もいくらでも可能なソフトウェアでも大抵同じく３ペーンになってしまうとやっぱりなんかつまらなくなります。これは特に個人や小人数で作成されているソフトではよく見られる現象です。多分、プログラミングはできるけど、デザインやUIに付いてはあまり詳しくない事がその原因ではないかと思いますがいかがでしょうか？

そこで、今朝考えた事が、タイトルの「'Top-down vs Bottom-up' Or 'Top-down with Bottom-up' 」です。Top-downとは、エンドユーザの観点から物事を考えて行くとの事、またBottom-upとは技術的な観点から物事を考えて行く事とこの文章では使用しています。
一般的に、プログラマーはBottom-upの思考をすると思います。（これは私自身の経験から^^;）例えば、何か新しい機能を提供する技術やチップなどを見つけると、「これでなんか作ってみようか？」と思っちゃう訳です。つまり、作り手の観点が基本で、使い手の観点などはあまり考えられてません。その結果が上述したような、機能的にはいいかも（！）知らないが使い勝手の悪いソフトウェアができてしまう理由の一つではないでしょうか？

参考として、最近読んだJoelの「User Interface Design for Programmer」では逆の発想として、「Activity-based Planning」を紹介しています。ユーザの観点で、ユーザは何をやりたがるかを真っ先に考えるという手法です。上記の用語定義からすると、正に「Top-down」形式だと言えます。（詳しくは前回のポスティングを参照）

で、今私が捨てないと行けないのは「Activity-based Planning」の対称となる、「Bottom-up」の考え方、言わば、「Technology-based Planning」でしょうね。但し、これは本当に、どっちかを選ぶべきものでしょうかね？両立した方が一番いいと思いませんか？「Top-down」でソフトウェアの要件を決め、UIをデザインし、その裏を「Bottom-up」で作って行くのです。（書いてみたら、まあ、当たり前か。）

二つの異質のものを一人が併せ持つ事は確かに難しい事だと思います。例えると、文武兼備でしょうかね？どちらか一つだけに優れる事も厳しいのが現実でしょう。だから、常は各分野に優れた複数の人がチームを組んで働きます。だが、チームにはコミュニケーションコストが発生しますし、そのコミュニケーションがボトルネックになるケースが多いです。クリエイティブな作業の場合はよりそうです。まだ形になってないクリエイティブな思考を共有するのはほぼ不可能に近いと思います。そしてクリエイティブな思考とは一段形になってからは既に変更が自由にできなくなります。

だからこそ、実は一人の人間が全ての知識を持ち合わせているのが理想なんです。（現実ではなく、理想ね！）でも現実的にはそんな天才肌の人は少ないですね。そこをなんとかしてみたいと思っていますけど、まだそれっぽい答えは見えていません。

まあ、ソフトの要件とデザインについて考えている途中のつぶやきでした。