「いつまで機能中心の開発をやってるんだ！」

先日、ある業務パッケージのデモを見て僕が思ったことだ。

業務パッケージの使いやすさは、ユーザの視点で作られているかどうかにかかっている。しかし多くの業務パッケージが、いまだに開発者の視点で作られているような気がするのだ。

たとえば販売管理のパッケージがあったとする。ユーザの業務は、受注、納期回答、納入処理、代金回収という一連の流れになる。受注の段階だけをとってみると、受注データの一覧表示や受注残の集計、データの修正入力、各種帳票の出力など、同じ受注データに対して、ユーザはいくつかの作業を行う。

つまりユーザの立場からすると、中心に「受注データ」があって、それに付随する作業がいくつかある、という見方になる。

一方、開発者の立場からすると、開発作業は機能別にすすめられるので、逆に「印刷」という機能が中心にあって、その派生物として「受注データ印刷」「納入データ印刷」などが存在する。同様に「修正入力」という機能が中心にあって、そのバリエーションとして「受注データ修正入力」「納入データ入力」などがある。

このように、ユーザの観点は「作業対象」が中心であり、「作業そのもの」はその派生物である。一方、開発者の観点は、「作業（＝機能）そのもの」が中心であり、「作業対象」によってその機能がちょっとずつ変化するという見方である。

残念ながら現状の業務アプリケーションの多くは、ユーザの観点ではなく開発者の観点から作られているように見える。それは、メニューの体系を見れば一目で分かる。メインフレームでおなじみの、階層化メニューである。

メインメニューに「受注管理」「納品管理」「債権管理」などがあって、そこから一段下りると、「受注状況一覧」「受注修正入力」などのメニューが現われ、さらに、「当日受注一覧」「当月受注一覧」などなど．．．何段階ものメニューによって構成されている。

文字表示かグラフィカルな表示かはどうでもいい。どちらにしても、このような階層化メニューは、開発者の頭の中を、何の知恵もなくそのままプログラムにドカン！と反映しただけである。開発者は自分が仕様書に書いたツリー状の機能構成図をそのままメニューにしている。

こんな設計では、ユーザはメニューを上ったり降りたりしなきゃいけないし、どこにどの機能があったのか、いちいち憶えている必要がある。

受注一覧を確認したら、メニューにもどって受注一覧の印刷を選択し、印刷が終わったらまたもどって修正入力を選択し、などなど．．．自然な業務の流れとはほど遠い煩雑な作業を強いられる。

こうした開発者的発想で作られたソフトが使いにくいのはなぜか？それは、開発者が、いつまでたっても機能分析手法を捨てられないからだ。

要求分析のとき、多くの開発者はユーザの要求を機能にバラしてしまう。いったんバラすと、開発に都合のいいように、「画面表示」「入力」「印刷」「バッチ処理」という具合にまとめてしまう。

そうではなく、ユーザから見た処理の対象（オブジェクト）を中心に見ていくべきだろう。ひとつひとつの処理は、その対象に対する操作でしかない。

そう考えれば、メニューは必然的に、階層型のメニューから、その時その時の作業状態に応じて変化する文脈依存型のメニューに変わる。ユーザはいちいちメニューを上ったり降りたりする必要がなくなる。

このようなことは、データ中心のアプローチであるとか、オブジェクト指向分析であるとか、開発者にとっては耳タコになるほど聞かされてきたことじゃないか？

にもかかわらず、いまだに階層型メニューで、ユーザの観点を無視した開発者のひとりよがりソフトが出てくるというのは、SEとしてのモラルの問題だろう。モラール（士気）じゃなくって、モラル（倫理）の問題だ。

つい先日、ある販売管理パッケージのデモを見て、こんなことを思った。

追記：ついでに言わせてもらうと、ソフトウェア技術者は全員カラーコーディネーターの資格を取るべきだ。配色センスが悪いGUIは、見にくいだけじゃなくって、使いにくい。自分には配色のセンスがないという自覚があったら３色以上は使うなぁ〜！（ホームページも同じじゃぁ〜！）