「OOUI本で思い出した話」で思い出した話
佐藤さんのこちらの記事「OOUI本で思い出した話」を読んで思い出したことを書いてみます。
この記事で（記事で取り上げられてる本を僕自身はまだ読んでない。でも関心はあるのでいずれ読んでみるつもり）述べられている「タスク指向UI」と「オブジェクト指向UI」について、私自身も取り組んだことがあります。
私はもともとレジ（コンビニとかスーパーのあれです）のソフトウェア開発をやっていました。今、日常的に見るレジは大きな液晶画面がついていて、もちろんタッチパネルで操作できるのが当たり前のものばかりだと思います。
しかし、かつてのレジは7セグメントディスプレイという数字だけ表示できるディスプレイが主に使われていて、入力もレジに備わっているキーから行うものでした。7セグメントといってもピンと来ない人も多いと思いますが、電光掲示板などで使われる0〜9しか表示できないコレです。
キーの方はというと、数字の入力以外には商品を入力するためのキー（今でこそ買い上げ商品の入力はバーコードが主流ですが、昔はレジ担当者が金額とボタンを押して入力するものだったのです。そっかこういうのいちいち説明しないといけないのか、辛い…）
アルファベット入力用のキーやファンクションキーのようなものはありません。レジのメインの機能は数字（数量や金額）の入力と商品の登録なので、日常の業務だけを考えればそれでいいのですが、スマートフォンやパソコンに設定があるようにレジにも設定がありましたし、商品売上げ業務以外に締め業務もありますのでこれらをこのレジに備わったキーボードで行わなければなりませんでした（設定のためだけのキーを追加するのはコスト増になるのでできません）。
そこで考案されたのが「キーを押す順番によって情報を入力する方法」でした。自宅にあるものなら、プリンタとかファックス、炊飯器などで同じような操作方法を採用しているものが多いかなと思います。
私たちが開発していたレジは「ジョブコード方式」を採用していました。設定したい機能ごとに「ジョブコード」と呼ばれる数字を入力し、自分がこれから何の設定を行うかを入力し、その後に設定情報を数字で入力するという形でした。もちろん、ジョブコードと設定情報を区切るための入力が必要ですので、そこにはレジには必ずある小数点キーや掛け算キー（数量を入力する時に使います）を使い、設定の確定は小計キーや現金支払いキーを使うようにし、レジの標準的なキーですべての操作ができるようにしていました。
たとえば、「２７０１・✖️５✖️１１０１１」 みたいな感じです。「２７０１」が設定項目ごとのジョブコード。「５」が設定項目の詳細番号「１１０１１」が設定データを表します。設定有効が１、無効なら０というように今ならラジオボタンやチェックボックスで入力するような情報を数字の羅列で入力しているのです。古い家庭用電話機とかFAXでも同じような設定方法が採用されていたと思います。
「・」は小数点「✖️」は数量を入力する時に使う掛け算のキーで、接客時の入力に必要なキーをファンクションキーとして使用して入力した数値の意味が確定するようになっています。ちなみに、私の担当したレジでは「・」を押すと設定入力モード、押さなければ設定確認モードになるという仕様でした。
画面上に表示されるメニューを操作するのと違って、操作順序、設定用の番号、設定内容を入力するための数字の並び方などを覚えていなければ設定ができません。一桁入れ間違うだけで全く意図しない設定になってしまうという代物でした。
幸い、レジにはレシート用のプリンタも標準で装備されていましたから設定内容をレシートに印刷することで設定内容を確認できるようにはしていましたが、それでも入力の難しさは変わりません。当時のレジの設定というのはとても難しいものだったのです。
このジョブコード方式の操作が、いわゆる「タスク指向UI」です。
タッチパネル操作の採用
時は流れ、世の中に液晶を使った商品が増え、さらに液晶画面に触れるタッチパネルを操作デバイスとして採用する機器がでてきました。私の担当する製品ラインアップでもようやくタッチパネル操作の製品の企画が立ち上がり、私は仕様設計とソフトウェアの基本設計から関わりました。
といっても、私の担当していたラインアップは組み込み機器用のマイコンを使ったものでグラフィック機能はなくメモリ容量も少なかったので、他の商品のように綺麗なグラフィックを表示を使えず、キャラクター単位の表示を組み合わせてボタンのような見た目を作る前時代的な商品でしたが…。
タッチパネル操作になるということで、私が最初に行ったのは画面とメニュー階層の仕様設計でした。これまでの「ジョブコード方式」と違って、情報を画面上に表示したメニューを選ぶだけの「オブジェクト指向UI」への転換をはかるべくUI仕様を再設計しました。
再設計とはいえ、従来とまったく異なるとこれまでの操作に慣れた方がとまどってしまうので、ジョブコード方式で実現されていた「目に見えない階層構造」を画面上のメニューという形で見えるようにしたことで、従来の操作方法に慣れた方も、慣れた方にも初めて使う方にもわかりやすいUIが実現できた、はずでした。
営業の反発
しかしながら、試作ができ実機で動くレベルになった時に営業（ヨーロッパ向け製品だったので営業担当はドイツ人でした）からこれでは困るという話が上がりました。操作に時間がかかってしまうというのです。
販売代理店の担当者やサービスマンは、従来の操作方法に慣れているので「ジョブコード」で入力できた方が設定が早くできる、設置にかかる時間が短縮できるので「ジョブコード入力」の方がよかった、というのです。
さらに、販売代理店（いわゆるディーラー）は自分たちが取り扱いしやすい機器を優先的に担ぐ（営業用語で、一般的に言う推しみたいな意味ですね）傾向にあるので、従来の操作方法が変わってしまうと販売代理店の扱いが悪くなるかもしれない。というのが営業の言い分でした。
そして改修
業務用機器、産業用機器の世界では販売代理店の力は絶対です。なんとか、タッチパネル操作の使いやすさを残しつつ、従来の「ジョブコード入力」方式を取り入れられないか？ということで画面仕様（配置するキー、レイアウト、ゾーニング）を考え直し、ソフトウェアアーキテクチャを見直してなんとか営業が納得できる形の仕様と実装にまで持って行きました。その機種の資料ないかな〜とおもったら、なんと取り扱い説明書がネットで公開されてました笑。
幸い、この改修は大当たりし製品リリース前の販売代理店向けお披露目会では、操作性の良さを評価していただきました。新しい機種で操作方法が変わっているにもかかわらず、その場にいた販売代理店担当者同士で操作方法を教え合うという謎の光景が繰り広げられたそうです。
進化の障壁はそこかしこに
業務用機器、産業用機器の使い勝手の悪さはよく批判の対象になりますが、たとえばこんな事情もあるので。それ以外には、操作方法を変えてしまうと再教育が必要になる、現場のマニュアルをリプレースしなければならない、など色んな障壁がありますね。
もちろん「タスク指向UI」よりも「オブジェクト指向UI」の方が人に優しいということは、みんなわかっているのですが関わる人が多ければ多いほどそれを変えていくのは難しくなるのです。
エンジニア人生の集大成でした
この機種の開発は自分にとっては忘れられないもので、エンジニア人生の集大成とも言える開発だったことを今でも思い出します。商品仕様設計、画面設計、API設計（メニュー表示、ウインドウ処理、イベント処理）、アプリケーションの開発サポート、一部アプリケーション開発を担当しましたし、アプリケーション担当者からフィードバックがあればAPI仕様への反映などもすべてひとりでやってました。
CPUは200MHzのSH4、ROM容量は忘れてしまったけど今のスマートフォンアプリから考えると信じられないぐらいの極小容量です。
開発言語はC言語、オブジェクト指向の仕組みなんて一切なかったので自前のAPIでオブジェクト指向風の仕組みを構築して、画面の追加や削除、イベントの伝播などを取り扱いしやすくしました。自分でいうのもなんですが、この仕組みによって画面仕様の変更にかかる工数が圧倒的に少なくできたのです。
まとめ
えっと、最後は思い出話というか自慢話になってしまいましたが、タスク指向UIからオブジェクト型UIへの転換には、作り手だけの考えではなくその製品に関係するすべての人の理解と協力が必要であり、過渡期にはそこを橋渡しする仕組みも必要だったということです。今はスマートフォンの普及が進み、オブジェクト指向UIへの理解も一般的になっているのでこれからはどんどん置き換わっていくでしょうね。
one more thing
思いのほか反響（主に知り合いですが）があったので、少し追記してみます。
オブジェクト指向風の仕組みを作ったと書きましたが、正確にはこのモデルのもっと前にはできていました。といってもそれを設計したのも私で、この時の開発で「オブジェクト指向」の良さを完全に理解しました。何かを理解するためにはその対象を学ぶよりも作った方が速いですね。
その後、私は一時的にこの部署を離れることになります。その間に他の方によって機能拡張されましたが、あまりにもひどい実装だったので9年後に戻った時に完全にやり直しました。この記事はその時のものです。おかげで開発スケジュールは遅れに遅れましたが、それでも後々のことと考えればそれでよかったと思っています。