実践 UIDD 入門のツールを考える

かつて、MVCが華やかし頃、その昔にはDoc-Viewというのがあり、その前には UI はキャラクタインターフェースとコマンドの組み合わせ出来ていた。そして、今は「プロトタイプUI」を「ユーザビリティUI」と分離させて、いまや GUI は完全にユーザーのものになったのである。

…というのを妄想してプレゼン資料を書いてみるテスト。MDA(Model Driven Architecture) とは違ったアプローチの仕方ですね。

■プレゼン資料

 

■ちまちまと説明

User Interface Driven Development は、UI を中心にしてソフトウェアを構築しよう、という主旨があって「考え中」なのですが、 そのためには、UI と内部ロジックの分離は必須なのですよ。ユーザーとはいえ、ライブラリに対して言えばプログラマもユーザー、プログラマが作ったアプリケーションを使うユーザー、という相対的な面もあり、いわば「おもてなしの心」って奴です(とお茶を濁します)。

さて、VB2 の頃に出てきた一番の売り文句が「プロトタイプが簡単にできる」だったのですよ。当時、VC++ で UI を作るのは非常に大変で、方眼紙を使って Windows アプリの UI を顧客に説明するか、Excel でぽちぽちと作るぐらいしか方法がなかったのです。まぁ、簡単なものであれば Excel を使うのもよく、当時 Excel VBA を使ってユーザーがアプリケーションを作れる、という一大ブームもあったわけで(それで被害をこうむっている人も多いみたいですが)、そのあたりはかつての COBOL を彷彿とさせます。いやいや、皆様あまり歴史は得意ではないようです。
そんなわけで、VB2 を使って「プロトタイプ」というものを作るわけですが、ComboBox やら TreeView やらをまじめに作ると結構大変なのですね。しかも、「顧客に見せる」ということ中身のデータを「ほんもの」らしく揃えないといけないという「固定概念」もあって、プロトタイプのくせに時間がかかっていました。
そして、当時「時間がかかったプロトタイプ」をどうしたかというと、「もったいない」から実プログラムに使おうという「もったいない」号令が発せられたわけです。まあ、プロトタイプにせよ、時間がかかり人件費がかかりコストがかかっているわけですから、マネージャとしてはなるべく「流用」をして、実コーディングの時間を減らす=コストを減らすことをしたい訳ですよ。が、実際はどうだったかというと、プロトタイプはプロトタイプに過ぎず、中身を本格的なプログラムに切り替えるには、それ相応の労力が必要であり、一概にプロトタイプを流用したからといって工数が減るという訳ではなかったのです。むしろ、時間がかかったりします。このあたり「プロトタイプ」としての試作品と、実コーディングを効率化させる「テンプレート」技法との差がわかっていなかった(という人が多かった)ということになります。
さらに言えば、なまじ「プロトタイプ」がきれいに出来上がってしまうものだから、プログラム自体がよくわかっていらっしゃらない顧客様におかれましては、「これ動いているから、これでいいじゃん」とのたまう始末でして、いやいや、所詮、紙芝居にすぎないのですから中身は空っぽなのです。なので、これから作りこみをしなければいけないのですが、「もうできているから、工数を削っていいよね」という仰りようもありまして、「プロトタイプ」に関してはもうこりごりというプログラマの方もたくさんいるかと。

で、ひとつの解決案としては、プロトタイプであること、紙芝居であることをわかりやすくするために、ペーパープロトタイピングという手法を取ったり、Microsoft の提案する Flow ツールを使ったりするわけです。あと、Visio の画面作成ツールとか。

■変更コストについての考察

まあ、画面作成というもの、ユーザビリティテストというものは、ソフトウェアの開発工程において一番最期におかれることが多いのですが、結局のところそれは上記な理由から「プロトタイプ」の練り込み具合、と実コードの入れ込みの乖離が原因だったりします。作ってみないことには、本格手な UI のテストができない、という訳ですね。確かに、車の試作品を作ってコースを走らせて、乗り心地をチェックするという「ユーザビリティ」テストがあるわけですが、これって車の量産よりも前にあるわけで、全体の製造工程の最後にある訳ではありません。もちろん、ソフトウェア開発は通常の製造業(プロダクト)とは違い、一過性のプロジェクトであるので、ソフトウェア開発自体はすべて「設計」であるということお言えるのですが、にしても、わざわざ仕様変更にコストがかかる(人件費と時間の両方がかかる)プロジェクトの最後の工程にユーザビリティテストを置くのはどうかな?と以前より思っていたわけです。

解決方法としては、実は2つあります。

  • ユーザビリティテストでの変更が、無視できるぐらいコストが安い(時間が早い)場合
  • ユーザビリティテストを変更コストの安い、前の工程に戻す。

という2つの方法です。たとえば「無視できるくらいコストが安い」の方法としては、Visual Studio 上でコントロールの背景色を変える、ってのがあります。以前は、コードでちまちまやっていたのですが、最近はプロパティの値を変えるだけですから、おそろしく「コストが安く」なりました。なので、この手のカラーリングに関しては、最後の工程でも構わないのです。よく「仕様変更」の受け入れ判断の基準は、この「変更コスト」が重視されますよね。

そうすると問題は「変更コスト」の高いものです。大体の場合、お客に「諦めて」もらうわけですが、社内アプリならばともかく、パッケージ製品であったり、iPhone などで配布するアプリだったりすると、そのあたりの「ユーザビリティ」は販売数に影響することがあるので、慎重に考える必要がありますよね。場合によっては徹夜で直すという、プログラマの安いコストを使う手段を使うことが多いのです。

でも、ちょっと考え直すと、方法はいくつかあって

  • 変更コストが高いものを、安くする手法を取り入れる。
  • 変更コストが高いものが、販売数(機会損失)に直結するか検討する。

という風に、変更コストに対する対処もいくつかあるのです。機会損失のほうは、もう少し分割できて、Windows Update のように後からプログラムを更新できるようにするとか、リリース後に対処するという「時間コスト」を伴わない方法を取ることもできます。

しかし、このリリース後の変更コストなのですが、リリースした後にもプログラマの時間コストを消費するために、隠れた変更コストではあるのですよ。あまり言及されていませんが、たいていの Web サービスが、サービスをリリースしたあとの不具合対蹠に時間を取られてしまい、新規機能がうまくリリースできない、あるいはサービス自体が陳腐化してしまう、のはこのあたりに原因があります。

というわけで、頭を使って「変更コストが高い」というのを「変更コストが安い」にシフトさせましょうというんが、プロトタイプ UI と実 UI の分離の主旨です。

■プロトタイプ UI の分離

実は、MVC パターンをうまく活用すれば(MVC パターンの実装の活用ではなくて、デザインパターンのひとつとして、ってことです)、View の変更はかなり楽になります。私がよくやる手法として、

  1. プロジェクトの初期の段階では、チープな View を用意して業務ロジックをテスト
  2. 業務ロジック自体は、xUnit を使う。
  3. 画面操作に関しては、チープな View でテストする。
  4. チープな View を徐々に本番 View に変更していく。

という手順で View を作ります。これの良い点は、最初のチープな View を変更するコストが恐ろしく安いことです。画面を増やすのも楽だし、画面自体のバグに悩まされることも少ないのです。かつ、業務ロジックを xUnit でテスト済みとして動かすので、画面のバグと業務ロジックのバグがきれいに分離できます。

しかし、長くこの手法をとっているのですが、問題もあって、工程が進んでいき複雑な View となってしまったときに、業務ロジックの変更が容易ではなくなってしまうのです。本来ならば業務ロジックは View と分離されるべきなのですが、そこは実学としてのソフトウェア開発ですから、混ざってしまうこともしばしばです。その混ざったところでバグが発生すると、なかなか調べるのが大変ということになるのですよ。このあたりは、システム試験までソフトウェア工程を付き合っている方ならばわかると思います。

そこで、昔とっていた手法としては、チープ View を隠し View として残しておくことです。業務ロジックを確認するためのデバッグ UI という立ち位置ですね。複雑になりそうな画面は、途中からデバッグ用の UI を新たに作ったりします。
しかし、これもちょっと問題があって、業務ロジックにチープ View が追随しないことがあるということです。実際デバッグ用に動かしてみたら、画面ロジックが違ってしまっているために「動かない」ということで、デバッグにならない、という落ちになるのです。

そんな訳で、プロトタイプ UI を残す場合には、業務ロジックに追随する形で、プロトタイプ UI を改変する、という手間が必要となり、結局のところ手間=コスト面から、プロトタイプ UI を残さないという結論にならざるを得ないのです。

■高速開発としてのプロトタイプ UI と実 UI

そういう訳で、既存の構造で「プロトタイプ UI」を残すのは難しいという考えから、では、根本から MVC パターンを考え直したらどうなるのだろうか?と思考実験してみたのが先のプレゼンテーションです。MDA が大変なのは、手作業(コーディング量)が多いからです。オブジェクト指向をインターフェース経由で行おうとすると、インターフェース絡みは自動化しておかないと(あるいは言語拡張をしないと)ちまちまとしたコードが多くなります。またインターフェースを重視という思想自体が「神の視点」(この話は後日)という時間軸を無視した思想に基づいてるので、当初の思惑の範囲内でしかシステム構築をできないのです。

そんな訳で、いつでも「後戻り」が可能であるという前提に経って、プロトタイプ UI と実 UI の両方を使っていきます。プロトタイプ UI 自体は極力コストを掛けないというパターンを使って、Excel のグリッドに項目を作ります。実際は、Excel 風のプロトタイプ作成ツールを用意するわけです。

永続化となるデータベースとの O/R マッピング、Model の構成、画面の基本的な Validation、項目同士の結合は、あらかじめ機能として用意してしまいます。項目の追加や削除は、まずはプロトタイプ UI に対して追加削除を行った後に、実 UI に反映させます。プロトタイプ UI の操作、更新のコストを減らすことにより、二度手間のコストを減らす、という方法ですね。

これの発想自体は、Rails や WebMatrix にあるものですが、発想のもととしては CakePHP です。プログラムを動かしながら、画面を構築していくという発想は、他にはないものなので一見してみるとよいです。

CakePHP はマニュアル無しでサイトを作れるのか? | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/1753

な訳で、これを妄想とするか、実装するかはちょっと思案中。Windows Metro か iPad で作るとよりベターかなと考えていますが、どうでしょう?

カテゴリー: UIDD パーマリンク

実践 UIDD 入門のツールを考える への1件のコメント

  1. 匿名 のコメント:

コメントは停止中です。