機能共有の悲劇

　昔は、解決策4のように、冷水と温水を別の蛇口で出していましたが、今ではそんなレトロな蛇口は（ほとんど）見掛けません。オシャレで便利になった半面、2つの機能を1本のレバーで共有するため、機構が複雑になり（必然的に高価となり）、また、変更や修理が難しくなったことを忘れてはなりません。現実の「保守」としては、解決策1が実践的ですが、ソフトウェアの設計では、そのような機能共有をさせてはなりません。“機能の独立性”を高めた解決策4が圧倒的に優れています。

　機能共有による構造の複雑化や、相互の機能干渉は人間の身体でも発生しており、例えば、「喉」は、呼吸と食物摂取の2つの機能を持っています。「呼吸」と「食物摂取」は、本来は互いに独立した別機能ですが、「喉」によって2つの機能が干渉しあっています。干渉の例として、「餅が喉に詰まると、呼吸困難になる障害」が発生します。食物摂取の障害が、全く別の機能である呼吸に重大な障害を起こすのです。

　ソフトウェアのバグや障害でも、「機能共有」「機能の相互干渉」が原因のものは、再現条件の特定や修正が簡単ではありません。このような構造は可能な限り避けましょう。まずは、“機能共有させないこと”が一番です。冷たい水を出すハンドルと、温水を出すハンドルの2つに分けましょう。ソフトウェアの機能設計において、「一石二鳥」は「百害あって一利なし」だと筆者は思っています。

　機能設計上、水温調整と水量調節の2つの機能を1本のレバーで制御するような機能共有は、本来は「禁じ手」です。こんなユーザーインタフェースを設計して、「オシャレでしょ？」「スタイリッシュでしょ？」と威張ってはなりません。逆に、「機能共有しているので、操作時に混乱する人がいるに違いない」「修理や取り換えが大変だ」と、謙虚で分かりやすい機能構造や表示方法を心掛けるべきです。

　話は大きく変わりますが、今から50年前、まだ一般の人々に「情報処理」と「諜報活動」の区別がつかなかったころ（当時、書店では、この2つのジャンルの書籍が同じ棚に混ざって並んでいました）、筆者の通っていた高校の野球部には部員が6人しかいませんでした。夏の高校野球の大阪府予選大会が始まると、投手は剣道部、遊撃手は卓球部、右翼手は器械体操部の“元中学球児”を借りて、ギリギリ9人で試合に出ていました。これは「体育部における機能共有」です。高校野球の予選の日と、剣道の大阪府大会予選の日程が重なると、ピッチャーがいなくなり、試合に出られません。ソフトウェアの機能の「一石二鳥」は、常にこんな問題をはらんでいます。ソースコードのコーディングを数百ステップ節約できるからといって、機能共有をしてはなりません。少々、コーディングのステップ数が増えても、理解容易性と、機能の独立性を高めましょう。王道の設計を進んでください。

ユーザーインタフェースの問題を発見するために

　デバッグ工程では、実装した機能が仕様通りに動作するか、何度も検証しますが、設計したユーザーインタフェースが意図した通りにユーザーへ伝わるかをキチンとテストすることはほとんどないでしょう。実はソースコードで実装した「機能」よりも、ユーザーの目に直接触れる「ユーザーインタフェース」の方が、特に組み込み系では、使う側にとっての“インパクトが大きい”といえます。製品の評価を大きく左右しますし、顧客からのクレームは、ユーザーインタフェースの不備に起因する場合が多くあります。

　ユーザーインタフェースを設計する際は、ぜひ以下のポイントを考慮してみてください。

　上記の3箇条には、いずれも「～が分かる」で終わっています。「分かる」は、「操作に慣れた人が分かる」のではなく、「全くの素人や、初めて使う人でも分かる」ことを意味します。地元の人には、地元の地図は不要です。海外から来て、初めてその土地を歩く人にこそ地図は必要です。初めて操作する人に伝わってこそのユーザーインタフェース。ぜひ、初心者に実際に使ってもらい、ユーザーインタフェースが役に立っているかをチェックしてみてください。初心者に使ってもらうと、筆者が悩んだ「蛇口の赤色か青色か？」のような、予想外の問題をたたき出せます。組み込み系のユーザーインタフェースが少しでも分かりやすくなれば幸いです。　（次回に続く）

⇒ 新着記事をチェックする