« 「上流工程入門セミナー」開催します | トップページ | 「ドメイン駆動開発」への素朴な疑問 »

2010.06.04

「周辺機能」はありきたり・安普請でいい

 業務システム開発においてUIパターン(データ処理パターン)を確立することの意義を何度も強調してきた。とくに、設計フェーズと実装フェーズとを貫くUIパターンを整備することで、設計・開発の生産性は桁違いに向上する。

 UIパターンの整備と活用を怠るとろくなことがない。たとえば、依拠する設計パターンがないので、ユーザーの要望をいちいち「尊重」してしまう。結果的に、個々にユニークな機能が設計・開発される。それらの中には「特定のユーザーしか使えない気の利いた機能」が含まれていたりして、これが案外クセモノだ。そういう機能は、特定ユーザーが自分の雇用強化をはかるための政治的存在だったりする。

 たとえば、そのユーザーがたまたま担当している異質の業務が単一の「気の利いたパネル」からすべてやれるようになっている。「そのパネルからすべての仕事ができるようでありたい」というのは、一見するとまともな要望のように思える。ところが、なにしろ多彩で複雑なことがやれるゆえに、使いこなせるのは特定ユーザだけ。だから、その業務を独占的に担当している彼/彼女を会社はどうしても切れない。このようなことをひとは、悪意がなくてもやってしまうものだ。

 そこまで派手でなくても、メインフレームやオフコン時代の癖のある仕様を無理やり再現したかのようなUIなどはわりと見かける。これも現行ユーザーにとっての利便性を必要以上に尊重してしまった結果だ。「業務担当者は替わる」という事実を前提にすれば、最新ITの特性を生かした形でUIを改善していっていいはずだ。ところが、開発者側に「UIパターンにもとづく効率的なシステム開発」の毅然とした姿勢がないと、現行ユーザーの意向が変に尊重されて八方美人的でコスト高なシステムが出来上がる。

 すべてをパターンに押し込めるべきであってユニークな機能はダメ、と言っているのではない。ある種の業務については、ありきたりなパターンからはずれた特殊な機能で支援される必要がある。そのような業務は事業全体における「制約条件」になっているので、お金をかけて支援することは理にかなっている。たとえば、一般顧客からの電話受付で受注するような事業では、電話を受け付けながら手際よく受注登録するための独特な支援機能が必要で、そういうものはお金をかけて手作りすればよい。しかし、8割がたがEDI受注で、残りがFAXと電話で受注されるといった業態であれば、対話形式での受注登録機能にコストをかけても割に合わない。

 事業の制約条件を効果的に手当てするための特殊機能を便宜上「コア機能」と呼び、それ以外を「周辺機能」と呼んでおこう。物流部分以外に制約条件があるような事業では、アプリケーションが「周辺機能」だけで出来ているという場合も少なくない(コア機能ばかりというのもあり得ないわけではないが、特殊な事例だ)。

 従来のシステム開発では「コア機能」も「周辺機能」も同じような扱いで手作りされてきた。結果的に、開発コストがいたずらに膨らんでしまった。そんなやり方では依頼者も開発者も不幸になる。依頼者は費用をより多く払う羽目になるし、開発者のより多くがうつ病になる。だから、周辺機能については「ありきたりなデザイン」かつ「安普請(やすぶしん)」に対処して、いっぽうコア機能については個々にきっちり設計・実装する、というメリハリの効いたやり方をとるべきだ。こういった「仕分け作業」も設計者の重要な役割であって、そのためにもUIパターンや業務知識は欠かせない。

 では、UIパターンの一覧は具体的にはどんなものになるのだろう。XEAD Driverでの例を紹介しよう。以下の10種類。これらであれば「仕様書で動く」のである。

1.機能切替ランチャー
 指定機能を条件にしたがって起動するための機能タイプ
2.スクリプトランチャー
 個別に記述されたスクリプトを起動するための機能タイプ
3.明細一括表示
 一次テーブル上の複数レコードを一覧表示するための機
 能タイプ。Excel出力も可能
4.明細一括更新
 一次テーブル上の複数レコードを一括更新するための機
 能タイプ。Excel出力も可能
5.単票表示保守
 一次テーブル上の特定レコードを追加・表示・変更・削除
 するための機能タイプ。Excel出力も可能
6.単票更新
 一次テーブル上の特定レコードを更新するための機能タ
 イプ。Excel出力も可能
7.単票印刷
 一次テーブル上の特定レコードにもとづいて印刷(PDF出
 力)するための機能タイプ
8.見出し明細表示
 見出しテーブル上の特定レコードと、これに関連する明細
 テーブル上の複数レコードを表示するための機能タイプ。
 Excel出力も可能
9.見出し明細保守
 見出しテーブル上の特定レコードを変更し、これに関連す
 る明細テーブル上の複数レコードを追加・変更・削除する
 ための機能タイプ。Excel出力も可能
10.見出し明細印刷
 見出しテーブル上の特定レコードと、これに関連する明細
 テーブル上の複数レコードにもとづいて印刷(PDF出力)する
 ための機能タイプ

 これらで通常の業務システム向けアプリケーションの8割方はカバーできると私はふんでいる(*1)。じっさい、XEAD Driverで実装が進められている「CONCEPTWARE/販売管理」は売掛・買掛・在庫管理機能を含むそれなりに複雑なアプリケーションであるが、これらのパターンにおさまる公算だ。今後、「CONCEPTWARE/生産管理」を実装する過程で増える可能性があるが、それにしても15種類より多くなることはないだろう。

 何度も言ってきたことだが、UIパターンの数は少なすぎても多すぎてもいけない。少なすぎては仕様が硬直的ゆえに使いにくいし、多すぎると多彩すぎるゆえに使いにくい。UIについては「仕様の柔軟さ」と「操作マニュアル不要なありきたりさ」とを両立しなければいけない。その結果がたとえば上記の10種類ということだ。

 UIパターンが開発者にもユーザーにも周知されていれば、上流工程(モデリング工程)での作業効率が良くなる。それだけでなく、実装効率を高めるためのしくみとしてプラットフォームに組み込まれていれば、下流工程の効率も良くなる。「設計フェーズと実装フェーズとを貫くUIパターンを整備することで、設計・開発の生産性は桁違いに向上する」というのはそういう意味だ。

 そして、より多くの機能を規定パターンの中に追い込むためにも、データベースは形式化(正規化)されなければいけない。モデリングの重要性は何度強調してもし足りないくらいだ。


*1.これらには「ログインダイアログ」や「メニュー」等のUIは含まれないが、それらはXEAD Driverによって勝手に生成されるのでパターンに含める必要がない。また、採番やログ管理等のセッション管理機能もXEAD Driverによって提供されるので、個別開発の必要はない。

|

« 「上流工程入門セミナー」開催します | トップページ | 「ドメイン駆動開発」への素朴な疑問 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「周辺機能」はありきたり・安普請でいい:

« 「上流工程入門セミナー」開催します | トップページ | 「ドメイン駆動開発」への素朴な疑問 »