昔、Word vs 一太郎という対決が雑誌を賑わした。やれ、どんな機能がWordにはあって、一太郎にはないなどと言ったスペック上の比較だけがソフトウエアの価値になった。

つまり、表を書いて、機能の有無の数でソフトウエアの優劣が決まる手法だ。これは、コンピューターのソフト/ハードに限らず多くの商品比較の雑誌が今でも取り入れている手法ではないだろうか。これをやると、MacよりWindowsで、Honda StreamよりToyota Wishという選択にならざるを得ない。

こういう日本の状況に起因してか、システム構築のコンペなどでも比較表の優劣でのみ商品や提案の善し悪しを決める人がいる。正確には判断する自信がないため、比較表の○の数で一番多いものを選んでおけば無難だろうという発想ではないだろうか。また、プロダクトを作る側でも、とりあえず、比較表で○が落ちないように機能実装を行い、個性がなくなる方向に開発工数を費やす。昨今の国産PCが、みんなTVが見られたりするのは、そういうことだ。

（これは悲しいかな、公共事業の入札対策で重要。とりあえず入札条件にマッチすれば、あとは金と政治の問題なので、他社の仕様を基準に書かれた入札条件でも、ノーカスタマイズで対応できることは重要だ。PCの入札で、OASISのデータが読めること・・・とか書いてあったとか言う笑える話はさておき。）

しかし、ソフトウエアにどんな沢山の機能があっても、それを扱うユーザーインターフェースが使いにくいと、まったくその機能を生かすことはできない。しかし、実際に運用するのは、製品やサービスを選択する人とは違う人だったりすると、そんなことは選択者には無関係である。システムを運用者が扱えない場合で、かつ会社の力関係が「選択者＞運用者」の場合には、この責任は全て運用する者が無能であるという扱いになる。

ここがポイントだ。すなわち、会社としての利益を最大にするには何か？ということを考える場合、本来、UIを中心に機能設計をアプローチすべきだ。もちろん、システム開発は、ビジネスロジックが中心なわけだが、その中の一つにオペレーションコストを前提とした、肝心のシステム自身のUIは重要な要素になるべきだろう。本当は。

何でもアリのシステムでは、大体、UIが破綻して使いにくく、ヒューマンエラーのおきやすいものになる可能性が高い。決定権を持つ人が機能の絞込みに自信をもてないシステムは、往々にして不幸な結末を迎える。
どんなにシステム開発者の能力が高くても、決定権を持つ人以上のシステムは作れない。これが現実。

本当は、機能を絞るなりUIを工夫すべきだし、そういう提案ができ、協調できるシステム会社と組むべきだろう。
しかし、僕はコンサルでも上級SEでもないので、そこで何とかしましょうとかの「かくあるべし論」はさておき、もうちょっと生きていくために現実的な意見を書く。

ITに対するセンスがない担当者に対するアピールの場合、その人の会社での役割と力関係をきっちり見極める必要がある。

システムの選択者が運用者ではない場合、かつITに不慣れ、企業規模が大企業で運用者の代替が、いくらでもきくような会社に対しては、なんでもアリの立派なシステムを提案するべきだ。

アレもできます、コレもできますと言って、UIなんてどうでも良いようなシステムを提案すればよい。
要はWordの論理である。Wordの設定ダイアログは、まさに破綻しているが、売れればそれで良いし、実際、OfficeはMSの稼ぎ頭だ。

また、それでいかに使いやすいUIを設計するかが、開発の腕の見せ所だ。もちろん、UIはシステムの要件の段階で破綻してるものを、なんとかできるようなことはありえないので、その辺はオトナ的対処で（ｗ

そうではなく、もうちょっと小さな会社で、選択者が運用に対して直接的被害を受ける可能性がある場合、いかにUIが簡単でその人の残業時間や危険率が減らせますよ～というアプローチをすることが大事であろう。また、システムの経験が長く、痛い思いを沢山している人に対しても重要。Apple的アプローチと言える。

大事なのは、決定権を持つ人にとって何がcomfirtableか？を読めという話。
なんにせよ、ここをクリアしないことには、何も話が進まないのだから、こちらの自分勝手でこれが良いだろうと提案しても、所詮、話が通じてナンボなんだよな。これが。